Microsoft Sentinel data lakeのコスト管理で最も重要な変化は、KQLクエリやNotebookの利用がしきい値を超えたときに、通知するだけでなく新しい実行をブロックできるようになった点です。2026年4月16日時点の注目アップデートとして、MicrosoftはMicrosoft Sentinel data lakeのKQL queries and notebooksに対するcost limits、正確にはthreshold enforcementの追加を発表しました。従来の「気づくためのアラート」から、「止めるためのガードレール」へ進化したと考えると分かりやすいでしょう。(TECHCOMMUNITY.MICROSOFT.COM)
特にSentinel adminsやFinOps-aware security teamsにとって、この更新は単なる節約機能ではありません。大規模な脅威ハンティング、長期ログ調査、Jupyter Notebookによる高度分析を進めながら、予算超過・暴走クエリ・新人アナリストの誤操作を抑えるためのdata-lake governance設計そのものに関わる変更です。
Microsoft Sentinel data lakeのhard cost limitsとは
Microsoft Sentinel data lakeのhard cost limitsとは、データレイクに対するKQLクエリやNotebook実行について、設定したしきい値を超えたあとに新規のクエリ、ジョブ、Notebookセッションをブロックする運用上の仕組みを指します。
Microsoftの表現では「threshold enforcement」です。これまでのConfigure Policiesでは、データレイク使用量がしきい値に近づいたときにメール通知を受け取ることはできました。しかし、通知後も処理は継続できたため、重いクエリや頻繁なNotebook実行による予期しないコスト増を完全には防げませんでした。今回の更新では、Enforcementを有効化すると、しきい値超過後の新規実行が「Limit exceeded」エラーで失敗します。(TECHCOMMUNITY.MICROSOFT.COM)
| 観点 | 従来のしきい値通知 | 今回のEnforcement付きcost limits |
|---|---|---|
| 主な目的 | 使用量の増加に気づく | しきい値超過後の新規利用を止める |
| 予算超過リスク | 通知を見逃すと継続利用される | 新規クエリやジョブをブロックできる |
| アナリストへの影響 | 基本的に実行は継続 | 超過後はLimit exceededエラーが表示される |
| 運用上の意味 | 監視・通知 | 予算統制・ガバナンス |
| 向いている用途 | 使用量の可視化 | 本番SOC、マルチチーム利用、FinOps管理 |
重要なのは、これは「Microsoft Sentinel全体の請求を完全に止める機能」ではないことです。対象はMicrosoft Sentinel data lakeの特定カテゴリにおけるKQLクエリやNotebook関連の利用です。Azure全体の予算管理、Log Analyticsの取り込み量管理、Microsoft SentinelのAnalytics tierの費用管理は、引き続きAzure Cost ManagementやSentinelの既存のコスト管理と組み合わせる必要があります。(Microsoft Learn)
対象になるのはData Lake QueryとAdvanced Data Insights
Enforcementの対象は、Microsoft Sentinel data lakeの次の2カテゴリです。
| カテゴリ | 対象になる主な処理 | 管理上のポイント |
|---|---|---|
| Data Lake Query | Data lake explorerでの対話型KQLクエリ、スケジュールまたはアドホックのKQLジョブ | 履歴調査や大規模検索でデータスキャンが増えやすい |
| Advanced Data Insights | VS Code拡張機能経由のNotebook実行、バックグラウンドまたはスケジュールされたNotebookジョブ | Sparkプール、機械学習、集計処理でコンピュート消費が増えやすい |
Microsoftの発表では、対話型KQL、KQLジョブ、Microsoft Sentinel VS Code extensionから実行されるNotebookクエリ、スケジュール実行されるNotebookジョブに対して一貫した制御が適用されると説明されています。すでに実行中のクエリやジョブは途中で止められず、新しいクエリ、ジョブ、Notebookセッションがブロックされる点も押さえておきましょう。(TECHCOMMUNITY.MICROSOFT.COM)
この仕様は、SOCの現場ではかなり重要です。インシデント対応中に長時間ジョブが突然中断されるリスクは下がる一方で、しきい値超過後に追加調査を始めようとするとブロックされる可能性があります。つまり、コスト制限は「安全装置」ですが、設計を誤ると調査のボトルネックにもなります。
なぜdata-lake governanceが変わるのか
Microsoft Sentinel Data Lakeは、大量のセキュリティデータを長期間保持し、KQLやJupyter Notebookで分析できる基盤です。Microsoftのドキュメントでは、Data Lake tierは長期保存やPythonベースの高度分析に向いた層として説明され、保持期間は設定やデータ種別に依存しつつ最大12年まで扱える設計になっています。(Microsoft Learn)
この利点は、同時にガバナンス上の課題にもなります。長期データに対して広い期間で検索できるほど、誤って巨大な範囲をスキャンするリスクが高まるためです。Notebookでは、Sparkプールの選択やセッションの稼働時間によってコスト影響が変わります。VS CodeのNotebookにはSmall、Medium、Largeのランタイムプールがあり、Microsoftの説明では選択するプールがパフォーマンス、コスト、実行時間に影響します。(Microsoft Learn)
これまでのdata-lake governanceは、主に次のような管理に寄りがちでした。
- 誰がデータにアクセスできるか
- どのテーブルをAnalytics tierに置くか、Data Lake tierに置くか
- どのデータをどれくらい保持するか
- どのジョブをスケジュール実行するか
hard cost limitsの追加後は、ここにどの分析ワークロードに、どれだけの消費上限を認めるかという実行時ガバナンスが加わります。これはFinOpsとSOC運用の接点です。セキュリティチームだけで「必要だから使う」と判断するのではなく、使用量、調査優先度、予算、例外承認をセットで扱う必要があります。
Sentinel adminsが最初に決めるべき3つの設計項目
Enforcementを有効化する前に、いきなりしきい値を入力するのはおすすめできません。先に、次の3点を決めておくと運用が安定します。
しきい値は「月額予算」ではなくワークロード単位で考える
Microsoft Sentinel data lakeのコストは、Data Lake tierの各機能の使用量に基づいて発生します。Microsoftの課金ドキュメントでは、Data lake ingestion、data processing、data lake storage、Notebook関連のコンピュート利用など、複数の要素が説明されています。(Microsoft Learn)
そのため、しきい値は「Sentinel全体で月いくらまで」という大ざっぱな決め方ではなく、少なくとも次のように分けて考えるべきです。
| 管理対象 | しきい値設計の考え方 |
|---|---|
| 対話型KQL | 日常調査・脅威ハンティングで使うため、過去実績に少し余裕を乗せる |
| KQLジョブ | スケジュール実行があるため、ジョブ単位で所有者と目的を明確にする |
| Notebook実行 | 実験・ML・集計で消費が膨らみやすいため、利用者とプール選択を管理する |
| 緊急調査 | 平常時とは別に、一時的な上限引き上げやEnforcement解除の承認手順を用意する |
最初の運用では、過去30日程度の使用傾向を見て、通常運用のピークに一定の余裕を持たせる方法が現実的です。新規導入で実績がない場合は、いきなり厳しいブロックを入れるより、まず通知しきい値で利用パターンを観察し、その後にEnforcementを有効化する方が失敗しにくくなります。
アラート率は「気づくため」ではなく「止まる前に動くため」に設定する
Configure Policiesでは、total threshold valueに加えて、しきい値に対するalert percentageを設定できます。Microsoftのドキュメントでは、しきい値に対するメール通知と、しきい値超過後のEnforcementを設定できる流れが説明されています。(Microsoft Learn)
実務では、アラート率を単なる通知として扱わないことが大切です。例えば、70%到達でSentinel adminに通知、85%到達でジョブ所有者に確認、95%到達で緊急時以外のNotebookジョブを停止する、といった内部ルールに落とし込みます。
| アラート段階 | 推奨アクション |
|---|---|
| 70%前後 | 使用量の増加要因を確認する |
| 85%前後 | 大きなKQLジョブやNotebookジョブの実行予定を見直す |
| 95%前後 | 不要な探索・実験系ジョブを止め、緊急調査の余地を残す |
| 100%超過 | Limit exceededの問い合わせ対応と、必要に応じた一時的な上限変更を判断する |
数値は組織ごとに変えて構いません。大切なのは、アラートを受け取った人が「何を判断し、誰に連絡し、何を止めるか」まで決まっていることです。
例外対応を先に決める
Microsoftの発表では、侵害対応などで追加の余力が必要になった場合、しきい値の調整、Enforcementの一時無効化、ポリシー変更によってSOCの対応を止めない運用が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
これは非常に現実的なポイントです。セキュリティ分析では、平常時に抑えるべきコストと、重大インシデント時に必要な調査コストが一致しません。たとえば、ランサムウェア調査で過去180日分の認証ログ、EDRログ、プロキシログを横断検索する場合、通常より大きなKQL処理が必要になることがあります。
例外対応では、次の項目を事前に決めておきましょう。
| 項目 | 決めておく内容 |
|---|---|
| 承認者 | SOC manager、Security Administrator、FinOps担当など |
| 解除条件 | 重大インシデント、監査対応、法務調査など |
| 解除範囲 | Data Lake Queryのみか、Advanced Data Insightsも含めるか |
| 解除時間 | 4時間、24時間、週末対応など期限を明確にする |
| 記録 | チケット番号、理由、変更前後のしきい値、戻し作業の予定 |
Enforcementは強力ですが、緊急時の調査を止めると本末転倒です。平常時は厳格に、緊急時は承認付きで柔軟に、という二段構えが現実的です。
Cost limitsの設定手順
設定はMicrosoft Defender portalのMicrosoft Sentinel > Cost management > Configure Policiesから行います。Microsoftのドキュメントでは、Data Lake tier向けのコスト管理ページにアクセスするにはBilling AdministratorとSecurity Administratorの両方のロールが必要とされています。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Defender portalでMicrosoft Sentinel > Cost managementを開く | 対象テナント、対象ワークスペースを間違えない |
| 2 | Configure Policiesを選択する | Cost management画面の右上から設定する |
| 3 | Data Lake QueryまたはAdvanced Data Insightsのポリシーを選ぶ | KQL系とNotebook系を混同しない |
| 4 | total threshold valueを入力する | 過去実績、予算、緊急時の余力を考慮する |
| 5 | alert percentageを入力する | 通知後の対応手順とセットで決める |
| 6 | Enforcementを有効化する | 超過後に新規実行がブロックされることを周知する |
| 7 | Submitで保存する | 変更内容をチケットや運用台帳に記録する |
注意点として、Microsoft LearnではEnforcementはリアルタイムではなく、しきい値到達後に適用されるまで最大4時間かかる場合があると説明されています。つまり、これは完全な瞬間停止スイッチではありません。高頻度ジョブや大きなNotebook処理がある環境では、通知、使用量監視、ジョブ管理も併用してください。(Microsoft Learn)
どのようにしきい値を決めるべきか
しきい値設計で失敗しやすいのは、「全チーム共通の上限」をいきなり設定することです。Microsoft Sentinel data lakeは、調査、検知開発、フォレンジック、機械学習、レポート集計など、利用目的によって使用量の波が大きく変わります。
小規模SOCの場合
小規模SOCでは、まずData Lake Queryのしきい値を低めに設計し、Notebook側は利用者を限定する方法が扱いやすいです。Notebookは便利ですが、Sparkプールの選択やセッション時間によって消費が読みにくくなります。MicrosoftのNotebookドキュメントでも、プール選択がコストや実行時間に影響すると説明されています。(Microsoft Learn)
おすすめの運用は次の通りです。
- 日常調査はKQL中心にする
- Notebook利用はTier 3 analystや検知開発担当に限定する
- Largeプール利用はチケット承認制にする
- 月初からの消費推移を週次で確認する
- Limit exceededが出た場合の問い合わせ先をSOC内に明示する
大規模SOCの場合
大規模SOCでは、複数チームが同じデータレイクを使うため、Enforcementだけでは不十分です。ジョブ所有者、実行目的、実行頻度、想定消費を台帳化し、Data Lake QueryとAdvanced Data Insightsを別々に管理します。
特に注意したいのは、スケジュールジョブです。対話型クエリは利用者が気づきやすい一方、スケジュールジョブは誰も見ていない時間帯に継続実行されることがあります。月次レポート、週次集計、MLモデル検証、過去ログの再処理などは、コスト増の原因になりやすい処理です。
MSSPやグローバル組織の場合
MSSPやグローバル組織では、テナント、リージョン、顧客、事業部ごとにコスト責任が分かれることがあります。この場合、しきい値は単なる技術設定ではなく、チャージバックやショーバックの前提になります。
次のようなルールを定めると、後から揉めにくくなります。
| ルール | 具体例 |
|---|---|
| 所有者を必須にする | すべてのKQLジョブ、Notebookジョブにowner、purpose、cost centerを付ける |
| 実験と本番を分ける | 検知開発用Notebookと本番集計ジョブを同じ予算枠に入れない |
| 例外の期限を決める | インシデント対応で上限を上げる場合も、終了日時を必ず設定する |
| 月次レビューを行う | 上位消費ジョブ、失敗ジョブ、Limit exceeded件数を確認する |
Microsoft Sentinel data lakeは複数のデータソースを統合して長期分析できるため、使い始めると自然に利用範囲が広がります。だからこそ、最初から「誰が、何のために、どれだけ使ってよいか」を運用ルールに落とし込むことが重要です。
KQLクエリでコストを増やさない実務ルール
Cost limitsは最後の安全装置です。日常運用では、そもそも重すぎるクエリを減らす設計が必要です。MicrosoftのKQLドキュメントでは、Data lakeに対するKQLクエリはAnalytics tierよりパフォーマンスが低く、履歴データの探索やData Lake onlyのテーブルを扱う場合に使うべきと説明されています。(Microsoft Learn)
実務で守りたいルールは次の通りです。
| ルール | 悪い例 | 良い例 |
|---|---|---|
| 時間範囲を必ず絞る | いきなり12か月分を検索する | まず24時間、次に7日、必要なら30日へ広げる |
| フィルターを早く適用する | 全件取得後に条件を絞る | whereで対象ホスト、ユーザー、IP、期間を先に絞る |
| 列を絞る | すべての列を返す | projectで調査に必要な列だけ返す |
| ジョブ化する前に検証する | 未検証クエリをスケジュール化する | 小さい期間で結果と消費傾向を確認する |
| Analytics tierと使い分ける | 直近調査もData Lakeに投げる | リアルタイム性が必要な調査はAnalytics tierを優先する |
Microsoft Sentinel data lakeのKQLには、結果サイズ、行数、タイムアウトなどのサービス制限もあります。Microsoft Learnでは、対話型KQLの結果データ64MB、結果行数50万行、クエリタイムアウト4分などの制限が示されています。(Microsoft Learn)
この制限は単なる仕様ではなく、コスト管理のヒントでもあります。50万行を返すクエリを頻繁に実行しているなら、多くの場合、調査設計を見直す余地があります。検知・調査で必要なのは「大量の生データ」ではなく、「判断に必要な最小限の証拠」です。
Notebook利用で失敗しやすいポイント
Advanced Data Insights側で特に注意したいのが、Jupyter Notebookです。Notebookは、Python、Spark、可視化、機械学習を組み合わせられるため、脅威ハンティングやフォレンジックに非常に有効です。一方で、実験的なコードを何度も実行したり、Largeプールを使い続けたりすると、コストが膨らみやすくなります。
MicrosoftのNotebookドキュメントでは、Smallは開発・テスト・軽量な探索、MediumはETLや結合・集計・MLモデル学習、Largeは深層学習、大規模結合、時間重視の処理に向くと説明されています。(Microsoft Learn)
| 利用シーン | 推奨する考え方 |
|---|---|
| 初回探索 | Smallで開始し、対象期間と列を絞る |
| 中規模の集計 | Mediumを使う前に、入力データ量と出力先を確認する |
| ML・大規模結合 | Large利用の理由、想定時間、終了条件を記録する |
| 定期実行 | Notebookジョブとして所有者と実行頻度を管理する |
| 調査終了後 | 不要なセッションやジョブが残っていないか確認する |
Notebookでは、対話型セッションの無操作タイムアウトやジョブタイムアウト、同時実行数にも制限があります。Microsoft Learnでは、Notebook job timeoutは8時間、同時Notebookジョブは最大3で、それ以降はキューに入ると説明されています。(Microsoft Learn)
つまり、Notebookのガバナンスでは「誰に許可するか」だけでなく、「どのプールを選ぶか」「どれだけ実行するか」「ジョブ化してよいか」まで管理対象になります。Cost limitsは、その運用ルールを破ったときの最後の防波堤です。
Limit exceededが出たときの対応フロー
Enforcementを有効化すると、しきい値超過後の新しいクエリやジョブ、Notebookセッションは失敗します。現場の混乱を避けるには、Limit exceededエラーを見たアナリストが次に何をすればよいかを明確にしておく必要があります。
| 状況 | アナリストの対応 | 管理者の対応 |
|---|---|---|
| 日常調査で発生 | クエリ範囲を短くする、列を絞る、既存結果を再利用する | 使用量上位のクエリやジョブを確認する |
| スケジュールジョブで発生 | ジョブ所有者に連絡する | 不要ジョブの停止、頻度変更、しきい値見直しを行う |
| 重大インシデント中に発生 | インシデント番号を添えて例外申請する | 一時的な上限変更またはEnforcement無効化を判断する |
| Notebookで発生 | プールサイズ、対象データ、実行回数を見直す | Advanced Data Insights側の消費傾向を確認する |
ここで避けたいのは、管理者がその場の判断で恒久的にしきい値を引き上げてしまうことです。一時的な例外であれば、必ず期限を設定し、調査後に元へ戻します。変更理由と変更前後の値を記録しておけば、後日のコストレビューや監査にも対応しやすくなります。
Cost limitsだけに頼ってはいけない注意点
Microsoft Sentinel data lakeのcost limitsは強力ですが、万能ではありません。特に次の点は、導入前に関係者へ共有しておくべきです。
実行中の処理は止まらない
Microsoftの発表では、Enforcementは実行中の処理を遡って止めるものではなく、すでに走っているクエリやジョブは通常どおり完了するとされています。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、非常に大きなジョブがすでに開始されている場合、Enforcementだけで即座に消費を止めることはできません。ジョブ設計、スケジュール管理、レビューが引き続き必要です。
適用に時間差がある
Microsoft Learnでは、Enforcementはリアルタイムではなく、しきい値到達後に適用されるまで最大4時間かかる場合があると説明されています。(Microsoft Learn)
高頻度のクエリやNotebookジョブが短時間に集中する環境では、この時間差を前提にアラート率を早めに設定する必要があります。
RBACとコスト制限は別物
Microsoft Sentinelでは、SIEM側はAzure RBAC、data lake側はMicrosoft Entra ID RBACやDefender XDR unified RBACなど、用途に応じた権限管理が関わります。Microsoftのロールドキュメントでは、最小権限の利用が推奨され、data lakeの読み取りや書き込み、ジョブ管理に必要なロールも整理されています。(Microsoft Learn)
Cost limitsは「使いすぎ」を防ぐ仕組みであり、「見てはいけないデータを見せない」仕組みではありません。データアクセス制御、テーブル単位の権限、職務分掌は別途設計してください。
Azure全体の予算管理は別途必要
Microsoft SentinelのコストはAzure請求の一部であり、他のAzureサービスや関連リソースの費用も発生します。Microsoft Learnでも、SentinelのコストはAzure請求全体の一部であると説明されています。(Microsoft Learn)
Data lakeのKQLやNotebookにEnforcementを入れても、データ取り込み、保存、他サービス、Logic Apps、Azure Functionsなどのコスト管理が不要になるわけではありません。FinOps観点では、Azure Budgets、Cost Analysis、タグ設計、月次レビューと組み合わせる必要があります。
導入時のチェックリスト
最後に、Sentinel adminsとFinOps-aware security teamsが実際に進めるためのチェックリストをまとめます。
| チェック項目 | 確認内容 |
|---|---|
| 対象ワークロード | Data Lake QueryとAdvanced Data Insightsのどちらを制限するか |
| 権限 | Billing AdministratorとSecurity Administratorを持つ担当者がいるか |
| ベースライン | 過去の使用量、ピーク、上位ジョブを確認したか |
| しきい値 | 通常運用、余裕枠、緊急時の上限を分けて考えたか |
| アラート率 | 通知後の対応者と対応手順が決まっているか |
| 例外対応 | 重大インシデント時の一時解除・引き上げ手順があるか |
| ジョブ台帳 | KQLジョブ、Notebookジョブの所有者と目的を記録しているか |
| 利用者教育 | Limit exceeded時の問い合わせ先とクエリ最適化ルールを共有したか |
| 月次レビュー | 消費傾向、失敗ジョブ、例外対応を定期確認する予定があるか |
Microsoft Sentinel data lakeのhard cost limitsは、セキュリティ分析を抑制するための機能ではありません。むしろ、長期ログ分析やNotebookによる高度な調査を、予算面の不安を減らしながら広げるための仕組みです。
最初に行うべきことは、Enforcementをオンにすることではなく、現在のKQLクエリ、KQLジョブ、Notebook利用を棚卸しすることです。そのうえで、Data Lake QueryとAdvanced Data Insightsを分けてしきい値を設計し、アラート時の対応と緊急時の例外ルールを決めます。ここまで準備してからEnforcementを有効化すれば、Microsoft Sentinel data lakeは「便利だがコストが読みにくい分析基盤」から、「大規模分析を安心して運用できるセキュリティデータ基盤」へ近づきます。
コメント