2026年11月10日 · データ

バックテストに必要なのはデータのスナップショットだけではなく変更ログ

バックテストに必要なのはデータのスナップショットだけではなく変更ログ

市場データのスナップショットを固定するだけでは、信頼できるバックテストにはなりません。同じ結果を再現できても、その結果を生んだ入力データがベンダーによって変更されていた事実は隠れてしまうことがあります。

スナップショットは保存しましょう。そのうえで、何がいつ変わったのか、そして戦略に影響したのかが分かる変更ログも残します。修正済みの取引データ、改訂されたファンダメンタルズ、再構築されたファンディングデータ、あるいはベンダーがひそかに更新した履歴データを使うリサーチでは、特に重要です。

バックテストを再現できても、誤解を招くことがあるのはなぜでしょうか?

月曜日に5年分の1時間足をダウンロードして、戦略を実行したとします。金曜日には、ベンダーが誤った取引データを修正したり、コーポレートアクションを調整したり、欠損を補完したりしています。保存したファイルからは、月曜日の結果を正確に再現できます。これは再現性があるということです。しかし、ベンダーの最新の履歴データを使って再実行すると結果が変わる可能性があり、その理由を示す記録が残っていないこともあります。

問題は大きな修正だけに限りません。高値が1つ変わるだけでストップが発動することもあれば、終値の改訂によって指標が閾値を超えることもあります。広い投資対象ユニバースでは、1銘柄の履歴変更で順位が変わり、別の資産がポートフォリオから外れることもあります。戦略コードと設定が同じでも、最終的なSharpeは変動し得ます。

ファイルのハッシュから分かるのは、2つのファイルが異なるということだけです。株式分割の調整で40年分の価格が変わったのか、ベンダーが3件の取引を修正したのか、パーサーが空欄を0に変換したのかは分かりません。

市場データの変更ログには何を記録すべきでしょうか?

研究で影響を受けた部分を再実行できるだけの情報を添えて、実用上必要な最小単位で変更を記録します。バー配信データの場合、通常は銘柄、時間間隔、イベント時刻、変更前後の値、データソース、更新を確認した時刻を記録します。ベンダーが元のペイロードを提供している場合は、それも保存しましょう。

記録項目記録する理由例
ソースのバージョンまたは取得時刻使用したベンダーデータの状態を特定できるスナップショット取得日時 2026-11-02 08:15 UTC
変更されたフィールドと変更前後の値実際に何が変わったかを示せるETHUSDT 1h 高値: 3,412.10 → 3,418.60
変更の分類修正と変換を区別できる遅延した取引の修正、分割調整、バックフィル
パイプラインとスキーマのバージョンソース側の変更と独自処理を区別できるNormalizer v7、調整済みバーのスキーマ v3

大規模なデータセットでは、不変のスナップショットを保存し、チェックサム、ソースのバージョン、取得時刻をまとめた簡潔なマニフェストを作成します。変更されたパーティションには行単位の差分を追加します。これなら、変更のない行を別の監査テーブルにすべて書き込まずに、全体を再実行できる実用的な落としどころになります。

修正が重要かどうかは、どう測ればよいでしょうか?

変更された行数を数えるだけで終わらせないでください。同じコード、パラメーター、手数料、執行前提のもとで、旧データと新データを使って影響を受けた戦略を再実行します。判断と、結果に至るまでの推移を比較しましょう。

  1. 差分から影響を受けた銘柄とイベント時刻を特定する。
  2. 該当レコードを参照する特徴量、シグナル、注文、ポートフォリオのウェイトを調べる。
  3. ルックバック期間と保有中ポジションの状態を含め、妥当な最小区間を再実行する。
  4. 注文、約定、エクスポージャー、売買回転率、ドローダウン、最終的なパフォーマンスを比較する。

たとえば、ベンダーが1分足の高値を$0.02修正したことで100万行に影響しても、日次モメンタム戦略の結果は変わらないかもしれません。ストップ水準にあるバーが1つ修正されれば、影響はより大きくなり得ます。判断への影響を測りましょう。変更レコード数は、その影響を測る目安として適切ではありません。

次の2つの問いは分けて考えましょう。「保存したデータから結果を再現できるか?」そして「当時、このデータバージョンを戦略が利用できたか?」変更ログは両方の問いに答える助けになりますが、後者にはポイントインタイムの利用可能性を記録する仕組みも必要です。

どれくらいコストがかかり、どんな場合に導入する価値があるでしょうか?

変更追跡には、ストレージ、データ取り込みの作業、運用上の判断が必要です。ベンダーが安定したバージョンを公開していないこともあり、過去データが明確な修正通知なしに定期的に再構築される場合もあります。気づかなかった変更は記録できません。

まずは、改訂によってリサーチの結論が変わり得るデータから始めましょう。ストップロジックに使うバー、コーポレートアクション調整済みの株式データ、ポイントインタイムのファンダメンタルズ、再構築されるファンディングや建玉の時系列データが対象です。広範で安定したデータセットなら、日次マニフェストとパーティションのチェックサムで十分かもしれません。更新頻度が高いデータや、個々のレコードが売買判断を左右するデータには、フィールド単位の差分を追加します。

ベンダーからの全応答を永久に完全保存するのは高くつくうえ、当時ソース側で把握されていた情報を記録できるとは限らない、という批判はもっともです。対象となるデータと重要な判断に合わせて監査範囲を決め、記録上の空白を明示しましょう。スナップショットがあれば実験を再実行できます。変更ログがあれば、実験の結果が変わった理由を説明できます。

データエンジニアリングバックテスト再現性クオンツリサーチ
← 記事一覧