EA最適化では最高成績の一点だけを見ると、過剰最適化を見逃しやすくなります。周辺パラメータでも成績が維持される「台地」を確認し、MT5の最適化結果から頑健性を評価する手順と実務上の注意点を具体的に整理します。
最高成績の一点だけでは頑健性を判断できない
EAの最適化では、利益やSharpe Ratioが最も高いパラメータを選びたくなる。しかし、その一点だけが突出して良い場合、過去データの偶然に適合した可能性を排除できない。
重要なのは、最良値そのものではなく、その周辺でも似た成績が得られているかである。パラメータを少し動かしただけで損益が急変する戦略は、実運用で市場環境がわずかに変化しただけでも性能が崩れやすい。
このため最適化結果を見る際は、「ピーク」よりも広い範囲で成績が維持される「台地」を探す考え方が有効になる。
パラメータ空間を面として見る
たとえば移動平均期間を10から60まで、損切り幅を50から300ポイントまで変化させるとする。各組み合わせについて純利益、最大ドローダウン、取引数、Profit Factor、Sharpe Ratioなどを記録すれば、最適化結果は一つの表ではなく二次元の面として扱える。
ここで確認したいのは、最高値の座標ではない。隣接する複数の組み合わせでも、同程度の成績が連続しているかである。
仮に期間37、損切り幅145だけが極端に良く、36や38、140や150では急激に悪化するなら、その設定は不安定と解釈できる。一方、期間30〜40、損切り幅130〜170の広い範囲で似た成績が続くなら、局所的な偶然への依存は相対的に小さい。
MT5のStrategy Testerでは、最適化結果を2D・3Dで確認できるため、このようなパラメータ空間の連続性を視覚的に確認できる。
台地を数値で定義する
見た目だけで判断すると再現性が落ちるため、台地を数値で定義すると扱いやすい。
一例として、最良結果に対して純利益が80%以上、最大ドローダウンが基準値以下、取引数が一定以上という条件を設定する。その条件を満たす組み合わせが周辺に何個存在するかを数える。
さらに、隣接するパラメータへの感応度も確認する。パラメータを1ステップ動かしたときの評価値の変化率が小さいほど、局所的な変化に対して頑健とみなせる。
評価値は純利益だけに限定しない方がよい。利益が高くても取引数が少なすぎる場合や、ドローダウンが急増する場合は、安定性の評価を誤る可能性がある。複数指標を組み合わせて条件を設定する方が、実運用に近い。
最適化幅と刻み幅にも注意する
台地の有無は、探索範囲とステップ幅によって見え方が変わる。
たとえば期間を5刻みでしか試していない場合、その間に急峻なピークが存在しても検出できない。逆に刻み幅を細かくしすぎると、組み合わせ数が急増し、偶然良い結果を拾う機会も増える。
まず粗いグリッドで全体構造を確認し、その後に有望な領域だけを細かく探索する二段階方式が実務的である。
また、最適化するパラメータ数を増やしすぎると探索空間が急速に拡大する。自由度が増えるほど過去データに合わせ込めるため、必要性の低いパラメータまで最適化対象にしないことも重要になる。
Forward期間で台地が残るか確認する
パラメータ安定性は、バックテスト期間内だけで確認して終わりではない。
MT5にはForward testingがあり、指定期間をバックテスト側とForward側に分割できる。最適化で得られた候補を未使用期間で再評価することで、過剰最適化を検出しやすくなる。
ここでも見るべきなのは「最良パラメータがForwardでも一位だったか」ではない。バックテストで形成されていた台地の周辺設定が、Forward期間でも一定の成績を維持しているかを見る。
順位が多少入れ替わっても、同じ領域の複数設定が残るなら構造的な安定性を示す材料になる。逆に、バックテストの最適値だけが崩れ、周辺もまとめて悪化するなら、過去データへの依存を疑う余地が大きい。
実運用前に残すべき記録
検証では、採用したパラメータだけでなく、周辺の結果も保存しておく。
最低限、探索範囲、刻み幅、評価指標、上位設定、周辺設定の成績、Forward結果を記録する。可能であれば、パラメータごとの損益差やドローダウン差も残す。
こうした記録があれば、後に成績が悪化した際、それが通常の変動なのか、パラメータ依存性が顕在化したのかを比較しやすい。
最適化は「最も良い数字を探す作業」ではなく、「どの範囲なら性能が大きく変わらないかを測る作業」と捉えた方が、EA検証として再現性が高くなる。
まとめ
EAのパラメータ評価では、最高成績の一点より、周辺でも似た結果が続く台地の存在が重要である。2D・3Dの最適化結果、隣接設定への感応度、複数評価指標、Forward期間での持続性を組み合わせれば、過剰最適化をより構造的に確認できる。
採用すべき設定を直接示すのではなく、パラメータを動かしたときに性能がどの程度変化するかを測る。この視点を持つことで、バックテストを単なるランキングではなく、頑健性を検証するためのデータとして利用できる。
