この記事は、自社サイトを「人が見る場所」から一歩広げて考えたい、経営層や事業責任者に向けて書いています。WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を扱ってきたシリーズ全体を踏まえ、AI向けの入口づくりを、技術の話ではなく事業の再構築（リストラクチャ）の話として整理します。読み終えると、何をAIに開き、何を人が持ち、どの順で試すかを議論できるようになります。
WebMCPは草案の段階で、内容は変わり続けています。この記事の確認は2026年10月20日時点です。また、記事の前半に出てくる「パーソナルエージェントが当たり前に使われる世界」は、あくまで仮説です。確定した未来として書いているわけではありません。
シリーズの起点は、WebMCPの入門記事です。仕組みから知りたい方は、先にそちらをご覧ください。
前提となる仮説：エージェントが「訪問者」になる世界
ここで置く仮説は、次のとおりです。ひとりひとりの利用者が、自分の代わりに調べ、比べ、手続きを進めてくれるAIエージェント（利用者に代わって作業を進めるAI）を使うようになる。そうなれば、サイトを訪れるのは人だけではなくなる、という見方です。
これは仮説です。どのくらいの速さで、どこまで広がるかは、断定できません。確かなのは、Chromeが2026年にWebMCPのオリジントライアル（限定的な試験提供）を始めており、「エージェントがサイトの機能を使う」ことを前提にした仕組みが、実際に議論され、試されているという点です。
経営として大事なのは、仮説が当たるかどうかを言い当てることではありません。当たった場合と外れた場合の両方で、大きく困らない準備をしておくことです。小さな準備なら、外れても失うものは限られます。当たったときには、他社より早く動ける余地が残ります。この考え方が、以降の章の土台になります。
詳しくはパーソナルエージェントの記事をご覧ください。
「AI向けWeb」とは、入口を二つ持つこと
これまでのサイトは、人が目で見て、読んで、クリックする前提で作られてきました。再構築というのは、その画面を作り直すことではありません。人向けの画面はそのまま主役に置き、その横に、AI向けの入口を足すということです。入口は、大きく二種類に分けて考えると整理しやすくなります。
| 入口の種類 | 役割 | 主な手段 | 関連記事 |
|---|---|---|---|
| 読む入口 | AIが、自社の情報を正しく読み取れるようにする | 情報の整備、構造化データなど | 構造化データの記事、AI検索最適化の記事 |
| 操作の入口 | AIが、自社の機能を安全に呼び出せるようにする | WebMCP、MCP | WebMCPとMCPの違いの記事、業務向けMCPサーバーの記事 |
読む入口は、情報の整備です。商品、料金、手順、よくある質問といった、自社が持つ情報を、機械にも読みやすい形に整えます。これは、WebMCPの行方に関わらず自社に残る、土台の仕事です。ただし、検索エンジンやAIサービスが実際にどう扱うかは、この記事では断定できません。確認できていない部分は、確認できていないままにしておきます。
操作の入口は、サイトの機能をAIが使える形にすることです。WebMCPは、そのうち「利用者がブラウザでサイトを開いている場面」を対象にした提案です。一方のMCP（Model Context Protocol）は、AIアプリを外部のデータや機能につなぐための、オープンソースの標準です。Chromeの資料は、この二つを「競合ではなくパートナー」と位置づけ、MCPはバックエンドのサービス層、WebMCPはブラウザ内の接続という分担で説明しています。
操作の入口には、他の方法もあります。API連携、RPA（画面操作の自動化）、画面の読み取り（スクレイピング）などです。それぞれの向き不向きは、WebMCPとAPI・RPA・スクレイピングを比べた記事にまとめています。どれか一つを選ぶ話ではなく、場面ごとに組み合わせる話です。
経営判断の軸：何を開き、何を人が持つか
入口を作るとなると、現場は「何から実装するか」を考えがちです。しかし、先に決めるべきは経営の側の問いです。次の五つの軸で整理すると、議論が進みます。
| 判断の軸 | 経営が決めること | 見る観点 |
|---|---|---|
| どの業務を開くか | AIに任せてよい業務と、まだ任せない業務の線引き | 照会のような読み取り中心の業務は始めやすい。取り消しにくい業務は後回しにする |
| 人が持つ判断 | 最終的な確認や例外対応を、誰が担うか | 購入、予約、送金のような重要な操作では、人の確認を挟む前提にする |
| リスク | 起きうる事故と、許容できる範囲 | 悪意ある指示の紛れ込み、意図しない操作、情報の漏えい |
| 体制 | 誰が設計し、誰が運用し、誰が見直すか | 事業側、開発側、法務・セキュリティ側の役割分担 |
| 段階 | どの順で、どこまで広げるか | 小さく始め、結果を見て進めるか止めるかを決める |
第一の軸「どの業務を開くか」では、頻度、価値、リスクの三つで仕分ける方法が使えます。頻度と価値が高く、リスクが低い、読み取り中心の業務が最初の候補です。ツールの数の考え方は、ツール設計の記事で扱っています。
第二の軸「人が持つ判断」は、とくに重要です。WebMCPの草案は、人の関わるブラウザでの利用を主に想定しており、完全自律でUIなしの運用を想定したものではありません。ツール実行時の利用者確認を必須とは定めていない点も、草案の特徴です。つまり、確認の仕組みをどこまで用意するかは、サイト側の設計と経営判断に委ねられる部分が大きいということです。詳しくは人が確認する設計の記事をご覧ください。
第三の軸「リスク」では、草案が挙げる課題を知っておく必要があります。ツールの説明や出力に悪意ある指示が紛れ込むプロンプトインジェクション、宣言と実際の動作が食い違う意図の偽装、過剰な入力項目による情報漏えいなどです。Chromeの資料も、LLM（大規模言語モデル）の内側で安全を保証することはできない、という前提で書かれています。具体的な点検項目は、セキュリティチェックリストの記事にあります。法務やセキュリティに関わる判断は、断定せず、専門家に確認しながら進めてください。
認証や権限の扱いは、特に注意が必要です。W3Cの草案は、認証やCookieの扱いを規定していません。一方でChromeの資料は、WebMCPがライブのタブにあるログイン中のセッション情報やCookieにアクセスすると述べています。両者の書き方が違う以上、自社のサイトでどう扱うかは自社で確かめる必要があります。詳細は認証と権限の記事で整理しています。
小さく試し、撤退基準も持つ
草案の段階では、大きな投資は向きません。仕様は変わりえますし、Chromeの資料も議論の最中であることを明記しています。Edgeなど他のブラウザの対応時期は、確認できていません。だからこそ、小さく試し、止める条件もあらかじめ決めておく進め方が現実的です。
段階の切り方の一例を示します。これは仕様に書かれた手順ではなく、考え方の一例です。
| 段階 | やること | 進む・止めるの判断材料 |
|---|---|---|
| 第1段階：棚卸し | サイトでできる操作と、持っている情報を書き出す。読む入口の整備を進める | 整理した結果、AIに開く価値のある業務が見えたか |
| 第2段階：読み取りで試す | 読み取り中心のツールを少数、ローカル環境や検証環境で動かす | 意図どおりにツールが選ばれ、引数が正しく渡されるか |
| 第3段階：限定して公開 | 安全面の確認を終えた範囲だけを、本番で公開する | 運用の負荷とリスクが、許容できる範囲に収まっているか |
| 第4段階：広げる、または見直す | 呼ばれ方を見て、ツールを増減する。重要な操作は確認を設計して検討する | 事業上の意味が確認できたか。なければ縮小する |
段階ごとの進め方は導入ロードマップの記事で、最初の実装は最小構成の実装の記事で、検証の方法はテストの記事で扱っています。
撤退基準も、始める前に決めておきます。たとえば、次のような条件です。ここに挙げるのは考え方の例で、数値の目安ではありません。
- 仕様が大きく変わり、作り直しの負担が見合わなくなった。
- 安全面の懸念が、自社の対策では抑えきれないと判断された。
- 試した範囲で、事業上の意味が確認できなかった。
撤退といっても、すべてを捨てるわけではありません。情報の整備は、WebMCPの行方に関わらず自社に残ります。WebMCPは、あれば使われ、なくても動く（プログレッシブエンハンスメント）ものとして扱うのが、Chromeの資料の勧めにも沿っています。
シリーズの道案内：どこから読むか
ここまでを踏まえ、シリーズの記事を目的別に並べます。気になるところから読んでください。
基礎を知る
設計する
業種別の使いどころ
実装と検証
安全と、周辺の整備
経営層の方は、入門記事、人が確認する設計、導入ロードマップの三つから。担当者の方は、チェックリストの記事から読むと動き出しやすくなります。
経営会議で議論したい問い
社内で議論するための問いです。答えは会社ごとに違って構いません。
最後に、社内で議論するための問いをまとめます。答えは、会社ごとに違って構いません。
- 自社の顧客は、AIエージェントに調べものや手続きを任せるようになるか。なるとしたら、どの場面からか。
- 自社の情報は、機械にも正しく読み取れる状態か。古い情報や、ばらばらの表記は残っていないか。
- AIに開いてよい業務はどれか。開いてはいけない業務はどれか。
- 重要な操作の最終確認は、誰が、どの画面で行うか。
- 問題が起きたとき、止める判断をするのは誰か。
- 試す範囲はどこまでか。やめるときの条件は何か。
以下の例は架空の例です。ある架空の宿泊施設が、予約サイトの情報整備を進めたとします。料金や空室の説明を整理したところ、人向けの案内文も分かりやすくなりました。そのうえで、読み取りだけのツールを検証環境で試し、予約確定は人が確認する前提にとどめました。このように、AI向けの取り組みが、人向けの品質の見直しにつながることもあります。ただし、これは架空の例であり、効果を示すものではありません。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると述べています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- パーソナルエージェントの普及は仮説です。広がり方や速さは、断定できません。数値による裏づけも、この記事にはありません。
- ツールは人向け画面の補完です。人が使う画面が主役であることは変わりません。
- 安全面は専門家に確認してください。プロンプトインジェクションなどのリスクがあります。法務、個人情報、業法に関わる点は、断定せず、専門家に確認しながら進めてください。
- 読む入口の効果は断定できません。検索エンジンやAIサービスの挙動は確認できていません。
Otsumuに相談できること
入口づくりの前に、まず社内の現状を整理するだけでも、進め方は見えてきます。AIツールの活用状況を診断して現状を整理する「AIツール診断」という選択肢もあります。どこから手をつけるか迷っている段階でも、お声がけください。
Otsumuは、AIファーストで事業を再構築することを支援しています。業務の棚卸し、AIに開く範囲の整理、ツールの設計や、小さな検証の進め方まで、状況に合わせてご一緒できます。詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20