【要約】バックテストの再現性を壊す5つの罠 — 10年分のFX検証で全部踏んだ [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
筆者が10年間のFX検証を行う際、戦略のロジックではなく、検証の足回りに起因するデータの不整合に直面した。具体的には以下の問題が発生した。
- ・実行日に依存する相対的な期間指定による、開始日の意図しない変動。
- ・データカバー率を無視した、高精度ソースの優先順位付けによる計算誤差。
- ・口座残高がマイナスになっても計算を継続する、物理的に不可能な数値の算出。
- ・中間処理での丸めによる、最終出力の微細な誤差。
- ・改定統計データによる、意図しない先読みバイアス（Look-ahead bias）の混入。
// Approach
筆者は、データの整合性と再現性を担保するために、取得層とフィルタ層の分離や、データのバージョン管理を導入した。
- ・取得は最大期間で行い、期間の限定はバックテスト側のフィルタ層で行う。
- ・ソースの選択条件に「カバー率」を追加し、不完全な場合は警告を出す。
- ・異常なドローダウン発生時は、損失額ではなく「破産日」として解釈する。
- ・数値は生値のまま保持し、丸め処理は出力直前の1回のみに限定する。
- ・
merge_asofを用い、direction="backward"で公表済みの値のみを参照する。
// Result
筆者は、これらの対策により、バックテストの信頼性を大幅に向上させた。
- ・MXN/JPYの再計算により、4ポイントの計算誤差を修正した。
- ・不完全なスワップデータによる誤った投資判断を、警告機能で回避した。
- ・Look-ahead biasを排除し、当時の既知情報に基づいた検証を実現した。
- ・異常値の解釈を「破産日」に切り替えることで、実務的な分析を可能にした。
Senior Engineer Insight
> 本記事の核心は、計算ロジックではなく「データのライフサイクル」への洞察にある。特に「静かなフォールバックは静かな嘘になる」という指摘は、大規模なデータパイプラインを運用する上で極めて重要だ。エラーや欠損を隠蔽せず、不完全な状態を明示的に警告する設計は、システムの信頼性を担保する鉄則である。金融に限らず、時系列データを扱うあらゆるシステムにおいて、この設計思想は必須と言える。