AI が今ウェブを使う方法は、コンテンツのクロールとスクリーンショットによるボタン推測

ウェブページというものは、そもそも「画面の向こうに人間がいる」ことを前提に設計されています。人間は文字を読み、ボタンをクリックし、フォームに入力します。

今や訪問者の多くは AIエージェントです。彼らは、人間向けに作られたこれらのページをどう使うのでしょうか？ 現状は主に2つの方法しかなく、どちらもあまり良い方法とは言えません。

1つ目はクロールです。 エージェントがページ全体を自社のサーバーにコピーして解析します。この方法はサイト運営者にとって最もつらい方法です。コンテンツは持ち去られるのに、トラフィックは残らず、クレジット表記もありません。

一般的な方法はクローラーで、コンテンツをサーバーにコピーすることです。そして多くの場合、元のサイトにはトラフィックもクレジットもほとんど残りません。もっと良い方法があります。それはクロールを必要としない方法です。

Cloudflare ブログ · Give any website a WebMCP interface

2つ目はスクリーンショット → 分析 → クリックです。 エージェントは人間のように画面を見ます。スクリーンショットを撮り、モデルにそれがどんな画面で検索ボックスがどこにあるかを分析させ、クリックし、またスクリーンショットを撮り、また分析する。遅く、壊れやすく、そして消費するトークンの大半は「道を見つける」ことに使われ、「タスクを実行する」ことにはほとんど使われません。ページがリニューアルされると、この一連の流れ全体が使えなくなります。

WebMCP が目指すのは3つ目の道です。ウェブサイトがエージェントに「私には直接呼び出せるツールがこれだけあります」と自ら伝えることです。例えば「フライトを検索」「航空券を予約」といった具合に、各パラメータの型も明確に記載されています。エージェントは推測する必要がなく、直接呼び出せます。

WebMCP はサイトが実行可能なタスクをツールとして公開し、AI がそれに従って呼び出す

まず、その立ち位置を明確にしましょう。WebMCP はブラウザ標準の提案であり、W3C のコミュニティグループで検討中で、まだ正式な標準にはなっていません。Chrome 側のステータスも本日時点では「Proposed」（提案中）とされています。

これはウェブページ内では document.modelContext というインターフェースとして実装されます。ウェブサイトはこのインターフェースにツールを登録し、ブラウザ内のエージェントがそれを参照・呼び出せるようにします。

ツールの登録方法は2通りあり、ハードルはかなり異なります。

1つは JavaScript を書く方法で、registerTool() を呼び出し、ツールの名前、説明、パラメータ構造、実行ロジックを明確に記述します。複雑なインタラクションはこの方法でしか実現できません。

もう1つはもっと簡単で、既存の HTML フォームにいくつか属性を追加するだけです。 予約フォームに toolname（このツールの名前）、tooldescription（何をするツールか）を追加し、各入力欄に toolparamdescription（この欄に何を入力するか）を追加するだけで、ブラウザが自動的にそれをエージェントが呼び出せるツールに変換し、パラメータの説明書まで自動生成してくれます。

ツールはページに応じて変化、支払い前は人の確認を待つ

インターフェース定義を見ただけでは、実際の使用感はわかりません。Cloudflare のリモートブラウザドキュメントには、Google 公式のホテル予約デモを使った実践記録が掲載されており、2つの点が予想外でした。

1つ目は、ツールが固定されていないことです。 ページを開いた直後は3つだけです。「ホテル詳細を見る」「場所で検索」「設備・ポリシーを調べる」。次に「場所で検索」で「Paris」を検索すると、ページは検索結果に移動し、その時点で初めて「検索結果を絞り込む」という新しいツールが追加されます。ツールはページの状態に応じて変化します。

2つ目は、機密性の高い操作ではエージェントが停止することです。 「予約を完了する」というツールを呼び出しても、すぐには成立しません。ブラウザで「予約を確定」というボタンをクリックするまで、そこで停止します。これは標準に組み込まれた人間による確認メカニズムです。

Cloudflare の方法：ページ送信の途中にスクリプトを1行挿入

標準仕様の説明は以上です。Cloudflare の今回の対応に戻りましょう。その実装は2つの部分に分かれており、どちらもオリジンサーバーの前段で行われ、あなたのコードは一字も変更する必要がありません。静的サイトでも SPA でも、効果は同じです。

パート1：エッジでスクリプトを1行挿入

ダッシュボードでスイッチをオンにすると、Cloudflare のサーバーから訪問者に送信される前に、あなたのすべての HTML ページに次の1行が追加されます。

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

この作業を行うツールは HTMLRewriter と呼ばれ、Cloudflare がページ送信の途中で HTML を書き換えるものです。オリジンサーバーはそのことを知る由もなく、連携も不要です。

パート2：橋渡し役の bridge.js

これはページ内で実行され、最初にブラウザに WebMCP インターフェースがあるかどうかを確認します。なければそのまま戻り、何もしません。ページはこれまで通りです。あれば、data-packs に列挙されたパックを1つのツールリストにまとめ、一つずつ登録していきます。

標準で2つの機能パック：画像の出所確認と、自前 MCP サーバーの呼び出し

ツールは「パック」単位で提供されます。関連するツール群が1つにまとめられ、一緒にオン・オフされます。プレビュー版では2つのパックが提供されており、どちらも完全に訪問者のブラウザ内で動作し、Cloudflare のサーバーを経由しません。今後新しいパックが追加された場合、サイトはダッシュボードでチェックを入れるだけで利用でき、再デプロイは不要です。

パック1：ページ上の画像の作成者を確認

このパックは、画像内の C2PA 情報を読み取ります。これは画像に「出自証明書」を記録するための業界標準で、この画像が誰に生成されたか、AI によるものか、その後誰が編集したかが、画像ファイルの先頭部分のメタデータに記録されています。

このパックには2つのツールがあります。scan_images_c2pa はページ全体の画像をスキャンし、要約を返します。Cloudflare が示したサンプル出力は、ページ全体で12枚の画像をすべてスキャンし、うち8枚に C2PA 情報が含まれているというものです。各画像の出所がリスト表示され、例えば hero.jpg の生成元は Adobe Firefly、署名者は Adobe Inc. といった具合です。もう1つの inspect_image_c2pa は単一の画像を深く調査し、完全なアーカイブ（編集履歴、主張された作者、署名証明書）を解読します。

技術的には、これは純粋な TypeScript 製のリーダーで、画像先頭の数 KB のメタデータのみを参照し、画像全体をダウンロードしません。

パック2：自前の MCP サーバーをページに組み込む

あなたのサイトに既に MCP サーバーがある場合（ここ1、2年で多くの企業が構築済みです）、このパックはまず /mcp に「どんなツールがありますか」と問い合わせ、リストを取得した後、既存の各ツールをそのままプロキシとしてページに登録します。名前、説明、パラメータ仕様書もそのまま引き継がれます。

これが2つのパックの違いです。画像確認パックのツールは事前にハードコードで定義されていますが、このパックのツールは問い合わせて初めて判明します。

document.modelContext.registerTool({
  name: tool.name,                 // 例: "search_products"
  description: tool.description,
  inputSchema: tool.inputSchema,   // パラメータ仕様書をそのまま使用
  execute: async (args) => {
    const res = await fetch(mcpUrl, {   // 同一ドメインの /mcp
      method: "POST",
      credentials: "same-origin",       // ← 訪問者の現在のログイン状態を使用
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0", id: 1, method: "tools/call",
        params: { name: tool.name, arguments: args },
      }),
    });
    const { result } = await res.json();
    return result;   // 結果をそのまま返す
  },
});

エージェントにとって、これらはすべてごく普通の MCP ツールです。Cloudflare は MCP プロトコル自身のデータ型を使用しているため、通常 MCP サーバーと連携するエージェントは、何も追加せずにウェブページを操作できます。

そして、今後の方向性を示す一文もあります。bridge のコードは Cloudflare エッジ上の Worker が配信しており、これは将来のために余白を残しています。将来的には、この Worker がページ単体ではできない処理（Workers AI を使ったサイトマップ全体の要約や、AI Search インデックスの参照など）を実行できるようになるでしょう。

このスイッチはどこでオンにし、どう確認するか

ダッシュボードのパス：Cloudflare Dashboard → Agent Readiness → Labs（Beta マーク付き）。この Labs ページの自己紹介は「実験的で、自分で有効化する機能。あなたのサイトと AIエージェントの連携をより良くする」というものです。

ダッシュボードの実際の表示：上部にメインスイッチ、下部に2つの機能パックのチェックボックスがあり、デフォルトで両方オンになっています。どちらもオフにするとデフォルトセットと同じ動作になります。画像は Cloudflare ブログより。

実際に有効になったことを確認するには、1つのコマンドで、あなたのサイトの任意のページを取得し、その挿入行があるかどうかを確認します。

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

ツールが実際に呼び出せることを確認したい場合、自分でエージェントを作る必要はありません。Browser Run（Cloudflare のクラウド上のリモートブラウザ）をあなたの URL に向けるだけで、訪問者のエージェントと同様に、ツールを発見し、呼び出してみることができます。ただし、前提条件があります。WebMCP は現在 Chrome のテスト版でのみ利用可能なため、専用の実験セッションを開始する必要があります。

実測：今日の最新版 Chrome は WebMCP をサポートしていません

有効化はできましたが、訪問者側は現在実際に認識できるのでしょうか？ この点についての説明は更新が必要です。

Cloudflare のブログには WebMCP が「Chrome 146 で実験的にリリースされている」と書かれています。この表現はすでに古くなっています。Chrome 公式ドキュメントによると、WebMCP の公開試用期（origin trial）はChrome 149 から開始され、サイトが Google に登録すれば、実際のユーザーに対してこの機能を有効化できます。自分の PC でスイッチを切り替えて試すだけではなくなります。そして今日、Chrome 安定版はすでに 151 です。

では、実際に使えるのでしょうか？ 私はローカル環境でテストしました。テストページには Chrome が要求する隔離レスポンスヘッダーが含まれており、インターフェースが利用可能な前提条件を満たしています。

これはこの機能が役に立たないという意味ではありません。「開発者プレビュー」とはそもそもそういうものです。現在の価値は「ゼロコストでサイトを先に準備しておける」ということであり、「今日オンにすれば明日にはエージェントが来る」ということではありません。Chrome がこの機能のために登録している目標リリースバージョンは 157 で、ステータスは依然として「提案中」です。

ちなみに、Cloudflare 自身も確認しました。同社のブログ、公式サイト、Radar の3つのサイトは、現在この機能を有効化していません。Radar の自前 WebMCP ツールもまだリリースされておらず、発表時点では「もうすぐ」とされていました。

Chrome 公式が挙げる3つの制限：ページが開いていなければ呼び出せない

標準仕様自体にも、いくつかのハードな制限があります。Chrome 公式ドキュメントの「制限」セクションに記載されています。これはこの標準を作っている人々自身が挙げたものであり、どのサードパーティの評論よりも重みがあります。

さらに2つのセキュリティ上の制約があります。WebMCP はソース分離されたページでのみ利用可能です（サイトがこの分離を無効にすると、インターフェースは即座に無効になります）。ツールの登録にはパーミッションポリシーも関わり、デフォルトではトップレベルのページと同一オリジンのページのみが登録を許可され、クロスオリジンの iframe はデフォルトで禁止されています。ツールの登録を許可する場合は、個別に許可する必要があります。

冒頭の質問に戻りましょう。このスイッチは今オンにする価値があるでしょうか？ オンにするコストはゼロです。クリックするだけで、オリジンは変更されず、ブラウザが対応していなければ静かにスキップされます。したがって、考えるべきは別の質問です。オンにした後、その2つの汎用パック以外に、接続できる自前の MCP サーバーを持っていますか？ エージェントが本当にユーザーに代わってあなたのサイトでタスクを完了できるようにするのは、そのパックです。画像証明書スキャナーはおまけです。

WebMCP 自体はまだ孵化中のブラウザ標準であり、サイトが対応するには自らコードを書く必要があります。Cloudflare は今回、この部分を肩代わりしました。ダッシュボードでスイッチをオンにすれば、オリジンのコードは一行も変更不要。再デプロイも不要です。

スクリプトはページが送信される途中に挿入されます。ページが Cloudflare のエッジノードから訪問者に届く前に、1行の script が追加されます。このスクリプトはあなたのサイトと同じドメインです。スクリプトはまずブラウザに WebMCP インターフェースがあるかどうかを確認します。なければそのまま終了し、ページはこれまで通り。あれば、選択した機能パックをツールリストにまとめて AI に渡します。

プレビュー版には2つの機能パックが含まれており、どちらも訪問者のブラウザ内で動作し、Cloudflare のサーバーを経由しません。

もう1つのパックはより実用的です。既に MCP サーバーを持っているなら、このパックがその中のツールをそのままページにプロキシ登録します。名前、説明、パラメータもそのまま引き継がれます。

2026-08-07 に、ローカルの最新版 Chrome でテストしました。

今日このスイッチをオンにすると、スクリプトは確かにページに挿入されます。しかし、ほとんどの訪問者のブラウザにはこのインターフェースが存在せず、スクリプトはそれを検出できず、そのまま終了し、ページはこれまで通りです。実際にツールを利用できるのは、自分で実験スイッチをオンにしたブラウザと、テスト版 Chrome を実行するクラウド上のリモートブラウザです。