バックテストの年率リターンは20%でした。8年分のデータを使い、取引は1,640回、ウォークフォワード分割も適切に行っていました。ところが、ベンダーの現在の履歴を当時記録された値に置き換えると、優位性は3%まで低下しました。
意外だったのは当初のリターンではありません。改訂後のデータに依存していた17パーセントポイントです。こうした後知恵は、経済指標の発表、企業のファンダメンタルズ、指数構成銘柄、さらには一見単純な市場データ項目にも潜んでいます。過去データが示すのは、情報源が現在そう言っている内容です。ポイントインタイムデータセットが示すのは、当時、戦略が知り得た内容です。
なぜ、出来事の後に過去データが変わるのでしょうか？
最初は推計値として発表され、後で修正される値もあります。金曜日に発表された経済統計が翌月に改訂されることがあります。企業が決算数値を訂正する場合もあります。データベンダーが誤った値を修正したり、欠損区間を補完したり、速報値を確報値に置き換えたりすることもあります。最新の値しか保存しないデータベースでは、こうした変更が最初からずっと正しかったかのように見えてしまいます。
報告された売上高で企業を順位付けする戦略や、予定されたデータ発表後に市場で取引する戦略では、これは重大な問題です。訂正後の数値を数か月も前から参照できてしまえば、バックテストは意思決定時点で市場に存在しなかった情報を与えたことになります。シグナルの計算に誤りがなくても、入力データは誤った履歴バージョンから取られているのです。
ここにはありがちな落とし穴があります。dateというフィールド名が示しているのは、多くの場合、その値が対象とする期間であり、利用可能になった時刻ではありません。3月31日と記された四半期売上高の行が、実際に公表されたのは5月かもしれません。このラベルが示すのは事業上の対象期間であって、戦略が利用できた情報の範囲ではありません。
バックテストではどのタイムスタンプを使えばよいですか？
値が対象とする有効期間と、その値が利用可能になった時刻を別々に記録しましょう。可能であれば、公表時刻と取り込み時刻も保存します。戦略が値を利用できるのは、公表されてシステムに届いた後です。両者の時刻が異なる場合は、保守的な再現のため、遅い方の時刻を使います。
| タイムスタンプ | 示す内容 | 用途 |
|---|---|---|
| 有効時刻 | 値が指す期間または出来事 | 測定対象ごとに観測値をまとめる |
| 公表時刻 | 情報源がこのバージョンを公開した時刻 | 公開前の情報が利用可能に見えるのを防ぐ |
| 取り込み時刻 | システムがこのバージョンを受信した時刻 | 配信の遅延や遅れて行われる遡及補完を記録する |
たとえば、ある企業の四半期売上が1月から3月を対象とし、5月8日16:15（米国東部時間）に発表され、16:17にリサーチ用データストアへ届いたとします。5月8日の引けで意思決定する戦略は、引け時点の判断が16:00に行われたなら、その報告を使えません。翌朝に判断する戦略なら使えます。四半期末の日付だけでは、どちらの場合も判断できません。
改訂が結果を左右しているか、どう検証すればよいですか？
同じ戦略を2回実行します。1回目は過去の各意思決定時点で利用可能だったデータバージョンを使い、2回目は最新の改訂履歴を使います。執行の前提、ユニバース、コードは固定します。その差は改訂感応度の結果であり、新たな戦略比較ではありません。
次に、その差がどこから生じたのかを調べます。発表日にパフォーマンスが変化していますか？差が大きいのは、訂正された企業や修正された観測値の一部に集中していますか？関連データの公表時刻より前に戦略が取引していますか？イベント単位の小さな監査を行う方が、累積リターンのグラフをもう1つ作るより、多くのことが分かる場合があります。
これらの数値は例示であり、普遍的なペナルティではありません。役に立つのは、自分の戦略について、可能な限り同じ取引とコストを使って比較した結果です。改訂後のバージョンが大幅に優れているなら、見出しのバックテスト結果を信頼する前に、差を生んだフィールドと日付を特定しましょう。
ポイントインタイムデータの監査では何を記録すべきですか？
まず、戦略が実際に利用するフィールドから始めます。それぞれについて、情報源、タイムスタンプの意味、改訂方針、過去のバージョンを取得できるかを確認します。訂正がどのように表現されるのか、ベンダーに尋ねましょう。行の上書き、新しいバージョンの行、別の監査ログのいずれでしょうか。製品ページに「過去データ」と書かれているだけでは、これらの疑問は解決しません。
- 各バージョンを、公表時刻または最初に利用可能になった時刻とともに保存する。
- 期間ラベルではなく、利用可能時刻を使って特徴量を意思決定に結合する。
- 再現可能な実行のため、固定したスナップショットまたは情報源のバージョンを保存する。
- 到着が遅れた値、改訂された値、信頼できる履歴がない値にフラグを付ける。
対象範囲は実用的に保ちましょう。戦略が取引所の約定データとバーだけを使うなら、経済データの改訂は関係ないかもしれません。ただし、バーの訂正やベンダーによる遡及補完は依然として影響する場合があります。特に、流動性の低い市場や厳密なイベント期間に依存するシグナルでは注意が必要です。
ポイントインタイムの履歴を利用できない場合
現在の値を、何も言わずに昨日の値として扱わないでください。そのフィールドを制約事項として明記し、過去に利用可能だったかどうかに依存する主張から除外するか、保守的な遅延を設けて結果がどれほど変わるかを示します。遅延を明示し、その制約を結果にも記載すれば、遅延させた代替値もリサーチに役立ちます。
バックテストの役割は、その時点で存在した情報を使って意思決定を再現することです。データに最新バージョンしか残っていないなら、正直な結果には限界があります。今日再構成した履歴に対して戦略を検証することはできますが、過去の運用者が正確に何を見られたかまでは立証できません。
← 記事一覧
