結論から言うと、Microsoft Sentinel in the Microsoft Defender portalは、Microsoft Sentinelの運用画面をAzure portal中心からMicrosoft Defender portal中心へ移すための重要な変更です。Microsoft SentinelはDefender portalで一般提供されており、Microsoft Defender XDRやE5ライセンスがない環境でも利用できます。一方で、2027年3月31日以降、Microsoft SentinelはAzure portalではサポートされず、Defender portalでの利用に一本化される予定です。管理者は「画面が変わるだけ」と捉えず、インシデント管理、データコネクタ、分析ルール、自動化、API連携、SOC運用手順を早めに点検する必要があります。(Microsoft Learn)
2026年5月14日更新のMicrosoft Learn移行ガイドでは、Defender portalへの移行時に確認すべきデータ収集、分析ルール、自動化、API、インシデント相関の変更点が整理されています。既存のMicrosoft Sentinel環境を使っている組織は、2027年の期限を待たず、まず検証用の運用フローをDefender portal前提で作り直すのが現実的です。(Microsoft Learn)
Microsoft Sentinel in the Microsoft Defender portalとは
Microsoft Sentinel in the Microsoft Defender portalは、SIEMであるMicrosoft Sentinelと、XDRであるMicrosoft Defender XDRの運用体験をMicrosoft Defender portal上で統合する取り組みです。エンドポイント、ID、メール、クラウド、脅威インテリジェンス、SIEMの情報を同じポータルで扱えるため、調査時にAzure portal、Defender portal、各セキュリティ製品を行き来する負担を減らせます。(Microsoft Learn)
従来のMicrosoft SentinelはAzure portalでLog Analyticsワークスペース、データコネクタ、分析ルール、インシデント、ワークブックを管理する運用が一般的でした。Defender portalでは、インシデントキュー、Advanced hunting、エンティティページ、脅威インテリジェンスなどが統合され、SIEMとXDRの情報をより近い文脈で確認できます。(Microsoft Learn)
特に重要なのは、Microsoft Sentinel単体でもDefender portalで利用できる点です。Microsoft Defender XDRを導入していない、またはMicrosoft 365 E5を持っていない組織でも、Microsoft SentinelのDefender portal体験を利用できます。ただし、Defender XDR由来の一部機能は、ライセンスや有効化しているサービスによって使える範囲が変わります。(Microsoft Learn)
2026年5月時点で押さえるべき主な変更点
Microsoft Sentinel in the Microsoft Defender portalで変わるポイントは、単なるメニュー配置の変更ではありません。管理者にとっては、SOCの一次対応、検知ルールの設計、チケット連携、KQLクエリ、権限管理に影響する変更として見るべきです。
| 変更点 | 内容 | 管理者が確認すべきこと |
|---|---|---|
| Azure portalからDefender portalへの移行 | 2027年3月31日以降、Microsoft SentinelはAzure portalではサポートされずDefender portal中心になる予定 | 既存運用手順、教育資料、監査手順をDefender portal前提に更新する |
| 統合インシデントキュー | Microsoft SentinelとDefender XDRのインシデントを単一の場所で扱える | SOCの担当分担、優先度判断、フィルター条件を見直す |
| Advanced huntingの活用範囲拡大 | Microsoft Sentinelのデータ、既存KQL、関数をDefender portal側で調査に利用できる | 既存クエリがAdvanced huntingで期待どおり動くか検証する |
| インシデント相関の変更 | Defender XDRの相関エンジンが複数のアラートを統合する | 自動化ルールやチケット起票が「想定外の統合インシデント」に対応できるか確認する |
| Microsoft Defender XDRコネクタ | Defender portalへのオンボード時、Defender XDRコネクタが自動的に有効化される場合がある | 重複取り込み、スキーマ差分、既存コネクタの扱いを確認する |
| 自動化・プレイブック | 一部のトリガー、手動実行、フィールド参照に制限や変更がある | Logic Apps、ServiceNowなど外部連携の条件式を点検する |
Microsoftの公式情報では、統合エンティティページ、統合インシデント、Advanced hunting、Security Copilot連携、Case management、自動攻撃中断、SOC最適化、データレイクなどが新しい体験の主な強化点として示されています。Advanced huntingの生ログは、Microsoft Sentinelに取り込まなくても30日間ハンティング用途で利用できると説明されています。(Microsoft Learn)
ただし、Microsoft SentinelだけをDefender portalにオンボードし、Defender XDRなどを有効化していない場合、Microsoft Security Exposure Management、Defender XDR提供のCustom detection rules、Action centerなどは制限または利用不可になる場合があります。ここを見落とすと、「Defender portalに移したのに期待した機能が表示されない」という混乱が起きやすくなります。(Microsoft Learn)
影響を受ける範囲
Microsoft Sentinel in the Microsoft Defender portalへの移行で影響を受けるのは、セキュリティ管理者だけではありません。SOCアナリスト、クラウド管理者、ID管理者、DevSecOps担当、外部SOC、チケット管理システムの開発者まで関係します。
| 対象 | 主な影響 | 具体的な確認ポイント |
|---|---|---|
| セキュリティ管理者 | ポータル、権限、ワークスペース管理が変わる | Primary workspace、Azure RBAC、Defender portal上の表示権限 |
| SOCアナリスト | インシデントの見え方、相関、調査導線が変わる | インシデントキュー、エンティティページ、Advanced huntingの使い方 |
| 検知ルール担当 | 分析ルール、Fusion、アラート相関の扱いが変わる | ルールの出力、アラートのみ生成するルール、相関後のインシデント名 |
| 自動化担当 | Automation rules、Logic Apps、プレイブックに影響 | Incident provider、Descriptionフィールド、遅延、手動実行可否 |
| 開発者 | APIレスポンスや外部連携のフィールドが変わる | Microsoft Graph REST API、providerName、providerIncidentUrl |
| MSSP・複数テナント運用 | Primary workspaceと複数ワークスペースの扱いが重要になる | テナントごとのオンボード、マルチテナントポータル、B2B認証 |
移行後も、Microsoft Sentinelの既存データコネクタやLog Analytics側の基本的なデータ収集アーキテクチャは維持されると説明されています。つまり、バックエンドの取り込み基盤が全面的に置き換わるわけではありません。しかし、前面の運用画面、アラートの相関、表示されるフィールド、自動化の発火条件には違いが出るため、運用テストは必須です。(Microsoft Learn)
Azure portalとDefender portalの主なメニュー対応
既存の手順書や社内ナレッジを更新する際は、まず「Azure portalで見ていた機能がDefender portalのどこにあるか」を整理します。移行初期の問い合わせは、機能そのものの不具合ではなく、単にメニュー位置が変わったことによるものが多くなりがちです。
| Azure portalでの機能 | Defender portalでの場所 |
|---|---|
| Overview | Overview |
| Logs | Investigation & response > Hunting > Advanced hunting |
| Search | Microsoft Sentinel > Search |
| Incidents | Investigation & response > Incidents & alerts > Incidents |
| Workbooks | Microsoft Sentinel > Threat management > Workbooks |
| Hunting | Microsoft Sentinel > Threat management > Hunting |
| Notebooks | Microsoft Sentinel > Threat management > Notebooks |
| Threat intelligence | Threat intelligence > Intel management |
| MITRE ATT&CK | Microsoft Sentinel > Threat management > MITRE ATT&CK |
| Content hub | Microsoft Sentinel > Content management > Content hub |
| Data connectors | Microsoft Sentinel > Configuration > Data connectors |
| Analytics | Microsoft Sentinel > Configuration > Analytics |
| Watchlists | Microsoft Sentinel > Configuration > Watchlists |
| Automation | Microsoft Sentinel > Configuration > Automation |
| Settings | System > Settings > Microsoft Sentinel |
Microsoft Learnでは、Workspace managerとNews & guidesはDefender portal側で利用できない項目として示されています。特にWorkspace managerを使って複数ワークスペースへコンテンツを展開していた組織は、Content as codeやマルチテナント管理など、代替手段への切り替えを検討する必要があります。(Microsoft Learn)
移行前に管理者が確認すべき設定
ワークスペースと権限
Microsoft SentinelをDefender portalへ接続するには、Microsoft Sentinelが有効化されたLog Analyticsワークスペースが必要です。オンボードには、Owner、またはUser Access AdministratorとMicrosoft Sentinel Contributorの組み合わせなど、作業内容に応じたAzureロールが必要になります。閲覧だけであればMicrosoft Sentinel Readerが基準になりますが、インシデント調査やコメント、タスク操作を行う場合はContributor相当の権限が必要です。(Microsoft Learn)
複数のMicrosoft Sentinelワークスペースがあるテナントでは、Primary workspaceの設計が重要です。Defender portalは1つのPrimary workspaceと複数のSecondary workspaceを扱えますが、Defender XDRデータとの相関はPrimary workspaceを軸に考える必要があります。Primary workspaceを誤ると、SOCが期待するインシデント統合やデータ参照ができない可能性があります。(Microsoft Learn)
データコネクタとDefender XDRコネクタ
Defender portalにMicrosoft Sentinelをオンボードすると、Microsoft Defender XDRコネクタが自動的に有効化されるケースがあります。Microsoft Learnでは、Defender portalにオンボード済みの場合、Azure portal側で説明されている手動のDefender XDRコネクタ設定は不要とされています。(Microsoft Learn)
既存のDefender製品別コネクタを利用している場合は、重複データやスキーマ差分に注意が必要です。Microsoft Defender XDRコネクタを有効にすると、Defenderコンポーネントの個別コネクタがバックグラウンドで切断され、見かけ上は接続済みに見えてもデータが流れない場合があります。既存のKQL、ワークブック、アラート条件が特定のスキーマに依存している場合は、検証環境で差分を確認してください。(Microsoft Learn)
データ取り込みを確認する基本的なKQLは次の通りです。
SecurityIncident
| where ProviderName == "Microsoft XDR"このクエリは、Microsoft Defender XDR由来のインシデントがMicrosoft Sentinel側で確認できるかを見るための初期確認に使えます。実運用では、期間条件やSeverity、Owner、Statusなどの条件を追加し、取り込み量とチケット起票件数に大きな差がないか確認するとよいでしょう。(Microsoft Learn)
Microsoft Defender for Cloud連携
Microsoft Defender for Cloudを利用している場合は、テナントベースのコネクタと従来のサブスクリプションベースのコネクタの扱いに注意します。公式移行ガイドでは、Defender for Cloudのテナントベースコネクタを利用している場合、重複イベントや重複アラートを防ぐための対応が必要とされています。従来のサブスクリプションベースコネクタを使う場合は、インシデントとアラートのMicrosoft Defenderへの同期をオプトアウトする確認が必要です。(Microsoft Learn)
実務では、移行前に「どのワークスペースでDefender for Cloudアラートを受けるか」を決めてください。複数ワークスペースに同じアラートが流れると、同じ脅威に対して複数のインシデントやチケットが作られ、SOCの一次対応を混乱させます。
分析ルールとアラート相関
Microsoft Sentinelの分析ルールはDefender portalでも作成、更新、管理できます。ルールの基本機能は維持されますが、インシデント相関やアラートグルーピングはDefender XDR側の相関エンジンの影響を受けます。公式情報では、Defender portalではMicrosoft DefenderデータとMicrosoft Sentinelに取り込まれたサードパーティデータの両方に対して相関が自動的に適用されると説明されています。(Microsoft Learn)
特に注意すべき点は、Azure portalでFusion分析ルールにより実現していた相関が、Defender portalではDefender XDRのインシデント作成・相関機能に置き換わることです。また、インシデント作成をオフにして「アラートのみ」を生成するMicrosoft Sentinel分析ルールは、Defender portalでは表示されないとされています。(Microsoft Learn)
既存ルールを棚卸しする際は、次の観点で確認します。
| 確認項目 | 見るべきポイント |
|---|---|
| インシデント作成の有無 | アラートのみ生成するルールがDefender portalで見えなくならないか |
| ルール名への依存 | 自動化やチケット連携が特定のルール名を条件にしているか |
| Fusionへの依存 | 相関後のインシデント単位が変わっても運用できるか |
| False positive対策 | Defender portalのalert tuningで抑制できるか |
| 複数製品の横断検知 | SentinelデータとDefender XDRデータをまたいだ検知をどう設計するか |
自動化ルールとプレイブック
Automation rulesとLogic Appsベースのプレイブックは、移行時に最も慎重に確認すべき領域です。公式移行ガイドでは、Defender portalではAutomation rulesのアラートトリガーがMicrosoft Sentinelアラートのみに作用すること、Incident provider条件が削除されること、すべてのインシデントのProviderNameがMicrosoft XDRになることなどが説明されています。(Microsoft Learn)
また、オンボード後はSecurityIncidentテーブルにDescriptionフィールドが含まれなくなるため、このフィールドを条件にした自動化ルールは動作しなくなる可能性があります。ServiceNowなど外部チケットシステムにインシデント説明を同期している場合も、説明欄が欠落する可能性を確認してください。(Microsoft Learn)
プレイブック実行には遅延も考慮が必要です。Microsoft DefenderインシデントがMicrosoft Sentinelに表示されるまで最大5分、Defender portalでアラートが発生してインシデントが作成または更新されてからAutomation ruleが実行されるまで最大10分かかる場合があるとされています。即時遮断や即時通知を前提にした運用では、遅延を織り込んだSLA設計が必要です。(Microsoft Learn)
Defender portalへの展開手順
Microsoft SentinelをDefender portalへ接続する基本的な流れは、Defender portalのSystem > Settings > Microsoft Sentinel > Connect a workspaceから対象ワークスペースを選び、Primary workspaceを指定し、製品変更を確認して接続する手順です。接続後はDefender portalの左側ナビゲーションにMicrosoft Sentinelが表示され、Home、Incidents、Advanced huntingなどにMicrosoft Sentinelの情報が反映されます。(Microsoft Learn)
実務では、いきなり本番SOCの手順を切り替えるのではなく、次の順序で進めると失敗しにくくなります。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | 既存のワークスペース、コネクタ、分析ルール、自動化、API連携を一覧化する | 影響を受ける運用項目がリスト化されている |
| 権限確認 | Owner、User Access Administrator、Microsoft Sentinel Contributor、Readerなどを確認する | 管理者、SOC、開発者の操作権限が過不足なく割り当てられている |
| 検証接続 | Defender portalでワークスペースを接続し、Primary workspaceを確認する | Incidents、Advanced hunting、Data connectorsが想定どおり表示される |
| データ確認 | Defender XDRコネクタ、Defender for Cloud、サードパーティログの取り込みを確認する | KQLで取り込みデータと件数を確認できる |
| ルール確認 | 分析ルール、Fusion依存、アラートのみルール、抑制条件を確認する | 検知結果とインシデント化の動作が説明できる |
| 自動化確認 | Logic Apps、Automation rules、外部チケット連携をテストする | チケット、通知、隔離、コメント追加が想定どおり動く |
| SOC訓練 | Defender portal前提の一次対応手順を演習する | アナリストが新しい画面で調査を完了できる |
| 本番移行 | 監視手順書、教育資料、監査証跡の取得方法を更新する | Azure portal前提の手順が残っていない |
新規にMicrosoft Sentinelへオンボードする組織では、2025年7月1日以降にオンボードした場合、多くのケースでDefender portalへ自動的にオンボードされると説明されています。既存環境と新規環境が混在する場合、管理画面や運用手順が分かれないよう、ワークスペース単位で状態を確認してください。(Microsoft Learn)
データ保存、CMK、プライバシーで注意すべき点
Azure portalでMicrosoft Sentinelを使う場合と、Defender portalでMicrosoft Sentinelを使う場合では、適用されるデータ保存、処理、保持、共有に関するポリシーが異なります。移行ガイドでは、Azure portal利用時はMicrosoft Sentinelのポリシーが適用され、Defender portal利用時はMicrosoft Defender XDRのポリシーが適用されると説明されています。(Microsoft Learn)
Customer-managed keys、つまりCMKを使っている組織は、特に確認が必要です。CMKを有効にした状態でMicrosoft SentinelワークスペースをDefender portalへオンボードした場合、ワークスペース内のログデータや分析ルール、Automation rulesなどのSentinelコンテンツはCMK暗号化が継続されます。一方で、オンボード後のアラートとインシデントはCMK暗号化されないと説明されています。さらに、Microsoft Sentinel data lakeに保存されるデータはCMKが完全にはサポートされず、Microsoft-managed keysで暗号化されます。(Microsoft Learn)
金融、医療、公共、グローバル企業など、データ所在地や暗号化要件が厳しい組織では、移行前に次の確認を行ってください。
| 確認項目 | 実務上の判断基準 |
|---|---|
| データ所在地 | Defender XDR側のデータ保存ポリシーが社内規定と整合するか |
| CMK | ログ、ルール、アラート、インシデントのどこまでCMK対象か |
| データレイク | Microsoft-managed keysでの暗号化を許容できるか |
| 監査 | 監査ログ、インシデント証跡、チケット連携の保存先が説明できるか |
| 契約・規制 | 顧客契約、業界規制、社内セキュリティ基準と矛盾しないか |
開発者が確認すべきAPIと外部連携の変更
開発者や自動化担当者は、Defender portal移行後のAPI設計を必ず見直してください。公式移行ガイドでは、統合されたインシデントとアラートに対する自動化にはMicrosoft Graph REST API v1.0の利用が推奨されています。一方、分析ルールやAutomation rulesなどMicrosoft Sentinelリソースに対する操作では、Microsoft Sentinel APIが引き続き使われます。(Microsoft Learn)
特に外部チケット管理、SOAR、社内ダッシュボードと連携している場合、次のフィールド変更に注意します。
| 項目 | Azure portal中心の従来運用 | Defender portal移行後の注意 |
|---|---|---|
| インシデントURL | incidentUrlがSentinel側の直接URLとして使われる | providerIncidentUrlがDefender portal側のインシデントURLとして重要になる |
| アラート製品名 | alertProductNamesを参照 | 取得に?$expand=alertsが必要になる場合がある |
| Provider名 | providerName = "Azure Sentinel" | providerName = "Microsoft XDR"になる |
| サービスソース | 従来レスポンスに存在しない場合がある | serviceSourceでMicrosoft Defender for Cloud Appsなどを判別できる |
| 検知ソース | 従来レスポンスに存在しない場合がある | detectionSourceで検知技術やセンサーを判別できる |
| 製品名 | 従来レスポンスに存在しない場合がある | productNameでアラートを発行した製品を判別できる |
既存コードでproviderName == "Azure Sentinel"のような条件分岐を使っている場合、移行後に対象インシデントを拾えなくなる可能性があります。また、ServiceNow、Jira、Teams通知、Slack通知、独自SOCポータルでインシデントURLを表示している場合は、Defender portal側のURLを使うように変更する必要があります。(Microsoft Learn)
Advanced huntingとKQLクエリの確認ポイント
Defender portalへオンボードした後も、既存のLog Analyticsテーブル、KQLクエリ、関数はAdvanced huntingページから利用できます。Microsoft Sentinelアラートのうちインシデントに紐づくものは、Advanced huntingのAlertInfoテーブルから参照できます。(Microsoft Learn)
ただし、すべてが同じように使えるわけではありません。Advanced huntingではブックマークがサポートされず、ブックマークはMicrosoft Sentinel > Threat management > Hunting側で扱う必要があります。また、UEBA関連のIdentityInfoテーブルはDefender側でネイティブテーブルになり、一部フィールド名が変わったり、サポートされないフィールドが出たりします。(Microsoft Learn)
さらに重要なのは、IdentityInfoテーブルがDefender側のネイティブテーブルになることで、Azure portalで利用していたテーブルレベルRBACが使えなくなる点です。特定部門だけにID情報の一部を見せる、といった細かい制御をしていた組織は、移行前にアクセス制御の代替設計を確認してください。(Microsoft Learn)
SOC運用で見直すべきポイント
Defender portalでは、複数のセキュリティドメインにまたがるアラートが1つのインシデントとして相関される可能性が高くなります。これは攻撃全体を把握しやすくする一方で、従来の「メール担当」「エンドポイント担当」「クラウド担当」といった縦割りトリアージを前提にしたSOCでは、担当範囲があいまいになる場合があります。(Microsoft Learn)
移行後のSOCでは、次のように運用を見直すと効果的です。
| 見直し対象 | 変更の方向性 |
|---|---|
| 一次対応 | 製品別キューではなく、統合インシデントの重大度、影響範囲、攻撃ストーリーで判断する |
| エスカレーション | エンドポイント、ID、メール、クラウドを横断して担当を決める |
| フィルター | Detection source、Product name、Service sourceを使った絞り込みを整備する |
| 教育 | Defender portalのIncident、Entity page、Advanced huntingを使った調査演習を行う |
| KPI | アラート件数だけでなく、相関後のインシデント件数、重複削減、対応時間を見る |
公式移行ガイドでも、統合トリアージはアナリストの負荷を減らす可能性がある一方、より広く深い知識を求める可能性があるため、新しいポータル画面でのトレーニングが推奨されています。(Microsoft Learn)
移行時につまずきやすいポイント
Microsoft Sentinel in the Microsoft Defender portalへの移行で失敗しやすいのは、技術的な接続よりも「既存運用の前提」を残したままにすることです。
| つまずきやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Azure portalの手順書をそのまま使う | SOCが機能の場所を見つけられない | Defender portal版の操作手順に更新する |
| Primary workspaceを深く考えずに選ぶ | 相関、データ表示、チケット連携が期待とずれる | 代表ワークスペースを設計してから接続する |
providerName条件を修正しない | API連携や自動化が対象インシデントを拾えない | "Microsoft XDR"前提で条件を見直す |
| インシデント名を自動化条件に使う | 相関によりインシデント名が変わり、ルールが動かない | 分析ルール名、タグ、Severityなど安定した条件を使う |
Descriptionフィールドに依存する | Automation ruleや外部チケットの説明欄が欠落する | 参照フィールドを変更し、チケット本文生成を再設計する |
| 手動作成インシデントを同期前提にする | APIやLogic Appで作成したインシデントがDefender portalに出ない | 手動・API作成インシデントの運用を分ける |
| CMKの対象範囲を誤解する | アラートやインシデントの暗号化要件を満たせない | ログ、コンテンツ、インシデントごとに暗号化要件を確認する |
| Advanced huntingでブックマークを探す | 調査メモや証跡が見つからない | SentinelのHunting側でブックマークを扱う |
プレビュー機能にも注意が必要です。公式移行ガイドでは、Microsoft SentinelのSimilar incidents機能はPreviewであり、Defender portalではサポートされないため、インシデント詳細画面にSimilar incidentsタブは表示されないと説明されています。(Microsoft Learn)
まず着手すべき3つのアクション
Microsoft Sentinel in the Microsoft Defender portalへの対応は、2027年の期限直前にまとめて行うのではなく、今のうちに段階的に進めるべきです。最初にやるべきことは大きく3つです。
1つ目は、既存運用の棚卸しです。Azure portalのどの画面を使っているか、どのKQLクエリを定常的に実行しているか、どの分析ルールがインシデントを作るか、どのAutomation ruleやLogic Appsが外部システムと連携しているかを一覧化します。
2つ目は、Defender portal上での検証です。ワークスペースを接続し、Primary workspace、Data connectors、Incidents、Advanced hunting、Analytics、Automation、Workbooksを確認します。Microsoft Defender XDRコネクタの取り込み状況は、KQLで実データを確認してください。
3つ目は、SOC手順とAPI連携の更新です。統合インシデントキュー、相関後のインシデント、providerName = "Microsoft XDR"、providerIncidentUrl、Descriptionフィールドの扱い、プレイブック実行遅延を前提に、チケット起票、通知、エスカレーションの流れを作り直します。
Microsoft Sentinel in the Microsoft Defender portalは、単なる管理画面の変更ではなく、SIEMとXDRを統合してセキュリティ運用を再設計するための変更です。早い段階でワークスペース、権限、コネクタ、分析ルール、自動化、APIを点検しておけば、2027年3月31日以降のDefender portal一本化にも落ち着いて対応できます。(Microsoft Learn)
コメント