AIレッドチームとは？LLMの評価範囲・試験条件・診断との違い

AIレッドチームとは、攻撃者がどうAIシステムを攻撃するかの観点で、対策と対応体制が効くかを確かめる評価だ。

この定義はAISI（AIセーフティ・インスティテュート）の『AIセーフティに関するレッドチーミング手法ガイド』による。試験で明らかにしたいのは、どの条件で問題が起き、どの対策で抑えられるかだ。LLM（大規模言語モデル）は同じ入力にも違う出力を返しうるので、Webアプリ・APIの通常の診断と組み合わせ、修正後は同じ条件で試し直す。

AIレッドチームの目的とセキュリティ診断との違い

AIレッドチームの目的は攻撃者の目線で弱点や対策の不備を見つけて直すことで、決めた項目を一通り確かめる診断に対し、何を失敗とみなすかを用途から決めて、そこへ至る筋書きを試す。AISIのガイドも目的をこう書き、NISTも『AIリスク管理フレームワーク：生成AIプロファイル』で、管理された環境で開発者と協力し、望ましくない挙動とその起こり方を探す試験としている。

AIレッドチームの評価目的

研究者らは論文『100の生成AI製品のレッドチーミングから得た教訓』で、同じLLMでも創作の補助に使う場合より、医療で患者の記録を要約する場合のほうが明らかに危険が大きいと書いている。失敗の定義は用途と読めるデータで決まり、社員向けの規程検索なら利用者の部署では読めない文書の内容が回答に出ること、社外向けの問い合わせ窓口なら他の顧客の情報を答えることが失敗だ。

攻撃の筋書き（リスクシナリオ）づくりには用途の専門家も加える。AISIのガイドはヘルスケアの例に、医師、薬剤師、看護師、医療法務に詳しい弁護士を挙げる。

失敗は情報の漏えいに限らない。ガイドはリスクシナリオの観点に、有害情報の出力制御、偽誤情報の出力・誘導の防止、公平性と包摂性なども挙げている。この記事はそのうち、情報の漏えいと不正な操作を中心に扱う。

AIレッドチームと診断の役割分担

AISIのガイドは、AIのレッドチーミングを従来の情報セキュリティのレッドチーミングの延長に置き、主流とみられる直接・間接のプロンプトインジェクションへの対応と、LLMを組み込んだシステム全体の試験を重ねるとしている。脆弱性診断との違いを我々は次のように整理している。成果物の欄はガイドが挙げる報告書の項目だ。

前述の論文は、レッドチーミングは安全性のベンチマーク（共通の問題集での採点）より人手がかかる一方で、用途に固有の危険を見つけられ、両者は補い合うとしている。我々は、Web・APIの認証や入力処理は診断で一通り確かめ、LLMを経由する攻撃の筋書きをレッドチームで試す組み合わせがよいと考える。

診断で一通り確かめるLLMアプリの入力・権限・出力の項目は、AIセキュリティ診断の項目の記事で整理している。

AIレッドチーム（LLMレッドチーミング）で試す権限・データ・接続先の範囲

LLMレッドチーミングの範囲は、入力の経路、読めるデータ、動かせる機能、出力の行き先を、範囲表の別々の行に書いて決める。AISIのガイドは実施を、実施計画の策定と準備、攻撃計画・実施、結果のとりまとめと改善計画の3工程に分け、範囲は第1工程で決める。その前に、出力の渡し先、参照するもの、LLMの学習のさせ方から利用形態を把握するよう求めている。

プロンプトインジェクションのテスト範囲：LLMの入力と参照データ

OWASPは『LLM01:2025 プロンプトインジェクション』で、利用者の入力がモデルの挙動を変える直接型と、Webサイトやファイルなど外部の情報をLLMが受け取るときに起きる間接型を分けている。安全対策を完全に無視させるジェイルブレイク（脱獄）も、プロンプトインジェクションの一形態としている。AISIのガイドは、システムプロンプトを引き出すプロンプトリーキングも挙げ、その内容は次の攻撃の材料になり、機密情報を含めば漏えいにもなるとしている。

同じガイドによれば、何も参照しない構成では攻撃者がアクセスできる可能性は低い。社内データベースやWebページを参照するなら、その参照先に悪意ある内容を埋め込まれうる。チャット欄に加えて、LLMが読む社内文書とWebページも試験の入力に数える。

出力の行き先も範囲に入る。ガイドは、LLMが作ったSQL文を他のシステムへ渡す構成ではSQLインジェクションを誘発しうると例に挙げている。外部のAPIで使う商用LLMはブラックボックスでしか試せず、学習データの個人情報が漏れないかの確認は難しいとも書いている。

AI接続先の操作権限と停止条件

AISIのガイドは、プラグインやライブラリへの過剰な権限は重大な被害につながりやすいとして、権限の付与状況も事前に集めるよう求めている。メール送信やデータ更新ができる構成では、試験の操作が実際の相手やデータに届くので、外部に作用する操作を限り、止める基準を先に決める。ガイドは実施の前後に次のことを取り決めるよう挙げている。

• 試験用のアカウントやAPIキーの発行と、ログの取得
• 監視で大量の警報が出ることの事前の調整
• 利用規約の確認と、回数制限のあるサービスへの大量の問い合わせの回避
• 予期しない動作が起きたときの停止・継続の基準と復旧の手順
• 試験後の一時アカウントの削除と、緩めた防御設定の復帰

AIレッドチームの自社検証・ツール・外部依頼の比較

自社は固有の筋書き、公開ツールは既知の攻撃の網羅、外部依頼は攻撃の知見に強い。AISIのガイドは、攻撃の実行方法を自動化ツール・手動・AIエージェントの3つに分けている。自動化ツールは既知の攻撃を効率よく再現できる形で試せるが、システム固有の攻撃は試せず、成功の判定に誤検知も多い。ガイドは、ツールで有効な攻撃の候補を絞り、本当に成功するかは専門家が手で確かめるよう勧めている。ガイドの付録はツールの例に、OSSのPyRITや、LLMを使うソフトウェアに情報の漏えいなどを試すgarakを挙げている。

我々は3つの選び方を次のように整理している。

自社で行う場合も、ガイドは試す担当者に開発の責任者からの独立性を求めている。組織内で体制を確保できなければ外部の活用を挙げ、機密情報の扱い、再委託の禁止、必要に応じた監査を契約に含めるよう勧めている。依頼先の見極めには、OWASPの『AIレッドチーミングの提供者・ツールの評価基準』が使える。この基準は、既存の攻撃文の一覧を流すだけのものや、モデルの出力だけ見て操作や状態の変化を見ないものを注意点に、複数往復の会話を再現できることや、重大な指摘を人が確かめることを良い兆候に挙げている。

AIレッドチームの評価結果と修正の優先順位

評価結果は、修正の前後で同じ攻撃を再現するための記録として受け取り、直す順番は攻撃の成功の可能性と想定被害で決める。

AI評価結果の再現条件と影響

AISIのガイドによれば、一度の実行で成功しなかった攻撃が本番で成功することも、成功した攻撃が別の状況で失敗することもある。そのため成功と判断する基準と実行回数を決め、条件と結果のログを取るよう求めている。OWASPの評価基準も、1回の結果に頼らず、同じ攻撃を何度か試した結果を数える指標を求める。

報告書には、実施日時、前提条件と侵入経路、成功した攻撃の意図、実際の入力と応答、成功と判断した理由などを載せる。我々は、入力の文面に加えて、そのときのシステムプロンプト、利用者の権限、つないだ機能、出力の行き先も記録するべきだと考える。どれかが変われば、同じ入力でも結果が変わりうるからだ。同じガイドは、試した攻撃が成功しなかったことを、攻撃者のすべての攻撃が成功しない根拠にはできないとしている。

AIシステムの修正優先順位

AISIのガイドでは、開発・提供の責任者が攻撃の成功の可能性と想定被害から事業への影響を評価し、緊急度とリスクの大きさで優先度を決める。対策は緊急・暫定・本格のように段階を分け、予防・検知・対処の策を組み合わせる。入力を前段で、出力を後段で調べる仕組みも確実に防げるとは限らないので、複数を重ねるとしている。

直したあとは、記録した条件で攻撃を再現し、結果が変わったかを確かめる。ガイドは改善後に必要なら再び実施し、運用開始後もシステムプロンプトの変更や追加学習のたびに検討するよう勧めている。