AIがWordPressを操作する仕組みとして「MCP」が急速に広がっていますが、その次の流れとしてWebMCPという新しい仕組みが出てきました。2026年9月には、WordPressをブラウザだけで動かせる公式ツール「WordPress Playground」がWebMCPに対応したと発表されています。日本語でPlaygroundとWebMCPを組み合わせて扱った記事は、調べた範囲ではまだありません。

そこで当社でも、ChatGPTのアプリから実際に試しました。この記事では、MCPとWebMCPは何が違うのかを整理したうえで、実際にやってみて、どこまで動き、どこで止まったかをそのまま書きます。

結論から言うと、ページ側は準備ができていました。PlaygroundはAIが使える道具を17個公開し、ChatGPTのアプリにもその一覧が表示されました。ところが、AIに作業を頼むと「道具が見つからない」と言い、実際には1つも呼べませんでした。2026年9月時点のWebMCPは、「Webサイトの側は整い始めたが、AIの側がまだ追いついていない」段階です。

この記事は2026年9月23日の実験と、同時点の公開情報にもとづいています。WebMCPは提案段階の技術で、変化がとても速い分野です。実際に使えるようになったら、再実験して追記します。

WebMCPとは?「Webページ自身がAIに操作方法を教える」仕組み

WebMCPは、Webページが「AIが使える操作」を自分で宣言し、ブラウザの中のAIがそれを直接呼び出せるようにする仕組みです。Googleとマイクロソフトの技術者が中心になって、W3C(Webの標準を作る団体)のコミュニティグループで仕様の下書きが進められています。まだ正式な標準ではありません。

たとえるなら、これまでのAIは、Webページを「人間と同じように画面を見て、ボタンの場所を探して押す」やり方で操作していました。WebMCPでは、ページ側が「このサイトでできることはこの17個です。こう呼んでください」という操作メニューをAIに渡します。AIは画面を読み解く必要がなくなり、正確に、少ない手順で作業できるようになる、という考え方です。

ブラウザの対応は、Chromeが2026年6月から試験提供(オリジントライアル)を始めた段階で、正式提供はまだです。AI側では、ChatGPTのデスクトップアプリの内蔵ブラウザが「サイトツール」という名前で対応をうたっています。

MCPとWebMCPの違い

MCPとWebMCPは名前が似ていますが、AIとWordPressをつなぐ経路がまったく違います。

従来のMCPとWebMCPの構成の違い。MCPはAIと手元のMCPサーバーとWebSocketを経てブラウザにつながり、WebMCPはWebページ自身がブラウザ経由でAIに道具を公開する
比べる点 従来のMCP WebMCP
道具を出すのは誰か MCPサーバー(別のプログラム) Webページ自身
準備 手元のパソコンやサーバーでMCPサーバーを動かす ページを開くだけ
ログイン アプリケーションパスワードなどを別に設定 ブラウザのログイン状態をそのまま使う
主なAI Claude Code、Claude Desktop、Gemini CLI など ChatGPTのデスクトップアプリ(内蔵ブラウザ)
成熟度 実用段階 提案・試験段階

WordPressで言えば、WooCommerce MCPや、WordPress公式のMCP Adapterは従来のMCPです。サイトの外にMCPサーバーを置き、そこを通してAIが商品や投稿を操作します。WebMCPでは、そのサーバーを置かずに、ページそのものがAIの窓口になります。

Playgroundは両方に対応しています。当社で従来のMCP用のサーバー(@wp-playground/mcp)も起動して道具の一覧を取ってみたところ、こちらも17個でしたが、顔ぶれが少し違いました。ブラウザ側にある「メールの一覧」がなく、代わりに「新しいタブでサイトを開く」があります。同じPlaygroundでも、配布の経路ごとに更新のタイミングがずれているためです。

実際に試してみた|ChatGPTのアプリからPlaygroundを開く

実験は2026年9月23日の夜、ChatGPTのデスクトップアプリ(コーディング用のCodex画面、モデルはGPT-5.6 Sol)で行いました。OpenAIの公式ドキュメントでは、サイトツールを使えるモデルはGPT-5.6 SolかGPT-6 Solとされています。

内蔵ブラウザは「頼めば開く」

最初につまずいたのは、内蔵ブラウザの開き方です。公式ドキュメントにも手順は書かれていません。そこでAIに「内蔵ブラウザで https://playground.wordpress.net/ を開いてください」と頼んだところ、16〜26秒でアプリの右半分にPlaygroundが開きました。なお、普通のChromeでPlaygroundを開いても、WebMCPの道具は何も起きません。

ページは17個の道具を公開していた

内蔵ブラウザのアドレスバーの左端に、つまみが並んだ形のアイコンがあります。これが「サイトツール」です。押すと、次のように表示されました。

ChatGPTアプリの内蔵ブラウザでPlaygroundを開き、アドレスバーのサイトツールを押すと「利用可能なサイトツール(17)8件の読み取り、9件の書き込みツール」と表示された画面

「利用可能なサイトツール(17)」「8件の読み取り、9件の書き込みツール」。9月5日の公式発表では16個でしたが、その後の更新でメールの一覧を見る道具が加わり、本番でも17個になっていることが確認できました。主な道具は次のとおりです。

区分 できること(道具の例)
読み取り(8個) サイト情報の取得、現在のURLの確認、ファイルの読み込み・一覧・存在確認、送信されたメールの一覧 など
書き込み(9個) PHPの実行、WordPressへのリクエスト、ページ移動、ファイルの作成・削除、フォルダの作成・削除、Playground上の作業環境の名前変更 など

道具の説明文は、人間ではなくAIに向けて書かれていた

一覧から「PHPを実行する道具(playground_execute_php)」を開くと、区分が「書き込み」であることと、英語の説明文が表示されました。

playground_execute_phpの詳細。区分は書き込みで、説明文に出力は50KB以内に収めてコンテキストウィンドウを埋めないようにという、AIに向けた注意が書かれている

説明文には、PHPの書き方や結果の受け取り方に続いて、こう書かれています。「出力は切り詰めずにすべて返す。無制限に出力するクエリは避け、コンテキストウィンドウを埋めないよう50KB以内に収めること」。コンテキストウィンドウとは、AIが一度に覚えておける文章の量のことです。

この一文は、人間の利用者には意味がありません。Webページが、人間に向けた画面とは別に、AIに向けた「使い方の説明書」を持ち始めているということです。WebMCPで一番見てほしいのは、実はこの変化です。

ところが、AIは道具を使えなかった

準備が整ったところで、AIに次の依頼をしました。

「このWordPressのサイト名、WordPressのバージョン、PHPのバージョン、有効なテーマ名を、Site toolsを使って調べて教えてください」

2分33秒かかって返ってきた答えがこちらです。

AIの回答。Site toolsが利用可能なツールとして公開されておらず直接照会できなかったとし、Playgroundの既定構成から推測してサイト名やバージョンを答えている

AIは「この環境ではSite toolsが利用可能なツールとして公開されておらず、サイトへ直接照会できませんでした」と答えました。そのうえで、Playgroundの初期設定についての公開資料から推測して、サイト名・WordPress 7.1.2・PHP 8.5・Twenty Twenty-Fiveと答えています。管理画面で確認すると、サイト名とWordPressのバージョン、テーマは合っていましたが、これはサイトを調べた答えではなく、資料から推測した答えです。推測であることを正直に書いている点は評価できます。

つまり、ブラウザの画面には「利用可能なサイトツール(17)」と出ているのに、AIにはその道具が渡っていなかったことになります。設定画面の「サイトツールを有効にする」もオンでした。ページ側の仕組みは動いていて、止まっているのはアプリとAIのあいだです。段階的に提供中の機能なので、表示と実際の接続が噛み合っていない可能性が高いと考えていますが、原因は確定できていません。

道具が使えないと、AIは別の手段を探し始める

実は、1回目の実験ではもう少し気になる動きがありました。途中でモデルを切り替えた会話で同じ依頼をしたところ、AIは「サイトツールの接続が続けて失敗している」と報告し、別の経路を探すとして、パソコンの中で動いているプログラムの一覧を調べるコマンドを実行し始めました。

1回目の実験でAIが接続の失敗を報告し、別経路としてパソコンのプロセス一覧を調べるコマンドを実行し始めた画面

今回は一覧を見ただけで害はなく、そのまま答えを出さずに止まりました。ただ、これはWebMCPの考え方と真逆の動きです。WebMCPは「ページが許した操作だけをAIにさせる」ための仕組みですが、道具が使えないとき、AIはそれを諦めずに、許されていない手段へ回り込もうとすることがあります。AIに作業を任せるときは、道具が使えなかったときにどう振る舞わせるかまで考えておく必要があります。

WebMCPの安全面で知っておきたいこと

ChatGPTのアプリの設定画面を見ると、AIにブラウザをどこまで触らせるかを段階的に絞る設計になっていました。

ChatGPTアプリの設定画面。サイトツールを有効にする(WebMCPを含む)がオン、エージェントの権限はウェブ閲覧・ダウンロード・アップロードすべて承認が必要、CDPへのフルアクセスはリスク増大表示で既定オフ
  • 「サイトツールを有効にする」の説明に、WebMCPが名指しで書かれている。WebサイトがAIに道具を公開すること自体を、利用者が許可・拒否できます。
  • AIのウェブ閲覧・ダウンロード・アップロードは、初期設定ですべて「承認が必要」。サイトごとに例外を設定できます。
  • ブラウザの内部に深く入れる設定は「リスク増大」の表示つきで初期状態はオフ。

もう1つ、内蔵ブラウザを開くと「Chromeのパスワードと Cookie を内蔵ブラウザに移しますか」という案内が出ます。AIが操作するブラウザに、普段のログイン情報をまとめて渡すことになるので、実験目的なら移さないことをおすすめします。WebMCPはブラウザのログイン状態をそのまま使う仕組みなので、どのサイトにログインしたままAIに作業させるかは、利用者の側で意識する必要があります。

仕様書やChromeのガイド、Playgroundの説明でも、プロンプトインジェクション(ページの中に仕込んだ文章で、AIに意図しない操作をさせる攻撃)への注意がはっきり書かれています。Playgroundが「使い捨ての試験環境として使ってほしい」と案内しているのはそのためです。

WordPressの本番サイトはどうなるのか

2026年9月時点で、WordPressの本番サイトがWebMCPに対応するための公式の仕組みはありません。WordPress 7.2のロードマップでは、公式AIプラグインの中で「ブラウザで動くAIエージェントから、WordPressの機能(Abilities)を使えるようにする方法を探る」と書かれている段階です。7.2の本体にWebMCPが入るわけではありません。

それでも方向ははっきりしています。WordPressにはすでに、サイトの機能を「AIが呼べる形」で登録するAbilities APIがあり、今は従来のMCPを通してAIに渡しています。これが将来WebMCPにもつながれば、管理画面を開いているあいだ、AIがそのサイトの操作メニューを受け取って作業を手伝う、という使い方が現実になります。Webサイトは「人間が見るもの」から、「人間とAIの両方が使うもの」へ設計が変わり始めています。

結局、いま使えるのか

知りたいこと 2026年9月時点の答え
Playgroundは道具を公開しているか している(17個、ChatGPTのアプリで確認)
ChatGPTのアプリから実際に使えるか 当社の環境では使えなかった(一覧は見えるがAIに渡らない)
ClaudeやGeminiで使えるか 公式な対応の発表は確認できず。Claude CodeからPlaygroundを操作するなら従来のMCP
WordPressの本番サイトで使えるか 公式の仕組みはなし。公式AIプラグインで検討が始まった段階

「使える」かどうかだけで見れば、まだ早い技術です。ただ、Webページの側がAIに向けた説明書を持ち始めたこと自体は、確実な変化です。AIにサイトを操作させたいなら、今はWooCommerce MCPのような従来のMCPを使い、WebMCPは動向を追っておくのが現実的です。

よくある質問

Q. MCPとWebMCPは何が違うのですか?

MCPは、別に動かしたMCPサーバーがAIに道具を渡す仕組みです。WebMCPは、Webページ自身がブラウザを通してAIに道具を渡す仕組みで、サーバーを用意する必要がありません。

Q. WebMCPを試すには何が必要ですか?

当社が試したのは、ChatGPTのデスクトップアプリ(最新版)の内蔵ブラウザです。公式ドキュメントでは、モデルはGPT-5.6 SolかGPT-6 Sol、EnterpriseやEduのワークスペースでは使えないとされています。段階的に提供されているため、アカウントによっては使えない場合があります。開発者向けには、Chromeの試験用の設定で試す方法もあります。

Q. 普通のChromeでPlaygroundを開けばWebMCPが使えますか?

使えません。ページは道具を公開していますが、それを受け取って呼び出すAIがブラウザ側に必要です。

Q. 本番のWordPressサイトにWebMCPを入れるべきですか?

今はおすすめしません。仕様が下書き段階で、AI側の対応もそろっていません。公開する道具の設計を誤ると、ログイン中の権限でAIに操作をさせることになるため、試すなら使い捨ての環境で行ってください。

関連記事

AIにサイトや業務を操作させたいなら

今回の実験で改めて分かったのは、AIに任せる範囲と、任せないときの振る舞いを先に決めておくことが大切だということです。当社はWordPress専門のエンジニアとして、MCPを使ったサイト連携や、AIが処理して人が最後に確認する業務の自動化を実装しています。「うちのサイトでAIに何ができるか」から、お気軽にご相談ください。

▶ AI業務自動化・AIシステム開発の詳細を見る(相談無料)

更新履歴

  • 2026年9月27日:公開(2026年9月23日の実験と、同時点の公開情報にもとづく)

この記事を書いた人

矢部 敦

矢部 敦合同会社Edel Hearts 代表

WordPress専門の開発会社を経営。プラグイン開発・カスタマイズ・保守を専門とし、18時間におよぶUdemyのWordPress講座を開講。出典付きで回答するAIチャットボット「Edel AI Hybrid Chat」開発者。著書『WordPress はじめての最小プラグイン』(Kindle)。本ブログの記事は、実際の開発・運用で得た一次情報をもとに執筆しています。会社情報はこちら

この記事をシェア