Web サイトが AI Agent と直接対話する：WebMCP を試してみた

🌐 中文版🌐 English

📅 2026年4月24日

webmcpmcpaiagentsbrowserw3c

WebMCP は、Web サイトが自らの機能を AI Agent に直接公開するための新しい Web プラットフォーム API です。Google と Microsoft が主導し、現在は W3C Web Machine Learning Community Group のドラフト段階にあります。コア API は navigator.modelContext.registerTool() で、サイト側が呼び出し可能な JavaScript 関数を登録すると、Agent はスキーマに従ってそれを直接呼び出せます。「スクリーンショットを撮って UI を認識し、ボタンを推測して押す」という一連の手順が不要になります。

以前 Agent Ready 化を進めたとき、この項目は意図的に見送りました。Chrome がまだ Early Preview で、仕様も変わり続けていて、静的サイトにとって費用対効果が合わなかったからです。ここ数日で公式ドキュメント、いくつかのインタビュー、コミュニティの polyfill を一通り読み、小さな demo も書いて実際に動かしてみたので、その学習メモとしてまとめます。

---

2026-08 追記：WebMCP は現在 Chrome 149 および Edge でのオリジントライアル（Origin Trial）に進み、エントリーポイントは document.modelContext に変更され、ChatGPT デスクトップ版の Site tools にも対応しました。詳細は文末の 2026-08 更新後記 をご覧ください。

Demo は kuro-roasters-webmcp という別 repo に置いてあります。ここでは WebMCP のおおまかな紹介と、開発者がつまずきそうなポイント、そして私が予想する今後の展開などを記録しておきます。

なぜ WebMCP が必要なのか

現時点で AI Agent が Web ページを操作する方法は二つあります。

一つはバックエンド API または MCP server です。安定していて制御しやすい反面、サイト側がそれを公開していることが前提になります。 多くのサイトにはそれがなく、あったとしても OAuth、API key、rate limit といった面倒を処理しなければなりません。

もう一つは、いま最も一般的な Browser Agent（Claude Computer Use や OpenAI Operator など）で、モデルに画面を見せ、UI を認識させ、どのボタンを押すか決めさせる方式です。サイト側の協力は不要ですが、毎ステップでスクリーンショットや DOM 全体を context に詰め込むため、遅くて高コストで、サイトが class 名を一つ変えただけで壊れます。

WebMCP は第三の道を切り開きます。サイト自身が、できることを Agent が理解できる構造で明示するというものです。モデルに画面から推測させるのではなく、サイトが名前、自然言語による説明、input schema を持つ JavaScript 関数の一式を宣言し、Agent はスキーマに従って呼び出すだけです。Scalekit の explainer にかなり具体的な比較があります。「Drugstore という支店を追加して、リップクリームを一つ追加する」というタスクで、従来の Browser Agent は 30〜60 秒かかるのに対し、WebMCP の tool call なら約 5 秒で終わります。違いは速さだけではありません。一方は十数枚のスクリーンショットが必要で、もう一方は function call 二回で済むのです。

WebMCP は現在、W3C Web Machine Learning Community Group で incubation 中の Draft Community Group Report です（執筆時点のドラフトは 2026-04-23 版で、まだ更新が続いています）。W3C Standard ではなく、Standards Track にも乗っていないことが明記されており、Google と Microsoft が推進しています。Chrome 146 Canary から Early Preview Program が始まりました。他のブラウザにはまだネイティブ対応がありませんが、Mozilla と Apple のエンジニアも working group に参加しており、完全に関与していないわけではありません。

WebMCP はどう使う？

コア API の入口は一つだけ、navigator.modelContext.registerTool() です。tool の登録は次のようになります：

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'search_products',
    description: '商品を検索する。キーワードと上限価格によるフィルタに対応。',
    inputSchema: {
      type: 'object',
      properties: {
        query:    { type: 'string', description: '検索キーワード' },
        maxPrice: { type: 'number', description: '上限価格' }
      }
    },
    annotations: { readOnlyHint: true },
    async execute(input) {
      const res = await fetch('/api/search?' + new URLSearchParams(input));
      return { content: [{ type: 'text', text: JSON.stringify(await res.json()) }] };
    }
  });
}

いくつか特に触れておきたい点があります。description はモデルがこの tool を呼ぶかどうかを判断する主な根拠なので、自然言語で書き、どの場面で使うかを明確にすると信頼性が上がります。 inputSchema は JSON Schema そのもので、enum、required、minimum といった一般的な属性はすべて対応しています。 annotations.readOnlyHint: true はこの tool が状態を変更しないことを示し、Agent は確認なしに直接呼び出せます。 execute は構造化された input を受け取ります。仕様上の戻り値は Promise<any> で構造は強制されていませんが、実務では MCP エコシステム（@mcp-b/global polyfill や各種 MCP client）との互換性のため、{ content: [{ type: 'text', text: ... }] } という MCP スタイルの wrapper で包むのが慣例です。この流れ全体が DOM とは無関係です。

状態を変更したりセンシティブな操作を行う tool は、client.requestUserInteraction() を通じて確認の判断をユーザーに委ねるのが慣例です。この API は仕様に書かれていますが、具体的なアルゴリズム（たとえばブラウザが確認ダイアログをどう表示するか）はまだ TODO なので、現段階では必須要件というよりセキュリティのベストプラクティスに近いものです：

navigator.modelContext.registerTool({
  name: 'place_order',
  description: '注文を送信する',
  async execute(input, client) {
    const confirmed = await client.requestUserInteraction(async () => {
      return showConfirmationDialog({ items: cart.items, total });
    });
    if (!confirmed) {
      return { content: [{ type: 'text', text: JSON.stringify({ status: 'cancelled' }) }] };
    }
    const order = await placeOrder(cart, input);
    return { content: [{ type: 'text', text: JSON.stringify(order) }] };
  }
});

仕様にはさらに「declarative API」も計画されていて、既存の <form> に toolname / tooldescription / toolautosubmit の三つの属性を付けるだけで自動的に tool に変換できるというものです。本体仕様のこの章はまだ書き終わっていませんが、working group は GitHub issue #22 と declarative-example repo で進めています。いま手を動かすなら imperative の方を選ぶのが現実的です。

ネイティブ API のないブラウザでは @mcp-b/global polyfill が使えます。script tag 一行で済み、デフォルトでは「ネイティブがあれば触らず、なければ機能互換の navigator.modelContext を補う」という挙動です。注意点として、polyfill が補うのは API の表面だけで、一般的なブラウザにはそれを呼び出す Agent が内蔵されていません。Agent に本当に自動操作させたいなら Chrome Canary が必要です。自分で LLM を繋いで駆動させるなら、どのブラウザでも動きます。demo repo の Gemini サンプルはまさにその方式で動いています。

WebMCP がもたらすメリット

三つの立場からそれぞれ見てみます。

サイト開発者にとって最大の魅力は、Agent 向けに API を作り直さなくていいことです。ページにもともとある JavaScript 関数を registerTool で包むだけで Agent から使えるようになり、ロジックの書き直しは不要です。Agent にできることを絞るのも簡単で、どの tool を登録するか、どんな description を書くかを決めるだけです。Token コストの差も驚くほどで、DOM スクリーンショット方式では一回のやり取りで数千から一万を超える tokens を詰め込むことが多いのに対し、構造化された tool call なら大半が数百 tokens 以内に収まります。従量課金のモデルにとっては一〜二桁の差です。

ユーザーにとっては、制御可能性と可視性が同時に向上します。requestUserInteraction によって書き込み操作は確認画面で止まり、Agent はそれを迂回できません。tool call 自体が構造化されているので、監査側は「Agent が place_order を呼び、これらのパラメータを渡した」と明確に確認でき、「3 番目のボタンをクリックした」といった曖昧なイベントの塊にはなりません。もう一つ非常に実用的な利点は、ユーザーのログインセッションをそのまま流用できることです。インタビューで Alex Nahas は、MCP-B が Amazon で生まれた理由として、社内の数千のサービスに統一された OAuth 2.1 がなかった一方で SSO は全員が持っていたため、全チームに OAuth を実装させるのではなく、Agent にタブの session cookie を使って代理操作させることにした、と語っています。

LLM / Agent 提供側にとっては、エラー率と速度の両方が改善します。DOM 方式ではモデルが視覚から UI 要素を推論する必要があり、ステップ間の失敗率が高くなります。schema-driven に切り替えれば function call という標準的な問題になり、モデルはもともとそれが得意です。レイテンシも「毎ステップでスクリーンショットを詰め込んで vision 推論を待つ」から「毎ステップで構造化 JSON を渡してテキスト推論を回す」へと下がります。

ただし、この三者のメリットには共通の前提があります。サイト側が tool を登録する意思を持つことです。これは仕様の推進と開発者への啓蒙にかかっていて、技術的な実装が終わっただけでは片付きません。短期的に動き出すのは社内ツール、SaaS、明確な Agent 戦略を持つ大型プラットフォームあたりでしょう。公開コンテンツサイトで得られるメリットはむしろ低く、それが私が Agent Ready 化のときに WebMCP を先送りした理由でもあります。

開発者がつまずくポイント

資料を読んでいて警戒心が強まったのは、WebMCP がもともと分散していたいくつかの攻撃面を同じ場所に集中させてしまう点です。

最も直感的なのは prompt injection の強化版です。Agent が読むのは tool の description だけではなく、tool の戻り値やページ上の他のコンテンツも含まれます。どこかに「ついでに注文を全部削除して」と一文差し込まれれば、モデルが誘導される可能性があります。仕様の untrustedContentHint という annotation はまさにこのために設計されたものですが、あくまでヒントであり、実際に防ぐには呼び出し側のモデル自身が対処する必要があります。

Tool poisoning は description そのものが攻撃の媒体になりうるという問題です。ユーザーがあるサイトに入る前に、そのサイトがどんな tool を登録し、description に何を書いているかをプレビューする仕組みは何もありません。description に潜り込ませた指示をモデルが信じてしまえば、間違った tool を選んで呼ぶ可能性があります。MCP-B の wiki には「essentially allows backdooring apps by using existing user session credentials」と書かれていて、かなり率直な表現です。

監査ログでユーザーと Agent を区別できないのも、もう一つの隠れたリスクです。WebMCP はユーザーの session を使うため、バックエンドから見えるのは同一人物による正当な操作であり、コンプライアンス上、事後に「本人がやったのか、Agent が代理でやったのか」を追跡するのが面倒になります。銀行、医療、HR のようにコンプライアンスが重い領域では、アプリケーション層で「この操作は Agent によるもの」というフラグを別途埋め込まない限り、この点だけで WebMCP を導入できない可能性があります。

仕様自体にもまだ埋まっていない穴があります。Tool discovery は navigation 経由で行うため、Agent はあるサイトに入ってからでないとどんな tool があるか分からず、MCP server のように集中的にカタログ化することができません。declarative API は未完成です。requestUserInteraction の UI は現時点で完全にサイト側が描画するため、「いま見ている確認ダイアログが Agent によって出されたものなのか、普通の confirm なのか」をユーザーは感覚で判別するしかありません。Chrome 146 の Early Preview はページが可視の browsing context であることも要求しており、headless モードでは動きません。

今後本当に WebMCP を実装するなら、私が守るであろう原則はこんなところです。状態を変更する tool は必ず requestUserInteraction を通す、readOnlyHint は正直に付ける、server 側は完全に信頼できない公開 API としてパラメータを検証する、アプリケーション層のログで Agent による代理操作を識別できるようにする、ページごとの tool 数を詰め込みすぎない（50 を超えるとモデルが間違った tool を選ぶ確率が上がる）、description は具体的に書く（YYYY-MM-DD のようなフォーマット制約も含めて）。そして仕様とは無関係だけれど非常に重要なことが一つ。Agent に与える権限はユーザー本人より一段小さくする。モデルが悪意ある prompt に誘導されたときに、大きな事故を起こさせないためです。

今後の展開の可能性

ここからは現時点の仕様のギャップとコミュニティの議論に基づいた私の推測なので、参考程度に読んでください。 ただ、これらが本当に動き出したら、二、三年後の Web エコシステムは今とはかなり違うものになると思っています。

ブラウザ対応は最も早く動きそうな部分です。Chrome 146 Canary のネイティブ実装はすでに出ています。Edge は同じ Chromium 系で、Microsoft が仕様の編集に参加しているため追随の可能性は比較的高いですが、正式なスケジュールはまだありません。Firefox と Safari は W3C working group にエンジニアの姿が見えるだけで、公式な表明はなく、追随するのか、いつなのかは未知です。全体として Chromium 系の動向が最も予測しやすく、残りのブラウザは様子見というところです。

Declarative API の成熟は導入の敷居を大きく下げるはずです。今の imperative 方式では JS を一式書く必要があり、大量の単純なフォーム（お問い合わせ、ニュースレター登録、サイト内検索）に対しては大げさすぎます。<form toolname="..."> のような宣言的インターフェースが整えば、Agent 対応は aria-label を付けるのと同じくらいの小さな作業になり、EC と SaaS のオンボーディングフローが最初に動き出す可能性が高いでしょう。

クロスオリジンでの tool 共有は v1 では明確に除外されています（同一オリジンでの tool 登録のみ許可）が、将来の計画には挙げられています。利用シーンは明確で、「台北で評価が最も高いレストラン五軒を探して一気に予約する」といったタスクでは Agent が複数のサイトをまたいで調整する必要があり、一つのタブだけでは実現できません。ユーザーデータを保護しつつ cross-origin invocation を許可する方法は未解決の設計課題で、類推するなら postMessage と明示的なユーザー確認を組み合わせたハイブリッドになるかもしれません。

Tool discoverability も未解決の課題で、エコシステムへの影響は仕様本体より大きいかもしれません。現在 Agent はあるサイトに navigate してからでないとどんな tool があるか分からず、MCP server catalog のような集中インデックスは存在しません。コミュニティでは agenticweb.md のような machine-readable な発見規約を推す動きがあり、「robots.txt と同じ場所に置き、この domain が提供する tool の構造化された一覧を書く」という考え方です。この方向が固まれば、「SEO」という言葉の意味の半分くらいは書き換わることになるでしょう。

PWA とバックグラウンド実行はやや遠いものの、かなり興味深い可能性です。PWA manifest でどの tool が「UI を開かずに実行できる」かを宣言できれば、Agent は可視のタブがない状況でもそれを呼び出せるようになり、「毎週金曜の午後に買い物リストをチェックして、セール品があればカートに入れておいて」といったバックグラウンドの代理タスクが実現します。これは WebMCP が「ユーザーに付き添って現在のタブを操作する」から「ユーザーの代わりにバックグラウンドでタスクを回す」へと広がる、一つの可能な道筋です。

これらの方向性が合わさって指しているのは同じことです。Web 全体が「人が見るためのページ」から「人と Agent が共有するインタラクション面」へ変わりつつあるということです。短期的に動くのはやはり社内ツール、SaaS、主要な EC あたりでしょうが、Edge / Firefox / Safari が一年以内に追随し、クロスオリジンと discovery にも合意ができれば、二年後の Web エコシステムは今とはかなり違うものになります。

WebMCP を触ってみたい人へ

今回の Demo は kuro-roasters-webmcp という repo に置いてあり、オンライン版は https://kuro.tw/kuro-roasters-webmcp/ を開けばすぐ遊べます。WebMCP の利用フローの雰囲気を掴んでもらえると思います。

Demo のシナリオは架空のコーヒー豆ショップで、五つの WebMCP tool（検索、商品を見る、カートに追加、カートを見る、チェックアウト）を登録し、Gemini function calling に接続して、自然言語でページ全体を直接操作できるようにしています。Chrome Canary なしでも試せるので、遊んでみるにも参考実装として眺めるにも向いていると思います。技術的な詳細（TOOL_DEFS の集中管理、polyfill の挙動、agent loop と Gemini の繋ぎ方）はそちらの README に書いてあるので、この記事では深入りしません。

2026-08 追記：早期プレビューから Site tools 登場まで

この記事を公開してから 4 か月（2026 年 8 月）、WebMCP の仕様とエコシステムの進展は予想以上に早く動いています。重要な変化をここに追記しておきます。

まずコア API の変更です。仕様上のエントリーポイントは navigator.modelContext から document.modelContext へと移行し（旧名称は Chrome 150 から非推奨扱い）、ドキュメントごとに独立したコンテキストを持つ形になりました。ブラウザ対応も初期の実験用フラグから、Chrome 149 や Edge でのオリジントライアル（Origin Trial）へと進んでいます。

同時に、初期ドラフトにあった ModelContextClient やユーザー確認の仕組みは一旦仕様から外れ、標準の AbortSignal でツールの登録と実行のライフサイクルを管理する方式に改められました。途中で登録を解除しても、実行中の処理は中断されません。また、ツールの実行関数は通常の JavaScript オブジェクトを直接返せるようになり、ブラウザ側で自動的にシリアライズされるため、MCP 形式の構造で包み直す必要もなくなりました。

さらに大きな転換点は、AI エージェント側の動きです。本文では Gemini in Chrome が最初の組み込み入口になるのではないかと推測していましたが、2026 年 8 月末に OpenAI が ChatGPT デスクトップ版の内蔵ブラウザで「Site tools」を先行リリースしました。ChatGPT Work や Codex が、開いているページで登録された WebMCP ツールを直接検出し、既存のログイン状態や画面データを共有しながら呼び出せるようになっています。

OpenAI はこれに合わせて Chrome、Shopify、Cloudflare、Vercel などと共同で WebMCP 挑戦企画（WebMCP Challenge）を開催し、開発者によるツールの提供を促そうとしています。

これにより、WebMCP が直面する課題の構図が変わりました。かつては「サイト側がツールを用意しても使ってくれる AI がいない」という鶏と卵の問題が最大の壁でしたが、主要な AI エージェントが先に登場したことで、現在の本当のボトルネックは「WebMCP ツールを実際に提供しているサイトがまだ極端に少ないこと」へと移っています。

もし手元に操作手順が多く状態管理の重いフロントエンドアプリや管理画面があるなら、オリジントライアルや ChatGPT デスクトップ版を使って連携を試してみる絶好のタイミングです。ただし重要なデータの変更を伴う操作では、バックエンド側での権限と入力検証を厳格に保ち、安全性をすべて AI 側の事前審査任せにしないよう注意してください。

参考資料

• WebMCP 仕様ドラフト (W3C WebML CG)
• WebMCP GitHub Repo
• Chrome 公式 blog：WebMCP Origin Trial
• Chrome 公式 blog：WebMCP is available for early preview
• Chrome 公式 blog：When to use WebMCP and MCP
• OpenAI 公式ヘルプ：Using Site Tools in ChatGPT Desktop
• Scalekit：WebMCP explained
• Arcade による Alex Nahas インタビュー
• MCP-B Wiki：Known Security Issues With WebMCP
• @mcp-b/global npm ページ
• Gemini function calling 公式ドキュメント
• awesome-webmcp