バックテスト実務でよくあるミス
バックテストとは（そして何ではないのか）
バックテストとは、あらかじめ定めたトレードルール、または意思決定の枠組みを、過去の市場データに適用してみて、どのような結果になり得るかを確認するプロセスです。重要なキーワードは 事前に定めること（predefined） です。バックテストは、実行する前にロジック、入力、計算方法が設定されている場合にのみ意味があります。
バックテストは将来の結果を保証するものではありません。過去の関係性は変わり得て、結果がどれだけ現実的かは、執行（execution）やトレード条件に関するあなたの前提の妥当性に依存します。学習が目的なら、バックテストを計測のための作業として扱ってください。つまり、特定の仮説を、特定のモデル化された条件のもとで検証するのです。
よくあるミスと、それが重要な理由
-
前提と結果を分けないこと よくある誤解は、バックテストの結果を市場の真実だとみなしてしまうことです。実際には、結果はあなたの前提に左右されます。約定（fills）をどうモデル化するか、スプレッドや手数料をどう扱うか、そして注文をどう執行するか、です。これらの前提を明示しないと、2人が「同じ」アイデアを実行しても、異なる結果が得られ得ます。
-
過学習（overfitting）とパラメータ探索 過学習は、ルールが過去データに対してきわめて厳密に調整され、その結果、再現可能な振る舞いではなくノイズを捉えてしまうときに起こります。ひとつの兆候は、同じデータセットで繰り返し改善しているのに、別の場所ではパフォーマンスが落ちていることです。「不正（cheating）」がなくても、バックテストに導かれた反復的な改良によって、プロセスがカーブフィッティングになってしまうことがあります。
-
期間の恣意的な選択（cherry-picking） もうひとつのミスは、有利な履歴だけでテストすることです。これはときに偶然です（たとえば、特定のレジームにたまたま一致する期間を使うなど）。その結果、バックテストは説得力があるように見えるかもしれませんが、広く適用できる効果というより、選択効果を反映している可能性があります。
-
非現実的な執行モデルを使うこと 多くのバックテストは約定を単純化します。たとえば、理想的な価格での完璧な執行を仮定したり、レイテンシ（遅延）を無視したり、スリッページを一定だとみなしたりしますが、それは実際にはそうではないことがあります。こうしたことにより、結果が現実の制約下で得られるよりも強く見えてしまうことがあります。ロジックが妥当であっても、パフォーマンスの計測がずれる可能性があります。
-
コストと実務上の制約を無視すること コストには、手数料、スプレッド、そしてその他の一貫した取引費用が含まれます。制約には、注文を出せる範囲の制限や、ルールがバックテストが想定するタイミングで実際にポジションを生成できるかどうかが含まれます。これらが省略されたり、ゆるく近似されたりすると、リターンが過大に見積もられることがあります。
-
相関のように見える結果を意思決定の質と混同すること バックテストは、ルールというよりデータセットのせいで魅力的に見える結果を生み出すことがあります。たとえば、トレンドのレジームで発動するルールは、インサンプルではうまくいくかもしれませんが、条件が変わると失敗することがあります。よくある失敗パターンは、「良い結果（a good run）」を「安定した意思決定プロセス（a stable decision process）」だと取り違えることです。
期待すべき制限とリスク
最大の制限は、バックテストが現実そのものではなく、現実のモデルであることです。執行、流動性、そして市場のミクロ構造は、時間や環境によって異なり得ます。さらに、過去データが不完全だったり一貫していなかったりすることがあります（たとえば、特定の時間帯の挙動が欠けているなど）。その結果、計測が歪む可能性があります。
2つ目の制限は、パフォーマンス指標がテスト設計に依存することです。データの頻度、リターンの計算方法、処理の順序、あるいはトレードの整列（アライン）の仕方を変えると、結果が変わり得ます。したがって、バックテストのコードが正しくても、結論が頑健（robust）でない可能性があります。
最後に、結果は特定の市場条件や、コストと執行がどう表現されているかによって変わります。そのため、単一のバックテストを最終回答として扱うべきことは、めったにありません。
検証チェック（中立的で自己完結）
バックテスト結果が偶然ではなく頑健かどうかを確認するために、中立的なチェックを使ってください。
- 前提を明示する：スプレッド、スリッページ、手数料、そして注文執行をどうモデル化するかを記録する。
- 評価のためにパラメータを固定する：別のフェーズでのみチューニングし、その後は追加の変更なしで評価する。
- 複数の時間セグメントでテストする：異なる過去のレジームでパフォーマンスを比較する。
- コストと執行に対するストレステストを行う：スリッページの前提を妥当な範囲で変え、結論が変わるかどうかを見る。
- アウト・オブ・サンプル、またはホールドアウト評価を使う：改善が、ルールを作るために使ったデータだけに限って存在するのではないことを確認する。
これらのチェックで大きな不安定さが見られるなら、それ自体が価値ある結果です。つまり、戦略ロジックがモデリングの選択や市場条件に敏感である可能性を示唆します。「失敗」は行き止まりではなく、頑健性に関する情報です。
DOCUMENT END