2026年10月19日訂正：旧版は、ツールを登録する JavaScript API を
navigator.modelContext.registerToolと書いていました。WebMCP の仕様の原稿では、2026年5月27日に登録の入口がNavigatorからDocumentに移っており、現在の Chrome の文書もdocument.modelContext.registerToolを使っています。表の該当箇所を直しました。あわせて、宣言型の HTML 属性は Chrome の実装にはあるものの仕様の原稿にはまだ入っていないこと、オリジントライアルの期間と Microsoft Edge の対応、取り消しにくい操作に付けるconsequentialHintなどの注釈を追記しました。
「AI に予約を頼んだら、なぜかうちのサイトだけ最後まで進めなかった」——こうした相談が、これから増えていきます。ユーザーが自分でクリックするのではなく、ブラウザの中にいる AI エージェント（Gemini in Chrome など）が、本人の代わりにサイトを操作して予約・購入・問い合わせを完了する。その入口で、エージェントが「どこを押せばいいか分からず」に詰まると、競合サイトに流れます。これは検索順位とは別の、新しい「取りこぼし」です。
その状況を変えうるのが、Chrome 149 で始まった WebMCP のオリジントライアル です。WebMCP（Web Model Context Protocol）は、サイト側が「エージェントが呼び出せる操作（ツール）」を構造化して宣言できるようにする新しいブラウザ API です。Anthropic の MCP をブラウザに持ち込む発想で、Google と Microsoft が W3C のコミュニティグループで共同提案しています。サーバー側で AI と外部システムをつなぐ MCP の全体像は MCP 完全ガイド（GH Media） で解説していますが、WebMCP はそれを「自社サイトの画面そのもの」に適用する話だと考えてください。
エージェントが「画面を推測する」のをやめさせる
いまのブラウザエージェントは、人間と同じように画面のスクリーンショットや DOM を見て、「たぶんこのボタンが予約だろう」と推測しながら操作します。推測なので、独自レイアウトのサイトや、JavaScript で複雑に組まれた画面では失敗します。「人間には分かるが、エージェントには分かりにくい」サイトほど、エージェント経由のコンバージョンを落とすわけです。
WebMCP は、この推測をやめさせます。サイトが「これが検索ツール」「これがカートに追加するツール」「これが予約確定するツール」と名前と引数を付けて明示すれば、エージェントは推測ではなく宣言された操作を直接呼びます。Chrome のドキュメントでは、提供手段として大きく 2 つが示されています。
| 提供手段 | 使いどころ | イメージ |
|---|---|---|
JavaScript API（document.modelContext.registerTool） | 検索・絞り込み・カート操作など動的な処理 | 関数をツールとして登録する |
宣言的な HTML 属性（<form> に toolname・tooldescription を付ける） | 既にある問い合わせ・申込フォーム | フォームに「ツール」の意味付けを足す |
JavaScript API の入口は document.modelContext です。古い解説やサンプルには navigator.modelContext と書いたものが残っていますが、仕様の原稿は2026年5月に Document へ移しており、Chrome の文書の例も document.modelContext を使っています。もう一方の宣言的な HTML 属性は、Chrome の文書と実装にはあるものの、仕様の原稿では「別に検討中」とされ、まだ仕様には入っていません。フォームの属性は、JavaScript API よりも名前や動きが変わる可能性が高いと考えておくのが安全です。登録したツールが動くかを納品前のテストで確かめる方法は、Playwright 1.64 で WebMCP のツールを試験した記事（GH Media） で扱っています。
ポイントは、既存の HTML フォームを土台にできることです。新しい巨大な仕組みを別途作るのではなく、いま動いているフォームや検索に「エージェント向けの意味付け」を足していく。この「まず動く HTML があって、その上に機能を載せる」順番は、HTML ファーストでのリビルド（GH Media） で扱った発想とも一貫しています。
「端末内 AI」とは別の話 — 役割を取り違えない
ここで混同しやすいのが、Chrome の組み込み AI（端末内で動く Prompt API など）との違いです。組み込み AI は Chrome 組み込み AI で「サーバー不要の AI 機能」を作る受託（GH Media） で扱ったように、サイトが AI の機能を使う話です。一方 WebMCP は逆方向で、サイトが AI エージェントに使われるための入口を用意する話です。
| 観点 | 組み込み AI（Prompt API 等） | WebMCP |
|---|---|---|
| 向き | サイト → AI を呼ぶ | AI エージェント → サイトを呼ぶ |
| 目的 | サイト内に AI 機能を足す | サイトの操作をエージェントに開放する |
| 受託での価値 | 要約・補助などの新機能 | エージェント経由 CV の取りこぼし防止 |
この役割の違いを取り違えると、「AI チャットを置いたから WebMCP 対応済み」といった的外れな設計になります。受託では、ここをまず正しく切り分けます。
受託で提供する「エージェント対応サイト」整備
WebMCP はまだオリジントライアル（時限つきの先行実装）の段階で、仕様も動いています。Chrome Status によると、Chrome のオリジントライアルは当初 Chrome 149〜156 の予定で、Chrome 162 までの延長が申請されています（2026年10月19日時点）。Microsoft Edge でも Edge 150 からオリジントライアルが始まっており、登録ページの期限は2027年3月30日です。登録の入口が navigator から document に移ったように、名前や細部は今後も変わりえます。だからこそ、いきなり全面対応ではなく、「壊れない範囲で先行し、標準化に追従できる形で作る」進め方が現実的です。弊社の受託では次の順で組み立てます。
CVに近い操作から「ツール」にする
まず棚卸しするのは、売上に近い操作（検索 → 在庫確認 → 申込・予約確定）です。あるサービス予約サイトのクライアントでは、まず「空き枠検索」と「予約確定」の 2 つだけをツールとして宣言し、それ以外は従来どおりにしました。全画面を一度にエージェント対応にする必要はなく、詰まると一番痛い導線から開放するのが費用対効果の高いやり方です。
「人間が使えなくなる」改修にしない
エージェント対応のために独自マークアップを増やしすぎて、通常のユーザーや既存のアクセシビリティが壊れると本末転倒です。WebMCP の宣言はあくまで既存 HTML への上乗せにとどめ、人間が JS なしでも操作できる土台は維持します。アクセシビリティの基礎は Web アクセシビリティ対応ガイド（GH Media） を併読してください。
権限と確認のガードレールを設計する
エージェントが「予約を確定する」「支払う」といった取り消しにくい操作を呼べる以上、誰の許可で・どこまで実行してよいかの設計が要ります。Chrome の WebMCP のツールセキュリティ の文書は、登録時の annotations に目印（ヒント）を付けるよう勧めています。
| annotations のキー | 付ける対象 | 期待される効果 |
|---|---|---|
consequentialHint: true | 予約の確定・送金など、取り消しにくい操作 | エージェントやブラウザーが実行前にユーザーの確認を求められる |
readOnlyHint: true | 空き枠の検索など、状態を変えない操作 | 確認が要るかどうかをエージェントが判断しやすくなる |
untrustedContentHint: true | 口コミや外部データなど、信頼できない内容を返す操作 | 返した内容を慎重に扱うよう、エージェントに伝える |
ただし、名前のとおりこれらは目印で、確認を出すかどうかはエージェントやブラウザー側が決めます。同じ文書も、LLM の中で安全を保証することはできないと注意しています。受託では、確定前の確認ステップ・サーバー側の検証・実行ログを必ず噛ませ、「エージェントが勝手に確定して事故る」状態を作りません。AI に操作させる際の透明性の作り方は AI 機能の透明性 UI を受託で設計する（GH Media） も参考になります。
いま着手する意味 — 「様子見」のコスト
「標準が固まってからでいい」という判断も一見合理的ですが、エージェント経由の流入は、検索流入と同じく先に対応したサイトが体験として選ばれます。オリジントライアルの段階で、CV に近い 1〜2 操作だけでも宣言しておけば、エージェントから見て「ちゃんと使えるサイト」になり、仕様確定後の本対応もスムーズです。逆に様子見を続けると、エージェントが詰まる側に置かれたまま、気づかない取りこぼしが積もります。
まとめ — 「人が見て分かる」だけでは足りなくなる
これまでサイトは「人間が見て分かる」ように作れば十分でした。これからは、ブラウザ内のエージェントが正確に呼べることも、コンバージョンを左右する要素になります。WebMCP は、その入口をサイト側から用意するために提案されている標準です。受託で取り組むなら、CV に近い操作から少数だけツール宣言し、人間の体験を壊さず、確定操作には確認とログのガードレールを噛ませる——この最小構成から始めるのが、リスクを抑えて先行する現実的な一手です。
「自社サイトがエージェント経由で詰まっていないか確かめたい」「WebMCP のオリジントライアルを小さく試したい」というご相談は お問い合わせフォーム からどうぞ。CV 導線の棚卸しから着手できます。
Sources
- Join the WebMCP origin trial（Chrome for Developers）
- WebMCP tool security（Chrome for Developers）
- WebMCP（Chrome for Developers）
- WebMCP Imperative API（Chrome for Developers）
- WebMCP Declarative API（Chrome for Developers）
- WebMCP 仕様の原稿（W3C Web Machine Learning Community Group）
- WebMCP の実装状況（webmachinelearning/webmcp）
- WebMCP（Chrome Platform Status）
- WebMCP origin trial（Microsoft Edge Origin Trials）
- Inside WebMCP: how Google’s new browser API lets websites talk to AI agents natively（Rankly）
- MCP 完全ガイド（GH Media）
- Chrome 組み込み AI で「サーバー不要の AI 機能」を作る受託（GH Media）
- AI 機能の透明性 UI を受託で設計する（GH Media）
- Playwright 1.64 で WebMCP のツールを試験（GH Media）
