WebMCP専用の緩い処理を作らない
認証、認可、入力検証、業務処理は、通常UIと同じサーバー側の境界を通します。
要点まとめ
安全なツール設計の基本は、次の3つです。
- AIからの入力や結果は、通常のサイトと同じ基準で検証します。
- 読むだけの操作は低リスク、送信や削除などは高リスクとして扱います。
- 危険な操作には必ず人間の確認を入れ、実行内容を記録します。
4つの原則
- 01
最小権限
今の画面とユーザー権限で必要なツールだけを公開します。
- 02
再検証
Schema（入力の形式）を通った入力も、コードとサーバーの両方で検証します。
- 03
明示確認
送信、購入、削除などは実行内容を人間が確認できるようにします。
- 04
追跡可能性
誰が何を実行したかを、個人情報を抑えた監査ログで確認可能にします。
操作をリスクで分類する
| 分類 | 例 | リスク | 主な制御 |
|---|---|---|---|
| 読み取り | サイト内検索、公開情報の取得 | 低 | 入力制限、返り値の最小化 |
| 下書き | 問い合わせ内容、予約候補の入力 | 中 | 画面同期、人間の確認 |
| 送信 | 問い合わせ送信、予約確定 | 高 | 認証、CSRF、冪等性、明示確認 |
| 不可逆 | 購入、削除、契約締結 | 最高 | 初期導入の対象外を推奨 |
代表的な脅威
プロンプトインジェクション
投稿やコメントなど利用者が作った内容（UGC）や外部データがツール結果に含まれる場合、そこにAIへの指示が紛れ込むことがあります（プロンプトインジェクション）。untrustedContentHintを正しく設定し、返す内容を限定します。
説明と副作用の不一致
「候補を確認する」という説明で実際には予約を確定するツールは危険です。名前、説明、注記（アノテーション）、実処理を一致させます。
二重実行
AIが再試行すると、問い合わせや予約が重複することがあります。同じ処理が二重に実行されないためのキー（冪等性キー）、送信状態の表示、再実行時の応答を設計します。
アノテーションだけで安全にはなりません
readOnlyHintなどはAIとブラウザへの説明です。サーバー側の権限と検証を置き換えません。
公開前チェック
- 入力の種類、長さ、許容値、形式を再検証した
- 現在のユーザー権限をサーバーで確認した
- CSRF、レート制限、冪等性を検討した
- 危険な操作に人間の確認がある
- エラー時に安全な状態へ戻れる
- 未対応環境の通常UIをテストした
プロ向け支援
相談する 実装前にリスクを棚卸し
対象機能を分類し、段階導入の計画を作ります。