AIに「ブログ投稿まで」終わらせるツールをCloudflare無料枠で作らせて、ChatGPTから直接使ってみた（笑）

この記事のまとめ

ブログの記事はAIに書いてもらえるのに、最後の「投稿」でストップ。使っていた連携サービスの無料投稿枠がゼロになったのです。そこで「なら、投稿する道具そのものをAIに作ってもらおう（笑）」と、MUSEに頼んでみました。

Cloudflareの無料枠で自分用の投稿窓口を作る作戦です。でも、意外と苦労したのはプログラムより「ログインと認証」。ユーザー名を取り違えたり、AIだけでは進めない画面があったりして、人の助けも必要でした。

それでも完成した道具をChatGPTから直接使い、以前の記事を探す → 下書きを作る → 保存した内容を確認するところまで成功！ 記事公開はまだ試していません。その後、画像登録と下書きへの挿入もMUSEのMCP試験で成功しました（ChatGPTから新機能を使う試験は未実施）。

今回のいちばん面白い点は、AIを替えても、同じブログ投稿の道具を使えること。AIに文章を書かせるだけでなく、AIがブログ更新をできるようになる「道具」まで作ってもらえます‼︎ そんな小さな実証です。

さて、次の項からは、実際に困っている/やってみたい‼︎人向けに詳しく説明していきます‼︎

AIに「ブログ投稿まで」終わらせるツールをAIで、Cloudflare無料枠で。

AIにWordPressの記事を書いてもらう。そこまでは簡単になりました。 では、そのAIに「ブログを更新する道具そのもの」を作ってもらったらどうなるのか。

きっかけは、WordPress連携サービスのWPWriterの無料投稿枠を使い切ったことでした。記事も画像もできているのに、最後の投稿で止まる。そういうときは有料プランにするのが普通なのでしょうが、今回は「それなら自前で作ってみようか（笑）」ということに。

実装はAIのMUSEに依頼。Cloudflare Workersの無料枠を使って、campsite7.jp用のWordPress投稿・更新ツール「adc-wp-poster」を作りました。2026年11月10日の実機テストでは、記事の検索、下書き作成・読戻し・更新、画像登録まで成功。その後、MUSEにMCP対応も依頼し、ChatGPTの通常チャットから自作の投稿ツールを呼び出して、下書き作成まで成功しました。今回は、最初の構築から「@で指定したら動いた（笑）」という最後の一歩まで記録します。

出来上がったのは「AI用のWordPress投稿窓口」

構成は思ったより単純です。

WordPress側に別のAIを住まわせたわけではありません。記事を書くAIと、WordPressへ投稿するための小さな道具を分けました。投稿ツールを自分で持てば、AIを変更しても同じ窓口を使えます。これがAD&Cの「AIを替えても、続きから」にもつながる発想です。

Workerは1ファイルに管理画面とAPIを同居させ、データベースはなし。記事本文・画像などの実データは引き続きWordPressに置きます。今回の構築ではWorkers Freeを使い、新たな有料契約やKV・D1・R2などの追加ストレージを作らずに動かしました。ただし、将来の利用量によっても常に無料とは限りません。

何ができるようになった？

機能	2026年11月10日の確認結果
記事検索・重複確認	既存記事と下書きの検索に成功
WordPress認証での読戻し	既存の記事を取得できた
下書きの作成	テスト下書きID 26481を作成
下書きの更新	記事本文と抜粋を更新して再取得、draftのまま維持
画像アップロード・検索	テストメディアID 26483を登録して検索
記事公開	操作機能を実装。今回のテストでは実行していない

つまり、「AI用の管理画面が見える」だけではなく、WordPressに本物の下書きと画像が残ったことまで検証しています。一方で、公開操作と長期安定性はまだ別の検証課題です。その後MCP連携を追加し、ChatGPTから記事の検索・読戻し・下書き作成まで成功しました。

追記：ChatGPTから自作MCPを直接使えた（笑）

「MUSEがブラウザーで操作できる」だけでは、別のAIが使うたびに人間が操作する必要があります。そこで、同じWorkerにStreamable HTTP形式のMCP入口 /mcpを追加してもらいました。Cloudflareの既存管理画面とAPIはそのまま、ChatGPT向けには「検索・読戻し・下書き作成」の3機能だけを公開。公開と削除は出しません。

MUSEの実装報告では、MCPやOAuthの動作試験が19/19 PASS。MUSE側で試験下書きID 26484 ができました。そして11月10日、ChatGPTの非公開Plugin「AD&C WP Poster」を接続した状態で、独立した通常チャットから試しました。

ChatGPTでの実試験	結果
search_posts でInsta360記事を検索	PASS：記事ID 26477
get_post で記事のHTMLと状態を読戻し	PASS
create_draft で試験記事を作成	PASS：記事ID 26485
get_post で作成記事を再取得	PASS：本文・抜粋・カテゴリ一致、status=draft
既存記事の変更と公開	どちらも未実施

ここではWPWriterの投稿クレジットも、ブラウザー操作用のWorkも使っていません。 記事の作成と読戻しは、ChatGPT→Cloudflare Worker→WordPressの経路で成立しています。

最後の落とし穴：「@名前」がないとツールが見つからない？

ここはAIの手順書に加える価値がありました。接続後、普通に「投稿ツールを使って」と頼んだ最初のチャットでは、AIは専用ツールを見つけられませんでした。ところが、次に@AD&C WP Posterを明示したら、3つのツールが利用でき、下書き作成まで成功。

原因はPluginの選択が曖昧だった可能性が最も高いと考えています。ただし、接続の反映に時間がかかった可能性もあるため、@指定だけが原因とまでは断定できません。ChatGPTの公式案内でも、プラグインを@メンションや入力欄の選択操作で明示できます。

ここでの最小ルールは「ツールが見つからなければ、接続失敗と決めつける前に、@で対象Pluginを選択する」です。「常に許可」は操作承認の扱いであり、対象Pluginを確実に選ぶ手順とは別。サービスを勝手にWPWriterへ切り替えて試験成功と見せないことも重要です。

手順書というより『AIも人間も迷ったら、入口を指さす』という小さなナビですね（笑）。

追記：MUSEに渡したMCP対応の指示文（公開用）

既存Cloudflare Workerの管理画面とAPI、Secret、WordPress接続を保持し、ChatGPTから操作するためのMCPを追加してください。
1. Streamable HTTPの/mcpを実装し、search_posts、get_post、create_draftを提供。公開・削除・一括変更はMCPに出さない。
2. ChatGPTとの接続方法を現行の公式仕様で確認し、秘密鍵を公開せずOAuth等で安全に認可できるようにする。
3. 既存APIの回帰試験、MCPのツール一覧取得、記事検索・読戻し、試験用下書き作成・再読戻しを実施する。
4. デプロイ版・試験下書きID・成功/未確認を分けて記録。テスト記事は一般公開しない。
5. ChatGPTへのPlugin登録と会話内の実動試験は別の検収項目にする。接続承認が必要な一手だけ本人へ依頼する。
6. 実装経緯、問題と修正、一般化した手順をPlaybookへ反映。秘密鍵の値はチャットや公開資料へ記録しない。

実装の詳しい技術記録と手順は、MUSEのMCP実装記録、Playbook v1.1を参照してください。個人用のアクセスキーは掲載していません。

一番苦労したのはコードより「ログイン名」（笑）

実際の作業で意外だったのは、機能を増やすことよりWordPressとの認証の切り分けでした。

Cloudflareにアプリケーションパスワードを登録したのに、APIは記事の編集権限がないと返してくる。さらに「無効なパラメータ：status」という一見関係なさそうなエラーまで発生。

原因は、Cloudflareの変数WP_USERにWordPressの「表示名」を入れていたことでした。必要だったのは、プロフィールに載っている実際のログイン用ユーザー名（user_login）。そこを直すと、同じアプリケーションパスワードで認証が成立しました。

役立ったのが、WordPressのアプリケーションパスワードの「最終使用日」です。空欄なら、少なくともそのパスワードで成功した認証履歴は確認できない。原因の候補を、ユーザー名・秘密情報・デプロイ状況に絞って調べられます。

ほかにも、Cloudflareのコードエディタに長いソースがうまく貼り付かない、ログイン画面のTurnstile検証をAIのブラウザーで通せない、といったことがありました。そこだけは人間がログインや設定を補助し、後はMUSEが再試験。「すべて自動」ではなく、「自動化できない最後の一手だけを人間がやる」というのが、今回の実態です（笑）。

設定の手順：最小構成

以下は今回MUSEが残した実証Playbook v1.1を基に、一般化した手順です。細かい画面名称はサービス更新で変わることがあります。

1. WordPressの投稿先を決める。 HTTPSのサイトで、REST APIとアプリケーションパスワードを利用できるか確認する。
2. Cloudflare WorkersでWorkerを用意する。 管理画面とAPIを持つソースを配置してデプロイする。機能は記事の検索、下書き、更新、画像登録、独立した公開操作だけでよい。
3. WordPressで専用アプリケーションパスワードを発行する。 サイトの管理画面→ユーザープロフィールから、用途を識別できる名前で作成。画面に表示された値を公開資料やスクリーンショットに含めない。
4. Cloudflareで認証設定する。 ACCESS_KEY（投稿ツール用・Secret）、WP_APP_PASSWORD（WordPress用・Secret）、WP_USER（user_login、Var）。Secretはソースコードへ書かない。
5. プロダクションへデプロイする。 変数を追加しただけで終わらず、反映された版を確認する。
6. 小さな順序で試験する。 鍵なしAPIが401→鍵ありでカテゴリを取得→既存記事の読戻し→検索→テスト下書きの作成・更新・読戻し→テスト画像登録、の順。公開はこの試験に含めない。
7. 記事公開を独立操作にする。 下書きの保存と公開は別の機能。公開IDを指定して確認操作を行い、公開URLを再取得する。

今回作ったのは個人用の試作です。現状のアクセス制限はWorkerのアクセスキーが中心で、Cloudflare Accessによる追加の認証はまだ導入していません。公開記事で秘密のアクセスキーや本番Workerの管理用設定を配布しないこと、第三者向けに使う場合は認証を強化することが重要です。

公開：MUSEに渡した開発指示文（再利用できるように整理）

AD&Cで公開するなら、完成物だけでなく「どう依頼したか」も残したいところ。以下は、実際の依頼の内容を一般向けに整えた再利用用の指示文です。サイト固有の情報や秘密の値は含みません。

あなたはCloudflare WorkersによるWordPress投稿ツールの開発担当です。
設計だけで終了せず、実環境で下書きの作成・読戻しまで進めてください。

目的：既存WordPressサイトに、AIが作った記事と画像を投稿できる自前の道具を作る。
最初はブラウザーで操作できる小さな管理画面＋認証付きAPIを優先し、MCP連携は将来の拡張とする。

1. CloudflareとWordPressの既存構成を確認し、同種Workerの重複作成や既存環境の破壊を避ける。
2. WordPress REST APIで記事検索、下書き作成・更新・読戻し、画像検索・登録、明示的な記事公開を実装する。
3. 接続先を所有する1サイトに固定し、認証情報はCloudflare Secretsに保存。コード・GitHub・公開資料には書かない。
4. 管理画面/APIはアクセス制限を設け、公開機能は下書きとは独立させる。記事の削除・一括変更は実装しない。
5. 鍵なし401→鍵あり接続→記事読戻し→テスト下書き作成・更新→画像登録、の順に実機試験する。テスト記事は公開しない。
6. 実装ソース・設定方法・詰まった点・回復手順を、秘密の値を除いて記録する。
7. デプロイURL、テスト記事ID、画像ID、各機能のPASS/未検証、追加費用の有無を報告する。

新規課金は行わず、確認できない作業を完了済みと報告しない。
人間の認証操作が必要な場合、その1工程だけを依頼して継続する。

上の文章は公開用に一般化した版です。各自のWordPress URL、ログイン用ユーザー名、APIの鍵は手元で設定してください。アクセスキーやアプリケーションパスワード自体は、AIの公開チャットやGitHubに書き込まないでください。

結論：投稿枠が足りないなら、道具を作る選択肢もある

今回の収穫は「WordPressへの投稿が無料になった」という単純な話だけではありません。

記事を書くAIと、記事を置く道具を分離する。 そうしておくと、AIのサービスやプランを替えても、自分のWordPressへの出口は残せます。今回はMUSEが実装を担当し、画像登録に加えて、ChatGPTから自作MCPでの下書き作成・読戻しまで実際に確認しました。

しかも今回の経緯自体が、先に公開したInsta360 X4の記事につながっています。カメラのUSBハブを調べていたら、なぜか最後はブログ投稿の道具まで自作することになりました（笑）。

公開機能の本番検証、さらに別のAIからの直接利用、アクセス制限の強化は次の課題です。できたことと、これから確かめることを分けながら、道具を育てていこうと思います。

記録・追記：2026年11月10日。構築・試験結果は個人環境の実例です。クラウドサービスの無料枠・画面・認証方法は変更される場合があります。