Microsoft Defenderを使っている組織にとって、「Plan your migration to Microsoft Sentinel」は単なるSIEM移行の読み物ではありません。結論から言うと、レガシーSIEMからMicrosoft Sentinelへ移行する前に、既存の検知ルール、データソース、SOC運用、自動化、Microsoft Defender XDR連携、Defenderポータル移行の影響を棚卸しするための計画ガイドとして読むべき内容です。
特に注意したいのは、すべてのルールやログをそのまま移すのではなく、業務リスク、検知精度、直近の利用実績、運用負荷を基準に「移行するもの」「作り直すもの」「捨てるもの」を分けることです。Microsoft Learnの該当ページは2026年5月14日に更新されており、レガシーSIEMからMicrosoft Sentinelへ移行する理由と、移行フェーズの考え方が整理されています。(Microsoft Learn)
Microsoft Defender管理者から見た「Plan your migration to Microsoft Sentinel」の要点
「Plan your migration to Microsoft Sentinel」は、Microsoft Defender製品の単体機能変更を知らせるリリースノートではありません。中心テーマは、オンプレミス中心のレガシーSIEMから、クラウドネイティブなMicrosoft Sentinelへ移行するための計画です。
ただし、Microsoft Defender XDRやMicrosoft Defenderポータルを使っている組織では、Sentinel移行がDefender側のインシデント管理、アラート相関、データコネクタ、SOC運用に直結します。Microsoft SentinelはDefenderポータルで一般提供されており、Microsoft Defender XDRを使っていない顧客でもDefenderポータル上で利用できるとされています。さらに、2027年3月31日以降はAzure portalでのMicrosoft Sentinelサポートが終了し、Defenderポータルのみで利用可能になる予定です。(Microsoft Learn)
そのため、今回確認すべきポイントは次の3つです。
| 確認ポイント | 管理者が見るべき内容 |
|---|---|
| SIEM移行計画 | 既存SIEMのデータソース、検知ルール、ダッシュボード、自動化、履歴データをどう移すか |
| Microsoft Defender連携 | Defender XDRのインシデント、アラート、高度なハンティングイベントをSentinelとどう同期するか |
| 運用移行 | Azure portal中心のSOC運用をDefenderポータル中心に変える準備ができているか |
重要なのは、「SIEMを入れ替える」だけでなく、SOCの判断基準とワークフローを作り直す移行として扱うことです。
なぜレガシーSIEMからMicrosoft Sentinelへの移行が必要なのか
Microsoftの公式情報では、レガシーSIEMの課題として、脅威対応の遅さ、スケーリングの難しさ、手作業による分析・対応、複雑な管理負荷が挙げられています。特にオンプレミス資産の監視には対応できても、Azure、Microsoft 365、AWS、Google Cloudなどを含む分散したクラウド環境では十分な可視性を維持しにくくなります。(Microsoft Learn)
Microsoft Sentinelは、オンプレミスとクラウドの両方からデータを取り込み、SIEMとSOARをクラウドネイティブに提供するサービスです。脅威検出、調査、ハンティング、対応を一つの基盤で扱えるため、Microsoft Defender XDRと組み合わせると、Microsoft 365、エンドポイント、ID、クラウドアプリ、クラウドワークロードのシグナルを横断的に扱いやすくなります。(Microsoft Learn)
ただし、移行すれば自動的に運用が改善するわけではありません。古いSIEMで使っていたノイズの多いルール、放置されたダッシュボード、誰も見ていないアラートまで移すと、Sentinelでも同じ問題を再現します。
影響を受ける対象者
この移行計画は、SOC担当者だけの話ではありません。次のような担当者は、設定や運用への影響を確認する必要があります。
| 対象者 | 主な確認ポイント |
|---|---|
| セキュリティ管理者 | Microsoft Sentinelワークスペース、Defender XDR連携、権限、データコネクタ |
| SOCアナリスト | インシデントキュー、アラート相関、トリアージ手順、ハンティング画面 |
| SIEM運用担当 | 既存SIEMのルール、データソース、ダッシュボード、履歴ログの移行可否 |
| クラウド管理者 | Azure、Microsoft 365、AWS、GCP、オンプレミスログの取り込み設計 |
| 開発者・SRE | API連携、Logic Apps、チケット連携、KQLクエリ、CI/CDでのコンテンツ管理 |
| MSSP・複数テナント管理者 | マルチワークスペース、マルチテナント、Azure Lighthouse、委任管理 |
特にMicrosoft Defender XDRをすでに利用している組織では、Sentinel移行時にDefender側のインシデント相関やコネクタの扱いが変わります。Microsoft Defender XDRコネクタは、Defender XDRのインシデント、アラート、高度なハンティングイベントをMicrosoft Sentinelへストリーミングし、両ポータル間でインシデントを同期します。(Microsoft Learn)
移行計画で押さえるべき4つのフェーズ
公式ガイドでは、Microsoft Sentinelへの移行を大きく「Discover」「Design」「Implement」「Operationalize」の流れで考えるよう示しています。実務では、次のように落とし込むと進めやすくなります。(Microsoft Learn)
| フェーズ | やること | 成果物の例 |
|---|---|---|
| Discover | 既存SIEMの資産を棚卸しする | データソース一覧、検知ルール一覧、利用中ダッシュボード、Playbook一覧 |
| Design | SentinelとDefenderの構成を設計する | ワークスペース設計、RBAC設計、データ保持方針、インシデント運用設計 |
| Implement | MVPから段階的に実装する | Defender XDRコネクタ、優先ルール、主要ログ、SOC向けワークブック |
| Operationalize | SOC運用へ組み込む | トリアージ手順、エスカレーション基準、自動化ルール、監視KPI |
失敗しやすいのは、Discoverを飛ばして実装を始めるケースです。既存SIEMに何が入っているかを把握しないままSentinelへ移すと、コスト、アラート量、運用品質のどこかで問題が出ます。
まず棚卸しすべき既存SIEMの項目
移行前に確認すべき項目は、単なるログ一覧ではありません。実際にSOCで使われているか、事業リスクに紐づいているか、誤検知が多すぎないかまで確認します。
| 棚卸し項目 | 確認する内容 | 判断基準 |
|---|---|---|
| データソース | AD、Entra ID、Endpoint、Firewall、Proxy、SaaS、EDR、クラウドログ | Sentinelに標準コネクタがあるか、代替取り込みが必要か |
| 検知ルール | 相関ルール、カスタムルール、スケジュール検知 | 直近6〜12か月で有効なアラートを出しているか |
| アラート品質 | True Positive、False Positive、無視されているアラート | 誤検知が多いルールは移行より見直しを優先 |
| ダッシュボード | SOC、監査、経営報告、運用監視 | Sentinel Workbookで再現する必要があるか |
| 自動化 | チケット作成、通知、隔離、ブロック、承認フロー | Logic AppsやDefender側の自動化に置き換えられるか |
| 履歴データ | 監査要件、調査要件、保管期間 | 全量移行が必要か、検索可能な保管だけでよいか |
公式ガイドでも、移行前に現在のSIEMにある主要ユースケース、検知ルール、データ、自動化を特定し、段階的に移行する考え方が推奨されています。さらに、過去6〜12か月にアラートを出していないルールや、日常的に無視している低レベルアラートは見直し対象として扱うべきとされています。(Microsoft Learn)
すべてのルールを移行しない判断基準
SIEM移行でよくある失敗は、「既存ルールを全部移せば安全」と考えることです。実際には、不要なルールまで移すとSOCのノイズが増え、重要なインシデントを見落としやすくなります。
次の基準で優先度を分けると、移行の品質が上がります。
| 優先度 | ルールの例 | 判断 |
|---|---|---|
| 高 | ランサムウェア兆候、特権アカウント悪用、MFA突破、EDR高信頼アラート | MVP段階で移行・検証する |
| 中 | VPNブルートフォース、異常なクラウド管理操作、DLP関連アラート | データソース接続後に順次移行する |
| 低 | 1年以上発報なし、誤検知が多い、運用で無視されている情報レベルアラート | 移行せず廃止またはロジック再設計 |
| 要再設計 | 複雑なSPL、QRadar固有のビルディングブロック、独自ログ前提の相関 | SentinelのKQL、ASIM、Defender相関に合わせて作り直す |
Microsoftのガイドでは、検知の有効性を見る際に、False PositiveとPositiveの割合、直近の発報実績、ビジネスリスク、優先度付けの方法を確認する考え方が示されています。(Microsoft Learn)
Microsoft Defender XDR連携で変わるポイント
Microsoft Defender XDRとMicrosoft Sentinelを統合すると、Defender XDRのインシデントをSentinel側で確認・管理できます。Defender XDRは複数のMicrosoft Defender製品からアラートを集約・グループ化し、Microsoft Sentinel側のインシデントキューでも扱えるようにします。対象には、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender for Cloud Appsなどが含まれます。(Microsoft Learn)
管理者が特に確認すべき点は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| Defender XDRコネクタ | Azure portalでSentinelを使う場合は、Microsoft Defender XDRコネクタを有効化する |
| Defenderポータル統合 | SentinelをDefenderポータルへオンボード済みの場合、Defender XDRコネクタは自動設定される |
| 既存コネクタ | Defender XDRコネクタに含まれる個別のDefender系コネクタは切断または非表示になる場合がある |
| インシデント同期 | ステータス、所有者、クローズ理由などの同期仕様を確認する |
| Defender for Cloud | インシデントだけでなくアラートやエンティティを同期するには、Defender for Cloud側の設定も確認する |
| コスト | Defender XDRのアラート・インシデント同期は無償だが、高度なハンティングイベントなどの取り込みは課金対象になり得る |
Microsoftのドキュメントでは、Defender XDRのアラートとインシデントはSentinelへ無償で取り込まれる一方、DeviceInfoやDeviceFileEvents、EmailEventsなど個別Defenderコンポーネントの高度なハンティングテーブルは取り込み課金の対象と説明されています。(Microsoft Learn)
つまり、移行時に「全部のイベントをSentinelへ流す」と決める前に、どのテーブルが調査に本当に必要かを確認する必要があります。
Microsoft Defenderポータル移行で注意すべき運用変更
Microsoft SentinelはDefenderポータルで利用できるようになっており、今後の運用はDefenderポータル中心へ移る前提で設計する必要があります。Defenderポータルでは、インシデント、アラート、調査、Advanced hunting、エンティティページなどが統合された体験になります。(Microsoft Learn)
一方で、画面の場所や一部の挙動はAzure portalと同じではありません。
| Azure portalでの項目 | Defenderポータルでの主な場所 |
|---|---|
| Logs | Investigation & response > Hunting > Advanced hunting |
| Incidents | Investigation & response > Incidents & alerts > Incidents |
| Workbooks | Microsoft Sentinel > Threat management > Workbooks |
| Data connectors | Microsoft Sentinel > Configuration > Data connectors |
| Analytics | Microsoft Sentinel > Configuration > Analytics、またはCustom detection rules |
| Automation | Microsoft Sentinel > Configuration > Automation |
| Settings | System > Settings > Microsoft Sentinel |
特にSOCアナリストには、画面遷移だけでなく、インシデントのまとめ方が変わる点を説明する必要があります。Defenderポータルでは、複数の検知ソースからのアラートがDefender XDRの相関エンジンで統合されるため、従来の「製品別」「ドメイン別」にチケットを見る運用から、攻撃ストーリー全体を見る運用へ変わります。(Microsoft Learn)
自動化ルールとPlaybookで確認すべき注意点
移行時に最も事故が起きやすいのが、自動化ルールとPlaybookです。通知、チケット起票、隔離、ブロック、承認フローが動かなくなると、検知はできても対応が遅れます。
特に次の条件を使っている場合は、移行前に見直してください。
| 既存条件・処理 | リスク | 見直し方 |
|---|---|---|
| インシデント名を条件にする | Defender側の相関でインシデント名が変わる可能性がある | タグ、重大度、分析ルール名、エンティティ種別を使う |
| Incident providerを条件にする | DefenderポータルではProviderNameがMicrosoft XDRになる | 条件を再設計する |
| Descriptionフィールドを使う | オンボード後のSecurityIncidentテーブルで利用できないケースがある | チケット連携の本文生成ロジックを確認する |
| 手動作成インシデントを同期前提にする | APIやLogic Appsで作成した一部インシデントはDefenderポータルへ同期されない | 手動作成の運用を見直す |
| アラート単位の手動Playbook | Defenderポータルで未対応の操作がある | インシデント単位の自動化へ寄せる |
Microsoftの移行ドキュメントでは、Defenderポータル移行後にSecurityIncidentテーブルのDescriptionフィールドが含まれなくなること、Incident provider条件が変わること、インシデント名を条件にした自動化を避けるべきことが説明されています。(Microsoft Learn)
開発者・運用自動化担当が見るべきAPIとKQLの変更
開発者やSREが確認すべきポイントは、API、KQL、スキーマ、CI/CDです。
Microsoftのドキュメントでは、統合されたDefenderポータル体験において、インシデントやアラートに関する自動化ではMicrosoft Graph REST APIの利用が推奨されています。一方、分析ルールや自動化ルールなどMicrosoft Sentinelリソースに対する操作では、Microsoft Sentinel APIが引き続き使われます。(Microsoft Learn)
移行前に、少なくとも次を確認してください。
SecurityIncident
| where ProviderName == "Microsoft XDR"このクエリは、Microsoft Defender XDRコネクタで取り込まれたインシデントデータを確認する基本的な検証に使えます。Microsoft公式ドキュメントでも、Defender XDRコネクタ有効化後の確認例として示されています。(Microsoft Learn)
また、既存のAPI処理でproviderName = "Azure Sentinel"を前提にしている場合、Defenderポータル移行後はproviderName = "Microsoft XDR"になる点に注意が必要です。アラート情報を取得する処理では、Microsoft Graph APIで?$expand=alertsが必要になるケースもあります。(Microsoft Learn)
SIEM Migration experienceは使えるが、万能ではない
Microsoft Sentinelには、SIEM Migration experienceという移行支援機能があります。これはSplunkやQRadarの検知ルールを分析し、Microsoft Sentinelの推奨分析ルールやデータコネクタを提示する機能です。現在のSIEM Migration experienceは、SplunkとQRadarのセキュリティ監視をMicrosoft Sentinelへ移すことに重点を置いています。(Microsoft Learn)
ただし、次の点は誤解しないでください。
| 誤解 | 実際の注意点 |
|---|---|
| ツールがすべて自動移行してくれる | 推奨を出す機能であり、コネクタのインストールや検知ルールの有効化は明示的に実行する必要がある |
| SplunkやQRadarの全ルールがそのまま使える | Microsoft Sentinelの標準コネクタや標準分析ルールへのマッピングが中心 |
| 分析結果が出れば移行完了 | データソース接続、KQL確認、誤検知調整、SOC手順更新が必要 |
| Security Copilotの課金が発生する | SIEM Migration toolはSecurity Copilotで動作するが、SCUベースの課金は発生しないと説明されている |
特にSplunkのSPLやQRadar固有のルール構造は、Microsoft SentinelのKQLやDefender XDRの相関ロジックに合わせて見直す必要があります。単純変換ではなく、検知目的を維持したうえで再設計するのが安全です。
履歴データをどう扱うべきか
レガシーSIEMからの移行では、過去ログをすべてMicrosoft Sentinelへ移すべきかが論点になります。結論としては、監査・調査・法令・社内規程で必要な期間と検索要件を確認してから決めるべきです。
判断基準は次のとおりです。
| 判断項目 | 確認すること |
|---|---|
| 調査要件 | 過去インシデント調査で何か月分のログが必要か |
| 監査要件 | 規程や契約上、どのログを何年保管する必要があるか |
| 検索頻度 | 頻繁に検索するログか、保管だけでよいログか |
| コスト | 分析用テーブル、アーカイブ、データレイクなどの使い分け |
| 形式 | CSV、CEF、Syslog、API、ストレージ保管などの移行方式 |
「いつか使うかもしれない」という理由だけで全量を高コストな分析用ログとして取り込むと、移行後の費用が膨らみます。逆に、監査で必要なログを移行し忘れると、後から復元が難しくなります。
移行プロジェクトで使える実践チェックリスト
実務では、次の順番で進めると失敗を減らせます。
現状把握
- 既存SIEMのデータソースを一覧化する
- 検知ルールを重要度、発報実績、誤検知率で分類する
- ダッシュボード、レポート、通知、Playbookを棚卸しする
- 監査・保存期間・データ所在地の要件を確認する
- Microsoft Defender XDR、Defender for Cloud、Microsoft 365、Entra IDの接続状況を確認する
設計
- Microsoft Sentinelワークスペースの構成を決める
- Defenderポータル中心の運用にするか、移行期間中にAzure portalも併用するか決める
- RBAC、Unified RBAC、テーブル単位のアクセス制御を確認する
- 重要ログと低優先ログを分け、保持期間と課金方針を決める
- インシデントの命名規則ではなく、タグや重大度を軸にした自動化条件を設計する
実装
- Content Hubから必要なソリューションを導入する
- Microsoft Defender XDRコネクタを有効化またはDefenderポータルへオンボードする
- 優先度の高いデータソースから接続する
- 重要ルールだけをMVPとして有効化する
- KQL、Workbook、Automation rules、Playbookを検証する
- チケットシステムや通知先との連携をテストする
運用化
- SOCアナリスト向けにDefenderポータルのトリアージ手順を更新する
- 重大度、所有者、タグ、クローズ理由の運用ルールを決める
- 既存SIEMとMicrosoft Sentinelの並行稼働期間を設定する
- 誤検知が多いルールを停止または調整する
- レガシーSIEMの停止条件を明文化する
移行状況はWorkbookで可視化する
Microsoft Sentinelには、移行状況を追跡するための「Microsoft Sentinel Deployment and Migration」Workbookがあります。これにより、データソース、分析ルール、インシデント、Workbook、Playbook、自動化、UEBA、データ管理などの展開状況を可視化できます。(Microsoft Learn)
プロジェクト管理ツールだけで移行を追うと、セキュリティ運用に必要な観点が抜けやすくなります。たとえば、「データソースは接続済みだが、必要な分析ルールが有効化されていない」「ルールはあるが、Playbookに接続されていない」といった状態は、通常のタスク管理だけでは見落としがちです。
Workbookを使う場合は、次の観点で定期的に確認します。
| 確認項目 | 見るべき内容 |
|---|---|
| データ取り込み | どのテーブルにログが入っているか、取り込み量が急増していないか |
| 分析ルール | 有効化済みルール、未展開ルール、発報頻度 |
| インシデント | 重大度、分類、発報元、誤検知傾向 |
| 自動化 | Playbook接続状況、Automation ruleの状態 |
| UEBA | エンティティ関連テーブルのデータ有無 |
| データ管理 | 保持期間、アーカイブ、テーブルごとの利用状況 |
Defender for Cloud連携で重複を防ぐ
Microsoft Defender for Cloudを使っている場合は、Sentinel移行時にアラートやインシデントの重複に注意が必要です。Defender XDRコネクタ経由、Defender for Cloudコネクタ経由、旧サブスクリプションベースのコネクタ経由が混在すると、同じ検知が複数の経路で扱われる可能性があります。
Microsoftの移行ドキュメントでも、テナントベースのDefender for Cloudデータコネクタを使っている場合は重複イベントとアラートを防ぐ対策を取り、レガシーのサブスクリプションベースコネクタを使っている場合はMicrosoft Defenderへのインシデント・アラート同期をオプトアウトするよう注意が示されています。(Microsoft Learn)
確認すべき観点は次の3つです。
| 確認項目 | 推奨アクション |
|---|---|
| Defender for Cloudの接続方式 | テナントベースか、サブスクリプションベースかを確認する |
| アラートの流入経路 | Defender XDR経由とSentinelコネクタ経由で重複していないか確認する |
| インシデントの中身 | Defender for Cloudインシデントにアラートやエンティティが正しく含まれているか確認する |
データ保護・CMK・プライバシーの確認も忘れない
Defenderポータルへ移行する場合、データ保存、処理、保持、共有に関するポリシーの適用範囲も確認が必要です。Microsoftのドキュメントでは、Azure portal利用時はMicrosoft Sentinelのポリシーが適用され、Defenderポータル利用時はMicrosoft Defender XDRのポリシーが適用されると説明されています。(Microsoft Learn)
また、Customer-managed key（CMK）を使っている組織では特に注意が必要です。Defenderポータルへオンボードしてもワークスペース内のログデータや一部のSentinelコンテンツはCMK暗号化が継続される一方、アラートとインシデントはオンボード後にCMK暗号化されないとされています。さらに、Microsoft Sentinelデータレイクに保存されるデータではCMKが完全にはサポートされず、Microsoft管理キーで暗号化される点も確認が必要です。(Microsoft Learn)
規制業種、金融、医療、公共系の環境では、技術移行だけでなく、セキュリティ部門、法務、監査、データ保護責任者を交えた確認が必要です。
移行時によくある失敗と回避策
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| 既存SIEMのルールを全移行する | 誤検知が増え、SOCの負荷が上がる | 直近の有効性と事業リスクで優先順位を付ける |
| Defender XDRコネクタと個別コネクタを理解せず接続する | 重複、スキーマ差異、想定外のデータ停止が起きる | 接続方式とデータフローを図にして確認する |
| インシデント名に依存した自動化を残す | 相関後の名称変更でルールが動かない | タグ、重大度、分析ルール名、エンティティを条件にする |
| 高度なハンティングイベントを全量取り込む | Sentinelの取り込みコストが増える | 調査に必要なテーブルだけを選ぶ |
| SOCアナリストの教育を後回しにする | Defenderポータルでの調査手順が定着しない | 並行稼働期間中に演習を行う |
| 履歴ログの扱いを曖昧にする | 監査対応またはコスト管理で問題が出る | 保存要件と検索要件を分けて設計する |
| API連携の変更を見落とす | チケット起票や外部連携が壊れる | Microsoft Graph APIとSentinel APIの役割を分けて確認する |
まず管理者が取るべき次のアクション
最初に行うべきことは、Microsoft Sentinelをすぐ本番展開することではありません。まず、現在のSIEMとMicrosoft Defender環境を棚卸しし、移行対象を3分類してください。
| 分類 | 判断 |
|---|---|
| そのまま移行 | 直近で有効な検知実績があり、業務リスクが高く、Sentinelで再現しやすいもの |
| 再設計して移行 | 重要だが、SPLやQRadar固有ロジック、独自ログ、古い相関条件に依存しているもの |
| 移行しない | 発報実績がない、誤検知が多い、運用で無視されている、業務リスクが低いもの |
そのうえで、Microsoft Defender XDRコネクタ、Defenderポータル移行、Automation rules、Playbook、API連携、データ保持、コストの順に確認します。
「Plan your migration to Microsoft Sentinel」は、レガシーSIEMからSentinelへ移るための入口です。Microsoft Defender環境をすでに使っている組織では、Sentinel移行を単なるログ基盤の入れ替えではなく、Defender XDRとSentinelを前提にした統合SOC運用への移行として計画することが重要です。
コメント