Azure Monitorの「Dynamic threshold for Log search alerts」は、ログ検索アラートのしきい値を固定値で決める手間を減らし、過去のログクエリ結果から通常パターンを学習して異常を検知しやすくする機能です。2026年6月3日に確認された公式更新では一般提供として扱われており、Azure Updatesの「Launched」は本番利用可能な状態を示します。(Microsoft Azure)
結論から言うと、すべての既存アラートを一括で置き換えるべき機能ではありません。まずは「時間帯や曜日で正常値が変わるログ監視」「しきい値調整が難しく通知が多いアラート」「複数リソースやディメンションをまたぐ監視」から試すのが現実的です。一方で、「1件でも発生したら即対応が必要」「SLOや運用ルールで明確な固定値がある」アラートは、従来どおり静的しきい値を残す判断も重要です。
Azure MonitorのDynamic threshold for Log search alertsで何が変わるのか
Dynamic threshold for Log search alertsは、Azure Monitorのログ検索アラートに「動的しきい値」を使えるようにする更新です。
従来のログ検索アラートでは、たとえば「5分間のエラー数が100件を超えたら通知する」「失敗ログが10件以上なら重大」といった固定値を人が決める必要がありました。しかし実際のシステムでは、平日昼間、深夜、月曜朝、キャンペーン期間などで正常なログ量が大きく変わります。そのため、固定値だけでは「通知が多すぎる」か「本当に異常な増加を見逃す」状態になりがちです。
動的しきい値では、Azure Monitorがログクエリ結果の履歴を学習し、時間帯・日次・週次のパターンや異常な変化をもとに適切なしきい値を計算します。Microsoft Learnでは、動的しきい値がメトリックとログクエリ結果の履歴動作を学習し、異常を認識して適切なしきい値を計算すると説明されています。(Microsoft Learn)
今回のポイントは、Copilotのように対話で運用を支援する機能ではなく、Azure Monitorのアラート判定そのものに機械学習ベースのしきい値計算を使える点です。つまり、運用担当者が毎月しきい値を微調整する負担を減らし、より実態に合ったログ監視へ近づけるための更新と考えると分かりやすいでしょう。
| 比較項目 | 静的しきい値 | 動的しきい値 |
|---|---|---|
| しきい値の決め方 | 管理者が固定値を設定 | 過去のクエリ結果からAzure Monitorが計算 |
| 向いている監視 | 明確な基準値がある監視 | 正常値が時間帯・曜日で変わる監視 |
| 例 | エラーが1件でも出たら通知、失敗率5%以上で通知 | 平日昼のアクセス増、週末の低トラフィック、月曜朝の処理増を考慮した異常検知 |
| メリット | 判定理由が単純で説明しやすい | しきい値調整の手間や通知ノイズを減らしやすい |
| 注意点 | 正常な変動でも通知されやすい | 学習期間やデータ品質の影響を受ける |
影響範囲はログ検索アラートが中心
今回の対象は、Azure MonitorのLog search alerts、つまりログ検索アラートです。ログ検索アラートは、Log Analyticsなどに対するKQLクエリの結果を評価し、条件を満たしたときにアラートを発火します。
Microsoft Learnでは、ログ検索アラートの測定対象として「返された行数」と「数値列の計算結果」の2種類が示されています。たとえば、Windowsイベントログ、Syslog、アプリケーション例外の件数を数える監視や、CPU使用率のような数値列を集計する監視に使えます。(Microsoft Learn)
既存の静的しきい値アラートが自動的に動的しきい値へ変わるわけではありません。実務上は、管理者が対象ルールを選び、条件設定でThresholdをDynamicに変更する流れになります。既存の通知先、アクショングループ、重大度、タグ、運用手順も含めて確認する必要があります。
特に影響を受けるのは、次のような運用です。
- エラー件数や例外件数のログ検索アラートを多数持っている環境
- AKS、VM、App Service、Application InsightsなどのログをKQLで監視している環境
- リソース単位、サービス単位、名前空間単位などディメンションで分割して監視している環境
- 過去に「しきい値が低すぎて通知が多い」「高くしすぎて検知が遅い」という調整を繰り返してきた環境
一方で、Azure Monitorの通知機能そのものや、アクショングループの考え方が置き換わる更新ではありません。ログ検索アラートの判定条件に動的しきい値を使えるようになった、と捉えるのが正確です。
Dynamic thresholdが特に役立つ監視シナリオ
動的しきい値が効果を発揮しやすいのは、「正常な値が一定ではないが、異常なズレは検知したい」場面です。
アプリケーションのエラー数監視
Webアプリのエラー件数は、アクセス数に比例して増減します。昼間はエラーが20件でも正常範囲、深夜は5件でも異常というケースがあります。
静的しきい値で「5分間に10件以上」と設定すると昼間に通知が多くなり、「100件以上」にすると深夜の異常を見逃すかもしれません。動的しきい値なら、時間帯ごとの通常パターンから外れた増加を検知しやすくなります。
AKSやVMの再起動・失敗イベント監視
Podの再起動回数、ジョブ失敗数、VM上の特定イベントなどは、サービスや名前空間によって通常値が異なります。
すべての対象に同じ固定値を当てると、負荷の高いサービスでは通知が多く、低トラフィックのサービスでは検知が遅れることがあります。ディメンションで分割し、各系列の通常パターンに合わせて監視する使い方が向いています。
バッチ処理や定期処理の失敗監視
毎時、日次、週次で実行される処理は、特定の時間帯だけログ量が増えます。正常な増加と異常な増加を固定値だけで分けるのは難しいため、過去パターンを学習する動的しきい値と相性があります。
ただし、失敗が1件でも業務影響につながるバッチでは、動的しきい値だけに頼らず、静的しきい値のアラートを併用するのが安全です。
設定前に確認すべき重要ポイント
動的しきい値は便利ですが、設定すれば自動的に良い監視になるわけではありません。導入前に、次の条件を確認してください。
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| KQLクエリ | 時系列で安定して評価できる結果を返すか | 一時的な調査用クエリをそのままアラート化する |
| 測定値 | 件数または数値列として意味があるか | 文字列や不安定な集計結果を監視対象にする |
| ディメンション | 分割単位が多すぎないか | リソース、ユーザー、URLなどを増やしすぎて系列が爆発する |
| 評価頻度 | 1分頻度を前提にしていないか | 既存の高頻度ログアラートをそのまま動的化しようとする |
| 学習期間 | 十分な履歴データがあるか | 新規サービスや移行直後のログにすぐ適用する |
| 通知設計 | 通知先、重大度、抑制ルールが適切か | 動的化だけしてオンコール運用を見直さない |
Microsoft Learnでは、動的しきい値は作成時に10日分の履歴データを使って時間単位または日次の季節性を計算し、3週間後には週次パターンを識別できるだけのデータがそろうと説明されています。また、3日分かつ30サンプル以上のデータが集まるまではアラートを発火しない点にも注意が必要です。(Microsoft Learn)
さらに、ログ検索アラートで動的しきい値を使う場合、1分頻度はサポートされません。複数条件を監視するアラートルールでも動的しきい値は使えないため、既存ルールを移行する前に条件構成を確認しておきましょう。(Microsoft Learn)
設定時に見るべき項目
Azure Portalでログ検索アラートを作成または編集する場合、基本的な流れは従来のログ検索アラートと同じです。違いは、Alert logicでThresholdにDynamicを選ぶ点です。
| 設定項目 | 推奨される考え方 |
|---|---|
| Query | 監視したい現象をシンプルに集計する。調査用の複雑なKQLをそのまま使わない |
| Measurement | 件数監視ならTable rows、数値列を監視するならCalculation of a numeric columnを検討する |
| Aggregation granularity | 短すぎると一時的な揺れに反応しやすい。業務影響が出る時間幅に合わせる |
| Split by dimensions | サービス名、リソースID、名前空間など、対応判断に必要な単位に絞る |
| Operator | 上振れだけ見るのか、下振れも含めるのかを明確にする |
| Threshold sensitivity | 初期はMediumまたはLowから始め、通知量を見ながら調整する |
| Number of violations | 一時的なスパイクで通知したくない場合は、複数回の違反で発火するようにする |
| Preview chart | 過去データに対して、どのタイミングで発火しそうかを必ず確認する |
Azure Monitorのアラート設定では、動的しきい値の感度としてHigh、Medium、Lowを選べます。Highは小さな逸脱でも反応しやすく、Lowは大きな逸脱に絞って反応するため通知数は少なくなります。(Microsoft Learn)
実務では、いきなりHighにするよりも、MediumまたはLowで開始するほうが運用に乗せやすいです。特に既存の静的アラートで通知が多すぎる課題がある場合、Highにすると別の形で通知ノイズが残る可能性があります。
KQL設計で失敗しないための考え方
動的しきい値では、Azure Monitorがクエリ結果のパターンを学習します。そのため、KQLの作り方が悪いと、しきい値の精度も下がります。
避けたいのは、調査時に使った複雑なクエリをそのままアラート化することです。アラート用のKQLは「何を、どの粒度で、どの単位に分けて監視するか」が明確である必要があります。
たとえば、エラー件数をサービス単位で監視したい場合は、次のように時刻とサービス単位で数値を返す形に整えます。実際のテーブル名や列名は環境に合わせて置き換えてください。
YourLogTable
| where TimeGenerated > ago(30m)
| where Level == "Error"
| summarize errorCount = count()
by bin(TimeGenerated, 5m), ServiceNameこのようなクエリでは、errorCountが監視対象の数値列、ServiceNameがディメンション候補になります。サービスごとの通常パターンが異なる場合は、ディメンション分割が有効です。
ただし、ディメンションを増やしすぎると、評価対象の時系列が増えます。Microsoft Learnでは、ログ検索アラートで最大6個のディメンションを適用でき、複数ディメンションを使うと組み合わせごとにアラートが評価されると説明されています。(Microsoft Learn)
また、ログ検索アラートのクエリには制限があります。bag_unpack()、pivot()、narrow()はサポートされず、AggregatedValueは予約語として使えません。大きすぎるクエリや長すぎる説明、アクショングループの増やしすぎにより、ログアラートルールのプロパティサイズ上限に達する可能性もあります。(Microsoft Learn)
管理者が確認すべき移行・展開上の注意点
既存のログ検索アラートを動的しきい値へ移行する場合は、「通知を減らすために一括変更する」のではなく、影響度を見ながら段階的に展開するのが安全です。
既存アラートを3分類する
まず、現在のログ検索アラートを次の3つに分けます。
| 分類 | 判断基準 | 対応方針 |
|---|---|---|
| 動的しきい値向き | 正常値が時間帯・曜日で大きく変わる | 動的しきい値の候補にする |
| 静的しきい値維持 | 1件でも重大、または固定の運用基準がある | 既存ルールを維持する |
| 見直し対象 | 通知が多いが対応されていない、クエリの意図が不明 | 動的化の前に監視目的を整理する |
特に、オンコール通知に直結しているアラートは慎重に扱うべきです。動的しきい値はノイズ削減に役立ちますが、遅い変化やゆっくり悪化する問題の検知には向かない場合があります。Microsoft Learnでも、動的しきい値は大きな逸脱の検知に適しており、ゆっくり進行する問題ではアラートが発火しない可能性があると説明されています。(Microsoft Learn)
最初は並行運用で比較する
既存の静的アラートをすぐに無効化せず、同じ監視対象に対して動的しきい値のルールを作成し、一定期間は発火タイミングを比較する方法が安全です。
比較時には、次の観点を見ます。
- 静的アラートでは通知されたが、動的しきい値では通知されなかったケース
- 動的しきい値では通知されたが、実際には正常だったケース
- 障害や性能劣化の初動検知として十分な速さだったか
- 通知先の担当者が、アラート理由を理解できる内容になっているか
この比較で問題がなければ、静的アラートを縮小する、重大度を下げる、またはバックアップ用に残すといった判断ができます。
感度調整は通知量だけで決めない
通知が多いからLowにする、通知が少ないからHighにする、という単純な調整は避けましょう。
感度は、監視対象の性質と対応コストで決めます。顧客影響が出やすいAPIエラーや認証失敗の急増はMedium以上を検討し、短時間の揺れが多い内部ジョブや開発環境のログはLowから始める、といった判断が現実的です。
動的しきい値の通知が多すぎる場合は、感度を下げるだけでなく、集計期間を広げる、複数回の違反で発火するようにする、監視対象のクエリを見直すといった調整も必要です。Microsoft Learnでも、通知が多すぎる場合の対策として、感度をLowにする、データウィンドウを広げる、複数の逸脱が起きた場合に発火するよう設定する方法が示されています。(Microsoft Learn)
開発者が確認すべきデプロイ・IaCのポイント
ポータルでの設定だけでなく、Bicep、ARMテンプレート、TerraformなどのIaCで管理している環境では、APIバージョンとプロパティ対応を確認する必要があります。
Microsoftのリソース定義では、Microsoft.Insights/scheduledQueryRules@2026-03-01において、criterionTypeにDynamicThresholdCriterionを指定でき、alertSensitivity、failingPeriods、ignoreDataBefore、metricMeasureColumnなどのプロパティが確認できます。(Microsoft Learn)
実装時に確認したいポイントは次のとおりです。
| 項目 | 確認内容 |
|---|---|
| APIバージョン | 使用中のテンプレートが動的しきい値に対応したバージョンか |
| criterionType | 動的しきい値ではDynamicThresholdCriterionを指定する |
| alertSensitivity | High、Medium、Lowのどれを標準にするか |
| operator | 上限超過、下限割れ、上下両方のどれを検知するか |
| failingPeriods | 何回中何回の違反で通知するか |
| metricMeasureColumn | 監視対象の数値列名が正しいか |
| dimensions | 分割対象の列が存在し、数が増えすぎないか |
| ignoreDataBefore | 移行直後や大規模障害直後のデータを学習に含めるべきか |
Terraformを使っている場合は、AzureのAPIが対応していても、利用中のプロバイダーが同じタイミングで対応しているとは限りません。AzAPI providerのようにARM APIへ直接近い形で扱える選択肢もありますが、既存のIaC運用ルール、レビュー体制、state管理との整合性を確認してから採用しましょう。
料金とコスト管理で注意すべきこと
動的しきい値を使うときは、監視精度だけでなくコストも確認しておく必要があります。
Azure Monitorの価格情報では、アラートルールは監視するシグナルの種類や数に基づいて課金され、ログアラートルールはクエリの実行間隔に基づいて課金されると説明されています。また、複数ディメンションの結果を評価する場合は、評価されるディメンション、つまり時系列ごとに追加料金が発生する可能性があります。(Microsoft Azure)
特に注意したいのは、動的しきい値そのものよりも、次の設定変更です。
- 評価頻度を短くする
- ディメンションを増やす
- 対象リソースを広げる
- アクショングループによる通知数が増える
- Basic Logsなど、スキャン量に応じた追加課金が関係するログを使う
通知も別枠で課金対象になる場合があります。メール、Webhook、SMS、音声通知など、通知方法によってコスト構造が変わるため、アラート条件だけでなく通知設計も一緒に確認してください。(Microsoft Azure)
動的しきい値を使わないほうがよいケース
Dynamic threshold for Log search alertsは便利ですが、万能ではありません。次のようなケースでは、静的しきい値を維持するか、併用するほうが安全です。
1件でも発生したら重大なログ
セキュリティ違反、決済失敗、データ削除失敗、バックアップ失敗などは、通常パターンからの逸脱ではなく「発生そのもの」が問題です。
この場合、「普段より多いか」ではなく「発生したかどうか」が重要なので、静的しきい値のほうが適しています。
ゆっくり悪化する問題
メモリリーク、処理遅延の漸増、キュー滞留のじわじわした増加などは、動的しきい値では正常パターンの変化として扱われる可能性があります。
このような問題には、固定の上限値、SLOベースの監視、傾きや増加率を見るクエリなどを組み合わせるべきです。
履歴データが少ない新規サービス
新しく作成したサービスや、ログ形式を変えた直後のシステムでは、十分な履歴がありません。動的しきい値は履歴から学習するため、最初から期待どおりの判定になるとは限りません。
新規サービスでは、まず静的しきい値で最低限の監視を置き、データが蓄積してから動的しきい値を検討する流れが安全です。
導入時のおすすめ手順
Dynamic threshold for Log search alertsを導入するなら、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | 既存のログ検索アラートを一覧化する | ルール名、KQL、重大度、通知先、発火頻度の一覧 |
| 候補選定 | 通知が多い、しきい値調整が難しい、季節性があるルールを選ぶ | 動的しきい値化の候補リスト |
| クエリ整理 | KQLをアラート向けに簡素化する | 数値列とディメンションが明確なクエリ |
| 並行運用 | 静的ルールを残したまま動的ルールを追加する | 発火タイミングの比較結果 |
| 感度調整 | MediumまたはLowを基準に調整する | 運用に合った感度・評価期間 |
| 本番展開 | 問題が少ないものから既存ルールを置き換える | 更新済みアラート設計 |
| 定期レビュー | 障害後、リリース後、季節イベント後に見直す | 誤検知・見逃し・コストの改善点 |
最初に選ぶ候補は、重要度が高すぎるものではなく、「通知が多いが即時の重大障害ではない」「過去データが十分にある」「担当者が発火結果を評価できる」アラートが向いています。
まず管理者・開発者がやるべきこと
今回の一般提供で、Azure Monitorのログ検索アラートは固定値中心の監視から、ログの実態に合わせた異常検知へ広げやすくなりました。特に、ログ量やエラー件数が時間帯によって変わるシステムでは、動的しきい値により通知ノイズを減らしつつ、通常パターンから外れた変化を検知しやすくなります。
ただし、重要なのは「動的しきい値へ移行すること」ではなく、「どの監視に動的しきい値が向いているかを見極めること」です。
まずは、現在のログ検索アラートを棚卸しし、通知頻度が多いルール、しきい値調整に時間がかかっているルール、曜日や時間帯で正常値が変わるルールを3〜5個選んでください。そのうえで、静的アラートを残したまま動的しきい値のルールを作成し、Preview chartと実際の発火結果を比較するのが現実的な第一歩です。
最終的には、静的しきい値と動的しきい値を使い分ける設計が理想です。絶対に見逃せないイベントは静的しきい値で守り、季節性や負荷変動があるログ監視は動的しきい値で最適化する。この組み合わせが、Azure Monitorのログ監視を実務で使いやすくする近道です。
コメント