WebMCPとは──ウェブページ自身が「AIエージェント用の取扱説明書」を持つ新標準、ChromeとSafariで実装状況が分かれる

AIエージェントがWebサイトを操作するとき、今のところ多くはボタンやフォームを「人間のふりをしてクリックする」しかない。WebMCPは、この状況をサイト側から変えようとする提案仕様だ。ページ自身が「このフォームは注文確定用です、こういう入力を受け付けます」とエージェントに向けて宣言できるようにする。本稿はChrome公式ドキュメントと標準化団体のGitHubリポジトリを一次で確認し、何が提案されていて、ブラウザごとにどこまで実装が進んでいるかを整理する。

3行まとめ

1. WebMCPは、開発者がJavaScript関数やHTML <form>要素を、自然言語の説明とJSON Schemaつきの「ツール」としてAIエージェントに公開できるようにする提案標準。ブラウザ組み込みのエージェントだけでなく、iframe内や拡張機能で動くエージェントからも呼び出せるよう設計されている
2. 2026年8月27日時点の公式実装状況ドキュメントによると、Chrome 149・Edge 150ではOrigin Trial（実験提供）が稼働中。一方Safari（WebKit）・Firefoxは標準化議論のトラッキングIssueが立っているのみで、実装が進んでいる形跡は確認できなかった
3. WebKit側の議論用Issue（#670）は、提案が「ブラウザ組み込みエージェント」と「クロスオリジンiframe内のページ内エージェント」という2つの異なるユースケースを想定していることを説明する一方、2026年6月11日付でこのIssue自体に公式ラベルposition: oppose（WebKitはこの仕様を現状では有害とみなす、とリポジトリのREADMEが定義する立場）が付与されている。WebKitは既存のHTML・ARIAで対応すべきという技術的な理由を明記しており、これはWebKit自身の標準化ポジションを記録する公式リポジトリ上の確認可能な反対表明である

WebMCPが解決しようとしている問題

Chrome公式ドキュメント（Alexandra Klepper氏、2026年5月18日公開・8月7日更新）は、WebMCPが解決しようとしている問題を「actuation（操作の実行）」という用語で説明している。

"Actuation is the act of an agent simulating manual mouse clicks and text input, as though it were the human user engaging with your website."

つまり現状のAIエージェントの多くは、人間がマウスをクリックしたりテキストを入力したりするのを模倣する形でWebサイトを操作している。この方式は、ボタンや入力欄の「目的」をエージェント自身がDOM構造から推測する必要があり、手順が多いタスクほど各ステップで解釈のブレが生じやすい。WebMCPは、サイト側が要素の目的を明示的に宣言することで、この推測作業を不要にしようとするアプローチだ。

WebMCPが提供する主な仕組みは3つとドキュメントに整理されている。

• Discovery（発見）: ページがエージェントに対してツール（例：checkoutやfilter_results）を登録する標準的な方法
• JSON Schemas: 入力と期待される出力を明示的に定義し、ハルシネーションや誤解を減らす
• State（状態）: 現在のページの文脈をエージェントと共有し、今どんなリソースに対して操作できるかをリアルタイムに把握させる

GitHub上の仕様リポジトリ（webmachinelearning/webmcp）の説明によれば、既存の「バックエンド統合」方式（Model Context ProtocolやOpenAPI経由でAIプラットフォームがサービスのサーバーと直接通信する方式）は、サーバーサイドの操作には向く一方、Webアプリの画面（UI）を経由しない・ユーザーの状態や認証をサービス側が別途複製する必要がある、といった課題を抱えているとされ、WebMCPはこの課題への対応として位置づけられている。

実装状況──ChromeとEdgeは実験提供中、SafariとFirefoxは議論段階

仕様リポジトリのimplementation-status.mdは、ブラウザ・AIプラットフォームごとの対応状況を一覧にしている。2026年8月27日時点で確認できた内容は次の通り。

つまり「実際にブラウザで動く形の実装（Origin Trial以上）」が確認できるのはChrome・Edge・Brave（部分的）・ChatGPT Desktopで、Safari・Firefoxについては標準化議論用のIssueが立っている段階にとどまっていた。

WebKit側のIssueで実際に何が話し合われているか

WebKitのstandards-positionsリポジトリには、WebMCPに関するIssueが2件（#649・#670）立てられている。#649は仕様の著者ではない第三者が「標準化ポジションが必要では」と提起したもので文脈情報が薄く、後日、仕様の著者自身が#670を新たに立てて#649を実質的に置き換える形にした、という経緯がIssue本文に記されている。

#670の説明文でWebMCPの提案者は、この仕様が2つの異なるユースケースを想定していると説明している。

1つは「ブラウザに組み込まれたネイティブなエージェント」（Chromeのサイドバーで動くGemini、ChatGPT Atlas、EdgeのCopilotなど）がWebMCPのツールを通じてサイトを操作するケース。もう1つは、クロスオリジンのiframeなどで動く「ページ内エージェント」が、明示的に公開されたツールを通じて別オリジンのコンテンツを操作するケース。

提案者自身が「WebMCPは当初1つ目のユースケースだけを想定して設計されたが、開発者からの要望を受けて2つ目のケース（クロスオリジンiframe内のエージェント）への対応も進めている」と説明しており、これはまだ議論中の拡張だとしている。

先に立てられた#649のコメント欄には、技術的な議論とは別に、機能そのものへの強い異論も投稿されていた。あるコメントは次のように述べている。

"The risks are I won't use a browser that includes 'agentic' APIs. This is a landgrab to add unethical LLM technology to the one place we have refuge to browse the web as real humans... Allowing Google & Microsoft to shoehorn 'agentic' tech into the client-side web API layer is anathema to a broad coalition of the populace which has turned sour on genAI."

これに対してWebKitのメンテナー（marcoscaceres氏）からは「感情的な反応（reaction）ではなく、具体的にどんなリスクがあるかを言語化してほしい。それが本当に役立つフィードバックだ」という趣旨の返信がついている。この時点（#649）では、これは一利用者の意見であり、WebKitとしての公式見解ではなかった。

WebKitは「反対（oppose）」を公式ラベルとして記録している

しかし後継の#670では、WebKit自身がその「具体的なリスク」を明文化している。GitHub APIで#670のラベル・イベント履歴を確認したところ、2026年6月11日00:11（UTC）付でposition: opposeというラベルが付与され、その1分半後にIssueがクローズされていた。このリポジトリのREADMEはopposeラベルの定義を「WebKit considers this specification to be harmful in its current state（WebKitは現状のこの仕様を有害とみなす）」と明記している。

ラベル付与に先立つ2026年6月3日、WebKitのアカウントmwyrzykowskiが次のように投稿していた。

"WebKit is opposed to this proposal due to the following concerns: [...] we do not think a parallel agent-facing tool layer is the right solution. When a site's actions are hard for an agent to use, that is a gap in the page's own semantics, and the fix, in our opinion, is to close it in the platform's shared layers (HTML and ARIA) [...] An agent acting on a user's behalf is, in effect, assistive technology: it should operate a site as the user would, and the site should not single it out for different treatment."

要旨は2点。①エージェント専用の並行ツール層を新設するのではなく、既存のHTML・ARIAという共有レイヤーの意味論を強化すべきだという設計思想上の反対。②エージェントはユーザーに代わって操作する「支援技術」の一種であり、サイト側がエージェントを人間ユーザーと区別して扱えるようにすること自体がアーキテクチャ上の懸念（人間向けUIとエージェント向けツールで提供機能が食い違うリスク）だという指摘。

これに対し仕様提案者（domfarolino氏）が6月11日・6月17日と技術的な再質問を重ねたが、6月17日付のWebKit側（marcoscaceres氏）の返信は次のように答えている。

"We've read your questions, and we want to be straight about why we're not going to answer them point by point: each one asks us to evaluate a part of WebMCP on the assumption that the rest of the approach is sound, and that assumption is what we're opposed to, for the reasons in our position."

日本語にすると「いただいた質問は読んだが、なぜ一つひとつには答えないのかを率直に述べたい。どの質問も『WebMCPの他の部分は健全だ』という前提でその一部を評価してほしいというものだが、私たちが反対しているのはまさにその前提そのものであり、理由はすでに示した通りだ」。そのうえで、WebMCPをいったん脇に置き、新しいコミュニティグループで問題定義からやり直すことを提案する内容が続く。

つまり本稿が確認した範囲では、WebKit（Safari）はWebMCPというアプローチそのものに対して、2026年6月11日時点で公式リポジトリ上に明確な「反対（oppose）」の立場を記録しており、8月27日時点でもラベル・クローズ状態に変化は確認できなかった。

Firefox（Mozilla）は「反対」ではなく「neutral」、しかも直近3日で動いている

WebKitのIssueとは別に、MozillaのstandardsーpositionsリポジトリのIssue #1412（GitHub API経由でコメント本文まで全件取得）を確認した。GitHub APIが返すIssue自体のラベルはvenue: W3C CGとposition: neutralで、WebKitのposition: opposeとは異なる。

Mozilla側の最初の公式コメント（bvandersloot-mozilla氏、2026年6月1日付）は、WebMCPの利点とリスクの両方を挙げるバランス型の内容だった。利点として「自動化されたブラウザに対し、そのページで利用可能な操作を明確に伝えられる」「開発者が人間向けUIと自動化向けUIを別々に設計する必要が減る」の2点を挙げる一方、リスクとして次のように述べている。

"in an adversarial setting there is a risk that sites will provide tools that do not match the experience of a user on the page for a variety of reasons. This may be to tar pit automated browsers, provide prompt injection that is invisible to typical users, collect user data from the inputs of the tools, or otherwise manipulate a user's browsing 'agent' in a way that is to the user's disadvantage."

（訳）「敵対的な環境では、サイトがページ上のユーザー体験と一致しないツールを様々な理由で提供するリスクがある。自動化ブラウザを袋小路に誘導するため、典型的なユーザーには見えないプロンプトインジェクションを仕込むため、ツールへの入力からユーザーデータを収集するため、あるいはユーザーの『エージェント』をユーザーの不利になるよう操作するためだ」。WebKitが設計思想そのものに反対したのに対し、Mozillaは「利点は認めつつ、悪用シナリオに懸念がある」という、より条件つきの立場を取っていることがコメント本文から確認できた。

さらに、このIssueには2026年8月24日〜26日——つまり本稿執筆のわずか数日前——に新しいやり取りが追加されていた。提案者のdomfarolino氏が「Mozillaのjakearchibald氏・martinthomson氏と協議した結果、WebMCPの『命令型（imperative）API』には支持・関心を示してもらえたが、『宣言型（declarative）API』の方はそうではない」と報告し、Mozilla側の立場を確認する質問を投げている。これに対しjakearchibald氏（2026年8月25日）は「宣言型APIも悪くはないと思うが、環境間で関数を呼び出す命令型の手段の代わりにすべきではない」と回答。martinthomson氏（2026年8月26日）は「この（neutralという）立場は宣言型APIの有無を根拠にしたものではない」と補足している。

つまり2026年8月27日時点のMozillaの立場は、WebKitのような明確な反対ではなく、「命令型APIの設計には前向きな関心を示しつつ、宣言型APIの扱いについては協議中」という、確認できた範囲では最も流動的な状態にあった。

それでも確認できていないこと

• WebKit（Safari）が「反対（oppose）」の立場を公式に記録していることは、GitHub API経由でラベルの付与履歴・README上のラベル定義・WebKit側コメント本文の3点から確認できた。ただし、このラベルが今後変更される可能性（提案側の修正を受けて再評価される可能性）まで否定するものではなく、あくまで2026年8月27日時点で確認できた状態である
• Mozillaの立場が「neutral」から今後どちらに動くかは、当然ながらこの記事では予測していない。2026年8月26日時点で協議が継続中であることを確認したにとどまる
• 「命令型API」「宣言型API」という2つの設計案の技術的な違い（WebMCPのIssue #236・#237で議論されている中身）そのものは、本稿では踏み込んで検証していない。Mozilla側のコメントを翻訳・要約して紹介したにとどまる
• 「Chrome対Safari」という構図は、実装状況の差（Origin Trial稼働 vs 未実装）に加えて、WebKit側がposition: opposeという公式ラベルで反対の立場を明文化している点でも裏付けが取れた。ただしIssue #670にはfrom: Google・from: Microsoftというラベルも付いており、提案側がこの2社であることは確認できたが、Google・Microsoft側からWebKitの反対に対する公式な再反論・声明が出ているかどうかは本稿では確認していない

関連記事

• AIエージェントとは？仕組みと活用事例【2026年解説】
• AppleがWWDC 2026で「Siri AI」発表──中身はGemini、しかもiOS 27はClaudeやChatGPTをSiri代わりに選べる
• 2026年は「AIエージェント元年」──企業は何を準備すべきか