EAバックテスト曲線が良く見えても、まずこれらのテスト条件を確認する

著者：トーマス｜EAとプラットフォーム実務｜2026年10月6日

上向きのバックテスト曲線は、プログラムがどのような条件で動作したかを説明するものではなく、ましてやそのまま実運用の成績を表すものでもない。ゴールドEAを比較する場合、まずテスト条件を確認してから結果を読むほうが、純利益が最も高いレポートだけを選ぶより有用である。本記事では通常のMT4テスターについて述べ、MT5や第三者製テストツールの機能と混同しない。

まず、再確認できるテスト記録を保存する

テストを実行する前に、EAのバージョン、パラメータファイル、完全な銘柄名、チャート周期、日付範囲、初期資金とその通貨、データソースとターミナルのバージョンを保存しておく。パラメータや条件を変更するたびに理由を記録し、結果を見てから最も良い1回だけを保存しない。

これらの記録の目的はレポートのページ数を増やすことではなく、テストが実際に何を比較したかを他の人が把握できるようにすることである。2つの曲線は見た目が似ていても、契約条件、数量、資金の基準が異なれば、直接比較できない可能性がある。レポートに欠けている条件は不明と明記すべきであり、推測で補ってはならない。

モデリング方式は、プログラムのロジックに対応している必要がある

MT4の公式ヘルプには、異なる履歴モデリング方式が記載されている。始値のみでテストする場合と、バー内の価格変動に依存するプログラムでは、同じトリガー過程を反映できない可能性がある。方式を選択する際は、EAが完成したローソク足の形成後に判断するのか、それとも同じローソク足内部の価格、決済、注文の変化に依存するのかを先に確認すべきである。

公式説明におけるEvery tickモードも、より小さい周期のデータと補間を用いて価格変動を生成しており、自動的に完全な過去の実際のティック単位の約定記録と等しいわけではない。「Every tick」という文言を見ただけで、すべての市場の詳細が再現されたと判断してはならない。第三者データや追加ツールを使用する場合は、その出所と方法を別途説明すべきである。

スプレッドの前提は、歴史的な約定環境と同じではない

MT4の公式ヘルプによると、通常のテスターはデフォルトでテスト開始時の銘柄の現在スプレッドを使用してAskをシミュレートし、Spreadフィールドでカスタム値を設定することもできる。これは、テストのスプレッド前提を明確に記録する必要があり、固定の前提を過去期間全体の実際の変動スプレッドと見なしてはならないことを意味する。

経済指標発表時、流動性の変化、異常な時間帯の約定条件は、一組の固定設定で十分に反映できるとは限らない。手数料、スワップ費用、その他の執行への影響についても、具体的なレポートとツールが考慮しているか、どのような基準を採用しているかを確認すべきである。シミュレートされていない部分は明確に説明し、「バックテスト済み」でこれらの確認を代替してはならない。

最適化結果は、特定条件下での順位付けにすぎない

MT4の最適化結果は、異なるパラメータ組み合わせの利益、取引数、ドローダウン、期待収益などの統計項目を表示できる。1位であることは、その組み合わせが選択した範囲と条件下で相応の指標に達したことを示すが、将来も1位であり続けることを意味しない。

分析する際は、最良の行だけを見るのではなく、近傍のパラメータを少し変えただけでまったく異なる結果が現れないかも観察する。パフォーマンスが非常に狭い組み合わせにのみ集中している場合、結論が設定に敏感である可能性を示すが、この現象だけでプログラムが必ず機能しないと断定することはできない。ロジック、データ、テスト条件を引き続き確認し、有利な結果も不利な結果も保持すべきである。

パラメータ調整に使用していないデータを確保し、改めて確認する

パラメータ調整に使用する期間と、調整に参加させない独立した検証期間をあらかじめ区分できる。区分方法と評価指標は、検証結果を見る前に決定すべきである。検証後に同じデータ区間を繰り返し使ってパラメータを変更すると、そのデータ区間はもはや完全に独立した検証ではなくなる。

これは研究上の取り決めであり、利益を保証する認証プロセスではない。異なる市場状態におけるサンプル数、保有エクスポージャー、結果の差異は依然として記録する必要がある。一度の独立した検証で利益が出たからといって、サンプル不足や単一環境しかカバーしていない問題を無視してはならない。

条件が変化したときは、前後の対照を保持する

他の条件を同じに保ったまま、1つの明確な前提を変更して結果を比較することは、プログラムの条件に対する感度を発見するのに役立つ。変更内容、根拠、テスト結果、カバーされていない制限を記録すべきであり、「より安定」といった検証困難な評価だけを示してはならない。

シミュレーション運用は、プログラムの流れを確認し、実際のクォート環境を記録するために使用できるが、シミュレートされた約定は依然として実運用と等しくない。いかなる運用段階に入る前にも、異常注文、接続切断、ポジションのずれ、損失が制限に達したときの確認手順を明確にすべきであり、バックテスト曲線を継続させるためにその場でルールを緩めてはならない。

最後に結論を条件文として書く

明確な要約には、どのようなデータ、パラメータ、費用前提の下で、どのような結果が観察されたか、どのリスクがカバーされていないか、さらに何を検証する必要があるかを記載すべきである。未知の事項をそのまま残すことは、研究結果を収益保証として包装するよりも、その後の再確認に役立つ。

レバレッジ取引は重大な損失を引き起こす可能性がある。本記事はEAテストと研究方法の説明を目的としており、プログラムの購入、取引、ポジションに関する助言を構成しない。バックテスト、シミュレーション、最適化の結果はいずれも、実運用の安全性や将来の収益を保証するものではない。