レッドチーミングとは?AIの弱点を攻撃者目線で探す評価手法

レッドチーミングとは?AIの弱点を攻撃者目線で探す評価手法

AI チャットやエージェントのテストで確かめるのは、たいてい「正しく答えられるか」です。

ところが、悪意を持った使い手が狙うのは正反対の方向です。

答えてはいけないことを答えさせる道を探してきます。

作った側が思いつかない使い方を、公開前に誰が試しておくのでしょうか?

その役を担うのがレッドチーミング(red teaming)で、攻撃者の役を味方が先に演じ、本番より前に弱点を見つける評価手法です。

レッドチーミングは「攻撃者役」による評価

日本の AI セーフティ・インスティテュート(J-AISI)は、AIセーフティに関するレッドチーミング手法ガイドでこの手法を「対象のAIシステムに施したリスクへの対策を攻撃者の視点から評価するための手法」と説明しています。

AIセーフティに関するレッドチーミング手法ガイド - Japan AISI

ガイドは 2024 年 9 月に第 1.00 版が出て、2025 年 3 月の第 1.10 版で RAG を使ったシステムでの実施結果が反映されました。

目的は、弱点や対策の不備を見つけ、修正と堅牢化につなげることです。

Microsoft のセキュリティブログによると、AI のレッドチーミングは従来のセキュリティ診断より守備範囲が広く、ステレオタイプのような公平性の問題や有害なコンテンツまで探る言葉になりました。

Microsoft AI Red Team building future of safer AI | Microsoft Security Blog

悪意ある攻撃者だけでなく、普通の利用者とのやり取りで起きる失敗も対象に入る点が大きな特徴でしょう。

探すのはプロンプトの穴だけではない

何を探すのかについて、J-AISI のガイドは守るべき資産ごとに攻撃を整理しています。

学習データならデータポイズニング、学習済みモデルなら抽出や窃取、入力なら直接プロンプトインジェクションやプロンプトリーキング、といった具合です。

実行時に取り込む文書や Web ページを細工する間接プロンプトインジェクションも、同じ表に並びます。

この攻撃の仕組みは、こちらで整理しました。

プロンプトインジェクションとは?仕組みと防ぎ方を整理

そのうえでガイドは、プロンプト単体ではなく LLM システム全体に対して実施することが重要だと強調しています。

外部の LLM が十分にテストされていても、AI システム全体の安全までは保証されないためです。

誰が、どんな形で攻めるのか

レッドチームの顔ぶれについて、J-AISI のガイドは攻撃を計画・実施する要員に加え、対象分野のドメイン専門家を入れることを基本にしています。

ヘルスケアなら医師や薬剤師など、という例まで挙がっていました。

攻撃役には、開発・提供の管理者からの独立性も求められます。

作った本人ほど、設計の前提を疑いにくいものです。

米国の NIST も、生成 AI 向けの NIST AI 600-1(2024 年 7 月)で、レッドチーミングを一般の利用者・専門家・その組み合わせ・人間と生成 AI の協働の 4 種類に分けています。

Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

進め方は、Anthropic の Challenges in red teaming AI systems(2024 年 6 月)が具体的です。

Challenges in red teaming AI systems

まず専門家が手探りで攻撃を試し、手口を型へ整えます。

そこから言語モデルに入力の言い換えを数百から数千通り作らせ、人手の定性的な試験を、定量的で自動化された試験へ育てていく段取りです。

時期については、J-AISI のガイドがリリース前の実施を基本としつつ、一度実施して完了ではないと明記しています。

システムプロンプトの変更やモデルの追加学習など、中身が変わるたびに見直す対象になるわけです。

ガードレールや評価との違いと、限界

似た言葉と並べると、立ち位置がはっきりします。

ガードレールは、本番の入力と出力を常に検査する防御の仕組みです。

対してレッドチーミングは、その防御を攻撃者の目ですり抜けられないか試す点検にあたります。

ガードレールの置き方は、こちらにまとめました。

ガードレールとは?AIの入力と出力を検査して事故を防ぐ仕組み

ベンチマークとの違いについては、Microsoft AI Red Team が 100 以上の生成 AI 製品での経験をまとめた論文が、「AI レッドチーミングは安全性ベンチマークではない」と明言しています。

共通のデータセットで複数モデルを比べやすいベンチマークに対し、人手のかかるレッドチーミングは新しい種類の害や、使われ方に固有のリスクを見つけられる、という対比です。

採点役の LLM-as-a-Judge も、回答を評価する道具であって、攻め手を考える役ではありません。

限界については、J-AISI のガイド自身が、自然言語を受け付けるシステムは入力の幅が広く、網羅的なレッドチーミングは困難だと認めています。

同じ入力でも結果が変わりうるため、成功の基準と実行回数を決めて記録を残すことも求められていました。

試した攻撃が通らなかったとしても、すべての攻撃が通らない保証にはならない、という注意書きも添えられています。

先の論文も、最後の教訓に「AI システムを守る仕事は決して終わらない」を置いています。

最後に

レッドチーミングは、攻撃者の役を味方が引き受け、本番より前に弱点を見つけて直すための評価手法でした。

探す対象はプロンプトの穴に限らず、学習データや参照文書、システム全体に広がります。

ガードレールが守る仕組みなら、レッドチーミングはその守りを試す点検です。

私自身は、作った人とは別の目で、変更のたびに繰り返し攻めることが、この手法の核心だと受け止めました。

穴をふさぐ側の理解には、先に紹介したガードレールの記事が役に立つと思います。

以上です。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA