【MQL5】TimeCurrent関数の使い方と自動売買実装コード

1. TimeCurrent関数の概要と実務での活用法

TimeCurrentは、MQL5で「最後にサーバーが受信した気配値（ティック）の時刻」を取得するための非常に重要な関数です。言い換えれば、ブローカー側の最新時刻を知るための手段です。

実務開発において、初心者が最もつまずきやすいのが「PCの時計（ローカル時刻）」と「ブローカーの時計（サーバー時刻）」の混同です。FXのチャートはブローカーのサーバー時刻に基づいて形成されるため、エントリー判定やセッション終了のロジックにPCの時刻（TimeLocal）を使ってしまうと、夏時間（サマータイム）の切り替わりや時差によって、意図しないタイミングで売買が行われるリスクがあります。

TimeCurrentを活用することで、以下のような実装が可能になります。
* 特定の時間帯（例：ロンドン市場開始時）のみ取引するロジック
* 週末の閉場間際にポジションを強制決済する処理
* 一定時間以上、価格が更新されていない（流動性が低い）状態の検知

2. 構文と戻り値

TimeCurrent関数には2種類の呼び出し方があります。

1. 単純に時刻を取得する場合

datetime TimeCurrent();

• 戻り値: 1970年1月1日0時からの経過秒数（datetime型）を返します。

2. 時刻の詳細情報（年・月・日・曜など）を同時に取得する場合

datetime TimeCurrent(MqlDateTime& dt_struct);

• パラメーター: MqlDateTime構造体の変数を参照渡しします。
• 戻り値: 同様にdatetime型の値を返しますが、同時に引数の構造体の中に「年・月・日・時・分・秒・曜日」などの詳細データが格納されます。

3. 具体的な使い方・実践サンプルコード

以下は、TimeCurrentを使用して「特定の時間帯のみエントリーを許可し、かつ週末の金曜深夜に自動決済する」という実用的なEAのロジック例です。

//+------------------------------------------------------------------+
//| サーバー時刻に基づいた取引制限のサンプル                                |
//+------------------------------------------------------------------+
void OnTick()
{
    // 現在のサーバー時刻を取得（構造体も同時に利用）
    MqlDateTime now;
    datetime currentTime = TimeCurrent(now);

    // 1. サーバー時刻をログに出力（デバッグ用）
    // TimeToStringを使うと読みやすい文字列になります
    Print("現在のサーバー時刻: ", TimeToString(currentTime));

    // 2. 曜日判定の例 (now.day_of_week: 0=日曜, 5=金曜, 6=土曜)
    if(now.day_of_week == 5 && now.hour >= 22)
    {
        Print("金曜の22時を過ぎたため、新規エントリーを停止しポジションを整理します。");
        // ここに決済ロジックを記述
        return;
    }

    // 3. 特定の時間帯（例：サーバー時間 9時〜17時）のみ取引する判定
    if(now.hour >= 9 && now.hour < 17)
    {
        // エントリーロジック
        // if(Signal) Trade.Buy(...);
    }
}

4. 使用上の注意点とよくあるエラー

ティックが動いていないと更新されない

TimeCurrentは「最後に受信したティックの時刻」です。そのため、土日の閉場中や、極端に流動性が低く価格が全く動いていない状況では、実際のリアルタイム時刻が経過していてもTimeCurrentの戻り値は古い時刻のまま止まってしまいます。

TimeLocalとの使い分け

バックテストではTimeCurrentはテストデータの時刻に従いますが、TimeLocalはテストを実行しているPCの時刻に従ってしまいます。ロジック内で時刻判定を行う場合は、必ずTimeCurrentを使用してください。 そうしないと、バックテストと実運用で挙動が乖離する原因になります。

夏時間の考慮

多くのブローカー（GMT+2/DST+3）では、夏時間になるとサーバー時刻自体が1時間シフトします。TimeCurrentで取得できるのはあくまでその「シフト後の時刻」であるため、日本の感覚で「16時になったらロンドン開始」と固定値で書くと、夏時間の切り替わりで1時間のズレが生じます。

5. 【重要】自動売買における約定スピードと環境の罠

アルゴリズムトレードにおいて、TimeCurrentで取得する「時刻」がいかに正確であっても、あなたのEAが注文を出してからサーバーに届くまでの「物理的な距離」が遠ければ、その間に価格は無情にも変動します。自宅のPCから一般的なインターネット回線を経由して注文を送る場合、数百ミリ秒（0.x秒）の遅延（レイテンシ）が発生することは避けられません。このわずかな遅れが原因で、本来の価格から滑って約定する「スリッページ」が発生し、期待していた利益が削られ、最悪の場合は致命的な損失を招きます。

プロのクオンツや勝ち続けている個人トレーダーにとって、取引サーバーの目と鼻の先に位置する専用のVPS（仮想専用サーバー）を利用することは、もはや「推奨」ではなく「絶対条件」です。専用VPSを利用することで、ネットワーク遅延を極限まで排除し、コンマ数秒を争う約定スピードの優位性を確保できます。24時間365日、安定した高速回線でEAを稼働させ続けるインフラ環境を整えることこそが、聖杯を探すことよりも先に着手すべき、自動売買における最も確実なリスクヘッジなのです。