AIレッドチーミングを自動化するAzure Red Teaming Agentの仕組みと導入・運用

生成AIアプリを本番に出す前に、モデルが有害な応答を返さないかを攻撃者の視点で検証する作業がAIレッドチーミングです。Azure AI Foundry（Microsoft Foundry）のRed Teaming Agentは、MicrosoftのオープンソースフレームワークPyRIT（Python Risk Identification Tool）をFoundryに統合し、この敵対的プロービングを自動化するパブリックプレビュー機能です。本記事は、その構造とPyRIT統合、対応リスクカテゴリと攻撃戦略、SDK導入手順、Attack Success Rate（ASR）の読み解き方、他ツールとの比較、CI/CDへの組み込みとMITRE ATLAS・OWASP LLM Top 10への対応までを、実務で使える粒度でまとめます。組織的なセキュリティAI運用の前提は情報システム部門向けのサイバーセキュリティAIの基本構造と防御・導入の実務もあわせて確認してください。

まとめ：Red Teaming Agentで押さえるべき要点

• Red Teaming AgentはPyRITの攻撃能力とRisk and Safety Evaluatorsを統合し、生成AIへの敵対的プロービングを自動化する（2026年時点でパブリックプレビュー、SLA無し）。
• 評価の中心指標はASR（攻撃成功率＝有害応答を引き出した割合）。リスクカテゴリ別・攻撃複雑度別にブレークダウンして弱点を特定する。
• モデル向け7カテゴリに加え、エージェント専用に「禁止アクション」「機微データ漏えい」「タスク遵守」の3カテゴリが追加された（クラウド実行のみ）。
• ローカル実行はPython 3.10〜3.13、クラウド実行は5リージョン限定（East US 2 / France Central / Sweden Central / Switzerland West / US North Central）。
• Agentは「検出」ツール。防御はContent Safetyフィルタ・システムメッセージ・Foundry Control Planeで多層構成し、CI/CDで継続的に再スキャンする。

AIレッドチーミングとは——従来のセキュリティテストとの違い

従来のレッドチーミングは、ネットワーク侵入や権限昇格といったサイバーキルチェーン上の脆弱性を攻撃者の視点で洗い出す手法です。これに対しAIレッドチーミングは、生成AIモデルが不適切な出力を返すリスク、つまり暴力・差別・性的表現・自傷助長といったコンテンツ安全性の失敗と、プロンプトインジェクションやガードレール回避といったセキュリティの失敗の両方を対象とします。攻撃対象がコードやポートではなく、モデルの応答挙動そのものである点が根本的な違いです。

この違いは、大規模言語モデルがインターネット規模のデータで学習し、有害・偏向したコンテンツを内包しうることに由来します。直接「銀行の襲い方を教えて」と尋ねればほとんどのモデルは拒否しますが、プロンプトをBase64でエンコードする、文字を反転させる、過去形に書き換えるといった変換を挟むと安全アライメントをすり抜けられる場合があります。Red Teaming Agentは、こうした回避型攻撃を体系的に再現し、安全ガードレールが実際の攻撃に耐えるかを測る専用ツールです。「adversarial audit（敵対的監査）」を人手に頼らず反復可能にする点が価値になります。

Azure Red Teaming Agentの構造とPyRIT統合

自動スキャン・評価・レポートの3機能とASR

Red Teaming Agentは、自動スキャン・評価スコアリング・レポーティングの3機能で構成されます。自動スキャンはPyRIT由来の攻撃戦略で敵対的プロンプトをターゲットへ送信し、評価スコアリングはRisk and Safety Evaluatorsが各「攻撃と応答のペア」を採点してASRを算出、レポーティングはスコアカードをFoundryポータルで可視化します。ASRは「有害な応答を引き出せた攻撃数 ÷ 全攻撃数」で、リスクカテゴリ別と攻撃複雑度別の2軸に分解されるため、どのリスクのどの難易度で防御が破られたかを個別に読み取れます。一連の処理はローカルでもクラウドでもFoundryプロジェクトへログされ、時系列で追跡できます。

PyRITと敵対的LLMによる5ステップの攻撃パイプライン

PyRITは、Microsoft AI Red Teamが自チームのレッドチーミング業務のために開発したフレームワークで、Copilot各種やPhi系モデルのリリース前検証を含む100超の生成AI製品のレッドチーミングで使われてきました。Red Teaming Agentはこの能力をFoundryに統合し、内部処理を次の5ステップで回します。

1. 指定リスクカテゴリごとに、キュレーション済みデータセットからシードプロンプト（攻撃目標）を選ぶ（既定は各カテゴリ10件）。
2. 変換なしのベースラインプロンプトをターゲットへ送る。
3. 選択した攻撃戦略（Base64・Flip・Morse など）で各プロンプトを変換する。
4. 変換後プロンプトを送信し、モデル応答を収集する。
5. 各ペアをRisk and Safety Evaluatorsが採点し、ASRを含むスコアカードを生成する。

攻撃プロンプトの生成には、安全ガードレール回避に特化してファインチューニングした敵対的LLMが使われ、テンプレート的な攻撃より多様なバリエーションを自動で試します。ベースラインと戦略適用の結果を並べて見ることで、「素の攻撃は防げているが変換型に弱い」といった防御の穴が浮かび上がります。ターゲットは、Azure OpenAIのモデル構成、文字列入出力のシンプルコールバック、OpenAI Chat Protocol準拠の複合コールバック、PyRITのPromptChatTargetを継承した任意ターゲットの4種類を指定できます。

リスクカテゴリと攻撃戦略——スキャン設計の要点

モデル向け7カテゴリとエージェント専用3カテゴリ

モデルを対象とするリスクカテゴリは7種類です。既定で有効なのはViolence（暴力）、Sexual（性的）、HateUnfairness（ヘイト・不公正）、SelfHarm（自傷）の4つ。加えてProtectedMaterial（著作権保護物の再生成）、CodeVulnerability（脆弱性を含むコード生成。Python・Java・C++・C#・Go・JavaScript・SQLを対象）、UngroundedAttributes（根拠のない属性推定）の3つを拡張として選べます。カテゴリごとに設定できる攻撃目標数の上限が異なり、基本4カテゴリは各100、ProtectedMaterialとUngroundedAttributesは各200、CodeVulnerabilityは389です。

さらに2026年時点では、AIエージェントを狙う3カテゴリ——Prohibited actions（禁止アクションやツール使用の実行）、Sensitive data leakage（財務・個人・医療データの漏えい）、Task adherence（指示・制約からの逸脱）——が追加されました。これらはツール出力まで検査する必要があるためクラウド実行専用で、いずれもシングルターン・英語のみという制約があります。外部データ経由でエージェントを操るIndirect Prompt Injection（XPIA）も、これらエージェント向けカテゴリと組み合わせて検証されます。エージェント型アプリでは、モデル単体のスキャンだけではツール実行経由の情報漏えいや指示逸脱を検出できないため、このエージェント向けカテゴリも回します。攻撃の起点となるプロンプトインジェクションの基礎はChatGPTのロックダウンモードとプロンプトインジェクション対策を参照してください。

num_objectivesと3段階の攻撃複雑度

num_objectivesは各リスクカテゴリで生成する攻撃目標数で、既定は10（基本4カテゴリなら合計40）。増やすほどカバレッジは上がりますが、実行時間とSafety Evaluationsの課金も比例して増えます。開発初期は少数で素早く回し、プリデプロイでは目標数と戦略を広げる段階的アプローチが実務的です。攻撃戦略は、攻撃者に必要な労力で3段階に分かれます。

MultiturnやCrescendoは複数ターンにわたり段階的に安全策を突破する戦略で、単発では表面化しない弱点を突きます。複数戦略を連鎖させるAttackStrategy.Composeは、たとえばBase64でエンコードした後にROT13を掛けるといった多段攻撃を作れますが、連鎖できるのは2戦略までです。まず単一戦略でASRが上がる手法を特定し、その戦略を軸にCompose攻撃を組むと弱点を深掘りできます。

導入手順とスキャン結果の読み解き

SDK導入・認証・対応リージョンとPythonバージョン

ローカル実行はAzure AI Evaluation SDKのredteamエクストラを使います。インストールは次のとおりで、認証用のazure-identityも併せて導入します。クラウド実行の場合はAzure AI Projects SDK（プレビュー版）を使い、インポート元が異なる点に注意してください。

pip install "azure-ai-evaluation[redteam]" azure-identity

from azure.identity import DefaultAzureCredential
from azure.ai.evaluation.red_team import RedTeam, RiskCategory

agent = RedTeam(azure_ai_project=AZURE_AI_PROJECT, credential=DefaultAzureCredential())
result = await agent.scan(target=my_callback, output_path="scan.json")

対応Pythonは3.10・3.11・3.12・3.13で、3.9以下は依存解決の段階でエラーになります（過去のドキュメントでは3.13が非対応でしたが、現在は3.13までサポート対象です）。企業環境でシステムPythonが古い場合は、pyenvやcondaで別環境を用意します。認証はDefaultAzureCredentialが標準で、ローカルでは事前にaz loginが必要です。プロジェクトはエンドポイントURL、またはsubscription_id・resource_group_name・project_nameの辞書で指定します。ロールは「Foundry User」（旧Azure AI User）が必須で、結果アップロードには接続ストレージへの「Storage Blob Data Contributor」も要ります。この権限漏れは、スキャンは完走するのに結果がポータルに出ない典型トラブルです。クラウド実行はEast US 2・France Central・Sweden Central・Switzerland West・US North Centralの5リージョンに限られ、Foundryプロジェクトが対象外リージョンだとエラーになります。モデルのスキャンはスペイン語・イタリア語・フランス語・日本語・ポルトガル語・簡体字中国語の6言語に対応し、SupportedLanguagesクラスで指定できます（エージェント専用カテゴリは英語のみ）。Azure AI Foundryの概要もあわせて確認してください。

ASRスコアカードの読み方とContent Safety・システムメッセージによる改善

スキャンが終わると、risk_category_summary（全体ASRとカテゴリ別ASR）、attack_technique_summary（ベースライン／Easy／Moderate／Difficult別ASR）、joint_risk_attack_summary（両者のクロス集計）を含むJSONスコアカードが出力されます。読み順は、まず全体ASRでマクロな安全水準を把握し、次にカテゴリ別で問題領域を絞り、攻撃複雑度別でどの難易度に弱いかを見る流れが効率的です。ベースラインASRが0%でもEasyで上がるなら、入力段のエンコード検出が手薄なサイン。Moderateから上がるなら、LLMを使った巧妙な書き換えへの耐性不足を示します。

ASRの課題が見えたら、最も即効性が高いのはAzure AI Content Safetyフィルタの適用です。高ASRを示したカテゴリのしきい値を厳格化して防御層を足し、あわせてシステムメッセージ（安全システムメッセージのテンプレート）で拒否ルールを明示します。その後、同一条件で再スキャンしてASRの変化を測る——この検出→対策→再検証の反復が、段階的な安全性向上の基本サイクルです。Red Teaming Agent自体は検出ツールであり、防御はContent Safetyフィルタ・システムメッセージ・Foundry Control Planeで別に構成します。

他ツールとの比較と継続的レッドチーミングの運用

PyRIT単体・Giskard・Lakeraとの棲み分け

AIレッドチーミングの自動化はRed Teaming Agentだけではありません。PyRITは単体のオープンソースとしても使え、Red Teaming AgentはそれをFoundryでマネージド化した位置づけです。PyRIT単体はカスタマイズ性に優れる反面、シードプロンプトの用意・スコアリング実装・インフラ構築を自前で行う必要があります。Foundry統合版はキュレーション済みデータセット、ASR自動算出、ポータル可視化を即使える一方、リージョン制限やプレビューの制約を受け入れることになります。

サードパーティ製では、Giskardが再現可能なテストとリグレッション検知（モデル更新時の安全性劣化の検出）に強く、Lakeraはランタイム防御（Lakera Guardによるプロンプトインジェクションのリアルタイム検出）とプリデプロイ評価を組み合わせます。Red TeamingAgentはAzure/Foundry環境に深く統合された選択肢のため、検証対象の大半がAzure上ならこれを主軸にするのが合理的です。マルチクラウドやオンプレが中心なら、プラットフォーム非依存のPyRIT単体やGiskardを主軸に据えたほうが運用負荷を抑えられます。ベンダーごとの戦略の違いはGoogle AIレッドチーム戦略の全体像と比較すると立体的に理解できます。

CI/CD統合と4フェーズの継続的スキャン

Red Teaming Agentの価値は、1回限りの検査ではなく開発ライフサイクル全体での継続運用で最大化されます。Microsoftは設計・開発・デプロイ前・デプロイ後の4フェーズでの実行を推奨しており、設計では候補モデルの安全性比較、開発ではモデル更新やファインチューニングごとのリグレッション確認、デプロイ前は全カテゴリ・全複雑度のフルスキャンを投入可否のゲートに、デプロイ後はクラウド実行のスケジューリングで定期監視に使います。「継続的自動レッドチーム」は、この後半2フェーズを自動化する考え方そのものです。

CI/CDに組み込むときは、テストステージでスキャンを実行し、ASRがしきい値を超えたらパイプラインを失敗させるゲートを置きます。スキャンは数十分かかることがあるためタイムアウトを長めに設定し、認証はインタラクティブ認証ではなくマネージドIDかサービスプリンシパルに切り替えます。毎回フルスキャンするとコストがかさむため、変更に関係するリスクカテゴリだけを回す差分スキャンや、日替わりで戦略をローテーションする設計が現実的です。基盤モデルのバージョン変更・ファインチューニング適用・システムメッセージやフィルタ設定の変更の3条件に該当したら、必ず再スキャンする運用ルールを明文化しておきます。

MITRE ATLASの読み方とOWASP LLM Top 10へのマッピング

スキャン結果を組織のガバナンスに接続するには、業界標準フレームワークへのマッピングが有効です。MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）は、サイバー攻撃の知識ベースであるMITRE ATT&CKをAIシステム向けに拡張したマトリクスで、Microsoftも策定に関与しています。読み方はATT&CKと同じで、横方向の列が「戦術（Tactics）」＝攻撃者の目的（偵察、初期アクセス、MLモデルアクセス、実行、永続化、探索、情報持ち出し、影響など）を攻撃の進行順に並べたもの、各列の下に並ぶセルが「技術（Techniques）」＝その目的を達成する具体的手段です。左から右へ列をたどると攻撃の流れが読め、各セルの技術には実際の攻撃事例（ケーススタディ）が紐づきます。自社アプリで想定される列と技術を特定し、Red Teaming Agentのどのカテゴリ・戦略がその技術を模擬するかを対応づけると、検証の抜け漏れを可視化できます。

OWASP LLM Top 10（2025年版）は、LLMアプリの代表的リスクを10項目に整理したもので、プロンプトインジェクション（LLM01）が最大のリスクに位置づけられています。実務では、NISTのAIリスクマネジメントフレームワーク（Govern・Map・Measure・Manage）に沿って、MapでOWASP LLM Top 10を参照して該当リスクを特定し、MeasureでRed Teaming AgentのASRを使って深刻度を定量化、ManageでContent SafetyフィルタやFoundry Control Planeによる多層防御を実装し、Governでスコアカードをステークホルダーへ共有してリスク許容基準を見直す、という循環に組み込みます。第1層にContent Safety、第2層にシステムメッセージ、第3層にFoundry Control Planeを置き、Agentがその有効性を定期検証する構成なら、モデル更新やフィルタ変更のたびに防御の劣化を早期に検知できます。

よくある質問

Red Teaming Agentの利用に料金はかかりますか？

Agent自体に独自料金はなく、バックエンドで消費するAzure AI Risk and Safety Evaluationsの従量課金です。攻撃と応答のペア数に比例するため、「リスクカテゴリ数 × num_objectives ×（1＋攻撃戦略数）」でおおよそのペア総数を見積もれます。小規模スキャンで高リスクのカテゴリを特定し、そこだけ戦略を広げる2段階運用がコストを抑えます。

対応リージョンとPythonバージョンは？

クラウド実行はEast US 2・France Central・Sweden Central・Switzerland West・US North Centralの5リージョン限定です。ローカル実行のPythonは3.10〜3.13に対応し、3.9以下は非対応です。

MITRE ATLASとは何で、どう読めばよいですか？

AIシステムへの攻撃を体系化した知識ベースで、MITRE ATT&CKのAI版です。列（戦術）を左から右へ攻撃の進行順に、各列のセル（技術）を具体的手段として読みます。自社の想定攻撃経路を列と技術で特定し、レッドチーミングの検証項目と対応づけて使います。

PyRIT単体と何が違いますか？

Red Teaming AgentはPyRITをFoundryに統合し、キュレーション済み攻撃データセット、ASRの自動採点、ポータル可視化、クラウド実行を標準提供します。PyRIT単体はこれらを自前実装できる代わりに、プラットフォーム非依存で柔軟に使えます。

マルチターンやマルチモーダルに対応していますか？

基本のインタラクションはシングルターン・テキストのみです。ただし攻撃戦略としてMultiturnやCrescendoが提供され、複数ターンの段階的攻撃はシミュレートできます。画像・音声のマルチモーダル入力は現時点で非対応です。

関連記事

• Google AIレッドチーム戦略の全体像と従来型セキュリティ手法との相違点
• ChatGPTのロックダウンモードの定義とプロンプトインジェクション対策での位置付け
• Azure AI Foundryとは何か？概要と基本的なコンセプトを解説
• 情報システム部門が押さえるサイバーセキュリティAIの基本構造と防御・導入・運用の実務
• CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説