Microsoft SentinelでSecurity Copilotを使う場合、2026年4月時点で最初に見るべきポイントは「既存のSentinelデータを、インシデント要約・KQL生成・Defenderポータル上の統合調査にどうつなげるか」です。特に、既定のMicrosoft Sentinelワークスペース設定、Microsoft Defender XDRとの連携、Natural language to KQLの扱い、プライバシーと権限管理を確認しておくと、SOC運用にすぐ反映できます。Microsoft Learnの「Security Copilot with Microsoft Sentinel」は2026年4月22日に更新されており、本記事ではその内容をもとに、security admins、identity teams、compliance teamsが実務で何を見直すべきかを整理します。(Microsoft Learn)
Microsoft Sentinelの最新動向: Security Copilot with Microsoft Sentinelで何が変わったか
2026年4月更新で注目したいのは、Security CopilotがMicrosoft Sentinelのデータを単に「参照するAI」ではなく、インシデント対応・ハンティング・レポート作成の入口として使われる前提が明確になっている点です。
Microsoftの公式ドキュメントでは、Microsoft Sentinelの豊富なセキュリティデータが、Security Copilotによるインシデント分析やハンティングクエリ生成の有力な情報源になると説明されています。また、Microsoft Defender XDRなど他のSecurity Copilotソースと組み合わせることで、組織内の脅威とその文脈をより広く把握できるとされています。(Microsoft Learn)
実務上は、次のように理解すると分かりやすいです。
| 更新ポイント | 実務での意味 | まず確認すること |
|---|---|---|
| Microsoft SentinelデータをSecurity Copilotで活用 | インシデント要約、調査補助、ハンティングの起点にできる | Copilotから参照させるSentinelワークスペースを決める |
| 既定ワークスペースの設定 | プロンプト結果の精度や対象範囲を安定させやすい | Security Copilotのプラグイン設定で既定ワークスペースを登録する |
| Microsoft SentinelプラグインとNatural language to KQL | 自然言語からKQLを生成・実行する入口になる | Preview機能として扱い、生成されたKQLは必ず検証する |
| Microsoft Defender XDRとの統合 | 統合インシデントを使って、要約・対応・レポート作成を進めやすい | SentinelワークスペースをDefenderポータルに接続しているか確認する |
| プロンプトとフィードバック運用 | AIの回答品質を継続的に改善しやすい | SOCで使う定型プロンプトとレビュー基準を作る |
ここで注意したいのは、「2026年4月22日更新」はドキュメントの更新日であり、記載されたすべての機能が同日に新規リリースされたという意味ではない点です。公開記事や社内説明では、「2026年4月時点の公式ドキュメントで確認できるポイント」と表現するのが安全です。
Security Copilot with Microsoft Sentinelとは
Security Copilotは、セキュリティ担当者のインシデント対応、脅威ハンティング、インテリジェンス収集、セキュリティ態勢管理などを自然言語で支援する生成AIベースのセキュリティソリューションです。Microsoft Sentinel、Microsoft Defender XDR、Microsoft Entra、Microsoft IntuneなどのMicrosoftセキュリティ製品と統合される設計になっています。(Microsoft Learn)
Microsoft Sentinelとの組み合わせでは、主に次の用途が想定されます。
- Sentinelインシデントの要約
- インシデントに関連するユーザー、デバイス、IPアドレスなどの整理
- 調査結果を非技術者向けに要約
- 自然言語からKQLハンティングクエリを生成
- Microsoft Defender XDRの統合インシデントと組み合わせた調査
- 調査レポートや初動対応のたたき台作成
重要なのは、Security Copilotが「判断を完全に自動化するもの」ではないことです。生成された要約やKQLは、SOCアナリストやセキュリティ管理者が確認し、組織の運用ルールに沿って利用する必要があります。
2026年4月更新で押さえるべき主要ポイント
既定のMicrosoft Sentinelワークスペース設定が重要になる
Security Copilot with Microsoft Sentinelを実務で使うなら、最初に確認すべき設定は「既定のMicrosoft Sentinelワークスペース」です。Microsoft Learnでは、プロンプト精度を高めるために、Microsoft Sentinelワークスペースを既定として設定することが推奨されています。(Microsoft Learn)
特に、複数のワークスペースを持つ組織ではこの設定が重要です。たとえば、以下のような構成では、Copilotがどのワークスペースを対象にするかが曖昧になりやすくなります。
| よくある構成 | 起こりやすい問題 |
|---|---|
| 日本、米国、欧州でSentinelワークスペースを分けている | プロンプトが意図しない地域のデータを対象にする可能性がある |
| 本番、検証、SOC演習用のワークスペースがある | 検証データを本番インシデントのように扱う可能性がある |
| 子会社や事業部ごとにワークスペースを分けている | 担当者の権限や対象範囲と回答結果がずれる可能性がある |
設定の流れは、実務上は次のように整理できます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Security Copilotにアクセスする | 対象テナントと権限が正しいか確認する |
| 2 | プロンプトバーからSourcesを開く | 利用するソースやプラグインを確認する |
| 3 | Manage pluginsでMicrosoft Sentinelプラグインを有効化する | Microsoft SentinelプラグインはPreviewとして扱う |
| 4 | Microsoft Sentinelプラグインの設定を開く | 歯車アイコンから設定に入る |
| 5 | 既定のワークスペース名を設定する | 本番SOCで使う主要ワークスペースを指定する |
既定ワークスペースと異なるデータを見たい場合は、プロンプト内でワークスペース名を明示します。公式ドキュメントでも、既定と異なるワークスペースを使う場合はプロンプトで指定する例が示されています。(Microsoft Learn)
実務では、次のようなプロンプトが使いやすいです。
workspace "soc-prod-japan" の過去24時間に作成された高優先度のMicrosoft Sentinelインシデントを、重大度が高い順に一覧化してください。インシデント番号、タイトル、作成時刻、担当者を含めてください。グローバルSOCでは、時刻の指定も曖昧にしないことが大切です。
In workspace "soc-prod-global", list high severity Microsoft Sentinel incidents created between 2026-04-21T00:00:00Z and 2026-04-22T00:00:00Z. Include incident number, title, owner, affected user, affected device, and current status.「昨日」「直近1日」だけで指示すると、担当者のタイムゾーンや運用拠点によって解釈がずれることがあります。日本、欧州、米国のチームが同じインシデントを確認する場合は、UTCやJSTを明記する運用ルールを作ると安全です。
Defenderポータル統合により、統合インシデントでの調査が現実的になる
Security Copilot with Microsoft Sentinelのもう一つの重要点は、Microsoft Defender XDRとの統合です。公式ドキュメントでは、Microsoft Defender XDRを利用している場合、Microsoft Sentinelと統合されたインシデントを通じて、Defender側のCopilot機能が活用できると説明されています。(Microsoft Learn)
これにより、SOCの動きは次のように変わります。
| 従来の運用 | Copilot連携後に目指したい運用 |
|---|---|
| Sentinelでインシデントを確認し、別画面でDefender XDRを確認する | Defenderポータル上の統合インシデントを中心に調査する |
| アナリストがログ、アラート、エンティティ情報を手作業で整理する | Copilotにインシデント要約や関連エンティティの整理を依頼する |
| 報告書を別途手作業で作る | Copilotに非技術者向けの初期レポート案を作らせる |
| KQLに詳しい担当者に調査を依頼する | 自然言語からKQL案を作り、担当者が検証する |
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Defender XDRやE5ライセンスがない顧客でもDefenderポータルでMicrosoft Sentinelを利用できると案内されています。Microsoft Learnでは、Azureポータル中心の運用からDefenderポータルへの移行計画も推奨されています。(Microsoft Learn)
そのため、Security Copilot活用を検討する企業は、単にCopilotを追加するのではなく、次の観点で運用設計を見直すべきです。
- インシデントキューをどこで見るか
- SentinelとDefender XDRのどちらを一次調査画面にするか
- 統合インシデントの所有者を誰にするか
- 既存のプレイブックやチケット連携に影響がないか
- SOCアナリスト、IDチーム、コンプライアンス担当が同じ情報を参照できるか
特に、既存のSOC手順書が「AzureポータルのMicrosoft Sentinel画面」を前提にしている場合、Defenderポータルでの画面遷移、権限、インシデント名、ステータス更新、コメント運用を確認しておく必要があります。
Natural language to KQLは便利だが、Previewとして検証前提で使う
Security Copilot with Microsoft Sentinelでは、Natural language to KQL for Microsoft SentinelプラグインがPreviewとして提供されます。これは、自然言語からMicrosoft Sentinelデータを使ったKQLハンティングクエリを生成・実行する機能で、スタンドアロンのSecurity Copilot体験と、Microsoft DefenderポータルのAdvanced Huntingセクションで利用できるとされています。(Microsoft Learn)
ただし、ここで重要なのは「KQLを書かなくてよくなる」ではなく、「KQLのたたき台を速く作れる」と捉えることです。
MicrosoftのAdvanced Hunting向けSecurity Copilotドキュメントでは、Threat Hunting AgentとQuery assistantがシンプルから中程度の複雑さのクエリ生成をサポートし、複雑なユースケースでは正確性の検証を推奨しています。また、すべてのMicrosoft Sentinelテーブルがサポートされるわけではありません。(Microsoft Learn)
実務での使い分けは次のとおりです。
| 用途 | Copilotに任せやすいこと | 人が必ず確認すべきこと |
|---|---|---|
| 初動調査 | 関連ログを探すKQL案の生成 | 対象テーブル、期間、フィルター条件 |
| 脅威ハンティング | 不審なログイン、通信、プロセス実行の検索案 | join条件、集計条件、誤検知の扱い |
| レポート作成 | 調査結果の要約、時系列整理 | 事実関係、影響範囲、報告先に合わせた表現 |
| 教育・引き継ぎ | KQLの説明、調査観点の整理 | 自社固有のログ構造や命名規則 |
たとえば、IDチームがMicrosoft Entra関連のログを調べたい場合、次のように依頼できます。
過去7日間のSigninLogsを対象に、MFA失敗が多いユーザーを上位10件抽出するKQLを作成してください。ユーザー、失敗回数、主なIPアドレス、国/地域、最終発生時刻を表示してください。このプロンプトで生成されたKQLは、そのまま検知ルールにするのではなく、まず検証用クエリとして扱います。確認すべき点は、対象テーブルが自社環境で利用可能か、列名が正しいか、期間指定が適切か、集計結果が実際のログと一致するかです。
インシデント要約は「誰向けか」を指定すると実用性が上がる
Security Copilotは要約が得意ですが、単に「このインシデントを要約して」と依頼すると、SOCアナリストには浅すぎる、経営層には技術的すぎる、コンプライアンス担当には証跡が足りない、という結果になりがちです。
Microsoft Learnのサンプルでも、非技術者向けのエグゼクティブレポートを書くように対象読者を指定する例が示されています。Sentinelインシデント調査のPromptbookは、特定インシデントに関するレポート、関連アラート、レピュテーションスコア、ユーザー、デバイスなどを扱う起点として紹介されています。(Microsoft Learn)
役割別には、次のようなプロンプト設計が有効です。
| 対象者 | プロンプト例 | 期待する出力 |
|---|---|---|
| security admins | このMicrosoft SentinelインシデントをSOCアナリスト向けに要約してください。攻撃の時系列、関連エンティティ、推奨される次の調査手順を含めてください。 | 初動対応に使える技術的な要約 |
| identity teams | このインシデントに関連するユーザー、サインイン、リスクイベント、権限変更の有無をIDチーム向けに整理してください。 | アカウント侵害や権限悪用の確認 |
| compliance teams | この調査内容を非技術者向けに要約してください。影響範囲、確認済みの事実、未確認事項、次の対応を分けてください。 | 監査・報告に使いやすい整理 |
| グローバルSOC | Summarize this incident for a global SOC handover. Include UTC timestamps, impacted entities, current owner, open questions, and recommended next actions. | 拠点間の引き継ぎに使えるサマリー |
ポイントは、「要約の粒度」「対象読者」「含める項目」「除外する項目」を明示することです。
悪い例は次のようなプロンプトです。
このインシデントを説明して。この指示では、技術的な調査なのか、管理職向け報告なのか、監査証跡なのかが曖昧です。
改善した例は次のとおりです。
このMicrosoft Sentinelインシデントを、コンプライアンス担当者向けに日本語で要約してください。確認済みの事実、推定事項、未確認事項、個人情報への影響可能性、次に必要な証跡確認を分けてください。断定できない内容は「未確認」と明記してください。このように指定すると、AIの回答をそのまま信じるのではなく、レビューしやすい形式に整えられます。
Security adminsが確認すべきこと
セキュリティ管理者は、Security Copilot with Microsoft Sentinelを「便利なチャット画面」としてではなく、SOC運用の一部として管理する必要があります。
まず確認すべき項目は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| 既定ワークスペース | 本番SOCで最も使うSentinelワークスペースが設定されているか |
| プラグイン | Microsoft SentinelプラグインとNatural language to KQLの利用範囲を把握しているか |
| Defender統合 | SentinelワークスペースがDefenderポータルで利用できる状態か |
| 権限 | Copilot利用者が必要以上のデータを参照できない設計か |
| レビュー | Copilotの要約やKQLを人が確認する運用になっているか |
| フィードバック | 誤回答や不完全な回答を製品内フィードバックに残す手順があるか |
Security Copilotは、プロンプトごとの回答に対して「正しい」「改善が必要」「不適切」といったフィードバックを送れる仕組みがあります。Microsoftは、結果が不正確または不完全な場合、改善に必要な情報を記載することを推奨しています。(Microsoft Learn)
SOC内では、次のようなルールを決めておくと運用しやすくなります。
- Copilotの回答だけでインシデントをクローズしない
- 生成されたKQLを検知ルールへ反映する前に、別担当者がレビューする
- 高重大度インシデントでは、Copilot要約と実ログの差分を確認する
- 誤回答はスクリーンショットだけでなく、再現プロンプトも残す
- 定型プロンプトはチームで共有し、属人化させない
Identity teamsが確認すべきこと
IDチームにとって、Security Copilot with Microsoft Sentinelの価値は、アカウント侵害、リスクユーザー、不審なサインイン、権限昇格の兆候を素早く整理できる点にあります。
ただし、ID関連データは扱いを誤ると影響が大きい領域です。特に、ユーザー情報、サインイン履歴、リスク検出、条件付きアクセス、特権ロールの操作履歴などは、誤った要約や不十分な確認によって対応判断がぶれる可能性があります。
IDチーム向けの実用プロンプト例は次のとおりです。
このインシデントに関連するユーザーについて、過去72時間の不審なサインイン、MFA失敗、国/地域の変化、特権ロールの変更有無を調査するためのKQL案を作成してください。各クエリの目的も説明してください。このMicrosoft Sentinelインシデントに含まれるID関連エンティティを整理してください。ユーザー、IPアドレス、デバイス、サインインイベントを分け、侵害アカウントの可能性が高い順に理由付きで並べてください。ここでも、Copilotの出力は「調査の出発点」です。IDチームは、生成された結果をMicrosoft Entraの監査ログ、サインインログ、Privileged Identity Managementの履歴、条件付きアクセスの評価結果などと突き合わせる必要があります。
Compliance teamsが確認すべきこと
コンプライアンス担当者にとって重要なのは、Copilotを使うことで「どのデータが入力され、どのデータが取得され、どのように保存・処理されるか」を把握することです。
Microsoftのプライバシーとデータセキュリティのドキュメントでは、Security CopilotのCustomer Dataに、ユーザーが送信するプロンプト、回答生成のために取得された情報、回答、ピン留めされた項目、ファイルアップロードなどが含まれると説明されています。また、Security Copilotはユーザーとしてクエリを実行し、ユーザーが持つ権限を超えた昇格権限は持たないとされています。(Microsoft Learn)
コンプライアンス観点では、次の確認が必要です。
| 確認項目 | 実務での確認内容 |
|---|---|
| データ共有設定 | Microsoftへのデータ共有設定を誰が変更できるか |
| プロンプト内容 | 個人情報、機密情報、顧客情報を必要以上に入力していないか |
| データ保存場所 | Security Copilotワークスペース作成時の保存場所が社内要件と合うか |
| 保持と削除 | サブスクリプション、容量削除、削除要求時の扱いを把握しているか |
| 監査証跡 | Copilotで作成した要約を正式な報告書に使う前にレビューしているか |
| 権限最小化 | Global Administratorなど高権限ロールを日常運用に使っていないか |
Microsoftは、権限の少ないロールを使用することを推奨し、Global Administratorは既存ロールで対応できない緊急シナリオに限定すべき高権限ロールと説明しています。(Microsoft Learn)
コンプライアンス担当者がSecurity Copilotの導入レビューに関わる場合は、次の質問をSOCチームに投げると効果的です。
- Copilotに入力してよい情報と、入力してはいけない情報を定義しているか
- 生成されたレポートを正式文書にする前の承認フローはあるか
- インシデント要約に推定情報と確認済み事実を分けるルールはあるか
- データ共有設定を変更できる管理者を限定しているか
- 国や地域ごとのデータ保存・処理要件を確認しているか
実装前に使えるチェックリスト
Security Copilot with Microsoft Sentinelを本番運用に入れる前に、次の順番で確認すると失敗しにくくなります。
| フェーズ | チェック項目 | 完了の目安 |
|---|---|---|
| 準備 | Microsoft Sentinelワークスペースの一覧を棚卸しする | 本番・検証・地域別ワークスペースが分かる |
| 準備 | Security Copilotの利用者と権限を確認する | SOC、ID、コンプライアンスの利用範囲が決まる |
| 設定 | Microsoft Sentinelプラグインを有効化する | 利用対象のワークスペースで動作確認できる |
| 設定 | 既定ワークスペースを登録する | 通常のプロンプトで意図したデータが返る |
| 統合 | Microsoft Defender XDRとの連携状況を確認する | 統合インシデントを使った調査ができる |
| 検証 | インシデント要約を試す | 事実、推定、未確認事項を分けられる |
| 検証 | Natural language to KQLを試す | 生成KQLを人がレビューできる |
| 運用 | 定型プロンプトを作成する | チーム内で同じ品質の調査ができる |
| 運用 | フィードバック手順を決める | 誤回答や不適切回答を記録できる |
| ガバナンス | データ共有・保存・削除の扱いを確認する | コンプライアンスレビューに耐えられる |
このチェックリストで特に重要なのは、技術設定よりも「誰が、どのデータに対して、どの判断に使うのか」を先に決めることです。AI機能は導入そのものよりも、運用ルールが曖昧なまま使われることの方がリスクになります。
失敗しやすいポイントと回避策
ワークスペース名を指定せず、意図しないデータを見てしまう
複数ワークスペース環境では、プロンプトにワークスペース名を入れる癖をつけるべきです。既定ワークスペースを設定していても、例外的に別ワークスペースを見る場合は明示しましょう。
悪い例:
高優先度のインシデントを見せて。良い例:
workspace "soc-prod-japan" の過去24時間に作成された高優先度のMicrosoft Sentinelインシデントを、重大度順に一覧化してください。Preview機能を本番判断にそのまま使う
Microsoft SentinelプラグインやNatural language to KQL for Microsoft SentinelはPreviewとして扱われます。Preview機能を使う場合、回答や生成クエリの正確性を前提にせず、必ず検証プロセスを入れる必要があります。(Microsoft Learn)
特に、以下の使い方は避けるべきです。
- 生成されたKQLを確認せずに検知ルール化する
- Copilotの要約だけで重大度を下げる
- サポート対象外のテーブルに対する結果を正しいとみなす
- 複雑なjoinや集計を検証なしで使う
「要約」と「判断」を混同する
Copilotは要約や整理に強みがありますが、最終判断は人が行うべきです。たとえば「このインシデントは誤検知ですか？」と聞くよりも、次のように聞いた方が安全です。
このインシデントが誤検知である可能性を評価するために、確認すべき証跡を一覧化してください。誤検知を示す材料と、真陽性を示す材料を分けてください。この聞き方なら、Copilotを判断者ではなく、調査観点を整理する補助者として使えます。
コンプライアンス向けレポートで推定を断定してしまう
インシデント報告では、「確認済み」「推定」「未確認」を分けることが重要です。Copilotにレポートを作らせる場合も、この分類を明示しましょう。
この調査結果をコンプライアンス報告向けに整理してください。確認済みの事実、推定される内容、未確認の内容、追加確認が必要な証跡を分けてください。断定できない内容は断定しないでください。これにより、監査や顧客報告で問題になりやすい過剰な断定を避けやすくなります。
実務で使える運用シナリオ
高重大度インシデントの初動対応
高重大度インシデントが発生した場合、Security Copilot with Microsoft Sentinelは初動整理に向いています。
| 手順 | 作業 | Copilotに依頼する内容 |
|---|---|---|
| 1 | インシデント概要を把握 | 何が起きたか、影響を受けたエンティティ、時系列を要約 |
| 2 | 関連情報を整理 | ユーザー、デバイス、IP、アラートを分類 |
| 3 | 追加調査 | 関連IOCを過去7日間で検索するKQL案を作成 |
| 4 | 担当チームへ引き継ぎ | IDチーム、端末対応チーム、クラウド管理者向けに要約 |
| 5 | 報告 | 非技術者向けの暫定報告案を作成 |
この流れで使うと、Copilotは「調査のショートカット」ではなく、「調査開始時の情報整理役」として機能します。
ID侵害の疑いがある場合
ID侵害では、複数のログを横断して確認する必要があります。Copilotには、調査対象と観点を明確に伝えることが重要です。
このインシデントに関連するユーザーについて、アカウント侵害の可能性を確認する調査計画を作成してください。確認すべきログ、KQL案、判断材料、IDチームへの依頼事項を分けてください。IDチームは、Copilotが出した調査計画をもとに、サインインログ、リスクユーザー、条件付きアクセス、MFA登録変更、特権ロールの履歴を確認します。
監査・報告向けの文書作成
コンプライアンス担当者や経営層向けには、技術的な詳細よりも「影響」「対応状況」「残課題」が重要です。
このインシデントについて、経営層向けの暫定報告を作成してください。技術用語は最小限にし、発生概要、影響範囲、現在の対応状況、未確認事項、次のアクションを箇条書きでまとめてください。この出力をそのまま送付するのではなく、SOC責任者や法務・コンプライアンス担当がレビューしてから正式文書に反映します。
グローバル運用での注意点
Security Copilot with Microsoft Sentinelは、グローバル読者や多国籍組織にも向いたテーマです。ただし、グローバルSOCで使う場合は、日本国内だけの運用よりも曖昧さを減らす必要があります。
特に注意したいのは次の点です。
| 項目 | 推奨する運用 |
|---|---|
| 時刻 | UTCを基本にし、必要に応じてJSTや現地時間を併記する |
| 言語 | 調査用は英語、国内報告用は日本語など用途で分ける |
| ワークスペース名 | 地域、環境、用途が分かる命名規則にする |
| 引き継ぎ | 「open questions」「next actions」「owner」を必ず含める |
| 権限 | 地域ごとのデータアクセス制約を確認する |
| 報告 | 法規制や顧客契約に関わる内容は人がレビューする |
グローバルSOC向けのプロンプト例は次のとおりです。
Summarize this Microsoft Sentinel incident for global SOC handover. Use UTC timestamps. Include confirmed facts, suspected activity, impacted users and devices, current owner, open questions, and recommended next actions. Do not make conclusions that are not supported by evidence.日本側の報告に使う場合は、次のように変換できます。
上記のグローバルSOC引き継ぎ内容を、日本のコンプライアンス担当者向けに日本語で要約してください。確認済みの事実、未確認事項、国内ユーザーへの影響可能性、追加で確認すべき証跡を分けてください。まず着手すべきアクション
Security Copilot with Microsoft Sentinelの2026年4月更新ポイントを踏まえると、最初に取り組むべきことは明確です。
まず、Security Copilotで参照させるMicrosoft Sentinelワークスペースを決め、既定ワークスペースを設定します。次に、Microsoft Defenderポータル上でSentinelデータや統合インシデントを使った調査ができるか確認します。そのうえで、インシデント要約、Natural language to KQL、非技術者向けレポート作成の3つを小さく試し、SOC内の定型プロンプトとレビュー基準を作ります。
Security Copilotは、Microsoft Sentinel運用を置き換えるものではありません。むしろ、既存のSentinelデータ、Defender XDRの統合インシデント、KQL、SOCの判断プロセスをつなぐ補助線です。導入効果を出すには、AIに何を任せるかだけでなく、どこから人が確認するかを明確にすることが重要です。
コメント