この記事は、既存の自社サイトにWebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を取り入れたい、事業責任者や担当者に向けて書いています。読み終えると、棚卸しから運用までを五つの段階に分け、各段階で何を作り、何を基準に次へ進むか（あるいは止まるか）を、自社の計画として描けるようになります。
WebMCPは草案の段階で、内容が変わり続けています。この記事は2026年10月20日時点の確認に基づきます。そのため、ここで示すのは決まった手順ではなく、小さく始めて、いつでも縮小や撤退ができる進め方の一例です。時期・費用・人数の具体的な数字は、自社の状況で変わるため書きません。
まず全体像を知りたい方は、WebMCPの入門記事を先に読むと、用語がつかめます。
なぜ「一気に」ではなく「段階的に」なのか
理由は三つあります。
- 仕様が変動中：W3Cのコミュニティグループの草案は、W3Cの標準ではなく、標準化トラックにも載っていません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。大きく作り込むほど、作り直しの負担が増えます。
- 対応が限られる：Chromeではオリジントライアル（正式提供の前に、期間を区切って試せる仕組み）として提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 操作の重さが違う：商品を調べる操作と、予約を確定する操作では、間違えたときの影響がまるで違います。軽いものから順に進めれば、失敗しても傷が浅く済みます。
WebMCPは、人が使う画面を主役としたまま、それを補う位置づけです。バックエンドの連携の代わりではありません。Chromeの資料も、プログレッシブエンハンスメント（あれば使われ、なくても画面は動く、という考え方）として扱うよう勧めています。この前提に立つと、段階的な導入は自然な選択です。
五つの段階の全体像
段階は0から4までの五つです。各段階の目的・成果物・判断基準・やらないことを、表にまとめます。これは仕様に書かれた手順ではなく、この記事の整理です。
| 段階 | 目的 | 成果物 | 次へ進む判断基準 | やらないこと |
|---|---|---|---|---|
| 0 準備・棚卸し | サイトでできる操作と、守るべき情報を把握する | 操作の一覧、優先度の仕分け、体制と責任者の決定 | どの操作を公開しないかを含めて、関係者の合意がある | 実装に着手しない |
| 1 読み取り系 | 1〜3個の読み取り専用ツールで、一通りの流れを試す | ツール定義、検証の記録、見直しメモ | 呼ばれ方と返答を確認でき、問題なく動く | 状態を変える操作を入れない |
| 2 フォーム系 | 問い合わせなど、入力を伴う操作を扱う | 入力の定義、エラーの設計、表示の確認 | 入力の誤りから立て直せる。宣言的APIなら、送信は利用者の確認で完了する | 自動送信を既定にしない |
| 3 確認が要る操作 | 予約・購入など影響の大きい操作に、確認の仕組みを付ける | 確認の設計書、法務・セキュリティの確認結果 | 専門家の確認が済み、取り消しや問い合わせの経路がある | 確認なしで確定させない |
| 4 運用・見直し | 使われ方を見て、増減と撤退を判断する | 定期の見直し記録、削除したツールの一覧 | 見直しのたびに「続ける・縮める・やめる」を決める | 惰性で増やし続けない |
段階は、順番に最後まで進む必要はありません。段階1で止める、という判断も正当です。以下、段階ごとに説明します。
段階0：準備と棚卸し
最初にやるのは、作ることではなく、書き出すことです。
- サイトで利用者ができる操作を、すべて書き出す（検索、問い合わせ、予約、資料請求など）。
- それぞれを「状態を変えない」「入力を送る」「実世界に影響が出る」の三つに分ける。
- 個人情報や機密にかかわる操作に印を付ける。
- エージェント経由でも提供してよい操作と、人が画面で行うべき操作を分ける。
仕分けの視点は、AIエージェント対応サイトのチェックリストも参考になります。サイトの業種で操作の重さが違うため、自社に近い業種の記事も早めに見ておくと、棚卸しが具体的になります。
この段階の判断基準は、「公開しない」と決めたものを含めて合意できているかです。やらないことは、実装への着手です。棚卸しが曖昧なまま作り始めると、後から範囲が膨らみます。
段階1：読み取り系を1〜3個だけ
最初に公開するのは、状態を変えない読み取り専用の操作です。草案には、読み取りのみを示すreadOnlyHintという注釈があります。個数は1〜3個程度に絞ります。ツールが多いほど、エージェントが読む量が増え、選び間違いも起きやすくなるためです。数は、頻度・価値・リスクで絞るのが一つの考え方です。
ここで押さえるのは次の点です。
- 名前と説明は、何をするか・いつ使うかが伝わる言葉にする。設計の基本はツール設計の記事にまとめています。
- 入力の定義は、スキーマ（入力項目の型や必須の指定）で示す。厳しすぎる検証はエージェントを止めうるため、考え方は入力スキーマの記事で扱います。
- 最小限の実装の流れは、最小実装の記事が参考になります。
読み取りだけでも、利用者の情報が見えてしまう場合があります。Chromeの資料も、読み取り専用でも利用者の情報が見えうると述べています。何を返すかは慎重に決めてください。
判断基準は、実際に呼ばれ、返答が意図どおりであることです。やらないことは、状態を変える操作を入れることです。
段階2：フォーム系の操作
次に、問い合わせや資料請求のような、入力を伴う操作を扱います。Chromeの資料では、既存のHTMLフォームに属性を付けてツールにする方式が、命令型とは別のAPIとして紹介されています。一方、W3Cの草案の本文には、2026年10月時点でまだ含まれていません。両者を混同せず、動向は宣言的APIの見通しの記事で確認してください。
Chromeの資料によると、この方式では、既定は利用者が送信ボタンを押して完了します。自動送信にする属性もありますが、段階2では既定のままが無難です。フォームは利用者に見える状態のままなので、人が内容を確かめられます。
この段階の肝は、失敗したときの返し方です。Chromeの資料は、汎用的なエラーや、無言の失敗を避けるよう勧めています。「日付はYYYY-MM-DDの形式で入力してください」のように、次の一手が分かる返答にします。詳しくはエラー設計の記事を参照してください。
判断基準は、入力の誤りから立て直せることと、送信を利用者の確認で完了できることです。やらないことは、自動送信を既定にすることです。
段階3：確認が要る操作
予約・購入・送金のような、取り消しにくい操作です。草案には、実世界への影響や取り消せない操作を示すconsequentialHintという注釈があります。クライアント（エージェントを動かす側）は、これを手がかりに確認を求められます。ただし、草案はユーザー確認を必須とは定めておらず、同意の標準化は議論中です。
したがって、確認の仕組みは自社でも用意する前提で考えます。Chromeの資料は、重要な操作で確認ダイアログを出す指示を含められると述べています。設計の考え方は人が確認する設計の記事にまとめています。
この段階は、法務やセキュリティの確認が欠かせません。個人情報、契約、業法、決済にかかわる点は、断定せず、専門家に確認してください。判断基準は、確認が済み、取り消しや問い合わせの経路が用意されていることです。やらないことは、確認なしでの確定です。
段階4：運用と見直し
公開したあとが、本番です。ここで見るのは、検証と数字の二つです。
見直しは、あらかじめ周期を決めておくと続けやすくなります。周期は自社の更新頻度に合わせて決めてください。見直しの場では、次の三つから選びます。
- 続ける：狙いどおりなら、そのまま運用する。
- 縮める：使われないツールや、重なっているツールを外す。
- やめる：仕様の変更や対応状況の変化で、続ける意味が薄れたら、撤退する。
撤退を選択肢に入れておくことが、草案段階の取り組みでは大切です。登録解除は、登録時に渡すsignal（AbortSignal）で行えます。人が使う画面は変わらず動くので、戻す負担は比較的小さく設計できます。仕様の動向は現状とロードマップの記事で確認し、見直しのたびに最新情報を照らし合わせてください。
体制：誰が何を決めるか
WebMCPは、開発だけの話ではありません。役割を次のように分けると、判断が止まりにくくなります。
| 役割 | 主な担当 | 特に関わる段階 |
|---|---|---|
| 事業 | 目的の設定、公開する操作の優先度、見直しでの続行・縮小・撤退の判断 | 0・4 |
| 開発 | ツールの実装、検証、登録と解除の管理 | 1・2・3・4 |
| 法務 | 個人情報、契約、業法の観点での確認 | 0・3 |
| セキュリティ | プロンプトインジェクションや公開範囲の確認 | 1・3 |
人数や配置は、自社の規模で変わります。一人が複数の役割を兼ねる場合も、「誰がこの判断をするか」だけは決めておきましょう。
安全面で最初に押さえること
草案は、リスクとして次を挙げています。
- プロンプトインジェクション（ツールの説明・入力・出力に紛れた悪意ある指示）。
- 宣言と実際の動作が一致する保証がないこと。たとえば、finalizeCartという名前なのに、実際は購入まで行ってしまう場合です。
- 必要以上のパラメータによる、プライバシーの漏えい。
アクセスはPermissions Policyのtools機能で制御され、既定は自オリジンです。他のオリジンに見せるには、exposedToで明示します。Chromeの資料も、LLMの内側で安全を保証することは不可能だと述べています。指針は暫定的なので、最新の内容を確認しながら進めてください。
架空の例：中規模の宿泊予約サイト
以下は架空の例で、実在のサイトとは関係ありません。
- 段階0：検索、空き状況の確認、予約確定、問い合わせを書き出す。個人情報を扱う予約確定は、後回しと決める。
- 段階1：空き状況の確認だけを、読み取り専用で公開する。呼ばれ方をDevToolsで確かめる。
- 段階2：問い合わせフォームを、送信は利用者が押す形で試す。
- 段階3：予約確定は、確認の設計と法務の確認が済んでから検討する。済まなければ、見送る。
- 段階4：見直しの場で、使われないものを外す。
この例のように、すべてを公開しないことも、立派な計画です。
注意点
- 仕様は変わります。WebMCPはW3Cの標準ではなく、W3Cコミュニティグループの草案です。Chromeはオリジントライアルで、他のブラウザの対応時期は確認できていません。
- 段階の区切りは一例です。自社の事情に合わせて組み替えてください。
- 効果を前提にしないでください。導入で成果が出る、という確証は、この記事にはありません。小さく試して確かめる姿勢が必要です。
- 専門家の確認を。法務・セキュリティ・個人情報に関する判断は、専門家に確認してください。
Otsumuに相談できること
棚卸しと仕分けは、社内でも始められます。まずは操作を書き出し、読み取り系から少数（1〜3個程度）を選んでみてください。
どの操作をどの順で公開するか、確認の設計をどうするかなどは、実装との兼ね合いで悩みやすい点です。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、サイトを「AIが使える形」にする設計もご一緒できます。詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20