WebMCPのregisterTool手順と制限

ブラウザエージェントが画面をクリックして操作するという前提では、ラベルの揺れやUI改修によってすぐに失敗します。WebMCPは、開いているページが自らツールを公開し、エージェントがそれを発見して実行するという契約です。サーバー側のMCPを捨てる話ではありません。

📑目次

1. WebMCPはページ内ツール公開でありMCPの置き換えではない
2. registerToolと宣言的フォームの使い分け
3. Chrome Origin Trial 149で検証する手順
4. WebMCP・サーバーMCP・画面操作の比較
5. 採用前に確認する制限とツール安全性
6. 筆者の観点
7. よくある質問
8. まとめ

切り分けは次の通りです。

• ログイン中のタブ状態を使いたいなら WebMCP
• ヘッドレスのバックエンド連携なら既存 MCP

Chrome 149 からの Origin Trial、または chrome://flags/#enable-webmcp-testing で、読み取り専用の look ツール 1 本から検証できます。

---

WebMCPはページ内ツール公開でありMCPの置き換えではない

WebMCP は、ページの JavaScript 関数を name / description / JSON Schema / execute として公開する API です。W3C WebMCP 草案 は、このページを「クライアント側でツールを実装する MCP サーバー」に例えます。呼び出す側はブラウザ内エージェントや支援技術で、人間と同じ画面を見ながら作業を委譲します。

目標は、スクリーンショットや DOM クリックの推測を減らすことです。公式 GitHub の Non-Goals は、人間監視なしの完全自律、ヘッドレス主用途、バックエンド MCP の置換、人間 UI の廃止を否定します。サーバー MCP はブラウザセッション外の API です。WebMCP のツールは開いているタブのログイン、カート、フィルタ、未保存の下書きを継承します。

判断は単純です。タブ内の状態が必要ならWebMCPを、タブ外の社内APIやバッチ処理ならMCPを使います。両方必要なら役割を分けます。ホスト・クライアント・サーバーの役割そのものは関連記事のMCP認証解説に任せ、ここではブラウザAPIと採用判断に限定します。

---

registerToolと宣言的フォームの使い分け

命令形 registerTool

命令形は document.modelContext.registerTool です。

• ツール名は 1〜128 文字で、ASCII 英数字と _ - . に限られます。
• 解除は登録時に渡した AbortSignal の abort() です。Chrome 153 以降は、飛行中の実行を壊さずに unregister できます。
• 発見は getTools()、実行は executeTool(tool, jsonString) です。
• 既定の発見範囲は同一オリジンです。クロスオリジンは fromOrigins と exposedTo の両方が必要です。

const controller = new AbortController();
await document.modelContext.registerTool({
  name: "search_catalog",
  description: "Search products currently visible on this page.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "Search keyword" }
    },
    required: ["query"]
  },
  annotations: { readOnlyHint: true },
  execute: async ({ query }) => JSON.stringify({ query, matches: [] })
}, { signal: controller.signal });

---

宣言的フォーム

宣言形は既存の HTML フォームに toolname と tooldescription を付けます。エージェントはフォームにフォーカスして入力します。既定は人間が Submit します。自動送信は toolautosubmit が必要です。送信側は SubmitEvent.agentInvoked と respondWith() で結果を返せます。静的な検索や問い合わせは宣言形、動的なフィルタや状態変更は命令形、が実務の境界です。

出典：Chrome Imperative API、Chrome Declarative API、W3C WebMCP draft（2026年9月時点）

---

Chrome Origin Trial 149で検証する手順

本番トークンを付ける前に、ローカルで 1 ツールを動かします。

ローカル検証の手順

1. WebMCP Origin Trial に登録する（Chrome 149 から）。
2. ローカル検証なら chrome://flags/#enable-webmcp-testing を Enabled にして再起動する。
3. Model Context Tool Inspector で登録ツールの一覧、スキーマ、手動実行を確認する。既定モデルは gemini-3-flash-preview です。
4. 最初のツールは状態を変えない look（JSON で現状を返す）にする。

---

公開期間

独立ソースは公開 OT を Chrome 149〜156 と記載します（No Hacks、Spronta）。終了後はフラグと Chrome Status を再確認してください。

---

API移行と制限

APIの移行ポイントは次の通りです。

• エントリは document.modelContext です。navigator.modelContext は Chrome 150 で非推奨エイリアスです。
• provideContext / clearContext は第三者スクリプトが全上書きできるため削除されました。
• registerTool は追加型で、同名は throw します。

制限は次の通りです。

• Origin isolation が必須です。document.domain が有効、または Origin-Agent-Cluster: ?0 では API が無効になります。
• tools Permissions Policy の既定は self です。クロスオリジン iframe は allow="tools" が必要です。

出典：Chrome WebMCP（概要 2026-08-07 更新）、Jangwook の OT 分析

---

WebMCP・サーバーMCP・画面操作の比較

採用判断は「どこで実行し、どのセッションを使うか」です。画面操作エージェントは WebMCP 未対応サイトのフォールバックに残します。サイト作者が契約したツールがあるなら、クリック推測より失敗が少ないです。

方式	実行場所	セッション	向く作業	向かない作業
WebMCP	開いているページの JS / form	ログイン中のタブ状態を継承	フィルタ、下書き、サポートフォーム、look/act	ヘッドレス一括、ブラウザ非表示のバッチ
サーバー MCP	バックエンド API	別途認証・状態複製が必要	サーバー側検索、社内 API、ヘッドレスエージェント	カートや画面上の未保存 UI 状態
スクリーンショット / a11y 操作	視覚・DOM 推測	ページを見るがサイト作者が契約しない	WebMCP 未対応サイトのフォールバック	ラベル曖昧・UI 改修が多い画面

lookとactの分け方

出典（2026年8〜9月時点）:

• WebMCP GitHub
• Chrome WebMCP
• HackerNoon
• Tarsk

公開ツールは look（JSON で状態を返す）と act（UI を変える）に分けます。act のうち購入・削除・送信は確認ダイアログ必須です。Tarsk は、Shopify ホストストアフロントが WebMCP を有効化した一方、決済ツールは出さず人間確認に残したと報告しています。ChatGPT デスクトップ側のサイトツール実装は関連記事で扱っています。

---

採用前に確認する制限とツール安全性

Chrome は LLM 内部の安全を保証できない、と明記します。UGC や外部データは untrustedContentHint: true、状態を変えないツールは readOnlyHint: true です。説明 500、パラメータ説明 150、名前 30、1 ツール出力 1.5K 文字が目安です。既定では他サイトやクロスオリジン iframe はツールを見ません。exposedTo は信頼できる https オリジンだけにします。

ツール説明や結果にプロンプト注入を載せうるという指摘は、独立した出典でも共通しています。高コストの操作は確認の後ろに置きます。クライアントがサイトを直接開かないとツールは見えません。ヘッドレス前提の運用には向きません。仕様はW3C Web Machine Learning Community Groupの草案であり、Standards Trackではありません。Edgeのネイティブ対応は、独立ソース時点では未確認です。

• ✓ Origin Trial または flags で Inspector から 1 ツール実行できた
• ✓ look と act を分け、act の破壊的操作に確認がある
• ✓ untrustedContentHint / readOnlyHint を付けた
• ✓ exposedTo を最小にした（または付けない）
• ✓ サーバー MCP で足りる処理を WebMCP に載せていない

出典：Chrome secure tools（2026-07-01 更新）、botmonster

---

筆者の観点

採用の分岐点はAPIの新しさではなく、タブ内状態が必要かどうかです。カートやフィルタをサーバーMCPに複製してからエージェントに渡すより、ページがlookツールを直接出す方が差分は小さくなります。逆に、夜間バッチやヘッドレス巡回をWebMCPに乗せると、人間のタブを前提とするため運用が壊れます。

最初の実装は read-only の look 1 本に限定するのが安全です。act を足すときは、購入・削除・外部送信を同じツールに混ぜないことです。Origin Trial 中はフラグとトークンの期限をドキュメントに残し、終了後に Chrome Status を再確認する運用が必要です。

---

よくある質問

採用判断

Q. WebMCP は MCP サーバーを捨ててよいか？

A. いいえ。GitHub の Non-Goals はバックエンド MCP の置換を否定します。タブ外の API は MCP、タブ内 UI は WebMCP です。

Q. いま本番に載せてよいか？

A. Community Group draft であり Standards Track ではありません。Chrome は Origin Trial です。フラグ検証と確認ダイアログなしの本番公開は避けてください。

---

実装の境界

Q. 宣言的フォームだけで足りるか？

A. 既存 HTML フォームの入力・送信なら足ります。動的な状態変更は registerTool です。自動送信は toolautosubmit が必要です。

Q. Chrome 以外は使えるか？

A. 公式の公開 OT は Chrome 149 からです。Edge ネイティブは独立ソース時点で未確認です。他ブラウザは GitHub の Implementation Status を見てください。

Q. クロスオリジン iframe でツールを出していいか？

A. 既定では不可です。allow="tools" と exposedTo の両方が必要です。ユーザーデータを渡す相手と同じ基準でオリジンを選んでください。

---

関連記事:

• ChatGPT デスクトップと Sites に WebMCP — Codex がサイト内ツールを直接使う
• MCPのホスト・クライアント・サーバーとは？役割と認証方式の選び方【2026】

まとめ

WebMCP はページ作者が契約した in-page ツールであり、クリック推測より失敗が少ないです。MCP の上位互換ではありません。次の作業は次の順です。flags または OT で look ツール 1 本を Inspector 実行する。act は確認付きにする。サーバー MCP と役割分担を文書化する。仕様と Chrome ドキュメントが動いているので、公開前に OT 期間と API 名を再確認してください。