Cloudflare WebMCPとは？仕組み・設定手順・注意点を実際に有効化して解説

AI

Cloudflare WebMCPとは、Cloudflareを通しているWebサイトに、AIエージェント向けのツールインターフェース(WebMCP)をスイッチ1つで追加できる機能です。 2026年8月6日に開発者プレビューとして公開され、オリジンのコード変更もデプロイも不要で、配信されるHTMLにCloudflareのエッジが小さなブリッジスクリプトを挿入する仕組みです。この記事は、当サイト(Cloudflare無料プラン)で実際に有効化し、挿入される実物のHTMLと配信されるbridge.jsのコードを読んだうえで、標準の背景から設定手順・落とし穴までを解説します。

WebMCPとは?ブラウザ標準としての中身

WebMCPは、Webサイトが自分の機能を「AIエージェントが呼び出せるツール」として宣言するためのブラウザ標準です。GoogleとMicrosoftのエンジニアが2025年8月に統合提案を公開し、W3CのWeb Machine Learning Community Groupで策定が進んでいます。ブラウザ実装はChromeが先行しており、Chrome 146で実験フラグつきの早期実装、Chrome 149からはOrigin Trial(本番サイトでの試験運用)が予定されています。

ページ側のAPIは document.modelContext(仕様の経緯により navigator.modelContext と併記されることもあります)で、次のような形でツールを登録します。

await document.modelContext.registerTool({
  name: "search_products",
  description: "商品名で在庫を検索する",
  inputSchema: { type: "object", properties: { query: { type: "string" } } },
  async execute({ query }) { /* ページ内の検索処理を実行 */ },
});

ツールは「名前・自然言語の説明・JSON Schemaの入力定義・実行関数」の4点セットです。この形式はMCP(Model Context Protocol)のツール定義を踏襲しているため、エージェント側から見ればMCPサーバーと同じ作法で扱えます。違いは実行場所で、MCPは独立したサーバーを立てるのに対し、WebMCPでは開いているWebページ自身がツールサーバーになります。将来的には、JavaScriptを書かずフォーム要素の属性からツールを自動合成する宣言的APIも計画されています。

従来のAIエージェントのWeb操作と何が違う?

これまでブラウザ操作型のAIエージェントは、画面のスクリーンショットをビジョンモデルで解析し、「どこをクリックすべきか」を推測して操作してきました。WebMCPはこの構造を根本から変えます。

比較軸 画面解析型(従来) WebMCP(ツール呼び出し型)
操作の方法 スクリーンショット解析→座標クリック サイトが宣言したツールを直接呼び出し
確実性 レイアウト変更・言語で壊れやすい 入力・出力が構造化され安定
速度・コスト 画像解析の往復で遅く高コスト 関数呼び出し1回で完結
サイト側の統制 何をされるか制御できない 公開するツールをサイトが決める
ログイン状態 操作再現が不安定 ページのセッションをそのまま利用

サイト運営者の視点で重要なのは統制の行です。エージェントに「何でも操作される」のではなく、「この機能だけをこの形で使ってよい」とサイト側が定義できることが、WebMCPの本質的な価値です。

CloudflareのWebMCP機能の仕組み

Cloudflareの実装は「WebMCP対応をエッジで後付けする」ものです。有効化すると、エッジのHTMLRewriterが配信するHTMLの <head> にscriptタグを1本挿入します。当サイトの本番HTMLに実際に挿入されているタグは次の通りです。

<script type="module" src="https://digital-sales-job.com/.webmcp/bridge.js"></script>

/.webmcp/bridge.js(ドット付きのパスに注意)はCloudflareのエッジが配信するブリッジスクリプトで、当サイトで取得した実物は約47KB・非minifyのコードでした。動作の流れは次の通りです。

modelContext検出ツールパック解決ツール登録サイトMCP接続(動的)
  1. ページ読み込み時に document.modelContext(なければ navigator.modelContext)を探す
  2. 見つからない場合(=WebMCP未対応ブラウザ)は、コンソールに「Chrome M146+で実験フラグを有効に」という警告を出して終了する。ページの表示や既存の動作には一切影響しない
  3. 対応ブラウザでは、scriptタグの data-packs 属性で指定されたツールパックを読み込み、ツールを登録する
  4. Site MCP Serverパックが有効な場合は、サイトのMCPエンドポイントへ接続してツール一覧を取得し、ページのツールとして追加登録する

ツールの実行はすべて訪問者のブラウザ内で完結し、ツール実行に伴うデータがCloudflareへ送られることはない、というのが公式の設計方針です。実際、bridge.jsのコードにも「Worker RPCへcookieを送らない(credentials未指定)」「サイトのMCPエンドポイントへは同一オリジンのときだけセッションcookieを送る」という区別が明示的に実装されていました。

ツールパックは何をする?2種類の中身

開発者プレビュー時点で提供されるパックは2つです。bridge.jsのコードから読み取れる仕様レベルの挙動まで含めて整理します。

パック 登録されるツール できること
Content Credentials scan_images_c2pa / inspect_image_c2pa ページ内画像のC2PA来歴情報(コンテンツクレデンシャル)の一括スキャンと個別詳細の取得
Site MCP Server サイトのMCPサーバーのツールをそのまま再公開 サイト固有の操作(検索・手続き等)をページ経由でエージェントに開放

Content Credentialsパックは、scan_images_c2pa(ページ内の <img> を既定25枚・最大100枚までスキャンし、C2PAマニフェストの有無・生成ツール・署名者名を返す)と、inspect_image_c2pa(CSSセレクタまたはURLで指定した1枚のマニフェスト全体を返す)の2ツールです。JUMBF・CBOR・COSEといったC2PAのバイナリ形式の解析をブラウザ内のJavaScriptだけで行っており、外部サービスに画像を送りません。ただし現時点では署名のデコードのみで暗号学的な検証は未実装(結果に「検証していない」ことが明記される)です。AI生成画像の来歴表示が広がるなかで、エージェントが「この画像はどう作られたか」を確かめられるツールという位置づけです。

Site MCP Serverパックは動的パックで、サイトが既定パス /mcp(scriptタグの data-mcp-url 属性で変更可能)で運用しているMCPサーバーにJSON-RPC 2.0で接続し、tools/list で取得したツールをそのままWebMCPツールとして再登録します。コード上はタイムアウト20秒・応答サイズ上限8MB・ツール一覧はカーソル方式で最大20ページまで、SSE(text/event-stream)形式の応答にも対応という堅実な作りです。逆にいえば、サイト固有の操作をエージェントに提供するには自前のMCPサーバーが必要で、このパックを選ぶだけでは何も増えません。

実際に有効化してみた:当サイトの一次観察

当サイトでは公開直後にこの機能を有効化しました。手順はCloudflareダッシュボードの「エージェントの準備状況」(Agent Readiness)内のラボ(Labs)でWebMCPをオンにするだけ。再デプロイなしで、次のHTML応答からタグの挿入が確認できました。実際に運用して分かった観察点を4つ共有します。

観察①: パックを選ばないとツール0件で待機する。 bridge.jsのコードでは、有効なパックはscriptタグの data-packs 属性から読み取り、属性がない場合の既定は空(パックなし)でした。当サイトの挿入タグには現在この属性が付いておらず、この状態ではブリッジは読み込まれてもツールを1つも登録しません。有効化したら、挿入されたタグに data-packs が付いているかをブラウザの開発者ツールで確認し、なければダッシュボードでツールパックの選択を見直してください。

観察②: 診断スコアへの反映は遅れる。 Cloudflareの「エージェントの準備状況」には診断(Agent Readinessスコア)がありますが、WebMCPを有効化してHTMLへの挿入を確認した後も、診断のWebMCP項目は数日たっても未反映でした。ベータの検知遅れとみられるため、診断の表示だけで「動いていない」と判断しないことです。実物のHTMLを見るのが確実です。

観察③: bridge.jsのパスはドット付き。 配信パスは /webmcp/bridge.js ではなく /.webmcp/bridge.js です。curl等で確認する際にドットを落とすと、自サイトの404ページが返って「動いていない」と誤認します(挿入されたscriptタグのsrcをそのままコピーするのが確実です)。

観察④: ダッシュボード操作後はrobots.txtも確認する。 これはWebMCP自体の問題ではありませんが、当サイトではAI関連機能の設定を触った時期に、Cloudflareの「AIボットアクセスを管理」機能が有効になり、robots.txtの先頭にAIクローラーをブロックする管理ブロックが注入されていたことがありました。AIに読まれたいサイトにとっては方針と真逆の変更が静かに入ることになるため、ダッシュボードでAI関連の設定を操作した後は、本番のrobots.txtをcurlで確認する習慣をおすすめします。

設定手順と動作確認の方法

設定は5分で終わります。

  1. Cloudflareダッシュボードで対象ドメインのゾーンを開き、「エージェントの準備状況」(Agent Readiness)へ移動する
  2. ラボ(Labs)のWebMCPをオンにし、使用するツールパックを選択する
  3. 本番ページのHTMLソースに /.webmcp/bridge.js のscriptタグが挿入されたことを確認する(反映は即時〜数分)
  4. タグに data-packs 属性が付いているかを確認する(観察①の通り、なければツールは登録されません)
  5. 動作を見る場合は、Chrome 146以降で chrome://flags/#enable-experimental-web-platform-features を有効にし、開発者ツールのコンソールで [webmcp-interceptor] のログと document.modelContext の存在を確認する

現時点の限界と、それでも今有効化しておく理由

限界は明確です。ブラウザ側の対応がChromeの実験フラグ(Origin TrialはChrome 149から)に限られ、一般の訪問者のエージェントが今日からツールを使い始めるわけではありません。パックも2種類のみで、サイト固有の操作には自前のMCPサーバーが必要です。開発者プレビューのため、仕様・提供条件は今後変わり得ます。

それでも早期の有効化には合理性があります。第一に、リスクがほぼゼロであること。未対応環境では警告ログを出して待機するだけで、表示にもSEOにも影響しません。第二に、AIエージェント経由のアクセスは検索と別の入口として立ち上がりつつあり、llms.txtやAIクローラー許可と同じ「AIに読ませる・使わせる」路線の受け皿を先に持っておく価値があること。この文脈の全体像はAEO(回答エンジン最適化)の基礎で解説しています。第三に、ブラウザとエージェント側の対応が進んだとき、すでに配信面が整っているサイトから恩恵を受けるためです。

よくある失敗

  • 有効化しただけで満足する: ツールパック未選択(data-packs 属性なし)ではツール0件で待機するだけ。タグの属性まで確認する
  • 全ブラウザで動くと誤解する: 現状はChromeの実験機能。顧客向け機能をWebMCP前提で設計するのは時期尚早
  • MCPサーバーなしでSite MCP Serverパックだけ選ぶ: 既定の /mcp にサーバーがなければ何も追加されない。まずはContent Credentialsから
  • 診断スコアだけ見て判断する: 反映が遅れるため、実物のHTMLとコンソールログで確認する
  • ダッシュボード操作後にrobots.txtを見ない: AI関連設定の副作用でクローラーブロックが注入されることがある(当サイトで実例あり)

まとめ

  • WebMCPは「サイトが自分の機能をAIエージェント向けツールとして宣言する」W3C系のブラウザ標準。ページ自身がMCPサーバーの役割を果たす
  • CloudflareのWebMCP機能(2026年8月・開発者プレビュー)は、エッジでbridge.jsを挿入し、コード変更なしでこの標準に対応させる
  • パックはContent Credentials(C2PA来歴の読み取り)とSite MCP Server(自サイトMCPの再公開)の2種
  • 有効化は低リスクだが、data-packs 属性・診断の反映遅れ・robots.txtの副作用など、確認すべき落とし穴がある

生成AIまわりの社内ルール整備はAIガバナンス、AI検索対策の実装はAEOの基礎もあわせてどうぞ。

よくある質問

WebMCPとは何ですか?

Webサイトが自分の機能を「AIエージェントが呼び出せるツール」としてブラウザ経由で公開するための標準仕様です。GoogleとMicrosoftのエンジニアが提案し、W3CのWeb Machine Learning Community Groupで策定が進んでいます。エージェントは画面のスクリーンショットから操作を推測する代わりに、サイトが宣言したツールを直接呼び出せます。

CloudflareのWebMCP機能は無料プランでも使えますか?

使えます。当サイトはCloudflareの無料プランですが、ダッシュボードの「エージェントの準備状況」内のラボ(Labs)からWebMCPを有効化でき、本番HTMLへのbridge.js挿入を確認済みです。ただし開発者プレビュー(ベータ)のため、提供条件は今後変わる可能性があります。

WebMCPを有効化するとSEOやサイト表示速度に影響しますか?

検索順位への直接の影響はありません。挿入されるのはmodule型のscriptタグ1本(bridge.jsは約47KB)で、レンダリングをブロックせず、WebMCP未対応のブラウザではコンソールに警告を出して待機するだけです。当サイトでは有効化後も表示速度・検索計測に変化は見られていません。

MCPとWebMCPは何が違いますか?

MCPはAIアプリと外部ツール・データをつなぐプロトコルで、通常は独立したMCPサーバーを立てます。WebMCPはその考え方をWebページに持ち込んだブラウザ標準で、ページ自身がツールサーバーの役割を果たします。ツール定義の形式はMCPの型を踏襲しているため、エージェント側はMCPサーバーと同じ感覚で扱えます。

関連記事