複数のWordPressサイトをClaude Code / CursorのMCPサーバーとして繋ぐ - ハマった沼と正解ルート

この記事で分かること

• WordPressサイトをAIコーディングエージェント(Claude Code、Cursor等)のMCPサーバーとして繋ぐ2つの方式
• 公式「WordPress MCP」プラグイン導入時にほぼ確実にハマるエンドポイントの罠
• claude mcp addでの実際の登録コマンド
• おまけ: WP-CLIでオプションを直接書き換えても意図した動作(cron登録)にならないケース

自分の運営する複数のWordPressサイトを、Claude Code から横断的に触れるようにした時の記録です。半日ほど原因不明の404に悩まされたので、同じ沼にハマる人向けに正解ルートを共有します。

前提: 2つの接続方式

WordPressサイトをAIエージェントに繋ぐ方法は大きく2系統あります。

方式	特徴
SaaS型MCPブリッジ(WPVibe等)	1アカウントで複数サイトをまとめて接続。ワンクリック認証。WP-CLIエミュレーション・ファイル読み取り等、汎用的な操作が可能。無料枠あり
公式WordPress MCP(Automattic製、wordpress-mcp + mcp-adapter)	サイトごとに個別導入するセルフホスト型。プラグインが公開しているAbilities(機能)だけを、絞り込まれた形で安全に叩ける

両方を併用し、「公式MCPで足りる操作は公式MCPを優先、無いものだけSaaS型に回す」という運用にしました。理由は、公式MCP側は各プラグイン(SEO系、キャッシュ系等)が明示的に公開しているAbilitiesしか触れないため、AIが暴走して余計な操作をするリスクが低いからです。

公式WordPress MCPの導入

wordpress-mcpとmcp-adapterは、記事執筆時点ではWordPress.org公式ディレクトリには未公開で、GitHubのリリースページからzipを直接ダウンロードしてアップロードする必要があります。

# 最新版のダウンロードURLを取得
gh api repos/Automattic/wordpress-mcp/releases/latest --jq '.assets[].browser_download_url'
gh api repos/WordPress/mcp-adapter/releases/latest --jq '.assets[].browser_download_url'

取得したzipを、対象サイトのwp-admin「プラグイン→新規追加→プラグインのアップロード」からmcp-adapter→wordpress-mcpの順にインストール・有効化します(依存関係があるため順番に注意)。

有効化すると、Settings > MCPにプラグイン独自の設定画面が現れます。ここに「MCP Client Setup Guide」というドキュメントが用意されており、Claude Codeへの接続コマンド例も載っています。

ハマった罠: エンドポイントが2つある

wordpress-mcpプラグインの公式ドキュメントには、こう書かれています。

claude mcp add --transport http wordpress-mcp \
  https://example.com/wp-json/wp/v2/wpmcp/streamable \
  --header "Authorization: Bearer your-jwt-token-here"

このガイド通りに設定すると、認証には成功するのに、リクエストを送ると必ずrest_no_routeの404が返ってくるという現象に遭遇しました。

{"code":"rest_no_route","message":"URLとリクエストメソッドに一致するルートが見つかりませんでした。","data":{"status":404}}

厄介なのは、認証が失敗している時は正しく401やプラグイン独自のエラーが返ってくる点です。つまり**「認証に成功した瞬間だけ」404になる**という、一見すると原因不明の挙動でした。

半日かけて以下を全部疑いましたが、どれも的外れでした。

• プラグインのバージョン不整合(mcp-adapterの新旧を揃えても再現)
• SaaS型MCPブリッジ(WPVibe)側のセキュリティ機能との干渉(無効化しても再現)
• サーバーのキャッシュ/WAF(パージしても、WAFなしサイトでも再現)
• パーマリンク未設定問題(?rest_route=形式に変えても再現)
• JWTトークンの有効期限切れ(有効期限内でも再現。Application Password/Basic認証に変えても同じ現象)

最終的に、同じ現象が「認証済みの正常なサイト」でも再現することに気づき、方針を転換。プラグイン本体のソースコードを直接読みに行きました。

本当のエンドポイントは別にあった

wordpress-mcpプラグイン自身が実装している/wp/v2/wpmcp/streamableとは別に、依存プラグインのmcp-adapterが独自のデフォルトMCPサーバーを持っていることが分かりました。

// mcp-adapter/includes/Servers/DefaultServerFactory.php
$wordpress_defaults = array(
    'server_id'              => 'mcp-adapter-default-server',
    'server_route_namespace' => 'mcp',
    'server_route'           => 'mcp-adapter-default-server',
    ...
    'tools' => array(
        'mcp-adapter/discover-abilities',
        'mcp-adapter/get-ability-info',
        'mcp-adapter/execute-ability',
    ),
);

つまり正しいエンドポイントはこちらです。

❌ 誤: /wp-json/wp/v2/wpmcp/streamable
✅ 正: /wp-json/mcp/mcp-adapter-default-server

こちらのエンドポイントは権限チェックにcurrent_user_can('read')というシンプルなWordPress標準の仕組みを使っており、JWTでもApplication Password(Basic認証)でも問題なく通ります。

実際の登録コマンド

Application Password(wp-admin「ユーザー→プロフィール」またはREST APIのPOST /wp/v2/users/{id}/application-passwordsで発行)を使う場合。

AUTH=$(echo -n "ユーザー名:xxxx xxxx xxxx xxxx xxxx xxxx" | base64)

claude mcp add --transport http my-wordpress-site \
  https://example.com/wp-json/mcp/mcp-adapter-default-server \
  -H "Authorization: Basic $AUTH" \
  -s user

claude mcp listで✔ Connectedになれば成功です。JSON-RPC 2.0のMCPプロトコルでinitialize→tools/listと叩くと、以下の3ツールが見えます。

• mcp-adapter-discover-abilities: 有効なプラグインが公開している機能一覧を取得
• mcp-adapter-get-ability-info: 特定機能の入出力スキーマを取得
• mcp-adapter-execute-ability: 機能を実行

SEO系プラグインやキャッシュ系プラグインが対応していれば、記事のメタ情報更新やキャッシュクリアといった操作が、AIエージェントから安全な形(プラグインが許可した範囲だけ)で行えるようになります。

おまけ: WP-CLIでオプションを直接書き換えても「実際の動作」にはならないことがある

バックアップ自動化(UpdraftPlus)の設定でも一つ学びがありました。バックアップ間隔を「毎週」にしたくて、WP-CLI経由でオプションを直接更新しました。

wp option update updraft_interval weekly

これで設定は変わったように見えますが、wp cron event listで確認すると実際の定期実行イベント(updraft_backup)は登録されていませんでした。

UpdraftPlusは、設定画面で「保存」ボタンを押した時に発火するアクションの中でwp_schedule_event()を呼んでcronを登録しています。DBのオプション値を直接書き換えても、このスケジューリング処理自体は実行されないため、「設定は変わったのに何も動かない」という状態になります。

教訓: WP-CLIやDB直接操作で設定を変更した場合、値が保存されたことと、プラグインが意図した副作用(cron登録、キャッシュ生成等)が実際に起きたことは別物です。wp cron event listのような手段で、実際に意図した状態になっているか必ず検証するべきです。

まとめ

• WordPressをMCPサーバー化するなら、公式wordpress-mcp+mcp-adapterの組み合わせが有力な選択肢
• ただし公式ドキュメント記載の/wp/v2/wpmcp/streamableエンドポイントは、認証成功後にrest_no_routeを返す不具合が(この記事執筆時点で)未解決。mcp-adapter本体が持つ/mcp/mcp-adapter-default-serverエンドポイントを使うのが正解
• WP-CLIでの設定変更は、値の書き換えと実際の副作用の発生を分けて検証する

同じ現象で困っている人の助けになれば幸いです。