この記事は、経営層や事業責任者の方に向けて書いています。「利用者が自分専用のAIエージェントを使うようになったら、自社サイトの役割はどう変わるのか」を、事業の視点で考えるための材料です。読み終えると、どの接点をAIに開くかを、自社で整理し始められます。
先に断っておきます。これは未来の予測ではなく、「そうなったとき」という仮説です。根拠となる仕様（WebMCP）は、まだ草案の段階で、内容が変わり続けています。数字や普及の見通しは書きません。仕様の全体像は、WebMCPとは何か：AIエージェントに対応するWebサイトの考え方にまとめています。
いまのWeb：人が画面を見て、自分で操作する
いまのWebは、人が画面を見て動かす前提でできています。検索し、複数のページを開き、見比べ、迷い、申し込みます。サイトの文章、写真、配置、導線は、すべて人の目と手のために設計されています。
この前提では、サイトを訪れる人は「自分で調べる人」です。事業者は、その人の注意を引き、納得してもらうことに力を注いできました。
パーソナルエージェントが広がると、この前提の一部が動きます。調べる、比べる、手続きを進める、といった作業を、利用者に代わってAIが行う場面が出てきます。どこまで広がるかは、現時点では分かりません。
エージェントが代わりに行う流れ（架空の例）
次は架空の例です。実在の企業やサービスとは関係ありません。
架空の例：ある人が、エージェントに「来月の家族旅行で使う、荷物が多くても入るレンタカーを探して」と頼みます。エージェントは、その人の好みと予定を踏まえて候補を集め、条件を比べます。候補を三つに絞って理由を添え、最後に「この一台で予約を進めてよいですか」と本人に確認します。本人が了承すると、手続きが進みます。
この流れで大切なのは、最後に人が確認していることです。仕様の草案も、人が関わる使い方を主に想定しています。Chromeの資料も、ローカルのブラウザで人が関わる使い方を主に想定する、と述べています。完全に任せきりの世界を前提にしたものではありません。
もう一つ、エージェントがサイトを使うやり方は、いまは画面の読み取りと操作が中心です。WebMCPは、サイト側が「できること」を道具（ツール）として差し出し、エージェントがそれを呼ぶ、という別のやり方を提案しています。ツールは、名前、説明、入力の形、実行する処理の組です。
変わるかもしれない点：四つの接点
仮説として、変わりうる点を四つに分けます。どれも「そうなったとき」の話で、確定した変化ではありません。
| 接点 | いま | エージェントが入ると |
|---|---|---|
| 見つけ方 | 検索結果や広告から、人がページを開く | エージェントが候補を集める。事業者の情報が、機械に読み取れる形かどうかが問われる |
| 比較のされ方 | 人が複数ページを見比べる | 条件ごとに、エージェントが並べて整理する。曖昧な表現は比べにくい |
| 購入までの導線 | 人が画面の順に進む | エージェントが手続きを代行しうる。確認の場面をどこに置くかが論点になる |
| ブランドの伝わり方 | デザインや文章の印象で伝わる | 画面を見ない場面が増えうる。説明文やルールの書き方にも、ブランドが出る |
見つけ方と比較のされ方
エージェントは、人のように雰囲気で選ぶとは限りません。料金、条件、対応範囲といった事実が、はっきり書かれているサイトのほうが、扱いやすいと考えられます。逆に、問い合わせないと分からない情報は、比較の土俵に載りにくくなるかもしれません。
これは、自社の強みが数字だけでは伝わらない場合に、悩ましい点です。人が読む場面とAIが読む場面で、伝え方を分ける必要が出てきます。
購入までの導線とブランド
手続きをエージェントが進めるなら、入力欄の分かりやすさや、確認画面の位置が重要になります。迷わせない設計は、人にもAIにも効きます。
ブランドについては、Chromeの資料も、ブランドや人間中心のデザインを保つことを勧めています。AIが使う入口があっても、人が見る画面の価値は残ります。
サイト側に起きる変化：AI向けの入口と、情報の出し方
サイト側では、二つの準備が考えられます。一つは「AI向けの入口」、もう一つは「コンテンツの提供の仕方」です。
入口とは、サイトの機能を、エージェントが呼べる形にすることです。WebMCPの草案では、ページ内のスクリプトでツールを登録します。窓口は document.modelContext です。登録できる機能は、検索、予約の空き確認、見積もりの目安の算出などです。
情報の出し方とは、料金や条件、よくある質問を、正確で更新しやすい形に整えることです。これは、WebMCPを使わない場合でも役に立ちます。
| 準備 | 中身 | WebMCPがなくても有効か |
|---|---|---|
| 情報の整理 | 料金、条件、対応範囲を、一か所に正確に書く | 有効 |
| 入力のしやすさ | フォームの項目名と選択肢を、明確にする | 有効 |
| 機能の公開 | 検索や予約などを、ツールとして登録する | 対応するエージェントがあれば使われる |
| 確認の設計 | 重要な操作の前に、人の確認を置く | 有効 |
Chromeの資料は、WebMCPを、あれば使われ、なくても動く「プログレッシブエンハンスメント」として扱うことを勧めています。つまり、いまの画面を壊さずに、あとから足せる位置づけです。
なお、HTMLのフォームに注釈を付けてツールにする方式（宣言的API）が、Chromeの資料では紹介されています。ただ、W3Cの草案の本文には、まだありません。ここも変わりうる部分です。
社内で分かれやすい意見
この話題は、部署によって受け止め方が分かれます。営業は「問い合わせが減るのでは」と心配し、開発は「何を作ればよいのか」と迷い、法務は「責任の所在」を気にします。どれも自然な反応です。
大切なのは、全員が同じ未来像を信じることではありません。「こうなったら、自社はどう動くか」を、仮説として共有しておくことです。仮説が外れても、情報の整理や確認の設計は残ります。
画面を見ない利用者への説明
エージェント経由で来る利用者は、サイトの画面を見ないまま、結論だけを受け取るかもしれません。その場合、説明文の短さや正確さが、そのまま事業者の印象になります。ツールの名前や説明文も、人が読んで意味が通る言葉で書くのが望ましいでしょう。
変わらない点：最終判断と責任は人にある
エージェントが増えても、変わらないものがあります。
- 最終判断は人：購入や契約のような重い決定は、本人の確認を挟む設計が自然です。
- 責任は事業者にも残る：サイトが差し出す情報や機能が誤っていれば、利用者の信頼を損ないます。
- 信頼が選ばれる理由になる：正確で、約束を守る事業者であることは、人にもAIにも伝わります。
草案には、重要な操作を示す注釈（consequentialHint）があります。実世界への影響や取り消せない操作、たとえば航空券の予約や送金を示すものです。これを見て、エージェント側が確認を求めることができます。ただし、草案の本文は、ツール実行時の確認を必須とは定めていません。確認をどう出すかは、クライアント側の設計に委ねられています。
つまり、「確認を置く」責任は、サイト側でも考えておく必要があります。仕様に任せきりにできない、と受け取ってください。
経営の問い：自社のどの接点をAIに開くか
ここからは、経営会議で使える問いです。技術の細部ではなく、事業の判断として考えます。
- 自社の顧客は、いまどこで調べ、どこで決めているか。
- その中で、AIに任せても困らない作業はどれか。
- AIに任せると困る作業（高額、取り消せない、個別事情が大きい）はどれか。
- AIに開く接点では、どの情報を正確に出し、何を人の確認に残すか。
- 画面を見ない場面でも、自社らしさを伝える言葉は何か。
開く接点を絞ることは、守りでもあります。草案は、プロンプトインジェクション（ツールの説明や出力に紛れた悪意ある指示）や、宣言と実際の動作が一致しない恐れなどを、リスクとして挙げています。最初は、読み取りだけの機能や、影響の小さい操作から始めるほうが安全です。
準備の第一歩
最初から完成形を目指す必要はありません。小さく試し、分かったことを次の判断に使うのが現実的です。
大きな投資をする前に、次の小さな作業から始められます。
- 顧客の接点を書き出す：問い合わせ、見積もり、予約、購入、アフターサポートを並べます。
- 情報を点検する：料金、条件、よくある質問が、最新で、矛盾していないかを確認します。
- AIに開く候補を一つ選ぶ：読み取りだけで済み、間違っても影響が小さいものを選びます。
- 人の確認を置く場所を決める：どの操作の前に、本人に確認するかを決めます。
- 試せる環境で検証する：ChromeにはDevToolsでツールを確認できる機能があります。本番の前に、社内で試します。
設計の細かい進め方は、別の記事で扱います。また、進める順番は会社によって違います。顧客の動きが読みやすい事業から、試すとよいでしょう。ここでは、事業側が最初に決めることに絞りました。
注意点：分からないことが多い
- 仕様は変動中：Chromeの資料は、議論の最中で変更されうると明記しています。
- 対応状況：Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 利用の広がり：どれだけの人がエージェントを使うかは、現時点では不明です。この記事は仮説であり、予測ではありません。
- 安全面：宣言した内容を検証する手段が、現状ではありません。サイトの善意を前提にしている面があります。
- 専門家への確認：個人情報、契約、法務に関わる設計は、専門家に確認してください。
Otsumuに相談できること
棚卸しや情報の整理、AIに開く接点の候補出しまでは、社内で進められます。顧客の動きを一番知っているのは、事業の担当者だからです。
実際に機能をツールとして公開する、確認の流れを設計する、既存システムとつなぐ段階では、技術と事業の両方の判断が要ります。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一部として設計や実装をお手伝いできます。
詳しくはAIエージェント開発をご覧いただくか、お問い合わせからご相談ください。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日です。WebMCPの仕様は変動中のため、最新の内容は各資料でご確認ください。参照元：WebMCP 仕様草案（W3C Web Machine Learning Community Group）、WebMCP 提案のリポジトリ、Chrome の WebMCP 公式資料。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20