2026年5月14日に更新された公式情報「Microsoft Sentinel skill-up training」は、Microsoft Sentinelをレベル400相当で学ぶためのトレーニング集です。Microsoft Defender管理者にとっての結論は、この更新自体は緊急の設定変更を求める製品アップデートではなく、Defender XDRとMicrosoft Sentinelを統合運用するために確認すべき学習・設計・移行ポイントを整理した公式リソースとして読むのが適切です。特に、Defenderポータルへの移行、Defender XDRコネクタ、インシデント同期、KQL、分析ルール、SOAR、自動化、コスト管理は、運用前に必ず確認しておきたい領域です。(Microsoft Learn)
Microsoft Sentinel skill-up trainingとは
Microsoft Sentinel skill-up trainingは、Microsoft Sentinelの導入・設計・運用・拡張を体系的に学ぶための公式トレーニング記事です。公式ページでは、SOCのライフサイクルに沿って、21個のセルフペースモジュールを5つのパートに分けています。対象は入門者というより、実際にMicrosoft SentinelやMicrosoft Defender XDRを設計・運用する管理者、SOC担当者、セキュリティエンジニア、開発者です。(Microsoft Learn)
今回押さえるべきポイントは、Microsoft Sentinel単体の学習ではなく、Microsoft Defenderを含むセキュリティ運用全体の見直しに使えることです。Microsoft SentinelはSIEM/SOARとして、Microsoft Defender XDRはエンドポイント、ID、メール、SaaSアプリなどの脅威保護として機能します。両者を組み合わせると、インシデント、アラート、エンティティ、ハンティングの調査体験を統合しやすくなります。(Microsoft Learn)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 公式ページの更新日 | 2026年5月14日 | 最新の学習導線として再確認する価値がある |
| トレーニングレベル | Level 400 | 基本操作だけでなく、設計・移行・自動化・API活用まで扱う |
| モジュール数 | 21モジュール | SOC運用の全体像を分担学習しやすい |
| 対象領域 | 概要、設計と展開、コンテンツ作成、運用、高度な拡張 | 管理者、SOC、開発者で見るべき箇所が異なる |
| Microsoft Defenderとの関係 | Defender XDR連携、統合インシデント、高度なハンティング、Defenderポータル移行と関係が深い | SentinelだけでなくDefender運用設計の確認にも使える |
2026年5月14日更新で何が変わるのか
公式ページ内で確認できる確実な変更点は、ページの最終更新日が2026年5月14日であることです。ただし、ページ本文だけでは、前回版からどのモジュールやリンクが新規追加・変更されたかまでは断定できません。そのため、実務では「新機能が強制適用された」と読むのではなく、Microsoft SentinelとMicrosoft Defender XDRを統合運用するための公式学習ハブが更新されたと捉えるのが安全です。(Microsoft Learn)
重要なのは、トレーニング記事そのものよりも、そこからたどるべき関連領域です。Microsoft SentinelはDefenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスがない顧客でもDefenderポータルでSentinelを使用できます。また、2027年3月31日以降、Microsoft SentinelはAzure portalではサポートされず、Microsoft Defenderポータルでのみ利用可能になる予定です。(Microsoft Learn)
つまり、管理者が今やるべきことは、単にトレーニングを読むことではありません。現在のワークスペース、コネクタ、分析ルール、自動化ルール、KQLクエリ、インシデント対応フローが、Defenderポータル中心の運用に移っても問題なく動くかを確認することです。
Microsoft Defender管理者への影響範囲
Microsoft Sentinel skill-up trainingの更新は、すべてのMicrosoft Defender利用者に同じ影響を与えるものではありません。影響が大きいのは、Defender XDRとSentinelを連携している、または今後連携する組織です。
| 対象者 | 影響 | 確認すべきポイント |
|---|---|---|
| Microsoft Defender XDR管理者 | DefenderのインシデントやアラートがSentinelと連携する | Defender XDRコネクタ、インシデント同期、アラート重複防止 |
| Microsoft Sentinel管理者 | Azure portal中心の運用からDefenderポータル中心の運用へ移行が必要になる | ワークスペース、データコネクタ、分析ルール、Automation、Watchlists |
| SOCアナリスト | インシデント調査、エンティティ確認、ハンティングの画面や流れが変わる | 統合インシデント、高度なハンティング、Security Copilot活用 |
| 開発者・自動化担当 | KQL、API、Logic Apps、Playbook、Notebookの確認が必要 | 既存クエリ、スキーマ変更、API連携、CI/CD |
| MSSP・大規模組織 | 複数テナント・複数ワークスペースの設計に影響する | RBAC、データ所在地、ワークスペース分割、権限委任 |
特に注意したいのは、Defender XDRとMicrosoft Sentinelの統合方法です。Microsoft SentinelをDefenderポータルにオンボードし、Defender XDRライセンスがある場合、SentinelはDefender XDRに自動接続され、Defender XDRデータコネクタも自動的に設定されます。このとき、Defender XDRコネクタに含まれる個別のアラートプロバイダー用コネクタは切断されます。対象にはMicrosoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender for Cloud Apps、Microsoft Entra ID Protectionなどが含まれます。(Microsoft Learn)
管理者が最初に確認すべき設定
Defenderポータルへの移行計画
現在Azure portalでMicrosoft Sentinelを使っている場合は、Defenderポータルへの移行計画を早めに作るべきです。Microsoftの公式情報では、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Defenderポータルでのみ利用可能になるとされています。(Microsoft Learn)
移行計画では、次の項目を棚卸しします。
- Microsoft Sentinelワークスペース
- 接続済みデータコネクタ
- Defender XDRとの接続状態
- 分析ルールとスケジュール
- 自動化ルールとLogic Apps Playbook
- Watchlists
- Workbooks
- KQLクエリ
- SOCの運用手順書
- API連携や外部チケットシステム連携
単に「画面が変わる」だけではありません。インシデントの見え方、ハンティングの場所、設定メニュー、権限管理、データポリシーの考え方も変わる可能性があります。
Microsoft Defender XDRコネクタ
Azure portalでMicrosoft Sentinelを引き続き操作している環境では、Microsoft Defender XDRデータをSentinelに同期するために、Microsoft Defender XDRコネクタを有効化します。公式手順では、Microsoft SentinelのContent HubからMicrosoft Defender XDRソリューションをインストールし、Defender XDRデータコネクタを有効にしてインシデントとアラートを収集します。(Microsoft Learn)
確認すべきポイントは、コネクタが「接続済み」と表示されるかだけではありません。実際にインシデントが流れているかをKQLで確認する必要があります。公式手順では、次のようにSecurityIncidentテーブルでProviderName == "Microsoft XDR"を確認する例が示されています。(Microsoft Learn)
SecurityIncident
| where ProviderName == "Microsoft XDR"この確認を本番移行後に初めて行うのは危険です。検証用ワークスペースや限定範囲で先に確認し、インシデント件数、重大度、所有者、ステータス、タグ、コメントがSOCの想定どおりに扱えるかを見ておきましょう。
インシデント作成ルールと重複防止
Defender XDRを接続すると、同じアラートに対して重複インシデントを作らないよう、Defender XDR統合製品のMicrosoftインシデント作成ルールがオフになります。これは合理的な挙動ですが、既存の運用に影響する可能性があります。(Microsoft Learn)
特に注意すべきなのは、インシデント名を条件にした自動化ルールです。Defender XDRコネクタ有効化後は、Defender XDRの関連付けエンジンがインシデント作成と命名を管理するため、インシデントタイトルを事前に決められません。公式情報でも、インシデント名ではなくタグなどを条件に使うことが推奨されています。(Microsoft Learn)
実務では、次のように見直します。
| 既存の条件 | リスク | 推奨される見直し |
|---|---|---|
| インシデントタイトルに特定文字列が含まれる | 自動命名により条件が一致しなくなる | タグ、重大度、プロダクト名、エンティティ種別を使う |
| 個別Defender製品のコネクタ前提のKQL | XDRコネクタ移行でスキーマ差分が出る可能性 | テーブル名、列名、Alert product nameを再確認 |
| アラート単位でチケットを起票 | Defender XDR側でインシデントが集約される | インシデント単位の起票に見直す |
| すべての検知を即時通知 | 統合後に通知件数や粒度が変わる | 重大度、タグ、エンティティで通知条件を調整 |
Defender for Cloudの扱い
Defender XDRコネクタはMicrosoft Defender for Cloudからのインシデントも提供します。ただし、それらのインシデントからアラートとエンティティも同期するには、Microsoft Sentinel側でDefender for Cloudコネクタを有効にする必要があります。有効にしていない場合、Defender for Cloudインシデントが空で表示される可能性があります。(Microsoft Learn)
クラウドワークロードを監視している組織では、これは見落としやすいポイントです。Azure、マルチクラウド、サーバー、コンテナー、クラウドセキュリティ態勢管理を含む運用では、Defender for Cloudのアラートが調査時に十分なコンテキストを持って表示されるかを必ず確認してください。
開発者・自動化担当が確認すべきポイント
Microsoft Sentinel skill-up trainingには、KQL、ASIM、Analytics、SOAR、Workbooks、Notebooks、API、機械学習といった開発者寄りのモジュールが含まれています。Microsoft Defender環境で高度な検知や自動化を行っている場合、ここが最も実務に直結します。(Microsoft Learn)
KQLと分析ルール
Microsoft Sentinelの多くの機能ではKusto Query Language、つまりKQLを使います。ログ検索、分析ルール、ハンティングクエリ、Workbooksの設計ではKQLの品質が検知精度と調査効率に直結します。(Microsoft Learn)
確認すべきなのは、クエリが動くかどうかだけではありません。次の観点で見直します。
- Defender XDRコネクタ移行後も参照テーブルと列が正しいか
- 個別Defender製品のアラート前提で書いた条件が残っていないか
joinやunionが過剰で、クエリが重くなっていないか- 誤検知を除外する条件が古くなっていないか
- ASIMを使ってデータソース横断の検知にできないか
- 検知ルールの実行間隔とルックバック期間が妥当か
特に、既存SIEMからMicrosoft Sentinelへ移行する場合、Splunk SPLやQRadar、ArcSightのルールをそのままKQLへ置き換えるだけでは不十分です。Microsoft Sentinelのデータ構造、Defender XDRのインシデント集約、ASIMの正規化を前提に再設計する必要があります。(Microsoft Learn)
ASIMでデータソース横断の検知を作る
ASIMは、複数のデータソースを正規化されたビューで扱うための仕組みです。公式トレーニングでは、ASIMによりオンプレミスやクラウドを横断した検知、ソースに依存しないコンテンツ、カスタムソースの組み込みがしやすくなると説明されています。(Microsoft Learn)
実務では、次のような場面で有効です。
| 活用シーン | ASIMを使う理由 |
|---|---|
| 複数のID基盤をまたいだ不審ログイン検知 | フィールド名や形式をそろえて比較しやすい |
| Defender for EndpointとSysmonを併用 | プロセスイベントを共通の形で扱いやすい |
| AWS、Azure、SaaSのログを横断調査 | ソース別クエリを減らせる |
| 将来のログソース追加に備える | ソース追加後も既存コンテンツを流用しやすい |
ASIMは便利ですが、導入すれば自動的に検知品質が上がるわけではありません。パーサーの品質、対象データの網羅性、運用チームのKQL理解が必要です。まずは既存の高頻度クエリや重要な分析ルールからASIM化を検討すると、効果を測りやすくなります。
SOARとPlaybook
Microsoft SentinelのSOARでは、Automation rulesとLogic Apps Playbooksが重要です。公式トレーニングでは、インシデント処理、誤検知対応、自動割り当て、Playbookによるワークフロー自動化が扱われています。(Microsoft Learn)
Defender XDR連携後は、次のような自動化を見直します。
- 高重大度インシデントだけTeamsやチケットシステムに通知する
- 特定タグのインシデントだけ担当チームに割り当てる
- 既知の誤検知は自動でクローズする
- 侵害端末の隔離やユーザー無効化は承認フローを挟む
- 外部IP、ファイルハッシュ、URLを脅威インテリジェンスで照合する
失敗しやすいのは、「自動化できるから全部自動化する」ことです。端末隔離、ユーザー無効化、メール削除のような影響の大きい処理は、最初は承認付きPlaybookにし、ログと実行結果を確認してから段階的に自動化します。
コストとデータ保持で注意すべき点
Defender XDRからのアラートとインシデントは、SecurityAlertテーブルやSecurityIncidentテーブルに入る項目を含め、Microsoft Sentinelへ無料で取り込まれ、同期されます。一方、DeviceInfo、DeviceFileEvents、EmailEventsなど個別Defenderコンポーネントの高度なハンティングテーブルをSentinelへ取り込む場合は課金対象になります。(Microsoft Learn)
ここを誤解すると、必要以上に大量の生ログを取り込んでコストが増えます。Microsoft Defenderポータルでは、Microsoft SentinelデータとDefender XDRデータを統一されたスキーマで扱えるほか、高度なハンティングの生ログはMicrosoft Sentinelへ取り込まなくても、ハンティング用途で30日間利用できると説明されています。(Microsoft Learn)
実務では、次の基準で判断します。
| データ | Sentinelへ取り込む判断基準 |
|---|---|
| インシデント・アラート | SOCの一次対応、チケット連携、統合キューに必要なら取り込む |
| 高度なハンティングの生ログ | 長期分析、相関分析、独自ルール、監査要件がある場合に限定する |
| 低頻度ログ | アーカイブやデータレイクの利用を検討する |
| 高頻度イベント | 取り込み前にフィルタ、変換、保持期間、検索頻度を確認する |
| 監査証跡 | 法務・内部統制・業界規制の保存要件を確認する |
Microsoft Sentinel skill-up trainingのログ管理モジュールでは、データの保持期間、アクセス管理、コスト、アーカイブ、検索、復元などが扱われています。管理者は、検知精度だけでなく「どのログを、どの期間、どのコストで保持するか」まで設計する必要があります。(Microsoft Learn)
権限、プライバシー、暗号化の確認
Microsoft Defenderポータルへ移行すると、Microsoft Sentinelデータを操作する場合でも、データストレージ、処理、保持、共有についてMicrosoft Defender XDR側のポリシーが適用されます。これはセキュリティ管理者、コンプライアンス担当、法務部門が見落としてはいけない点です。(Microsoft Learn)
また、カスタマーマネージドキーを使っている場合も注意が必要です。公式情報では、オンボード前にCMKを有効にしていたMicrosoft Sentinel対応ワークスペースでは、既存・新規のログデータや分析ルールなどのSentinelコンテンツは引き続きCMKで暗号化されます。一方、オンボード後のアラートとインシデントはCMKで暗号化されないと説明されています。(Microsoft Learn)
権限面では、Azure portalでDefender XDRコネクタを構成する場合、有効なMicrosoft Defender XDRライセンス、テナントのセキュリティ管理者ロールまたは同等権限、Sentinelワークスペースへの読み取り・書き込みアクセス、同一Microsoft Entraテナントのメンバーであることなどが前提になります。(Microsoft Learn)
移行前に、少なくとも次の権限設計を確認してください。
- 誰がMicrosoft Sentinelワークスペースを管理するか
- 誰がDefender XDRのインシデントを操作できるか
- 誰がデータコネクタを変更できるか
- 誰が分析ルールやPlaybookを変更できるか
- SOCアナリストに必要最小限の権限が付与されているか
- MSSPや外部委託先に過剰な権限を与えていないか
- 監査ログを誰が確認するか
Microsoft Sentinel skill-up trainingの使い方
このトレーニングは、最初から最後まで順番に読むだけでは効率がよくありません。組織の役割ごとに、優先して読むモジュールを分けるのが実務的です。
| 役割 | 優先モジュール | 目的 |
|---|---|---|
| セキュリティ責任者 | Module 1、2、5、19 | SentinelとDefenderの位置付け、コスト、運用品質を把握する |
| Sentinel管理者 | Module 3、4、5、7、8 | ワークスペース、データ収集、ログ管理、移行を設計する |
| Defender管理者 | Module 2、4、11、16、17 | Defender XDR連携、インシデント、ハンティングを確認する |
| SOCアナリスト | Module 10、11、16、17、18 | KQL、分析ルール、調査、UEBAを実務に落とし込む |
| 自動化担当 | Module 12、20 | SOAR、Logic Apps、API連携を設計する |
| データ分析・開発者 | Module 9、10、14、21 | ASIM、KQL、Notebook、機械学習を活用する |
まずは、現在困っている領域から読むのがおすすめです。たとえば、誤検知が多いならAnalyticsとWatchlists、調査に時間がかかるならIncident handlingとHunting、コストが増えているならLog management、既存SIEMから移行中ならMigrationとASIMを優先します。
展開・移行時の実務手順
Microsoft DefenderとMicrosoft Sentinelの統合を進める場合は、次の順番で確認すると失敗を減らせます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 現状棚卸し | ワークスペース、コネクタ、ルール、Playbook、権限を一覧化 |
| 2 | 移行方針の決定 | Defenderポータル中心にするか、移行期間中だけAzure portalを併用するか決める |
| 3 | 検証環境で接続確認 | Defender XDRコネクタ、インシデント同期、KQL確認を行う |
| 4 | 既存ルールの影響確認 | インシデント名条件、テーブル名、列名、スキーマ差分を見る |
| 5 | 自動化の再設計 | タグ、重大度、プロダクト名、エンティティを条件にする |
| 6 | コスト確認 | 高度なハンティングテーブルの取り込み対象を絞る |
| 7 | 権限と監査の確認 | RBAC、委任権限、外部委託先アクセスを確認 |
| 8 | SOC手順書の更新 | 画面遷移、トリアージ、エスカレーション、クローズ基準を更新 |
| 9 | 段階展開 | 対象チームや対象ワークスペースを絞って展開 |
| 10 | 本番後レビュー | インシデント件数、誤検知、対応時間、コストを確認 |
この手順で重要なのは、技術設定よりも「運用の再確認」です。Defender XDRとSentinelの統合により、アラートが整理される一方で、既存の通知条件やチケット起票条件が合わなくなることがあります。特にSOCが24時間運用している環境では、移行当日に担当者が画面や手順で迷わないよう、事前に演習しておくべきです。
失敗しやすいポイント
Microsoft Sentinel skill-up trainingを活用する際に、現場で起きやすい失敗は次のとおりです。
| 失敗例 | なぜ問題か | 対策 |
|---|---|---|
| トレーニング更新を製品変更と誤解する | 不要な設定変更を急いでしまう | 公式ページの性質を「学習リソース」として理解する |
| Defender XDRコネクタを有効化して終わる | データフロー、スキーマ、同期を確認していない | KQLでインシデント流入を確認する |
| インシデント名で自動化している | 自動命名で条件が外れる可能性がある | タグや重大度など安定した属性に変更する |
| 高度なハンティングテーブルをすべて取り込む | コストが増えやすい | 長期保存や独自分析に必要なものだけ選ぶ |
| Defender for Cloudコネクタを見落とす | クラウドインシデントの詳細が不足する可能性がある | Defender for Cloudの同期設定を確認する |
| SOC向け教育を後回しにする | 画面変更や調査導線で対応が遅れる | 移行前にトリアージ演習を行う |
| 権限を広く付けすぎる | ルール変更やデータ閲覧のリスクが高まる | 最小権限と監査ログ確認を徹底する |
まとめ：次にやるべきこと
2026年5月14日更新のMicrosoft Sentinel skill-up trainingは、Microsoft Defender管理者にとって、SentinelとDefender XDRを統合運用するための実務チェックリストとして使えます。今回の更新自体を緊急の機能変更として扱う必要はありませんが、Defenderポータルへの移行、Defender XDRコネクタ、インシデント同期、KQL、SOAR、コスト、権限設計は早めに確認すべきです。
次に取るべき行動は明確です。まず現在のMicrosoft Sentinel環境を棚卸しし、Defender XDRとの接続方式、既存の分析ルール、自動化ルール、KQLクエリ、データ取り込みコストを確認してください。そのうえで、管理者は設計・移行モジュール、SOC担当者はインシデント対応・ハンティング・KQLモジュール、開発者はASIM・API・Notebook・SOARモジュールを優先して学習すると、公式トレーニングを実際の運用改善につなげやすくなります。(Microsoft Learn)
コメント