資料室 ── データ品質 ── 更新 2026-08-26
サマータイムで検証は1時間ずれる — 相場が米国ルールで動くことを2.2億ティックで確かめた
スプレッドが開くのは1日1時間で、スプレッドが最も開く1時間が日本時間6時と7時のあいだを季節で行き来することを実測しました。
この記事はその続きです。なぜ動くのか、いつ動くのか、そして検証データにとって何を意味するのか。
先に厄介な事実を1つ。サマータイムのルールは米国と欧州で違います。切替日が毎年ずれるので、年に3〜4週間は「片方だけが夏時間」という状態が生まれます。相場がどちらに従うのかは、決めつけずに測れば分かります。
結論
- 為替の日付が切り替わるロールオーバーはニューヨーク17時に固定されている。UTCで見ると、サマータイムに合わせて年2回1時間動く
- **相場が従うのは米国ルール。**3通貨ペア×6回=18回の米国切替すべてで時刻が移動し、18回の欧州切替では一度も動かなかった
- 米国と欧州の切替日はずれる。春は14日または21日、秋は必ず7日。合わせて年21〜28日が「ずれた状態」になる
- **1時間足以下で時刻条件を持たない戦略だけが、時刻の取り方に依存しない。**日足・4時間足はバー境界が動くとOHLCそのものが変わる
- UTC固定のデータで日足を作ると、毎週1本、長さ2〜3時間の日曜バーが混入する。しかも長さが季節で変わる(実測で確認)
- 時刻でフィルタする戦略は、条件を±1時間ずらして壊れるかどうかを見ておく。1時間で壊れる条件は、サマータイムだけで壊れる
仕組み: 2つのルールが並走している
サマータイムの規則そのものは法令で決まっていて、曖昧さはありません。問題は2つあることです。
| 開始 | 終了 | 根拠 | |
|---|---|---|---|
| 米国 | 3月第2日曜 02:00(現地) | 11月第1日曜 02:00(現地) | Energy Policy Act of 2005(2007年から適用) |
| 欧州 | 3月最終日曜 01:00 GMT | 10月最終日曜 01:00 GMT | 指令 2000/84/EC 第2条・第3条(2002年から適用) |
日本にはサマータイムがないので、日本時間はUTC+9で固定です。動くのは向こう側だけです。
規則から切替日を計算すると、こうなります。
| 年 | 米国開始 | 欧州開始 | 春のズレ | 欧州終了 | 米国終了 | 秋のズレ |
|---|---|---|---|---|---|---|
| 2023 | 03-12 | 03-26 | 14日 | 10-29 | 11-05 | 7日 |
| 2024 | 03-10 | 03-31 | 21日 | 10-27 | 11-03 | 7日 |
| 2025 | 03-09 | 03-30 | 21日 | 10-26 | 11-02 | 7日 |
| 2026 | 03-08 | 03-29 | 21日 | 10-25 | 11-01 | 7日 |
| 2027 | 03-14 | 03-28 | 14日 | 10-31 | 11-07 | 7日 |
| 2028 | 03-12 | 03-26 | 14日 | 10-29 | 11-05 | 7日 |
秋のズレは必ず7日です。「10月最終日曜」の1週間後が「11月第1日曜」になるので、構造的に固定されます。
春は14日か21日で、3月の曜日の並びによって変わります。合計すると年21〜28日、つまり1年の6〜8%は米欧がずれた状態です。
実測: 相場はどちらのルールで動くのか
ここからが本題です。「ニューヨーク17時に固定されている」なら米国ルールのはずですが、確かめられます。
測り方
前回と同じ3通貨ペア・3年分のティック(合計2億2,218万件)を使います。
UTC21時台と22時台のスプレッド中央値を週単位で出し、どちらが広いかを見ます。サマータイムの切替はどれも日曜に起きるので、月曜起点で週を切れば、1つの週がまるごと切替前か切替後のどちらかに収まります。
集計期間に含まれる切替は、米国6回・欧州6回。3ペアで18回ずつです。
結果(米ドル/円)
秋の切替を1つ見ます。単位はポイント(1ポイント=0.1銭)。
| 週(月曜) | UTC21時 = 日本6時 | UTC22時 = 日本7時 | 広いほう |
|---|---|---|---|
| 2025-10-13 | 55 | 6 | UTC21 |
| 2025-10-20 | 92 | 6 | UTC21 |
| ← 10-26 欧州が冬時間へ | |||
| 2025-10-27 | 60 | 6 | UTC21(変化なし) |
| ← 11-02 米国が冬時間へ | |||
| 2025-11-03 | 5 | 42 | UTC22(入れ替わった) |
| 2025-11-10 | 6 | 30 | UTC22 |
欧州の切替日をまたいでも何も起きず、米国の切替日をまたいだ週にきれいに入れ替わりました。
春も同じです。
| 週(月曜) | UTC21時 | UTC22時 | 広いほう |
|---|---|---|---|
| 2026-02-23 | 7 | 48 | UTC22 |
| 2026-03-02 | 8 | 53 | UTC22 |
| ← 03-08 米国が夏時間へ | |||
| 2026-03-09 | 41 | 11 | UTC21(入れ替わった) |
| 2026-03-16 | 66 | 10 | UTC21 |
| ← 03-29 欧州が夏時間へ | |||
| 2026-03-30 | 61 | 9 | UTC21(変化なし) |
集計
| 米国の切替日 | 欧州の切替日 | |
|---|---|---|
| 米ドル/円 | 6回中6回で移動 | 0回 |
| ユーロ/米ドル | 6回中6回で移動 | 0回 |
| 英ポンド/米ドル | 6回中6回で移動 | 0回 |
| 合計 | 18/18 | 0/18 |
18回中18回。例外はありませんでした。
ユーロ/米ドルの2024年3月最終週だけ、機械的な判定が「入れ替わった」と出ましたが、中身を見ると両方の時間帯が同じ値(0.9pips)に並んだだけで、広いほうは前後を通じてUTC21時のままでした。復活祭前の薄商いの週です。方向が逆転した回はゼロです。
**ユーロやポンドの通貨ペアであっても、欧州のサマータイムでは動きません。**日付の切り替えがニューヨーク時間に紐づいている以上、通貨の組み合わせは関係ない、ということになります。
その後、17通貨ペアに広げても同じだった
この記事を書いたあと、対象を17通貨ペアまで広げて測り直しました(合計10億ティック超)。
スプレッドが最も広い時間帯は、17銘柄すべてで日本時間6時(夏)/ 7時(冬)。例外はゼロでした。
| 群 | 該当 |
|---|---|
| ドルストレート | 米ドル/円、ユーロ/米ドル、英ポンド/米ドル、豪ドル/米ドル、NZドル/米ドル、米ドル/カナダドル、米ドル/スイスフラン |
| クロス | ユーロ/円、英ポンド/円、豪ドル/円、NZドル/円、スイスフラン/円、ユーロ/英ポンド、ユーロ/スイスフラン、英ポンド/スイスフラン、ユーロ/カナダドル |
| エキゾチック | ユーロ/香港ドル |
米ドルが絡まないペアも、エキゾチック通貨も、すべて米国の夏時間に連動します。 一方で同じデータに含まれる株価指数CFDは季節で動きませんでした(最も広い時間帯は両季節とも日本時間9時)。為替とは別の時計で動いています。
何が壊れるか
時刻が動くこと自体は、そう分かれば対処できます。問題は気づかないまま検証してしまうことです。
1. 時刻でフィルタする戦略
「日本時間9時〜15時だけ取引する」のようなフィルタは、時刻の基準が動けば実際に取引する相場の局面が変わります。1年のうち21〜28日は、意図と1時間ずれた条件で動くことになります。
2. 日足・4時間足のOHLC
整数時間のずれなら、1時間足以下の形は変わりません(ラベルがずれるだけです)。
しかし日足と4時間足は、バーの区切りが基準時刻の0時起点です。基準がずれるとバーの中身が入れ替わり、高値・安値・始値・終値が別の値になります。日足の平均線、前日高安、日足のATR——これらを使う戦略は、時刻の取り方が違うだけで別の戦略になります。
3. UTC固定データの日曜バー
為替の週は日曜のニューヨーク17時ごろに始まります。UTCで言うと夏は21時、冬は22時です。
これは手元のデータでも確認できました。日曜のティックは、夏時間の期間はUTC21時台から、冬時間の期間はUTC22時台から始まっています。夏時間の期間にUTC21時台のデータがあり、冬時間の期間にはそれが存在しない、という形できれいに分かれました。
したがってUTC固定のデータから日足を作ると、週の頭に長さ2〜3時間の日曜バーが毎週1本混入します。しかも夏は3時間、冬は2時間と長さが変わります。日足ベースの指標を使うなら、この1本が計算に混ざることになります。
ここで言えるのは「日足の中身が変わる」ところまでです。どちらの作り方が成績上有利かという話ではありません。
4. 経済指標の時刻
指標の発表時刻は発表国の現地時間で固定されていて、その国のサマータイムで動きます。米国の指標は米国ルール、欧州の指標は欧州ルールです。
つまりどの基準時刻を選んでも、米欧どちらかの指標時刻は年21〜28日ずれます。「サーバー時刻に合わせれば解決」とはなりません。指標を避けるフィルタを持つなら、その前提で組む必要があります。
実務でどう使うか
- **その時刻に実際いくら払うかは、時間帯別コスト計算機(TOOL-003)で確認できます。**本記事と同じデータを使っていて、夏時間と冬時間を分けて持っています
- **1時間足以下で、時刻条件を持たない戦略なら、この問題は起きません。**まずここに当てはまるかどうかを確認してください。当てはまるなら以下は不要です
- **時刻条件を入れた瞬間に、戦略は時刻の取り方に依存します。**その条件が何時のことなのか(日本時間か、データの基準時刻か)を、検証記録に必ず書いておいてください。後から見て判別できないと再現できません
- 条件を±1時間ずらして再検証してください。それで成績が崖のように落ちるなら、その条件はサマータイムだけで壊れます。年21〜28日は実際にずれるので、これは仮定の話ではありません
- どのくらい落ちたらだめか、という基準はここでは示しません。時刻条件を持たない戦略群の変化幅を先に測り、それと比べるのが素直な見方です
- 選ばれた時刻に構造的な説明がつくかを見てください。実測した時間帯プロファイルやセッションの構造と対応しているなら、実体がある可能性が上がります。説明できない時間帯に利益が集中しているなら、偶然を疑うほうが安全です
- **時刻条件は自由度が大きく、探索するほど「たまたま良い時間帯」が見つかります。**これはたくさん試して一番良いのを選ぶと、なぜ嘘の好成績が生まれるのかで書いた問題そのものです。時刻フィルタの成績は、多重比較と切り離して読めません
- **長期の検証では、規則そのものが変わっていることに注意してください。**米国の現行ルールは2007年から、欧州は2002年からです。それ以前を含む期間で現行ルールを当てはめると、3〜4月と10〜11月の一部に1時間の系統誤差が入ります
データの見方(方法と限界)
- 判定に使ったのはスプレッドが最も開く時間帯の位置です。ロールオーバーそのものの時刻を直接観測したわけではありません。ただし両者が一致することは市場慣行の資料(夏はGMT21時、冬はGMT22時)と符合しています
- **データ源は1つです。**ForexTester 6 の Advanced Data Feedが配信するティックを使っています。その先の流動性提供元は公開されていません。他の配信元でも同じ結果になるかは確認していません
- 3年間・18回の切替の観測です。規則が変わればこの結果も変わります
- 切替日の当日にバーの重複や欠落が起きるかは、この記事では確認していません。切替はいずれも週末の市場クローズ中に起きるため通常は発生しないはずですが、実データでの検証は行っていません
- 検証ソフトやデータ変換ツールが、2007年以前の旧ルールを正しく適用するかは製品によります。ここでは確認していません
まとめ
- 為替の時刻は年2回、1時間動く。動かしているのは米国のサマータイム
- 3通貨ペア×6回の米国切替、18回すべてで移動を確認。欧州切替では0回
- 米欧のズレは年21〜28日。秋は必ず7日、春は14日か21日
- 1時間足以下・時刻条件なしなら影響を受けない。それ以外は受ける
- 時刻条件は**±1時間ずらして壊れないか**を見る。壊れるならサマータイムだけで壊れる
出典
- 米国の規則と切替日: Daylight Saving Time — NIST(3月第2日曜〜11月第1日曜)
- 欧州の規則: Directive 2000/84/EC — EUR-Lex(第2条=3月最終日曜01:00 GMT開始、第3条=10月最終日曜01:00 GMT終了)
- ロールオーバーがニューヨーク17時であること、および夏GMT21時・冬GMT22時: Value dates, market convention — London FX
- 時刻・カレンダー条件と探索の問題: Sullivan, Timmermann & White, Dangers of data mining: the case of calendar effects in stock returns, Journal of Econometrics 105(1), 2001
- 切替時刻の実測: ForexTester 6 の Advanced Data Feed が配信する3通貨ペア・3年分のティック(2023年8月25日〜2026年8月23日、合計2億2,218万件)を当サイトで集計。手法はスプレッドが開くのは1日1時間と共通
- 17通貨ペアへの拡張と、データそのものの品質検査: ForexTesterのデータはどこまで信用できるか(当サイト)
※本記事は情報提供を目的としたもので、特定の取引や手法を推奨するものではありません。数値は集計期間における実測値であり、将来の結果を保証するものではありません。