42 ポイント 投稿者 xguru 2026-02-11 | 3件のコメント | WhatsAppで共有
  • WebMCPは、Webサイトがブラウザ内のAIエージェントに対して構造化されたツールを直接公開できるよう設計された提案標準
  • 従来の画面スクレイピングやDOM推論の代わりに、Web自体が**「このページで何ができるか」という機能と入出力を明示的な契約の形**で提供
  • 宣言的APIと命令的APIにより、HTMLフォームベースの作業から複雑なJavaScriptインタラクションまで対応
  • エージェントがページ上のツールを探索(Discovery)し、JSON Schemaで入出力を明示し、現在のページ状態(State)を共有する契約(contract)構造
  • Chrome 146にアーリープレビュー版として同梱。事前体験には Chrome built-in AI Early Preview Program への参加が必要
  • 既存のMCPがサーバーサイドのプロトコルであるのに対し、WebMCPはクライアントサイドのブラウザ内AIエージェント向けのプロトコルという点で差別化される

仕様ドラフト文書: WebMCP Early Preview

WebMCPの登場背景

  • エージェントWeb環境では、AIがユーザーに代わって予約、申請、設定変更、探索といった実作業を行う比重が増加中
  • 従来のWebは人間ユーザーを前提に設計されているため、エージェントはボタンの意味やフォーム構造を推論する必要があった
  • その結果、入力ミス、誤ったフィールド対応付け、UI変更に伴う脆弱性が繰り返し発生
  • WebMCPはこれらの問題を解決するため、Webとエージェントの間に**明示的な相互作用契約(contract)**を導入
  • エージェントがボタンの目的やフォーム構造を推測するのではなく、Webサイト側が自らのインターフェースを明示的に公開する方式
  • この契約は3つの中核要素で構成される:
    • Discovery: ページが対応するツール(例: checkout, filter_results)をエージェントが標準化された方法で取得
    • JSON Schema: 入力と期待される出力を明示的に定義し、ハルシネーションや誤解を低減
    • State: 現在のページコンテキストに対する共有理解により、エージェントが利用可能なリソースをリアルタイムで把握

WebMCPの中核概念

  • 構造化されたツール公開

    • Webサイトは自らが提供する機能を**ツール(tool)**として宣言
    • 各ツールは名前、説明、入力スキーマ(JSON Schema)、実行結果を明確に定義
    • エージェントはDOMを解釈せずとも「何を呼び出すべきか」を正確に把握可能
  • 推論ではなく契約

    • ボタンの意味の推測やカレンダーUIの解析の代わりに、Webが直接意図とルールを公開
    • 入出力形式が固定されるため、ハルシネーションと誤作動を低減
    • UIが変更されてもツール契約が維持されていれば、エージェントの動作は安定して維持される

2つのAPIモデル

  • 宣言的API(Declarative API)

    • HTML <form> 要素に属性を追加するだけでツールに変換
    • toolname, tooldescription 属性でツールの意味を宣言
    • フォームフィールドがそのままツールの入力パラメータになる
    • ブラウザがこれを自動的にJSON Schemaへ変換
    • 単純で反復的な作業や、既存のフォームベースUIに適する
  • 命令的API(Imperative API)

    • JavaScriptで直接ツールを登録
    • registerTool, provideContext, unregisterTool などのAPIを提供
    • 複雑なロジック、条件分岐、非同期処理、状態ベースの動作に適する
    • SPAや高度なWebアプリケーションでの活用度が高い

ブラウザとエージェントの相互作用方式

  • エージェントがツールを呼び出すと、ブラウザは該当UIに自動でフォーカスし入力する
  • フォームがエージェントによって呼び出されたかどうかを agentInvoked フラグで区別
  • 成功・キャンセル時には toolactivated, toolcancel イベントが発生
  • CSS疑似クラス(:tool-form-active, :tool-submit-active)を通じて視覚的フィードバックを提供
  • 人間ユーザーとエージェントの利用フローを同一のUI状態モデルに統合可能

代表的な活用シナリオ

  • 航空会社サイトで book_flight ツールを提供すれば、エージェントはカレンダーUIを解釈せず構造化された乗客情報を直接送信できる
  • 医療・法律ポータルでは submit_application ツールによりフィールドの意味を明確に伝達
  • 開発者向け設定ページでは run_diagnostics のようなツールを公開し、隠れたメニューを自動実行可能
  • カスタマーサポート、EC、旅行サービスなど、高信頼な入力が必要な領域で特に有効

WebMCPとMCPの違い

  • MCP(Model Context Protocol)はサーバー側プロトコルで、別途サーバー配備が必要
  • WebMCPはブラウザ内部で動作し、既存のWebアプリケーションへ直接統合できる
  • サーバーなしでもクライアントサイド機能をエージェントに提供可能
  • エージェントブラウザを前提としたフロントエンド中心のアプローチである点が主要な違い

現在の状態と制約

  • Chrome 146以降でフラグを有効にすると利用可能
  • ヘッドレス環境では動作せず、可視のブラウジングコンテキストが必要
  • ツールを提供するサイトを自動発見する仕組みはまだない
  • UI状態同期は開発者が責任を持って行う必要がある構造
  • 初期プレビュー段階のため、API変更の可能性や実装上の摩擦がある

3件のコメント

 
xguru 2026-02-11

@firt がXで話してからかなり話題になっています。リンクはGoogleのものにしました。

ウェブサイト自動化はスクリーンショット/DOM分析よりも10%のトークンだけで可能になるとのことです。
トークンコストを節約してくれるソフトウェアが進化論的な圧力によって生き残るだろうという予想とも一致しています.

 
crawler 2026-02-11

Chromeが主導すれば、ほかのブラウザーにもすぐに入ってきそうですね

 
parkindani 2026-02-11

agent 向けの Swagger っぽいですね。