スプレッドの前提
スプレッドの前提とは？
スプレッドの前提とは、フォレックスのバックテストおよびフォワードテストで取引結果を計算するときに、ビッド–アスク・スプレッドについて行う簡略化した選択のことです。スプレッドとは、提示されているビッド価格（通常は売却できる価格）と、提示されているアスク価格（通常は購入できる価格）の差です。バックテストでは、すべてのライブ執行の詳細が揃わないことがあります（特に正確なタイムスタンプ、板の状態、そしてブローカー固有の取り扱い）。そのため、スプレッドを「仮定」します。多くの場合、固定値、ルール、または導出した時系列などです。そして、それを使ってシグナルを現実的なエントリー価格と決済価格へ変換します。
役に立つ考え方として、スプレッドの前提は摩擦モデルの一部です。これは、ポジションを建てるときと決済するときに、ビッドからアスクへ（そしてその逆へ）またぐことによるコスト影響を表します。
スプレッドの前提はどう機能するか
ほとんどのバックテスト・エンジンでは、シミュレーションされた各フィル（約定）に対して具体的な価格が必要です。スプレッドの前提は、ミッド価格（またはクオートの片側）を両側へマッピングすることで、その不足している詳細を補います。
よくあるパターンは次のとおりです：
- 固定スプレッド：すべての取引で同じスプレッド値を使います。簡単ですが、流動性と執行条件が安定していることを前提にします。
- 時間/セッションによるスプレッド：市場の時間帯ごとに異なるスプレッドを使います（たとえば、主要な重なり時間と、より静かな時間帯を比較するなど）。これは、流動性が時間によって変わりやすいことを反映しています。
- 過去データからのスプレッド時系列：スプレッドを時間に沿って推定し、各シミュレーション取引に適用します。現実に近づきますが、それでもデータの品質と、執行タイミングとの整合性に依存します。
- ルールに基づく調整：想定されるスプレッドが広がる局面（たとえばボラティリティが高いとき）では、スプレッドの前提を増やします。ポイントは、そのルールが、テストでどのように注文執行を表現しているかと一貫している必要があることです。
実務上、スプレッドの前提は少なくとも3つのメカニズムを通じて結果に影響します：
- エントリー価格の変換：バックテストがミッド価格を使う場合、アスクへ到達するために仮定したスプレッドの半分を加え、ビッドへ到達するために半分を引くことで、初期のフィルが決まります。
- 決済価格の変換：同じマッピングが、ポジションをクローズするときのフィルにも影響します。
- タイミングへの感度：実際のスプレッドが拡大するタイミングで取引しているのに、データセットがそれを平滑化している場合、仮定したスプレッドは取引コストを過小評価または過大評価する可能性があります。
バックテストの結果は、スプレッドの変化に対するフィルのタイミングに依存するため、仮定したスプレッドがどのように構築されているかと、バックテストのタイムスタンプのロジックが一致していることが重要です。同じスプレッドのデータセットを使っていても、整合しないと体系的なバイアスが生じ得ます。
制約とリスク
スプレッドの前提によって、テストがライブ取引より良く（または悪く）見えることがあります。主な制約は、「仮定したスプレッド」が自動的に「実際に経験したスプレッド」と一致するわけではない点です。
主な不確実性には次が含まれます：
- ブローカーと取引会場の違い：過去の市場クオートで観測されるスプレッドが、実際に注文が約定する際のスプレッドと一致する保証はありません。マッチングは、執行モデルとデータソースに依存します。
- 流動性とボラティリティのレジーム転換：流動性が低下したりボラティリティが上昇したりすると、スプレッドは広がりやすくなります。落ち着いた局面に合わせて調整したモデルは、条件が変わると不正確になり得ます。
- 執行タイミングの不一致：バックテストは通常、特定のタイムスタンプでフィルをシミュレーションします。仮定したスプレッドが、シミュレーションされたフィル時刻よりも粗い間隔でサンプリングされている場合、急速なスプレッド拡大を見逃す可能性があります。
- データの代表性：過去データが真のビッド–アスクの挙動を捉えていない場合（たとえば導出、集計、または古いデータである場合）、スプレッドの前提はその制約を引き継ぎます。
- 単純化への過信：固定スプレッド値は、コストの変動を隠してしまうことがあります。これにより、フォワードテストでスプレッドの挙動が異なると、ドローダウンやパフォーマンス上の想定外が起きる可能性があります。
独立した検証アプローチ
スプレッドの前提はモデリング上の選択であるため、独立して確認できる根拠を使って検証すべきです：
- 仮定したスプレッドの挙動を、同じ銘柄と一般的な時間帯における実際に観測されたスプレッド統計と比較する。
- 感度チェックを実行する（たとえば、スプレッドの幅を複数の範囲でテストし、結論が狭いコスト推定に依存していないかを確認する）。
- フォワードテストでは、すべての取引結果が完全に一致するかどうかよりも、スプレッド関連のコスト効果が前提と一致しているかに注目する。
これはリスクをなくすわけではありませんが、コストモデリングをより反証可能にします。
バックテストとフォワードテストの文脈におけるスプレッドの前提
バックテストは遡及的であり、価格、スプレッド、執行モデリングの忠実度によって制限されます。フォワードテストは追加の現実確認を加えます。執行条件は変化し得て、実現したスプレッド分布が過去の前提と異なる可能性があります。
実務的な結論として、スプレッドの前提はテスト設計における明示的なパラメータとして扱うべきです。妥当な範囲内でスプレッドの前提を調整したときに結果が大きく変わるなら、戦略はシグナルの挙動だけでなく、取引コストのモデリングに敏感である可能性があります。
結論：覚えておくべきこと
スプレッドの前提は、フォレックスのバックテストおよびフォワードテストにおける取引コストをモデリングするための中核となる入力です。提示された価格情報を、ビッド/アスクを意識したシミュレーション約定へ変換します。最大のリスクは、流動性、ボラティリティ、執行タイミングの違いによって、仮定したスプレッドと実現したスプレッドが一致しないことです。前提をテスト用パラメータとして扱い、そのうえで、検証できるデータを使って検証し、ストレステストしてください。
DOCUMENT END