WebMCP とは何か - サイトが AIエージェントに「道具」を渡すブラウザネイティブな仕組み

ブラウザ上の AIエージェント（Chrome の Gemini など）が「あなたの代わりにサイトを操作する」とき、今は何をしているかというと——画面のDOMやピクセルを見て、ボタンの位置を推測してクリックする、という綱渡りです。レイアウトが少し変わると壊れますし、複雑な操作ほど不確実になります。

WebMCP は、この関係を逆転させる提案です。エージェントが画面を推測するのではなく、サイト側が「これがうちの操作API（ツール）です」とエージェントへ構造化して渡す。Google I/O 2026 で公開され、Chrome 149 でオリジントライアルが始まります。この記事では、WebMCP とは何か・MCP とどう違うか・どう書くかを整理します。

WebMCP とは

WebMCP は、Web 標準の提案です。仕様は W3C の Web Machine Learning Community Group（webmachinelearning/webmcp）で議論されており、ドラフトが webmachinelearning.github.io/webmcp/ で公開されています。

要するに、サイトが自分の機能を機械が直接呼べる関数（ツール）として宣言し、ブラウザのエージェントがそれを叩く、という仕組みです。エージェントは「送信ボタンを探してクリック」ではなく「add-todo ツールを呼ぶ」だけで済みます。

MCP との違い

名前のとおり WebMCP は MCP（Model Context Protocol）から着想を得ており、ツール・スキーマ・パラメータという語彙を共有します。ただし動く場所が決定的に違います。

つまり WebMCP は、MCP の考え方をWeb プラットフォームにネイティブ移植したものです。サーバーインフラを立てずに、ページのスクリプトだけで「このサイトでできること」をエージェントに渡せます。Claude Code などで使うサーバー型 MCP の導入は Claude Code プラグイン導入ガイドも参照してください。

どう書くか

中心となる命令的 API は document.modelContext.registerTool() です。MCP のツール定義とよく似た形で、名前・説明・入力スキーマ・実行関数を渡します。

document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: {
      text: { type: "string", description: "The text content of the todo item" }
    },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return {
      content: [{
        type: "text",
        text: `Added todo item: "${text}" successfully.`
      }]
    };
  }
}, { signal: controller.signal });

ポイントは execute がそのページの実関数を呼べること。addTodoItemToCollection(text) は、あなたのアプリが普段使っている処理そのままです。エージェントは内部実装を知らなくても、宣言された inputSchema どおりに引数を渡せばよく、サイトは自分のロジックで安全に処理を完結できます。signal で登録の破棄（ページ遷移時など）も制御できます。

このほか、標準の HTML フォームに注釈を付けてツール化する宣言的なやり方も用意されています。既存フォームを起点にエージェント操作へ開く、という現実的な導線です。

何が嬉しいのか

サイトがツールを宣言することで、エージェント側の「画面を推測する」工程が消えます。

• 信頼性: DOM 構造やボタン位置に依存しない。レイアウト変更で壊れにくい
• 速度: スクリーンショットを撮って視覚モデルで解釈する往復が不要。構造化された呼び出しで完結
• 精度・パーソナライズ: サイトが意図したとおりの操作だけを公開でき、曖昧なクリックの誤爆を避けられる

実際、Google I/O 2026 では旅行・EC 系（Expedia などのデモ、Shopify・Booking.com も検証中と報じられています。詳細は要確認）が早期に関心を示しています。「エージェントが画面を当てずっぽうで触る」より「サイトが正しい操作を渡す」ほうが、双方にとって確実だからです。

現状の立ち位置

• 標準としては提案段階。Chrome 149 でオリジントライアルが始まるが、仕様は流動的
• ブラウザ対応は Chrome 中心。Gemini in Chrome が初日から消費側として存在。Firefox/Safari は未表明
• 本番採用は時期尚早だが、document.modelContext.registerTool の形を今のうちに把握しておくと、エージェント時代の Web の作り方が見えてくる

Google I/O 2026 の開発者向けハイライトで触れた「agentic web（エージェントが主役の Web）」の、具体的な土台がこの WebMCP です。

まとめ

• WebMCP は、ブラウザ内の AIエージェントにサイト側が構造化ツールを公開する Web 標準提案。Google I/O 2026 で公開、Chrome 149 でオリジントライアル
• MCP と語彙（ツール・スキーマ・パラメータ）を共有しつつ、サーバー不要のクライアントサイドで動くのが違い
• API は document.modelContext.registerTool({ name, description, inputSchema, execute })。HTML フォームへの注釈による宣言的な書き方もある
• 利点はエージェントが画面を推測しなくて済むこと（信頼性・速度・精度）。一方でツール公開は新しい攻撃面でもあり権限設計が要る
• 現状は提案段階・Chrome 中心。本番採用より「エージェント時代の Web の作り方」を掴むために今押さえておきたい

エージェントがサイトを「見て触る」時代から、サイトがエージェントに「道具を渡す」時代へ。WebMCP はその転換点を示す提案です。

参考リンク

• WebMCP（Chrome for Developers）
• webmachinelearning/webmcp（提案リポジトリ）
• Chrome at I/O 2026（Chrome for Developers）
• MCP 2026 ロードマップ（当ブログ）
• MCP のプロンプトインジェクションと RCE（当ブログ）
• Google I/O 2026 開発者向けハイライト（当ブログ）