定量運用における「データリーク」の罠── バックテストを歪める誤り

バックテストで良好な成績を示した戦略が、実運用に移した途端に機能しなくなる。定量運用に携わる人であれば一度は経験する現象です。原因はいくつかありますが、繰り返し現れるのがデータリーク、すなわち検証時点では入手できなかったはずの情報が学習や判定に混入している状態です。

データリークが厄介なのは、検証コードが正しく動いているように見える点にあります。エラーは出ず、指標は改善し、むしろ「うまくいった」という手応えとともに問題が埋め込まれます。本稿では、実務で頻出する混入経路を類型化し、それぞれについて何が起きているのかと、どの程度の対処が必要になるのかを、計算できる形まで下ろして整理します。参照した一次資料は末尾に列挙しています。

これは金融だけの問題ではない

まず、この問題の規模を示す調査があります。プリンストン大学の Kapoor と Narayanan は、機械学習を用いた科学研究を横断的に点検し、データリークが17分野・294件の研究に影響して過度に楽観的な結論を生んでいたと報告しました。2023年に Patterns 誌へ掲載された論文です。

同論文はリークを8つの類型に整理したうえで、内戦の発生予測という具体的な分野で再現検証を行っています。この分野では複雑な機械学習モデルが従来の統計モデルを上回るとされていましたが、リークを補正して評価し直すと、その優位性は消えました。「モデルが優れていた」のではなく、「検証の設計が甘かった」というのが結論です。

金融の定量運用は、この種の誤りに対してとくに脆弱な条件が揃っています。データが時系列で並んでいるため過去と未来の境界を誤りやすく、信号対雑音比が低いため小さな混入でも成績が大きく動き、しかも試せる戦略候補が事実上無数にあります。以下、混入経路を三つに分けて見ていきます。

混入経路① 時点のずれ

金融データは、値そのものと同じくらい「いつ入手できたか」が重要です。ところが多くのデータセットは参照時点で並んでおり、実際に配信された時刻を持ちません。四半期決算の数値が期末日付で格納されていれば、それをそのまま特徴量に使った瞬間、発表前の情報を使って売買していることになります。

同じ問題は、経済統計の速報と改定、指数構成銘柄の入れ替え、格付の変更などにも現れます。いずれも公表日と対象期間が異なるため、対象期間の日付で結合するとリークが生じます。決算であれば期末から発表までの間隔は数十日に及ぶことも珍しくなく、その期間分の未来を先取りしていることになります。

対策は単純で、すべての時系列にデータが利用可能になった時刻を持たせ、結合はその時刻で行います。ベンダーが提供していない場合は、公表スケジュールから保守的に推定した遅延を一律で加えるほうが、期末日付で結合するよりはるかに安全です。

より厄介なのが、値そのものが後から書き換わるデータです。経済統計の改定や財務データの修正再表示では、同じ日付の値が時間とともに変わります。現在のデータベースを参照して過去を検証すると、当時は知りえなかった改定後の値を使うことになります。改定履歴を保持したポイントインタイム構成のデータが必要になるのはこのためです。

取引時刻とデータ時刻のタイムゾーンも見落とされがちです。海外市場のデータを国内時刻の日付で結合すると、市場の営業日の境界をまたいで数時間分の未来情報が入ります。時刻はすべて協定世界時で保持し、表示のときだけ変換する方針にしておくと、この種の混入を防げます。

混入経路② 全期間集計と交差検証の設計

特徴量の正規化は、リークがもっとも紛れ込みやすい工程です。標準化のために平均と標準偏差を全期間から計算すると、過去のある時点の特徴量に未来の統計量が入り込みます。欠損値を全期間の中央値で埋める処理、外れ値の閾値を全期間の分位点で決める処理も同じ構造です。

この種のリークは効果が穏やかなため、指標の改善幅も控えめで、かえって発見が遅れます。予防としては、前処理をすべて拡張窓もしくは移動窓で行い、ある時点の変換パラメータはその時点までのデータだけから決めると徹底します。当日の値を統計量の計算に含めない点も忘れがちな落とし穴です。

交差検証の設計にも同じ注意が要ります。時系列データに対して無作為分割の k 分割交差検証を適用すると、未来のサンプルで学習して過去を予測する組み合わせが生じます。時系列に沿って分割するのが前提ですが、それだけでは足りません。

問題はラベルの算出区間にあります。「20営業日後までのリターン」をラベルにしているなら、ある時点のラベルは 20営業日先の情報を含んでいます。学習期間の末尾にあるサンプルのラベルは、検証期間に食い込んでいるわけです。この重なりを取り除く操作をパージ、検証期間の直後についても同様に間隔を空ける操作をエンバーゴと呼びます。

必要な幅は計算できます。ラベルの算出期間を h 営業日とすると、境界の前後それぞれ h 営業日、合計 2h 営業日を学習データから除くことになります。実際に代入すると次のとおりです。

• h = 5 営業日 — 境界あたり 10 営業日を除去
• h = 20 営業日 — 境界あたり 40 営業日を除去
• h = 60 営業日 — 境界あたり 120 営業日を除去

1年を約252営業日とすると、h = 60 の場合に失われる 120営業日は、検証窓を1年に取ったときのほぼ半分に相当します。保有期間の長い戦略ほど、まともに検証するために必要なデータ量が跳ね上がるということです。この負担を嫌ってパージを省くと、そのぶんが成績の上振れとして返ってきます。

混入経路③ 生存バイアス

上場廃止、統合、指数からの除外を経た銘柄がデータセットから消えていると、検証の母集団が勝ち残った銘柄に偏ります。これは前処理では直せず、データの取得段階で決まります。

確認方法として、各時点の母集団サイズと、その時点で存在した銘柄の一覧を時系列で出力してみると異常に気づきやすくなります。過去に遡るほど銘柄数が減っている、あるいは現在の構成銘柄と過去の構成銘柄が同一になっているデータセットは、生存バイアスを含んでいる可能性が高いといえます。

指数連動の戦略を検証する場合は、時点ごとの構成銘柄を保持したデータが要ります。現在の構成銘柄で過去を遡ると、その後に採用された優良銘柄を最初から保有していたことになります。学術研究で CRSP のような上場廃止銘柄を含むデータベースが標準的に使われるのは、この問題を避けるためです。

試行回数もリークの一種

ここまでは実装上の混入でしたが、もう一つ、設計者自身を経由するリークがあります。同じデータで多数の戦略候補を試し、その中から成績の良いものを選ぶ行為です。選択の過程を通じて、検証データの情報がモデルの選択に流れ込んでいます。

この影響は定量化できます。互いに独立な N 個の候補を試したとき、帰無仮説のもとで各候補の t 統計量が標準正規に従うと仮定すると、その最大値の期待値はおおよそ次の式で近似できます。

E[max t] ≈ √(2 ln N)

実際に代入すると次のようになります。

• N = 10 — 最大 t の期待値 2.15
• N = 50 — 2.80
• N = 100 — 3.03
• N = 500 — 3.53
• N = 1000 — 3.72

つまり、中身が空の候補を100通り試せば、t = 3 前後の「発見」が一つは出るという計算です。独立性の仮定は現実の戦略候補では成り立たないため実効的な試行回数はこれより少なくなりますが、桁感を掴む目安にはなります。

金融の実証研究でも同じ問題が指摘されています。Harvey・Liu・Zhu は、1967年の初期の実証研究から現在までに発表されたファクター研究を横断的に集計し、これだけ大量の探索が行われた後では通常の有意水準は意味をなさないと論じました。同論文が新しいファクターに求める水準は t 統計量 3.0 超です。論文はさらに、金融経済学で主張されている研究結果の多くはおそらく誤りである、とまで述べています。

実務上できることは、試行回数を記録に残すことです。何通りのパラメータを試し、何度データを見直したかを残しておかないと、最終的な成績をどれだけ割り引いて読むべきかが判断できなくなります。

検証を疑うための実務的な手順

リークの有無を確かめる方法として、いくつかの簡便な検査が役立ちます。第一に、特徴量をすべて一定期間ずらして再検証し、成績が不自然に劣化しないかを見ます。リークがある場合、わずかなずらしで成績が大きく崩れることがあります。

第二に、ラベルを無作為に並べ替えて学習させ、成績が偶然の水準に落ちるかを確認します。落ちない場合は、特徴量とラベルの間に想定していない結合経路が存在します。この検査は追加のデータを必要とせず、既存の検証コードをそのまま使えるため、最初に試す価値があります。

第三に、成績が異常に良い期間や銘柄を抽出し、その時点の入力を個別に追跡します。決算発表日や指数入れ替え日の周辺に利益が集中していれば、時点のずれを疑う十分な理由になります。

仕組みで防ぐ

属人的な注意に頼らず、仕組みで防ぐのが確実です。有効なのは、特徴量の生成を時点を引数に取る関数として実装し、その関数が指定時点より後のデータへアクセスできないようにデータ層で遮断する構成です。検証コードから未来のデータを物理的に見せないため、意図しない参照が実行時エラーになります。

あわせて、検証結果とともにデータのスナップショット、コードのバージョン、乱数シードを記録します。後から検証を再現できない状態は、リークの調査そのものを不可能にします。前掲の Kapoor らが提案しているのも、モデルと検証設計の情報を定型の様式で残し、第三者が同じ手順を辿れるようにするという方向の対策です。

レビューの観点も決めておくと再現しやすくなります。新しい特徴量が追加されたときに、その値がいつ配信されるものかを説明できるか。前処理の統計量が学習期間に閉じているか。この二点をコードレビューの必須項目にしておくだけで、混入の大半は入口で止まります。

まとめ

データリークは高度な問題ではなく、時点管理の不備という地味な原因から生じます。すべての系列に利用可能時刻を持たせ、前処理を時点ごとに閉じ、パージとエンバーゴでラベルの重なりを取り除き、母集団の変遷を保持する。これらを実装として強制できていれば、大半のリークは入り込みません。そのうえで残るのが試行回数の問題で、こちらは √(2 ln N) という単純な式が、何通り試した結果なのかを記録しておく理由を示してくれます。検証結果に驚いたときこそ、モデルではなくデータの結合を疑う価値があります。

金融テクノロジー総合研究所では、バックテスト基盤の設計、データ品質の検証、モデル検証プロセスの整備を受託しています。既存の検証環境の点検からご相談いただけます。お問い合わせよりご連絡ください。

参考資料

• Kapoor, S. & Narayanan, A. Leakage and the reproducibility crisis in machine-learning-based science, Patterns 4(9), 100804, 2023（オープンアクセス。17分野・294件、8類型、内戦予測の再現検証）
• Harvey, C. R., Liu, Y. & Zhu, H. … and the Cross-Section of Expected Returns, The Review of Financial Studies 29(1), 5–68, 2016（多重検定を踏まえた t > 3.0 の基準）
• Bailey, D. H., Borwein, J. M., López de Prado, M. & Zhu, Q. J. Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance, Notices of the AMS 61(5), 458–471, 2014（バックテストの過剰適合と必要な検証期間）
• Sasse, L. ほか On Leakage in Machine Learning Pipelines, arXiv:2311.04179, 2023（前処理を含むパイプライン全体での混入経路の整理）
• CRSP（上場廃止銘柄を含む、生存バイアスを避けた株式データベースの代表例）

FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。