Microsoft Sentinel SIEMは、Microsoft Defenderポータル上で使えるクラウドネイティブなSIEM/SOARです。結論から言うと、2026年5月時点で管理者が最も重視すべき変化は「Microsoft Sentinelそのものがなくなる」のではなく、運用の中心がAzure portalからMicrosoft Defenderポータルへ移っていくことです。
特に、既存のMicrosoft Sentinel利用組織は、2027年3月31日以降にAzure portalでのMicrosoft Sentinelサポートが終了し、Microsoft Defenderポータルでの利用に一本化される予定を前提に、ワークスペース、権限、データコネクタ、分析ルール、自動化、API連携を点検する必要があります。Microsoft Learnの「What is Microsoft Sentinel SIEM?」は2026年5月14日に更新されており、Microsoft Sentinelの基本機能に加えて、Defenderポータル移行の重要性が明確に示されています。(Microsoft Learn)
Microsoft Sentinel SIEMとは
Microsoft Sentinel SIEMは、マルチクラウド、オンプレミス、各種アプリケーション、デバイス、IDなどからセキュリティデータを収集し、脅威の検出、調査、対応、ハンティングを支援するクラウドネイティブなSIEMです。公式説明では、AI、分析、オートメーション、脅威インテリジェンスを組み合わせ、検出から対応までを支援するサービスとして位置づけられています。(Microsoft Learn)
一般的なSIEMが「ログを集めて相関分析する基盤」として理解されるのに対し、Microsoft SentinelはSOARの要素も含みます。つまり、アラートを出すだけでなく、Automation rulesやPlaybooksを使ってインシデント対応の一部を自動化できます。たとえば、特定のアラート発生時にServiceNowやJiraへチケットを作成する、担当者へ通知する、調査用の追加情報を取得するといった運用を組み込めます。(Microsoft Learn)
SIEMとSOARの違いを簡単に整理する
| 項目 | 役割 | Microsoft Sentinelでの例 |
|---|---|---|
| SIEM | ログ収集、相関分析、検出、可視化 | データコネクタ、分析ルール、Incidents、Workbooks |
| SOAR | 対応手順の自動化、外部システム連携 | Automation rules、Playbooks、Azure Logic Apps |
| XDR連携 | エンドポイント、ID、メール、クラウドアプリなどのシグナル統合 | Microsoft Defender XDRとの統合、統合インシデントキュー |
実務上は「ログ管理ツール」ではなく、「SOCの調査画面、検知ロジック、自動化、外部連携をまとめるセキュリティ運用基盤」と捉えると分かりやすいです。
2026年5月時点で押さえるべき変更点
今回の公式情報で管理者が特に押さえるべきポイントは、Microsoft Sentinelの機能追加そのものよりも、Microsoft Defenderポータル中心の運用へ移行する流れです。Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやMicrosoft 365 E5ライセンスがない顧客でも単体で利用できます。(Microsoft Learn)
| 変更・確認ポイント | 内容 | 管理者が取るべき対応 |
|---|---|---|
| Azure portalでのサポート終了予定 | 2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルで利用する形になる予定 | 2026年中に移行計画、検証環境、運用手順書の更新を進める |
| 新規顧客のオンボード | 2025年7月以降、条件を満たす新規顧客はMicrosoft Sentinelオンボード時にDefenderポータルへ自動オンボードされる | 新規構築時はAzure portal前提の手順ではなく、Defenderポータル前提で設計する |
| 統合インシデント管理 | DefenderポータルではMicrosoft SentinelとMicrosoft Defender XDRのシグナルを統合的に扱える | SOCの一次切り分け、担当分担、フィルター条件を見直す |
| API連携の変化 | 統合インシデントやアラートの操作ではMicrosoft Graph REST APIの利用が推奨される | 既存のSecurityInsights API依存部分を棚卸しする |
2025年7月以降の新規顧客については、最初のMicrosoft SentinelワークスペースをオンボードするユーザーがサブスクリプションのOwnerまたはUser Access Administrator権限を持ち、Azure Lighthouse委任ユーザーでない場合、Defenderポータルへ自動的にオンボードされると説明されています。条件を満たさない場合は自動オンボードされず、必要な権限を持つユーザーによる手動オンボードが必要です。(Microsoft Learn)
影響を受ける対象者
影響が大きいのは、すでにAzure portalでMicrosoft Sentinelを運用している組織です。特に、インシデント対応の手順、KQLクエリ、Logic Apps連携、チケットシステム連携、独自API連携を作り込んでいる場合は、単に画面の場所が変わるだけではありません。
| 対象者 | 影響 | 優先して確認すべきこと |
|---|---|---|
| セキュリティ管理者 | ポータル、権限、ワークスペース管理の変更 | Sentinel Reader、Sentinel Contributor、Owner、User Access Administratorの割り当て |
| SOCアナリスト | インシデントの見え方、相関、トリアージ手順の変更 | 統合インシデントキュー、フィルター、調査画面、Advanced hunting |
| インフラ管理者 | データコネクタ、Log Analytics、保持期間、コストへの影響 | 収集対象ログ、ワークスペース設計、保持設定、データ量 |
| 開発者・自動化担当 | APIレスポンス、Webhook、チケット連携、Playbook条件の変更 | Microsoft Graph API、SecurityInsights API、incidentUrl、providerNameなどの差分 |
| MSSP・複数テナント管理者 | テナント横断管理、Azure Lighthouse、B2B認証の扱い | 複数ワークスペース、プライマリワークスペース、委任管理の制限 |
Microsoft Defenderポータルでは、Microsoft Sentinel単体でオンボードした場合に一部の機能が制限または利用不可になることがあります。たとえば、Microsoft Security Exposure Management、Microsoft Defender XDR由来のCustom detection rules、Action centerなどは、Defender XDRなどの利用状況によって扱いが変わります。(Microsoft Learn)
管理者が最初に確認すべき設定
ワークスペースとポータル接続を確認する
Microsoft SentinelはLog Analyticsワークスペースに追加して利用します。Microsoftの展開ガイドでも、Defenderポータルへオンボードするかどうかに関係なく、Microsoft SentinelにはLog Analyticsワークスペースが必要と説明されています。(Microsoft Learn)
まず確認すべき項目は次の通りです。
| 確認項目 | 確認する理由 |
|---|---|
| Microsoft Sentinelが有効なLog Analyticsワークスペース | Defenderポータルに接続する対象を明確にするため |
| プライマリワークスペース | Defender XDRとの統合や相関の中心になるため |
| セカンダリワークスペース | 複数ワークスペース運用時の影響を把握するため |
| データ保持期間 | 調査・監査・コストに直結するため |
| リソースグループとサブスクリプション | RBAC、課金、運用責任の境界になるため |
新規構築では、後から簡単にワークスペース構成を変えられると考えないほうが安全です。公式手順では、Microsoft Sentinelをワークスペースへ追加した後、そのワークスペースを別のリソースグループやサブスクリプションへ移動することはサポートされないと説明されています。(Microsoft Learn)
権限を確認する
DefenderポータルでMicrosoft Sentinelをオンボード、表示、調査するには、作業ごとに必要な権限が異なります。たとえば、オンボードにはOwner、またはUser Access AdministratorとMicrosoft Sentinel Contributorの組み合わせが必要です。閲覧にはMicrosoft Sentinel Reader、インシデントへの調査アクションにはMicrosoft Sentinel Contributor相当の権限が必要です。(Microsoft Learn)
実務では、次のように分けると事故を防ぎやすくなります。
| 役割 | 推奨する権限設計 |
|---|---|
| SOC閲覧担当 | Microsoft Sentinel Readerを基本にする |
| インシデント対応担当 | Microsoft Sentinel Contributorを必要範囲に割り当てる |
| ワークスペース接続担当 | OwnerまたはUser Access Administratorを一時的・限定的に使う |
| 自動化担当 | Logic Apps、Microsoft Sentinel、必要な外部サービス権限を個別に確認する |
Microsoftは最小権限のロール利用を推奨しています。全員に広い権限を付与すると移行作業は楽になりますが、インシデント対応基盤自体が攻撃対象になった場合の影響が大きくなります。(Microsoft Learn)
データコネクタとログ収集の注意点
Defenderポータルへ統合しても、Microsoft Sentinelのデータ収集アーキテクチャやテレメトリの流れは基本的に維持されます。既存のMicrosoft Sentinelデータコネクタは中断なく動作し、Log Analyticsの取り込みパイプラインやデータスキーマにも変更はないと説明されています。(Microsoft Learn)
ただし、ここで油断しやすいのが「画面上に見えないコネクタ」です。Defenderポータルへオンボード後、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps、Microsoft Defender XDRなど一部のコネクタは、DefenderポータルのData connectorsページに表示されない場合があります。それでもAzure portal側には引き続き表示されるとされています。(Microsoft Learn)
Defender for Cloud連携は重複に注意する
Microsoft Defender for Cloudを使っている場合は、テナントベースのコネクタと従来のサブスクリプションベースのコネクタの扱いに注意が必要です。公式情報では、テナントベースのDefender for Cloudコネクタを使っている場合は重複イベントや重複アラートを防ぐための対応が必要で、従来のサブスクリプションベースのコネクタを使っている場合はMicrosoft Defenderへのインシデント・アラート同期を無効化する確認が必要とされています。(Microsoft Learn)
確認すべき実務ポイントは次の3つです。
| 確認ポイント | 具体的な見方 |
|---|---|
| 同じアラートが二重に出ていないか | Sentinel incidentsとDefender incidentsの件名、発生元、時刻を比較する |
| プライマリワークスペースが正しいか | Defender XDR連携の中心にしたいワークスペースか確認する |
| レガシーコネクタが残っていないか | Defender for Cloudの旧コネクタと新しい連携方式を棚卸しする |
分析ルールとインシデント相関で変わること
Microsoft Sentinelの分析ルールはDefenderポータルでも作成、更新、管理できます。ルールの基本機能は維持され、ウィザード、リポジトリ、Microsoft Sentinel APIによる管理も引き続き可能です。一方で、アラート相関やインシデント統合の考え方は、Defender XDRエンジンの影響を受けます。(Microsoft Learn)
特に重要なのは、Azure portalでFusion分析ルールが担っていた高度な相関が、DefenderポータルではDefender XDR側のインシデント作成・相関機能に置き換わる点です。DefenderポータルへオンボードするとFusion分析ルールは無効化されますが、相関機能そのものを失うわけではありません。(Microsoft Learn)
ルール検証で見るべき観点
移行前後で次のような差分が起きないか確認してください。
| 観点 | 確認方法 |
|---|---|
| インシデント件数 | 移行前後で同じ検知ルールのインシデント数が急増・急減していないか |
| 相関結果 | 複数アラートが想定通り1つのインシデントにまとまるか |
| 担当振り分け | 統合インシデント化により、従来の担当チーム分類が崩れていないか |
| 抑制・チューニング | Defenderポータル側のAlert tuningで誤検知を抑制できているか |
| アラートのみ生成するルール | インシデント作成をオフにしたアラートがDefenderポータルで見えない問題がないか |
公式情報では、Microsoft Sentinel分析ルールで「アラートのみをトリガーし、インシデント作成をオフ」にしている場合、それらのアラートはDefenderポータルに表示されないと説明されています。既存ルールにこの設定が含まれる場合は、移行前に必ず棚卸ししてください。(Microsoft Learn)
自動化ルールとPlaybooksの注意点
Microsoft SentinelのAutomation rulesとPlaybooksは、Defenderポータル移行で特に影響が出やすい領域です。理由は、インシデントのプロバイダー名、フィールド、同期タイミング、相関結果が変わると、自動化の条件にズレが出るためです。
たとえば、Defenderポータルへのオンボード後は、すべてのインシデントのproviderがMicrosoft XDRとして扱われます。また、SecurityIncidentテーブルからDescriptionフィールドがなくなるため、このフィールドをAutomation ruleの条件や外部チケット連携で使っている場合は、移行後に想定通り動かない可能性があります。(Microsoft Learn)
失敗しやすい自動化条件
| 既存の条件・実装 | 起きやすい問題 | 対応 |
|---|---|---|
| インシデントタイトルで分岐 | 相関によりタイトルが変わり、条件に一致しない | 分析ルール名、タグ、エンティティ情報を使う |
| Descriptionフィールドを参照 | 移行後にフィールドがなく、チケット本文が空になる | 代替フィールドやコメント、カスタム詳細を使う |
| providerNameでAzure Sentinelを判定 | DefenderポータルではMicrosoft XDRになる | 条件式を見直す |
| Playbookをアラートやエンティティに手動実行 | Defenderポータルでは一部手順が未対応 | インシデント起点の実行に寄せる |
| 複数ワークスペースでXDR連携 | プライマリワークスペースだけに取り込まれる可能性 | Automation ruleの配置先を見直す |
Microsoftは、インシデント名をAutomation ruleの条件に使うのではなく、アラートを作成した分析ルール名やタグを条件に使うことを推奨しています。相関エンジンによってインシデント名が変わる可能性があるためです。(Microsoft Learn)
開発者が確認すべきAPI連携
開発者やSREが最初に確認すべきなのは、既存のスクリプトや外部連携が「Microsoft Sentinelのリソース操作」なのか、「統合インシデントやアラートの操作」なのかという切り分けです。
Microsoft Sentinel APIは、分析ルールやAutomation rulesなどMicrosoft Sentinelリソースへの操作を引き続きサポートします。一方、統合インシデントやアラートを扱う場合は、Microsoft Graph REST APIの利用が推奨されています。既存のSecurityInsights APIでインシデントを扱っている場合は、レスポンス本文や条件判定の更新が必要になる可能性があります。(Microsoft Learn)
API移行で見るべきフィールド
| 観点 | Azure portal中心の実装 | Defenderポータル中心の実装で確認する値 |
|---|---|---|
| インシデントURL | incidentUrl | providerIncidentUrlも確認 |
| アラート発生元 | alertProductNames | ?$expand=alertsを付けて取得する必要がある場合あり |
| プロバイダー名 | Azure Sentinel | Microsoft XDR |
| サービス発生元 | なし | serviceSource |
| 検出ソース | なし | detectionSource |
| 製品名 | なし | productName |
実装例として、統合インシデントの詳細と関連アラートを同時に参照したい場合は、Microsoft Graph APIで次のような考え方になります。
GET /security/incidents/{incident-id}?$expand=alertsここで重要なのは、単にAPIのエンドポイントを置き換えることではありません。チケットシステム、SlackやTeams通知、SOAR処理、監査ログ保存のどこでproviderNameやURL、説明文、アラート発生元を使っているかを洗い出すことです。
移行・展開時のおすすめ手順
既存環境をDefenderポータルへ移行する場合は、いきなり本番SOCの導線を切り替えるのではなく、次の順序で進めると失敗を減らせます。
| 手順 | 作業内容 | 完了判断 |
|---|---|---|
| 現状棚卸し | ワークスペース、コネクタ、分析ルール、Playbooks、API連携を一覧化 | 影響を受ける設定がリスト化されている |
| 権限確認 | Owner、User Access Administrator、Sentinel Contributor、Sentinel Readerを確認 | オンボード担当と運用担当の権限が分離されている |
| Defenderポータル接続 | System > Settings > Microsoft Sentinelからワークスペース接続 | Microsoft Sentinelメニューと対象ワークスペースが見える |
| 検知確認 | 主要な分析ルールとインシデント生成を検証 | 期待したインシデントが作成・相関される |
| 自動化確認 | Automation rules、Playbooks、外部チケット連携を実行確認 | 条件分岐、本文、担当者、ステータス更新が正しく動く |
| SOC手順更新 | トリアージ、エスカレーション、クエリ保存場所を更新 | アナリストがDefenderポータルだけで一次対応できる |
| 本番切替 | Azure portal前提の手順を段階的に廃止 | 旧手順に依存する作業が残っていない |
Defenderポータルへの移行自体について、Microsoftは非E5顧客でも追加コストは発生せず、Microsoft Sentinelの使用量に基づく通常の課金が継続されると説明しています。ただし、データ取り込み量、保持期間、Playbooks、関連するAzureリソースのコストは別途影響するため、移行時にはコスト見積もりも合わせて確認してください。(Microsoft Learn)
導入・移行でよくある誤解
Microsoft Sentinelが廃止されるわけではない
廃止が予定されているのは、Azure portalにおけるMicrosoft Sentinelのサポートです。Microsoft Sentinel自体はMicrosoft Defenderポータルで利用する形に移行していきます。ここを誤解すると、不要なSIEM移行プロジェクトを立ち上げたり、検知ルール資産を早急に捨てたりする判断につながります。
Defender XDRやE5がないと使えないわけではない
Microsoft Sentinelは、Microsoft Defender XDRやE5ライセンスがない顧客でもMicrosoft Defenderポータルで利用できます。ただし、Defender XDR由来の機能や一部の統合機能は利用状況によって変わるため、「Sentinelは使える」と「Defender XDRの全機能が使える」を混同しないことが重要です。(Microsoft Learn)
画面移行だけでは済まない
Defenderポータルへの移行は、メニューの場所が変わるだけではありません。統合インシデントキュー、相関エンジン、APIレスポンス、Automation ruleの条件、Playbook実行タイミング、SOCの担当分担に影響します。特に外部チケット連携を使っている場合は、インシデントURLや説明文、プロバイダー名の扱いを必ず確認してください。
まず何をすべきか
Microsoft Sentinel SIEMを利用している、またはこれから導入する組織は、次の3点から始めるのが現実的です。
- 既存環境がAzure portal前提の運用になっていないか棚卸しする
- Microsoft Defenderポータルでワークスペース、権限、データコネクタ、インシデント表示を確認する
- Automation rules、Playbooks、API連携、チケット連携を重点的にテストする
Microsoft Sentinelは、クラウドネイティブなSIEM/SOARとして、ログ収集、脅威検出、調査、対応自動化をまとめる中核サービスです。2026年時点の実務では、機能理解だけでなく、Microsoft Defenderポータル中心の運用へ計画的に移行できるかが重要になります。まずは本番環境の設定一覧を作り、影響が大きい自動化とAPI連携から検証を始めてください。
コメント