Microsoft Defender Advanced HuntingでAIエージェント関連のクエリを使っている場合、まず確認すべきことは「AIAgentInfo / AIAgentsInfo を参照しているクエリが残っていないか」です。公式情報では、AIエージェントのインベントリ情報は新しい AgentInfo / AgentsInfo 系のテーブルへ移行され、古いテーブルは非推奨になります。特にSOCチームでは、保存済みクエリ、カスタム検出、API経由のクエリ、ダッシュボードが無音で失敗したり、結果が0件になったりするリスクがあります。
重要なのは、単なるテーブル名の置換だけで済ませないことです。新しいスキーマでは、エージェントID、認証、権限、ライフサイクル、構成情報などの扱いが広がっており、列名やデータ型、フィルター条件の見直しが必要です。Microsoft Defender XDR内に保存されたクエリやカスタム検出ルールは自動更新されると説明されていますが、APIで実行しているクエリや、Defender外部に保存しているKQLは手動更新が必要です。(Microsoft Learn)
Microsoft Defender Advanced Huntingの変更点：AIAgentInfoからAgentInfo系テーブルへ移行
Microsoft Defender Advanced Huntingのスキーマ変更として、AIエージェント関連のインベントリテーブルが旧テーブルから新テーブルへ移行されます。公式の移行情報では AIAgentInfo から AgentInfo への移行と表記される箇所があります。一方、スキーマ変更ページやテーブルリファレンスでは AIAgentsInfo から AgentsInfo への移行として案内されています。実務上は、自社テナントのAdvanced Huntingスキーマで表示される実際のテーブル名を確認し、AIAgentInfo、AIAgentsInfo、AgentInfo、AgentsInfo の表記揺れを含めて棚卸しするのが安全です。(Microsoft Learn)
公式のスキーマ変更ページでは、2026年6月の変更として AIAgentsInfo テーブルが AgentsInfo テーブルへ移行中であり、AIAgentsInfo はCopilot Studio向けに作られた旧スキーマ、新しい AgentsInfo はCopilot Studio、Microsoft Foundry、Microsoft 365 Copilot、サードパーティエージェント、エンドポイントで検出されたエージェントなどを扱う統合スキーマと説明されています。(Microsoft Learn)
| 確認項目 | 旧スキーマで見直す対象 | 新スキーマで見るべき観点 |
|---|---|---|
| テーブル名 | AIAgentInfo / AIAgentsInfo | AgentInfo / AgentsInfo |
| エージェントID | AIAgentId など | AgentId、SourceAgentId、EntraAgentId |
| 表示名 | AIAgentName など | AgentName |
| 状態 | AgentStatus、IsBlocked など | PublishedStatus、LifecycleStatus |
| 所有者 | CreatorAccountUpn、OwnerAccountUpns など | Owners、SharedWith |
| 権限・認証 | 個別列やJSON内の値 | Permissions、ToolsAuthenticationType |
| 追加情報 | RawAgentInfo | RawAgentInfo。新スキーマではJSON形式の追加情報として活用 |
なぜ小さなスキーマ変更がSOCに大きく影響するのか
テーブル名の変更は、一見すると小さなメンテナンスに見えます。しかし、Advanced Huntingのクエリは単なる調査用ではなく、カスタム検出ルール、レポート、SOAR連携、監査用ダッシュボードの土台になっていることがあります。
たとえば、AIエージェントの所有者、公開状態、外部接続、MCPサーバー、認証設定を監視していたクエリが古いテーブルを参照し続けると、次のような問題が起きます。
- 検出ルールが期待通りに評価されない
- ダッシュボードが0件表示になり、問題がないように見える
- API連携や自動レポートでエラーが発生する
- 列名変更により、
project、join、where条件だけが壊れる - 旧テーブルが残っている間は動くため、移行漏れに気づくのが遅れる
Microsoft DefenderのAdvanced Huntingは、最大30日間の生データをKQLで探索でき、同じクエリをカスタム検出ルールにも利用できます。つまり、クエリの破損は「調査がしにくい」だけでなく、「検知や対応の品質が下がる」問題につながります。(Microsoft Learn)
影響を受ける可能性が高い環境
今回の変更で特に注意すべきなのは、Microsoft Defender XDRやMicrosoft Defender for Cloud Apps上でAIエージェントの棚卸し、リスク検出、ポリシー監視を行っている環境です。
| 対象 | 影響の出方 | 優先度 |
|---|---|---|
| SOCの保存済みハンティングクエリ | 旧テーブルや旧列名の参照で結果が変わる | 高 |
| カスタム検出ルール | Defender XDR内の保存ルールは自動更新対象とされるが、移行後の結果確認は必要 | 高 |
| API経由で実行するKQL | 自動更新されないため、手動修正が必要 | 最重要 |
| Git、Wiki、Runbookに保存したKQL | 古いサンプルが再利用されるリスク | 高 |
| Power BI、Workbook、SIEM連携 | 結果0件、列不足、型不一致が起きやすい | 高 |
| SOAR、Logic Apps、チケット起票連携 | JSON解析や列参照が失敗する可能性 | 高 |
| 一時的なアドホック調査クエリ | 影響は限定的だが、移行後の調査効率に影響 | 中 |
Microsoft Defender XDR内に保存されたクエリやカスタム検出ルールは自動的に命名変更が適用されるとされています。ただし、APIで実行するクエリ、Defender XDR外に保存されたクエリは更新が必要です。自動更新される対象であっても、列名やロジックの意味が完全に保たれるかは別問題なので、検出件数や代表的な結果を比較して確認してください。(Microsoft Learn)
AIAgentsInfoからAgentsInfoへの移行は「名前変更」だけではない
今回の変更で見落としやすいのは、新しい AgentsInfo が単なる旧テーブルの別名ではない点です。旧 AIAgentsInfo は主にCopilot Studioシナリオを前提にした列が多く、新しい AgentsInfo は複数種類のAIエージェントを統一的に扱うためのスキーマです。
AgentsInfo テーブルには、AIエージェントのID、名称、プラットフォーム、説明、バージョン、Entra ID関連の識別子、認証・承認モデル、権限、公開状態、ライフサイクル状態、共有範囲、システムプロンプト、モデル、接続先、MCPサーバー、メモリ、ガードレール、実行エンドポイント、Microsoft Agent 365内の利用状況と関連付けるための ObservabilityId などが含まれます。(Microsoft Learn)
特にSOCの観点では、次の列を優先的に確認すると実務に直結します。
| 列 | 見るべき理由 |
|---|---|
AgentId | 新スキーマでの基本的な一意識別子。旧 AIAgentId の置換候補として確認 |
AgentName | ダッシュボードやアラート通知で表示される名称 |
Platform | Copilot Studio、Foundryなど発生元の切り分けに使う |
PublishedStatus | 下書きか公開済みかを判断 |
LifecycleStatus | Active、Blocked、Uninstalled、Deletedなどの状態確認に使う |
Owners | 問い合わせ先、是正依頼先、承認フローの特定に重要 |
Permissions | 要求・付与された権限や同意状況の確認に使う |
ToolsAuthenticationType | 認証・承認モデルの確認に使う |
McpServers | MCP連携の有無や外部接続リスクを確認する入口 |
DeclaredDataSources | エージェントがアクセスできるデータソースを把握 |
DeclaredTools | 実行可能なツールやアクションの棚卸しに使う |
RawAgentInfo | スキーマに展開されていない追加情報をJSONとして確認 |
管理者がすぐ確認すべき設定と移行ポイント
Microsoft Agent 365ライセンスの対象か確認する
2026年7月1日以降、Microsoft Copilot StudioおよびMicrosoft Foundryエージェント向けの一部AIエージェントセキュリティ機能は、Microsoft Agent 365の対象ライセンスが必要になると案内されています。対象ライセンスがないテナントでは、該当機能へのアクセスが失われる可能性があります。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| Agent 365対象ライセンスの有無 | 対象機能を継続利用する予定があるか |
| Copilot Studioエージェントの利用状況 | エージェント発見、姿勢管理、脅威検出を使っているか |
| Microsoft Foundryエージェントの利用状況 | Foundryエージェント単位の可視化や脅威検出を使っているか |
| Defender for Cloud Apps / Defender for Cloud依存 | 既存ライセンスだけで継続できると誤認していないか |
| 監査・SOC運用への影響 | 可視化、検出、ブロック、レポートのどれに依存しているか |
Security for AI Agentsの設定を確認する
公式情報では、2026年7月1日にSecurity for AI関連機能がDefender設定内の単一のSecurity for AI Agentsトグルへ統合されると説明されています。このトグルがオフの場合、Security for AI機能が無効になります。(Microsoft Learn)
管理者は、移行前後で次の状態を確認してください。
- DefenderポータルでSecurity for AI関連設定が有効になっているか
- 既存のAIエージェント検出や推奨事項が継続表示されているか
- ライセンスなしのテナントで、機能画面がライセンス案内に置き換わっていないか
- 設定変更の権限を持つ管理者が明確か
- 本番テナントと検証テナントで設定差分がないか
リアルタイム保護のブロックルールを再定義する
Agent 365の既存リアルタイム保護ルールでBlockに設定されているテナントは、2026年7月1日にブロックが停止すると案内されています。ブロックを継続するには、新しいポリシー体験でルールを再定義する必要があります。(Microsoft Learn)
この点は特に重要です。クエリ移行だけ済ませても、ブロックルールの再設定を忘れると「検知はできるが止められない」状態になる可能性があります。
| 状態 | 必要な対応 |
|---|---|
| 既存ルールがAuditのみ | ログ取得と検出ロジックの移行を確認 |
| 既存ルールがBlock | 新しいポリシー体験でブロックルールを再定義 |
| SOARで後続対応している | 新しい BehaviorInfo やAgent 365観測ログを入力元に更新 |
| アラート通知だけ使っている | 通知条件とアラート名の変化を確認 |
開発者・SOCエンジニア向けの移行手順
まず旧テーブル名を全検索する
最初に行うべき作業は、旧テーブル名の棚卸しです。検索対象はDefenderポータル内だけでは不十分です。KQLが保存されている場所をすべて洗い出してください。
| 探す場所 | 検索する文字列 |
|---|---|
| Microsoft Defender XDRの保存済みクエリ | AIAgentInfo、AIAgentsInfo |
| カスタム検出ルール | AIAgentInfo、AIAgentsInfo、旧列名 |
| Sentinel Workbook / Analytics Rule | AIAgentInfo、AIAgentsInfo |
| Gitリポジトリ | AIAgent、AIAgentsInfo、AgentStatus |
| Power BI / レポート | 旧列名、旧JSONパス |
| Logic Apps / Power Automate | KQL本文、JSON解析スキーマ |
| Wiki / Runbook | 手順書内のサンプルKQL |
表記揺れを考慮して、AIAgentInfo と AIAgentsInfo の両方を検索してください。公式情報でも移行記事とテーブル参照で単数・複数の表記差が見られるため、どちらか一方だけを検索すると移行漏れが残ります。
新旧クエリの結果を比較する
移行時は、テーブル名だけを置換して本番運用に戻すのではなく、代表的なクエリで件数と中身を比較します。
旧クエリの例です。
AIAgentsInfo
| summarize arg_max(Timestamp, *) by AIAgentId
| project Timestamp, AIAgentId, AIAgentName, Platform, AgentStatus, OwnerAccountUpns新スキーマでは、列名や状態の持ち方が変わるため、次のように置き換え候補を確認します。
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| project Timestamp, AgentId, AgentName, Platform, PublishedStatus, LifecycleStatus, Owners検証時は、次の観点で比較してください。
| 比較項目 | 確認内容 |
|---|---|
| 件数 | 旧クエリと新クエリで大きな差がないか |
| 代表的なエージェント | 重要な本番エージェントが新テーブルにも出ているか |
| 所有者情報 | 是正依頼先が特定できる形で取得できるか |
| 状態 | 公開済み、ブロック済み、削除済みの条件が再現できるか |
| 権限・接続先 | 旧クエリで見ていたリスク条件を新列で表現できるか |
| ダッシュボード | グラフや集計の軸が壊れていないか |
列名変更をマッピングする
AIAgentId を AgentId に、AIAgentName を AgentName に置き換えるだけなら簡単です。しかし、所有者、権限、状態、接続先の情報は構造が変わる可能性があります。dynamic 型の列を使う場合は、既存のJSONパースや配列展開の処理も見直してください。
移行時の考え方は次の通りです。
| 旧クエリの目的 | 新スキーマでの見直し方 |
|---|---|
| 公開済みエージェントを探す | PublishedStatus を確認 |
| ブロック済み・削除済みを除外する | LifecycleStatus を確認 |
| 所有者を表示する | Owners を確認し、必要に応じて展開 |
| 外部接続を調べる | Endpoints、DeclaredTools、McpServers を確認 |
| 権限の強いエージェントを探す | Permissions、ToolsAuthenticationType を確認 |
| 追加メタデータを調べる | RawAgentInfo を parse_json() で確認 |
たとえば、MCPサーバーが設定されたエージェントを確認したい場合、まずは次のようなシンプルなクエリで取得できるデータの形を確認します。
AgentsInfo
| where isnotempty(McpServers)
| project Timestamp, AgentId, AgentName, Platform, LifecycleStatus, Owners, McpServers外部接続先を確認したい場合は、まず列の中身を見てから展開方法を決めます。
AgentsInfo
| where isnotempty(Endpoints)
| project Timestamp, AgentName, Platform, LifecycleStatus, Endpoints
| take 20最初から複雑な検出ロジックへ移植するより、まずは project と take でデータ形状を確認し、その後に mv-expand や parse_json() を加える方が安全です。
移行時に失敗しやすいポイント
旧テーブルが残っている間に安心してしまう
AIAgentsInfo は移行期間中も一定期間アクセス可能と案内されています。公式情報では2026年7月1日までアクセス可能とされていますが、これは「まだ使ってよい」という意味ではなく「移行するための猶予」と捉えるべきです。(Microsoft Learn)
旧テーブルが返す結果を前提にしたまま運用を続けると、切り替え日付の前後で突然ダッシュボードやAPI連携が壊れる可能性があります。特に、月次レポートや四半期監査でしか実行しないクエリは発見が遅れがちです。
Defender内の自動更新を過信する
Microsoft Defender XDRに保存されたクエリやカスタム検出ルールは自動更新されると説明されています。ただし、これはDefender XDRが管理している範囲の話です。Git、Wiki、Sentinel、Power BI、外部の自動化スクリプト、APIクライアントに埋め込まれたKQLは別途確認してください。(Microsoft Learn)
また、自動更新後も検出意図まで完全に担保されるとは限りません。列の意味が変わっている場合、クエリは実行できても「検出したいリスク」を拾えていない可能性があります。
列名だけでなくデータ型を確認していない
新しい AgentsInfo では、Permissions、Owners、DeclaredTools、McpServers、Endpoints、RawAgentInfo など、dynamic 型の列が重要になります。文字列として比較していた旧ロジックをそのまま移すと、意図した条件に一致しない場合があります。
特に次のような書き方は注意が必要です。
| where Owners contains "[email protected]"Owners が配列やJSON構造の場合、文字列検索でたまたま一致することはあっても、安定した判定とは限りません。実際のデータ構造を確認し、必要に応じて mv-expand、tostring()、parse_json() を使って明示的に評価してください。
結果0件を「問題なし」と判断してしまう
移行後のクエリで最も危険なのは、エラーではなく0件です。KQLが実行できてしまうため、監視画面上は正常に見えます。しかし、列条件が新スキーマに合っていなければ、本来検出すべきエージェントが漏れます。
移行テストでは、次の3種類のクエリを必ず分けて確認してください。
| テスト | 目的 | |
|---|---|---|
| 全件確認 | AgentsInfo | count でデータが入っているか確認 | |
| 代表確認 | 既知の本番エージェント名で検索し、取得できるか確認 | |
| リスク条件確認 | MCP、外部接続、強い権限など、実際の検出条件が機能するか確認 |
実務で使える移行チェックリスト
| チェック項目 | 完了基準 |
|---|---|
| 旧テーブル名の検索 | AIAgentInfo と AIAgentsInfo の両方で検索済み |
| 新テーブルの存在確認 | 自社テナントのスキーマに AgentInfo / AgentsInfo が表示される |
| 列マッピング作成 | 旧列と新列の対応表を運用チーム内で共有済み |
| カスタム検出の確認 | 自動更新後の実行結果と検出件数を確認済み |
| APIクエリの修正 | 外部スクリプト、SOAR、CI/CD、定期実行ジョブを更新済み |
| ダッシュボード修正 | Power BI、Workbook、レポートの列参照を更新済み |
| ライセンス確認 | Microsoft Agent 365対象ライセンスの有無を確認済み |
| Security for AI設定確認 | Defender側の有効化設定を確認済み |
| ブロックルール確認 | Block設定が必要なルールを新ポリシーで再定義する計画がある |
| 関係者への周知 | SOC、IT管理者、監査担当、アプリ所有者へ影響を共有済み |
移行後の検証で見るべきKQL例
まずは新テーブルにデータが入っているか確認します。
AgentsInfo
| count主要なエージェントを一覧化します。
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| project Timestamp, AgentId, AgentName, Platform, PublishedStatus, LifecycleStatus, Owners
| order by Timestamp desc公開済みかつアクティブなエージェントだけを確認します。
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where PublishedStatus == "Published"
| where LifecycleStatus == "Active"
| project AgentName, Platform, Owners, SharedWith, LastUpdatedDateTimeMCPサーバーが設定されたエージェントを確認します。
AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where isnotempty(McpServers)
| project AgentName, Platform, LifecycleStatus, Owners, McpServers追加情報のJSONを確認します。
AgentsInfo
| where isnotempty(RawAgentInfo)
| extend Raw = parse_json(RawAgentInfo)
| project AgentName, Platform, Raw
| take 20これらのクエリは、そのまま本番検出ルールにするというより、移行後のデータ形状を確認するための出発点です。実際の検出ルールでは、自社のAIエージェント利用ポリシーに合わせて、公開状態、共有範囲、接続先、権限、所有者不明、外部公開などの条件を具体化してください。
展開計画は「期限」ではなく「検出品質」から逆算する
2026年7月1日まで旧テーブルへアクセスできるとしても、SOC運用では期限ぎりぎりの変更は避けるべきです。カスタム検出、API連携、ダッシュボード、レポートは、それぞれ失敗の仕方が異なります。
現実的には、次の順で進めると安全です。
| フェーズ | 実施内容 |
|---|---|
| 棚卸し | 旧テーブル名、旧列名、外部保存KQLを検索 |
| 影響分類 | 検出、ブロック、調査、レポート、監査に分類 |
| 新スキーマ確認 | AgentsInfo の列、データ型、実データを確認 |
| クエリ移植 | テーブル名だけでなく列と条件を修正 |
| 並行検証 | 旧クエリと新クエリの件数・代表結果を比較 |
| 本番切替 | カスタム検出、API、ダッシュボードを更新 |
| 監視 | 数日から数週間、0件化やエラー増加を確認 |
特に優先すべきなのは、ブロックや自動対応に関係するものです。表示用ダッシュボードの修正よりも、検出ルール、SOAR連携、チケット起票、ブロックポリシーを先に確認してください。
まとめ：AIAgentInfoの移行は、SOC運用の棚卸しとして扱う
Microsoft Defender Advanced Huntingの AIAgentInfo / AIAgentsInfo から AgentInfo / AgentsInfo への移行は、単なる名称変更ではありません。AIエージェントのインベントリをMicrosoft Agent 365中心の統合スキーマへ寄せる変更であり、列名、データ型、対象エージェント、検出ロジックの見直しが必要です。
まずは、旧テーブル名を参照しているクエリをすべて洗い出してください。次に、AgentsInfo の実データを確認し、ID、名前、所有者、公開状態、ライフサイクル、権限、外部接続、MCP関連の条件を新スキーマで再設計します。Defender XDR内で自動更新されるクエリであっても、検出件数と代表結果の確認は必須です。
最終的には、次の3点を完了できれば移行リスクを大きく下げられます。
AIAgentInfo/AIAgentsInfoを参照するKQLをDefender内外で棚卸しするAgentInfo/AgentsInfoの列構造に合わせて、検出条件とダッシュボードを更新する- ライセンス、Security for AI設定、リアルタイム保護のブロックルールまで含めて展開計画を確認する
小さなスキーマ変更でも、SOCでは検出漏れや無音のダッシュボード障害につながります。期限前に「クエリが動くか」だけでなく、「本来検出したいリスクを検出できているか」まで確認しておきましょう。
コメント