検証結果と実際の売買記録が1時間ずれているとき、まず疑うべきはサーバー時刻と夏時間（サマータイム）の切替です。多くの取引プラットフォームのチャートに表示されるのは、自分のパソコンの時刻でもUTCでもなく、業者のサーバーが設定しているタイムゾーンの時刻です。そしてそのタイムゾーンが夏時間に連動している場合、年に2回、日足の区切りと時間帯フィルタの意味が1時間動きます。この記事では、ずれの正体を切り分ける手順と、確認が効かない場面までを整理します。
チャートに出ている時刻は誰の時刻か？
時刻の話で混乱が起きるのは、同じ「9時」でも基準が4種類あるからです。まず用語を揃えます。
| 名称 | 意味 | 取引での現れ方 |
|---|---|---|
| UTC（協定世界時） | 世界共通の基準時。夏時間の概念がない | データ提供元の生データ、API応答 |
| サーバー時刻 | 取引業者のサーバーが設定しているタイムゾーンの時刻 | チャートの横軸、注文履歴の約定時刻 |
| ローカル時刻 | 自分の端末のOSが持つ時刻。日本ならJST（UTC+9、夏時間なし） | 日誌アプリ、スクリーンショットの撮影時刻 |
| 市場の現地時刻 | ニューヨーク、ロンドンなど各市場の現地時刻 | 経済指標の発表時刻、取引所の立会時間 |
検証でよく壊れるのは、この4つを無意識に混ぜたときです。たとえば次のような場面です。チャート上で「サーバー時刻の15時から17時」という条件を作って集計し、日誌には端末のJSTで時刻をメモし、指標カレンダーは発表国の現地時刻で見ていた。3つの基準がずれたまま突き合わせれば、対応する行が見つからないか、別の足を見比べることになります。
なお、サーバー時刻のタイムゾーンは業者が決める設定値であり、業界で統一されたものではありません。口座ごとに違う前提で、自分で確認するしかありません。
夏時間の切替は何をずらすのか？
夏時間は、春から秋にかけて時計を1時間進める制度です。切替日は地域ごとに別々の規則で決まっています。
| 地域 | 切替時期の規則 | 備考 |
|---|---|---|
| 米国 | 3月第2日曜に開始、11月第1日曜に終了 | Energy Policy Act of 2005 による現行規定。州により不採用の地域あり |
| 欧州連合 | 3月最終日曜に開始、10月最終日曜に終了 | 夏時間に関する指令で統一。英国も同時期 |
| 豪州（一部の州） | 南半球のため10月頃開始、4月頃終了 | 州ごとに扱いが異なる |
| 日本 | 夏時間なし（JSTはUTC+9で固定） | 切替の影響は「相手側だけが動く」形で現れる |
ここで重要なのは、米国と欧州で切替日が一致しない期間があることです。3月に米国が先に夏時間へ入り、欧州が追いつくまでの数週間、米欧の時差はふだんと1時間違います。秋も、欧州が10月最終日曜に終了し米国が11月第1日曜に終了するまで同じことが起こります。
外国為替市場では、ニューヨーク市場のクローズを日足の区切りとする設定が広く使われています。この設定を採る場合、サーバー時刻は米国の夏時間に連動して年2回動きます。すると起きるのは次の3つです。
- 日足の区切り時刻が、サーバー時刻の表示上は同じでもUTC基準では1時間動く
- 「○時台のレンジ」のような時間帯フィルタが、市場の実時間とは別のものを指すようになる
- 経済指標の発表が、切替前後でチャート上の別の足に入る
米国労働統計局（BLS）が公表する雇用統計のように発表時刻が現地時間で固定されている指標は、JSTで見れば夏時間中と冬時間中で1時間違う時刻に出ます。指標直後の値動きを集計している人は、ここを固定時刻で絞ると年2回、別の時間帯を数えることになります。
自分の口座のオフセットを確かめる4手順
推測せず、手元のデータから逆算します。
- 基準になる既知の時刻を1つ決める。発表時刻が公的に決まっているイベントが扱いやすく、米雇用統計なら米国東部時間の午前8時30分です。その日の1分足を開き、値動きが跳ねた足のサーバー時刻を読み取ります。
- UTCとの差を計算する。東部時間はUTC-5（夏時間中はUTC-4）なので、発表はUTC 13:30（夏時間中は12:30）。チャート上の該当足の時刻との差が、その時点でのサーバー時刻のオフセットです。
- 切替をまたいだ2点で同じ計算をする。3月の第2日曜より前の週と後の週、それぞれでオフセットを出します。値が変わっていれば、そのサーバー時刻は夏時間に連動しています。変わらなければ固定オフセットの設定です。
- 日足の本数と区切りを数える。週あたりの日足が5本か6本か（短い日曜足があるか）、日足の始値がどの時刻の1時間足と一致するかを確認します。ここで日足の区切り時刻が確定します。
手順2と3は、同じ検算を2点で行うだけです。1点しか見ていないと「ずれていない」と誤って結論づけます。値が変わらないことを確かめる作業まで含めて1セットだと考えてください。
データの取り込み側でも同じ確認が要ります。欠損や重複を含めた点検の型は検証データの欠け・重複・時刻ずれを潰す手順に整理しています。併せて、どの仕様を固定しておくかは検証のブレを潰すデータ仕様7項目が参考になります。
記録と検証データで時刻をそろえる設計
確認できたら、ずれないように保存形式を決めます。原則は「保存はUTC、表示は好きな基準」です。
- 記録の列を分ける。取引記録に「UTC時刻」「サーバー時刻」の2列を持たせ、どちらが原本かを決めておきます。あとから片方だけを信じる事故が減ります。
- オフセット付きの書式で書く。国際標準化機構のISO 8601形式なら、末尾にZ（UTC）や+09:00のようにオフセットが付き、文字列だけで基準が分かります。表計算ソフトの日付型は入力環境のタイムゾーンを引きずることがあるため、文字列として持つ方が安全な場面があります。
- 時間帯フィルタは市場の現地時刻で定義する。「ロンドン時間の寄り付き後2時間」を検証したいなら、サーバー時刻の固定値ではなく、ロンドン現地時刻で条件を書き、そこからUTCへ変換します。タイムゾーンと夏時間の規則をまとめたIANAタイムゾーンデータベース（tz database）を使うライブラリなら、この変換を自前で書かずに済みます。
- 日足集計の区切りを明記する。「日足」と書くだけでは、区切りがUTC 0時なのかニューヨーククローズなのか分かりません。集計スクリプトのコメントか仕様メモに1行書いておきます。
記録項目そのものの作り方は取引記録は表計算で足りる──続く項目の決め方で扱っています。列を増やしすぎると続かないため、時刻列を2つに増やすなら、他のどこかを削る判断もセットで考えてください。
この確認が効かない場面
手順には前提があり、次の条件では別の調べ方が要ります。
- サーバー時刻が固定オフセットの業者。UTC固定などの設定なら夏時間で動きません。この場合、ずれの原因は別（データ提供元の基準違い、取り込みスクリプトの変換）にあります。
- 業者が途中でサーバー設定を変更した場合。過去の履歴に段差が残り、切替日前後で検証結果が不連続になります。古いデータほど、当時の設定が分からず復元が難しくなります。
- 株価指数CFDや個別株。原資産の取引所の立会時間に従うため、為替とは別の切替スケジュールになります。為替で合わせたオフセットをそのまま流用できません。
- データ提供元が複数。同じ通貨ペアでも、提供元ごとにタイムスタンプの基準（足の開始時刻か終了時刻か、どのタイムゾーンか）が違うことがあります。接ぎ木したデータは境界で必ず検算します。
- 切替当日そのもの。時計が進む日は存在しない1時間が生じ、戻る日は同じ時刻が2回現れます。重複行の削除処理が、この2回目を誤って消すことがあります。
また、1時間ずれを直しても検証結果が安定するとは限りません。時刻合わせは誤差の一因を取り除く作業であって、成績を改善する手法ではありません。切替前後で結果が大きく変わる戦略は、そもそもサンプル数が足りていない可能性を先に疑うべきです。
まとめ
サーバー時刻は業者が決めた設定値で、夏時間に連動していれば年2回、UTC基準で1時間動きます。確かめ方は、発表時刻が公的に決まっているイベントを基準に、切替日をまたいだ2点でオフセットを逆算することです。そのうえで、記録はUTCを原本にしてオフセット付きの書式で保存し、時間帯フィルタは市場の現地時刻で定義し直します。
一方で、固定オフセットの口座、設定変更をまたいだ古い履歴、提供元が異なるデータの接ぎ木、切替当日の重複・欠落には、この手順だけでは届きません。ここで扱ったのは誤差要因の切り分けであり、相場の方向を示すものではありません。検証環境の整備は損失を防ぐものではなく、記録と検証の前提を揃えるための作業です。投資判断はご自身の責任で行ってください。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
この記事は情報の提供を目的としたもので、特定の金融商品の売買をすすめるものではありません。売買の判断は、ご自身の責任で行ってください。（運営者情報）
