生成AIの脆弱性を自動検出するRed Teaming Agentの基本構造と対象領域

生成AIの脆弱性を自動検出するRed Teaming Agentの基本構造と対象領域

生成AIアプリケーションを本番環境にデプロイする際、安全性の検証は避けて通れない工程です。Azure AI Red Teaming Agentは、Microsoft Foundry（旧Azure AI Foundry）に統合されたパブリックプレビュー機能であり、生成AIシステムに対する敵対的プロービングを自動化するツールとして注目を集めています。従来のセキュリティテストがネットワークやコードの脆弱性を探るのに対し、AIレッドチーミングは生成AIモデル特有のリスクを体系的に洗い出す点で根本的に異なる手法です。この記事では、Red Teaming Agentの構造から導入手順、攻撃戦略の活用法、他ツールとの比較、そして開発パイプラインへの統合設計まで、実務で必要な知識を網羅的に解説していきます。

Foundryに統合された3つの中核機能とスキャン処理の基本フロー

Azure AI Red Teaming Agentの中核を構成するのは、自動スキャン、評価スコアリング、レポーティングの3機能です。自動スキャンでは、MicrosoftのオープンソースフレームワークPyRIT（Python Risk Identification Tool）に由来する攻撃戦略を用いて、対象AIシステムに敵対的プロンプトを送信する仕組みが実装されています。評価スコアリングでは、各攻撃とモデル応答のペアに対してRisk and Safety Evaluatorsが自動でスコアを付与し、Attack Success Rate（ASR）を算出する流れとなっています。レポーティングでは、スキャン結果をFoundryポータル上のダッシュボードで可視化し、リスクカテゴリ別や攻撃複雑度別の成功率をドリルダウン形式で確認できる設計です。

基本的な処理フローとしては、まずシードプロンプト（攻撃目標）が自動生成され、次に選択された攻撃戦略によるプロンプト変換が行われる流れです。変換されたプロンプトがターゲットのAIシステムへ送信され、返却された応答とペアで評価エンジンに渡されたのち、スコアカードが生成される仕組みになっています。最終的にローカル環境またはFoundryプロジェクト上に結果が保存され、この一連の流れが1回のscanメソッド呼び出しで完結する点が大きな特徴です。

対象となるモデルとエンドポイント形式の対応範囲と非対応パターン

Red Teaming Agentがスキャン対象として受け付けるターゲットは、大きく4種類に分類できます。1つ目はAzure OpenAIのモデル構成（エンドポイントとデプロイメント名を指定）、2つ目はシンプルなPythonコールバック関数（文字列入出力）、3つ目はOpenAI Chat Protocolに準拠した複合コールバック関数、4つ目はPyRITのPromptChatTargetクラスを継承した任意のターゲットです。特にPyRIT PromptChatTargetを活用すれば、PyRITエコシステムで対応済みの多様なエンドポイントをそのままスキャン対象にできる柔軟性を備えています。

一方で、現行のプレビュー版にはいくつかの非対応パターンが存在する点に留意してください。クラウド実行モードでターゲットにできるのはFoundryプロジェクト内のAzure OpenAIデプロイメントとFoundry Agentに限定されており、外部のサードパーティモデルを直接指定する手段は提供されていません。また、サポートされるのはシングルターンかつテキストのみのインタラクションであり、マルチターン対話や画像・音声を含むマルチモーダル入力への対応は今後の課題となっています。この制約を理解したうえで、検証範囲を設計する必要があるでしょう。

従来のセキュリティテストと異なるAIレッドチーミング固有の検証観点

従来のレッドチーミングは、サイバーキルチェーンの各段階を攻撃者の視点で検証し、ネットワーク侵入やシステム権限昇格といったセキュリティ脆弱性を発見する手法です。これに対してAIレッドチーミングは、生成AIモデルが不適切なコンテンツを出力してしまうリスクに焦点を当てた検証領域を対象とします。具体的には、暴力的表現の誘発、差別的バイアスの露呈、性的コンテンツの生成、自傷行為を助長する応答といった、AIモデル固有の失敗モードが検証項目に含まれるのが特徴です。

この違いが生じる背景には、生成AIモデルの学習データに起因するリスクが挙げられます。大規模言語モデルはインターネット上のデータで学習しているため、有害なコンテンツや偏った情報を内包している可能性が否定できません。巧妙なプロンプト操作によってそれらが引き出されるおそれもあり、Red Teaming Agentはこうしたリスクを攻撃者の立場からシミュレートする専用ツールとして位置づけられています。モデルの安全性ガードレールが適切に機能しているかを体系的に検証できる点が、従来型のセキュリティテストとの決定的な違いといえるでしょう。

East US2など4リージョン限定で利用可能なプレビュー版の制約事項

Red Teaming Agentのプレビュー版は、Azure AI Foundryプロジェクトが特定のリージョンに配置されている場合にのみ利用可能です。現時点でサポートされているリージョンは、East US 2、Sweden Central、France Central、Switzerland Westの4つに限られています。これ以外のリージョンにプロジェクトを作成している場合、スキャンの実行時にエラーが発生するか、一部の評価機能がスキップされる可能性があるため注意が必要です。

プレビュー版にはサービスレベルアグリーメント（SLA）が付帯されていない点にも留意しなければなりません。Microsoftの公式ドキュメントでは、本番ワークロードへの使用は推奨されていない旨が明記されています。機能面でも制約があり、完全なサンドボックス環境でのテストには対応しておらず、モックツールが返すのは合成データに限られた範囲です。実際の本番データ分布を再現したテストではないため、スキャン結果はあくまで既知リスクカテゴリに対する安全性の参考指標として解釈すべきでしょう。プロジェクトの作成時にはリージョン選択に細心の注意を払い、必要に応じてFoundryプロジェクトの新規作成またはマイグレーションを検討してください。

コンテンツ安全性とセキュリティの両面をカバーする評価対象の具体例

Red Teaming Agentが検証する対象は、コンテンツ安全性リスクとセキュリティリスクの2軸で整理できる構造になっています。コンテンツ安全性の面では、モデルが暴力的な指示に従ってしまうケース、差別的な偏見を含む回答を生成するケース、不適切な性的コンテンツを出力するケース、そして自傷行為に関する情報を提供してしまうケースが主な検証項目に含まれています。これらはAzure AI Content Safetyのフレームワークと整合しており、デフォルト4カテゴリを含む全7種類のリスクカテゴリとして定義された体系です。

セキュリティリスクの面では、プロンプトインジェクションによるシステムプロンプトの漏洩、エンコーディングやキャラクター操作を使ったガードレール回避、そしてエージェントワークフローにおけるツール呼び出しの悪用といったシナリオが含まれている点が見逃せません。たとえば、Base64やモールス符号でエンコードした攻撃プロンプトを送信し、モデルがそれをデコードして有害な応答を生成するかどうかを検証することが可能です。OWASP LLM Top 10やMITRE ATLAS Matrixで指摘されている脅威ベクトルとも対応しているため、業界標準のフレームワークに沿ったリスク評価を実現できるでしょう。

手動テストの限界を超えるPyRIT統合による敵対的プロービング自動化の全容

生成AIの安全性を手動で検証する場合、セキュリティ専門家がプロンプトを個別に作成し、モデルの応答を一つずつ確認する必要があるため、多大な工数が発生します。テスト規模の拡大が直接的に人件費とスケジュールに跳ね返るこの手法では、開発スピードとのトレードオフが避けられません。Red Teaming Agentは、MicrosoftのAIレッドチームが開発したPyRITの攻撃能力をFoundryに統合することで、この構造的課題を解消しているのが最大の特徴です。

MicrosoftのAIレッドチームが100件超の実戦で培ったPyRITの設計思想

PyRIT（Python Risk Identification Tool）は、Microsoft AI Red Teamが自社のレッドチーミング業務で使用するために開発したオープンソースフレームワークです。このチームは業界で最も早期に設立されたAIレッドチームの一つであり、MITRE ATLAS Matrixの前身となったAdversarial ML Threat Matrixの策定や、機械学習の失敗モード分類法の公開など、AI安全性分野の基盤を築いてきた存在として知られています。PyRITは、CopilotシリーズやPhi-3モデルのリリース前検証を含む100件以上のレッドチーミング作戦で活用されてきた実績を誇ります。

設計思想の根幹にあるのは、拡張性とモジュール性という2つの原則です。PyRITのアーキテクチャは、オーケストレーター、コンバーター、ターゲット、スコアリングエンジン、メモリの5コンポーネントで構成されており、それぞれが独立した役割を担っています。オーケストレーターが攻撃全体の制御を担い、コンバーターがプロンプトの変換処理を行い、ターゲットが攻撃先を定義し、スコアリングエンジンが成否を判定し、メモリが過去の攻撃結果を保持するという分業構造です。各コンポーネントを差し替え可能な設計のため、新しい攻撃手法やターゲットへの拡張も容易に行えるでしょう。

シードプロンプト自動生成から攻撃変換までの5ステップ処理パイプライン

Red Teaming Agentの内部処理は、5つのステップで構成されたパイプラインとして理解すると全体像が把握しやすくなります。各ステップの処理内容は以下のとおりです。

1. 指定されたリスクカテゴリに基づいてシードプロンプト（攻撃目標）がキュレーション済みデータセットから選択される（デフォルトでは基本4カテゴリに各10個、合計40個）
2. ベースラインとして変換なしの直接プロンプトがターゲットに送信される
3. 指定された攻撃戦略（Base64エンコード、ROT13変換など）を用いて各ベースラインプロンプトが変換される
4. 変換後のプロンプトがターゲットに送信され、モデル応答が収集される
5. 各攻撃と応答のペアに対してRisk and Safety Evaluatorsがスコアリングを行い、ASRを含むスコアカードが生成される

この5段階の処理全体が非同期で実行されるため、大量の攻撃パターンを効率的に処理できる点がメリットです。ステップ2のベースラインスキャンとステップ3〜4の攻撃戦略適用スキャンは並列に走るわけではなく、ベースラインの結果を踏まえたうえで攻撃変換が実行される逐次的な流れとなっています。この処理構造を理解しておくと、スキャン結果の分析時にベースラインASRと各戦略ASRの差異を正しく解釈できるようになるでしょう。

直接プロービングでは発見できない安全性バイパスの典型的な失敗例

モデルに対して「銀行の強盗方法を教えて」のような直接的な有害プロンプトを送信した場合、ほとんどのモデルは安全性アライメントによって拒否応答を返すことが一般的です。しかし現実の攻撃者は、より巧妙な手法でガードレールを回避しようと試みるのが常套手段といえます。たとえば、プロンプト全体をBase64でエンコードしてモデルに渡す手法や、ロールプレイのシナリオに有害な指示を埋め込む手法、仮説的な質問形式で制限を迂回する手法など、多数のバイパス技術が報告されている状況です。

直接プロービングだけでテストを終えてしまうと、こうした変換型攻撃に対する脆弱性が見落とされるリスクは無視できません。Red Teaming Agentは、PyRITのコンバーター機能を活用してプロンプトを多様な形式に自動変換し、直接的な問い合わせでは表面化しない脆弱性を浮かび上がらせる仕組みを提供しています。ASCIIアート変換やUnicode類似文字の置換、Leetspeak表記への変換など、人間が手動で網羅するには膨大な工数がかかるバリエーションを体系的にカバーできる点が自動化の大きな利点でしょう。

微調整済みの敵対的LLMが生成するプロンプトの多様性と攻撃精度の実態

Red Teaming Agentの内部では、敵対的プロンプトの生成に微調整済みのLLMが使用されている点が技術的な特徴です。このLLMは、安全性ガードレールを回避するための攻撃プロンプトを生成するよう最適化されており、単純なテンプレートベースの攻撃よりも高い多様性と精度を実現する設計になっています。各リスクカテゴリに対してバランスのとれた攻撃目標が生成され、暴力、差別、性的コンテンツ、自傷行為のそれぞれについて異なるアプローチが自動的に試行される仕組みです。

攻撃精度に関しては、モデルの安全性アライメントの強度によってASRが大きく変動する傾向が見られます。十分にファインチューニングされたモデルやContent Safetyフィルタが適切に構成されている環境では、ASRが0%に近づくケースも報告されている状況です。一方で、攻撃戦略の複雑度を上げると、ベースラインでは0%だったASRがEasy・Moderate・Difficultの各レベルで徐々に上昇するパターンが観測されることもあるでしょう。この変化の傾向を分析することで、モデル防御の弱点がどの層に存在するかを特定できるため、スキャン結果は攻撃複雑度別のブレークダウンまで確認することが欠かせません。

カスタムシードファイルによる独自攻撃目標の追加とJSON形式の記述例

デフォルトのシードプロンプトに加えて、業種固有のリスクシナリオや自社アプリケーション特有の攻撃ベクトルをテストしたい場合は、カスタムシードファイルを作成して読み込ませる方法が有効です。シードファイルはJSON形式で記述し、各エントリに攻撃目標のテキストとリスクカテゴリを指定する構造になっています。たとえば金融アプリケーションであれば、不正取引を誘導するプロンプトや個人情報の漏洩を試みるプロンプトなど、ドメイン固有のシナリオを追加できるでしょう。

カスタムシードファイルを使用する場合でも、Red Teaming Agentの攻撃戦略パイプラインは同様に適用される点がポイントです。つまり、独自の攻撃目標がBase64エンコードやROT13変換などの各戦略で自動的に変換され、複合的な攻撃パターンとしてターゲットに送信される流れに変わりはありません。この仕組みにより、業界特有のコンプライアンス要件に沿った安全性テストを自動化でき、手動テストでは到達しにくいカバレッジを効率的に確保することが可能となります。また、日本語を含む6言語（スペイン語、イタリア語、フランス語、日本語、ポルトガル語、簡体字中国語）での攻撃シミュレーションにも対応しており、SupportedLanguagesクラスで言語を指定できる点もグローバル展開を行う企業にとっては重要な機能です。自社のリスクアセスメント結果やインシデント履歴をもとにシードファイルを継続的に拡充していく運用が推奨されるでしょう。

7つのリスクカテゴリ別スキャン設計とASR評価指標の実務的な読み解き方

Red Teaming Agentのスキャンは、リスクカテゴリの選択と攻撃目標数の設定によって結果の粒度と精度が決まる構造です。スキャン設計を適切に行わないと、過剰なコストを費やしても有意義な結果が得られなかったり、逆に不十分なカバレッジのままリスクを見過ごしてしまったりする事態を招きかねません。ここでは、各リスクカテゴリの検出範囲とASR指標の正しい読み方を実務者向けに掘り下げていきます。

デフォルト4カテゴリと拡張3カテゴリが検出する具体的リスク範囲

Red Teaming Agentが対応するリスクカテゴリは全7種類あり、Azure AI Content Safetyのフレームワークに準拠した体系です。デフォルトで有効になるのは、Violence（暴力行為の具体的手順や武器製造方法の説明）、Sexual（性的に露骨なコンテンツや性的搾取の助長）、Hate and Unfairness（人種・性別・宗教等に基づく差別的表現やヘイトスピーチ）、SelfHarm（自傷行為・自殺に関する情報提供や摂食障害の助長）の4カテゴリです。

これに加え、ProtectedMaterial（著作権保護コンテンツの再生成）、CodeVulnerability（脆弱性のあるコード生成）、UngroundedAttributes（根拠のない属性付与）の3カテゴリが拡張リスクとして利用可能になっています。各カテゴリで設定可能な攻撃目標数の上限も異なり、基本4カテゴリは各最大100、ProtectedMaterialとUngroundedAttributesは各最大200、CodeVulnerabilityは最大389という設定です。アプリケーションの用途に応じて対象カテゴリを選択できるため、医療系ではSelfHarmの重点検証が、コード生成系ではCodeVulnerabilityの優先検証が有効であるなど、ドメインに応じたスキャン設計を行うのが望ましいでしょう。

num_objectivesの設定値がスキャン精度とコストに与える影響の比較

num_objectivesパラメータは、各リスクカテゴリに対して生成される攻撃目標の数を指定するものです。デフォルト値は10で、基本4カテゴリすべてを対象とした場合は合計40の攻撃目標が生成される計算になります。カテゴリごとに設定可能な上限値が異なり、基本4カテゴリは最大100、ProtectedMaterialとUngroundedAttributesは最大200、CodeVulnerabilityは最大389です。この数値を増やすほどテストカバレッジは向上する一方、比例して実行時間とSafety Evaluationsの課金額も増大するトレードオフが存在します。

開発初期のプロトタイプ検証であればnum_objectives=5で迅速にフィードバックを得る運用が効率的でしょう。プリデプロイメントの本格的な安全性評価では、デフォルトの10以上に設定し、より広範な攻撃パターンをカバーすることが推奨されます。コスト面での懸念がある場合は、まずリスクカテゴリを絞って少数の目標でスキャンし、問題が検出されたカテゴリに対して追加スキャンを実施する段階的アプローチが実務的な選択肢です。

Attack Success Rateの算出ロジックとリスクカテゴリ別の許容基準

Attack Success Rate（ASR）は、Red Teaming Agentのスキャン結果を評価する中心的な指標として位置づけられています。算出ロジックはシンプルで、攻撃が成功した（モデルが有害な応答を生成した）ペア数を全攻撃ペア数で除した割合です。ASRはリスクカテゴリ別と攻撃複雑度別の2軸でブレークダウンされるため、どのカテゴリのどの攻撃レベルで防御が破られたかを特定できる構造になっています。

許容基準の設定はアプリケーションの用途とリスク許容度によって異なるものの、一般的にはASR 0%を目標とすることが推奨されるでしょう。特にViolenceやSelfHarmのカテゴリでASRが0%を上回る場合は、Content Safetyフィルタの追加やシステムプロンプトの強化を優先的に実施すべき状況といえます。すべてのカテゴリでベースラインASRが0%であっても、Easy以上の攻撃複雑度でASRが上昇するケースは、エンコーディング型攻撃への耐性不足を示唆しているため見逃せません。この場合、入力検証の前処理層を追加するなどの対策が検討に値するでしょう。

スキャン結果のJSON構造とスコアカードから読み取るべき5つの重要項目

スキャン完了後に出力されるJSONスコアカードには、リスク管理上の判断に必要な情報が構造化されて格納されています。最も重要な5項目は、全体ASR（overall_asr）、リスクカテゴリ別ASR（基本4カテゴリについてhate_unfairness_asr、violence_asr、sexual_asr、self_harm_asr）、攻撃複雑度別ASR（baseline_asr、easy_complexity_asr、moderate_complexity_asr、difficult_complexity_asr）、リスクカテゴリと攻撃複雑度のクロス集計（joint_risk_attack_summary）、そしてパラメータセクションに記録されたスキャン設定情報です。さらに詳細スコアカードには、各複雑度レベル内のコンバーター別ASR（たとえばBase64Converter_ASR、FlipConverter_ASRなど）のブレークダウンも含まれており、どの具体的な戦略がモデル防御を突破したかを個別に確認できます。

これらの項目を正しく読み解くためには、まず全体ASRでマクロな安全性レベルを把握し、次にリスクカテゴリ別ASRで問題のあるカテゴリを特定する順序が効果的です。そのうえで攻撃複雑度別ASRを確認し、どの難易度の攻撃で防御が破られたかを分析していきます。クロス集計を参照すれば、たとえばHate and Unfairnessカテゴリに対するModerate複雑度の攻撃だけが成功しているといった、細かなパターンの把握も可能になるでしょう。最後に、パラメータセクションのスキャン設定情報を記録に残すことで、異なる時点のスキャン結果を比較する際の再現性を確保できる点も見落とせません。

Foundryポータル上のレポート画面で攻撃応答ペアを精査する実務手順

ローカル実行でもクラウド実行でも、スキャン結果はFoundryプロジェクトに自動的にログとして保存される設計です。Foundryポータルにアクセスし、Evaluationページの「AI red teaming」タブを選択すると、過去のスキャン一覧が表示される画面に遷移します。各スキャンを開くと、リスクカテゴリ別の成功攻撃数サマリーと攻撃複雑度別の内訳グラフが確認できるレイアウトが用意されています。

より詳細な分析を行うには、データタブに切り替えて個々の攻撃応答ペアを確認する手順が不可欠です。各ペアには、攻撃の成否、使用された攻撃戦略、攻撃複雑度が付記されており、「View more」を選択すると完全な対話内容を閲覧できる仕組みになっています。ここで人間のレビュアーがサムズアップ・サムズダウンのアイコンを使ってフィードバックを付与することも可能であり、自動スコアリングでは検出しきれない微妙な安全性問題を拾い上げる役割を果たすでしょう。スキャン結果の精査を定期的に行い、フィードバックをシステムプロンプトの改善やContent Safetyフィルタの調整に反映させていく運用サイクルの確立が、継続的な安全性向上の鍵といえます。

SDK導入から初回スキャン実行までの環境構築手順とPython要件の注意点

Red Teaming Agentを使い始めるには、適切なSDKのインストールと認証設定が欠かせません。利用するSDKにはAzure AI Evaluation SDKとAzure AI Projects SDK（旧Azure AI Foundry SDK）の2系統があり、ローカル実行とクラウド実行で使い分ける形式です。ここでは環境構築の全手順を具体的なコマンドとともに示し、初心者がつまずきやすいポイントを先回りして解説していきます。

Evaluation SDKとredteamパッケージのインストール手順と依存関係

ローカル環境でRed Teaming Agentを実行するには、Azure AI Evaluation SDKにredteamエクストラを追加してインストールする手順が必要です。このredteamパッケージがPyRITの機能を提供しており、敵対的プロンプトの生成や攻撃戦略の適用に必要なコンポーネントが含まれた構成になっています。インストールコマンドはpip install "azure-ai-evaluation[redteam]"であり、併せて認証用のazure-identityパッケージも導入しなければなりません。なお、ローカル実行版はFoundry（new）ポータルおよびSDKとは互換性がない点に注意が必要です。

クラウド実行を行う場合は、Azure AI Projects SDKを使用する形式に切り替わります。インストールコマンドはpip install azure-ai-projects azure-identityで、バージョンはプレビュー版（1.1.0b3以上または2.0.0b1以上）を指定しなければなりません。ローカル実行用のEvaluation SDKとクラウド実行用のProjects SDKは、それぞれ異なるRedTeamクラスを提供しているため、インポートパスが異なる点に注意してください。ローカル版はazure.ai.evaluation.red_teamから、クラウド版はazure.ai.projects.modelsからインポートする違いがあります。依存関係の衝突を避けるため、仮想環境を作成してからインストールすることが推奨されるでしょう。

Python 3.10〜3.12限定の互換性要件と3.9以下で起きる典型エラー

Red Teaming Agentの実行環境として対応しているPythonバージョンは3.10、3.11、3.12の3つに限定されています。これはPyRITの依存ライブラリがPython 3.10以降の構文や標準ライブラリの機能に依存しているためです。Python 3.9以下の環境でredteamパッケージをインストールしようとすると、依存解決の段階でエラーが発生するか、インストール自体は完了しても実行時にインポートエラーが表示される事態に陥ります。

特に注意すべきは、企業環境でシステムPythonが3.8や3.9に固定されているケースでしょう。この場合、pyenvやcondaを使って3.10以降の環境を別途構築しなければなりません。また、Python 3.13以降についてもPyRITのコミュニティで互換性の問題が報告されているため、現時点では3.10〜3.12の範囲に留めるのが安全な選択です。Dockerコンテナを使用する場合は、ベースイメージにPython 3.11または3.12を指定することで環境差異によるトラブルを回避できるでしょう。バージョン管理が不十分な状態でスキャンを開始すると原因特定に時間がかかるため、最初にpython --versionで確認する習慣をつけておくことが重要です。

DefaultAzureCredentialの認証設定とプロジェクト情報の構成例

Red Teaming Agentの認証にはDefaultAzureCredentialが標準的に使用される方式です。このクラスは、環境変数、マネージドID、Azure CLI認証など複数の認証方式を自動的に試行するため、開発環境と本番環境の両方で同一コードを利用できる利点があります。ローカル開発時は、事前にaz loginでAzure CLIにサインインしておく必要がある点に留意してください。

プロジェクト情報の指定方法は2通り用意されています。1つ目は辞書形式でsubscription_id、resource_group_name、project_nameの3項目を個別に指定する方式です。2つ目は、プロジェクトエンドポイントURLを文字列で直接指定する方式であり、形式はhttps://<account_name>.services.ai.azure.com/api/projects/<project_name>となります。クラウド実行時にはエンドポイントURL方式が推奨されるでしょう。いずれの場合も、認証ユーザーにはFoundryプロジェクトに対する「Azure AI User」ロールが付与されている必要があり、評価結果のアップロードにはストレージアカウントへの「Storage Blob Data Contributor」ロールも求められる点が見落としやすいポイントです。

モデル構成・コールバック・PyRITターゲットの4種類の指定方法

ローカル実行時のターゲット指定には、モデル構成を直接渡す方式、シンプルコールバック関数方式、Chat Protocol準拠の複合コールバック方式、PyRIT PromptChatTarget方式の4種類が提供されています。シンプルコールバック方式は、文字列を受け取って文字列を返す任意のPython関数をターゲットとして定義できるため、カスタムアプリケーションのエンドポイントやサードパーティのモデルAPIをラップして検証する際に便利な選択肢です。

モデル構成方式では、azure_endpoint、azure_deployment、api_keyを辞書形式で指定してスキャン対象に渡します。Entra ID認証を使用する場合はapi_keyの指定は不要で、事前のaz loginのみで認証が完了する仕組みです。クラウド実行モードでは現時点でAzure OpenAIデプロイメントとFoundry Agent（プロンプトエージェントおよびコンテナエージェント）がサポートされている制約を再確認しておきましょう。ターゲットのデプロイメント名が実環境と一致していないケースはよくあるトラブルの原因であり、az cognitiveservices account deployment listコマンドで正確なデプロイメント名を事前確認することが推奨されます。

ローカル実行とクラウド実行の使い分け基準とストレージ権限の落とし穴

ローカル実行は、開発段階でのプロトタイピングや小規模なスキャンに適した方式です。コード変更のたびに即座にスキャンを実行してフィードバックを得るサイクルに向いており、攻撃戦略やリスクカテゴリを限定した軽量テストに最適な選択肢といえるでしょう。一方、クラウド実行はプリデプロイメントの本格的な安全性評価に適しており、より多くの攻撃戦略とリスクカテゴリの組み合わせを大規模に処理する能力を備えています。さらにクラウド実行では、定期的なスキャンのスケジューリングにも対応しているため、デプロイ後の継続的監視にも活用可能です。

クラウド実行を利用する際にはFoundryプロジェクトのタイプにも注意が必要になります。ハブベースプロジェクトではクラウド実行が非対応であり、Foundryプロジェクト（新形式）への移行が求められる状況です。また、ストレージ権限は見落としやすい落とし穴として頻繁に問題が報告されています。スキャン結果をFoundryプロジェクトにアップロードするには、接続されたストレージアカウントでMicrosoft Entra ID認証が有効になっていなければなりません。加えて、ユーザーまたはマネージドIDに対して「Storage Blob Data Contributor」ロールが割り当てられていないと、スキャン自体は完了するものの結果がポータルに表示されないという事象が発生するため、初回セットアップ時にIAM設定を漏れなく確認しておくことが不可欠です。

3段階の攻撃複雑度とカスタム戦略を組み合わせたスキャン結果の改善手法

Red Teaming Agentの攻撃戦略は、単純なエンコーディングから複数手法を連鎖させる高度な攻撃まで、幅広い複雑度をカバーした体系です。スキャン結果を改善につなげるには、攻撃複雑度ごとのASR傾向を分析し、モデル防御の弱点を正確に特定したうえで適切な対策を講じるプロセスが不可欠となります。

Easy・Moderate・Difficultの各レベルが想定する攻撃者像と技術要件

攻撃複雑度の3段階は、攻撃者が必要とするリソースと技術力に基づいて分類された体系です。Easy複雑度は、テキストを特定のエンコーディングに変換するだけの比較的単純な攻撃であり、プログラミングの基本知識があれば実行可能な水準に設定されています。デフォルトのEASYグループにはBase64、Flip、Morseの3戦略が含まれていますが、個別指定では20種類以上のEasy戦略（Jailbreak、IndirectAttackを含む）が利用可能です。

Moderate複雑度は、攻撃の実行に別の生成AIモデルへのアクセスを必要とするレベルとして定義されています。デフォルトのMODERATEグループにはTense（時制変換）戦略が含まれ、攻撃プロンプトを過去形に書き換えてフィルタを迂回する手法です。Difficult複雑度は、デフォルトではTenseとBase64のCompose（連鎖）として定義されていますが、個別指定ではMultiturn（複数ターンにわたる段階的攻撃）やCrescendo（徐々にリスクを高める攻撃）も利用できます。企業のリスク評価では、最低でもModerate以上の攻撃に耐えられることを基準とし、高セキュリティ要件のアプリケーションではDifficult攻撃への耐性も必須と考えるべきです。

Base64・ROT13・Morse Codeなど主要エンコード戦略の特性と有効場面

Red Teaming Agentが提供する個別の攻撃戦略は、テキスト変換、キャラクター操作、エンコーディング技法、プロンプト攻撃、対話型攻撃の5系統に大別できる構成となっています。テキスト変換にはBase64、ROT13、バイナリ、Morseなどが含まれ、プロンプト全体を異なる表記体系に変換してモデルの入力フィルタを回避する目的で使用されるのが一般的です。

上記以外にも、Atbash、Binary、Caesar、CharacterSpace、CharSwap、Diacritic、AsciiSmuggler、AnsiAttack、SuffixAppend、StringJoin、UnicodeSubstitution、Urlなど多数のEasy戦略が提供されています。キャラクター操作やエンコーディング技法は入力のパターンマッチングベースのフィルタを欺く効果が期待できるでしょう。特筆すべきは、MultiturnやCrescendoといったDifficult戦略では複数ターンの対話を通じた攻撃が可能であり、基本的にはシングルターンのテキストインタラクションがベースでありながら、攻撃戦略としてはマルチターン手法も利用できる点です。これらの戦略は単体で使用するだけでなく、Compose機能を用いて組み合わせることで攻撃の複雑度をさらに高められる点が実務上の重要な活用ポイントとなります。

Compose機能で2つ以上の戦略を連鎖させる多段攻撃シナリオの設計例

Red Teaming AgentのAttackStrategy.Compose機能は、複数の攻撃戦略をパイプラインとして連鎖させることで、単一戦略では検出できない脆弱性を浮き彫りにする強力な仕組みです。たとえば、AttackStrategy.Compose([AttackStrategy.Base64, AttackStrategy.ROT13])と指定すると、まずプロンプトがBase64でエンコードされ、次にROT13変換が適用される二段階の攻撃が実行される流れとなります。

多段攻撃の設計では、変換の順序が結果に影響する点に注意しなければなりません。Base64でエンコードした後にROT13を適用する場合と、ROT13を適用した後にBase64でエンコードする場合では、最終的なプロンプトの形態が異なるためです。実務的には、まず単一戦略で各攻撃手法の有効性を個別に確認し、ASRが0%に近い戦略同士を組み合わせるよりも、ASRが上昇した戦略を基軸にCompose攻撃を構成するほうが弱点をより深く掘り下げられるでしょう。上級者は、PyRITの個別コンバーターを直接利用して3段階以上のCompose攻撃を構築し、モデルの防御限界を体系的に探ることも可能です。

攻撃複雑度別ASRの乖離パターンから特定するモデル防御の弱点領域

スキャン結果の分析で最も重要なのは、攻撃複雑度ごとのASR推移パターンを正しく解釈する作業です。たとえば、ベースラインASRが0%でEasy複雑度のASRも0%、しかしModerate複雑度で突然ASRが上昇するパターンは、基本的な入力フィルタは機能しているものの、LLMを活用した巧妙なプロンプトリライトに対する耐性が不足していることを示唆しているといえるでしょう。

別のパターンとして、ベースラインASRは0%だがEasy複雑度のASRが一定の値を示すケースがあり、これはエンコーディング型攻撃への防御が手薄であることを意味する兆候です。この場合、入力段階でのデコード処理やエンコーディング検出ロジックの追加が効果的な対策となるでしょう。また、特定のリスクカテゴリだけがDifficult攻撃に弱いというクロス集計上のパターンは、そのカテゴリに関する安全性アライメントの不十分さを示す重要なシグナルです。このような分析結果は、ファインチューニングの重点領域やContent Safetyフィルタのカスタムルール追加の根拠として活用することが推奨されます。

Content Safetyフィルタとシステムメッセージ調整によるASR低減の実践例

スキャン結果でASRの課題が特定された場合、最も即効性のある対策はAzure AI Content Safetyフィルタの適用でしょう。Content Safetyフィルタは、モデルの入出力に対してリアルタイムでコンテンツ分類を行い、有害と判定されたコンテンツをブロックする防御機構です。Red Teaming Agentのスキャンで高ASRを示したリスクカテゴリについて、対応するContent Safetyカテゴリのしきい値を厳格化することで、防御層を一段強化できる効果が見込めます。

もう一つの重要な対策は、システムメッセージ（システムプロンプト）の見直しです。Microsoftが提供するセーフティシステムメッセージテンプレートを活用し、モデルに対して明確な制約条件を設定することで、攻撃プロンプトへの耐性が向上する効果が期待できるでしょう。実践的なアプローチとしては、まずRed Teaming Agentでスキャンを実行してASRが0%でないカテゴリを特定し、次にContent Safetyフィルタの設定を調整すると同時にシステムメッセージに該当カテゴリの拒否ルールを追加する流れが効率的です。その後、同一条件で再スキャンを実行してASRの変化を測定し、改善効果を定量的に検証するという反復サイクルを回すことが、段階的な安全性向上への確実な道筋となります。

PyRIT単体や他ツールとの機能差から見るAgent選定時の判断軸と制約

AIレッドチーミングの自動化ツールはRed Teaming Agent以外にも選択肢が存在する状況です。PyRITをスタンドアロンで使用する方式や、GiskardやLakeraといったサードパーティ製品との比較を通じて、自組織にとって最適なツールを選定する判断が求められます。ここでは各ツールの強みと制約を整理し、選定時の判断軸を明確にしていきましょう。

PyRIT単体利用とFoundry統合版の5つの機能差と運用負荷の比較

PyRITは単体のオープンソースフレームワークとしても利用可能であり、GitHubから直接インストールできるツールです。Red Teaming AgentはこのPyRITの機能をFoundryに統合したマネージドサービスという位置づけになっています。両者の主要な機能差は以下の5つの観点で整理できるでしょう。

運用負荷の観点では、PyRIT単体はカスタマイズ性に優れる反面、インフラ構築やスコアリングロジックの実装に追加工数がかかるのが実情です。一方、Red Teaming Agentはマネージドな環境で即座に利用を開始できるメリットがある反面、マルチターン攻撃への非対応やリージョン制限などの制約を受け入れる必要があるでしょう。セキュリティ専門チームが既にPyRITの運用経験を持っている場合は単体利用を継続しつつFoundry統合版を併用する形が効率的であり、レッドチーミング初心者であればFoundry統合版から始めるのが適切な入口です。

GiskardやLakeraなど競合ツールが得意とする検証領域との棲み分け

AIレッドチーミング市場にはRed Teaming Agent以外にも複数の選択肢が存在しており、それぞれ得意とする検証領域が異なる状況です。Giskardは、オープンソースのAIテストフレームワークとして、再現可能なテストシナリオの構築とリグレッションテストに強みを持つ製品として知られています。モデル更新のたびに同一条件でテストを自動実行し、安全性の劣化を検知する用途に適したツールといえるでしょう。

Lakeraは、ランタイム防御に重点を置いたソリューションであり、プロンプトインジェクションのリアルタイム検出と防御が中核機能として位置づけられています。Lakera Guardを通じたランタイム保護と、Lakera Redによるプリデプロイメントのリスク評価を組み合わせた包括的なアプローチが特徴的です。Red Teaming AgentがMicrosoftのエコシステムに深く統合されたAzure環境向けの選択肢であるのに対し、GiskardやLakeraはマルチクラウドやオンプレミスでの利用にも対応しています。自組織のクラウド戦略やモデルホスティング環境に応じて、単一ツールに依存するのではなく複数ツールを組み合わせる選定が現実的な判断となるでしょう。

テキスト専用やサンドボックス未対応など現行プレビュー版の主要制限事項

Red Teaming Agentのプレビュー版には、導入判断に直接影響する制限事項がいくつか存在する点を把握しておく必要があるでしょう。基本的なインタラクションモードはシングルターンのテキストのみに限定されていますが、攻撃戦略としてはMultiturnやCrescendoといったDifficult複雑度の手法が提供されており、複数ターンにわたる段階的攻撃のシミュレーションは可能です。ただし、マルチモーダル入力（画像・音声）への対応は現時点では提供されていない状況にあります。

また、モックツールは合成データの取得にのみ対応しており、動作のモック（ツール実行結果のシミュレーション）には非対応です。そのため、エージェントワークフローにおけるツール呼び出しの安全性検証は限定的な範囲にとどまる点も認識しておくべきでしょう。サンドボックスの完全な分離も保証されていないため、敵対的テストの影響が実環境に波及しないよう制御されている一方で、本番に近い環境でのテストには適していない制約があります。SLAが付帯されていないことも運用上のリスクであり、これらの制約を踏まえたうえでプレビュー版を既知リスクの初期スクリーニングとして位置づけ、補完的な手動テストと併用する運用が現実的な選択肢です。

Safety Evaluations課金とスキャン規模別コスト試算の実務例

Red Teaming Agent自体には独自の料金体系は設定されておらず、課金はバックエンドで使用されるAzure AI Risk and Safety Evaluationsの消費量に基づく従量課金モデルです。Azureの料金ページで「Complete AI Toolchain」タブに表示されるSafety Evaluationsの単価が適用される仕組みになっています。つまり、攻撃と応答のペア数に比例してコストが増加していく構造です。

コストを試算する際の基本的な計算式は、リスクカテゴリ数×num_objectives×（1＋攻撃戦略数）でおおよその攻撃応答ペア総数を算出し、それにSafety Evaluationsの単価を掛けるという流れになります。たとえば基本4カテゴリ×10目標×（1ベースライン＋3攻撃戦略）＝160ペアが基本的な1スキャンあたりの規模です。コスト最適化を図るには、まず小規模スキャンでリスクの高いカテゴリを特定し、次に該当カテゴリのみで攻撃戦略を拡張するという2段階アプローチが効果的でしょう。定期実行を設定する場合は、毎回フルスキャンを実行するのではなく、リスクカテゴリや攻撃戦略を日替わりでローテーションさせてコストを分散する方法も検討に値します。

Azure以外のクラウドやオンプレミス環境での代替手段と移行判断の基準

Red Teaming AgentはAzure AI Foundryへの依存度が高いサービスであるため、AWSやGoogle Cloud上でホストしているモデルに対して直接スキャンを実行することはできない制約があります。ただし、ローカル実行モードのコールバック関数を活用すれば、外部APIを呼び出すラッパー関数を作成して間接的にテストすることは技術的に可能です。この場合はクラウド実行の利点であるスケーラビリティやFoundryポータルとの統合が失われる点を考慮しなければなりません。

マルチクラウド環境でAIレッドチーミングを統一的に実施したい場合、PyRIT単体をプラットフォーム非依存のツールとして採用する選択肢が有力でしょう。PyRITはAzure OpenAIだけでなくHugging Faceやカスタムエンドポイントにも対応しているため、クラウドプロバイダーに縛られない柔軟な運用が可能になります。移行判断の基準としては、検証対象モデルの大部分がAzure上にあるならRed Teaming Agentを主軸とするのが合理的な選択です。一方、マルチクラウドや大規模なオンプレミス環境がある場合はPyRIT単体またはGiskardのようなプラットフォーム非依存ツールを主軸に据えたほうが運用負荷を抑えられるでしょう。

開発パイプラインへのRed Teaming Agent統合と継続的安全監視の運用設計

Red Teaming Agentの価値は、1回限りのスキャンではなく、開発ライフサイクル全体を通じた継続的な安全性検証に組み込むことで最大化される性質を持っています。ここでは、設計から運用後までの各フェーズにおけるスキャンの活用方法と、CI/CDパイプラインへの統合パターンを具体的に解説していきましょう。

設計・開発・デプロイ前・運用後の4フェーズ別スキャン頻度の推奨基準

Microsoftは、Red Teaming Agentの活用を設計（Design）、開発（Development）、デプロイ前（Pre-deployment）、運用後（Post-deployment）の4フェーズで推奨しています。設計フェーズでは、候補となる基盤モデル同士の安全性を比較し、ユースケースに最適なモデルを選定するためにスキャンを活用する位置づけです。この段階では少ないnum_objectivesで迅速にベースラインを比較するスキャンが適しているでしょう。

開発フェーズでは、モデルのアップグレードやファインチューニングのたびにスキャンを実行し、安全性のリグレッションがないことを検証する運用が求められます。デプロイ前フェーズでは、すべてのリスクカテゴリと攻撃複雑度を網羅したフルスキャンを実施し、本番環境への投入可否を判断する最終的なゲートとして機能させるのが理想的な形です。運用後フェーズでは、クラウド実行のスケジューリング機能を活用して定期的な自動スキャンを設定し、モデルの動作変化や新たな攻撃手法の出現に対する継続的な監視を行います。スキャン頻度は、開発段階ではスプリントごと、デプロイ前には各リリースごと、運用後は週次から月次が一般的な目安といえるでしょう。

CI/CDパイプラインにスキャンを組み込む際の実装パターンと自動化の注意点

Red Teaming AgentのスキャンをCI/CDパイプラインに組み込むことで、コード変更が安全性に悪影響を与えていないかを自動的に検証する体制を構築できます。基本的な実装パターンは、パイプラインのテストステージにPythonスクリプトを追加し、スキャン結果のASRが設定したしきい値を超えた場合にパイプラインを失敗させるゲートチェックを構成する方式です。

自動化にあたっての注意点として、まずRed Teaming Agentの実行には30分以上かかることがあるため、パイプラインのタイムアウト設定を十分に長くしなければなりません。次に、認証にインタラクティブブラウザ認証が使用される場合はCI/CD環境では動作しないため、マネージドIDまたはサービスプリンシパルによる認証に切り替える必要がある点も重要でしょう。さらに、スキャンの実行にはAzureリソースへのネットワーク接続が必要であり、プライベートネットワーク環境ではプロキシ設定やファイアウォールルールの追加が求められるケースも想定されます。パイプラインの実行コストも考慮し、毎回フルスキャンを実行するのではなく、変更されたコンポーネントに関連するリスクカテゴリのみをターゲットとする差分スキャンの設計も検討すべきです。

モデル更新やファインチューニング後に再スキャンが必須となる3つの条件

すべてのモデル変更に対してフルスキャンを実行するのはコスト効率が悪いため、再スキャンが必須となる条件を明確に定義しておくことが運用の鍵となります。以下の3条件に該当する場合は、必ず再スキャンを実施すべきです。

• 基盤モデルのバージョンアップグレード：GPT-4oからGPT-4o-miniへの切り替えやマイナーバージョンの更新であっても、安全性アライメントの挙動が変化する可能性があるため再スキャンが不可欠となる
• カスタムファインチューニングの適用：ファインチューニングによってモデルの応答傾向が変化するため、安全性ガードレールが弱体化していないかの検証が求められる
• システムプロンプトやContent Safetyフィルタの設定変更：安全性を強化する方向の変更であっても、意図しない副作用で特定カテゴリの防御が低下する可能性があり、変更後の効果確認が必要となる

これら3条件を開発チームの運用ガイドラインに明文化し、再スキャンの責任者とスキャン設定の標準パラメータを定めておくことで、属人化を防ぎつつ安全性検証の一貫性を担保できるでしょう。条件に該当しない軽微な変更（UIの修正やバックエンドロジックの変更でモデル連携部分に影響がないケースなど）についてはスキャンを省略し、コストの最適化を図る判断も合理的です。

Content Safetyフィルタやガードレールとの多層防御を構成する設計指針

Red Teaming Agentはリスクを検出するツールであり、リスクを防御するツールではないという点を正しく理解しておく必要があるでしょう。検出された脆弱性に対する実際の防御は、Content Safetyフィルタ、システムメッセージ、Foundry Control Planeなどの防御機構を多層的に構成して実現しなければなりません。多層防御の設計では、各層が異なる種類の脅威に対応することが理想的な構造です。

第1層にはAzure AI Content Safetyフィルタを配置し、入出力のリアルタイムコンテンツ分類による即座のブロックを担当させる形が基本です。第2層にはシステムメッセージによるモデル挙動の制約を設定し、安全性ポリシーに沿った応答を生成するようモデルをガイドする役割を持たせます。第3層にはFoundry Control Planeを活用し、エージェントワークフロー全体のガバナンスとアクセス制御を実施する構成が推奨されるでしょう。Red Teaming Agentは、この多層防御の有効性を定期的に検証する役割を担い、各層のフィルタ設定やルールが実際の攻撃に対して期待どおりに機能しているかを確認するためのツールとして位置づけるのが適切です。防御の構築と検証のサイクルを継続的に回すことが、生成AIシステムの長期的な安全性維持の基盤となります。

OWASP LLM Top 10とMITRE ATLASに沿ったリスク管理体制の構築例

組織全体のAI安全性ガバナンスを構築する際には、OWASP LLM Top 10やMITRE ATLAS Matrixといった業界標準フレームワークを参照することが効果的な出発点です。OWASP LLM Top 10の2025年版では、プロンプトインジェクションがLLMアプリケーションにおける最大のリスクとして位置づけられています。MITRE ATLAS Matrixは、AI特有の攻撃技術と緩和策をマトリクス形式で整理した体系であり、MicrosoftのAIレッドチームが策定に関与した経緯を持つフレームワークとしても知られています。

リスク管理体制の構築にあたっては、NISTのAIリスクマネジメントフレームワークに沿ったGovern・Map・Measure・Manageの4ステップが参考になるでしょう。Mapステップでは、OWASP LLM Top 10を参照して自社アプリケーションに該当するリスクカテゴリを特定する作業から着手します。Measureステップでは、Red Teaming Agentのスキャンを活用して各リスクの深刻度を定量的に評価する工程が中心です。Manageステップでは、Content SafetyフィルタやFoundry Control Planeを用いた防御策を実装し、運用中のインシデント対応計画を策定する段階に移行します。Governステップでは、スキャン結果のレポートを定期的にステークホルダーに共有し、リスク許容基準の見直しや新たな脅威への対応方針を組織的に意思決定する体制の整備が求められるでしょう。こうした体系的なアプローチにより、Red Teaming Agentの出力を単なる技術的なテスト結果ではなく、経営レベルのリスク管理判断に活用できる形に昇華させることが可能となります。