Power Automate × Claude API で社内SEがブログ自動化に挑戦した記録

休日に何となく思いついて、ブログ運用を半自動化するシステムを組みました。

使ったのは、Power AutomateとClaude APIとWordPress REST API。

名前を並べただけで強そうですね。

軽い気持ちで始めたんですが、結論から言うと半日では終わりませんでした。

正確には、半日で「動くもの」はできました。

そこから「実用に耐えるもの」にするのに、さらに数日かかりました。

しかも、何回か心が折れかけました。

今回は、その全部を残しておきます。

同じことをやりたい人の参考になれば。

そもそも、なぜブログを自動化したかったのか

本題に入る前に、私の動機を書いておきます。

私はブログを書くのが、そこまで嫌いではありません。

ただ、リライトが嫌いです。

正確には、過去の記事を見るのが嫌い。

昔の記事を見ると、こう思います。

「なんで、この文章で公開した？」

普通にあります。

あと、地味に面倒な作業が多いです。

• タイトル調整
• 見出し調整
• 語尾修正
• SEO意識
• 内部リンク
• 誤字確認

新記事は楽しい。

でも、リライトは修繕工事です。

テンションが、まったく違う。

そこで考えました。

「これ、AIにやらせればよくない？」

とは言え、チャッピーやクロに毎回コピペするのも、それはそれで面倒です。

人間、怠惰の方向には驚くほど努力できます。

だったら、記事取得から下書き保存まで全部自動化したい。

そう思ったのが始まりでした。

あと、社内SEの悪い癖もあります。

「効率化できそうなものを見つけると、触りたくなる」

これは、もはや職業病です。

本業ではない部分でも、勝手に動いてしまう。

たぶん、同業の人なら共感してもらえると思います。

完成したシステムの構成

先に、何ができるシステムなのかを書いておきます。

やっていることは、こんな感じ。

• SharePointリストに「リライトしたい記事ID」を登録
• Power Automateが定期実行で取得
• WordPress REST APIで記事本文を取得
• Claude APIに投げてリライト
• WordPressに下書きとして保存
• 完了メールが届く

文字で書くと簡単そうですね。

私も最初はそう思っていました。

結論から言うと、ここに辿り着くまでの道のりが、まあまあ地獄でした。

特に、WordPress REST APIが想像以上にクセものです。

あと、Claude APIに対する勘違い。

あと、SiteGuard。

君か__。

使った技術スタックを並べると、こうなります。

• Microsoft 365（SharePoint・Power Automate・Outlook）
• Claude API（Anthropic）
• WordPress REST API
• ConoHa WING（サーバー）

業務システム寄りのスタックで、個人ブログ運用をやる。

社内SEあるあるです。

初期費用と運用コストを表にすると、こんな感じです。

項目	費用
Microsoft 365 Business	月1,500円程度
Claude API 初回購入	$5（約750円）
ConoHa WING	既存契約
1記事あたりのAPI実費	$0.05〜$0.30
22記事リライト総額	約$2.40（約360円）

22記事のリライトに360円。

外注したら、ゼロ1個追加でも足りない金額です。

時代、変わりすぎ。

構築でハマった3つのポイント

順番に振り返ります。

後から見ると笑えますが、当日はめちゃくちゃ真顔でした。

401と301と403の三連コンボ

WordPress REST APIを叩こうとすると、エラーがコンボで飛んできます。

まずは、401。

「認証できません」と言われます。

原因は、認証設定の入れ忘れ。

Power AutomateのHTTPアクションには、認証タイプを「Basic」に設定する欄があります。

ここをデフォルトの「None」のまま使っていました。

普通に入れ忘れ。

事前にブラウザでURL叩いてJSONが返ってくることまで確認してたのに、Power Automateに移った瞬間に忘れる。

人間、別の画面に移ると別の生き物になります。

次は301。

「恒久的にリダイレクト」と返されます。

原因は、URLを「http」で書いてました。

「s」が足りない。

これも、普通にミス。

そして本日のラスボス、403。

「Forbidden」と言われます。

つまり、お前のリクエストは受け付けない、という宣言。

これは認証ミスではなく、別の理由でブロックされていました。

犯人については、後で書きます。

Claude API、別料金問題

これは多くの人がハマるはずです。

私はClaude MAXを契約しています。

月額固定で、Opusも使い放題。普段のお供です。

なので、こう思いました。

「APIも、契約に含まれてるでしょ。」

含まれてませんでした。

Claude APIは、完全に別料金です。

従量課金です。

つまり、サブスクの顔して、別請求が出てきます。

現代っぽいですね。

料金自体は安いです。

記事1本のリライトで、だいたい15円ぐらい。

使うモデルにもよりますが、軽いモデルなら本当に安い。

ただ、最初に最低$5を購入する必要があります。

あと、自動チャージ設定があります。

これは必ずOFFにしましょう。

気付いたら数万円、みたいなのが一番怖いので。

月の使用量上限も、最初は低めに設定するのをおすすめします。

私は$5に設定しました。

足りなくなったら増やせばいい。

逆は、しんどい。

SiteGuard、君か__

403エラーの犯人がこれでした。

SiteGuardは、WordPress用のセキュリティプラグイン。

ConoHa WINGなら、ほぼ標準で入っています。

こいつが、書き込み系のリクエストを誤検知でブロックしてきます。

読み込み(GET)は通る。

でも、書き込み(POST)は通らない。

厄介なのが、エラーがHTMLで返ってくることです。

JSONを期待していたのに、HTMLで「閲覧できません」と表示される。

初見だと、正直何が起きてるかわかりません。

レスポンスを開いた瞬間に「Powered by SiteGuard Lite」の文字が出てきて、ようやく気付きました。

君か__。

ただ、ここからが本当の地獄でした。

SiteGuardを無効化しても、403が出続けたんです。

はい？

WAFとの戦い、2種類の番人が立ちはだかる

SiteGuardを無効化しても、エラーが消えませんでした。

ここで、私は重大なことに気付きます。

WAFが、2種類いた。

知らんて。

プラグイン側WAFとサーバー側WAF

WAFはWeb Application Firewallの略です。

怪しいリクエストを止める、Webの番人。

セキュリティ的にはありがたい存在。

でも、自分のリクエストが止められると、ただの邪魔者。

私の環境には、こいつが2人いました。

• SiteGuard WP Plugin（プラグイン側）
• ConoHa WINGのWAF（サーバー側）

SiteGuardは、WordPressのプラグイン。

WordPressに入ってから働く番人。

ConoHa WINGのWAFは、サーバー側。

WordPressに辿り着く前に止める番人。

つまり、二重の城壁。

SiteGuardを無効化しても、サーバー側で止められていました。

そりゃ、エラー出続けるわ。

「MsgBox」「Replace」が攻撃扱いされる悲劇

もっと笑えるのが、誤検知される単語です。

私のブログは、VBA記事が多いです。

VBAのコードには、こういう関数が出てきます。

• MsgBox
• Replace
• Select
• Application

VBA書く人なら、毎日見る単語です。

これが、WAFにXSSやSQLインジェクションと誤認されました。

君ら、犯罪者じゃないんだから。

特にSelect。

SQLのSELECTと同じ綴りなので、WAFが過剰反応します。

WordPressの記事にVBAコードを投稿しようとすると、403。

VBA系の記事は、ほぼ全滅でした。

WAFは、コード内容と攻撃コードの区別ができません。

当然と言えば当然。

でも、技術ブログ運営者には致命的です。

WAFを止めずに通す方法

解決策は、3つ試しました。

1つ目は、WAF自体を一時的にOFF。

これは却下。

セキュリティ捨てるのは、さすがにナシ。

2つ目は、SiteGuardの「WAFチューニングサポート」。

これを有効化して、ブロックされたパターンを「除外」する方法。

プラグイン側はこれで解決。

3つ目は、ConoHa側のWAFで、特定IPだけ除外する方法。

Power AutomateのIPアドレスは、毎回変わります。

固定できない。

つまり、IP除外戦法は使えない。

仕方なく、サーバー側のWAFを「ログのみ」モードに変更しました。

これで、検知はするけど止めない、という状態。

セキュリティ的には妥協です。

個人ブログだから許容範囲、と自分に言い聞かせました。

本職的には、絶対NGの設定です。

知らんて。

6,998件のロック履歴、XMLRPC事件

WAFの設定を見ている時に、もう1つ気になるものを発見しました。

SiteGuardのログ画面。

ロック履歴の件数が、なんかおかしい。

▼詳細はコチラの記事で紹介しています

6,998件、という数字

ログを開いた瞬間、目を疑いました。

ロック履歴：6,998件。

__。

桁、間違ってない？

個人ブログのアクセス数を考えると、明らかに異常。

PV数より、ロック件数の方が多い日もありました。

これは普通なのか。

結論から言うと、普通でした。

WordPressサイトには、毎日大量の攻撃が飛んできます。

気付いていないだけ。

攻撃元IPの正体

ログを掘ると、攻撃元IPが見えました。

調べてみると、ほとんどが海外。

具体的には、こんな分布。

攻撃元	件数（概算）
中国	約3,200件
ロシア	約1,500件
東欧諸国	約1,100件
アメリカ	約700件
その他	約500件

個人ブログに、なぜここまで来るのか。

答えは単純で、ターゲットは私じゃないからです。

「WordPressサイト全般」が狙われている。

botが手当たり次第に、世界中のWordPressサイトを叩いている。

私のサイトは、その中の1つにすぎない。

狙いは、ほぼ100%がxmlrpc.php。

そして、wp-login.phpへのブルートフォース。

WordPressの定番攻撃ポイントです。

xmlrpc.phpを完全無効化した

xmlrpc.phpは、WordPressの古いAPI。

REST APIが登場する前の、レガシー機能です。

今は、ほとんど使われません。

でも、デフォルトで有効になっています。

つまり、使ってないドアが開きっぱなし。

そりゃ、攻撃される。

無効化の方法は3つあります。

• SiteGuard WP Pluginの「XMLRPC防御」をONにする
• .htaccessで完全拒否
• 専用プラグインを入れる

私は2つ目を選びました。

.htaccessに、こう書きます。

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

これで、xmlrpc.phpへのアクセスは全拒否。

サーバー側で、WordPressに到達する前に弾けます。

WordPress側で処理するより、圧倒的に軽い。

無効化の副次的メリット

これが、想像以上に効果ありました。

無効化前後で、こんな変化が出ました。

項目	無効化前	無効化後
1日のロック件数	約300件	約20件
サーバーレスポンス	平均1.2秒	平均0.8秒
SiteGuardログ容量	肥大化	軽量

サイト速度まで上がりました。

攻撃を捌くだけで、サーバーは結構なリソースを使っていたわけです。

個人ブログにxmlrpcは不要。

速度のためにも、セキュリティのためにも、消しましょう。

Jetpackやモバイルアプリ経由の投稿を使っている場合は、影響が出ます。

でも、私みたいに使ってない人は、無効化推奨です。

放置していた古いドアを、ようやく塞いだ気分です。

APIキーを画面に映してしまった事件

これは、技術というよりやらかし話です。

Power AutomateでHTTPアクションを設定する時、ヘッダーにAPIキーを入れます。

その画面のスクショを、AIに送って相談していました。

普通にAPIキーが、画面に映ってました。

__。

慌ててAPIキーを削除して、再発行しました。

AIに教えてもらって、ようやく気付くというマヌケ。

これ、地味に怖いポイントです。

APIキーは、お財布の鍵と同じ。

流出すると、第三者に勝手に使われて、勝手に課金されます。

Power Automateには「セキュアな入力」という設定があります。

これをONにすると、実行履歴で入力値がマスクされます。

編集画面では普通に見えますが、ログには残らない。

APIキーを扱う時は、必ずこれをONにしましょう。

あと、AIに相談する時のスクショは要注意です。

映ってはいけないものを、普通に映してしまいます。

人間、慌てている時ほど、危険な行動を取ります。

「WAFテスト走行」というアイデア

WAFとXMLRPCの問題が片付いて、いよいよリライト本番です。

でも、22記事を一気に流すのは怖い。

失敗したら、被害が大きすぎる。

そこで考えたのが、「WAFテスト走行」という方式でした。

「先書き→上書き」パターンの発想

普通のリライトは、こうです。

• 記事本文を取得
• AIにリライトを依頼
• 結果を下書きに保存

シンプルです。

でも、AIの処理時間が読めない。

Power Automateには120秒のタイムアウトがある。

そして、WAFが何を弾くか、本番まで分からない。

そこで、こう考えました。

「先に空の下書きを作って、後で上書きすればいい」

具体的にはこうです。

• ステップ1：まず空の下書きをWordPressに作る
• ステップ2：別のフローで、AIリライトを実行
• ステップ3：結果をその下書きに上書き

これだと、ステップ1の時点でWAFを通るか判定できます。

テスト走行、というネーミングはこれです。

本番リクエスト（AIリライト結果）を投げる前に、軽量リクエスト（空の下書き作成）で道を確認する。

業務システムの「疎通確認」と同じ発想です。

社内SEの癖が、ここでも出てしまいました。

22記事中9記事が一発で通った

このパターンで、22記事を流しました。

結果がこちら。

結果	件数
一発で通った	9件
1回リトライで通った	8件
2回以上のリトライ	4件
手動で修正必要	1件

正直、もうちょい通ると思ってました。

一発通過率、約40%。

VBA記事はやはり、WAFの誤検知率が高い。

コード量が多い記事ほど、引っかかる。

逆に、解説中心の記事はほぼ一発で通りました。

これは、事前に予測できた結果でもあります。

でも、数字で見ると説得力が違う。

実測データは正義です。

4時間ずらしスケジュールの効果

もう1つ、地味だけど大事な工夫があります。

記事の処理を、4時間ずつずらすこと。

理由は2つ。

1つは、WAFのレート制限を避けるため。

同じIPから連続してリクエストを送ると、WAFが警戒します。

22記事を一気に投げると、途中から弾かれる確率が上がる。

もう1つは、AI料金の月次平準化。

API使用量上限を$5に設定していたので、1日に使いすぎると止まる。

SharePointリストの「実行予定時刻」列に、4時間刻みで時刻を入れる。

Power Automateが、その時刻ごとに1件ずつ処理。

これで、システムが勝手に分散実行してくれます。

夜中に走らせれば、朝には全部終わっている。

寝てる間にリライトが進む世界。

これが、なかなか気持ちいい。

実測データで見るリライト結果

22記事を流した結果を、数字で残しておきます。

感想だけじゃなく、データで残すのが社内SEの性です。

文字数の変化

特に伸びが大きかった3記事をピックアップします。

記事	元文字数	リライト後	増加率
PowerApps 2000件問題	1,749字	6,361字	+264%
VBA Do While / Do Until	2,103字	5,892字	+180%
VBAでセルの保護	1,855字	4,720字	+154%

PowerApps記事、3.6倍。

増えすぎでは？

と思いきや、読んでみると意外と自然に肉付けされていました。

元記事の骨格は維持されている。

説明が薄かった部分が、ちゃんと埋まっている。

嘘の情報が混入していないかは、別途確認が必要ですが。

Sonnet vs Haiku の処理時間とコスト

同じ記事を、Sonnet 4.6とHaiku 4.5で処理してみました。

項目	Sonnet 4.6	Haiku 4.5
1記事の処理時間	平均85秒	平均32秒
1記事の総コスト	$0.18	$0.05
22記事の合計	約$3.96	約$1.10
HTML構造維持	9/10	7/10
文体再現度	8/10	6/10

Sonnetの方が、文体の再現が圧倒的に上手い。

Haikuは速くて安いけど、語尾が単調になりがち。

「かもと節」を狙うなら、Sonnet一択でした。

コストの差は、22記事で$2.86。

約430円。

この差なら、品質を取ります。

1記事あたり13円の差で、ストレスが減るならお安いもの。

大量処理が必要な場合は、Haiku。

品質重視なら、Sonnet。

そんな使い分けに落ち着きました。

AIに任せて分かった「人間の出番」

システムを組む前、私はこう思っていました。

「リライトぐらい、全部AIでいけるでしょ。」

実際にやってみると、考えが変わります。

Claude API、確かに優秀です。

普通に自然な文章を返してきます。

でも__

普通に壊します。

しかも、自然に壊します。

• 見出しタグが消える
• 箇条書きが平文化する
• 内部リンクが消える
• 勝手にまとめが追加される
• 逆にまとめが削除される

怖いのは、ぱっと見は自然なところ。

これ、人間がチェックしないと普通に事故ります。

あと、AIが書く文章には独特の癖があります。

「__と言えるでしょう」

「__が重要です」

「いかがでしたか？」

このへんを使い出した瞬間に、ブログ全体がAI臭くなります。

SEO的にも、いまや差別化要素にはなりません。

むしろ、量産AI記事と同じ扱いを受けて沈みます。

だから今、私の結論はこれ。

「AIに下書きを書かせて、人間が仕上げる。」

完全自動化はロマンです。

でも、運用目線だと、半自動が一番強い。

下書きまでAI、最終確認は人間。

これが、現時点での最適解だと思います。

体験談やボケは、人間にしか書けません。

あと、唐突な例えとかも。

AIに「君か__」は書けない。

実際、今回の構築中もAIに何度か文体分析を依頼しました。

かなり優秀でした。

でも、唐突に「ラブストーリーは突然に」のパロディを混ぜたり、「クロといっしょ→トロといっしょ→どこいつ」みたいな連想ゲームを仕込むのは、まだ人間の領分です。

たぶん、AIには「やりすぎ判定」が働く。

滑るリスクを取らない。

人間は、平気で滑ります。

そして、滑った先に、独自性が生まれます。

次にやりたいこと

ここまでで、最低限のシステムは動きました。

ただ、効率化したい人間は、ここで止まりません。

次にやりたいことが、すでに山ほどあります。

• プロンプトの精度向上（HTML構造維持・文体ガイド適用）
• バックアップ機能（元記事の自動保存）
• エラーハンドリング（失敗時の自動通知）
• スケジュール実行（毎週月曜AM3時など）
• Search Console連携（順位低下記事の自動抽出）

Search Console連携まで行ければ、本格的な「AIブログ運用システム」になります。

順位が下がった記事を自動検知。

AIが下書きでリライト。

人間が確認して公開。

個人ブログを、ほぼ自動運用できる世界。

夢があります。

ただ、ここまで来ると、本業を超える可能性が出てきます。

社内SEなのに、社外SEっぽい。

あと、もう一つ気になっているのが、Power Automateを使わない構成です。

クロ子（Claude Code）を使えば、ローカルでスクリプトを書いて全部完結します。

こちらの方が、柔軟性は高い。

JSONエスケープ問題も、コードで完全に解決できる。

H2単位で記事を分割して、個別にAIに投げるみたいな、ややこしい処理もやりやすい。

ただ、PCを起動しておく必要があります。

Power Automateはクラウドで動くので、その心配がない。

どっちも、一長一短。

たぶん、最終的には両方使う気がします。

定型処理はPower Automate、複雑な処理はクロ子。

そんな住み分け。

まとめ

今回かかった費用と時間を、最後にまとめておきます。

• Claude API初回購入：$5（約750円）
• 22記事のリライト実費：約$3.96（約594円）
• 構築時間：合計で約20時間（試行錯誤含む）
• 使ったツール：全てMicrosoft 365 + Claude API

個人で組めるレベルとしては、コスパは悪くないと思います。

正直、何回か心が折れかけました。

特に、WAFの誤検知地獄。

あれは、本気で投げ出しそうになりました。

でも、組み上がった瞬間の達成感はありました。

SharePointに登録した数分後に、WordPressにリライト下書きが完成している。

あれを見たら、社内SE的にちょっとテンションが上がります。

数年前なら、これは外注案件でした。

今は、休日に組めます。

時代、変わったなと思います。

たぶん私はまた、余計な自動化を始めます。

社内SEなので。

__

余談ですが、この記事自体も、半分はAIに整えてもらっています。

私が直筆で書いた骨組みに、AIが肉付け。

それを、私が違和感のある部分だけ修正。

つまり、半自動。

今回構築したシステムと、まったく同じ仕組みです。

記事を書きながら、システムが正しいことを証明する。

これも、社内SEっぽい締め方ですね。