「取引先を探して、この会社の問い合わせフォームから見積もりを依頼しておいて」——ユーザーがAIアシスタントにこう頼み、エージェントが代わりにあなたの会社のサイトを開いてフォームを埋める。まだ日常ではありませんが、2026年に入ってこの方向への地固めが一気に進みました。ここで問題になるのが、いまのWebサイトの多くは「人間が見て操作する」前提で作られていて、AIエージェントが確実に操作できる作りになっていないことです。
これまでエージェントは、画面の見た目（DOM）を推測してボタンや入力欄を当てにいっていました。これは当てずっぽうで、レイアウトが少し変わるだけで失敗します。Chrome 149 で試験公開（オリジントライアル）が始まった WebMCP は、この関係を逆転させ、サイト側から「ここはこう操作してほしい」を宣言できるようにする提案です。本記事では、これが何で、検索対策と何が違い、発注者がいま何を考えておくべきかを整理します。
WebMCP — サイトが「操作方法」をエージェントに渡す
WebMCP は、Web サイトが AI エージェント向けに構造化されたツールを公開するための仕組みです。エージェントに画面を推測させるのではなく、サイト側が「予約する」「カートに入れる」「問い合わせを送る」といった操作を、機械が確実に呼び出せる形であらかじめ用意します。用意のしかたには二つあります。
| 方式 | 内容 | 向くケース |
|---|---|---|
| 宣言的API | 既存のHTMLフォームに注釈を付けてツール化する | フォーム中心の一般的なサイト |
| 命令的API | JavaScript の関数としてツールを定義する | 複雑な操作・アプリ的なサイト |
考え方の根っこは、AI と外部ツールをつなぐ標準として広がった MCP（Model Context Protocol）と同じで、それをブラウザ上の Web サイトに持ち込んだものです（MCP そのものはMCP完全ガイドで解説しています）。エージェントは推測をやめ、サイトが宣言したツールを直接呼ぶので、動作が安定し、誤操作も減ります。
「検索で見つかる」対策とは別レイヤーの話
ここで混同しやすいのが、AI 検索対策との違いです。AI Overview 時代のSEOで扱うのは、AI に見つけてもらい・引用してもらうための取り組み——つまり「情報として読まれる」層の話です。一方 WebMCP が担うのは、AI に操作してもらう・取引してもらう層。予約を取る、フォームを送る、注文を確定する、といった行動をエージェントに任せられるようにする、まったく別のレイヤーです。
両者は競合せず、重なって効きます。まず検索・生成AIに見つけてもらい、そのうえでエージェントが迷わず操作できる。この二段構えが、これからの「AI に強いサイト」の姿になります。人間の来訪者だけでなく、その人の代理で来るエージェントという新しい来訪者を想定するかどうか、という発想の切り替えです。
発注者がいま考えておくこと — 焦らず、土台から
では今すぐ WebMCP を実装すべきかというと、そうではありません。まだオリジントライアル（試験公開）の段階で、対応ブラウザも仕様も動いています。ここに過剰投資するのは時期尚早です。いま賢いのは、WebMCP が普及しても慌てないための土台を先に整えることです。土台とは、特別な技術ではなく次のような「基本を正しくやる」ことです。
- フォームや主要な操作導線を、意味の通るマークアップ（セマンティックHTML）で組む
- 構造化データを整備し、何のページ・何のフォームかを機械が読み取れるようにする
- アクセシビリティを整える（ラベルの付いた入力欄は、人にもエージェントにも優しい）
これらは WebMCP を待たずに、いまの検索・AI 引用にもそのまま効きます。逆に、見た目だけを追ってマークアップが曖昧なサイトは、人間にもエージェントにも「操作しづらいサイト」のままです。新規制作やリニューアルを検討しているなら、将来エージェントに操作されることを前提に、土台を機械可読にしておく——この一点を発注要件に入れておくだけで、数年後の作り直しを避けられます。
自社サイトがこの流れに耐えられる作りか分からない、リニューアルの要件に「AI・エージェント対応」をどう織り込めばいいか整理したい——そうした段階であれば、グリームハブの開発・AI・自動化のご相談へお気軽にお声がけください。いまの土台の診断から、過剰投資を避けた段階的な対応方針までご一緒に描きます。
