AIエージェント

WebMCPとは？サイトがAIにツールを渡す仕組みとWebKitが反対する理由

2026/9/24 （更新: 2026/10/10）

🤖 AIを使用して執筆

推測する側と宣言する側の作り手は重なり、二つの経路は併用できる

Microsoft は、Playwright MCP と WebMCP のどちらにも作り手として加わっている。二つは排他ではない。Playwright MCP は、ページが WebMCP で登録したツールを集めてエージェントに渡す機能を、既定で有効にしている⁵。WebMCP の説明書も、ページのツールで目的を果たせないエージェントは、汎用のブラウザ自動化へ「フォールバック」できると書く²。ただし Mozilla は2026年6月1日の時点で、ツールの呼び出しはブラウザ開発者自身の製品と in-page エージェントに限られていると書き、ほかの利用者へ開く一歩として WebExtension と WebDriver BiDi の統合を挙げていた⁴。経路は、推測と宣言の二つに限らない。画面を映像として見て座標をクリックする方式も、裏側のAPIへ直接つなぐ方式も、あらかじめ用意した静的なファイルにツールを書き並べる方式もある。

Playwright MCP は、Microsoft の Playwright チームが公開する MCP サーバーである。土台にあるのは、同じく Microsoft が2020年に公開したブラウザ自動化ライブラリ Playwright である。この MCP サーバーは、Playwright がブラウザから取り出すアクセシビリティツリー（要素の役割と名前の並び）をエージェントに渡し、エージェントはそれを手がかりに操作する。リポジトリの作成日は2025年3月21日で、2026年9月16日時点でスターは37,150に達する⁵。README 自身は、コーディングエージェントが「MCP よりも CLI と SKILLS を好むようになってきている」と書く。そのうえで、MCP が引き続き役立つ場面として、状態を持ち続け、ページ構造を反復的に推論する専門的なループを挙げる⁵。

WebMCP は、W3C の Web Machine Learning Community Group が公開する Draft Community Group Report である⁶。編集者は、Microsoft の Brandon Walderman と、Google の Khushal Sagar・Dominic Farolino である⁶。原典自身が「W3C 標準ではなく、標準化トラックにもない」と書く、検討段階の提案である⁶。最初の版の公開は2025年8月13日、リポジトリの作成は同年8月5日である。2026年9月16日時点でスターは4,030である²。

Chromium 系の二つのブラウザが試験提供し、原典は人のいない実行まで目標を広げた

宣言する側は、提案の文書だけの段階から、実装が動く段階へ進んだ。Chrome 149 と Edge 150 は、同じ Chromium の実装の上で、申し込んだサイトにだけ一定期間この機能を有効にするオリジントライアルを提供している¹⁷。ChatGPT Desktop は対応済みで、Brave の Leo には実験的な対応が加わった⁷。エンジンの側は分かれ、Firefox は中立、Safari は反対の立場を公開している³⁴。ここまでの動きは、最初の版が出てからの一年で積み上がった²。

原典の目標も広がった。2026年9月4日にマージされた変更は、「ヘッドレスブラウジングの場面」を非目標の欄から目標の欄へ移した⁸。変更前の非目標は、このAPIが「主に人間が関与するローカルなブラウザの作業のために設計されている」と書いていた。変更後の目標は、人間が関与する場面のために公開したツールを「ヘッドレスの作業完了にも使え、人間が関与する体験とヘッドレスの体験を切り替えるときに特に役立つ」と書く⁸。同じ差分は、非目標の「完全に自律的な作業」から「人間の監督なしで動く」という除外を消し、残る境界を「ブラウザ UI が無い場面」と「純粋にサーバー側で完結する作業」に書き直した⁸。人間の画面のために用意したツールを、人間のいない実行にも使う想定へ、原典自身が広げたことになる。

構造を読む設計と、サイトに書かせる設計は、それぞれ何を前提に置いたか

二つのツールは、エージェントが何を手がかりに動くべきかで、作り手の判断が分かれている。

Playwright MCP が狙うのは、README 自身の言葉で言えば、「LLM が構造化されたアクセシビリティスナップショットを通じてウェブページとやり取りできるようにし、スクリーンショットや視覚に調整されたモデルを不要にする」ことである⁵。強みも弱みも、この狙いから出る。強みは、ページの見た目ではなく構造を読むので、ツールの適用が決定的になり、見た目に左右されるあいまいさを避けられることである⁵。弱みは、既定のツールが操作する要素を、おもにページのアクセシビリティツリーに載った構造から指すことである。座標を指定してクリックするツールは、README が別に、明示して有効にする視覚モードとして用意している⁵。README は、コーディングエージェントが CLI と SKILLS を好む理由を、CLI の呼び出しのほうがトークン効率がよく、大きなツールスキーマと冗長なアクセシビリティツリーをモデルのコンテキストに入れずに済むことだと書く⁵。

WebMCP が狙うのは、作り手が公開する説明書の言葉で言えば、「壊れやすい UI 操作、すなわち DOM のスクレイピングや模擬クリックの代わりに、よく定義されたクライアント側のツールを通してエージェントとやり取りできるようにする」ことである²。説明書はその動機を、裏側統合が抱える三つの問題として書く。サービスの UI やブラウザ体験を素通りする「UI の中抜きと文脈の喪失」、利用者の状態や認証情報を別サーバーに複製しなければならない「状態と認証の複製」、専用のバックエンドサーバーを書く必要がある「開発者の負担」である²。強みは、サイトが持つ既存のクライアント側のコードをそのまま再利用でき、画面とツールが同じ状態を共有し続けられることである²。弱みは、ツールの説明を書くのがサイト自身なので、宣言された説明と実際の挙動が一致する保証がないことである。原典自身が「WebMCP のツールが宣言する意図と、その実際の挙動が一致するという保証はない」と書く⁶。

説明書は、この形に決めるまでに検討した代案を三つ挙げ、現行案ではいずれも採っていない。ひとつは、バックエンド向けの MCP の仕様をそのままブラウザに載せる案で、原典は、MCP がサーバーとクライアントの間や標準入出力の通信のために作られており、オリジンや標準のブラウザの許可、DOM との統合、タブ単位の生存期間の管理といったウェブ固有の概念を欠くと書く²。ふたつめは、静的なマニフェストファイルにツールを書き並べる案で、原典は、活動中のページの状態や認証状況に応じてツールを動的に追加・更新・削除できず、マニフェストには実行できるコードを含められないと書く²。みっつめは、ウィンドウ単位のイベントだけでツールの呼び出しを扱う案で、原典は、ツールの宣言と実装が分かれて同期を保ちにくくなり、イベントハンドラの中に巨大な分岐処理を生むと書く²。ただし原典は、静的な宣言を将来重ねる余地と、イベントを先に発火させる混成形の余地を、それぞれ残している²。

WebMCP の各機構は、何を解くために置かれたかを説明書自身が書いている。registerTool() は、名前・説明・入力スキーマ・実行処理の四つを一組で登録する。解くのは、既存のクライアント側のコードを再利用しながら、エージェントが発見でき型で呼び出せるツールを用意する問題で、原典が API 全体の目標に挙げる「コードの再利用」と「AI エージェント統合の単純化」に対応する²。宣言型の <form> は、フォーム要素に属性を付けると、ブラウザがツールの定義を自動で合成する仕組みである。合成の手順そのものは宣言型の説明書がまだ決めておらず、Chromium がその緩い版を実装し、方式として支持されるべきかを試験で確かめるとしている²。解くのは、保守されていない古いフォーム中心のサイトに、属性を足すことでツールを公開できる経路を用意する問題で、編集者の一人は、この経路があれば「お粗末な車両登録の役所サイトも、とても操作しやすくなる」と書く⁴。宣言型を残すかどうかも、編集者が2026年8月に Mozilla へ意見を求めた論点だった。そのときは命令型と共存させる考えだとしつつ、選択肢を「命令型と宣言型」と「命令型のみ」の二つに置いていた⁴。仕様は2026年10月8日の改訂で宣言型を外し、命令型の registerTool() に絞った。宣言型は、いまは仕様に含まれず、別に検討を続ける将来の案という扱いになった²。

残る機構は、ツールを誰に見せ、いつ人に確かめるかを決める。exposedTo は、既定では同一オリジンと組み込みのエージェントにしか公開されないツールを、指定した安全なオリジンへ選んで公開する仕組みで、iframe に埋め込まれた作り手提供のエージェントとフレームをまたいで協働する経路を開く²。Permissions-Policy: tools=() は、tools という機能を空の許可リストで無効化するヘッダで、注入された脆弱性や侵害された依存関係を含む、悪意あるスクリプトによる意図しないツールの登録や呼び出しという脅威に応える。原典はこのヘッダが子孫フレームすべてに、同一オリジンと越境オリジンの両方に適用されると書く⁶。ブラウザに組み込まれたエージェントは、ページ上で JavaScript を実行せず、「観測」と呼ぶ実装依存のデータ構造を通じてツールの一覧を得るが、原典は経路を分ける理由そのものを書いていない⁶。consequentialHint は、ツールの実行が重大で現実世界に及ぶ、取り消せない結果を招くことを知らせる真偽値の注釈で、原典はこれが「予約や送金のような結果を招くツールに対して、実行前の利用者確認を選んで強制できるようにする」と書く⁶。

Playwright MCP の側も、機構ごとに解く問題を持つ。browser_snapshot は、ページの構造をアクセシビリティスナップショットとして取得する。README はこの説明の中で、これが「スクリーンショットより良い」と明記し、browser_take_screenshot の説明では「スクリーンショットに基づいて操作をすることはできない、操作には browser_snapshot を使う」と書く⁵。画像から座標を読むあいまいさを避け、要素の参照でツールを決定的に当てるという判断が、ここでも一貫している。browser_click が受け取る element パラメータは、「要素を操作する許可を得るために使う、人間が読める要素の説明」と定義される⁵。クリックそのものを特定するのは正確な要素参照で、その操作をしてよいかを人に確かめる材料は、別に用意された読みやすい説明が担う。

WebKitはエージェントを見分けられること自体を欠陥と呼び、提案の編集者はすでに見分けられていると返した

WebKit は、この設計に反対の立場を公開している。理由の中心は、エージェントの位置づけである。利用者の代わりに動くエージェントは事実上の支援技術であり、サイトはそれを人間の操作と区別して扱うべきではないと WebKit は書く。ところが WebMCP は逆に、「エージェントが操作している」こと自体を観測できる事実に変える。区別できるようになれば、exposedTo や既定の公開範囲という未決の論点を通じて、サイトが人間の画面には与えない能力をエージェントにだけ与える余地が生まれると WebKit は指摘する³。一方、WebMCP の説明書は目標の欄で、エージェントを支援技術の利用者を助ける仲介者と位置づけ、WebMCP 自体は支援技術が取り込むためにも、アクセシビリティツリーと直接やり取りするためにも設計されていないと書く²。ただし仕様の要旨は、ツールを呼び出す側として、エージェントとブラウザのエージェントに並べて支援技術を挙げている⁶。

信頼性についても WebKit は、型付きスキーマは引数の形を縛るだけで、エージェントが読み取る意味は縛らないと書く。原典の「WebMCP のツールが宣言する意図と、その実際の挙動が一致するという保証はない」を引いたうえで、脆さが DOM からツールの説明文へ移っただけだと評する³⁶。同意の仕組み、越境オリジンの安全分析、宣言型のスキーマ合成の手順は、原典自身がまだ TODO として残している部分だとも指摘する³。このうち同意については、確認のダイアログのような利用者の入力を求めるメソッドが、この指摘の8日後の2026年6月11日に、完全には仕様化も実装もされていないとして、より恒久的な設計が決まるまで仕様から外された⁶。越境オリジンの安全分析は、2026年10月8日の版でも TODO のままである⁶。宣言型のスキーマ合成の手順は、宣言型ごと仕様から外れ、宣言型の説明書で未定のまま残る²。個人化から指紋化へ至る経路については、原典が自ら「個人化から指紋化へのパイプライン」と呼んでいることを引く³⁶。重大な結果を招く操作に、同意と取り消しの仕組みが無いことも挙げる³。仕様は、この反対表明の3か月後の2026年9月3日に、そうしたツールを示す注釈 consequentialHint を加えた⁶。WebKit は代わりに、サイトの操作がエージェントに使いにくいならそれはページ自身の意味づけの穴であり、HTML と ARIA という共有層で埋めるべきだと書く³。

Mozilla は中立にとどまっている。二つの評価が並び立つからである。ひとつは、正直な参加者どうしであれば、このAPIが自動化されたブラウザに使える操作を伝え、人間とエージェントの両方向けに一つの画面を設計する開発者の負担を減らせるという評価である。もうひとつは、敵対的な設定では、サイトがページ上の体験と一致しないツールを出す危険があるという評価で、Mozilla は、自動化されたブラウザを足止めするため、通常の利用者には見えないプロンプトインジェクションを仕込むためといった動機を挙げる⁴。そのうえで Mozilla は、こうした危険が「この API によって悪化するのか、それとも LLM がコンテンツを読み、ブラウザを操作すること自体に内在するものなのかは明らかでない」と留保する⁴。名前についても、「名前は、どうツールが公開されるかに注目させ、実際に与えられる能力から目をそらす、誤解を招くものである。ここに MCP は無い」と評する⁴。

提案の位置づけ自体を問い直す議論もある。Jake Archibald は、この提案を環境をまたいだ汎用の関数呼び出しとして位置づけ直すべきだという見方を、別の議論の場で示している⁹。WebKit も同じ立場表明の中で、この提案は MCP の束縛ではなく外部の呼び出し手へ型付きの関数を登録する汎用機構だと書く³。編集者の Farolino も2026年8月26日に、この位置づけ直しへ「おおむね支持する」と応じている⁹。

作り手の側も、この対立に応答している。WebMCP の編集者の一人である Dominic Farolino は、WebKit の立場表明のスレッドで2026年6月11日に応答し、多くのエージェント拡張はすでにページへ JavaScript を注入してボタンを押しフォームを操作しており、それは「利用者がすることとは大きく異なる」と書いた。そのうえで、エージェントが人間と異なる使い方をする限り「サイトの利用はほぼ確実に観測できる」とし、WebKit の支持はエージェントを観測不能にすることを前提とするのか、と問い返している³。読み取って推測する側も、すでに人間と同じ面を使ってはいないという反論である。WebKit は2026年6月17日の返答で、個別の問いには答えず、「利用者の代わりに動くエージェントは支援技術である」「利用者がエージェントに頼っていることをサイトに露出すべきではない」を交渉の余地がない不変条件として置き直した³。区別がすでに存在するかという事実の問いと、区別を設計に置いてよいかという規範の問いは、この場ではかみ合わないまま残っている。

WebKit は、問題の立て方そのものからやり直すべきだと提案している。WebMCP をいったん棚上げして新しいコミュニティグループを立ち上げ、W3C のワークショップを開くという道筋を示し、その時期として2026年10月26日から30日にダブリンで開かれる TPAC 2026 の頃を打診している³。

エージェントの操作をサイトが区別できる設計である限り、同等性や公開範囲をめぐる論点は残り続ける。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。