EAバックテスト初心者が知っておくべきこと

EAバックテストとは（そして何ではないのか）

EAバックテストとは、ルールベースの取引システム（しばしばエキスパートアドバイザー、またはEAと呼ばれます）を取り、過去の価格データにそのルールを適用して、もしどうなっていたかを確認するプロセスです。その結果は将来のパフォーマンスを証明するものではありません。特定のシミュレーション前提のもとで、過去データに対してルールがどのように反応したかを示す証拠です。

バックテストは、ペーパートレードやライブトレードとも異なります。バックテストでは、入力（ヒストリカルデータとモデリングの選択）をあなたが制御します。一方、ライブ市場では入力が異なり得ます。スプレッドが広がり、執行の遅延が起こり、流動性が変化します。

実際にEAバックテストはどう動くのか

ほとんどのバックテストは、同じ基本的な流れに従います。

1. 戦略ルールを定義する。 EAには通常、エントリー／エグジットのロジック、ポジションサイジングのロジック、リスクまたはマネーマネジメントのルールがあります。これらのルールが、どの注文が発動されるかを決めます。

2. ヒストリカルデータを選ぶ。 テストで使われる「ヒストリカル価格」が結果に影響します。データセットに欠損がある、ティックの品質が異なる、EAが想定するバー形成と異なる場合、結果は誤解を招く可能性があります。

3. 執行の詳細をモデリングする。 バックテストでは、スプレッド、コミッション、スリッページ、注文約定、そして価格が表示されたときにストップ／ターゲットが正確にヒットするかどうかについての前提が必要になることがよくあります。ここでの小さな変更が、収益性やドローダウンを左右し得ます。

4. シミュレーションを実行する。 エンジンは時間を進めながらEAルールを適用します。EAがインジケーターを使う場合、それらのインジケーターは、各シミュレーション時点までに利用可能だった情報だけを使って計算されます。

5. パフォーマンス指標を評価する。 よくある指標には、純利益（ネットリターン）、ドローダウン、勝率、そして取引の分布があります。これらの指標を解釈するには、対象期間、含まれているコスト、そしてEAがチューニングされていたかどうかを理解する必要があります。

証拠と例：「良い」結果が生まれる場所

現実的な例は、よくある落とし穴を明確にするのに役立ちます。

• たとえば、EAがある1か月のヒストリカルデータで強く見えるとします。それは、市場のトレンドがEAのロジックと一致していたからかもしれません。そのロジックが安定したモメンタムに依存している場合、同じルールでも、横ばい局面やボラティリティの高いレジームではパフォーマンスが悪化する可能性があります。

• たとえば、バックテストが取引コストを無視、または過小評価しているとします。実際の取引では、スプレッドとコミッションがリターンを減らし、スリッページがエントリー／エグジットの価格を変えます。現実的なコストを含めないバックテストは、結果を誇張し得ます。

• たとえば、EAのパラメータが、単一のデータセットで最大の結果が出るように繰り返し調整されていたとします。これは過学習の解決策を生みやすくなります。つまり、一般的な市場の挙動ではなく、過去の癖を「学習」してしまうのです。

重要な制限と失敗パターン

初心者は、バックテスト結果を前提に条件づけられたものとして扱うべきです。重要な制限には次のようなものがあります。

1. 市場レジームの変化 過去に見えていた関係は、持続しないことがよくあります。戦略ルールが同じでも、市場の振る舞いが変わり得ます。

2. 執行の不一致 約定、スリッページ、ストップ／ターゲットの発動タイミングに関するバックテストの前提は、実際の執行と異なる可能性があります。

3. データ品質とサンプリング ヒストリカルデータは、EAが想定するティックやバーの正確な並びを再現できない場合があります。これにより、インジケーターの値やシグナルのタイミングが変わります。

4. 過学習 パラメータの調整、インジケーターの選択、フィルターが、ある期間に対して繰り返し最適化されると、戦略は脆くなり得ます。

5. サバイバーシップバイアスと選択バイアス（該当する場合） テストが選択的に選ばれた時間窓（たとえば「見栄えの良い」期間だけ）を使っている場合、結果はバイアスを受ける可能性があります。

関連する事実を独立に検証する方法

実務的な管理ポイントは、バックテストが、明確な前提のもとで検証可能な質問に答えているかを確認することです。

次の検証ステップを考えてください。

• 一貫した入力でテストを再現する。 同じヒストリカルデータセットと同じEA設定で、同じ出力が得られるか確認します。

• 重ならない複数の時間期間を使う。 異なる年（または少なくとも異なる市場状況）にまたがってテストすることで、結果が1つのレジームに依存しているかどうかが見えやすくなります。

• 現実的なコストと執行設定を含める。 バックテストが、コミッションやスプレッドのようなコストをモデリングしていない（そして、関連する場合にスリッページの前提を含めていない）なら、結果は不完全だと考えてください。

• 感度（センシティビティ）をストレステストする。 パラメータや執行モデリングを少し変えるだけで結果が大きく変わるなら、それは脆さを示します。

• 学習（トレーニング）と検証（バリデーション）のロジックを比較する。 パラメータがある期間で最適化されていた場合、チューニングに使われていない別の期間で検証します。

DOCUMENT END