「 が下がってることに、3 日後に気付いた」は遅すぎる。普段と違う数字をリアルタイムで検知する仕組みが要ります。本記事では の手法を 領域に絞って整理します。3σ から機械学習まで、段階的なアプローチ。
段階別アプローチ
| 手法 | 実装難度 | 向く KPI | 弱点 |
|---|---|---|---|
| 固定閾値 | 極低 | 明確な合格ライン（SLA） | 状況変化に追従しない |
| 3σ rule | 低 | 正規分布する KPI | 歪んだ分布で過剰検知 |
| IQR / MAD | 低 | 外れ値多めの KPI | 季節性に弱い |
| STL 分解 | 中 | 週次・年次の季節性あり | 実装が一段階増える |
| Prophet | 中 | ホリデー込みの季節性 | ライブラリ依存 |
| Isolation Forest | 中 | 多変量の異常 | 解釈性低 |
| オートエンコーダ | 高 | 複雑な時系列 | データ大量必要 |
実装の段階的アプローチ
- 1まず固定閾値で「明らかな異常」を捕捉。例：DAU < 1000 で発火
- 23σ で「いつもと違う」を捕捉。過去 30 日の平均 ±3σ を外れたら
- 3季節性が見えたら STL 分解：曜日依存を除いた残差で 3σ
- 4多変量で見たくなったら Isolation Forest：DAU ↓ + 課金 ↑ の組合せを異常検知
アラート疲れを防ぐ
「狼少年」化を避ける
毎日 10 件のアラートが来ると、誰も見なくなる。1 日 1〜2 件に絞り込み、本当に対処が必要なものだけ通知するのが鉄則。
- 抑制ルール：同じ異常を 24 時間以内に再通知しない
- 重要度別チャネル分け：CRITICAL は PagerDuty、WARN は Slack #alerts、INFO はダッシュボードのみ
- 自動鎮静：「リカバリ確認時に notify」ではなく、状態変化時のみ通知
- 月次レビュー：誤検知の多いアラートは閾値調整 or 廃止
ふくふくの進め方
「KPI 異常を早期検知したい」というご相談には、現状の閾値棚卸し（1 週間）→ 段階的アラート設計 → ダッシュボード組み込みを 1〜2 ヶ月で。 シリーズの手法を、KPI 領域に絞って実装します。
次回予告
EP.15 は KPI レビュー会の設計と運営。ダッシュボードを作っただけで終わらせない、組織への定着の話。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。