検証ラボ ── 2026-08-23

SQXにヒストリカルデータを取り込む — ダウンロード手順と「時間軸」を合わせる注意点

前回、Builderで戦略を生成するとき「銘柄はデータを取り込んだものから選ぶ」と書きました。今回はそのデータの取り込み方です。あわせて、見落とすと検証そのものが壊れる時間軸(タイムゾーン)の注意点を、実測を交えて説明します。

バックテストの信頼性はデータで決まります。ここは急がず丁寧にやる価値があります。

スクリーンショットはブラウザモードで撮影していますが、デスクトップ版と同じ画面です(Build 144時点)。

Data Managerを開く

左ナビゲーションの Data Manager を開くと、取り込み済みデータの一覧が表示されます。

Data Managerのメイン画面。取り込み済み銘柄の一覧に、Broker profile、Timeframe、Timezone、期間、レコード数などの列が並ぶ
Data Managerの画面。1行が1つのデータで、Timezone列に注目(後述)

上部の「Data sources」に、データの入手経路が並んでいます。ファイルからのインポートやMT5からの取り込みもできますが、まずは無料でまとまった期間が手に入るDukascopyデータから始めるのが手軽です。

ダウンロード手順(Dukascopyデータ)

  1. Data sources → Dukascopy data → Add new Dukascopy data symbol を選ぶ
  2. ダイアログで銘柄を選ぶ(FX主要ペアはM1が2003年から揃っています)
  3. Data type を選ぶ — 最初は M1 data で十分です(理由は後述)
  4. Broker profile を選ぶ — ここが時間軸合わせの本丸です(次のセクション)
  5. 最後に、ダイアログ下部の 「I confirm that I understand the following: …」と書かれたスイッチをクリックしてONにします。「このデータはDukascopyが無償提供しているもので、品質や提供の継続をStrategyQuantが保証するものではない」という注意書きへの同意スイッチで、ONにしないとSaveボタンが押せません
  6. Save を押すとダウンロードが始まります(進み具合は画面上部のProgressバーに出ます)
Add Dukascopy dataダイアログ。銘柄一覧と利用可能なデータ範囲、Data type(Tick/M1)、Broker profileの選択欄
追加ダイアログ。銘柄・Data type・Broker profileをここで決めます

所要時間とサイズの目安(私の実測)です。

項目実測値
M1・約23年分のダウンロード1銘柄あたり約9分30秒
M1・約23年分のレコード数約850万本
Tick・同期間のレコード数約5億件(M1の約60倍)

M1で十分というのはこの差のためです。H1やM15で戦略を生成する分にはM1データで問題なく、Tickが要るのは高精度リテストを本格的に使う段階になってからで遅くありません。

時間軸(タイムゾーン)を合わせる — 一番大事な注意点

チャートの時刻はブローカーごとに違う

同じEURUSDでも、どの時刻でローソク足を区切るかはブローカーごとに違います。多くの海外系MT4/5ブローカーは「NYクローズ=24:00」になる時刻を使い、しかも米国の夏時間に連動してUTCとの差が年内で変わります。SQXのBroker profile一覧を見ると、大半のブローカーのTimezoneが「EETUS」(米国DST連動)になっているのが分かります。

Broker profiles画面。Darwinex、Dukascopy、FTMO、ICMarkets、OANDAなどのプロファイルにTimezone列(EETUS、EET、Asia/Jerusalem)がある
Broker profiles。タイムゾーンとセッション定義をブローカー単位で持っています(EETUSが多数派ですが、EETやAsia/Jerusalemの業者もあります)

時刻の区切りが違えばバー境界が変わり、同じ戦略でもバックテスト結果が変わります。日足やH1を使う戦略、時間帯フィルタを持つ戦略ほど影響は大きくなります。

SQXで見かける時刻表記の読み方

Data Manager一覧のTimezone列(冒頭の画面)や、Broker profileのTimezone列には次のような表記が出てきます。意味が分かると設定で迷わなくなります。

表記意味
UTC世界標準時。夏時間の切り替えなし。SQ defaultプロファイルで取り込んだデータはこれになります
(EST+07) New York Trading hoursニューヨーク時間+7時間、つまりNYクローズ(NY17:00)がチャートの24:00に来る区切り。「DST: Yes」なら米国夏時間に連動します
EETUSベースはGMT+2/+3で、切り替えを米国の夏時間カレンダーで行う時刻。実質「NYクローズ=24:00」を年間通して保つ区切りで、海外系MT4/5ブローカーの多数派。SQXのブローカープロファイルの大半がこれです
EET東欧時間(切り替えは欧州の夏時間)。一部の業者が使います

ポイントはひとつで、「NYクローズ=24:00」(EST+07やEETUS)か、UTCかという大きな区別です。実運用予定のブローカーがMT4/5系なら、多くの場合はEETUS系のプロファイルを選ぶことになります。

日本時間に合わせたい場合

「国内業者を使うから日本時間に合わせる」と考えたくなりますが、ここは要注意です。MT4/MT5系なら、国内業者でもサーバー時刻はNYクローズ基準が多いからです(私が実測した国内系MT5業者もNY+7時間のEETUS型でした)。この場合、合わせるべきはEETUS系であって日本時間ではありません。

見分け方は、実運用するツールで日足が切り替わる時刻を見ることです。

日足の切り替わり時間軸SQXでの設定
朝6時ごろ(冬は7時)NYクローズ基準EETUS系のプロファイル(FTMO、ICMarkets等)をそのまま使う
深夜0時日本時間基準下記の手順で日本時間のプロファイルを自作する

日本時間(UTC+9・夏時間なし)基準のツール(国内業者の自社ツール系など)に合わせる場合は、プリセットに日本時間のプロファイルがないため自作します。

  1. Data Managerの Broker profiles → Add new で新しいプロファイルを作る
  2. Broker timezone で 「(UTC+09) Osaka, Sapporo, Tokyo, DST: No」 を選ぶ(実機で確認済みの表記です)
  3. データを取り込むときのBroker profileに、この自作プロファイルを指定する

ズレは静かに検証を壊す(実測)

私が実際に踏んだ例をひとつ。MT5ブローカーのデータと手元のデータを「GMT+3固定」とみなして突き合わせたところ、H1リターンの相関が0.61まで崩れ、終値に10pips超の”乖離” が見えました。一瞬「業者のフィードがおかしい」と疑いましたが、真因は夏時間でした。米国DSTに追従して変換し直すと、相関0.99・差はサブpipに回復。固定オフセットでは年の半分が1時間ズレていたのです。

さらに厄介なことに、USDJPYだけを確認したときは固定オフセットでも綺麗に見えました(データ元の時刻規約がたまたま一致していたため)。1銘柄の確認ではズレを見抜けないことがあります。

対策は「取り込むときに」決める

  • Broker profileを実運用予定のブローカーに合わせて選ぶ。 プロファイルがタイムゾーンとセッション定義を持っているので、ダウンロード時に選ぶだけで時間軸が揃います
  • 全銘柄で同じプロファイルに統一する。 銘柄ごとにバラバラだとバー境界がずれ、複数銘柄の比較で交絡要因になります(冒頭の画面の私のデータ一覧に、UTCとEST+07が混在した銘柄が写っています。過去の取り込み方針が揺れていた痕跡で、反面教師にしてください)
  • 取り込み後にタイムゾーンだけを変えるのは容易ではありません(少なくともCLIには変更手段がないことを確認しています)。最初に決めるのが安全です
  • ブローカーが未定なら、ひとまず既定(SQ default=UTC)で全銘柄を統一しておけば、少なくとも銘柄間の一貫性は保てます
  • 外部データと突き合わせて検証するときは、複数銘柄・夏冬両方の季節で確認します

まとめ

  • データは Data Manager → Dukascopy data からM1を取り込むのが手軽(1銘柄10分弱)
  • Tickは後回しでいい(M1の60倍重い)
  • 時間軸はダウンロード時のBroker profileで決まる。実運用ブローカーに合わせ、全銘柄で統一する
  • 時刻のズレは「業者フィードの欠陥」のような顔をして現れる。疑うべきはまず時刻規約

これでデータと生成の流れが一通り繋がりました。次回は、生成した戦略の結果(databank)の見方を扱う予定です。

※本記事の画面・実測値はBuild 144・2026-08時点・私の環境でのものです。データの提供元・範囲・画面構成は変わることがあります。