Microsoft Defender for Cloudの「AIサービスの脅威保護」は、生成AIアプリケーションやAIエージェントをAzureサブスクリプション単位で保護するための機能です。まず確認すべき結論は、Defender for Cloudを有効化したうえで、対象サブスクリプションのDefenderプランから「AI services」をオンにし、必要に応じてプロンプト証拠、Purview連携、AIモデルセキュリティの各コンポーネントを有効化することです。公式ドキュメントでは、Microsoft Foundryワークロードを対象に、生成AIアプリケーションへ影響し得る脅威の分析情報を提供する機能として説明されています。(Microsoft Learn)
2026年5月16日前後にこの情報を確認している管理者は、単に「新機能が出たか」だけでなく、既存のAIアプリ、Azure OpenAI利用、Microsoft Purview連携、SOC運用、AIモデルのCI/CDまで含めて見直す必要があります。特に、プロンプトや応答データの扱い、Purviewライセンス、Microsoft Entra IDのユーザーコンテキスト、AIモデルスキャンの対象範囲は、後から気づくと運用トラブルになりやすいポイントです。
Microsoft DefenderのAIサービス脅威保護とは
Microsoft Defender for CloudのAIサービス脅威保護は、生成AIアプリケーションやAIエージェントを狙う攻撃を検出し、セキュリティ担当者が調査・対応しやすくするための防御レイヤーです。Microsoftの公式概要では、Azure AI Content Safety Prompt ShieldsやMicrosoftの脅威インテリジェンスと連携し、データ漏洩、データポイズニング、脱獄、資格情報の盗難などに関するセキュリティアラートを提供すると説明されています。(Microsoft Learn)
従来のクラウドセキュリティでは、仮想マシン、ストレージ、コンテナー、データベースなどの保護が中心でした。しかし生成AIアプリでは、ユーザー入力、モデル応答、プロンプトインジェクション、エージェントの権限、外部ツール連携、モデルファイルそのものが攻撃対象になります。AIサービス脅威保護は、こうしたAI特有のリスクをMicrosoft Defender for Cloudの管理画面やDefenderポータルのアラート運用に取り込むための機能と考えると分かりやすいです。
Microsoft Defender XDRとの統合により、AIワークロードのアラートをDefender XDRポータルで一元的に扱える点も重要です。SOC担当者は、AIアプリ単体の異常だけでなく、ユーザー、アプリケーション、クラウドリソース、ID関連のインシデントを関連付けて調査できます。(Microsoft Learn)
2026年5月16日時点で見るべき変更点
2026年5月16日時点で確認する場合、注意すべきなのは「機能仕様が大きく変わった」と早合点しないことです。Microsoft Learn本文の表示上の最終更新日は2026年4月1日で、公開リポジトリ上では2026年5月15日にai-onboarding.mdへのコミットが記録されています。該当コミットの差分は、Azure無料サブスクリプション作成リンクの更新が中心で、AIサービス脅威保護の有効化手順そのものを変更する内容ではありません。(Microsoft Learn)
| 確認項目 | 2026年5月16日時点の見方 | 実務上の影響 |
|---|---|---|
| Microsoft Learn本文 | ページ表示上の最終更新日は2026年4月1日 | 設定手順や主要コンポーネントの理解が重要 |
| 公開リポジトリの更新 | 2026年5月15日にリンク更新のコミットあり | 既存環境の移行作業が必要になる変更ではない |
| 管理者が見るべき点 | AI servicesプランと各コンポーネントの有効化状態 | サブスクリプション単位で設定漏れが起きやすい |
| 開発者が見るべき点 | ユーザー・アプリケーションコンテキストの付与 | アラート調査の精度に影響する |
| コンプライアンス担当が見るべき点 | プロンプト、応答、メタデータの扱い | Purview連携や社内規程の確認が必要 |
つまり、今回の確認ポイントは「緊急の破壊的変更への移行」ではなく、AIサービス脅威保護を正しく有効化し、証拠データ・Purview・モデルスキャン・アラート運用まで整備できているかを見直すことです。
影響範囲はAzure管理者だけに限られない
AIサービス脅威保護はAzureポータル上で有効化するため、最初の作業者はAzure管理者になりがちです。しかし実際の影響範囲は、セキュリティ運用、アプリ開発、データガバナンス、AIモデル管理まで広がります。
| 関係者 | 主な確認ポイント | 見落とすと起きやすい問題 |
|---|---|---|
| Azure管理者 | Defender for Cloud、AI servicesプラン、権限、対象サブスクリプション | 一部サブスクリプションだけ未保護になる |
| SOC・CSIRT | アラートの証拠、Defender XDR連携、調査手順 | アラートが出ても原因や対象ユーザーを特定しにくい |
| アプリ開発者 | Azure OpenAI API呼び出し時のユーザー・アプリ情報 | アラートに文脈がなく、対応優先度を判断しにくい |
| データ保護担当 | プロンプト、応答、メタデータの保存・処理 | 社内ポリシーや監査要件との不整合が起きる |
| MLOps担当 | Azure Machine Learning上のモデルスキャン | 危険なモデルファイルを本番投入前に検出できない |
特に大企業や複数部門でAzureを使っている環境では、「AIアプリを作っているチーム」と「Defender for Cloudを管理しているチーム」が別であることがよくあります。この場合、AI servicesプランをオンにしても、アプリ側でユーザーコンテキストを渡していなかったり、Purviewライセンスやデータ保持方針が未整理だったりすると、十分な効果が出ません。
有効化前に確認すべき前提条件
公式手順では、AIサービス脅威保護を有効にする前提として、Azureサブスクリプション、Defender for Cloudの有効化、プランを有効化するための所有者または共同作成者レベルの権限が必要とされています。(Microsoft Learn)
実務では、次の順番で確認すると設定漏れを減らせます。
| 確認順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 対象のAzureサブスクリプションを特定する | AIアプリ、Azure OpenAI、Microsoft Foundry、Azure Machine Learningを利用しているサブスクリプションを洗い出す |
| 2 | Defender for Cloudが有効か確認する | Defender for Cloudの環境設定で対象サブスクリプションが管理対象になっている |
| 3 | 作業者の権限を確認する | 所有者または共同作成者レベルの権限がある |
| 4 | 課金影響を確認する | Defender for AI Servicesの価格や無料試用の条件を確認する |
| 5 | データ取り扱いを確認する | プロンプト、応答、メタデータを証拠やPurview連携に使ってよいか社内判断を取る |
価格については、公式概要でDefender for AI Servicesは価格ページに基づいて課金され、30日間の無料試用にはスキャンされた最大750億トークンの上限があると説明されています。上限に達した場合、30日以内でも課金が開始される可能性があるため、本番サブスクリプションで有効化する前に利用量の見積もりを行うべきです。(Microsoft Learn)
AI servicesプランを有効にする手順
公式ドキュメントで示されている基本手順は、AzureポータルからMicrosoft Defender for Cloudを開き、対象サブスクリプションのDefenderプランでAI servicesをオンにする流れです。(Microsoft Learn)
| 手順 | 操作 |
|---|---|
| 1 | Azure portalにサインインする |
| 2 | 「Microsoft Defender for Cloud」を検索して開く |
| 3 | Defender for Cloudのメニューから「環境設定」を選択する |
| 4 | 対象のAzureサブスクリプションを選択する |
| 5 | Defenderプランの画面で「AI services」をオンにする |
ここで重要なのは、設定対象が「テナント全体」ではなく、実際にはサブスクリプション単位で確認が必要になる点です。複数のAzureサブスクリプションを使っている組織では、開発環境、検証環境、本番環境、部門別サブスクリプションごとに状態を確認してください。
また、単にAI servicesをオンにするだけで終わらせず、次に説明する3つのコンポーネントをどう扱うか決める必要があります。
3つのコンポーネントをどう使い分けるか
AIサービス脅威保護プランでは、プラン内の複数コンポーネントを個別に制御できます。公式ドキュメントでは、疑わしいプロンプトの証拠、AI対話のデータセキュリティ、AIモデルのセキュリティが説明されています。(Microsoft Learn)
| コンポーネント | 役割 | 有効化を検討すべき場面 | 注意点 |
|---|---|---|---|
| 疑わしいプロンプトの証拠 | アラート調査のため、疑わしいプロンプトやモデル応答の一部を証拠として扱う | SOCがAI関連アラートを具体的に分析したい場合 | プロンプトと応答はデータとして扱われるため、社内規程の確認が必要 |
| AI対話のデータセキュリティ | Microsoft Purviewがプロンプト、応答、関連メタデータを分析できるようにする | SIT分類、監査、インサイダーリスク、eDiscoveryなどを使いたい場合 | Defender for AI Servicesプランには含まれない有料Purview機能 |
| AIモデルのセキュリティ | Azure Machine Learningのモデルをスキャンし、マルウェア、危険なオペレーター、公開されたシークレットなどを検出する | 独自モデルや社内モデルをAzure Machine Learningで管理している場合 | プレビュー扱いや対象制限、スキャン条件を確認する必要がある |
疑わしいプロンプトの証拠は「調査しやすさ」と「データ保護」のバランスが重要
疑わしいプロンプトの証拠を有効にすると、アラートにユーザープロンプトやモデル応答の疑わしい部分を含められます。これにより、SOC担当者は「本当に脱獄の試みなのか」「認証情報を引き出そうとしているのか」「データ漏洩につながる入力なのか」を判断しやすくなります。公式情報では、プロンプトや応答はデータと見なされ、Azureポータル、Defenderポータル、連携済みのパートナー統合から利用できると説明されています。(Microsoft Learn)
一方で、ユーザーが入力した業務情報や個人情報が証拠として扱われる可能性があります。公式説明では機密データは自動的に編集されるとされていますが、組織のデータ分類ルール、監査要件、ログ保管ポリシーと矛盾しないかは事前に確認すべきです。(Microsoft Learn)
なお、ユーザープロンプトの証拠を無効にしても、Microsoft Defender for Cloudは脅威検出のためにプロンプトと応答の分析を続けます。ただし、アラート内のプロンプト内容はマスクされます。調査時に「何が入力されたか分からない」という状態を避けたい場合は、証拠表示の有効化を検討してください。(Microsoft Learn)
Purview連携はライセンスと認証方式を必ず確認する
AI対話のデータセキュリティを有効にすると、Microsoft PurviewがMicrosoft Foundryからプロンプト、応答、関連メタデータにアクセスし、分類、監査、インサイダーリスク、コミュニケーションコンプライアンス、電子情報開示などに利用できるようになります。これはデータガバナンスを重視する組織にとって有用ですが、Microsoft Defender for CloudのDefender for AI Servicesプランには含まれない有料Purview機能です。(Microsoft Learn)
ここで失敗しやすいのが、ライセンスだけを見て認証方式を確認しないケースです。公式ドキュメントでは、Microsoft Foundry相互作用のデータセキュリティポリシーは、Microsoft Entra ID認証でユーザーコンテキストトークンを使うAPI呼び出し、またはユーザーコンテキストを明示的に含むAPI呼び出しに対してのみサポートされると説明されています。その他の認証シナリオでは、Purview監査とDSPM for AI Activity Explorerにのみ表示されます。(Microsoft Learn)
また、Purview統合にはFoundryエージェントからのデータやコンテキストは含まれないと明記されています。エージェント型AIアプリを使っている場合、「Purview連携をオンにしたから全エージェントの文脈まで統制できる」と考えないようにしてください。(Microsoft Learn)
AIモデルセキュリティはMLOpsの本番投入前チェックに向いている
AIモデルセキュリティは、Azure Machine Learningのワークスペースやレジストリ、CI/CDパイプラインと統合し、モデルが本番環境に到達する前に埋め込みマルウェア、安全でないオペレーター、公開されたシークレットなどを検出するための機能です。(Microsoft Learn)
AIモデルを外部から取り込む、OSSモデルを検証する、社内でファインチューニングしたモデルを本番投入する、といった運用では特に有効です。モデルファイルはコードと同じようにサプライチェーンリスクを持つため、セキュリティレビューを人手だけに頼るのは現実的ではありません。
ただし、AIモデルセキュリティは対象条件を確認する必要があります。公式のAI model securityページでは、この機能は現在プレビューであり、Azure Machine Learningのワークスペースやレジストリに登録されたAIモデルを含むAzureサブスクリプションが必要とされています。また、プライベートリンクを使用するワークスペースやレジストリはサポートされず、10GBを超えるモデルファイルはスキャンできず、スキャンは週1回行われると説明されています。(Microsoft Learn)
開発者が確認すべきAPI実装のポイント
AIサービス脅威保護は、Azureポータルでオンにすれば基本的な保護を開始できます。しかし、アラートの調査精度を高めるには、開発者側の実装も重要です。
公式ドキュメントでは、Azure AI API呼び出しにパラメーターを追加することで、エンドユーザーやアプリケーションのコンテキストをDefender for CloudのAIアラートに伝達できると説明されています。特にエンドユーザーコンテキストでは、少なくともEndUserIdとSourceIPを渡すことが推奨され、アプリケーションコンテキストではapplicationNameを渡すとされています。(Microsoft Learn)
| 実装項目 | 推奨される対応 | 注意点 |
|---|---|---|
EndUserId | Microsoft Entra IDのユーザーオブジェクトIDを渡す | 機密性の高い個人情報を入れない |
SourceIP | エンドユーザーの送信元IPを渡す | プロキシやAIゲートウェイ利用時は正しいIPを取得できる設計にする |
applicationName | アプリ名を単純な文字列で渡す | 複数アプリで共通名を使うと調査時に区別しにくい |
| フィールド名 | 正確に記述する | スペルミスがあってもAPI呼び出し自体は成功するため、コンテキスト欠落に気づきにくい |
| 対象API | Azure OpenAIの対応バージョンやSDKを確認する | Azure AIモデル推論API経由のモデルでは、この機能がサポートされない条件がある |
特に危険なのは、EndUserIdやapplicationNameのフィールド名を間違えてもAPI呼び出しが成功する点です。アプリは正常に動くため、開発テストでは問題に見えません。しかし、セキュリティアラートが発生したときに必要な文脈が欠落し、SOCが「どのユーザーが、どのアプリから、どのリソースに対して行った操作なのか」を追いにくくなります。公式ドキュメントでも、フィールド名のスペルが間違っていてもAzure OpenAI API呼び出しは成功すると説明されています。(Microsoft Learn)
実装後は、単体テストだけでなく、検証環境でアラートやログに期待したユーザー・アプリケーション情報が表示されるか確認してください。
管理者が展開時に注意すべきポイント
AIサービス脅威保護の展開では、設定画面でオンにする作業よりも、その前後の設計が重要です。特に以下の点を確認すると、導入後の混乱を減らせます。
| 注意点 | 具体的な確認内容 |
|---|---|
| サブスクリプション単位の設定漏れ | AIアプリを含むすべてのAzureサブスクリプションでAI servicesがオンになっているか |
| 権限不足 | 作業者が所有者または共同作成者レベルの権限を持っているか |
| コスト影響 | 無料試用の条件、トークン量、課金開始条件を確認したか |
| プロンプト証拠の扱い | アラート証拠としてプロンプトや応答を扱ってよいか |
| Purviewライセンス | 追加ライセンスが必要な機能を有効化しようとしていないか |
| Entra ID認証 | Purviewのデータセキュリティポリシーに必要なユーザーコンテキストを渡せるか |
| Foundryエージェント | Purview統合の対象外になるデータやコンテキストを誤解していないか |
| AIモデルスキャン | Azure Machine Learning、ファイルサイズ、プライベートリンク、スキャン頻度の条件を確認したか |
本番環境でいきなり全機能を有効化するより、まず検証用サブスクリプションでAI servicesプランをオンにし、アラートの出方、証拠の表示、Purview側の可視化、モデルスキャン結果を確認する流れが安全です。
既存環境での移行・見直しポイント
既にAzure OpenAIやMicrosoft Foundryを使っている環境では、「新しく導入する」よりも「既存構成をどこまで可視化できているか」を確認することが重要です。
AIアプリの棚卸しを行う
まず、どのアプリケーションがAzure OpenAI、Microsoft Foundry、Azure Machine Learning、AIゲートウェイ、外部モデル、社内データソースを使っているかを整理します。部署ごとにPoCや小規模アプリが存在する場合、セキュリティチームが把握していないAI利用が見つかることもあります。
棚卸しでは、次の情報を最低限記録します。
| 項目 | 記録例 |
|---|---|
| アプリ名 | 社内FAQボット、営業支援AI、開発者向けコード支援など |
| 利用サブスクリプション | 本番、検証、部門別サブスクリプション |
| 利用AIサービス | Azure OpenAI、Microsoft Foundry、Azure Machine Learningなど |
| 認証方式 | Microsoft Entra ID、APIキー、アプリケーション認証など |
| ユーザー情報の渡し方 | EndUserId、SourceIP、applicationNameの有無 |
| データ種別 | 個人情報、機密文書、顧客情報、ソースコードなど |
| SOC連携 | Defender XDR、SIEM、チケット管理との連携有無 |
この棚卸しがないままAI servicesをオンにすると、アラートが出ても担当部署や影響範囲が分からず、対応が遅れます。
証拠データの表示方針を決める
疑わしいプロンプトの証拠は調査に役立ちますが、プロンプトと応答はデータとして扱われます。セキュリティチームだけで判断せず、個人情報保護、情報システム、法務、監査部門と相談し、次のような方針を決めておくと安全です。
| 判断項目 | 方針例 |
|---|---|
| 誰が証拠を閲覧できるか | SOC担当者とセキュリティ管理者に限定する |
| どの環境で有効化するか | まず検証環境と低リスクアプリから有効化する |
| どのデータを扱うアプリで慎重にするか | 顧客情報、医療情報、金融情報、未公開ソースコードを扱うアプリ |
| インシデント時の扱い | 証拠データの共有範囲と保管ルールを定める |
「証拠が多いほど調査しやすい」と「データの露出面が増える」は表裏一体です。ここを設計せずに有効化すると、後から監査対応で問題になる可能性があります。
Purview連携はデータガバナンスの設計とセットで進める
Purview連携は、AIのプロンプトや応答をデータセキュリティの対象として扱いたい組織に向いています。ただし、ライセンス、Entra ID認証、ユーザーコンテキスト、対象外となるFoundryエージェントの扱いを理解していないと、期待した通りにデータが見えないことがあります。(Microsoft Learn)
有効化後にPurview Activity Explorerでユーザー操作が見えない場合、公式ドキュメントではMicrosoft Purviewサービスプリンシパルがテナントに存在するかをAzure PowerShellで確認し、存在しなければ追加するトラブルシューティング手順が示されています。(Microsoft Learn)
このため、Purview連携はセキュリティ担当だけでなく、Microsoft 365やPurviewを管理するチームと一緒に進めるべきです。
失敗しやすいポイントと対策
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| AI servicesをオンにしただけで完了と考える | プロンプト証拠、Purview、モデルスキャンの設定が未確認になる | 各コンポーネントのオン・オフを別途確認する |
| 本番サブスクリプションだけ確認する | 開発・検証環境のAIアプリが未保護になる | 全サブスクリプションを棚卸しする |
| プロンプト証拠を無条件で有効化する | データ保護や監査上の懸念が出る | 閲覧権限とデータ分類ルールを先に決める |
| Purviewライセンスを確認しない | 機能を有効化しても期待通り運用できない | ライセンスと対象機能を事前確認する |
| Entra IDのユーザーコンテキストを渡していない | Purviewポリシーやアラート調査でユーザーを追いにくい | API呼び出しにユーザー・アプリ情報を追加する |
UserSecurityContextのフィールド名を誤る | APIは成功するが、アラートに文脈が載らない | テストでアラート表示まで確認する |
| AIモデルスキャンの制限を見落とす | 対象外モデルを保護できていると誤解する | プライベートリンク、10GB制限、スキャン頻度を確認する |
実務でおすすめの展開手順
AIサービス脅威保護は、次の流れで段階的に展開すると失敗しにくくなります。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 棚卸し | AIアプリ、利用サービス、サブスクリプション、認証方式を整理する | 対象リストが作成されている |
| 検証 | 検証サブスクリプションでAI servicesをオンにする | Defender for Cloud上で有効化状態を確認できる |
| 証拠設計 | 疑わしいプロンプトの証拠を使う範囲を決める | 閲覧権限とデータ扱いの方針が決まっている |
| アプリ改修 | EndUserId、SourceIP、applicationNameを渡す | アラートにユーザー・アプリ情報が反映される |
| Purview連携 | ライセンス、Entra ID認証、サービスプリンシパルを確認する | Activity Explorerや監査で期待したデータが確認できる |
| モデル保護 | Azure Machine Learning上のモデルスキャンを有効化する | セキュリティ検出結果と修復手順を確認できる |
| 本番展開 | 本番サブスクリプションへ展開する | SOC運用手順とエスカレーションルールが整備されている |
特に、アプリ改修とSOC運用を分けて考えないことが重要です。開発者がユーザーコンテキストを渡していなければ、SOCはアラートを受け取っても優先度や影響範囲を判断しにくくなります。逆に、SOC側でアラート対応手順がないまま有効化すると、通知が増えても改善につながりません。
次に管理者が取るべき行動
Microsoft Defender for CloudのAIサービス脅威保護は、生成AIアプリケーションを使う組織にとって、今後の標準的な確認項目になります。最初にやるべきことは、対象サブスクリプションでDefender for CloudとAI servicesプランが有効か確認することです。その次に、疑わしいプロンプトの証拠、Purview連携、AIモデルセキュリティを、自社のデータ保護方針と運用体制に合わせて有効化します。
開発チームは、Azure OpenAI API呼び出しにユーザーとアプリケーションのコンテキストを渡せているか確認してください。SOCやセキュリティ管理者は、Defender XDRやDefenderポータルでAI関連アラートをどう調査し、誰にエスカレーションするかを決めておく必要があります。
今回のポイントは、単なる設定変更ではありません。AIアプリの利用状況、データの扱い、認証方式、モデルの安全性、アラート対応をまとめて見直す機会として捉えることが重要です。
コメント