Azure AI Foundryで生成AIアプリやエージェントを運用している管理者は、今回の公式情報を「コンプライアンス画面の説明追加」ではなく、ガードレール、Defender for Cloud、Microsoft Purviewを組み合わせてAIワークロードを統制するための実務ガイドとして確認すべきです。特に重要なのは、モデルデプロイごとの安全設定を個別管理するだけでなく、サブスクリプションやリソースグループ単位でポリシー化し、違反を検出・修正できる点です。Microsoft Learnの該当ドキュメントでは、Microsoft Foundry Control Planeがコンプライアンス管理、ガードレール制御、Defender for Cloud連携を支援することが説明されています。(Microsoft Learn)
この記事では、Azure AI Foundryのセキュリティ更新として管理者・開発者が押さえるべき変更点、影響範囲、確認すべき設定、移行・展開時の注意点を整理します。
Azure AI Foundryのセキュリティ更新で何が変わったのか
今回のポイントは、Azure AI Foundryにおけるセキュリティとコンプライアンス管理が、より「運用管理者向け」に整理されたことです。従来のように開発者が各モデルやエージェントの安全設定を個別に見るだけでなく、管理者がサブスクリプション全体を見渡し、ポリシー違反や未設定のガードレールを確認しやすくなっています。
公式情報では、Complianceワークスペースに次のタブが整理されています。Policiesではガードレールポリシーの確認・作成・編集、Assetsではモデルデプロイごとの違反確認、Guardrailsではデプロイ間のガードレール設定比較、Security postureではDefender for Cloudの推奨事項やMicrosoft Purviewの有効化を扱います。(Microsoft Learn)
| 確認画面 | 主な用途 | 管理者が見るべきポイント |
|---|---|---|
| Policies | ガードレールポリシーの確認、作成、編集 | 組織標準の安全設定がポリシー化されているか |
| Assets | モデルデプロイ単位の違反確認 | どのデプロイが非準拠なのか |
| Guardrails | ガードレール設定の横断比較 | フィルター無効、設定漏れ、例外の偏り |
| Security posture | Defender for Cloud推奨事項、Purview連携 | セキュリティ推奨事項と監査・分類の状態 |
実務上の意味は明確です。AIアプリをPoCから本番運用へ進める企業では、「誰がどのモデルにどの安全設定を入れたか」を手作業で追うのではなく、Azure AI Foundryの管理画面で統制状況を確認し、必要に応じてAzure PolicyやDefender for Cloud、Microsoft Purviewと連携して運用する流れに寄せるべきです。
影響を受ける範囲はモデル、エージェント、サブスクリプション全体
今回の内容は、単一プロジェクトの設定変更にとどまりません。影響を受けるのは、Azure AI Foundry上で管理されるモデルデプロイ、Foundry Agent Serviceで開発されたエージェント、サブスクリプションまたはリソースグループ単位の管理ポリシーです。
公式ドキュメントでは、ガードレールはコアモデルとエージェントに適用でき、リスク検出、介入ポイント、応答アクションを定義するコントロールの集合として説明されています。介入ポイントには、ユーザー入力、ツール呼び出し、ツール応答、出力が含まれます。ただし、ツール呼び出しとツール応答はプレビュー扱いです。(Microsoft Learn)
管理者に影響すること
管理者は、プロジェクト単位ではなく、サブスクリプションやリソースグループ単位で次の点を確認する必要があります。
| 確認項目 | なぜ重要か | 具体的な確認方法 |
|---|---|---|
| ガードレールポリシーの適用範囲 | 一部のプロジェクトだけ安全設定が弱い状態を防ぐため | Compliance > Policiesでスコープを確認 |
| 非準拠のモデルデプロイ | 組織ポリシーに反するAI出力や不正利用のリスクがあるため | PoliciesまたはAssetsでViolations detectedを確認 |
| Defender for Cloudの有効化 | 構成不備や脅威アラートを検出するため | Security postureで推奨事項を確認 |
| Microsoft Purview連携 | プロンプト・応答データの監査、分類、ガバナンスに関わるため | Security postureでPurviewトグルを確認 |
開発者に影響すること
開発者は、モデルやエージェントをデプロイした後に「動けばよい」と考えないことが重要です。ガードレール設定が組織ポリシーを満たしていない場合、管理画面上で違反として表示される可能性があります。
特に、次のような開発チームは早めに確認すべきです。
- 複数のAzure AI Foundryプロジェクトを並行運用している
- PoC環境から本番環境へモデルデプロイを移行している
- エージェントに外部ツールやMCPツールを接続している
- ユーザー入力や生成結果に個人情報、機密情報、社外秘データが含まれる可能性がある
- 既存のAzure AI関連RBACロール名を前提に権限設計している
公式ドキュメントでは、Foundry 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 AI Foundryのコンプライアンスとセキュリティ管理を始める前に、必要な環境と権限を確認します。公式情報では、Azureサブスクリプション、Foundryプロジェクト、対象エージェント、タスクに応じた権限が前提として示されています。(Microsoft Learn)
| 作業内容 | 必要な権限・条件 | 注意点 |
|---|---|---|
| コンプライアンス状態とガードレールポリシーの表示 | プロジェクトへのアクセス権 | 多くの利用者は閲覧のみ可能 |
| ガードレールポリシーの作成・編集 | サブスクリプションまたはリソースグループのOwner、またはResource Policy Contributor | Azure Policyを扱うため、一般開発者には権限がない場合が多い |
| Defender for Cloudの有効化 | サブスクリプションのSecurity AdminまたはOwner | Defenderプランやエージェントレス保護の有効化に関わる |
| Microsoft Purview連携の構成 | Foundry Account Owner | 監査・分類・DSPM for AIの運用担当と連携が必要 |
権限不足で設定できない場合、開発者が個別に回避しようとすると運用が崩れます。最初にAzure管理者、セキュリティ管理者、AI開発チームの責任範囲を分けておくべきです。
おすすめは、次のように役割を分担することです。
| 役割 | 主な責任 |
|---|---|
| Azure管理者 | サブスクリプション、リソースグループ、Azure Policy、RBACの管理 |
| セキュリティ管理者 | Defender for Cloud、セキュリティ推奨事項、アラート対応 |
| データガバナンス担当 | Microsoft Purview、監査、分類、DLP、eDiscovery |
| AI開発者 | モデルデプロイ、エージェント設定、ガードレール修正 |
| プロダクト責任者 | 例外承認、リスク判断、本番展開可否の判断 |
ガードレールポリシーで最低限の安全基準を統一する
Azure AI Foundryのガードレールポリシーは、モデルデプロイに対して最低限必要な安全制御を強制するための仕組みです。公式ドキュメントでは、コンテンツフィルター、プロンプトシールド、不正利用検出などのコントロールを選択し、サブスクリプションまたはリソースグループ単位でスコープを設定できると説明されています。(Microsoft Learn)
ここで重要なのは、ガードレールを「任意の安全機能」として扱わないことです。生成AIアプリでは、モデルごとに利用目的やリスクが異なります。社内FAQボット、営業支援AI、顧客対応チャット、業務エージェントでは、求められる安全基準が同じとは限りません。
ガードレールポリシーを作るときの判断基準
| 判断項目 | 推奨される考え方 | 失敗しやすい例 |
|---|---|---|
| 適用範囲 | 本番環境はサブスクリプションまたは主要リソースグループ単位で統一 | プロジェクトごとに設定がバラバラ |
| 例外設定 | テスト環境、旧環境、検証中モデルに限定 | 本番デプロイまで例外に入れたまま放置 |
| コントロール内容 | コンテンツフィルター、プロンプト保護、不正利用検出を用途に応じて組み合わせる | 最小構成のまま本番公開 |
| ポリシー名 | 対象範囲と目的が分かる名前にする | 「policy1」「test」など運用不能な名前 |
| 変更反映 | 作成・編集後すぐに反映されない前提で運用 | 展開直前に設定して確認時間を取らない |
公式情報では、ガードレールポリシーの作成後、Foundryポータルに表示されるまで最大30分かかる可能性があり、コンプライアンス結果はAzure Policyのスキャン後に表示されると説明されています。編集後も同様に、更新されたポリシーが有効になるまで最大30分待つ必要があります。(Microsoft Learn)
つまり、本番リリース直前にガードレールポリシーを作成するのは危険です。リリース判定に使うなら、少なくとも事前にポリシーを作成し、対象デプロイが準拠状態になることを確認しておく必要があります。
非準拠のモデルデプロイを確認して修正する手順
ガードレールポリシーを作成したら、次に確認すべきなのは違反の有無です。公式ドキュメントでは、Policiesタブでポリシー単位に違反を確認する方法と、Assetsタブでモデルデプロイ単位に確認する方法が示されています。(Microsoft Learn)
Policiesタブから確認する流れ
| 手順 | 操作 | 確認すること |
|---|---|---|
| 1 | Operate > Compliance > Policiesを開く | 対象サブスクリプションとプロジェクトが正しいか |
| 2 | Policy Compliance列を確認 | Violations detectedがないか |
| 3 | 対象ポリシーを選択 | どのアセットが違反しているか |
| 4 | Fix nowを選択 | モデルデプロイのガードレール設定を修正 |
| 5 | 保存後に再確認 | 数分後にコンプライアンス状態が更新されるか |
Assetsタブから確認する流れ
Assetsタブは、開発者や運用担当者が「自分のデプロイが準拠しているか」を確認するのに向いています。対象デプロイが複数のポリシーにかかっている場合、同じアセットが複数回表示される可能性があります。
この場合、1つの違反だけを直して終わりにしないことが重要です。対象デプロイに適用されているすべてのガードレールポリシーを確認し、全体として準拠状態になっているかを見ます。
Guardrailsタブでは「ポリシー違反になっていない穴」も探す
PoliciesやAssetsは、すでに定義されたポリシーに対する違反を確認する画面です。一方、Guardrailsタブは、デプロイ済みアセットのガードレール設定を横断比較し、設定漏れやカバレッジ不足を見つけるために使います。
公式ドキュメントでは、Guardrailsタブでプロジェクトやサブスクリプション全体の設定を比較し、列の並び替えなどでフィルター無効などの問題を見つけられると説明されています。さらに、問題が見つかった場合は個別デプロイを更新するか、新しいガードレールポリシーを作成して全体に強制する選択肢があります。(Microsoft Learn)
実務では、ここが見落とされやすいポイントです。ポリシー違反がないから安全、とは限りません。そもそもポリシーが未作成だったり、対象外のリソースグループにデプロイされていたりすれば、違反として検出されない可能性があります。
Guardrailsタブで見るべき例
| 見るべき状態 | 想定されるリスク | 対応 |
|---|---|---|
| コンテンツフィルターが無効 | 有害・不適切な応答が返る可能性 | 個別修正またはポリシー化 |
| 一部プロジェクトだけ設定が弱い | 部門やチームごとの統制差 | サブスクリプション単位の基準を作成 |
| 例外が多すぎる | 本番環境に未統制デプロイが残る | 例外理由と期限を棚卸し |
| エージェントのツール関連制御が不足 | 外部ツール実行やデータ流出のリスク | ツール呼び出し・応答の制御を確認 |
| 旧ポータルや旧名称の手順が残っている | 運用手順と現行画面が合わない | 手順書を更新 |
Defender for CloudでAIワークロードの推奨事項と脅威を確認する
Azure AI Foundryのセキュリティ管理では、Defender for Cloudとの連携も重要です。公式ドキュメントでは、Defender for Cloudがセキュリティ姿勢のギャップや修復推奨事項を提供し、Foundryのマネージド推論エンドポイント上に構築されたAIワークロードについて、推奨事項やアラートを扱うと説明されています。(Microsoft Learn)
また、Defender for CloudのAI threat protectionは、生成AIアプリケーションやエージェントへの脅威をリアルタイムに識別し、データ漏えい、データポイズニング、ジェイルブレイク、資格情報の窃取などの脅威に対するアラートを提供すると説明されています。(Microsoft Learn)
管理者が優先して確認すべき推奨事項
Defender for CloudのAIセキュリティ推奨事項には、Microsoft Foundryに関係する項目が含まれます。たとえば、間接プロンプトインジェクションリスクのあるFoundry AI Agentに対してHuman in the loop制御を求める項目、Jailbreak controlの不足、Microsoft Entra IDを使わないストレージ接続、Application Insights未構成、ネットワーク接続の制限不足、コンテンツフィルタリング無効などが示されています。(Microsoft Learn)
| 優先度 | 確認項目 | 理由 |
|---|---|---|
| 高 | Microsoft Entra IDによる接続に統一できているか | キーや資格情報ベースのアクセスは漏えい時の影響が大きい |
| 高 | 間接プロンプトインジェクション対策があるか | 外部データやWebページ経由でエージェントが操作される可能性がある |
| 中 | Jailbreak controlが含まれているか | 安全指示を回避する入力に対する耐性を高める |
| 中 | Application Insightsが構成されているか | インシデント調査や挙動把握が遅れる |
| 中 | パブリックネットワークアクセスが適切に制限されているか | 外部からの不要な露出を減らす |
| 中 | コンテンツフィルタリングが有効か | 有害コンテンツや不適切出力のリスクを下げる |
ここで大切なのは、推奨事項を単に「対応済み」にすることではありません。AIワークロードでは、モデル、エージェント、データソース、外部ツール、ユーザー権限がつながります。1つの設定だけで安全になるわけではないため、Defender for Cloudの推奨事項は、ガードレールポリシーやPurview監査と合わせて見る必要があります。
Microsoft Purview連携でプロンプトと応答の監査・分類を考える
Microsoft Purview連携は、AIガバナンスを強化するうえで重要な要素です。公式ドキュメントでは、AzureサブスクリプションでMicrosoft Purviewを有効化すると、Microsoft Foundryのアプリやエージェントからのプロンプト・応答データと関連メタデータにアクセス、処理、保存できると説明されています。対象シナリオには、Purview Audit、SIT分類、DSPM for AI、Insider Risk Management、Communication Compliance、Data Lifecycle Management、eDiscoveryが含まれます。(Microsoft Learn)
Microsoft PurviewのAI向けデータセキュリティ説明でも、PurviewはAI利用に伴うリスクを軽減・管理し、保護とガバナンス制御を実装するために使われると説明されています。また、Microsoft FoundryはEnterprise AI appsの一部として扱われています。(Microsoft Learn)
Purview連携でできること
| 機能 | Azure AI Foundry運用での意味 |
|---|---|
| Microsoft Purview Audit | AIアプリとのやり取りを監査ログとして確認する |
| SIT分類 | プロンプトや応答に含まれる機密情報を分類する |
| DSPM for AI | AI利用のデータセキュリティ姿勢を可視化する |
| Insider Risk Management | 内部不正や情報持ち出しの兆候を検出する |
| Communication Compliance | 不適切なやり取りや規制違反の可能性を確認する |
| eDiscovery | 法務・調査対応でAI関連データを検索・保全する |
Purview連携で注意すべき制限
特に注意すべき点は、Microsoft Purview Data Security Policiesの適用条件です。公式ドキュメントでは、Purview Data Security Policiesは、Foundryのマネージド推論エンドポイント /chat/completions に対してMicrosoft Entra IDのユーザーコンテキスト認証を使うやり取りに適用されると説明されています。それ以外の認証シナリオでは、ユーザー操作はPurview AuditやDSPM for AIの分類で可視化されるものの、データセキュリティポリシーによる強制は行われないとされています。(Microsoft Learn)
つまり、監査に見えることと、ポリシーで制御できることは同じではありません。開発者はAPI認証方式を設計する段階で、Purviewのデータセキュリティポリシーを使いたいのか、監査・分類だけでよいのかを管理者と決める必要があります。
さらに、FoundryにおけるMicrosoft Purview統合は、該当機能についてネットワーク分離をまだサポートしていないと説明されています。ネットワーク分離が必須の業界やシステムでは、本番適用前に社内基準との整合を確認すべきです。(Microsoft Learn)
Microsoft Purviewを有効化する手順
Microsoft Purview連携を有効にするには、Foundry Account Ownerロールが必要です。公式情報では、Operate > Compliance > Security postureを開き、対象のAzureサブスクリプションを選択してMicrosoft Purviewのトグルをオンにする流れが示されています。(Microsoft Learn)
| 手順 | 操作 |
|---|---|
| 1 | FoundryポータルでOperateを選択 |
| 2 | 左ペインからComplianceを選択 |
| 3 | Security postureタブを開く |
| 4 | 対象のAzureサブスクリプションを選択 |
| 5 | Microsoft Purviewトグルをオンにする |
| 6 | 必要に応じて他のサブスクリプションでも同じ作業を行う |
運用上は、有効化する前に次の3点を確認しておくと失敗を避けやすくなります。
| 事前確認 | 理由 |
|---|---|
| テナントにMicrosoft Purviewライセンスがあるか | 公式情報ではPurviewライセンスが必要とされている |
| どのサブスクリプションを対象にするか | サブスクリプションごとに有効化が必要になる |
| 監査対象データの扱いを社内規程で説明できるか | プロンプト・応答データを処理・保存するため、データ管理部門との合意が必要 |
移行時に注意すべきポイント
Azure AI Foundryをすでに利用している組織では、今回の内容を受けて設定を確認するだけでなく、既存運用の見直しが必要です。
旧ロール名と新ロール名の混在に注意する
Foundry RBACロールはリネームされていますが、ロールIDと主要な権限は変わっていません。とはいえ、手順書、申請フォーム、監査資料、権限一覧で旧名称が残っていると、管理者と開発者の間で認識違いが起きます。(Microsoft Learn)
特に次のような資料は更新対象です。
| 更新対象 | 見直す内容 |
|---|---|
| 権限申請フォーム | Azure AI Ownerなど旧名称をFoundry Ownerに置き換える |
| 運用手順書 | Foundry新ポータルの画面構成に合わせる |
| 監査チェックリスト | ガードレールポリシー、Defender、Purviewの確認項目を追加 |
| 開発者向けガイド | デプロイ後の準拠確認手順を明記 |
| リリース判定基準 | Violations detectedが残っていないことを条件化 |
Foundry新ポータルで確認する
公式ドキュメントでは、この機能はFoundryの新ポータルでのみ利用できると説明されています。旧ポータルやクラシック系の手順を前提にしている場合、同じメニューが見つからない可能性があります。(Microsoft Learn)
運用チームは、画面キャプチャ付きの社内手順書を作る前に、対象環境がFoundry新ポータルであることを確認してください。
例外設定を棚卸しする
ガードレールポリシーでは、特定のモデルデプロイやリソースグループを例外にできます。例外はテスト環境やレガシーデプロイには有効ですが、本番環境で放置するとリスクになります。
例外を使う場合は、最低限次の情報を残します。
| 項目 | 記録例 |
|---|---|
| 例外対象 | rg-ai-poc-001、legacy-chatbot-deploy |
| 例外理由 | 検証中のため、旧モデル移行中のため |
| 承認者 | AI基盤管理者、セキュリティ責任者 |
| 期限 | 2026年6月末まで |
| 再確認日 | 月次セキュリティレビュー時 |
「一時的な例外」が恒久的な抜け穴にならないよう、期限を設定することが重要です。
本番展開前のチェックリスト
Azure AI FoundryでAIアプリやエージェントを本番展開する前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認済みの判断基準 |
|---|---|
| 対象デプロイが正しいサブスクリプション・リソースグループにある | Compliance画面のスコープで確認できる |
| ガードレールポリシーが適用されている | Policiesタブに対象ポリシーが表示される |
| 非準拠が残っていない | Policy ComplianceにViolations detectedがない |
| Guardrailsタブで設定漏れがない | フィルター無効や未設定が見つからない |
| Defender for Cloudが有効化されている | Security postureで推奨事項を確認できる |
| 高・中リスクの推奨事項に対応方針がある | 未対応の場合も期限と責任者がある |
| Microsoft Purview連携の要否を判断済み | 監査・分類・DSPM for AIの利用方針がある |
| Entra IDユーザーコンテキスト認証の要否を確認済み | Purview Data Security Policiesを使う場合は特に確認 |
| 例外設定が妥当 | 期限、理由、承認者が明記されている |
| 社内手順書が新ポータル・新ロール名に対応 | 旧名称や旧画面前提の記述が残っていない |
このチェックリストは、開発者だけで完結させないことが大切です。AIアプリの本番展開では、セキュリティ管理者、データガバナンス担当、Azure管理者の確認が必要になります。
よくある失敗と回避策
ポリシーを作っただけで安全になったと思い込む
ガードレールポリシーは作成後すぐに完全な評価結果が出るとは限りません。公式情報では、ポリシー表示や評価に最大30分かかる可能性があると説明されています。リリース当日に作成して、そのまま本番公開する運用は避けるべきです。(Microsoft Learn)
回避策は、リリース前日までにポリシーを作成し、非準拠の修正と再評価の時間を確保することです。
Purviewで見えているから制御できていると思い込む
Purview AuditやDSPM for AIで可視化できても、Data Security Policiesによる強制が効くとは限りません。公式情報では、データセキュリティポリシーの適用にはMicrosoft Entra IDユーザーコンテキスト認証が必要とされています。(Microsoft Learn)
回避策は、API認証方式とPurviewポリシーの適用範囲を設計段階で確認することです。
Defender for Cloudの推奨事項を後回しにする
AIアプリは、従来のWebアプリと違い、プロンプト、応答、外部データ、ツール実行が攻撃面になります。Defender for Cloudの推奨事項には、間接プロンプトインジェクション、Jailbreak control、Entra ID接続、ネットワーク制限、コンテンツフィルターなど、AI特有のリスクに関係する項目があります。(Microsoft Learn)
回避策は、少なくとも高リスク項目を本番前レビューの必須項目にすることです。
エージェントのツール連携を軽く見る
エージェントが外部ツールやデータソースにアクセスする場合、単なるチャットボットよりリスクが大きくなります。間接プロンプトインジェクションでは、外部データに埋め込まれた悪意ある指示をエージェントが正当な命令として解釈する可能性があります。Defender for Cloudの推奨事項でも、MCPツールアクションに対するHuman in the loop制御や強化されたガードレールが扱われています。(Microsoft Learn)
回避策は、ツール実行に承認フローを入れる、許可されたツール一覧を定義する、外部データを扱うエージェントにはより強いガードレールを適用することです。
管理者と開発者が次に取るべき行動
今回のAzure AI Foundryのセキュリティ更新で、最初にやるべきことは新機能を試すことではありません。まず、現在のAIデプロイがどの程度見える状態になっているかを確認することです。
管理者は、ComplianceワークスペースでPolicies、Assets、Guardrails、Security postureを順に確認し、サブスクリプション全体で非準拠、設定漏れ、Defender for Cloudの未対応推奨事項、Purview連携の必要性を洗い出してください。開発者は、自分のモデルデプロイやエージェントが組織ポリシーに準拠しているかをAssetsとGuardrailsで確認し、必要に応じてガードレール設定を修正します。
特に本番運用中または本番予定のAzure AI Foundry環境では、次の3つを優先してください。
- ガードレールポリシーをサブスクリプションまたはリソースグループ単位で定義する
- Defender for CloudのAIセキュリティ推奨事項を確認し、高リスク項目から対応する
- Microsoft Purview連携の要否を判断し、監査・分類・DSPM for AIの運用方針を決める
Azure AI Foundryのセキュリティ対策は、モデル単体の安全設定だけでは不十分です。ガードレールで出力と入力を制御し、Defender for Cloudで構成不備と攻撃兆候を検出し、Microsoft Purviewでデータ利用を監査・分類する。この3つを組み合わせて、PoCから本番運用まで一貫したAIガバナンスを作ることが、今回の公式情報から読み取れる最も重要な対応ポイントです。
コメント