EAのパラメータ最適化とは？過剰最適化に陥らないための考え方

「バックテストのPFが3.0を超えた。これは良いEAができたということか？」

EA開発を始めたばかりの頃、こういう状況に何度も直面しました。

結論から言います。

バックテストのPFが高すぎるEAは、むしろ危険です。

PFが高いのはロジックが優れているからではなく、過去のデータに「完璧にフィット」するようにパラメータを調整しすぎた結果である可能性が高いです。これが過剰最適化（カーブフィッティング）です。

EA-LabではGENESIS・凜・AXISの開発を通じて、パラメータ最適化と過剰最適化の問題に何度も向き合ってきました。

「どこまで最適化すべきか」「どこから過剰最適化になるのか」という判断基準を、開発の実体験をもとに解説します。

パラメータ最適化とは何か

EAには様々なパラメータ（設定値）があります。

BOXブレイクアウトであれば「何本のローソク足でBOXを形成するか」「SLは何pipsか」「TPは何pipsか」といった数値です。トレンドフォローであれば「移動平均線の期間」「ATRの倍率」などです。

パラメータ最適化とは、バックテストの結果が最も良くなるようにこれらの数値を調整する作業です。

MT5のストラテジーテスターには「最適化」機能があります。指定した範囲の全パラメータの組み合わせを自動で試して、最もPFが高くなる・DDが小さくなる組み合わせを見つけてくれます。

便利な機能です。しかしこの機能が過剰最適化を生む温床にもなります。

過剰最適化が起きるメカニズム

過剰最適化とは「過去データにだけ完璧にフィットしたEAができあがってしまうこと」です。

なぜこれが問題なのか。

過去のデータは変えられません。そのデータに完璧にフィットしたEAを作ることは、原理的に可能です。パラメータを細かく調整し続ければ、バックテストでPF5.0・DD2%のような数値を作れます。

しかしそのEAは「過去のデータを暗記した」だけです。未来の相場に対応する能力は全くありません。

フォワードに入った瞬間に崩れます。

過去の特定の動きに最適化されたルールは、相場環境が少し変わっただけで機能しなくなります。これが過剰最適化の本質的な問題です。

GENESIS開発で過剰最適化の誘惑に勝てなかった話

正直に言います。GENESIS開発の初期、過剰最適化の誘惑に何度も負けかけました。

MT5の最適化機能を使ってパラメータを調整すると、みるみるPFが上がります。「もう少し調整すれば…」という誘惑が常にありました。

あるとき、最適化を重ねてバックテストのPFが2.5を超えたことがあります。「これは良いEAができた」と思いました。

しかしその数値をよく確認すると、問題が見えてきました。

取引数が大幅に減っていました。フィルターを厳しくした結果、エントリー条件が非常に限定的になっていたのです。取引数が少ないということは統計的な信頼性が低いということです。

さらにウォークフォワードテスト（後述）を試すと、バックテストと全く異なる結果が出ました。

この経験から「PFが高くなるほど疑ってかかる」という姿勢を徹底するようになりました。

過剰最適化のわかりやすいサイン

過剰最適化に陥っているかどうかを判断するサインがあります。

①バックテストのPFが異常に高い

PF2.0以上、特にPF3.0を超えている場合は過剰最適化の可能性が高いです。EA-Labの開発目標PF1.2前後というのは、長期フォワードで現実的に再現できる水準として設定しています。

②取引数が極端に少ない

最適化を重ねると、エントリー条件が厳しくなって取引数が激減することがあります。10年バックテストで取引数が100回以下のような場合は、統計的な信頼性が低いです。

③パラメータが細かすぎる

「BOX期間が23本のとき最もPFが高い」というような、細かい数値に最適解が出ている場合は過剰最適化を疑います。23本と24本でPFが大きく変わるなら、それは本質的なロジックではなく過去データへの過剰適応です。

④異なる期間でバックテストすると結果が大きく変わる

2010〜2020年のデータで最適化したパラメータを使って2015〜2025年でバックテストすると、全く異なる結果が出る場合は過剰最適化の可能性があります。

バックテストの信頼性についてはこちらで詳しく解説しています。

過剰最適化を防ぐためにEA-Labがやっていること

EA-Labでは過剰最適化を防ぐためにいくつかの方針を徹底しています。

①パラメータの数を最小限にする

パラメータが多いほど過剰最適化のリスクが上がります。GENESIS・凜・AXISはいずれも「必要最低限のパラメータだけ使う」という設計思想です。

不要な条件・フィルターは積極的に削ります。「あった方が良さそう」という直感でパラメータを増やすことをしません。

②ロバストネステストを行う

最適化で得られたパラメータの前後の値でもバックテストを行い、結果の安定性を確認します。

たとえばBOX期間の最適値が20本だったとして、18本・19本・21本・22本でもある程度良い結果が出るかを確認します。ピンポイントの値でだけ結果が良い場合、そのパラメータは過剰最適化の可能性があります。

③長期バックテストで検証する

EA-Labでは基本的に10年バックテストを実施しています。

長期であればあるほど様々な相場環境が含まれます。特定の相場環境だけに最適化されたパラメータは、長期バックテストで崩れやすいです。

④サンプル外データで検証する

最適化に使ったデータとは別の期間のデータで検証します。たとえば2010〜2020年のデータで最適化したパラメータを、2020〜2025年のデータで検証します。この検証で良い結果が出ないパラメータは採用しません。

カーブフィッティングの詳しい解説はこちらで確認できます。

凜の開発で学んだ「シンプルさの価値」

凜のアノマリー型ロジックの開発では、過剰最適化のリスクを特に強く意識しました。

アノマリーとは統計的な偏りです。その偏りが「どの時間帯か」「どの曜日か」という条件で発生することが前提になります。

開発初期、「この条件も加えればPFが上がる」という誘惑に何度も直面しました。

祝日の扱い、特定のニュースがある日の除外、時間帯のさらなる絞り込み。条件を追加するたびにバックテストのPFは上がりました。

しかしそれは「過去のデータに存在した偶然の規則性」を拾っているだけです。未来の相場でその条件が同じように発生する保証はありません。

最終的に凜のロジックは「削れるだけ削ったシンプルな条件」に落ち着きました。

シンプルなロジックほど、過去の特定期間への依存度が下がります。相場環境が変わっても、本質的な統計的偏りが残りやすくなります。

「条件を増やすこと」より「本質的な優位性を残すこと」を優先する。

これが凜の開発から得た最大の学びです。

最適化は「ゼロ」でも「過剰」でもダメ

ここまで過剰最適化の危険性を説明してきましたが、誤解してほしくない点があります。

パラメータの最適化自体は必要な作業です。

全く最適化しないEAは、ロジックの可能性を活かしきれていない状態です。SLとTPのバランスを確認する、BOX形成の期間を検証する、これらは必要な作業です。

問題なのは「やりすぎること」です。

適切な最適化とは「ロジックの本質的な優位性が発揮される範囲でパラメータを調整すること」です。過剰最適化とは「過去データに完璧にフィットさせるためだけにパラメータを調整すること」です。

この境界線は曖昧です。だからこそ、上述したサインを確認しながら判断する必要があります。

EAを買うときにも過剰最適化を疑う

過剰最適化の問題は自分でEAを開発するときだけでなく、EAを購入するときにも重要な視点です。

販売されているEAのバックテスト結果を見て「PF3.0以上・月利30%以上・DD3%以下」という数値が出ていたら、まず過剰最適化を疑ってください。

現実的な長期運用で再現できる数値ではありません。

EA-LabがPF1.2前後を開発目標にしているのは、地味に見えてもフォワードで再現できる現実的な水準だからです。

EAを選ぶときのチェックポイントはこちらで解説しています。

バックテストの正しい見方はこちらも参考になります。

まとめ

パラメータ最適化と過剰最適化の違いをまとめます。

適切な最適化はロジックの本質的な優位性を発揮させるための調整です。過剰最適化は過去データへの過剰適応であり、フォワードで崩れます。

過剰最適化を防ぐためにEA-Labが実践していることは、パラメータの最小化・ロバストネステスト・長期バックテスト・サンプル外データでの検証の4点です。

GENESIS・凜・AXISの開発を通じて確信したのは「シンプルなロジックほど長期で機能する」ということです。

バックテストのPFを高くすることを目指すより、フォワードで再現性のある数値を維持することを優先する。これがEA開発・EA選びの本質です。