Microsoft Defenderを利用している管理者がまず押さえるべき点は、今回の「Get started with Microsoft Sentinel MCP server」は、Defenderの検知エンジンそのものを入れ替える更新ではなく、Microsoft Sentinel MCP serverを使ってAIクライアントからセキュリティデータを自然言語で扱うための公式手順だということです。
2026年5月7日に更新されたMicrosoft Learnの公式情報では、Microsoft SentinelのMCPツール群を使い、Microsoft Sentinel data lakeやMicrosoft Defender関連のセキュリティデータに対して、自然言語で検索・調査・トリアージ・脅威ハンティングを行う流れが整理されています。管理者は、すぐに全社展開するよりも、データレイクの有効化、Defenderポータルへの移行状況、権限設計、AIクライアントの利用範囲を先に確認する必要があります。(Microsoft Learn)
Microsoft Sentinel MCP serverとは
Microsoft Sentinel MCP serverは、Model Context Protocol（MCP）を使って、AIモデルやAIエージェントからMicrosoft SentinelやMicrosoft Defenderのセキュリティデータへアクセスできるようにする仕組みです。MCPは、AIアプリケーションが外部ツールやコンテキストとやり取りするためのプロトコルで、Microsoft Sentinel MCP serverはそのサーバー側の役割を担います。(Microsoft Learn)
実務上のポイントは、管理者やSOC担当者がすべてのテーブル名やKQLの構文を覚えていなくても、AIクライアントを通じて「過去24時間のサインイン失敗を要約して」「危険度の高いユーザーを上位3人抽出して」といった形で調査を始められることです。公式ドキュメントでは、Visual Studio Code、Microsoft Security Copilot、Microsoft Copilot Studio、Microsoft Foundryなどの対応クライアントやエージェント構築基盤から、Microsoft Sentinel MCPのツール群を追加して利用する流れが示されています。(Microsoft Learn)
ただし、これは「AIにセキュリティ判断を丸投げできる機能」ではありません。MCP serverは、AIが適切なセキュリティデータやツールを呼び出すための接続口です。最終的な判断、対応優先度、インシデントのクローズ判断は、従来どおりSOC運用ルールや管理者の確認に基づいて行うべきです。
2026年5月更新で管理者が見るべき変更点
今回の公式情報で重要なのは、Microsoft Sentinel MCP serverの導入前提、利用できるツールコレクション、対応クライアント、権限要件が整理された点です。Microsoft Defenderの運用に関わる組織では、特にDefender XDR、Defender for Endpoint、Microsoft Sentinel in the Microsoft Defender portal、Security Copilotの利用状況を確認する必要があります。(Microsoft Learn)
| 確認項目 | 公式情報で示された内容 | 管理者への影響 |
|---|---|---|
| 利用目的 | 自然言語でセキュリティデータを検索、取得、分析、トリアージ、脅威ハンティングできる | SOCの初動調査やハンティングの入口がAIクライアントに広がる |
| 前提条件 | 多くのツールでMicrosoft Sentinel data lakeが必要 | データレイク未導入環境では、使える機能が限定される |
| Defender連携 | 一部のツールはMicrosoft Defender XDRまたはDefender for Endpointなどを前提にする | Defender側のインシデント、アラート、端末、ファイル、IP、脆弱性情報の扱いを確認する必要がある |
| 権限 | ツールの一覧表示や実行にはSecurity readerロールが必要。ツールによって追加ロールが必要 | 最小権限でのRBAC設計が必須になる |
| 対応先 | Security Copilot、Copilot Studio、Foundry、Visual Studio Codeなどから追加可能 | 本番利用を許可するAIクライアントを組織として決める必要がある |
| 無効化 | Sentinel MCPツールアクセスを無効化するにはカスタマーサポートへの連絡が案内されている | テナント全体での利用方針を事前に決めておくべき |
とくに注意したいのは、Microsoft Sentinel MCP serverが「サーバーを自社で構築する仕組み」ではなく、Microsoftが提供するホスト済みインターフェースとして位置付けられている点です。インフラ構築の負担は小さい一方で、どのAIクライアントから、誰が、どのセキュリティデータにアクセスできるかを厳密に管理する必要があります。(Microsoft Learn)
Microsoft Defender環境への影響範囲
Microsoft Defender管理者にとっての影響は、主に「インシデント対応」「高度なハンティング」「AIエージェント連携」「SentinelのDefenderポータル移行」の4つです。
インシデント対応とトリアージ
トリアージ用のMCPツールコレクションでは、Microsoft Defender XDR、Microsoft Defender for Endpoint、またはDefenderポータルにオンボードされたMicrosoft Sentinelが前提条件として示されています。利用シナリオには、インシデント一覧の取得、アラートや証拠の確認、Advanced huntingクエリの実行、ファイル・IP・端末・ユーザー・脆弱性情報の取得などが含まれます。(Microsoft Learn)
たとえば、SOC担当者が「直近の重大インシデントを5件出して、最も優先すべきものを理由付きで説明して」と依頼すると、AIエージェントがインシデントやアラート証拠を取得し、優先度判断の材料を提示する使い方が想定されます。
ただし、トリアージコレクションには制限があります。ゲストユーザーや委任アクセスでは利用できず、自分のホームテナントでのみ使えるとされています。また、Microsoft Sentinelユーザーはワークスペースを選択できず、Sentinel lakeのデータを直接クエリする用途ではなく、データレイクの検索にはdata explorationツールを使う必要があります。(Microsoft Learn)
Advanced huntingとKQL運用
Microsoft DefenderのAdvanced huntingを使っている組織では、MCP serverの導入によって「AIがKQL作成やテーブル探索を補助する」場面が増えます。data explorationコレクションには、関連テーブルを検索するsearch_tables、Microsoft Sentinel data lakeへKQLを実行するquery_lake、ワークスペースを一覧化するlist_sentinel_workspacesなどのツールが含まれます。(Microsoft Learn)
これは便利ですが、KQLレビューを不要にするものではありません。特に、インシデント対応で使うクエリ、検知ロジックの検証、外部チケットシステムに連携する結果は、人間がテーブル、時間範囲、フィルター条件を確認すべきです。AIが生成したクエリは、調査のたたき台として扱うのが安全です。
Microsoft Sentinel data lakeの前提確認
公式情報では、Microsoft Sentinel MCP serverの多くのツールを利用するにはMicrosoft Sentinel data lakeへのオンボードが必要とされています。さらに、ツールによってはMicrosoft Sentinel in Microsoft Defender portal、Microsoft Defender XDRまたはMicrosoft Defender for Endpoint、Microsoft Security Copilotが必要になる場合があります。(Microsoft Learn)
導入前に、次の3点を棚卸ししてください。
| 棚卸し項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| データレイク | 対象ワークスペースがMicrosoft Sentinel data lakeにオンボード済みか | 一部ワークスペースだけ有効で、期待したデータが取得できない |
| Defenderポータル | SentinelがMicrosoft Defenderポータル側で使える状態か | Azureポータル前提の運用手順が残っている |
| テーブル | 調査に必要なSigninLogs、AlertEvidence、DeviceNetworkEventsなどが存在するか | AIエージェントが回答できない原因を「AIの不具合」と誤解する |
data explorationのエンティティ分析では、ユーザーやURLをAIで分析できますが、ユーザー分析にはAlertEvidence、SigninLogs、CloudAppEvents、IdentityInfoなどのテーブルが精度に関わります。IdentityInfoは、Microsoft Defender for Identity、Defender for Cloud Apps、Defender for Endpoint P2などのライセンス条件にも関係するため、事前確認が重要です。(Microsoft Learn)
利用できるMCPツールコレクションの使い分け
Microsoft Sentinel MCP serverでは、用途ごとにツールコレクションが分かれています。管理者は「便利そうだから全部追加する」のではなく、SOCの業務シナリオごとに必要なものを選ぶべきです。(Microsoft Learn)
| ツールコレクション | 主な用途 | 向いている場面 | 注意点 |
|---|---|---|---|
| Data exploration | Sentinel data lakeのテーブル検索、KQL実行、エンティティ分析 | 長期保存データの調査、テーブル探索、初動分析 | 多くの機能でSentinel data lakeが必要。大量エクスポート用途ではなく、調査・分析向き |
| Triage | Defenderのインシデント、アラート、証拠、Advanced hunting、端末・ファイル・IP情報の取得 | SOCの初動トリアージ、脅威ハンティング、端末調査 | ホームテナント利用などの制限がある。Sentinel lakeの直接クエリには不向き |
| Security Copilot agent creation | Security Copilotエージェントの作成支援 | 定型的な調査、報告書作成、インシデント後処理の自動化 | エージェント定義や展開範囲のレビューが必要 |
| Custom MCP tools | 保存済みKQLをMCPツール化し、AIエージェントに使わせる | 決まった調査手順を安全に自動化したい場合 | ツール名・説明・パラメーター設計が曖昧だと、AIが誤ったツールを選びやすい |
実務では、最初にData explorationで小さく検証し、次にTriageでDefenderのインシデント対応へ広げ、定型化できたクエリだけをCustom MCP toolsにする流れが安全です。Custom MCP toolsは、Advanced huntingやSentinel data lakeのKQLを保存して使えるため、AIエージェントが参照できるデータの種類と量を制御しやすくなります。(Microsoft Learn)
管理者が最初に確認すべき設定
本番導入前に、次の順序で確認すると手戻りを減らせます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 利用シナリオを決める | 「誰が、どの調査で、どのデータを使うか」を1つに絞る |
| 2 | 前提サービスを確認する | Sentinel data lake、Defender XDR、Defender for Endpoint、Security Copilotの有無を確認する |
| 3 | 権限を確認する | Security Readerを基本に、必要な場合だけSecurity OperatorやSecurity Administratorを付与する |
| 4 | AIクライアントを決める | Security Copilot、Copilot Studio、Foundry、Visual Studio Codeのどれを許可するか決める |
| 5 | テストプロンプトを用意する | 実データを扱う前に、限定した時間範囲と対象で検証する |
| 6 | 結果の検証方法を決める | KQL、Advanced hunting、Defenderのインシデント画面で照合する |
| 7 | 展開範囲を制限する | まずSOCの一部メンバー、検証用ワークスペース、限定コレクションで始める |
公式情報では、MCPツールの一覧表示や実行にはSecurity readerロールが必要とされています。data explorationコレクションでは、Security Administrator、Security Operator、Security Readerのいずれかを持つユーザー、マネージドID、サービスプリンシパルがサポート対象として示されています。(Microsoft Learn)
エンティティ分析ツールを使う場合は、Security Copilot Contributorロールが必要で、Security Compute Units（SCUs）の使用状況を表示・監視するにはSecurity Copilot Ownerが必要になる場合があります。コストや利用量管理に関わるため、SOC担当者だけでなく、Microsoft 365管理者やセキュリティ管理責任者も確認すべき項目です。(Microsoft Learn)
導入手順の実務イメージ
Microsoft Defender環境でMicrosoft Sentinel MCP serverを試す場合は、次のように進めると安全です。
まずは検証用のユースケースを1つ決める
最初から「インシデント対応をすべてAI化する」と考えると、権限、データ範囲、監査、運用手順が複雑になります。初回検証では、次のような限定的なユースケースが向いています。
| ユースケース | 例 |
|---|---|
| サインイン調査 | 過去24時間のサインイン失敗を要約し、異常なユーザーやIPを確認する |
| 端末調査 | 特定端末に関連するアラート、ログオンユーザー、脆弱性を確認する |
| URL調査 | 特定URLに関する脅威インテリジェンス、クリック、通信履歴を確認する |
| インシデント要約 | 直近の重大インシデントを抽出し、優先度と確認ポイントを整理する |
公式サンプルでも、危険なユーザーの抽出、過去24時間のサインイン失敗の要約、異常に多い外向き通信を示したデバイスの特定、パスワードスプレーアラートの調査などが例示されています。(Microsoft Learn)
AIクライアントにMCPツールを追加する
Security Copilotでは、カスタムエージェントを作成したうえで、ツールカタログからMicrosoft SentinelのMCPツールを追加する流れが示されています。Copilot Studioでは、エージェントのToolsからSentinelを検索し、認証方式をMicrosoft Entra ID Integratedに設定する手順が案内されています。(Microsoft Learn)
Visual Studio Codeで利用する場合は、コマンドパレットからMCP: Add Serverを選び、HTTP方式でMCP serverのURLを追加し、少なくともSecurity readerロールを持つアカウントで認証します。開発者がVS Codeで試す場合でも、個人判断で本番テナントに接続するのではなく、管理者が許可したアカウント、ワークスペース、サーバーURLだけを使うべきです。(Microsoft Learn)
公式URLは用途別に使い分ける
代表的なMCP server URLは次のとおりです。利用するAIクライアントに追加する際は、目的に合うコレクションを選びます。(Microsoft Learn)
| 用途 | URL |
|---|---|
| Data exploration | https://sentinel.microsoft.com/mcp/data-exploration |
| Security Copilot agent creation | https://sentinel.microsoft.com/mcp/security-copilot-agent-creation |
| Triage | https://sentinel.microsoft.com/mcp/triage |
本番環境では、これらのURLを「誰でも自由に追加できる便利な接続先」として扱うのではなく、承認済み接続先として管理することが重要です。特に、SOC端末、開発者端末、外部委託先アカウント、MSSP運用端末では、利用可否を明確に分けてください。
移行・展開時に注意すべきポイント
Microsoft Sentinel MCP serverをMicrosoft Defender環境で活用するには、Defenderポータルへの移行状況も無視できません。Microsoft Learnでは、Microsoft SentinelはDefenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでのMicrosoft Sentinelサポートが終了し、Defenderポータルのみで利用可能になると案内されています。(Microsoft Learn)
Defenderポータル移行の確認
Microsoft SentinelをAzureポータル中心で運用している場合、MCP serverの検証と並行して、Defenderポータル移行計画を見直してください。既存のデータコネクタやLog Analyticsの取り込みパイプラインは基本的に継続しますが、Defenderポータル移行後は一部のデータ保存、プライバシー、CMK、コネクタ表示、インシデント相関、API応答に差分があります。(Microsoft Learn)
特に注意すべき点は次のとおりです。
| 項目 | 注意点 |
|---|---|
| データコネクタ | Defender製品系の一部コネクタはDefenderポータルのData connectorsページに表示されないが、Azureポータル側には表示される場合がある |
| インシデント相関 | Defender XDRの相関エンジンがアラートグルーピングやインシデント統合に影響する |
| 自動化ルール | インシデントタイトルを条件にしたルールは、相関による名称変更の影響を受けやすい |
| Playbook | Defenderポータル上では一部の手動実行や同期タイミングに制限がある |
| API | 統合インシデントやアラートにはMicrosoft Graph REST APIの利用が推奨される場面がある |
| IdentityInfo | Defender側のAdvanced huntingでは、テーブルレベルRBACの扱いに注意が必要 |
既存のServiceNow連携、Logic Apps、メール通知、チケット起票、SOAR連携がある場合は、MCP serverの検証前に「現在のインシデントID、URL、タイトル、説明、プロバイダー名をどのフィールドから取っているか」を確認しておくと安全です。Defenderポータル移行後は、SecurityIncidentテーブルのDescriptionフィールドやincident provider条件などが自動化に影響する可能性があります。(Microsoft Learn)
Copilot StudioとMicrosoft Foundryはプレビュー表記に注意
Copilot StudioとMicrosoft Foundry向けのMicrosoft Sentinel MCP tool利用手順には、プレビューまたはプレリリース情報であり、正式リリース前に変更される可能性がある旨が記載されています。社内手順書や顧客向けドキュメントに反映する場合は、「画面名や設定項目が変わる可能性がある」ことを前提に、定期的な見直し日を設定してください。(Microsoft Learn)
Custom MCP toolsは便利だが、設計が重要
Custom MCP toolsを使うと、Advanced huntingやMicrosoft Sentinel data lakeのKQLクエリをMCPツールとして保存し、AIエージェントが利用できるようになります。これは、エージェントがアクセスできるデータの種類と量を制御し、予測しやすいワークフローを作るうえで有効です。(Microsoft Learn)
一方で、ツール名や説明が曖昧だと、AIが意図しない場面でツールを選ぶ可能性があります。公式情報でも、ツール説明は短く、行動指向で、目的を明確に書くことが推奨されています。たとえば「ユーザーの監査ログを取得する」よりも、「指定したUPNの過去7日間のサインイン失敗とリスクイベントを取得する」のように、対象、期間、用途を絞ると運用しやすくなります。(Microsoft Learn)
開発者・SOC担当者が失敗しやすいポイント
権限を広く付けすぎる
MCP serverはAIクライアントからセキュリティデータにアクセスできる入口になるため、権限の付けすぎは大きなリスクです。検証段階では、Security Readerを基本にし、必要なツールだけを追加してください。Security OperatorやSecurity Administrator、Global Adminが必要な作業は、検証目的と作業期間を明確に区切るべきです。
取得できないデータをAIの問題と誤解する
AIが期待した回答を返さない場合、原因はAIモデルではなく、テーブル未オンボード、ワークスペース指定漏れ、ロール不足、Defenderポータル未接続、対象期間の誤りであることが少なくありません。まずlist_sentinel_workspacesで対象ワークスペースを確認し、必要なテーブルがデータレイクまたはAdvanced huntingで見えているかを確認しましょう。(Microsoft Learn)
本番データでいきなり長期間検索する
自然言語で調査できると、つい「過去1年分を全部調べて」と依頼したくなります。しかし、MCPツールは調査や分析のための取得に向いており、大量エクスポートの代替ではありません。最初は「過去24時間」「特定ユーザー」「特定インシデント」「特定端末」のように範囲を絞って使うべきです。
VS Codeのワークスペース設定を軽視する
Visual Studio CodeでMCP serverを追加する際は、すべてのVS Codeワークスペースで使えるようにするか、現在のワークスペースだけで使うかを選びます。セキュリティデータに接続するMCP serverを全ワークスペースで有効にすると、開発用・検証用・個人作業用の境界が曖昧になります。まずは検証用ワークスペースだけで使い、社内ルールが整ってから範囲を広げるのが現実的です。(Microsoft Learn)
Microsoft Defender管理者向けの実践チェックリスト
公開情報を読んだあと、管理者がすぐに確認すべき項目は次のとおりです。
| チェック項目 | 完了条件 |
|---|---|
| 利用目的を定義した | サインイン調査、端末調査、インシデント要約など、最初のユースケースが1つに絞られている |
| 対象データを確認した | 必要なDefender/SentinelテーブルがAdvanced huntingまたはSentinel data lakeで確認できる |
| 権限を確認した | 利用者に必要最小限のロールだけが付与されている |
| AIクライアントを決めた | Security Copilot、Copilot Studio、Foundry、VS Codeのうち、許可するものが明確になっている |
| 接続URLを管理した | Data exploration、Triage、Agent creationのURLを用途別に管理している |
| 検証用プロンプトを作った | 時間範囲、対象ユーザー、対象端末、期待する出力形式が明確になっている |
| 結果検証の手順を作った | KQL、Defenderインシデント画面、Advanced huntingで照合する流れがある |
| 監査と教育を準備した | AIの回答を最終判断にしないルール、機密データの扱い、誤回答時の報告先が決まっている |
| Defenderポータル移行を確認した | 2027年3月31日以降のAzureポータル非サポートを前提に移行計画がある |
Microsoft Sentinel MCP serverは、Microsoft Defenderを中心としたSOC運用にAIを取り込むための有力な入口です。一方で、便利さだけを見て展開すると、権限過多、データ範囲の誤認、移行中の自動化ルール破損、AI回答の過信といった問題が起きやすくなります。
まずは、限定したユースケースでData explorationまたはTriageコレクションを検証し、必要なテーブル、権限、プロンプト、検証手順を固めましょう。そのうえで、定型化できる調査はCustom MCP toolsやSecurity Copilotエージェントに展開していくのが、Microsoft Defender環境で安全に活用するための現実的な進め方です。
コメント