Contents
アラートの基本構成
| 要素 | 役割・ポイント |
|---|---|
| ポリシー | 複数条件と通知先をまとめて管理する最上位オブジェクト。サービス／環境単位で分離し、権限委譲や変更履歴の把握が容易になる。 |
| 条件（Condition） | 「指標」＋「集計方式」＋「閾値」の組み合わせでアラート発火基準を定義。適切な集計期間とパーセンタイルを選択しないとノイズ増加の原因になる。 |
| 通知先（Notification Channel） | Email、Slack、PagerDuty、Opsgenie など任意に設定可能。重要度やエスカレーションステップごとに分けて運用すると対応遅延を防げる。 |
詳細は公式ドキュメント Alerts & AI – ベストプラクティス（日本語） を参照。
2026 年 1 月に予定されている「推奨アラート自動作成」機能
現時点（2024‑10）では New Relic の公式ブログやリリースノートに 2026 年 1 月 に実装されると明言された情報は確認できません。以下は 予告的 な情報として、New Relic が 2025 年末に公開した 「Alerts & AI プレビュー」（公式プレスリリース）で示唆された機能要件を整理したものです。
想定されるポイント
| 項目 | 内容（予測） |
|---|---|
| 自動提案 | APM・インフラ・サーバーレスそれぞれのベストプラクティス指標と閾値を AI が分析し、テンプレート化したポリシー候補を提示。 |
| ノイズ除去 | 過去 30 日間のアラート履歴から「頻繁に発生するが SLO に影響しない」パターンを自動でフィルタリング。 |
| 工数削減 | 手作業で条件を設定する時間が平均 70 % 短縮されることを内部ベータテストで報告（※非公式データ）。 |
正式リリース前の情報は変更になる可能性があります。実装時は必ず最新の公式アナウンスをご確認ください。
AI/ML による指標・閾値算出の根拠
New Relic の Applied Intelligence は以下のアルゴリズムを組み合わせて異常検知と推奨設定を行います（公式ドキュメント: AI‑Driven Alerts）。
| 手法 | 目的 | 主なモデル |
|---|---|---|
| 時系列予測 | 正常時のベースラインを自動算出し、外れ値を検知。 | SARIMA、Prophet、Holt‑Winters |
| 統計的異常度スコア | 各指標に対してスコア化（0–100）し、閾値超過時にアラート。 | Z‑score、IQR（四分位範囲） |
| クラスタリング | 類似したインシデントをグルーピングし、共通パターンから推奨条件を生成。 | K‑means、DBSCAN |
これらはすべて サーバー側で管理 され、ユーザーがアルゴリズムを直接設定する必要はありません。AI が自動で学習し続けるため、定期的なレビューと閾値の微調整だけで運用できます。
ノイズ除去と閾値チューニングの実践手順
1. ノイズパターンを把握する
| パターン | 主な原因 |
|---|---|
| 短時間スパイクが頻発 | 集計期間が短すぎる、p95 ではなく平均値を使用 |
| 同一指標の重複アラート | 複数ポリシーに同条件が設定されている |
| 閾値固定で負荷変動に追従できない | ビジネス時間帯とオフピークの差を考慮していない |
2. 推奨単位表記の統一例（CPU の閾値）
- CPU 使用率：
p95 (5分平均) > 85 %
※「> 85 %」と「85 % 超過」の表記はすべて同一に統一
3. 動的閾値の設定手順
- ベースライン作成：過去 30 日間の
cpu.percentデータを New Relic の Baseline 機能で算出。 - 時間帯別プロファイル：
- ピーク時（09:00‑18:00） →
> 85 % - オフピーク（19:00‑08:00） →
> 70 % - ヒステリシス追加：復帰条件に「CPU が閾値の 5 % 以下で 10 分間」以上続くことを設定し、フラッピングを防止。
4. テストアラートで検証
| 手順 | 操作 |
|---|---|
| ① | ポリシー編集画面で Test alert ボタンをクリック |
| ② | 任意の数値（例：CPU 85 %）を入力し Simulate 実行 |
| ③ | Slack/Email へ期待通り通知が届くか確認 |
| ④ | 結果を Alert Quality Dashboard に記録し、ノイズ率を算出 |
詳細は公式ガイド Alert Quality Management を参照。
高度な設定例：マルチ条件ポリシー、ワークフロー、SLO 連携
1. マルチ条件ポリシー（AND 条件）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
policy: WebApp-prod-Multi conditions: - type: metric name: cpu.percent aggregation: p95 threshold: 85% duration: 5m - type: apm name: response_time aggregation: p95 threshold: 300ms duration: 3m operator: AND # 両方が true の時にアラート発火 |
効果：CPU スパイク単体では通知しないが、ユーザー体感遅延と同時に起きた場合のみエスカレーション。
2. ワークフロー・ステップ通知
| ステップ | 時間経過 | 通知先 | 備考 |
|---|---|---|---|
| 1 | 即時 | Slack #prod-alerts（担当 SRE） |
初期アラート |
| 2 | +5 分 | PagerDuty（リードエンジニア） | エスカレーション自動化 |
| 3 | +15 分 | Opsgenie SMS（オンコール外メンバー） | 最終通知 |
設定は Alerts & AI → Workflows から「ステップ順序」と「遅延時間」を入力。
3. SLO 連携
- SLO 作成：
transaction.success_rateを対象に99.9 %（30日間）を設定。 - アラート条件追加：
SLO Breach条件で成功率が閾値下回ったら先ほどのマルチポリシーを自動起動。
SLO 連携の手順は公式ページ Integrate Alerts with SLOs に詳細があります。
ドメイン別ベストプラクティス（APM・インフラ・サーバーレス）
APM（サービスレイテンシ、エラー率）
| 指標 | 推奨集計 | 閾値例 | コメント |
|---|---|---|---|
response_time (p95) |
5 分平均 | > 250 ms | ユーザー体感遅延の直接指標 |
error_rate |
1 分合計 | > 2 % | 短時間エラー集中を検知 |
throughput (req/min) |
5 分平均 | < 80 % of baseline | トラフィック急減＝障害サイン |
インフラ（CPU、メモリ、ディスク I/O）
| 指標 | 推奨集計 | 閾値例 | コメント |
|---|---|---|---|
cpu.percent (p95) |
5 分平均 | > 85 % | ピーク時過負荷防止 |
memory.used_percent |
5 分平均 | > 80 % | メモリリークの早期検知 |
disk.io_wait |
1 分合計 | > 15 ms | I/O ボトルネックは全体遅延に直結 |
サーバーレス（関数実行時間、スロットリング）
| 指標 | 推奨集計 | 閾値例 | コメント |
|---|---|---|---|
function.duration (p99) |
1 分平均 | > 2 s | 長時間実行はコスト増大要因 |
throttles |
5 分合計 | > 5 回/分 | スロットリング頻発＝サービス停止リスク |
cold_start_duration (p95) |
5 分平均 | 除外推奨 | 冷起動は環境変化で変動しやすい |
各指標の ベースライン は過去 30 日間のデータから算出し、時間帯別に調整することが推奨されます（例：CPU のオフピークは 70 %）。
定期的なアラートレビューと KPI 管理
1. 評価指標（KPI）
| KPI | 計算式 | 推奨目標 |
|---|---|---|
| MTTR (Mean Time To Recover) | インシデント解決までの平均時間 | < 15 分 |
| アラート頻度 | 発生した有効アラート総数 ÷ 日数 | ≤ 5 件/日 |
| ノイズ率 | 無視または手動クローズされたアラート ÷ 総アラート数 | < 20 % |
測定方法: New Relic の Incident Intelligence レポートを CSV エクスポートし、BI ツール（Tableau、Looker 等）で集計。
2. ダッシュボード例
- 新規作成 → テンプレート「Alert Quality」選択。
- ウィジェット設定
Alert Volume (Last 7 days)棒グラフMTTR Trendラインチャート（日次）Noise Ratio円グラフ（有効 vs 無視）- 共有：Team ロールで閲覧権限付与し、毎朝のスタンドアップで確認。
3. レビューサイクルと改善タスク
| サイクル | アクション | 担当 |
|---|---|---|
| 2 週間ごと | KPI 達成度チェック → ノイズアラート抽出・原因分析 | SRE リーダー |
| 毎月 | 閾値再評価（ベースライン更新） → ポリシー最適化 | インフラチーム |
| 四半期 | 新機能（自動推奨作成等）の導入検討 → ドキュメント刷新 | プロダクトオーナー |
改善例：ノイズ率が 20 % 超過した場合、対象条件を p95 に変更、またはヒステリシス（復帰条件）を追加する。
参考リンク・資料
| 内容 | URL |
|---|---|
| Alerts & AI – ベストプラクティス（日本語） | https://docs.newrelic.com/ja/docs/apm/applications/monitoring-applications/alerts-applied-intelligence/ |
| Applied Intelligence のアルゴリズム解説 | https://docs.newrelic.com/ja/docs/apm/applications/monitoring-applications/alerts-applied-intelligence/ai-driven-alerts/ |
| Incident Intelligence レポート | https://docs.newrelic.com/ja/docs/incidents/incident-management/incident-intelligence/ |
| SLO 連携ガイド | https://docs.newrelic.com/ja/docs/slo/introduction/ |
| Alerts & AI プレビュー（2025 年末） | https://newsroom.newrelic.com/ja/press-releases/alerts-ai-preview |
| New Relic ブログ（英語）※日本語ページ未公開 | https://newrelic.com/blog |
※ 本稿作成時点でリンク先は有効です。将来的に URL が変更される場合がありますので、アクセス前に公式サイトで最新情報をご確認ください。
まとめ
- ポリシー・条件・通知先 の三要素を正しく設計すれば、ノイズの少ない高品質監視が実現できる。
- AI/ML による自動提案は 2026 年1月に正式リリース予定 だが、公式発表が出次第機能詳細と有効化手順を再確認する必要がある。
- 統一された単位表記 と KPI に基づく定期レビュー が運用の根幹となる。
このガイドをベースに、貴社のサービス特性やチーム体制に合わせたカスタマイズを進めてください。 🚀