FX・自動売買公開 2026-09-17 ・ 更新 2026-10-02

MT4のサーバー時間と日本時間のずれ、夏時間でEAは何を間違える？

このページには広告（アフィリエイトリンク）を含むことがあります。

結論：「夏は6時間、冬は7時間足す」だけでは、EAの時刻はそろいません。夏時間を米国式で切り替えるサーバーを欧州式で計算すると、2026年は28日のあいだ1時間ずれます。私自身、検証用のデータの時刻を2時間まちがえていましたし、時計のずれた金と銀のデータで PF 1.5〜1.75 の「勝てる EA」を作ってしまったこともあります。時計をそろえ直すと PF 0.48〜0.61 でした。

よく言われる「6時間・7時間を足せばいい」

これは多くの業者で正しいです。サーバー時間を冬は UTC+2、夏は UTC+3 にしている業者が多く、日本は UTC+9 なので、差はちょうど7時間と6時間になります。

ただ、EA に時刻を任せると、この一行では足りない場面が出てきます。「夏」はいつからいつまでか。手元のバックテストのデータは、本当にサーバー時間で記録されているのか。テスターの中でも、同じ計算が働くのか。この3つは、それぞれ別に確かめる必要がありました。

最初につまずいたのは、自分のデータの時計だった

恥ずかしい話から書きます。

私の検証用プログラムの先頭には、「日本時間 = データの時刻 + 7時間」というメモがありました。データは業者のサーバー時間で記録されている、という思い込みです。何本もの検証がこの前提の上で動いていました。

ところが実際のデータは UTC（世界の基準時刻）で記録されていて、日本時間は +9時間。メモは2時間ずれていました。

確かめ方は単純です。USDJPY の1分足850万本で、金曜の最後の足がいつ来るかを見ました。ニューヨークの夕方5時に週が終わるので、UTC なら冬は21時59分、夏は20時59分が最後の足になるはずです。データはその通りに並んでいました。冬 UTC+2・夏 UTC+3 のサーバー時間で記録されていれば、夏も冬も23時59分で終わるはずです。

時刻を「メモを信じる」から「値動きの形で確かめる」に変えたのは、このときからです。

ずれは3か所で起きる

自分の検証とEAの点検で見つかったずれを、起きる場所ごとに分けました。

1. 夏時間の基準が、米国式か欧州式か

UTC+2／+3 のサーバーの多くは、米国の夏時間に合わせて切り替えます。米国は3月第2日曜から11月第1日曜まで。欧州は3月最終日曜から10月最終日曜までです。

どちらも「3月から秋まで」なので、雑に覚えると同じに見えます。でも切り替え日は違います。

2026年なら、3月8日〜28日の21日と、10月25日〜31日の7日。合わせて28日です。年によって21日か28日になります。

仲値やロンドンの寄り付きのように時刻そのものを狙う EA だと、この数週間だけ1時間早い、または遅い時刻に売買します。バックテストの成績表を見ても、この28日が紛れていることにはまず気づけません。

2. 過去データは、昔の夏時間の規則を使っている

米国の夏時間の規則は2007年に変わっています。2006年までは4月第1日曜から10月最終日曜まででした。

いまの規則を2006年以前にもそのまま当てると、切り替え前後の数週間で時刻が1時間ずれます。私は雇用統計の発表時刻を計算するときにこれを踏み、2006年11月3日の発表を1時間まちがえていました。その日の値動きの山は、計算した時刻の60分後にありました。

20年分のバックテストをする EA なら、2007年を境に規則を分けておく必要があります。

3. テスターの中では、TimeGMT() がサーバー時間を返す

MQL4 には UTC を返す TimeGMT() という関数があります。これでサーバーとの時差を自動で出せば楽そうに見えます。

ところが公式ドキュメントには、ストラテジーテスターの中では TimeGMT() が常にサーバー時間と同じになると書いてあります（2026年9月17日に確認）。テスターで時差を計算すると0になるわけです。

実運用では正しく動き、バックテストだけ時刻がずれる。逆に、バックテストで合わせた設定が実運用でずれる。どちらも起こりえます。

自作 EA を15本点検したとき（2026年9月3日）、3本は時差の設定の初期値が0のままでした。そのせいで、1日の損失上限を数える「日付の区切り」が、決めた時刻と違う時刻になっていました。

時計がずれると、偽物の「勝てる EA」ができる

時刻のずれがいちばん怖いのは、売買の時刻が狂うことより、バックテストの成績を良く見せてしまうことです。

金と銀の値段の比率が平均に戻る動きを狙った EA を検証したとき、PF 1.5〜1.75 が出ました。PF は「1円損する間に何円稼いだか」で、1.5 を超えればかなり良い数字です。

原因は時計でした。金のデータは UTC、銀のデータは東ヨーロッパ時間で記録されていて、2〜3時間ずれていた。金の値段を見た時点で、銀はもう少し先の未来の値段になっていたのです。未来を見て売買すれば、勝てて当たり前です。

時計をそろえて測り直すと（2026年8月27日）、8通りの設定すべてが PF 0.48〜0.61 でした。1円損する間に0.5円前後しか戻らない、はっきりした負けです。この話はバックテストの偽物の利益6つにもまとめています。

EA ではこう書いている

私は、業者ごとに冬と夏の時差を入力で持たせ、夏時間かどうかは日付から計算しています。TimeGMT() には頼りません。

input int WinterUtcOffset = 2;  // 冬のサーバー時間 = UTC+2
input int SummerUtcOffset = 3;  // 夏のサーバー時間 = UTC+3

// 米国の夏時間か（2007年に規則が変わったので年で分ける）
bool IsUsDst(datetime t)
{
   int y = TimeYear(t);
   datetime start, end;
   if(y >= 2007)
   {
      datetime mar1 = StringToTime(IntegerToString(y) + ".03.01");
      start = mar1 + ((7 - TimeDayOfWeek(mar1)) % 7 + 7) * 86400;   // 3月第2日曜
      datetime nov1 = StringToTime(IntegerToString(y) + ".11.01");
      end = nov1 + ((7 - TimeDayOfWeek(nov1)) % 7) * 86400;         // 11月第1日曜
   }
   else
   {
      datetime apr1 = StringToTime(IntegerToString(y) + ".04.01");
      start = apr1 + ((7 - TimeDayOfWeek(apr1)) % 7) * 86400;       // 4月第1日曜
      datetime oct31 = StringToTime(IntegerToString(y) + ".10.31");
      end = oct31 - TimeDayOfWeek(oct31) * 86400;                   // 10月最終日曜
   }
   return (t >= start && t < end);
}

// サーバー時刻 → 日本時間
datetime ServerToJst(datetime serverTime)
{
   int offset = IsUsDst(serverTime) ? SummerUtcOffset : WinterUtcOffset;
   return serverTime + (9 - offset) * 3600;
}

MetaEditor（MT4）で 0 errors・0 warnings を確認済み（2026年9月17日）。切り替えは日付の0時で判定しているので、切り替え当日の数時間はずれます。欧州式で切り替える業者や、時差が固定の業者では、この関数は使えません。

コードより先に大事なのは、使う業者が本当に米国式かを確かめることです。3月の第2日曜の前後で、金曜の最後の足の時刻が変わった日を見れば分かります。

自分の EA で確かめる順番

1. 業者のサーバー時間を、冬と夏の両方で確かめる（金曜の最後の足の時刻を見る）
2. 切り替えた日付が、3月第2日曜か3月最終日曜かを見る
3. バックテストのデータが、どの時計で記録されているかを確かめる
4. 2006年以前も測るなら、夏時間の規則を分ける
5. 時差を TimeGMT() で出しているなら、テスターでは0になると知っておく

私が自分の EA を販売するときの基準にも、「時刻のずれを確認済みであること」を入れています。私も EA を売る側に立つので、この確認は自分の EA にも同じように当てます。

この記事でわからないこと

• あなたの業者が米国式か欧州式かは、この記事ではわかりません。上の手順で分かります。
• 載せたコードは、コンパイルが通ることまでしか確かめていません。実際の口座とテスターで時刻を突き合わせてから使ってください。
• 時刻をそろえたからといって、時間帯のロジックに効き目が出るわけではありません。時間帯のアノマリーの検証では、コストの壁を越えたのはゴトー日の仲値だけでした。

振り返ると、時刻のまちがいは3回とも、成績の数字を見ているだけでは見つかりませんでした。見つけたきっかけは、金曜の最後の足や発表時刻の値動きといった「時刻がわかっている出来事」と突き合わせたことです。

時刻のずれ以外にも、EA がプロップの規約で失格につながる作りは手元で見つかった規約事故5つに、バックテストの良すぎる数字の疑い方は過学習の見抜き方にまとめています。

あなたの EA の時刻の設定は、3月の第2日曜から最終日曜のあいだも合っていますか？

時刻の補正を入れた EA の作成や、手持ちの EA の時刻の点検は作成依頼で受けています。検証してほしい手法のリクエストはフォームからどうぞ。

運営者が自分の EA 開発で確かめた記録です（2026年9月時点）。特定の業者や売買のタイミングをすすめるものではありません。