Azure の「Create incidents from alerts in Microsoft Sentinel」で最初に押さえるべき結論は、Microsoft Sentinel に Microsoft セキュリティ製品のアラートを接続しても、既定では Sentinel インシデントは自動作成されないという点です。自動作成したい場合は、データコネクタや Microsoft security rule を使って「どのアラートをインシデント化するか」を明示的に設定します。ただし、Microsoft Defender XDR incident integration を有効化している環境、または Microsoft Sentinel を Microsoft Defender ポータルへオンボード済みの環境では、この設定の考え方が変わります。該当環境では Defender XDR の相関エンジンがインシデント作成を担うため、従来の Microsoft Sentinel 側の incident creation rules をそのまま前提にしないことが重要です。(Microsoft Learn)
なお、Microsoft Learn の該当ページは確認時点で「Last updated on 2026-06-15」と表示されています。本記事では、2026年6月29日時点で管理者が確認すべき関連公式情報を含め、影響範囲、設定変更、移行期限、確認ポイントを実務向けに整理します。(Microsoft Learn)
Azure の「Create incidents from alerts in Microsoft Sentinel」とは
「Create incidents from alerts in Microsoft Sentinel」は、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps など、Microsoft Sentinel に接続した Microsoft セキュリティソリューションのアラートから、Microsoft Sentinel のインシデントを自動作成するための設定です。
ここで混同しやすいのは、「アラートの取り込み」と「インシデントの作成」は別の処理だという点です。Microsoft セキュリティソリューションを Microsoft Sentinel に接続すると、アラートは SecurityAlert テーブルに取り込まれます。しかし、それだけでは SOC が調査対象として扱うインシデントにはなりません。インシデントとして扱うには、データコネクタの推奨設定や Microsoft security rule を有効化する必要があります。(Microsoft Learn)
実務では、次のような場面でこの設定が役立ちます。
| 利用シーン | 具体例 | 設定の考え方 |
|---|---|---|
| Microsoft 製品の重要アラートを Sentinel のインシデントキューで扱いたい | Microsoft Defender for Identity の高重大度アラートを SOC が必ず調査する | 重大度やアラート名で絞り込んでインシデント化する |
| アラートは多いが、すべてをインシデントにしたくない | 低重大度アラートまでインシデント化するとノイズが増える | High / Medium などに絞る |
| Sentinel の自動対応ルールや playbook と連携したい | インシデント作成時に Teams 通知、チケット作成、所有者割り当てを行う | Automated response で automation rule を設定する |
| Defender XDR ではなく Sentinel 側で運用を継続している | Azure portal の Microsoft Sentinel を中心に調査している | Microsoft security rule の適用可否を確認する |
今回の更新ポイントで最も重要なこと
今回確認すべき最大のポイントは、この設定がすべての Microsoft Sentinel 環境に当てはまるわけではないことです。
Microsoft Learn では、この手順が適用されないケースとして、Microsoft Defender XDR incident integration を有効化している場合、または Microsoft Sentinel を Microsoft Defender ポータルにオンボードしている場合を明記しています。これらの環境では、Microsoft Defender XDR が Microsoft サービス由来のアラートを相関し、インシデントを生成します。(Microsoft Learn)
適用される環境と適用されない環境
| 環境の状態 | この設定の扱い | 管理者が見るべき場所 |
|---|---|---|
| Microsoft Sentinel を Azure portal 中心で利用している | 適用対象になり得る | Sentinel の Data connectors、Analytics、Active rules |
| Microsoft セキュリティ製品のアラートを取り込んでいるが、インシデントが作られていない | 設定確認が必要 | SecurityAlert テーブルと Microsoft security rule |
| Microsoft Defender XDR incident integration を有効化済み | 原則、この手順の対象外 | Defender XDR connector、Defender 側のインシデント相関 |
| Microsoft Sentinel を Microsoft Defender ポータルへオンボード済み | 原則、この手順の対象外 | Microsoft Defender ポータルの incidents / alerts |
| Defender XDR に統合されていない Microsoft セキュリティ製品を使っている | scheduled analytics rules への置き換えを検討 | Analytics rule、KQL、automation rule |
この整理をせずに設定を追加すると、同じアラートから重複インシデントが作成されたり、想定していた automation rule が動作しなかったりする可能性があります。特にグローバル企業で複数リージョン、複数ワークスペース、複数 SOC を運用している場合は、ワークスペース単位で「誰がインシデントを作っているのか」を確認してください。
影響範囲：既存の Sentinel 運用で何が変わるのか
この更新は、新しい検出エンジンを強制的に有効化するものではありません。影響の中心は、Microsoft セキュリティ製品のアラートを Sentinel インシデントに変換する責任範囲の整理です。
影響を受けやすい運用
影響を受けやすいのは、次のような運用です。
| 運用パターン | 影響 |
|---|---|
| Microsoft security incident creation rules を使っている | Defender ポータル移行時に無効化・非対応になる可能性を確認する |
| インシデント名を条件に automation rule を動かしている | Defender XDR の相関エンジンがインシデント名を決めるため、条件が合わなくなる可能性がある |
| Microsoft Defender for Identity や Defender for Office 365 のアラートを Sentinel 側で細かく絞り込んでいる | Defender XDR 連携後は alert tuning や automation rule で代替設計が必要になる |
| 外部チケットシステムと Sentinel インシデントを連携している | インシデント作成元、URL、同期遅延、フィールド差分を確認する |
| Azure portal の Sentinel を主画面として使っている | 2027年3月31日後の Defender ポータル移行を前提に運用変更が必要 |
Microsoft Defender XDR と Microsoft Sentinel を統合すると、Defender XDR のインシデントは Microsoft Sentinel でも表示・管理でき、状態、所有者、クローズ理由などの双方向同期が利用できます。一方で、Defender XDR 側の相関やグルーピングが主導するため、従来の Sentinel 側のインシデント作成ルールと完全に同じ挙動を期待しない方が安全です。(Microsoft Learn)
設定方法：データコネクタから自動インシデント作成を有効化する
最も直接的な方法は、Microsoft Sentinel のデータコネクタで「Create incidents – Recommended」を有効化することです。
基本の流れは次のとおりです。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Sentinel の Content Hub から対象ソリューションを導入する | 対象製品のデータコネクタが利用可能か |
| 2 | Microsoft セキュリティソリューションのデータソースを接続する | アラートが SecurityAlert に入っているか |
| 3 | データコネクタ画面で「Create incidents – Recommended」を探す | 表示されない場合は Defender XDR 連携や Defender ポータルオンボード済みの可能性 |
| 4 | Enable を選択する | 既定の analytics rule が有効化される |
| 5 | Analytics > Active rules でルールを確認・編集する | 重大度、名称、対象サービス、automation を調整する |
「Create incidents – Recommended」が表示されない場合、Microsoft Defender XDR connector の incident integration が有効になっている、または Microsoft Sentinel が Defender ポータルにオンボードされている可能性があります。この場合、Microsoft Sentinel 側で無理に同等設定を探すのではなく、Defender XDR の相関エンジンでインシデントが作成される前提で確認してください。(Microsoft Learn)
Microsoft Security template からルールを作成する方法
より細かく制御したい場合は、Microsoft Sentinel の Analytics から Microsoft security rule template を使います。Microsoft Sentinel には、Microsoft Defender for Endpoint、Microsoft Defender for Cloud、Microsoft Defender for Identity など、Microsoft ソースごとのテンプレートが用意されています。(Microsoft Learn)
設定時に重要なのは、すべてのアラートをインシデント化しないことです。たとえば Microsoft Defender for Identity の High severity だけを対象にすれば、SOC が調査すべきアラートを絞り込めます。Microsoft Learn でも、重大度やアラート名の文字列でフィルターできることが説明されています。(Microsoft Learn)
実務で使いやすいフィルター設計例
| 目的 | フィルター例 | 判断基準 |
|---|---|---|
| 重大な ID 攻撃を優先調査する | Microsoft Defender for Identity、Severity = High | アカウント侵害の初動対応を重視する場合 |
| 低ノイズ運用から始める | Severity = High のみ | 初期導入、SOC 人員が少ない環境 |
| フィッシング対応を強化する | Defender for Office 365 の特定アラート名を対象 | メール起点のインシデントが多い組織 |
| クラウドアプリのリスクだけを切り出す | Defender for Cloud Apps の高リスクアラート | SaaS 利用が多いグローバル企業 |
| 自動対応を限定する | 特定アラートのみ automation rule を付与 | 誤検知時の自動隔離や通知過多を避ける |
複数の Microsoft Security analytics rule を作ることも可能ですが、同じサービスに複数ルールを作る場合は、フィルター条件が重ならないようにします。フィルターが重複すると、意図しないノイズや運用混乱につながります。(Microsoft Learn)
Defender ポータル移行を前提にした設定変更の考え方
Microsoft Sentinel は Microsoft Defender ポータルで一般提供されており、Microsoft Defender XDR や E5 ライセンスがない顧客でも Defender ポータル上で Sentinel を利用できます。Microsoft は、2027年3月31日後に Microsoft Sentinel が Azure portal でサポートされなくなり、Defender ポータルでのみ利用可能になると案内しています。(Microsoft Learn)
このため、今から新しく incident creation rules を増やす場合は、短期的な Azure portal 運用だけでなく、Defender ポータル移行後の挙動まで見て設計する必要があります。
移行時に特に注意すべき変更
| 項目 | Azure portal 中心の Sentinel | Defender ポータル移行後の考え方 |
|---|---|---|
| Microsoft incident creation rules | Sentinel 側で利用 | Defender ポータルでは非対応。オンボード時に無効化される場合がある |
| インシデント作成 | Sentinel の rule 設定が中心 | Defender XDR の相関エンジンが主導 |
| インシデント名 | ルールや設定に依存 | Defender XDR の相関ロジックで自動命名される可能性 |
| アラート絞り込み | incident creation rules で実施 | alert tuning、automation rule、scheduled analytics rules で代替 |
| Fusion | Azure portal の Fusion rule | Defender XDR の相関機能が役割を代替 |
| automation | Sentinel automation rule / playbook | 同期遅延やトリガー範囲の違いを確認 |
Microsoft Learn では、Microsoft incident creation rules は Defender ポータルではサポートされず、Defender XDR 連携製品では重複インシデントを避けるために incident creation rules の設定がオフになると説明されています。また、Defender XDR に統合されていない Microsoft セキュリティ製品やサービスで同様の制御が必要な場合は、scheduled analytics rules への置き換えが案内されています。(Microsoft Learn)
scheduled analytics rules へ置き換えるべきケース
今後も Sentinel 側で検出条件を明示的に管理したい場合は、scheduled analytics rules を検討します。これは KQL を定期実行し、一定条件を満たした場合にアラートやインシデントを生成するルールです。Microsoft Learn では、scheduled rules は指定した lookback period のデータを Kusto query で調べ、しきい値を超えた場合にアラートを生成する一般的な analytics rule と説明されています。(Microsoft Learn)
置き換え判断の目安
| 置き換えを検討する状況 | 理由 |
|---|---|
| Defender XDR に統合されていない Microsoft 製品のアラートを扱う | Microsoft incident creation rules の代替として使いやすい |
| アラート名や重大度だけでは絞り込みが足りない | KQL でユーザー、IP、デバイス、国、回数などを条件にできる |
| SOC の調査対象を業務リスクに合わせて定義したい | 例：役員アカウント、特権アカウント、海外拠点からのアクセスを優先 |
| 自動対応前にしきい値を入れたい | 単発アラートではなく、短時間の複数イベントでインシデント化できる |
| Defender ポータル移行後も検出ロジックを維持したい | Sentinel analytics rules は Defender ポータルでも管理対象になる |
たとえば、単に「High severity のアラートをすべてインシデント化」するのではなく、「特権アカウントに関連する High severity アラートのみ」「海外拠点では通常発生しないクラウドアプリ操作のみ」といった条件を KQL で設計すると、調査キューの品質が上がります。
Custom detections も選択肢に入れる
新規の検出ルールを設計する場合は、Microsoft Defender XDR の custom detections も確認しておくべきです。Microsoft Learn の該当ページでは、custom detections を Microsoft Sentinel SIEM と Microsoft Defender XDR の横断的な新規ルール作成に適した方法として案内しており、advanced hunting クエリをもとにアラートや自動応答を実行できると説明しています。(Microsoft Learn)
特に Defender XDR と Sentinel の両方を使う組織では、「どの検出を Sentinel の scheduled analytics rules に置くか」「どの検出を Defender XDR の custom detections に置くか」を分けて考えると、運用が整理しやすくなります。
| 選択肢 | 向いているケース |
|---|---|
| Microsoft Security template | Microsoft 製品アラートを手早くインシデント化したい |
| Microsoft incident creation rule | Azure portal 中心の既存 Sentinel 運用で使っているが、移行影響に注意 |
| scheduled analytics rule | KQL で柔軟に条件を作り、Sentinel 検出として維持したい |
| custom detections | Defender XDR / Defender ポータル中心で横断的に検出と応答を設計したい |
| alert tuning / automation rule | Defender XDR 連携後にノイズ抑制や自動クローズを行いたい |
管理者が確認すべきチェックリスト
実際の管理では、いきなり設定を変更するよりも、現在のインシデント作成経路を棚卸しすることが先です。
| 確認項目 | 確認方法 | 対応の目安 |
|---|---|---|
| Sentinel が Defender ポータルにオンボード済みか | Microsoft Defender ポータル、Sentinel workspace 設定を確認 | オンボード済みなら Defender XDR 相関を前提にする |
| Defender XDR connector の incident integration が有効か | Microsoft Sentinel の Data connectors を確認 | 有効なら Microsoft incident creation rules の重複に注意 |
SecurityAlert にアラートが入っているか | Logs で SecurityAlert を確認 | 入っているが incident がない場合は rule 設定を確認 |
| Microsoft security rule が有効か | Analytics > Active rules を確認 | 不要なルールや重複条件を整理 |
| 重大度・アラート名のフィルターが適切か | 直近30日程度のアラート件数を確認 | ノイズが多ければ High のみにするなど調整 |
| automation rule が incident name に依存していないか | Automation の条件を確認 | タグ、重大度、製品名、エンティティ条件へ変更 |
| 外部チケット連携に影響がないか | ServiceNow、Jira、ITSM、Logic Apps のマッピングを確認 | Defender ポータル移行後の URL・フィールド差分を検証 |
| 2027年3月31日後の運用を決めているか | 移行計画、権限、SOC 手順を確認 | Azure portal 前提の手順書を更新 |
失敗しやすいポイント
すべての Microsoft アラートをインシデント化してしまう
初期設定でありがちな失敗は、接続した Microsoft セキュリティ製品のアラートを広くインシデント化しすぎることです。これにより、SOC のキューが低優先度アラートで埋まり、重要インシデントの初動が遅れることがあります。
最初は High severity や特定製品に限定し、件数と誤検知傾向を見ながら対象を広げる方が現実的です。
Defender XDR と Sentinel の二重作成を見落とす
Defender XDR incident integration を使っているのに、Sentinel 側でも同じ Microsoft アラートからインシデントを作ろうとすると、重複や調査分断の原因になります。Microsoft Learn でも、重複インシデントを避けるため、Defender XDR 統合製品では Microsoft incident creation rules がオフになることが説明されています。(Microsoft Learn)
インシデント名を自動化条件に使いすぎる
Defender XDR 連携後は、相関エンジンがインシデント名を決めるため、従来の命名規則を前提にした automation rule が動かなくなる可能性があります。条件には、インシデント名だけでなく、製品名、重大度、タグ、エンティティ、analytics rule name などを組み合わせる方が安全です。
移行期限を「まだ先」と考える
Microsoft Sentinel の Azure portal サポート終了は 2027年3月31日後と案内されています。グローバル環境では、権限設計、SOC 手順、監査対応、チケット連携、データ所在地の確認に時間がかかります。年度末や監査サイクルと重なる組織では、2026年中に検証環境で Defender ポータル移行後のインシデント作成・自動化・通知を確認しておくと安全です。(Microsoft Learn)
グローバル運用で追加確認すべきポイント
多国籍企業や複数リージョンで Azure / Microsoft Sentinel を運用している場合は、単一ワークスペースの設定だけでは不十分です。
特に確認したいのは次の点です。
| 観点 | 確認内容 |
|---|---|
| 複数ワークスペース | どのワークスペースが primary workspace として扱われるか |
| 複数テナント | Defender ポータル側の RBAC と Sentinel 側の Azure RBAC の差分 |
| データ所在地 | Defender ポータル移行後のデータ保管・処理・共有ポリシー |
| CMK 利用 | Customer-managed key を使っている場合の暗号化範囲 |
| SOC 分担 | 地域 SOC とグローバル SOC のインシデント所有者ルール |
| 自動化 | Logic Apps、ITSM、通知、メール、Teams 連携の同期遅延 |
Microsoft の移行ガイドでは、Azure portal 利用時と Defender ポータル利用時でデータ保管、処理、保持、共有のポリシーが異なることが示されています。また、CMK を有効化している環境では、オンボード後も Log Analytics ワークスペース内のログは CMK で暗号化される一方、アラートやインシデントはオンボード後に CMK 暗号化の対象外になる点が説明されています。規制業種やデータ主権要件がある組織は、技術設定だけでなくコンプライアンス部門とも確認してください。(Microsoft Learn)
次に取るべき行動
Azure の「Create incidents from alerts in Microsoft Sentinel」は、Microsoft セキュリティ製品のアラートを Sentinel インシデントとして扱うための重要な設定です。ただし、2026年時点では Microsoft Defender XDR との統合、Defender ポータルへの移行、custom detections の利用拡大により、従来の「Sentinel 側でインシデント作成ルールを作る」だけでは最適解にならないケースが増えています。
まずは、現在の環境が次のどれに当たるかを確認してください。
| 現在の状態 | 次のアクション |
|---|---|
| Azure portal の Sentinel を中心に使っている | データコネクタと Microsoft security rule の有効化状況を確認する |
| アラートはあるがインシデントが作られない | SecurityAlert と Analytics rule を確認する |
| Defender XDR integration を有効化済み | Sentinel 側の incident creation rules ではなく Defender XDR の相関を確認する |
| Defender ポータルへ移行予定 | Microsoft incident creation rules を scheduled analytics rules、alert tuning、custom detections に置き換える計画を立てる |
| グローバル運用・規制対応がある | データ所在地、RBAC、CMK、ITSM 連携、SOC 手順を移行前に検証する |
最も安全な進め方は、既存ルールを一覧化し、「残す」「scheduled analytics rules に置き換える」「Defender XDR の alert tuning に寄せる」「custom detections へ移す」に分類することです。これにより、重複インシデント、通知漏れ、移行後の自動化停止を避けながら、Microsoft Sentinel と Microsoft Defender XDR の統合運用へ移行できます。
コメント