Microsoft Defender環境でAIエージェントやVS Codeからインシデント調査・脅威ハンティングを行う場合、2026年5月14日に更新された「Microsoft Sentinel MCP server pricing, limits, and availability」は必ず確認しておきたい公式情報です。結論から言うと、Microsoft Sentinel MCP serverの統合インターフェイス自体は一部ツールで追加料金なしとされていますが、データ取得に使うKQLクエリ、Entity analyzerの処理、Advanced Hunting APIの利用制限などは別途考慮が必要です。特にMicrosoft Defender XDRやMicrosoft Defender for EndpointをDefenderポータルにオンボードしている組織では、トリアージツールの利用可否、権限、クエリ制限、英語プロンプトのみ対応という点を展開前に確認しておくべきです。(Microsoft Learn)
この記事では、Microsoft Sentinel MCP serverの価格、制限、提供地域に関する公式情報をもとに、Microsoft Defender管理者・SOC担当者・開発者が確認すべき変更点と実務上の注意点を整理します。
Microsoft Sentinel MCP serverとは何か
Microsoft Sentinel MCP serverは、Model Context Protocol（MCP）を使って、AIモデルや対応クライアントからMicrosoft SentinelやMicrosoft Defenderのセキュリティデータを扱えるようにする仕組みです。
Microsoftの説明では、Microsoft SentinelのMCP対応は、複数のシナリオ別ツールコレクションを統合サーバーインターフェイスとして提供し、自然言語によるセキュリティデータの問い合わせや、セキュリティエージェントの構築を支援するものです。インフラを自前で展開するのではなく、Microsoft Entra IDを使うホスト型インターフェイスとして提供される点が特徴です。(Microsoft Learn)
Microsoft Defenderとの関係で重要なのは、MCP serverが単なるSentinel専用機能ではなく、Microsoft Defender XDRやMicrosoft Defender for Endpointのデータを使ったトリアージ、Advanced Hunting、ファイル・IP・デバイス・脆弱性調査にも関わる点です。たとえば、トリアージツールではインシデント、アラート、Advanced Huntingテーブル、Defender for Endpointのファイル情報、デバイス情報、脆弱性、修復タスクなどを扱えます。(Microsoft Learn)
2026年5月14日更新で押さえるべきポイント
今回の公式情報で管理者が最初に見るべきポイントは、価格そのものよりも「どの操作が課金や制限の対象になるか」です。
| 確認項目 | 公式情報の要点 | 実務上の見方 |
|---|---|---|
| 統合MCP serverインターフェイス | Microsoft Sentinel data lake tierでは追加料金なし | 接続するだけで定額課金が増えるとは限らないが、データ取得処理は別 |
| Data lake tools | KQLでMicrosoft Sentinel data lakeから検索・取得する処理に対して課金 | 調査プロンプトを多用するとクエリコストが増える可能性 |
| Entity analyzer | data lake上のKQLクエリとSCUが課金対象 | 自動分析を大量実行する前にコスト監視が必要 |
| Triage tool | 必要な製品・サービスにオンボード済みなら追加料金なし | Defender側のAPI制限や既存権限の影響を受ける |
| 提供地域・言語 | 英語プロンプトのみ対応。日本は利用対象地域に含まれる | 日本語での運用手順を作る場合も、実行プロンプトは英語前提で設計 |
公式ページでは、一部情報がプレリリース製品に関するものであり、正式リリース前に変更される可能性があるとも明記されています。運用設計や社内手順書に反映する場合は、価格・制限・対応クライアントを固定仕様として扱わず、定期的な見直しを前提にしてください。(Microsoft Learn)
価格と課金の考え方
MCP serverのインターフェイス自体は追加料金なしでも、クエリは無料とは限らない
Microsoft Sentinel data lake toolsでは、統合MCP serverインターフェイスは追加料金なしで提供されます。ただし、Microsoft Sentinel data lakeからKQLクエリでデータを検索・取得するツール呼び出しには、data lakeの課金モデルが関係します。Microsoftの説明では、data lakeの課金モデルは取得クエリに対する従量課金です。(Microsoft Learn)
つまり、管理者が見るべきなのは「MCP serverを追加したか」だけではありません。次のような利用パターンがコストに影響します。
| 利用例 | コスト影響の考え方 |
|---|---|
| アナリストが自然言語で長期ログを頻繁に検索する | data lakeへのKQL実行回数や取得量が増える |
| AIエージェントが調査のたびに複数テーブルを横断検索する | 1回のプロンプトでも複数クエリに分解される可能性がある |
| Entity analyzerでURL、ドメイン、ユーザーを大量分析する | KQLクエリに加え、SCU課金の対象になる |
| トリアージツールでインシデントやDefender情報を参照する | 追加料金なしとされるが、API制限やAdvanced Hunting制限の確認が必要 |
コスト管理の観点では、初期展開時に「どのチームが、どのツールを、どの頻度で使うか」を決めておくことが重要です。特にSOCで複数人が同時に使う場合、自然言語プロンプトは便利な一方で、実際にはKQLクエリやAPI呼び出しとして実行されるため、利用状況の可視化が欠かせません。
Entity analyzerは便利だが、実行回数と保持時間に注意
Entity analyzer toolは、Microsoft Sentinel data lakeのデータを使って、URL、ドメイン、ユーザーなどのエンティティを分析するツールです。公式情報では、KQLクエリに加え、普及度、脅威インテリジェンス、関係性にもとづくリスク分析を提供するためのSecurity Compute Units（SCU）が課金対象になるとされています。(Microsoft Learn)
また、Entity analyzerにはテナント単位の実行制限があります。
| 制限項目 | 上限 |
|---|---|
| 1時間あたりの総実行数 | 200回 |
| 1日あたりの総実行数 | 500回 |
| 5分あたりの同時実行数 | 約15回 |
| 分析結果の有効期間 | 1時間 |
分析結果は1時間利用可能ですが、期限切れ後は再度クエリを実行する必要があります。(Microsoft Learn)
実務では、Entity analyzerを「すべてのアラートに対して自動実行する」よりも、「重大度High以上」「外部通信を伴うURL」「VIPユーザーに関係するサインイン異常」など、対象を絞って使う方が現実的です。上限に達すると、緊急時に必要な分析が回らなくなる可能性があります。
Microsoft Defender環境への影響範囲
Defenderポータルにオンボード済みかが前提になる
トリアージツールコレクションを使うには、Microsoft Defender XDR、Microsoft Defender for Endpoint、またはMicrosoft SentinelがDefenderポータルにオンボードされている必要があります。(Microsoft Learn)
そのため、Microsoft Defender管理者は、まず次の点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Defender XDRの利用状況 | 対象テナントでDefender XDRが有効か |
| Defender for Endpointのオンボード | デバイスがDefender for Endpointに登録され、データが蓄積されているか |
| Sentinel in Defender portal | SentinelをDefenderポータル側で利用しているか |
| Advanced Hunting | 対象ユーザー・アプリがAdvanced Huntingを実行できるか |
| 権限 | ユーザーやアプリが必要最小限の権限でツールを利用できるか |
特に開発者がAIエージェントを作る場合、ローカルのVS Codeや対応プラットフォームから接続できても、実際に取得できるデータは権限とオンボード状況に左右されます。接続テストだけで「展開完了」と判断しないようにしましょう。
Advanced Huntingの制限はそのまま影響する
トリアージツールのうちAdvanced Hunting APIを呼び出すものは、既存のAdvanced Huntingのクォータやサービス制限に従います。公式情報でも、通常のAPIスロットリングに加えて、Advanced Hunting APIを呼び出すツールは既存のAdvanced Huntingクォータとサービス制限に縛られると説明されています。(Microsoft Learn)
Microsoft Defender XDRのAdvanced Huntingには、クエリリソースの消費状況を確認するレポートがあります。このレポートでは、過去30日間に各ハンティングインターフェイスで実行されたクエリのCPUリソース消費を確認でき、リソースの大きいクエリやスロットリングの原因調査に役立ちます。(Microsoft Learn)
MCP経由の利用が増えると、ポータルで手動実行するクエリだけでなく、AIエージェントやAPI経由のクエリも運用負荷になります。展開後は、Advanced Huntingのクエリリソースレポートで「High」になっているクエリや、失敗・スロットリングが発生しているクエリを定期的に確認してください。
MCPツールごとの主な制限
Microsoft Sentinel MCP serverでは、ツールの種類によって制限が異なります。特にMicrosoft Defender管理者が意識すべきなのは、data lake tools、Entity analyzer、triage toolの違いです。
| ツール種別 | 主な用途 | 主な制限・注意点 |
|---|---|---|
| Data lake tools | 長期セキュリティデータの探索、KQL実行、テーブル検索 | MCP streamingは120秒、ツールのquery windowは800文字 |
| Entity analyzer | URL、ドメイン、ユーザーなどのリスク分析 | 1時間200回、1日500回、結果は1時間で期限切れ |
| Triage tool | インシデント整理、アラート確認、Defender情報取得、Advanced Hunting | 通常のAPIスロットリングとAdvanced Hunting制限が適用 |
| Data lake service全体 | テーブル管理、取り込み、KQL実行 | ワークスペース数、クエリタイムアウト、結果サイズなどの制限あり |
Data lake MCP tools固有の制限として、MCP streamingは120秒、ツールのquery windowは800文字です。長い日本語の調査依頼をそのまま英訳して投入すると、意図がぼやけるだけでなく、query windowに収まりにくくなる可能性があります。(Microsoft Learn)
運用では、1つの大きなプロンプトにすべてを詰め込むよりも、次のように分割すると安定しやすくなります。
| 悪い例 | 改善例 |
|---|---|
| 「過去180日の全ログから怪しいユーザーと端末とURLを全部調べて、優先度を付けて」 | 「直近7日のHigh severity incidentsを5件取得」「対象ユーザーのサインイン失敗を確認」「関連端末の脆弱性を確認」のように段階化 |
| テーブル名を指定せず広すぎる調査を依頼 | 先にテーブル概要やスキーマを確認してからKQLを実行 |
| 大量結果を前提にした抽出 | 条件、期間、件数を絞って調査 |
Data lake service側の制限も見落とさない
Microsoft Sentinel MCP serverを使う場合でも、Microsoft Sentinel data lakeそのもののサービス制限は適用されます。公式のdata lake service limitsでは、たとえばテナントあたり20ワークスペース、オンボード時のテーブルセットアップや新規テーブルセットアップ、データ階層切り替えに90〜120分程度の遅延があることが示されています。(Microsoft Learn)
KQLクエリについては、Microsoft Sentinel data lakeのlake tierで次のような制限があります。
| 項目 | 制限 |
|---|---|
| 同時インタラクティブクエリ | 45回/分 |
| クエリ結果データ | 64MB |
| クエリ結果行数 | 500,000行 |
| クエリタイムアウト | 4分 |
| クエリ可能な期間 | 保持設定に応じて最大12年 |
また、KQLジョブはテナントあたり同時実行3件、ジョブクエリ実行タイムアウト1時間、Enabled状態のジョブはテナントあたり100件とされています。(Microsoft Learn)
これらは「MCPだから無制限にAIで調査できる」という誤解を避けるために重要です。AIエージェントが裏側でKQLを実行する場合でも、クエリ結果のサイズ、タイムアウト、同時実行数を超えれば期待した結果は得られません。
提供地域と言語対応の注意点
Microsoft Sentinel MCP toolsは、英語プロンプトのみをサポートします。利用に適した国・地域として、Australia、Canada、Europe、India、Japan、Norway、Southeast Asia、Switzerland、United Kingdom、United Statesが挙げられており、日本は対象に含まれています。(Microsoft Learn)
日本企業で特に注意したいのは、「日本リージョンで使える」ことと「日本語プロンプトで安定運用できる」ことは同じではない点です。公式には英語プロンプトのみ対応とされているため、SOCの運用手順では、英語プロンプトのテンプレートをあらかじめ用意しておくと失敗を減らせます。
たとえば、次のようなテンプレートを標準化するとよいでしょう。
| 調査目的 | 英語プロンプト例 |
|---|---|
| 直近インシデントの優先度確認 | List the last five incidents from my tenant and assess which one is the most urgent to triage. |
| アラート証跡の確認 | Provide the alerts for this incident and analyze the alert evidence for maliciousness. |
| Advanced Huntingの準備 | Fetch the available advanced hunting tables and show the schema for the relevant tables. |
| ユーザー侵害の確認 | Help me understand if the user <user object ID> is compromised. |
英語プロンプトをテンプレート化しておけば、日本語の一次対応手順書と組み合わせても、実際のMCP呼び出しは公式仕様に沿った形で運用できます。
管理者が展開前に確認すべき設定
Microsoft Sentinel MCP serverをMicrosoft Defender環境で使う前に、管理者は次の順序で確認すると安全です。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | 対象サービスのオンボード状況を確認 | Defender XDRやDefender for Endpointが対象テナントで使える前提を見落とす |
| 2 | Microsoft Sentinel data lakeの利用可否を確認 | data lake未利用のままdata explorationやEntity analyzerを試す |
| 3 | ユーザー・アプリの権限を確認 | 接続はできるがデータ取得できない |
| 4 | Advanced Huntingの利用制限を確認 | AIエージェントのクエリでスロットリングが発生する |
| 5 | コスト監視の担当を決める | 自然言語調査の裏でKQLクエリが増える |
| 6 | 英語プロンプトを標準化する | 日本語で依頼して期待通りに動かない |
| 7 | 本番前に少人数で検証する | SOC全体へ展開後に制限・権限・コスト問題が見つかる |
Microsoft Sentinel MCP toolsを一覧表示・実行するにはSecurity Readerロールが必要とされ、トリアージツールでは既存の権限で許可されたツールを使用できると説明されています。(Microsoft Learn)
Data exploration collectionについては、Security Administrator、Security Operator、Security Readerのいずれかのロールが割り当てられたユーザー、マネージドID、サービスプリンシパルでサポートされるとされています。(Microsoft Learn)
権限設計では、便利だからといって広い管理者権限を与えるのではなく、調査担当、ハンティング担当、エージェント開発担当で必要な範囲を分けるべきです。特にサービスプリンシパルやマネージドIDを使う場合、退職者や担当変更に左右されない一方で、過剰権限のまま長期間残りやすい点に注意してください。
移行・展開時に注意したいポイント
Customer-Managed Keysを使っている組織はdata lake利用可否を確認する
Microsoft Sentinel data lakeのサービス制限では、Customer-Managed Keys（CMK）を使ってデータ暗号化している組織に対して重要な注意が示されています。CMKはMicrosoft Sentinel data lakeに保存されるデータではサポートされず、CMKを適用しているSentinelワークスペースはdata lakeエクスペリエンスからアクセスできないとされています。(Microsoft Learn)
これは、金融、公共、医療、グローバル企業など、暗号化ポリシーが厳しい組織で特に重要です。MCP活用を前提にdata lakeへ移行・展開する場合は、セキュリティ部門だけでなく、法務、リスク管理、クラウド基盤チームとも事前に確認してください。
既存SOC運用をそのままAI化しない
MCP serverを導入すると、インシデント確認や脅威ハンティングを自然言語で進めやすくなります。しかし、既存の手順をそのままAIに置き換えると、次のような問題が起きやすくなります。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| 調査結果が毎回ばらつく | プロンプトが担当者ごとに違う | 重大度別・調査対象別の標準プロンプトを用意する |
| クエリ制限に達する | 広すぎる期間・条件で繰り返し実行する | 期間、件数、対象テーブルを絞る |
| コストが読みにくい | 自然言語の裏で複数クエリが実行される | テスト期間中に実行回数とクエリ内容を記録する |
| 権限エラーが多い | ユーザー・アプリの権限設計が未整理 | ロールと実行可能ツールを一覧化する |
| 日本語手順と英語実行の間で混乱する | 公式対応が英語プロンプトのみ | 日本語説明＋英語プロンプトの運用テンプレートを作る |
AIエージェントの導入で重要なのは、作業を丸投げすることではなく、調査プロセスを分解して再現性を高めることです。たとえば「インシデント一覧取得」「関連アラート確認」「証跡エンティティ確認」「Advanced Hunting実行」「影響端末確認」「修復タスク確認」という流れをテンプレート化すれば、担当者の経験差を減らしやすくなります。
開発者が確認すべき実装上の注意点
AIエージェントや社内ツールからMicrosoft Sentinel MCP serverを使う開発者は、機能の接続よりも「安全に失敗できる設計」を重視してください。
クエリとプロンプトを無制限に連鎖させない
MCPはAIモデルが外部ツールを呼び出す仕組みです。便利な一方で、エージェントに自由度を持たせすぎると、必要以上にクエリを実行したり、同じ調査を繰り返したりする可能性があります。
開発時は、次のような制御を入れると安全です。
| 制御項目 | 実装例 |
|---|---|
| 実行回数 | 1インシデントあたりのツール呼び出し回数を上限設定する |
| 対象期間 | 初期調査は24時間または7日などに制限する |
| 対象件数 | インシデント・アラートの取得件数に上限を設ける |
| クエリ確認 | 高コストが予想されるKQLは実行前に確認フローを入れる |
| ログ保存 | プロンプト、実行ツール、KQL、結果件数、エラーを記録する |
| 権限分離 | 調査用IDと管理操作用IDを分ける |
特にRunAdvancedHuntingQueryのようにKQLを実行するツールでは、事前にテーブル概要やスキーマを取得してからクエリを組み立てる流れが推奨されています。トリアージツールの公式説明でも、Advanced Huntingテーブルの概要取得、詳細スキーマ取得、クエリ実行という流れが示されています。(Microsoft Learn)
レート制限・タイムアウト時のリトライ設計を入れる
MCP streamingの120秒制限、data lakeのクエリタイムアウト、Advanced Huntingのスロットリングは、実装側で考慮すべき制約です。
単純にリトライを連打すると、制限にさらに引っかかる可能性があります。リトライする場合は、対象期間を狭める、取得件数を減らす、クエリ条件を見直すなど、負荷を下げる方向で再実行してください。
たとえば、最初のクエリで過去30日を対象にして失敗した場合、次は過去7日、過去24時間のように範囲を狭める設計が現実的です。障害時に「再試行しました」だけを表示するのではなく、「期間を短縮して再実行してください」「条件を追加してください」といった操作可能なメッセージを返すと、運用現場で使いやすくなります。
管理者向けチェックリスト
本番展開前に、以下を確認してください。
| チェック項目 | 確認済み |
|---|---|
| Microsoft Defender XDR、Defender for Endpoint、Sentinelのオンボード状況を確認した | |
| Microsoft Sentinel data lakeの利用可否と対象ワークスペースを確認した | |
| CMK利用環境でdata lakeアクセスに問題がないか確認した | |
| Security Reader、Security Operator、Security Administratorなどのロール設計を整理した | |
| サービスプリンシパルやマネージドIDの権限を最小化した | |
| Advanced Huntingのクエリリソースレポートを確認する担当を決めた | |
| Entity analyzerの実行対象と上限を決めた | |
| 英語プロンプトの標準テンプレートを用意した | |
| 料金・制限が変更される可能性を踏まえ、公式情報の確認サイクルを決めた | |
| 少人数のパイロット運用で実行回数、失敗率、クエリ負荷を測定した |
このチェックリストを満たしてからSOC全体に展開すると、権限不足、クエリ制限、想定外のコスト、プロンプト品質のばらつきといった問題を減らせます。
まず何から対応すべきか
Microsoft Defender管理者が最初に取るべき行動は、MCP serverをすぐ全社展開することではありません。まず、対象テナントでMicrosoft Defender XDR、Defender for Endpoint、Microsoft Sentinel data lake、Advanced Huntingがどの状態にあるかを棚卸ししてください。
そのうえで、少人数のSOC担当者または開発者に限定して、次の順序で検証するのが現実的です。
- インシデント一覧取得やアラート確認など、低リスクなトリアージ操作から試す
- Advanced Huntingのクエリ実行回数、失敗、スロットリングを確認する
- Entity analyzerは対象を絞って実行し、上限とコスト感を確認する
- 英語プロンプトを標準化し、日本語の運用手順に組み込む
- 本番展開前に権限、ログ、監査、コスト監視を整える
Microsoft Sentinel MCP serverは、Microsoft Defender環境の調査・ハンティングを効率化できる有力な仕組みです。一方で、価格、クエリ制限、地域、言語、権限、data lakeの前提を理解せずに展開すると、現場で使いづらいAI連携になってしまいます。
2026年5月14日時点の公式情報では、MCP serverの価値は「AIで何でも自動化できる」ことではなく、Microsoft DefenderとSentinelのデータを、権限と制限の範囲内で安全に活用しやすくすることにあります。まずは小さく検証し、利用パターン・コスト・クエリ負荷を見ながら段階的に展開するのが最も安全です。
コメント