Azure AI FoundryのAI Red Teaming Agentで重要なのは、生成AIモデルやAIエージェントを本番投入する前に、危険な出力・プロンプトインジェクション・機密データ漏えい・禁止アクションなどを自動的に検査できる点です。2026年5月19日に更新された公式ドキュメントでは、特にクラウド実行、エージェント固有リスクの評価、SDK/APIによる実行、RBACロール名の変更、対応ターゲットの制限を確認する必要があります。(Microsoft Learn)
社内Copilot、RAGチャットボット、ツール実行型エージェントをAzure AI Foundryで開発している場合、AI Red Teaming Agentは「最後に一度だけ試す安全性チェック」ではありません。設計、開発、デプロイ前、本番後の継続監視まで組み込むべき評価プロセスとして捉えるのが実務上のポイントです。(Microsoft Learn)
AI Red Teaming Agentとは何か
AI Red Teaming Agentは、生成AIシステムに対して敵対的な入力や攻撃パターンを自動的に試し、モデルやエージェントが安全でない応答や動作をしないかを評価するAzure AI Foundry向けの機能です。MicrosoftのオープンソースフレームワークであるPyRITのAIレッドチーミング機能と、FoundryのRisk and Safety Evaluationsを組み合わせて、スキャン、評価、レポート作成を行います。(Microsoft Learn)
従来のセキュリティテストがシステムやネットワークの脆弱性を探すのに対し、AI Red Teaming Agentは生成AI特有の失敗を探します。たとえば、次のようなリスクです。
- 有害コンテンツを生成してしまう
- プロンプトインジェクションで制約を回避される
- RAGやツール呼び出し経由で機密情報を漏らす
- エージェントが禁止された操作や不可逆な操作を実行する
- 指示された業務手順を守らず、誤った判断をする
評価結果では、攻撃と応答のペアを分析し、攻撃成功率であるASRを使ってリスクの傾向を把握できます。ASRは、実行した攻撃のうち、望ましくない応答や挙動を引き出せた割合を示す指標です。(Microsoft Learn)
2026年5月19日更新で確認すべき主な変更点
2026年5月19日に更新された公式ドキュメントの中心は、クラウドでAI Red Teaming Agentを実行する手順です。ローカルでのプロトタイプ検証だけでなく、より大きな攻撃戦略とリスクカテゴリの組み合わせ、本番後のスケジュール実行、エージェント固有リスクの評価に対応する流れが整理されています。(Microsoft Learn)
| 確認項目 | 内容 | 実務上の影響 |
|---|---|---|
| クラウド実行の位置付け | デプロイ前評価、継続的な本番後評価、エージェント固有リスクの評価に使う | 本番前チェックだけでなく、運用監視の一部として設計する必要がある |
| SDK | azure-ai-projects>=2.0.0 を利用 | 既存の評価コードやCI/CDの依存関係を見直す |
| 認証 | DefaultAzureCredential によるキーレス認証が推奨 | APIキー前提の実装は、Entra IDベースの認証へ移行を検討する |
| RBAC | Foundry Userなどのロール名に変更。旧Azure AI Userなどの名称が一部表示される可能性あり | 権限設定の確認時に、新旧ロール名の混在で誤認しないよう注意する |
| 対象 | Foundryプロジェクトのデプロイ、Azure OpenAIモデルデプロイ、Foundry Agentsが対象 | すべての外部エージェントやツールが評価対象になるわけではない |
特に管理者が見落としやすいのがRBACロール名の変更です。Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当します。ロールIDと中核権限は変更されていないものの、名称変更の反映中は旧名称が表示される場合があります。(Microsoft Learn)
クラウド実行とローカル実行の使い分け
AI Red Teaming Agentには、クラウド実行とローカル実行があります。どちらか一方だけを選ぶというより、開発段階と本番準備段階で使い分けるのが現実的です。
| 利用シーン | 推奨される実行方法 | 判断基準 |
|---|---|---|
| 初期プロトタイプの安全性確認 | ローカル実行 | 小さなモデルやコールバック関数を素早く検証したい |
| モデル選定時の比較 | ローカルまたはクラウド | 複数モデルのASRやリスクカテゴリ別の傾向を比較したい |
| 本番リリース前のゲート | クラウド実行 | 攻撃戦略とリスクカテゴリを広く組み合わせたい |
| ツール実行型エージェントの検証 | クラウド実行 | 禁止アクション、機密データ漏えい、タスク遵守などを見たい |
| 本番後の定期チェック | クラウド実行 | スケジュール実行や継続的なリスク追跡を行いたい |
ローカル実行ドキュメントでは、AI Red Teaming Agentのローカル実行はプレビュー扱いで、SLAなし、運用環境のワークロードには推奨されないと説明されています。また、ローカルのAI Red Teaming AgentはFoundryの新しいポータルおよびSDKと互換性がない点にも注意が必要です。(Microsoft Learn)
一方、Microsoft Foundry BlogではAI Red Teaming Agentが一般提供として説明されており、Foundry SDK/API、No-code UI、CI/CD連携、継続的なリスク追跡が紹介されています。ただし、個別機能や実行形態にはプレビュー表記が残る場合があるため、導入時は使用する実行方法ごとに公式ドキュメントの状態を確認してください。(Microsoft for Developers)
影響を受ける対象サービスとワークロード
今回の更新で特に影響を受けるのは、Azure AI Foundry上で生成AIアプリやAIエージェントを開発・運用しているチームです。クラウド実行でサポートされるターゲットは、Foundryプロジェクトのデプロイ、Azure OpenAIモデルデプロイ、Microsoft Foundryプロジェクト内のFoundry Agentsです。(Microsoft Learn)
エージェントやツールについては、対応範囲に制限があります。公式情報では、Foundryでホストされたプロンプトエージェントとコンテナーエージェントはサポート対象ですが、Foundry workflow agents、Foundry以外のエージェント、非Azureツール、Function tool calls、ブラウザー自動化、Connected Agent tool calls、Computer Use tool callsはサポート外とされています。(Microsoft Learn)
つまり、次のような構成では事前確認が必要です。
- LangGraphや独自HTTP APIで構築した外部エージェントをそのまま評価したい
- Azure以外のSaaSツールを多数呼び出すエージェントを評価したい
- ブラウザー操作やComputer Useを含む業務自動化エージェントを検証したい
- Function callingを中心に組んだ既存アプリを同じ方法で評価したい
これらは「安全性評価が不要」という意味ではありません。AI Red Teaming Agentのサポート範囲に入るように評価対象を切り出すか、別の評価手法や手動レビューを組み合わせる必要があります。
管理者が確認すべき設定
管理者は、開発者がAI Red Teaming Agentを実行できるかだけでなく、誰が、どの環境で、どのターゲットに対して、どの権限で実行するのかを確認する必要があります。
FoundryプロジェクトとRBAC
クラウド実行にはFoundryプロジェクトと、対象プロジェクトに対するFoundry Userロールが必要です。ロール名の変更により、管理画面や既存ドキュメント、社内手順書でAzure AI Userなどの旧名称が残っている場合があります。権限棚卸しを行う際は、新旧名称を対応付けて確認しましょう。(Microsoft Learn)
実務では、次のように整理すると混乱を防げます。
| 確認対象 | 見るべきポイント |
|---|---|
| 開発者アカウント | Foundry User相当の権限が付与されているか |
| CI/CD用ID | DefaultAzureCredential で認証できるマネージドIDやサービスプリンシパルになっているか |
| プロジェクト境界 | 評価対象のモデルやエージェントが同じFoundryプロジェクト、または接続済みリソースとして扱えるか |
| 旧ロール名 | 社内手順書にAzure AI Userなどの旧名称が残っていないか |
リージョン対応
AI Red Teaming Agentのクラウドレッドチーミングは、公式ドキュメント上でEast US 2、France Central、Sweden Central、Switzerland West、US North Centralに対応すると説明されています。対象のAzure AI Projectがサポートリージョン外にある場合、評価用プロジェクトを別リージョンに用意する必要が出る可能性があります。(Microsoft Learn)
日本リージョンを前提にAI Foundry環境を構築している場合は、本番環境をそのまま動かすのではなく、サポートリージョンに本番相当の検証環境を作る判断が現実的です。機密データや本番ツールを直接接続せず、合成データや制限付きツールで再現する設計にしましょう。
認証方式
公式手順では、Foundryプロジェクト内のモデルデプロイを使う場合、DefaultAzureCredential を使ったキーレス認証が推奨されています。APIキー認証も例示されていますが、可能であればEntra IDベースの認証に寄せる方が、権限管理やキー漏えい対策の面で扱いやすくなります。(Microsoft Learn)
開発者が確認すべき実装ポイント
開発者が最初に確認すべきなのは、評価対象の指定方法です。Foundryプロジェクト内のデプロイを使う場合はデプロイ名を直接指定できます。一方、Azure OpenAIやFoundry Toolsアカウントのデプロイを使う場合は、接続を作成し、connectionName/deploymentName の形式でモデルデプロイを指定します。(Microsoft Learn)
クラウド実行の最小構成では、次の要素を準備します。
pip install "azure-ai-projects>=2.0.0"endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
agent_name = os.environ["AZURE_AI_AGENT_NAME"]エージェント固有リスクを評価する場合は、プロジェクト内に既存のFoundry Agentが必要で、エージェント名を AZURE_AI_AGENT_NAME として指定します。(Microsoft Learn)
評価できるリスクカテゴリ
AI Red Teaming Agentでは、モデル向けのコンテンツリスクと、エージェント固有のリスクを分けて考える必要があります。
| リスクカテゴリ | 主な対象 | 実務での確認例 |
|---|---|---|
| Hate and Unfair Content | モデル、エージェント | 差別的・不公平な表現を出さないか |
| Sexual Content | モデル、エージェント | 性的コンテンツの生成を適切に抑制できるか |
| Violent Content | モデル、エージェント | 暴力的な手順や武器関連の危険な応答を防げるか |
| Self-Harm-Related Content | モデル、エージェント | 自傷に関する危険な助言を避けられるか |
| Protected Materials | モデル、エージェント | 保護されたコンテンツを不適切に出力しないか |
| Code vulnerability | モデル、エージェント | 脆弱なコードを生成しないか |
| Ungrounded attributes | モデル、エージェント | 根拠のない個人属性の推測をしないか |
| Prohibited actions | エージェントのみ | 禁止された操作や高リスク操作を実行しないか |
| Sensitive data leakage | エージェントのみ | 個人情報、金融情報、医療情報などを漏らさないか |
| Task adherence | エージェントのみ | ルール、手順、制約を守ってタスクを完了するか |
エージェント固有のリスクでは、生成された文章だけでなく、ツール出力やツール呼び出しに危険な挙動がないかも評価対象になります。この点が、通常のチャットボット評価との大きな違いです。(Microsoft Learn)
日本語環境で注意すべき点
日本語圏で使う場合に重要なのは、日本語の業務プロンプトで検証できる範囲と、英語限定の制限がある範囲を分けて理解することです。
ローカル実行の公式ドキュメントでは、スペイン語、イタリア語、フランス語、日本語、ポルトガル語、簡体字中国語でのシミュレーションがサポートされています。一方、エージェント固有リスクのうち、機密データ漏えいや禁止アクションには、シングルターン、英語のみ、合成データなどの制限が記載されています。(Microsoft Learn)
そのため、日本語の社内Copilotや問い合わせボットでは、次のような二段構えが現実的です。
- 日本語の通常業務シナリオは、ローカル実行や独自評価データで確認する
- エージェント固有リスクは、英語ベースの公式評価で構造的な弱点を確認する
- 日本語の実運用に近い攻撃例は、社内ポリシーに合わせたカスタム攻撃目標として追加する
- ASRだけでなく、行レベルの攻撃・応答データを人が確認する
ASRが低いから安全、ASRが高いから即リリース不可、という単純な判断は避けるべきです。AI Red Teaming Agentの結果は非決定的になる可能性があり、偽陽性が発生することもあるため、対策前に結果をレビューすることが推奨されています。(Microsoft Learn)
移行・展開時の注意点
既存の評価ワークフローからAI Red Teaming Agentを展開する場合、いきなり本番環境に組み込むのではなく、評価対象、データ、権限、結果の扱いを段階的に整理しましょう。
ローカル評価からクラウド評価へ移行する
ローカル実行では、Azure AI Evaluation SDKの追加パッケージとして azure-ai-evaluation[redteam] を使います。一方、クラウド実行ではMicrosoft Foundry SDKの azure-ai-projects>=2.0.0 を使います。SDK、Pythonバージョン、ターゲット指定方法が異なるため、同じコードをそのまま移す前提にしない方が安全です。(Microsoft Learn)
ローカル実行ではPython 3.10、3.11、3.12、3.13が必要で、Python 3.9はサポートされません。クラウド実行の前提条件ではPython 3.9以降とされています。開発端末、CI/CDランナー、評価用コンテナーでPythonバージョンの差が出ないように確認してください。(Microsoft Learn)
本番データを直接使わない
公式ドキュメントでは、クラウドでのエージェント向けレッドチーミング実行について、有害データがFoundry Agent Serviceに記録されないよう一時的な実行になることや、チャット補完が保存されないことが説明されています。また、現実に近いが本番ではない「purple environment」で実行することが推奨されています。(Microsoft Learn)
実務では、次のような検証環境を作ると安全です。
| 項目 | 推奨 |
|---|---|
| データ | 本番データではなく、合成データまたはマスキング済みデータを使う |
| ツール | 本番の書き込み系APIではなく、読み取り専用またはモックツールを使う |
| 権限 | 検証用IDに最小権限のみ付与する |
| ログ | 攻撃プロンプトや応答が保存される範囲を事前に確認する |
| 承認 | 高リスク操作や不可逆操作は人間の承認を必須にする |
評価分類を人が確認する
禁止アクションの評価では、ユーザーが承認したポリシーや禁止アクション分類に基づいて攻撃プロンプトが生成されます。公式ドキュメントでは、禁止・高リスク・不可逆アクションの分類は例示であり、法令やMicrosoftの規制解釈を保証するものではないと注意されています。(Microsoft Learn)
たとえば金融、医療、人事、公共分野のエージェントでは、開発者だけで禁止アクションを決めるのは危険です。プロダクト責任者、セキュリティ担当、法務、業務部門を含めて、次のように分類しましょう。
- 絶対に許可しない操作
- 人間の明示承認があれば許可する操作
- 実行前に説明と確認が必要な不可逆操作
- ログ記録と監査が必須の操作
- エージェントではなく人間が実施すべき操作
AI Red Teaming Agentの結果をどう読むべきか
AI Red Teaming Agentの結果で見るべき指標はASRだけではありません。スコアカードには、リスクカテゴリ別、攻撃戦略別、攻撃の複雑さ別の集計が含まれ、行レベルでは攻撃・応答ペア、攻撃成功の有無、リスク評価を確認できます。(Microsoft Learn)
実務での見方は次のとおりです。
| 見る項目 | 判断のポイント |
|---|---|
| overall ASR | 全体傾向を見る。単独で合否判定に使わない |
| リスクカテゴリ別ASR | 自社サービスで許容できないカテゴリを優先的に確認する |
| 攻撃戦略別ASR | Base64、Flip、IndirectJailbreakなど、どの回避手法に弱いかを見る |
| 行レベルデータ | 本当に危険な応答か、評価の誤判定かを人が確認する |
| 前回との差分 | モデル変更、プロンプト変更、ツール追加でリスクが増えていないかを見る |
特にエージェントでは、単に危険な文章を出したかだけでなく、「ツールを呼び出したか」「許可されていないデータを取得しようとしたか」「本来必要な確認を省略したか」を見る必要があります。AI Red Teaming Agentは、このようなエージェント固有の評価に対応している点が重要です。(Microsoft Learn)
導入前チェックリスト
AI Red Teaming Agentを導入する前に、管理者と開発者で次の項目を確認してください。
| 担当 | 確認項目 |
|---|---|
| 管理者 | Foundryプロジェクトがサポート対象リージョンにあるか |
| 管理者 | Foundry User相当のRBACが適切に付与されているか |
| 管理者 | 本番データを使わない検証環境を用意しているか |
| 管理者 | 高リスク操作に人間の承認フローがあるか |
| 開発者 | azure-ai-projects>=2.0.0 を使うクラウド実行手順を確認したか |
| 開発者 | 評価対象のモデルやエージェントを正しく指定できるか |
| 開発者 | connectionName/deploymentName が必要な構成か確認したか |
| 開発者 | 攻撃戦略とリスクカテゴリを業務リスクに合わせて選んだか |
| 開発者 | ASRと行レベル結果をレビューする運用を決めたか |
まず何から始めるべきか
Azure AI FoundryでAI Red Teaming Agentを使うなら、最初に行うべきことは大きく3つです。
まず、評価対象を棚卸しします。対象がモデルだけなのか、RAGアプリなのか、ツール実行型エージェントなのかを分けてください。次に、サポート対象リージョン、Foundryプロジェクト、RBAC、認証方式を確認します。最後に、開発環境または本番相当の検証環境で、少数のリスクカテゴリと攻撃戦略からスキャンを実行し、ASRと行レベル結果の読み方をチームで揃えます。
AI Red Teaming Agentは、安全性評価を自動化する強力な機能ですが、判断を完全に自動化するものではありません。スキャンでリスクを広く見つけ、ASRで傾向を把握し、人間が結果を確認して、プロンプト、ガードレール、ツール権限、承認フローを改善する。このサイクルをCI/CDや本番後の監視に組み込むことが、Azure AI Foundryで生成AI・AIエージェントを安全に展開するための現実的な進め方です。(Microsoft for Developers)
コメント