IS/OOS分割では足りない｜ウォークフォワードの窓設計

結論：OOSが一区間だけなら、まだ「一回の試験」にすぎない

データを最適化用(IS)と検証用(OOS)に分ける方法は、過剰最適化を疑う第一歩として有効です。ただし分割が一回きりだと、OOSの結果は「その一区間でどうだったか」しか教えてくれません。

私たちの結論は次のとおりです。OOSを複数の窓に分けて前に進めながら検証し、合計ではなく窓ごとに黒字かどうかを見ます。合計が黒字でも、利益が特定の窓に偏っているなら評価は保留にします。

固定分割の弱点

分割点が結果を左右する

固定分割では、どこで区切るかを開発者が決めます。OOSがたまたまトレンドのはっきりした時期に当たれば、ロジックの実力以上に良く見えます。逆の時期に当たれば、使えるロジックを捨てることになります。どちらも、分割点という一つの選択に結果が依存しています。

OOSを何度も見ると、OOSではなくなる

もう一つの問題は開発者側の行動です。OOSの成績が悪いとパラメータを直し、もう一度OOSを見る。これを繰り返すと、OOSに合うものを選んでいるのと同じになります。形の上では未使用データでも、実質は最適化に使われています。これは私たち自身にも起こりうる失敗で、手順で縛らないと防げません。

ウォークフォワードの窓の作り方

ウォークフォワードは、「最適化する期間」と「その直後の検証する期間」をひと組の窓として、時間を前にずらしながら繰り返す方法です。検証区間は常に最適化区間より未来にあり、OOSが複数得られます。

窓の長さを決める基準

窓の長さは暦の年数よりも、取引数で決めるほうが安全です。検証区間に入る取引が少なすぎると、黒字か赤字かは偶然で決まります。保有時間が長く取引頻度の低いロジックほど、検証区間を長く取る必要があります。

窓ごとに確認する手順

1. 検証区間が重ならないように窓を並べる
2. 各窓で最適化し、得たパラメータを直後の検証区間だけに適用する
3. 検証区間ごとに損益、PF、取引数、最大ドローダウンを記録する
4. PF1.0以上の窓がどれだけあるか、赤字の窓がどの時期かを確認する
5. 最大の利益を出した窓を除いても、残りの合計が黒字かを確認する
6. 窓ごとに選ばれたパラメータが大きく飛び回っていないかを見る

チェックの要点は三つあります。

• 黒字の窓が一部に集中していないか
• 赤字の窓の損失が、黒字の窓の利益に対して大きすぎないか
• 隣り合う窓で最適パラメータが極端に変わっていないか

全窓が黒字である必要はないと私たちは考えています。トレンドフォロー型は、方向感のない時期の窓で負けるのが普通です。問題にすべきなのは、負ける窓の理由が説明できないこと、そして負けの深さが想定を超えることです。

限界と注意

取引数が足りないと窓が成立しない

ATLASのバックテストは検証7.5年で1193取引あり、複数の窓に分けても各窓にある程度の取引が残ります。一方、ETHEREUM EAのバックテストは検証7.5年で154取引です。こうした低頻度のロジックを細かい窓に切ると、ひと窓あたりの取引はごくわずかになり、窓単位の黒字・赤字はほとんど判断材料になりません。窓を粗くするか、窓ごとの評価は参考程度にとどめるしかありません。

公開している数値は全期間の値

実測ランキングに載せているPFや勝率は、検証期間全体を通した値です。窓ごとの成績ではないので、これだけで過剰最適化の有無は判定できません。この点は割り引いて読んでください。

窓の設計そのものも最適化できてしまう

窓の長さや本数を変えて、結果が良く見える組み合わせを選べば、それも過剰最適化です。窓の設計は検証を回す前に決め、後から動かさないことが前提になります。外から見て、その前提が守られたかを確かめる方法はほぼありません。

それでも将来は分からない

ウォークフォワードを通過しても、過去に無かった相場には対応できません。私たちが運用しているデモ口座でのフォワードテストでも、損益がマイナスのEAが複数あります。デモ口座であって実口座の成績ではなく、開始からの期間も短いので、良い結果も悪い結果も結論を出せる段階ではありません。検証手法は外れを減らす道具で、当たりを約束するものではありません。

まとめ

• 固定のIS/OOS分割は、分割点とOOSの見直し回数に結果が左右される
• ウォークフォワードは検証区間を複数作り、前に進めながら確かめる方法
• 見るのは合計ではなく窓ごとの損益。利益の偏りとパラメータの安定性を確認する
• 取引数が少ないロジックは窓に分けるほど判断が不安定になる
• 窓の設計は事前に固定する。通過しても将来の成績は分からない

検証の考え方はノウハウ集にもまとめています。