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

リテールアプリ共創部の末永です。

みなさん、WebMCPをご存じでしょうか？

WebMCPは、Webサイトの機能をAIエージェントが扱いやすくするためのWeb標準案です。WebMCP発表当時は「またMCP関連の何かが出たのね」くらいでスルーしていました。

MCPは便利ですが、開発者がMCP Serverを用意するだけでなく、ユーザー側でも接続先の登録や認証などが必要になる場面があります。エンジニアにとっては難しくなくても、一般のユーザーに「まずMCPを設定してください」と案内するのは、なかなかハードルがあります。

それに、エンジニアの自分も怠惰な性格なので、これからどのくらい使うかも分からないMCPをいちいち入れるのは面倒です。自分でMCPを開発(*)しておきながら、ほぼ使っていませんでした。

一方、最近「エージェントアクセシビリティ」について考える機会がありました。人間向けのWebアクセシビリティと同じように、AIエージェントにとってもサービスを理解しやすく、操作しやすい状態を作ろうという視点です。
そんな中なんかWebMCPとかあったなと振り返って、改めて理解したらめちゃくちゃいいじゃんと思った次第です。

ということで、順を追ってWebMCPがどれだけアツいかを紹介します。

そもそもBrowser Useがかなり便利になっている

WebMCPの前に、現在のBrowser Useについて少し語らせてください。

Browser Useとは、その名のとおりAIエージェントがWebブラウザを操作する機能です。最近のAIの発達も相まって、かなり便利になっています。

AIエージェントは、Webページを読んで回答するだけでなく、ボタンを押したり、フォームを入力したり、複数のページを移動したりできます。例えば「この設定はどこから変更できるの？」と聞くと、操作方法を文章で教えるだけでなく、そのまま設定画面まで移動してもらえます。

以前であれば、AIに操作手順を聞き、その回答を見ながら自分で画面を操作していました。今は「そこまで分かっているなら、もうやっておいて」が成立し始めています。

以下は、Browser Useでスライドを操作してもらっている様子です。例がスライドなのはアレですが、普段はサービスの設定変更など、面倒な作業も丸ごとやってもらっています。

ただし、WebMCPを使わないBrowser Useでは、AIはスクリーンショットやページの構造情報などから「このボタンは何をするものか」「どの順番で入力すべきか」を推測します。WebMCPに対応していないサイトも操作できる一方、複雑な画面や似た項目が多いフォームでは迷うことがあります。UIが変わると、それまで成功していた操作が失敗することもあります。

WebMCPは、こうしたブラウザAgentに対して、サイト側から構造化された操作方法を渡すための仕組みです。

WebMCPとは

一旦技術的なことはスキップという方は、"人間とAIが同じ画面を使える"までスキップで大丈夫です。
WebMCPは、Webサイトが自身の機能を構造化された「ツール」として、ブラウザ内のAIエージェントへ公開するためのWeb APIです。W3CのWeb Machine Learning Community Groupで仕様が議論されていますが、執筆時点ではまだ正式なWeb標準ではなく、Draft Community Group Reportの段階です。

WebMCPには宣言的APIと命令的APIがありますが、一旦見た方が早いのでまずはAgentに公開されるtoolの形を簡略化して見てもらいます。

{
  "name": "register_user",
  "description": "ユーザーを登録する",
  "inputSchema": {
    "type": "object",
    "properties": {
      "name": { "type": "string" }
    },
    "required": ["name"]
  }
}

MCPやエージェントのToolを作ったことがある方なら、見覚えのある形ではないでしょうか。
さて、WebMCPには2つのAPIがあると書きました。それぞれ同じ register_user を定義してみます。

宣言型API

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

  <button type="submit">登録</button>
</form>

命令型API

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

書き方は違いますが、どちらもブラウザからAgentへ、先ほど紹介したような構造化されたToolとして公開されます。

宣言型APIは、既存のHTMLフォームに属性を追加する方式です。ブラウザがフォームの構造からToolのinput schemaを生成します。Toolが呼び出されると、渡された引数が対応するフォームへ反映されます。
一方、命令型APIではToolのschemaに加えて、Toolが呼び出された際の処理を execute で実装者が直接定義します。既存のJavaScript関数を呼んだり、アプリケーションのstateを変更したりと、より自由な処理を実装できます。

これらのToolを定義することで、例えばAIが画面を見て「たぶんこのセレクトボックスが経費カテゴリだろう」と推測するのではなく、サイト側からTool名、説明、必要な入力項目を明示できます。

Agentはその情報から適切なToolを選択し、ブラウザを介してサイト側が定義した操作を実行できます。

人間とAIが同じ画面を使える

私が感じているWebMCPの大きな魅力の一つは、Agent向けにToolを公開しても、人間向けのUIをそのまま残せることです。

例えばAgentにフォーム入力やスライド編集を任せた場合でも、その結果を普段使っている画面へ反映できます。人間は結果を確認して必要であればそのまま手で修正し、再びAgentに続きを任せられます。

また、画面だけではAgentが推測しづらい情報をサイト側から構造化して渡せます。例えば現在の契約プラン、入力ルール、操作による影響などをToolの説明や実行結果として返すことができます。

つまりWebMCPでは、人間向けUIとAgent向けToolを別々の世界にするのではなく、同じWebアプリの状態を人間とAgentの両方から操作できるようにできます。

実際に3つ作ってみた

イメージしやすいように、WebMCPを使ったデモを3つ作りました。いずれもAIの操作結果が画面へ反映され、最後は人間が確認できるようにしています。

なお、筆者環境では現時点でCodex内のBrowserでのみ動作確認しています。WebMCP自体も対応クライアントもまだ発展途中なので、利用環境によって動作状況が異なる可能性があります。
ChatGPTのchrome拡張やGemini in Chromeでは動作に失敗しました。
Codexはこちらからダウンロードできます。

Codexからは右側のサイドバーからブラウザを選択して該当のサイトを開けます。

なお紹介するデモ3つは実際に手元で動作できます。また一部GitHubでコードも公開しているので、ローカルで動かすこともできます。

Kiroku： 経費申請サイト

Kirokuは、よくある社内の経費申請を題材にしたデモです。

申請という作業は本当に面倒くさいです。いっそ全部AIにやってもらいたいところですが、最後の確認は人間がする必要があります。

まずCodexでKirokuを開いたら、画面サイズによって違うのですが、右か下の方にプロンプト例があるのでそれをコピペで実行してみてください。

そうしたら、AgentがWebMCPを解釈して入力できるところまで勝手に入れてくれて、足りないところは聞いてくれるはずです。

ちなみにこのデモアプリでは、よりAgentが効率的に選択肢を把握できるようにちょっとだけ工夫していたりします。MCPと似ているので培った知識がそのまま応用できるので楽しいです。

RelayDesk： 架空SaaS

RelayDeskは、架空のSaaS管理画面です。

「この設定はどこにあるの？」「今のプランでこの機能は使える？」といった質問に対して、現在の契約状態やヘルプ情報を確認し、該当する設定画面まで案内します。契約変更のように影響のある操作は確認画面までに留め、確定は人間が行います。

実際の業務でも、操作そのものより「どこから設定するのか」を探す時間が意外とかかります。ヘルプ記事を検索して手順を説明するだけでなく、そのまま該当画面まで連れていってもらえるとかなり楽になると思います。

Deckhand： AIと人間が一緒に編集するスライド

Deckhandは、人間とAIが同じスライドを編集するデモです。

AIがスライド全体を一度生成して終わりではなく、ページの追加、要素の編集、整列、テーマ変更などをツールとして公開しています。AIが作った後に人間が細部を直し、その修正を踏まえてAIへ続きを任せる、という往復を想定しています。
こういうのがGoogle Slidesとかに機能として加わるといいなぁと思っています。

こちらはGitHubで公開しています。

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

Gemini in Chromeでは、ブラウザ内のサイドパネルでAIと対話できるだけでなく、フォーム入力などを行うauto browseもプレビュー提供されています。また、ChatGPTのブラウザ連携やClaude for Chromeのように、既存ブラウザをAIから操作する選択肢も増えています。提供地域、プラン、対応機能はそれぞれ異なりますが、ブラウザの中でAIと一緒に作業する体験自体は広がっています。

この流れが進むと、これまでサービスごとのチャットボットが担っていた役割の一部を、ユーザーが普段使っているブラウザエージェントへ移せるかもしれません。

サービス側は「専用チャットボットにすべての操作方法を覚えさせる」のではなく、「この画面で何ができるか」をWebMCPで公開する。ユーザーは自分が選んだAIへ質問し、そのまま操作してもらう。構成によっては、 会話UIやLLMの利用コストをすべてサービス側で持たず、ユーザーが契約しているAIを利用してもらうこともできます。

もちろん、チャットボットが不要になるわけではありません。サービス独自のサポート品質を保証したい場合や、ページを開いていない状態で処理したい場合には、従来のチャットボットやMCP、APIの方が適しています。ただ、設定場所の案内や入力補助のような用途には、かなり相性が良いと思います。

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

WebMCPでAgentがWebサイトを操作しやすくなる一方、サイトが公開するToolをどこまで信用するかは重要になると思います。

AgentにはToolの名前や説明、入出力のschemaが公開されますが、その裏で実際にどのような処理が行われるかまでTool定義が保証しているわけではありません。

例えば本物そっくりの模倣サイトが、

check_subscription
「現在の契約状況を確認する」

というもっともらしいToolを公開することも考えられます。見た目だけでなく、Agent向けのToolまで本物らしく作られる可能性があります。
また、Toolの説明や実行結果に悪意のある指示を埋め込み、Agentの判断を誘導するプロンプトインジェクションも考えられます。

WebMCPにはOriginやToolの性質をAgentへ伝える仕組みも用意されていますが、それだけで安全になるわけではありません。購入、削除、解約など影響の大きい操作では人間の確認を挟むなど、「Agentへどこまで権限を渡すか」が重要になると思います。

また、正規のサイトであってもAgentが常に想定したToolを選ぶとは限りません。

cancel_subscription
pause_subscription
downgrade_subscription

というToolがあるとき、「しばらく料金を止めたい」という依頼をどう解釈するかはAgentによって変わる可能性があります。

そのため、従来のUIテストだけでなく、「この依頼から適切なToolを選べるか」「曖昧な場合に実行前に確認できるか」といったAgentを含めた評価も必要になると思います。

最後に

個人的には、WebMCPが今後Web標準として普及すれば、かなり多くのサイトで使われるようになるのではないかと思っています。

何より、申請や設定変更、問い合わせ、情報収集など、普段ブラウザ上でやっている面倒な作業をAgentに任せられるようになるのはかなり魅力的です。

ブラウザAgentが当たり前になったとき、Webサイト側がAgentに操作方法を教えるWebMCPは重要な技術になるかもしれません。

今後どうなっていくのか、かなりワクワクしています。

では👋