EA開発は検証設計で決まる — t値・スプレッド会計・Bid歪みを開発前に組み込む

「バックテストは完璧だったのに、フォワードで急に負け始めた」
そんな相談を、これまで何度も受けてきました。

原因はコードのバグでも、スピード不足でもありません。検証方法を「作った後」に決めていたことです。

これは仕方のないことです。EAが完成してからバックテストをかけると、人はどうしても「良く見える条件」を後から選んでしまいます。スプレッドを少し狭く。好調な年だけを期間に。取引回数が増えるパラメータだけを採用。どれも不正ではなく、ただの「選択」です。でも、その選択の積み重ねが、実運用で崩れるEAを生みます。

この記事では、開発のスタートラインで決めておくべき数値を3つだけに絞って解説します。t値・スプレッド会計・Bid歪み。この3つを仕様書に書いてから開発に入るだけで、完成後の後悔をかなり減らせます。

なぜ「後から検証」では間に合わないのか

バックテストは、条件を選べる分だけ自由に良く見せられます。

• スプレッドを現在より狭く設定する
• 好調な年だけを期間に選ぶ
• 取引回数が増えるパラメータだけを採用する

ここに悪意はありません。ただ、先に検証方法を決めていないと、あとから都合の良い条件を選んでしまうのが人間です。開発前に「何をどう検証するか」を文書化しておけば、この後付けの条件選択を構造的に防げます。

外注する場合はもっとシンプルです。検証設計を発注書に一文書き加えるだけで、納品物の質が変わります。外注前に整理すべき項目は要件定義チェックリストにまとめています。

検証設計に入れるべき3つの数値

1. t値 — 「偶然ではない」ことを数字で保証する

t値は「期待値÷ばらつき」で算出される統計量で、その利益が偶然のブレではないかを判定します。

目安はシンプルです。取引件数300件以上・t値2.0以上を、設計段階の合格ラインに設定してください。

期間5年で取引が100件未満のEA — どれだけプロフィットファクターが優秀でも、統計的には「まだ何とも言えない」状態です。年ごとの期待値のばらつき(標準偏差)も合わせて見ることで、「特定の1年だけ稼いだEA」を早い段階でふるい落とせます。

2. スプレッド会計 — 実測よりやや広めで計算する

スプレッドは時間帯で変動します。特にロールオーバー(日本時間の朝6〜7時前後)は一時的に拡大します。その時間帯にエントリーするEAを「平均スプレッド」だけで検証すると、実態より有利な数字が出ます。

設計段階での合格条件はこうです。実測の1.2〜2倍のスプレッドでも利益が残ること。

当サイトの監査実録でも、スプレッドを2倍にしただけで利益が消えるロジックを複数確認しています。これは口座選び以上に、EAの命運を分ける項目です。詳しくはスプレッドとスワップの正直会計で解説しています。

3. Bid歪み — エントリー時刻の実際の約定価格を疑う

ヒストリカルデータの多くはBid終値ベースで記録されています。ところがロールオーバー直後の0時台は、Bid価格が一時的に不自然に沈む(または跳ねる)ことがあるのです。その瞬間にエントリーするロジックは、データ上だけ有利に見えてしまいます。

実際の監査では、特定時刻のエントリーが実コスト比で数pips不利になっていたケースを確認しています。対策はシンプルです。エントリー時刻を、歪みが重なりやすい時間帯からずらして、同じ期待値が出るか再検証すること。時間帯別の分析例は東京時間のドリフト検証で公開しています。

開発前に決める検証チェックリスト

この6項目を、そのまま仕様書や発注書に貼ってください。

これを開発者と発注者の間で共有するだけで、「検証済み」の基準がぶれなくなります。頑健性の作り方は過剰最適化を防ぐ設計の実践ガイドで詳しく扱っています。

すでに動いているEAはどうするか

「もう開発済みだから遅い」と思うかもしれませんが、そんなことはありません。検証設計は後から当てはめることもできます。

まずはEAが稼がない理由を数字で特定する5つのチェックポイント、または無料のEAセルフチェックシート(20問)で、今の信頼度を自分で点検してみてください。5分で終わります。

検証設計は、いわば「EAの信用性を作る工程」です。開発前にかける1時間が、完成後の数千時間の運用と、失う可能性のある資金を守ります。

まずは上の表を、今あなたが動かしているEA、あるいは今検討しているEAに当てはめてみてください。何個埋まりますか?