ego (lite) はブラウザそのもの、ego は端末を横断して動くあなた専属のエージェントです。
順番待ちリストに参加する
WebMCPMCPブラウザ自動化AI エージェントChrome

WebMCPとは:WebサイトがAIエージェントに構造化ツールを提供する仕組み

2026年9月01日11 min read
Last updated 2026年9月11日
星空と雪山を背景に、端末画面の前でひざまずく青いドット絵のエージェント。WebMCPを表したイメージ

WebMCPは、ユーザーに代わってAIエージェント向けの構造化ツールを見つけ、記述し、実行する提案段階のブラウザAPIです。サイト側が「その操作が何をするのか」「どんな入力を受け取るのか」を宣言し、エージェントはどのボタンや欄をクリックすべきか推測する代わりに、そのツールを呼び出します。フォームや予約フロー、診断作業を速く確実にできますが、ブラウザ自動化を全面的に置き換えるものではありません。 ChromeのWebMCPドキュメント

実務上の判断はアーキテクチャの問題です。WebMCPはサーバー側の協調で、サイト運営者がエージェント向けの契約を公開します。ブラウザ自動化はクライアント側の観察で、エージェントはすでに存在する画面(認可済みのログインセッションを含む)を操作します。サイトを自分で制御でき、安全なツールを定義できるなら前者を、今日のWeb相手に作業する必要があるなら後者を選びます。 安全なツールのガイドライン

WebMCPとは何か

WebMCP(Web Model Context Protocol)は、ChromeチームとWebMCPコミュニティによるブラウザ向けAPIの提案です。Chromeのドキュメントは、目に見えるWebアプリケーションとユーザーの制御を保ったまま、エージェント向けの構造化ツールを構築・公開する方法として説明しています。サイトは検索、決済、日付選択、サポート、診断といったツールをプログレッシブ・エンハンスメントとして公開でき、エージェントがいないときも人は同じページを使い続けられます。 Chromeのオリジントライアル告知

Chrome for DevelopersのWebMCPドキュメント。定義、ナビゲーション、ページ構成が表示されている
Chromeの公式ドキュメントは、WebMCPをAIエージェントに構造化ツールを提供するための提案標準として説明しています。これは出典の背景であり、こちらの挙動テストではありません。

WebMCPの仕組み

WebMCPに対応したページは、ブラウザにツールを登録します。各ツールには名前、説明、入力スキーマ、そしてページ内で動く実装があります。命令型APIはJavaScriptで独自の操作を書き、宣言型APIは通常のHTMLフォームに注釈を付けます。Chromeのドキュメントは、エージェントにとって重要な3点として、発見、入出力のJSON Schema、現在のページに何ができるかを示す状態を挙げています。

その結果、操作の経路を短くできます。大きなDOMを読み、あるボタンが submit_application を意味すると推測し、リデザイン後もセレクタが生き残ることを願う代わりに、エージェントはスキーマで記述された項目を渡して名前付きツールを呼べます。操作は今もWebサイト上で目に見える形で実行されるため、ページは進行状況を示し、購入など状態を変える操作の前に確認を求めることができます。

Chrome LabsのHotel Chainデモと、lookup_amenity、search_location、view_hotel のスキーマを一覧表示するWebMCP Inspector
こちらの実行では、Inspector 1.9.15が目に見えるHotel Chainデモのページから、名前付きツールとその入力スキーマを直接発見しました。

実際に試したこと:Chrome 152でのホテル予約デモ

2026年9月11日、macOS上のGoogle Chrome 152.0.7977.76とWebMCP Model Context Tool Inspector 1.9.15を使い、公式のChrome Labs Hotel Chainデモで誘導付きのテストを1回実施しました。操作者は合成の宿泊者データを使い、Gemini APIキーも、実際のホテル・決済・アカウントの認証情報も使っていません。これは挙動のウォークスルーであり、速度や信頼性のベンチマークではありません。

  1. Inspectorがページのツールとスキーマを発見しました。search_location でパリ、9月18日、3泊、大人1名を指定すると、ページには2件の宿泊施設が表示されました。
  2. filter_search_results を breakfast で呼び出しました。画面上の結果件数は2件から1件に変わり、Montmartre Suites だけが残りました。
  3. そのホテルを開き、予約フローを開始し、合成の身元 Alex Chen を入力しました。ツールはフォームを用意しましたが、予約は確定しませんでした。
  4. ページは Confirm Reservation で止まりました。操作者がこのコントロールをクリックして初めて、デモは Reservation Confirmed を表示しました。
WebMCPの朝食フィルターツール呼び出し後、Hotel Chainのパリ結果がMontmartre Suitesに絞り込まれた画面
有効なツール呼び出しが画面上のページ状態を変えました。朝食フィルターにより、パリの結果は2件から1件に減りました。
WebMCPの complete_booking ツール入力の隣に Confirm Reservation ボタンが表示された、ホテル予約の確認画面
ツールは合成の宿泊者情報を入力しましたが、結果を左右する操作は目に見える人間の確認コントロールの先に残りました。
人間が合成予約を承認した後に Reservation Confirmed を表示するHotel Chainデモ
人間のクリック後、デモは Reservation Confirmed を表示し、Inspectorは成功を報告しました。実際の予約は作成されていません。

ツール側の制限も1つ重要でした。手動で Execute Tool を実行した後、Inspectorの Copy trace 操作は空のJSON配列を返しました。そのため、この実行の証拠にはスクリーンショットと構造化した手順記録を使い、このtraceの結果をInspectorの他のモードに一般化しません。

WebMCPとブラウザ自動化の関係:競合ではなく層が違う

WebMCPとブラウザ自動化は、それぞれ別の失敗の形を解きます。サイトが良い契約を公開していれば、WebMCPは曖昧さを取り除きます。Playwright、Selenium、browser-use、あるいは実ブラウザを動かすエージェントといった従来の自動化は、契約を公開していないサイトを、描画されたページを読んで操作することで扱います。したがってWebMCPは自動化を補完します。クライアントはツールが使えるときはページのツールを呼び、使えないときは通常のブラウジングに戻れます。

この違いは能力の境界として監査するのが最も簡単です。経路を選ぶ前に、できることとできないことの両方の列を読んでください。

方式できることできないこと
WebMCPページが公開する、名前付きでスキーマ記述されたツールを呼び出すツールを登録していないページや、別のブラウザログインを持ち込めないページに到達する
DOMベースの自動化セレクタ、スクリーンショット、アクセシビリティ状態を使って、ほぼ任意の描画済みページを操作するインターフェースを解釈せずに、サイトが意図する操作を知る
実ブラウザのセッション再利用明示的に用意され、認可されたログイン済みのブラウザ状態を使うアクセスを保証したり、CAPTCHAを迂回したり、サイトの方針を上書きしたりする

実務的な導入は、読み取り専用のツール1つ、対応ブラウザ1つ、目に見える確認ステップ1つから始めます。フォールバックの経路が動いてから広げてください。

セッションの境界も同じくらい重要です。WebMCP はクライアントが訪れたページ内で動作し、ユーザーの Chrome Cookie を新しいクラウドセッションへ転送するものではありません。WebMCP のないサイトでは、ego (lite) がローカルの Chromium エージェントブラウザになります。ブラウザ状態はユーザーが明示的に用意し、対応エージェントが ego-browser 経由で専用かつ可視の Space からサイトを操作します。Space はタスクのタブと制御をユーザーの作業から分けますが、リモート VM やテナント分離の境界ではありません。この経路が変えるのはブラウザの実行モデルであり、サイトの UI 契約ではありません。 OpenClaw 2.0のリリースノート

WebMCPを万能のアップグレードとして扱うのではなく、この評価表で判断を明示してください。

評価の問いWebMCPを選ぶのは…ブラウザ自動化を選ぶのは…
サイトを自分で制御できるかはい。ページのツールを公開し、保護できるいいえ。第三者のサイトを相手にする必要がある
既存のログインが必要な作業かページ自身の認証済みセッションで足りるエージェントが別途用意したローカルセッションを再利用する必要がある
導入の目的は何か対応クライアント向けの、安定した型付きの契約サイト側の対応を待たずに、複数ページへすぐ適用できる流れ

WebMCPはどんなときに使うのか

アプリケーションを自分が所有し、安定したタスク境界を定義でき、エージェントに構造化された作業を完遂させたいならWebMCPを選びます。サポートフォーム、旅行検索、決済、社内診断などが該当します。人が意図する操作を分かっていても、エージェントなら多くのクリックを解釈する必要がある複雑な画面では特に有効です。ツールは小さく、型付きで、観察可能に保ってください。

サイトを制御しておらず、認可済みの既存ログインが必要で、互いに関係のない多くのサイトをまたいで作業する必要があり、サイトの対応を待たずに今日ワークフローが要るなら、実ブラウザの自動化を選びます。作り込んだCIスクリプトには決定的な自動化が引き続き適します。対話的なログイン作業では、目に見えるローカルブラウザが、人が確認できるのと同じアカウントとページ状態をエージェントに与えます。

WebMCPのセキュリティ上の限界

WebMCP自体が権限を与えるわけではありません。Chromeはオリジン分離と tools 権限ポリシーでAPIを制御し、クロスオリジンのiframeは既定で無効です。サイトは信頼するオリジンにだけツールを公開でき、Chromeのセキュリティ指針は、状態を変えないツールには readOnlyHint を、出力にユーザー生成や外部のテキストが含まれる場合は untrustedContentHint を推奨しています。

エージェントは指示とWebコンテンツをまとめて処理するため、プロンプトインジェクションは依然として起こり得ます。説明と出力は簡潔にし、入力はサーバー側で検証し、結果を左右する操作にはユーザーの確認を求め、必要な最小限のオリジンとツールだけを公開してください。WebMCPはより明確なインターフェースであり、認証、認可、監査ログ、人の確認を省く理由にはなりません。

WebMCPの課題と制限事項

WebMCPの最大の制約は普及です。クライアントは対応ページを訪れる必要があり、ブラウザは実験的なAPIを実装していなければなりません。Chromeはまた、ヘッドレス環境が主な設計対象ではないこと、複雑なアプリケーションは状態の作り直しが必要になり得ること、提案がまだ変化していることも述べています。

当面は混在した構成になります。あるサイトは優れた決済ツールを公開しながら、アカウント設定は通常のDOM操作のままにするかもしれません。ブラウザがテストではWebMCPに対応していても、本番の fleet ではそうとは限りません。通常の自動化のフォールバックを保ち、繰り返し実行の中でツールのエラー、確認率、人への引き継ぎを測ってください。

WebMCPを今試すには

ローカルで試すには、Chromeで chrome://flags/#enable-webmcp-testing を有効にして再起動します。実環境で試す場合、ChromeのドキュメントはChrome 149のオリジントライアルを案内しています。公式デモと Model Context Tool Inspector 拡張を使い、登録されたツールを見て、手動で呼び出し、有効な入力と無効な入力の両方を試してください。提案は活発に議論されているため、ブラウザのバージョンを固定し、APIの変更を前提にしてください。 OpenAIのWebMCP Challenge

サイト運営者ではなくエージェントを使う側なら、WebMCPの普及を待つ必要はありません。対応するコーディングエージェントで /ego-browser を実行し、範囲を限定したタスクを伝え、ブラウザセッションと権限を明示的に保ってください。2つのアプローチは併存します。WebMCPは協力するサイトを扱いやすくし、実ブラウザの自動化はそれ以外に届きます。

よくある質問

WebMCPはMCPサーバーと同じものですか

いいえ。従来のMCPサーバーは、クライアントにツールを公開する外部のプロセスやサービスです。WebMCPは、ブラウザ内のエージェントに対して、Webページ自身からツールを公開し、ブラウザのオリジンと権限ポリシーを境界とします。

WebMCPに対応していないサイトをWebMCPで自動化できますか

いいえ。クライアントはツールを登録しているページを訪れる必要があります。WebMCPを導入していないサイトには通常のブラウザ自動化を使い、認証やチャレンジで人の入力が必要になったら止まってください。

WebMCPを実装する必要があるのは誰ですか

WebMCPのツールを実装するのはWebサイトの運営者です。エージェントのクライアントとブラウザがそれを利用できる必要があります。訪問者が関係のないサイトにツールを追加することはできません。

WebMCPの主な利点は何ですか

WebMCPはエージェントに名前付きの操作、スキーマで記述された入力、ページ状態を与え、協力するサイトでセレクタの推測や解釈を伴うクリックを減らします。アプリケーションは依然としてすべてのペイロードを検証する必要があります。

WebMCPの主な制限は何ですか

WebMCPにはページ側の導入とブラウザの対応が必要で、Chromeでは実験的なままで、ヘッドレス環境の同等性、認証方針、プロンプトインジェクションは解決しません。

WebMCPのツールは人の介在なしに動きますか

リスクの低いツールは自動で動かせますが、機微な操作はユーザーの操作と確認を求めるべきです。Chromeの設計は、人間がループに入るローカルなブラウザワークフローを対象としています。

WebMCPはすべてのiframeにツールを公開しますか

いいえ。オリジン分離と tools 権限ポリシーが登録を制御し、クロスオリジンのiframeには明示的な許可と信頼された公開が必要です。

WebMCP APIはどのくらい安定しますか

安定性の保証はまだありません。ChromeはWebMCPを活発に議論中の提案標準と位置づけているため、バージョンを固定し、explainerとオリジントライアルの記述を追ってください。

ログイン済みのアカウントでWebMCPを使えますか

ページは自身の認証済みセッションの中でツールを公開できますが、WebMCPがCookieを別のブラウザへ移すことはありません。認可と確認はサイトのセキュリティモデルの中に置いてください。

サイトがWebMCPに対応していない間は何を使えばよいですか

通常のブラウザ自動化を使ってください。認可済みのローカルセッションであれば、ego (lite) により対応エージェントが /ego-browser を通じて別途用意した実ブラウザを操作できます。

実装の指針はどこで読めますか

まずChromeのWebMCPドキュメント、安全なツールのガイドライン、オリジントライアルのページ、GitHubのWebMCP explainerを参照してください。リンクは下の出典メモにまとめています。