AI レッド チーミング: 完全な方法論ガイド
Comprehensive methodology for testing AI systems - from reconnaissance to remediation
Updated: August 2026 • 読書時間: ~ 15 分
AI レッド チーミングとは何ですか?
AI レッド チーム化が実践されているの AI システムに対する意図的で組織的な攻撃 to identify vulnerabilities before real-world adversaries can exploit them. Unlike traditional penetration testing, which focuses on infrastructure and code, AI red teaming addresses unique risks inherent to machine learning systems:
プロンプト インジェクション
Manipulating AI behavior through malicious inputs that override system instructions
ジェイルブレイク
安全対策をバイパスして禁止されたコンテンツを生成
データ抽出
トレーニング データまたは出力からの機密情報の抽出
モデル操作
モデルの動作を変更する中毒または微調整攻撃
2026 年に AI のレッド チーム化が重要となる理由
- 180% increase in LLM-related security incidents (2025)
- Microsoft の AI Red Team が評価済み 100 以上の GenAI 製品 多くの影響力のある失敗の原因は次のとおりであることがわかりました シンプルなテクニック
- AI システムはますます多くの処理を実行します 機密データと重要な決定
- 規制要件 (EU AI 法) による義務 AI セキュリティ テスト 高リスク システムの場合
AI レッド チームの構築
必要なスキル
技術的スキル
- LLM アーキテクチャの理解
- 迅速なエンジニアリング知識
- Web アプリケーションのセキュリティ
- API セキュリティ テスト
- スクリプト (Python、バッシュ)
敵対的スキル
- 創造的な問題解決
- ソーシャル エンジニアリングの認識
- マルチモーダル攻撃の考え方
- 調査と偵察
- ドキュメントとレポート
ドメインナレッジ
- OWASP LLM トップ 10
- MITRE ATLAS フレームワーク
- AI/ML の基礎
- 倫理と責任開示
- 業界固有のリスク
エンゲージメント モデル
| モデル | 説明 | 長所 | 短所 |
|---|---|---|---|
| 社内チーム | 専任の社内レッド チーム | 深い製品知識、継続的なテスト | 外部の観点から見逃される可能性 |
| 外部コンサルタント | サードパーティのセキュリティ会社 | 新鮮な視点、特殊なスキル | 高コスト、学習曲線 |
| ハイブリッド | 内部 + 外部コラボレーション | 両方の長所 | 調整オーバーヘッド |
| 自動 | CI/CD 統合テスト | 継続的、スケーラブル | 既知のパターンに限定 |
フェーズ 1: 偵察と発見
The initial phase focuses on understanding the target AI system and mapping its attack surface.
1.1 システム マッピング
- アーキテクチャのレビュー: AI が他のシステムとどのように統合されるかを理解する
- データ フロー: データがシステム内を移動する方法をマップする
- API エンドポイント: 公開されているすべてのインターフェイスの特定
- サードパーティの統合: 外部サービスを文書化する
- ユーザー ロール: さまざまなアクセス レベルを理解する
1.2 機能の調査
- モデル機能: AI は何ができるのですか?
- ツール アクセス: どのような機能を呼び出すことができますか?
- データ アクセス: どのような情報を取得できますか?
- 出力チャネル: どのように通信するのですか?
- 状態管理: セッションはどのように処理するのですか?
重要なテクニック
- システム プロンプトの抽出: 注意深いプロンプトを通じてシステム指示を明らかにしようとする
- モデル フィンガープリンティング: 動作パターンを通じて基礎となるモデルを特定
- API 検出: 隠されたエンドポイントまたは文書化されていないエンドポイントを見つける
- ドキュメントのレビュー: 実装の詳細については公開ドキュメントを分析
フェーズ 2: 脆弱性マッピング
Identify and categorize potential attack vectors based on the discovered attack surface.
攻撃分類法
プロンプト インジェクション
- 直接インジェクション
- 間接インジェクション
- マルチターン操作
- コンテキスト オーバーフロー
ジェイルブレイク攻撃
- ロール プレイング (DAN)
- キャラクターのなりすまし
- 認可フレーミング
- エンコーディング バイパス
データ抽出
- トレーニング データの回復
- システム プロンプトの漏洩
- 会話履歴へのアクセス
- API キーの公開
サービス拒否
- リソース枯渇
- コンテキスト オーバーフロー
- モデル操作
- システムのハング/クラッシュ
ツール/機能の悪用
- 不正な API 呼び出し
- パラメータ操作
- 関数チェーン
- 権限昇格
マルチモーダル攻撃
- イメージベースの挿入
- 音声操作
- クロスモーダル エクスプロイト
- 埋め込みコンテンツ
モデル攻撃
- 敵対的な例
- モデル反転
- メンバーシップ推論
- モデル抽出
サプライ チェーン
- 依存性ポイズニング
- モデル ハブの侵害
- トレーニング データ ポイズニング
- サードパーティのリスク
フェーズ 3: エクスプロイト
Attempt to actively exploit identified vulnerabilities to determine their real-world impact.
エクスプロイト手法
- 優先度の割り当て: 重大度および悪用可能性によって脆弱性をランク付け
- 概念実証: 各脆弱性に対して有効なエクスプロイトを開発
- 影響評価: 悪用が成功した場合の実際の影響を判断する
- チェイン: 複数の脆弱性を組み合わせて影響を大きくできるかどうかをテストする
- ドキュメント: すべての悪用の試み、成功、失敗を記録する
Microsoft レッド チーム レッスン
100 以上の GenAI 製品のテストに基づいて、Microsoft の AI レッド チームは次のことを発見しました:
- 簡単な手法が機能する: 多くの影響を与える障害は基本的なジェイルブレイク プロンプトに起因します
- システム レベルの考え方が重要: 脆弱性は多くの場合、複数のコンポーネントにまたがります
- 人間の創造性が勝利します: 自動ツールは既知のパターンを検出します。人間による新たな攻撃の発見
- 継続的なテストが不可欠: 新機能による新たな攻撃対象領域の導入
フェーズ 4: 永続性テスト
Test whether attack effects persist beyond the initial interaction and can survive system resets.
セッションの永続性
- 操作はセッションの更新後に存続しますか?
- 新しいセッションに状態を事前にロードできますか?
- 以前のプロンプトの影響が残っていますか?
モデルの永続性
- 攻撃は将来のモデルの更新に影響を与える可能性がありますか?
- 微調整により脆弱性は維持されますか?
- ポイズン攻撃は永続的ですか?
システムの永続性
- Can vulnerabilities survive updates?
- バックドア メカニズムはありますか?
- 攻撃は展開全体で持続しますか?
ツールの詳細
Garak
NVIDIA のオープンソース LLM 脆弱性スキャナ
- 40 以上の脆弱性タイプを調査
- 継続的モデル評価
- 定期的な脆弱性データベースの更新
- CI/CD パイプラインとの統合
PyRIT
Microsoft の Python リスク特定ツール
- 包括的なレッド チーム フレームワーク
- 複数の攻撃対象領域のサポート
- 自動化された攻撃生成
- スコアリングと評価
CI/CD Integration
Embed AI security testing into your development pipeline to catch vulnerabilities before production.
パイプライン統合ポイント
1. プリコミット
- ローカル プロンプト検証
- パターンベースのインジェクション検出
- 開発者ワークステーション テスト
2. プル リクエスト
- 自動化された脆弱性スキャン
- ベースラインの比較
- セキュリティ ゲートの強制
3. 本番前
- レッドチームの完全な評価
- 回帰テスト
- パフォーマンス ベンチマーク
4. 本番
- 継続的なモニタリング
- 異常検出
- インシデント対応の統合
Example: GitHub Actions Integration
```yaml
name: AI Security Scan
on: [pull_request]
jobs:
garak-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Garak
run: |
pip install garak
garak --model_type chat --target_url http://localhost:8000
- name: Upload results
uses: actions/upload-artifact@v3
with:
name: garak-results
path: results.json
```
Scoring & Triage
重大度評価フレームワーク
| 重大度 | 基準 | 例 |
|---|---|---|
| クリティカル | リモート コード実行、データ侵害、システム侵害 | RCE につながる完全なプロンプト インジェクション |
| 高 | 不正アクセス、機密データの漏洩 | システム プロンプト抽出 |
| 中 | ポリシー バイパス、データ アクセスの制限 | コンテンツ フィルタ バイパス |
| 低 | 軽微なポリシー違反、情報提供 | 意図しない出力形式 |
評価方法
LLM-as-Judge
AI を使用して、安全性とポリシー遵守のための AI 出力を評価
人間による評価
微妙なセキュリティ評価のための出力の専門家レビュー
自動スコアリング
パターン マッチングとルールベースの評価
レッド チームの指標
悪用成功率、誤検知率を追跡
修復アーキテクチャ
防御層
1. 入力フィルタリング
- プロンプト パターン検出
- エンコーディング認識
- 長さの制限
- レート制限
2. ガードレール
- 出力検証
- コンテンツ フィルタリング
- ツールの使用ポリシー
- アクセス制御
3. モデルの強化
- 安全のための微調整
- RLHF の改善
- システム プロンプト エンジニアリング
- 温度/最高レベルの調整
4. システム設計
- 権限の分離
- 人間参加型
- ロギングとモニタリング
- インシデント対応
検証テスト
修正を実装した後、再テストして検証します:
- 元の脆弱性は悪用できなくなりました
- 修正によって新しい脆弱性が導入されることはありません
- システム機能はそのままです
- パフォーマンスは許容範囲内
- 誤検知率は管理可能
レポート テンプレート
概要
- 範囲と目的
- 主要な調査結果の概要
- リスク評価の概要
- 優先的な推奨事項
技術的な詳細
- Each vulnerability with: ID, Description, Severity, Impact, Steps to Reproduce, Proof of Concept, Remediation
- スクリーンショットとログ
- 攻撃チェーン図
- コード スニペット
推奨事項
- 短期的な修正 (即効性)
- 中期的な改善
- 長期的なアーキテクチャ変更
- リソース要件
- タイムライン
付録
- ツールの出力
- 使用されるテスト ケース
- 参考資料
- 用語集
倫理的考慮事項
承認
Always obtain explicit written permission before testing. Document scope boundaries.
範囲の境界
Never exceed agreed-upon testing parameters. Report immediately if unintended systems are affected.
データ処理
Handle any accessed data responsibly. Don't exfiltrate more than necessary for proof.
責任ある開示
Allow reasonable time for remediation before public disclosure. Coordinate with vendors.
References & Resources
Related Articles
詳細を学習する準備はできましたか?
AI セキュリティ トピックの調査を継続します。