WebMCP：既存サイトにコード変更なしで「エージェント向けツール面」を配れるようになった

要約

Cloudflare が 2026-08-06、WebMCP の実装を開発者プレビューとして公開しました。同日発表の「Agentic Internet」構想のうち、エージェントからサイトを呼び出せるようにする Callable の柱に当たります。

WebMCP はブラウザ標準の側から来ている仕組みです。これまで AI エージェントがサイトを操作する手段は、実質的にスクレイピングとブラウザ自動操作でした。画面を読み、要素を探し、クリックする。この方式はサイト側が DOM を少し変えるだけで壊れます。WebMCP はここを逆転させ、サイト側が「これができます」というツールを宣言し、エージェントはそれを呼ぶという形にします。Chrome 146 に実験的に搭載されていて、ブラウザ上では document.modelContext として現れます。

Cloudflare の実装は2つの要素からなります。1つはエッジでの注入です。HTMLRewriter を使って、配信される HTML レスポンスにブリッジスクリプトの参照を差し込みます。サイト側のコードには手を入れません。もう1つがブラウザ側のブリッジで、WebMCP への対応を検出し、ツールパックを登録してエージェントから呼び出せる状態にします。data-packs に列挙されたパックを1つのツールリストへ合成し、それぞれを .registerTool で登録する仕組みです。

有効化は Cloudflare ダッシュボードの Agent Readiness > Labs から、コード変更なしのワンクリックで行えます。初期のツールパックは2種類です。Content Credentials は画像の C2PA メタデータ（誰がいつ作った画像か）をエージェントから参照できるようにするもの。Site MCP Server は、すでに運用している MCP サーバーをサイト上のツールとして露出させるものです。

重要な設計点として、ツールはすべて訪問者のブラウザ上で、訪問者のオリジンとセッションで実行されると説明されています。提供は開発者プレビューで、価格の記載はありません。

同日の発表には MCP そのものの次世代仕様への対応（ステートレス化と createMcpHandler）も含まれますが、そちらがサーバー側の実装・運用の話であるのに対し、WebMCP は「既存の Web サイトにツール面をどう配るか」という配信側の話です。

何が変わったか

• サイトのコードを変更せず、ダッシュボード操作だけで WebMCP のツール面を配信できるようになった（Agent Readiness > Labs）
• HTMLRewriter によるエッジ注入方式のため、既存サイトの実装・フレームワークを問わない
• Content Credentials（画像の C2PA メタデータ）と Site MCP Server（既存 MCP サーバーへの接続）の2パックをすぐ有効化できる
• 運用中の MCP サーバーを、サイト訪問時にエージェントから呼べるツールとして露出できる
• ツールの実行は訪問者のブラウザ上、訪問者のオリジンとセッションで行われる
• ブラウザ側は Chrome 146 の実験搭載（document.modelContext）に依存する。開発者プレビューで価格記載なし

業務インパクト（一般企業向け）

この発表は、いま何かを導入する話としてよりも、近い将来の前提を把握しておく話として読むのが適切です。ブラウザ標準側が Chrome の実験機能段階にあり、Cloudflare 側も開発者プレビューです。本番の顧客体験をここに乗せる段階ではありません。

そのうえで、押さえておく価値があるのは方向性のほうです。自社サイトに AI エージェントが訪れて操作するという事態は、すでに起きはじめています。このとき企業が取れる立場は2つに分かれます。何もせず、エージェントに画面を読ませて推測で操作させるか。あるいは「うちのサイトではこの操作ができます」と定義して、その範囲で呼ばせるか。後者を選べる手段が出てきた、というのが今回の意味です。**エージェントの操作経路を定義できるということは、定義しない経路を減らせるということでもあります。**在庫照会は許すが発注は許さない、といった線引きが、画面の作りではなくツールの定義として表現できるようになります。

一方で、セキュリティ上の論点が明確にあります。ツールが訪問者のセッションと権限で実行される構図は、裏を返せば「サイトが提供するツールを、エージェントが訪問者の権限で叩く」ということです。ログイン中のユーザーのブラウザでエージェントが動いていれば、そのユーザーができることはエージェントもできます。ここは従来の「サーバー側 API に認証をかける」という発想だけでは整理しきれません。どのツールを露出するか、実行前に人間の確認を挟むか、という設計判断が要ります。既存 MCP サーバーを Site MCP Server パックでそのまま露出させる場合は特に、そのサーバーが持つ書き込み系ツールの扱いを先に決めてください。

社内での扱いとしては、Web 担当と情シスの両方が関わる話になります。ダッシュボードのワンクリックで有効化できるということは、Web 担当が単独で有効化できてしまうということでもあります。プレビュー段階の今のうちに、誰が判断するのかを決めておくのが安全です。

副業・個人活用視点

個人で Web 制作やエージェント開発をしているなら、ここは「学ぶ価値はあるが、まだ売る段階ではない」領域です。

まず学習面での価値がはっきりしています。「エージェントにスクレイピングさせるか、ツールを渡すか」という対比は、MCP という考え方を理解する入口として非常に分かりやすい題材です。スクレイピングの脆さ — セレクタが変わると壊れる、レイアウト変更で誤動作する — を実際に体験してから、ツールを宣言して呼ばせる方式を見ると、MCP が何を解決しようとしているのかが腹落ちします。MCP をこれから学ぶなら、仕様書から入るより、この対比から入るほうが速いはずです。

実案件への持ち込みは、現時点では推奨しにくい状況です。Chrome 146 の実験機能に依存しているため、クライアントのエンドユーザー環境で動く保証がありません。提案に組み込むなら「今できること」ではなく「今後こうなる」の文脈に留め、実装は既存の MCP サーバー構築のほうで受けるのが現実的です。逆に言えば、Site MCP Server パックで露出できる MCP サーバーを先に作っておくのは筋の良い準備になります。WebMCP が安定したときに、そのまま配信面を足せる位置に立てます。

発信のネタとしては扱いやすい題材です。実際に自分のサイトで有効化して、Chrome の実験フラグを立てて挙動を確認する — この手の検証記事は、標準が動いている時期にこそ読まれます。ただし記事にするなら、実験段階であることと document.modelContext という API 名が変わり得ることを明記しておかないと、後で誤情報になります。仕様が固まるまでは「そういう方向の標準が動いている」という位置づけで書くのが安全です。