Microsoft Defenderの公式ドキュメント更新「Update service limits table by removing ingestion limits」でまず押さえるべき点は、データ取り込み制限がすべてなくなったと判断しないことです。今回の更新は、Microsoft Sentinel data lakeのサービス制限表から一部のingestion関連項目を削除し、Log Analyticsワークスペース側の制限確認へ切り分ける意味合いが強い更新です。
セキュリティ管理者、コンプライアンス担当、エンタープライズIT担当は、「上限が消えたから大量取り込みしてよい」と解釈するのではなく、Log Analyticsの取り込みレート、データ欠損リスク、コスト管理、保持期間、Defenderポータル移行の観点で確認する必要があります。2026年4月30日のMicrosoftDocsリポジトリのコミット履歴では、該当ファイルに対して「Update service limits table by removing ingestion limits」という更新が行われています。(GitHub)
Microsoft Defenderの公式ドキュメント更新「Update service limits table by removing ingestion limits」で何が変わったか
今回の更新対象は、Microsoft Defender関連ドキュメント群の中にあるMicrosoft Sentinel data lakeのサービス制限表です。コミット内容を見ると、sentinel/includes/service-limits-table-manaement-ingestion.mdが変更され、データ取り込みに関する3つの行が削除されています。(GitHub)
| 変更前に表へ載っていた項目 | 値 | 今回の扱い |
|---|---|---|
| Data ingestion per minute to a data collection endpoint | 50 GB | サービス制限表から削除 |
| Default ingestion volume rate threshold in Log Analytics workspaces | 6 GB/min uncompressed | サービス制限表から削除 |
| Ingestion requests per minute to a data collection endpoint | 15,000 | サービス制限表から削除 |
差分では、これらの行を削除したうえで、Log Analyticsワークスペースの取り込み制限についてはAzure Monitorの「Log Analytics workspaces, data collection volume and retention」を参照する案内が追加されています。つまり、Microsoft Sentinel data lakeの表にすべての取り込み上限を混在させるのではなく、Log Analytics側の仕様はLog Analyticsの公式制限ページで確認する構成に整理されたと見るのが安全です。(GitHub)
「ingestion limits削除」は上限撤廃ではなく参照先整理として読む
この更新でよくある誤解は、「ingestion limitsが削除されたので、Microsoft DefenderやMicrosoft Sentinelに無制限でログを投入できる」という読み方です。しかし、現行のMicrosoft Sentinel data lakeサービス制限ページでは、Log Analyticsワークスペースの取り込み制限について別ページを参照するよう案内されています。(Microsoft Learn)
特に、Microsoft Defender XDR、Microsoft Sentinel、Log Analyticsを組み合わせている環境では、取り込み経路が複数あります。Defender XDRのインシデント同期、Advanced Huntingイベント、Azureリソースの診断ログ、カスタムログ、Data Collection Ruleなどが混在している場合、どの制限がどの層に適用されるのかを分けて確認しなければなりません。
実務では、次のように整理すると判断しやすくなります。
| 確認対象 | 見るべきポイント | 主な担当 |
|---|---|---|
| Microsoft Sentinel data lake | テーブル、保持期間、データレイク層、クエリ制限 | SOC、SIEM管理者 |
| Log Analytics workspace | 取り込み量、取り込みレート、Operationテーブル、課金 | Azure管理者、監視基盤担当 |
| Microsoft Defenderポータル | SentinelとDefender XDRの統合、テーブル管理、RBAC | セキュリティ管理者 |
| コンプライアンス要件 | 長期保持、暗号化、監査証跡、データ所在 | コンプライアンス担当 |
現行のサービス制限表で残っている主な項目
Microsoft Sentinel data lakeの現行サービス制限表では、ワークスペース数、保持期間、フィールド値サイズ、テーブル設定の反映時間などが残っています。たとえば、テナントあたりのワークスペース数は20、Asset dataとAuxのLake Retentionは12年、Log Analyticsのフィールド値最大サイズは32KB、オンボーディング時や新規テーブル設定時の遅延は90〜120分とされています。(Microsoft Learn)
| 項目 | 現行表で確認できる値 | 運用上の見方 |
|---|---|---|
| Workspaces per tenant | 20 workspaces | 複数地域・複数部門での設計時に確認 |
| Lake Retention | 12 years | 監査・長期調査・法令対応の保持設計に関係 |
| Maximum size for field values | 32 KB | 大きなJSONや長文ログの切り捨てに注意 |
| Table setup latency | 90〜120 minutes | オンボーディング直後の検証時間に余裕を持つ |
| Switching data between tiers latency | 90〜120 minutes | 階層変更直後の確認タイミングに注意 |
この表から分かるのは、今回の更新後もサービス制限がなくなったわけではないということです。単に、Microsoft Sentinel data lakeの表からLog Analytics取り込み関連の値が外れ、取り込み系の制限確認はLog Analytics側へ移ったと考えるべきです。
セキュリティ管理者が確認すべき運用影響
取り込み量を増やす前にLog Analyticsの制限を確認する
Azure Monitorの公式ドキュメントでは、Log Analyticsワークスペースの既定の取り込みボリュームレートしきい値は500MB圧縮済み、目安として非圧縮で約6GB/分と説明されています。また、しきい値の80%を超えた場合やしきい値を超えた場合にはOperationテーブルへイベントが送信され、しきい値超過時には一部データがドロップされる可能性があります。(Microsoft Learn)
そのため、ログソース追加やDefender XDR連携の拡張を行う前に、次の観点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 直近30日〜90日の取り込み量 | 通常時とピーク時の差が大きいか |
| 新規コネクタ追加予定 | 追加後にどのテーブルへどれだけ増えるか |
| DCRや診断設定の変更 | 収集対象を増やしすぎていないか |
| Operationテーブルの警告 | Ingestion rate、Data collection stoppedが出ていないか |
| サポート依頼の必要性 | しきい値を超える計画があるか |
特に、大規模環境では「平均取り込み量」だけでは不十分です。EDRイベント、メールイベント、クラウドアプリイベント、Azure診断ログは、インシデント発生時や設定変更時に一時的に急増することがあります。ピーク時の取り込みレートを見ずに設計すると、検知に必要なログが欠落するリスクがあります。
Operationテーブルの監視を見直す
Azure Monitorでは、Log Analyticsワークスペースの問題をOperationテーブルや_LogOperationで確認できます。公式ドキュメントでは、WarningやErrorレベルの問題に対してアラートを作成することが推奨されています。(Microsoft Learn)
取り込みレートに関する確認には、次のようなKQLを使えます。
_LogOperation
| where TimeGenerated >= ago(7d)
| where Category == "Ingestion"
| where Operation has "Ingestion rate"
| order by TimeGenerated desc日次上限や収集停止の兆候を確認する場合は、次のように絞り込みます。
_LogOperation
| where TimeGenerated >= ago(7d)
| where Category == "Ingestion"
| where Detail has "Data collection"
| order by TimeGenerated descアラート設計では、Errorは短い間隔で通知し、Warningは日次レビューに回すなど、重要度に応じて通知先を分けると運用しやすくなります。すべての警告をSOCへ即時通知するとアラート疲れにつながるため、取り込み停止やデータ欠損に直結するものを優先してください。
コンプライアンス担当が見るべきポイント
今回の更新は取り込み制限表の整理ですが、コンプライアンス面ではMicrosoft Sentinel data lakeの利用条件も合わせて確認すべきです。公式ドキュメントでは、Customer-Managed Keysを使用している組織に対して、Microsoft Sentinel data lakeに保存されるデータではCMKがサポートされないこと、データレイクへ取り込まれたデータはMicrosoft-managed keysで暗号化されることが説明されています。(Microsoft Learn)
つまり、保持期間を最大12年まで設計できることだけを見て採用判断をしてはいけません。金融、医療、公共、グローバル企業では、暗号化キー管理、データ保持、監査証跡、越境データ管理の要件と照合する必要があります。
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| 暗号化ポリシー | Microsoft-managed keysで社内基準を満たすか |
| 保持期間 | 監査要件に対して短すぎないか、長すぎないか |
| データ分類 | 個人情報、機密情報、認証ログが含まれるか |
| アクセス制御 | Defenderポータルの統合RBACと既存Azure権限の差分 |
| 証跡管理 | 誰がテーブル設定や保持期間を変更できるか |
コンプライアンスチームは、技術的な上限変更だけでなく、「どのログを、どの層に、何年間保持し、誰がアクセスできるか」を文書化しておくと、監査対応がしやすくなります。
コスト管理で注意すべき点
ingestion関連の行がサービス制限表から削除されたからといって、コストリスクが小さくなるわけではありません。Azure Monitor Logsのベストプラクティスでは、ワークスペース設計、価格レベル、保持期間、Basic Logs、収集対象の制限、高いデータ収集時のアラート、日次上限などがコスト最適化の確認項目として挙げられています。(Microsoft Learn)
特に注意したいのは、Daily Capを通常のコスト削減手段として使わないことです。公式ドキュメントでは、Daily Capは予期しない課金増加を抑える保護策であり、主なフィルタリング手段や日常的なコスト削減策として使うべきではないと説明されています。Daily Capに達するとデータ収集が停止し、監視やアラート、依存サービスの健全性把握に影響します。(Microsoft Learn)
コストを抑えるなら、まずは収集前の設計を見直します。
| よくある失敗 | 改善策 |
|---|---|
| すべての診断ログを無条件に有効化する | 必要なカテゴリだけを選ぶ |
| 調査に使わない高頻度ログをAnalytics層へ入れる | Basic LogsやData Lake層の適用を検討 |
| 保持期間を一律で長くする | テーブル単位で保持期間を分ける |
| Daily Capで強制停止させる | 事前アラートと収集対象の調整を優先 |
| 新規コネクタ追加後にレビューしない | 追加後1週間と1か月で取り込み量を確認 |
Defenderポータル移行とあわせて確認する
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRやE5ライセンスを持たない顧客でもDefenderポータルで利用できると説明されています。また、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルのみで利用される予定です。(Microsoft Learn)
このため、今回のドキュメント更新は単発の表修正としてではなく、Defenderポータル中心の運用へ移る流れの中で捉えるべきです。テーブル設定や保持期間の管理も、Microsoft Defenderポータル上でMicrosoft SentinelとDefender XDRのテーブルを横断して扱う方向に整理されています。(Microsoft Learn)
移行準備では、次の点を確認してください。
| 項目 | 確認すべき内容 |
|---|---|
| 利用ポータル | Azure portal中心か、Defenderポータル中心か |
| 権限 | Azure RBACとDefender XDR統合RBACの対応関係 |
| テーブル管理 | Defenderポータルで保持期間・階層を変更できる担当者 |
| インシデント同期 | Defender XDRとSentinelの双方向同期の運用ルール |
| 自動化 | インシデント名やステータス変更を条件にしたルールの見直し |
Microsoft Defender XDRとMicrosoft Sentinelを統合する場合、Defender XDRのインシデントやアラート情報はMicrosoft Sentinelに同期されます。一方で、個別のDefenderコンポーネントのAdvanced Huntingテーブルなど、データ種別によっては取り込み課金が発生するため、無料同期される範囲と課金対象の範囲を分けて確認する必要があります。(Microsoft Learn)
実務で使える確認手順
公式差分を確認する
まず、今回のコミットで削除された項目を確認します。見るべきポイントは、削除された3行そのものと、Log Analyticsワークスペースの取り込み制限ページへの誘導が追加された点です。ここで「数値が削除された」ことと「制限確認が不要になった」ことを混同しないようにします。(GitHub)
確認時は、社内向けの変更管理メモに次のように記録すると実務で使いやすくなります。
| 記録項目 | 記載例 |
|---|---|
| 更新日 | 2026年4月30日 |
| 対象 | MicrosoftDocs defender-docs / Microsoft Sentinel data lake service limits |
| 変更内容 | サービス制限表からingestion関連3項目を削除 |
| 影響 | Log Analytics側の取り込み制限確認が必要 |
| 対応 | 取り込みレート監視、コスト監視、保持設計を再確認 |
Log Analyticsワークスペースの取り込み状況を確認する
次に、実際の取り込み状況を確認します。ワークスペースごとの通常時、ピーク時、障害時の取り込み傾向を見て、しきい値に近づいていないかを判断します。
最低限、次の3点を確認してください。
| 確認内容 | 目的 |
|---|---|
| 直近7日・30日の取り込み量 | 通常運用の基準値を把握する |
| Ingestion rateのWarning/Error | データ欠損リスクを把握する |
| 新規ログソース追加後の増加量 | 設計値と実測値の差を見る |
大量のログソースを追加する予定がある場合は、本番反映前にテストワークスペースや限定範囲で実測するのが安全です。机上計算だけでは、イベント発生頻度やログサイズのばらつきを見落としやすくなります。
Defenderポータルでテーブル設定を確認する
Microsoft Defenderポータルでは、Microsoft SentinelとDefender XDRのテーブルレベルの保持期間や階層設定を一元的に管理できます。公式手順では、左側ナビゲーションから「Microsoft Sentinel > Configuration > Tables」を選択し、対象テーブルを選んで保持や階層を確認・変更する流れが示されています。(Microsoft Learn)
確認時は、次のようにテーブルを分類します。
| テーブル種別 | 推奨される考え方 |
|---|---|
| インシデント調査で頻繁に使うテーブル | Analytics層で短〜中期保持 |
| 監査や過去調査で必要なテーブル | Data Lake層で長期保持 |
| 低頻度の診断・デバッグ用ログ | Basic Logsや短期保持を検討 |
| 個人情報や機密情報を含むログ | 保持期間とアクセス権を厳格に管理 |
すべてのログを同じ層・同じ保持期間にするのは避けるべきです。調査頻度、検索速度、保持要件、コストのバランスをテーブル単位で決めると、無駄な課金と監査リスクを抑えやすくなります。
変更対応で失敗しやすいポイント
今回のような公式ドキュメント更新では、差分の見方を誤ると運用判断を間違えます。特に次の3つは注意してください。
| 失敗しやすい解釈 | 正しい確認 |
|---|---|
| ingestion limitsが削除されたので無制限になった | Log Analytics側の制限と監視を確認する |
| Defender関連だからEndpointだけの話だと思う | Sentinel data lake、Defender XDR、Log Analyticsの連携を見る |
| 表の数値だけを見て保持設計を決める | 暗号化、RBAC、監査、コストも確認する |
| Daily Capでコストを抑えればよい | 収集停止による監視不能リスクを考慮する |
| ポータル移行は別件として後回しにする | Defenderポータルでのテーブル管理と権限を先に確認する |
公式ドキュメントの表から数値が消えた場合、運用チームが取るべき行動は「制限がなくなったと喜ぶ」ことではありません。まず、数値の参照先が変わったのか、仕様そのものが変わったのか、製品ページとGitHub差分の両方で確認することが重要です。
まとめ：次にやるべきこと
今回のMicrosoft Defender関連ドキュメント更新は、Microsoft Sentinel data lakeのサービス制限表からingestion関連項目を削除し、Log Analyticsワークスペース側の取り込み制限確認へ誘導する更新として捉えるのが現実的です。
次に取るべき行動は明確です。まず、該当コミットで削除された3項目を確認し、自社の設計資料に残っている古い上限値を洗い出します。次に、Log Analyticsワークスペースの取り込みレート、Operationテーブルの警告、コストアラート、Daily Cap設定を確認します。最後に、Defenderポータルでのテーブル管理、保持期間、RBAC、Microsoft Sentinel移行計画を見直してください。
「ingestion limits削除」は、運用を緩めるサインではなく、参照先と責任範囲を整理するサインです。セキュリティ運用では、公式表の変更をきっかけに、ログ収集・保持・課金・権限をまとめて棚卸しすることが最も実務的な対応です。
コメント