2026年4月30日のMicrosoft Defender関連ドキュメント更新「Update triage doc date and remove preview note」は、セキュリティ運用担当者にとって“すぐ設定を変えるべき重大な仕様変更”というより、Microsoft Sentinel MCP serverのtriage collectionを本番運用に近い前提で見直すためのシグナルとして確認すべき更新です。
今回の変更では、該当ドキュメントの見出しから「preview」表記が外され、プレリリース警告ブロックが削除されました。一方で、周辺ドキュメントにはMicrosoft Sentinel MCP server全体に関するプレビュー表記や制限情報が残っています。そのため、security admins、compliance teams、enterprise IT readersは、「GAになった」と早合点せず、対象機能、前提条件、権限、監査、料金、制限を切り分けて確認することが重要です。(GitHub)
Microsoft Defenderの公式ドキュメント更新で何が変わったか
今回の更新対象は、MicrosoftDocsのdefender-docsリポジトリにあるsentinel/datalake/sentinel-mcp-triage-tool.mdです。コミットタイトルは「Update triage doc date and remove preview note」で、1ファイルに対して2行追加・5行削除の変更が入っています。(GitHub)
変更の中心は、Microsoft Sentinel MCP serverのtriage collectionに関するドキュメントです。Microsoft Learn上の該当ページは「Prioritize incidents and hunt for threats with triage collection」として公開されており、最終更新日は2026年4月30日と表示されています。(Microsoft Learn)
今回の差分を運用目線で整理すると、次のようになります。
| 確認項目 | 変更内容 | 運用上の意味 |
|---|---|---|
| 見出し | 「(preview)」表記が削除 | triage collectionの扱いが見直された可能性がある |
| 警告文 | プレリリース製品に関する注意書きが削除 | 該当ページ単体ではプレビュー警告が前面に出なくなった |
ms.date | ドキュメント日付が更新 | 管理者向け手順や社内ナレッジの再確認タイミング |
| 機能説明 | triage collectionの目的は継続 | インシデント優先度付けと脅威ハンティング支援が主用途 |
| 変更範囲 | 1つのMarkdownファイル | Microsoft Defender全体の仕様変更とは限らない |
特に注意したいのは、GitHub上の差分ではms.date: 04/40/2026という表記が見えますが、Microsoft Learnの公開ページでは「Last updated on 2026-04-30」と表示されている点です。記事化や社内共有では、公開ページ上の日付である2026年4月30日を基準に扱うのが自然です。(GitHub)
そもそもtriage collectionとは何か
triage collectionは、Microsoft SentinelのModel Context Protocol、いわゆるMCP serverで提供されるツール群の一部です。AIモデルや対応クライアントから、インシデントの優先順位付け、アラート確認、エンティティ調査、Advanced Huntingクエリ実行などを行いやすくするためのコレクションです。(Microsoft Learn)
Microsoft Learnでは、triage collectionの用途として大きく次の2つが示されています。
- Incident triage：インシデント、アラート、証拠、エンティティなどを取得し、優先度付けを支援する
- Hunting：自社データを対象に脅威ハンティングを行い、リスク露出や滞留時間の削減を支援する
利用には、Microsoft Defender XDR、Microsoft Defender for Endpoint、またはMicrosoft SentinelがDefenderポータルにオンボードされていることが前提です。また、対応するAI-powered code editorまたはagent-building platformも必要で、該当ページではVisual Studio Codeが前提例として示されています。(Microsoft Learn)
triage collectionのエンドポイントは次のURLです。
https://sentinel.microsoft.com/mcp/triageこのURL自体は、AIエージェントや対応クライアントからMCP serverへ接続するための参照先として扱います。ブラウザで直接開いて使う管理画面ではないため、社内手順書では「設定先URL」と「利用画面」を混同しないように書き分ける必要があります。(Microsoft Learn)
「preview」表記削除をどう解釈すべきか
今回もっとも誤解しやすいポイントは、「preview」表記が外れたことをもって、Microsoft Sentinel MCP server全体、またはMicrosoft Defender関連のすべてのMCP機能が一般提供になったと判断してしまうことです。
結論としては、この更新だけで“全体がGAになった”とは判断しない方が安全です。
理由は、料金・制限・可用性に関するMicrosoft Learnページでは、引き続きプレリリース製品に関する注意書きが掲載されています。また、Microsoft SentinelのWhat’s newページでも、過去の更新としてMicrosoft Sentinel MCP serverがPreviewとして説明されています。(Microsoft Learn)
つまり、今回の更新は少なくとも次のように切り分けて見るべきです。
| 判断したいこと | 今回の更新だけで判断できるか | 確認すべき追加情報 |
|---|---|---|
| triage collectionのページからpreview表記が外れたか | できる | GitHub差分、Microsoft Learnの該当ページ |
| triage collectionが本番運用候補として扱いやすくなったか | ある程度推測できる | 前提条件、制限、料金、サポート範囲 |
| Microsoft Sentinel MCP server全体がGAか | 判断しない方がよい | What’s new、pricing/limits、製品リリースノート |
| 社内で正式利用を開始してよいか | 組織判断が必要 | セキュリティ審査、権限設計、監査ログ、データ取り扱い |
| 既存設定をすぐ変更すべきか | 通常は不要 | 現行運用、接続エラー、権限、利用中クライアント |
実務では、「preview表記が外れたから即展開」ではなく、ドキュメント上のステータス変化をきっかけに、利用可否判断を再開するのが適切です。
管理者が最初に確認すべきポイント
security adminが最初に見るべきなのは、機能の魅力ではなく、利用条件です。triage collectionはインシデント、アラート、デバイス、ユーザー、脆弱性などのセキュリティ情報にアクセスする可能性があるため、通常の便利ツールよりも慎重に確認する必要があります。
Defenderポータルへのオンボード状況
Microsoft Learnでは、triage collectionの利用前提として、Microsoft Defender XDR、Microsoft Defender for Endpoint、またはMicrosoft SentinelがDefenderポータルにオンボードされていることが示されています。(Microsoft Learn)
そのため、まず次を確認します。
| 確認項目 | 見るべきポイント |
|---|---|
| Microsoft Defender XDR | 対象テナントで利用中か |
| Microsoft Defender for Endpoint | デバイス情報やファイル情報の調査に使える状態か |
| Microsoft Sentinel | Defenderポータル側で運用しているか |
| Microsoft Sentinel data lake | MCPツール利用に必要な範囲で構成済みか |
| 利用リージョン | 日本を含む対象地域で利用できるか |
料金・制限ページでは、Microsoft SentinelのMCP toolsの最適な利用地域として日本も含まれています。ただし、組織の契約、テナント構成、データ所在地の要件によって判断が変わるため、グローバル企業では地域ごとに確認が必要です。(Microsoft Learn)
必要な権限
Microsoft Learnの開始ガイドでは、SentinelのMCP toolsを一覧表示・呼び出しするにはSecurity readerロールが必要とされています。また、triage tool collectionでは、既存の権限で許可されているツールを利用できるという説明があります。(Microsoft Learn)
ここで重要なのは、AIエージェントに接続するからといって、権限が自動的に広がるわけではない点です。むしろ、既存権限の範囲内でAIが操作できるため、人間のユーザーに与えた権限がそのままAI経由の調査範囲に影響すると考えるべきです。
実務では、次のようにロールを分けると管理しやすくなります。
| 利用者 | 推奨する考え方 |
|---|---|
| SOCアナリスト | インシデント確認・ハンティングに必要な最小権限 |
| セキュリティ管理者 | 設定確認、接続テスト、障害対応に必要な権限 |
| コンプライアンス担当 | 監査・証跡確認に必要な閲覧権限 |
| 開発・自動化担当 | 本番データへの直接アクセスを避け、検証環境から開始 |
| 外部委託先 | ゲスト利用や委任アクセスの制限を必ず確認 |
対応クライアント
該当ドキュメントでは、対応するAI-powered code editorやagent-building platformが必要で、Visual Studio Codeが前提例として示されています。開始ガイドでは、Microsoft Security Copilot、Microsoft Copilot Studio、Microsoft Foundry、Visual Studio Codeに関連する導線も示されています。(Microsoft Learn)
本番利用を検討する場合は、「どのクライアントでつなげるか」を先に決めると、検証がスムーズです。VS Codeでアナリスト向けに試すのか、Copilot Studioで業務エージェント化するのか、Security Copilotと連携するのかで、認証、監査、プロンプト設計、利用者教育が変わります。
利用できる主なツールと活用シーン
triage collectionには、インシデント確認、アラート調査、Advanced Hunting、ファイル調査、デバイス調査、ユーザー調査、脆弱性確認、修復タスク確認などに使えるツールが含まれます。Microsoft Learnでは、ListIncidents、GetIncidentById、ListAlerts、RunAdvancedHuntingQuery、GetDefenderFileInfo、GetDefenderMachine、ListUserRelatedAlertsなどが説明されています。(Microsoft Learn)
運用シーン別に見ると、次のように使い分けできます。
| 運用シーン | 使う可能性が高いツール | 実務での使い方 |
|---|---|---|
| 新規インシデントの優先度判断 | ListIncidents、GetIncidentById | 重大度、状態、担当者、関連アラートを確認する |
| アラートの深掘り | ListAlerts、GetAlertByID | 関連証拠やエンティティを見て誤検知か判断する |
| KQLによる脅威ハンティング | FetchAdvancedHuntingTablesOverview、FetchAdvancedHuntingTablesDetailedSchema、RunAdvancedHuntingQuery | テーブル構造を確認してからクエリを実行する |
| ファイルハッシュ調査 | GetDefenderFileInfo、GetDefenderFileStatistics、GetDefenderFileAlerts | 端末内の拡散状況や関連アラートを確認する |
| デバイス調査 | GetDefenderMachine、GetDefenderMachineAlerts、GetDefenderMachineLoggedOnUsers | 端末のリスク、サインインユーザー、関連アラートを確認する |
| 脆弱性対応 | GetDefenderMachineVulnerabilities、ListDefenderMachinesByVulnerability | CVE単位で影響端末を確認し、パッチ優先度を決める |
| 修復状況の確認 | ListDefenderRemediationActivities、GetDefenderRemediationActivity | 対応タスクの進捗や完了状況を確認する |
ポイントは、AIに「何が危険？」と丸投げしないことです。たとえば、重大アラートが発生した場合は、次のように具体的に依頼した方が、再現性のある調査につながります。
過去24時間に作成されたHigh以上のインシデントを一覧化し、
関連アラート数、影響デバイス、関連ユーザー、既知のファイルハッシュを基準に
優先対応すべき順番を提案してください。Microsoftのトラブルシューティング文書でも、曖昧なプロンプトより、対象ユーザー、期間、比較条件、調査観点を指定したプロンプトの方が望ましいと説明されています。(Microsoft Learn)
compliance teamsが見るべきリスクと監査観点
compliance teamsにとって重要なのは、「AIで調査できるようになった」ことそのものではありません。重要なのは、誰が、どのデータに、どの目的で、どの範囲までアクセスできるかです。
triage collectionは、インシデント、アラート、ユーザー、デバイス、ファイル、脆弱性といったセキュリティデータを扱います。これは、組織によっては個人情報、機密情報、内部統制上の重要データに該当する可能性があります。
確認すべき観点は次の通りです。
| 観点 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 権限 | 利用者が必要最小限のロールか | 検証担当に広すぎる権限を与える |
| データ範囲 | どのワークスペース、どのテナントを対象にするか | 複数ワークスペースのデータが混在する |
| プロンプト | 機密情報を不用意に入力していないか | チケット番号、氏名、IP、端末名を必要以上に含める |
| 監査 | 実行履歴や調査結果を追跡できるか | AI回答だけを残し、元データや判断根拠を残さない |
| 外部委託 | 委託先アカウントで使える範囲は妥当か | ゲスト・委任アクセスの制限を見落とす |
| 運用ルール | AIの提案を誰が承認するか | AIの判断をそのまま封じ込めや修復に使う |
Microsoft Learnでは、triage collectionについて、ゲストとして他テナントで使うことや委任アクセスで使うことはできず、自分のホームテナントでのみMCP serverを利用できると説明されています。また、Microsoft Sentinelユーザーは利用するワークスペースを選べないという制限も示されています。(Microsoft Learn)
この制限は、コンプライアンス上のマイナスだけではありません。むしろ、委任アクセスやゲスト利用による想定外のデータアクセスを避けるための重要な前提として、社内規程に明記しておくべきです。
enterprise IT readers向けの移行準備チェックリスト
今回の更新を受けて、すでにMicrosoft Defender XDRやMicrosoft Sentinelを利用している企業は、MCP triage collectionの検証を進めやすくなります。ただし、移行準備では「接続できたか」だけでなく、「運用に組み込めるか」を確認する必要があります。
検証前に確認すること
| チェック項目 | 確認内容 |
|---|---|
| 対象テナント | 本番ではなく検証用テナント、または限定された本番範囲で始める |
| Defenderポータル | Microsoft Defender XDR、Defender for Endpoint、Microsoft Sentinelのオンボード状態を確認する |
| ロール | Security readerなど必要な権限を最小限で付与する |
| クライアント | VS Code、Security Copilot、Copilot Studio、Foundryなど利用候補を決める |
| データ範囲 | ワークスペース、対象デバイス、対象ユーザーを明確にする |
| ログ・監査 | 誰が何を実行したか追える仕組みを確認する |
| プロンプト標準 | SOCで使う定型プロンプトを準備する |
| エラー対応 | 401、403、404、ツール未呼び出し時の対応手順を用意する |
検証時のおすすめ手順
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 事前確認 | 公式ドキュメントの更新日、前提条件、制限を確認 | preview削除だけで判断しない |
| 接続確認 | 対応クライアントからMCP serverへ接続 | 認証エラーが出ない |
| 権限確認 | 最小権限ユーザーでツール一覧を確認 | 想定外のデータが見えない |
| インシデント確認 | ListIncidents系の動作を検証 | 実際のSOC運用に使える粒度で返る |
| ハンティング確認 | テーブル確認後にKQLを実行 | スキーマ確認を挟んで誤クエリを減らせる |
| 監査確認 | 実行者、対象、結果の記録方法を確認 | チケットやSIEM運用と結び付く |
| 運用判断 | 本番適用範囲を決定 | 人間の承認フローを維持できる |
特にKQLを実行する場合は、いきなりRunAdvancedHuntingQueryを使うのではなく、先にFetchAdvancedHuntingTablesOverviewやFetchAdvancedHuntingTablesDetailedSchemaでテーブルとスキーマを確認する流れが安全です。Microsoft Learnでも、エラーの少ないKQLを作るためにスキーマ確認を先に行う考え方が示されています。(Microsoft Learn)
料金と制限で見落としやすい点
triage collectionについては、必要な製品・サービスにオンボードされていれば追加料金なしで使えると説明されています。ただし、これは「すべての関連操作が無制限に無料」という意味ではありません。料金・制限ページでは、triage tool collectionには通常のAPIスロットリングが適用され、Advanced Hunting APIを呼び出すツールは既存のAdvanced Huntingのクォータやサービス制限に従うと説明されています。(Microsoft Learn)
また、Microsoft Sentinel MCP toolsは英語プロンプトのみをサポートすると記載されています。日本のチームで利用する場合も、運用プロンプトは英語で標準化するか、日本語の社内手順から英語プロンプトへ変換するテンプレートを用意するとよいでしょう。(Microsoft Learn)
実務上は、次のような誤解に注意が必要です。
| 誤解 | 正しい見方 |
|---|---|
| 追加料金なしなら大量実行しても問題ない | API制限やAdvanced Huntingのクォータを確認する |
| 日本語で自然に聞けばよい | 公式上は英語プロンプトのみサポートとされている |
| preview表記が消えたので全社展開できる | 周辺ドキュメントのプレビュー表記と制限も確認する |
| AIがクエリを作るのでKQL知識は不要 | スキーマ確認と結果検証は人間が行う |
| エージェントが判断したら自動修復してよい | 影響の大きい操作は承認フローを残す |
トラブルシューティングで確認すべきポイント
MCP toolsの導入でよく起きるのは、「接続できない」「ツールが呼ばれない」「期待したデータが返らない」という問題です。Microsoftのベストプラクティスでは、MCPクライアントを互換性のある最新状態に保つこと、具体的なプロンプトを書くこと、複数ワークスペースがある場合はワークスペースIDを明示することが推奨されています。(Microsoft Learn)
障害時は、次の順番で切り分けると無駄が少なくなります。
| 症状 | 確認すること | 対応例 |
|---|---|---|
| ツールが呼ばれない | Defenderポータルへのオンボード、モデル、プロンプト、ツール構成 | 目的別コレクションを使い、プロンプトを具体化する |
| 期待しないワークスペースの結果が出る | 複数ワークスペースへのアクセス有無 | workspace IDを明示する |
| VS Codeで一時的な404 | トークン更新や接続状態 | MCP serverを削除し、VS Code再起動後に再追加する |
| 追加時に継続的な404 | テナント登録、data lakeワークスペース、ユーザー権限 | オンボード状態とアクセス権を確認する |
| 結果が返らない | テーブル有無、クエリ条件、権限 | クエリ条件を広げ、利用可能テーブルを確認する |
SOC運用では、エラー解決手順を個人の経験に任せると属人化します。MCP接続の再追加手順、権限確認先、ワークスペースIDの確認方法、サポート起票条件を1枚のランブックにまとめておくと、夜間対応や引き継ぎ時の混乱を減らせます。
社内ナレッジを更新する際の書き換え例
今回の公式ドキュメント更新を受けて、社内Wikiや運用手順書を更新する場合は、表記を慎重に変える必要があります。
避けたい書き方は次のような断定です。
Microsoft Sentinel MCP triage collectionはGAになったため、全社で利用可能。今回の更新だけでは、このように断定するのは避けるべきです。より安全な書き方は次の通りです。
2026年4月30日のMicrosoft Learn更新で、triage collectionの該当ページからpreview表記とプレリリース警告が削除された。
ただし、Microsoft Sentinel MCP server全体の提供状態、料金、制限、対応地域、利用条件については、
関連する公式ドキュメントを確認したうえで、社内のセキュリティ審査に基づき利用範囲を決定する。また、運用チーム向けには次のような一文を追加すると実用的です。
本番インシデント対応で利用する場合は、AIの回答を最終判断とせず、
対象インシデント、関連アラート、影響デバイス、実行したKQL、判断理由をチケットに記録する。このように書いておくと、AI活用を進めながらも、監査・説明責任・再現性を確保しやすくなります。
今回の更新で取るべき次のアクション
今回のMicrosoft Defender関連の公式ドキュメント更新は、見た目の差分は小さいものの、Microsoft Sentinel MCP serverのtriage collectionを検証・運用する企業にとっては確認価値の高い更新です。
まず、公式ページから「preview」表記が外れたことを確認します。次に、周辺ドキュメントのプレビュー表記、料金、制限、対応地域、英語プロンプト要件、APIスロットリングを確認します。そのうえで、Defenderポータルへのオンボード状況、Security readerなどの権限、利用クライアント、監査ログ、社内承認フローを点検してください。
すぐに行うべきことは、大きく3つです。
1つ目は、社内Wikiや運用手順の「preview」表記を公式ドキュメントに合わせて見直すことです。ただし、GA断定は避けます。
2つ目は、限定された検証環境でtriage collectionの接続、権限、ツール呼び出し、プロンプト精度を確認することです。
3つ目は、SOC、コンプライアンス、IT管理者の間で、AIエージェントが扱えるデータ範囲と承認ルールを明文化することです。
今回の更新は、単なる日付修正ではなく、AIを使ったセキュリティ運用を現実の運用設計に落とし込むタイミングを示すものです。Microsoft Defender XDR、Microsoft Defender for Endpoint、Microsoft Sentinelを運用している組織は、triage collectionを「便利そうな新機能」としてではなく、権限・監査・プロンプト・インシデント対応プロセスを含めた運用基盤として評価するのがよいでしょう。
コメント