Microsoft Defender for Cloudの「AI threat protection」は、生成AIアプリケーションやAIエージェントを狙う攻撃を検出し、管理者がDefender for CloudやDefender XDRで調査・対応できるようにする機能です。2026年5月20日に更新された公式情報では、対象範囲、AIサービス向けプラン、プロンプト証拠の扱い、AIモデルのスキャン、Defender XDR連携を確認することが重要です。特にAzure OpenAIやMicrosoft Foundryを業務アプリに組み込んでいる組織は、「有効化しただけで全AIリスクを自動的に防げる」と考えず、対応サービス・課金・証拠データ・アラート運用まで見直す必要があります。 (Microsoft Learn)
Microsoft Defender for CloudのAI threat protectionとは
Microsoft Defender for CloudのAI threat protectionは、生成AIアプリケーションやAIエージェントに対する脅威を検出し、セキュリティチームがインシデント対応しやすくするための保護機能です。
公式情報では、Azure AI Content Safety Prompt ShieldsとMicrosoftの脅威インテリジェンスを組み合わせ、データ漏えい、データポイズニング、Jailbreak、資格情報窃取などの脅威をアラート化すると説明されています。また、Defender XDRと統合されるため、AIワークロードのアラートをDefender XDRポータルで集約し、他のインシデントと関連付けて調査できます。 (Microsoft Learn)
従来のクラウドセキュリティでは、仮想マシン、コンテナー、ネットワーク、IDの保護が中心でした。しかし生成AIでは、次のようなAI特有の攻撃が問題になります。
| AI特有のリスク | 具体例 | 管理者が見るべきポイント |
|---|---|---|
| Prompt Injection / Jailbreak | システムプロンプトを無視させる指示、隠し命令の注入 | Prompt Shieldsの検出・ブロック結果、プロンプト証拠 |
| 資格情報の漏えい | モデル応答にAPIキーやトークンが含まれる | 秘密情報の混入元、RAGデータ、ツール連携 |
| 悪性URLの拡散 | AIアプリやエージェントがフィッシングURLを返す | 応答元がモデル、データ、ツールのどれか |
| Wallet attack | 大量リクエストでAI利用料金を膨らませる | 使用量異常、レート制限、予算アラート |
| 不審なツール呼び出し | エージェントが通常と異なる操作を実行 | ツール権限、実行履歴、最小権限設計 |
重要なのは、AI threat protectionは「AIアプリの安全設計を不要にする機能」ではないことです。脅威の検出と調査を強化する機能であり、アプリ側の認証、認可、入力検証、ツール権限制御、監査ログ設計と組み合わせて使う必要があります。
2026年5月20日更新で管理者が確認すべきポイント
2026年5月20日更新の公式ページでは、AI threat protectionの提供状態や対象範囲が整理されています。管理者が最初に確認すべきポイントは次のとおりです。 (Microsoft Learn)
| 確認項目 | 公式情報上の要点 | 実務での確認ポイント |
|---|---|---|
| 提供状態 | AI threat protectionはGAとして案内されている | 本番環境で有効化する前に対象サブスクリプションを整理する |
| 対象機能 | アクティビティ監視とプロンプト証拠を使ったセキュリティアラート | SOCや運用担当がアラートを受け取れるか確認する |
| 対象サービス | Azure OpenAI対応モデル、Azure AI Model Inference service対応モデル | 利用中のモデル、リージョン、API経路が対象か確認する |
| トークン種別 | 現時点ではテキストトークンのみ対応 | 画像・音声入力を扱うAIアプリは別の監視策が必要 |
| クラウド | 商用クラウドは対応、Azure Governmentや21Vianet、中国向けクラウド、接続済みAWSアカウントは非対応 | マルチクラウドや政府系環境では適用可否を個別に確認する |
| 権限 | サブスクリプションスコープのOwner、または必要なデータアクションを持つロールが必要 | セキュリティ担当とAzure管理者の権限分離を事前に設計する |
| 課金 | Defender for AI Servicesとして課金され、30日無料試用はスキャン対象75 billion tokensまで | PoC段階でもトークン量と予算アラートを確認する |
ここで特に見落としやすいのは、対応範囲です。Microsoft Defender for Cloudを有効化していても、すべてのAIサービス、すべてのトークン、すべてのクラウド環境が自動的に保護されるわけではありません。まずは「どのサブスクリプションで、どのAIサービスを、どの認証方式で使っているか」を棚卸しすることが出発点です。
影響範囲：対象になる環境と対象外になりやすい環境
AI threat protectionの影響を受けるのは、主にAzure上で生成AIアプリケーションやMicrosoft Foundryワークロードを運用している環境です。オンボーディング手順では、AzureサブスクリプションでDefender for Cloudを有効化し、Defender plansからAI servicesをオンにする流れが示されています。 (Microsoft Learn)
対象になりやすい環境
次のような環境では、今回の情報を優先して確認すべきです。
- Azure OpenAIを社内アプリ、チャットボット、業務支援ツールに組み込んでいる
- Microsoft Foundry上でAIアプリケーションやAIエージェントを構築している
- Azure AI Model Inference serviceを利用している
- Azure Machine LearningにカスタムAIモデルを登録している
- AIアプリをAKSなどのKubernetes上で公開している
- SOCでMicrosoft Defender XDRやMicrosoft Sentinelを使っている
特にRAG構成やエージェント構成では、AIモデル単体ではなく、検索対象データ、外部ツール、API、ユーザー入力が連鎖します。AI threat protectionのアラートを有効にしても、ツール側の権限が過剰であれば被害範囲は広がります。AIアプリの権限設計も同時に確認してください。
対象外・制約になりやすい環境
一方で、次の環境では「Defenderを入れているから大丈夫」と判断しない方が安全です。
| 環境・条件 | 注意点 |
|---|---|
| 画像・音声中心のAIアプリ | 公式情報ではテキストトークンのみスキャン対象とされています |
| Azure Governmentや21Vianet環境 | 公式情報では対象外として示されています |
| 接続済みAWSアカウント | AI threat protectionの対象クラウドとしては示されていません |
| Azure AI Model Inference API経由の一部シナリオ | エンドユーザー文脈の付与など一部機能に制約があります |
| 独自LLMをAzure外でホストしている環境 | Defender for CloudのAIサービス向け保護範囲外になる可能性があります |
この制約を踏まえると、AIセキュリティの設計では「Defender for Cloudで検出できる範囲」と「アプリケーション側で補完する範囲」を分けて考える必要があります。
有効化前に確認すべき設定
AI threat protectionを展開する前に、管理者はサブスクリプション、権限、証拠データ、課金、アラート連携を確認してください。
AI servicesプランを有効化する
基本的な有効化手順は、AzureポータルでMicrosoft Defender for Cloudを開き、Environment settingsから対象サブスクリプションを選択し、Defender plansページでAI servicesをオンにする流れです。前提としてAzureサブスクリプション、Defender for Cloudの有効化、OwnerまたはContributorレベルの権限が必要です。 (Microsoft Learn)
実務では、いきなり全サブスクリプションへ展開するより、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 棚卸し | AIリソース、モデル、エージェント、APIゲートウェイ、AKS公開サービスを一覧化 | 本番・検証・開発環境を分けて管理する |
| 試験展開 | 検証サブスクリプションでAI servicesをオンにする | アラートの出方、証拠データ、通知先を確認する |
| 運用設計 | Defender XDR、Sentinel、チケット管理への連携を決める | High/Medium/Lowごとの対応SLAを決める |
| 本番展開 | 優先度の高いAIアプリから段階展開する | 課金、誤検知、プライバシー影響を監視する |
| 定期見直し | 新規AIアプリやモデル登録時に適用状況を確認する | AI利用の増加に伴う未保護リソースを防ぐ |
Suspicious prompt evidenceのオン・オフを判断する
Suspicious prompt evidenceを有効にすると、疑わしいユーザープロンプトやモデル応答の一部がアラートの証拠として表示されます。公式情報では、機密データは自動的に編集されると説明されていますが、プロンプトと応答は顧客データとして扱われるため、プライバシーや社内規程との整合性を確認する必要があります。無効にした場合でも脅威検出のための分析は継続されますが、アラート内のプロンプト内容はマスクされます。 (Microsoft Learn)
判断基準は次のように整理できます。
| 選択 | 向いている環境 | 注意点 |
|---|---|---|
| オン | SOCがプロンプト内容を見て迅速にトリアージしたい環境 | 証拠データの閲覧権限、保管、チケット転記ルールを決める |
| オフ | 個人情報、機密契約、医療・金融データなどを扱う慎重な環境 | アラート調査時に文脈が不足し、アプリログとの突合が必要になる |
おすすめは、まず検証環境でオンにし、実際にSOC担当者がどの情報を見られるかを確認することです。そのうえで、本番ではデータ分類や社内ポリシーに応じてオン・オフを決めるとよいでしょう。
Microsoft Purview連携はライセンスと対象範囲を確認する
Data security for AI interactionsを有効にすると、Microsoft Purviewがプロンプト、応答、関連メタデータを分析し、SIT分類、監査、インサイダーリスク、コミュニケーションコンプライアンス、eDiscoveryなどに利用できます。ただし、この機能はMicrosoft Purviewの有償機能であり、Defender for AI Servicesプランには含まれません。また、公式情報ではFoundry agentsのデータやコンテキストはPurview統合に含まれないとされています。 (Microsoft Learn)
導入前に確認すべき点は次の3つです。
- Purviewの対象ライセンスを保有しているか
- Entra IDのユーザー文脈、または明示的なユーザーコンテキストをAPI呼び出しに含めているか
- 監査・eDiscoveryにAIプロンプトや応答を含めることが社内規程上問題ないか
特に、AIログをコンプライアンス管理に使う場合は、セキュリティ部門だけで判断せず、法務、個人情報保護、監査部門と合意してから有効化してください。
開発者が確認すべき実装ポイント
AI threat protectionの効果を高めるには、開発者側の実装も重要です。公式情報では、Azure AI API呼び出しにエンドユーザーやアプリケーションのコンテキストを追加することで、AIアラートの実用性を高められると説明されています。推奨される最小項目は、EndUserIdとSourceIPです。アプリケーション文脈としてはapplicationNameを渡します。 (Microsoft Learn)
UserSecurityContextを設計する
開発者は、AIアプリからAzure OpenAIを呼び出す際に、誰が、どのアプリから、どのIPで呼び出したのかを追跡できるように設計してください。
| 項目 | 目的 | 実装時の注意 |
|---|---|---|
| EndUserId | インシデント時に対象ユーザーを特定する | Entra IDのユーザーオブジェクトIDを使い、氏名やメールなどの機密性が高い個人情報を直接入れない |
| SourceIP | 不審なアクセス元を調査する | プロキシやAPIゲートウェイ配下では実ユーザーIPの取得方法を確認する |
| applicationName | どの業務アプリで発生したかを識別する | 表記ゆれを防ぐため命名規則を決める |
注意したいのは、フィールド名を間違えてもAzure OpenAI API呼び出し自体は成功する点です。つまり、アプリは正常に動いているように見えても、Defender側のアラートに必要な文脈が入らない可能性があります。実装後は、テストアラートやログ確認で、SOCが必要な情報を見られるか検証してください。
SDKとAPIバージョンを確認する
公式情報では、Azure OpenAI REST API、Azure .NET SDK、Python SDK、JS/Node SDK、Go SDKの対応バージョンが示されています。SDKの対応状況は変わる可能性があるため、実装時点の公式ドキュメントで確認するのが安全です。 (Microsoft Learn)
既存アプリを移行する場合は、SDK更新だけでなく、次の点も確認してください。
- APIゲートウェイやバックエンドでユーザーIDが失われていないか
- サービスプリンシパルだけの呼び出しになっており、エンドユーザー文脈が欠落していないか
- applicationNameが環境ごとに統一されているか
- ログ、チケット、Defenderアラートで同じユーザー・アプリを追跡できるか
AI model securityは開発パイプラインでも確認する
AI model securityは、Azure Machine Learningのワークスペースやレジストリに登録されたAIモデルを対象に、埋め込みマルウェア、危険なオペレーター、露出したシークレットなどを検出する機能です。公式情報では、この機能はプレビューであり、Defender for AI Servicesプランに含まれますが、GA時にライセンス要件が変わる可能性があると説明されています。 (Microsoft Learn)
運用上の注意点は次のとおりです。
| 項目 | 注意点 |
|---|---|
| 対象モデル | Azure Machine Learningのワークスペースやレジストリに登録されたモデルが中心 |
| Private Link | Private Linkを使用するワークスペースやレジストリはサポート対象外とされています |
| ファイルサイズ | 10GBを超えるモデルファイルはスキャンできません |
| スキャン頻度 | 公式情報では週1回スキャンとされています |
| CI/CD | Azure DevOpsやGitHubのパイプラインでスキャンを組み込む設計が有効 |
開発チームにとって重要なのは、本番登録後に初めて検出するのではなく、ビルドやリリース前に危険なモデルを止めることです。外部から取得したモデル、委託先が作成したモデル、社内で再利用されるモデルは、CI/CDの段階でスキャンし、Highの検出があればリリースを停止するルールを作るべきです。
主なAIアラートと初動対応
AI threat protectionで発生しうるアラートには、AIアプリケーション、AIエージェント、AIモデルに関するものがあります。公式のアラート一覧には、資格情報窃取、Jailbreak、悪性URL、ASCII Smuggling、Torや不審IPからのアクセス、Wallet attack、異常なツール呼び出し、AIエージェントの命令漏えい、アップロードモデル内の悪性コンテンツなどが含まれています。 (Microsoft Learn)
実務では、アラート名を覚えるよりも、検出されたリスクごとに初動を決めておくことが重要です。
| 検出内容 | 初動対応 | 再発防止策 |
|---|---|---|
| Jailbreak / Prompt Injection | 該当プロンプト、ユーザー、アプリ、モデル応答を確認する | Prompt Shields設定、入力検証、システムプロンプト保護を見直す |
| 資格情報窃取の疑い | 露出した可能性のあるキーやトークンを失効・ローテーションする | Secrets Manager利用、RAGデータ内の秘密情報除去 |
| 悪性URL | URLをブロックし、AI応答の発生元を特定する | 外部データソース、ツール出力、検索インデックスを検査する |
| Suspicious IP / Tor | アクセス元、認証状況、操作履歴を確認する | 条件付きアクセス、WAF、レート制限を強化する |
| Wallet attack | 使用量、課金、同一リクエストの急増を確認する | クォータ、予算アラート、APIキー管理を見直す |
| Anomalous tool invocation | エージェントが実行したツールと権限を確認する | ツールの許可リスト、承認フロー、最小権限を導入する |
| Exposed Kubernetes service | LoadBalancer公開設定と認証有無を確認する | Ingress、Network Policy、認証・認可を再設計する |
| AIモデル内の悪性コンテンツ | モデルを隔離し、リリースを停止する | CI/CDスキャンとモデル承認フローを導入する |
Highアラートは、単なるAIの誤応答ではなく、認証情報、外部公開、フィッシング、マルウェア、過剰権限に直結する可能性があります。AI担当チームだけで抱えず、SOC、クラウド管理者、アプリ開発者、データ管理者が同じインシデントとして扱う体制を作ってください。
Defender XDRとアラート運用の設計
AI threat protectionはDefender XDRと連携し、AIワークロードのアラートやインシデントをDefender XDRポータルで集約できます。これにより、AIアプリ単体の異常だけでなく、ID侵害、端末侵害、クラウドリソースへの不審操作と組み合わせて調査しやすくなります。 (Microsoft Learn)
また、Defender for Cloudのアラート運用では、重大度を基準に優先順位を付け、Security alerts画面で詳細、影響リソース、MITRE ATT&CK上の意図、Take actionタブの推奨対応を確認します。必要に応じてLogic Appによる自動対応、類似アラートの抑制、Microsoft SentinelなどSIEM/SOARへの連携も検討できます。 (Microsoft Learn)
運用で失敗しやすいのは、アラートを有効化したものの、誰が見るのか、どの基準で対応するのかが決まっていない状態です。次のルールを事前に決めておくと、導入後の混乱を防げます。
| 運用項目 | 決めるべき内容 |
|---|---|
| 通知先 | Defender XDR、Defender for Cloud、Sentinel、チケット管理のどこを一次窓口にするか |
| 対応SLA | Highは即時、Mediumは営業日内など、重大度別の対応期限 |
| 担当分界 | SOC、Azure管理者、AIアプリ開発者、データ管理者の役割 |
| 証拠の扱い | プロンプト証拠をチケットへ転記してよいか、マスクが必要か |
| 抑制ルール | 誤検知を抑制する条件と、定期見直しの頻度 |
| 自動対応 | Logic Appで通知、キー無効化、IPブロック、チケット起票のどこまで行うか |
AIアラートは、従来のマルウェア検知や不審ログインより文脈依存になりやすい特徴があります。アラート本文だけで判断せず、ユーザー、アプリ、プロンプト、モデル応答、接続データ、ツール実行履歴をセットで確認する運用にしてください。
展開・移行時の注意点
既存のAIアプリにAI threat protectionを展開する場合、単にAI servicesプランをオンにするだけでは不十分です。次の順に確認すると、設定漏れや運用負荷の増加を抑えられます。
課金とトークン量を事前に見積もる
Defender for AI Servicesには無料試用が用意されていますが、公式情報では30日無料試用は75 billion tokens scannedまでで、30日以内に上限へ達すると課金が開始されると説明されています。PoCや検証環境でも、大量の自動テストや高トラフィックのAIアプリを対象にすると想定より早く上限に近づく可能性があります。 (Microsoft Learn)
導入前に、Azure Cost Managementや予算アラートを使い、サブスクリプション単位でコスト監視を設定してください。
プロンプト証拠と個人情報の扱いを決める
プロンプトや応答には、顧客情報、社内文書、問い合わせ内容、医療・金融・人事情報が含まれる可能性があります。Suspicious prompt evidenceを有効にする場合は、閲覧できる担当者、転記ルール、保存期間、監査ログを事前に決める必要があります。
「機密データは自動的に編集される」とされていても、すべての社内規程を自動的に満たすとは限りません。特にチケット管理ツールやチャット通知へ転送する場合、証拠データが別システムへ広がらないようにしてください。
AIアプリの認証方式を見直す
AIアラートの調査では、どのユーザーがどの操作をしたかが重要です。すべての呼び出しがバックエンドの単一サービスプリンシパルに見える構成では、SOCが個別ユーザーを追跡しにくくなります。
可能な範囲で、Entra IDのユーザー文脈やUserSecurityContextを使い、Defenderのアラートに調査可能な情報を残してください。匿名ユーザーを扱う外部公開AIアプリでは、セッションID、送信元IP、アプリ名、レート制限ログを組み合わせて追跡できるようにします。
AIエージェントのツール権限を最小化する
AIエージェントは、メール送信、データ検索、チケット作成、外部API呼び出しなどのツールを実行できる場合があります。JailbreakやPrompt Injectionでエージェントが意図しないツールを呼び出すと、被害はチャット画面の誤回答にとどまりません。
展開時には、次のような制御を入れてください。
- 高リスク操作は人間の承認を必須にする
- ツールごとに許可する入力形式を制限する
- エージェントがアクセスできるデータ範囲を業務単位で分離する
- 読み取り権限と書き込み権限を分ける
- 外部URLや添付ファイルを扱うツールは追加検査する
AI threat protectionのアラートは、こうした制御が破られそうになった兆候を検出する助けになります。ただし、根本的な被害抑制はアプリ設計側で行う必要があります。
管理者・開発者向けチェックリスト
最後に、導入時に確認すべき項目をチェックリストとして整理します。
| 対象 | 確認項目 |
|---|---|
| Azure管理者 | 対象サブスクリプションでDefender for CloudとAI servicesプランが有効か |
| Azure管理者 | 利用クラウド、リージョン、モデル、トークン種別が対象範囲に入るか |
| セキュリティ管理者 | Defender XDR、Defender for Cloud、Sentinelでアラートを受けられるか |
| セキュリティ管理者 | Suspicious prompt evidenceをオンにするか、マスク運用にするか |
| コンプライアンス担当 | Purview連携のライセンス、監査対象、データ保持方針を確認したか |
| 開発者 | UserSecurityContextでEndUserId、SourceIP、applicationNameを渡せるか |
| 開発者 | SDKやREST APIの対応バージョンを確認したか |
| AI基盤担当 | Azure Machine Learning上のモデルスキャン対象と制約を確認したか |
| DevOps担当 | CI/CDで危険なAIモデルを本番前に止める仕組みがあるか |
| 運用担当 | High/Medium/Lowアラートごとの対応SLAと担当分界を決めたか |
Microsoft Defender for CloudのAI threat protectionは、生成AIアプリケーションを本番運用する組織にとって重要な監視・対応基盤です。まずはAIリソースの棚卸しを行い、対象サブスクリプションでAI servicesプランを有効化できるか確認してください。そのうえで、プロンプト証拠、Purview連携、UserSecurityContext、AIモデルスキャン、Defender XDR連携を順に整備すると、検出だけで終わらない実効性のあるAIセキュリティ運用に近づけます。
コメント