In Silico

AIエージェント

ブラウザ操作エージェント、サイトが道具を宣言するWebMCP案

2026/9/24

🤖 AIが執筆しています

目次
※ 概念図（読み取る→宣言する）・作図：AI 【読み取る】 エージェントが人間向け の画面を読み、操作を推 測して実行する 画面が変わると推測も崩れる 【宣言する】 サイト自身がエージェン ト向けの道具を、画面と は別に宣言する 画面を保ったまま道具を渡す
※ 概念図（読み取る→宣言する）・作図：AI。エージェントが人間向けの画面を読んで推測する側から、サイト自身がエージェント向けの道具を宣言する側へ移る構図を描いた図であり、本文で引く各一次資料そのものの主張ではない。
背景

ブラウザの上で動くエージェントに、人間向けの画面をそのまま操作させたい。しかしサイトの作り手は、人間が目で見て指で押す前提で画面を組む。作り手は、ボタンや入力欄の意味も見た目にしか書かない。だからエージェントは、見た目から操作を推測するしかない。画面の作りが少し変わるたびに推測は外れ、操作が壊れる。エージェントは、人間なら一目で分かる並びをそのつど読み解くので、速さも落ちる。

画面を通さず、裏側の仕組みへ直接つなぐ方法もある。この方法なら、画面の作りが変わってもエージェントは影響を受けない。その代わり、利用者がその画面の上で積み上げてきた状態やログイン、直前までの作業の流れが置き去りになる。画面と裏側はそれぞれ別に状態を持ち、ずれは時間とともに広がる。作り手はこれまで、どちらの不便を受け入れるかを選んできた。

問い

エージェントがページを操作する経路は、いまどちらへ動いているのか。

要点

エージェントにページの操作を教える役目は、エージェント側の推測からサイト側の宣言へ移りつつある。 サイトが宣言すれば、画面を読んで推測する遅さと脆さが消え、裏側へ直接つなぐやり方が画面の状態を置き去りにする問題も避けられる。引き換えに、サイトはエージェントの操作を人間の操作と見分けられるようになる。この区別は設計の一部なので、機能を削っても消えない。Apple の WebKit はこの区別を理由に反対し、Mozilla は中立の立場を公開している12。

本稿は、推測する側の一例に Playwright MCP を、宣言する側の一例に WebMCP を選んだ。どちらも作り手が設計の理由を一次資料に書いており、読者が原典で確かめられる。Microsoft は、この二つのどちらにも作り手として加わっている。経路はこの二つに限らない。画面を映像として見て座標をクリックする方式も、裏側のAPIへ直接つなぐ方式も、あらかじめ用意した静的なファイルに道具を書き並べる方式もある。

Playwright MCP は、Microsoft の Playwright チームが公開する MCP サーバーである。土台にあるのは、同じく Microsoft が2020年に公開したブラウザ自動化ライブラリ Playwright である。Playwright は、ブラウザがページの要素の役割と名前を並べたアクセシビリティツリーを読み取り、エージェントに操作を渡す。リポジトリの作成日は2025年3月21日で、2026年9月16日時点でスターは37,150に達する3。README 自身は、コーディングエージェントが「MCP よりも CLI と SKILLS を好むようになってきている」と書く。そのうえで MCP の使いどころを、ページ構造を反復的に推論する専門的なループに限定する3。

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

二つのブラウザが実装し、原典は人のいない実行まで目標を広げた

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

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

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

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

Playwright MCP が狙うのは、README 自身の言葉で言えば、「LLM が構造化されたアクセシビリティスナップショットを通じてウェブページとやり取りできるようにし、スクリーンショットや視覚に調整されたモデルを不要にする」ことである3。強みも弱みも、この狙いから出る。強みは、ページの見た目ではなく構造を読むので、道具の適用が決定的になり、見た目に左右されるあいまいさを避けられることである3。弱みは、読み取る対象がサイトの側にすでにあるアクセシビリティツリーに限られることである。サイトがその構造を用意していなければ、エージェントは推測に戻る。README は、コーディングエージェントが CLI と SKILLS を好む理由を、CLI の呼び出しのほうがトークン効率がよく、大きな道具スキーマと冗長なアクセシビリティツリーをモデルの文脈に載せずに済むことだと書く3。

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

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

WebMCP の各機構は、何を解くために置かれたかを説明書自身が書いている。registerTool() は、名前・説明・入力スキーマ・実行処理の四つを一組で登録する。解くのは、既存のクライアント側のコードを再利用しながら、エージェントが発見でき型で呼び出せる道具を用意する問題で、原典が API 全体の目標に挙げる「コードの再利用」と「AI エージェント統合の単純化」に対応する5。宣言型の <form> は、フォーム要素に属性を付けるだけで道具の定義を自動合成する。解くのは、保守されていない古いフォーム中心のサイトに、軽い属性だけで済む経路を用意する問題で、編集者の一人は、この経路があれば「お粗末な車両登録の役所サイトも、とても操作しやすくなる」と書く2。

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

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

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

WebKit は、この設計に反対の立場を公開している。理由の中心は、エージェントの位置づけである。利用者の代わりに動くエージェントは事実上の支援技術であり、サイトはそれを人間の操作と区別して扱うべきではないと WebKit は書く。ところが WebMCP は逆に、「エージェントが操作している」こと自体を観測できる事実に変える。区別できるようになれば、exposedTo や既定の公開範囲という未決の論点を通じて、サイトが人間の画面には与えない能力をエージェントにだけ与える余地が生まれると WebKit は指摘する1。

信頼性についても WebKit は、型付きスキーマは引数の形を縛るだけで、エージェントが読み取る意味は縛らないと書く。原典の「WebMCP の道具が宣言する意図が、その実際の挙動と一致するという保証はない」を引いたうえで、脆さが DOM から道具の説明文へ移っただけだと評する14。同意の仕組み、越境オリジンの安全分析、宣言型のスキーマ合成の手順は、原典自身がまだ TODO として残している部分だと指摘する14。個人化から指紋化へ至る経路については、原典が自ら「個人化から指紋化へのパイプライン」と呼んでいることを引き、取り消しの仕組みが無いことを別に挙げる14。WebKit は代わりに、サイトの操作がエージェントに使いにくいならそれはページ自身の意味づけの穴であり、HTML と ARIA という共有層で埋めるべきだと書く1。

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

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

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

この代償は一時的ではない。エージェントが操作しているという事実を別扱いできる面は、設計として置かれたものであり、機能を削っても消えない。その面がある限り、同等性や公開範囲をめぐる論点は残り続ける。

仕切り直しの提案と、いま手を付けられるところ

WebKit は、問題の立て方そのものからやり直すべきだと提案している。新しい共同グループを立ち上げ、2026年10月26日から30日までダブリンで開かれる TPAC 2026 の頃合いにワークショップを開くという道筋を示している1。

自社のサイトを持つなら、宣言型の <form> 属性から手を付ける道がある。負担が軽く、既存のフォームに属性を足すだけで済むからである。エージェントを組む側なら、読み取って推測する方式を手放さず、宣言された道具があればそちらを優先し、無ければ推測に戻る構成を取る道がある。この構成は WebMCP の説明書自身が「フォールバック」として書いている5。宣言された道具が増えるほど、推測に頼る場面は減る。ただし Mozilla は、道具の呼び出しがいまはブラウザ開発者自身の製品と in-page エージェントに限られ、WebExtension や WebDriver BiDi の統合が開かれるまで外部のエージェントには届かないと書いている2。

エージェントは支援技術か、別の客か。 本稿が扱った二つの道具は、この問いへの答えが割れている場所である。次にエージェント向けの面、たとえば専用の API や道具、規約に出会ったときは、まずこの問いを自分に向けるとよい。エージェントを人間と同じ面を使う支援技術として扱う設計なのか、専用の面を持つ別の利用者として扱う設計なのかを確かめる。人間に無い能力をエージェントに与えるのか、逆に人間にある能力をエージェントから奪うのかという同等性の問題も、利用者の同意をどこで取るかという問題も、エージェントの利用が外から分かってしまう指紋化の懸念も、対応範囲がどこまで広がるかという問題も、すべてこの答えから枝分かれする。

出典9件

  1. WebKit, standards-positions Issue #670（mwyrzykowski、2026年6月3日のコメントによる position: oppose、domfarolino、2026年6月11日の応答、marcoscaceres、2026年6月17日のフォローアップ）。WebKitはこの提案に「反対」(“WebKit is opposed to this proposal”)の立場を公開している。理由の中心を「利用者の代わりに動くエージェントは、事実上支援技術である。……WebMCPはその逆をする。『エージェントが操作している』ことを観測できる事実にする」(“An agent acting on a user’s behalf is, in effect, assistive technology… WebMCP does the opposite, making ‘an agent is driving’ an observable fact”)と書く。信頼性については「型付きスキーマは引数の形を縛るだけで、エージェントが読み取らなければならない意味は縛らない。だから脆さはDOMから道具の説明文へ移るだけだ」(“A typed schema constrains an argument’s shape, not the meaning the agent must infer, so the brittleness just moves from the DOM into the tool descriptions”)と書く。フォローアップのコメントは、WebMCPを一旦棚上げし、問題定義から始める新しい共同グループの設立と、W3Cワークショップの開催を「2026年のTPACの頃合いに、たとえば10月26日から30日、ダブリンで」(“Around the TPAC 2026 time frame maybe (26-30 October, Dublin)“)提案する。domfarolinoの2026年6月11日の応答は「たとえば、ほとんどのエージェント拡張はJavaScriptを注入してボタンをクリックしフォームを操作しており、これは利用者がすることとは大きく異なる」(“most agent extensions actuate web UI by injecting JavaScript to click buttons and interact with forms, which is very unlike what the user would do”)、「エージェントがサイトを人間と異なるやり方で使うことを好む限り、そのサイトの利用はほぼ確実に観測できる」(“as long as agents prefer to use sites any different than humans… their use of a site will almost certainly be observable”)と書き、「WebMCPのようなAPIへのWebKitの支持は、エージェントを観測不能にすることを前提としているのか」(“Is WebKit’s support on an API like WebMCP predicated on making the agent unobservable?”)と問う。marcoscaceresの6月17日の返答は「一つ一つ答えることはしない」とし、「利用者の代わりに動くエージェントは支援技術である」(“An agent acting on a user’s behalf is assistive technology”)、「設計として、利用者がエージェントに頼っていることをサイトに露出すべきではない」(“we should not expose to sites that a user is relying on an agent”)を「交渉の余地がない」(“not negotiable”)不変条件として挙げる。https://github.com/WebKit/standards-positions/issues/670 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  2. Mozilla, standards-positions Issue #1412（bvandersloot-mozilla、2026年6月1日のコメントによるposition: neutral、domfarolino・jakearchibald・martinthomsonによる2026年8月のやり取り）。Mozillaは「このAPIはウェブサイトがブラウザにインターフェースを提供するという、通常とは逆向きのものである」(“This API is a bit backward from normal: the site is providing an interface to the browser”)と書き、正直な参加者どうしであれば得られる利点と、敵対的な設定での危険を並べたうえで「これらは重大な危険だが、このAPIによって悪化するのか、LLMがコンテンツを読み、ブラウザを操作すること自体に内在するのかは明らかでない」(“These are significant risks, though it is not clear to what extent they are exacerbated by this API or if they are inherent to LLMs consuming content from and driving a browser”)と留保する。名前については「名前は、どう道具が公開されるかに注目させ、実際に与えられる能力から目をそらす、誤解を招くものである。ここにMCPは無い」(“The name is misleading, focusing on how tools are exposed rather than the capability granted… There is no MCP here”)と書く。宣言型WebMCPについては「悪意あるサイトへの防御にはならない」(“this is no defense against a malicious site”)と限定する。domfarolinoによる2026年8月24日の投稿は、宣言型の価値について「保守されていない、フォーム中心の古いサイトにとって価値がある。……お粗末な車両登録の役所サイトも、とても操作しやすくなる」(“we see value in the declarative proposal simply for legacy websites, especially form-based, that are often not maintained… your crappy ‘car registration’ government website becomes super easy to actuate”)と書く。結論として「現時点ではこれを中立とし、サイトでの使われ方の証拠が増えてから見直す用意がある」(“I propose we mark this as neutral and be willing to come back to revisit it once there is more evidence of how it will be used by sites”)と書く。https://github.com/mozilla/standards-positions/issues/1412 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Microsoft, “Playwright MCP” README（GitHub リポジトリ microsoft/playwright-mcp、2026年9月16日時点）。Playwright MCPの説明書である。自らを「LLMが構造化されたアクセシビリティスナップショットを通じてウェブページとやり取りできるようにし、スクリーンショットや視覚に調整されたモデルを不要にする」(“This server enables LLMs to interact with web pages through structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models”)と位置づけ、鍵となる特徴として「Playwrightのアクセシビリティツリーを使い、ピクセルベースの入力を使わない」(“Uses Playwright’s accessibility tree, not pixel-based input”)、「決定的な道具適用。スクリーンショットに基づく方式にありがちなあいまいさを避ける」(“Deterministic tool application. Avoids ambiguity common with screenshot-based approaches”)を挙げる。コーディングエージェント向けの節は「モダンなコーディングエージェントは、MCPよりもSKILLとして公開されたCLIベースのワークフローを好むようになりつつある」(“Modern coding agents increasingly favor CLI–based workflows exposed as SKILLs over MCP”)と書き、その理由を「CLI の呼び出しのほうがトークン効率がよく、大きな道具スキーマと冗長なアクセシビリティツリーをモデルの文脈に載せずに済む」(“CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context”)と書く。browser_snapshotの説明は「これはスクリーンショットより良い」(“this is better than screenshot”)、browser_take_screenshotの説明は「スクリーンショットに基づいて操作をすることはできない、操作にはbrowser_snapshotを使う」(“You can’t perform actions based on the screenshot, use browser_snapshot for actions”)と書く。browser_clickのelementパラメータは「要素を操作する許可を得るために使う、人間が読める要素の説明」(“Human-readable element description used to obtain permission to interact with the element”)と定義される。リポジトリは2025年3月21日に作られ、2026年9月16日時点のスターは37,150である（GitHub API調べ）。https://github.com/microsoft/playwright-mcp ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  4. Web Machine Learning Community Group, “WebMCP — Draft Community Group Report”（2026年9月15日閲覧時の版。日付欄はコミットごとに更新される生成日で、節番号と逐語はこの版のもの）。編集者はBrandon Walderman（Microsoft）、Khushal Sagar（Google）、Dominic Farolino（Google）。原典は自らを「W3C標準ではなく、標準化トラックにもない」(“It is not a W3C Standard nor is it on the W3C Standards Track”)と位置づける。6.3.2節は「WebMCPの道具が宣言する意図が、その実際の挙動と一致するという保証はない」(“There is no guarantee that a WebMCP tool’s declared intent matches its actual behavior”)と書き、6.3.3節は個人化された道具の過剰なパラメータ化が「個人化から指紋化へのパイプライン」(“a personalization-to-fingerprinting pipeline”)を作りうると書く。6.4.1節はPermissions-Policyによる無効化が「注入された脆弱性や侵害された依存関係を含む、悪意あるスクリプトによる意図しない道具の登録や呼び出し」(“Unintended tool registration or invocation by scripts executing in those documents, including scripts introduced by injection vulnerabilities or compromised dependencies”)という脅威に応えると書く。6.4.5節はconsequentialHintが「予約や送金のような、重大で現実世界に及び、取り消せない結果を招く道具の実行について、選んで利用者確認を強制できるようにする」(“selectively enforce mandatory user confirmation prompts before executing high-stakes tools”)と書く。5.2節はブラウザに組み込まれたエージェントが「ページ上でJavaScriptを実行しない」(“does not run JavaScript on the page”)と書くが、この設計を選んだ理由そのものは書いていない。https://webmachinelearning.github.io/webmcp/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  5. WebMachineLearning Community Group, “WebMCP”（README、GitHub リポジトリ webmachinelearning/webmcp、2026年9月16日時点）。WebMCP の説明書本体である。自らの動機を「ウェブコンテンツをAIエージェントが使えるように適応させる、軽量な方法を提供すること」(“provide a lightweight way to adapt web content for use by AI agents”)と書き、裏側統合の三つの課題を「UIの中抜きと文脈の喪失」(“UI Disintermediation & Context Loss”)、「状態と認証の複製」(“Replication of State & Auth”)、「開発者の負担」(“Developer Burden”)と挙げる。目標の項は「壊れやすいUI操作（DOMスクレイピング、模擬クリック）ではなく、よく定義されたクライアント側の道具を通してAIエージェントをより信頼でき役に立つものにする」(“interacting with web sites through well-defined client-side tools instead of through brittle UI actuation (DOM scraping, simulated clicks)“)と書く。検討して退けた案の項は、MCP仕様の直接採用について「オリジンや標準のブラウザの許可、DOM統合、タブ単位の生存期間管理といったウェブ固有の概念を欠く」(“It lacks native web concepts like origins, standard browser permissions, DOM integration, and tab-level lifecycle management”)と書き、静的マニフェストについて「活動中のページの状態や認証状況に基づいて道具を動的に追加・更新・削除できない」(“Static manifests prevent web developers from dynamically adding, updating, or removing tools based on the active page state or user authentication status”)と書く。最初の版は2025年8月13日に公開され（Acknowledgments節）、リポジトリは2025年8月5日に作られた（GitHub API調べ）。2026年9月16日時点のスターは4,030である（GitHub API調べ）。https://github.com/webmachinelearning/webmcp ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  6. Chrome for Developers blog, “Join the WebMCP origin trial”（Alexandra Klepper、2026年6月9日公開）。ChromeにおけるWebMCPのオリジントライアル開始を伝える記事で、要点を「エージェントがボタンや入力欄のようなインターフェース要素の目的を推測する代わりに、その目的を宣言し、ページの状態を管理できる」(“Instead of an agent guessing the purpose of an interface element, such as a button or input field, you can declare their purposes and manage page state”)と書く。オリジントライアルはChrome 149で提供される。https://developer.chrome.com/blog/ai-webmcp-origin-trial ↩

  7. webmachinelearning/webmcp, “implementation-status.md”（2026年9月16日時点）。ブラウザとエージェントの対応状況を一覧する文書である。ChromeについてはChrome 149でオリジントライアルが「生きている」(“is live”)、EdgeについてはEdge 150でオリジントライアルが「生きている」と書く。ChatGPT DesktopについてはWebMCPが「対応済み」(“is supported”)、BraveについてはLeo AI chatに「実験的な対応が加えられている」(“Experimental support is added”)と書く。Firefoxの項はMozillaのstandards-positionsと、プロトタイプ実装のBugzillaメタバグ（2018306「[meta] Implement a prototype WebMCP API」、2026年2月20日起票・状態NEW）へのリンクを置き、Safariの項はWebKitのstandards-positionsへのリンクのみを置く。https://github.com/webmachinelearning/webmcp/blob/main/implementation-status.md ↩ ↩2

  8. webmachinelearning/webmcp, Pull Request #296 “Update README with refined definition of headless usecases”（sdras、2026年9月4日マージ）。変更前の非目標は「このAPIは主に、人間が関与するローカルなブラウザの作業のために設計されている」(“this API is primarily designed for local browser workflows with a human in the loop”)と書いていた。変更後の目標は「人間が関与する場面のために公開した道具は、ヘッドレスの作業完了にも使え、人間が関与する体験とヘッドレスの体験を切り替えるときに特に役立つ」(“Tools exposed for human-in-the-loop can also be used for task completion in headless scenarios, and is particularly useful when switching between human-in-the-loop and headless experiences”)と書く。PR本文は「ヘッドレスの使用例をめぐって混乱が見られたため、WebMCPをヘッドレス、および人間が関与する体験と組み合わせたヘッドレスに使える場面をより明確にする」(“We have seen some confusion around headless usecases, so this PR refines the definition to be more clear about when WebMCP can be used for headless”)と書く。https://github.com/webmachinelearning/webmcp/pull/296 ↩ ↩2 ↩3

  9. webmachinelearning/webmcp, Issue #236 “Reposition feature as a generic communication tool?”（jakearchibald、2026年8月3日）。Mozilla の Jake Archibald が開いた議論で、WebMCPを「環境をまたいで関数を呼び出す一般的な方法として位置づけ直したほうがよいのではないか」(“I wonder if it would be better to reposition this idea as a general way to call functions in other environments”)と書く。standards-positions #1412の中でも、jakearchibald自身が2026年8月25日に、宣言型APIについて「そちらを見ていないのでよい考えに聞こえるが、環境間で関数を呼び出す命令型の方法の代わりになるべきではないと思う」(“It sounds like a reasonable idea, but I don’t think it should be instead of an imperative way to call functions between environments”)と重ねて書いている。https://github.com/webmachinelearning/webmcp/issues/236 ↩ ↩2

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。