LLMのレッドチーミングとは？公開前に悪用・誤操作・情報漏えいを探す
通常の評価は、LLMアプリが想定した仕事を正しく行えるかを測る。レッドチーミングは、利用者が意図的に制約を破ろうとした場合や、開発者が想定しなかった入力を与えた場合に、どこまで危険な振る舞いへ到達できるかを探す。
OpenAIの開発者向け資料は、レッドチーミングを公開前に悪用、安全性、セキュリティ、規約違反の挙動を見つけるための敵対的テストと位置付け、通常の評価を補うものとしている。高い品質点を取ることと、攻撃に耐えることは別である。
モデル単体ではなく完成したシステムを試す
LLMアプリの危険は、モデルの返答だけから生まれるとは限らない。検索が権限外の文書を返す、画面が操作対象を曖昧にする、道具が過剰な権限を持つ、再試行で二重送信する、といった組み合わせで事故になる。
テスト対象には、システム指示、検索、外部文書、道具、認証、承認画面、後処理、ログ、監視まで含める。OpenAIの外部レッドチーミングに関する資料も、モデルだけでなく、分類器、フィルター、画面上の介入、監視、規約適用を含むシステム全体を対象としている。
開発用の会話画面だけで試し、実際の製品画面や権限を通さないと、本番固有の失敗を見逃す。最終的な構成に近い環境で、実際の利用者が選べる操作と同じ経路を使う。
脅威モデルから試す範囲を決める
無作為に危険な文章を入力しても、重要な経路を網羅できない。最初に、守る対象、攻撃者、入口、起きてはいけない結果を整理する。
守る対象には、個人情報、秘密値、内部文書、外部サービスの操作権限、利用者の判断、安全なブランド表示がある。攻撃者は、匿名利用者だけではない。通常権限の利用者、悪意のある文書提供者、侵害された外部API、誤操作する担当者も想定する。
入口は、チャット本文、添付ファイル、Webページ、RAGの文書、道具の返却値、画像内の文字、会話履歴などである。最悪の結果を「不適切な回答」のように広くせず、「別利用者の文書内容を表示する」「承認対象と異なる宛先へ送る」のように観測可能な形へする。
OpenAIのレッドチーミング手法は、想定能力、過去に観測した問題、利用用途を基に事前の脅威モデルを作り、重点領域と参加者を決める流れを示している。
正常な利用と敵対的な利用を両方試す
攻撃者らしい命令だけに偏ると、普通の利用者が偶然引き起こす事故を見逃す。曖昧な依頼、誤字、長い会話、複数の意図、古い添付、対象を省略した承認など、日常的な入力も安全性の境界を越えることがある。
敵対的な試験では、直接の制約回避だけでなく、外部文書に命令を埋める間接プロンプトインジェクション、権限昇格、秘密情報の推測、道具の不正利用、過大な資源消費、出力形式の破壊を扱う。
複数ターンも試す。一回の入力では拒否しても、少しずつ前提を変えると危険な情報を出す場合がある。エージェントでは、途中の道具結果を受けた後に制約が失われないか、引き継ぎ先へ権限が増えていないかを見る。
安全な試験環境を用意する
レッドチーミングは実際の弱点を探すため、試験自体が外部送信、削除、課金、情報漏えいを起こさないよう隔離する。読み取り専用の複製データ、架空の利用者、送信しないメール環境、金銭移動をしない道具を使う。
本番環境を対象にする必要がある場合は、所有者の明示的な許可、対象、時間帯、禁止操作、停止条件、連絡先を決める。自分が所有していないシステムや第三者のコードを無断で試さない。OpenAIの資料も、所有または試験許可を得た資産だけを対象にするよう明記している。
攻撃例や未修正の弱点は、通常の開発文書より厳しく扱う。閲覧権限、共有範囲、保持期間、修正後の開示方法を決める。成功した攻撃手順を広く共有すると、修正前に悪用される可能性がある。
人と自動化の役割を分ける
自動試験は、言い換え、多言語、文字の分割、長い文脈など多数の変種を速く生成できる。同じ評価基準で変更前後を比較しやすく、既知の攻撃が再発していないかを継続確認するのに向く。
一方、自動生成は似た手口へ偏り、成功判定も誤ることがある。OpenAIは、自動レッドチーミングが大量の例を作れる反面、戦術の多様性や有効性に課題があると説明している。モデルが「攻撃成功」と判定しても、実際の権限や業務影響を専門家が確認する。
人は、製品の利用文脈、地域や言語、専門領域、画面の誤解、複数機能の組み合わせを探索できる。安全、セキュリティ、業務、アクセシビリティなど異なる視点を持つ参加者を選ぶ。人数の多さより、脅威モデルに必要な専門性が揃っているかを重視する。
発見を再現可能な記録にする
「うまく脱獄できた」だけでは修正できない。発見ごとに、対象構成の版、前提権限、入力と会話履歴、参照した文書、呼ばれた道具、実際の結果、期待する安全な結果、再現性、影響、暫定対策を記録する。
重大度は、攻撃の巧妙さではなく、到達できる影響、必要な権限、再現の容易さ、影響を受ける人数、検知可能性で決める。一度だけ不適切な文章が出た例と、任意の宛先へ機密文書を送れる例を同じ点数にしない。
重複した攻撃は共通原因へまとめる。ただし、同じ原因でも入口や影響が違えば、修正後に両方を再試験する。入力を拒否するだけでなく、権限分離、引数検証、承認、出力制限、監視のどこで止めるかを決める。
修正後は回帰評価へ変える
レッドチーミングの目的は、弱点の一覧を作ることではない。各発見に所有者と期限を付け、修正、再試験、残る危険の判断まで追跡する。公開を止める条件と、危険を説明した上で許容する条件を事前に定める。
再現可能な攻撃は、機密情報を除去して安全性評価セットへ追加する。修正のたびに既知の攻撃と通常の利用例を両方実行し、厳しい防御で正当な操作まで使えなくなっていないか確認する。
OpenAIは、以前のモデルや構成で見つけた弱点を評価へ変え、後の構成を測る方法を説明している。OWASPの生成AIレッドチーミング資料も、モデルの弱点からAPIやシステム統合、データ露出までを含むリスクベースの方法を示している。
モデル、プロンプト、道具、権限、参照文書が変われば、脅威モデルも更新する。一回の公開前イベントで終わらせず、大きな変更、重大事故、新しい攻撃経路の発見時に重点領域を見直す。
レッドチーミングは、あらゆる攻撃に安全だと証明する試験ではない。現実の利用経路を敵対的に探索し、見つけた弱点を防御と回帰評価へ変える作業である。対象と権限を明確にし、完成したシステムを安全な環境で試し、発見を修正まで追跡することが重要だ。