MCP（Model Context Protocol）を調べると「AIと外部ツールをつなぐ規格」という説明が多く出ます。WordPressでは、MCP AdapterがAbilities APIとMCPクライアントの橋渡しをします。つまり、MCP Adapter単体が投稿機能を無制限に作るのではなく、WordPress側で登録されたAbilityをAI側から発見・実行できる形へ変換します。
この違いを理解すると、REST APIとMCPのどちらを選ぶかも整理できます。固定されたワークフローから投稿を更新するだけならREST APIで十分なことがあります。AIエージェントが「利用可能な機能を発見し、必要なものを選んで呼ぶ」場面ではMCPの価値が出ます。
WordPress×MCPは5段階で考えると分かりやすい
| 段階 | 役割 |
|---|---|
| 1. WordPress機能 | 投稿・サイト情報・独自プラグイン処理など |
| 2. Ability | 機能名、説明、input/output schema、権限を標準化 |
| 3. MCP Adapter | 公開対象AbilityをMCP tool/resource/promptへ橋渡し |
| 4. MCP client / AI agent | 使えるtoolを発見し、必要な操作を要求 |
| 5. WordPress permission | 最終的に実行してよいユーザー/権限か判定 |
WordPress公式MCP Adapterには、デフォルトサーバーとAbilityを発見・詳細取得・実行するためのmeta-toolsが用意されています。AI側から見ると「何ができるか」を段階的に確認できるため、すべての内部実装をプロンプトへ書き込む必要がありません。
REST APIとMCPは「どちらが新しいか」ではなく役割が違う
| 比較 | REST API | MCP Adapter |
|---|---|---|
| 主な呼び出し側 | スクリプト、アプリ、ワークフロー | MCP対応AIクライアント/エージェント |
| 機能の選び方 | endpointを開発側が指定 | クライアントがtool情報を発見できる |
| WordPress側の抽象化 | 投稿等のresource中心 | Abilityという機能単位 |
| 向く処理 | 定型処理、バッチ、CRUD | 対話的なtool選択、Agent連携 |
| 安全性 | 認証・権限・実装次第 | 露出設定＋permission＋transport認証が必要 |
MCPだからRESTより安全、RESTだから単純で危険、という関係ではありません。MCP Adapter自体もWordPress側のAbilityと権限設計に依存します。定型ジョブはREST、AIへ複数ツールを選ばせたい部分はMCPというように、同じシステム内で使い分けることもできます。
2026年のMCP AdapterではAbilityは勝手に外部公開されない
WordPress 7.1ではAbilitiesに高水準のpublic metadataが導入され、外部クライアントへ公開する意図を表現しやすくなりました。WordPress MCP Adapter側でも公開対象を明示する設計が採られています。Abilityを登録しただけで、すべてがMCPクライアントへ自動公開されるわけではありません。
さらに「公開されている」と「誰でも実行できる」は別です。publicやMCP固有の公開設定は発見可能性を決めるもので、実行権限はAbilityのpermission callback等で判定します。外部へ見せる設定をセキュリティ境界そのものとして扱わないことが重要です。
MCPで公開するtoolの設計
tool・resource・promptは用途を分ける
MCPでは何でも「実行tool」にする必要はありません。WordPress MCP Adapterの設計では、Abilityをtoolだけでなくresourceやpromptとして扱う構成も可能です。サイト情報や静的な設定を背景情報として渡すだけならresourceの方が自然な場合があります。
| 種類 | 向く内容 | WordPress例 |
|---|---|---|
| Tool | 明示的な処理を実行 | 記事一覧取得、指定postの要約、承認済み更新 |
| Resource | 背景として参照する情報 | サイト設定、ガイドライン、read-only情報 |
| Prompt | 定型の指示テンプレート | 編集ルール、分析フォーマット |
実務では、変更を伴わない情報をtoolにしても問題はありませんが、「実行」と「参照」を分けるとAI側にも意図が伝わりやすくなります。破壊的操作にはdestructive、読み取りにはreadonlyといった注釈を正しく付けることも、Agentが扱う手掛かりになります。
最初に公開するならread-only Abilityから
最初のMCP連携で候補にしやすいのは、公開記事一覧、指定記事の更新日、サイト基本情報、環境情報などのread-only操作です。AIへ情報を渡す価値はありつつ、誤って呼ばれても記事を壊しません。
次の段階で、更新候補の生成やdraft作成のような「戻せるwrite」を承認付きで追加します。公開・削除・ユーザー変更・プラグイン操作のように影響範囲が広いものは、便利さだけを理由に同じMCPサーバーへ並べない方が安全です。
AIへ渡すtoolは「できること」より「できないこと」を明示する
Agentにtool名だけ渡しても、安全境界は伝わりません。Abilityのdescription、input schema、permission、annotationを使い、対象ID必須、draftのみ、最大件数、許可されたフィールドなどを実装側で制約します。「プロンプトに書いたから守るはず」ではなく、WordPress側で拒否できる条件にします。
特に外部コンテンツを読んだAgentは、ページ内の命令文を誤って優先するprompt injectionの影響を受ける可能性があります。外部ページを読んだ結果だけでpublish/deleteへ進めない、tool引数をサーバー側で再検証する、という設計が重要です。
STDIOとHTTPは接続経路が違う
WordPress MCP AdapterはCLI/STDIOやHTTP経路でクライアント接続を構成できます。ローカルの開発支援と、クラウド上のAgentから本番WordPressへ接続する場合では、認証・ネットワーク露出・ログの考え方が変わります。
本番でHTTP経由にするなら、MCP endpointをインターネットへ置いた事実だけで安全とは言えません。transport側の認証、WordPress側の認証、Abilityごとのpermissionを重ね、どの層で拒否されたかログで追えるようにします。
MCPが向くケース・向かないケース
| 状況 | 判断 |
|---|---|
| Agentに複数のWordPress機能を発見・選択させたい | MCP/Abilitiesを検討する価値が高い |
| 決まった記事を毎晩取得するだけ | REST APIやWP-CLIの方が単純 |
| 公開・削除を完全自律化したい | 先に承認・rollback・permission設計が必要 |
| まだWordPress側の機能境界が曖昧 | MCPより先にAbility/RESTの責務を整理 |
| 検証目的 | read-only＋テストサイトから開始 |
discoveryとexecutionを分けて監査する
Agentから見たMCPでは、toolを一覧で発見できることと、実際に引数付きで実行できることは別です。ログでも「発見」「実行要求」「permission拒否」「成功」を分けて残すと、どこで止まったかを追いやすくなります。公開toolが増えた場合は、使われていないtoolや拒否が多いtoolを定期的に棚卸しし、外部公開範囲を縮める判断材料にします。
特にwrite系toolは、発見可能でも通常状態では実行不可にし、承認後だけ短時間のpermissionを与える設計も考えられます。MCPを「AIに管理者権限を渡す仕組み」と捉えず、WordPress側で定義した狭いtoolを必要な範囲だけ見せる接続層として扱う方が安全です。
2026年9月時点でもWordPressのAI/MCP周辺は更新が速く、7.2ロードマップではMCP Adapterの更新や配布方法も検討されています。実装記事を古いコードのコピペだけで運用せず、AdapterのreleaseとWordPress本体バージョンを一緒に確認してください。
公式情報・参考資料
仕様確認日：2026年9月30日。実装時はリンク先の最新版も確認してください。
- https://developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter/
- https://github.com/WordPress/mcp-adapter
- https://make.wordpress.org/core/2026/08/04/a-unified-public-exposure-flag-for-abilities-in-wordpress-7-1/
コメント