みなさんこんにちは。マネージドサービス課の塩野です。
今回の記事では、New Relicは2025年7月にGAした「NRQL Predictions」とAnomaly Detection(異常検知)について取り上げてみました。従来のAnomaly Detection(異常検知)が「今、何かおかしい」を教えてくれる機能だったのに対し、Predictionsは「このままだと将来、問題が起きそうだ」を事前に知らせてくれます。
この記事では、両機能のアルゴリズムの違い、使い分けのポイント、設定方法を解説してみました。
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#e1f5ff','primaryTextColor':'#000','primaryBorderColor':'#0066cc','lineColor':'#0066cc','secondaryColor':'#fff4e1','tertiaryColor':'#f0f0f0','background':'#ffffff','mainBkg':'#ffffff','textColor':'#000000'}}}%%
graph TD
A[システム監視の2つのアプローチ] --> B[Anomaly Detection]
A --> C[Predictions]
B --> D[今の異常を検知]
C --> E[未来の問題を予測]
D --> F[標準偏差ベース]
E --> G[Holt-Winters]
style A fill:#f0f0f0,stroke:#333,stroke-width:2px
style B fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style C fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style D fill:#e1f5ff,stroke:#0066cc
style E fill:#fff4e1,stroke:#ff9900
style F fill:#e1f5ff,stroke:#0066cc
style G fill:#fff4e1,stroke:#ff9900
Anomaly Detection(異常検知)については過去にも話題に取り上げていますので、こちらも合わせてご一読ください。
目次
- 目次
- Anomaly Detection(異常検知)とは
- NRQL Predictions(予測)とは
- 両者の技術的な違いを理解する
- 実務での使い分けガイド
- それぞれの設定手順
- 利用に必要な契約について
- まとめ
- 宣伝
Anomaly Detection(異常検知)とは
Anomaly Detectionは、メトリクスの値が「普段と比べて異常かどうか」を判断する機能です。過去のデータパターンを学習して動的にしきい値を調整する「Baseline Thresholds(ベースラインしきい値)」を使用します。
静的なしきい値(例えば「CPU使用率が80%を超えたらアラート」)とは異なり、時間帯や曜日による変動を考慮した判定が可能です。例えば、平日昼間はアクセスが多く夜間は少ないWebサイトの場合、「この時間帯としては異常に少ない」という判断ができます。
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#e1f5ff','primaryTextColor':'#000','primaryBorderColor':'#0066cc','lineColor':'#0066cc','secondaryColor':'#d4edda','tertiaryColor':'#f8d7da','background':'#ffffff','mainBkg':'#ffffff','textColor':'#000000'}}}%%
flowchart TD
A[過去7日間のデータ] --> B[標準偏差を計算]
B --> C[動的ベースライン生成]
C --> D[現在の値と比較]
D --> E{標準偏差の範囲内?}
E -->|Yes| F[正常]
E -->|No| G[異常検知・アラート発報]
style A fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style B fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style C fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style D fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style E fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style F fill:#d4edda,stroke:#28a745,stroke-width:2px
style G fill:#f8d7da,stroke:#dc3545,stroke-width:2px
標準偏差を使ったアプローチ
Anomaly Detectionのアルゴリズムは統計学の標準偏差をベースにしています。過去7日間のデータから予測値と実際の値の標準偏差を追跡し、現在の値が予測値から何標準偏差離れているかを計算します。
設定画面のスライダーで感度を調整できます。バンド(帯)が狭いほど多くのインシデントが発生し、広くすれば大きな異常のみを検知します。十分な履歴データがあるほど、予測の精度が向上します。
季節性の自動検出
New Relicは季節性(Seasonality)を自動的に検出します。時間単位、日次、週次といった周期的なパターンを学習し、それを考慮した異常判定を行います。
例えば「毎週月曜の朝はアクセスが多い」というパターンを学習すれば、月曜朝の高トラフィックは異常と判定されなくなります。季節性は自動検出のほか、手動で指定することも可能です。
適したユースケース
- 突発的なスパイクや急落: エラー率の急上昇、レスポンスタイムの悪化など、「今」起きている問題を即座に検知
- 季節性があるメトリクス: Webサイトトラフィックのように時間帯や曜日で変動する指標
- 統計的な異常: 普段から少数のエラーが発生しているシステムで、その頻度が異常なレベルまで跳ね上がったケース
NRQL Predictions(予測)とは
NRQL Predictionsは「未来」に焦点を当てた機能です。現在のトレンドが続いた場合、メトリクスの値が将来どうなるかを予測し、しきい値を超えると判断された時点でアラートを発報します。
問題が実際に発生する前に通知を受け取れるため、ディスク拡張やスケールアップなどの対策を余裕を持って実施できます。
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#fff4e1','primaryTextColor':'#000','primaryBorderColor':'#ff9900','lineColor':'#ff9900','secondaryColor':'#d4edda','tertiaryColor':'#f8d7da','background':'#ffffff','mainBkg':'#ffffff','textColor':'#000000'}}}%%
flowchart TD
A[過去のデータ] --> B[Holt-Wintersモデルで学習]
B --> C[レベル・トレンド・季節性を分析]
C --> D[将来の値を予測]
D --> E{しきい値を超える?}
E -->|Yes| F[予測アラート発報]
E -->|No| G[監視継続]
style A fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style B fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style C fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style D fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style E fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style F fill:#f8d7da,stroke:#dc3545,stroke-width:2px
style G fill:#d4edda,stroke:#28a745,stroke-width:2px
NRQL PREDICT句の仕組み
New Relicのクエリ言語NRQLにPREDICT句を追加することで、時系列データの将来の値を予測できます。2025年7月に正式リリースされたこの機能は、過去のデータパターンを機械学習モデルで学習し、そのモデルを使って将来を予測します。
デフォルトではクエリウィンドウの20%の期間を予測します(1時間のデータなら次の12分間)。BY句で予測期間、USING句で学習データ量を調整できます。
FROM Transaction SELECT average(duration) TIMESERIES PREDICT
Holt-Winters(三重指数平滑法)
Predictionsで使用されているのは、Holt-Winters法(別名:三重指数平滑法)です。時系列予測で広く使われる標準的な手法で、以下の3要素を考慮して予測を行います。
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#fff4e1','primaryTextColor':'#000','primaryBorderColor':'#ff9900','lineColor':'#ff9900','secondaryColor':'#e1f5ff','tertiaryColor':'#f0f0f0','background':'#ffffff','mainBkg':'#ffffff','textColor':'#000000'}}}%%
graph TD
A[Holt-Winters] --> B[レベル<br/>平均的な水準]
A --> C[トレンド<br/>増加/減少傾向]
A --> D[季節性<br/>周期的パターン]
B --> E[将来の予測値]
C --> E
D --> E
style A fill:#fff4e1,stroke:#ff9900,stroke-width:3px
style B fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style C fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style D fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style E fill:#d4edda,stroke:#28a745,stroke-width:2px
レベルはデータの平均的な水準、トレンドはデータが増加傾向か減少傾向か、季節性は一定周期で繰り返されるパターンを表します。
季節性がある場合は3要素すべてを考慮し、ない場合はレベルとトレンドのみで予測します。そのため非季節データの予測は直線的になります。
New Relicは季節性の有無を自動判定し、適切なモデルを選択します。現在サポートされているのは時間単位、日次、週次の季節性です。
適したユースケース
- ディスク容量枯渇の予測: ログの蓄積で徐々に増加する使用量から「3日後に100%になる」を事前予測
- メモリリークの検知: 右肩上がりで増え続けるメモリ使用量から、OOM(Out of Memory)発生前に警告
- ビジネスKPIの予測: 売上やユーザー登録数が目標値に届くかの見込み把握
両者の技術的な違いを理解する
Anomaly DetectionとPredictionsは、どちらも過去のデータを使いますが、その使い方が根本的に異なります。
時間軸の違い
最も大きな違いは「いつ」に焦点を当てているかです。
Anomaly Detectionは「今」を見ています。「現在の値は、普段のこの時間帯と比べておかしいか?」を判定します。問題が発生した瞬間、あるいは発生直後に検知することを目的としています。
Predictionsは「未来」を見ています。「今のペースで推移すると、X時間後に問題が起きるか?」を判定します。問題が実際に発生する前に、事前対処の時間を確保することを目的としています。
この違いを理解すると使い分けが明確になります。「今起きている異常」を知りたいならAnomaly Detection、「これから起きる問題」を予測したいならPredictionsです。
アルゴリズムの違い
両者が使用するアルゴリズムも大きく異なります。
| 項目 | Anomaly Detection | NRQL Predictions |
|---|---|---|
| アルゴリズム | 標準偏差ベース | Holt-Winters(三重指数平滑法) |
| 判定基準 | 過去のパターンとの乖離 | 将来の到達値 |
| 考慮する要素 | 標準偏差、季節性 | レベル、トレンド、季節性 |
| 得意なパターン | 突発的な変化、スパイク | 緩やかな増加・減少、トレンド |
| 学習期間 | 過去7日間 | クエリウィンドウ×3(デフォルト) |
標準偏差ベースのアプローチは、データのばらつきを統計的に評価します。「この値は統計的に見て異常か?」という問いに答えるのが得意です。
Holt-Wintersは時系列の傾向を捉えます。「このトレンドが続くと将来どうなるか?」という問いに答えるのが得意です。
実務での使い分けガイド
実際の監視設計では、以下の判断フローと具体例を参考にしてください。
判断フロー
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#e1f5ff','primaryTextColor':'#000','primaryBorderColor':'#0066cc','lineColor':'#0066cc','secondaryColor':'#fff4e1','tertiaryColor':'#f0f0f0','background':'#ffffff','mainBkg':'#ffffff','textColor':'#000000'}}}%%
flowchart LR
A[監視対象の特性] --> B{物理的な限界がある?}
B -->|Yes<br/>ディスク、メモリ等| C[Predictions]
B -->|No<br/>トラフィック、レスポンス等| D[Anomaly Detection]
A --> E{時間軸}
E -->|将来の問題を予測| C
E -->|今の異常を検知| D
style A fill:#f0f0f0,stroke:#333,stroke-width:2px
style B fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style C fill:#fff4e1,stroke:#ff9900,stroke-width:2px
style D fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style E fill:#fff4e1,stroke:#ff9900,stroke-width:2px
監視対象に物理的な限界(ディスク容量100%、メモリ上限など)がある場合、徐々にその限界に近づく様子を監視するならPredictionsが向いています。
一方、トラフィック量やレスポンスタイムのように上限が明確でなく値が変動するものなら、Anomaly Detectionが適しています。
シナリオ別の推奨機能
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#e1f5ff','primaryTextColor':'#000','primaryBorderColor':'#0066cc','lineColor':'#0066cc','secondaryColor':'#fff4e1','tertiaryColor':'#f0f0f0','background':'#ffffff','mainBkg':'#ffffff','textColor':'#000000'}}}%%
graph TB
A[監視シナリオ] --> B[Webトラフィック監視]
A --> C[データベースストレージ]
A --> D[APMレスポンスタイム]
A --> E[コンテナメモリ]
B --> F[Anomaly Detection<br/>季節性のある変動]
C --> G[Predictions<br/>徐々に増加]
D --> F
E --> G
style A fill:#f0f0f0,stroke:#333,stroke-width:2px
style B fill:#e1f5ff,stroke:#0066cc
style C fill:#fff4e1,stroke:#ff9900
style D fill:#e1f5ff,stroke:#0066cc
style E fill:#fff4e1,stroke:#ff9900
style F fill:#e1f5ff,stroke:#0066cc,stroke-width:2px
style G fill:#fff4e1,stroke:#ff9900,stroke-width:2px
Webアプリケーションのトラフィック監視 → Anomaly Detection
アクセス数は時間帯や曜日で変動するため季節性があります。突然のアクセス減少(障害の兆候)やDDoS攻撃による急増など、「今」の異常を即座に検知したい場面が多いためです。
データベースストレージの監視 → Predictions
ストレージ使用量は通常、徐々に増加していきます。「現在の増加ペースだと、いつ容量が満杯になるか」を事前に知ることで、計画的にディスク拡張やデータアーカイブを実施できます。
APMレスポンスタイムの監視 → Anomaly Detection
デプロイ直後の性能劣化や、突発的な高負荷による応答遅延など、ユーザー体験に直結する問題を即座に検知する必要があります。
コンテナメモリ使用量の監視 → Predictions
メモリリークがあると使用量が右肩上がりで増え続けます。OOM(Out of Memory)で突然コンテナがクラッシュする前に、「このままだとX時間後にメモリ不足になる」という警告を受け取れます。
両機能の併用パターン
実際の運用では両方を組み合わせるのが効果的です。
例えば、ディスク容量監視ではPredictionsで「3日後に満杯」の予測を受け取り、Anomaly Detectionで「突然の大量ログ出力」を検知する使い方ができます。データベースのパフォーマンス監視では、クエリ実行時間の突然の悪化をAnomaly Detectionで検知し、接続数の増加トレンドをPredictionsで監視することで、短期的な問題と長期的な問題の両方に対応できます。
それぞれの設定手順
Anomaly Detection(異常検知)の設定方法
基本手順
- Alerts > Alert Conditions > + New alert condition をクリック
- Write your own queryを選択してデータソースとメトリクスを選択
- Set condition thresholds のステップで Anomaly を選択
- 季節性を設定(New Relic calculation推奨、または手動でHourly・Daily・Weekly・None (don't calculate)を選択)
- 方向(上限・下限・両方)を選択し、スライダーで感度を調整
プレビューグラフの明るい灰色の帯が狭いほど感度が高く、より多くのインシデントが発生 - しきい値期間を設定(例: 「5分間連続で異常」に設定すれば、5分間異常範囲にある場合にアラート)
- アラート条件に名前を付けてポリシーに関連付け、保存

NRQL Predictionsの設定方法
既存のラインチャートまたはエリアチャートから、メニューの Predict trend を選択するだけで予測が追加されます。チャート上に灰色の領域が表示され、破線で将来の予測値が描画されます。
詳細制御する場合
View Query からNRQLを直接編集できます。
SELECT average(diskUsedPercent) FROM SystemSample WHERE entityName = 'myhost' PREDICT BY 4 hours USING 1 week TIMESERIES
BY: 予測期間を指定(例: 4 hours で4時間先まで予測)USING: 学習データ量を指定(例: 1 week で1週間分のデータで学習)holtwinters(seasonality: 1 day): 季節性を手動指定(通常は自動検出で十分)
予測グラフができたら Add to dashboard でダッシュボードに追加できます。

Predictive Alertsの設定方法
基本手順
- Alert conditions > New alert condition から作成開始
- NRQLクエリを入力(例: ディスク使用率の監視クエリ)
- Set condition thresholds で Static(静的しきい値)を選択
- Predict future behavior トグルをONにする(これが予測アラートの有効化)
- Look-ahead time(先読み時間)を設定
Window Durationの2〜360倍の範囲で指定可能(例: Window Duration 1分なら、2分〜360分) - しきい値(例:
result > 90)と条件期間(例:for at least 5 minutes)を設定して保存
設定完了後、予測値がしきい値を超えると判断された時点でアラートが発報されます。インシデントのタイトルには「Predict」という文字が含まれるため、予測アラートか実アラートかが一目で判別できます。

利用に必要な契約について
NRQL PredictionsとPredictive Alertsを使用するには、Advanced Computeの契約が必要です。これはAdvanced Compute Add-onとして追加するか、Compute価格モデルの一部として提供されます。この契約にはCCU (Compute Capacity Unit) を消費するため、使用状況などによってはコストに影響する場合があります。
一方、Anomaly Detectionは通常のアラート機能の一部として提供されているため、特別な契約は不要です。標準のNew Relicアカウントで利用できます。
まとめ
New RelicのAnomaly DetectionとPredictionsは、目的とアルゴリズムが大きく異なります。
Anomaly Detectionは標準偏差ベースで「今、異常か?」を判定し、突発的な変化の検知に優れています。PredictionsはHolt-Winters法で「未来に問題が起きるか?」を予測し、リソース枯渇のような緩やかに進行する問題の事前検知に強みがあります。
実務では監視対象の特性に応じた使い分けが重要です。ユーザー体験に直結する指標はAnomaly Detection、キャパシティプランニングはPredictionsというように、両方を組み合わせることで効果的な監視戦略を構築できます。
2025年にGAとなったPredictions機能により、New Relicはリアクティブな監視からプロアクティブな監視へと進化しました。ぜひ両機能を活用して、より安定したシステム運用を実現してください。
この記事がどなたかのお役に立てれば幸いです。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。 もしご興味をお持ちの方は、こちらのお問合せフォームよりお問合せ頂けましたら幸いでございます。
◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X(Twitter):@shioccii
◆ 過去記事はこちら
前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。