AI・機械学習のPoCで、想定以上に高い精度が出ることがあります。
AccuracyやAUCが非常に高い、予測誤差が想定より小さい。こうした結果はモデル性能が高い可能性を示しますが、そのまま「PoC成功」「本番でも同じ性能が出る」と判断する前に確認したいものがあります。
その一つがData Leakage（データリーケージ）です。
ここでいうData Leakageは、個人情報や機密情報が外部へ流出するというセキュリティ上の「データ漏えい」とは異なります。本記事では、機械学習モデルの構築・評価へ、本来その予測時点では利用できない情報や評価用データ由来の情報が入り込み、汎化性能を実際より良く評価してしまう問題を指します（Kaufman et al., 2012）。
重要なのは、高精度そのものがData Leakageの証拠ではないことです。実際に予測力の高いFeatureが存在する場合もあります。
したがって、「高精度だから怪しい」と判断するのではなく、想定以上の高精度が出たら評価設計を一度監査するという考え方が実務的です。
データリーケージとは何か
機械学習におけるData Leakageの本質は、本来の予測問題では利用できない情報がモデルへ入ることです。
典型例は、将来確定する情報を過去の予測に使ってしまうケースです。
例えば「月初時点で、その月に契約更新を行わない顧客を予測する」とします。この場合、モデルへ入力できるのは、原則として月初時点ですでに利用可能な情報です。
後からデータベースを確認すると、その月の解約処理完了フラグも同じ顧客レコードに保存されているかもしれません。しかし、その情報は月初にはまだ存在していません。
過去データベースに存在していることと、実際のPrediction Time（予測実行時点）で利用できたことは別です。
将来確定する情報がFeatureに入っていた架空例
説明用の架空企業を考えます。
目的は「月初時点で、その月に契約更新を行わない顧客を予測する」ことです。
モデルには、過去3か月の利用回数、契約期間、過去の問い合わせ回数、月初時点の契約プランなどを利用していました。
ところが、Feature一覧には「当月の解約処理完了フラグ」も含まれていました。
このフラグは解約と強く関係するため、過去データを使ったValidationでは非常に高い性能になる可能性があります。しかし、実際に予測を行う月初時点ではまだ確定していません。
つまり、過去データの世界では利用できても、本番のPrediction Timeでは利用できないFeatureです。
製造業でも同じ問題が起こり得ます。製造開始時点で不良発生を予測したいにもかかわらず、製造後の最終検査結果、修理実施フラグ、不良確定後に入力された原因コードなどをFeatureへ入れれば、評価結果を過度に楽観視する可能性があります。
Featureを見るときは、「Targetとの相関が高いか」だけでなく、「Prediction Timeでその値を取得できるか」を確認することが重要です。
データリーケージの代表的な5パターン
1. Target Leakage
目的変数が確定した後に生成される情報や、実質的に目的変数そのものを表す情報がFeatureへ含まれるケースです。
解約予測に解約完了後のステータスを使う、不良予測に最終検査結果を使う、といった例が該当します。
2. Train / Test Contamination
Test Dataの情報をTrainingやモデル選択へ利用してしまうケースです。
Test Setは、本来「未知データでどの程度性能が出るか」を確認するためのものです。Test結果を何度も見ながらFeatureやモデルを変更すると、直接学習させていなくてもTest Setへ最適化していく可能性があります。
3. Preprocessing Leakage
Leakageはモデル学習だけでなく、前処理でも起こります。
例えばTrain / Testを分割する前に全データから平均・標準偏差を計算して標準化したり、全データから欠損補完値やPCAの変換、Feature Selectionの対象を決めたりすると、Test側の情報が前処理へ入り込む可能性があります。
基本的には先にデータを分割し、学習が必要な前処理はTraining Dataだけでfitします。Cross Validationでは、各FoldのTraining側で前処理をfitする設計にします。
4. Temporal / Future Leakage
時系列で特に注意したいのが、未来情報の混入です。
例えば過去と未来をランダムに混ぜてTrain / Testへ分割すると、実運用では未来となる期間のパターンを学習した上で、過去側を評価してしまうことがあります。
また、Rolling Mean等のFeatureを作る際に、予測対象時点より後のデータをWindowへ含めてしまうケースもあります。
時系列に標準K-foldを使用できる条件も研究されていますが、その適用は系列相関や非定常性等に依存するため一律ではありません（Bergmeir et al., 2018）。予測時点とForecast Horizonに合った評価設計を選ぶ必要があります。
5. Entity / Group構造による楽観的評価
同じ顧客・設備・患者・製造ロット等から複数レコードが生成されるデータでは、同一対象の一部がTraining、一部がTestへ入ることで評価が高くなる場合があります。
例えば、新規顧客への汎化性能を評価したいのに、同じ顧客の別期間データがTraining側に存在すれば、「未知顧客への予測」とは異なる評価になります。
本記事では説明上、このようなGroup構造による過度に楽観的な評価もLeakage確認項目として扱います。目的に応じて、同一GroupがTrainとTestへまたがらない分割を検討します。
最初にPrediction Timeを決める
Data Leakageを確認するとき、最も重要なのは「いつ予測するか」を明確にすることです。
例えば「毎月末時点の情報から翌月の解約を予測する」「製造開始時点の情報から完成後の不良を予測する」のように、一文で定義します。
そのうえで、各Featureについて次の時刻を整理します。
- 実際の事象が発生したEvent Time
- データがシステムへ登録された時刻
- 値が確定し、分析へ利用可能になったAvailable Time
- モデルが予測を実行するPrediction Time
この区別が重要なのは、「イベント自体は過去に起きていたが、システムへの入力は予測後だった」というケースがあるためです。
後日更新されたステータスや事後確定したマスタ値が、履歴テーブル上では過去日時へ紐付いていることもあります。
モデル開発時には、単なる日付列ではなく「当時、本当に利用可能だったか」というPoint-in-Timeの整合性を確認します。
時系列データでは評価方法そのものを確認する
時系列では観測同士が時間的に依存しているため、一般的なランダム分割を機械的に適用すると、本番利用時とは異なる評価条件になる場合があります。
例えば、過去期間をTraining、その後の期間をValidationとして評価すれば、「過去から未来を予測する」という実際の利用条件へ近づけられます。
必要に応じて、TrainingとValidationの間にGapを設けることも検討します。Labelが確定するまで時間がかかる場合や、近接期間の情報が強く重なる場合には、このGapが重要になることがあります。
ただし、時系列なら特定のSplit方法を使えば常に安全というわけではありません。Forecast Horizon、Label確定時期、Feature更新頻度、Group構造等に合わせて設計します。
前処理・Feature Engineeringでもリークは起こる
TrainとTestを分けているだけでは十分ではありません。
例えば、全データから平均・標準偏差を計算した後に標準化してTrain / Testへ分割すると、Test Dataの情報を使って前処理パラメータを決めたことになります。
同様に、欠損補完、PCA、Feature Selection等も、データから何らかの値や構造を学習する処理であればTraining側だけでfitすることが基本です。
Cross Validationを行う場合には、それぞれのFoldのTraining Dataだけで前処理を学習し、Validation側へ適用します。Pipelineを利用すると処理順を管理しやすくなりますが、Pipelineを使うだけですべてのLeakageを防げるわけではありません。
Feature Engineeringでも同様です。例えばRolling Meanを作る際にcentered windowを使い、予測対象時点より後の観測が計算へ入れば、未来情報を利用している可能性があります。
同一顧客・設備がTrainとTestにまたがっていないか
BtoBデータでは、一つの顧客から多数の取引行が生成されたり、一つの設備から多数のセンサーレコードが生成されたりします。
このとき評価したいのが「未知の行」なのか「未知の顧客・設備」なのかで、適切な分割方法は変わります。
新規設備への適用性能を知りたいにもかかわらず、同じ設備の別期間データがTrainingとTestの双方に存在すれば、評価したい問題とは異なる可能性があります。
Groupをまたいだ汎化性能を確認したい場合は、同一顧客・設備等がTrainとTestへ重複しないGroup-awareな分割を検討します。
高すぎる精度が出たときの7ステップ
- Prediction Timeを一文で定義する
「いつ、何を予測するのか」を明確にします。 - 全FeatureのAvailable Timeを確認する
予測時点ですでに値が確定しているか確認します。 - Target確定後に生成される列を確認する
事後ステータスや結果由来のFeatureを探します。 - Splitより前にfitしている処理を確認する
標準化、欠損補完、PCA、Feature Selection等を確認します。 - 時間・Group構造に合ったSplitへ見直す
本番利用時に未知となる対象を考えて分割します。 - 独立したHoldoutやOut-of-time Dataで再評価する
モデル開発中に繰り返し参照していないデータで性能を確認します。 - Leakage除去前後の性能差を記録する
性能低下を単なる「モデル改悪」と捉えず、本番条件へ評価が近づいた可能性を検討します。
特に最初の2ステップは、複雑なツールがなくても実施できます。
モデルで使用しているFeatureを一覧化し、「この値は実際の予測を行う時点ですでに確定しているか」を1列ずつ確認してみてください。
Feature Availability Auditを作る
初期確認では、Excel等でFeature Availability Auditを作成するだけでも有効です。
| 項目 | 確認内容 |
|---|---|
| Feature Name | モデルへ入力する項目名 |
| Source System | どのシステムから取得するか |
| Event Time | 対象となる事象が発生した時刻 |
| Available Time | 分析で利用できる状態になった時刻 |
| Prediction Time | モデルが予測する時刻 |
| Available at Prediction? | Prediction Time時点で利用可能か |
| Used in Production? | 本番システムでも取得可能か |
| Leakage Risk | 未来情報・Target由来等の懸念 |
最初からすべての時刻を精緻に取得できない場合は、「Feature Name」「Available Time」「Prediction Time」「Available at Prediction?」の4列から始めても構いません。
重要なのは、Featureの意味だけでなく、データがいつ確定するかをモデル仕様の一部として管理することです。
本番導入前のチェックリスト
| 確認項目 | 確認内容 |
|---|---|
| Prediction Time | いつ何を予測するか明文化したか |
| Feature Availability | 全Featureが予測時点で利用可能か |
| Target Leakage | Target確定後の情報やProxyがないか |
| Preprocessing | Training Dataだけでfitしているか |
| Feature Selection | Test Dataを含めて選定していないか |
| Cross Validation | 各Fold内で前処理を学習しているか |
| Time | 未来情報を利用していないか |
| Rolling Window | 予測後の観測を含んでいないか |
| Group | 同一顧客・設備等の重複が目的に適しているか |
| Duplicate | 重複・ほぼ同一レコードがTrain/Testにないか |
| Production | 本番でも同じFeatureを同じ時点で取得できるか |
| Holdout | モデル開発から独立した評価データがあるか |
Data LeakageとOverfittingは同じではない
Data LeakageとOverfitting（過学習）は、どちらも「検証では良いが未知データでは悪い」という現象につながることがありますが、原因は異なります。
Overfittingは、正当に利用できるTraining Dataへモデルが過度に適合し、未知データへのGeneralizationが低下する問題です。
一方、Data Leakageは、本来利用できない情報がモデル構築や評価へ入り、そもそもの評価条件が楽観的になっている問題です。
両方が同時に存在する場合もあるため、「精度が落ちたから過学習」「精度が高いからLeakage」と単純に判定しないことが重要です。
まとめ
AI・機械学習PoCで非常に高い精度が得られたこと自体は、問題ではありません。
一方、その精度を本番性能として扱う前に、「実際のPrediction Timeで利用できる情報だけから予測しているか」を確認する必要があります。
Data LeakageはTarget由来のFeatureだけでなく、Test Dataを含めた前処理、時系列の未来情報、Feature Engineering、同一Entityの重複等、データ準備から評価までさまざまな工程で起こり得ます。実環境と異なる情報共有によって評価性能が過度に良くなる問題は、近年も再現性上の重要な論点として扱われています（Bernett et al., 2024）。
Leakageを除去した結果、評価値が下がったとしても、それを直ちにモデルの失敗とは考えません。むしろ、本番で期待できる性能に近い評価へ修正できた可能性があります。
SCI総合研究所株式会社のRASHINRAでは、AI・機械学習モデルの精度だけを見るのではなく、実際の意思決定時点で利用できるデータ、評価方法、本番運用条件まで含めて、モデルを業務へ利用できるかを整理します。
「PoCでは高精度だったが本番で再現するか不安」「時系列データの分割方法が妥当か分からない」「将来情報がFeatureへ入っていないか確認したい」といった段階から、モデル評価と本番導入判断の論点を整理できます。
参考文献
- Kaufman, S. et al. 2012. Leakage in Data Mining: Formulation, Detection, and Avoidance. ACM Transactions on Knowledge Discovery from Data. Vol. 6. Issue 4. pp. 1-21. DOI: 10.1145/2382577.2382579.
- Bergmeir, C. et al. 2018. A note on the validity of cross-validation for evaluating autoregressive time series prediction. Computational Statistics & Data Analysis. Vol. 120. pp. 70-83. DOI: 10.1016/j.csda.2017.11.003.
- Bernett, J. et al. 2024. Guiding questions to avoid data leakage in biological machine learning applications. Nature Methods. Vol. 21. Issue 8. pp. 1444-1453. DOI: 10.1038/s41592-024-02362-y.