FXのオーバーフィッティング（カーブフィッティング）とは？対策やバックテスト時の注意点などを解説

---

オーバーフィッティング問題はシステムトレードで実際に利益を上げることの大きな障害の一つです。
優位性のある戦略を見つけることも重要ですが、システムに優位性があるのかないのかをある程度の精度で見分けることができなければ利益に繋げることはできません。
この記事ではオーバーフィッティングをできるだけ回避し、システムの本質を見抜くためのバックテスト方法を解説します。

見せかけの優位性

価格変動が非ランダムとなる周期や条件を検出し、そのタイミングで適切な方向にポジションを持てるシステムが、実運用で利益を上げられます。
ポジションを持っている間の価格変動がランダムウォークである場合や、ポジションを持つ方向を見つけられなければ、どのようなロジックにも優位性は生まれません。

システムの開発では、パラメータの最適化やロジックの修整、フィルターの追加などの目的で、同じヒストリカルデータを何度も往復する必要が生じることがあります。
何度も往復するうちに、システムの設定がランダムウォークなど予測できるはずのない値動きにカーブフィッティングしていくことで、再現性のない見せかけの優位性を持つことになります。
当然、これは再現性がないのでフォワード期間では全く通用しません。

アウトオブサンプルテスト

オーバーフィッティング対策として広く使用され、有効なアプローチにアウトオブサンプルテストがあります。
同じヒストリカルデータを何度も往復することがオーバーフィッティングの原因なのであれば、何度も往復するシステムの調整期間とは別枠で、1度しか通過しないシステムのテスト期間を残しておくことが、現実的な検証データを集めるための有効な手段であると考えられます。

バックテストの目的は検証であり、システムの調整ではありません。
優位性のないシステムを切り捨てるためのバックテストであるべきで、システムを改善するためのバックテストであってはいけません。
システムの調整で使用したデータの中から納得いくパフォーマンスを出したものを選び、あたかも過去のパフォーマンスであるかのように取り扱うこと自体に問題があるのです。

アウトオブサンプルテストの代表的な手法にウォークフォワード法があります。
画像は2013年始から2022年末までのヒストリカルでウォークフォワードテストを実施した例です。

青はシステムの最適化する訓練期間(インサンプル)で、緑がテスト期間(アウトオブサンプル)です。

• 1．2013～2016年で最適化、2017年でテスト
• 2．2014～2017年で最適化、2018年でテスト
• 3．2015～2018年で最適化、2019年でテスト
• 4．2016～2019年で最適化、2020年でテスト
• 5．2017～2020年で最適化、2021年でテスト
• 6．2018～2021年で最適化、2022年でテスト

このような手順でバックテストを行うことで現実のトレードに近い状況を再現し、2017年から2021年までのテストデータを集めることができます。

訓練データ(インサンプル)はヒストリカルを何度も往復した非現実的なデータなので、このデータはシステムの評価のためには使わず、システムの評価はテストデータ(アウトオブサンプル)のみで行うことが非常に重要です。

ウォークフォワード法で集めたアウトオブサンプルデータ(緑)に確かな優位性があるなら、その延長線上にある実運用期間(赤矢印)での利益にも期待できます。

2種類のオーバーフィッティング

最適化はインサンプルのパフォーマンスを上げるために利用するものではなく、アウトオブサンプルで機能するパラメータを見つけるために利用するべきです。
インサンプルでの最適化の結果、発見したパラメータがアウトオブサンプルで機能しなくては意味がないからです。

インサンプルとアウトオブサンプルのどちらにもオーバーフィッティングします。

インサンプルにオーバーフィッティングしている場合、インサンプル内ではシステムはロジックとは無関係な値動きやノイズまで予測してしまっている状態となります。
予測できるはずのない値動きは、当然アウトオブサンプルでは予測できないため、インサンプルで発見したパラメータとアウトオブサンプルの最適なパラメータに大きな誤差が生じます。

アウトオブサンプルがオーバーフィッティングする原因について考えてみます。

ウォークフォワードテストを行ったあとに新たにアイデアが浮かび、ロジックを変更してもう一度ウォークフォワードテストを行ったとします。
ヒストリカルを何度も往復することでオーバーフィッティングすると説明しましたが、このようにウォークフォワードを2度繰り返すことは、テスト期間をロジック変更の前後で2回通過し、結果を見てからロジックを選択してしまっているのです。
パラメータの最適化がロジックの最適化に置き換わっているだけなので、開発者が気付かないうちにテストデータが訓練データになってしまっているわけです。

もうひとつ例を挙げます。
システム開発、バックテストという流れを合計100回行い、そのほとんどが開発者の納得いく検証結果ではなかったですが、ごく少数のシステムは開発者の納得いく基準を満たしているとします。
ここで、本来は優位性のないシステムが偶然ヒストリカルデータのノイズ等に当てはまって納得いく基準を満たしてしまう確率が1%だと仮定します。
つまり、合計100回のバックテストの内、およそ1回は優位性ないシステムを優位性ありと誤判定してしまいます。
これではオーバーフィッティングしているときと同じように、予測できるはずのないものを偶然予測しているので、実運用での成績と乖離します。

インサンプルのオーバーフィッティング対策

インサンプルのオーバーフィッティングしやすさはサンプルサイズとシステムの複雑さに影響します。
インサンプルのオーバーフィッティング対策を考察します。

対策1：サンプルサイズを大きくする

サンプルサイズ(最適化期間の取引回数)が小さすぎるとノイズなどの影響が大きくなり、最適化結果が極端な上振れや下振れを起こします。
ノイズの影響は十分なサンプルサイズがあれば小さくなっていきます。
サンプルサイズが大きいときなら問題ないですが、サンプルサイズが小さいときは偶然の振れ幅が大きくなることを見積もる必要があります。

グラフは母分散の区間推定を逆算して、サンプルサイズが大きいほど分散が小さくなり精度が上がる様子を示しています。

サンプルサイズが小さいほど厳しくする評価指標を考えてみます。
この計算式はn回ランダムに取引した結果のプロフィットファクター(PF)が信頼度95%で収まる確率を示しています。

ランダムな取引のPFの上振れ値は取引回数が多くなるほど1.0に収束し、少ないほど大きな値となります。
最適化結果のPFをランダムな取引のPFの上振れ値で割った式について説明すると

• ●取引回数が多いほど値は最適化結果のPFに収束する
• ●取引回数が少ないほど小さい値となる
• ●ランダムな取引のPFの上振れ値を最適化結果のPFが超えると値は1.0以上になる

というような特性を持ちます。

つまり、PF/PFrを最適化の目的関数にすることが一つの対策案となります。

対策2：複雑過ぎないシステムにする

ロジックを複雑にするほど、複雑な値動きにフィッティングしてヒストリカルデータのノイズを拾いやすくなります。
理想的なのは「予測可能な狙いのエッジ」にフィッティングして、ノイズ等その他の値動きにフィッティングしないようなロジックです。

システムが狙っている予測可能なエッジすら説明できないほどシンプルなものでは優位性は生まれませんが、必要以上の複雑さを追加すればバックテストを難しくしてしまいます。

• ●狙いのエッジに合わせてポジションを持たせる
• ●やみくもにエントリーフィルターを追加しない
• ●最適化するパラメータは必要最小限にする

このような考えでロジックを作成します。

複雑過ぎるシステムはオーバーフィッティングしやすいですが、シンプルであるほど良いというわけでもないです。
予測可能な狙いのエッジを説明するためには、最小限の絡み合いが必要であることが多く、「オーバーフィッティングを防ぐために最適化は行わない」という選択はほとんどが間違いです。
『マーケットの魔術師 システムトレーダー編』(アート・コリンズ著、パンローリング)のマイク・ディーバーの章では、最適化を行って堅牢さを判断する必要性があるパラメータも存在するという説明があります。

最適化しなければならないパラメータの例を紹介します。
「ゴトー日(5の倍数の日)の9:30にドル円を買い、9:55(仲値)で決済する」というシンプルなシステムがあるとします。
これは日本企業のゴト払いという慣習が影響して生まれる、仲値前が上がりやすいというアノマリーを狙った戦略です。
仲値でロングポジションを決済するということが重要なポイントですが、エントリーの9:30という時刻には大きな意味がありません。
このシステムを最適化しなかった場合どうなるのか考えてみます。
実際には9:30よりも早い時間から上昇しやすいという傾向が過去の値動きにありますが、最適化しなかったことによって、この傾向を見落としてしまいます。
この例では、9:30というエントリー時刻は最適化して特徴を調べなければならないパラメータであったということがわかります。

機械学習の分野では、モデルがシンプル過ぎる場合や学習不足によってバイアスと呼ばれる誤差が大きくなり、反対にモデルが複雑過ぎる場合や過学習によってバリアンスと呼ばれる誤差が大きくなる現象が広く知られています。
バイアスとバリアンスはトレードオフの関係です。
シンプル過ぎず、複雑過ぎないバランスのとれたものを探すことが重要となります。

対策3：最適化結果から堅牢性をチェックする

最適化の最良結果以外の数値にも注目します。
最良結果となるパラメータを少しずらすと、結果が大きく変わるシステムは脆弱なシステムだといえます。
逆に、パラメータを多少ずらしても結果はあまり変わらない、パラメータはどれを選んでも良い結果となるシステムは堅牢である可能性があります。
パラメータを多少ずらしても結果が安定しているシステムは、フォワード期間で相場環境に変化があったとしても安定した利益を上げる期待が高くなります。
脆弱なシステムは偶然ノイズを拾っているため局所的な結果となっている、つまりオーバーフィッティングしている可能性が高いと考えられます。

画像は脆弱なシステムの最適化結果です。
良い結果は全体のわずかな箇所しかありません。

次に、堅牢なシステムの最適化結果です。
こちらは全体的にみて、ほとんどが良い結果となっていることが確認できます。

対策4：最良結果を選ばない

最適化結果全体をぼんやりと観察して、山型となっているかを確認します。
最良結果は必ずしも最適なパラメータであるとは限らず、山型の山頂付近が最適なパラメータとなります。

山型となる傾向はパラメータを連続的に変化させたときに「予測可能な狙いのエッジ」に徐々にフィッティングする様子を示しています。
ここの細かなバラツキはノイズ等を拾っている影響なので、上に大きくはみ出たものはオーバーフィッティングしている可能性が高いです。
細かいバラツキを無視して、山頂付近のパラメータを選択することが重要です。

インサンプルの評価

インサンプルでオーバーフィッティングを防げているなら、インサンプルの最適パラメータとアウトオブサンプルの最良パラメータがおよそ一致するはずです。
アウトオブサンプルで検証データを集め終えたら、アウトオブサンプル期間のパラメータをランダムに変化させます。
インサンプルの最適パラメータがランダム結果の上位何%に位置しているかを確認することで、最適化がうまく実行できたかを評価できます。
ランダム結果の上位に位置するほど、オーバーフィッティングしている可能性は低いと考えられます。

アウトオブサンプルのオーバーフィッティング対策

アウトオブサンプルがオーバーフィッティングする原因についてはすでに述べました。
アウトオブサンプルではヒストリカルデータを往復する行為は一切禁止です。
ヒストリカルデータを往復する行為には最適化以外にも、ロジックの変更、取引銘柄の変更なども含まれることに注意が必要です。

本当に実戦を想定した一度きりのアウトオブサンプルデータでも、偶然アウトオブサンプル期間のノイズに当てはまって本来のポテンシャルを超えたパフォーマンスを発揮することがあります。
優位性のないシステムも100個作れば1つくらいは偶然高いパフォーマンスを発揮するかもしれませんが、それには再現性がありません。

サンプルサイズについて

これはウォークフォワード法と、全く最適化しない単一バックテストを比較した図です。

ウォークフォワード法と単一バックテストを比較すると、ウォークフォワード法のアウトオブサンプル期間の方が短くなります。
インサンプルの説明でサンプルサイズが大きいほどオーバーフィッティングを起こしにくいと述べましたが、アウトオブサンプルにも同じことが言えます。

説明したとおり、最適化して特徴を調べなければいけないパラメータがあることや、システムの堅牢性を測るという目的もあるため、全く最適化しない単一バックテストが良いとはなりません。

最適化しつつアウトオブサンプル期間を長くとるための手段として、K分割交差検証法というものがあります。

この手法では、ウォークフォワード法に比べてインサンプル、アウトオブサンプルともにサンプルサイズを大きくすることができます。
ただし欠点もあります。
ウォークフォワード法はアウトオブサンプル期間とインサンプル期間の時系列が現実的なものになっているのに比べて、K分割交差検証法ではアウトオブサンプル期間より近年のデータで最適化していることになります。
つまり、未来のデータを使って最適化していることになるのです。
未来のデータを使うことになるので、知るはずのない情報をアウトオブサンプル期間にリークさせないように注意する必要があります。

バックテスト経路について

ここまで説明したウォークフォワード法とK分割交差検証法はバックテスト経路がひとつしか検証できないという共通の欠点が存在します。
『ファイナンス機械学習　―金融市場分析を変える機械学習アルゴリズムの理論と実践』（マルコス・ロペス・デ・プラド著、金融財政事情研究会）では、このような問題を解決するために、組合せパージング交差検証法(CPCV)という手法を解説しています。

CPCVが複数のバックテスト経路を生成できることを示す図です。

この図では5つのバックテスト経路を生成していますが、充分な取引頻度であれば何百、何千と生成することもできます。
複数の検証データの違いは、どの期間で訓練しているかで、中には結果が上振れしているものや下振れしているものが混在しているはずです。
ウォークフォワード法やK分割交差検証法は検証データはひとつなので、上振れにも下振れにも気付けません。

例を挙げます。
ウォークフォワード法で4年最適化、1年テストのセットを行った結果が優位性を認められるものでした。
同じシステムを5年最適化、1年テストのセットに変更して再びバックテストしたところ、今度は優位性がないような結果になってしまったとします。
1回目と2回目のバックテストではウォークフォワード法の設定が少し違うだけですが、結果が大きく変わってしまうのは堅牢なシステムではないという心配が生じます。
ウォークフォワード法やK分割交差検証法が1つのバックテスト経路しか生成しないことが欠点となるのは、このような問題に気付けないからです。

シャープレシオでシステムを評価するなら、ウォークフォワード法は単一のシャープレシオで評価することになりますが、CPCVは複数のシャープレシオによる分布を得ることができます。

リークについて

バックテストのテスト期間では、その時点で知るはずのない情報をシステムに与えてはいけません。
2022年、ドル円レートは大きく上昇しました。
それを開発者が知っていて「2022年はドル円を積極的に買う設定にする」とバックテストでは良い結果となりますが、2022年をテストするシステムにとっては知るはずのない情報なのです。
知るはずのない情報を取得してしまうことをリークと呼びます。

アウトオブサンプルテストは訓練データとテストデータに分けて、バックテストを行うわけですが、訓練データとテストデータの間にすき間を空けないとリークしてしまうことがあります。
一週間先まで予測するシステムの場合は、最大で一週間分がテストデータと重複する恐れがあるからです。

このように重複期間を空けるような対策をパージングと呼び、CPCV(組合せパージング交差検証法)の重要なテクニックともなっています。

パージングに加えて、テクニカル指標など過去データをさかのぼって計算するものも、リークの原因となります。
例えば、1ヶ月移動平均線を使用する場合は、1ヶ月期間を空ける必要があります。
これをエンバーゴと呼びます。

ウォークフォワードやCPCVなどアウトオブサンプルテストで試行回数、つまり訓練データとテストデータの接点が多いほど、成績が良くなる傾向にあるような場合は、リークしている恐れがあります。

本記事の執筆者：藍崎@システムトレーダー

　　　　　 　　　　　　　 　

本記事の執筆者：藍崎@システムトレーダー	経歴
	個人投資家としてEA開発＆システムトレード。 トレードに活かすためのデータサイエンス / 統計学 / 数理ファイナンス / 客観的なデータに基づくテクニカル分析 / 機械学習 / MQL5 / Python

---

本ホームページに掲載されている事項は、投資判断の参考となる情報の提供を目的としたものであり、投資の勧誘を目的としたものではありません。投資方針、投資タイミング等は、ご自身の責任において判断してください。本サービスの情報に基づいて行った取引のいかなる損失についても、当社は一切の責を負いかねますのでご了承ください。また、当社は、当該情報の正確性および完全性を保証または約束するものでなく、今後、予告なしに内容を変更または廃止する場合があります。なお、当該情報の欠落・誤謬等につきましてもその責を負いかねますのでご了承ください。

---