コンテンツに移動
管理ツール

Cloud Monitoring: 動的しきい値と 2 年間のルックバックを活用したアラートによる異常検出

2026年7月15日
Lee Yanco

Senior Product Manager

Daniel Koss

Staff Software Engineer

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 7 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

アラート ポリシーのしきい値を適切に設定することは難しい作業になりがちです。過去のデータを分析し、意味のある時系列データに集約したうえで、適切なしきい値を選択する必要があります。ワークロードが増加した場合は、以前に設定した静的なしきい値が低くなりすぎ、アラートが頻繁に発生してしまう可能性があります。また、新しいワークロードには新たなしきい値の設定が必要になることもあり、その場合は、ワークロードごとにしきい値を設定するために個別のポリシーを作成することになります。その結果、ほぼ同じようなポリシーを多数管理するという煩わしさが生じます。

言うまでもなく、一部の指標では、静的なしきい値によるアラート設定自体ができません。指標が時間帯によって変動する場合(多くの e コマース指標が該当)、単一のしきい値では対応できません。たとえば、指標が次のような場合はどうすればよいでしょうか。

https://storage.googleapis.com/gweb-cloudblog-publish/images/qtfse9nqWC88b92.max-2200x2200.png

このグラフの途中では明らかに何か問題が発生していますが、この異常値は日次データの正常範囲内にあるため、静的なしきい値では決して検出できません。

長期ルックバックと動的しきい値の導入

このたび、プレビュー版としてリリースされた PromQL の長期ルックバック アラート ポリシーは、Cloud Monitoring のアラートにおけるこの課題を解決するものです。特にご要望が多かったこの機能アップデートにより、Cloud Monitoring に保存された 2 年間以上の指標データに対して PromQL アラート ポリシーを構成できるようになり、前年比や前四半期比の分析が可能になります。

PromQL での 2 年間のルックバックによって実現される主なユースケースの一つが、動的しきい値です。これは、しきい値が指標の履歴を参照するポリシーです。簡単な例として、「過去 5 分間の平均値が過去 1 週間の平均値の 2 倍を超えたらアラートを送信する」というアラート ポリシーを考えてみましょう。この場合、しきい値として静的な数値を設定する代わりに、アラートを生成する前に、各時系列データが過去のデータに対してどの程度逸脱しているかを設定します。これにより、ポリシーの柔軟性が向上し、ワークロードの増加によって自然に変化するベースラインに対応できるほか、あらゆるワークロードに適用可能な単一のしきい値を提供できます。アラートを適切に設定するためにすべての時系列を分析する必要はありません。「異常」だと判断する要素を設定するだけで済みます。

上の例でこの異常を検出するには、「過去 5 分間の値が、1 週間前の同じ 5 分間の値の 70% を下回った場合にアラートを送信する」というポリシーを作成します。このようなポリシーにより、時間帯に応じて変動するしきい値が設定され、異常な低下を検知できるようになります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/8JX8WREHZPq68Fc.max-2100x2100.png

動的しきい値のアルゴリズム

PromQL で適切な動的しきい値のアルゴリズムを選択するには、ソースデータの特性を考慮する必要があります。時間帯によって変動する指標には、変動が少ない指標とは異なるアルゴリズムが必要です。

以下の例を書き換えて、履歴データクエリをしきい値として設定することも可能です(< または > の後に指標を指定します)。ただし、この場合はしきい値を簡単に可視化できなくなります。

これらは履歴データを使用するため、集計値ではなく個々のワークロード単位でトリガーされるきめ細かなアラート ポリシーは、新しいワークロードをスピンアップするときに不安定になる可能性があります。この問題は、履歴データが蓄積されるにつれて自然に解消されます。また、動的しきい値アラートを集計値に対してのみ実行することで、この問題を回避することもできます。

移動平均最もシンプルなアルゴリズムでは、データの最近の傾向が長期にわたるデータの移動平均から逸脱した際に、アラートがトリガーされます。これは、比較的安定したデータにおける異常値を検出するのに適しています。

以下は、過去 5 分間のデータを 1 週間のベースラインと比較し、平均より 30% 高いまたは低い場合にアラートを発行する PromQL の例です。

読み込んでいます...
https://storage.googleapis.com/gweb-cloudblog-publish/images/4v9HQ8snDJbP2oR.max-1400x1400.png

これは直接比較する形として記述することもできます(その方がわかりやすいかもしれません)。以下の例は、「直近 5 分間のデータの平均値が 1 週間の平均値の 1.3 倍を超えたらアラートを送信する」というものです。

読み込んでいます...

Z スコア(標準偏差)このアルゴリズムを使用すると、データの平均値と標準偏差に基づいて異常値を特定できます。Z スコアは、最近のデータと過去のデータとの間の統計的な距離を測定するものです。一般的なしきい値として、Z スコアが 3 を超えるか -3 を下回ると異常とみなされます。これは、通常のノイズと比較したデータの変動性を測定するものであり、平均値が安定していて適度な変動性を持つデータで最も効果を発揮します。

過去 5 分間のデータを 1 週間の平均値と標準偏差と比較する PromQL の例:

読み込んでいます...

Z スコアのシグナルと、その結果として得られる異常検出のしきい値の例:

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_VFrHPBv.max-1700x1700.png

季節変動の分解(時間オフセット比較)これは、ある期間の時系列データを、前日または前週の同じ期間と比較する単純な時間オフセット アルゴリズムであり、時間帯や曜日によって変動するウェブサイトの訪問者数など、時間に関連するパターンを持つ指標に最適です。祝日やその他の要因によって、特定の日の数値が予想よりも低くなる可能性がある場合は、複数の過去の期間の平均を算出することで平滑化できます(たとえば、1 週間前、2 週間前、3 週間前の平均を算出し、その平均値を今日のデータと比較します)。

過去 5 分間と昨日の同じ時間帯を比較し、最近のデータが 1 日オフセットされたデータよりも 50% 以上低い場合にアラートを発行する PromQL の例:

読み込んでいます...

これは、代数的に書き換えると次のようになります。

読み込んでいます...
https://storage.googleapis.com/gweb-cloudblog-publish/images/Bkby4f9LySHuz75.max-1500x1500.png

本番環境では、週末や祝日など、本来アクセス数が少ない日にアラートがトリガーされるのを避けるため、1 週間前の同じ期間と比較したり、1 日前や 7 日前の同じ期間の平均値と比較したりすることが望ましい場合があります。

読み込んでいます...

時間オフセットを使用する場合は、急激な減少または急激な増加のどちらか一方だけを確実にトリガーするようにします。これは、1 つのポリシーで両方をトリガー対象にすると、アラートが 2 回発生してしまう可能性があるためです。

たとえば、今日のトラフィックが急激に減少した場合、アラートは直ちにトリガーされます。しかし、ちょうど 24 時間後には、今日の異常な減少が明日の過去のベースラインとして扱われます。ポリシーが異常な差異(増加や減少)に対してトリガーされる場合、明日の急激な「正常値への回復」は、前日と比べると大きな値の増減に見えるため、実際には発生していない異常に対してアラートが誤って発行されることになります。これは上のグラフでも確認できます。シグナルの低下(青い線)が、ちょうど 24 時間後にその逆の値として再び現れています。

これを防ぐには、特定の指標をモニタリングする際に、急激な減少または急激な増加のいずれか一方のみを追跡するようにします。

動的しきい値を使用して費用の急増を抑制する

過去のベースラインからの逸脱に基づいてアラートをトリガーできるようになると、多くの興味深いユースケースが生まれます。たとえば、動的しきい値を使用すると、費用を大まかに追跡できる指標を提供する Google Cloud サービスにおいて、予算超過を防ぐことができます。

ここでは、AI トークンの費用の急増を防ぐ例を考えてみましょう。たとえば、次のように設定します。

  • 直近 10 分間の入出力トークンの累積使用量が、過去 1 週間の平均の 25 倍を超えた場合にトリガーされる動的しきい値アラートを構成します。これは、過剰な支出が確実に発生することにつながる極端な異常事態(API キーの漏洩など)のみを捕捉するものです。

    • sum(rate({"__name__"="aiplatform.googleapis.com/publisher/online_serving/token_count"}[10m])) > 25 * sum(rate({"__name__"="aiplatform.googleapis.com/publisher/online_serving/token_count"}[1w]))

  • アラートをトリガーして、Pub/Sub 通知チャンネルに通知を送信し、そこから Cloud Run 関数に通知を push します。

  • この Cloud Run 関数は、Cloud Quotas API を使用してトークン使用量の割り当てを 0 に下げるワークフローを実行し、過剰支出を即座に停止します。トークンの正当な使用は、問題が解決されるまで一時停止されますが、少なくとも損失の拡大は食い止めることができます。

デザイン パートナーにご登録ください

Google は現在、しきい値を使用した異常検出をより簡単に実装できるよう製品化を進めています。また、Cloud Monitoring のアラートにおいては、時系列データ向けに特化してトレーニングされた AI モデルを使用する、より高度な異常検出アルゴリズムの開発にも取り組んでいます。

このような分野で Google が進めている取り組みについてご関心をお持ちの方や、先行ユーザーとしてご協力いただける方は、ぜひプレビュー パートナーにご登録ください。皆様のご参加を心よりお待ちしております。

- シニア プロダクト マネージャー、Lee Yanco

- スタッフ ソフトウェア エンジニア、Daniel Koss

投稿先