Azure の「Investigate incidents with Microsoft Sentinel (legacy)」は、Microsoft Sentinel のインシデントを Azure portal 上の旧調査画面で確認・割り当て・調査するための手順です。結論から言うと、今すぐ機能が使えなくなる変更ではありませんが、Microsoft Sentinel の運用画面は Microsoft Defender portal へ移行する流れが明確になっており、旧画面を前提にした SOC 手順書、権限設計、プレイブック、チケット連携は見直しが必要です。
特に重要なのは、2026年6月24日に更新された Microsoft Learn の移行情報で、Defender portal への移行時にインシデント、アラート相関、コメント、Automation rules、Playbooks、外部チケット連携に影響する差分が整理された点です。旧来の「Investigate incidents with Microsoft Sentinel (legacy)」を使っている管理者は、単なる画面変更ではなく、調査プロセス全体の移行計画として捉えるべきです。(Microsoft Learn)
Azure の「Investigate incidents with Microsoft Sentinel (legacy)」とは
「Investigate incidents with Microsoft Sentinel (legacy)」は、Microsoft Sentinel の従来型インシデント調査エクスペリエンスを使うための公式手順です。対象は「Microsoft Sentinel in the Azure portal」であり、新しいインターフェイスを使う場合は別の手順を参照する位置づけになっています。(Microsoft Learn)
Microsoft Sentinel では、Analytics rules によって検出されたアラートをもとにインシデントが作成されます。インシデントは単一の警告ではなく、複数のアラート、関連エンティティ、重大度、ステータス、MITRE ATT&CK の戦術・技術などをまとめた調査単位です。つまり、SOC の担当者は「アラートを1件ずつ見る」のではなく、「インシデント単位で証拠を集約し、担当者を割り当て、対応履歴を残す」運用を行います。(Microsoft Learn)
旧画面でできる主な作業は、次のとおりです。
| 作業 | 旧インシデント調査画面で確認する内容 | 実務での使いどころ |
|---|---|---|
| インシデント一覧の確認 | New、Active、Closed などの状態、重大度、発生時刻 | 優先順位付け、当番者への割り当て |
| 詳細確認 | アラート、エンティティ、ブックマーク、コメント | 侵害範囲の把握、調査証跡の整理 |
| Investigation graph | エンティティ同士の関係、関連アラート、タイムライン | 攻撃の広がりや起点の推定 |
| Owner / Status の更新 | 担当者、対応状態、クローズ分類 | SOC 内の引き継ぎ、対応完了管理 |
| Playbook 実行 | アラートやインシデントに対する自動処理 | 外部調査、通知、封じ込め処理 |
今回の更新ポイントは「旧画面の使い方」より「移行前提の見直し」
今回確認すべきポイントは、旧画面の操作手順そのものが大きく変わったというより、旧画面を前提にした運用がいつまで安全に続けられるか、Defender portal 移行後に何が変わるかです。
Microsoft は、Microsoft Sentinel が Microsoft Defender portal でも一般提供されており、Microsoft Defender XDR や E5 ライセンスがなくても利用できると説明しています。また、2027年3月31日以降、Microsoft Sentinel は Azure portal ではサポートされず、Microsoft Defender portal のみで利用する形になります。(Microsoft Learn)
このため、旧画面を使っている組織は、次のように考えると整理しやすくなります。
| 観点 | 旧画面での考え方 | 移行に向けた考え方 |
|---|---|---|
| 日々のインシデント対応 | Azure portal の Incidents で確認 | Defender portal の Incidents & alerts を標準手順にする |
| 調査画面 | Timeline、Alerts、Entities、Bookmarks、Comments を中心に確認 | Defender portal の統合インシデント画面、Advanced hunting、Entity page に慣れる |
| 相関・マージ | Sentinel 側のインシデント設計を中心に考える | Defender XDR の相関エンジンによる統合インシデントを前提にする |
| 自動化 | Sentinel の Automation rules / Playbooks を中心に設計 | Defender portal 移行後の制限、遅延、トリガー差分を確認する |
| 権限管理 | Azure RBAC / Sentinel ロールを中心に管理 | Unified RBAC や Defender portal 側の権限設計を検討する |
影響範囲：誰が確認すべきか
今回の影響を受けやすいのは、Microsoft Sentinel を単に閲覧しているユーザーだけではありません。インシデント対応を自動化している組織、複数ワークスペースを運用している組織、外部チケットシステムと連携している組織ほど、早めの確認が必要です。
SOC アナリスト
SOC アナリストは、インシデントの優先順位付け、担当者の割り当て、調査コメント、クローズ分類の手順を見直す必要があります。旧画面では、Timeline、Similar incidents、Alerts、Bookmarks、Entities、Comments の各タブを使って調査を進めます。Similar incidents では、現在のインシデントに似た過去または同時期のインシデントを最大20件確認でき、類似性はエンティティ、ルール、アラート詳細などから算出されます。(Microsoft Learn)
ただし、移行後の Defender portal では、Microsoft Sentinel の Similar incidents 機能はサポートされず、インシデント詳細ページに Similar incidents タブは表示されないとされています。旧画面で Similar incidents を調査の起点にしているチームは、代替として Defender portal の統合インシデント、Entity page、Advanced hunting、タグ、保存クエリを使う手順を用意しておくべきです。(Microsoft Learn)
Microsoft Sentinel 管理者
管理者は、Analytics rules のエンティティマッピングを確認する必要があります。旧画面の Investigation graph は、元のインシデントにエンティティが含まれていることを前提とするため、Analytics rule 作成時に entity mapping を設定していないと十分に活用できません。また、ゲストユーザーがインシデントを割り当てる場合は、Microsoft Entra tenant で Directory Reader ロールが必要です。(Microsoft Learn)
これは移行前後を問わず重要です。エンティティマッピングが不十分なルールは、調査グラフ、相関、UEBA、Advanced hunting での分析価値が下がります。移行準備として、まずは重大度 High / Medium の Analytics rules から entity mapping と custom details を棚卸しするのが現実的です。
SOAR / 自動化担当者
Automation rules や Playbooks を使っている場合は、移行後の動作差分を必ず確認してください。Microsoft Learn では、Defender portal 移行後、SecurityIncident テーブルに Description フィールドが含まれなくなるため、この Description を条件にしているインシデント作成トリガーの Automation rule は動作しなくなる可能性があると説明されています。また、ServiceNow など外部チケットシステムとの連携で incident description を使っている場合、説明文が欠落する可能性があります。(Microsoft Learn)
さらに、Defender portal で作成・更新されたインシデントが Microsoft Sentinel 側に反映されるまで時間がかかる場合があり、Playbook のトリガーにも遅延が出ることがあります。複数の変更が短時間に連続した場合、中間更新が失われる可能性にも注意が必要です。(Microsoft Learn)
設定変更で確認すべきポイント
旧画面を使い続ける場合でも、移行を見据えるなら「今の設定が Defender portal でも同じ意味で動くか」を確認する必要があります。
Analytics rules とインシデント生成
Microsoft Sentinel の Analytics rules は Defender portal でも検出、設定、管理が可能で、ルールの作成や更新といった基本機能は維持されます。一方で、Defender portal では Defender XDR の相関エンジンがアラートのグルーピングやインシデントのマージを制御するため、Azure portal 時代と同じ単位でインシデントが作られるとは限りません。(Microsoft Learn)
実務上は、次のような影響が出やすくなります。
| 確認項目 | 起こり得る変化 | 管理者の対応 |
|---|---|---|
| 1アラート1インシデント前提の運用 | Defender XDR の相関で複数アラートが統合される | チケット起票条件をインシデント単位で再確認する |
| ルール名を条件にした自動化 | 特定ルール由来のアラートだけに限定される場合がある | Automation rule の条件を検証環境で再テストする |
| Fusion ルール前提の設計 | Defender portal では Fusion analytics rule が無効化される | Defender XDR の相関エンジン前提で検知品質を確認する |
| Alert only の設定 | インシデント作成を無効にしたアラートは Defender portal で見えない可能性 | 重要な検知はインシデント生成設定を見直す |
特に「既存の SOC KPI がインシデント件数を基準にしている」場合は注意が必要です。相関やマージの挙動が変わると、実際の脅威量が同じでも、月次レポート上のインシデント件数が変わる可能性があります。
コメントと調査証跡
旧画面では、Comments タブで調査メモを残し、他のアナリストのコメントも確認できます。コメントはプレーンテキスト、基本的な HTML、Markdown に対応し、1コメントあたり最大30,000文字、1インシデントあたり最大100コメントという制限があります。(Microsoft Learn)
移行後は、コメントの扱いに差分があります。Microsoft Learn では、Defender portal と Azure portal のどちらでもコメント追加は可能ですが、Defender portal では既存コメントの編集はサポートされず、Azure portal 側で編集したコメントは Defender portal に同期されないと説明されています。(Microsoft Learn)
そのため、監査や引き継ぎでコメントを重視している組織は、次のルールを決めておくと混乱を避けやすくなります。
| 運用ルール | 推奨内容 |
|---|---|
| コメントの追記方針 | 既存コメントを編集するのではなく、追記で履歴を残す |
| 調査メモの形式 | 「確認事項」「判断理由」「実施した封じ込め」「未解決事項」をテンプレート化する |
| 外部チケット連携 | Sentinel コメントとチケットコメントのどちらを正とするか決める |
| 証跡保全 | 重大インシデントはコメントだけでなく、関連クエリやブックマークも保存する |
移行期限：2027年3月31日を前提に計画する
Microsoft は、2027年3月31日以降、Microsoft Sentinel は Azure portal でサポートされず、Microsoft Defender portal のみで利用可能になると説明しています。Azure portal を使っている顧客は Defender portal にリダイレクトされるため、期限直前に画面操作だけを覚えるのではなく、運用・権限・自動化・レポートを含めた移行計画が必要です。(Microsoft Learn)
移行計画は、次の順序で進めると現場への影響を抑えやすくなります。
| フェーズ | 実施内容 | 目安 |
|---|---|---|
| 現状把握 | 利用中のワークスペース、Analytics rules、Automation rules、Playbooks、外部連携を棚卸し | まず着手 |
| 差分確認 | Defender portal での画面位置、権限、インシデント生成、相関、コメントの違いを確認 | 棚卸し後 |
| 並行運用 | 一部チームまたは一部ワークスペースで Defender portal の運用手順を試す | 本格移行前 |
| 手順書更新 | SOC ランブック、エスカレーション基準、チケット連携手順を更新 | 並行運用中 |
| 本番切り替え | Azure portal 前提の作業を段階的に廃止 | 期限前に完了 |
旧画面の調査で押さえるべき実務ポイント
旧画面をまだ使う場合も、調査品質を上げるために確認すべき点は明確です。
重大度だけでなく「影響範囲」で優先順位を決める
インシデント一覧では重大度を見て対応順を決められますが、重大度だけで判断すると見落としが発生します。たとえば Medium のインシデントでも、対象エンティティが特権アカウント、ドメインコントローラー、VPN ゲートウェイ、重要な SaaS 管理者であれば、High と同等に扱うべきケースがあります。
旧画面では、インシデント詳細でエンティティ、アラート、MITRE ATT&CK の戦術・技術、Raw events を確認できます。初動では次の順番で見ると判断が速くなります。(Microsoft Learn)
| 順番 | 確認するもの | 判断ポイント |
|---|---|---|
| 1 | Severity / Status | 既に対応中か、新規か、緊急度は高いか |
| 2 | Entities | 重要ユーザー、重要端末、外部 IP、機密システムが含まれるか |
| 3 | Timeline | 単発か、複数段階の攻撃に見えるか |
| 4 | Alerts | どの Analytics rule が検知したか |
| 5 | Events / Log Analytics | 実際のログで誤検知かどうか確認できるか |
Investigation graph は「きれいな図」ではなく仮説整理に使う
Investigation graph は、アラートとエンティティの関係を視覚的に確認できる機能です。エンティティを選択し、探索クエリを使って関連アラートや追加情報を広げられます。グラフは侵害範囲や根本原因の把握に役立ちますが、利用には元のインシデントにエンティティが含まれていることが必要で、調査できるインシデントは最大30日前までという制限があります。(Microsoft Learn)
実務では、グラフを最終証拠として扱うのではなく、次に見るべきログや関連エンティティを決めるための仮説整理に使うのが適切です。たとえば、侵害疑いのユーザーから複数のホスト、外部 IP、ファイルハッシュに線が伸びている場合、まずユーザーのサインイン履歴、次に端末のプロセス実行、最後に外部通信を確認する、といった調査順を決められます。
クローズ分類は後日の改善に使える粒度で残す
インシデントを解決したら、Status を Closed にし、分類理由を選びます。旧画面では、True Positive、Benign Positive、False Positive – incorrect alert logic、False Positive – incorrect data、Undetermined などの分類が用意されており、クローズ時にはコメントを追加できます。(Microsoft Learn)
ここで「対応済み」「問題なし」だけを書いてしまうと、後から検知ルールを改善できません。最低限、次の3点をコメントに残すと、運用改善に使いやすくなります。
| コメント項目 | 例 |
|---|---|
| 判断理由 | 管理者の予定作業と変更申請番号が一致したため Benign Positive と判断 |
| 確認した証拠 | SigninLogs、DeviceProcessEvents、Firewall ログを確認し、不審な横展開なし |
| 次の対応 | 同様の予定作業で誤検知するため、対象端末グループを例外条件に追加予定 |
Defender portal 移行で失敗しやすいポイント
Azure portal の画面名をそのまま手順書に残す
Defender portal では、Microsoft Sentinel の機能配置が変わります。たとえば Azure portal の Incidents は、Defender portal では Investigation & response > Incidents & alerts > Incidents に相当します。Logs は Advanced hunting 側に移り、Data connectors、Analytics、Automation なども Microsoft Sentinel セクション内の別メニューとして整理されます。(Microsoft Learn)
手順書に「Azure portal で Sentinel を開く」「左メニューの Threat management を開く」とだけ書かれている場合、移行後に現場が迷う原因になります。画面名だけでなく、目的ベースで書き換えるのが有効です。
| 古い書き方 | 移行を見据えた書き方 |
|---|---|
| Azure portal の Incidents を開く | Defender portal の Incidents & alerts で対象インシデントを検索する |
| Logs でクエリを実行する | Advanced hunting または Sentinel の Logs 相当画面で KQL を実行する |
| Comments タブに記録する | インシデントの Activity / Comments に判断理由を追記する |
| Playbook を手動実行する | Defender portal でサポートされる実行方法か確認してから実行する |
外部チケット連携を後回しにする
ServiceNow、Jira、独自の ITSM、メール通知、Teams 通知などと連携している場合、画面移行よりも外部連携の検証が重要です。特に incident URL、incident description、provider name、status 変更、owner 変更を使っている連携は、フィールド差分や同期遅延の影響を受けやすくなります。Microsoft Learn では、Defender portal 移行後のレスポンス項目として providerIncidentUrl などの違いも示されています。(Microsoft Learn)
本番移行前に、少なくとも次のテストを行ってください。
| テスト | 確認内容 |
|---|---|
| 新規インシデント起票 | チケットが重複作成されないか |
| ステータス変更 | Active / Closed の変更が正しく同期されるか |
| 担当者変更 | Owner 情報が期待通り反映されるか |
| コメント追加 | 調査コメントがチケット側に必要な粒度で残るか |
| クローズ分類 | True Positive / False Positive などの分類がレポートに反映されるか |
「旧画面が使える間は何もしない」と判断する
旧画面がまだ使えるからといって、移行対応を後回しにするのは危険です。理由は、画面の切り替えそのものよりも、SOC の判断基準、チケット運用、検知ルール、自動化、権限設計の見直しに時間がかかるためです。
特にグローバル環境では、地域ごとにワークスペース、データ保持、監査要件、担当チームが異なることがあります。日本、米国、欧州などで運用ポリシーが分かれている場合は、まず共通の調査テンプレートとクローズ分類を定義し、その上で地域差分を吸収する方が移行しやすくなります。
管理者向けチェックリスト
Microsoft Sentinel 管理者は、次のチェックリストを使って現状を確認してください。
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| Azure portal 利用状況 | どのチームが旧画面でインシデント調査しているか | 高 |
| Defender portal 利用可否 | 対象テナント、ワークスペースが Defender portal にオンボード可能か | 高 |
| 権限 | Sentinel ロール、Azure RBAC、Unified RBAC、ゲストユーザー権限を確認 | 高 |
| Analytics rules | Entity mapping、custom details、incident creation 設定を確認 | 高 |
| Automation rules | Description など移行後に使えない可能性がある条件を確認 | 高 |
| Playbooks | 手動実行、トリガー、遅延、外部 API 連携を検証 | 高 |
| チケット連携 | incident URL、description、status、owner、classification の同期を確認 | 高 |
| コメント運用 | 編集前提の運用を追記前提に変更 | 中 |
| Similar incidents | 旧画面依存の調査手順を代替手順に変更 | 中 |
| 手順書 | Defender portal のメニュー名と新しい調査フローに更新 | 高 |
まず取るべきアクション
今回の更新ポイントを実務に落とし込むなら、最初にやるべきことは「旧画面の操作を覚え直すこと」ではありません。現在の SOC 運用が、Azure portal の旧インシデント調査画面にどれだけ依存しているかを可視化することです。
まず、過去30日から90日程度のインシデントを対象に、どの Analytics rules が多くのインシデントを作っているか、どの Playbooks が動いているか、どのチケット連携が使われているかを棚卸ししてください。次に、重要度の高いユースケースから Defender portal で同じ調査ができるかを確認します。
特に優先すべきなのは、次の3つです。
| 優先アクション | 理由 |
|---|---|
| 重大インシデントの調査手順を Defender portal 版に更新する | 本番障害やセキュリティ対応時に迷わないようにするため |
| Automation rules / Playbooks / 外部チケット連携を検証する | 移行後に通知漏れや重複起票が起きると影響が大きいため |
| Entity mapping とクローズ分類を標準化する | 調査品質、相関精度、レポート品質に直結するため |
Azure の「Investigate incidents with Microsoft Sentinel (legacy)」は、旧インシデント調査画面の使い方を理解するうえで今も重要な情報です。ただし、今後の主戦場は Microsoft Defender portal です。旧画面を使っている組織ほど、期限直前の画面移行ではなく、インシデント対応プロセス全体の移行として準備を進めることが重要です。
コメント