Microsoft Defender の「Detect and investigate threats to AI agents using Microsoft Defender」は、AIエージェントの不審な動作を検出し、Defender ポータルのアラート、インシデント、Advanced Hunting で調査できるようにするプレビュー機能です。結論から言うと、Copilot Studio、Microsoft Foundry、Microsoft 365 Copilot Agent Builder、その他の Agent 365 管理対象エージェントを使っている組織は、Agent 365 ライセンス、Microsoft 365 コネクタ、Advanced Hunting のテーブル移行、リアルタイム保護ルール、プロンプト証拠収集の扱いをすぐに確認すべきです。公式ドキュメントは 2026年7月1日に更新されており、AIエージェントの可視化・検出・調査の前提が Microsoft Agent 365 に寄せられている点が大きなポイントです。(Microsoft Learn)
Microsoft Defender の AI エージェント脅威検出とは
Microsoft Defender の AI エージェント脅威検出は、AIエージェントが実行するツール呼び出し、データアクセス、実行パターンなどをもとに、不審または悪意のある挙動を検出する仕組みです。対象は Microsoft Agent 365 で管理される AIエージェントで、Defender XDR の既存の運用フローに沿って、アラート確認、インシデント調査、Advanced Hunting による追跡ができます。(Microsoft Learn)
AIエージェントは、単なるチャットボットと違い、自然言語の指示を受けて外部ツールを呼び出したり、業務データへアクセスしたり、システム上で操作を実行したりします。そのため、従来の「ユーザー操作」や「アプリ通信」だけを見る監視では、攻撃の起点や影響範囲を追いにくくなります。
この機能で特に重要なのは、次のような AI 固有のリスクを Defender の調査対象にできる点です。
| 検出・調査したいリスク | 実務での例 | 管理者が見るべき観点 |
|---|---|---|
| ジェイルブレイク試行 | エージェントの制約を無視させようとするプロンプト | どのユーザー、どのエージェント、どの会話で発生したか |
| XPIA 試行 | 外部コンテンツに隠された命令でエージェントを誘導 | 参照したファイル、URL、ツール呼び出しの流れ |
| 資格情報・シークレット漏えい | エージェントが機密情報を出力または外部送信しようとする | 対象データ、呼び出したツール、関係ユーザー |
| 悪意あるコンテンツの伝播 | エージェントが危険な内容を他システムへ展開 | 影響を受けるアプリ、チャネル、宛先 |
| 回避的な挙動 | 検出を避けるような不自然な実行パターン | 実行頻度、時間帯、異常なツール組み合わせ |
公式情報では、Defender がジェイルブレイク、XPIA、悪意あるコンテンツの伝播、シークレットや資格情報の漏えい、回避手法、不審なユーザーアクセスなどを検出対象としていることが示されています。(Microsoft Learn)
2026年7月1日更新で押さえるべき変更点
今回の更新で管理者が最も注意すべきなのは、単に「新しい検出機能が増えた」という話ではありません。AIエージェントのセキュリティ運用が、Microsoft Agent 365 の観測データとエージェントレジストリを前提に再整理されている点が重要です。
| 確認項目 | 更新ポイント | 管理者の対応 |
|---|---|---|
| ライセンス | 2026年7月1日以降、Copilot Studio と Microsoft Foundry のエージェントセキュリティ機能には Agent 365 対象ライセンスが必要 | テナントに Agent 365 対象ライセンスがあるか確認 |
| データ収集 | Agent 365 の観測データが検出・調査・ハンティングの前提 | Microsoft 365 コネクタと Security for AI の有効化状態を確認 |
| Advanced Hunting | AIAgentsInfo から AgentsInfo への移行が必要 | 保存済みクエリ、カスタム検出、ワークブックを修正 |
| リアルタイム保護 | 監査・ブロックイベントは BehaviorInfo などで追跡する運用が重要 | 新しい Policies & rules でブロックルールを再定義 |
| サードパーティ製クラウドエージェント | 従来の Defender for Cloud コネクタ経由の発見から Agent 365 レジストリ同期へ移行 | レジストリ同期の利用可否を確認 |
| ローカル AI エージェント | クラウドエージェントとは別に Defender for Endpoint 側の設定が必要 | 対象端末、Defender Antivirus のアクティブモード、Runtime protection を確認 |
公式の移行情報では、2026年7月1日以降、Agent 365 対象ライセンスがないテナントでは該当する AI エージェントセキュリティ機能へのアクセスを失うと説明されています。また、既存の Agent 365 リアルタイム保護ルールで Block に設定していたものは、同日以降に新しいポリシー体験で再定義しないとブロックが継続されない点も明記されています。(Microsoft Learn)
影響範囲：どの AI エージェントが対象になるのか
Microsoft Defender での AIエージェント脅威検出は、主に Microsoft Agent 365 で管理されるエージェントが対象です。公式ドキュメントでは、Microsoft Copilot Studio、Microsoft Foundry、Microsoft 365 Copilot Agent Builder で作成された宣言型エージェントは、既定で Microsoft 365 に観測データを送信すると説明されています。その他のプラットフォームで構築された AI エージェントでは、Microsoft Agent 365 SDK などを使って観測データを有効化する必要があります。(Microsoft Learn)
注意したいのは、クラウド上のエージェントと端末上で動くローカル AI エージェントでは、オンボードの考え方が違う点です。ローカル AI エージェントを検出・保護対象にするには、Microsoft Defender for Endpoint 側で AI agent runtime protection を設定し、Defender for Endpoint と Microsoft Defender Antivirus がアクティブモードで動作している必要があります。(Microsoft Learn)
たとえば、次のような環境では確認が必要です。
| 利用状況 | 影響 | 確認すべきこと |
|---|---|---|
| Copilot Studio のカスタムエージェントを業務部門が作成している | ツール呼び出しや不審動作の検出対象になり得る | Agent 365 ライセンス、Microsoft 365 コネクタ、Copilot Studio 連携 |
| Microsoft Foundry で社内向けエージェントを構築している | Foundry エージェントの可視化・検出が Agent 365 前提になる | 旧 Defender for Cloud 前提の運用が残っていないか |
| 端末上でローカル AI エージェントを使っている | クラウド側の設定だけでは保護できない | Defender for Endpoint の Runtime protection |
| サードパーティ製エージェントを導入している | 検出・棚卸しの経路が変わる可能性がある | Agent 365 レジストリ同期や SDK 対応状況 |
有効化前に確認すべき前提条件
Microsoft Defender で AI エージェント脅威を検出・調査するには、まず Security for AI agents を有効化し、Microsoft 365 app connector を使って Agent 365 の観測データを収集できる状態にします。Defender ポータルでは、Settings > Security for AI > Get started から構成を確認できます。Microsoft 365 コネクタでは、少なくとも Microsoft Entra ID Management events と Microsoft 365 activities の選択が必要とされています。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| ライセンス確認 | Agent 365 対象ライセンスがあるか | 旧 Defender for Cloud Apps / Defender for Cloud の権利だけで足りると誤解する |
| Security for AI の有効化 | Defender ポータルで Security for AI agents のトグルを確認 | トグルが Off でデータ収集も検出も止まる |
| Microsoft 365 コネクタ | Entra ID 管理イベントと Microsoft 365 アクティビティを接続 | コネクタ未接続だと、調査や Advanced Hunting に必要なデータが不足する |
| エージェント観測データ | Agent 365 に観測データが流れているか | 独自実装エージェントで SDK 対応が未実施 |
| ローカルエージェント | Defender for Endpoint の Runtime protection を設定 | クラウドエージェントと同じ手順で保護できると誤認する |
| 証拠データの扱い | プロンプト証拠収集の設定を確認 | 会話断片がセキュリティ証拠として扱われるため、社内ポリシー確認が必要 |
Copilot Studio のリアルタイム保護については、Power Platform 管理者との連携が必要です。公式手順では、Defender ポータル側で提供される URL や App ID を使い、Power Platform 管理者がオンボード作業を完了する流れになっています。(Microsoft Learn)
アラートとインシデント調査で何が見えるのか
Microsoft Defender は、AIエージェント関連の検出を Defender ポータルのアラートとして表示し、関連するアラートをインシデントに相関します。これにより、SOC やセキュリティ管理者は、通常の Defender XDR と同じ流れでトリアージ、影響範囲の確認、根本原因の調査を進められます。(Microsoft Learn)
調査で見るべきポイントは、従来のマルウェアやフィッシングとは少し異なります。AIエージェントの場合、単に「誰がアクセスしたか」だけでなく、どのエージェントが、どのツールを、どのデータに対して、どのような文脈で呼び出したかを追う必要があります。
具体的には、次の順番で見ると実務に落とし込みやすくなります。
| 調査観点 | 確認する内容 | 判断の目安 |
|---|---|---|
| 起点 | ユーザー入力、外部コンテンツ、ファイル、URL など | 外部コンテンツ参照後に不審な命令が発生していないか |
| エージェント | Agent ID、名前、プラットフォーム、所有者 | 業務上必要なエージェントか、放置されたエージェントか |
| ツール呼び出し | 実行されたツール、API、MCP サーバー | 書き込み・削除・送信など高リスク操作がないか |
| データアクセス | ナレッジソース、ファイル、アプリ、クラウドリソース | 機密情報や資格情報に触れていないか |
| 影響範囲 | 関連ユーザー、端末、アプリ、リソース | 追加調査や封じ込めが必要な範囲はどこか |
| 再発防止 | ルール、ガードレール、権限、共有範囲 | 監査で足りるか、ブロックへ移行すべきか |
Microsoft Defender は、インシデントグラフや調査画面で関係エンティティと影響範囲を把握できるようにし、Advanced Hunting では Agent 365 の観測データを KQL で照会できます。(Microsoft Learn)
Advanced Hunting で使う主要テーブル
AIエージェント脅威の調査では、Advanced Hunting のテーブル理解が重要です。公式ドキュメントでは、AIエージェントの調査に使う主要テーブルとして AlertInfo、CloudAppEvents、AgentsInfo、AlertEvidence、BehaviorInfo、BehaviorEntities が示されています。(Microsoft Learn)
| テーブル | 役割 | 使いどころ |
|---|---|---|
AgentsInfo | AIエージェントのインベントリと構成情報 | エージェント名、所有者、権限、公開状態、ツール、ナレッジソースを確認 |
CloudAppEvents | クラウドアプリや Agent 365 観測データに基づく活動 | エージェントのアクション、ツール呼び出し、データアクセスの追跡 |
AlertInfo | Defender のアラート概要 | AI エージェント関連アラートの抽出、優先度判断 |
AlertEvidence | アラートに紐づく証拠エンティティ | ユーザー、URL、ツール、リソースなどの関係確認 |
BehaviorInfo | リアルタイム保護の監査・ブロックなどの挙動 | ブロックルールや監査イベントの追跡 |
BehaviorEntities | Behavior に紐づくエンティティ | どのユーザー、デバイス、リソースが関係したかを確認 |
特に AgentsInfo は、従来の AIAgentsInfo から移行するテーブルです。Microsoft Agent 365 利用者は AgentsInfo を使うべきであり、AIAgentsInfo は 2026年7月1日までアクセス可能と説明されています。保存済みクエリやカスタム検出で古いテーブル名を使っている場合は、現在の運用に合うよう見直してください。(Microsoft Learn)
まず実行したい KQL 例
AIエージェントの棚卸しでは、公式ドキュメントにも示されている次のようなクエリが出発点になります。AgentsInfo は同じエージェントのスナップショットを複数保持するため、最新状態を見るには arg_max(Timestamp, *) を使うのが実務的です。(Microsoft Learn)
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where LifecycleStatus != "Deleted"エージェントの公開状態、所有者、権限、ツール、データソースを確認したい場合は、次のように必要な列だけに絞るとレビューしやすくなります。
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where LifecycleStatus != "Deleted"
| project
Timestamp,
AgentName,
Platform,
PublishedStatus,
LifecycleStatus,
Owners,
Permissions,
DeclaredTools,
DeclaredDataSources,
McpServers,
Guardrailsリアルタイム保護の監査・ブロックイベントを確認する場合は、BehaviorInfo を使います。BehaviorInfo はプレビューのテーブルで、GCC では利用できない点に注意が必要です。(Microsoft Learn)
BehaviorInfo
| where Timestamp > ago(7d)
| project
Timestamp,
Title,
ActionType,
ServiceSource,
DetectionSource,
AccountUpn,
AdditionalFields
| order by Timestamp descアラートに紐づく関係エンティティを見たい場合は、AlertEvidence を使い、ユーザー、URL、デバイス、アプリ、クラウドリソースなどを確認します。AlertEvidence には、アラート ID、エンティティ種別、関係する URL、ユーザー、デバイス、アプリケーションなどの列が用意されています。(Microsoft Learn)
リアルタイム保護との違いを理解する
「Detect and investigate threats to AI agents」は、発生した脅威を検出・調査・ハンティングするための機能です。一方で、危険なエージェント操作を実行前に止めたい場合は、Microsoft Defender のリアルタイム保護を組み合わせます。(Microsoft Learn)
リアルタイム保護では、クラウドエージェント向けに既定の監査ルールとカスタムブロックルールを使い分けます。既定ルールはすべてのエージェントを監査し、実行を止めずに Behavior として記録します。カスタムルールは、特定の検出タイプやエージェント範囲に対して、実行前に危険な操作をブロックするために使います。(Microsoft Learn)
| モード | 向いている場面 | 注意点 |
|---|---|---|
| 監査 | 初期導入、誤検知確認、影響調査 | 危険な操作を止めるわけではない |
| ブロック | 高リスク操作、外部公開エージェント、機密データに触れるエージェント | 業務処理を止める可能性があるため、対象範囲を絞る |
| 特定エージェント除外 | 業務影響が大きいエージェントの段階導入 | 除外しすぎると保護対象が空洞化する |
実務では、最初から全エージェントを広範囲にブロックするよりも、監査で 1〜2週間程度の傾向を見てから、高信頼の検出タイプや高リスクエージェントに絞ってブロックする方が安全です。Defender for Endpoint のローカル AI エージェント保護でも、Microsoft は小規模テスト、レビュー、段階展開、検証後のブロック移行という流れを推奨しています。(Microsoft Learn)
プロンプト証拠収集は既定有効、ただし社内ルール確認が必要
Microsoft Defender では、検出のきっかけになったユーザープロンプトやエージェント応答の一部を、アラートの証拠として含める設定があります。公式ドキュメントでは、このプロンプト証拠収集は既定で有効とされています。証拠に含まれるのは、セキュリティ分類に関連すると判断された不審な部分で、機密データやシークレットは編集されると説明されています。(Microsoft Learn)
ただし、ここはセキュリティ部門だけで判断しない方がよい領域です。プロンプトには、顧客情報、社内プロジェクト名、人事情報、契約条件などが含まれる可能性があります。証拠としての有用性と、プライバシー・コンプライアンス上の扱いを両立させるため、次の観点を事前に決めておくべきです。
| 確認項目 | 決めるべき内容 |
|---|---|
| 閲覧権限 | 誰がプロンプト証拠を閲覧できるか |
| 保管期間 | アラートやインシデント証拠としてどの程度保持するか |
| 利用目的 | 調査、監査、教育、再発防止のどこまで使うか |
| エスカレーション | 個人情報や機密情報が含まれる場合の報告先 |
| 無効化判断 | 業界規制や社内規定によりオフにすべきケース |
プロンプト証拠収集は、Settings > Security for AI > Prompt evidence collection で有効・無効を切り替えられます。(Microsoft Learn)
ローカル AI エージェントを使っている場合の追加確認
端末上で動作するローカル AI エージェントは、ユーザー権限でファイルを読み取り、ツールを呼び出し、コマンドを実行できる場合があります。悪意ある指示がファイルや外部コンテンツに隠されていると、プロンプトインジェクションによってエージェントが意図しない操作を実行する可能性があります。Microsoft Defender for Endpoint の AI agent runtime protection は、こうした端末レベルのプロンプトインジェクション検出や、実行前の監査・ブロックを担います。(Microsoft Learn)
単一端末で確認する場合は、PowerShell で状態確認と設定を行います。
Get-MpComputerStatus | Select-Object AntivirusSignatureVersionSet-MpPreference -AiAgentProtection Audit
Set-MpPreference -AiAgentNetworkInspection AuditGet-MpPreference | Select-Object AiAgentProtection, AiAgentNetworkInspection公式手順では、AiAgentProtection はベンダー対応のエージェントイベントインターフェイスを持つエージェント向け、AiAgentNetworkInspection はそのようなインターフェイスを持たないエージェントにも保護を広げる方式として説明されています。どちらも Disabled、Audit、Block のモードを取ります。組織展開では、現時点でネイティブの Intune ポリシーサポートはなく、PowerShell スクリプトを Intune で配布する形が示されています。(Microsoft Learn)
管理者がすぐ確認すべきチェックリスト
2026年7月1日の更新ポイントを踏まえると、Microsoft Defender 管理者は次の順番で確認するのが効率的です。
| 優先度 | 確認すること | 完了の目安 |
|---|---|---|
| 高 | Agent 365 対象ライセンスの有無 | Security for AI 機能が継続利用できる状態 |
| 高 | Security for AI agents のトグル | Defender ポータルで有効化されている |
| 高 | Microsoft 365 コネクタ | Entra ID 管理イベントと Microsoft 365 activities が接続済み |
| 高 | AIAgentsInfo 依存のクエリ | AgentsInfo に移行済み |
| 高 | 既存のブロックルール | 新しい Real-time protection policy で再定義済み |
| 中 | Prompt evidence collection | 有効・無効の判断と閲覧権限が整理済み |
| 中 | ローカル AI エージェント | Defender for Endpoint 側で Audit または Block を設定 |
| 中 | カスタム検出・自動化 | BehaviorInfo や AlertEvidence を使う形に修正 |
| 中 | 業務部門への周知 | エージェント所有者がルール変更と影響を理解している |
特に見落としやすいのは、ライセンスとコネクタを別物として確認することです。ライセンスがあっても Microsoft 365 コネクタや観測データが不足していれば、アラート調査や Advanced Hunting の実効性は下がります。逆に、データが収集されていても、古い AIAgentsInfo 前提のクエリや旧ブロックルールが残っていると、運用移行後に検出や自動化が期待どおり動かない可能性があります。
導入時の判断基準：監査から始め、ブロックは絞って適用する
AIエージェントの保護は、強くしすぎると業務を止め、弱すぎると攻撃に気づけません。最初の設計では、エージェントをリスク別に分類すると判断しやすくなります。
| リスク区分 | エージェントの特徴 | 推奨アクション |
|---|---|---|
| 高 | 外部データを読む、外部送信する、書き込み権限を持つ、MCP ツールを使う | 監査後、検出タイプを絞ってブロック検討 |
| 中 | 社内データを参照するが、書き込みや外部送信は限定的 | 監査と所有者レビューを継続 |
| 低 | FAQ、検索補助、限定的な読み取り中心 | まず棚卸しと権限確認を優先 |
| 不明 | 所有者不明、用途不明、長期間更新なし | 無効化、共有範囲縮小、所有者確認を実施 |
ブロックルールは「AI エージェント全体に一律適用」ではなく、業務影響と検出精度を見ながら対象を絞るのが現実的です。たとえば、社外公開に近いエージェント、顧客データを参照するエージェント、書き込み系ツールを持つエージェント、MCP サーバーに接続するエージェントは、優先的に監査・ブロック候補にします。
よくある失敗と回避策
Microsoft Defender の AIエージェント脅威検出では、設定そのものよりも、運用移行の見落としが問題になりがちです。
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| Agent 365 ライセンス確認を後回しにする | 2026年7月1日以降の機能利用に影響する | 契約・管理センター・対象ユーザーを先に確認 |
| Microsoft 365 コネクタを未接続のままにする | アラートや Advanced Hunting の文脈が不足する | Get started のチェックリストで接続状態を確認 |
AIAgentsInfo のクエリを放置する | 棚卸しやカスタム検出が古い前提で動く | AgentsInfo へ移行し、列名も見直す |
| 旧ブロックルールを信頼し続ける | ブロックが継続しない可能性がある | 新しい Policies & rules で再定義 |
| プロンプト証拠の扱いを決めない | 調査時に機密会話の閲覧範囲が曖昧になる | セキュリティ、法務、個人情報管理部門で合意 |
| クラウド設定だけでローカルエージェントも守れると考える | 端末上の AI エージェントが保護対象外になる | Defender for Endpoint の Runtime protection を別途設定 |
まとめ：まずは Agent 365 前提の運用に切り替える
Microsoft Defender の「Detect and investigate threats to AI agents using Microsoft Defender」は、AIエージェントの脅威を Defender XDR の通常運用に組み込むための重要なプレビュー機能です。単なるアラート追加ではなく、Agent 365 の観測データ、AI Agents インベントリ、Advanced Hunting、リアルタイム保護ポリシーを組み合わせて、エージェントの行動を継続的に監視・調査する流れへ移行するものと考えるべきです。
管理者が最初に行うべきことは明確です。Agent 365 対象ライセンスを確認し、Security for AI と Microsoft 365 コネクタを有効化し、AIAgentsInfo 依存のクエリを AgentsInfo へ移行し、既存のブロックルールを新しいポリシーで再定義します。そのうえで、プロンプト証拠収集の扱いとローカル AI エージェントの Defender for Endpoint 設定を確認すれば、AIエージェントの検出・調査・保護を実務に落とし込みやすくなります。
コメント