Azure AI Foundryで生成AIアプリやCopilot型エージェントを運用している場合、今回確認すべきポイントは「AI Red Teaming Agentをクラウド上で実行し、本番前・本番後の安全性評価をより運用に組み込みやすくなったこと」です。ローカルでの試験的なレッドチーミングだけでなく、攻撃戦略やリスクカテゴリを組み合わせたクラウド実行、エージェント特有のリスク評価、結果の継続的な確認が重要になります。管理者はRBAC、接続、リージョン、非本番環境の設計を、開発者はMicrosoft Foundry SDK、評価分類、攻撃戦略、結果確認の流れを押さえておきましょう。(Microsoft Learn)
Azure AI FoundryのAI Red Teaming Agentクラウド実行で何が変わるのか
Microsoft Learnの英語版「Run AI Red Teaming Agent in the cloud」は、2026年5月15日更新表示の公式情報として公開されています。日本語版は2026年5月5日更新表示のため、実装時は英語版の最新内容も併せて確認するのが安全です。(Microsoft Learn)
今回のポイントは、AI Red Teaming AgentをMicrosoft Foundry SDKからクラウド実行できる手順が整理されたことです。クラウド実行では、デプロイ前により大きな攻撃戦略とリスクカテゴリの組み合わせで評価でき、デプロイ後の継続的なレッドチーミングや、エージェント固有のリスクシナリオにも対応しやすくなります。(Microsoft Learn)
AI Red Teaming Agentは、生成AIシステムに対して攻撃的な入力や誘導をシミュレーションし、望ましくない応答や危険なツール利用が起きないかを確認するための仕組みです。Microsoftの説明では、PyRITのAIレッドチーミング機能とFoundryのRisk and Safety Evaluationsを活用し、攻撃と応答の組み合わせを評価してAttack Success Rate、つまり攻撃成功率を算出できます。(Microsoft Learn)
まず押さえるべき影響範囲
Azure AI FoundryのAI Red Teaming Agentクラウド実行は、すべてのAIアプリを無条件に対象にできる機能ではありません。公式手順でサポート対象として示されているのは、Foundryプロジェクト内のデプロイ、Azure OpenAIモデルデプロイ、Microsoft Foundryプロジェクト内のFoundry Agentsです。特にFoundry Agentsは、プロンプトエージェントとコンテナーエージェントが対象として記載されています。(Microsoft Learn)
| 確認項目 | 管理者への影響 | 開発者への影響 |
|---|---|---|
| Foundryプロジェクト | 評価を実行するプロジェクト、権限、リージョンの確認が必要 | AZURE_AI_PROJECT_ENDPOINTを正しく設定する必要がある |
| RBAC | Foundry User相当の権限確認が必要 | 権限不足だと評価作成や結果取得で失敗しやすい |
| Azure OpenAI接続 | 外部のAzure OpenAIやFoundry Toolsを使う場合、接続設定が必要 | connectionName/deploymentName形式を誤ると対象モデルを参照できない |
| Foundry Agent | 対象エージェントの種類、名前、バージョン、ツール構成の棚卸しが必要 | AZURE_AI_AGENT_NAMEやターゲット定義を実環境と一致させる必要がある |
| 評価結果 | ASRだけで合否判定せず、人手レビューの運用が必要 | 出力アイテムを取得し、失敗ケースを修正サイクルに回す必要がある |
ローカル実行との違いを理解する
AI Red Teaming Agentはローカルでも実行できますが、クラウド実行は「本番前後の運用に組み込む評価」に向いています。ローカル実行はプロトタイプ段階の確認に便利ですが、Microsoft Learnのローカル実行ページでは、ローカル版はFoundry(new)ポータルおよびSDKと互換性がない旨も記載されています。既存のAzure AI Evaluation SDKベースの検証コードを、そのままクラウド実行へ移行できると考えないほうがよいでしょう。(Microsoft Learn)
| 観点 | ローカル実行 | クラウド実行 |
|---|---|---|
| 主な用途 | 開発中の試験、早期の安全性チェック | デプロイ前評価、継続評価、エージェント固有リスクの確認 |
| 利用SDK | Azure AI Evaluation SDK中心 | Microsoft Foundry SDKのプロジェクトクライアント |
| 実行環境 | 開発者のローカル環境 | Foundryプロジェクトを前提にクラウド側で実行 |
| 向いている場面 | 小規模なプロンプト検証、初期調査 | 複数の攻撃戦略、ツール利用エージェント、運用監視 |
| 注意点 | Foundry(new)との互換性に注意 | RBAC、接続、リージョン、結果取得の設計が必要 |
管理者が最初に確認すべき設定
RBACロール名の変更に注意する
英語版の公式手順では、前提条件としてFoundryプロジェクトのFoundry Userロールが示されています。一方で、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)
実務では、権限不足よりも「ロール名の表示ゆれ」による確認漏れが起きやすいです。Azureポータル、IaCテンプレート、社内手順書、監査資料で旧名称と新名称が混在していないかを確認してください。特に、評価実行用のサービスプリンシパルや開発者グループに対して、プロジェクト単位で必要な権限が付与されているかを見直すことが重要です。
対象リージョンを確認する
AI Red Teaming Agentの概念ページでは、クラウドレッドチーミングの利用可能リージョンとして、East US 2、France Central、Sweden Central、Switzerland West、US North Centralが記載されています。日本リージョン中心でAzure AI Foundryを運用している組織は、利用可否、データ取り扱い、検証環境の配置を事前に確認する必要があります。(Microsoft Learn)
「本番環境がJapan Eastだから、同じ構成でそのままクラウドレッドチーミングできる」と決めつけるのは危険です。PoC段階で、対象プロジェクトのリージョン、モデルデプロイ、接続、社内のデータ越境ルールを確認してから展開計画を立てましょう。
接続の作成と管理を確認する
Azure OpenAIやFoundry Toolsアカウント側のデプロイを使う場合は、それらのリソースをFoundryプロジェクトへ接続する必要があります。公式手順では、接続を作成し、生成された接続名を使ってconnectionName/deploymentName形式でモデルデプロイを指定する流れが示されています。(Microsoft Learn)
接続まわりでよくある失敗は、開発者がモデルデプロイ名だけを指定してしまうことです。Foundryプロジェクト内のデプロイであればデプロイ名を直接指定できますが、接続経由のAzure OpenAIデプロイでは接続名を含める必要があります。複数環境を運用している場合は、開発、検証、本番で接続名の命名規則をそろえておくとトラブルを減らせます。
開発者が押さえる実装の流れ
クラウド実行では、Microsoft Foundry SDKのプロジェクトクライアントを使います。公式手順では、azure-ai-projects>=2.0.0のインストール、AZURE_AI_PROJECT_ENDPOINT、エージェントシナリオ用のAZURE_AI_AGENT_NAMEなどの環境変数設定が示されています。(Microsoft Learn)
pip install "azure-ai-projects>=2.0.0"
az loginimport os
endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
agent_name = os.environ["AZURE_AI_AGENT_NAME"]認証は、可能な限りDefaultAzureCredentialを使ったキーレス認証が推奨されています。APIキー認証も選択肢として示されていますが、管理者がキーの発行、保管、ローテーション、漏えい時の対応を設計していない場合は、安易にAPIキー前提で実装しないほうが安全です。(Microsoft Learn)
実行の基本ステップ
AI Red Teaming Agentのクラウド実行は、大まかに次の流れで進めます。
| 手順 | やること | 確認ポイント |
|---|---|---|
| 1 | Foundryプロジェクトと対象モデル、対象エージェントを決める | 対象がサポート範囲に入っているか |
| 2 | 認証と環境変数を設定する | AZURE_AI_PROJECT_ENDPOINT、AZURE_AI_AGENT_NAME、モデルデプロイ名 |
| 3 | Red Teamを作成する | 評価条件、データソース、組み込みエバリュエーター |
| 4 | 評価分類を作成または更新する | 禁止アクションの分類を人間が確認、編集、承認する |
| 5 | Runを作成する | 攻撃戦略、ターン数、ターゲット、分類ファイルID |
| 6 | 完了までポーリングする | queued、running、completed、failedなどの状態確認 |
| 7 | 出力アイテムと結果を取得する | ASR、失敗ケース、再現条件、修正方針 |
公式例では、Red Teamの作成時にProhibited Actions、Task Adherence、Sensitive Data Leakageの組み込みエバリュエーターを設定する例が示されています。また、Run作成時の攻撃戦略例としてFlip、Base64、IndirectJailbreakが使われています。(Microsoft Learn)
エージェント型AIで特に重要な評価ポイント
Copilot型アプリや業務エージェントでは、単に「危険な文章を出さないか」だけでは不十分です。ツール呼び出し、RAG、外部データ、ワークフロー実行が絡むため、間接プロンプトインジェクションや禁止操作の実行、機密データ漏えい、手順逸脱を確認する必要があります。
Microsoftの概念ページでは、エージェント固有のリスクカテゴリとして、Prohibited actions、Sensitive data leakage、Task adherenceが説明されています。これらは単なる出力テキストだけでなく、ツール出力やツール利用を含む危険な挙動を確認する観点です。(Microsoft Learn)
Prohibited Actionsは「社内ポリシー」とセットで確認する
Prohibited Actionsは、エージェントが禁止された操作、高リスクな操作、不可逆な操作を実行しないかを見る評価です。公式手順では、禁止アクションの評価分類を生成し、確認、編集、更新したうえで、攻撃プロンプト生成やASR評価に使う流れが示されています。(Microsoft Learn)
ここで重要なのは、生成された分類をそのまま使わないことです。たとえば、経費精算Copilotなら「支払い実行」「承認者変更」「銀行口座情報の変更」は高リスク操作です。社内ヘルプデスクエージェントなら「ユーザー削除」「MFA無効化」「権限昇格」は禁止または人間承認必須にすべき操作です。分類は、法務、セキュリティ、業務部門が確認したポリシーとして扱いましょう。
Sensitive Data Leakageは日本語業務データで過信しない
Sensitive Data Leakageは、金融、医療、個人識別情報などの漏えいリスクを確認するカテゴリです。ただし公式説明では、合成データを使うこと、単一ターン、英語のみ、メモリやトレーニングセット由来の漏えいを除くといった制限が示されています。(Microsoft Learn)
日本語の社内文書、顧客番号、住所表記、氏名の表記ゆれ、業界固有の機密語を扱う場合、公式評価だけで「漏えい対策は完了」と判断しないでください。AI Red Teaming Agentの結果を入口にして、自社データ形式に合わせた追加テストを設計するのが現実的です。
Task Adherenceは「便利だが勝手にやらない」ことを確認する
Task Adherenceは、ユーザーの目的に沿い、ルールや制約を守り、必要な手順を逸脱しないかを見る評価です。業務エージェントでは、回答の正しさだけでなく「承認前に処理しない」「根拠のない外部送信をしない」「指定された手順を省略しない」といった確認が重要になります。(Microsoft Learn)
たとえば、社内申請エージェントが「申請内容のドラフト作成」までは許可されていても、「承認者に代わって送信」してはいけないケースがあります。評価分類とツール権限を合わせて設計し、エージェントが越えてはいけない境界を明文化してください。
サポート対象外に注意したいエージェントとツール
概念ページのサポート表では、Foundry hosted prompt agentsとFoundry hosted container agentsはサポート対象として示されています。一方、Foundry workflow agents、Non-Foundry agents、Non-Azure tools、Function tool calls、Browser automation tool calls、Connected Agent tool calls、Computer Use tool callsなどは未サポートとして記載されています。(Microsoft Learn)
これは、業務エージェントをすでに独自フレームワークや外部ツール連携で作っているチームにとって大きな確認ポイントです。たとえば、ブラウザ操作型のエージェントや、独自関数呼び出しを多用するエージェントは、公式のクラウドレッドチーミングだけでは十分に検証できない可能性があります。
その場合は、次のように切り分けると運用しやすくなります。
| 状況 | 推奨対応 |
|---|---|
| Foundry hosted prompt/container agentsを使っている | クラウド実行を優先して評価フローに組み込む |
| Azureツール呼び出し中心の構成 | サポート範囲を確認し、Prohibited ActionsやTask Adherenceを重点評価する |
| 独自関数、ブラウザ操作、非Azureツールが中心 | 公式評価に加えて、手動レッドチーミングや独自テストを併用する |
| 日本語・業界固有データが多い | 公式結果を参考にしつつ、自社データ形式の追加評価を作る |
| 本番データを直接使いたい | 非本番のpurple environmentで再現し、実データ投入は避ける |
展開前に作るべき「purple environment」
Microsoftの概念ページでは、Foundry hosted agentを対象にするクラウドレッドチーミングでは一時的な実行となり、有害なデータがFoundry Agent Serviceにログ保存されず、チャット完了も保存されないと説明されています。また、現実的な条件で確認するため、本番に似たリソースで構成した非本番環境、いわゆるpurple environmentで実行することが推奨されています。(Microsoft Learn)
実務では、次の条件を満たす検証環境を用意すると、評価結果を本番改善に活かしやすくなります。
| 設計項目 | 推奨内容 |
|---|---|
| モデル | 本番と同じ、または同等のモデルデプロイを使う |
| システムメッセージ | 本番と同じガードレール、禁止事項、応答方針を反映する |
| ツール | 本番と同じ種類のツールを用意し、破壊的操作はモック化する |
| データ | 合成データまたはマスキング済みデータを使う |
| 権限 | 本番より弱い権限にし、実システムへの変更を防ぐ |
| ログ | 評価結果、失敗ケース、修正履歴を追跡できるようにする |
「本番に近いが、本番には影響しない」環境を作ることが重要です。特に削除、送金、権限変更、外部送信のような操作は、レッドチーミング中に実行されても被害が出ないように設計してください。
ASRだけで合否判定しない
AI Red Teaming AgentではAttack Success Rate、つまり攻撃成功率が重要な指標になります。ただし、Microsoftは既知の制限として、レッドチーミング実行は合成データやモックツールに依存すること、現実世界のデータ分布を完全には代表しないこと、ASR評価には生成モデルが使われるため非決定的で、偽陽性の可能性があることを説明しています。(Microsoft Learn)
そのため、ASRが低いから安全、ASRが高いから即リリース不可、と機械的に判断するのは避けるべきです。出力アイテムを確認し、次の観点でレビューしてください。
| レビュー観点 | 見るべき内容 |
|---|---|
| 再現性 | 同じ攻撃が複数回成功するか、一時的な判定ゆれか |
| 影響度 | 実際に機密情報漏えい、禁止操作、手順逸脱につながるか |
| 修正箇所 | システムメッセージ、ツール権限、分類、データ接続のどこを直すべきか |
| 業務文脈 | 日本語表現、社内用語、承認フローに照らして問題があるか |
| リリース判断 | 本番前に必ず直す問題か、監視しながら改善する問題か |
移行・展開で失敗しやすいポイント
旧ロール名のまま手順書が残っている
日本語版の前提条件ではAzure AI Userロールと表示される箇所がありますが、英語版ではFoundry Userロールの表記になっています。ロールIDや主要権限は変わらないと説明されていますが、運用現場では表示名の違いが問い合わせや設定漏れの原因になります。(Microsoft Learn)
社内ドキュメントには「Azure AI Userは旧称、Foundry Userが新名称」と明記しておくと、管理者と開発者の認識違いを防げます。
モデルデプロイ名と接続名を取り違える
Foundryプロジェクト内のモデルデプロイを使う場合は、initialization_parameters.deployment_nameにデプロイ名を直接渡します。一方、Azure OpenAIやFoundry Toolsアカウントのデプロイを接続経由で使う場合は、connectionName/deploymentName形式を使います。(Microsoft Learn)
環境変数名だけを見て実装すると、開発環境では動くのに検証環境で失敗することがあります。接続経由なのか、プロジェクト内デプロイなのかをREADMEや設定ファイルに明記してください。
Taxonomyを技術チームだけで決めてしまう
Prohibited Actionsの分類は、エージェントの禁止行為や高リスク操作に直結します。技術チームだけで決めると、業務上は重要な禁止事項が漏れたり、逆に必要な操作を過度に禁止してしまったりします。
おすすめは、次の3者で確認することです。
| 役割 | 確認する内容 |
|---|---|
| 開発チーム | エージェントのツール、プロンプト、実行フロー |
| セキュリティチーム | 禁止操作、機密データ、攻撃パターン |
| 業務部門・法務 | 承認フロー、規制、社内ルール、顧客影響 |
日本語シナリオの追加検証を忘れる
公式情報では、いくつかのエージェント固有カテゴリに英語のみ、単一ターン、合成データなどの制限が示されています。日本語圏の業務システムでは、日本語の曖昧な依頼、敬語、略語、部署固有の言い回しがリスクになります。(Microsoft Learn)
たとえば「急ぎなので承認者には後で連絡します」「いつもの権限で処理して」「顧客番号だけ教えて」といった日本語の業務依頼は、実際の現場で起こりやすい入力です。公式の攻撃戦略に加えて、自社の問い合わせログや業務フローをもとにした追加テストを用意しましょう。
導入判断の基準
Azure AI FoundryのAI Red Teaming Agentクラウド実行は、次のような組織ほど優先度が高くなります。
| 導入を優先すべきケース | 理由 |
|---|---|
| 本番運用前の生成AIアプリを評価したい | デプロイ前に攻撃戦略とリスクカテゴリを組み合わせて確認できる |
| Copilot型エージェントがツールを呼び出す | 禁止操作、手順逸脱、間接プロンプトインジェクションの確認が重要 |
| Azure AI Foundry上で複数プロジェクトを運用している | 統一した評価フローを作りやすい |
| 監査やリリース判定に評価結果を使いたい | 出力アイテムやASRをレビュー記録として活用しやすい |
| ローカル評価だけでは運用に足りない | クラウド実行により継続評価や大規模評価へ広げやすい |
一方で、非Foundryエージェント、ブラウザ操作型エージェント、独自関数呼び出し中心の構成、日本語独自データの深い検証が必要な構成では、公式のクラウドレッドチーミングだけに頼らず、手動レビューや独自テストも組み合わせるべきです。
いま取るべき次のアクション
まず、対象のAzure AI Foundryプロジェクトがクラウドレッドチーミングのサポート条件に合っているかを確認してください。次に、Foundry User相当のRBAC、Azure OpenAIやFoundry Toolsへの接続、対象エージェントの種類、リージョン、SDKバージョンを棚卸しします。
開発者は、azure-ai-projects>=2.0.0を使った最小構成でRed Teamを作成し、評価分類、Run作成、ポーリング、出力アイテム取得までを検証環境で一度通してください。管理者は、その結果を本番前チェックリストに組み込み、ASRだけでなく失敗ケースの人手レビュー、修正履歴、再評価の流れまで整備しましょう。
AI Red Teaming Agentのクラウド実行は、生成AIアプリを「作って終わり」にしないための運用基盤です。特にCopilot型エージェントでは、便利さと安全性の境界が曖昧になりやすいため、本番展開前のゲートと本番後の継続評価の両方に組み込むことが、現実的なリスク低減につながります。
コメント