WebMCP とは何か — Cloudflare が「スイッチひとつでサイトをエージェント対応にする」開発者プレビューを公開

2026年8月6日（米国時間）、Cloudflare が「Give any website a WebMCP interface」と題したブログ記事を公開しました（執筆: Will Rowe 氏）。同社が「Agents Week」と位置づける発表週の一つで、ダッシュボードのスイッチを切り替えるだけで、コード変更なしにサイトへ WebMCP のツール群を追加できる開発者プレビューです。弊社のサイトも Cloudflare 上で運用しているため、発表の内容と、その前提となる WebMCP という標準提案の現在地を、公式資料に基づいて整理しておきます。

背景 — 人間を前提に作られたウェブと、人間ではない訪問者

Cloudflare の記事は、今回の機能の動機を次のように述べています。

The web was built on the assumption that there is a person on the other end: someone to read the page, click buttons, and fill in the forms. But now more and more visits come from AI agents instead, to an Internet made for humans.

（ウェブは、向こう側に人間がいるという前提で築かれてきました。ページを読み、ボタンをクリックし、フォームに記入する誰かがいる、と。しかし今では、人間のために作られたインターネットへの訪問が、AI エージェントによるものへと次第に置き換わりつつあります）

これまでの主流はクローラーでした。コンテンツをサーバー側へ複製して利用する方式で、Cloudflare は「元のサイトにトラフィックをまったく返さず、クレジットもほとんど与えないことが多すぎる」と指摘し、「スクレイピングを伴わない、より良い方法がある」と続けます。AI に参照される側のサイトとクローラーの関係については、以前の記事で各社の公式ドキュメントを確認しました。今回の発表は、その関係を「複製されるのを待つ」から「訪問してきたエージェントに道具を渡す」へ転換する試みの一つと位置づけられます。

WebMCP とは — ページがエージェントに「道具」を渡すためのブラウザ標準の提案

WebMCP は、ウェブページが AI エージェント向けに構造化されたツール（関数と入力スキーマの組）を公開できるようにするブラウザ API の提案です。W3C の Web Machine Learning Community Group が仕様ドラフトを公開しており、2026年7月28日版のドラフトでは、各 Document オブジェクトに ModelContext が関連づけられ、ページは document.modelContext.registerTool() でツールを登録すると定義されています。登録には name（識別子）・description（自然言語の説明）・execute（実行される関数）が必須で、任意で JSON スキーマによる inputSchema や、読み取り専用であることを示す readOnlyHint などの注釈を付けられます。

注意が必要なのは標準化の段階です。ドラフト自身が明記するとおり、これは Community Group の作業文書であって W3C 標準ではなく、標準化トラックにも載っていません。ブラウザ側の実装も実験段階で、Chrome の公式ドキュメント（2026年6月9日更新版）によれば、ローカル開発用のフラグ chrome://flags/#enable-webmcp-testing で有効化でき、Chrome 149 以降ではオリジントライアルが提供されています。Cloudflare の記事は「Chrome 146 で実験的に出荷が始まった」と表現しています。いずれにせよ、一般の訪問者のブラウザで既定で動く状態には、本稿執筆時点では至っていません。

WebMCP という名前のとおり、基盤にあるのは Model Context Protocol（MCP）です。MCP はアプリケーションと AI モデルの間でツールやコンテキストをやり取りするためのオープンなプロトコルで、通常はサーバーとして実装されます。WebMCP はそのツールの概念をブラウザ内のページに持ち込むもので、Cloudflare の実装も MCP 仕様の Tool と CallToolResult という型をそのまま使っています。記事は次のように要約しています。

To an agent, all of these are ordinary MCP tools. We use Model Context Protocol’s own Tool and CallToolResult types, so an agent that already talks to MCP servers can drive a page with nothing special added. The browser is just another place MCP runs.

（エージェントから見れば、これらはすべて通常の MCP ツールです。Model Context Protocol 自身の Tool と CallToolResult の型を使っているため、すでに MCP サーバーと通信できるエージェントは、何も特別なものを追加せずにページを操作できます。ブラウザは、MCP が動くもうひとつの場所にすぎません）

エージェントにとっての利点は、人間向けに設計された画面を「推測しながら」操作しなくてよくなることです。ボタンの位置を探し、フォームの意味を画面から読み取る代わりに、スキーマつきの関数を呼べばよいため、トークンをナビゲーションではなくタスクそのものに使える、と Cloudflare は説明しています。ただし従来は、そのためにサイト側が WebMCP を自前で実装する必要がありました。今回の発表は、その実装の手間をエッジ側で肩代わりするものです。

Cloudflare の実装 — エッジでの1行注入と、ページ内で動くブリッジ

Cloudflare の実装は2つの部品からなり、どちらもオリジン（サイト本体）の手前で完結します。サイトのコードには一切手を入れず、静的サイトでもシングルページアプリでも同じように動くとされています。

第一の部品はエッジでの注入です。ダッシュボードで WebMCP を有効にすると、HTMLRewriter（Cloudflare のエッジで動く HTML 書き換え機構）がすべての HTML レスポンスに次の1行を追加します。スクリプトタグもスクリプト本体も同一オリジンのエッジから配信され、それ以外のページ内容は変わりません。

<!-- Cloudflare injects this at the edge. Same origin, and your HTML is otherwise untouched. -->
<script type="module"
        src="/.webmcp/bridge.js"
        data-packs="c2pa,mcp-server-client"
        data-mcp-url="/mcp"></script>

第二の部品が、この bridge.js（ブリッジ）です。ページ内で実行され、まずブラウザに WebMCP のインターフェースがあるかを確認します。なければ何もせずに終了するため、対応していないブラウザではページは従来どおりに振る舞います。インターフェースがあれば、data-packs 属性に列挙された「ツールパック」を1つのツール一覧に合成し、それぞれを registerTool で登録します。

ツールパックとは、MCP のツール記述子とその処理をまとめた単位です。パックは今後追加され、サイト側は再デプロイなしにトグルで追加分を有効化できる設計とされています。今回のプレビューには2つのパックが含まれ、いずれも訪問者のブラウザ内だけで完結します（Cloudflare のサーバーへの往復はありません）。

図1: ダッシュボードの Agent Readiness > Labs にある WebMCP の設定画面。ツールパック単位で有効化できる（出典: The Cloudflare Blog）

Site MCP Server パック — 既存の MCP サーバーをページ経由で使えるようにする

サイトがすでに自前の MCP サーバーを持っている場合、このパックが起動時に tools/list でツール一覧を取得し、各ツールの「代理（プロキシ）」をページに登録します。エージェントが代理ツールを呼ぶと、ページから同一オリジンの MCP エンドポイントへ、訪問者自身のセッションで tools/call が送られます。

// For each tool the site's own MCP server advertises (via tools/list),
// registering a proxy whose execute() calls the site back on the
// visitor's origin, with their session.
document.modelContext.registerTool({
  name: tool.name,                 // e.g. "search_products"
  description: tool.description,
  inputSchema: tool.inputSchema,   // taken straight from tools/list
  execute: async (args) => {
    const res = await fetch(mcpUrl, {   // same-origin /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;   // an MCP CallToolResult, passed straight through
  },
});

credentials: "same-origin" の指定が示すとおり、呼び出しは訪問者のブラウザに既にあるセッション（ログイン状態）で実行されます。リモートの MCP サーバーに別途認証を組み込むのではなく、「その人がブラウザでできること」の範囲でエージェントに実行させる構図です。

Content Credentials パック — 画像の来歴メタデータを読む

もう一つのパックは、コンテンツ来歴の業界標準である C2PA（Coalition for Content Provenance and Authenticity）のメタデータを読み取ります。scan_images_c2pa はページ内の全画像を走査して要約を返し、inspect_image_c2pa は1枚の画像のマニフェスト（編集履歴・作者表示・署名証明書）を展開します。画像本体ではなく先頭数キロバイトのメタデータだけを読む TypeScript 実装で、これも訪問者のブラウザ内で完結します。

{
  "imageCount": 12,
  "scanned": 12,
  "withC2pa": 8,
  "results": [
    {
      "src": "https://example.com/hero.jpg",
      "hasC2pa": true,
      "format": "image/jpeg",
      "manifestCount": 1,
      "claimGenerator": "Adobe Firefly",
      "title": "sunrise over the bay",
      "signedBy": "Adobe Inc."
    },
    { "src": "https://example.com/logo.png", "hasC2pa": false, "format": "image/png" }
  ]
}

重要な限定があります。現時点のこのパックは資格情報を「読んで報告する」だけで、暗号学的な検証は行いません。結果には常に signatureVerified: false が付き、復号された主張を検証済みの事実とエージェントが取り違えないようにしてあります。来歴表示が偽造されていないかの確認は、この段階では提供されていません。

位置づけと留意点

発表を確認した範囲で、把握しておくべき点を挙げます。

• 標準はまだ提案段階です。 WebMCP の仕様は W3C の Community Group ドラフトであり、標準化トラック外です。API の形（document.modelContext の位置づけを含む）は今後も変わりえます
• 動くのは実験的な環境に限られます。 Chrome ではフラグまたはオリジントライアル（Chrome 149 以降）が必要で、一般の訪問者のブラウザでは、ブリッジは何もせずに終了します。現時点で実害も実益も一般訪問者には及ばない一方、効果を確かめるには対応環境が必要です。Cloudflare は自社のリモートブラウザ BrowserRun が WebMCP のツールを発見・呼び出しできるとしており、確認手段として案内しています
• エージェントは訪問者のセッションで動きます。 Site MCP Server パックの呼び出しは訪問者のログイン状態を引き継ぎます。エージェントにどの操作を許すかは、ツールとして何を公開するかというサイト側の設計問題になります。仕様ドラフト側にも、読み取り専用を示す readOnlyHint や、信頼できないコンテンツ由来であることを示す untrustedContentHint といった注釈が用意されており、安全性の設計は仕様・実装の双方でまだ発展途上です
• C2PA の読み取りは検証ではありません。 前述のとおり signatureVerified: false が常に付きます
• 導入自体は1トグルです。 ダッシュボードの Agent Readiness > Labs で有効化し、curl -s https://your-site.example | grep webmcp で注入された1行を確認できます

なお、弊社サイトでは本稿の時点で有効化していません。ブログという静的コンテンツ主体のサイトでは、そもそもエージェントに公開すべき「ツール」が何かという設計から考える必要があり、標準と実装の成熟を見ながら判断する予定です。

まとめ

• 2026年8月6日、Cloudflare が WebMCP の開発者プレビューを発表しました。ダッシュボードのトグルだけで、コード変更なしにサイトへエージェント向けツールを追加できます
• WebMCP は、ページが document.modelContext.registerTool() で AI エージェントに構造化ツールを渡せるようにするブラウザ標準の提案です。W3C の Web Machine Learning Community Group のドラフト段階で、Chrome ではフラグまたはオリジントライアルでのみ動作します
• 実装はエッジでの <script> 1行の注入と、ページ内で動くブリッジの2部構成です。非対応ブラウザでは何も起きず、ページは従来どおり表示されます
• プレビューには2つのツールパックが含まれます。Site MCP Server は既存の MCP サーバーのツールを訪問者のセッションでページから呼べるようにし、Content Credentials は画像の C2PA 来歴メタデータを読み取ります（暗号学的検証はまだ行われません）
• クローラーによる複製ではなく、訪問してきたエージェントにサイト側が道具を渡すという方向性の実装であり、標準・実装ともに発展途上の段階です

参考

• Give any website a WebMCP interface — The Cloudflare Blog（2026年8月6日、Will Rowe 氏） — 本記事の主たる出典。サムネイルおよび図1は同記事からの引用
• WebMCP — Draft Community Group Report（W3C Web Machine Learning Community Group、2026年7月28日版）
• webmachinelearning/webmcp — GitHub — 提案のリポジトリと explainer
• WebMCP | AI on Chrome — Chrome for Developers（2026年6月9日更新） — フラグとオリジントライアルの案内
• Model Context Protocol — MCP の仕様
• C2PA — Coalition for Content Provenance and Authenticity