Microsoft DefenderポータルでMicrosoft Sentinelのデータ保持期間や保存コストをどう管理すべきか迷っているなら、まず押さえるべき結論はシンプルです。検知・ハンティング・ワークブックで日常的に使うデータはAnalytics tierに置き、監査・長期保管・過去分析が主目的のデータはData lake tierを活用するのが基本方針です。2026年5月14日に更新された公式情報「Manage data tiers and retention in Microsoft Sentinel」では、Microsoft SentinelとMicrosoft Defender XDRのデータをテーブル単位で保持・階層管理する考え方が整理されています。(Microsoft Learn)
今回の内容は、単なるストレージ設定の話ではありません。設定を誤ると、アラート、Advanced Hunting、分析ルール、カスタム検出が動かなくなる可能性があります。一方で、すべてのログを高性能なAnalytics tierに置き続けると、コストが膨らみやすくなります。この記事では、Microsoft Defender管理者、SOC運用担当者、SIEM設計者、開発者が確認すべき変更点、影響範囲、設定時の判断基準を実務目線で整理します。
2026年5月14日更新の「Manage data tiers and retention in Microsoft Sentinel」で押さえる要点
今回の公式情報で重要なのは、Microsoft SentinelとMicrosoft Defender XDRのデータを、テーブル単位で「どの階層に置くか」「何日保持するか」「どの機能で使うか」を管理する運用が明確になった点です。
Microsoft SentinelやMicrosoft Defender XDRに収集されるデータはテーブルに保存され、Microsoft Defenderポータルから保持期間や保存コストに関わる設定を管理できます。管理のタイミングは大きく分けて、データコネクタを構成するときと、既存テーブルを管理するときです。(Microsoft Learn)
特に確認すべきポイントは次の4つです。
| 確認ポイント | 実務上の意味 |
|---|---|
| Analytics tierとData lake tierの使い分け | リアルタイム検知に使うか、長期保管・過去分析に使うかで保存先を分ける |
| テーブル単位の保持期間設定 | 重要なログだけ長く保持し、低優先度ログのコストを抑える |
| Microsoft Defender XDRデータの扱い | 既定の30日保持、90日までの延長、Data lake保存の費用影響を確認する |
| ティア変更時の機能停止リスク | Analytics tierからData lake tierへ移すと、検知・ハンティング系の機能に影響する |
従来のように「ログはとりあえず長く保存する」という設計ではなく、検知に必要な期間、調査に必要な期間、監査に必要な期間を分けて考えることが重要です。
対象になる管理者・開発者
この更新の影響を受けやすいのは、次のような担当者です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Defender管理者 | DefenderポータルでSentinelのテーブル保持設定を変更できる権限があるか |
| Microsoft Sentinel管理者 | テーブルごとのAnalytics retentionとTotal retentionが適切か |
| SOC運用担当者 | 検知ルール、ハンティングクエリ、ワークブックが参照するテーブルがAnalytics tierに残っているか |
| セキュリティアーキテクト | コスト最適化と調査性能のバランスが設計されているか |
| 開発者・自動化担当者 | KQL、Notebook、Playbook、カスタム検出がティア変更後も期待どおり動くか |
| コンプライアンス担当者 | 長期保持が必要なログをData lake tierで保持できているか |
特に注意したいのは、Microsoft Defender XDRのAdvanced HuntingデータをSentinel側でも長期利用したいケースです。既定の30日を超えて利用する場合、保持期間の延長やData lake tierへの保存がコストと機能の両面に影響します。
データ階層はAnalytics tierとData lake tierの2つで考える
Microsoft Sentinelのデータ保持は、主にAnalytics tierとData lake tierで考えます。公式情報では、Analytics tierはアラート、ハンティング、ワークブックなどのMicrosoft Sentinel機能で利用できる高性能な階層、Data lake tierは長期保管向けの低コストな階層として説明されています。(Microsoft Learn)
Analytics tierはリアルタイム検知に必要なデータ向け
Analytics tierは、日々のセキュリティ運用で直接使うデータに適しています。たとえば、次のような用途です。
| 用途 | Analytics tierが必要な理由 |
|---|---|
| 分析ルールによるアラート生成 | リアルタイムまたは準リアルタイムの検知に使うため |
| Advanced Hunting | 高速なクエリと調査が必要なため |
| Workbooks | ダッシュボードで継続的に可視化するため |
| インシデント調査 | 直近の端末、ID、クラウド操作ログを素早く追跡するため |
| カスタム検出ルール | 定期的な検知クエリの対象になるため |
Analytics tierの保持期間は、テーブル設定画面で管理できます。公式情報では、Analytics retentionは30日から最大2年まで設定でき、Total retentionはData lake側の長期保持として最大12年まで設定できるとされています。(Microsoft Learn)
実務では、すべてのテーブルを長期間Analytics tierに置くのではなく、検知・調査に本当に必要なテーブルだけを長めに保持するのが現実的です。
Data lake tierは長期保管・監査・過去分析向け
Data lake tierは、リアルタイム検知ではなく、長期保管や過去分析に向いています。公式情報では、Data lake tierのデータはリアルタイム分析機能や脅威ハンティングには使えない一方、KQL jobs、Spark jobs、Summary rulesなどで利用できると説明されています。(Microsoft Learn)
Data lake tierが向いている代表例は次のとおりです。
| データ例 | Data lake tierが向いている理由 |
|---|---|
| 監査ログ | 普段は参照頻度が低いが、証跡として長期保持したい |
| DNS、Proxy、Firewallログ | 大容量になりやすく、すべてをAnalytics tierに置くとコストが大きい |
| 過去のEDRイベント | 直近の検知より、事後調査や傾向分析で使うことが多い |
| コンプライアンス用ログ | 規制や社内規程に合わせて数年単位で保持したい |
| 低頻度の外部サービスログ | 通常運用では使わないが、重大インシデント時に参照したい |
Data lake tierは「安く長く保存できる場所」と考えると分かりやすいですが、Analytics tierの代替ではありません。検知ルールや日常的なハンティングに使うテーブルをData lake tierのみに移すと、運用に支障が出ます。
Analytics tierとData lake tierの違い
判断に迷う場合は、「そのデータをリアルタイムに使うか」「後から調査できればよいか」で切り分けます。
| 比較項目 | Analytics tier | Data lake tier |
|---|---|---|
| 主な用途 | 検知、アラート、ハンティング、ワークブック | 長期保管、監査、過去分析、フォレンジック |
| クエリ性能 | 高速な対話型クエリ向け | 長期データの検索・分析向け。リアルタイム分析には不向き |
| 分析ルール | 利用可能 | 基本的に対象外 |
| Advanced Hunting | 利用可能 | Analytics tierと同じ使い方はできない |
| コスト設計 | 高性能だが長期保持は費用増になりやすい | 長期保持に向くが、クエリや処理に別途費用が発生する場合がある |
| 適したデータ | 直近のインシデント調査で頻繁に使うログ | 参照頻度は低いが捨てられないログ |
重要なのは、Data lake tierに移したからといって「何でも同じように検索できる」と考えないことです。Data lake tierでは、KQL jobsやNotebookなどを使った分析は可能ですが、リアルタイムの検知や通常のハンティング運用とは使い勝手が異なります。
Microsoft Defender XDRデータの保持で変わること
Microsoft Defender XDRの脅威ハンティングデータは、既定で30日間利用できます。公式情報では、サポートされるXDRテーブルの保持期間を30日を超えて90日まで延長すると、Sentinelの取り込みコストは発生するものの、ストレージコストは追加されないと説明されています。90日を超えてAnalytics tierに保持する場合は、ストレージコストも考慮が必要です。(Microsoft Learn)
実務上は、次のように考えると設計しやすくなります。
| 保持方針 | 向いているケース | 注意点 |
|---|---|---|
| 30日保持 | Defender XDR標準の調査期間で十分な組織 | 長期調査や監査要件には不足する可能性がある |
| 31〜90日保持 | 直近数カ月の端末・ID調査をSentinelで行いたい組織 | Sentinel側の取り込みコストを確認する |
| 90日超のAnalytics保持 | 長期にわたり高速な調査が必要な重要テーブル | ストレージコストが増える可能性がある |
| Data lake tier中心 | 長期保管・フォレンジック・監査が主目的 | リアルタイム検知やAdvanced Hunting用途には向かない |
たとえば、DeviceEventsやAlertInfoのようなXDR関連テーブルを長期調査に使う場合、どの期間までをAnalytics tierに置くかを明確に決める必要があります。ランサムウェア調査や内部不正調査では、30日を超える端末操作履歴が必要になることがあります。一方で、すべてのXDRイベントを長期間Analytics tierに置くとコストが増えやすいため、重要テーブルだけを延長する設計が現実的です。
管理できるテーブルと管理できないテーブルを確認する
Microsoft Defenderポータルで管理できるテーブルには、Microsoft Sentinelの組み込みテーブル、カスタムテーブル、Microsoft Defender XDR関連テーブルなどがあります。ただし、すべてのテーブルを同じように管理できるわけではありません。
公式情報では、Defenderポータル上でBasic logsテーブルを表示できるものの、現時点では管理はLog Analyticsワークスペース側で行う必要があると説明されています。Defenderポータルで管理したい場合は、テーブルプランをBasicからAnalyticsへ変更する必要があります。(Microsoft Learn)
| テーブル種別 | 例 | Defenderポータルでの扱い |
|---|---|---|
| Microsoft Sentinel組み込みテーブル | SecurityAlert、SigninLogsなど | 管理対象 |
| カスタムテーブル | _CL、_SRCHなどのサフィックスを持つテーブル | 管理対象 |
| XDR default tierのテーブル | IdentityInfoなど | 表示できるが、管理できないものがある |
| Basic logsテーブル | Basicプランのログテーブル | 表示は可能。管理はLog Analytics側が基本 |
テーブル設定を変更する前に、まず「そのテーブルが本当にDefenderポータルで管理可能か」を確認してください。特にBasic logsとXDR default tierの扱いを誤解すると、期待した保持設定が反映されない可能性があります。
設定変更の影響範囲
保持期間やティアはいつでも変更できますが、変更の影響は軽くありません。公式情報では、テーブルをAnalytics tierからData lake tierへ変更すると、リアルタイム分析やハンティングクエリが動作しなくなると説明されています。また、Analytics retentionの変更は既存データに即時反映されます。(Microsoft Learn)
Analytics tierからData lake tierへ移すと止まりやすい機能
特に影響を受けるのは、次のような機能です。
| 影響を受ける機能 | 起こり得る問題 |
|---|---|
| Analytics rules | 参照テーブルが使えず、検知が成立しなくなる |
| Alerting | アラート生成対象から外れる |
| Advanced Hunting | これまでのクエリが期待どおり動かない |
| Custom detection rules | カスタム検出の条件に必要なデータが欠ける |
| Workbooks | グラフや集計が空になる、または一部しか表示されない |
| Playbooks | トリガー元のアラートやデータが変わり、自動処理が期待どおり動かない |
「低コスト化のためにData lake tierへ移したら、SOCの検知ルールが動かなくなった」という失敗は避けなければなりません。設定変更前に、そのテーブルを参照している分析ルール、ハンティングクエリ、ワークブック、Playbookを洗い出してください。
保持期間を短くする場合はデータ削除タイミングに注意
Total retentionを短くした場合、Microsoftは30日待ってからデータを削除するとされています。これは誤設定を戻せる猶予として役立ちます。一方で、Analytics retentionの変更は即時反映されるため、Analytics tierから外れたデータはリアルタイム分析の対象外になります。(Microsoft Learn)
たとえば、Analytics retentionを180日から90日に短縮し、Total retentionを180日のままにした場合、90日を超えるデータはAnalytics tierからは外れますが、Data lake側には保持されます。この状態では、90日超のデータを使ったリアルタイム検知はできませんが、長期調査用のデータとしては残せます。
Defenderポータルで確認すべき設定手順
既存テーブルの保持期間やティアを確認・変更する場合、Microsoft DefenderポータルのMicrosoft Sentinel設定から作業します。公式手順では、Microsoft Sentinelの「Configuration」配下にある「Tables」から対象テーブルを選び、「Manage table」で保持設定を変更します。(Microsoft Learn)
| 手順 | 確認内容 |
|---|---|
| Microsoft Defenderポータルを開く | Sentinelを利用しているテナント・ワークスペースで作業しているか確認する |
| Microsoft Sentinel > Configuration > Tablesへ移動 | 対象ワークスペースのテーブル一覧を表示する |
| 対象テーブルを選択 | テーブルの説明、現在のティア、保持期間を確認する |
| Manage tableを選択 | Analytics retention、Total retention、Data lake tier設定を確認する |
| 警告メッセージを確認 | 機能停止やコスト増の警告を読み飛ばさない |
| Saveで保存 | 変更後にルール、クエリ、ワークブックの動作を確認する |
データコネクタの設定時にも保持期間やティアを構成できます。コネクタ構成画面では、既定でデータがAnalytics tierへ送信され、Data lake tierにも同じ保持期間でミラーされます。必要に応じてAnalytics retentionやTotal retentionを調整し、Data lake tierのみへの保存も選択できます。(Microsoft Learn)
必要な権限を事前に確認する
テーブル設定を変更するには、単にDefenderポータルへアクセスできるだけでは不十分です。公式情報では、テーブル設定の表示にはDefenderポータルのUnified RBACにおけるSecurity data basics (read)、またはLog Analyticsワークスペースのテーブル読み取り権限が必要とされています。設定変更にはData (manage)やLog Analytics Contributor相当の書き込み権限が必要です。(Microsoft Learn)
| 作業 | 必要な権限の考え方 |
|---|---|
| テーブル設定を見る | セキュリティデータの読み取り権限、またはLog Analytics Reader相当 |
| テーブル設定を変更する | データ管理権限、またはLog Analytics Contributor相当 |
| XDR huntingテーブルを管理する | Microsoft SentinelをDefenderポータルへオンボードしている必要がある |
| 複数ワークスペースを管理する | 対象ワークスペースごとの権限とRBACを確認する |
運用上は、SOC担当者に広く変更権限を付与するのではなく、閲覧権限と変更権限を分けるのが安全です。保持期間の変更はコストと検知能力に直結するため、変更申請、承認、変更後レビューの流れを作っておくとトラブルを防ぎやすくなります。
コスト最適化の判断基準
Microsoft Sentinelのコストは、どのティアに取り込むか、どれだけ保持するか、Data lakeでどれだけクエリや処理を行うかによって変わります。公式の課金情報では、Data lake tierのみへ取り込むデータにはData lake ingestionやdata processingの課金が発生し、Analytics tierの保持期間を超えてData lakeに残るデータにはData lake storageの課金が発生すると説明されています。(Microsoft Learn)
コスト最適化では、次の順で判断すると失敗しにくくなります。
まず「検知に必要な期間」を決める
最初に決めるべきなのは、Analytics tierに置く期間です。これはコストではなく、SOC運用の要件から決めます。
例として、次のような基準が考えられます。
| ログ種別 | Analytics tierの考え方 |
|---|---|
| IDサインインログ | 不正ログイン調査に頻繁に使うため、比較的長めに保持する候補 |
| EDRイベント | 端末侵害調査で重要。重要端末や高リスク環境では延長を検討 |
| Firewallログ | 大容量になりやすい。直近検知に必要な範囲だけAnalytics tierに置く |
| SaaS監査ログ | 検知ルールで使うものはAnalytics tier、監査目的はData lake tierを検討 |
| 低頻度の外部ログ | Data lake tier中心でよい場合が多い |
次に「監査・証跡として残す期間」を決める
監査や規制対応では、リアルタイム検知ではなく、後から証跡を確認できることが重要です。この場合、Total retentionを長めに設定し、Analytics retentionとの差分をData lake tierで保持する設計が有効です。
たとえば、直近90日はAnalytics tierで高速調査し、1年分はData lake tierに保持する、といった設計です。この場合、90日を超えるデータはリアルタイム検知には使いにくくなりますが、過去調査や監査には活用できます。
最後に「クエリ頻度」を見積もる
Data lake tierは長期保管に向いていますが、検索や処理にもコストが関係します。大量データに対して頻繁にKQL jobsを実行する場合、保存コストだけでなくクエリコストも確認してください。公式情報でも、Data lake queryはスキャンした非圧縮データ量に応じた課金が発生すると説明されています。(Microsoft Learn)
移行・展開時に失敗しやすいポイント
保持期間とティア設定は、画面上では簡単に変更できます。しかし、実務では次のような失敗が起こりやすいです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 検知ルールが動かなくなった | 参照テーブルをData lake tierのみに変更した | 変更前にAnalytics rulesとCustom detection rulesの参照テーブルを棚卸しする |
| Workbooksのグラフが空になった | 可視化対象のテーブルがAnalytics tierから外れた | 主要ダッシュボードのクエリを事前確認する |
| コスト削減のつもりが費用増になった | XDRデータの保持延長やData lakeクエリ費用を見落とした | 変更前後でCost Managementを確認する |
| Basic logsをDefenderポータルで変更できない | Basic logsはDefenderポータルで管理できない場合がある | Log Analytics側のテーブルプランを確認する |
| 長期保持したはずのデータが調査で使いにくい | Data lake tierとAnalytics tierの機能差を理解していなかった | 調査手順にKQL jobsやNotebookの利用を組み込む |
特に危険なのは、「Data lakeに残っているから大丈夫」と考えることです。Data lake tierに保存されていても、Analytics tierと同じようにアラートやハンティングで即座に使えるわけではありません。保持できることと、SOC運用で即利用できることは別です。
開発者・自動化担当者が確認すべきポイント
KQL、Logic Apps、Notebook、API連携、独自ダッシュボードを使っている場合は、ティア変更の影響を必ず確認してください。
KQLクエリの参照テーブルを棚卸しする
まず、分析ルール、ハンティングクエリ、保存済みクエリ、Workbook、Notebookで参照しているテーブルを洗い出します。特にjoinやunionを多用しているクエリでは、一部のテーブルだけがData lake tierに移ると期待した結果が得られない可能性があります。
カスタム検出ルールの実行対象を確認する
カスタム検出ルールは、リアルタイムまたは定期実行でテーブルを参照します。対象テーブルがAnalytics tierから外れると、検出条件が成立しなくなる可能性があります。
変更前に確認する項目は次のとおりです。
| 確認項目 | 理由 |
|---|---|
| ルールが参照するテーブル | Data lake tierのみになると動作に影響するため |
| クエリの時間範囲 | Analytics retentionを短縮すると対象期間が不足するため |
join対象テーブル | 一部テーブルだけ保持方針が異なると結果が変わるため |
| アラート生成条件 | 件数や集計値が変わり、しきい値の調整が必要になるため |
| Playbook連携 | アラート内容やエンティティ情報が変わる可能性があるため |
検証環境または低リスクテーブルから変更する
いきなり重要テーブルの保持設定を変更するのは避けましょう。まずは低リスクのテーブルでData lake tierへの移行やTotal retentionの延長を試し、クエリ、ダッシュボード、コストの変化を確認します。
本番環境で変更する場合は、少なくとも次の順序を推奨します。
| フェーズ | 実施内容 |
|---|---|
| 事前調査 | テーブル、ルール、Workbook、Playbook、コストを棚卸しする |
| 設計 | Analytics retentionとTotal retentionをテーブルごとに決める |
| 小規模変更 | 影響の小さいテーブルで設定変更を試す |
| 動作確認 | 検知ルール、ハンティング、ダッシュボードを確認する |
| 段階展開 | 重要度の低いテーブルから順に適用する |
| 運用監視 | Cost ManagementとSOC運用結果を確認する |
Azureポータル利用中の組織はDefenderポータル移行も意識する
Microsoft SentinelをAzureポータル中心で運用している組織は、Defenderポータルへの移行計画も並行して確認してください。公式情報では、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Microsoft Defenderポータルで利用する形になると案内されています。(Microsoft Learn)
今回のデータ保持・ティア管理も、Defenderポータルでの統合運用を前提に理解しておくべき内容です。Azureポータルでの従来運用に慣れている場合、テーブル管理、データコネクタ、XDR連携、RBACの確認手順が変わる可能性があります。
移行前に確認したい項目は次のとおりです。
| 確認項目 | 理由 |
|---|---|
| Sentinelワークスペースの一覧 | 複数ワークスペースがある場合、設定漏れが起きやすい |
| Defenderポータル上のRBAC | Azure側の権限だけでは十分でない場合がある |
| データコネクタの状態 | XDR連携や既存コネクタの取り込み先を確認する |
| テーブルごとの保持設定 | Azureポータル運用時の設定と差異がないか確認する |
| 運用手順書 | SOC担当者がDefenderポータルで同じ作業をできるようにする |
管理者向けチェックリスト
設定変更前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認 |
|---|---|
| 重要テーブルを一覧化したか | □ |
| 各テーブルの用途を「検知」「調査」「監査」「保管」に分類したか | □ |
| Analytics retentionをテーブルごとに決めたか | □ |
| Total retentionを監査要件に合わせて決めたか | □ |
| Data lake tierのみに移すテーブルを明確にしたか | □ |
| 分析ルールとカスタム検出の参照テーブルを確認したか | □ |
| Workbooksとハンティングクエリの影響を確認したか | □ |
| XDRデータの30日超保持に伴うコストを確認したか | □ |
| Basic logsの管理場所を確認したか | □ |
| 変更後にCost Managementで費用を確認する運用を決めたか | □ |
| 変更権限を持つ担当者を限定したか | □ |
| 変更前の設定値を記録したか | □ |
このチェックリストで特に重要なのは、変更前の設定値を記録することです。保持期間やティアを変更した後に問題が起きた場合、元の設定が分からないと復旧に時間がかかります。
実務でのおすすめ設計例
すべての組織に共通する正解はありませんが、一般的には次のような設計が現実的です。
| データ種別 | おすすめ方針 |
|---|---|
| 重大アラートやインシデント関連テーブル | Analytics tierを長めに設定し、日常調査で使える状態にする |
| Defender XDRの主要イベント | 30日で足りるかを確認し、必要に応じて90日までの延長を検討する |
| 大容量ネットワークログ | 直近分のみAnalytics tier、長期分はData lake tierを検討する |
| 監査証跡 | Total retentionを長めに設定し、Data lake tierで保管する |
| 低頻度ログ | Data lake tier中心で保存し、必要時にKQL jobsで分析する |
コスト削減だけを目的にData lake tierへ移すのではなく、SOCが即時に使うデータと、後から分析できればよいデータを分けることがポイントです。
まず実施すべき次のアクション
今回の「Manage data tiers and retention in Microsoft Sentinel」の更新を受けて、最初に行うべきことは新機能を試すことではありません。まずは、現在のテーブル保持設定を可視化することです。
優先順位は次のとおりです。
| 優先度 | やること |
|---|---|
| 高 | Microsoft DefenderポータルでTablesを開き、主要テーブルのAnalytics retentionとTotal retentionを確認する |
| 高 | 分析ルール、Advanced Hunting、Workbooksが参照するテーブルを棚卸しする |
| 高 | Microsoft Defender XDRデータを30日超で保持しているか確認する |
| 中 | 監査・コンプライアンス要件に合わせてTotal retentionを見直す |
| 中 | Data lake tierへ移せる低頻度ログを特定する |
| 中 | Cost Managementで変更前後の費用を確認する運用を作る |
| 低 | Notebook、KQL jobs、Summary rulesを使った長期分析の活用を検討する |
Microsoft SentinelとMicrosoft Defender XDRのデータ保持は、セキュリティ運用の精度とコストの両方に影響します。すべてをAnalytics tierに置くと費用が増えやすく、すべてをData lake tierに寄せると検知能力が落ちる可能性があります。まずは重要テーブルを洗い出し、検知に使う期間、調査に使う期間、監査のために残す期間を分けて設計してください。
コメント