この記事は、自社サイトの機能をAIエージェントに使わせたい責任者や担当者に向けて書いています。読み終えるころには、どの操作ならAIに任せてよく、どの操作で人の確認を挟むべきかを、自社で線引きできるようになります。
前提として、WebMCPはまだ仕様の草案です。内容は変わり続けています。この記事は2026年10月時点の資料に基づくため、実装の前に最新の資料を見直してください。全体像はWebMCPとは何か（全体像の記事）にまとめています。
なぜ、人の確認が要るのか
AIエージェントは、利用者の代わりにサイトの機能を呼びます。便利な反面、人が自分で操作するときにはない失敗が起こりえます。主な理由は三つあります。
意図の誤解が起こる
利用者の頼み方は、あいまいなことがあります。「安い方で予約して」と言われても、何を基準に安いとするかは人によって違います。AIが意図を取り違えたまま実行すれば、利用者の望まない結果になります。
取り消せない操作がある
下書きの保存なら、やり直せます。しかし送金や、航空券の予約や、個人情報の送信は、あとから戻せないことがあります。戻せない操作ほど、実行の前に人が見る意味が大きくなります。
責任の所在が曖昧になる
AIが勝手に実行した結果について、利用者もサイト運営者も困ります。誰が何を承認したのかが残っていなければ、問い合わせやトラブルの際に説明ができません。
WebMCPの草案も、人が関わる使い方を前提にしています。Chromeの公式資料は、ローカルのブラウザで人が関わる（human in the loop）使い方を主に想定している、と述べています。完全に自律して、画面なしで動かす運用を想定した仕組みではありません。
操作を3段階に分けて考える
最初の作業は、公開しようとしている機能を洗い出し、影響の大きさで分けることです。次の表は、考え方の一例です。自社の事情に合わせて調整してください。
| 段階 | 操作の性質 | 確認の考え方 |
|---|---|---|
| 1 読み取りだけ | 商品の検索、在庫や料金の表示、営業時間の確認など。何も変更しない | 原則として、確認なしでAIに任せやすい。ただし、返す内容に個人情報が含まれないかは見る |
| 2 変更できるが戻せる | カートに入れる、下書きを保存する、予約を仮押さえする、など。あとで取り消せる | 画面に結果が見えるようにする。取り消しの手段を用意し、利用者にも分かるようにする |
| 3 取り消せない・お金や個人情報が動く | 購入、決済、送金、本予約、個人情報の送信、アカウントの削除など | 実行の直前に、人が内容を見て承認する流れを設計に入れる |
迷ったときは、段階を一つ重い方に倒すのが安全です。あとから軽くするのは簡単ですが、事故のあとに重くするのは大変だからです。
また、一つの機能の中に複数の段階が混ざっていないかも確認してください。たとえば「カートに入れる」と「購入を確定する」を一つのツールにまとめると、段階1や2のつもりで公開したものが、実際には段階3になってしまいます。確認が必要な操作は、独立したツールに切り出すと線引きしやすくなります。ツールの切り方はWebMCPのツール設計の記事で扱っています。
注釈ヒントの使い方と、草案が決めていないこと
WebMCPのツールには、注釈（annotations）という項目があります。ツールの性質を、AI側のクライアント（AIを動かすブラウザやアプリ）に伝えるための印です。草案には、次のヒントが載っています。いずれも既定値は false です。
| ヒント | 意味 | 使いどころ |
|---|---|---|
| readOnlyHint | 読み取りのみで、何も変更しない | 段階1のツールに付ける |
| consequentialHint | 実世界への影響や、取り消せない操作を伴う。草案の例は航空券の予約や送金 | 段階3のツールに付ける |
| untrustedContentHint | 返す内容が信頼できない可能性がある | 利用者の投稿や外部から取り込んだ文章を返すツールに付ける |
草案では、クライアントがこれらのヒントを見て、重要な操作の前に確認を出せる、という位置づけです。たとえばconsequentialHintが付いたツールに対し、クライアントが確認を必須にすることはできます。
草案は、ユーザー確認を必須とは決めていない
ここが大切な点です。2026年10月時点の草案の本文は、ツール実行時のユーザー確認を必須とは規定していません。ユーザー確認の標準化は、未解決の課題として残っています。
つまり、確認が出るかどうかは、利用者が使うクライアントの挙動に左右されます。クライアントによっては、確認を出さないかもしれません。ヒントを付けたから安全、とは言えないのです。そのため、サイト側でも確認の仕組みを設計しておく必要があります。ヒントは「クライアントへの申告」、サイト側の確認は「最後の砦」と考えると整理しやすくなります。
もう一つ、草案自身が認めている限界があります。宣言と実際の動作が一致するかを確かめる手段が、現状はありません。草案は、finalizeCart（名前は「確定前の準備」に見える）が実際には購入してしまう例を、リスクとして挙げています。ヒントを正直に付けるのは、サイト運営者の責任です。
Chrome資料にある「確認ダイアログを出す指示」
Chromeの資料は、購入などの重要な操作で、ユーザーに確認ダイアログを出すよう、ツールの説明に指示を含められると述べています。また、ツールはページ上で見える形で実行されます。つまり、AIが動かしている様子を、利用者が画面で追えます。
ただし、この「指示」はAIへの依頼文であり、守られる保証までは草案に書かれていません。説明文に頼るだけでなく、ページ側で実際に確認画面を出し、承認されるまで処理を進めない作りにしておくのが確実です。
確認画面で見せること
確認は、単に「よろしいですか」と聞くことではありません。承認する人が、内容を理解して判断できる状態をつくることです。中身が読めない確認は、責任を利用者に押し付けるだけで、安全には寄与しません。
確認画面は、承認する人が「何が起こるか」を一目で判断できるものにします。AIの言い回しではなく、サイト自身が持つ確かな情報から表示してください。見せる項目の基本は、次の三つです。
- 何を：対象の商品、予約、データの名前と数量
- いくら：総額、税や手数料の内訳、支払日や課金の周期
- 誰に：送金先、配送先、情報を渡す相手
加えて、取り消せるかどうか、取り消せる期限、キャンセル料の有無も書いておくと親切です。承認ボタンの文言は「はい」ではなく、「3,000円を支払う」のように、押した結果が分かる言葉にします。
次は、架空の例です。ある架空の宿泊予約サイトで、AIが「予約を確定する」ツールを呼んだとします。確認画面には「2名・1泊・合計18,000円・宿泊施設名・無料キャンセルは前日まで・予約者の連絡先」を並べ、「18,000円で予約を確定する」と「やめる」の二択を出します。金額は説明のための仮の数字です。
確認疲れを避け、記録を残す
確認を出しすぎない
確認が多すぎると、人は中身を読まずに承認するようになります。これが確認疲れです。確認を出す意味がなくなるので、段階1の読み取りには出さず、段階3に絞ります。段階2は、結果を画面に見せることと、簡単に取り消せることで補います。
同じ内容を何度も聞かない工夫も有効です。一回の依頼の中で、すでに承認した内容は繰り返し聞かず、内容が変わったときだけ聞き直します。逆に、金額や宛先が承認のあとで変わったなら、聞き直す設計にします。
やり直しの道を用意する
確認を通した操作でも、間違いは起こります。取り消しや返金、訂正の手順を、画面と案内の両方で用意しておいてください。AIが実行した操作も、人が実行した操作と同じ窓口で扱えるようにすると、運用が単純になります。
記録を残す
いつ、どのツールが、どんな入力で呼ばれ、誰が承認したかを、サイト側のログに残します。トラブルの調査や、利用者への説明に役立ちます。草案には、実行の開始や中断を知らせるイベント（toolactivated、toolcancel）がありますが、記録の取り方そのものは草案が決めるものではありません。自社の運用に合わせて設計します。記録に個人情報を入れすぎないことも、あわせて考えてください。
ログインした利用者の権限をどう扱うかは、別の論点です。草案は、認証やログイン状態の扱いまでは定めていません（Chromeの資料は、ログイン中のセッション情報にアクセスすると述べています）。いずれにしても、サイト側で決める必要があります。詳しくは認証と権限の記事をご覧ください。
導入前のチェック項目
公開前に、次の点を確認しておくと抜けが減ります。公開全体のチェックはAIエージェント対応サイトのチェックリストにもあります。
- 公開する機能を一覧にし、3段階のどれかを決めたか
- 一つのツールに、段階の違う操作が混ざっていないか
- 段階1のツールにreadOnlyHint、段階3のツールにconsequentialHintを付けたか
- 外部の文章を返すツールに、untrustedContentHintを付けたか
- 段階3の操作は、サイト側の確認画面を通らないと実行できないか
- 確認画面に、何を・いくら・誰にが表示されているか
- 承認後に金額や宛先が変わったとき、聞き直す作りか
- 実行の記録が残り、個人情報を残しすぎていないか
- 入力の検証を、ツールの実行側でも行っているか
注意したいこと
- 仕様は変動中です。ヒントの名前や意味が変わる可能性があります。実装の際は、最新の草案とChromeの資料を見直してください。
- ヒントは申告にすぎません。クライアントが確認を出すかどうかは、草案では保証されていません。
- 確認画面があっても、プロンプトインジェクション（ツールの説明や入力、出力に紛れ込む悪意ある指示）への備えは別に必要です。
- 法律や契約にかかわる確認（同意の取り方、表示事項など）は、この記事の範囲外です。必要に応じて専門家にご確認ください。
- Edgeなど他のブラウザの対応時期は、公式な確認が取れていません。
Otsumuに相談できること
機能の洗い出しと3段階の分類は、社内でも進められます。まずは表を作り、担当者同士で「これは戻せるか」を話し合ってみてください。それだけでも、確認が要る操作がかなり見えてきます。
確認画面の設計や、実装、ログの設計まで進めるときは、外部の手を借りる方が早いことがあります。Otsumuは、AIを前提に事業を組み直す「AIファースト事業リストラクチャ」を支援しています。AIが下書きや実装を担い、人が判断と責任を持つ形で、安全に任せる範囲を一緒に決められます。
具体的な進め方は、AIエージェント開発のページをご覧ください。ご相談はお問い合わせから承ります。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日です。WebMCPの仕様は変動中のため、最新の内容は参照元をご確認ください。参照元：WebMCP 仕様草案（W3C Web Machine Learning Community Group）、WebMCP 提案のリポジトリ、Chrome公式資料。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20