Microsoft Defenderのセキュリティ更新として今回まず押さえるべき点は、Defender端末エージェントの修正ではなく、Microsoft Sentinel MCP serverの「Data exploration tool collection」に関する公式情報だということです。Microsoft Defender XDRやDefender for Endpoint、Defender for Identity、Defender for Cloud AppsのデータをSentinel data lakeで活用している組織では、自然言語でのテーブル検索、KQL実行、ユーザーやURLのEntity Analyzer利用が運用に影響します。Microsoft Learn上の当該ページは最終更新日が2026年5月15日と表示されており、本記事では日本時間で2026年5月16日に確認すべき更新情報として、管理者・SOC担当者・開発者が確認するべき設定、権限、コスト、展開時の注意点を整理します。 (Microsoft Learn)
Microsoft Defender管理者が最初に理解すべきポイント
今回の「Data exploration tool collection in Microsoft Sentinel MCP server」は、Microsoft Defenderの検知ロジックそのものを変更する更新ではありません。Microsoft Sentinel data lakeに蓄積されたセキュリティデータを、MCP対応のAIクライアントから自然言語で探索・分析しやすくするための機能群です。
Microsoftの公式説明では、このData exploration collectionにより、Microsoft Sentinel data lake内の関連テーブルを検索し、データを取得できるとされています。対応する利用環境として、Microsoft Security Copilot、Microsoft Copilot Studio、Microsoft Foundry、Visual Studio CodeなどのAI対応コードエディターやエージェント構築基盤が挙げられています。 (Microsoft Learn)
管理者が急いで確認すべき結論は、次の4点です。
| 確認項目 | なぜ重要か | 優先度 |
|---|---|---|
| Microsoft Sentinel data lakeの利用状況 | Data exploration collectionの前提になるため | 高 |
| Sentinel MCP toolsの権限 | Security Administrator、Security Operator、Security Readerなどのロールが関係するため | 高 |
| Entity Analyzerで必要なテーブル | ユーザー分析やURL分析の精度・可否に直結するため | 高 |
| コスト・クォータ・英語プロンプト制限 | SCU消費、KQL課金、上限超過、運用失敗を避けるため | 高 |
特にDefender管理者は、「Microsoft Defenderだけを使っているから関係ない」と判断しない方が安全です。Defenderのアラート、サインイン、クラウドアプリ、ID、エンドポイント関連データをSentinel data lakeに連携している場合、SOCの調査手順や自動化フローに影響します。
今回の公式情報で明確になった変更点
今回の更新で重要なのは、新しいツール名を覚えることではなく、Microsoft DefenderとSentinelをまたいだ調査が「AIエージェント前提の操作」に近づいている点です。
Data exploration collectionでは、主に次のツールが整理されています。 (Microsoft Learn)
| ツール | 主な用途 | Defender運用での使いどころ |
|---|---|---|
search_tables | 自然言語の入力から関連するdata lakeテーブルとスキーマを探す | 「サインイン失敗」「怪しいURLクリック」などから必要なテーブルを探す |
query_lake | Microsoft Sentinel data lakeに対してKQLを実行する | 調査に必要なイベント、アラート、ID、端末、補足情報を取得する |
list_sentinel_workspaces | 利用可能なSentinel data lakeワークスペース名とIDを一覧化する | 複数ワークスペース環境で誤った対象にクエリを投げる事故を防ぐ |
analyze_user_entity | ユーザーを対象にEntity Analyzerを開始する | アカウント侵害、パスワードスプレー、異常サインインの調査 |
analyze_url_entity | URLを対象にEntity Analyzerを開始する | フィッシングURL、メール内URL、クリック履歴の調査 |
get_entity_analysis | 開始した分析結果を取得する | 非同期分析の結果をSOC画面やチケットに反映する |
実務上の変化として大きいのは、KQLに詳しい一部の担当者だけでなく、AIクライアントを使うアナリストや開発者が、関連テーブルの探索から分析までを一連の流れで実行できるようになる点です。ただし、これは「権限管理を緩めてもよい」という意味ではありません。むしろ、AIクライアント経由でセキュリティデータに触れる範囲が広がるため、最小権限、監査、利用ルールの整備がより重要になります。
Data exploration collectionの接続先と前提条件
Data exploration collectionを追加するには、Microsoft Sentinelの統合MCP serverインターフェイスを設定したうえで、以下のData exploration collection用エンドポイントを利用します。公式ページでは、Data exploration collectionがこのURLでホストされると説明されています。 (Microsoft Learn)
https://sentinel.microsoft.com/mcp/data-exploration前提条件として、Microsoft Sentinel data lakeが必要です。また、対応するAI対応コードエディターまたはエージェント構築プラットフォームとして、Microsoft Security Copilot、Microsoft Copilot Studio、Microsoft Foundry、Visual Studio Codeが挙げられています。 (Microsoft Learn)
権限面では、Sentinel MCP toolsへのアクセスは、少なくとも次のいずれかのロールを割り当てられたユーザー、マネージドID、サービスプリンシパルでサポートされます。 (Microsoft Learn)
| ロール | 運用上の見方 |
|---|---|
| Security Administrator | 管理権限が強いため、MCP利用だけを目的に安易に付与しない |
| Security Operator | SOC運用担当者向けの候補になるが、既存の職務分掌と照合する |
| Security Reader | 読み取り中心の検証や初期展開で候補になりやすい |
Microsoft Security Copilotを使う場合は、Security Copilot側のロールと、Microsoft Entra RBACやAzure RBACが別物である点にも注意が必要です。Security CopilotのロールはCopilot機能へのアクセスを制御しますが、それだけでSentinelやDefenderのセキュリティデータへアクセスできるわけではありません。Microsoftの認証説明でも、Copilotロール、Microsoft Entra RBAC、Azure RBAC、各サービス固有の権限を分けて考える必要があるとされています。 (Microsoft Learn)
Microsoft Defender環境への影響範囲
この更新の影響を受けやすいのは、Microsoft DefenderとMicrosoft Sentinelを組み合わせて運用している組織です。単体のDefender管理画面だけで完結している環境よりも、Sentinel data lake、Security Copilot、SOAR、MCP対応クライアントを使っている環境ほど確認範囲が広くなります。
| 対象 | 影響 | 確認すべきこと |
|---|---|---|
| Microsoft Defender XDR運用チーム | インシデント調査でAIエージェントがSentinel data lakeを参照する可能性がある | どのワークスペースとデータにアクセスできるか |
| Defender for Endpoint管理者 | 端末、ネットワーク、ファイル、URL関連データが分析材料になる | data lakeへの連携状況とテーブル有無 |
| Defender for Identity / Cloud Apps管理者 | ユーザー分析でID情報やクラウドアプリイベントが使われる | IdentityInfoやCloudAppEventsの利用可否 |
| SOCアナリスト | 自然言語で調査補助を受けられる一方、AI出力の検証が必要になる | 標準プロンプト、確認手順、エスカレーション条件 |
| 開発者・自動化担当者 | MCP経由の調査フローやエージェントを組み込める | API的に使いすぎない設計、リトライ、上限、課金 |
重要なのは、Data exploration collectionが「調査の入口」を増やす機能であることです。Defenderで発生したアラートを、Sentinel data lake上のサインインログ、メールURL情報、端末通信、Threat Intelligence、Watchlistなどと突き合わせる流れが作りやすくなります。
一方で、AIエージェントが出した説明をそのまま封じ込めやアカウント無効化の判断に使うのは危険です。運用ルールとして、「AIの分析結果は判断材料」「最終アクションは証拠テーブルやアラート詳細で確認」という線引きを明文化しておくべきです。
Entity Analyzerで確認すべきテーブル
今回の更新でDefender管理者が特に注意したいのがEntity Analyzerです。Entity Analyzerは、Microsoft Sentinel data lake内の組織データをAIで分析し、URL、ドメイン、ユーザーエンティティに対する判定と詳細な洞察を提供するツール群です。公式情報では、手作業のデータ収集や複雑な統合を減らす目的の機能として説明されています。 (Microsoft Learn)
ユーザー分析では、次のテーブルが精度確保のために必要とされています。 (Microsoft Learn)
| 分析対象 | 必須または重要なテーブル | 注意点 |
|---|---|---|
| ユーザー分析 | AlertEvidence、SigninLogs、CloudAppEvents、IdentityInfo | IdentityInfoはDefender for Identity、Defender for Cloud Apps、Defender for Endpoint P2ライセンスを持つテナントで利用可能とされています |
| ユーザー分析であると望ましいテーブル | AADNonInteractiveUserSignInLogs、BehaviorAnalytics | なくても動作する場合がありますが、分析の文脈が薄くなる可能性があります |
| URL分析であると望ましいテーブル | EmailUrlInfo、UrlClickEvents、ThreatIntelIndicators、Watchlist、DeviceNetworkEvents | URLの評判、クリック履歴、端末通信、監視リストとの照合に関わります |
実務では、Entity Analyzerを有効化する前に「自社のdata lakeにどのテーブルが実際に存在するか」を確認してください。必要なテーブルがない場合、ユーザー分析では不足テーブルを示すエラーが返る場合があり、URL分析では不足テーブルに関する免責・注意付きの応答になると説明されています。 (Microsoft Learn)
また、analyze_user_entityは最大7日間の分析ウィンドウをサポートし、Microsoft Entra object IDを持つユーザーが対象です。オンプレミスActive Directoryのみのユーザーは、ユーザー分析の対象外とされています。 (Microsoft Learn)
コスト、クォータ、言語制限で失敗しやすいポイント
Data exploration collectionを本番展開する前に、コストと上限を必ず確認してください。Microsoftの価格・制限ページでは、Microsoft Sentinelの統合MCP serverインターフェイス自体は追加費用なしで提供される一方、Sentinel data lakeからKQLでデータを検索・取得するツール呼び出しには、data lakeのクエリ課金が発生すると説明されています。さらにEntity Analyzerでは、data lakeに対するKQLクエリに加え、AIによる推論分析のためのSecurity Compute Units、つまりSCUの課金対象になるとされています。 (Microsoft Learn)
| 項目 | 公式情報で示されている内容 | 実務上の注意 |
|---|---|---|
| MCP serverインターフェイス | 追加費用なし | ただしツール呼び出しや分析で別の課金が発生する |
| data lake検索・取得 | KQLクエリに対する従量課金 | 大量取得や広すぎる時間範囲を避ける |
| Entity Analyzer | KQLクエリとSCUが課金対象 | 自動化で無制限に回さない |
| MCP streaming | 120秒 | 長時間処理を前提にしすぎない |
| Query window for tools | 800文字 | 複雑な指示を1回に詰め込みすぎない |
| Entity Analyzer上限 | 1時間200回、1日500回、5分あたり約15同時実行 | SOARやLogic Appsで並列実行を制御する |
| Entity Analyzer結果の保持 | 1時間 | 結果を使うワークフローでは取得タイミングに注意する |
| 言語 | 英語プロンプトのみ対応 | 日本語プロンプト前提の運用手順にしない |
| 利用可能地域 | 日本を含む複数地域 | グローバルテナントでは対象リージョンを確認する |
特に見落としやすいのは、英語プロンプトのみ対応という点です。日本語のSOC運用では、調査メモやチケットは日本語でも、MCPツールに渡すプロンプトは英語の標準文として整備した方が安定します。
例として、次のようなプロンプトを社内テンプレートにしておくと、属人化を減らせます。
Find sign-in failures in the last 24 hours and summarize key findings.Help me understand if the user <user object ID> is compromised.Analyze this URL and explain what Microsoft knows about it: <URL>管理者が確認すべき設定チェックリスト
展開前の確認は、機能単位ではなく「データ」「権限」「コスト」「運用」の4つに分けると漏れにくくなります。
データ連携の確認
まず、Microsoft Sentinel data lakeが利用可能かを確認します。Data exploration collectionはSentinel data lakeを前提にしているため、Defender側にデータが存在していても、data lakeで参照できなければ分析に使えない可能性があります。
確認すべき項目は次のとおりです。
| 確認内容 | 判断基準 |
|---|---|
| Sentinel data lakeが有効か | 対象ワークスペースでdata lakeを利用できる |
| Defender関連データが連携されているか | サインイン、クラウドアプリ、エンドポイント、URL、アラート関連テーブルが存在する |
| 複数ワークスペースがあるか | list_sentinel_workspacesで対象ワークスペースを明確にする |
| 未サポートテーブルに依存していないか | 既存のカスタム調査で使うテーブルが検索・分析対象になるか確認する |
query_lakeは、単一のKQLクエリを指定ワークスペースに対して実行し、生の結果セットを返すツールです。公式情報では、集中的な調査・分析の取得向けであり、大量エクスポート向けではないと説明されています。大量データの抽出用途に流用すると、コストや上限、応答時間の問題が起きやすくなります。 (Microsoft Learn)
権限の確認
MCP対応クライアントを使うと、ユーザーが自然言語で調査を開始できます。これは便利ですが、権限設計を誤ると、必要以上のセキュリティデータを閲覧できる状態になります。
初期展開では、次の方針がおすすめです。
| フェーズ | 推奨方針 |
|---|---|
| 検証 | Security Reader相当の読み取り権限で、限定ワークスペースから開始する |
| 小規模展開 | SOC担当者のグループ単位で付与し、個人直付けを避ける |
| 本番展開 | 職務分掌に合わせてSecurity Operatorや管理者権限を最小限にする |
| 自動化 | マネージドIDまたはサービスプリンシパルの権限を専用化する |
Security Administratorは強い権限です。MCPを使うためだけに付与すると、過剰権限になりやすいので注意してください。
Entity Analyzerの実行制御
Entity Analyzerは、分析開始ツールでIDを受け取り、結果取得ツールで分析結果を取得する非同期型の流れです。公式情報では、分析に数分かかる場合があり、結果取得ツールの内部タイムアウトが長い分析に十分でない場合は、複数回実行が必要になる可能性があると説明されています。 (Microsoft Learn)
自動化する場合は、次の設計を入れてください。
| 設計項目 | 推奨内容 |
|---|---|
| リトライ | 結果未準備の場合に一定間隔で再取得する |
| タイムアウト | 無限待機を避け、最大待機時間を決める |
| 並列数 | 最初は同時分析を少なくし、負荷と応答時間を見ながら調整する |
| 結果保存 | 1時間で結果が期限切れになる前に、必要な要約や証跡をチケットへ保存する |
| 人間の確認 | 高リスク判定でも、封じ込め前にアラートやKQL結果を確認する |
公式情報では、Entity Analyzerを複数同時実行すると各実行のレイテンシが増える可能性があり、タイムアウトやしきい値超過を避けるため、まず最大5件程度の分析から開始して調整することが推奨されています。 (Microsoft Learn)
開発者が実装時に注意すべきポイント
開発者やSOCエンジニアがMCPを組み込む場合、単に「AIから呼べる便利な検索機能」として扱うと失敗します。MCPツールは、権限、コスト、データ範囲、応答時間を含む本番システムの一部として設計する必要があります。
search_tablesを先に使う
KQLを直接生成して失敗するより、まずsearch_tablesで関連テーブルとスキーマを確認する流れにした方が安全です。公式情報でも、search_tablesは自然言語入力に関連するdata lakeテーブルを発見し、KQL作成を支援するスキーマ定義を返すツールとして説明されています。 (Microsoft Learn)
実装例の流れは次のとおりです。
| 手順 | 処理 |
|---|---|
| 1 | list_sentinel_workspacesで対象ワークスペースを特定する |
| 2 | search_tablesで関連テーブルとスキーマを探す |
| 3 | 生成したKQLを人間または検証ロジックで確認する |
| 4 | query_lakeで必要最小限の期間・列・件数に絞って実行する |
| 5 | 結果をアナリスト向けに要約するが、元データへの参照を残す |
自動化では「広すぎる質問」を避ける
AIエージェントに「全部調べて」と指示すると、対象テーブル、時間範囲、出力件数が曖昧になり、コストや応答時間が膨らみやすくなります。
悪い例は次のような指示です。
Investigate all suspicious users and URLs in the tenant.改善例は次のように、対象、期間、目的を明確にします。
Find sign-in failures for this user in the last 24 hours and return the top 10 relevant events.Analyze this URL using the last 7 days of available evidence and summarize the risk indicators.特にquery_lakeは大量エクスポート向けではないため、take、時間条件、必要列の指定を標準化してください。
AIの回答をそのままアクションにしない
MCPツールが返した分析結果を、アカウント無効化、端末隔離、URLブロックなどの自動アクションに直結させる場合は、必ず承認ステップを入れるべきです。
本番で安全に使うなら、次のような段階的な扱いが現実的です。
| リスク判定 | 推奨アクション |
|---|---|
| 低 | チケットに分析結果を追記し、監視継続 |
| 中 | アナリスト確認後、追加KQLやDefender画面で裏取り |
| 高 | インシデント責任者の承認後、封じ込めや条件付きアクセス対応 |
| 不明・データ不足 | 不足テーブルや根拠不足を明記し、追加調査へ回す |
移行・展開時のおすすめ手順
Data exploration collectionは、既存のDefender運用やKQLハンティングを一気に置き換えるものではありません。まずは、既存の調査手順をAIで補助する形で導入するのが安全です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 事前確認 | Sentinel data lake、Defender連携、必要テーブル、権限を棚卸しする | 不足テーブルと対象ワークスペースが明確になる |
| 小規模検証 | Security Reader相当のユーザーで英語プロンプトを試す | 想定したテーブル検索とKQL実行ができる |
| Entity Analyzer検証 | ユーザーとURLの代表ケースで分析結果を確認する | 不足テーブル、応答時間、SCU消費の傾向が分かる |
| 運用設計 | 標準プロンプト、承認フロー、ログ保存、並列数を決める | SOCメンバーが同じ手順で使える |
| 本番展開 | 対象チームと利用ケースを限定して開始する | コスト・上限・誤操作を監視できる |
| 拡張 | SOARやチケット連携、自動要約に広げる | 人間の判断ポイントを残したまま効率化できる |
展開時に失敗しやすいのは、検証段階で「使えそう」と判断して、すぐに全SOCメンバーへ広げるケースです。MCPツールは便利ですが、接続先データが多いほど権限とコストの管理が難しくなります。最初は、パスワードスプレー、フィッシングURL、特定ユーザーの異常サインインなど、調査テーマを絞って導入してください。
よくある疑問
Microsoft Defenderだけを使っている環境にも影響しますか？
Microsoft Defender単体で、Microsoft Sentinel data lakeやMCP対応クライアントを使っていない環境では、直接の影響は限定的です。ただし、Defender XDR、Defender for Endpoint、Defender for Identity、Defender for Cloud AppsのデータをSentinel data lakeへ連携し、Security CopilotやVisual Studio Codeなどから調査する場合は影響があります。
日本語プロンプトで使えますか？
公式の価格・制限ページでは、Microsoft SentinelのMCP toolsは英語プロンプトのみ対応とされています。日本の利用者は対象地域に含まれていますが、プロンプトは英語で標準化するのが無難です。 (Microsoft Learn)
KQLを知らなくても使えますか？
search_tablesにより、関連テーブルやスキーマを自然言語で探しやすくなります。ただし、query_lakeはKQLを実行するツールです。AIがKQL作成を支援しても、実行対象、期間、取得件数、結果の妥当性を確認する知識は必要です。
既存のハンティングクエリは不要になりますか？
不要にはなりません。むしろ、既存の信頼できるKQLや調査手順を、MCP対応クライアントやエージェントの中で再利用する設計が現実的です。公式情報でも、MCP tool collectionはテーブル検索、データ取得、エンティティ分析、インシデントトリアージ、脅威ハンティングなどの用途に分けて整理されています。 (Microsoft Learn)
管理者が次に取るべき行動
今回のMicrosoft Defender関連のセキュリティ更新として、管理者が最初に行うべきことは、機能を有効化することではなく、影響範囲を棚卸しすることです。
まず、Microsoft Sentinel data lakeを使っているか、Defender関連データがどのテーブルに入っているか、MCPツールを使えるロールが誰に付与されているかを確認してください。次に、Entity Analyzerで必要なテーブル、SCUとKQL課金、英語プロンプト、並列実行上限を確認します。そのうえで、1つの調査シナリオに絞って小さく検証し、SOCの標準手順へ組み込むのが安全です。
Data exploration collectionは、Defender運用を「画面で調べる」から「AIエージェントと一緒に調べる」方向へ進める重要な要素です。ただし、効果を出すには、データ品質、権限設計、コスト管理、AI回答の検証ルールをセットで整える必要があります。
コメント