MT4/MT5のサーバー時間とGMTオフセット｜バックテストがずれる原因と確認手順
WorldLinkForex基準日：2026年8月7日／本記事はMetaTraderの仕様と各国の夏時間制度に基づいて解説しています。お使いのブローカーのサーバー時間・GMTオフセットは業者ごとに異なり、予告なく変更される場合があります。必ずご自身の環境で確認してください。
MT4やMT5を開いたとき、「チャートの時刻が日本時間と合っていない」と戸惑ったことはありませんか。
さらに厄介なのが、EA（自動売買）を使っている場合です。バックテストでは良好だった成績が、実運用でどうしても再現しない。ロジックもパラメータも同じはずなのに、エントリーする時間帯が微妙に違う——。
その原因の多くが、サーバー時間とGMTオフセットのズレにあります。
この記事では、MT4/MT5の時刻がなぜ日本時間とずれるのか、なぜ業者ごとに違うのか、そしてそれがバックテストの再現性にどう効いてくるのかを、MetaTrader公式ドキュメントの記述をもとに整理します。あわせて、自分のブローカーのサーバー時間とGMTオフセットを自分で確認する手順を具体的に解説します。
この記事でわかること
- MT4/MT5のチャート時刻が日本時間とずれるのは、不具合ではなく仕様である理由
- ブローカーがGMT+2／GMT+3を使うことが多い理由と、日足の本数との関係
- 夏時間（DST）の切替日が、業者がどちらの国の規則に合わせるかで変わること
- バックテストが実運用と再現しなくなる4つの経路
- 自分のサーバー時間・GMTオフセットを確認する具体的な手順
1. 結論：まず確認する3つのこと
先に結論からお伝えします。
- MT4/MT5のチャート時刻は「ブローカーのサーバー時間」です。パソコンの時計とは無関係で、日本時間とずれているのは正常な状態です。
- サーバー時間は業者ごとに違い、冬にGMT+2・夏にGMT+3を採用する業者が多いとされます。ただし例外もあるため、業者名から決めつけず、自分の口座で確認するのが唯一確実な方法です。
- 時間指定で動くEAは、このズレをそのまま踏みます。バックテストと実運用で時刻の基準が食い違うと、同じロジックでも発火する時間帯がずれます。
| 確認すること | どこで見るか | 目安 |
|---|---|---|
| サーバー時間 | 気配値表示（Ctrl+M）のタイトルバー・「時間」列 | 平日の取引時間中に見る |
| GMTオフセット | サーバー時間 − 同時刻のUTC | 冬+2／夏+3の業者が多い（要確認） |
| 日足の区切り | D1チャートの1週間の本数 | 5本ならNYクローズ基準 |
💡 この記事では特定のブローカーのオフセット値は掲載しません。業者は予告なく設定を変更するため、値そのものより「確認できる状態になること」のほうが長く役に立つからです。確認手順は「6. 自分のサーバー時間とGMTオフセットを確認する手順」でまとめています。
2. MT4/MT5の時刻は「サーバー時間」— 日本時間とずれるのは仕様
MT4/MT5のチャートに表示される時刻は、あなたのパソコンの時計ではなく、ブローカーの取引サーバーが刻んでいる時刻です。
MetaTraderの公式リファレンスは、サーバー時間を返す関数 `TimeCurrent()` について、次のように明記しています。
The time value is formed on a trade server and does not depend on the time settings on your computer.
（時刻値はトレードサーバー上で生成され、利用者のコンピュータの時刻設定に依存しない）
つまり、パソコンのタイムゾーンを日本時間に直しても、チャートの時間軸は1ミリも動きません。これは不具合ではなく、世界中のどの利用者が見ても同じローソク足になるようにするための設計です。
ターミナルはサーバーのタイムゾーンを「知らない」
もう一段ややこしいのは、MT4/MT5のターミナル自身も、サーバーがどのタイムゾーンで動いているかを教えてもらっていないという点です。
MetaTraderの解説書（MQL5 Book）によれば、ターミナルは自分のローカル時刻とサーバーから届いた時刻を比較して差分を算出しているにすぎません。そしてその差分が更新されるのは、気配値表示ウィンドウに入れている銘柄のどれかに、新しい価格（ティック）が届いたときだけです。
Thus, the updated server time becomes known in the terminal only as a result of a change in the price of at least one financial instrument on the market, that is, from among those selected in the Market Watch window.
（したがってサーバー時間の更新は、気配値表示ウィンドウで選択されている銘柄のうち、いずれかの価格が動いたときにはじめてターミナルに伝わる）
そのため、土日や休場中はサーバーの時計が止まって見えます。同書も「日曜にはサーバー時間が金曜の夕方のまま表示されることが多い」と述べています。日曜の昼にMT4を開いて「金曜の夜の時刻のまま止まっている」と驚いた経験がある方も多いはずですが、これも仕様どおりの挙動です（暗号資産のように土日も動く銘柄を扱うサーバーは例外です）。
⚠️ GMTオフセットを確認するときは、必ず平日の取引時間中に行ってください。休場中は時計が止まっているため、正しい差が出ません。
日本時間への換算
日本標準時（JST）はUTC+9で、夏時間はありません。そのため、サーバーのオフセットが分かれば換算は単純です。
| サーバーのオフセット | 日本時間への換算 |
|---|---|
| GMT+2（冬時間の想定） | サーバー時間 ＋7時間 |
| GMT+3（夏時間の想定） | サーバー時間 ＋6時間 |
⚠️ これは「サーバーがGMT+2／+3だった場合の」換算式です。まずご自身のオフセットを確認したうえで当てはめてください。
3. なぜ業者ごとに違うのか — GMT+2/+3と「週5本の日足」
「業者はなぜ日本時間でもUTCでもなく、GMT+2やGMT+3という中途半端な時刻を使うのか」——これには明快な理由があります。
日足（D1）を、1週間ちょうど5本にするためです。
外国為替の1週間は「5×24時間」
外国為替市場は、日曜17時（ニューヨーク時間）に開き、金曜17時（ニューヨーク時間）に閉じます。つまり1週間は連続した24時間×5日ぶんです。
もしサーバーの「00:00」がニューヨークの17時とぴったり一致していれば、この5日ぶんは24時間ずつきれいに割り切れ、日足は週5本になります。
ニューヨークの17時をUTCに直すと、冬時間（EST＝UTC−5）で22:00 UTC、夏時間（EDT＝UTC−4）で21:00 UTC。これを「00:00」にするオフセットが、冬でGMT+2、夏でGMT+3というわけです。
この関係は MQL5 Book でも確認できます。同書は「外国為替市場は日曜22:00 UT に開き金曜22:00 に閉じる。したがって UTC+2 のサーバーでは月曜のちょうど0時0分に最初のバーが立つ」とし、夏時間へ切り替わると「サーバーのタイムゾーンが UTC+2 から UTC+3 に変わり、週の開始が 22:00 から 21:00 へ動く」と説明しています（MQL5 Book: Daylight saving time）。
ずれると日曜に「6本目」が生まれる
逆に、サーバーのオフセットがこれと違うと、週の切れ端が余ります。MQL4フォーラムの回答（2015年3月30日・ユーザー JC 氏）では、この点が次のように説明されています。
A majority of MT4 brokers run their servers at GMT+2 with daylight savings. The purpose is to have five D1 candles per week, with no partial bar on Sunday evening (or Saturday morning).
（MT4ブローカーの多くは夏時間つきのGMT+2でサーバーを動かしている。狙いは、日曜夜（や土曜朝）に中途半端な足を作らず、週5本のD1にすることだ）
>
If a broker doesn't do this, then there are five D1 candles plus an extra one for a partial day on Sunday, and a simple calculation of things like D1 ATR will be an underestimate.
（そうしない業者では、5本に加えて日曜の数時間ぶんの足が1本増え、D1 ATRのような単純計算は過小評価になる）
これは軽い話ではありません。日曜の数時間だけの極端に値幅の小さい日足が1本混ざると、それを含めて平均を取る指標——D1のATR、移動平均、前日高値・安値、日足ピボットなど——の値が業者間で食い違います。
| サーバーのオフセット | 週の日足本数 | 特徴 |
|---|---|---|
| GMT+2／+3（NYクローズ基準） | 5本 | 日足がNYクローズで区切られる。D1指標の計算が素直 |
| GMT+0（UTC固定） | 6本 | 通年で一貫していて分かりやすいが、日曜に小さい足が入る |
| GMT−5（米東部）など | 6本 | 同上 |
💡 どちらが優れているという話ではありません。GMT+0運用は「夏時間で時刻が動かない」という明確な利点があります。重要なのは、自分が使っている業者がどちらなのかを知っていることです。
4. 夏時間で年2回ずれる — 切替日は「どちらの規則に合わせるか」で変わる
サーバー時間が「冬はGMT+2、夏はGMT+3」と動くということは、年に2回、時間軸が1時間ジャンプするということです。
ここで押さえておきたいのは、業者によって「どちらの国の夏時間規則に合わせるか」が違うという点です。前掲のMQL4フォーラムの回答は、この点をはっきり述べています。
However, some of these brokers use American daylight savings ... and some of these brokers use European daylight savings ... It depends on the broker's source of liquidity.
（ただし、これらの業者のうち米国の夏時間を使うところもあれば、欧州の夏時間を使うところもある。業者の流動性の調達先による）
そして、米国と欧州では切替日が一致していません。
| 地域 | 夏時間の開始 | 夏時間の終了 | 切替時刻 |
|---|---|---|---|
| 米国 | 3月の第2日曜 | 11月の第1日曜 | 現地時間 午前2時 |
| EU | 3月の最終日曜 | 10月の最終日曜 | 1:00 GMT |
- 米国の規則は、2007年から現行のかたちです。NIST（米国国立標準技術研究所）は「begins at 2:00 a.m. on the second Sunday of March」「ends at 2:00 a.m. on the first Sunday of November」と規定しており、この規則は2005年エネルギー政策法によるものだと説明しています（NIST）。
- EUは指令 2000/84/EC 第2条・第3条により、全加盟国が3月最終日曜の1:00 GMTに夏時間へ移り、10月最終日曜の1:00 GMTに標準時へ戻します。廃止案は2018年に欧州委員会が提案し2019年に欧州議会が可決しましたが、理事会で合意に至らないまま停滞しています（欧州議会 Legislative Train）。2025年10月に本会議で議論が行われ、欧州委員会は今後の判断材料として追加調査を行う方針を示しましたが、2026年8月時点でも年2回の切替は継続中です。
米国の規則に合わせているサーバーは、ズレません
日足の区切りにしたいNYクローズは、米国の夏時間で動きます。ですからサーバー側も米国の規則で切り替わるなら、日足の境界は年間を通じてNYクローズと一致し続けます。
MQL5 Book も「3月初旬に夏時間へ移り、11月初旬に冬時間へ戻ると、夏時間の期間はおよそ8か月になる」と、米国の日程を前提にした記述をしています（MQL5 Book: Daylight saving time）。
欧州の規則に合わせているサーバーには、年2回の「端境期」が生まれます
一方、サーバーが欧州の規則で切り替わる場合、米国と欧州の切替日の差がそのまま出ます。
- 春： 米国が先に夏時間へ入り（3月第2日曜）、EUが追いつくまで2週間または3週間
- 秋： EUが先に標準時へ戻り（10月最終日曜）、米国が戻るまでちょうど1週間（10月最終日曜の7日後が11月第1日曜になるため）
この端境期は、米国側だけが夏時間の状態です。NYクローズは17時 EDT＝21:00 UTC。いっぽうサーバーはまだ標準時（UTC+2）なので、サーバーの00:00が来るのは22:00 UTC。
つまりこの期間は、NYクローズがサーバー時刻の23:00に来て、サーバーの日付が変わるのはその1時間後になります。春・秋のどちらの端境期でも、ズレの向きは同じです。
言いかえると、年に2回・合計3〜4週間ほど、日足の区切りがいつもと1時間ずれるということです。
⚠️ 「3月と11月の前後だけ、EAの成績や日足指標の挙動がいつもと違う」という現象は、サーバーが欧州の規則で切り替わっている場合、この端境期で説明がつくことがあります。切替日は年によって日付が動きます。上の表は規則であり、その年の実日付はご自身でご確認ください。
5. バックテストが再現しない4つの経路
ここからが本題です。時間軸のズレは、バックテストと実運用の食い違いとして表面化します。原因は1つではなく、少なくとも次の4経路があります。
| # | 経路 | 何が起きるか |
|---|---|---|
| 1 | 日付境界のズレ | 業者が違えば日足のOHLCが別物になり、D1参照の指標（ATR・前日高安・ピボット）の値が変わる |
| 2 | テスター内でGMTとサーバー時刻が同じ値になる | 検証環境と実環境で「GMTとの差」が食い違う |
| 3 | 夏冬の端境期 | 欧州規則のサーバーでは、年2回・数週間だけ日足の境界が1時間動く |
| 4 | ヒストリカルデータの出所違い | 別業者のヒストリーで検証すると、時刻の基準そのものが違う |
経路2がとくに見落とされやすい
このなかで、知らないと絶対に気づけないのが経路2です。
MetaTraderには、GMT（UTC）を返す `TimeGMT()` という関数があります。時間指定型のEAには、この関数と `TimeCurrent()`（サーバー時間）の差を取って、GMTオフセットを自動判定する実装が少なくありません。
ところが、公式リファレンスにはこう書かれています。
During testing in the Strategy Tester, TimeGMT() is always equal to TimeCurrent() simulated server time.
（ストラテジーテスターでのテスト中、TimeGMT() は常に TimeCurrent()＝シミュレートされたサーバー時刻と等しくなる）
MT5（MQL5）側の記述はこうです。
During testing in the strategy tester, TimeGMT() is always equal to TimeTradeServer() simulated server time.
（ストラテジーテスターでのテスト中、TimeGMT() は常に TimeTradeServer()＝シミュレートされたサーバー時刻と等しくなる）
そしてMT5では、`TimeTradeServer()` も `TimeLocal()` も、テスター内では `TimeCurrent()` と等しくなると明記されています（TimeTradeServer／TimeLocal）。`TimeGMTOffset()` は定義上 `TimeGMT() - TimeLocal()` ですから（TimeGMTOffset）、テスターの中ではこれらが同じ値になり、GMTオフセットは0として扱われる計算になります。
これが何を意味するか。バックテストのなかでは「GMT」と「サーバー時間」の差が0になるのに、実運用では実際のオフセット（たとえば2〜3時間）が返ってくる、ということです。
自動判定に頼ったEAは、テストと実運用で時間条件の発火時刻がずれます。ロジックを一行も変えていないのに成績が再現しない、という現象の、これは説明可能な機序のひとつです。
📝 上のうち、MT4リファレンスの一文は「テスターではGMTがサーバー時刻に等しくなる」ことを直接述べています。MT5側の「オフセットが0になる」は、公式が明記した3つの等式（TimeGMT＝TimeTradeServer、TimeTradeServer＝TimeCurrent、TimeLocal＝TimeCurrent）と `TimeGMTOffset()` の定義から導かれる帰結です。お使いのEAが実際にどの関数を使っているかは、配布元のマニュアルやパラメータ名（`GMTOffset` `UseAutoGMT` など）でご確認ください。
⚠️ もちろん、バックテストが再現しない原因は時間だけではありません。スプレッド設定、ティックデータの品質、スリッページ、約定モデルなど、複数の要因が重なります。詳しくはバックテスト・フォワードテストの読み方ガイドもあわせてご覧ください。
6. 自分のサーバー時間とGMTオフセットを確認する手順
ここが、この記事でいちばん実用的なパートです。
先に重要な事実をお伝えしておきます。MetaTraderには、サーバー側の夏時間を判定する標準機能がありません。MQL5の解説書は、サーバー時刻からは「そもそも夏時間が使われているのか、いま有効なのか」をMQL5が教えてくれないと述べたうえで、サーバーのDST判定について「Determining the daylight saving time on a server is not as easy.（サーバーの夏時間を判定するのは容易ではない）」とし、過去のヒストリカルデータを解析して経験的に判定するサンプルコードを示しています。そして、判定しきれない場合についてこう結論しています。
Such points should be clarified with the broker's support service.
（こうした点はブローカーのサポートに確認すべきである）
公式ドキュメント自身が「業者に聞け」と書いている領域ということです。ネット上のオフセット一覧表を鵜呑みにせず、次の手順でご自身の環境を確認してください。
手順A：サーバー時間を表示させる（MT4/MT5共通）
1. `表示` メニュー →`気配値表示` を開く（ショートカット：Ctrl + M） 2. 気配値表示の枠内で右クリックする 3. メニューの `時間`（Time）にチェックを入れる 4. 表示された時刻がサーバー時間です（チャートの時間軸と同じ基準）
▲ 気配値表示の右クリックメニューから『時間』を有効にすると、サーバー時間が確認できる。ウィンドウのタイトルバーにも直近のサーバー時刻が表示される
💡 気配値表示のタイトルバーにも、直近のサーバー時刻が出ています。公式リファレンスも `TimeCurrent()` の説明で「the time shown in the title of this window（このウィンドウのタイトルに表示されている時刻）」と述べており、ここが最も手早い確認場所です（MQL4 Reference: TimeCurrent）。
手順B：GMTオフセットを割り出す
1. 手順Aでサーバー時間を確認する 2. 同じ瞬間の UTC（GMT） を外部の時刻ソースで確認する（`time.is` や `time.gov` など） 3. サーバー時間 − UTC ＝ GMTオフセット 4. 出た値を「2. 日本時間への換算」の表に当てはめる
⚠️ 必ず平日の取引時間中に行ってください。土日・休場中はサーバーの時計が止まっているため、誤った差が出ます（→「2. ターミナルはサーバーのタイムゾーンを知らない」）。
手順C：日足の本数で「NYクローズ基準か」を判定する
1. 任意の通貨ペアのD1（日足）チャートを開く 2. 1週間に日足が何本立っているかを数える
| 結果 | 意味 |
|---|---|
| 5本 | 日付の区切りがNYクローズとほぼ一致（GMT+2/+3系の設定） |
| 6本（日曜に細い足がある） | 一致していない。D1 ATRなどの単純計算が過小になる点に注意 |
手順D：夏時間の切替があるか・どちらの規則かを確かめる
1. 3月または10〜11月をまたぐ期間のH1（1時間足）チャートを開く 2. 同じイベント（例：ニューヨーク市場のオープン）が、サーバー時刻で何時に来ているかを切替日の前後の週で比べる 3. 1時間動いていれば、そのサーバーは夏時間を採用しています 4. 動いた週が3月第2日曜／11月第1日曜なら米国の規則、3月最終日曜／10月最終日曜なら欧州の規則です 5. どちらでも動いていなければ、通年固定の可能性があります
💡 なお、一年中サマータイム相当のまま運用しているサーバーも存在します。MQL5 Book も、そうしたサーバーではヒストリカルデータからの判定が「夏時間の補正」なのか「単なるオフセット設定」なのか区別できなくなる、と認めています。確実に知りたい場合は、ブローカーのサポートに直接問い合わせてください（これがMQL5公式の推奨です）。
手順E：確認結果をメモに残す
確認した内容は、EAの設定と一緒に記録しておくことをおすすめします。
- ☐ サーバー時間（確認した日時とあわせて）
- ☐ GMTオフセット（例：UTC+3）
- ☐ 日足は週5本か6本か
- ☐ 夏時間の切替があるか／あるならどちらの規則か
- ☐ バックテストをどのオフセット前提で回したか
バックテストの条件をメモに残していないと、後から「実運用と何が違ったのか」を検証できません。ここを面倒がらないことが、再現性の第一歩です。
7. EAの時間設定で気をつけること
時間指定で動くEA——とくに深夜の値動きの薄い時間帯を狙うタイプ——は、サーバー時間の設定がそのまま成績に直結します。
- GMTオフセットのパラメータを自動判定に任せきりにしない。「5. 経路2」のとおり、自動判定はバックテストと実運用で異なる値を返す可能性があります。手動設定できるEAなら、確認した実測値を入れるほうが確実です。
- ブローカーを変えたら、必ず設定を見直す。同じEAでも、業者が変わればサーバー時間の基準が変わります。同じ業者が、タイムゾーンの異なる複数のサーバーを用意している場合もあります。
- 夏冬の切替タイミングで一度確認する。年2回、時間軸が動くタイミングがあります。
- バックテストと同じ業者のヒストリカルデータで検証する。別業者のデータで検証すると、時刻の基準そのものが違います。
EAの導入手順そのものは、MT4でEAを動かすまでの手順とMT5でEAを動かすまでの手順で解説しています。
⚠️ EAのパラメータの最適な値は、EAの実装ごとに異なります。この記事では特定のEAの推奨設定値は示しません。必ず配布元のマニュアルを確認してください。また、過去のバックテスト結果は、将来の成果を保証するものではありません。
8. 症状別チェック表
| 症状 | 考えられる原因 | 確認すること |
|---|---|---|
| チャートの時刻が日本時間と6〜7時間ずれている | 仕様（サーバー時間表示） | 手順A・Bでオフセットを確認。異常ではない |
| 土日にMT4/MT5の時計が止まっている | 仕様（気配値が来ないため更新されない） | 平日の取引時間中に再確認する |
| 日足が週6本ある | サーバーの日付区切りがNYクローズと不一致 | 手順C。D1指標の解釈に注意する |
| バックテストと実運用でエントリー時刻が違う | テスター内ではGMTとサーバー時刻が同値になり、自動判定が実オフセットを返さない | 「5. 経路2」。EAの時間パラメータを手動確認 |
| 3月・11月の前後だけ挙動が変わる | サーバーが欧州の規則で切り替わっている場合の端境期 | 手順D。切替の有無とどちらの規則かを確認 |
| 別のPCでバックテストしたら結果が違った | ヒストリカルデータの出所違い | 同じ業者・同じデータで再検証する |
| どうしてもオフセットが確定できない | 通年サマータイム運用などの可能性 | ブローカーのサポートに問い合わせる（公式推奨） |
EAがそもそも起動しない・発注しないという場合は、時間の問題ではない可能性が高いため、EAが動かないときのチェックリストを先にご確認ください。
9. よくある質問
Q. MT4/MT5の時刻を日本時間に変更できますか？
A. 標準機能では変更できません。チャートの時間軸はサーバー時間で固定されており、パソコンのタイムゾーン設定を変えても動きません（「2.」参照）。日本時間を確認したい場合は、サーバー時間に換算値（GMT+2なら＋7時間、GMT+3なら＋6時間）を足して読み替えるか、時刻表示用のインジケーターを併用してください。
Q. GMT+2とGMT+3、どちらの業者を選ぶべきですか？
A. 時間軸の設定だけを理由に業者を選ぶ必要はありません。多くの業者が採用するGMT+2/+3は日足が週5本になるという利点があり、GMT+0運用は通年で時刻が動かないという利点があります。どちらにも合理性があります。大事なのは「自分の業者がどちらか」を把握し、EAの設定とバックテストの前提をそれに合わせることです。
Q. サーバー時間は変更されることがありますか？
A. あります。ブローカーがサーバーの設定を変更したり、サーバーを移設したりすることは実際に起こります。また、同じ業者がタイムゾーンの異なる複数のサーバーを提供していることもあります。定期的に——少なくとも夏冬の切替時期には——手順A〜Dで確認することをおすすめします。
Q. バックテストが再現しないのは時間のせいだけですか？
A. いいえ。スプレッドの設定、ティックデータの品質（モデリング品質）、スリッページ、約定モデルなど、複数の要因が重なります。時間軸のズレは「そのなかで見落とされやすい要因のひとつ」と捉えてください。
Q. 日足が週6本だと不利なのですか？
A. 有利・不利の問題というより、指標の値が変わるという問題です。日曜の数時間だけの小さな足が混ざるため、D1のATRや移動平均といった単純平均の計算結果が、週5本の業者と食い違います。日足を参照するロジックを使う場合は、この点を織り込んで解釈してください。
10. まとめ
- MT4/MT5のチャート時刻はブローカーのサーバー時間であり、日本時間とずれているのは仕様です
- 多くの業者が冬GMT+2／夏GMT+3を使うのは、日足を週5本にしてNYクローズで区切るためです
- 夏時間の切替日は、業者が米国と欧州のどちらの規則に合わせるかで変わります。欧州の規則で動くサーバーでは、年2回・数週間だけ日足の境界が1時間ずれます
- バックテストが再現しない原因のひとつは、テスターの中ではGMTとサーバー時刻が同じ値になることにあります
- MetaTraderにはサーバー側の夏時間を判定する標準機能がなく、公式ドキュメント自身が「ブローカーに確認せよ」と述べています
サーバー時間は、意識しないうちに検証結果を静かに歪める要素です。逆にいえば、一度確認してメモに残しておけば、その後ずっと効きます。この記事の手順A〜Eを、EAの設定を見直すタイミングでぜひ一度通してみてください。
関連記事
※本記事の情報は2026年8月時点の内容です。サーバー時間・GMTオフセットは各ブローカーの設定により異なり、予告なく変更される場合があります。最新の情報は各公式サイトおよびサポートでご確認ください。
