WebMCP — 「エージェントに操作されるサイト」から「エージェントにツールを差し出すサイト」へ

今週何度目かの Cloudflare の話ですが、これは Cloudflare というよりブラウザ標準の話なので許してください。Kitesurf の記事で「エージェントが使うためのブラウザ」を取り上げましたが、今度はその裏側、エージェントに使われる側のサイトがどう変わるかという話です。

WebMCP とは何か

WebMCP は Chrome 146 に実験的に搭載される新しいブラウザ標準です。ページの JavaScript から document.modelContext という API が使えるようになり、サイトが「このページでエージェントに使ってほしいツール」を登録できます。

document.modelContext.registerTool({
  name: "search_products",
  description: "商品を検索する",
  inputSchema: { /* ... */ },
  execute: async (args) => { /* ... */ },
});

いま AI エージェントがブラウザで Web サイトを操作するときにやっているのは、突き詰めると「人間のふり」です。スクリーンショットや DOM を読んで、検索ボックスらしき要素を推測して、クリックして、結果をまた読む。遅いし、壊れやすいし、トークンも食う。

WebMCP のあるページでは、エージェントは推測をやめて、サイトが公式に差し出したツールを関数として呼べばいい。「操作される」から「ツールを提供する」への転換です。名前のとおり、エージェント連携の標準になった MCP(Model Context Protocol)の考え方をブラウザのページ内に持ち込んだものです。

クローラーと決定的に違うところ

もうひとつ見逃せないのが、実行される場所です。従来の AI クローラーはコンテンツを吸い上げて自分のサーバーに持ち帰るので、元のサイトには何も残りません。WebMCP のツールは訪問者のブラウザの中で、そのユーザーのセッションのまま実行されます。

つまりログイン状態や権限はユーザーのものがそのまま使われ、アクセスはサイトのトラフィックとして残る。「AI に読まれるとサイトに人が来なくなる」問題への、構造的な回答のひとつになっています。

Cloudflare の発表: コード変更なしで対応させる

で、今回 Cloudflare が出したのは、この WebMCP に既存サイトをコード変更なしで対応させる開発者プレビューです。仕組みは潔くて、エッジの HTMLRewriter で各ページに <script> を1行注入するだけ。

<script type="module"
        src="/.webmcp/bridge.js"
        data-packs="c2pa,mcp-server-client"
        data-mcp-url="/mcp"></script>

このブリッジスクリプトがページ内で document.modelContext の有無を確認し（対応ブラウザでなければ何もしない）、「パック」と呼ばれるツール群を登録します。ダッシュボードの Agent Readiness > Labs でトグルを入れてパックを選ぶだけで、デプロイ作業はありません。

現時点のパックは2つです。

• Content Credentials — ページ内の画像を C2PA（コンテンツ来歴）でスキャンするツール。どの画像に来歴情報があり、誰が署名したか（例: Adobe Firefly 生成）をエージェントが確認できます
• Site MCP Server — サイトが自前の MCP サーバーを持っている場合、その各ツールをブラウザ内ツールとしてプロキシ登録してくれます。既存の MCP 資産がそのまま「ページのツール」になるのが賢い

手元での確認も簡単

対応済みかどうかは HTML を見れば分かります。

curl -s https://your-site.example | grep webmcp

エージェントを持っていなくても、Cloudflare の Browser Run（Kitesurf が動いているリモートブラウザ基盤）が WebMCP 対応済みなので、登録されたツールの検出と呼び出しをテストできます。エージェント用ブラウザとサイト側対応の両輪を同時に整備してくるあたり、今週の Cloudflare は本当に手が早い。

冷静な注意点

• Chrome 146 の実験的機能であり、標準化はこれからです。他ブラウザの動向も未知数
• Cloudflare 側も開発者プレビューで、Content Credentials パックは現状デコードのみ（暗号署名の検証は未実装）
• ツールはユーザーのセッションで動くため、「エージェントに何をさせてよいか」の権限設計はサイト側の新しい宿題になります

サイト運営者として考えておくこと

弊社のようなサイトを作る側の目線だと、これは「対応するかどうか」より「いつ、どのツールを公開するか」の問題になっていくと思います。ECなら商品検索と在庫確認、予約サイトなら空き照会——エージェント経由の来訪者に何を許すかは、そのままビジネスの意思決定です。

コーポレートサイトや自社サービスの「エージェント対応」をどう設計するか、といったご相談も受け付けています。まだ答えが固まっていない領域だからこそ、早めに触っておく価値があるはずです。