AIによる異常検知は、データから通常の振る舞いと異なる状態を見つけるために使います。時系列データなら、値の大きさだけでなく、時間帯や曜日などの変化を考慮する方法があります。
ただし、通常と違うことを検出しても、故障の原因や対応方法まで確定したとは限りません。業務で使うには、何を異常として調べ、誰が結果を確認するかまで決める必要があります。
固定のしきい値と、パターンからの逸脱を比べる
固定のしきい値は、あらかじめ決めた値を超えたかなどで判断します。一方、時系列の異常検知では、過去の変動から期待する範囲を作り、そこからの外れ方を見る方法があります。
具体例として、Amazon CloudWatchの異常検知は統計・機械学習を用い、指標の過去データから期待値の範囲を作ります。時間・日・週の周期や傾向を考慮する仕組みが説明されています。これは一つのサービスの方式で、すべての異常検知が同じ方法ではありません。出典：AWS CloudWatch anomaly detection
架空の受付件数を例にすると、昼間は多く夜間は少ない業務で、同じ件数でも時間帯によって意味が変わります。昼間の急減を調べたい場合、件数が一定以上かだけを見る監視とは、確認したいことが異なります。
最初に、検知した後の行動を決める
「異常を見つけたい」だけでは、評価基準を決めにくくなります。問い合わせの急増を見つけて要員を確認する、処理件数の急減から連携の失敗を調べるなど、検知後に何をするかを整理します。
異常検知の出力は、確認を始めるきっかけとして扱えます。急減が起きても、システム故障とは限らず、休日、業務の変更、データ取得の失敗かもしれません。指標の変化と原因の確定を分け、関連ログや業務状況を確認する手順を作ります。
人が確認する前にシステムを自動停止するような設計は、影響が大きくなります。最初の試行では通知・確認の範囲にとどめ、必要な判断と実行権限を整理する方法があります。
データの欠損と、本当のゼロを分ける
一定間隔で集める指標なら、取得時刻、集計単位、欠損の扱いを確認します。計測できなかった値をゼロとして扱うと、「業務が発生しなかった」のか「観測できなかった」のかを区別できません。
学習に使う期間も確認します。繁忙期、休業、計画停止、障害中の値が含まれる場合、通常状態として扱ってよいかを考えます。後からモデルを変更するなら、どの期間と設定で評価したかを残してください。
新しい業務や設備で、正常状態の変動を十分に観測できていない場合は、その限界を明記します。データが少ないまま、すべての故障を検知できると判断しないことが大切です。
誤報・見逃し・検知の遅れを分けて評価する
過去の記録と照合できるなら、検知した時刻と実際の事象を対応付けます。数値の点数だけでなく、必要な対応に間に合ったかを確認します。
| 評価の観点 | 確認する問い |
|---|---|
| 誤報 | 通知されたが調査不要だったのは、どの条件か |
| 見逃し | 確認すべき事象があったのに通知されなかったか |
| 遅れ | 通知時点で、必要な対応を始められたか |
| 調査負担 | 一件の通知を判断するために、どの情報と時間が必要か |
過去の故障記録自体が不完全なら、見逃し率を正確に計算できない場合があります。未記録の事象を推測で補わず、評価できた範囲を示します。
CloudWatchの資料では、異常検知のしきい値を大きくすると正常範囲の帯が広がると説明されています。許容範囲の調整で通知は変わるため、通知が少なくなったことだけを改善としないでください。出典：AWS
運用が変わったときの見直しを用意する
業務時間や処理量が変わった後も、以前と同じパターンが通常とは限りません。現場の変更情報と通知の傾向を合わせて確認し、データ・設定・判断手順のどこを見直すかを決めます。
固定しきい値で明確に定められる条件と、変動パターンを見たい条件を分ける方法もあります。AIだけへ置き換えることを目的にせず、検出したい問題に合わせて比較しましょう。
異常検知は、通知の後に調査と対応がつながって初めて業務で使えます。指標の選び方や運用への組み込みを整理したい場合は、テクノヴァースのAI活用の案内をご覧ください。