バックテストで、市場に一度も表示されていない価格で約定したと記録されることがあります。多くの場合、シミュレーターが不完全なデータから、もっともらしい執行価格を推定しているためです。たとえば、バーの高値や安値、ミッド価格、あるいは1件の取引で付けた指値です。その結果、取引ログは正確そうに見えても、市場で実際に提示されていた価格が分からなくなります。
まず、自分の注文がどの価格と取引できたのかを考えます。最終取引価格のバーで分かるのは、一定の時間内にどの価格で取引があったかです。注文が到着した時点の買い気配と売り気配、その価格でどれだけの数量があったか、注文がキューの先頭に進めたかは分かりません。
バックテストで、市場価格の範囲外の約定が表示されるのはなぜ？
まず、「範囲外」が何を指すのかを明確にしましょう。バーの安値より低い買い約定や、高値より高い売り約定は、明らかな会計処理またはタイミングの誤りです。一方、高値と安値の間の約定でも、実際には起こり得ない場合があります。注文が出される前にその価格で取引されていたり、スプレッドの反対側で付いた価格だったり、注文を全量約定させるには数量が少なすぎたりすることがあります。
始値100.00、安値99.80、終値100.10の1分足を考えてみましょう。戦略が確定済みのバーを確認して買い注文を出し、シミュレーターは99.80で約定させます。その安値は、シグナルの50秒前、1分足の始まり近くに付いたのかもしれません。このバーからは、判断後に99.80で取引できた証拠は得られません。
| 利用できるデータ | 分かること | 分からないこと |
|---|---|---|
| OHLCVバー | 時間区間内に観測された取引価格の範囲と出来高 | 価格の推移、買い気配と売り気配、注文到着時点の流動性 |
| 約定履歴 | タイムスタンプと価格が記録された取引 | 板に残っている流動性やキュー内での自分の順位 |
| 最良気配値 | 各観測時点で表示された最良買い気配と最良売り気配 | 最良気配より深い価格帯の板、または観測の合間も気配が維持されたかどうか |
| 板のイベント | 配信範囲内で観測された表示数量の変化とキューの動き | 非表示の流動性、取引所へのアクセス、優先順位の保証 |
もう1つよくある原因は、ミッド価格と実際に約定可能な価格を混同することです。買い気配が99.99、売り気配が100.01のとき、100.00のミッド価格で買えたとすると、レポート上は見栄えよくまとまります。しかし、成行性のある買い注文では通常、売り気配を支払ううえ、注文量によっては価格インパクトも加わります。ミッド価格を約定価格とみなすと、スプレッドの半分がいつの間にか消えてしまいます。
市場が指値に触れただけで、指値注文は約定する？
価格に触れたということは、その指値で取引が成立した証拠です。しかし、板に残していた自分の注文が約定した証明にはなりません。自分の注文より前に他の注文があれば、その価格での取引数量が自分のキュー順位に届くほどなかった可能性があります。また、約定が別の取引所で発生し、自分の注文は別の場所に出ていた場合もあります。
買い指値を50.00に置いた後、市場でその価格の取引が200株成立したとします。価格に触れれば約定するとみなすシミュレーターは、500株すべてを約定させます。より慎重なモデルでは、注文到着後に50.00以下で取引された数量を確認し、前方に並ぶキューの推定数量を考慮します。注文単位の板データがなければ、そのキューは仮定にすぎません。確実な事実のように扱わず、結果の中で見えるようにする必要があります。
小規模なリサーチシステムなら、ローソク足データからキュー内の優先順位が分かるふりをせず、その仮定を明示して幅を持たせて検証する方がよいでしょう。適切な幅は、取引所、注文量、戦略の取引頻度によって変わります。寄り付きの静かな株式と、03:00 UTCの流動性が薄い暗号資産のコントラクトでは、執行の問題が異なります。
バーのデータには、どの約定モデルを選べばよい？
データと戦略が主張する内容の両方に合ったモデルを選びます。バーを使うバックテストも、取引頻度の低い戦略には役立ちます。ただし、約定の扱いはバーから実際に分かる範囲に沿わせましょう。
- 判断時刻と注文到着時刻を設定する。バーの終値を使ってシグナルを計算するなら、その終値が確定してから注文を出します。執行価格は次に利用できる時間区間や気配値をもとにモデル化し、確定済みバーの過去の安値は使いません。
- スプレッドの正しい側を使う。成行性のある買い注文は売り気配から、売り注文は買い気配から始めます。取引バーしかない場合は、別の情報源からスプレッドを推定するか、モデルがスプレッドを考慮していないと明記します。
- 妥当な流動性に応じて約定数量を制限する。観測出来高に対する参加率の上限を設け、手数料と価格インパクトも含めます。バー全体の出来高が、そのすべてを指定価格で取引できたことを意味するわけではありません。
- 仮定にストレスをかける。次の始値での約定に保守的なスリッページを加えた場合と比較し、執行条件を悪化させても結果が維持されるか確かめます。戦略の成績が上がるまで約定モデルを調整するのはやめましょう。
これらはモデル化の選択肢であり、不完全なデータから唯一の正しい約定を復元する方法ではありません。戦略の成否が数ベーシスポイントの獲得にかかっているなら、その主張を裏付ける証拠としてバーのデータは不十分かもしれません。
あり得ない約定がバックテストのどこで入り込んだか、どう突き止める？
疑わしい取引を1件選び、シグナルから台帳まで追跡します。判断時刻、注文送信時刻、シミュレーション上の到着時刻、参照した市場データ、約定価格、約定数量、手数料をそれぞれ別の項目に記録します。そのうえで、次の順に確認します。
- 判断時点でまだ確定していないバーのデータを使って特徴量を計算していなかったか？
- その価格が注文到着前に付いていたのに、バーの高値、安値、または終値で約定させていなかったか？
- 買い注文を買い気配に、または売り注文を売り気配にマッチさせていなかったか？
- シミュレーション上の数量が、利用可能な気配数量やモデルの参加率上限を超えていなかったか？
- 約定価格を決めた後に、価格の丸め、コントラクトの呼値単位、手数料を適用していなかったか？
取引記録からこれらの質問に答えられないなら、バックテストには執行の証拠が不足しています。項目を追加し、いくつかの取引を生データと照らして手作業で再現し、意図したモデルのもとで記録された価格が実際に約定し得たか確認します。損益曲線がきれいでも、シミュレーター内にしか存在しなかった価格は見つかりません。
← 記事一覧
