同じEAなのにテスト結果が毎回違う — バックテストを狂わせる「時刻ずれ」の正体

「同じEA、同じ期間、同じ設定のはずなのに、口座を変えてバックテストしたら成績がガラリと崩れた」「先月やった検証をやり直したら、なぜか結果が微妙に違う」。こうした経験は、検証のやり方が悪いわけではありません。背後には、チャート上では見えない「時刻のずれ」と「データ品質の差」という犯人がいることが多いのです。

この記事でわかること:

• バックテストの再現性を壊す3種類の「ずれ」(バータイムスタンプ・サーバー時刻/DST・ブローカー間のデータ差)
• それぞれがEAの成績をどう歪めるのか
• 監査現場で実際に使う、ずれを検出する4つの突合チェック
• 再現性のある検証を設計する3つのポイント

まず結論 — バックテストを狂わせるのは3種類の「ずれ」

EAの検証結果が環境間で再現できないとき、原因はほぼ次の3種類に分類できます。それぞれ「何がずれるか」も「どう検出するか」も違います。

以下で順番に、それぞれのずれがどう成績を歪めるかを見ていきます。

1つ目: バーのタイムスタンプ — 「8:00の足」には8:00〜8:59が詰まっている

図: バーのスタンプは「開始時刻」。実際のティックはその後の1分間に到達します。

MT4のヒストリカルデータでは、各バーに「開始時刻」でタイムスタンプが押されます。8:00のM1バーには、8:00:00〜8:59:59のティックの結果がすべて詰まっているのです。

ここで注意したいのが「8:00になったら判定する」タイプのEAです。テスター上では8:00バーの情報で判定が走りますが、実運用では8:00ちょうどに約定できるとは限りません。ティックの到達順序や、Close[1]のような「1本前の確定足」の参照位置が1本ずれるだけで、シグナルの回数は変わってしまいます。

同じ理由で、上位足(1時間足など)を参照するEAは「どのタイミングでその足が確定したとみなすか」で結果が変動します。期間の区切り方ひとつで、同じロジックが別の取引をすることがあるのです。

2つ目: サーバー時刻とDST — 「日本時間のつもり」が1時間ずれる

図: 多くの海外ブローカーのサーバー時間は、年2回のサマータイム切替で日本時間との時差が1時間動きます。

海外ブローカーのサーバー時間はGMT+2またはGMT+3に設定されていることが多く、多くの場合は米国のサマータイム(DST)に連動して、春と秋の年2回、1時間ずつ切り替わります。つまり、コード上の「同じ8時」でも、3月と11月では指し示す日本時間が1時間違うのです。

「東京時間の朝に買う」つもりでサーバー時刻を指定したEAは、切替のたびに実際の取引時刻がずれます。時間帯依存の戦略ほど、このずれの影響をまともに受けます。

見分け方は年別・月別の成績分解です。3月と10〜11月の境目だけ成績の質が変わるEAは、この「DSTのずれ」を疑う兆候です。監査では単月ごとに成績を分離して、時刻指定が切替日をまたいでいないかを確認します。

3つ目: ブローカー間のデータ差 — 「同じUSDJPYのM1」は存在しない

これが最も見落とされやすいポイントです。通貨ペアの名前が同じでも、ブローカーごとの提示レートは独立しています。流動性の供給元が違えば、スプレッドも、板が薄い時間帯の一瞬の異常値も、データの欠損の入り方も別物です。

つまり、口座Aのデータで導いた期待値は、口座Bではそのまま成立しません。これはEAの欠陥ではなく、検証データの「出身」の問題です。監査では2つのデータソースを突合して、対象口座に固有の歪み(例: 特定の時間帯だけ突出して広いスプレッド)を検出してから期待値を計算します。

このあたりの考え方や事例は、口座ごとの正直会計の記事と、データ破損を見抜いた監査実録で詳しく解説しています。

監査で使う4つの突合チェック

では、こうしたずれを実際にどう検出するのか。監査工程で使う4つのチェックを紹介します。

1. バー数カウント: 期間 × 期待されるバー本数(週末・祝日を除く)と、実際のデータのバー数を比較します。欠損や重複はここで浮かび上がります。
2. 2ソース突合: 別のデータソースの週足終値と突き合わせ、差分が閾値を超える週がないかを確認します。固有の歪みはここで検出します。
3. DST境界テスト: 3月・10月末の切替周辺だけを単月で分離して成績を比較します。時間帯指定のEAはここで本質が現れます。
4. スプレッド実測ログ: エントリー予定時刻の実スプレッドを数日分記録し、テスターが仮定したコストと比較します。テスターのスプレッド固定値は、実コストの代表値とは限りません。

この4つは特別なツールがなくても、MT4の履歴と地道な突合作業で再現できます。ただ、10年分のM1データ相手にやると数時間はかかるのが実情です。

再現性を確保する3つの設計

ずれを検出するだけでなく、EAや検証の設計段階で「ずれに強い構造」にしておくことが可能です。

• サーバー時刻で書く: コード内の時刻指定はすべてサーバー時間で統一し、日本時間への固定換算(「-6時間」のような固定オフセット)を書かない。DSTは切替のたびに対応が変わる前提で書きます。
• 確定したバーだけ参照する: シグナル判定は「1本前の確定足」のみを参照する設計にすると、ティックの到達順序に左右されにくくなります。
• 本番と同じ口座のデータで検証する: 厳密です。別のデータで検証せざるを得ない場合は、実スプレッドの差を上乗せする悲観会計で評価します。

まとめ — 数字を信じる前に「ずれ」を疑う

バックテストが再現できないのは、ほとんどの場合EAの欠陥ではなく、検証環境のずれです。バーのタイムスタンプ、サーバー時刻とDST、ブローカー間のデータ差。この3つを知っているかどうかで、「この数字は信じられるか」という判断の精度が変わります。

あなたのEAの最後のバックテストは、どのブローカーの、どの時間軸のデータで走ったものだったか、今一度思い返してみてください。答えに迷ったら、それが監査のスタート地点です。

関連記事: EAのバックテストはこう読む — 見抜く3つの数字 / EA開発は検証設計で決まる — t値・スプレッド会計・Bid歪み

※本記事にはアフィリエイト広告も含みます。