Microsoft Defenderで高度なハンティングやMicrosoft Sentinelを運用している管理者にとって、2026年5月14日に更新された「Create and use custom Microsoft Sentinel MCP tools」は、AIエージェントにどのセキュリティデータを参照させるかを細かく制御するための重要な公式情報です。結論から言うと、これはDefenderの検知ルールや端末保護ポリシーを直接変更する更新ではなく、保存済みKQLクエリをMicrosoft Sentinel MCPのカスタムツールとして登録し、Security CopilotなどのAIエージェントから利用できるようにする機能です。導入前に確認すべきポイントは、ライセンス、ロール、Sentinel data lake、Advanced huntingのクエリ設計、ツール説明文、展開先のAIプラットフォームです。公式ページはプレビュー機能として扱っており、一般提供前に仕様が変わる可能性がある点にも注意が必要です。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新として見るべきポイント
今回の公式情報は、Microsoft DefenderポータルのAdvanced huntingで作成・保存したKQLクエリを、Microsoft Sentinel MCPのカスタムツールとして扱えるようにする内容です。Microsoft Sentinel MCPツールを使うと、セキュリティエージェントがMicrosoft Sentinel data lakeやDefender上のセキュリティデータを参照し、調査・トリアージ・脅威ハンティングなどのワークフローで利用できます。(Microsoft Learn)
重要なのは、AIエージェントに「何でも自由に検索させる」のではなく、あらかじめ検証したKQLクエリをツール化し、参照できるデータの種類・範囲・入力値を制御できる点です。Microsoftは、カスタムMCPツールによってセキュリティエージェントがアクセスできるデータを細かく制御し、決定論的なエージェントワークフローを作れると説明しています。(Microsoft Learn)
| 確認項目 | 内容 | 管理者が見るべきポイント |
|---|---|---|
| 対象機能 | Microsoft Sentinel MCPカスタムツール | Defenderの保護設定ではなく、AIエージェントのデータ参照経路として評価する |
| 利用元 | Microsoft DefenderのAdvanced hunting | 保存済みKQLクエリや手動作成クエリの品質を確認する |
| 利用先 | Security Copilot、Copilot Studio、Microsoft Foundry、Visual Studio Codeなど | どのAIクライアントに展開するかを決める |
| 主なリスク | AIが参照できるデータ範囲の過大化 | ロール、ワークスペース、クエリ条件、パラメータを最小権限で設計する |
| 導入判断 | SOC業務の反復調査に有効 | 一度きりの調査クエリより、定型化できる調査に向く |
Microsoft Sentinel MCPカスタムツールとは
Microsoft Sentinel MCPカスタムツールは、保存済みKQLクエリをAIエージェントから呼び出せるツールとして登録する仕組みです。MCPはModel Context Protocolの略で、AIアプリケーションが外部ツールやデータソースとやり取りするためのプロトコルです。Microsoft Sentinel MCP serverは、Microsoft Sentinel data lakeやMicrosoft Defenderの構造化されたセキュリティデータとAIモデルを接続するホステッド型のインターフェースとして説明されています。(Microsoft Learn)
標準のMicrosoft Sentinel MCPツールコレクションには、データ探索、Security Copilotエージェント作成、トリアージなどの用途別コレクションがあります。カスタムMCPツールは、この標準ツールだけでは足りない組織固有の調査クエリを、AIエージェントのワークフローに組み込むための拡張手段です。(Microsoft Learn)
たとえば、次のような定型調査をツール化できます。
| ユースケース | ツール化するKQLの例 | 期待できる効果 |
|---|---|---|
| サインイン失敗の調査 | 特定ユーザーの過去24時間の失敗ログを集計 | アナリストが毎回KQLを書く手間を減らす |
| 不審な端末通信の確認 | 端末IDやホスト名を入力して外向き通信を抽出 | インシデント初動時の確認を標準化する |
| アラート関連エンティティの確認 | ユーザー、URL、IP、デバイスを軸に関連イベントを取得 | Security Copilotの回答に組織データを反映しやすくする |
| 内部不正の兆候確認 | ファイル操作、サインイン、ラベル情報などを相関 | 長期データを使った調査の再現性を高める |
影響範囲は「Defenderの設定」ではなく「AIが参照するデータ経路」
この更新をMicrosoft Defenderのセキュリティ更新として確認する場合、最初に切り分けるべきなのは影響範囲です。エンドポイントの検知設定、隔離ルール、攻撃面の縮小ルールを直接変更する機能ではありません。影響するのは、DefenderポータルのAdvanced hunting、Microsoft Sentinel data lake、Microsoft Sentinelのワークスペース、Security CopilotなどのAIエージェント連携です。
Microsoft Defenderポータルでは、Microsoft Sentinelワークスペースを接続すると、Advanced huntingからMicrosoft Sentinelデータや既存のクエリ、関数などを扱えるようになります。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされなくなり、Microsoft Defenderポータルでのみ利用可能になると案内しているため、MCPツールの導入はDefenderポータル移行計画とも合わせて考えるべきです。(Microsoft Learn)
| 影響を受ける領域 | 具体的な確認内容 |
|---|---|
| Advanced hunting | 保存済みクエリ、手動作成KQL、スキーマ、時間条件、実行結果の妥当性 |
| Microsoft Sentinel data lake | 対象データが取り込まれているか、保持期間、対象テーブルの有無 |
| Microsoft Defender XDR | Defender由来データをSentinel側でどう扱っているか |
| Security Copilot | カスタムツールコレクションの追加、プラグイン公開範囲、AllowedTools |
| 権限管理 | 作成・更新・削除できる管理者と、一覧表示・実行できる利用者の分離 |
| SOC運用 | AIの回答をそのまま判断材料にせず、証跡確認プロセスを残す |
事前条件として確認すべきライセンスとロール
Microsoft Sentinel MCPカスタムツールを作成するには、Microsoft Sentinel data lakeとMicrosoft Defenderのライセンスが必要です。また、カスタムツールを作成・更新・削除するにはSecurity Operator、Security Admin、Global Adminのいずれかのロールが必要で、ツールの一覧表示や実行にはSecurity readerまたはGlobal readerが必要とされています。(Microsoft Learn)
運用上は、Global Adminで日常運用するのではなく、作成・更新権限を持つ担当者と、実行だけを行うアナリストを分けるのが安全です。特にMCPツールはAIエージェントから呼び出されるため、従来の「人がクエリを実行する」前提よりも、参照できるデータの範囲を慎重に設計する必要があります。
| 権限 | できること | 運用上の注意点 |
|---|---|---|
| Security Operator | カスタムツールの作成・更新・削除 | SOC運用責任者や検知運用担当に限定する |
| Security Admin | カスタムツールの作成・更新・削除 | 設定変更の承認フローを設ける |
| Global Admin | カスタムツールの作成・更新・削除 | 緊急時以外の日常利用は避ける |
| Security reader | ツールの一覧表示・実行 | アナリスト向けの標準ロールとして検討する |
| Global reader | ツールの一覧表示・実行 | 広範な閲覧権限を伴うため付与範囲を絞る |
カスタムMCPツールの作成手順
公式手順では、Microsoft DefenderのAdvanced huntingページでKQLクエリを開き、「Save as tool」からMCPツールとして保存します。保存時には、名前、説明、コレクション、既定ワークスペース、必要に応じたパラメータを設定します。保存したカスタムMCPツールは、Advanced huntingページのToolsタブで確認できます。(Microsoft Learn)
| 手順 | 作業 | 実務での確認ポイント |
|---|---|---|
| KQLを作成・選定する | Advanced huntingで手動作成クエリまたは保存済みクエリを開く | 実行結果が多すぎないか、誤検知や空振りがないかを確認する |
| Save as toolを選ぶ | クエリのメニューからツール保存を開始する | 本番環境で使う前に検証用クエリで試す |
| Nameを設定する | AIモデルが識別しやすい名前を付ける | 略語や社内だけの呼称を避ける |
| Descriptionを設定する | ツールの用途を短く明確に説明する | AIが誤って選ばないよう、目的を具体化する |
| Collectionを選ぶ | 既存コレクションに追加するか新規作成する | SOC業務、脅威ハンティング、ID調査など用途別に分ける |
| Default workspaceを設定する | プロンプトにワークスペース指定がない場合のヒントを設定する | 既定値を境界として過信しない |
| Parametersを設定する | KQL内の値を{ParameterName}形式でパラメータ化する | ユーザーID、端末名、IP、期間など、入力値を明確にする |
| 保存後に確認する | Toolsタブで保存済みツールを確認する | 作成者、用途、変更履歴を運用台帳で管理する |
KQLクエリをツール化する判断基準
すべてのKQLクエリをMCPツール化すればよいわけではありません。ツール化に向いているのは、SOCやCSIRTで繰り返し使う調査クエリ、入力値を変えれば再利用できるクエリ、実行結果がAIエージェントの判断材料として扱いやすいクエリです。
反対に、範囲が広すぎるクエリ、実行結果が大量になるクエリ、担当者の意図を知らないと誤解しやすいクエリ、個人情報や機密情報を過剰に返すクエリは、ツール化前に見直すべきです。AIエージェントが自然言語で呼び出す前提では、人間がクエリ名だけを見て実行する場合よりも、説明文と戻り値の設計が重要になります。
| ツール化の判断 | 向いている例 | 避けたい例 |
|---|---|---|
| 再利用性 | 特定ユーザーのサインイン失敗を確認する | 一度だけ使った調査メモ用クエリ |
| 入力の明確さ | UserPrincipalName、DeviceId、IPAddressを指定できる | 入力値が曖昧で、AIが推測しなければならない |
| 結果の扱いやすさ | 件数、時刻、エンティティ、理由を絞って返す | 生ログを大量に返す |
| 安全性 | 必要な列だけを返す | 不要な個人情報や機密属性まで返す |
| 運用性 | SOCの手順書に組み込める | 誰が何のために使うか不明 |
ツール名と説明文はAIが選びやすい形にする
Microsoftは、カスタムツールの名前と説明文が、AIモデルが特定タスクに適したツールを識別・選択するうえで重要だと説明しています。説明文は短く、行動を示す表現にし、パラメータの詳細ではなくツールの目的を中心に書くことが推奨されています。前提となる別ツールの実行が必要な場合だけ、ワークフロー上のヒントを簡潔に入れるのがよいとされています。(Microsoft Learn)
日本語環境で運用する場合でも、当面はツール名や説明文、プロンプトの主要部分を英語で設計することをおすすめします。Microsoft Sentinel MCP serverは英語プロンプトのみをサポートすると説明されており、英語以外ではツール選択や結果の精度が低下する可能性があるためです。(Microsoft Learn)
| 悪い例 | 問題点 | 改善例 |
|---|---|---|
RiskCheck | 何を確認するツールか分からない | retrieve_user_signin_risk_events |
SOC query 01 | AIにも人にも用途が伝わらない | Retrieve recent failed sign-ins for a specified user |
Get logs | 対象データが広すぎる | Retrieve Defender alert evidence for a specified device |
Investigate everything about user | 返す情報が広すぎ、過剰取得につながる | Summarize risky sign-in activity for a specified user in the last 24 hours |
説明文は、次のような形にすると実用的です。
Retrieves recent failed sign-in events for a specified user and summarizes source IPs, timestamps, and failure reasons.
この説明なら、対象が「サインイン失敗」、入力が「特定ユーザー」、戻り値の観点が「IP、時刻、失敗理由」だと分かります。パラメータ名の説明はスキーマ側に寄せ、説明文では「何の調査で使うか」を明確にします。
パラメータ設計で失敗しやすいポイント
KQL内の固定値をパラメータ化すると、AIエージェントが会話の文脈に応じて値を入れられるようになります。公式手順では、KQL内の一部の値を{ParameterName}形式に変換し、パラメータ名と説明を追加できるとされています。(Microsoft Learn)
実務では、パラメータを増やしすぎるとAIが値を誤って補完する可能性があります。最初は、ユーザーID、端末ID、IPアドレス、期間など、調査対象を限定するために不可欠な値に絞るのが安全です。
| パラメータ | よい使い方 | 注意点 |
|---|---|---|
UserPrincipalName | 特定ユーザーのサインインやアラートを調査する | 表示名ではなくUPNやObject IDを要求する |
DeviceId | 端末単位でアラートや通信を確認する | ホスト名とDeviceIdの混同に注意する |
IPAddress | 不審な接続元・接続先を調べる | IPv4、IPv6、プライベートIPの扱いを明確にする |
TimeRange | 直近24時間、7日間などを切り替える | KQL内の固定期間と矛盾しないようにする |
Workspace | 複数ワークスペース環境で対象を指定する | 既定ワークスペースだけに頼らない |
特に期間指定は注意が必要です。Microsoft DefenderのAdvanced huntingでは、Defender XDRテーブルをMicrosoft Sentinelにストリーミングしている場合、クエリ内で時間を固定するより、クエリエディターの時間フィルターを使うべきケースがあると説明されています。ツール化するKQLでも、時間条件をどこで制御するかを事前に決めておくべきです。(Microsoft Learn)
Security Copilotへ展開する場合の注意点
Security CopilotでカスタムMCPツールコレクションを使う場合は、ツールコレクションをプラグインとして追加し、カスタムエージェントに組み込みます。Microsoftの手順では、YAMLファイルでコレクション名、説明、MCPエンドポイント、TokenScope、UseStreamableHttp、UsePluginAuth、AllowedTools、TimeoutInSecondsなどを定義し、Security Copilotポータルからカスタムプラグインとして追加します。(Microsoft Learn)
展開時に特に重要なのは、AllowedToolsです。AllowedToolsにはSecurity Copilotから利用を許可するツール名をカンマ区切りで指定します。これにより、MCPサーバー側に存在するツールのうち、Security Copilotで使わせたいものだけを制限できます。(Microsoft Learn)
また、Security CopilotのMCPプラグインには既知の制限があります。MCPサーバー側でツールが追加・編集されても、Security Copilotが動的に変更を反映するわけではなく、新しいツールを反映するにはYAMLファイルの再アップロードが必要です。ツール入力はプリミティブ型のみサポートされる点にも注意が必要です。(Microsoft Learn)
| 展開項目 | 確認すべき内容 |
|---|---|
| プラグイン公開範囲 | 自分だけに公開するか、組織全体に公開するか |
| AllowedTools | 本当に使わせたいツールだけを列挙しているか |
| TimeoutInSeconds | 長時間実行されるKQLを前提にしていないか |
| UseStreamableHttp | 推奨される通信方式で設定しているか |
| YAML再アップロード | ツール追加・変更時の更新手順を運用に組み込んでいるか |
| カスタムエージェント | どのエージェントがどのツールを使えるか明確か |
Microsoft Sentinel data lakeとDefenderポータル移行の確認
多くのMicrosoft Sentinel MCPツールは、Microsoft Sentinel data lakeへのオンボードを前提としています。Microsoft Sentinel MCP serverの開始手順でも、多くのツールでSentinel data lakeへのオンボードが必要だと説明されています。(Microsoft Learn)
加えて、Microsoft SentinelはDefenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでサポートされない予定です。MCPカスタムツールの検証を始めるなら、単独機能として試すのではなく、Sentinel運用をDefenderポータルへ移す計画とセットで進めるのが現実的です。(Microsoft Learn)
移行時は、次の点を確認してください。
| 確認項目 | 見落としやすいポイント |
|---|---|
| ワークスペース接続 | Defenderポータルに対象ワークスペースが接続されているか |
| テーブルの見え方 | Advanced huntingのSchemaタブで必要なテーブルを確認できるか |
| 既存クエリ | Sentinel側の保存済みクエリをDefender側で使えるか |
| データ保持 | 調査に必要な期間のデータが保持されているか |
| 補助ログ | Sentinel data lakeオンボード後のAdvanced huntingで補助ログテーブルの扱いが変わる点を確認する |
| アナリスト教育 | Azureポータル前提の手順書をDefenderポータル前提に更新する |
管理者が導入前に確認すべきチェックリスト
本番環境でMicrosoft Sentinel MCPカスタムツールを使う前に、最低限次の項目を確認しておくと、権限過多や誤ったAI回答のリスクを下げられます。
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | Microsoft Sentinel data lakeとMicrosoft Defenderの前提を満たしているか |
| ロール | 作成者、更新者、実行者の権限が分離されているか |
| データソース | Sentinel data lakeに必要なデータが取り込まれているか |
| KQL品質 | クエリが検証済みで、想定通りの結果を返すか |
| 戻り値 | 必要な列だけを返し、結果件数が多すぎないか |
| パラメータ | AIが誤入力しにくい名前と説明になっているか |
| ツール説明文 | 英語で短く、用途が明確に書かれているか |
| コレクション | 用途別に整理され、不要なツールが混在していないか |
| Security Copilot設定 | AllowedToolsで利用範囲を制限しているか |
| 変更管理 | ツール追加・変更時の承認、テスト、再展開手順があるか |
| 監査 | 誰がどのツールを作成・変更したかを追跡できるか |
| 教育 | アナリストがAI回答を検証する手順を理解しているか |
開発者・SOCエンジニア向けの設計ポイント
開発者やSOCエンジニアが重視すべきなのは、AIに任せる範囲を広げることではなく、調査の再現性を上げることです。カスタムMCPツールは、自然言語プロンプトからKQLを毎回生成させるより、検証済みKQLをツールとして呼び出せる点に価値があります。
実装時は、次の考え方で設計すると運用しやすくなります。
| 設計観点 | 推奨される考え方 |
|---|---|
| 1ツール1目的 | ひとつのツールに複数の調査目的を詰め込まない |
| 入力は少なく | AIが補完すべき値を減らす |
| 出力は要約しやすく | タイムスタンプ、エンティティ、理由、件数を返す |
| 列を絞る | 不要なフィールドや機密性の高い列を返さない |
| 英語名を使う | MCPの英語プロンプト前提に合わせる |
| 検証用と本番用を分ける | テスト中のツールを本番エージェントに混ぜない |
| バージョン管理する | クエリ変更時に旧版との差分を残す |
たとえば「ユーザーが侵害されているか調べる」という広すぎるツールより、「指定ユーザーの直近24時間の失敗サインインを取得する」「指定ユーザーに関連する高重大度アラートを取得する」「指定ユーザーの通常と異なる国からのサインインを取得する」のように分割した方が、AIエージェントが誤った文脈で使いにくくなります。
失敗しやすい運用パターン
Microsoft Sentinel MCPカスタムツールは便利ですが、設計を誤るとAIが参照できるデータ範囲が広がりすぎます。特に次のパターンは避けるべきです。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| 便利だから広いクエリを登録する | 大量データを返し、AI回答が曖昧になる | 調査目的ごとにクエリを分ける |
| ツール説明文が抽象的 | AIが誤ったツールを選ぶ | 動詞、対象、用途を明記する |
| Global Adminで作業する | 運用権限が過大になる | Security OperatorやSecurity Adminに限定する |
| 既定ワークスペースを過信する | 意図しないデータ参照につながる | プロンプトやパラメータで対象を明示する |
| YAML更新を忘れる | Security Copilot側に新ツールが反映されない | ツール更新後の再アップロード手順を標準化する |
| 日本語プロンプトだけで運用する | ツール選択や回答品質が不安定になる可能性がある | 重要なツール名・説明・運用プロンプトは英語で整備する |
今すぐ取るべき対応
Microsoft Defender環境でMicrosoft Sentinel MCPカスタムツールを検討する場合、最初にやるべきことは新機能を有効化することではありません。まず、現在のAdvanced huntingクエリの棚卸しを行い、繰り返し使う調査クエリを選別してください。そのうえで、対象データ、必要ロール、戻り値、パラメータ、Security Copilotへの展開範囲を決めます。
小さく始めるなら、次の順番が現実的です。
| ステップ | 作業内容 |
|---|---|
| 1 | SOCで頻繁に使うKQLクエリを3〜5本選ぶ |
| 2 | クエリ結果が過剰でないか、必要列だけを返しているか確認する |
| 3 | ユーザー、端末、IP、期間などのパラメータを整理する |
| 4 | 英語のツール名と説明文を作る |
| 5 | Advanced huntingでSave as toolを使い、検証用コレクションに保存する |
| 6 | Toolsタブで確認し、実行結果をテストする |
| 7 | Security Copilotなどに展開する場合はAllowedToolsで対象ツールを絞る |
| 8 | 本番利用前に権限、変更管理、アナリスト向け手順書を整備する |
今回の更新は、Microsoft DefenderとMicrosoft SentinelをAIエージェント時代のSOC運用に近づけるための機能です。ただし、効果を出すには「AIに何を聞くか」よりも、「AIがどの検証済みデータにアクセスできるか」を設計する必要があります。まずは反復頻度が高く、結果が明確で、権限リスクが低いKQLからツール化し、段階的にMicrosoft Sentinel MCPカスタムツールの運用範囲を広げるのが安全です。
コメント