■ 1. WebMCPを再評価した経緯
- WebMCPの位置づけ:
- Webサイトの機能をAIエージェントが扱いやすくするためのWeb標準案
- 発表当時は「またMCP関連の何かが出たのね」程度の認識でスルーしていた
- MCP導入の障壁:
- 開発者がMCP Serverを用意するだけでなく、ユーザー側でも接続先の登録や認証が必要になる場面がある
- エンジニアには難しくなくても、一般ユーザーに「まずMCPを設定してください」と案内するのはハードルがある
- どのくらい使うか分からないMCPをいちいち入れるのは面倒で、自分でMCPを開発しておきながらほぼ使っていなかった
- エージェントアクセシビリティ:
- 人間向けのWebアクセシビリティと同様に、AIエージェントにとって理解しやすく操作しやすい状態を作ろうという視点
- この視点から振り返って改めて理解した結果、WebMCPは非常に良い技術だと考えを改めた
■ 2. Browser Useの現状
- Browser Useの利便性:
- AIエージェントがWebブラウザを操作する機能で、最近のAIの発達と相まってかなり便利になっている
- ページを読んで回答するだけでなく、ボタンの押下、フォームの入力、複数ページの移動ができる
- 設定の変更場所を尋ねると、操作方法を文章で教えるだけでなく設定画面まで移動してもらえる
- 操作代行への移行:
- 以前はAIに操作手順を聞き、その回答を見ながら自分で画面を操作していた
- 現在は「そこまで分かっているなら、もうやっておいて」が成立し始めている
- サービスの設定変更など面倒な作業も丸ごと任せている
- 推測に依存する限界:
- WebMCPを使わないBrowser Useでは、スクリーンショットやページの構造情報からボタンの役割や入力順を推測する
- WebMCP非対応のサイトも操作できる一方、複雑な画面や似た項目が多いフォームでは迷うことがある
- UIが変わると、それまで成功していた操作が失敗することもある
- WebMCPは、こうしたブラウザAgentに対してサイト側から構造化された操作方法を渡すための仕組み
■ 3. WebMCPの仕様
- WebMCPの定義:
- Webサイトが自身の機能を構造化された「ツール」としてブラウザ内のAIエージェントへ公開するためのWeb API
- W3CのWeb Machine Learning Community Groupで仕様が議論されている
- 執筆時点では正式なWeb標準ではなく、Draft Community Group Reportの段階
- 公開されるToolの形:
- name、description、inputSchemaを持つ構造で、MCPやエージェントのToolを作った経験があれば見覚えのある形
- 宣言型API:
- 既存のHTMLフォームにtoolnameやtooldescriptionといった属性を追加する方式
- ブラウザがフォームの構造からToolのinput schemaを生成する
- Toolが呼び出されると、渡された引数が対応するフォームへ反映される
- 命令型API:
- document.modelContext.registerToolでschemaとexecuteを定義する方式
- Toolが呼び出された際の処理をexecuteで実装者が直接定義する
- 既存のJavaScript関数の呼び出しやアプリケーションのstate変更など、より自由な処理を実装できる
- Tool定義の効果:
- AIが画面を見て「たぶんこのセレクトボックスが経費カテゴリだろう」と推測する必要がなくなる
- サイト側からTool名、説明、必要な入力項目を明示できる
- Agentはその情報から適切なToolを選択し、ブラウザを介してサイト側が定義した操作を実行できる
■ 4. 人間とAIによる同一画面の共有
- 人間向けUIの維持:
- Agent向けにToolを公開しても人間向けのUIをそのまま残せることが大きな魅力の一つ
- フォーム入力やスライド編集をAgentに任せた場合でも、結果を普段使っている画面へ反映できる
- 人間は結果を確認して必要であれば手で修正し、再びAgentに続きを任せられる
- 構造化情報の受け渡し:
- 画面だけではAgentが推測しづらい情報をサイト側から構造化して渡せる
- 現在の契約プラン、入力ルール、操作による影響などをToolの説明や実行結果として返せる
- 単一状態の共有:
- 人間向けUIとAgent向けToolを別々に用意するのではなく、同じWebアプリの状態を人間とAgentの両方から操作できる
■ 5. 作成した3つのデモ
- 動作環境の制約:
- 筆者環境では現時点でCodex内のBrowserでのみ動作確認しており、ChatGPTのchrome拡張やGemini in Chromeでは動作に失敗した
- WebMCP自体も対応クライアントもまだ発展途中で、利用環境によって動作状況が異なる可能性がある
- Codexでは右側のサイドバーからブラウザを選択して該当のサイトを開ける
- 3つのデモはいずれも手元で動作でき、一部はGitHubでコードも公開している
- Kiroku: 経費申請サイト:
- よくある社内の経費申請を題材にしたデモ
- 申請作業は面倒で全部AIに任せたいが、最後の確認は人間がする必要がある
- AgentがWebMCPを解釈して入力できるところまで自動で入力し、足りないところは質問してくる
- Agentが効率的に選択肢を把握できるよう工夫しており、MCPと似ているため培った知識をそのまま応用できる
- RelayDesk: 架空SaaS:
- 架空のSaaS管理画面を題材にしたデモ
- 設定の場所や現在のプランで使える機能かという質問に対し、契約状態やヘルプ情報を確認して該当画面まで案内する
- 契約変更のように影響のある操作は確認画面までに留め、確定は人間が行う
- 実際の業務でも操作そのものより設定場所を探す時間がかかるため、該当画面まで連れて行ってもらえると楽になる
- Deckhand: 共同編集スライド:
- 人間とAIが同じスライドを編集するデモ
- スライド全体を一度生成して終わりではなく、ページ追加、要素の編集、整列、テーマ変更などをツールとして公開している
- AIが作った後に人間が細部を直し、その修正を踏まえてAIへ続きを任せる往復を想定している
- Google Slidesなどに機能として加わることを期待している
■ 6. チャットボットの役割変化
- ブラウザAgentの普及:
- Gemini in Chromeはサイドパネルでの対話に加え、フォーム入力などを行うauto browseもプレビュー提供している
- ChatGPTのブラウザ連携やClaude for Chromeなど、既存ブラウザをAIから操作する選択肢が増えている
- 提供地域、プラン、対応機能はそれぞれ異なるが、ブラウザの中でAIと一緒に作業する体験自体は広がっている
- 役割の移行:
- サービスごとのチャットボットが担っていた役割の一部を、ユーザーが普段使うブラウザエージェントへ移せるかもしれない
- サービス側は専用チャットボットに操作方法を覚えさせるのではなく、その画面で何ができるかをWebMCPで公開する
- ユーザーは自分が選んだAIへ質問し、そのまま操作してもらう
- 構成によっては会話UIやLLMの利用コストをサービス側で持たず、ユーザーが契約しているAIを利用してもらえる
- チャットボットが残る領域:
- サービス独自のサポート品質を保証したい場合や、ページを開いていない状態で処理したい場合は従来のチャットボットやMCP、APIが適する
- 設定場所の案内や入力補助のような用途にはWebMCPの相性がかなり良い
■ 7. セキュリティと精度の課題
- Tool定義の信用問題:
- サイトが公開するToolをどこまで信用するかが重要になる
- AgentにはToolの名前や説明、入出力のschemaが公開されるが、裏で実際にどのような処理が行われるかまでTool定義は保証しない
- 本物そっくりの模倣サイトがcheck_subscriptionのようなもっともらしいToolを公開することも考えられる
- 見た目だけでなく、Agent向けのToolまで本物らしく作られる可能性がある
- プロンプトインジェクション:
- Toolの説明や実行結果に悪意のある指示を埋め込み、Agentの判断を誘導する攻撃が考えられる
- 権限委譲の設計:
- WebMCPにはOriginやToolの性質をAgentへ伝える仕組みも用意されているが、それだけで安全になるわけではない
- 購入、削除、解約など影響の大きい操作では人間の確認を挟むなど、Agentへどこまで権限を渡すかが重要になる
- Tool選択の不確実性:
- 正規のサイトであってもAgentが常に想定したToolを選ぶとは限らない
- cancel_subscription、pause_subscription、downgrade_subscriptionが並ぶ場合、「しばらく料金を止めたい」の解釈はAgentによって変わりうる
- 従来のUIテストだけでなく、依頼から適切なToolを選べるか、曖昧な場合に実行前に確認できるかというAgentを含めた評価も必要になる
■ 8. 今後の展望
- WebMCPが今後Web標準として普及すれば、かなり多くのサイトで使われるようになると考えている
- 申請、設定変更、問い合わせ、情報収集など、普段ブラウザ上でやっている面倒な作業をAgentに任せられる点が魅力的
- ブラウザAgentが当たり前になったとき、Webサイト側がAgentに操作方法を教えるWebMCPは重要な技術になるかもしれない