AI Agentセキュリティチェックリスト: 委任前に確認すること
ツール、外部データ、権限、承認、ログを分けて確認し、AI Agentへの作業委任を段階的に進めるための実践ガイド。
最終更新
AI Agentがファイルを読み、Webページを扱い、チケットを更新し、ツールを呼び出すなら、それは単なるチャットではありません。言語モデル、外部から入る文章、実際の権限が一つの流れになります。重要なのは「モデルが誤った答えを返すか」だけではなく、「誤った指示を信じたときに何ができてしまうか」です。
このチェックリストは、Agentを全面的に禁止するためのものではありません。ある一つの業務について、どの情報を読ませるか、どのツールが本当に必要か、どこで人が承認するか、後から何を調べられるかを決めるためのものです。本稿の前提は2026年7月12日に確認しました。連携方法と脅威は変わるため、導入時には各提供者の最新資料も確認してください。
まず三つの境界を分ける
| 境界 | 起きやすいこと | 確認する質問 |
|---|---|---|
| 指示 | チケットやWebページの文章が、本来の依頼やルールを上書きしようとする | ユーザーの依頼と外部文章を区別できるか |
| ツール | 権限が広すぎる、説明が紛らわしい、所有者が不明なツールを使う | この業務に必要なツールだけが見えているか |
| データ | 外部データを信頼できる設定値や実行指示のように扱う | 出所、機密性、実行コンテキストを分けているか |
Prompt injectionは重要ですが、問題はそれだけではありません。偽装されたツール説明、構造化された出力に見せかけた危険な値、広すぎるトークン、複数の小さな操作を組み合わせた望ましくない変更も起こりえます。安全な設計は、モデルが毎回攻撃を見抜くことを前提にしません。見抜けなかった時の影響範囲を狭くします。
委任前の実務チェックリスト
| 確認項目 | 最初の安全な設定 | 危険な状態 |
|---|---|---|
| 業務範囲 | 成功条件と終了条件が一つに決まっている | 「必要なことを全部やる」と依頼する |
| データ境界 | 信頼できる入力と外部コンテンツを明示して分ける | メール、Web、顧客データ、秘密情報が同じ文脈に入る |
| ツール一覧 | 各ツールに用途、所有者、権限レベルがある | 似たツールが多く、必要性が不明 |
| 権限 | 原則読み取り専用。書き込みは承認後 | 削除、送信、支払い、デプロイまで自動実行できる |
| 認証情報 | サービスごと、業務ごとに範囲を狭くする | 共通トークンを複数の用途に渡す |
| 承認 | 外部送信、高額、不可逆な操作で停止する | 一回の実行で元に戻せない操作まで終える |
| ログ | 入力、ツール呼び出し、結果、承認、最終操作を残す | 最後の回答だけが残る |
| テスト | 通常入力、曖昧入力、悪意ある入力で試す | きれいなデモだけで判断する |
小さなチームで使いやすいルールは単純です。元に戻しにくい操作は、実行の直前に人が承認します。顧客への送信、本番環境の変更、データ削除、権限変更、支払いはこの対象です。
Prompt injection、tool poisoning、data injectionの違い
| リスク | 意味 | 例 |
|---|---|---|
| Prompt injection | 外部文章が依頼やルールを上書きしようとする | 読み込んだページが内部指示を表示するよう要求する |
| Tool poisoning | ツール名や説明がモデルの選択を誤らせる | 分析用に見えるツールが機密情報の送信を促す |
| Data injection | 外部データが設定値、URL、パス、次の操作として扱われる | ツール結果の値が社内URLや実行先を不正に変える |
この区別は対策のために必要です。命令文らしい文字列だけを弾いても、構造化出力の値が後でURL、ファイルパス、権限として使われるなら境界は守れません。Webページだけでなく、ツールの応答も出所と用途を確認する必要があります。
MCPは「多くつなぐ」より「必要な分だけつなぐ」
MCPはAIアプリケーションとツール、データソースの接続を標準化します。接続を整理できる一方で、新しいサーバーやツールごとに確認点も増えます。導入前に次を確認してください。
- サーバーの運営者は誰で、実装や依存関係を確認できるか。
- 何を読み、何を変更でき、そのためにどの権限が必要か。
- ツール名と説明は、モデルが間違えずに選べるほど明確か。
- 利用者と業務ごとに最小限の同意と権限を渡しているか。
- トークンは正しい相手向けに発行され、無検証で中継されていないか。
- 内部アドレスや想定外のリダイレクトへ接続しない制限があるか。
- 誰が、いつ、どの入力でツールを呼んだかを後から確認できるか。
例えば、社内FAQの下書きを作るAgentに、検索、社内文書の読み取り、下書き保存だけを渡すのは合理的です。同じAgentに本番デプロイ、CRM更新、経費処理まで見せる理由はありません。
日本のB2Bチームでの進め方
日本語の問い合わせと英語の技術資料を扱うSaaSチームを考えてみます。顧客のセキュリティ質問票を要約し、承認済み資料から回答候補を作る業務です。最初の版では、Agentが顧客ポータルへ回答を送らないようにします。許可済みの知識ベースを読み、不明な項目を印にし、回答案と参照元を出すところまでに留めます。セキュリティ担当者かアカウント担当者が、送信前に内容を確認します。
| 段階 | Agentがしてよいこと | 人が確認すること |
|---|---|---|
| 受領 | 質問票を分類し、公開・承認済み資料を探す | 秘密添付、個別契約、例外の有無 |
| 下書き | 根拠を付け、未確認項目を示す | 事実、個人情報、契約上の表現 |
| 送信 | 承認前は外部送信しない | 宛先、最終文面、添付 |
| 振り返り | 入力と参照元、操作を記録する | 不自然な入力をテスト集に追加する |
稟議、顧客対応、責任分界が重い環境では、この段階的な設計が特に重要です。Agentは作業を短くできますが、説明責任まで代行するものではありません。
Coding Agentに追加する確認
| 許可する前に | 最低限の確認 |
|---|---|
| ファイル編集 | 作業ディレクトリを限定し、生成パッチをレビューする |
| コマンド実行 | 読み取りと、install、delete、deployなど状態変更を分ける |
| 依存関係 | パッケージ名、レジストリ、lockfile、postinstallを確認する |
| Secrets | プロンプト、ログ、生成物、履歴にトークンを残さない |
| Pull Request | テスト、差分確認、変更の根拠を求める |
| 外部入力 | Issue、README、コメント、Webの断片をuntrustedとして扱う |
Shell、ネットワーク、トークン、書き込み権限が、理由の分からないまま一つに集まる状態が危険です。生産性は最大権限からではなく、レビューの流れが見えることから生まれます。
今週からできる進め方
- サポート要約やPR下書きのような、繰り返し可能な業務を一つ選ぶ。
- 読み取り専用と少数のツールから始める。
- 各ツールについて用途、所有者、入力、出力、権限を記録する。
- 書き込み、外部送信、購入、デプロイ、削除には承認を置く。
- 入力、ツール呼び出し、結果、承認、最終操作を残す。
- 「前の指示を無視して」と書かれたチケットのような悪意ある入力で試す。
- 安全に再現できた実行が増えてから、少しずつ権限を広げる。
支払い、人事、不可逆な本番変更、顧客が書いた文章と機密情報が混ざる作業、未知の第三者サーバー、追跡できない操作では、無監督のAgentを使うべきではありません。読む、要約する、下書きを作る、提案する、承認後に実行する。この順序で委任を進める方が、長く使える仕組みになります。