消費者も、ビジネスの担当者も、誰もが自分専用のパーソナルエージェントを使う世の中になったとき、Webサイトの役割は今とは大きく変わります。いまのWebサイトは、人間が画面を見て、読んで、クリックして使うことを前提につくられています。ところが、調べものも比較も予約も購入も、エージェントが利用者の代わりに行うようになれば、サイトを最初に訪れるのは人間ではなくAIになります。そのとき必要になるのは、人間向けの画面とは別の、AI向けの入口と、AIに向けたコンテンツやサービスの提供の仕方です。
この記事は、その入口をつくるための動きの一つである「WebMCP」を、事業者の視点で解説します。自社のWebサイトやサービスの責任者、新規事業の担当者、エンジニアでなくても「AI時代のサイトはどうなるのか」を押さえておきたい方に向けて書いています。読み終えるころには、自社のどの機能を「AIが呼べるもの」にすべきか、何から試すかを判断できるようになります。なお、WebMCPはまだ新しい提案仕様で、内容が変わり続けています。最新の状況は、記事末尾の公式資料でご確認ください。
なぜ、Webサイトに「AI向けの入口」が必要になるのか
たとえば「来週の出張で、駅に近い宿を探して、予算内で予約しておいて」と、エージェントに頼む場面を考えてみます。エージェントは、宿の比較サイトや予約サイトを訪れ、条件を入力し、結果を読み取り、予約まで進めなければなりません。人間なら自然にできるこの一連の操作が、AIにとっては簡単ではありません。
いまのエージェントは、人間の画面を無理に読んでいる
現在のブラウザ操作型のエージェントの多くは、画面の構造や見た目から、どこに何があるかを推測し、ボタンを探してクリックしています。この方式は、サイトの側に何の準備もなくても動くという利点があります。一方で、画面のデザインが少し変わるだけで動かなくなる、時間がかかる、押し間違いが起きる、といった弱点があります。事業者の側から見れば、自社のサービスがAIにどう使われるかを、制御できていない状態です。
人間向けの画面と、AI向けの入口は別物
AIに確実に使ってもらうには、画面を読ませるのではなく、「このサイトでできること」を、AIが理解できる形で差し出すほうが確実です。人間向けの画面とAI向けの入口は、設計の考え方が異なります。
| 観点 | 人間向けの画面 | AI向けの入口 |
|---|---|---|
| 伝える相手 | 人 | エージェント（AI） |
| 伝え方 | 見た目・文章・導線 | 名前・説明・入力項目の定義 |
| 操作のしかた | クリック・入力 | 決められた関数を呼ぶ |
| 失敗したとき | 人が気づいて戻る | エラーの内容を返し、やり直させる |
| 評価する数字 | 閲覧数・離脱率 | 呼ばれた回数・成功率 |
これまでWebサイトは、人間と検索エンジンに見つけてもらうことを考えて設計されてきました。これからは、これに加えて「AIに見つけてもらい、AIに使ってもらう」ための設計が、新しい論点になっていくと考えられます。
WebMCPとは何か
WebMCPは、Webサイトが自分の機能を「ツール」として、ブラウザ上のAIエージェントに公開するための仕組みです。W3Cのウェブ機械学習コミュニティグループ（Web Machine Learning Community Group）で提案が進められており、仕様案の筆者にはMicrosoftとGoogleの技術者が名を連ねています。提案が公開されたのは2025年8月で、Chromeでは2026年2月に、設定を有効にして試せる早期プレビューが始まりました。ただし、W3Cの標準になったわけではなく、コミュニティグループの草案、つまり実験的な提案の段階です。
ここでいう「ツール」とは、名前、自然な言葉での説明、受け取る入力の形（スキーマ）、実行する処理をひとまとめにした、JavaScriptの関数のことです。エージェントは、画面のボタンを探してクリックする代わりに、サイトが用意したツールを呼び出して目的を果たします。たとえば、次のような操作がツールの候補になります。
- 商品や記事を条件で検索する
- 空き日程を確認して、予約を取る
- 条件を入れて、見積もりの目安を出す
- 注文や申し込みの状況を調べる
仕様案では、サイトの側がページ内のスクリプトからツールを登録し、エージェントがそれを一覧して呼び出す、という流れが示されています。登録に使う窓口の名前は、初期の資料ではnavigator.modelContextと書かれていましたが、現在の仕様案ではdocument.modelContextです。HTMLのフォームに属性を付けて宣言的に公開する方式は「今後の検討」とされ、仕様には含まれていません。このように名前や機能が短期間で変わっているため、実装の前には必ず最新の仕様を確認してください。
MCP（Model Context Protocol）との違い
名前が似ているため、同じものと誤解されることがあります。MCPは、Anthropicが公開した、AIアプリが外部のツールやデータにつながるためのプロトコルで、主に裏側（サーバー側）の連携に使われます。WebMCPは、MCPと用語や考え方を共有しながら、Webの仕組み（オリジン、ブラウザの権限、タブなど）に合わせて、ページの中で動くように設計されたものです。
| 観点 | MCP | WebMCP |
|---|---|---|
| 動く場所 | 独立したサーバー側 | ページ自身の実行環境（ブラウザが仲立ち） |
| 主な相手 | AIアプリ・エージェント基盤 | ブラウザ内のエージェントや拡張機能 |
| Webの概念 | 前提にしていない | オリジン・権限・タブなどを前提にする |
| 向いている場面 | 業務システムや裏側の連携 | 画面で行う操作を、AIへ安全に渡す |
どちらか一方を選ぶものではなく、補い合う関係です。仕様案の側でも、人間が使う画面が主役であり続けること、WebMCPは裏側の連携を置き換えるものではないことが明記されています。社内システムとの接続については、MCPで社内システムとAIをつなぐもあわせてご覧ください。
事業者がいまから準備できること
WebMCPが標準として定着するかどうかは、まだ分かりません。それでも、「AIに使ってもらうために、自社のサービスを整理する」作業は、どの方式に進むとしても無駄になりません。次の順で進めるのがおすすめです。
- AIに任せたい操作を棚卸しする。問い合わせの前段階の検索、予約、見積もり、状況の確認など、利用者がよく行う操作を書き出します。ツールは、1つの操作に1つを基本にします。
- 名前・説明・入力項目を、AIが誤解しない形で書く。名前は「動詞＋対象」にし、説明には「何をするか」「何はしないか」を書きます。入力項目には、形式や取れる範囲を明記します。
- 実行する側で必ず入力を確かめ、分かるエラーを返す。AIが渡す値は、想定外になることがあります。仕様案でも、実行側での検証と、次に何をすればよいか分かるエラーの返却が勧められています。
- 人の確認が要る操作を決める。購入や決済、個人情報の変更、取り消せない操作は、必ず利用者本人に確認する段階を挟みます。確認のしかたの標準化は、仕様案でも検討中の課題です。
- 人間向けの画面は残す。AI向けの入口は、画面の代わりではなく追加の入口です。AIが途中で止まったとき、人が引き継げる導線を残します。
- 計測する。ツールが呼ばれた回数、成功した割合、途中でやめられた割合を見て、改善します。
ツールの数は、絞る
エージェントが一度に扱える情報量には限りがあるため、ツールを増やしすぎると、かえって選べなくなります。仕様案でも、複雑なサービスでは必要なものだけを、状況に応じて登録することが勧められています。最初は3つ以内に絞り、よく使われるものだけを残すのが現実的です。
ツール以前に、情報を機械が読める形にする
価格、在庫、営業時間、申し込み条件、よくある質問などが、画像やPDFの中にしかない状態では、AIは正しく扱えません。テキストや構造化データとして、画面の外からも読み取れる形で整えておくことが、AI向けの入口の土台になります。
注意点：セキュリティと、仕様が変わり続けること
- 悪意のある指示への対策。ツールの説明や、ツールが返す内容に紛れ込んだ指示によって、エージェントが意図しない操作をしてしまう危険があります。ツールには必要最小限の権限だけを持たせ、重要な操作は人の確認を挟み、呼び出しの記録を残します。
- 公開する範囲の管理。仕様案では、ツールは同じオリジン内が基本で、別のオリジンへ公開するには、明示的な設定が必要です。意図せず外へ出していないか、確認が必要です。
- 対応するブラウザが限られる。現時点では実験段階で、使えるブラウザや条件が限られます。WebMCPだけを唯一の入口にせず、従来の画面とAPIを併用してください。
- 仕様が変わる。窓口の名前が変わったり、一部のメソッドが取り除かれたりしています。本番に出す前に、最新の仕様と、ブラウザの対応状況を確認してください。
セキュリティや個人情報、契約に関わる設計は、社内の担当者や専門家にも確認しながら進めてください。
いま始めるなら：小さく試す3ステップ
- 操作を1つ選び、テスト環境で公開する。本番ではなく、検証用の環境で、1つのツールだけを公開します。
- 実際のエージェントで呼んで、説明が通じるか確かめる。意図どおりに呼ばれているか、誤った値が渡されていないかを見ます。
- 数字を見て、増やすか止めるかを決める。成功率と、人の確認が必要だった回数をもとに、判断します。
この試作を通じて、「自社のサービスの中で、AIに任せられる部分と、人が見るべき部分」がはっきりします。これは、WebMCPを使うかどうかにかかわらず、AI時代の事業の組み立て直しに役立つ整理です。
Otsumuに相談できること
対象の操作が1つ決まっていて、社内に実装できるエンジニアがいる場合は、この記事の手順で、テスト環境での試作から始めることは十分可能です。まずは小さく試して、エージェントがどのように自社のサービスを使うかを観察するだけでも、多くの発見があります。
一方で、複数のサービスや社内システムをまたいでAIに操作させたい、承認や停止の仕組みを設計したい、権限やログを社内の基準に合わせたい、といった場合には、設計と開発の工夫が必要になります。どの操作をAIに開くべきか社内で意見が分かれているときも、外部の視点を入れると早く決まります。
Otsumuでは、AIファーストで事業を組み直す観点から、AIに開く操作の棚卸しと、AIエージェントやAI向けの入口の設計・開発、試験運用と改善までを一貫して支援しています。AIを活用した少人数の開発で、小さく始めて広げる進め方を取ります。詳しくはAIエージェント開発のページをご覧ください。まずは状況を伺いながら一緒に整理するAIツール診断もご利用いただけます。
この記事について
Otsumu株式会社が執筆しました。2026年10月時点の情報で、WebMCPは実験段階の提案仕様のため、内容は今後変わる可能性があります。統計値や他社の事例には依拠せず、考え方と進め方を中心にまとめています。最新の仕様は、WebMCPの公式リポジトリ（W3C ウェブ機械学習コミュニティグループ）でご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.17