WebMCP：GoogleがChrome 146に仕掛けた爆弾

AIエージェントはもうウェブを「人間のふり」をしてブラウジングする必要がなくなります。

GoogleはChrome 146でWebMCPの早期プレビューをこっそりリリースし、フラグを通じて有効化できます。

そしてこの機能は、AIエージェントとウェブページのインタラクション方法を根本的に書き換える可能性があります。

Chrome 146にはWebMCPの早期プレビューが含まれており、フラグで有効化することで、AIエージェントがユーザーのようにウェブを閲覧することなく、直接サービスをクエリして実行できるようになります。サービスは命令型のnavigator.modelContext APIまたは宣言型のフォームを通じて宣言できます。

そしてこれは、開発者Alex Volkovの言葉を借りれば、UIの中のAPIのようなものです。

これは本当に興味深いです。

WebMCPは、ウェブ開発者がAIエージェント/スマートブラウザに対して直接的なツールセットを公開できる新しい標準で、これによりボタンをクリックする必要がなくなり、サイト上の関数を直接呼び出せるようになります！

現在のエージェント

現在のAIエージェントがウェブページを操作する方法は、本質的に人間のユーザーをシミュレートしていることです：スクリーンショットの撮影、ボタンの場所の識別、クリック、フォームへの入力、ページのロード待機……

まるで天才的なアシスタントを雇いながら、彼に目隠しをしてコンピュータを操作させ、常にスクリーンショットを撮り続けて画面を「見る」ことに頼るようなものです。

その結果は：遅く、高くつき、脆い……

サイトがリデザインされると、エージェントは混乱します。

簡単な検索操作でも、スクリーンショット画像とDOMの解析に数千トークンを消費するかもしれません。

一方、WebMCPのアプローチは全く異なります：サイトがエージェントに「何ができるか」を積極的に伝える。

二つの公開方法

WebMCPは開発者に二つの道を提供します。

命令型API

JavaScriptのnavigator.modelContext.registerTool()を通じてツール関数を登録します。例えば、ECサイトはsearch_productsツールを登録できます。AIエージェントはこれを見つけると、キーワードを直接渡して呼び出し、構造化された商品データを取得します——スクリーンショットも、DOM解析も、検索ボックスの模擬クリックも必要ありません。

宣言型フォーム

HTMLフォーム要素に注釈を付けることで、エージェントがページ上のインタラクティブな機能を自動的に理解できるようにします。この方法はよりシンプルで、軽量なシナリオに適しています。

二つの方法は併用できます。

熟練した開発者は命令型で細かい制御を行い、シンプルなサイトは宣言型で迅速に統合し、柔軟性を最大化します。

極めてトークン効率が良い

実測データによると、WebMCPの構造化ツール呼び出しは、スクリーンショットベースのエージェントインタラクションと比較して、最大89%のトークン消費を節約できます。

これは、ページを「理解する」ためにスクリーンショット一枚を処理するのに2000トークンかかっていたところが、今では20-100トークンのJSONレスポンスで済むことを意味します。

そしてスクリーンショットの検証も不要で、ツールの戻り値が直接結果を確認します。

マイクロソフトとGoogleの連携

さらに、WebMCPはGoogleだけが遊んでいるわけではありません。

マイクロソフトのEdgeチームは独自に「WebModel Context」案を提案し、Chromeチームも同様の「Script Tools」提案を持っていました。

結果として、両者が顔を合わせた際に重複していることに気づき、W3C Web Machine Learningコミュニティグループの下で統一されたWebMCP提案に統合することを決定しました。

マイクロソフトEdgeプラットフォームのプロダクトマネージャーであるKyle Pflugは次のように述べています：

WebMCPはウェブページがMCPツールをエージェントに公開できるようにします。これは従来のMCPサーバーが公開するツールと似ていますが、別個のサーバーコンポーネントを必要としません。これは「人間がループ内にいる」シナリオに自然に適合します。なぜなら、ブラウザの閲覧コンテキストで実行されるため、状態と認証を簡素化できるからです——これは従来のブラウジングエージェントスキームでは非常に厄介なことでした。

簡単に言えば：ウェブページ自体がMCPサーバーになりますが、実際にサーバーを実行する必要はありません。

認証の仕組み

疑問に思うかもしれません：認証はどうなるの？ユーザーの既存のログインセッションを再利用するの？

答えは：はい、まさにその通りです。

WebMCPはブラウザの閲覧コンテキストで実行されるため、ユーザーの現在の認証セッションとブラウザの同一生成元セキュリティモデルを自然に継承します。エージェントが呼び出すツールの権限は、ユーザーが手動で操作するものと完全に同一で、追加のOAuthフローやAPIキーは必要ありません。

これは従来のサーバーサイドMCPスキームよりもはるかにシンプルです。

Kyle Pflugも、「一部のサイトはWebMCPと従来のMCPサーバーの両方を使用する」と予想していることを確認しました。なぜなら、これらは異なるシナリオにサービスを提供するからです：WebMCPはユーザーがいるブラウザシナリオに適しており、従来のMCPはヘッドレスのサーバーサイドシナリオに適しています。

人間とAI

WebMCPの設計哲学には明確な一線があります：エージェントは補助であり、代替ではない。

公式ドキュメントにはいくつかの原則が記載されています：

ウェブページの人間向けインターフェースは依然として主体であり、WebMCPはあなたのUIを置き換えることはありません
AIエージェントは人間のインタラクションを置き換えるのではなく、強化します
ユーザーはエージェントによるすべての操作を可視化し制御可能な状態に保ちます
人間とAIは協力し、AIが単独で作業するのではありません

そのため、WebMCPはヘッドレスブラウジング、完全自律型エージェント、バックエンドサービス統合をサポートしていません。それはまさに「ユーザーがブラウザの前に座り、エージェントが脇で助ける」というシナリオのために設計されています。

二層ウェブの未来

主流ブラウザがAIエージェントとウェブページの構造化インタラクションをネイティブにサポートし始めると、興味深い変化が起こりつつあります：ウェブサイトは二層に分かれる必要があるかもしれません。

人間向けの層：視覚的、ブランド重視、物語駆動。

エージェント向けの層：構造化、スキーマ駆動、高速応答。

おそらく、「エージェントSEO」について議論する時が来たのでしょう：

あなたのサイトがAIエージェントに対してどれだけ親しみやすいかは、新しい競争の次元になるかもしれません。WebMCPツールを公開しないサイトは、徐々にエージェントに対して「見えなくなる」可能性があります。

現在のWebMCPは非常に初期の段階にあり、API設計はまだ繰り返し改良中で、Chrome 146での実装はフラグを手動で有効にする必要がありますが、方向性はすでに自明かもしれません：

ブラウザはもはや人間のためのツールだけでなく、同時にAIエージェントのオペレーティングシステムになりつつあります。