MT4のFX日足：ブローカー時間・日曜足・H4の時間整合

1. MT4の日足が実際に表すもの

D1は、ある日次区間に割り当てた価格の始値・高値・安値・終値、つまりOHLCを要約します。日付の付け方は足の構築方法によります。個人向けFXには、すべてのブローカーが表示しなければならない単一の集中管理された日足はありません。銘柄名が同じでも、配信元、Bid/Askの別、取引時間、足の境界が同じとは限りません。

本稿の目的は再現可能なデータの時間規則を定めることで、エントリー条件の提案ではありません。見やすいチャートが高収益のシグナルを生むとは限りません。まずH4/D1のスイング取引の枠組みを確認し、開発、その後の検証、フォワード観測で使う足の定義を記録します。

2. チャート比較前にデータ仕様を作る

ブローカーとサーバー、正確な銘柄名と接尾辞、元ファイルまたは配信元、Bid/Ask/仲値、時刻精度、過去のUTC変換、日次境界、取引日程を記録します。日曜、祝日、空の区間、同一時刻の重複、データ訂正の扱いも定めます。元データの版やハッシュを保存し、再実行時に同じ入力を識別できるようにします。

端末の表示やパソコンのタイムゾーンを変えるだけでは、ブローカー配信のOHLCは再構成されません。独自に再集計したデータは別のデータセットであり、独自の仕様が必要です。Bid足とAsk足、仲値足を混ぜ、差をすべて時刻のせいにしてはいけません。銘柄仕様ガイドで契約の特定方法を確認できます。

3. 同じ価格を二つの日次区間に分ける

表は計算用に作ったEUR/USDのBid価格列の全体であり、表以外の観測値は仮定しません。時刻はすべてUTCです。時計Aの月曜区間を[2026-08-02 21:00, 2026-08-03 21:00)、時計Bを[2026-08-03 00:00, 2026-08-04 00:00)とします。Aは終了日によって月曜と呼ぶ、という規則を明示しています。

左の角括弧は開始時刻ちょうどの価格を含み、右の丸括弧は終了時刻ちょうどの価格を含みません。したがって2026-08-03 21:00の価格はAの次の区間、2026-08-04 00:00の価格はBの次の区間に入ります。区間は重なりますが観測値の集合は違います。同じ価格列を使うことで区切り方の影響を分離しています。実際のブローカー比較では配信価格自体も異なり得ます。

4. 実際に含まれる観測値からOHLCを計算する

区間内の最初の価格がOpen、最後がClose、最大がHigh、最小がLowです。AはO 1.10000、H 1.10300、L 1.09800、C 1.10200、BはO 1.10050、H 1.10500、L 1.09800、C 1.10500です。1 pip = 0.0001なら、High−Lowの値幅はそれぞれ50 pipsと70 pipsです。

どちらの終値も、確定足を確認した後に自動的に約定できる価格ではありません。それぞれの区間内で最後に観測した値です。その後の注文には、その時点のBid/Askと約定記録が必要です。この疎な教材データは観測間の実際の市場高安値を主張するものではありません。ローソク足の読み方で各要素と価格の側を説明しています。

5. 過去の時差と夏時間でブローカー時刻を対応させる

条件付きのニューヨーク終値方式では、現地17:00はUTC−4のとき21:00 UTC、UTC−5のとき22:00 UTCです。サーバーの午前0時がそれぞれUTC+3またはUTC+2なら、この境界と一致します。これは時刻計算であり、全社の運用を示すものではありません。リンク先のOANDA FAQは同社の時刻をEST/GMT+2と表現していますが、その短い説明だけでは過去全体の夏時間規則は分かりません。

日付別のサーバー時刻とUTCの対応を保存し、切替前後の実際の足時刻を確認します。地域によって夏時間の切替日が違うため、現在の時差を全履歴に当てはめてはいけません。TimeGMTOffsetはローカルPCに関する関数で、過去のブローカー時差の保管庫ではありません。取引時間帯と夏時間のガイドが補足になります。日次境界と資金調達費用の締切も別々に定義します。

6. 予定終了と観測した確定を区別する

MT4時系列のインデックス0は形成中の現在足です。新しい足を観測すると、通常インデックス1は直前に存在する足になりますが、前の暦日とは限りません。対象銘柄、時間足、履歴の読込状況、足時刻を確認します。iTimeは足の開始時刻を返し、ローカル履歴が空なら0を返すことがあります。このゼロを有効な市場時刻として取引に使ってはいけません。

別の遅延配信例では、旧区間の最後の価格が20:59:58、境界が21:00、新区間の最初の価格が21:00:04です。予定終了は21:00でも、ティックで動く処理が切替を観測するのは21:00:04です。判断や約定を旧終値時点へ遡らせてはいけません。TimeCurrentはサーバーの最後に分かっている受信価格時刻を反映し、独立して連続的に進むUTC時計ではありません。

7. 日曜足の扱いを明示して選ぶ

別の架空条件として週の取引開始を日曜21:00 UTCとすると、UTC午前0時区切りには[日曜21:00, 月曜00:00)という3時間だけの短い足ができます。一方、日曜21:00から月曜21:00までのセッションなら、開始直後の価格は月曜区間に入ります。これは仮定した区間の説明であり、全ブローカーの開始時刻や命名方式ではありません。

短い足を残す、条件計算の対象から外す、特定の隣接足へ統合する、という選択は別のデータを作ります。シグナル計算から外しても実際の市場リスクや資金調達費用は消えません。統合には対象価格からのOHLC再計算が必要で、行の削除だけでは統合になりません。検証前に方針を決め、週の区切りや保有経過足数と整合させます。

8. 欠損区間と祝日をデータの問題として扱う

価格のない区間には、観測されたOpen、High、Low、Closeがありません。横ばいで取引可能な足を捏造したり、前の価格で埋めてブローカー履歴と呼んだりしてはいけません。予定休場、配信停止、未完了のダウンロードを区別します。欠損フラグを残し、モデルが待つのか、その判断を見送るのか、影響を受けた標本を除くのかを定義します。

足の位置は利用可能な観測の数であり、必ず24時間のブロックを数えるわけではありません。祝日を挟む七本は、より長い暦日範囲に及びます。iBarShiftはexact=falseなら欠損時に近い足を返すことがあり、exact=trueなら−1を返すことがあります。この設定は検索の動作であり完全性の証明ではないため、返された開始時刻と意図した区間も確認します。

9. 表示ラベルではなく区間でH4をそろえる

UTC午前0時基準を固定すると、H4の標準的な開始は00:00、04:00、08:00、12:00、16:00、20:00 UTCです。日次境界を21:00 UTCとし、そこから四時間ずつ区切ると、21:00、01:00、05:00、09:00、13:00、17:00になります。これは時差固定時の規則的な区間です。欠けたセッションや時刻切替には別の処理が必要です。

D1の判断境界21:00 UTCでは、UTC基準のH4 [20:00, 00:00)はまだ形成中です。最終的な高値、安値、終値には未来の情報が含まれます。この基準で予定終了済みの最新H4は[16:00, 20:00)で、実データの利用可否も確認します。A基準の[17:00, 21:00)はD1と同時に終わります。他の配信元のH4インデックスをコピーせず、終了区間と利用可能時点で選びます。

10. 時間規則の変更はNR7の選択も変える

別の架空NR7例では、先行する対象日足六本の値幅を両時計とも55、60、65、80、75、90 pipsとします。候補の値幅が六本すべてより厳密に小さい場合だけ合格と定義します。Aの50 pipsは合格、Bの70 pipsは70が55未満ではないので不合格です。先行値は説明用の入力で、九つの価格の表から再構成したものではありません。

実際の再集計では先行六本の値幅も変わり得るため、最新足だけでなく参照期間全体を再計算します。同値、短い足の採用、欠けたセッションの規則を先に決めます。これはデータ由来条件の感応度を示すだけで、NR7の売買条件、出口、バックテスト、収益を提案しません。結果を見て最も儲かった時計を選ばないことが重要です。

11. 週の参照値と保有期間に同じ暦を使う

週の参照区間には開始、終了、タイムゾーン、対象セッション、利用可能時刻が必要です。日足五行や六行だけでは確定週は定義できません。配信元のW1を使うなら実際の開始時刻と規則を調べます。週を再構成するなら、元の観測値または正しく整合した構成足を集計し、後の情報を除きます。

対象となる確定足が一定本数進んだ後の決済、経過時間による決済、金曜の指定時刻の決済も区別します。祝日や短い足によって発動時点は変わります。資金調達費用は別問題です。スワップとロールオーバーのガイドでは、D1の本数や経過した夜の数だけで費用計算日数が決まらない理由を説明します。

12. 利用可能な情報だけで日次判断を行う

別の遅延例では21:00:04に確定を観測し、必要な足を検証し、21:00:05の新しい価格を評価します。架空の有効期限を21:01:00に固定すると、他の事前条件もすべて満たした場合だけ評価対象になります。21:01:01の価格は遅く、MT4を再起動しても機会は復活しません。これは順序の例で、推奨執行時間幅ではありません。

仮の注文前に、有効な履歴、新鮮な価格、許容スプレッド、銘柄の取引可否、一意の判断記録を要求します。この例では、不明なデータや期限切れイベントから新規要求を出しません。要求、拒否、約定、再試行の状態は別々に記録します。終値シグナルは終値約定ではありません。取引記録の照合ガイドがイベント管理を補足します。

13. 足の構築確認と約定の仮定を分ける

最初に元価格、区間への所属、計算したOHLCを比べます。次にシグナル条件と初めて観測できた時刻を比べます。その後で初めて、実際または模擬の約定可能価格、スプレッド、手数料、資金調達費用、ギャップを調べます。データ段階の不一致をスリッページや数量の調整で説明してはいけません。

配信比較では時刻と価格の側の定義を共有し、共通観測がない場所も報告します。見た目の類似度や最終利益の一致だけでは足の一致は証明できません。見送り判断を含め、予定した差と実際の差を保存します。配信元の足と独自集計足は明確に区別し、結果を実際に使用したデータへ対応させます。

14. 過去全体と再起動時の時計を検証する

通常の週、関係する夏時間切替の前後、日曜の開始、祝日、既知の欠損を調べます。構成H4がD1区間に収まるか、重複処理が一貫しているか、再実行で同じ結果になるかを確認します。訂正データは新しい版として保存し、過去の結果の根拠を黙って上書きしません。

再起動では最後に処理した判断と状態を復元し、逃した約定を作り出したり重複注文したりしてはいけません。履歴の読込遅延による延期または失効は事前規則に従います。MT4バックテストのガイドで一般的な限界を確認できます。一度の集計成功は売買モデルや実運用約定の妥当性を証明しません。

15. 成績比較の前に仕様を固定する

元データ識別子、価格の側、時刻変換、過去の時差表、日次・週次境界、区間所属規則、短い足と欠損の扱い、H4利用可能性テストを保存します。モデル版、判断期限、再起動対応も加えます。監査記録は元観測、足、条件判定、その後の口座イベントを結び、各時刻を一つにまとめません。

時間規則を変えたらデータまたはモデルを新しい版にし、開発検査を再実行したうえで未使用の後続データを時系列順に評価します。却下した構成と選択理由も残します。何度も比較して過去で最も魅力的な足を選ぶと、OHLCの計算がすべて正しくても選択バイアスが生まれます。

16. 再現可能な日足チェックを使う

D1結果を信頼する前に、配信元と価格の側、開始と終了、過去のUTC時差、日曜・祝日の方針、最後の確定H4、最初の観測時刻に答えられるようにします。小さな既知サンプルを手計算し、欠損処理を確認し、別の実行でも追える版管理済みの仕様一覧を残します。

目標は、価格から確定情報へ、さらに約定可能かもしれないイベントへ至る過程を説明することです。どの時計、ローソク足パターン、週五日表示も収益改善を保証しません。教材例は、当サイト掲載の商用EAが同じ規則を使うことや判断を再現することを証明しません。不一致の記録は、成績比較の前に調査や採用見送りを行う根拠になります。

よくある質問

出典と学習上の注意

MetaQuotesの時系列インデックス、足の時刻、履歴欠損時の仕様を確認しました。iTime、iBarShift、TimeCurrent、TimeGMTOffsetの資料も確認しています。OANDAのFAQは同社の時刻説明であり、全MT4共通の日程や過去の夏時間対応表を示すものではありません。価格列、値幅、判断時系列はすべて架空の教材です。集計・検証規則は明示した編集上の定義で、戦略の成績を裏付けるものではありません。

• MetaQuotes · MQL4 timeseries and indicators
• OANDA · MT4 daily-candle timing

教育用の内容です。価格、日程、判断例は架空です。FX取引にはリスクがあります。正しい足の構築は、収益性、約定の保証、将来の成績を証明しません。