「最近、問い合わせ件数は落ちていないのに、予約フォームの完了率だけがじわじわ下がっている気がする」——飲食と物販を手がける会社の経営者から、こんな相談を受けました。原因を一つに特定はできませんでしたが、話すうちに一つの仮説が浮かびました。利用者が自分でサイトを操作するのではなく、スマホのAIアシスタントに「この店、金曜の夜に予約しといて」と頼むケースが、少しずつ増えているのではないか、という仮説です。
AIとサイトの関係は、いま大きく変わりつつあります。これまで語られてきた「AI対応」は、検索AIに自社の情報を正しく読ませ、引用してもらうための備えでした。ところが2026年、話はもう一段進みました。ブラウザに組み込まれたAIエージェントが、人の代わりにサイトを操作し、検索・絞り込み・カート投入・フォーム送信まで代行する。その土台となる WebMCP という新しい仕組みが、Chrome で試験提供に入っています。本記事では、この変化が中小企業のサイトに何を意味するのかを、実装の細部ではなく「取りこぼしを防ぐ経営判断」の視点で整理します。
「読ませるAI対応」と「操作させるAI対応」は別物
まず、混同しやすい二つを分けます。ここ数年で企業サイトが取り組んできたAI対応は、大きく言えば「読ませる」対応でした。検索AIに正確な情報を渡し、AI Overview のような要約に正しく引用されるよう構造化データを整える。この考え方はAI Overview時代のSEO戦略や、AIに要点を渡すllms.txt の記事で扱ってきたとおりです。
一方、WebMCP が扱うのは「操作させる」対応です。AIエージェントがサイトに来たとき、ボタンやフォームを画面の見た目から推測して操作するのではなく、サイト側が「ここで検索できます」「これが予約フォームです」と、機械が確実に呼び出せる形で自分の機能を差し出す。読ませる対応が「案内図を置く」ことなら、操作させる対応は「操作パネルを正式に用意する」ことに近いと言えます。
なぜこれが重要かというと、AIエージェントが画面の見た目だけを頼りに操作すると、取りこぼしや誤操作が起きるからです。人間には自然に見えるボタンでも、機械にとっては「押していいのか分からない画像」に見えることがあります。実際、構造化された呼び出しを用意した場合、見た目からの推測に頼る方式に比べて操作の失敗が大きく減るという計測結果も報告されています。予約や購入の一歩手前で機械が迷えば、それはそのまま機会損失になります。
WebMCP で何が変わるのか
WebMCP（Web Model Context Protocol）は、Google と Microsoft のエンジニアが W3C のコミュニティで提案している、ブラウザの標準候補です。サイトが自分の機能を、ブラウザ内のAIエージェントに対して「呼び出せる道具」として公開できるようにします。公開のしかたは大きく二通りです。
| 公開のしかた | 向いている対象 | イメージ |
|---|---|---|
| 画面の裏側で道具を登録する方式 | 検索・絞り込み・カート操作など動的な処理 | 「在庫検索」「カートに追加」を機能として差し出す |
| 既存フォームに印をつける方式 | すでにある問い合わせ・予約フォーム | フォームに「これは予約用」と目印を足す |
重要なのは、後者のように、いまあるフォームに目印を足すだけでも第一歩になる、という点です。サイトを丸ごと作り直す話ではありません。Chrome 149 で試験提供（オリジントライアル）が始まり、他のブラウザも年内から対応を表明しています。つまり、まだ全利用者に効く段階ではないものの、方向性は固まりつつあるということです。「AIエージェント対応かどうか」を外形的に診断する動きは、以前サイトのエージェント対応診断の記事でも取り上げましたが、WebMCP はそれを「診断」から「実装の標準」へ一歩進めるものです。
慌てて全部対応する必要はない、が「入口」は今から
とはいえ、まだ試験段階の仕様に、いま全力投資すべきかというと、そうではありません。経営判断として現実的なのは、優先順位をつけることです。自社サイトの中で、AIエージェント経由の来訪が売上や問い合わせに直結する「入口」はどこか。予約なのか、見積もり依頼なのか、商品の在庫確認なのか。そこを見極め、まずはその一か所から、機械にも分かる形で差し出せるように整える。これが費用対効果の高い順番です。
ここで見落としてはいけないのが、機能を機械に差し出すということは、攻撃の入口も増えるという事実です。AIエージェントに「予約する」という道具を渡すなら、それが悪用されて大量の空予約を入れられないか、意図しない操作を実行させられないか、という設計上の配慮が要ります。便利さと安全性は必ずセットで考える必要があり、ここは自己流でやると事故につながりやすいところです。
事例: 予約フォームに「目印」を足すところから始めた会社
具体例を挙げます。宿泊業の会社（社名は伏せます）から、「AI経由の予約が今後増えると聞いたが、何から手をつければいいのか」という相談を受けました。サイト全体をエージェント対応にするのは大がかりで、費用も読めません。そこで、いきなり全面対応はせず、いちばん売上に近い予約フォーム一つに絞りました。
やったことは大きく二つです。まず、既存の予約フォームに「これは予約を受け付ける機能だ」という機械向けの目印を足し、AIエージェントが迷わず呼び出せる状態にしました。次に、その入口が悪用されないよう、送信回数の制限や確認の仕組みを合わせて設計しました。効果をすぐに数字で断言できる段階ではありませんが、少なくとも「AIエージェントが来ても操作できずに離脱する」という取りこぼしの芽は、いちばん大事な一か所から潰せました。ここで大事だったのは、全部を先回りして作り込まなかったことです。売上に直結する入口を一つ選び、そこだけを確実に、安全とセットで対応した。この絞り込みが、試験段階の技術に無駄な投資をしないコツでした。
まず「AI経由で来てほしい操作」を一つ決める
AIエージェントが人の代わりにサイトを操作する流れは、まだ始まったばかりですが、方向は固まっています。慌てて全面対応する必要はありません。着手するなら、まず自社サイトの中で「AIエージェント経由で来てほしい操作」を一つだけ決めてください。予約、見積もり依頼、在庫確認——売上や引き合いに最も近い操作はどれか。そこを、機械にも分かる形で、かつ悪用されない形で差し出せるように整える。この一点集中が、投資を無駄にせず時代の変化に乗る現実的な第一歩です。
自社サイトがAIエージェントの来訪に対応できているか診断したい、予約や問い合わせの入口だけ先に整えたい、対応にあたって悪用のリスクも一緒に潰したい——そうしたご相談があれば、グリームハブの開発・AI・自動化のご相談窓口からお気軽にお問い合わせください。売上に近い入口の見極めから、安全性とセットにした実装まで、御社の優先順位にあわせてご一緒します。
