MCPをWordPressの中で動かさない構成にした理由

AIからWordPressを操作できる仕組みを作ると聞くと、WordPressの中へAI機能を組み込む姿を想像しやすい。管理画面に機能を足し、同じサーバー上で全部を動かせば、ひとつにまとまって分かりやすそうに見える。

KagoHubのMCPは、その構成を選ばなかった。WordPressサーバー内では動かさず、CursorやCodexなどのMCPクライアントを使う手元のマシンで起動する。WordPress側とはHTTPSのREST APIで接続し、データベースへ直接つながない。

この分離は、単に置き場所を変えただけではない。WordPressが持つ責任、AIとの会話を受け取るMCPの責任、人間が最後に判断する責任を混ぜないための境界になる。この記事では、非エンジニアの立場から、この構成が何を分かりやすくしたのかを整理する。

WordPressプラグインとMCPは別の仕事をする

KagoHub CoreはWordPressプラグインとして動く。公式・準公式の情報をRSSから収集し、MySQLの独自テーブルへ保存し、受信箱、既読、記事候補、取得ログ、WordPress下書きなどを扱う。日々の情報管理を支える中核はWordPress側にある。

一方、MCPサーバーは、CursorやCodexのようなAIクライアントからKagoHubの機能を呼び出すための入口だ。AIから届いた要求を、許可されたREST APIの操作へ対応づける。KagoHubのデータを自分で所有するのではなく、WordPress側にある正規の入口を使う。

二つを分けると、役割を短く説明できる。

• WordPressプラグインは、データと業務ルールを持つ
• REST APIは、外部から使える操作の契約を持つ
• MCPは、AIクライアントとREST APIをつなぐ
• 人間は、下書きの確認と公開判断を持つ

MCPをWordPressの中へ入れないことで、AI向けの入口がKagoHub Coreそのものにならない。AIとの接続方式が変わっても、情報の保存場所や公開の基本ルールを同時に変える必要がない構成になる。

接続の流れを一本にすると、確認場所が分かる

KagoHub MCPの通信経路は、手元のAIクライアントからローカルstdioのMCPサーバーを通り、HTTPSのKagoHub REST APIへ進む。そこからWordPressプラグインが、権限や入力内容を確認して処理する。

Cursor / Codex
  → ローカル stdio MCP
  → HTTPS REST（kagohub/v1）
  → KagoHub Core
  → WordPress / MySQL

この順番が決まっていると、問題が起きたときの確認場所を分けられる。AIクライアントがMCPを起動できないのか。MCPからREST APIへ届かないのか。WordPress側の権限で拒否されたのか。入力が契約に合っていないのか。一つの巨大な処理として見るより、境界ごとに切り分けやすい。

非エンジニアにとって、エラーの詳しいコードが読めることより、「どこまで届いたか」を説明できることが重要だ。接続経路が一本で、各区間の役割が文書化されていれば、AIへ調査を頼むときも対象を狭められる。

データベースへ直接つながない

MCPからWordPressのMySQLへ直接接続すれば、できることは増えるかもしれない。テーブルを読んだり、値を書き換えたりする処理を自由に作れる。しかし、自由さはWordPress側のルールを通らずに変更できる危険とも隣り合わせだ。

KagoHub MCPは、データベースへ直接接続しない。書き込みは、すでにKagoHub REST側へ用意された監査、レート制限、冪等性、ロックなどの経路を通す方針になっている。MCPだけの特別な裏口を作らず、WordPress側が管理する同じ契約を利用する。

これはREST APIなら自動的に安全になる、という意味ではない。APIの権限確認や入力検証が正しく実装されていることが前提になる。ただ、操作の入口を一つへ寄せると、「どのルールを通る変更なのか」を確認しやすくなる。

DB直結の場合、MCP側にもテーブル構造や更新規則の知識が必要になる。WordPress側の仕様変更が、そのままMCPの修正へ波及しやすい。REST契約を間に置けば、MCPは許可された操作と応答の形に集中できる。保存の細部はKagoHub Coreの責任として残せる。

AIが使える機能を、最初から全部にはしなかった

KagoHub MCP v1.4.0には10個のツールがある。内訳は、状態や情報源、受信箱を確認する読取5個、既読・記事候補・アーカイブを変更する状態更新3個、WordPress下書き作成と一括取得の2個である。

一方で、公開、削除、自動公開、プラグイン更新のツールは用意していない。下書き作成もWordPressのdraftに限定している。AIと接続できるようにすることと、AIへすべての操作を渡すことを同じにしなかった。

ここが、MCPを外へ分ける構成の重要な点だ。MCPは便利な遠隔操作装置ではなく、「AIへ何を見せ、何を実行させるか」を定義する境界になる。提供しない操作を明記し、ツール一覧に存在しないことまで契約テストで確認する。

機能を止める判断を、AIへのお願いだけにしない。「公開しないで」と毎回プロンプトへ書くのではなく、公開ツール自体を持たせない。人間の注意力だけに頼らず、できる操作の種類を構造で制限する。

秘密情報は設定に必要でも、会話やログには残さない

MCPからWordPress REST APIへ接続するには、RESTのベースURL、WordPressユーザー名、Application Passwordの三つが必要になる。だからといって、これらをリポジトリやIssue、チャットへ貼り付けてよいわけではない。

KagoHub MCPの文書では、資格情報をGit、ログ、チャット、配布用のsidecarへ入れないことを明記している。設定例にも環境変数の名前だけを置き、秘密値は環境やOSの秘密ストアから注入する方針だ。認証情報はメモリ内で組み立て、Authorizationや資格情報をログへ出さない。

ローカルで動かせば、それだけで秘密が安全になるわけではない。端末の設定やログの扱いが悪ければ漏れる可能性はある。重要なのは、どこで秘密値を渡し、どこへ残してはいけないかを構成と手順の両方で決めることだ。

stdioの標準出力をMCPのJSON-RPC専用にし、通常ログを混ぜないという決まりもある。これは通信を壊さないための技術的な理由に加えて、出力の役割を混ぜない設計でもある。何がプロトコルで、何が診断情報かを分けることで、確認対象を明確にできる。

WordPress ZIPだけではMCPを導入できない

KagoHubでは、WordPressプラグインとMCPサーバーを別の配布物として扱う。WordPressプラグインのZIPだけを入れてもMCPは導入されない。MCPは別パッケージを、AIクライアントを使うマシンへ導入して起動する。

最初は手順が一つ増えたように見える。しかし、別物であることが導入時にも明らかになる。WordPressへ入れるものと、手元のAI環境へ入れるものを取り違えにくい。MCPを使わない運用では、WordPress側だけを維持することもできる。

配布物が分かれていると、更新の判断も分けられる。WordPressプラグインの変更と、AIクライアント側の接続変更を同時に行う必要があるかを確認できる。実際、v1.4のリリース方針では、MCP対応に必要な変更がない限りWordPressプラグインの版を維持し、DBスキーマ版も維持する範囲が定められていた。

分離したあとに必要な確認

構成を分けただけで運用が完成するわけではない。KagoHubでは、MCPの配線、ツール契約、安全性、実際のWordPress通信をまとめて試験している。公開・削除ツールが存在しないこと、下書きがdraftだけであること、資格情報が出力へ残らないことも確認対象に含めた。

分離には、境界が増えるという弱点もある。接続先URL、認証、Node.js環境、WordPressプラグインの状態など、確認項目は増える。だから、構成図だけで終わらせず、正常時と失敗時の両方を試す必要がある。

KagoHubのIssueでは、正常応答だけでなく、認証・権限・未検出・競合・入力不備・レート制限・タイムアウト・不正JSONなども確認対象にしている。本番書き込みは、明示フラグ、接続先、対象IDがそろうまで実行しない。分離によって生まれた境界を、テストで一つずつ確かめる考え方だ。

非エンジニアが持ち帰れること

• AI接続をCMSの中へ全部入れず、AI側の入口を別プロセスにできる
• MCPからDBへ直結せず、既存のREST契約を通すと責任を分けやすい
• 「公開しない」という注意書きより、公開ツールを提供しない構造のほうが確認しやすい
• 秘密値は必要な場所だけへ渡し、Git、Issue、チャット、ログへ残さない
• WordPressプラグインとMCPを別配布にすると、導入先と更新判断を分けられる
• 分離して増えた境界は、実通信と失敗系のテストで確認する必要がある

KagoHubがMCPをWordPressサーバー内で動かさない構成にしたことで、WordPressはデータと業務ルール、MCPはAIとの接続、人間は公開判断という役割が見えやすくなった。

AIとつながることをゴールにすると、できる操作を増やす方向へ進みやすい。しかし、長く使うためには「どこで動くか」「何を通るか」「何をできなくするか」を先に決める必要がある。接続の便利さだけでなく、境界を説明できることが、非エンジニアにとって運用可能なAI連携を作る。

この記事は、2026年9月8日に確認したKagoHubの README.md、mcp-server/README.md、docs/architecture.md、docs/CURRENT_STATUS.md、GitHub Issue #53・#54・#58・#59の記録をもとに構成した。ローカル実行だけで安全が保証される、REST APIなら無条件に安全になる、といった主張はしていない。