2026年5月7日に更新されたMicrosoft公式情報では、Microsoft SentinelがModel Context Protocol（MCP）をサポートし、Microsoft Sentinel data lakeやMicrosoft DefenderのセキュリティデータをAIクライアントから自然言語で扱えるようになることが示されています。結論として、管理者がまず確認すべきなのは「対象データがSentinel data lakeやDefenderに正しく連携されているか」「Entra IDの権限が最小権限で付与されているか」「MCPクライアントを本番展開してよい範囲を決めているか」の3点です。(Microsoft Learn)
この更新は、単に“AIでセキュリティ調査が便利になる”という話ではありません。Microsoft Defender XDR、Microsoft Defender for Endpoint、Microsoft Sentinel、Security Copilot、Visual Studio Codeなどを組み合わせ、インシデント調査・脅威ハンティング・エンティティ分析・Security Copilotエージェント作成を自動化しやすくする仕組みです。特にSOC運用、Defenderの高度なハンティング、Sentinel data lakeを利用している組織では、権限、データ保持、クエリ制限、リージョン、英語プロンプト対応を事前に整理しておく必要があります。(Microsoft Learn)
Microsoft SentinelのMCP対応とは
Microsoft SentinelのMCP対応とは、AIアプリケーションやエージェントが、Microsoft Sentinel data lakeやMicrosoft Defenderのセキュリティデータへ標準化された方法でアクセスできるようにする機能です。MCPはModel Context Protocolの略で、AIモデルが外部ツール、メモリ、コンテキストとやり取りするためのオープンプロトコルです。Microsoft Sentinel MCP serverは、MCPサーバーとしてセキュリティ運用向けのツール群を提供します。(Microsoft Learn)
従来、セキュリティ担当者がMicrosoft DefenderやSentinelのデータを調査するには、テーブル構造を理解し、KQLを記述し、複数のデータソースを横断して確認する必要がありました。今回のMCP対応では、対応クライアントから自然言語で「直近24時間のサインイン失敗を要約して」「このユーザーが侵害されている可能性を調べて」といった依頼を行い、AIが適切なツールやクエリを呼び出して調査を進められます。(Microsoft Learn)
ただし、これはMicrosoft Defenderのすべての作業を自動化してよいという意味ではありません。公式情報でも、人間による確認を前提とした設計であり、AIの出力はセキュリティアナリストが検証してから対応する必要があるとされています。(Microsoft Learn)
2026年5月7日の公式更新で押さえるべき変更点
今回の更新で重要なのは、Microsoft Sentinel MCP serverが「Microsoft DefenderとSentinelのデータをAIエージェントが扱うための実用的な接続口」として整理されたことです。Microsoft Learnの該当ページは2026年5月7日に更新され、MCP対応の概要、主な機能、利用シナリオ、関連ツールコレクションが説明されています。(Microsoft Learn)
主な変更点を管理者目線で整理すると、次のようになります。
| 観点 | 変更・追加されたポイント | 実務上の意味 |
|---|---|---|
| AI連携 | Sentinel MCP server経由でAIクライアントがセキュリティデータを扱える | SOC調査や脅威ハンティングを自然言語で開始しやすくなる |
| データ対象 | Microsoft Sentinel data lakeとMicrosoft Defenderのデータを活用 | Defender単体ではなく、Sentinel側のデータ連携状況も重要になる |
| ツール群 | データ探索、エージェント作成、トリアージのコレクションを提供 | 利用目的ごとに有効化する範囲を分ける必要がある |
| 認証・認可 | Microsoft EntraによるID管理とロールベースアクセス制御を利用 | Security Readerなどの権限設計が展開前の必須作業になる |
| クライアント | Visual Studio Code、Security Copilot、Copilot Studio、Foundryなどに対応 | 開発者・SOC担当者・自動化担当者で使い方が変わる |
| 制限事項 | 英語プロンプトのみ、リージョン、クォータ、プレビュー機能あり | 日本語運用ではプロンプト標準化や検証プロセスが必要 |
特に注意したいのは、MCP対応が「セキュリティ運用に特化したAI活用」である点です。一般的なチャットAIのように自由な質問へ答える用途ではなく、Microsoft Sentinel data lakeとMicrosoft Defenderにあるセキュリティデータを前提に、インシデント対応やハンティングを支援する仕組みとして理解するのが適切です。(Microsoft Learn)
影響を受ける管理者・開発者・SOC担当者
Microsoft Defenderを利用している組織でも、すべての担当者が同じ影響を受けるわけではありません。影響が大きいのは、DefenderのアラートやインシデントをSentinelやSecurity Copilotと連携し、調査・自動化・エージェント開発に活用しているチームです。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Microsoft Defender管理者 | Defender XDR、Defender for EndpointのデータがMCPツールから利用される可能性がある | Defenderポータルへのオンボード状況、ユーザー権限、監査ログ |
| Microsoft Sentinel管理者 | Sentinel data lakeとワークスペース設定がMCP利用の前提になる | data lakeの有効化、コネクタ、ワークスペースID、保持データ |
| SOCアナリスト | 自然言語でインシデント調査やエンティティ分析を行える | プロンプトの書き方、AI出力の検証手順、誤判定時のエスカレーション |
| 開発者・自動化担当者 | MCPツールを使ったSecurity Copilotエージェントやワークフローを作成できる | 利用するツールコレクション、KQL、権限、YAML定義、テスト環境 |
| セキュリティ責任者 | AIによる調査支援の利用範囲とガバナンスを決める必要がある | 利用ポリシー、監査、機密データの扱い、承認フロー |
Microsoft Defender中心の環境では、「Defenderの機能追加」とだけ見ると影響を見落とします。実際には、Sentinel data lake、Microsoft Entra ID、Security Copilot、MCP対応クライアントが関係するため、セキュリティ運用基盤全体の見直しとして扱うのが安全です。
利用できる主なMCPツールコレクション
Microsoft Sentinel MCP serverには、用途別のツールコレクションが用意されています。公式情報では、Data exploration、Security Copilot agent creation、Triageの3つが主要なコレクションとして整理されています。(Microsoft Learn)
| コレクション | 主な用途 | サーバーURL | 向いている利用シーン |
|---|---|---|---|
| Data exploration | Sentinel data lake内のテーブル検索、KQL実行、エンティティ分析 | https://sentinel.microsoft.com/mcp/data-exploration | 長期ログ調査、サインイン失敗の確認、ユーザー・URL分析 |
| Security Copilot agent creation | Security Copilotエージェントの作成 | https://sentinel.microsoft.com/mcp/security-copilot-agent-creation | インシデント後レポート作成、定型調査フローのエージェント化 |
| Triage | インシデントの優先順位付け、Defenderデータを使ったハンティング | https://sentinel.microsoft.com/mcp/triage | Defender XDRのインシデント確認、アラート証拠の分析、脆弱性調査 |
Data explorationでは、search_tablesで関連テーブルを探し、query_lakeでKQLを実行し、list_sentinel_workspacesで利用可能なワークスペースを確認できます。エンティティ分析では、ユーザーやURLに対するリスク分析も可能ですが、利用には追加のロールやデータテーブルが必要です。(Microsoft Learn)
TriageコレクションはMicrosoft Defenderとの関係が特に強い領域です。インシデント一覧、アラート、ファイル情報、IPアドレス関連アラート、デバイス情報、脆弱性、修復タスク、ユーザー関連アラートなどを扱えます。前提として、Microsoft Defender XDR、Microsoft Defender for Endpoint、またはMicrosoft SentinelがDefenderポータルにオンボードされている必要があります。(Microsoft Learn)
Microsoft Defender環境で確認すべき前提条件
Microsoft Sentinel MCP serverを使う前に、管理者は前提条件を確認する必要があります。特にMicrosoft Defender環境では、Defender側のオンボードだけでなく、Sentinel data lakeやSecurity Copilotの利用条件も関係します。
Sentinel data lakeへのオンボード
多くのMCPツールは、Microsoft Sentinel data lakeへのオンボードを前提としています。公式の開始手順でも、ほとんどのツールでSentinel data lakeが必要とされています。(Microsoft Learn)
確認すべきポイントは次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| Sentinel data lakeが有効か | 利用予定のワークスペースでdata lakeが使える状態か |
| 必要なデータが取り込まれているか | Defender、Entra ID、Cloud Apps、Endpointなどのログが欠けていないか |
| ワークスペースIDを特定できるか | 複数ワークスペース環境では、調査対象のworkspaceIdを明示できるか |
| データの鮮度が十分か | 取り込み遅延や未接続コネクタがないか |
よくある失敗は、MCPクライアントの接続だけを先に済ませ、後から「データが返らない」「別ワークスペースの結果が混ざる」と気づくケースです。複数ワークスペースを運用している場合は、list_sentinel_workspacesで対象ワークスペースを確認し、プロンプトにworkspaceIdを含める運用を標準化しましょう。(Microsoft Learn)
Defenderポータルへのオンボード
Triageコレクションを使う場合、Microsoft Defender XDR、Microsoft Defender for Endpoint、またはMicrosoft SentinelがDefenderポータルにオンボードされている必要があります。(Microsoft Learn)
Defender管理者は、次の観点で確認します。
| 確認項目 | 具体例 |
|---|---|
| Defender XDRの利用状況 | インシデント、アラート、エビデンスがDefenderポータルで確認できるか |
| Defender for Endpointの状態 | デバイス、ファイル、IP、脆弱性データが利用できるか |
| Advanced Huntingの利用可否 | KQLでDefenderテーブルを検索できるか |
| API・クォータの影響 | 高頻度な自動化で既存のAPI制限に抵触しないか |
TriageコレクションはDefenderデータの調査に便利ですが、Sentinel lakeのデータ照会そのものには向いていません。Sentinel data lakeを調べたい場合はData explorationコレクションを使い分ける必要があります。(Microsoft Learn)
権限設計で確認すべきポイント
MCP対応で最も慎重に扱うべきなのは権限です。AIエージェントがセキュリティデータを扱えるようになるため、便利さと同時に「誰が、どのデータに、どの範囲でアクセスできるか」を明確にしなければなりません。
Microsoft Sentinel MCPツールを一覧表示・実行するには、少なくともSecurity readerロールが必要です。Data explorationコレクションでは、Security Administrator、Security Operator、Security Readerのいずれかが割り当てられたユーザー、マネージドID、サービスプリンシパルのアクセスがサポートされています。(Microsoft Learn)
| 用途 | 必要・関連する権限 | 注意点 |
|---|---|---|
| MCPツールの一覧表示・実行 | Security Reader以上 | 読み取りだけでも広範なセキュリティ情報に触れる可能性がある |
| Data explorationの利用 | Security Administrator、Security Operator、Security Readerなど | data lake上のテーブルアクセス権限も確認する |
| エンティティ分析 | Security Copilot Contributor、SCU監視にはSecurity Copilot Ownerが関連 | SCU消費とコスト監視を分けて考える |
| カスタムMCPツール作成 | Security Operator、Security Admin、Global Adminなど | 保存済みKQLをエージェントが使うため、クエリ内容のレビューが必要 |
| カスタムMCPツールの実行 | Security ReaderまたはGlobal Reader | 実行者が見られるデータ範囲を確認する |
権限を広く付与してから運用で制御するのは避けましょう。最初は検証用の少人数グループに限定し、利用ログを確認した上で対象者を広げるのが現実的です。特にGlobal Adminを常用アカウントに割り当てる設計は避け、必要な作成・管理作業だけに絞って使うべきです。
開発者が知っておくべきMCPの構成
MCPは、AIアプリケーション側のホスト、接続を維持するクライアント、外部ツールやデータを提供するサーバーで構成されます。Microsoftの説明では、Visual Studio CodeがMCPホストとして動作し、Microsoft Sentinel MCP serverへ接続すると、VS CodeランタイムがMCPクライアントを生成して接続を維持する例が示されています。(Microsoft Learn)
開発者や自動化担当者は、次のように役割を分けて考えると理解しやすくなります。
| 構成要素 | 役割 | Microsoft Sentinel MCPでの例 |
|---|---|---|
| MCP host | AIアプリケーション本体 | Visual Studio Code、Security Copilot、Copilot Studioなど |
| MCP client | MCP serverとの接続を維持する部品 | ホスト内で生成される接続コンポーネント |
| MCP server | ツールやコンテキストを提供 | Microsoft Sentinel MCP server |
| Tool collection | 用途別のツール群 | Data exploration、Triage、Agent creation |
| Security data | AIが参照する根拠データ | Sentinel data lake、Microsoft Defenderデータ |
実装・展開時に重要なのは、AIモデルそのものではなく、どのツールを接続し、どのデータを参照させるかです。Microsoft Sentinel MCP serverはモデル非依存であり、最終的な出力品質は接続するクライアントやモデルにも左右されます。(Microsoft Learn)
移行・展開前に行うべきチェックリスト
Microsoft Defender環境にMCP対応を導入する場合、いきなり本番SOCへ展開するのではなく、段階的に確認するのが安全です。
| フェーズ | 確認内容 | 完了の目安 |
|---|---|---|
| 事前調査 | 利用するコレクションを決める | Data exploration、Triage、Agent creationのうち必要なものだけ選ぶ |
| データ確認 | Sentinel data lakeとDefenderのデータ連携を確認 | 主要ログ、インシデント、アラート、エンティティ情報が取得できる |
| 権限確認 | Entra IDロールとアクセス範囲を確認 | Security Readerなど最小権限で検証できる |
| クライアント確認 | VS Code、Security Copilotなどの対応状況を確認 | 最新版クライアントで認証エラーなく接続できる |
| プロンプト検証 | 代表的な調査シナリオでテストする | 同じ入力に対して期待に近い結果が安定して返る |
| 監査確認 | 誰がどのツールを使ったか追跡できる | 監査ログやクエリイベントを確認できる |
| 運用展開 | 対象チームと利用ルールを決める | AI出力のレビュー、誤判定時の対応、禁止用途を明文化する |
Microsoftは、MCPクライアントを最新の互換バージョンに保つこと、必要なツールコレクションだけを構成すること、監査ログを確認すること、広範展開前に制御された環境でテストすることを推奨しています。(Microsoft Learn)
日本語環境で特に注意すべき英語プロンプト制限
日本語圏の管理者が見落としやすいのが、Microsoft Sentinel MCP toolsが英語プロンプトのみをサポートしている点です。公式情報では、英語以外のプロンプトではパフォーマンス低下、不正確なツール選択、不完全な結果が起こり得るとされています。(Microsoft Learn)
つまり、日本語のSOC運用で使う場合も、MCPツールに渡す実行プロンプトは英語に統一するのが安全です。日本語で方針を相談し、実行プロンプトだけ英語テンプレート化する運用が現実的です。
たとえば、次のようなテンプレートを用意しておくと、属人化を防げます。
| 調査目的 | 英語プロンプト例 |
|---|---|
| サインイン失敗の確認 | Find sign-in failures in the last 24 hours and summarize key findings. |
| リスクユーザーの抽出 | Find the top three users that are at risk and explain why they are at risk. |
| 特定ユーザーの侵害確認 | Help me understand if the user <user object ID> is compromised. |
| パスワードスプレー調査 | Investigate users with a password spray alert in the last seven days and tell me if any of them are compromised. |
| インシデント優先度判断 | List the last five incidents from my tenant and assess which one is the most urgent to triage. |
日本語で「このユーザー、怪しい？」と入力するよりも、対象、期間、目的、期待する出力を英語で明示した方が結果の安定性は高くなります。公式ベストプラクティスでも、曖昧な短文より、ユーザー、期間、比較対象、調査目的を含む具体的なプロンプトが推奨されています。(Microsoft Learn)
コスト・制限・リージョンで確認すべきこと
Microsoft Sentinel MCP serverの利用では、ツールの種類によってコストや制限の考え方が異なります。Data lakeツールでは、統合MCPサーバーインターフェイス自体は追加料金なしとされていますが、データ検索・取得に使うKQLクエリの実行にはSentinel data lakeの課金モデルが関係します。エンティティ分析では、KQLクエリに加えてSecurity Compute Units（SCUs）が消費されます。(Microsoft Learn)
| 項目 | 公式情報で示されているポイント | 運用上の注意 |
|---|---|---|
| Data lakeツール | KQLでデータを検索・取得するクエリに対して従量課金 | 自動化で大量実行しないようにする |
| Entity analyzer | KQLクエリとSCU消費が関係 | SCU使用量を監視できる担当者を決める |
| Triageツール | 必要サービスにオンボード済みなら追加料金なし | 通常のAPIスロットリングやAdvanced Hunting制限は考慮する |
| MCP streaming | 120秒の制限 | 長い調査は段階的なプロンプトに分ける |
| Query window | 800文字 | 複雑な条件はKQLやカスタムツール化を検討する |
| Entity analyzer | テナントあたり1時間200回、1日500回などの制限 | Logic Appsなどで並列実行しすぎない |
| リージョン | 日本を含む複数リージョンが最適パフォーマンス対象 | 海外拠点は対象地域か確認する |
エンティティ分析では、分析結果が1時間で期限切れになるため、古い結果を再利用する運用は避けましょう。また、Logic AppsのFor Eachで多数の分析を同時実行すると遅延や制限に当たる可能性があります。公式情報では、最初は同時実行数を5程度に抑えて調整する例が示されています。(Microsoft Learn)
エンティティ分析で失敗しやすいポイント
MCP対応の中でも、ユーザーやURLのエンティティ分析は便利な一方で、前提データが不足すると期待通りに動きません。
analyze_user_entityは、Microsoft EntraオブジェクトIDを持つユーザーを対象とし、オンプレミスActive Directoryのみのユーザーはサポートされません。また、精度確保のため、AlertEvidence、SigninLogs、CloudAppEvents、IdentityInfoなどのテーブルが重要です。(Microsoft Learn)
| 失敗例 | 原因 | 対策 |
|---|---|---|
| ユーザー分析ができない | 対象がオンプレADのみのユーザー | Entra ID上のオブジェクトIDを持つユーザーか確認する |
| 結果が薄い | 必要なテーブルがdata lakeにない | Defender、Entra、Cloud Apps関連の連携を確認する |
| URL分析の根拠が不足 | EmailUrlInfoやUrlClickEventsなどがない | メール・クリック・ネットワーク関連ログを確認する |
| 分析が遅い | 多数の分析を並列実行している | 同時実行数を下げ、キューイングする |
| 古い結果を参照している | 分析結果の有効期限が切れている | 1時間以上前の結果は再実行する |
実務では、エンティティ分析を「最終判断」ではなく「初動調査の材料」として扱うのが安全です。たとえば、URLが疑わしいと表示された場合でも、Defenderのアラート、メールクリック履歴、端末通信、脅威インテリジェンス、影響ユーザーを別途確認してからブロックや隔離に進めます。
カスタムMCPツールを使うべきケース
標準のMCPツールだけでなく、保存済みKQLクエリをカスタムMCPツールとして使うこともできます。公式情報では、Advanced HuntingやSentinel data lakeのKQLクエリを保存し、セキュリティエージェントが取得・推論できるようにする方法が説明されています。なお、この機能はプレビュー情報として扱われており、正式提供前に変更される可能性があります。(Microsoft Learn)
カスタムMCPツールが向いているのは、次のような場面です。
| 使うべき場面 | 例 |
|---|---|
| 調査手順を標準化したい | パスワードスプレー調査、疑わしいPowerShell実行調査 |
| AIに参照させるデータを制限したい | 特定テーブル、特定期間、特定列だけを返す |
| KQLの品質を担保したい | レビュー済みのクエリだけをツール化する |
| エージェントの挙動を安定させたい | 毎回自由にKQLを生成させず、定型クエリを使わせる |
| 監査しやすくしたい | どの調査ツールが使われたかを追いやすくする |
カスタムツールの説明文は、AIが正しく選択できるように短く、行動指向で、目的が分かる内容にすることが推奨されています。パラメーターの細部を説明文に詰め込むのではなく、「特定ユーザーの監査ログを取得する」など、何をするツールなのかを明確にするのがポイントです。(Microsoft Learn)
本番展開で避けたい運用ミス
Microsoft DefenderとSentinel MCP serverを組み合わせると、調査のスピードは上がります。一方で、AIエージェントに広範な権限を与えたまま本番運用すると、誤った結果を過信したり、想定外のデータへアクセスしたりするリスクがあります。
避けたいミスは次のとおりです。
| 避けたいミス | 起こり得る影響 | 予防策 |
|---|---|---|
| すべてのツールコレクションを一括で有効化する | モデルが不要なツールを選び、結果が不安定になる | 業務に必要なコレクションだけ接続する |
| ワークスペースIDを指定しない | 別環境のデータを参照する、結果がぶれる | 複数ワークスペースではworkspaceIdを明示する |
| 日本語プロンプトで本番調査する | ツール選択や結果の精度が下がる可能性 | 英語テンプレートを用意する |
| AI出力をそのまま対応に使う | 誤判定による隔離、ブロック、見逃し | アナリストのレビューを必須にする |
| SCUやクエリコストを監視しない | 自動化による想定外の利用増 | 実行回数、SCU、クエリ量を定期確認する |
| プレビュー機能を本番前提で設計する | 仕様変更時に運用が止まる | 検証環境で評価し、代替手順を残す |
トラブルシューティングでは、ツールが呼び出されない、HTTP 404が出る、結果が返らない、HTTP 403が出る、ゲストユーザーのテナント認証が想定と異なるといった問題が想定されています。Microsoftは、クライアントの更新、必要なオンボード状況の確認、ワークスペースIDの指定、権限確認などを対処方法として示しています。(Microsoft Learn)
管理者が今すぐ行うべき対応
Microsoft Defender環境でMCP対応を検討する場合、最初に行うべきことは機能を有効化することではありません。自社のSOC運用において、どの調査をAIに支援させ、どこから先は人間が判断するのかを決めることです。
まずは、次の順序で進めると安全です。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | Sentinel data lakeとDefenderのオンボード状況を確認 | MCPツールが参照するデータ基盤を整える |
| 高 | Security Readerなどの権限を棚卸し | AI経由のデータアクセスを最小権限にする |
| 高 | 利用するツールコレクションを限定 | 不要な自動化や誤ったツール選択を防ぐ |
| 中 | 英語プロンプトテンプレートを作成 | 日本語環境でも安定した調査結果を得る |
| 中 | 代表的なインシデントで検証 | 本番SOCに展開できる精度か確認する |
| 中 | 監査ログとコスト監視を設定 | 利用状況と異常利用を追跡する |
| 低 | カスタムMCPツールを検討 | 定型調査やエージェント化を進める |
特に、Microsoft Defender XDRやDefender for Endpointのインシデントを日常的に扱っている組織では、Triageコレクションを小さく試す価値があります。一方、長期ログや複数データソースを横断した調査が多い組織では、Data explorationから検証すると効果を確認しやすいでしょう。
まとめ：MCP対応はDefender運用をAI化する入口だが、権限とデータ設計が前提
Microsoft SentinelのMCP対応は、Microsoft DefenderやSentinelのセキュリティデータをAIエージェントから扱いやすくする重要な更新です。自然言語で調査を始められるため、KQLに不慣れな担当者でもデータ探索やインシデント調査に参加しやすくなります。
一方で、MCP serverはセキュリティデータへの強力な入口でもあります。管理者は、Sentinel data lake、Defenderポータル、Entra IDロール、Security Copilot、クライアント互換性、リージョン、英語プロンプト、クォータをまとめて確認する必要があります。
まずは検証環境で、代表的な3つのシナリオを試すのがおすすめです。
- 直近24時間のサインイン失敗を要約する
- 重要度の高いDefenderインシデントを優先順位付けする
- 特定ユーザーまたはURLのリスクを分析する
この3つで期待どおりの結果が得られ、権限・監査・コストの管理方法を確認できれば、SOCチームや開発者向けに段階的な展開を進めやすくなります。
コメント