xshoji's blog

10 min read

WebMCP は「 AI に Web UI を中抜きさせない」 ための規格なのか

#WebMCP #MCP #AI エージェント #Cloudflare

目次

はじめに

Cloudflare が「 Give any website a WebMCP interface 」という記事を公開した。

WebMCP を有効にすると、 Cloudflare が HTML へ bridge script を挿入し、ブラウザ内の AI エージェントが利用できる Tool をページへ登録するという。 サイトのオリジン側には変更が要らない。

Give any website a WebMCP interface
https://blog.cloudflare.com/webmcp/
─
Today we are launching a developer preview of WebMCP on Cloudflare. Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin. Cloudflare adds a small bridge to your pages, which registers a set of tools for a visitor’s agent to use.
本日、 Cloudflare における WebMCP の Developer Preview を開始します。有効にすると、コードやオリジン側の変更なしに、ブラウザエージェントがサイトを操作できるようになります。 Cloudflare はページへ小さな bridge を追加し、訪問者のエージェントが利用する Tool 群を登録します。

最初は、 AI エージェントが Web サイトを効率よく操作するための API だと理解した。 画面を見てボタンを探す代わりに、ページが操作可能な機能を構造化された Tool として渡す。 それならエージェントの操作は速く、安定する。

ただ、調べるうちに別の疑問が生じた。 AI エージェントが DOM や Accessibility Tree から画面を理解できるなら、サイト側が追加実装してまで Tool を用意する必要はあるのだろうか。

WebMCP の公式 README には、その疑問を操作精度だけでは説明できない一節がある。

Prevent web content disintermediation

WebMCP は、 AI エージェントに Web を「中抜き」させないための規格でもあるのだろうか。

WebMCP ではサイトが可能な操作を宣言する

現在のブラウザエージェントは、スクリーンショット、 DOM 、 Accessibility Tree などから画面の構造を読み取り、ユーザーの目的に合う操作を推論できる。 「商品をカートへ追加する」という目的に対して、エージェントが該当するボタンを探してクリックする方式である。

WebMCP では責任の置き場所が変わる。 Web アプリは、自然言語の説明と入力 Schema を持つ Tool を document.modelContext へ登録する。 エージェントは人間向け UI から操作方法を推測する代わりに、サイトが公開した Tool を呼び出せる。

await document.modelContext.registerTool({
  name: "search_products",
  description: " 条件に一致する商品を検索する ",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string" }
    },
    required: ["query"]
  },
  execute: async ({ query }) => searchProducts(query)
});

WebMCP の仕様は、この API を「 Web アプリケーションが JavaScript ベースの Tool を AI エージェントへ提供するもの」と説明している。

WebMCP
https://webmachinelearning.github.io/webmcp/
─
The WebMCP API enables web applications to provide JavaScript-based tools to AI agents.
WebMCP API は、 Web アプリケーションが JavaScript ベースの Tool を AI エージェントへ提供できるようにします。

Chrome の公式ドキュメントも、サイト側が推奨する操作方法を定義できる点を利点として挙げる。 操作対象を見つけられることと、サイトが意図した操作を選べることは同じではない。

When to use WebMCP and MCP
https://developer.chrome.com/docs/ai/webmcp/compare-mcp
─
You’re in control: You clearly define the preferred way for an agent to interact with your site, instead of hoping the agent finds the right button to click. You define your application’s logic in a way the agent can understand, guiding them directly rather than hoping they infer actions from the UI.
制御するのはサイト側です。エージェントが正しいボタンを見つけることに期待する代わりに、エージェントがサイトとやり取りする望ましい方法を明示できます。エージェントが理解できる形でアプリケーションのロジックを定義し、 UI から操作を推論することに期待せず直接導けます。

Accessibility Tree が画面を理解するための情報を与えるのに対して、 WebMCP はサイトが実行可能な操作とその境界を示す。 エージェントだけを賢くするのではなく、サイト自身をエージェントとの接点にする設計である。

WebMCP 仕様の公開主体と Editors

この設計意図を読む前に、仕様文書の位置づけを確認しておきたい。

WebMCP の仕様文書は、 W3C の Web Machine Learning Community Group による Draft Community Group Report として公開されている。 Editors には、 Microsoft 所属の Brandon Walderman と、 Google 所属の Khushal Sagar 、 Dominic Farolino が名を連ねる。 Microsoft は Edge 、 Google は Chrome を提供しており、ブラウザを提供する企業のメンバーが仕様編集に参加していることになる。

WebMCP
https://webmachinelearning.github.io/webmcp/
─
Draft Community Group Report, 28 July 2026
Editors:
Brandon Walderman (Microsoft)
Khushal Sagar (Google)
Dominic Farolino (Google)

ただし、これは W3C Standard ではなく、 W3C Standards Track 上の文書でもない。 複数企業の所属者が参加する公開仕様ではあるが、現時点では策定中の提案として捉えるのが正確である。

WebMCP
https://webmachinelearning.github.io/webmcp/
─
This specification was published by the Web Machine Learning Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
この仕様は Web Machine Learning Community Group によって公開されました。 W3C 標準ではなく、 W3C 標準化プロセス上の文書でもありません。

公式 README が挙げる UI の中抜き

WebMCP の公式 README は、外部 Tool を AI プラットフォームへ接続する方法として、 MCP や OpenAPI を使った バックエンド連携 を挙げている。 この方式では、 AI プラットフォームがサービスのバックエンド API と直接通信する。

バックエンド連携は、サーバー側の処理をエージェントへ提供する用途に適している。 一方、 README はその課題の一つを UI Disintermediation & Context Loss と呼ぶ。

webmachinelearning/webmcp README
https://github.com/webmachinelearning/webmcp/blob/main/README.md
─
UI Disintermediation & Context Loss: Backend integrations take place directly between the agent and the service, bypassing the service’s web UI / browser experience.
UI の非仲介化とコンテキストの喪失：バックエンド連携ではエージェントとサービスが直接通信し、サービスの Web UI やブラウザ体験を迂回します。

ユーザーが AI プラットフォームへ依頼し、 AI プラットフォームが MCP Server を呼び出す構成では、 Web ページが処理に関与しない。 現在表示している内容や UI の状態を使うには、その情報をバックエンド側へ別途渡す必要がある。 認証状態についても、ブラウザとは別の経路を用意しなければならない場合がある。

User
  ↓
AI Platform
  ↓ MCP / API
Service Backend

Web UI は処理の外にある

WebMCP が想定する配置は異なる。 ページが Tool を登録し、その Tool が既存のクライアント側ロジックや DOM を操作する。 ユーザー、エージェント、 Web アプリは同じブラウザタブにいる。

User
  ↓
Browser + Agent
  ↓
┌──────── Web App ────────┐
│ Human UI      WebMCP    │
│    │             │      │
│    └── 共有状態 ─┘       │
└─────────────────────────┘

この配置は、 Web UI を残すこと自体を Goal に含んでいる。 README には、フロントエンドを置き換えるのではなくエージェント向けに適応させることで、バックエンド連携による Web アプリの disintermediation を防ぐと明記されている。

webmachinelearning/webmcp README
https://github.com/webmachinelearning/webmcp/blob/main/README.md
─
Prevent web content disintermediation: Prevent disintermediation of web apps by backend integrations by adapting front-ends for use by agents, rather than replacing them.
Web コンテンツの非仲介化を防ぐ：フロントエンドを置き換えるのではなく、エージェント向けに適応させることで、バックエンド連携による Web アプリの非仲介化を防ぎます。

また、このバックエンドとエージェントの直結によって Web UI が迂回される問題は、複数ある公式 Goals の一つである。

WebMCP が残すのは画面だけではない

Web UI を処理の中に残すと、ユーザーが見ている画面とエージェントの作業を分断せずに済む。

公式 README は、 WebMCP の Goal として human-in-the-loop なワークフローを挙げている。 ユーザーがエージェントへ作業を委譲しながら、 Web ページ上の可視性、履歴、制御を維持する構成である。

webmachinelearning/webmcp README
https://github.com/webmachinelearning/webmcp/blob/main/README.md
─
Enable human-in-the-loop workflows: Support cooperative scenarios where users delegate tasks to AI agents while maintaining visibility, history, and control over web pages.
human-in-the-loop なワークフローを可能にする：ユーザーが Web ページ上の可視性、履歴、制御を維持しながら、 AI エージェントへ作業を委譲する協働シナリオを支援します。

Chrome の公式ドキュメントは、 MCP と WebMCP の違いを「誰が UI を所有するか」という問いで説明している。 WebMCP では、エージェントの画面内へサービスを組み込むのではなく、エージェントが既存の Web サイトを訪れる。

When to use WebMCP and MCP
https://developer.chrome.com/docs/ai/webmcp/compare-mcp
─
Instead of your application being a guest within an agent, the agent is a guest on your platform.
アプリケーションがエージェント内のゲストになるのではなく、エージェントがサイト側のプラットフォームを訪れるゲストになります。

この違いは、単なる実行場所の差ではない。 サイトはユーザーがログインしているセッションと現在のページ状態を保ち、 Tool を通じてエージェントに望ましい操作方法を示せる。 ユーザーも、エージェントの操作を同じ Web UI 上で確認し、必要なら手を入れられる。

ここから先は公式文書に直接書かれていない解釈になる。

AI プラットフォームが検索、比較、意思決定、購入までを引き受け、サービスがバックエンド処理だけを提供するようになれば、ユーザーとの接点は AI プラットフォーム側へ集まる。 サービスが Web UI で提供してきたブランド表現、レコメンド、関連情報の提示も、ユーザーから見えにくくなる可能性がある。

WebMCP は、その変化を技術的に禁止する規格ではない。 それでも、エージェントを既存の Web アプリへ参加させ、サイト側が操作方法とユーザー体験を設計する余地を残す。 その意味では、サービスとユーザーの接点を Web 上に保つための選択肢になり得る。

サイト側が実装しなければ Tool は生まれない

WebMCP には、普及を考えるうえで分かりやすい負担がある。 サイト側が対応しなければ、エージェントへ公開する Tool は存在しない。

開発者は少なくとも次の設計を担う。

  • エージェントへ公開する操作を選ぶ
  • Tool の名前、説明、入力 Schema を定義する
  • Tool を既存のアプリケーションロジックへ接続する
  • 購入や削除など、人間の確認を必要とする境界を決める
  • UI と Tool の状態を同期する
  • 仕様の変更へ追従する

Accessibility Tree を使った操作では、エージェントが既存 UI から可能な操作を推論するため、サイト側に WebMCP 専用の実装を求めない。 WebMCP はサイト側へ制御を戻す代わりに、サイト側の明示的な参加を必要とする。

中抜きを避けることが参加する動機になったとしても、実装コストは消えない。 Cloudflare の記事も、 Tool の設計、 UI への接続、変化する標準への追従を手作業で行うのは一つの小規模プロジェクトになると認めている。

Give any website a WebMCP interface
https://blog.cloudflare.com/webmcp/
─
Implementing WebMCP by hand is a small project: design the tools to expose, wire them into your interface, and keep them working as the standard evolves.
WebMCP を手作業で実装するのは、小規模なプロジェクトです。公開する Tool を設計し、インターフェースへ接続し、標準の進展に合わせて動作を維持する必要があります。

Cloudflare は WebMCP の共通処理をエッジへ移した

Cloudflare の Developer Preview は、この実装負担をすべて自動化するものではない。 共通化できる部分を、サイト本体から Cloudflare のエッジへ移す機能である。

利用者が Dashboard で WebMCP を有効にすると、 Cloudflare は HTMLRewriter を使い、 HTML レスポンスへ bridge script を読み込む一行を挿入する。

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

bridge は指定された Tool Pack を読み込み、各 Tool を document.modelContext.registerTool() で登録する。 Developer Preview で提供されるのは、画像の C2PA メタデータを扱う Content Credentials Pack と、サイト自身の MCP Server へ接続する Site MCP Server Pack である。

後者の構成が興味深い。 Site MCP Server Pack は、サイトの MCP Server から tools/list で Tool を取得し、ページ上の WebMCP Tool として登録する。 Tool が実行されると、 bridge は同一オリジンの MCP エンドポイントへ、ユーザーの既存セッションを使って tools/call を送る。

Browser Agent
      ↓
WebMCP Bridge
      ↓ 同一オリジン、既存セッション
Site MCP Server

Give any website a WebMCP interface
https://blog.cloudflare.com/webmcp/
─
The Site MCP Server pack talks straight to your MCP server endpoint from the page, on the visitor’s origin and with their existing session.
Site MCP Server Pack は、訪問者のオリジンと既存セッションを使い、ページからサイトの MCP Server エンドポイントへ直接通信します。

MCP と WebMCP は、どちらか一方を選ぶ競合規格ではない。 Chrome の公式ドキュメントも、 WebMCP は MCP の拡張でも代替でもなく、両者は異なる用途を扱うと説明している。

Cloudflare の bridge も、バックエンドの MCP Tool を捨てて WebMCP へ作り直すのではない。 既存の Tool を、ユーザーがサイトを開いているブラウザの文脈から利用できるように接続する。

When to use WebMCP and MCP
https://developer.chrome.com/docs/ai/webmcp/compare-mcp
─
You don’t have to choose between MCP and WebMCP to create an agentic experience. WebMCP is not an extension or a replacement of MCP.
エージェント向け体験を作るために、 MCP と WebMCP のどちらかを選ぶ必要はありません。 WebMCP は MCP の拡張でも代替でもありません。

ただし、 Cloudflare を有効にすれば、既存サイトの操作が自動的に Tool へ変換されるわけではない。 既製 Pack 以外のサービス固有機能については、公開する Tool の設計と実装、または既存 MCP Server の用意が必要である。

Cloudflare が引き受けるのは、 bridge の配信、 WebMCP への Tool 登録、既製 Tool Pack の提供、既存 MCP Server との接続である。 WebMCP 対応を不要にしたのではなく、サイトごとに繰り返していた共通処理をインフラ側へ移した。

まとめ

WebMCP は、 AI エージェントの操作を速く安定させるためだけの API ではなかった。 公式 README は、バックエンド連携が Web UI やブラウザ体験を迂回する問題を UI Disintermediation & Context Loss と呼び、その防止を Goal の一つに掲げている。

ここでいう「中抜き」は、広告収益や企業価値までを直接指す言葉ではない。 仕様が扱っているのは、エージェントとサービスのバックエンドが直接通信することで、 Web アプリがユーザーとエージェントのあいだから外れる問題である。

WebMCP はバックエンド連携を禁止せず、 MCP を置き換えもしない。 エージェントを既存の Web アプリへ参加させ、ユーザー、 Web UI 、エージェントが状態と制御を共有する別の選択肢を作る。

そして Cloudflare は、その選択肢をサイトごとの個別実装からインフラ機能へ近づけようとしている。 まだサービス固有の Tool 設計は残るものの、 bridge の配信と既存 MCP Server への接続はエッジへ移せる。

AI エージェントが Web を迂回する未来を WebMCP が止められるわけではない。 それでも、エージェントに Web を推測させるだけでなく、サイト自身がエージェントとの接点を設計する道は残る。 Cloudflare の発表は、その道を「仕様を読んで個別実装するもの」から「 Web 基盤で有効にするもの」へ変える一歩に見える。