KPIの急変に気づく仕組み：異常検知とアラート通知の設計

KPIの急変に早く気づくには、ダッシュボードを毎日誰かが眺めることに頼らず、「どの指標を」「どの基準で」「誰に」「どの経路で」知らせるかを決めた自動のアラートを用意するのが基本です。基準は、固定の数値（閾値）、前週の同じ曜日との比較、過去の変動の幅から外れたかどうか、の三つを指標の性質に合わせて使い分けます。通知が多すぎると誰も見なくなり、少なすぎると見逃すため、通知の量と重要度の設計が成否を分けます。

もう一つの要点は、数字が急変したときに、それが事業上の本当の変化なのか、計測や集計の不具合なのかを素早く切り分けることです。KPIの急変の原因は、実際には計測タグの外れ、データ連携の停止、集計処理の失敗といった技術的な問題であることも少なくありません。切り分けの手順を決めておかないと、存在しない問題への対策に時間を使ったり、本当の問題を不具合と思い込んで放置したりします。

この記事は、事業のKPIを管理している事業責任者、企画・分析担当者、データの仕組みを担当している開発者に向けて書いています。KPIの異常検知の考え方、閾値の決め方、通知の設計、計測不具合との切り分け、運用の手順とよくある失敗までを解説します。

なぜKPIの急変に気づく仕組みが必要か

多くの組織では、KPIを週次や月次の会議で確認しています。この頻度では、数字に大きな変化が起きても、気づくのが数日から数週間後になります。その間に失われるものは小さくありません。

• 決済の画面に不具合があり、購入が完了しない状態が週末の間続いた
• 広告の設定ミスで、予算が想定より早く消化されてしまった
• 計測タグが外れて、数日分のデータが記録されていなかった
• 外部サービスの仕様変更で、データの連携が止まっていた
• 競合の動きや話題の広がりで、問い合わせが急に増えたのに対応が遅れた

いずれも、早く気づけば被害を小さくできたり、機会を逃さずに済んだりする出来事です。異常検知とは、こうした「いつもと違う」状態をデータから自動で見つける仕組みのことです。高度な統計の手法を使うものもありますが、事業のKPIであれば、単純なルールの組み合わせでも十分に役立ちます。

なお、サーバーの停止やエラーの増加といったシステムの異常を見つける仕組みについてはサービス監視とアラートの設計で扱っています。この記事では、売上、登録数、問い合わせ数、購入率など、事業の数字の異常に焦点を当てます。

監視するKPIを選ぶ

すべての指標に通知を設定すると、通知が多すぎて誰も見なくなります。監視する指標は、次の観点で絞ります。

• 変化に早く気づくことで、打てる手があるか：気づいても何もできない指標は、日々の監視には向きません
• 毎日、または毎時間の単位で十分な件数があるか：件数が少ない指標は、自然な揺れが大きく、異常かどうかの判断が難しくなります
• 事業への影響が大きいか：売上や登録など、止まると影響が大きい指標を優先します
• データの不具合を見つける役割があるか：計測の停止に最も早く気づける指標（ページの閲覧数など）も監視の対象にします

一般的には、次のような指標が監視の候補になります。

最後の「データの鮮度」は見落とされがちですが、非常に重要です。データの取り込みが止まると、ダッシュボードの数字は前日のまま更新されず、誰も異常に気づかないことがあります。

異常の基準を決める：三つの方法

「いつもと違う」と判断する基準には、主に三つの方法があります。

固定の閾値

最も単純で分かりやすい方法です。「決済の成功率が一定の水準を下回ったら」「データの取り込み件数がゼロになったら」「広告費の一日の消化が上限に達したら」のように、明確な基準がある指標に向いています。ただし、売上のように成長や季節で水準が変わる指標では、閾値を定期的に見直さないと、通知が鳴りっぱなしになったり、まったく鳴らなくなったりします。

前期間との比較

多くの事業の数字は、曜日によって大きく変わります。平日に多く週末に少ないサービスで前日と比較すると、毎週月曜日に「急増」、土曜日に「急減」の通知が出てしまいます。前週の同じ曜日と比べることで、曜日の影響を取り除けます。MoM・YoY（前月比・前年比）の考え方も同じで、比較の対象をそろえることが大切です。祝日や大型連休、セールの日などは、比較対象として特殊なので、例外として扱うか、カレンダーを参照して比較の対象を変えます。

過去の変動の幅

過去数週間の同じ曜日・同じ時間帯の値から、平均と揺れの大きさを計算し、そこから大きく外れたら通知する方法です。指標ごとに、普段どの程度揺れるかを考慮できるため、固定の閾値より誤った通知が少なくなります。表計算ソフトやSQLでも計算でき、BIツールや監視のサービスの中には、この種の判定を機能として持っているものもあります。

通知の設計：誰に、どの経路で、どの重要度で

異常を検知しても、適切な人に、適切な形で届かなければ意味がありません。通知の設計では、次の点を決めます。

重要度を分ける。 すべての通知を同じ扱いにすると、重要な通知が埋もれます。たとえば次のように分けます。

• 緊急：事業に大きな影響があり、すぐに対応が必要（決済の成功率の急低下、売上がゼロになったなど）
• 要確認：その日のうちに確認が必要（主要な指標が通常の範囲を外れたなど）
• 参考：会議で確認すればよい（緩やかな低下傾向など）

宛先と経路を決める。 緊急の通知は担当者の携帯に直接届く経路で、要確認の通知はチームのチャットの専用チャンネルに、参考の情報は週次のレポートにまとめる、というように、重要度に応じて経路を変えます。チャットの通知は便利ですが、雑談と同じチャンネルに流すと見落とされます。夜間や休日に緊急の通知を受ける体制を取るかどうかも、事業への影響の大きさと担当者の負担を比べて決めておきます。すべてを即時に対応する体制は長続きしないため、夜間は売上が止まるような事態だけに絞る、といった線引きが現実的です。

通知の文面に判断材料を入れる。 「売上が異常です」だけでは、受け取った人は何をすればよいか分かりません。指標の名前、現在の値、比較の基準の値、変化の大きさ、関連するダッシュボードへの案内、最初に確認すべきこと、を文面に含めます。

担当者を決める。 通知を受けたら誰が最初に確認するのかを決めておきます。チャンネルにいる全員が「誰かが見るだろう」と思っていると、誰も対応しません。曜日や時間帯で当番を決める方法もあります。

計測不具合との切り分け方

KPIの急変を検知したら、まず「本当に起きている変化か」を確かめます。次の手順で切り分けます。

1. データの鮮度を確認する：最終の更新時刻はいつか、取り込みの処理は正常に終わっているか
2. 別の情報源と照らし合わせる：分析ツールの数字と、業務システムのデータベースの数字（注文、登録など）を比べる
3. 影響の範囲を確認する：特定の端末、ブラウザ、流入経路、地域、画面だけで起きているか
4. 直近の変更を確認する：サイトやアプリのリリース、計測タグの変更、広告の設定変更、外部サービスの仕様変更がなかったか
5. 実際に操作してみる：該当する画面で購入や登録を試し、正常に完了するか、計測が記録されるかを確かめる
6. 結論を記録し、関係者に共有する：本当の変化か、計測の不具合か、原因と対応を書き残す

手順2が特に有効です。分析ツールでは注文が急減しているのに、データベースの注文の件数は普段どおり、ということであれば、計測の不具合の可能性が高くなります。逆に、データベースの件数も減っていれば、事業上の本当の変化か、サービスそのものの不具合です。

手順3で、特定の端末やブラウザだけで数字が落ちている場合は、その環境での画面の不具合や、計測タグの読み込みの失敗が疑われます。全体で落ちているなら、データ連携の停止や、集客の大きな変化が疑われます。

本当の変化だった場合の動き方

切り分けの結果、計測の不具合ではなく本当の変化だと分かったら、次は原因と対応を決めます。低下であれば、サービスの不具合（特定の画面でエラーが出ている、決済が通らないなど）、集客の変化（広告の停止、検索順位の変動、外部サイトからの紹介の終了など）、外部の要因（天候、競合の販促、社会的な出来事など）の順に確認すると、対応の早いものから潰していけます。

増加の場合も、喜ぶ前に確認が必要です。不正な登録や機械的なアクセスによる見かけの増加でないか、急な注目で在庫や対応の体制が足りなくなっていないかを確かめます。いずれの場合も、原因と対応を記録しておくと、次に同じことが起きたときの判断が速くなり、監視の基準を見直す材料にもなります。

計測が正しく記録されていることは、異常検知の前提です。記録する項目の設計についてはプロダクトのイベントログ設計を参考にしてください。

KPIの異常検知を導入する手順

異常検知の仕組みを作る流れは次のとおりです。

1. 監視する指標を、影響の大きさと件数の多さを基準に数個選ぶ
2. 各指標の過去数か月の推移を確認し、曜日や時間帯の変動、季節の影響を把握する
3. 指標ごとに、基準の方法（固定の閾値・前期間との比較・過去の変動の幅）を選び、最初の基準値を決める
4. 重要度、宛先、経路、通知の文面、最初に対応する担当者を決める
5. 過去のデータに当てはめて、どのくらいの頻度で通知が出るかを試算する
6. 実際に運用を始め、数週間は通知の量と的中の度合いを記録する
7. 誤った通知が多い指標は基準を緩め、見逃しがあった指標は基準を厳しくする
8. 切り分けの手順と、過去の通知とその原因の記録を共有の場所に残す

手順5の試算を省くと、運用を始めた初日から通知が大量に届き、すぐに無視されるようになります。過去のデータで「この基準だと月に何回鳴るか」を確かめてから始めると、適切な量に調整しやすくなります。

仕組みの作り方としては、BIツールの通知機能を使う、データウェアハウスで定期的に判定の処理を動かしてチャットに通知する、監視のサービスに事業の指標を送る、などの方法があります。定期的なレポートの自動配信と組み合わせることもできます。配信の仕組みは定例レポート作成を自動化するで解説しています。

架空の例：ECサイトの週末の購入率の低下

架空の例として、ECサイトを運営する会社を考えます。この会社は、週次の会議で購入率を確認していましたが、ある週の会議で、前の週末の購入率が大きく落ちていたことに気づきました。調べると、金曜日の夕方に行ったサイトの更新で、特定のスマートフォンのブラウザで購入ボタンが反応しなくなっていました。週末の間、その端末の利用者は購入できない状態が続いていたのです。

この会社は、購入率と決済の成功率を一時間ごとに前週の同じ曜日・時間帯と比較し、大きく下回ったらチームのチャットに通知する仕組みを作りました。あわせて、端末の種類ごとの購入率も監視の対象に加えました。また、通知を受けた当番が最初に、データベースの注文件数と照らし合わせ、該当する端末で実際に購入を試す、という切り分けの手順を決めました。

その後、別の更新で似た不具合が起きたときには、数時間のうちに通知が届き、すぐに修正できました。監視の仕組みと切り分けの手順をセットで用意したことで、被害を小さくできた例です。

KPI異常検知のチェックリスト

• 監視する指標を、影響の大きさと件数の多さで絞り込んでいるか
• データの鮮度（最終更新の時刻、取り込み件数）を監視しているか
• 指標ごとに、曜日や季節の変動を考慮した基準を選んでいるか
• 祝日やセールなど特殊な日の扱いを決めているか
• 通知を重要度で分け、経路を変えているか
• 通知の文面に、現在の値、比較の基準、確認すべきことが含まれているか
• 通知を最初に確認する担当者が決まっているか
• 計測不具合との切り分けの手順が文書になっているか
• 運用開始前に、過去のデータで通知の頻度を試算したか
• 通知とその原因の記録を残し、基準を定期的に見直しているか

よくある失敗とその避け方

通知が多すぎて無視される。 誤った通知が続くと、本当に重要な通知も見られなくなります。通知の量を記録し、誤った通知が多い指標は基準を見直すか、監視の対象から外します。通知の数は、少なく始めて必要に応じて増やす方が安全です。

前日比で判定する。 曜日の変動がある指標を前日と比べると、毎週決まった曜日に誤った通知が出ます。前週の同じ曜日と比べるか、過去の同じ曜日の変動の幅を使います。

監視の対象を後から増やし続ける。 一度見逃しがあるたびに監視の指標を足していくと、いつの間にか通知の数が管理できないほどに増えます。新しい指標を加えるときは、既存の指標で代わりにならないか、外せる指標はないかを同時に確認します。

増加を監視しない。 異常というと低下に目が向きがちですが、急な増加にも注意が必要です。不正な登録、計測の二重記録、広告費の暴走、急な注目による問い合わせの殺到など、増加にも対応が必要な事態があります。

通知の後の動きを決めていない。 通知が届いても、誰が何を確認するのかが決まっていなければ、対応が遅れます。担当者と切り分けの手順を、通知の仕組みと同時に決めます。

基準を一度決めたまま放置する。 事業の成長や季節の変化で、適切な基準は変わります。四半期に一度など、定期的に通知の記録を振り返り、基準を見直してください。

よくある質問

Q. 高度な統計や機械学習を使わないと、異常検知はできませんか？

事業のKPIであれば、固定の閾値と前週の同じ曜日との比較を組み合わせるだけでも、多くの異常に気づけます。高度な手法は、監視する指標が非常に多い場合や、季節の変動が複雑な場合に検討すれば十分です。まずは単純な方法で運用を始め、見逃しや誤った通知の傾向を見てから改善するのが現実的です。

Q. 件数の少ない指標はどう監視すればよいですか？

一日の件数が少ない指標は、自然な揺れが大きく、日単位の判定では誤った通知が多くなります。週単位にまとめて判定する、件数ではなく「一定期間ゼロが続いたら通知する」という形にする、関連する件数の多い指標で代わりに監視する、といった方法があります。

Q. 異常検知の仕組みを作るのに、専用のツールは必要ですか？

必須ではありません。BIツールやスプレッドシートの通知機能、データウェアハウスでの定期的な処理とチャットへの通知など、すでに使っている仕組みで始められることが多くあります。監視する指標や通知の量が増え、管理が難しくなってきた段階で、専用のツールを検討するとよいでしょう。

Otsumuに相談できること

KPIのデータが一か所に集まっていて、BIツールやチャットの通知機能を扱える担当者がいれば、この記事の手順で監視する指標を絞り、基準と通知を設計するところまでは、自社で十分に進められます。最初は売上とデータの鮮度の二つを監視するだけでも、気づくまでの時間は大きく変わります。

一方で、データが複数のシステムに散らばっていて同じ時間軸で比較できない、計測の不具合が頻繁に起きて数字が信用できない、通知を作ったものの量が多すぎて運用が回らない、といった状況では、データの整備と監視の設計を一緒に見直す必要があり、外部の力を借りた方が早いことがあります。

OtsumuはKPI改善コンサルティングとして、監視すべき指標の選定、基準の設計、計測不具合との切り分けの手順づくりまでを支援します。データの集約や自動の通知の仕組みが必要な場合は、ダッシュボード開発やAPI連携開発として、必要な範囲に絞って開発することもできます。支援の範囲は状況に応じて個別にお見積もりします。

どの指標をどう監視すればよいかの相談だけでもかまいません。まずは30分の無料相談で、現在の数字の確認方法をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01