時系列データの異常検知は、手法を選ぶ前に「どの形の異常を拾いたいのか」を決める作業から始まります。瞬間的な跳ね上がりなのか、平常値そのものが別の水準へ移った瞬間なのか、数十分続くおかしな区間なのか。対象が変われば前処理もしきい値の引き方も別物です。この記事では、異常の三形態の切り分け、STL分解と再サンプリングという時系列固有の前処理、移動中央値・ESD検定・ホテリングT²で引くしきい値、Isolation Forestや再構成誤差型を持ち出す条件、ラベルが乏しい現場での評価、取り込みからアラートまでの経路設計と実装先の判断までを、実装の単位で組み立てます。
まとめ：時系列の異常検知で先に決める三つの判断軸と、統計だけで足りる境界
先に結論を置きます。判断軸は三つで、順に「拾いたい異常の形」「使えるラベルの量」「誤報を受け止める運用体制の規模」です。周期性が明確な監視メトリクスや設備の計測値であれば、STL分解で季節性とトレンドを落とし、残差に対して移動中央値と分位点でしきい値を引くところまでで実務の大半は動きます。
機械学習へ進む合図は、単変量のしきい値では拾えない「複数系列の関係が崩れる異常」が主目的になったときです。逆に、系列が数十本で周期が日単位、当番が平日日中のみという体制なら、深層学習モデルを持ち込むと再学習と監視の負荷だけが増えます。TSB-AD（NeurIPS 2024 Datasets and Benchmarks Track）でも、単純な統計手法が高度なニューラル構造を上回る場合が多いと報告されました。
評価では、時系列異常検知でよく使われるpoint-adjust方式のF1値を鵜呑みにしないでください。運用に入れる前に見るべき数字は、単位時間あたりの誤報件数と検知遅延の実測値です。
時系列に固有の異常の形｜点の外れ値・変化点・区間異常で分かれる検知設計
異常検知という言葉は、時系列に限っても三つの異なる問題を指します。ここを混ぜたまま手法比較を始めると、精度が出ない理由が最後まで分かりません。
点異常・変化点・区間異常の三形態｜検知したい対象で変わる手法選び
点異常は1時点だけが平常の範囲から外れた状態で、センサーの瞬断や計測ノイズが典型例です。変化点は、平均や分散といった分布の性質が別の水準へ移った時刻そのものを指します。区間異常（異常部位）は、個々の値が正常範囲に収まっているのに、形状として見ると平常のパターンから外れている数分から数十分の区間を指します。
| 異常の形 | 典型例 | 主な手法 | 拾えない異常 |
|---|---|---|---|
| 点異常 | センサー瞬断・スパイク | 移動中央値・ESD検定 | 緩やかな水準移動 |
| 変化点 | 設定変更後の水準移動 | CUSUM・ruptures | 単発のスパイク |
| 区間異常 | 振動波形の崩れ | 部分列距離・再構成誤差 | 単一時点のずれ |
実務でまず押さえるのは点異常と変化点の二つです。区間異常は波形データや設備振動の案件で必要ですが、監視メトリクスの用途では後回しで支障ありません。異常の定義そのものや製造業での導入判断は、異常検知の3類型と製造業での導入判断を整理した記事で扱っているため、本記事は時系列固有の実装に絞ります。
季節性とトレンドの分離｜STL分解の残差だけを判定に回す前処理
Webサービスのリクエスト数も工場の消費電力も、平日と休日、昼と夜で水準が数倍動きます。生の値にしきい値を引けば、毎朝の立ち上がりが全部アラートです。そこで statsmodels の STL で系列をトレンド・季節・残差の三成分へ分け、残差だけを異常判定へ回します。
STLを使うときの設定は二つだけ意識してください。周期の長さは、5分間隔で日周期なら288、1時間間隔で週周期なら168というように、データの取得間隔から逆算した点数で与えます。もう一つはロバスト推定の切り替えで、過去の異常が季節成分の推定を汚すのを避けたい場合に有効にします。分解を挟むだけで、しきい値を変えないまま誤報が数分の一に落ちる系列は珍しくありません。
欠測と時刻ずれの扱い｜再サンプリングが生む偽の異常を抑える手順
時系列の異常検知で最初に事故が起きるのは、モデルではなく再サンプリングの段です。欠測を0で埋めると、その0が最大の外れ値として検知されます。エッジ機器の時計がずれていれば、同じ現象が数分違う時刻に二重で現れます。
実装では、欠測を「値がない」まま保持し、判定側で欠測区間をスキップする作りにしてください。前方補完を使うなら、補完した点にフラグを立て、その区間のスコアはアラート対象から外します。欠測が常態化する屋外構造物の監視での運用は、土木のIoT予知保全で温度補正と警報設計まで扱っています。集約の基準は、取得側の時刻ではなく計測時刻です。補間方式の選び分けやタイムゾーンの扱いを含む前処理の全体像は、時系列データの前処理を工程順に整理した記事で扱っています。遅れて届くデータの待ち時間を決めずにストリーム処理へ進むと、集計途中の不完全なバケットが毎回異常として出続けます。
統計手法による実装｜移動中央値・季節調整残差・多変量スコアで引くしきい値
統計手法は説明可能性と運用コストの両面で有利です。しきい値の根拠を現場に説明できること、再学習の当番が不要になること。
移動平均と移動中央値の使い分け｜スパイクに引きずられない基準線
基準線に移動平均を使うと、直前のスパイクが平均を引き上げ、次に来た本物の異常を見逃します。移動中央値なら、窓の半分未満の外れ値には影響を受けません。ばらつきの尺度も標準偏差ではなく中央絶対偏差（MAD）を使い、正規分布に合わせる場合は1.4826倍して換算します。
実装の目安として、窓幅は検知したい異常の継続時間の3倍以上を取ります。5分続く異常を拾いたいなら15分から30分の窓です。窓が短すぎると異常自身が基準線を持ち上げ、長すぎると水準移動への追随が遅れます。
季節調整残差へのESD検定｜曜日周期を持つ指標のしきい値の決め方
残差の外れ値判定には、一般化ESD検定（Generalized Extreme Studentized Deviate）が扱いやすい選択です。あらかじめ「最大で何点まで異常とみなすか」の上限だけを与え、統計量の大きい順に検定を繰り返す仕組みのため、外れ値が複数あっても互いに隠し合いません。上限は観測点数の数％以内が実務的な出発点です。
季節性が二重（日周期と週周期が重なる）の場合は、STLで季節を落としてから中央値を基準に使うS-H-ESDの構成が安定します。予測モデルの残差を使う道もあり、その場合の枠組みは需要予測と同じです。予測器の選び方は時系列予測アルゴリズムの選び方と実装手順を扱った記事にまとめてあるため、残差ベースで組むならそちらの選定基準がそのまま使えます。
多変量監視のホテリングT²｜相関の崩れを一つのスコアで捉える設計
系列が増えると、個別にしきい値を引く方式は破綻します。10系列に3σを引けば、正常時の誤報も10倍です。ホテリングのT²統計量は、平常時の平均ベクトルと共分散行列から各時点のマハラノビス距離を求め、多変量の逸脱を単一のスコアへ落とします。判定は自由度が変数の数のカイ二乗分布で近似できるため、しきい値を確率で指定できます。
使えない条件も明確です。変数間に強い共線性があると共分散行列が不安定になり、スコアが跳ねます。変数が20を超えるあたりからは主成分分析で次元を落とすか、系列を機能単位（同じ設備・同じサービス）でグループに割ってから個別にT²を計算する構成へ切り替えてください。
機械学習を持ち出す条件｜Isolation Forestと再構成誤差型の費用対効果
機械学習を導入する理由は精度そのものではなく、「統計手法では表現できない正常のパターンがある」ことに限られます。
Isolation Forestの窓特徴量｜汚染率の設定と学習データの区切り
Isolation Forest は scikit-learn 1.9系（2026年8月23日時点のPyPI最新）に標準搭載されており、教師ラベルなしで動きます。ただし時系列をそのまま与えても時間の情報は使われません。スライディングウィンドウで平均・標準偏差・傾き・直近差分といった特徴量を作り、1行が1窓に対応する表形式へ変換してから学習させます。
contamination パラメータは「学習データに含まれる異常の割合」で、ここが実質的なしきい値です。既定の auto に任せず、平常期間だけを集めた学習データを用意したうえで0.001から0.01程度の小さな値を明示するほうが、運用時の誤報件数を見積もりやすくなります。学習データは異常が混ざっていない期間で区切り、設備更新やリリースを跨がないようにします。
再構成誤差型のオートエンコーダ｜必要データ量と学習コストの目安
LSTMや1次元畳み込みのオートエンコーダは、正常波形を圧縮して復元する訓練を行い、復元しきれない部分（再構成誤差）を異常度とみなします。区間異常や多変量の形状崩れを拾える一方、要求は重くなります。周期の異なるパターンを網羅するには少なくとも数十周期分の平常データが必要で、日周期なら数か月分が目安です。
加えて、再学習の当番が発生します。設備更新やサービス改修で正常の形が変われば、誤報が急増するためです。PyOD 3.6系のように時系列を含む61の検出器を揃えたライブラリもあり、実装自体は数行で済みます。労力が乗るのは学習ではなく、その後の再学習と検証の運用です。
TSB-ADの実測が示す序列｜統計手法が深層学習を上回る条件
TSB-AD（NeurIPS 2024 Datasets and Benchmarks Track）は、データセットを人手で精査し、統計手法・ニューラル手法・基盤モデルを同じ条件で比較したベンチマークです。報告された結論は、単純な構造や統計手法が高度なニューラル構造を上回る場合が多いというものでした。従来のベンチマークに含まれていた欠陥のあるデータセットと偏った評価指標が、序列を歪めていたためです。
ここから導ける実装方針を言い切ります。単変量で周期が明確な系列に深層学習を持ち込む判断は見送ってください。深層学習が正当化されるのは、多変量の形状異常を拾う必要があり、かつ平常データが数か月分そろい、再学習を回す担当を置ける場合だけです。三つのうち一つでも欠けるなら、統計手法で組んで運用を先に立ち上げるほうが投資対効果は高くなります。
ラベルが乏しい現場での評価｜point-adjustの罠と運用前に測る指標
現場のデータには、異常のラベルがほとんど付いていません。それでも運用判断はできます。評価設計の誤りだけは避けてください。
point-adjust評価が精度を過大に見せる仕組みと代替指標
時系列異常検知の論文で長く使われてきたpoint-adjustは、正解区間の中で1点でも検知できれば、その区間全体を正しく検知したとみなす計算方式です。この扱いのもとでは、ランダムに近い出力でも高いF1値が出てしまいます。実力を見誤る最大の原因がここにあります。
代わりに置く指標は二つです。一つは区間単位の適合率と再現率で、検知した区間と正解区間の重なり方をそのまま評価します。もう一つはしきい値に依存しないPR曲線下の面積で、しきい値を1点に固定せず、スコアの並び自体の良し悪しを見ます。運用判断ではさらに、後述する単位時間あたりの誤報件数を必ず併記してください。
検知遅延と誤報コストの換算｜現場が受け入れるアラート件数の上限
アラートは、対応する人の時間を消費します。1件の確認に平均10分かかり、担当が1日あたり異常対応に割ける時間が60分なら、受け入れ可能な上限は1日6件です。この上限を先に決め、しきい値をそこから逆算します。精度の目標値を先に置く進め方は、現場の体制と噛み合いません。
検知遅延も同時に決めます。設備停止を防ぐ用途なら、発生から検知までの許容は分単位です。月次のデータ品質チェックなら日単位で足ります。許容遅延が日単位であれば、ストリーム処理は不要で、日次バッチで十分に成立します。
ラベルなしで始める運用｜再現テストと現場フィードバックの回収設計
ラベルが無い状態での立ち上げは、過去データでの再現テストから入ります。過去半年分に検知器を流し、出力されたアラートの件数と時刻を現場の担当者に見せて、心当たりのある事象と照合します。この照合作業そのものが最初のラベル生成です。
本番投入後は、アラートごとに「対応が必要だったか」を1クリックで記録できる導線を作り込んでください。この記録が3か月たまれば、しきい値の再設定と手法の入れ替えを実データで判断できます。たまったラベルを教師ありの判定へ回す場合に必要な件数は、Amazon Fraud Detectorの学習データ要件と代替3系統が下限と推奨値の両方を示しています。フィードバックの回収経路を作らないまま運用に入ると、誤報が多いという印象だけが残り、半年後に検知器が止められます。
取り込みからアラートまでの経路｜監視メトリクスとIoTセンサーの違い
検知アルゴリズムが同じでも、監視メトリクスとIoTセンサーでは前後の経路が別物で、取り込み側の制約が使える手法をほぼ決めます。
監視メトリクスの経路｜PromQLでの帯計算とCloudWatchの学習期間
サーバやアプリケーションのメトリクスは、すでに収集基盤が存在する前提で考えます。PromQLだけで期待範囲の帯を作れるため、外部に検知器を建てる必要はありません。中央値を quantile_over_time で、ばらつきを stddev_over_time で計算し、中央値に倍率を掛けた標準偏差を加減して上下限とします。下限が負になる指標には clamp_min を挟んで0で止めます。
マネージド側を使う場合、Amazon CloudWatch の異常検知は最大2週間分のメトリクスで学習し、時・日・週の周期とトレンドを考慮します（AWS公式ドキュメント・2026年8月23日確認）。しきい値として与える数値を大きくすると帯が太くなり、誤報が減る代わりに小さな逸脱を逃します。デプロイなど平常でない期間を学習から除外する設定もあるため、リリース直後の異常値を平常として覚え込ませない運用が可能です。
IoTセンサーの経路｜エッジでの間引きと時系列DBへの保存設計
設備計測では、収集そのものを設計する必要があります。1kHzで振動を測る用途なら、生波形をすべてクラウドへ送る構成は帯域と保管費で破綻します。エッジ側で実効値や周波数帯ごとのエネルギーへ集約し、異常の兆候が出たときだけ生波形を短時間だけ送る、という二段構成が現実解です。
保存先は、追記中心で期間走査が主体という性質から時系列データベースが噛み合います。保持ポリシーとダウンサンプリングの段をどう決めるか、製品をどう選ぶかは時系列データベースの圧縮・保持設計と製品選定を扱った記事で整理しました。検知器は、生データではなくダウンサンプリング後の系列を読む設計にしておくと、再学習や再現テストの実行時間が桁で変わります。
アラート運用の設計｜連続違反の待機時間と抑制で誤報を減らす手順
スコアがしきい値を超えた瞬間に通知を飛ばす作りは、必ず失敗します。単発の逸脱を除き、継続を条件に加えるだけで誤報は大きく減ります。実装の順序は次のとおりです。
- スコア計算と通知判定を分離し、スコアは常時記録する
- しきい値超過が指定時間続いた場合のみ発火させる（Prometheusなら for 句）
- 同一系列の再通知を一定時間抑制し、連投を止める
- 関連する系列のアラートを1件へまとめてから通知する
- 発火と解消の履歴を残し、月次で件数と対応要否を集計する
2番目の待機時間は、許容できる検知遅延の半分を目安にします。分単位の検知が要る設備なら1分から2分、日単位で足りる指標なら1時間でも支障ありません。5番目の集計を仕組みに入れておくと、しきい値の見直しが感覚論になりません。
内製と外部委託の分岐｜マネージド終了後に残る実装先と契約時の確認項目
実装先の前提は、ここ数年で変わりました。既製のマネージド異常検知に全面依存する構成は、提供終了の影響を正面から受けます。
マネージド異常検知の縮退｜2025年10月の終了が示した依存の危うさ
Amazon Lookout for Metrics は2025年10月10日にサポートが終了し、それに先立って新規受付も停止されました。AWSは移行先として、Amazon CloudWatch、Amazon Redshift ML、Amazon QuickSight、AWS Glue Data Quality と、検索分析基盤のマネージドサービスという5つの汎用サービス群を案内しています（AWS公式ブログ・2026年8月23日確認）。単機能の異常検知サービスが畳まれ、既存の監視基盤やデータウェアハウスの機能として吸収された、という流れです。
この教訓を設計へ落とすなら、検知ロジックを特定サービスのAPIに閉じ込めず、スコア計算・しきい値判定・通知を分離しておくことに尽きます。データウェアハウス側の機能で組む選択肢もあり、たとえばSQLだけで異常検知を実装するSnowflakeのML関数を扱った記事の構成なら、すでに置いてあるデータの上で完結します。
自前実装を見送る三つの条件｜系列数・保持期間・当番体制で引く線
自前で検知基盤を組む判断を見送るべき条件を、条件付きで言い切ります。次のいずれかに当てはまるなら、既存の監視基盤の機能で組むか、外部へ委託してください。
- 監視対象の系列が100本未満で、周期が日単位に収まっている
- データの保持が3か月未満で、再現テストに使える履歴が足りない
- 再学習とチューニングを担当できる人員が実質0.2人月未満しか取れない
逆に、系列が千本規模で、設備固有の判定ロジックが必要で、保持期間が年単位ある場合は、自前実装の投資が回収できます。境界は精度ではなく運用負荷にあります。
委託先に確認する項目｜評価指標・再学習頻度・引き渡し形態の明示
委託する場合、見積書と提案書で確認する項目は次の三つです。第一に評価指標の定義で、point-adjust方式のF1値だけを提示している提案は、実力を過大に見せている可能性があります。区間単位の指標と、単位時間あたりの誤報件数の見込みを必ず求めてください。
第二に再学習の頻度と担当の所在で、モデルが劣化したときに誰がどの手順で再学習するかを契約に書き込みます。第三に引き渡し形態で、学習済みモデルだけでなく、特徴量の生成コードと前処理の設定値まで受け取れるかを確認してください。要件整理の段階から相談したい場合は、データ分析基盤構築・MLOps構築支援で、取り込み経路の設計から検知器の運用まで一括で扱っています。
よくある質問
時系列データの異常検知を実装する現場から実際に出る質問を、判断の基準とあわせて整理します。
時系列データの異常検知は統計だけで足りますか？
単変量で周期が明確な系列であれば、STL分解とESD検定、あるいは移動中央値とMADの組み合わせで実務は成立します。統計だけで足りなくなるのは、複数系列の関係が崩れる異常や、値ではなく形状が崩れる区間異常を主目的にしたときです。まず統計で立ち上げ、拾えない異常が具体的に挙がってから機械学習へ進む順序を推奨します。
学習に必要な履歴はどのくらい必要ですか？
統計手法なら、季節周期の5倍から10倍が目安です。日周期なら1〜2週間分で動きます。参考として、Amazon CloudWatch の異常検知は最大2週間分のメトリクスで学習する設計になっています。一方、オートエンコーダなど再構成誤差型を使う場合は、平常のバリエーションを網羅する必要があるため、日周期で数か月分が現実的な下限です。履歴が足りない段階では、モデルを重くするより、しきい値を緩めに置いて誤報を抑えるほうが立ち上がりが早くなります。
異常のラベルが1件もない場合はどう評価しますか？
過去データへの再現テストで代替します。過去半年分に検知器を流し、出力されたアラートの時刻を現場の担当者と照合すると、心当たりのある事象がラベルとして回収できます。同時に、単位時間あたりの誤報件数という運用側の指標を主軸に置いてください。精度指標の目標値を先に置く進め方は、ラベルが無い現場では機能しません。
変化点検知と異常検知はどう使い分けますか？
拾いたい対象で分かれます。変化点検知は、平均や分散といった分布の性質が別の水準へ移った時刻そのものを見つける手法で、設定変更後の水準移動やセンサーの校正ずれを拾います。点異常の検知はスパイクを拾いますが、緩やかな水準移動は拾えません。オフラインで過去データを区切る用途なら ruptures 1.1系（2026年8月23日時点）が扱いやすく、オンラインで逐次判定するならCUSUMやSDARベースの手法が向きます。
リアルタイム検知と日次バッチはどちらから始めるべきですか？
許容できる検知遅延で決まります。設備停止の回避のように分単位の対応が要る用途以外は、日次バッチから始めてください。バッチであれば、再現テストとしきい値の調整を同じコードで回せるため、立ち上げの速度が段違いになります。ストリーム処理は、遅れて届くデータの待ち時間・状態管理・再処理の設計が加わり、実装量が数倍に膨らみます。日次で運用を確立し、遅延が業務上の損失に直結すると分かった系列だけをリアルタイム化する順序が安全です。
関連記事
- Prophet（Meta）とは｜時系列予測ライブラリの仕組み・使い方と2026年の開発状況：予測残差ベースで異常検知を組む場合の予測器の候補として
- InfluxDBとは？時系列DBの仕組み・InfluxDB 3の設計から採用判断まで実装者向けに解説：検知対象の系列を保存する製品を個別に検討する場合に
- 時系列とは？意味と分析手法の使い分け｜ARIMAからPython実装まで：季節調整やARIMAなど、前処理の土台になる分析手法の整理
- 予知保全とは？仕組みと予防保全との違いから費用対効果・導入判断まで解説：設備の異常検知を予知保全の投資判断として捉え直す場合に
