Log retention tiers in Microsoft Sentinelは、Microsoft SentinelとMicrosoft Defender XDRのログを「どのデータを高性能に分析するか」「どのデータを低コストで長期保存するか」に分けて管理するための仕組みです。2026年5月14日に更新された公式情報では、Defenderポータルでのテーブル管理、Analytics tierとData lake tierの使い分け、AzureポータルからDefenderポータルへの移行が重要な確認ポイントになっています。特に、ログをData lake tierのみに移すとアラートや高度なハンティングに影響するため、管理者は「保持期間を延ばす」前に、検知ルール・KQLクエリ・コスト・権限をテーブル単位で確認する必要があります。(Microsoft Learn)
Log retention tiers in Microsoft Sentinelとは
Log retention tiers in Microsoft Sentinelは、Microsoft Sentinelに取り込むログを用途に応じて保持・検索するための階層設計です。基本的な考え方はシンプルで、リアルタイム検知や日常的な調査に使うログはAnalytics tierに置き、長期保管や監査、過去分析に使う大量ログはData lake tierに置きます。
Microsoftは、Sentinelに取り込むデータを大きく次の2種類に分類しています。(Microsoft Learn)
| 分類 | 役割 | 代表例 | 推奨される保持先 |
|---|---|---|---|
| Primary security data | 検知・相関分析・ハンティング・レポートに直接使う重要ログ | EDR、認証ログ、クラウド監査ログ、脅威インテリジェンス、外部システムのアラート | Analytics tier |
| Secondary security data | 単体の重要度は低いが、調査時の文脈補強や長期分析に役立つ大量ログ | Firewall、Proxy、NetFlow、TLS/SSL証明書ログ、クラウドストレージアクセスログ、IoTログ | Data lake tier |
実務では、「よく使うログ」と「保管しておきたいログ」を分けるだけでは不十分です。検知ルールが参照しているテーブル、インシデント対応で頻繁に見るテーブル、監査証跡として必要なテーブルを棚卸しし、テーブルごとに保持階層を決める必要があります。
2026年5月14日の更新で押さえるべき変更点
今回のポイントは、単にログ保持期間の説明が増えたことではありません。Microsoft SentinelとMicrosoft Defender XDRのログ管理が、Defenderポータル中心の運用へ寄っている点が重要です。
Microsoft SentinelワークスペースがDefenderに接続されている場合、階層化と保持期間の管理はDefenderポータルの新しいTable management体験から行う必要があります。一方、Defenderに接続されていないSentinelワークスペースでは、従来の管理方法を引き続き使う前提です。(Microsoft Learn)
また、Microsoftは2027年3月31日以降、Microsoft SentinelをAzureポータルではサポートせず、Microsoft Defenderポータルのみで利用できるようにすると案内しています。Azureポータル中心でSentinelを運用している組織は、ログ保持設定だけでなく、データコネクタ、分析ルール、権限、運用手順書の移行も計画に含めるべきです。(Microsoft Learn)
変更点の整理
| 確認項目 | これまでの運用で起きがちな状態 | 2026年5月14日時点で意識すべきこと |
|---|---|---|
| 管理画面 | Azureポータル、Log Analytics、Sentinel画面を使い分ける | Defender接続済みワークスペースはDefenderポータルのTablesで管理する |
| 保持階層 | すべてAnalytics前提で保持期間を延長しがち | Analytics tierとData lake tierを用途別に分ける |
| コスト管理 | 取り込み量だけを見る | 取り込み、保存、クエリ、Data lake保持を分けて見る |
| XDRデータ | Defender XDR側の既定保持だけで運用しがち | Sentinel側に取り込むか、Data lakeへ保持するかを判断する |
| 移行 | Azureポータル前提の手順書が残る | Defenderポータル前提に運用手順を更新する |
Analytics tierとData lake tierの違い
Analytics tierは、リアルタイム検知や高性能な対話型クエリのための階層です。Microsoft Sentinelのアラート、分析ルール、ハンティング、ワークブックなど、日々のSOC運用で使うログは基本的にAnalytics tierに置くべきです。
Data lake tierは、長期保存と大容量データの保管に向いた階層です。リアルタイム分析には向きませんが、KQLジョブ、Sparkジョブ、Notebookなどを使って、長期間の傾向分析やフォレンジック調査に活用できます。Microsoft Sentinel data lakeは、長期のセキュリティデータを集約し、必要に応じてKQLやJupyter Notebookで分析できる基盤として説明されています。(aka.ms)
| 比較項目 | Analytics tier | Data lake tier |
|---|---|---|
| 主な用途 | リアルタイム検知、アラート、ハンティング、ワークブック | 長期保存、監査、過去分析、大量ログ保管 |
| クエリ性能 | 高性能で対話的な検索に向く | 大規模検索は可能だが、リアルタイム分析向けではない |
| 検知ルールでの利用 | 適している | 制限がある |
| コストの考え方 | 取り込み・保持期間延長の影響を受けやすい | 長期保存に向くが、保存期間やクエリ量に注意 |
| 代表的なログ | 認証、EDR、クラウド監査、重要アラート | Proxy、Firewall、NetFlow、IoT、クラウドストレージアクセス |
Data lake tierを使うメリットは、ログの網羅性を落とさずに長期保持しやすくなることです。ただし、「安いから全部Data lakeにする」という判断は危険です。Data lake tierのデータはリアルタイム分析機能や脅威ハンティングで制限を受けるため、検知に使うログまで移すと、検知抜けや調査遅延につながります。(aka.ms)
保持期間で確認すべきポイント
Microsoft Sentinelの保持設定では、単に「何日保存するか」ではなく、次の2つを分けて考えます。
| 設定 | 意味 | 実務での見方 |
|---|---|---|
| Analytics retention | Analytics tierで高性能に使える期間 | 検知ルール、ハンティング、調査に必要な期間を設定する |
| Total retention | Data lakeを含めた全体の保持期間 | 監査、法令、社内ポリシー、過去調査に必要な期間を設定する |
Analytics tierでは、Microsoft Sentinelのデータは90日、Microsoft Defender XDRのデータは30日が保持期間の基準として示されています。Analytics tierの保持期間は最大2年まで延長でき、Data lake tierを使うと合計保持期間を最大12年まで延長できます。ただし、テーブル種別やライセンス、設定内容によって課金の扱いが変わるため、実際の運用では各テーブルの設定画面とコスト管理画面で確認することが重要です。(aka.ms)
たとえば、認証ログを90日だけAnalytics tierに置き、1年分はData lake tierで保持する構成なら、直近の調査は高速に実行しつつ、過去の監査やインシデント再調査にも対応できます。一方、FirewallログをすべてAnalytics tierで1年保持すると、調査性能は高くてもコストが膨らみやすくなります。このようなログは、必要な集計だけをAnalytics tierに残し、詳細ログはData lake tierへ置く設計が現実的です。
影響を受ける管理者・開発者
Log retention tiers in Microsoft Sentinelの影響を受けるのは、Sentinel管理者だけではありません。Microsoft Defender XDR、Microsoft Sentinel、Log Analytics、Azure課金、SOC運用、KQL開発に関わる担当者が横断的に確認する必要があります。
セキュリティ管理者
セキュリティ管理者は、どのテーブルが検知やインシデント対応に使われているかを確認する必要があります。特に次のログは、Data lake tierのみに移す前に慎重に判断してください。
- 分析ルールが参照しているテーブル
- Advanced huntingや日次ハンティングで使うテーブル
- インシデントの相関分析に使うテーブル
- UEBAや行動分析の材料になるテーブル
- 監査レポートや経営向けセキュリティレポートに使うテーブル
Microsoftの説明では、テーブルをAnalytics tierからData lake tierに変更すると、リアルタイム分析やハンティングクエリが動かなくなる可能性があります。DefenderポータルのTable managementでも、Alerting、Advanced hunting、Analytics rules、Custom detection rulesへの影響が警告されます。(aka.ms)
SOCアナリスト
SOCアナリストは、普段使っているKQLクエリがどのテーブルを参照しているかを確認してください。特に、過去90日超のログを使った調査や、インシデント発生後に長期ログを掘り返す手順がある場合、Data lake tierでの検索方法やKQLジョブの実行手順を運用手順書に入れておく必要があります。
「普段は見ないが、重大インシデント時だけ必要になるログ」はData lake tier向きです。ただし、重大インシデント時に初めてData lakeの検索手順を確認するのでは遅いため、平時にサンプルクエリと検索時間、想定コストを検証しておくと安全です。
開発者・自動化担当者
KQL、Logic Apps、Playbook、Notebook、API連携を使っている開発者は、テーブル階層の変更によって参照先や実行性能が変わる可能性を確認しましょう。
特に注意すべきなのは、次のような実装です。
- Analytics tier前提で作ったKQLクエリ
- 定期実行の検知クエリ
- インシデント作成後にログを引くPlaybook
- Workbooksで長期ログを可視化しているダッシュボード
- Notebookで過去ログを分析するフォレンジック手順
Data lake tierでは、KQLジョブやNotebookを活用できますが、Analytics tierと同じ感覚でリアルタイム検知に使う設計は避けるべきです。Data lakeのクエリにはスキャン量に応じた課金が発生するため、定期実行ジョブは対象期間、対象テーブル、フィルター条件を絞ることが重要です。(Microsoft Learn)
Defenderポータルで確認すべき設定
Defenderポータルでは、Microsoft SentinelとMicrosoft Defender XDRのテーブル保持設定を一元的に確認できます。管理対象のテーブルは、Microsoft Sentinelの組み込みテーブル、カスタムテーブル、一部のXDRテーブルなどです。一方、Basic logsテーブルはDefenderポータルで表示できても、現時点ではLog Analyticsワークスペース側で管理する必要があります。(aka.ms)
テーブル保持設定の確認手順
| 手順 | 操作 | 確認すること |
|---|---|---|
| 1 | Microsoft Defenderポータルを開く | 対象テナントとワークスペースが正しいか確認する |
| 2 | Microsoft Sentinel > Configuration > Tables を開く | 管理対象テーブルの一覧を確認する |
| 3 | ワークスペースを選択する | 複数ワークスペース運用では選択ミスを防ぐ |
| 4 | 対象テーブルを選択する | 現在のTier、Analytics retention、Total retentionを確認する |
| 5 | Manage tableを開く | 保持期間やData lake tierへの変更可否を確認する |
| 6 | 警告メッセージを確認する | アラート、ハンティング、分析ルールへの影響を確認する |
| 7 | Saveする | 変更内容を記録し、影響確認を実施する |
保持期間の設定画面では、Analytics retentionを30日から最大2年まで、Total retentionを最大12年まで設定できます。Data lake tierを選ぶ場合は、データをData lakeのみに保存する構成になります。Microsoftの公式手順でも、設定変更時には警告やメッセージを確認することが求められています。(Microsoft Learn)
データコネクタ側で見るべきポイント
データコネクタを新しく有効化する場合も、保持階層の設定が重要です。Microsoft Sentinel data lakeにオンボード済みであれば、コネクタ設定時にデータをAnalytics tierへ送るか、Data lake tierにも保持するか、またはData lake tierのみに送るかを選べます。
公式手順では、Microsoft Sentinel > Configurations > Data connectorsから対象コネクタを開き、Table managementセクションでテーブルを選択して保持設定を変更します。Data lakeへの取り込みは、データが表示されるまで90〜120分かかる場合があります。(Microsoft Learn)
実務では、コネクタ有効化時に次の3点を記録しておくと、後のトラブル調査が楽になります。
| 記録項目 | 例 | 理由 |
|---|---|---|
| 取り込み先 | Analytics tier、Analytics + Data lake、Data lake only | 検知機能への影響を追跡するため |
| 保持期間 | Analytics 90日、Total 1年など | コストと監査要件を確認するため |
| 関連ルール | 分析ルール名、Workbook名、Playbook名 | 階層変更時の影響範囲を判断するため |
Microsoft Defender XDRデータの扱い
Microsoft Defender XDRの脅威ハンティングデータは、既定で30日間Analytics tierに相当する高度なハンティングで利用できます。これをMicrosoft Sentinel側で長く保持する場合、設定によってSentinelの取り込みコストやData lakeの保持コストが関係します。(aka.ms)
たとえば、XDRデータを30日より長く使いたい場合は、31〜90日の範囲でAnalytics tierに拡張する、あるいはData lake tierに長期保持する、といった選択肢があります。ただし、XDRデータをData lake tierのみに取り込む場合でも、取り込み・保存・処理・クエリに関するコストを確認する必要があります。(aka.ms)
Microsoft Defender XDR連携を使っている環境では、次の確認を優先してください。
- Defender XDRコネクタが有効か
- 対象のXDRテーブルがSentinelワークスペースに作成されているか
- XDRデータの保持期間を30日超にしているか
- Analytics tierに保持する必要がある検知・調査ユースケースがあるか
- Data lake tierへ移した場合に、既存のAdvanced huntingやカスタム検知が影響を受けないか
コスト面で失敗しやすいポイント
Log retention tiers in Microsoft Sentinelで最も失敗しやすいのは、「Data lake tierは安い」という理解だけで設計してしまうことです。Data lake tierは長期保持に向いていますが、無料で無制限に使えるわけではありません。
Microsoft Sentinel data lakeでは、Data lake tierのみに取り込むデータには取り込み料金と処理料金が発生し、Analytics tierの保持期間を超えてData lakeに残るデータには保存料金が発生します。また、KQLクエリやKQLジョブではスキャンした非圧縮データ量に応じたクエリ料金が発生します。(Microsoft Learn)
コストを抑える判断基準
| 判断ポイント | 推奨アクション |
|---|---|
| 毎日アラートに使う | Analytics tierに残す |
| 月1回程度の監査で使う | Data lake tierを検討する |
| 大量だが検知価値が低い | Data lake tier、または集計結果だけAnalytics tierへ |
| 長期の傾向分析に使う | Data lake tierで保持し、KQLジョブやNotebookで分析 |
| クエリ対象が広すぎる | 期間・列・条件を絞ってスキャン量を減らす |
| 保持期間を短縮する | 削除猶予や復元可否を確認してから変更する |
保持期間を短縮した場合、Microsoftは設定ミスによるデータ損失を避けるため、データ削除まで30日待つと説明しています。一方、保持期間を延長した場合は、まだ削除されていない既存データにも新しい保持期間が適用されます。(aka.ms)
権限とロールの確認
Table managementを安全に使うには、表示権限と変更権限を分けて管理する必要があります。Defenderポータルでテーブル設定を表示するには、Unified RBACのSecurity data basics (read)、またはLog Analyticsワークスペースのテーブル読み取り権限が必要です。設定変更には、Unified RBACのData (manage)、またはLog Analyticsワークスペースの書き込み権限とテーブル書き込み権限が必要です。(Microsoft Learn)
運用上は、SOCアナリストに読み取り権限を付与し、保持階層や保持期間を変更できる権限はセキュリティ管理者やプラットフォーム管理者に限定するのが安全です。Data lake tierへの変更は、検知ルールの停止やコスト増につながる可能性があるため、変更申請とレビューを通す運用にしておくと事故を防げます。
移行時の注意点
Microsoft SentinelをAzureポータル中心に運用している場合、2027年3月31日を待たずにDefenderポータルへの移行計画を進めるべきです。Microsoftは、Defenderポータルへの移行自体に追加コストはなく、Sentinelの利用量に応じた通常の課金が継続すると説明しています。(Microsoft Learn)
移行時は、画面が変わるだけだと考えないほうが安全です。Defenderポータルでは、Microsoft SentinelとMicrosoft Defender XDRが統合されたセキュリティ運用体験として提供され、インシデント管理、高度なハンティング、相関分析などが一体化されます。(Microsoft Learn)
移行前チェックリスト
| 項目 | 確認内容 |
|---|---|
| ワークスペース接続 | SentinelワークスペースがDefenderポータルに接続されているか |
| プライマリワークスペース | 複数ワークスペース環境で正しく指定されているか |
| データコネクタ | 既存コネクタが継続稼働しているか |
| 分析ルール | 参照テーブルと保持階層が一致しているか |
| ハンティングクエリ | Analytics tier前提のクエリがData lake変更で壊れないか |
| RBAC | Azure RBACとDefender Unified RBACの役割分担が明確か |
| 手順書 | Azureポータル前提の画面説明をDefenderポータル向けに更新したか |
| コスト管理 | Analytics、Data lake、クエリ、保存の課金を分けて見られるか |
Microsoftは、Defenderポータルへ統合しても、既存のデータ収集アーキテクチャやLog Analyticsに基づく取り込み・保存・検索の基盤は維持されると説明しています。ただし、一部のコネクタ表示やアラートスキーマには差分があるため、移行後は検知ルールとインシデント対応手順の動作確認を行うべきです。(Microsoft Learn)
Data lakeオンボード時の注意点
Microsoft Sentinel data lakeを使うには、前提条件も確認が必要です。Microsoft DefenderとMicrosoft Sentinelが構成済みであること、課金用のAzureサブスクリプションとリソースグループがあること、Defenderポータルに接続されたMicrosoft Sentinelのプライマリワークスペースがあることなどが求められます。Data lakeはプライマリSentinelワークスペースと同じリージョンにプロビジョニングされ、同じリージョンにあるDefender接続済みワークスペースが対象になります。(Microsoft Learn)
特に注意すべきなのは、Customer-Managed Keys、つまりCMKです。Microsoftは、Microsoft Sentinel data lakeに保存されるデータではCMKが完全にはサポートされず、Data lakeに取り込まれるデータはMicrosoft-managed keysで暗号化されると説明しています。暗号化ポリシーが厳しい組織では、Data lakeを有効化する前にセキュリティ部門、法務、監査部門と確認してください。(Microsoft Learn)
また、Data lakeにオンボードすると、同じリージョンにあるDefender接続済みワークスペースが自動的にData lakeへ接続されます。特定のワークスペースだけを個別に除外する運用は前提にしないほうが安全です。(Microsoft Learn)
実務でおすすめの設計パターン
ログ保持設計は、最初から完璧に決めるよりも、段階的に分類して見直すほうが現実的です。まずは高リスク・高コストのテーブルから確認してください。
パターン1：重要ログはAnalytics tier、長期分だけData lake
認証ログ、EDRログ、重要なクラウド監査ログなどは、直近の調査と検知に使うためAnalytics tierに残します。過去分が必要な場合はTotal retentionを延ばし、Data lake tierに長期保存します。
向いているケースは、アカウント侵害、ラテラルムーブメント、クラウド権限濫用の調査です。直近の検知性能を維持しながら、過去の履歴を追いやすくなります。
パターン2：大量ログはData lake、集計結果だけAnalytics tier
Firewall、Proxy、NetFlow、IoTログのように量が多いログは、すべてをAnalytics tierに置くとコストが増えやすくなります。この場合は詳細ログをData lake tierに保持し、定期的なKQLジョブやSummary rulesで集計結果だけAnalytics tierに残す設計が有効です。
たとえば、Proxyログの全明細はData lake tierに置き、ドメイン別アクセス数、異常な国・地域への通信、ブロック件数の急増などを集計してAnalytics tierへ保存します。これにより、検知に必要な要約データを使いつつ、必要なときは詳細ログを掘り返せます。
パターン3：XDRデータは30日基準で延長要否を判断
Microsoft Defender XDRデータは、まず30日で運用できるかを確認します。30日を超える調査が多い場合や、長期の端末挙動分析が必要な場合は、Analytics tierの延長やData lake tier保持を検討します。
ただし、XDRデータをSentinel側へ長期保持すると、コストやデータ管理範囲が広がります。延長前に、どのテーブルを、何の調査に、どれくらいの頻度で使うのかを明文化してください。
管理者が今すぐやるべきこと
Log retention tiers in Microsoft Sentinelへの対応は、次の順番で進めると失敗しにくくなります。
- Defenderポータルに接続済みのSentinelワークスペースを一覧化する
- Microsoft Sentinel > Configuration > Tablesで主要テーブルのTierと保持期間を確認する
- 分析ルール、Advanced hunting、Workbook、Playbookが参照するテーブルを洗い出す
- Primary security dataはAnalytics tier、Secondary security dataはData lake tier候補として分類する
- Data lake tierへ移す前に、アラートや検知ルールへの影響を検証する
- Data lakeのクエリコスト、保存コスト、取り込みコストをCost Managementで確認する
- Azureポータル前提の運用手順をDefenderポータル前提に更新する
- 2027年3月31日までの移行計画に、権限・教育・手順書更新・検証期間を含める
特に重要なのは、保持期間の延長よりも先に「そのログを何に使うのか」を決めることです。検知に使うログをData lake tierのみに移すと、コストは下がってもセキュリティ運用の品質が落ちる可能性があります。一方で、ほとんど参照しない大量ログをAnalytics tierに置き続けると、コスト最適化の機会を逃します。
Log retention tiers in Microsoft Sentinelは、ログを削るための機能ではなく、必要なログを必要な階層に置くための設計機能です。まずは重要テーブルを棚卸しし、検知に必要なログはAnalytics tier、長期保管や補助調査に使うログはData lake tierという方針で、テーブル単位の保持設定を見直してください。
コメント