MCPでつくる自作AIサーバー #4｜Publishing MCP――ChatGPTからWordPressとSNSまで公開する仕組み

水彩画調で、Publication / Revision / Validation、Draft / Preview / Publish / Schedule、WordPress / SNS配信、Partial Retry / Reconciliationを描いた「MCPでつくる自作AIサーバー 第4回 Publishing MCP」のサムネイル。 MCPでつくる自作AIサーバー

第1回：Development MCPでは、AIが安全に「作る」ための仕組みを書きました。

第2回：Knowledge MCPでは、AIがプロジェクトの状態を「知り直す」ための外部知識基盤を紹介しました。

第3回：Loop Engineでは、結果を見ながら必要な仕事だけを「続ける」仕組みについて書きました。

そして最後に残るのが、作ったものを現実世界へ出すことです。

AIに記事を書かせること自体は、もう珍しくありません。

問題は、その文章をWordPressへ入れ、画像を設定し、カテゴリーやSEOを整え、適切な時刻に公開し、X、Bluesky、Instagramへ媒体ごとの形で投稿するところまで進めようとしたときでした。

文章生成と公開は、まったく別の問題でした。

そこで作ったのが、今回のPublishing MCPです。

以前の連載では、なぜPublishing MCPを作ったのかを詳しく書きました。

→ 記事を書くだけでは自動化にならなかった。Publishing MCPを作った

今回の第4回では、その後実際に使い続けて分かってきたことを中心にします。

Publishing MCPは、今では「WordPressへ投稿するMCP」というより、AIが外部サービスへ副作用を起こすためのpublication lifecycleを管理する仕組みになっています。

AIが記事を書けても、公開作業は消えなかった

ChatGPTで記事が完成したとしても、その時点ではまだ何も公開されていません。

タイトル、本文、slug、抜粋、カテゴリー、タグ、SEO、アイキャッチ画像をWordPressへ設定する必要があります。

SNSも同じです。

Xには文字数制限があります。Blueskyは文章の組み立て方が少し違います。Instagramは記事URLを本文に置くよりプロフィール導線を使う方が自然なことがあります。画像の縦横比や枚数にも媒体ごとの制約があります。

さらに私の場合、サイトが一つではありません。

理系猫凛、Chloroquest、Ordinary Japanがあります。

同じ「記事を公開する」という操作でも、サイト、ブランド、言語、SNSアカウントが違います。

つまり、

文章が完成した

と

正しい場所へ、正しい状態で公開された

の間には、かなり大きな距離がありました。

最初の発想は「WordPress APIを呼べばよい」だった

一番単純に考えれば、WordPressのAPIへ記事を送れば終わります。

実際、それだけなら難しくありません。

しかし、本当にAIへ任せることを考えると、すぐに問題が増えます。

どのサイトへ出すのか。

最新の本文なのか。

下書きなのか公開なのか。

予約時刻はいつなのか。

画像は本当にWordPressへ届いたのか。

SNSはすでに送信済みではないのか。

日本語記事なのか英語記事なのか。

途中で一媒体だけ失敗したらどうするのか。

こうした状態をLLMとの会話だけで覚えておくのは危険です。

そこで、外部へ何かを送る前にPublicationという単位を作るようになりました。

Publicationという「公開予定物」を先に固定する

Publishing MCPでは、記事本文だけをWordPressへ直接送るのではありません。

まずPublicationを作ります。

Publicationには、WordPress記事、SEO、SNS文章、画像、ブランド、公開予定時刻など、「今回何を外へ出そうとしているのか」をまとめます。

概念的には次の流れです。

ChatGPT / Agent ↓ Publication ↓ Validation / Revision / Media ↓ WordPress Draft ↓ Read-back Verification ↓ Publish / Schedule ↓ Buffer → X / Bluesky / Instagram ↓ Reconciliation

ここで重要なのは、WordPressやBufferがシステムの状態そのものではないことです。

まずこちら側に「何を公開しようとしているか」というdurableな単位があり、それを外部サービスへ反映します。

これによって、途中でChatが変わっても、Publication IDから仕事を再構成できます。

これはDevelopment MCPのworkspaceやLoop EngineのRunとよく似ています。

会話を状態にしない。

4本を通して、結局ここへ何度も戻ってきました。

会話中に本文が変わるので、revisionも必要だった

ChatGPTと記事を書いていると、公開直前まで内容が変わります。

タイトルを変更する。一段落削る。数字を修正する。画像を差し替える。SNS文を短くする。

そのたびにPublicationも更新されます。

ここで怖いのが、AIが古いPublicationを見たまま公開することです。

そのため、Publicationにはrevisionがあります。

たとえばrevision 3を確認したあと、別の操作でrevision 4へ本文が更新されたなら、revision 3を前提にした外部書き込みはそのまま実行しません。

確認した状態と、変更する状態が一致するときだけ実行する。

Knowledge MCPでSHAを確認することや、Development MCPでexpected HEADを確認することと、考え方は同じです。

二重投稿は「AIが同じボタンを2回押す」だけでは起きない

Publishingで特に避けたいものの一つが重複投稿です。

同じ記事をWordPressへ二つ作る。Xへ同じ投稿を二回送る。一度成功したのに、内部側では失敗したと思って再実行する。

こうした事故は、単にAIが二回同じ指示を出した場合だけではありません。

ネットワークが途中で切れたり、外部サービス側では成功したのにこちらがresponseを受け取れなかったりすることでも起きます。

そのためPublicationにはidempotencyを持たせています。

さらに、外部サービスへ作ったWordPress postやBuffer postのidentityを保存します。

「もう一度実行された」という事実だけでは、新規作成しません。

前回どこまで成功したかを見る。

ここまでやって、ようやく再試行を安全にできます。

「APIが成功した」と「記事が正しい」は違った

Publishing MCPを作っていて、かなり重要だった発見があります。

APIから200 OKが返っても、それだけでは成功ではないということです。

WordPressへ下書きを作ったあと、実際のWordPressから読み戻します。

タイトルは一致しているか。本文は欠けていないか。slugは正しいか。カテゴリー・タグは意図どおりか。SEO metadataは入っているか。アイキャッチ画像は設定されているか。

つまり、

Write → Response

ではなく、

Write → Read Back → Compare

までを一つの操作として考えるようになりました。

これはPublishing MCPだけの話ではないと思います。

AIに外部サービスを操作させる場合、API responseを成功条件にするより、外部の現実が目的の状態になったことを確認する方が重要です。

それでも外部サービスの状態は後から変わる

読み戻して確認しても、まだ終わりではありません。

SNSサービスでは、送信直後に@@INLINE0@@だった投稿が数秒後に@@INLINE1@@になることがあります。

こちらの内部DBがSendingのままでも、実際にはInstagramへ投稿済みということもあります。

そこで追加したのがreconciliationです。

Publishing MCPは後からWordPressやBufferの状態を読み直し、

内部ではこうなっているはず

と、

外部では実際にこうなっている

を照合します。

現在のPublishing Platformには、このreconciliationを行うworkerも常駐しています。

つまり、Publishingでは「一回APIを呼んだら終了」ではなくなりました。

現実と内部状態が一致するまで観測する。

この考え方もLoop Engineとかなり似ています。

第3回の公開でも、さっそくpartial failureが起きた

これはこのシリーズで実際に起きた例です。

前回のLoop Engineの記事を理系猫凛へ公開したとき、WordPressは正常に公開されました。

Blueskyも成功しました。

Instagramも送信処理へ入りました。

ところがXだけ失敗しました。

理由は単純で、280文字を超えていたからです。

ここでPublishing MCP全体をもう一度実行していたら、すでに成功しているBlueskyへ同じ投稿を再送してしまう可能性があります。

実際にはXだけ文章を短縮し、Xだけ再実行しました。

その後Instagramについても外部状態をreconcileし、@@INLINE0@@から@@INLINE1@@になったことを確認しました。

最終的には、WordPress、X、Bluesky、Instagramの全targetが完了し、Publication lifecycleはcompletedになりました。

これはPublishing MCPを作った理由をかなり端的に表しています。

外部公開では、「全部成功」か「全部失敗」だけではない。

現実にはpartial successがあります。

だから、targetごとに状態を持つ必要があります。

画像も「ファイルを一枚送る」では終わらなかった

記事には画像があります。

しかも、その画像をWordPressだけでなくSNSでも使います。

最初はChatGPTへ添付した画像をどうPublishing MCPへ渡すかが面倒でした。

一度どこかへ公開してURLを作る方法もあります。Base64へ変換する方法もあります。ただ、どちらも不要な処理でした。

現在は、ChatGPTで生成・添付した画像をPublishing MCPへ渡し、対象ブランドのWordPress Media Libraryへ保存し、そのpermanent URLをWordPress記事とBufferの両方で利用できます。

今回の連載でも、この経路をそのまま使っています。

さらにSNSによって画像の制約も違うので、公開前のvalidationで確認します。

つまり画像も本文と同じで、

「ある」ことより、「正しい媒体へ使える状態になっている」こと

の方が重要でした。

3つのサイトを扱うとbrand routingが必要になる

現在のPublishing Platformでは、理系猫凛、Chloroquest、Ordinary Japanの3ブランドを扱っています。

単純にURLを変えているだけではありません。

ブランドごとにWordPress接続先とBufferのchannelが分離されています。

さらにChloroquestでは、現在、日本語・英語のBogo pairを標準の記事release modeとして扱っています。

ここで怖いのは、

正しい記事を、間違ったサイトへ公開すること

です。

文章としては完璧でも、Chloroquestの記事を理系猫凛へ出したら完全な失敗です。

多言語化すると、

正しいサイトだが、言語やtranslation linkageが間違っている

という失敗も加わります。

そのため、brandやlanguageは文章の一部ではなく、Publicationのidentityとして扱う必要があります。

多言語機能については、現在もブランドごとに実装や運用方法が異なり、一つの万能な翻訳publication systemとして完成しているわけではありません。

ここは今後も拡張していく部分です。

WordPress自身もMCP対応した。では自作Publishing MCPはもう不要なのか

この連載を始めた頃と比べて、状況はかなり変わりました。

WordPress.comは2026年にMCPのwrite capabilityを提供し、AIエージェントから投稿の下書き・公開、固定ページ更新、カテゴリー・タグ整理、media metadata編集などを行えるようになっています。

AI agents can now create and manage content on WordPress.com

self-hosted WordPress側でも、Abilities APIで定義された機能をAI Agentへ公開する公式MCP Adapterが整備されています。

From Abilities to AI Agents: Introducing the WordPress MCP Adapter

つまり、

「ChatGPTからWordPressを操作できます」

だけでは、もう自作する意味はかなり薄くなっています。

これはむしろ良いことだと思います。

Publishing MCPで自作する価値が残る部分は、その一段上です。

WordPressだけではなく、複数ブランド、複数SNS、画像、予約、revision、idempotency、多言語、partial retry、reconciliationまで含めて、

一つのpublication lifecycleとして扱うこと。

ここが現在のPublishing MCPの役割です。

Publishing MCPは「WordPress MCP」ではなくなった

現在の構成をかなり単純化すると、こうなります。

ChatGPT / Agent ↓ Publishing MCP ↓ Publication / Revision / Validation ↓ Media ↓ WordPress ↓ Publish / Schedule ↓ Buffer ↓ X / Bluesky / Instagram ↓ Reconciliation

WordPressは重要な出力先ですが、Publishing MCPそのものではありません。

Bufferも同じです。

Publishing MCPの中心にあるのは、

何をどこへ出し、その仕事が現在どこまで完了しているか

です。

この構造になってから、WordPress APIやBuffer APIの仕様変更があっても、publication全体の概念まで壊す必要がなくなりました。

Implementation snapshot ― 2026年9月8日

この記事を公開する2026年9月8日時点で、Publishing Platformはv0.16.1で稼働しています。

保存されているPublication packageは280件です。

これは記事数だけではなく、article campaignやsocial-onlyなどを含むPublicationの総数です。

理系猫凛、Chloroquest、Ordinary Japanの3ブランドを一つのPublishing Platformから扱っています。

WordPressとBufferへのwrite経路は稼働中で、reconciliation workerも正常に動いています。

直近20件のPublication lifecycleでは13件がcompleted、7件が進行中で、そのうち3件はvalidationまたはdeliveryの観点から人間の確認が必要な状態として分類されています。

この数字を見ると、Publishing MCPはもう「試しにWordPressへ一件投稿できた」という段階ではありません。

一方で、Publicationが増えるほど新しい問題も見えてきます。

多言語publicationの整合性。古い記事の更新。既存記事への内部リンク。画像や動画のlifecycle。各SNS APIの違い。予約投稿後の状態確認。公開後のSearch ConsoleやGA4への接続。

Publishingは、公開ボタンを自動化したら終わるシステムではありませんでした。

CLI化してもPublishing MCPは残す

現在、Personal AI PlatformはBrowser ChatGPT中心の構成から、Codex CLI / App Serverをサーバーに常駐させる次世代構成へ移行しています。

このときも、Publishing MCPをCodex側へ作り直す予定はありません。

Codexは、

「この記事は公開すべきか」

「どの媒体へ出すべきか」

「今公開するか予約するか」

といったreasoningを担えるようになります。

しかし、実際の外部書き込みはPublishing MCPのbounded surfaceを使う。

つまり、

Reasonerが変わっても、外部副作用を起こす境界は残す。

これはDevelopment MCPやKnowledge MCPと同じです。

MCPという接続方式が将来変わったとしても、Publishingという責務自体はなくなりません。

Publishing MCPを作って分かったこと

Publishing MCPを作り始めたとき、欲しかったのは「ChatGPTからブログを投稿できる仕組み」でした。

実際に使い続けてみると、必要だったものは少し違いました。

AIが現実世界へ変更を加えるとき、その変更を追跡し、検証し、失敗から復旧できる仕組み。

記事公開は、その分かりやすい一例だったのだと思います。

生成と公開を分ける。

確認したrevisionだけを実行する。

二重実行しても重複させない。

送信したら読み戻す。

一部失敗なら成功済みの部分を壊さない。

後から外部状態とreconcileする。

ブランド、言語、媒体を明示する。

こうした設計は、ブログ以外のAIエージェントにもそのまま使えるはずです。

AIが賢くなるほど、「何ができるか」よりも、

現実へ作用するときの境界をどう作るか

が重要になっていくのだと思います。

4つをつなぐと、自作AIサーバーになった

この4本では、Personal AI Platformの第1世代を構成している4つの仕組みを振り返りました。

回コンポーネント役割
#1Development MCP作る
#2Knowledge MCP知る／知り直す
#3Loop Engine続ける
#4Publishing MCP外へ出す

一つ一つを見ると、それぞれは専用のMCPや実行基盤です。

しかし実際に使っている感覚では、

作る → 知る → 続ける → 外へ出す

がつながって、ようやく「自分の仕事を扱うAIサーバー」になりました。

そして今、この構成自体を次の段階へ移しています。

Browser ChatGPTから毎回MCPを呼ぶ構成ではなく、サーバー側にCodexを常駐させ、仕事全体をより持続的に扱うCLI型へ。

次に書くなら、

「MCPで作ったAIサーバーを、なぜCLI常駐型へ作り直したのか」

です。

この4本は、そこで捨てる古い記事ではありません。

むしろ、なぜ次の構成が必要になったのかを説明するための、第1世代Personal AI Platformの記録として残します。

「MCPでつくる自作AIサーバー」シリーズ

シリーズ一覧を見る

コメント

タイトルとURLをコピーしました