「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（navigator.modelContext.registerTool） | 検索・絞り込み・カート操作など動的な処理 | 関数をツールとして登録する |
| 宣言的な HTML 属性（既存フォームへの注釈） | 既にある問い合わせ・申込フォーム | フォームに「ツール」の意味付けを足す |
ポイントは、既存の 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 はまだオリジントライアル（時限つきの先行実装）の段階で、仕様も動いています。だからこそ、いきなり全面対応ではなく、「壊れない範囲で先行し、標準化に追従できる形で作る」進め方が現実的です。弊社の受託では次の順で組み立てます。
CVに近い操作から「ツール」にする
まず棚卸しするのは、売上に近い操作（検索 → 在庫確認 → 申込・予約確定）です。あるサービス予約サイトのクライアントでは、まず「空き枠検索」と「予約確定」の 2 つだけをツールとして宣言し、それ以外は従来どおりにしました。全画面を一度にエージェント対応にする必要はなく、詰まると一番痛い導線から開放するのが費用対効果の高いやり方です。
「人間が使えなくなる」改修にしない
エージェント対応のために独自マークアップを増やしすぎて、通常のユーザーや既存のアクセシビリティが壊れると本末転倒です。WebMCP の宣言はあくまで既存 HTML への上乗せにとどめ、人間が JS なしでも操作できる土台は維持します。アクセシビリティの基礎は Web アクセシビリティ対応ガイド（GH Media） を併読してください。
権限と確認のガードレールを設計する
エージェントが「予約を確定する」「支払う」といった取り消しにくい操作を呼べる以上、誰の許可で・どこまで実行してよいかの設計が要ります。Chrome 側も WebMCP のツールセキュリティ で、信頼できないツール呼び出しへの注意を促しています。受託では、確定前の確認ステップ・サーバー側の検証・実行ログを必ず噛ませ、「エージェントが勝手に確定して事故る」状態を作りません。AI に操作させる際の透明性の作り方は AI 機能の透明性 UI を受託で設計する（GH Media） も参考になります。
いま着手する意味 — 「様子見」のコスト
「標準が固まってからでいい」という判断も一見合理的ですが、エージェント経由の流入は、検索流入と同じく先に対応したサイトが体験として選ばれます。オリジントライアルの段階で、CV に近い 1〜2 操作だけでも宣言しておけば、エージェントから見て「ちゃんと使えるサイト」になり、仕様確定後の本対応もスムーズです。逆に様子見を続けると、エージェントが詰まる側に置かれたまま、気づかない取りこぼしが積もります。
まとめ — 「人が見て分かる」だけでは足りなくなる
これまでサイトは「人間が見て分かる」ように作れば十分でした。これからは、ブラウザ内のエージェントが正確に呼べることも、コンバージョンを左右する要素になります。WebMCP は、その入口をサイト側から用意するための標準です。受託で取り組むなら、CV に近い操作から少数だけツール宣言し、人間の体験を壊さず、確定操作には確認とログのガードレールを噛ませる——この最小構成から始めるのが、リスクを抑えて先行する現実的な一手です。
「自社サイトがエージェント経由で詰まっていないか確かめたい」「WebMCP のオリジントライアルを小さく試したい」というご相談は お問い合わせフォーム からどうぞ。CV 導線の棚卸しから着手できます。
