MT4サーバー時間とGMTオフセットの読み方｜夏冬のズレ早見表と確認手順

MT4のチャートに表示される時刻は、パソコンの時刻でも日本時間でもありません。取引サーバーが刻む「サーバー時間」です。海外FX業者の多くはGMT+2（冬時間）／GMT+3（夏時間）を採用しており、日本時間とは6〜7時間ずれます。このズレを把握しないままEAの時間フィルタを設定すると、狙った時間帯とまったく違う時間に取引が走ります。この記事では、サーバー時刻の読み方、日本時間への変換早見表、自分の口座で実測する手順を順に説明します。

結論：日本時間は「夏は+6時間、冬は+7時間」

サーバー時刻を間違えると困るのは、EAの時間帯フィルタ、日次リセット、ロールオーバー回避といった「時刻を条件にする処理」です。EAの導入手順そのものは EAの導入手順 にまとめていますが、GMTオフセットは導入後に最も事故が起きやすい設定項目のひとつです。

サーバー時刻から日本時間への変換早見表

サーバー時刻を左列、日本時間を夏冬の2列に並べた早見表です。夏時間はサーバーがGMT+3、冬時間はGMT+2である前提で計算しています。

逆方向に読むときは、日本時間から夏は6、冬は7を引きます。たとえば日本時間の21:30はサーバー時刻で夏15:30、冬14:30です。

主要な時刻の対応

運用中によく使う時刻だけを抜き出すと、次のようになります。

ロールオーバー前後はスプレッドが数倍から数十倍に開くことがあります。日跨ぎで保有するEAでは、この時刻の把握が損益に直結します。停止判断の考え方は EAを停止すべきタイミング で整理しています。

なぜ海外FX業者はGMT+2/+3を使うのか

「なぜGMT+0にしないのか」という疑問は当然です。理由は日足の区切り方にあります。

GMT+2（冬時間）のサーバーでは、日足の確定時刻がニューヨーク17:00と一致します。ニューヨーク17:00は外国為替市場の慣行上の1日の区切りであり、ロールオーバーやスワップ計算の基準にもなっています。この基準に合わせると、月曜から金曜までの日足がちょうど5本になります。

一方、GMT+0のサーバーでは1日の区切りがニューヨーク17:00より2時間早くなります。その結果、日曜日に数時間分しか値動きのない細い6本目のバーができます。日足の高値・安値・終値を参照するEAやインジケーターは、この6本目のバーで計算が崩れます。

サーバー時刻を実測する3つの方法

具体的なオフセット値は業者ごとに異なります。GMT+2/+3が多数派というだけで、例外もあります。必ず自分の口座で確認してください。

方法1：気配値表示ウィンドウで見る

1. MT4で「気配値表示（Market Watch）」ウィンドウを開きます（Ctrl+M）。
2. ウィンドウ上部に表示されている時刻がサーバー時刻です。MT5ではMarket Watchの時刻欄に表示されます。
3. 自分のパソコンやスマートフォンの日本時間と見比べ、何時間ずれているかを数えます。

最も手軽ですが、差を目視で数えるため分単位のずれを見落としやすい方法です。

方法2：TimeCurrent() と TimeGMT() の差で求める

MQLには、サーバー時刻とGMTをそれぞれ返す関数があります。公式リファレンスの説明は次のとおりです（出典: MQL4 Reference - TimeCurrent / TimeGMT 、2026年9月24日確認）。

公式は TimeCurrent() について「時刻の値は取引サーバー上で形成され、あなたのコンピュータの時刻設定には依存しない」とも明記しています。つまりサーバー時刻はPCの時計をいじっても変わりません。

方法3：簡易スクリプトで数値を出力する

差を手計算せずに済ませるなら、次のような短いスクリプトを MQL4\Scripts\ に置いてコンパイルし、チャートにドラッグします。出力は「ターミナル」→「エキスパート」タブに出ます。

void OnStart()
{
   datetime server = TimeCurrent();
   datetime gmt    = TimeGMT();
   double   offset = (double)(server - gmt) / 3600.0;

   Print("Server time : ", TimeToString(server, TIME_DATE|TIME_SECONDS));
   Print("GMT         : ", TimeToString(gmt,    TIME_DATE|TIME_SECONDS));
   Print("GMT offset  : ", DoubleToString(offset, 1), " hour(s)");
}

出力された GMT offset が 2.0 なら GMT+2、3.0 なら GMT+3 です。ファイルの置き場所やコンパイル手順は EAの導入手順 と同じ流れになります。

EAの「GMT Offset」パラメータの意味

多くのEAは GMT Offset Broker GMT Offset TimeZone といったパラメータを持っています。これは業者サーバーの時刻がGMTから何時間ずれているかをEAに教えるための設定です。

このパラメータは、主に次の処理で使われます。

• 時間帯フィルタ（ロンドン時間だけ取引する、夜間だけ取引する、など）
• 日次リセット（1日の取引回数の上限、日次損失上限のリセット時刻）
• ロールオーバー回避、指標発表前後の停止
• 週末クローズ前の全決済

つまり、EAの「いつ動くか」を決めるすべての判断がこの値に乗っています。時間帯フィルタそのものの設計は 時間フィルタ付きEAの考え方 で扱っています。

設定を間違えるとどうなるか

GMTオフセットを間違えたときの症状は、故障に見えないのが厄介です。EAはエラーも吐かず、静かに間違った時間帯で動き続けます。

「EAは動いているのにトレードしない」「バックテストでは勝っていたのに実運用で挙動が違う」という相談の一部は、このオフセット設定が原因です。症状の切り分けは EAが動かないときのチェック も併せて確認してください。成績の劣化を数値で比較したいときは EA成績指標チェッカー で、設定変更の前後を同じ指標で並べると判断しやすくなります。

バックテスト用ヒストリカルデータとオフセット

外部配信のヒストリカルデータは、GMT+0が標準です。Dukascopy由来のティックデータをそのまま取り込むと、GMT+2/+3の業者サーバーとは2〜3時間ずれた状態で検証することになります。

時間帯フィルタを持つEAでは、このズレだけで結果が別物になります。バックテストの手順は バックテストのやり方 にまとめていますが、タイムゾーンの整合は手順の前段階で決めておくべき項目です。

TickstoryやTick Data Suiteにはタイムゾーン変換機能があります。 Tickstoryでのティックデータ取得 の段階で、業者サーバーと同じオフセットに変換してから .fxt を生成してください。変換設定を記録に残しておくと、後から検証条件を再現できます。

XMの場合（公式記述で確認できる範囲）

具体例としてXMTradingの記述を挙げます。貴金属の取引条件ページに次の記載があります。

「調整額はポイント単位で表示され、月曜日から金曜日の毎日、**00:00（GMT+2、夏時間の変更を含む）**に適用されます。また、GOLD、SILVER、XAUEURの場合は水曜日に、その他の貴金属については金曜日に3日分の調整が行われます。」
出典: XMTrading 貴金属 （2026年9月24日確認）

ここから読み取れるのは次の3点です。

FX通貨ペアの3倍スワップ日については、商品ページに同様の脚注を確認できませんでした。一般には水曜とされますが、業者の公式情報で確認してください。XMでのEA設定全般は XMでのEA設定 にまとめています。

よくある失敗

• チャート右上の時刻を日本時間だと思い込む。 MT4のチャートに日本時間は一切出てきません。すべてサーバー時刻です。
• ネットで見た「GMT+2」をそのまま入れる。 記事の執筆時点と今で、業者の設定が変わっている可能性があります。
• 夏冬で設定を変え忘れる。 手動設定のEAは、自分で切り替えないと半年間ずれ続けます。
• VPSの時計を放置している。 TimeGMT() を使う実測やEAの内部処理が、VPSの時刻ずれの影響を受けます。
• バックテストのデータをGMT+0のまま使う。 検証結果と実運用が構造的に一致しなくなります。

まとめ

サーバー時間の理解は、EA運用の土台です。日本時間はサーバー時刻に夏は6時間、冬は7時間を足した値になります。ただしこれはGMT+2/+3を採用する業者の場合であり、必ず自分の口座で実測してください。

実測は TimeCurrent() と TimeGMT() の差を出力する短いスクリプトで十分です。VPSの時計が正しいこと、ストラテジーテスター内では差が出ないことの2点だけ押さえておけば、数分で終わります。

次に読むなら、ズレが発生する時期を扱った 夏時間・冬時間の切り替えでEAが狂う理由 、時刻条件の設計を扱った 時間フィルタ付きEAの考え方 、そして導入全体の流れを確認できる EAの導入手順 の3本が順路としておすすめです。