Security Copilot with Microsoft Sentinelは、Microsoft SentinelのインシデントやハンティングデータをSecurity Copilotで活用し、調査、要約、KQL生成、対応判断を支援する連携機能です。2026年5月14日に更新された公式情報では、Microsoft Defenderポータルとの統合、Sentinelプラグイン、自然言語からKQLを生成する機能、Defender XDRとの統合時の注意点が整理されています。(Microsoft Learn)
管理者が最初に確認すべき結論は明確です。Security Copilotの既定Microsoft Sentinelワークスペース、Microsoft SentinelとMicrosoft Defender XDRの接続状態、RBAC、既存の自動化ルールとKQLクエリへの影響を確認してください。特に、Microsoft SentinelをAzureポータル中心で運用している組織は、Defenderポータルへの移行計画も早めに進める必要があります。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内しています。(Microsoft Learn)
Security Copilot with Microsoft Sentinelで何ができるのか
Security Copilot with Microsoft Sentinelは、Microsoft SentinelのセキュリティデータをSecurity Copilotに渡し、SOCの調査作業を短縮するための連携です。主な用途は、インシデントの要約、関連エンティティの把握、ハンティングクエリの作成、調査結果のレポート化です。
公式情報では、Microsoft SentinelはSecurity Copilotに対して、主に次の2つのプラグインを提供します。
| プラグイン | 主な用途 | 管理者が確認すべきこと |
|---|---|---|
| Microsoft Sentinel（Preview） | Sentinelのインシデントやデータを使った調査、要約、質問応答 | 既定ワークスペースが正しいか、利用者に必要なSentinel権限があるか |
| Natural language to KQL for Microsoft Sentinel（Preview） | 自然言語からKQLクエリを生成し、ハンティングに活用 | 生成されたKQLを実行前に検証する運用ルールがあるか |
この連携は、Security Copilotのスタンドアロン体験だけでなく、Microsoft Defenderポータル内のCopilot in Defenderや高度なハンティングにも関係します。Microsoft Defender XDRを併用している場合、Microsoft SentinelのインシデントがDefender XDRの統合インシデントと連携し、Copilotがインシデント要約、ガイド付き対応、インシデントレポート作成に活用できます。(Microsoft Learn)
2026年5月14日の公式更新で押さえる変更点
今回の更新は、脆弱性修正パッチというよりも、Security Copilot、Microsoft Sentinel、Microsoft Defender XDRを組み合わせて運用する際の公式ガイダンス更新として捉えるのが適切です。
| 確認項目 | 変更・整理されたポイント | 実務上の影響 |
|---|---|---|
| 対象範囲 | Microsoft Sentinel with Defender XDR、Microsoft Sentinel in Azure portal、Security Copilotが対象 | Sentinel単体ではなく、Defenderポータル統合を前提に確認が必要 |
| Sentinelプラグイン | Microsoft Sentinel（Preview）とNatural language to KQL for Microsoft Sentinel（Preview）が案内されている | プレビュー機能は仕様変更の可能性を踏まえ、検証環境や限定ユーザーから展開する |
| 既定ワークスペース | Security Copilotで既定のMicrosoft Sentinelワークスペースを設定できる | 複数ワークスペース環境では、誤ったワークスペースを参照するリスクがある |
| Defender統合 | SentinelデータをDefenderポータルで使い、統合インシデントに基づいてCopilotを活用できる | SOCの調査画面、インシデントキュー、自動化ルールの設計に影響する |
| 高度なハンティング | 自然言語からKQLを生成できるが、すべてのSentinelテーブルが対象ではない | 生成クエリをそのまま本番運用せず、テーブル対応状況と結果を検証する |
Microsoft Defenderポータルでは、Microsoft Sentinelが一般提供されており、Microsoft Defender XDRやE5ライセンスがない顧客でもSentinelをDefenderポータルで利用できるとされています。一方で、SentinelのみをDefenderポータルで使う場合、一部のMicrosoft Defender XDR由来の機能は制限または利用不可になる点に注意が必要です。(Microsoft Learn)
影響を受ける管理者・開発者・運用担当者
Security Copilot with Microsoft Sentinelの影響は、SOCアナリストだけに限られません。Microsoft Defender、Microsoft Sentinel、Azure RBAC、自動化、KQL、データ保持、プライバシー設定まで関係します。
| 対象者 | 主な影響 | 優先して確認すべきこと |
|---|---|---|
| Microsoft Defender管理者 | DefenderポータルでSentinelデータを扱う範囲が広がる | Sentinelワークスペースの接続状態、Defender XDRライセンス、統合インシデント |
| Microsoft Sentinel管理者 | Azureポータル中心の運用からDefenderポータル中心の運用へ移行が必要 | 2027年3月31日までの移行計画、主ワークスペース、RBAC |
| SOCアナリスト | Copilotによるインシデント要約、対応案、KQL生成が利用しやすくなる | Copilotの回答を検証する手順、誤回答時のフィードバック |
| KQL・自動化担当者 | コネクタ変更やスキーマ差分で既存クエリが影響を受ける可能性 | SecurityAlert、SecurityIncident、AlertInfo、AlertEvidenceなどのクエリ確認 |
| セキュリティ責任者 | 生成AIが扱うプロンプト、取得データ、応答内容の管理が必要 | データ共有設定、最小権限、利用ログ、社内ガイドライン |
Microsoft Security Copilotは、Security Copilot専用のロールだけでセキュリティデータへアクセスできるわけではありません。Security Copilot ContributorなどのロールはCopilotプラットフォームへのアクセスを制御しますが、Microsoft SentinelやMicrosoft Defender XDRのデータを扱うには、Microsoft Entra IDやAzure RBAC側の適切な権限が必要です。(Microsoft Learn)
管理者が最初に確認すべき設定
Security Copilot側で既定のSentinelワークスペースを設定する
複数のMicrosoft Sentinelワークスペースを使っている組織では、まずSecurity Copilotの既定ワークスペースを確認してください。既定ワークスペースが誤っていると、Copilotが意図しない環境のインシデントやログを参照し、調査結果がずれる可能性があります。
公式手順では、Security CopilotのプロンプトバーからSourcesを開き、Manage pluginsでMicrosoft Sentinel（Preview）プラグインを有効化し、歯車アイコンから既定ワークスペース名を構成します。既定ワークスペースと異なる環境を調べる場合は、プロンプト内でワークスペース名を明示します。(Microsoft Learn)
実務では、次のような運用ルールにするとミスを減らせます。
| 状況 | 推奨する指定方法 |
|---|---|
| 本番SOCで日常調査する | 本番用Sentinelワークスペースを既定にする |
| 検証環境でプロンプトを試す | 検証用ワークスペースを明示して質問する |
| 複数リージョンや複数事業部のワークスペースがある | プロンプトにワークスペース名、期間、重大度を必ず含める |
| MSSPや複数テナント運用 | テナント切り替え、ゲストアカウント、RBACの整合性を確認する |
たとえば、単に「重大なインシデントを教えて」と聞くより、次のように指定した方が実務で使いやすくなります。
workspace "soc-prod-japan" で、過去24時間に作成されたHigh以上のMicrosoft Sentinelインシデントを、重大度、所有者、関連ユーザー、推奨対応の順に一覧化してください。Microsoft SentinelをDefenderポータルに接続する
Microsoft DefenderポータルでSentinelを使うには、SentinelワークスペースをDefenderポータルに接続します。公式手順では、Microsoft Defenderポータルの「System > Settings > Microsoft Sentinel > Connect a workspace」からワークスペースを選択し、プライマリワークスペースを指定して接続します。接続後は、Defenderポータルの左側ナビゲーションにMicrosoft Sentinelが表示されます。(Microsoft Learn)
接続時は、次の権限を事前に確認してください。
| タスク | 必要な権限の例 | 注意点 |
|---|---|---|
| SentinelをDefenderポータルに接続 | Owner、またはUser Access AdministratorとMicrosoft Sentinel Contributor | 複数ワークスペース環境では追加のMicrosoft Entra権限が必要になる場合がある |
| SentinelをDefenderポータルで閲覧 | Microsoft Sentinel Reader | 閲覧だけならContributorを付与しない |
| インシデントへ調査アクションを実行 | Microsoft Sentinel Contributorまたは同等のカスタム権限 | コメント、タスク、関連付けの書き込み権限を確認する |
| 主ワークスペースの変更 | Security Administrator以上とAzure側の適切な権限 | 主ワークスペース変更はDefender XDRコネクタにも影響する |
最小権限の原則を守ることが重要です。Copilotを使わせるためだけにGlobal AdministratorやSecurity Administratorを広く付与すると、調査支援のための機能展開が、逆に権限過多のリスクになります。(Microsoft Learn)
Defender XDR連携で注意すべき影響
Defender XDRコネクタによりインシデントとアラートの流れが変わる
Microsoft SentinelとMicrosoft Defender XDRを統合すると、Defender XDRのインシデント、アラート、エンティティ、関連情報がMicrosoft Sentinelに取り込まれ、両ポータル間でインシデントが同期されます。Azureポータル側でDefender XDRコネクタを有効にする場合、インシデントとアラート、エンティティ、advanced huntingイベントの接続設定があります。(Microsoft Learn)
接続確認には、Microsoft SentinelのLogsで次のようなKQLを実行します。
SecurityIncident
| where ProviderName == "Microsoft XDR"この確認は、展開直後だけでなく、コネクタ切り替え、主ワークスペース変更、既存コネクタ整理の後にも実施してください。
既存のMicrosoft Defender系コネクタは重複に注意する
Microsoft Defender XDRコネクタを有効にすると、Microsoft Defender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Appsなど、Defender XDRに統合される製品のスタンドアロンコネクタが影響を受けます。DefenderポータルにSentinelをオンボードしてDefender XDRライセンスがある場合、Defender XDRデータコネクタは自動設定され、対象となる個別コネクタは切断されます。(Microsoft Learn)
注意したいのは、管理画面上でコネクタが接続済みに見えても、実際にはデータが流れていないケースです。公式情報でも、Defender XDRコネクタ有効化後、以前のMicrosoft Defenderコンポーネントコネクタはバックグラウンドで自動的に切断され、表示上は接続されているように見えてもデータは流れないと説明されています。(Microsoft Learn)
既存のKQL、分析ルール、自動化ルールへの影響
アラートスキーマ差分を必ず確認する
スタンドアロンコネクタからXDRコネクタへ移行すると、アラートのフィールドマッピング、派生フィールド、スキーマ構造、取り込み条件が変わる可能性があります。Microsoftの公式情報では、これらの差分が既存のクエリ、分析ルール、ワークブックに影響する可能性があるため、移行前に確認するよう案内されています。(Microsoft Learn)
特に確認すべき項目は次のとおりです。
| 確認対象 | 起こり得る影響 | 対応例 |
|---|---|---|
CompromisedEntity | 製品ごとに値の扱いが変わる | エンティティ抽出ロジックを実データで検証する |
ExtendedProperties | 一部フィールド名や値セットが変わる | WorkbooksやAnalytics rulesの条件を見直す |
| Microsoft Defender for Cloud | スタンドアロンではサブスクリプション単位、XDRではテナント単位のスコープになる | 監視対象サブスクリプションの絞り込み条件を再確認する |
| Microsoft Entra ID Protection | 既定ではHigh未満のアラートが取り込まれない場合がある | 必要に応じて取り込み設定を調整する |
| Informationalアラート | 一部のInformational severityアラートが取り込まれない | ノイズ削減か監査要件かを判断する |
移行後に「アラートが減った」と見える場合、検知が壊れたとは限りません。取り込み経路、スキーマ、重大度フィルター、重複抑制のいずれが原因かを切り分けてください。
インシデント名に依存した自動化は壊れやすい
Defender XDR統合では、Defender XDR側の相関エンジンがインシデントを作成し、タイトルも自動的に決まります。Microsoftは、インシデント名を条件にした自動化ルールは影響を受ける可能性があるため、タグなど別の条件を使うことを推奨しています。(Microsoft Learn)
たとえば、次のような自動化は見直し対象です。
| 既存の条件 | 問題になりやすい理由 | 見直し案 |
|---|---|---|
| インシデントタイトルに「Phishing」を含む | XDR相関後にタイトルが変わる可能性がある | ProductName、AlertInfo、タグ、カテゴリを使う |
| 特定のアラート名でPlaybookを起動 | スキーマや命名が変わる可能性がある | Alert evidenceやMITRE tacticsを条件にする |
| 重大度だけで自動クローズ | XDR側の相関で影響範囲が変わる可能性がある | 重大度、エンティティ、信頼済み送信元、タグを組み合わせる |
| 個別Defenderコネクタ前提のクエリ | XDRコネクタ経由ではフィールド構造が変わる | XDRコネクタ移行後のサンプルデータで再作成する |
開発者や自動化担当者は、本番切り替え前に最低でも「検知」「チケット起票」「通知」「自動クローズ」「Playbook実行」の5つをテストしてください。
Advanced Huntingと自然言語KQLの使いどころ
Security Copilot in advanced huntingでは、Threat Hunting AgentとQuery assistantが案内されています。Query assistantは自然言語からKQLを作る用途に向いており、Threat Hunting Agentは複数ステップの調査や探索的な分析に向いています。ただし、一部情報はプレビュー製品に関するもので、仕様変更の可能性があります。(Microsoft Learn)
公式情報では、単純から中程度の複雑さのクエリ生成はサポートされる一方、join、filter、aggregationを組み合わせる複雑なケースでは正確性の検証が推奨されています。(Microsoft Learn)
実務では、次のように使い分けると安全です。
| 用途 | Copilotに任せやすい作業 | 人が必ず確認すべき作業 |
|---|---|---|
| 初期調査 | 過去24時間の高重大度インシデント一覧化 | 対象期間、ワークスペース、重大度条件 |
| KQL作成 | DeviceEventsやSecurityIncidentの基本クエリ生成 | join条件、タイムゾーン、誤検知除外条件 |
| レポート | 非技術者向けのインシデント要約 | 事実関係、影響範囲、対応完了の有無 |
| ハンティング | 疑わしいIP、ユーザー、デバイスを起点にした調査案 | 実行コスト、対象テーブル、データ保持期間 |
| 改善提案 | 再発防止策の候補提示 | 組織のポリシー、承認プロセス、実行責任者 |
Copilotが生成したKQLは、すぐに自動化ルールへ組み込まないでください。まず短い期間で実行し、件数、列、想定されるエンティティ、false positiveの傾向を確認します。特に本番環境で大量データを検索するクエリは、コストとパフォーマンスにも影響します。
Security Copilotの権限とデータ保護で確認すべきこと
Security Copilotは、オンビハーフ認証を使って有効なMicrosoftプラグイン経由でセキュリティ関連データへアクセスします。認証後、どのプラグインがプロンプトで使えるかは、Microsoft EntraやAzure RBACによって決まります。つまり、Copilotの画面に入れることと、SentinelやDefenderのデータにアクセスできることは別です。(Microsoft Learn)
展開前に、次の3層で権限を分けて確認してください。
| 層 | 何を制御するか | 例 |
|---|---|---|
| Security Copilotロール | Copilotプラットフォーム上の利用、設定、セッション作成 | Security Copilot owner、Security Copilot contributor |
| Microsoft Entraロール | Microsoft 365やセキュリティサービスへの管理権限 | Security Administrator、Security Readerなど |
| Azure RBAC | SentinelワークスペースやAzureリソースへのアクセス | Microsoft Sentinel Reader、Microsoft Sentinel Contributorなど |
Microsoftは、Security Copilotロールを個別ユーザーではなくセキュリティグループに割り当てることを推奨しています。また、一部の既存環境ではEveryoneグループがContributorアクセスに残っている可能性があるため、広すぎる付与がないか確認してください。(Microsoft Learn)
データ保護面では、Security CopilotのCustomer Dataには、ユーザーが入力したプロンプト、応答生成のために取得された情報、応答、ピン留め項目、アップロードファイルが含まれます。データ共有は既定で有効とされますが、Microsoft 365 E5/E7顧客では既定設定が異なる点にも触れられています。設定は、Global AdministratorやSecurity Administratorなど、必要な権限を持つ管理者が確認する必要があります。(Microsoft Learn)
導入・移行時の推奨手順
Security Copilot with Microsoft Sentinelを本番展開する場合は、機能を一気に全社展開するより、SOCの実業務に沿って段階的に導入するのが安全です。
| ステップ | 実施内容 | 完了の判断基準 |
|---|---|---|
| 現状棚卸し | Sentinelワークスペース、Defender XDR接続、既存コネクタ、KQL、Playbookを一覧化 | 影響を受けるルールとクエリが特定できている |
| 権限確認 | Security Copilotロール、Sentinel RBAC、Defender XDR権限を確認 | 最小権限で対象ユーザーが必要データを参照できる |
| 既定ワークスペース設定 | Security CopilotのMicrosoft Sentinelプラグインで既定ワークスペースを設定 | Copilotが正しいワークスペースのインシデントを返す |
| Defenderポータル接続 | SentinelワークスペースをDefenderポータルへ接続 | Home、Incidents、Advanced Huntingで想定データが見える |
| クエリ検証 | 主要なKQL、ワークブック、分析ルールを移行後スキーマで確認 | 検知件数と列構造が想定範囲に収まる |
| 自動化テスト | 通知、チケット連携、Playbook、自動クローズを検証 | 誤起動や未起動がない |
| SOCパイロット | 限定ユーザーでCopilotの要約、KQL生成、レポート作成を試す | 回答精度、利用ルール、レビュー手順が整う |
| 本番展開 | 利用者を拡大し、フィードバックと監査を定期確認 | 誤回答、権限過多、コスト増を継続的に監視できる |
特に、2025年7月1日以降にMicrosoft Sentinelへオンボードした一部環境では、条件を満たすとDefenderポータルへ自動的にオンボードされる場合があります。既存環境と新規環境でポータル体験が異なる可能性があるため、管理者は「どのワークスペースが、どのポータルで、どのコネクタ経由でデータを扱っているか」を明文化しておくべきです。(Microsoft Learn)
失敗しやすいポイントと対策
Copilotの回答をそのまま対応手順にしてしまう
Copilotは調査を加速するツールですが、最終判断を代替するものではありません。特に、隔離、ブロック、アカウント無効化、メール削除、チケット自動クローズなどの操作は、人の承認や既存の変更管理プロセスに組み込むべきです。
対策として、Copilotの回答を次の3段階で扱うと安全です。
| Copilotの出力 | 扱い方 |
|---|---|
| インシデント要約 | 初動把握に使うが、アラートとエンティティを確認する |
| 推奨対応 | 社内手順書や権限者の判断と照合する |
| KQL | 実行範囲を絞り、結果とコストを確認してから保存する |
既定ワークスペースを設定せずに複数環境で使う
複数ワークスペース環境では、既定ワークスペースの未設定や誤設定が調査ミスにつながります。本番、検証、海外拠点、MSSP管理環境が混在している場合は、プロンプトにワークスペース名を明示するルールを作ってください。
インシデントタイトル依存の自動化を残す
Defender XDR統合後は、インシデントタイトルが以前と同じとは限りません。タイトルではなく、タグ、重大度、ProductName、エンティティ種別、MITRE分類、カスタム属性など、変更に強い条件へ移行するのが現実的です。
Azureポータル前提の運用を放置する
Microsoft SentinelはDefenderポータルへの移行が進んでいます。2027年3月31日以降はAzureポータルでのSentinelサポートが終了し、Defenderポータルのみになるため、ブックマーク、ワークブック、データコネクタ、Automation、Analytics rule、運用手順書の場所を見直してください。(Microsoft Learn)
SOCで使いやすいプロンプト例
Security Copilot with Microsoft Sentinelでは、対象、期間、ワークスペース、出力形式を具体的に指定すると実務に使いやすくなります。
workspace "soc-prod-japan" で、過去24時間に作成されたHigh以上のMicrosoft Sentinelインシデントを一覧化してください。各インシデントについて、重大度、所有者、関連ユーザー、関連デバイス、推奨される初動対応を表で出してください。このSentinelインシデントについて、攻撃の流れ、影響を受けた資産、確認すべき追加ログ、推奨対応をSOCアナリスト向けに要約してください。経営層向けに、このインシデントの概要、事業影響、現在の封じ込め状況、今後の再発防止策を非技術者にも分かる表現でまとめてください。過去7日間で、同じIPアドレスまたは同じユーザーに関連するSentinelインシデントがないか調べるKQLを作成してください。実行前に、参照するテーブルと条件の意味も説明してください。公式のサンプルでも、インシデント番号、作成時刻、担当者、自分に割り当てられたインシデント、非技術者向けレポートなど、具体的な文脈を入れることが推奨されています。(Microsoft Learn)
開発者・自動化担当者が確認すべき実装ポイント
開発者や自動化担当者は、Security Copilotの有効化そのものよりも、既存の検知・通知・連携が壊れないかを重点的に確認してください。
| 項目 | 確認内容 |
|---|---|
| KQLの互換性 | XDRコネクタ移行後も、既存クエリが同じ列と値を返すか |
| スキーマ差分 | SecurityAlert、SecurityIncident、AlertInfo、AlertEvidenceの使用列を洗い出す |
| Playbook | インシデントタイトルや旧コネクタ由来のフィールドに依存していないか |
| チケット連携 | ServiceNow、Jira、メール通知などに送るフィールドが空にならないか |
| API連携 | Sentinel APIやGraph APIから取得するID、状態、分類が変わらないか |
| コスト | Advanced huntingイベントの取り込みやログ保持設定が意図せず増えないか |
| 監査 | Copilotの利用者、プロンプト、応答、共有セッションの扱いが社内ルールに合うか |
Microsoftは、Microsoft SentinelとDefender XDRをまたいだ新しいルール作成では、Defender側のcustom detectionsを活用する方向性も示しています。一方で、Microsoft Sentinelのanalytics rulesも引き続き利用できます。新規検知を作る場合は、どちらで作ると運用、コスト、レスポンスアクション、エンティティマッピングの面で有利かを比較してください。(Microsoft Learn)
まず実施すべき対応
Security Copilot with Microsoft Sentinelの更新で、管理者がすぐに行うべきことは3つです。
まず、Security CopilotのMicrosoft Sentinelプラグインを確認し、既定ワークスペースを正しく設定します。次に、Microsoft SentinelとMicrosoft Defenderポータル、Defender XDRコネクタの接続状態を確認し、既存の個別Defenderコネクタや自動化ルールへの影響を洗い出します。最後に、SOCアナリスト向けに、Copilotの回答を検証する手順、KQLのレビュー方法、権限とデータ共有のルールを整備します。
この連携は、Microsoft DefenderとMicrosoft Sentinelを単に同じ画面で見られるようにするだけではありません。インシデント調査、ハンティング、レポート作成、自動化の設計を見直すきっかけになります。まずは限定ユーザーと検証ワークスペースで動作を確認し、既存のKQL、Playbook、RBAC、データ保護設定を点検してから本番展開へ進めるのが安全です。
コメント