LASSIC Media らしくメディア
生成AIのレッドチーミング（セキュリティ検証）を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 生成AIのレッドチーミングは、防御を実装する安全対策とは異なり、攻撃者の視点で脆弱性を洗い出す検証を指します。
- OWASPは2025年1月22日にGenAI Red Teaming Guideを公開し、モデル評価から実行時の挙動まで4つの観点を示しました。
- 手動の検証と自動的な敵対的テストツールを組み合わせ、評価指標や実施頻度を設計する点が内製と外注の判断材料になります。
目次
生成AIのレッドチーミングとは、攻撃側の視点で脆弱性を検証する手法
生成AIのレッドチーミングとは、本番投入前後の生成AI・LLM(大規模言語モデル)アプリケーションに対し、攻撃者の視点で脆弱性を模擬的に検証する取り組みです*1。プロンプトインジェクション(悪意ある入力でAIへの指示を上書きする手口)や情報漏えいなどが主な検証対象です*1。OWASPは2025年1月22日、この検証を体系化した「GenAI Red Teaming Guide」を公開しました*1。
この検証は4つの観点で構成されます。モデル単体のふるまいを見る「モデル評価」、自社アプリへの実装状況を見る「実装テスト」、API連携や権限設定を見る「インフラ評価」、公開後の応答を見る「実行時挙動分析」です*1。単発の診断ではなく、複数の切り口を組み合わせる点が特徴です。
Microsoftは2018年にAI専門のレッドチームを設置しました*4。その後2020年に敵対的機械学習の脅威分類を、2021年にAIセキュリティのリスク評価フレームワークを公開しています*4。生成AIの応答は同じ入力でも結果が変わる確率的な性質を持つため、従来の一度きりの脆弱性診断とは異なり、複数回の試行を前提にした検証設計が必要になります*4。
ガードレール実装や権限設計とは異なる「攻めて確かめる」検証の役割
生成AIのセキュリティを高める取り組みには、大きく2つの方向があります。ひとつは入出力フィルタリングや権限境界を設計する「守りを作る」対策で、もうひとつは実際に攻撃を模してその守りの穴を見つける「攻めて確かめる」検証です。本稿が扱うレッドチーミングは後者に当たります。
権限設計やガードレールの実装そのものは、AIエージェントに与える権限の範囲や入出力フィルターの仕組みを事前に定義する作業です。レッドチーミングは、その設計が実際の攻撃に耐えられるかを、模擬攻撃を通じて事後に検証する役割を担います*5。設計と検証は別の工程であり、どちらか一方だけではセキュリティの裏付けが不十分になります。
Microsoftのガイドも、レッドチーミングは体系的な測定や緩和策の代替ではないと位置づけています*5。まず手動での探索的な検証で問題の輪郭をつかみ、そのうえで測定と改修を進める順序が推奨されています*5。
プロンプトインジェクション・情報漏えい・権限昇格——検証対象になるリスク
OWASPが2025年3月12日に改定した「LLM Applications向けTop 10」では、レッドチーミングの主な検証対象となるリスクが10分類で示されています*2。このうち生成AIアプリのセキュリティ検証で頻度の高い4分類を整理すると、次の表のようになります。
| リスク分類 | 内容 | レッドチーミングでの検証観点 |
|---|---|---|
| LLM01 プロンプトインジェクション | 悪意ある入力でAIへの指示を上書きする手口*2 | 想定外の指示上書きが起きないかを模擬入力で確認 |
| LLM02 機密情報の開示 | 学習データや文脈から個人情報・機密情報が漏えいする状態*2 | プロンプト経由で機密情報を引き出せないか検証 |
| LLM06 過剰な自律性 | エージェントの権限や実行機能が必要な範囲を超える状態*2 | 権限昇格や意図しないツール実行の有無を確認 |
| LLM09 誤情報 | 事実と異なる出力を利用者が誤って信頼する状態*2 | 誤情報が生成されやすい入力パターンを洗い出す |
プロンプトインジェクションは、OWASPの分類でも1位に位置づけられています*2。レッドチーミングでは、想定していない指示の上書きが実際に起きるかどうかを、模擬的な入力パターンで確認します*2。
過剰な自律性(Excessive Agency。AIエージェントに与えた権限や実行できる機能が、業務上必要な範囲を超えている状態)も検証対象に含まれます*2。ツール呼び出しを持つエージェント型のアプリケーションでは、権限昇格や意図しない操作の実行が起きないかを重点的に確認する必要があります*6。
手動レッドチーミングと自動的な敵対的テストツールの組み合わせ
Microsoftのガイドは、レッドチーミングの計画段階で「誰が検証するか」「何を検証するか」「どう検証するか」を事前に定義するよう推奨しています*5。検証チームには、セキュリティの専門知識を持つ人材と、実際の利用者に近い視点を持つ人材の両方を配置することが望ましいとされます*5。
手動の検証は、創造的な入力を試しながら想定外の弱点を洗い出すのに向いています。自動的な敵対的テストツールは、既知のリスク分類に沿った模擬攻撃を大量かつ再現可能な形で実行するのに向いています*6。Microsoftが提供するAI Red Teaming Agentは、PyRIT(Python Risk Identification Tool。Microsoftが公開する敵対的テストの自動化フレームワーク)の攻撃手法を使い、ジェイルブレイク(AIの安全対策を回避させる入力手口)や文字列の変換といった手口を自動で試行します*6。
両者は競合する手段ではなく、補完し合う関係にあります。自動ツールで既知のリスクを広く網羅的にスキャンし、手動の検証で専門領域の判断や創造的な攻撃パターンを補う、という分担が実務的です*7。
評価指標ASR（攻撃成功率）と継続的な実施サイクル
自動的な敵対的テストの結果は、ASR(Attack Success Rate。模擬攻撃の総数に対して、実際にガードレールを回避できた攻撃の割合を示す指標)で評価するのが一般的です*6。ASRが高いほど、その観点での対策が不十分な状態を示します*6。
NIST AI RMFの生成AI向けプロファイルは、AIのリスク管理を「マップ」「測定」「マネジメント」という機能に整理しています*3。リスクの特定・評価・低減を継続的なプロセスとして位置づけ、レッドチーミングはこのうち測定の機能を担う手段の一つとなります*3。
実施頻度についても、設計時・開発時・公開直前の一度きりでは不十分です。Microsoftは公開後も、合成した敵対的データを用いた継続的な検証の実行を推奨しています*6。OpenAIも外部の専門家によるレッドチーミングを、モデル提供時だけの取り組みではなく継続的な体制として運用しています*8。
実際にGPT-4oの検証では、本人の声を意図せず模倣する音声を生成する問題が見つかりました*8。検証を経ずに公開すれば、こうした問題が利用者に届く形で表面化しかねません。
内製に必要な知見と外注判断の分かれ目
この検証を内製で担うには、複数領域の知見が要ります。プロンプトインジェクションなどの攻撃手口に関するセキュリティの専門知識、OWASPやNISTが示すリスク分類の理解、ASRのような指標の設計・評価、検証結果をガードレールの改修に落とし込む実装知識です*2*6。
Microsoftは自社で実施した大規模な検証を踏まえ、レッドチーミングは全体を自動化できないと述べています*7。医療やサイバーセキュリティなど専門領域を扱うアプリケーションでは、その分野の専門家による判断が欠かせません*7。利用者が感情的に不安定な状態でやり取りするチャットボットの評価には、人による感情面の読み取りも必要になります*7。
専門パートナーに委託する場合は、モデル単体かアプリケーション全体かという検証範囲、手動と自動の組み合わせ方、評価指標の設計を、契約前にすり合わせておくことが実務的です*1。内製では、通常業務と並行して検証チームを維持し続ける体制づくりが課題になります。
まとめ：生成AIレッドチーミングを外注判断する3つの軸
本稿では、生成AIのレッドチーミングについて、攻撃者視点で脆弱性を検証する手法として整理しました。要点は3つに集約できます。第一に、レッドチーミングは防御を作るガードレール実装とは役割が異なり、攻めて弱点を見つける検証です*1。第二に、プロンプトインジェクションや過剰な自律性など、OWASPが示すリスク分類が主な検証対象になります*2。第三に、手動検証と自動的な敵対的テストツールを組み合わせ、ASRのような指標で継続的に評価する体制が欠かせません*6。
よくある質問
生成AIのレッドチーミングと従来のセキュリティ診断は何が違いますか。
従来のセキュリティ診断はネットワークやアプリケーションの脆弱性を主な対象にしますが、生成AIのレッドチーミングはプロンプト操作や生成コンテンツの誘発など、モデル特有の挙動も検証範囲に含みます*4。同じ入力でも応答が変わる生成AIの確率的な性質を踏まえ、複数回の試行で検証する点も特徴です*4。
レッドチーミングは1回実施すれば十分ですか。
いいえ、1回の実施では十分ではありません*7。Microsoftは対策を講じてもセキュリティ上のリスクを完全には排除できないとして、設計・開発・公開前後にわたる反復的な検証サイクルを推奨しています*7。モデルやアプリケーションの更新に合わせて継続する運用が前提になります*6。
攻撃成功率（ASR）とは何を示す指標ですか。
ASR(Attack Success Rate)は、模擬攻撃の総数に対して、実際にガードレールを回避できた攻撃の割合を示す指標です*6。数値が高いほど、その観点でのリスクが残っている状態を示します*6。
自動テストツールだけで検証を完結できますか。
完結はできません*7。Microsoftは自社での大規模な検証を経て、レッドチーミングは全体を自動化できないと述べています*7。医療やサイバーセキュリティなど専門領域の判断、利用者の感情面への影響評価には、人による評価が欠かせません*7。
外部への委託を検討する際、何を確認すればよいですか。
検証対象の範囲(モデル単体かアプリケーション全体か)、手動と自動テストの組み合わせ方、評価指標の設計、結果をガードレール改善に反映する体制の4点を確認します*1。契約前にどのリスク分類を優先して検証するかをすり合わせておくと、後工程の改修がスムーズになります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：OWASP Gen AI Security Project「GenAI Red Teaming Guide」（2025年1月22日）（https://genai.owasp.org/resource/genai-red-teaming-guide/）
- *2 出典：OWASP「OWASP Top 10 for LLM Applications 2025」（2025年3月12日）（https://genai.owasp.org/llm-top-10/）
- *3 出典：NIST「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（NIST AI 600-1、2024年7月26日）（https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence）
- *4 出典：Microsoft Security Blog「Microsoft AI red team building future of safer AI」（2023年8月7日）（https://www.microsoft.com/security/blog/2023/08/07/microsoft-ai-red-team-building-future-of-safer-ai/）
- *5 出典：Microsoft Learn「Planning red teaming for large language models (LLMs) and their applications」（https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/red-teaming）
- *6 出典：Microsoft Learn「AI Red Teaming Agent」（https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/ai-red-teaming-agent）
- *7 出典：Microsoft Security Blog「3 takeaways from red teaming 100 generative AI products」（2025年1月13日）（https://www.microsoft.com/security/blog/2025/01/13/3-takeaways-from-red-teaming-100-generative-ai-products/）
- *8 出典：OpenAI「OpenAI’s Approach to External Red Teaming for AI Models and Systems」（2025年、arXiv:2503.16431）（https://arxiv.org/abs/2503.16431）
