WordPress MCP対Headless CMS MCP：エージェント対応スタック

WordPress MCPは公式なルートを手に入れました。WordPress 6.9で登場したAbilities APIと、それをエージェントが呼び出せるツールに変えるMCP Adapterです。良い動きです。Headless CMSは独自のファーストパーティサーバーでより早くその段階に到達し、gitベースサイトはすべてのエージェント編集をプルリクエスト経由で本番に到達させることを強制することで、同じ厄介事の多くを回避しています。これらのスタックはどれもデフォルトでは安全ではありません。本当の違いは安全性がどこにあるかです。ボックスの中か、その周りで行う仕事の中か。このポストではプラグイン対プラグインではなくスタック対スタックで比較し、スコアカードと2027年までにエージェント実行サイトがどこに存在するかについての慎重な見方を提供します。

MCPが変えること：サイトが書き込めるエージェントを手に入れる

読み取り専用MCPはより礼儀正しい検索ボックスです。エージェントは投稿を取得し、要約し、ギャップを見つけます。仕事がうまくいかなくても、サイトは傷つきません。何も壊れません。

書き込みアクセスは別です。サーバーが作成、更新、公開、削除ツールを公開すると、エージェントはサイトの実際のユーザーになり、トークンが持つすべての権限を持ちます。午前3時に価格ページを書き直すことができます。誰も承認していない下書きを公開することもできます。また、途中で読むテキストによってどちらかの間違いに押し付けられる可能性があります。詳しくはすぐ後で。

したがってCMS選択は主にエディターとテンプレートに関することをやめます。権限の問題になり、4つのサブ質問がほとんどの難しい仕事をします。

エージェントが何をできるかをどの程度細かく設定できますか？
下書きのままでいられるのか、それとも書き込みは毎回公開されますか？
監査証跡がありますか？そしてロールバックできますか？
人間は公開前に結果を見ることができますか？

これはもはやニッチな懸念ではありません。英国AISIは公開されたMCPツールが1年間で約5,000から177,000に増え、ダウンロードは80,000から1,400万に増えたと数えました。信頼するか信頼しないか、多くのサーバーがあります。その判断を行うための手順が欲しい場合は、Claude Codeスキル、プラグイン、MCPサーバーを検証することで書きました。本番環境でMCPを実行する大局的な図はMCPサーバー本番スタックポストにあります。

WordPress、公式ルート：Abilities APIとMCP Adapter

Abilities APIはWordPress 6.9に搭載されました。コア、テーマ、プラグインに、入力スキーマと権限コールバックが付属した何ができるかを宣言する標準的な方法を提供します。MCP Adapterはそのレイヤーの上に位置します。WordPressの公式MCPインテグレーションパッケージとして説明され、WordPress GitHubオーガナイゼーションの下に置かれ、WordPress向けAIビルディングブロックスイニシアチブに属しています。その仕事は狭いですが重要です。AbilitiesをMCPツール、リソース、プロンプトとして公開することです。

READMEが記録すること：

HTTPとSTDIOトランスポート、カスタムプロトコル用のMcpTransportInterface。クライアントはWP-CLI経由でSTDIOを通じて接続するか、HTTPクライアントを/wp-json/mcp/mcp-adapter-default-serverに向けます。
granular permissionsと呼ぶ機能：サーバーごとのトランスポート認証とAbility ごとの権限チェック。
能力はデフォルトではプライベートです。meta.public（または meta.mcp.public）を true に設定することで、1 つの能力が公開されます。
デフォルトサーバーは 3 つのメタツールを提供します：mcp-adapter/discover-abilities、mcp-adapter/get-ability-info、mcp-adapter/execute-ability。
McpErrorHandlerInterface および McpObservabilityHandlerInterface を通じたプラグイン可能なエラーハンドリングと可観測性。

デフォルトでプライベートであることは正しい本能です。エージェントが公開とマークされていない能力に到達することはできません。プロンプトがどんなに巧妙であっても同じです。そのリストに何が無いかを見てください：ドラフト専用のエージェントロールもなければ、組み込みの承認ステップもなく、監査ログもありません。可観測性フックは、これらを構築する場所です。完成した監査証跡ではありません。

ドラフト制御は能力の内部にあります。誰かがそれらを書かなければなりません。MS WordPress Abilities というサードパーティプラグインが、その仕事の形をよく示しています。29 の能力を登録し（26 のカスタムプラス 3 つのコア能力が MCP 可視性にオプトイン）、preview-post-update に続く apply-post-update という 2 段階のステージ更新を提供する一方、patch-post-content はステージングを必要としません。合理的な設計です。それでも WordPress ではなく、その著者の選択です。同じ README によると、コアと公式 AI プラグインは、そのままで数個の能力のみをリリースしています。

それはまた落ち着いている途中です。2026 年 3 月 18 日に開かれたイシューは、アダプター README がコアにマージされた後も Abilities API の必要性について述べていたことを指摘しました（イシュー 150）。2026 年 6 月 24 日、コントリビューターはそこでコメントし、新しいコアおよびサイト能力はアダプターではなく AI プラグインと Abilities API に属すること、および多くのアダプタードキュメントが任意の能力を登録して mcp.public を設定する古いモデルを教え続けていることを述べました。その後、2026 年 2 月 5 日、WordPress AI メンテナーは Abilities API または MCP サポートを実装しているプラグインのディレクトリを知らないと述べました（ディスカッション 204）。配管は公式です。安全で有用な能力のカタログは依然として薄いままです。

WordPress、プラグインルート：選択肢は豊富、セキュリティ記録は薄い

もう一つの WordPress ルートは、独自の MCP サーバーを備えたプラグインです。ベンダー比較ページに表示される名前には、Easy MCP AI、WPVibe、Novamira、Royal MCP、miniOrange Secure MCP Server、AI Engine が含まれます。ここではそれらをカテゴリとして扱っています。ランキングはありません。彼らの機能主張を事実として繰り返すこともありません。1 つの注意が重要です。一般的な比較ページはプラグインベンダーによって実行され、彼ら自身がリストされているため、それらをテーブル付きのマーケティングとして読んでください。

このカテゴリが提供するのはスピードです。プラグインをインストールし、トークンを AI クライアントに貼り付けると、投稿、メディア、そしてしばしばユーザーと設定のツールが得られます。その代償はトラストです。サードパーティの著者に WordPress ユーザーとして機能できるエンドポイントを渡しており、その背後には完全な管理エリアを持つ PHP サイトがあります。

ここで引用している唯一の公開セキュリティ記録は、1 つのプラグイン AI Engine に属しています：

CVE-2025-11749。バージョン 3.1.3 まで、No-Auth URL オプションが有効になっていると、MCP ベアラートークンがサイトの公開 REST ルートを通じてリークしました。認証されていない攻撃者は MCP エンドポイントに認証でき、管理者アカウントを作成することができました。3.1.4 で修正され、2025 年 11 月 5 日に NVD に公開されました（SentinelOne の記述では、リークを /mcp/v1/ エンドポイントに配置し、確認された公開エクスプロイトコードはないと述べています）。
CVE-2026-8719。2026 年 5 月 17 日に公開、高（CVSS 8.8）として評価。バージョン 3.4.9 では MCP OAuth ベアラートークンパスが管理者能力をチェックしなかったため、有効なトークンを持つサブスクライバーレベルのユーザーは管理者レベルの MCP ツールに到達し、管理者になることができました（GitHub アドバイザリ）。
より長いリスト。WPScan はマルチサイトの MCP ユーザーツールアカウント乗っ取り（3.6.1 で修正）や CSRF を通じた管理者アカウント作成（3.6.6 で修正）を含む、多くのリストを列挙しています。

これが何を証明するかについて公平でありなさい。それは 1 つのプラグインです。人気のあるプラグインは精査を引き寄せます。これが部分的にこれが記録を持っている理由であり、他の場所に空のレコードがあることは安全性の証拠ではありません。それでも、パターンは重要です。両方のヘッドラインバグは MCP ドアでの認可失敗です。エージェントが力を受け取る正確な場所です。その部分を覚えてください。

Headless CMS MCP サーバー：Sanity、Strapi、Contentful、Payload

Headless プラットフォームは、PHP 管理ではなく、データモデルを中心に MCP サーバーを構築しました。その違いはドキュメントに表れています。

Sanity

Sanity は https://mcp.sanity.io で Streamable HTTP でホストされたサーバーを実行し、デフォルトで OAuth、オプションとしてトークン認証を備えています。エージェントは GROQ クエリを実行し、リリースを管理し、スキーマ認識を持つドキュメントにパッチを適用できます。セットアップは npx sanity@latest mcp configure です。古いローカル @sanity/mcp-server パッケージは廃止されました。これが現在のルートです。

ドキュメントではドラフトファーストライティングについて説明します：create_documents は releaseId を渡さない限りドラフトを作成し、patch_documents はドラフトまたはリリースバージョンに保存され、公開されたコンテンツは直接変更されません。公開は別のツールです。各ドキュメントへのパッチは単一のトランザクションとして適用されます。個人トークンはあなたのロールを共有し、リビジョン履歴の変更にあなたを関連付けます。一方、Authorization ヘッダーに設定されたトークンは独自のロールとスコープ内で機能します。2 つの落とし穴があります。サーバーは開発およびプロジェクト管理（スキーマデプロイ、データセット、CORS オリジン）も公開しているため、トークンのスコープを慎重に設定してください。また、create_release は何もスケジュールしません。これは Studio または HTTP Actions API で発生する必要があります。

Strapi

StrapiのМCPサーバーは組み込まれており、あなた自身のインスタンス内で動作します。初登場はv5.47.0で、v5.49.0で一般提供となりました(Strapiブログ、2026年9月3日)。デフォルトではオフです。server.mcp.enabledはfalseです。管理APIトークンで認証され、コンテンツタイプごとにfind、create、update、publish、unpublishツールを公開します。トークンはそのオーナーの権限を決して超えることはなく、オーナーを無効化すればトークンは失効します。コンテンツタイプの作成やメディアのアップロードは行いません。これらはREST APIを通じて行われます(Strapi)。

ContentfulおよびPayload

Contentfulは公式のオープンソースМCPサーバー(МITライセンス、npmパッケージ@contentful/mcp-server)を公開しており、エージェントがエントリーとアセットを管理し、コンテンツタイプを更新し、タグ付けやマイグレーションなどのジョブを自動化できます。管理アクセストークンとスペースIDが必要です(Contentful)。コミュニティサーバーも存在し、公式サーバーをポイントしています。Payloadは公式プラグインを通じてМCPを追加します。スタンドアロンサーバーではありません。Payloadについてはここまでとします。

SanityとWordPressをより広く比較検討している場合は、「Sanity vs WordPress for enterprise」で非МCP側をカバーしています。決定のその部分についてはそこから始めてください。

Git ベースJamstack: プルリクエストはセーフティネット

3番目のパターンにはМCPサーバーがまったくありません。コンテンツはリポジトリ内にMarkdown、MDX、または型付きJSONとして存在し、サイトはAstroまたはNext.jsです。コーディングエージェントはファイルを編集します。プルリクエストを開き、ホストがプレビューデプロイをビルドし、人間がマージ前にdiffを読みます。VercelとNetlifyはいずれもGitベースのデプロイとプレビューデプロイをサポートしており、このパターンはホストからこれだけが必要です。

メインラインから分岐する直線的なブランチの図。ページカード、虫眼鏡、マージポイントにロックマーク付き

そのプルリクエストループは奇抜なものではありません。Next.jsはАIコーディングエージェントをサポートする方法を文書化しており、МicrosoftのAzure Static Web Appsチュートリアルは標準的な配線を示しています。プルリクエストのopened、synchronize、reopened、closedで起動するGitHub Actionsワークフロー、および preview を削除するための別のジョブです。通常のデリバリー機構です。これが魅力の一部です。

エージェントに適している理由は単純です。すべての変更は確認可能なdiffです。マージするまで本番環境に到達するものは何もありません。ロールバックはgit revertです。公開サイトは静的出力なので、盗まれたエージェントトークンが到達する管理ログインはありません。

ただし、コストは現実的です。非技術系のエディターは摩擦を受けます。gitはそのツールではないためです。ここには文書化されたМCPサーバーとセキュリティ記録がありません。エージェントはリポジトリアクセスを備えたコーディングエージェントなので、露出はそのgitトークンのスコープとそのシェルが触れられるものです。サプライチェーンの衛生が依然として適用されます。これについては「2026年のNext.js、Astro、Nuxtセキュリティ」で説明しました。

あらゆるスタック上のМCPリスク、およびそれらを含むコントロール

NSAは2026年6月にМCPセキュリティに関するサイバーセキュリティ情報シートを公開し、МicrosoftはМCPセキュリティの状態を2026年に記述しました。語彙を取り除くと、4つのリスクが繰り返し現れます。

継承された権限。エージェントはそのМCPサーバーの認証情報が何でもできることが何です。管理トークンは管理エージェントを意味します。
ツール中毒。ツールの説明はモデルによって読まれるため、悪意のあるまたは侵害されたサーバーは説明に指示を隠すことができます。これが第三者サーバーがインストール前にレビューに値する理由です。
プロンプトインジェクション。エージェントが読むコンテンツ(コメント、スクレイプされたページ、ドラフトに貼り付けられたサポートチケット)は指示を実行できます。エージェントはそれ自身の書き込みアクセスで従う可能性があります。
過度に特権のあるトークン。利便性により、人々は1つの広いトークンを渡すよう推進されます。そうしないでください。

コントロールは退屈です。彼らは機能します。エージェントに最小権限トークンを与え、読み取り専用またはドラフトのみのスコープを優先し、公開と削除の前に人間による承認を置きます。実際に読む監査ログを保持します。誰かが去ったときはトークンをローテーションします。これはいずれもスタック固有ではなく、それがポイントです。スタックはすべてのワークがすでにあなたのために行われているか、どのように多くのことを決定します。

エージェント準備度スコアカード

ここに比較をまとめました。評価は文書化された機能と公開記録に基づいており、上記でソースを示しています。このテーブル用にこれらのスタックをテストスイートで実行した人はいません。ラボ結果ではなく、文書化された比較として扱ってください。

Strongは、デフォルトでドキュメンテーションがカバーしていることを意味します。Partialは文書化されているが不完全、または短い記録にしか支えられていません。Depends on setupはスタックが決定しないことを意味します。あなたの設定が決定します。Weakは文書化された問題を意味します。

スタック	権限の粒度	ドラフト対公開コントロール	監査証跡とロールバック	ライブ前のプレビュー	認証モデル	公開セキュリティ記録
WordPress + 公式MCP Adapter	Strong	Depends on setup	Partial	Depends on setup	Partial	Partial
WordPress MCPプラグイン（グループとして）	Depends on setup	Depends on setup	Depends on setup	Depends on setup	Depends on setup	Weak（ドキュメント化されたプラグインは1つ）
Sanity	Strong	Strong	Strong	Partial	Strong	Partial
Strapi	Strong	Strong	Depends on setup	Depends on setup	Strong	Partial
Contentful	Partial	Depends on setup	Depends on setup	Depends on setup	Partial	Partial
Payload	Depends on setup	Depends on setup	Depends on setup	Depends on setup	Depends on setup	Partial
Git ベース Jamstack	Strong	Strong	Strong	Strong	Depends on setup	Partial

各評価の理由を簡潔に。

WordPress + Adapter。権限はstrong です。すべての機能が独自のチェックを持ち、機能は公開済みとしてマークされるまでプライベートだからです。ドラフト制御は、インストールする機能に依存します。ステージング更新の例で示したように。監査はpartialです。監視インターフェースは存在しますが、ネイティブな監査ログはありません。認証はpartialで、サーバーごとのトランスポート認証は高レベルで文書化されています。記録はpartialです。パッケージが新しく、ドキュメンテーションが目に見えて移行中だからです。

WordPress プラグイン。カテゴリ全体で統一されたものはないため、ほとんどのセルはプラグインに依存します。記録はweakです。文書化された箇所において。上記のAI Engineエントリーのみです。その区別は重要です。

Sanity。ロールスコープのトークン、デフォルトでドラフト書き込み、リリースおよび改定履歴がstrongな評価を獲得しています。プレビューはpartialです。リリースはステージング概念ですが、MCPサーバーはリリースをスケジュール、公開できないからです。記録はpartialです。短いという意味で。悪くはありません。

Strapi。コンテンツタイプごとのツールとオーナーバウンドトークンは権限と認証でstrongです。公開と非公開は別のツールで、サーバーは切り替えるまでオフです。監査とプレビューはインスタンスの実行方法に依存します。自己ホスティングは、パッチはあなたのものであることも意味します。

Contentful。公式サーバーは管理トークンとスペースIDが必要です。これは広いアクセスとして読めるため、権限と認証はpartialと評価します。ドラフト処理、監査およびプレビューは、スペースとロールをどのように設定するかに依存します。重要な仕事はその設定の中にあります。

Payload。公式プラグインが存在します。それ以上に、評価すべき一次ドキュメンテーションはないため、すべてのセルは「depends on setup」と読まれます。これは検証可能なものにおけるギャップです。判定ではありません。

Git ベース Jamstack。4つのカラムでstrongです。パターン自体が提供するため。ブランチレベルのレポ権限、公開ゲートとしてのプルリクエスト、git履歴と復帰、プレビューデプロイ。認証はコーディングエージェントとそのgitトークンに依存します。記録はpartialです。攻撃対象となるCMS管理サーフェスがないため。エージェントツーリングは依然として、他のすべてのものと同じMCPリスクを伴っています。

今日の選択肢を、状況別に検討する

既存のWordPress環境がある

そのまま使い続け、厳格に管理する。公式アダプターを使い、必要な機能だけをパブリックにマークし、変更をステージングしてから適用する機能を書くか選ぶ。管理者権限を持つトークンを備えた広範な第三者プラグインは、この全体の比較の中で最もリスクが高いセットアップだ。フロントエンド側からWordPressを解放したいなら、ヘッドレスWordPress開発が中間的な道だ。

新しく構築を始める

エージェントが運用を助けるなら、ヘッドレスまたはgitベースで始めよう。SanityやStrapiはドラフトとスコープ付きトークンを最初から提供する。AstroやNext.jsをリポジトリで使えば、差分とプレビューが得られる。新規プロジェクトにとって強力なデフォルトだ。

コンテンツチームが大規模か非技術者である

ビジュアルインターフェースで生活するエディターのチームは、プルリクエストを好まない。ヘッドレスに適切な編集スタジオがあれば、彼らに向いている。ただしエージェントはドラフトに限定される前提だ。WordPressのエディターはここで本当に優れている。これはWordPressの点数になる。

コンプライアンス要件がある

監査ログがどこにあり、誰が所有しているかを確認する。Git履歴は強力な答えだ。Sanityのリビジョン履歴も別の選択肢だ。WordPressの場合は、ロギングを自分で構築する必要がある。セルフホスト型オプション(StrrapiやWordPress)はデータをあなたのインフラストラクチャーに保つが、パッチは自分で対応し、ホストされたサーバーはその負担をベンダーにシフトする。

2027年に向けて: AIが実行するサイトに対してJamstackがより良い選択肢となる理由

このセクションは見解であり、調査結果ではなく、軽く考えている。

Jamstackが先行する理由。コンテンツは構造化され、型がついている。エージェントの変更はすべて人間が確認するdiffになる。プレビューデプロイはライブ化の前に結果を表示する。ロールバックはgit revertだ。公開サイトに盗まれたエージェントトークンが到達するための管理画面がない。エージェントはファイル編集に優れ、信頼されることには向いていない。このセットアップはまさにその組み合わせ向けに構築されている。

WordPressが失わないかもしれない理由。最大のインストールベースと才能プールを持つ。Abilities APIは既にコアにあり、公式アダプターがそばにいる。プラグインベンダーは迅速に反復する。高速な反復は多くを修正する。上記のCVEを作ったとしてもだ。

WordPressに必要なもの。コアにMCP、デフォルトで機能にマップされた能力。ドラフトのみのエージェントロール。ネイティブな監査ログ。MCPプラグインのより良いセキュリティ記録。それは短いリストで、何も不可能ではない。

この見方があなたに移行の判断を持たせるなら、WordPressを去るガイドが出発点だ。

実用的な指針: エージェントが運用を助ける新しいサイトなら、Jamstackまたはヘッドレスで始める。既存のWordPress環境なら、広い第三者プラグインではなく、最小権限の機能を備えた公式アダプターを使う。ここでは地味でいい。

WordPress MCP対Headless CMS MCP：AIエージェントに合うのはどちら？