AIエージェントの安全性を、モデルが不正な指示を見抜けるかどうかだけで考えるのは危険である。

ウェブページ、メール、PDF、チャット、検索結果には、利用者の依頼とは無関係な指示を埋め込める。エージェントが外部情報を読みながら、メール送信、ファイル変更、顧客情報取得、決済、削除などを実行できる場合、読み取り対象が攻撃経路になる。

この問題はプロンプトインジェクションと呼ばれる。OWASPは2025年版のLLM向け主要リスクで、プロンプトインジェクションを最上位に置き、RAGやファインチューニングでも完全には防げないとしている。OpenAIも2026年3月、現実の攻撃は単純な命令上書きより、文脈を利用したソーシャルエンジニアリングに近づいていると説明した。

したがって、安全設計の前提は「AIが必ず攻撃を見抜く」ではない。AIが誤誘導されても、重大な結果へ到達しにくいようにすることである。

読む能力と実行する能力を混ぜると危険になる

文章を要約するだけのAIが誤った指示に従っても、被害は主に回答品質に留まる。

しかし、次の能力を持つと影響が変わる。

  • 社内メールを検索する
  • 顧客データを取得する
  • 外部URLへ情報を送る
  • ファイルを書き換える
  • コードを実行する
  • SaaSの設定を変更する
  • 支払いを承認する
  • アカウントを削除する

攻撃者は、AIを直接突破する必要がない。AIが読む文書へ「この情報を外部サービスへ送れ」「安全確認は完了している」などの記述を置き、正当な作業の一部に見せればよい。

ここでは、入力の分類精度より、AIが最終的に何を実行できるかが被害規模を決める。

プロンプトインジェクションは迷惑文ではなく権限問題

典型的な対策は、悪意ある文を検知して除外する「AIファイアウォール」である。一定の効果はあるが、それだけでは不十分である。

理由は単純だ。悪意ある指示は、明白な命令文である必要がない。

  • 業務手順の補足に見せる
  • 管理者からの指示に見せる
  • セキュリティ確認の文面に見せる
  • 既存の会話を引用して正当性を装う
  • 複数の文書へ分割する
  • 画像や不可視要素へ埋め込む
  • 別言語や符号化で隠す

人間向けのフィッシングと同じく、文脈全体から嘘を見抜く必要がある。完全な検知を前提にすると、どこかで破られる。

したがって、問いは「この入力は悪意があるか」だけではない。

この入力が悪意を持っていたとしても、どこまでの操作が可能かを先に決める必要がある。

最小権限はAIにも適用する

最小権限とは、作業に必要な能力だけを、その作業に必要な時間だけ与える原則である。

AIエージェントでは、次のように具体化できる。

悪い設計改善した設計
全メールを読み、送信もできる対象ラベルの読み取りと下書き作成だけ
CRM全体を更新できる指定顧客の指定項目だけ更新できる
本番DBへ自由なSQLを実行できる読み取り専用ビューと定義済み操作だけ
任意URLへ通信できる許可済みドメインだけ
ファイルを直接削除できるゴミ箱への移動と復元可能な記録だけ
決済を実行できる金額上限付きの申請作成だけ

重要なのは、自然言語の禁止事項をシステムプロンプトへ書くだけでなく、実行基盤が物理的にできない状態を作ることである。

「顧客情報を外部へ送らないでください」という指示より、外部送信先を技術的に制限する方が強い。

高リスク操作には人間の承認を入れる

すべての操作を毎回承認させると、自動化の価値が失われる。一方、すべてを自動実行すると事故時の被害が大きい。

承認は、操作のリスクに応じて段階化するべきである。

自動実行しやすい操作

  • 公開情報の検索
  • 読み取り専用データ取得
  • 下書き作成
  • テスト環境での実行
  • 復元可能な一時変更

条件付きで自動実行できる操作

  • 社内限定の更新
  • 金額や件数に上限がある処理
  • 監査ログが残る定型処理
  • ロールバック可能な設定変更

原則として承認が必要な操作

  • 外部への送信
  • 個人情報の移動
  • 本番データ削除
  • 決済
  • 契約確定
  • 権限変更
  • 公開投稿
  • 法的・人事的な最終判断

承認画面では「実行しますか」だけを聞いてはいけない。対象、送信先、変更内容、不可逆性、根拠を表示する必要がある。

読み取りエージェントと実行エージェントを分ける

一つのエージェントへ、検索、判断、送信、削除をすべて与えると、攻撃経路と危険な操作が直結する。

より安全なのは役割分離である。

  1. 取得担当が外部情報を読む
  2. 整理担当が構造化する
  3. 検証担当が根拠と矛盾を確認する
  4. 実行担当が限定された操作を行う
  5. 高リスク時は人間へ戻す

この構成では、外部情報を読むエージェントが直接決済や削除を実行しない。実行担当は、構造化された要求だけを受け取り、許可された条件をコードで検証する。

エージェントを増やせば自動的に安全になるわけではない。しかし、信頼できない入力と強い権限を同じ場所へ置かないことは、基本的な防御になる。

「AIの判断」と「システムの判定」を分ける

AIに向いているのは、曖昧な文章の理解、候補抽出、分類、要約、例外の発見である。

一方、次は決定論的なコードで処理する方がよい。

  • 金額上限
  • 対象件数
  • 許可ドメイン
  • 必須承認者
  • 操作可能時間
  • データ分類
  • 送信禁止項目
  • 再試行回数
  • タイムアウト
  • 監査ログ保存

例えばAIが「返金が妥当」と判断しても、実際に返金できる金額、回数、対象は業務ルールで制限する。

AIへ判断力を与えることと、無制限の実行権限を与えることは別である。

ログは会話記録だけでは足りない

事故調査に必要なのは、最終回答だけではない。

最低限、次を記録する必要がある。

  • 利用者の依頼
  • 参照した外部情報
  • 使用したツール
  • ツールへ渡した引数
  • 取得した結果
  • 承認者と承認内容
  • 実際の変更
  • 失敗と再試行
  • モデル、プロンプト、ツールの版

ただし、ログ自体に機密情報が含まれる可能性がある。無期限保存や過剰収集は別のリスクになるため、アクセス制御、マスキング、保存期間も設計する必要がある。

取り消せない操作を減らす

安全な自動化は、失敗しない自動化ではない。失敗しても戻せる自動化である。

  • 削除ではなくゴミ箱へ移動する
  • 上書き前に版を保存する
  • 送信前に下書きを作る
  • 本番反映前にステージングで確認する
  • 設定変更にロールバック手順を持つ
  • 大量処理を小さな単位へ分ける
  • 異常時に自動停止する

AIエージェントは確率的に動作し、外部環境も変化する。取り消し可能性は例外対応ではなく、通常設計に含めるべきである。

導入前に作るべき権限表

各エージェントについて、次を一覧化する。

項目確認内容
入力何を読めるか
データどの機密区分へ触れるか
ツール何を呼び出せるか
操作読む、作る、更新する、削除する
外部通信どこへ送信できるか
上限金額、件数、時間、回数
承認何を誰が承認するか
監査何を記録するか
復旧どう戻すか
停止どの条件で止めるか

この表を作れない状態では、エージェントの実証実験はできても、本番運用の責任境界は定まっていない。

結論

プロンプトインジェクションは、悪い文章を検知すれば終わる問題ではない。外部情報を読むAIと、組織のシステムを動かす権限が結びつくことで生じる構造的なリスクである。

モデルが賢くなれば攻撃を見抜く能力は上がる可能性がある。しかし、攻撃側も文脈、権威、緊急性、分割、画像などを使って適応する。

したがって、本番のAIエージェントは「正しく判断するはず」という信頼で守ってはいけない。最小権限、役割分離、人間承認、決定論的な制約、監査、取り消し可能性を組み合わせ、誤判断しても重大事故へ直結しない構造にする必要がある。

一次情報