WebMCPがアツいので見てほしい

概要

クラスメソッドの末永氏による、Web標準案WebMCPの解説記事。Webサイトの機能をAIエージェントが扱いやすくするためのWeb標準案であり、「エージェントアクセシビリティ」（人間向けのWebアクセシビリティと同じように、AIエージェントにとってもサービスを理解しやすく操作しやすい状態を作る視点）の観点から、その魅力と課題を紹介しています。

前提: Browser Useがかなり便利になっている

現在のAIエージェントはWebブラウザを操作でき（Browser Use）、ボタンを押したりフォームを入力したり複数ページを移動したりできます。以前は「AIに手順を聞いて自分で操作」していたのが、今は「そこまで分かっているなら、もうやっておいて」が成立し始めているとのこと。

ただしWebMCP非対応のBrowser Useでは、スクリーンショットやページ構造から「このボタンは何をするものか」を推測するため、複雑な画面や似た項目が多いフォームでは迷うことがあり、UIが変わると成功していた操作が失敗することもあります。WebMCPはこの問題に、サイト側から構造化された操作方法を渡す仕組みで答えます。

WebMCPとは

• Webサイトが自身の機能を構造化された「ツール」としてブラウザ内のAIエージェントに公開するためのWeb API
• W3CのWeb Machine Learning Community Groupで仕様が議論中。執筆時点では正式な標準ではなくDraft Community Group Reportの段階
• 宣言的APIと命令的APIの2種類がある

宣言型API（既存HTMLフォームに属性を追加）

<form toolname="register_user" tooldescription="ユーザーを登録する">
  <label for="name">名前</label>
  <input id="name" name="name" required>
  <button type="submit">登録</button>
</form>

ブラウザがフォーム構造からToolのinput schemaを自動生成。Toolが呼び出されると引数が対応フォームへ反映されます。

命令型API（JavaScriptで直接定義）

document.modelContext.registerTool({
  name: "register_user",
  description: "ユーザーを登録する",
  inputSchema: { ... },
  execute: ({ name }) => registerUser(name)
});

Toolのschemaに加えて、呼び出し時の処理を execute で自由に実装できます。既存のJS関数呼び出しやstate変更なども可能。

大きな魅力: 人間とAIが同じ画面を使える

• Agent向けにToolを公開しても人間向けUIをそのまま残せる。Agentが入力・編集した結果が普段使っている画面に反映され、人間が確認して手で修正し、再びAgentに続きを任せられる
• 画面だけでは推測しづらい情報（現在の契約プラン、入力ルール、操作の影響など）をサイト側から構造化して渡せる
• 人間向けUIとAgent向けToolを別々に用意するのではなく、同じWebアプリの状態を人間とAgentの両方から操作できる

実際に作った3つのデモ

• Kiroku（経費申請サイト）: AgentがWebMCPを解釈して入力できるところまで自動入力し、足りない情報は人間に質問。申請のような面倒作業をAIに任せつつ最終確認は人間が行うデモ
• RelayDesk（架空SaaS管理画面）: 「この設定はどこにあるの？」「今のプランでこの機能は使える？」といった質問に契約状態・ヘルプ情報を確認して該当設定画面まで案内。契約変更のような影響のある操作は確認画面までで留め、確定は人間が行う
• Deckhand（AIと人間が一緒に編集するスライド）: ページ追加・要素編集・整列・テーマ変更などをToolとして公開し、AIが生成→人間が細部修正→AIに続きを任せる往復を実現。GitHubでコード公開中

チャットボットの役割も変わるかもしれない

Gemini in Chromeの auto browse、ChatGPTのブラウザ連携、Claude for Chromeなど、ブラウザ内でAIと作業する体験が広がっています。この流れが進むと、サービスごとのチャットボットが担っていた役割の一部を、ユーザーが普段使っているブラウザエージェントに移せるかもしれません。

• サービス側は専用チャットボットにすべてを覚えさせるのではなく、「この画面で何ができるか」をWebMCPで公開する
• 会話UIやLLMの利用コストをサービス側で持たず、ユーザーが契約しているAIを利用してもらう構成も可能
• ただし独自サポート品質の保証やページ未開示状態での処理には従来のチャットボット・MCP・APIが依然適している

セキュリティと精度の課題

• 模倣サイトのリスク: 本物そっくりのサイトが「check_subscription（現在の契約状況を確認する）」のようなもっともらしいToolを公開し、Agent向けToolまで本物らしく作られる可能性
• プロンプトインジェクション: Toolの説明や実行結果に悪意のある指示を埋め込み、Agentの判断を誘導する攻撃も考えられる
• WebMCPにはOriginやToolの性質をAgentへ伝える仕組みがあるが、それだけで安全になるわけではない。購入・削除・解約など影響の大きい操作では人間の確認を挟むなど「Agentへどこまで権限を渡すか」が重要
• Tool選択の曖昧さ: cancel_subscription / pause_subscription / downgrade_subscription が並んだとき「しばらく料金を止めたい」をどう解釈するかはAgent次第。「適切なToolを選べるか」「曖昧な場合に実行前に確認できるか」といったAgent込みの評価が必要

まとめ

• WebMCPが標準として普及すれば、多くのサイトで使われる可能性が高い
• 申請・設定変更・問い合わせ・情報収集など、普段ブラウザでやる面倒作業をAgentに任せられるのはかなり魅力的
• ブラウザAgentが当たり前になったとき、Webサイト側がAgentに操作方法を教えるWebMCPは重要な技術になるかもしれない