AI Red Teaming入門：主要手法とツールを評価する実務観点

このテーマを取り上げる理由

生成AIアプリの導入が進むと、「使ってよいモデルか」よりも「自社の業務フローで壊れないか」が問題になります。AI Red Teaming¹（AIシステムに対する攻撃者視点の検証）は、プロンプトインジェクション、機微情報漏えい、不適切応答、ツール悪用、権限逸脱を事前に見つけるための活動です。

従来の脆弱性診断と違い、AI Red Teamingは一回のスキャンで終わりません。モデル、プロンプト、RAG²、外部ツール、ログ、承認フローが変わるたびに、攻撃面も変わります。

基本：何を解決する技術／ツールか

AI Red Teamingの目的は、AIシステムが望ましくない振る舞いをする条件を見つけ、改善につなげることです。対象はモデル単体に限りません。社内文書を検索するRAG、チケット起票やメール送信を行うエージェント、管理画面の権限、監査ログまで含みます。

ツールは、攻撃プロンプトの生成、複数ターンの会話、評価結果の記録、再現テスト、スコアリングを助けます。ただし、ツールを入れれば安全になるわけではありません。業務影響を知らないツールは、危険応答と許容応答の境界を判断できないため、何を禁止し、何を許容し、どの結果をリリース判定に使うかを人が決めます。

主な手法

• プロンプトインジェクション検証: 直接入力や外部文書に紛れた指示で、システム指示や業務ルールを破れるかを試します。
• RAG漏えい検証: 権限のない文書、検索結果、引用元メタデータが回答に混ざらないかを確認します。
• ジェイルブレイク検証: 禁止カテゴリの回答、危険な手順、ポリシー回避が起きないかを試します。
• ツール実行検証: メール送信、ファイル更新、チケット起票、API呼び出しなどの副作用を持つ操作が誤実行されないかを見ます。
• エージェント権限検証: 長期トークン、代理実行、承認スキップ、別ユーザーなりすましを確認します。
• ログ・監査検証: 攻撃や失敗が後から追跡できるか、ログに機微情報が残りすぎないかを見ます。

主要ツールの見方

PyRIT³（Microsoftが公開するPython Risk Identification Tool）は、生成AIシステムのリスク識別とRed Teamingを支援するオープンソースフレームワークです。複数ターンの攻撃、ターゲット接続、スコアリングを組み合わせやすい点が特徴です。

Garak⁴（LLM脆弱性スキャナー）は、LLMに対して多様なプローブを実行し、既知の失敗パターンを確認する用途に向きます。モデル単体やAPIの傾向を見る入口として使いやすい一方、業務アプリ固有の権限やRAGの検証は別設計が必要です。

OWASP LLM Top 10とOWASP Agentic AI Threats and Mitigationsは、ツールではありませんが、テスト観点の設計に使えます。たとえば「機密情報が出るか」「ツール実行が過剰か」「エージェントのメモリが汚染されるか」という観点を、テストケース名に変換できます。

導入を検討する際の評価観点

• 対象範囲: モデル単体、RAG、エージェント、API、UIのどこまで検証するかを決めます。
• 再現性: 失敗した会話、入力文、検索結果、モデル設定、ツール呼び出しを再実行できる形で保存できるかを確認します。
• 評価基準: 危険応答、機微情報漏えい、権限逸脱、業務不適合を別々にスコア化します。
• 安全なテスト環境: 本番データや本番APIを使わず、ダミー権限と検証用データで副作用を抑えます。
• CI/CD連携: プロンプト、検索インデックス、ツール定義を変更したときに、最低限の回帰テストを走らせます。
• 人の判断: 自動スコアだけでなく、法務、CSIRT、業務責任者がレビューする条件を決めます。

よくある落とし穴

1つ目は、ジェイルブレイクだけをAI Red Teamingだと考えることです。企業利用では、不適切表現よりも、権限のない文書を要約する、外部にメールする、ログに秘密を残すといった業務被害が大きくなります。

2つ目は、本番に近い権限でテストすることです。AIエージェントは副作用を持つため、検証環境、読み取り専用トークン、ダミーデータを用意しないと、テスト自体が事故になります。

3つ目は、結果を改善に接続しないことです。失敗例は、プロンプト修正だけでなく、RAGの権限制御、ツール許可リスト、承認フロー、ログ設計へ戻す必要があります。

一枚要約

• AI Red Teamingは、生成AIアプリの不正応答、情報漏えい、権限逸脱、ツール悪用を攻撃者視点で検証する活動です。
• 自社への影響は、RAGやエージェントの導入により、モデル品質だけでなく業務操作の安全性まで広がります。
• まず検証対象を分け、PyRITやGarakで再現性のあるテストを作り、改善先を権限・RAG・ログまで広げます。

今日着手できる3アクション

• PyRITを検証環境に入れ、サンプルだけ実行してログの残り方を確認します。公式ドキュメントは https://microsoft.github.io/PyRIT/ です。確認コマンドは python -m pip install pyrit と python -c "import pyrit; print(pyrit.__version__)" です。
• Garakを使う場合は、対象を本番APIではなく検証用エンドポイントに限定します。公式リポジトリは https://github.com/NVIDIA/garak です。確認コマンドは python -m pip install garak と garak --help です。
• RAGやエージェントを持つ社内アプリでは、test_id, input, expected_block, actual_result, evidence_url の列で失敗例を記録します。OWASP LLM Top 10 2025は https://owasp.org/www-project-top-10-for-large-language-model-applications/ を参照します。

AI×セキュリティの観点

AI Red Teamingは、防御側がAIを評価する活動であると同時に、攻撃者のAI悪用を想定する活動でもあります。攻撃者はプロンプトを一度送るだけでなく、複数ターンで信頼を作り、RAG文書やツール応答に指示を混ぜます。したがって、単発の禁止ワード検査ではなく、会話の流れ、外部文書、権限、承認を含めて検証する必要があります。

用語ミニ解説

1. AI Red Teaming: AIシステムに攻撃者視点の入力や操作を行い、望ましくない挙動を見つける検証活動です。 ↩
2. RAG: Retrieval-Augmented Generation の略で、検索結果や社内文書をモデルに渡して回答させる構成です。 ↩
3. PyRIT: Microsoftが公開する生成AI向けリスク識別・Red Teaming支援フレームワークです。 ↩
4. Garak: LLMに対する既知の失敗パターンを検査するオープンソースのスキャナーです。 ↩

参考リンク

• PyRIT documentation
• Microsoft PyRIT GitHub
• Garak GitHub
• OWASP Top 10 for LLM Applications
• OWASP Agentic AI Threats and Mitigations