Claude CodeでWordPressを操作する | WordPress MCPの仕組み・つなぎ方と注意点

MCPとは何か｜AIと外部ツールをつなぐ共通規格

まず土台からよ。MCPは、Model Context Protocolの略で、AIアプリケーションと外部のデータやツールをつなぐためのオープンなプロトコル、つまり通信の約束事なの。Anthropicが提唱して、今はmodelcontextprotocol.ioで仕様が公開されているわ。

たとえるなら「AI用の共通コンセント」ね。夜のお店で言えば、どの子でも使える共通の控室みたいなもの。サービス側がMCPサーバーを1つ用意すれば、利用者はMCP対応のクライアントを選ぶだけで組み合わせられるのよ。それが共通規格のありがたさなの。

やり取りは、主に3つの要素で成り立つの。

• ツール（Tools）：AIが実行できる関数
• リソース（Resources）：AIが読み取るデータ
• プロンプト（Prompts）：作業の進め方を示すテンプレート

今回の組み合わせでは、Claude Codeがクライアント、WordPressサイトがサーバー側になるわ。

ここで勘違いしやすいのが、REST APIとの関係よ。WordPressには以前からREST APIという外部連携の仕組みがあるけれど、MCPはそれを置き換えるものじゃないの。内部の機能をAIから使いやすい形に包み直す規格、と捉えなさい。

WordPress公式の現状｜Abilities APIとMCP Adapter

「claude wordpress」連携を考えるうえで大事なのが、WordPress公式側の変化なのよ。

土台はWordPress 6.9のAbilities API

WordPress 6.9で導入されたAbilities APIは、コアやプラグインの機能を「名前」「入力と出力の形式」「権限チェック」「実行処理」として標準化して登録できる仕組みなの。何ができて、何が必要で、誰が頼めるのかが、最初から分かる形になるのよ。

初期状態のコアに登録されているのは、次の3つ。

• core/get-site-info：サイト情報を返す
• core/get-user-info：ユーザー情報を返す
• core/get-environment-info：環境情報を返す

数は少なくても、機能をプログラムから発見して実行できる形にそろえる土台が公式に整い始めたこと自体が重要なの。

橋渡し役は公式のMCP Adapter

Abilities APIとMCPをつなぐのが、WordPressのAI関連の取り組み「AI Building Blocks for WordPress」の公式パッケージ、MCP Adapterよ。Developer.WordPress.orgの公式記事では、登録されたアビリティをMCPのツールやリソースに変換し、Claude Code、Claude Desktop、Cursor、VS Codeなどから発見・実行できるようにするものとして紹介されているわ。

有効化すると、既定のサーバー「mcp-adapter-default-server」が登録されて、アビリティの発見、詳細取得、実行という3つのツールが公開されるの。接続先は、サイトURLに続く「/wp-json/mcp/mcp-adapter-default-server」が目安よ。

ここ、よく聞いて。すべての機能が自動で外に出るわけじゃないの。既定サーバーで公開するには、アビリティ登録時に「meta.mcp.public」(または「meta.public」)を有効にする明示的な設定が必要だと、公式記事は説明しているわ。「公開すると決めた機能だけがAIから見える」設計なの。これは制約であると同時に、安全面の要でもあるのよ。

それから、WordPress.orgにはプラグイン開発者の申請作業を支援する別のMCPサーバーもあるけれど、自分サイトを操作するものとは目的が違うから、区別なさいね。

接続の前提条件

さて、つなぐ前に必要なものを並べるわ。大きく4つよ。

1つ目はClaude Code。ターミナルで動作して、ログインできていることが前提。MCPサーバーの追加や確認は「claude mcp」コマンド群で行うの。

2つ目は、MCPに対応したWordPressサイト。公式ルートではWordPress 6.9以降を土台にMCP Adapterを用意する形ね。サードパーティ製のWordPress用MCPサーバープラグインも複数あるけれど、提供元、対応範囲、認証方式がそれぞれ違うの。導入前に配布元の公式情報を必ず確認なさい。本記事は公式のMCP Adapterを軸に説明するわ。

3つ目は、接続方式に応じた道具。ローカル環境へ標準入出力（STDIO）でつなぐ場合はWP-CLI、公開サイトへHTTPでつなぐ場合はNode.js環境などが関係してくるの。

4つ目は認証情報。公開サイトへの接続では、一般にWordPressのアプリケーションパスワードを使うわ。これはWordPress 5.6から標準搭載の仕組みで、ログインパスワードとは別に外部連携専用のパスワードをユーザーごとに発行できて、不要になれば個別に取り消せるの。鍵は分けて持つ。これ、夜の世界でも鉄則よ。

接続の考え方｜ローカルはSTDIO、公開サイトはHTTP

ローカル環境はSTDIOとWP-CLI

自分のパソコン上の開発用WordPressなら、STDIO方式が分かりやすい方法よ。公式記事では、WP-CLIの「wp mcp-adapter serve」でMCP Adapterを起動する構成が紹介されているわ。対象サイトはパスの指定で、実行ユーザーはユーザー指定で決まるの。

Claude Codeでは、この起動コマンドを「claude mcp add」で登録する形に読み替えられるわ。概念的には次の形ね（パスとユーザー名は自分の環境に置き換えてちょうだい）。

claude mcp add wordpress-local -- wp --path=/path/to/wordpress mcp-adapter serve --server=mcp-adapter-default-server --user=admin

「--」より後ろが、Claude Codeが起動する外部コマンドよ。登録後は「claude mcp list」で接続状態を、「claude mcp get wordpress-local」で詳細を確認できるの。セッション中は「/mcp」でサーバーの状態やツール数を確認するのが、公式ドキュメントの案内よ。

設定の保存先であるスコープも意識なさい。既定のローカルは現在のプロジェクトだけの個人設定、プロジェクトは直下の「.mcp.json」でチーム共有する設定、ユーザーは全プロジェクトで使う個人設定よ。認証情報は共有ファイルに直接書かず、個人側のスコープや環境変数で扱うのが安全なの。

公開サイトはHTTPとリモートプロキシ

公開サイトではHTTP方式が前提になるわ。公式記事では、サイトのMCPエンドポイントへつなぐために「@automattic/mcp-wordpress-remote」というリモートプロキシを介する構成が紹介されているの。Claude Code側でこのプロキシをSTDIOサーバーとして起動して、プロキシがサイトへHTTPで通信する形ね。設定に必要なのは、エンドポイントURL、WordPressのユーザー名、アプリケーションパスワードの3点よ。概念的には次の形になるわ。

claude mcp add --env WP_API_URL=https://example.com/wp-json/mcp/mcp-adapter-default-server --env WP_API_USERNAME=your-user --env WP_API_PASSWORD=xxxx --transport stdio wordpress-remote -- npx -y @automattic/mcp-wordpress-remote@latest

サーバーの実装によっては、プロキシなしでHTTP直接接続できる場合もあるの。そのときは「claude mcp add --transport http サーバー名 URL」で登録するわ。どちらの形かは、使うサーバーの公式案内が正解よ。自己流で決めちゃダメ。

接続できたら、まずは読み取りから試しなさい。AIがアビリティの発見、詳細取得、実行の順にツールを呼び、サイト名やURLが返ってくれば、接続の骨格は通っている証拠よ。

MCP経由でできること・できないこと

できることの範囲は、「WordPress側がアビリティとして登録し、MCP経由で公開した機能」と一致するわ。ここは夢を膨らませすぎないこと。

公式の初期状態でできるのは、サイト情報、ユーザー情報、環境情報の取得といった読み取りが中心よ。先はコアやプラグイン、独自コードがアビリティを増やすほど広がって、状態確認、公開範囲でのコンテンツ取得や更新の補助、診断手順の実行などが想定されるわ。Claude Codeの強みは、コード編集とサイト情報の参照を同じターミナルの流れで扱いやすい点にあるの。

一方で、限界もはっきりしているのよ。

第一に、公開されていない機能は使えないこと。アビリティとして登録されていない操作や、管理画面でしか提供されていない操作は、MCP接続だけでは実行できないわ。

第二に、見た目の最終判断は人間の領域が残ること。ブロックエディタ上のレイアウトやデザインの良し悪しまでを保証する仕組みじゃないの。

第三に、接続ユーザーの権限を超えることはできないこと。権限チェックで拒否される設計が公式に推奨されているの。逆に言えば、管理者で安易につなぐと、AIが実行できる範囲も最大化しちゃうのよ。

第四に、発展途上の仕組みであること。手順や提供範囲は更新されやすくて、古い記事の設定が現在のバージョンと一致しないことがあるわ。だから最新版の確認が欠かせないの。

認証と権限の注意点

WordPressをAIから触れるようにすることは、サイトへの新しい入口を増やすことなの。だから次の線引きを先に決めなさい。

まず、専用ユーザーを作って、権限は最小にすること。公式記事でも、MCPアクセス専用のユーザーを用意して、必要な権限だけを持たせることが推奨されているわ。読み取り中心なら読み取りに足る権限にとどめて、本番サイトでは特に徹底なさい。

次に、アプリケーションパスワードは「鍵」として扱うこと。漏れれば、発行ユーザーの権限でアクセスされかねないの。共有されやすい設定ファイルやGit管理のリポジトリに平文で書かない、画面共有やスクリーンショットに写り込ませない、通信はHTTPSを前提にする。基本だけど、基本を守れるかどうかが分かれ目よ。

さらに、最初は読み取り専用で小さく始めること。公式記事も、破壊的でない読み取り専用のアビリティから公開して、ローカルで挙動を確認してから段階的に広げる進め方を勧めているわ。削除や公開状態の変更など、取り返しのつきにくい操作は最後まで慎重に扱いなさい。

つまずきやすいのは、接続状態の確認不足、スコープの混同、他クライアント向け設定の流用よ。「claude mcp list」で認証待ちや失敗を切り分けて、ツール数が極端に少ない場合は公開アビリティが少ない可能性も考えなさい。他ツール向けJSONは、URLなのに種別指定がなくSTDIOと解釈されるなど、形式違いで失敗する場合があると公式ドキュメントは注意しているわ。

どんな人に向くか

向いているのは、ターミナルやClaude Codeに慣れて、WordPressのコードや運用を自分で扱っている人よ。開発の補助、複数サイトの状態確認、定型診断の効率化など、開発と運用の間にある作業で力を発揮するわ。

逆に、管理画面の操作を会話で置き換えたいだけの人には、現時点ではハードルが高いかもしれないわ。既定状態でできることは限定的で、範囲を広げるにはプラグインやコード側の整備が要る場面も多いからね。

よくある質問

MCPは、WordPressのREST APIの代わりになりますか。

代わりにはならないわ。MCPはREST APIを置き換えるものではなくて、内部の機能をAIから使いやすい形に包み直す規格よ。

管理者ユーザーでつないでも大丈夫ですか。

おすすめしないわ。管理者で安易につなぐと、AIが実行できる範囲も最大になるの。MCPアクセス専用のユーザーを作って、必要な権限だけを持たせなさい。

アプリケーションパスワードを、共有される設定ファイルに書いてもいいですか。

平文で書いてはだめよ。共有されやすい設定ファイルやGit管理のリポジトリには書かず、個人側のスコープや環境変数で扱いなさい。

ほかの記事

• WordPress公式AIプラグインの機能一覧
• WordPressでAI機能を使う前の確認リスト
• WordPressのバックアップを手動で取る方法

出典

• Abilities API in WordPress 6.9(Make WordPress Core)
• From Abilities to AI Agents: Introducing the WordPress MCP Adapter(WordPress Developer Blog)
• Application Passwords: Integration Guide(Make WordPress Core)
• Connect Claude Code to tools via MCP(Claude Code 公式ドキュメント)
• Model Context Protocol(公式)