時系列データの前処理7STEP｜精度を落とす失敗例6選も解説

時系列データは、売上や設備の稼働状況、Webサイトのアクセスログなど、あらゆる現場で日々蓄積されています。ところが、そのまま予測モデルや異常検知に投入しても、期待した精度が出ないことは珍しくありません。原因の多くはモデルの選び方ではなく、前処理の設計にあるのです。最初に手を入れるべき箇所を、本記事で順に整理していきます。

前処理という言葉からは、欠測値を埋める作業だけを思い浮かべがちです。実際の範囲はもっと広く、時刻表現の統一から特徴量の生成までを含みます。本記事のゴールは、自社のデータに対してどの処理をどの順番で適用するかを、読者自身が判断できる状態です。

解説する7つの手順は、いずれも特別なツールを必要としません。pandasやSQLなど、手元にある環境でそのまま試せる内容にそろえました。精度を落とす失敗例6選もあわせて紹介しますので、自社の進め方と照らし合わせながら読み進めてください。

時系列データの前処理とは

時系列データの前処理は、分析やモデリングの前段にある準備作業の総称です。どこまでを前処理と呼ぶのか、通常のデータ処理と何が違うのかを整理しておくと、後続の手順が理解しやすくなります。ここでは範囲の定義、時系列特有の性質、データクレンジングとの違いの3点を順に確認します。

前処理が指す範囲：品質の担保から分析用データへの加工まで

前処理の範囲は、大きく2つに分けて考えると整理しやすくなります。1つ目は品質の担保で、欠測や重複、明らかな入力誤りといった不備を取り除く作業が該当します。2つ目は分析用データへの加工であり、集計単位の変更や定常化、特徴量の作成などが含まれるのです。前者だけで終えてしまうと、データは正しくてもモデルが学習しにくい形のまま残ります。範囲を2段構えで捉えることが、手戻りを減らす最初の分かれ目です。この2段構えをチーム内で共有しておくことが、認識ずれを防ぐ近道です。

実務では、どこまでを前処理として扱うかをチームで先に決めておく必要があります。判断基準はシンプルで、そのデータを別の分析でも使い回すかどうかで線を引きます。共通で使う品質担保の処理はデータ基盤側に寄せ、モデル固有の変換はパイプラインの中に置くのが定石です。ここを曖昧にしたまま進めると、同じ補完処理が3か所に散らばり、修正のたびに全箇所を追う羽目になります。データ品質の考え方は次の記事で詳しく整理しています。

データ品質とは？品質評価項目や品質を向上させるための実務的対策を解説

時系列データ特有の3つの性質：時間依存性・季節性・不等間隔

時系列データが他のデータと決定的に違うのは、行の順序そのものが情報を持つ点です。顧客マスタであれば行を入れ替えても内容は変わりませんが、時系列では順序が崩れた瞬間に意味が失われます。並べ替えやランダムサンプリングを安易に行えない理由がここにあるのです。設計時には、次の3つの性質に分解して押さえておくと判断を誤りにくくなります。いずれも、後続の手順で処理内容を決める際の前提となる考え方です。3つの性質は、この後に続くすべての手順の判断に影響します。

• 時間依存性：直前の値が次の値に影響し、行同士が独立していない
• 季節性：曜日や月、四半期など、一定の周期で繰り返す変動が乗る
• 不等間隔：観測が等間隔に並ばず、欠測や不定期な記録が混ざる

3つの性質のうち、実務で最も見落とされやすいのが不等間隔です。センサーやアプリのログは、イベントが発生したときだけ記録される仕組みが多く、行間の時間差がばらつきます。この状態のまま移動平均を計算すると、窓の中に入る件数が期間ごとに変わり、値の意味が壊れてしまうのです。等間隔かどうかは、隣接する行の時刻差の分布を見れば数分で確認できます。pandasであればdiff関数で時刻差を取り、value_countsで分布を眺めるだけで十分に判断できます。周期性そのものを確かめたい場合は、コレログラムを描くのが早道です。

コレログラムとは？データの周期性を掴むグラフをわかりやすく解説

データクレンジングとの違い：不備の解消とモデル投入前の変換

データクレンジングと前処理は混同されがちですが、目的の置き場所が異なります。クレンジングが目指すのは、事実として誤っている値をあるべき姿に戻すことです。表記ゆれの統一や、ありえない負の売上の除去などがこれにあたります。対して前処理は、値が正しいことを前提に、モデルが扱いやすい形へ変換する作業を含むのです。定常化やスケーリングは元の値を意図的に変えているため、クレンジングとは呼びません。この違いを押さえておくと、担当範囲の線引きも明確になるのです。

境界に迷ったときは、その処理を止めても業務が回るかどうかで切り分けます。表記ゆれを放置すると請求や在庫の管理まで狂うため、これはクレンジングの領域です。一方でラグ特徴量を作らなくても業務は回り、困るのはモデルだけになります。この線引きができていると、データ基盤チームと分析チームの担当範囲も自然に決まるのです。迷った場合は、業務側の担当者に1つ確認するだけで判断がつきます。クレンジングの代表的な手法は次の記事にまとめています。

データクレンジングとは？意味と代表手法を解説！

時系列データに前処理が求められる理由

前処理を省いたまま分析に進むと、どこかの工程で必ずひずみが表面化します。集計値のずれ、モデルの不安定さ、誤った相関の読み取りなど、症状はさまざまです。ここでは、現場で頻出する4つの理由を、実際に起きる不具合とあわせて確認します。

時刻の粒度やタイムゾーンが揃わず、集計値がずれる

複数のシステムからデータを集めると、時刻の表現が一致していない状態がほとんどです。基幹システムは日本時間、SaaSのAPIはUTC、ログ基盤はエポック秒といった具合に分かれます。この状態で日次集計をかけると、UTC基準のデータだけが9時間ずれ、月末月初の売上が隣の月に流れてしまうのです。1日ずれた集計値は、月次の合計だけを見ていても発見できません。日別の折れ線を並べ、境界日の値が不自然に凹んでいないかを目視するのが確実な確認方法です。

対処の手順は決まっています。取り込み時点で全ての時刻をUTCに正規化し、集計の直前に業務側のタイムゾーンへ変換する2段構えにします。pandasであればtz_localizeで元のタイムゾーンを明示し、tz_convertで変換する流れです。つまずきやすいのは、タイムゾーン情報を持たないnaiveな日時と、持っているawareな日時が混在したまま結合するケースになります。結合前に型を確認し、両者をそろえてから処理を進めてください。

欠測や重複がモデルの学習を不安定にする

欠測と重複は、単純にデータが増減するだけの問題ではありません。時系列モデルは直前の値を手がかりに次の値を予測するため、1行の欠落が以降の予測全体に波及します。重複も同様に厄介で、同じ時刻の売上が2行入っていれば、その時点だけ実績が2倍に膨らむのです。学習データにこうした行が数十件混ざるだけで、モデルは実在しない急変動を学習してしまいます。結果として、予測値が実績から乖離する原因の特定にも時間がかかるのです。

影響の大きさは、欠測率と欠測の並び方で判断が変わります。全体の1〜2%が散発的に欠けている程度であれば、補完で吸収できる範囲です。一方で30日連続の欠測があるなら、補完よりも学習期間から除外する判断が現実的になります。目安として、連続欠測が予測したい期間の長さを超える場合は補完を諦めます。欠測がどこに固まっているかは、月別の欠測件数を棒グラフにすると一目で分かるのです。重複については、時刻と系列IDの組み合わせで一意性を確認し、件数を数えるところから始めてください。

非定常なまま扱うと、見かけ上の相関を読み取ってしまう

平均や分散が時間とともに変わる系列を非定常と呼びます。右肩上がりの傾向を持つ2つの系列を並べると、中身に関係がなくても相関係数が0.9を超えることは珍しくありません。アイスクリームの売上と熱中症の搬送者数のように、季節という共通要因が背後にあるだけの組み合わせです。この見せかけの回帰に気づかないまま施策を組むと、期待した効果は出ないままになります。相関の強さだけを根拠にするのは危険なのです。相関係数の大きさは、系列の性質を確かめたうえで解釈すべき指標です。

対処は難しくありません。差分を取る、対数変換を挟む、季節成分を除去するといった処理で、系列を定常に近づけます。定常性の確認にはADF検定がよく使われ、statsmodelsのadfuller関数で数行のコードから実行できるのです。検定の結果よりも、まず原系列と差分系列の折れ線を並べて見比べる手順を勧めます。目視で水準が動いていないかを確かめてから検定に進むと、解釈を誤りにくくなるはずです。相関分析そのものの考え方は次の記事が参考になります。

相関分析とは？分析初心者でもわかる解説とExcelでのやり方を紹介

収集元が複数に分かれるほどデータに不備が生じやすい

収集元が3つを超えたあたりから、不備の種類は一気に増えます。項目名の違い、単位の違い、更新頻度の違いが掛け合わさり、突き合わせのたびに例外処理が積み上がるのです。売上を例にすると、POSは税込、基幹は税抜、ECは送料込みといった具合に定義が分かれます。同じ指標名でも中身が違うため、単純に足し合わせた時点で数値の意味は失われてしまいます。統合の前に定義をそろえる作業が必要です。統合の設計に入る前に、必ず定義の突き合わせを済ませてください。

実務での回避策は、統合前に項目定義の一覧を作ることに尽きます。列名、単位、タイムゾーン、更新頻度、粒度の5項目を並べた表を作り、収集元ごとに埋めていきます。作成にかかる工数は、収集元が5つ程度なら半日から1日が目安です。この表がないまま結合を進めた案件では、原因不明の数値差異の調査に数週間を費やす例も見てきました。表の作成は面倒に見えても、後工程の調査時間を大きく削る投資です。データ統合の進め方は次の記事で解説しています。

データ統合とは？統合の目的や初心者向けの進め方を解説

前処理によって解決できること

前処理は地味な工程ですが、投じた工数に見合うだけの効果が明確に返ってきます。予測精度の安定、誤検知の削減、再現性の向上、そして問い合わせ対応の軽減です。ここでは4つの効果を、投資判断の材料になる形で具体的に見ていきます。

予測精度のばらつきを抑え、モデルの比較が可能になる

モデルAとモデルBのどちらが優れているかを判断するには、入力側の条件をそろえる前提が必要です。前処理がばらついていると、精度差がモデル由来なのか前処理由来なのかを切り分けられません。補完方法を線形補間から前値補完に変えただけで、平均絶対誤差が10%前後動く例も珍しくありません。この状態で複数の手法を比較しても、得られる結論は運任せになるのです。比較の土台をそろえる作業こそが前処理の役割になります。土台がそろって初めて、手法の優劣を語れる状態です。

前処理を固定したうえで比較すると、評価の議論が具体的になります。実案件では、同じ前処理の流れに対して統計モデルと勾配ブースティングを並べ、検証期間を3分割して平均精度を比べる進め方をとります。3分割それぞれで順位が入れ替わるようなら、差は誤差の範囲だと判断できるのです。逆に全期間で同じモデルが勝つなら、採用の根拠として十分な材料になります。3分割の結果を1枚の表にまとめておくと、社内の合意形成も早く進むのです。売上予測の精度を上げる観点は次の記事も参考になります。

店舗開発における売上予測とは？精度を上げるポイントを徹底解説

異常検知における誤検知と見逃しを減らせる

異常検知の現場で最も多い不満は、アラートが鳴りすぎて誰も見なくなる状態です。原因の多くは、曜日変動や月末処理といった正常な周期変動を異常として拾ってしまう点です。曜日成分を除去してから閾値を設定するだけで、誤検知は目に見えて減ります。ある製造業の設備監視では、この処理を入れた前後で1日あたりのアラート件数が40件から8件まで落ちました。見逃しの件数は変わらないままです。周期成分の除去は、閾値の調整より先に着手します。

閾値の決め方にも判断基準を持たせます。分布が正規に近ければ平均から標準偏差3つ分、裾が重ければ四分位範囲の1.5倍を使う切り分けが実用的です。加えて、異常と判定する条件を3点連続での閾値超過とすると、単発のノイズによる誤検知をさらに抑えられます。運用開始から2週間は閾値を仮置きし、現場のフィードバックを見ながら調整してください。数字を眺めるだけでなく、現場の感覚と突き合わせる工程が効きます。閾値は一度決めて終わりではなく、四半期ごとに見直す運用が現実的です。

分析結果の再現性と説明可能性が高まる

同じデータと同じコードから同じ結果が出ることを、再現性と呼びます。時系列分析では実行するたびに数値が変わる状況が起きやすく、原因は前処理の非決定性にあることがほとんどです。並び順が保証されていないSQLの結果に対して前値補完をかければ、補完後の値は実行のたびに変わります。ORDER BYを明示するだけで防げる不具合ですが、見つけるまでに数日かかる例も少なくありません。再現性の欠如は、分析そのものへの信頼を損なうのです。

説明可能性の面でも効果があります。役員から数値の作り方を問われた際、前処理の手順が文書化されていれば、その場で経路を説明できるのです。手順書には、処理の順序、使用した関数、パラメータの値、除外した期間とその理由の4点を残します。分量はA4で2〜3ページに収まり、作成にかかる時間も半日程度です。この記録が、監査対応や担当者の引き継ぎでそのまま使えます。引き継ぎ時に説明へ費やす時間も、半分以下に収まるはずです。

ダッシュボードの数値差異に関する問い合わせを減らせる

ダッシュボードを公開すると、経理の資料と数字が合わないという問い合わせが必ず届きます。原因を追うと、集計の締め時刻がずれている、除外条件が違う、タイムゾーンが揃っていないの3つに集約されるのです。いずれも前処理の段階で解消できる内容であり、可視化ツール側の設定では対処しきれません。問い合わせ1件あたりの調査工数は、経験上2〜4時間かかります。月に10件届けば、担当者の稼働は無視できない規模です。問い合わせ対応は、担当者の集中を最も削る作業になります。

前処理の段階で定義をそろえておくと、この問い合わせは大幅に減ります。有効な打ち手は、集計対象期間と除外条件をダッシュボード上に常時表示することです。表示内容は前処理の設定ファイルから自動生成し、手作業での更新を挟まない設計にします。実際にこの仕組みを入れた企業では、数値差異に関する問い合わせが月12件から月2件まで減りました。浮いた時間は、分析そのものに回せるのです。定義を先に固めるだけで、問い合わせの総量は目に見えて下がります。

時系列データの前処理の進め方7STEP

ここからは、実際の作業手順を7つのステップに分けて解説します。順序には理由があり、入れ替えると後工程で手戻りが発生する箇所も含まれています。全体像を把握したうえで、自社のデータがどの段階でつまずいているかを確認してください。

STEP1：データ構造と時間軸の把握

最初に行うのは、データの棚卸しです。確認すべき項目は決まっており、時刻列の型、時刻の最小値と最大値、レコード件数、系列の数、そして時刻差の分布の5点になります。pandasであればinfo関数とdescribe関数で大半が把握でき、所要時間は10分程度です。ここで得た数値が、以降の手順すべての判断材料になります。面倒に感じても省略しないでください。棚卸しを飛ばした案件ほど、後工程でのやり直しが増えます。

見落とされやすいのが、時刻列が文字列型のまま格納されているケースです。2026/03/01 09時00分のような表記は一見すると日時ですが、型としては文字列であり、大小比較が辞書順になります。この状態で期間フィルタをかけると、意図しない行が抜け落ちるのです。読み込み直後にto_datetime関数で変換し、型がdatetime64であることを必ず確認します。あわせて、時刻の最小値が1970年になっている行がないかも見ておきます。

STEP2：時刻表現の標準化：タイムゾーン・書式・粒度の統一

時刻表現の標準化は、後続のすべての処理の土台になります。作業は3つに分かれ、タイムゾーンの統一、書式の統一、粒度の統一の順に進めるのが基本です。粒度とは、秒単位か分単位か日単位かという記録の細かさを指します。粒度が混在した系列をそのまま集計すると、細かい系列だけが件数として重く扱われてしまうのです。標準化を先に済ませておけば、この歪みは発生しません。土台づくりに1日かけても、後工程で数日分の手戻りを防げるはずです。

実務の手順は次のとおりです。取り込み時にUTCへ変換し、内部処理は一貫してUTCで行い、出力の直前に日本時間へ戻します。タイムゾーンの変換点を入口と出口の2か所だけに限定すると、事故はほぼ起きなくなります。夏時間を持つ国のデータを扱う場合は、pytzやzoneinfoを使い、固定オフセットでの加算は避けてください。9時間を足すだけの実装は、海外拠点のデータが加わった瞬間に破綻します。変換点を増やさない設計が、運用時の安心につながるのです。

STEP3：等間隔化とリサンプリング：集計単位の決定

不等間隔のままでは扱えない処理が多いため、ここでリサンプリングを行います。集計単位の決め方には基準があり、予測したい期間の10分の1から20分の1程度の粒度を選ぶと扱いやすくなるのです。1か月先を日単位で予測するなら、元データは日次か時間単位に集約します。細かすぎる粒度はノイズを拾い、粗すぎる粒度は変化を見逃す結果になります。業務上の意思決定の周期に合わせるのも有効な考え方です。粒度の決定は、後から変更すると全処理をやり直す作業になります。

pandasのresample関数を使えば、1行で等間隔化できます。集約方法は指標の性質で選び、売上のような加算できる値はsum、在庫や気温のような状態量はmeanかlastを使うのが原則です。ここでのつまずきは、集約後に生まれる空の区間をどう扱うかという点になります。元から観測がなかった区間と、観測があったはずなのに欠けている区間は意味が違うのです。前者は0、後者は欠測として区別し、フラグ列を1つ足して記録しておきます。

STEP4：重複レコードの整理と系列単位の名寄せ

重複の判定は、時刻だけでは足りません。系列IDと時刻の組み合わせで一意になるかを確認し、重複があれば残す1行を決める基準を定めます。基準は3つから選ぶことになり、更新日時が最新の行を残す、値が大きい行を残す、複数行を合算するのいずれかです。売上のような加算値なら合算、在庫のような状態量なら最新を残す判断が自然になります。基準を決めずに機械的な削除を行うと、必要な行まで落としてしまうのです。決めた基準は、設計書に1行で書き残しておきます。

系列単位の名寄せは、店舗コードや設備IDの表記ゆれを吸収する作業です。全角と半角、前ゼロの有無、旧コードと新コードの併存が典型的なつまずきになります。対応表を1枚用意し、正規化後のコードへ変換する処理を流れの先頭に置きます。対応表の作成には、拠点が50程度であれば1〜2日、数百規模になると1週間ほどを見込んでおくと安全です。対応表は台帳として管理し、変更履歴を残す運用にします。名寄せの実務的な進め方は、次の記事で詳しく解説しています。

名寄せとは？正確な顧客データ管理の方法と活用ポイントを徹底解説

STEP5：欠測値の補完：補完方法の選択基準

補完方法は、系列の性質と欠測の長さで決まります。短い欠測には前進補完（forward fill）が扱いやすく、直前の値をそのまま延ばす方式です。滑らかに変化する気温やセンサー値には線形補間が向き、季節性が強い需要データには同一曜日の値を使う方法が適しています。欠測が起きた理由を確認しないまま補完へ進むのは避けたい進め方です。選択を誤ると、補完後の系列が実態とかけ離れた形になります。どの方法を選ぶかは、下の表の基準で切り分けてください。

補完した箇所には必ずフラグ列を立て、後から見分けられる状態にします。フラグがあれば、精度が悪化した期間と補完箇所の重なりを検証でき、原因の切り分けが数分で終わるのです。補完率の目安も持っておくと判断しやすく、全体の10%を超えたら補完方法の見直し、30%を超えたらその系列自体の採用を再検討します。補完率が高い系列を無理に使うより、対象から外したほうが全体の精度は安定します。無理に使わない判断も、精度を守るうえでは有効な選択です。

STEP6：外れ値の判定と扱いの決定

外れ値の判定でまず決めるのは、何を異常とみなすかという定義です。統計的な外れ値と、業務上の異常は必ずしも一致しません。大型連休の売上が平常時の5倍になっても、それは正常な変動であり、除去すべき対象ではないのです。判定には四分位範囲を使う方法が扱いやすく、第1四分位数と第3四分位数の差の1.5倍を超える値を候補として抽出します。抽出した候補は、そのまま削除せずに一覧化します。削除の判断は、必ず一覧を見てから下すべき工程です。

一覧化した候補は、扱いを3つから選びます。残す、除去する、上下限で丸めるのいずれかであり、判断は業務側の担当者と一緒に行うのが確実です。時系列では削除が使いにくく、行を消すと等間隔が崩れるため、欠測として扱い直してから補完する流れになります。作業量の目安として、1系列あたりの候補は全体の1〜3%程度に収まるのが通常です。10%を超える場合は、判定条件そのものを疑ってください。外れ値の見方は次の記事にまとめています。

箱ひげ図とは？外れ値の見方やExcelでの作成方法まで徹底解説

STEP7：変換と特徴量生成：定常化・スケーリング・ラグ特徴量

モデルに投入する直前の変換は、精度を左右する最後の分かれ目になります。作業は3つあり、定常化、スケーリング、ラグ特徴量の生成の順で進めます。定常化は差分や対数変換で行い、水準の変動を取り除く処理です。スケーリングは平均0・分散1に整える標準化が基本になり、勾配ブースティングのような手法では省略しても差は出ません。使うモデルに応じて要否を判断します。3つすべてを毎回行う必要はなく、目的に応じて取捨選択する工程です。

ラグ特徴量は、1時点前や7時点前の値を新しい列として持たせる仕組みです。日次データであれば1、7、14、28のラグと、7日および28日の移動平均を作る構成が出発点になります。作りすぎると列数が膨らみ、学習時間と過学習のリスクが同時に増えるのです。まずは10列前後から始め、特徴量の重要度を見ながら追加してください。ラグを作る際は、必ず時刻順に並べ替えてから処理する点にも注意します。並べ替えを忘れると、別の系列の値が混ざり込む不具合が起きるのです。

時系列データの前処理を成功させる6つのポイント

手順を知っていても、順序や適用範囲を誤ると効果は出ません。ここでは、実際の案件で精度と再現性を左右した6つのポイントを挙げます。いずれも一度仕組みに組み込めば、以降のプロジェクトでそのまま流用できる内容です。

標準化を先に、重複整理と名寄せを後に行う

作業の順序を誤ると、同じ処理を2回行う羽目になります。時刻の書式や表記が揃っていない状態で重複判定をかけても、2026-03-01と2026/03/01が別物として残るのです。名寄せも同様で、コードの表記ゆれを吸収する前に集約すると、同じ店舗が2行に分かれたまま集計されます。標準化を先に済ませておけば、重複判定は単純な比較だけで完了します。この順序は入れ替えず、必ず標準化から着手してください。順序の入れ替えは、見た目以上に大きな手戻りを生む変更です。

順序を守れているかは、処理の関数名を並べれば数分で点検できます。標準化、等間隔化、重複整理、名寄せ、補完、外れ値処理、変換の7段階が上から順に並んでいるかを見るだけです。途中に補完が2回出てくる、名寄せが標準化より前にあるといった並びは、手戻りの発生源になります。点検の頻度は、処理の流れを変更したタイミングごとで十分です。レビュー時のチェック項目に加えておきます。点検にかかる時間は5分程度で、費用対効果の高い作業です。

学習データと検証データは時系列の順序を保って分割する

時系列データをランダムに分割した時点で、その検証結果は信用できなくなります。未来のデータで学習し、過去のデータで検証する構図が生まれ、実運用ではありえない条件になるのです。分割は必ず時刻で区切り、前半を学習、後半を検証に充てます。より丁寧に検証するなら、学習期間を少しずつ伸ばしながら評価を繰り返す時系列交差検証を使います。scikit-learnのTimeSeriesSplitを使えば、実装は数行で済むはずです。

分割の比率にも目安があります。データが3年分あるなら直近6か月を検証に充て、残りを学習に使う配分が扱いやすい構成です。検証期間は、実運用で予測したい期間の3〜5倍を確保しておくと評価が安定します。加えて、学習期間と検証期間の間に数日の空白を挟む工夫も有効になります。実運用では最新データの反映に遅れが出るため、その遅れを検証条件にも反映させておくのです。空白期間の長さは、データ連携の遅延日数に合わせて決めます。

スケーリングの統計量は学習期間のみから算出する

標準化に使う平均と標準偏差を全期間から計算すると、検証データの情報が学習側へ漏れます。これがデータリーケージであり、検証時の精度だけが不自然に高くなる原因になるのです。全期間で算出した場合と学習期間のみで算出した場合を比べると、検証誤差が5〜15%変わる例もあります。本番投入後に精度が再現しない典型的な原因の1つです。見た目の数値に安心してはいけません。検証時の好成績は、実運用の成績を保証しない数値です。

実装ではscikit-learnのPipelineを使い、fitを学習データにのみ適用する構成にします。検証データと本番データにはtransformだけを呼び、統計量を再計算しない形が正解です。手作業のノートブックで前処理を進めると、この分離が崩れやすくなります。レビュー時には、fitとfit_transformが検証データに対して呼ばれていないかを検索して確認してください。検索そのものは数十秒で終わる作業です。

補完や平滑化は未来の値を参照しない範囲にとどめる

線形補間や中心移動平均は、欠測の前後の値を使って計算します。過去を振り返る分析としては自然な処理ですが、予測モデルの入力に使うと未来の情報を先取りすることになるのです。実運用の推論時点では、まだ観測されていない未来の値を参照できません。結果として、検証時だけ精度が高く、運用開始後に大きく崩れる状態を招きます。この差は、検証の設計を見直すまで気づかれないままです。設計の段階で、参照できる範囲を明文化しておきます。

使い分けの基準はシンプルです。可視化や過去の要因分析が目的であれば、中心移動平均や線形補間を使って構いません。予測モデルの入力にするなら、前進補完と後方移動平均だけに限定します。判断に迷ったときは、その特徴量を推論の時点で計算できるかを自問してください。計算できない特徴量は、検証結果を歪める要因になります。pandasのrolling関数は既定で後方参照になるため、centerの指定が入っていないかを確認しておきます。

業務イベントの記録と突き合わせ、欠測・外れ値の意味を判断する

数値だけを見て欠測や外れ値を処理すると、判断を誤ります。売上が3日連続でゼロになっていた場合、システム障害なのか、店舗の臨時休業なのかで扱いは正反対です。前者は欠測として補完の対象になり、後者は実績としてそのまま残す必要があります。判断材料になるのは、統計量ではなく業務側の記録になるのです。該当期間に何が起きていたかを確認する手間を惜しまないでください。確認先は、店舗の営業日カレンダーや障害報告の一覧が中心になります。

実務では、イベントカレンダーを1枚のテーブルとして用意しておくと効率が上がります。列は日付、イベント種別、対象拠点、備考の4つあれば十分です。祝日、大型セール、システム更改、設備の定期点検を登録し、前処理の判断時に結合して参照します。作成の初期工数は1〜2日程度で、以降は月に30分ほどの更新で維持できるのです。このテーブルは特徴量としても再利用でき、投資に対する効果は大きくなります。前処理と分析の両方で使える、数少ない共通資産です。

手順とパラメータを記録し、推論時に同じ前処理を再現する

学習時と推論時で前処理が食い違うと、モデルの性能は発揮されません。よくあるのは、学習時に使った標準化のパラメータが保存されておらず、推論時に再計算されてしまう構図です。列の順序が変わる、カテゴリの水準が欠ける、補完方法が違うといったずれも同じ結果を招きます。防ぐ手段は、前処理を1つのオブジェクトとして保存し、推論時に読み込む方式に統一することです。実装の負担は初回だけで済みます。2回目以降は、同じ仕組みをそのまま使い回せるはずです。

記録すべき項目は5つに整理できます。処理の順序、各処理の関数名とバージョン、パラメータの値、除外した期間と理由、そして入出力の構造です。これらをYAMLなどの設定ファイルにまとめ、コードから読み込む構成にします。設定ファイルをバージョン管理に載せておけば、いつどのパラメータを変えたかを後から追えるのです。作成にかかる工数は、既存の処理があれば半日程度で収まります。記録がないまま運用に移すのは、再現性を捨てる判断です。

時系列データの前処理でよくある失敗パターン

最後に、精度を落とす失敗例を6つ紹介します。いずれも実際の案件で繰り返し目にしてきたもので、共通するのは検証の時点では気づけない点です。自社の進め方に当てはまるものがないか、確認しながら読み進めてください。

ランダム分割で検証し、実運用時に精度が再現されない

入門書に載っているtrain_test_splitをそのまま使うと、行がランダムに振り分けられます。時系列では、これが最も影響の大きい失敗になるのです。2026年5月のデータで学習し、2026年3月のデータで精度を測る状態が生まれ、検証誤差は実力より小さく出ます。本番投入後に精度が半減し、原因の調査に数週間を費やす例も見てきました。分割方法は最初に確認すべき項目です。分割方法の確認は、モデル選定よりも先に済ませます。

回避策は、shuffleの指定をFalseにするか、TimeSeriesSplitへ置き換えることです。検証結果が実運用より明らかに良い場合は、まず分割方法を疑います。判断の目安として、検証誤差と本番稼働1か月目の誤差が2倍以上開いているなら、分割かリーケージのどちらかが原因になります。コードレビューの観点にshuffleの確認を1行加えるだけで、この失敗はほぼ防げるのです。見直しの手間は数分で済みます。

移動平均をかけた結果、検知すべき変化点まで消してしまう

ノイズを減らす目的で移動平均をかける処理は、広く使われています。窓幅を広げるほど系列は滑らかになりますが、同時に急な立ち上がりや落ち込みも削られるのです。設備の異常や需要の急変を検知したい場面では、この平滑化が見逃しの直接的な原因になります。窓幅30日の移動平均をかけた系列からは、3日間の異常はほとんど読み取れません。目的に合わない窓幅は、情報を捨てているだけの処理です。平滑化を入れる前に、検知したい変化の幅を必ず確認してください。

窓幅の決め方には目安があります。検知したい変化の持続期間の3分の1から2分の1に抑えると、変化点を残したままノイズを減らせます。3日続く異常を捉えたいなら、窓幅は1日から2日が上限です。平滑化した系列と原系列を必ず重ねて描き、消えている変化がないかを目視で確認してください。異常検知が目的の場合は、平滑化そのものを行わない選択も有効になります。窓幅は最初から固定せず、検証の結果を見ながら調整していく項目です。

全期間の統計量で標準化し、検証データの情報が混入する

標準化を全期間に対して一括で適用する処理は、コードとしては最も短く書けます。ところが平均と標準偏差の中に検証期間の情報が含まれ、検証誤差が実力より小さく出るのです。この失敗が厄介なのは、エラーが出ず、結果も一見して自然に見える点にあります。気づくきっかけは、本番稼働後に精度が落ちたときしかありません。検証段階での発見が難しい種類の不具合です。短く書けるコードほど、検証データの情報が混入しやすい構造になっているのです。

防ぐ方法は、統計量の算出範囲を学習期間に限定することに尽きます。scikit-learnのPipelineとTimeSeriesSplitを組み合わせれば、分割ごとに正しく統計量が計算されます。自作のコードで進める場合は、fitとtransformの呼び出し箇所を明示的に分けてください。レビュー時には、標準化の処理が分割の前にあるか後にあるかを確認します。分割の後にあるのが正しい形です。分割の位置は、レビュー時に真っ先に確認します。

欠測を一律にゼロで埋め、需要がない期間として学習させてしまう

欠測を0で埋める処理は、手軽さから広く使われています。売上データでこれを行うと、データが取れなかった期間が売上ゼロの期間としてモデルに学習されるのです。結果として予測値全体が下振れし、在庫や人員の計画にも影響が及びます。欠測率が5%程度でも、予測値が3〜8%下振れする例を確認しています。一律の穴埋めは避けてください。埋める前に、その0が事実かどうかを確かめる手順を挟みます。0と欠測を同じ値で表すこと自体が、情報を失う処理です。

判断の手順は2段階になります。最初に、その欠測が観測できなかったものなのか、事象が発生しなかったものなのかを業務側に確認します。休業日の売上は本当にゼロであり、この場合は0で埋めるのが正しい処理です。通信断でログが届かなかった場合は欠測であり、補完かフラグ付きの除外を選びます。営業日カレンダーと突き合わせれば、この切り分けは半日程度で完了するのです。確認結果は、欠測フラグの定義としてそのまま記録します。

タイムゾーンを未指定のまま結合し、日次集計が1日ずれる

海外拠点やSaaSのデータが混ざると、タイムゾーンの不一致は必ず起きます。UTCと日本時間が混在した状態で日次集計を行うと、9時間分の売上が前日側に寄るのです。月次の合計では差が見えにくく、月末月初の日別グラフでようやく異常に気づきます。影響範囲の特定だけで数日を要する厄介な不具合です。取り込み時点での対処が、最も安価な解決策になります。入口でそろえておけば、後続のどの処理でもずれは生じないはずです。

防止策は2つあります。1つは、時刻列に必ずタイムゾーン情報を持たせ、情報のない日時を処理に入れない方針です。もう1つは、結合前に各データの時刻の最小値と最大値を比較する自動チェックを入れる方法になります。同じ期間を対象にしているはずのデータで境界が9時間ずれていれば、その場で検知できるのです。チェックの実装は10行程度で済み、以降の調査工数を大きく削減できます。10行の投資で数日の調査を防げる、費用対効果の高い対策です。

前処理を手作業で進め、推論時に同じ処理を再現できない

ノートブック上でセルを順に実行しながら前処理を組み立てる進め方は、探索の段階では効率的です。問題は、その手順が本番環境に移せないまま残ることにあります。実行順序が記録されず、途中で手動修正した値も残らないため、同じ結果を再現できません。担当者が異動した時点で、前処理の中身は誰にも分からなくなるのです。再現できない前処理は、資産として残らない作業になります。探索用のコードと本番用のコードは、別物として扱うべきものです。

探索が終わった段階で、処理を関数化してスクリプトに落とす作業を必ず挟みます。関数化の単位は7つの手順に合わせ、入力と出力のデータ形式をそれぞれ明記します。所要時間は、ノートブックの分量にもよりますが半日から2日程度が目安です。この作業を後回しにすると、本番移行の直前に想定外の工数が発生します。探索と実装の切り替え時点を、プロジェクト計画に明示的に置いてください。切り替えの判断が遅れるほど、移行の負担は増える構造です。

まとめ

時系列データの前処理は、7つの手順と6つのポイントに整理できます。順序を守り、未来の情報を参照しない範囲で処理を組み立てれば、精度も再現性も安定してきます。まずは手元のデータで時刻列の型と時刻差の分布を確認するところから着手してください。

「これから時系列データの活用に関する取り組みを実施したいけれど、何から手をつけたらいいかわからない」「データ専門家の知見を取り入れたい」という方は、データ領域の実績豊富な弊社、データビズラボにお気軽にご相談ください。

貴社の課題や状況に合わせて、時系列データの取り組みをご提案させていただきます。

データビズラボの実績無料相談・お見積り