Microsoft Defenderの公式ドキュメント更新「Update sentinel/includes/service-limits-table-manaement-ingestion.md」を確認する際の結論は、今回のコミット自体はサービス制限値の変更ではなく、Log Analyticsの表記修正だという点です。2026年4月30日のコミットでは、該当ファイルの参照文にある「log analytics」が「Log Analytics」に修正されただけで、ワークスペース数、保持期間、テーブル設定待ち時間、取り込み上限などの数値変更は確認できません。(GitHub)
ただし、この更新が参照している領域はMicrosoft Sentinel Data Lake、Log Analyticsワークスペース、データ取り込み、テーブル階層、リテンションに関わります。Microsoft DefenderポータルでSentinelやDefender XDRを運用しているsecurity admins、compliance teams、enterprise IT担当者は、「単なる表記修正」として終わらせず、現在の公式制限値と自社運用への影響を確認しておくべきです。
Microsoft Defenderの公式ドキュメント更新で何が変わったか
今回確認対象のコミットは、MicrosoftDocs/defender-docsリポジトリにある次のファイルを更新しています。
sentinel/includes/service-limits-table-manaement-ingestion.md
コミット内容としては、1ファイルに対して1行追加・1行削除の差分です。変更箇所は、Log Analyticsワークスペースの取り込み制限を案内する文章内の製品名表記で、「log analytics」から「Log Analytics」へ修正されています。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年4月30日 |
| 対象ファイル | sentinel/includes/service-limits-table-manaement-ingestion.md |
| 変更の種類 | 表記修正 |
| 変更前後の要点 | log analytics → Log Analytics |
| 直接的な仕様変更 | 確認できない |
| すぐに設定変更が必要か | このコミットだけを根拠にした変更は不要 |
重要なのは、このコミットを「取り込み制限が変わった」と読まないことです。コミット差分に数値上限の追加・削除・変更はありません。監査対応や社内周知では、「公式ドキュメントの表記修正であり、サービスパラメーター変更ではない」と明記すると誤解を防げます。
なお、ファイル名は公式コミット上でmanaementと表記されています。検索や社内チケット化の際にmanagementへ直してしまうと、該当コミットや差分を見つけにくくなるため、証跡には公式表記のまま残すのが安全です。
なぜMicrosoft Defender運用チームが確認すべきなのか
今回の更新対象はMicrosoft Defender単体のアンチウイルス設定ではなく、Microsoft Defenderポータルで利用されるMicrosoft Sentinel、Microsoft Sentinel Data Lake、Log Analyticsの制限値に関わる領域です。
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Microsoft Defender XDRと組み合わせる場合も、Sentinel単体で利用する場合も、SIEMとXDRを統合した運用体験として扱われます。また、公式ドキュメントでは2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
つまり、現在Azure portal中心でMicrosoft Sentinelを運用している組織でも、今後はDefenderポータル上でのデータ管理、テーブル管理、リテンション設計、権限設計を避けて通れません。今回のような小さなドキュメント更新でも、移行計画や運用標準を見直すきっかけになります。
公式ドキュメントで確認すべきサービス制限
今回のファイルは、Microsoft Sentinel Data Lakeのテーブル管理、データ取り込み、リテンションに関する制限表に含まれる内容です。公式ページでは、主に次の制限値が示されています。(Microsoft Learn)
| 確認すべき項目 | 公式ドキュメント上の値 | 実務での見方 |
|---|---|---|
| テナントあたりのワークスペース数 | 20ワークスペース | マルチリージョン、子会社別、環境別に分けすぎると上限に近づく可能性がある |
| Lake Retention（Asset data） | 12年 | 長期監査、フォレンジック、規制対応の保存期間設計に使う |
| Lake Retention（Aux） | 12年 | 補助ログや低頻度参照データの長期保存に関わる |
| Log Analyticsのフィールド値最大サイズ | 32KB、超過分は切り捨て | 大きなJSON、メール本文、コマンドライン、認証ログの詳細が欠落しないか確認する |
| オンボード時のテーブル設定待ち時間 | 90〜120分 | 有効化直後にデータが見えないことを障害と誤認しない |
| 新規テーブル設定の待ち時間 | 90〜120分 | 新しいデータソース追加後の検証時間を変更計画に含める |
| データ階層切り替えの待ち時間 | 90〜120分 | Analytics層とData Lake層を切り替える作業は即時反映を前提にしない |
この表で特に見落としやすいのは、待ち時間が3項目あることです。オンボード、新規テーブル、階層切り替えのいずれも90〜120分が示されています。運用手順書では「設定後すぐに検出ルールやハンティングで確認する」ではなく、「反映待ち時間を考慮してから確認する」と書くべきです。
Log Analytics側の取り込み制限も合わせて確認する
今回の表記修正は「Log Analytics workspace ingestion limits」への参照文に関わるものです。したがって、Microsoft Sentinel Data Lake側だけでなく、Azure MonitorやLog Analytics側の制限も合わせて確認する必要があります。
Azure Monitorの公式サービス制限では、Logs Ingestion APIについてAPI呼び出し最大サイズ、フィールド値最大サイズ、DCRあたりのデータ量、DCRあたりのリクエスト数などが示されています。また、Log Analyticsワークスペースのデータ収集量や保持期間についても、料金レベルごとの制限が整理されています。(Microsoft Learn)
| 領域 | 確認ポイント | 失敗しやすい例 |
|---|---|---|
| Logs Ingestion API | API呼び出しサイズ、DCRあたりの取り込み量、リクエスト数 | 大量ログを一括送信し、スロットリングや再試行が発生する |
| Data Collection Rule | DCR単位の上限、変換ルール、送信先 | 1つのDCRに複数用途を詰め込みすぎて変更影響が大きくなる |
| Log Analytics workspace | 保持期間、課金レベル、データ収集量 | Sentinel側の制限だけ見て、ワークスペース側の制約を見落とす |
| フィールドサイズ | 長い文字列の切り捨て | 監査に必要な本文、URL、コマンドライン、JSON属性が欠落する |
実務では、問題が起きたときに「Microsoft Defenderの制限」「Microsoft Sentinel Data Lakeの制限」「Log Analyticsの制限」「Azure Monitor Logs Ingestion APIの制限」が混同されがちです。障害調査や設計レビューでは、どのレイヤーの上限に当たっているのかを切り分けてください。
運用影響を判断するためのチェックポイント
今回の更新だけで緊急対応が必要になる可能性は低いです。ただし、次の条件に当てはまる組織では、公式制限値と現行設計の突き合わせをおすすめします。
新しいデータソースやテーブルを追加する予定がある
新規テーブルの設定には90〜120分の待ち時間が示されています。データコネクタ追加、カスタムログ取り込み、XDRテーブルの保持延長、Data Lake層への移行を行う場合は、検証タイムラインに最低でも2時間程度の反映確認枠を入れておくと安全です。
たとえば、夜間メンテナンスで「22時に設定変更、22時30分に検知確認、23時に完了」といった計画を立てると、反映待ちを障害と誤判定する可能性があります。実際の変更計画では、設定変更、反映待ち、データ到着確認、クエリ確認、検知確認を分けて記録しましょう。
Analytics層とData Lake層を切り替える予定がある
Microsoft Sentinelでは、データをAnalytics層またはData Lake層で保持できます。Analytics層はリアルタイム分析、アラート、ハンティング、ブックなどに向き、Data Lake層は低コストの長期保存や監査、履歴分析に向くと説明されています。Data Lake層のみのデータは、リアルタイム分析機能の対象外になる点に注意が必要です。(Microsoft Learn)
判断基準はシンプルです。
| ログの用途 | 推奨される考え方 |
|---|---|
| 即時検知、分析ルール、SOCの常時監視に使う | Analytics層を維持する |
| 監査証跡、長期保管、年単位のフォレンジックに使う | Data Lake層を検討する |
| 月次・四半期の傾向分析に使う | Data Lake層とKQLジョブの活用を検討する |
| インシデント初動で頻繁に見る | Data Lake層のみへ移す前にSOCへ確認する |
コスト削減だけを理由に重要ログをData Lake層へ移すと、検知やハンティングの即応性が落ちる可能性があります。セキュリティ運用では、コストよりも「そのログを何分以内に使う必要があるか」を先に決めるべきです。
コンプライアンス上、暗号化キーの要件がある
Microsoft Sentinel Data Lakeでは、Customer-Managed Keys（CMK）がサポートされない旨が公式ページで案内されています。Data Lakeに取り込まれたデータはMicrosoft-managed keysで暗号化され、組織の暗号化ポリシーやデータ保護基準と完全には一致しない可能性があると説明されています。(Microsoft Learn)
この点は、compliance teamsが必ず確認すべきです。特に金融、医療、公共、グローバル企業では、次の観点でレビューしてください。
| 確認項目 | 判断ポイント |
|---|---|
| CMK必須ポリシー | Sentinel Data Lake利用が社内基準に合うか |
| データ所在・保持期間 | 12年保存が必要か、過剰保存にならないか |
| 監査証跡 | 設定変更者、変更日時、対象テーブルを記録できるか |
| 個人情報・機密情報 | 長期保存してよいログ種別か |
| 例外承認 | CMK非対応でも利用する場合の承認フローがあるか |
Microsoft Defenderポータル移行に向けた確認事項
Microsoft Defenderポータルでは、Microsoft SentinelとDefender XDR全体でテーブルレベルのリテンションや階層設定を管理できます。公式手順では、Microsoft Sentinel > Configuration > Tablesからテーブル設定を確認し、必要に応じて保持期間や階層を変更する流れが示されています。(Microsoft Learn)
移行準備では、次の順序で確認すると実務に落とし込みやすくなります。
| 手順 | 作業内容 | 担当の目安 |
| -: | ————————————– | ——————– |
| 1 | Sentinelワークスペース一覧を棚卸しする | Enterprise IT |
| 2 | 各テーブルの用途を「検知」「調査」「監査」「長期分析」に分類する | Security admin / SOC |
| 3 | Analytics層に残すログとData Lake層へ移すログを決める | Security admin |
| 4 | リテンション期間が社内規程・法令・契約に合うか確認する | Compliance team |
| 5 | DefenderポータルのRBACとLog Analytics権限を確認する | IAM / Platform team |
| 6 | 変更後90〜120分の反映確認時間を計画に入れる | Change manager |
| 7 | 設定変更前後の証跡を保存する | SOC / Compliance |
特に権限は見落としやすいポイントです。テーブル設定の表示や構成には、Defenderポータルの統合RBACとMicrosoft Sentinelワークスペース側の権限が関係します。作業者が画面を開けても、保存や階層変更ができないケースがあるため、移行リハーサルで事前に確認しておくとよいでしょう。(Microsoft Learn)
変更管理チケットに残すべき証跡
今回のような公式ドキュメント更新は、社内の変更管理や監査で「何が変わったのか」を明確にすることが重要です。次の項目をチケットや運用記録に残しておくと、後から説明しやすくなります。
| 証跡 | 記録する内容 |
|---|---|
| コミットID | 25307ebca0dca3f0f41909eb4fc4266631fcbc37 |
| 更新日 | 2026年4月30日 |
| 対象ファイル | sentinel/includes/service-limits-table-manaement-ingestion.md |
| 差分の要約 | Log Analyticsの表記修正 |
| 数値変更の有無 | コミット上は確認できない |
| 参照した公式ページ | Microsoft Sentinel Data Lake service parameters and limits |
| 社内判断 | 設定変更不要、ただし制限値と移行計画を確認 |
| 影響確認 | テーブル設定、リテンション、Data Lake層、Log Analytics取り込み制限 |
変更管理チケットの記載例は次のとおりです。
2026-04-30のMicrosoftDocs/defender-docsコミットを確認。対象は
sentinel/includes/service-limits-table-manaement-ingestion.mdで、変更内容はLog Analyticsの製品名表記修正。サービス制限値の変更はコミット差分上確認されない。Microsoft Sentinel Data LakeおよびLog Analyticsの現行制限値は別途公式ページで確認し、Defenderポータル移行計画に反映する。
このように書くと、「公式更新があったから急いで設定を変えた」という誤った判断を避けられます。
よくある誤解と注意点
Microsoft Defender全体の取り込み上限が変わったわけではない
今回のコミットは、Microsoft Defender製品群全体の取り込み上限を変更するものではありません。対象はSentinel関連のincludeファイルであり、差分もLog Analyticsの表記修正です。Defender for Endpoint、Defender for Office 365、Defender for Identityなどの個別機能の仕様変更と混同しないようにしてください。
Sentinel Data LakeとLog Analyticsは同じ制限ではない
Sentinel Data Lakeの制限と、Log AnalyticsワークスペースやAzure Monitor Logs Ingestion APIの制限は別レイヤーです。Data Lake側で問題がなさそうでも、DCR、API、ワークスペース、フィールドサイズ、クエリ制限のどこかに該当する場合があります。調査時は「どの制限表を見ているのか」を明確にしてください。
Data Lake層に移せばすべて安く安全になるわけではない
Data Lake層は長期保存や監査には有効ですが、リアルタイム分析や即時検知には向きません。公式ドキュメントでも、Data Lake層は低コストのコールド層であり、リアルタイム分析機能や脅威ハンティングでは利用できないと説明されています。(Microsoft Learn)
コスト最適化の前に、次の質問に答えることが重要です。
- そのログはアラート生成に使うか
- SOCがインシデント初動で見るか
- 何日以内に高速検索できる必要があるか
- 監査だけに使うのか、検知にも使うのか
- 階層変更後に既存の分析ルールへ影響が出ないか
90〜120分の待ち時間を障害と誤認しない
オンボード、新規テーブル、階層切り替えでは90〜120分の待ち時間が示されています。設定直後にデータが表示されない場合でも、すぐに障害と判断するのではなく、公式の待ち時間、データコネクタの状態、DCR、Log Analytics側の取り込み状況を順に確認しましょう。
今回の更新後に取るべき実務アクション
今回のMicrosoft Defender公式ドキュメント更新で取るべき行動は、緊急の設定変更ではありません。やるべきことは、公式制限値の再確認と、Defenderポータル移行を見据えたデータ管理設計の点検です。
まず、コミット差分を確認し、今回の変更が表記修正であることを社内に共有します。次に、Microsoft Sentinel Data Lakeのサービス制限、Log Analyticsワークスペースの取り込み制限、テーブル階層、保持期間、CMK要件を確認します。そのうえで、検知に必要なログはAnalytics層に残し、監査・長期分析向けのログはData Lake層を検討する、という方針に落とし込むのが現実的です。
Microsoft Defenderポータルへの移行が進むほど、セキュリティ管理者、コンプライアンス担当、IT基盤担当が同じ制限値を見て判断する必要があります。今回の小さなドキュメント更新は、取り込み設計、リテンション設計、コスト最適化、監査証跡を見直す良いタイミングです。
コメント