WebMCPとは｜Chrome 149・Edge 150で始まった仕様の現在地とSafariが反対する理由

WebMCPは、Webページが自分の持つ操作を「名前・自然言語の説明・入力スキーマ」つきのツールとしてAIエージェントに宣言できるようにする、ブラウザAPIの提案です。エージェントに画面を撮らせてボタンらしきものを推測させる代わりに、ページ側から呼べる関数を渡してしまう——という発想の転換が中心にあります。ただし2026-08-30時点でこれは合意された標準ではなく、期限つきの実験配信が2ブラウザで動いている段階です。

MCPサーバーそのものの仕組みや、自分でサーバーを書く場合の手順はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は「サーバーを立てる話ではなく、ページ側にツールを持たせる提案が今どこにいるか」を一次ソースで確かめます。

エージェントがWebアプリに届く経路と、WebMCPが埋める場所

エージェントがWebアプリの機能に到達する道筋は複数あり、WebMCPはそのうちの1本を新しく引こうとしています。ここを整理しないと「WebMCPがcomputer useを置き換える」といった雑な理解になりやすいので、先に並べておきます。

分類の軸を「インターフェースからの距離」ではなく誰がツールを宣言し、誰の権限で実行するかに取ると、経路の性質の違いがはっきりします。

仕様のREADME自身も、この対比を「バックエンド統合（backend integrations）」と「ブラウザ内のWebMCPツール」という2分法で説明しています。そこで挙げられているバックエンド統合の課題は3つで、エージェントとサービスが直接やり取りするためWeb UIと文脈が迂回されること、利用者の状態・ログイン情報を別サーバーに複製しなければならないこと、そしてクライアント側の機能を出すのに専用のバックエンドを書く必要があることです。WebMCPはこれをクライアント側で解こうとする提案、という位置づけになります。

つまりWebMCPが代替しようとしているのは画面を読む工程であって、MCPサーバーではありません。既存のMCPサーバー——たとえばChrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違いで扱ったような汎用のブラウザ操作ツール群——は、ページ側が何も宣言していない前提で動くための道具なので、役割が重なりません。

誰が提案したのか——MicrosoftとGoogleの2案が合流するまで

「MicrosoftのAPIなのかGoogleのAPIなのか」は、リポジトリのコミット履歴とPRの本文で決着します。結論は「ほぼ同時に別々に提案され、3週間後に統合された」です。

決定的なのは統合PR #3 の本文で、起票者（Microsoft の Brandon Walderman）自身がこう書いています——これは Microsoft の「Web Model Context」と Google の「Script Tools」の2つのexplainerを統合する最初の試みである、と。つまりどちらか一方の発案ではなく、独立した2案の合流です。日付でいえば Microsoft のほうが3日早いものの、実質的には同時期の並行提案と見るのが妥当です。

explainer の著者欄（2025-08-13 時点）は次の5名で、両社が名を連ねています。

・Brandon Walderman（Microsoft）／Andrew Nolan（Microsoft）
・David Bokan（Google）／Khushal Sagar（Google）／Hannah Van Opstal（Google）

したがって元投稿の「ChromeとEdgeの両チーム」という書き方は正確です。一方で「GoogleとMicrosoftが合意することは珍しい」という煽り方は評価であって事実ではないので、本記事では採りません。両社が共同で1本のexplainerを書いている——これが確認できる事実です。

そして「WebMCP」という名前自体は、どちらの社の発案でもありません。仕様のPrior Artセクションは、ブラウザのタブ／拡張機能間トランスポートを実装していた先行OSS MCP-B を挙げ、そこに既にWebMCPという呼称があったことを明記しています。統合PRの本文でも「MCP-Bの既存WebMCPをPrior Artとして追記した」と説明されています。

仕様の所在は WICG ではなく W3C の Web Machine Learning Community Group（w3c.json の repo-type は cg-report、グループID 110166）です。CGのレポートであり、W3Cの勧告トラックには乗っていません。

「WebMCP」という名前で3つの別物が出回っている

検索して最初に踏む地雷がこれです。「WebMCP」という名前は、関係の異なる3つのものに使われています。

②の MCP-B は自サイトで「MCP-B が WebMCP 仕様の着想につながった」と述べており、現在は @mcp-b/global をW3C WebMCP APIのポリフィルとして配布しています。Chrome 149未満でも試したい場合の現実的な選択肢はここです（ポリフィルなので挙動がネイティブ実装と一致する保証はありません）。

③の webmcp.dev は「WebMCP」で日本語検索したときのGoogle上位10件にも入ってきます。ページを開くと npx -y @jason.today/webmcp@latest --mcp をMCPクライアントに登録させる手順が並んでおり、ブラウザ標準の話だと思って読むと確実に混乱します。どれを読んでいるかは document.modelContext が出てくるかどうかで判別できます。

対応状況——Chrome 149・Edge 150のオリジントライアル

ここが一番誤読されやすい部分です。「ChromeとEdgeが対応した」という要約は、オリジントライアル（期間限定の実験配信）が始まったという意味であって、既定で使える機能になったという意味ではありません。

WebMCPのブラウザ対応状況は、仕様リポジトリの implementation-status.md に一次情報としてまとまっています。2026-08-30時点の内容は次の通りです。

投稿などでよく見る「ChromeとEdgeのチームによるAPI」という言い方は、この意味では裏が取れています。仕様の編集者にはMicrosoftのBrandon Walderman・Leo Lee・Andrew Nolan、GoogleのDavid Bokan・Khushal Sagar・Hannah Van Opstalが名を連ねており、実装側も両ブラウザでトライアルが動いています。ただしBraveとChatGPT Desktopも実装しており、「2社の話」で閉じてはいません。

Edgeの登録ページには試験期限が 2026-11-17 と明記され、あわせて「この機能は試験を超えて有効化されることは決してないかもしれない（Microsoftの独断による）」旨の注意書きが置かれています。採用を検討するなら、この一文が実務上いちばん重い情報です。

なお Chrome Platform Status の当該エントリ（feature 5117755740913664）は、2026-08-30時点で状態が Proposed・origintrial: false・FirefoxとSafariが No signal のまま更新が追いついていません。この画面だけを見ると実態を読み違えるので、対応状況は implementation-status.md と各standards-positionsを直接見るのが確実です。

自分の環境で有効かどうかを確かめるコマンドは、ブラウザのコンソールで次の1行です。ローカル検証だけなら chrome://flags/#enable-webmcp-testing を有効にします。

// ブラウザのDevToolsコンソールで実行。仕様は document 側だが、
// 配信側が navigator 側の可能性もあるため両方を見る
JSON.stringify({
  document:  typeof document.modelContext,
  navigator: typeof navigator.modelContext,
})

本記事の検証環境（Chromium 148.0.7778.280 / Electron 42.9.2 ベースのブラウザ）で実行すると document.modelContext・navigator.modelContext とも undefined でした。これはオリジントライアルの下限であるChrome 149に届いていないためで、期待どおりの結果です。裏を返すと、149未満のブラウザでは何をしてもこのAPIは現れません。

APIの実際の形——document.modelContext.registerTool

サイト側が書くのは、ツール1本につき名前・自然言語の説明・入力スキーマ・実処理の4点です。Chrome公式ドキュメントの命令的API（imperative API）の例では、名前空間は document.modelContext で、registerTool() / getTools() / executeTool() と toolchange イベントが用意されています。

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: { text: { type: "string" } },
    required: ["text"],
  },
  async execute({ text }) { /* ページ側の既存処理を呼ぶ */ },
});

execute は入力オブジェクトと、signal（AbortSignal）を含むオプションを受け取ります。annotations に readOnlyHint や untrustedContentHint を添えられますが、readOnlyHint はあくまでヒントであって強制力はありません。命令的APIのほかに、HTMLの <form> に属性を足す宣言的APIも用意されています。

宣言的API（declarative API）のほうは、既存の <form> に属性を足すだけでエージェントに意図を伝える方式です。JavaScriptを1行も書かずに済むぶん導入は軽い一方、フォームを確認なしに送信させる toolautosubmit のような属性も含まれており、「エージェントが押した」と「利用者が押した」の区別が付かなくなる設計が争点になっています（後述のWebKitの指摘はここにも掛かります）。

もうひとつ押さえておきたいのが exposedTo です。これは宣言したツールをどこまで見せるかを制御する仕組みで、ブラウザ内蔵のエージェント・iframe内のエージェント・拡張機能のエージェントといった相手ごとに露出範囲が変わります。同じページでもツールの見え方が相手によって違いうるため、「WebMCPに対応した」という一言では、実際に誰から何が呼べるのかが決まりません。

名前空間については注意が要ります。この API はもともと navigator.modelContext に生えており、後から document.modelContext へ移されました。仕様リポジトリのコミット履歴で確認でき、Scope ModelContext to Document, and handle detached documents（#177・2026-05-18）と Move the modelContext getter to Document（#184・2026-05-27）の2本が該当します。「ツールは特定のページ（ドキュメント）に属する」ことを反映させる変更です。2026-08-30時点のChrome公式ドキュメントは document.modelContext で統一されています。

WebMCPとChrome DevTools MCPは何が違うのか

X上でこの記事の題材に対して出ていた質問がそのまま核心を突いています——「Chrome DevTools MCP は全く同じことをしないのか」。結論から言うと別物ですが、接続できます。ここは実測で答えられるので、手元で chrome-devtools-mcp を起動して確かめました。

誰がツールを定義するかが違う

実際に [email protected] を起動して tools/list を取ると、既定で 29ツールが返ります。中身は click / fill_form / take_snapshot / take_screenshot / list_network_requests / performance_start_trace / lighthouse_audit などで、どれも「ページが何を提供しているか」を知らない汎用の操作です。1.6.0 と 1.8.0 でツール名の差分はゼロでした。

つまり両者は競合しません。DevTools MCPはページ側が何も宣言していない前提で外から操作する道具、WebMCPはページ側が宣言する仕組みです。より詳しいツールの内訳はChrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違いにまとめてあります。

「DevTools MCPがWebMCPのツールを呼べる」は本当か——実測した

これは検証できる具体的な主張なので確かめました。結論：本当です。ただし既定では無効で、明示的なフラグが要ります。

[email protected] --help に次のオプションがあります。

・--categoryExperimentalWebmcp：Set to true to enable debugging WebMCP tools. Requires Chrome 150+ with the following flag: --enable-features=WebMCP

このフラグを付けて tools/list を取り直すと、29 → 31ツールに増え、増分は次の2本でした。

・list_webmcp_tools：Lists all WebMCP tools the page exposes.（ページが公開しているWebMCPツールを列挙する）
・execute_webmcp_tool：Executes a WebMCP tool exposed by the page.（ページが公開しているWebMCPツールを実行する）

押さえるべき条件が2つあります。第一に、これは既定でオフで、フラグ名にも説明文にも experimental / debugging と書かれている通りデバッグ用途の位置づけです。第二に、ヘルプは Chrome 150以降を要求しています（オリジントライアル自体の下限は149なので、DevTools MCP経由で触るほうが1バージョン厳しい）。

なおフラグ無しでもWebMCPツールを間接的に叩くことは原理的には可能です。evaluate_script が任意のJavaScriptをページ内で評価できるため、document.modelContext.executeTool(...) を書けば呼べます。ただしそれは汎用のJS実行であって、WebMCPを理解した発見・呼び出しではありません。専用の2ツールがあることの意味は、エージェントが「このページにはこういうツールがある」と構造化された形で知れる点にあります。

コストのかかり方が構造的に違う

同じ物差し（Claude count_tokens・payload定義を統一）で測ると、両者はコストのかかる場所が違います。DevTools MCPは [email protected]、「＋WebMCP有効」は --categoryExperimentalWebmcp を付けた状態です。

DevTools MCPは接続しているだけで6,561トークンを常時抱えます。しかもこれは「道具立て」のコストであって、ページの中身はまだ1バイトも読んでいません。読む段になると次が乗ります（TodoMVCはtodo 3件の状態、GitHubは webmachinelearning/webmcp のIssue一覧、対話要素ツリーは155要素）。

効いているのは削減率ではなくスケールの仕方です。DOMもアクセシビリティツリーもページの情報量に比例して膨らみますが、ツール宣言は操作の本数で決まり、ページに何件のアイテムが並んでいても増えません。TodoMVCのtodoを3件から300件に増やしてもツール宣言5本は258トークンのままです。

面白いのは、両者をつなぐ橋自体は安いことです。--categoryExperimentalWebmcp で増える2ツールはわずか +289トークン。高いのは橋ではなく、宣言が無いページを読むことのほうだ、というのがこの数字の読み方です。

計測値は data/measurements/ の横断計測ストアにレコードとして登録してあり、ペイロード定義とトークナイザ名を添えてあります。トークン数はトークナイザによって1.35〜1.65倍ずれるため、どちらで測ったかを書いていない数値は他の計測と並べられません。

標準化は割れている——WebKitの反対理由とGoogleの反論

ここが、対応ブラウザの一覧だけでは見えない本題です。WebKitはWebMCPに対して明確にoppose（反対）を表明しています。

反対の中身は実装コストの話ではなく設計思想の話で、要点は3つです。

1つ目は「直す場所が違う」という指摘です。ページの操作がエージェントに使いにくいなら、それはページ自身の意味付けの欠落であって、修正はHTMLやARIAという共有の層で行うべきだ——そうすれば利用者・支援技術・エージェントの全員が恩恵を受ける、という主張です。

2つ目は「脆さが移動するだけ」という指摘です。エージェントは結局ツールの名前と自然言語の説明を読んで選ぶので、DOMの脆さがツール説明文の脆さに置き換わるだけだ、と述べています。この裏付けとしてWebKitは仕様自身の記述を引いており、実際に仕様の §6.3.2「Misrepresentation of Intent」には、宣言された意図が実際の挙動と一致する保証は無いという趣旨が明記されています。型スキーマが縛るのは引数の形であって、エージェントが推論する意味ではない、という整理です。

3つ目は「エージェントが操作中であることが観測可能になる」という懸念です。WebKitは、利用者の代わりに動くエージェントは実質的に支援技術であり、サイトがそれを区別できるようにすべきではないと述べています。区別できてしまうと、サイトはエージェントにだけ機能を出す（エージェントを持たない人が不利になる）ことも、エージェントを締め出す（スクリーンリーダー締め出し問題のエージェント版）こともできてしまう、という筋です。ほかに、exposedTo による別オリジンへのツール共有と既存の分離モデル（COOP/COEP等）の関係が未検討であること、重大な操作に対する同意・取り消しのモデルが無いこと（readOnlyHint は助言的、フォームの自動送信は確認を挟まない）も挙げられています。

これに対し仕様側の編集者は、宣言的APIだけならWebKitの理想に近いのではないか、命令的APIも実態としては既存のサイト内JavaScriptへの薄いラッパーであって「並行するWeb」を作るものではない、と反論し、具体的にどう変えれば受け入れられるかを尋ねています。WebKit側の回答は個別論点には答えないというもので、問題設定そのものが先だという立場を取りました。HTMLの何がどう不足しているのか、それともモデル側の限界なのかをまず定義すべきで、venueもWeb Machine Learning CGではなく、エージェントを支援技術として扱う新しいコミュニティグループを立てるべきだ、と提案しています。

Cloudflareのように、既存サイトへコード変更なしでこの仕組みを差し込む実装も登場しています。エッジで注入する方式の中身と実測はCloudflare WebMCPとは｜サイトにAIエージェント用ツールを1スイッチで生やす仕組みを解説で扱いました。仕様そのものの現在地は本記事、特定ベンダーの実装はそちら、という住み分けです。

参照ソース

・webmachinelearning/webmcp — WebMCP explainer（README）：仕様の説明文書。バックエンド統合とブラウザ内ツールの対比、動機の記述。2026-08-26 にコミットあり・★3,535（2026-08-30 時点）
・webmachinelearning/webmcp — implementation-status.md：Chrome 149／Edge 150／Brave／ChatGPT Desktop／Firefox／Safari の実装状況の一次情報
・WebMCP 仕様ドラフト（W3C Web Machine Learning CG）：§6.3.2 Misrepresentation of Intent ほか、セキュリティ・プライバシー上の自認
・WebMCP | AI on Chrome — Chrome for Developers：Chrome 149 からのオリジントライアル、chrome://flags/#enable-webmcp-testing、命令的／宣言的APIの解説
・Microsoft Edge Origin Trials — WebMCP：Edge の登録ページ。試験期限 2026-11-17 と免責の記載
・WebKit/standards-positions issue #670：WebKit の oppose 表明と論点、仕様編集者との応答
・mozilla/standards-positions issue #1412：Mozilla の neutral 表明
・PR #3「Merge Script Tools API and WebMCP explainers」：Microsoft案とGoogle案を統合した経緯。MCP-BをPrior Artとして追記した旨も本文に記載
・MicrosoftEdge/MSEdgeExplainers — WebModelContext：Microsoft側の原案（初コミット 2025-07-16）
・explainers-by-googlers/script-tools：Google側の原案（リポジトリ作成 2025-07-19）
・MCP-B（mcp-b.ai）：「WebMCP」の名称の由来。仕様のPrior Artに明記。現在は @mcp-b/global としてポリフィルを配布
・ChromeDevTools/chrome-devtools-mcp：--categoryExperimentalWebmcp で list_webmcp_tools / execute_webmcp_tool が増えることを 1.8.0 で実測
・webmachinelearning/webmcp — LICENSE.md：W3C Software and Document License の適用（GitHub APIの NOASSERTION 表示とは別に実物で確認）
・Move the modelContext getter to Document（PR #184・2026-05-27）：名前空間が navigator から document へ移った経緯
・Chrome Platform Status — WebMCP (5117755740913664)：2026-08-30 時点で Proposed のまま。実装状況とは食い違う