MQL5 latency-problemsの原因と対処法｜EA遅延を改善

この記事の結論

MQL5のlatency-problemsは、EAの計算処理だけでなく、ティック受信、VPS環境、ブローカーの約定条件、スプレッド拡大、注文前チェック不足が重なって起きます。
最短で確認すべき点は、OnTick内の処理時間、OrderSend前後の時刻差、スプレッド、約定結果コード、VPSと取引サーバーの距離です。
EA側では、重い処理をOnTickに集中させず、注文前にOrderCheckで条件を確認し、約定結果をMqlTradeResultで記録する設計が重要です。
バックテストでは通信遅延や実際の約定差を完全には再現できないため、実運用前にデモ口座や小さいロットでフォワードテストを行う必要があります。

1. 最短確認リスト

【結論】
MQL5のlatency-problemsでは、まずEA内部の処理遅延と、取引環境側の約定遅延を分けて確認します。
OnTickの処理時間、OrderSendの前後時刻、スプレッド、約定結果コードをログに残すと、原因を切り分けやすくなります。

最初に確認する項目は次のとおりです。

MQL5のEAでは、OnTickが新しいティックを受け取るたびに実行されます。
OnTick内で毎回重い計算、全ポジション走査、全履歴走査、複数インジケータの値取得を行うと、次のティックへの反応が遅れやすくなります。

1.1 最初に残すべきログ

遅延の原因を調べるには、感覚ではなくログで確認します。
注文前、OrderCheck後、OrderSend後、約定結果の4点を記録すると、EA側の処理と取引環境側の遅延を分けられます。

void PrintExecutionLog(const string step)
{
   MqlTick tick;
   if(SymbolInfoTick(_Symbol, tick))
   {
      Print(step,
            " time=", TimeToString(TimeCurrent(), TIME_DATE|TIME_SECONDS),
            " bid=", DoubleToString(tick.bid, _Digits),
            " ask=", DoubleToString(tick.ask, _Digits),
            " spread_points=", (tick.ask - tick.bid) / _Point);
   }
   else
   {
      Print(step, " failed to get current tick");
   }
}

2. 症状別クイック診断

【結論】
latency-problemsは、症状ごとに疑う場所が異なります。
注文だけが遅い場合は約定環境を疑い、EA全体が重い場合はOnTick内の処理量を疑います。

MQL5のlatency-problemsは、EAコードだけで完結しない場合があります。
注文が取引サーバーへ送られる以上、通信環境、ブローカー仕様、約定方式、銘柄の取引条件が結果に影響します。

2.1 EA処理遅延と約定遅延の違い

EA処理遅延は、OnTick内の条件判定やデータ取得が重いことで発生します。
約定遅延は、OrderSend後に取引サーバーから結果が返るまでの時間や、実際の価格変化によって発生します。

EA処理遅延はコード改善で抑えやすいです。
約定遅延はコードだけでは完全に制御できないため、許容スリッページ、注文前チェック、取引時間フィルター、VPS環境の見直しが必要です。

3. エラーの主な原因

【結論】
MQL5のlatency-problemsの主な原因は、OnTickへの処理集中、インジケータ値の過剰取得、注文前チェック不足、スプレッド拡大、通信環境の5つです。
原因を一つに決めつけず、EA内部と取引環境の両方を確認します。

3.1 OnTickに処理を詰め込みすぎている

OnTickは新しいティックを受け取るたびに呼ばれます。
そのため、毎回すべての履歴を走査したり、複数銘柄の大量データを取得したりすると、次のティックへの反応が遅れます。

重くなりやすい処理は次のとおりです。

• 全バーを毎ティックで走査する
• CopyBufferで必要以上の本数を取得する
• すべての注文履歴を毎ティックで確認する
• Printを大量に出力する
• ファイル書き込みを毎ティックで行う
• 複数銘柄の処理を無制限に回す

3.2 インジケータハンドルの使い方が不適切

MQL5では、多くのインジケータ関数は値を直接返すのではなく、インジケータハンドルを作成します。
EAではOnInitでハンドルを作成し、OnTickでCopyBufferを使って必要な値を取得する流れになります。

毎ティックでiMAやiATRなどのハンドルを作成すると、処理が重くなりやすいです。
ハンドルは原則としてOnInitで作成し、OnDeinitでIndicatorReleaseを使って解放します。

3.3 注文前チェックが不足している

OrderSendの直前に、ロット、証拠金、ストップレベル、フリーズレベル、取引可能時間、スプレッドを確認していない場合、注文が拒否されたり遅延して見えたりします。
MQL5のEAでは、MqlTradeRequestを作成した後、必要に応じてOrderCheckで注文条件を確認します。

3.4 実運用環境の影響を受けている

実運用では、バックテストと異なり通信遅延、サーバー応答、スリッページ、スプレッド拡大が発生します。
VPSの場所、回線品質、取引サーバーの混雑、銘柄の流動性によって、同じEAでも挙動が変わる場合があります。

4. 解決手順

【結論】
解決手順は、計測、切り分け、軽量化、注文前チェック、フォワード確認の順に進めます。
最初からパラメータを変更するより、どこで遅れているかをログで確認することが重要です。

4.1 処理時間を測定する

まず、OnTickの入口と出口で処理時間を測ります。
処理時間が長い場合は、EA内部の計算やデータ取得を見直します。

void OnTick()
{
   ulong start_ms = GetTickCount();

   // シグナル判定、フィルター判定、注文判定をここで実行する

   ulong elapsed_ms = GetTickCount() - start_ms;
   if(elapsed_ms > 100)
   {
      Print("OnTick processing is slow. elapsed_ms=", elapsed_ms);
   }
}

このコードは、OnTickの処理が一定時間を超えた場合だけログを出します。
毎ティックで詳細ログを出すと、ログ出力自体が遅延要因になる場合があります。

4.2 CopyBufferの取得本数を減らす

インジケータ値は、必要な本数だけ取得します。
最新足と確定足を使う場合でも、通常は数本で足ります。

int ma_handle = INVALID_HANDLE;

int OnInit()
{
   ma_handle = iMA(_Symbol, _Period, 20, 0, MODE_SMA, PRICE_CLOSE);

   if(ma_handle == INVALID_HANDLE)
   {
      Print("Failed to create MA handle");
      return INIT_FAILED;
   }

   return INIT_SUCCEEDED;
}

void OnDeinit(const int reason)
{
   if(ma_handle != INVALID_HANDLE)
   {
      IndicatorRelease(ma_handle);
   }
}

bool GetMaValues(double &current_ma, double &closed_ma)
{
   const int CURRENT_BAR_INDEX = 0;
   const int CLOSED_BAR_INDEX = 1;
   const int REQUIRED_BARS = 3;

   if(BarsCalculated(ma_handle) < REQUIRED_BARS)
   {
      Print("MA data is not ready");
      return false;
   }

   double ma_buffer[];
   ArraySetAsSeries(ma_buffer, true);

   int copied = CopyBuffer(ma_handle, 0, 0, REQUIRED_BARS, ma_buffer);
   if(copied < REQUIRED_BARS)
   {
      Print("CopyBuffer failed or not enough data. copied=", copied);
      return false;
   }

   current_ma = ma_buffer[CURRENT_BAR_INDEX];
   closed_ma  = ma_buffer[CLOSED_BAR_INDEX];
   return true;
}

MQL5では、配列を時系列として扱うかどうかで、最新足と過去足の位置が変わります。
ArraySetAsSeriesを使う場合、CURRENT_BAR_INDEXが最新足、CLOSED_BAR_INDEXが1本前の足になります。

4.3 OrderSend前にOrderCheckを入れる

注文が遅い、拒否される、結果が不安定に見える場合は、OrderSend前に注文条件を確認します。
OrderCheckは、証拠金やロットなどの条件が注文前に成立しそうかを確認するために使います。

bool SendMarketBuy(const double lot)
{
   MqlTick tick;
   if(!SymbolInfoTick(_Symbol, tick))
   {
      Print("Failed to get tick");
      return false;
   }

   double min_lot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double max_lot  = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double lot_step = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);

   if(lot < min_lot || lot > max_lot)
   {
      Print("Invalid lot size. lot=", lot, " min=", min_lot, " max=", max_lot);
      return false;
   }

   double normalized_lot = MathFloor(lot / lot_step) * lot_step;
   if(normalized_lot < min_lot)
   {
      Print("Normalized lot is too small. lot=", normalized_lot);
      return false;
   }

   MqlTradeRequest request;
   MqlTradeResult result;
   MqlTradeCheckResult check;
   ZeroMemory(request);
   ZeroMemory(result);
   ZeroMemory(check);

   request.action    = TRADE_ACTION_DEAL;
   request.symbol    = _Symbol;
   request.volume    = normalized_lot;
   request.type      = ORDER_TYPE_BUY;
   request.price     = tick.ask;
   request.deviation = 20;
   request.magic     = 12345;
   request.comment   = "latency test order";

   PrintExecutionLog("Before OrderCheck");

   if(!OrderCheck(request, check))
   {
      Print("OrderCheck failed. retcode=", check.retcode, " comment=", check.comment);
      return false;
   }

   PrintExecutionLog("Before OrderSend");

   ulong send_start_ms = GetTickCount();
   bool sent = OrderSend(request, result);
   ulong send_elapsed_ms = GetTickCount() - send_start_ms;

   Print("OrderSend result. sent=", sent,
         " retcode=", result.retcode,
         " deal=", result.deal,
         " order=", result.order,
         " elapsed_ms=", send_elapsed_ms,
         " comment=", result.comment);

   return sent && (result.retcode == TRADE_RETCODE_DONE || result.retcode == TRADE_RETCODE_PLACED);
}

このコードは検証用のサンプルです。
実運用では、既存ポジション、口座タイプ、損切り、利確、ストップレベル、フリーズレベル、取引可能時間を追加で確認する必要があります。

5. コード例

【結論】
遅延対策の基本コードは、OnInitで準備し、OnTickで軽く判定し、OrderSend前後を計測する構造にします。
MQL5では、インジケータ取得、注文前チェック、注文結果ログを分けると原因を追いやすくなります。

次のサンプルは、移動平均線を使った簡単な条件判定と、注文前チェック、注文送信時間のログをまとめた例です。
売買判断の優位性を示すものではなく、latency-problemsの確認用サンプルです。

#property strict

input double InpLot = 0.10;
input int    InpMaxSpreadPoints = 30;

int ma_handle = INVALID_HANDLE;
datetime last_bar_time = 0;

int OnInit()
{
   ma_handle = iMA(_Symbol, _Period, 20, 0, MODE_SMA, PRICE_CLOSE);
   if(ma_handle == INVALID_HANDLE)
   {
      Print("Failed to create MA handle");
      return INIT_FAILED;
   }

   return INIT_SUCCEEDED;
}

void OnDeinit(const int reason)
{
   if(ma_handle != INVALID_HANDLE)
   {
      IndicatorRelease(ma_handle);
   }
}

void OnTick()
{
   ulong start_ms = GetTickCount();

   MqlTick tick;
   if(!SymbolInfoTick(_Symbol, tick))
   {
      Print("Failed to get tick");
      return;
   }

   double spread_points = (tick.ask - tick.bid) / _Point;
   if(spread_points > InpMaxSpreadPoints)
   {
      Print("Spread is too wide. spread_points=", spread_points);
      return;
   }

   datetime current_bar_time = iTime(_Symbol, _Period, 0);
   if(current_bar_time == last_bar_time)
   {
      return;
   }
   last_bar_time = current_bar_time;

   double ma_current = 0.0;
   double ma_closed = 0.0;
   if(!GetMaValues(ma_current, ma_closed))
   {
      return;
   }

   if(tick.bid > ma_closed)
   {
      SendMarketBuy(InpLot);
   }

   ulong elapsed_ms = GetTickCount() - start_ms;
   if(elapsed_ms > 100)
   {
      Print("OnTick elapsed_ms=", elapsed_ms);
   }
}

bool GetMaValues(double &current_ma, double &closed_ma)
{
   const int CURRENT_BAR_INDEX = 0;
   const int CLOSED_BAR_INDEX = 1;
   const int REQUIRED_BARS = 3;

   if(BarsCalculated(ma_handle) < REQUIRED_BARS)
   {
      return false;
   }

   double ma_buffer[];
   ArraySetAsSeries(ma_buffer, true);

   int copied = CopyBuffer(ma_handle, 0, 0, REQUIRED_BARS, ma_buffer);
   if(copied < REQUIRED_BARS)
   {
      Print("CopyBuffer failed. copied=", copied);
      return false;
   }

   current_ma = ma_buffer[CURRENT_BAR_INDEX];
   closed_ma = ma_buffer[CLOSED_BAR_INDEX];
   return true;
}

bool SendMarketBuy(const double lot)
{
   MqlTick tick;
   if(!SymbolInfoTick(_Symbol, tick))
   {
      return false;
   }

   MqlTradeRequest request;
   MqlTradeResult result;
   MqlTradeCheckResult check;
   ZeroMemory(request);
   ZeroMemory(result);
   ZeroMemory(check);

   request.action = TRADE_ACTION_DEAL;
   request.symbol = _Symbol;
   request.volume = lot;
   request.type = ORDER_TYPE_BUY;
   request.price = tick.ask;
   request.deviation = 20;
   request.magic = 12345;
   request.comment = "latency check";

   if(!OrderCheck(request, check))
   {
      Print("OrderCheck failed. retcode=", check.retcode, " comment=", check.comment);
      return false;
   }

   ulong start_ms = GetTickCount();
   bool sent = OrderSend(request, result);
   ulong elapsed_ms = GetTickCount() - start_ms;

   Print("OrderSend sent=", sent,
         " retcode=", result.retcode,
         " elapsed_ms=", elapsed_ms,
         " comment=", result.comment);

   return sent && (result.retcode == TRADE_RETCODE_DONE || result.retcode == TRADE_RETCODE_PLACED);
}

このサンプルでは、新しいバーができたタイミングだけシグナル判定を行います。
毎ティックで注文判定を行う必要がないロジックでは、新しいバー単位にすると処理量を抑えやすくなります。

6. 環境別の注意点

【結論】
latency-problemsは、ローカルPC、VPS、バックテスト、デモ口座、リアル口座で見え方が変わります。
同じEAでも、接続先サーバー、口座タイプ、銘柄仕様、約定方式によって結果が変わる場合があります。

6.1 ローカルPCでの注意点

ローカルPCでは、他のアプリケーション、ネットワーク負荷、省電力設定、無線回線の不安定さが影響します。
EAを常時稼働させる場合、PCの再起動、通信断、スリープ設定も確認対象になります。

6.2 VPSでの注意点

VPSは、取引サーバーとの物理的な距離が近いほど通信遅延を抑えやすくなります。
ただし、VPSのCPU、メモリ、ディスク負荷が高い場合、EAの処理自体が遅くなる場合があります。

6.3 バックテストでの注意点

バックテストでは、通信遅延や実際のサーバー応答はそのまま再現されません。
そのため、バックテストが良好でも、実運用で同じ約定価格や同じ反応速度になるとは限りません。

バックテストで見るべき項目は次のとおりです。

• 総損益
• 最大ドローダウン
• 勝率
• 損益比
• 取引回数
• 連敗数
• スプレッド条件
• 期間依存性
• パラメータ依存性

6.4 フォワードテストでの注意点

フォワードテストでは、実際のティック受信、スプレッド変動、約定差、取引頻度を確認します。
特に、バックテストとの差が大きい場合は、シグナルの優位性ではなく、約定条件やスプレッド条件が成績に影響している可能性があります。

フォワードテストで見るべき項目は次のとおりです。

• 約定差
• スプレッド拡大時の挙動
• 取引頻度
• ドローダウン
• バックテストとの乖離
• ブローカー差
• VPS環境での安定性

7. よくある失敗

【結論】
よくある失敗は、遅延の原因をEAコードだけに限定してしまうことです。
MQL5の自動売買では、コード、取引条件、通信環境、口座タイプを分けて確認する必要があります。

7.1 毎ティックで重い処理を実行している

全履歴の走査や大量のCopyBufferを毎ティックで実行すると、処理が遅くなります。
新しいバーで十分なロジックは、バー更新時だけ判定する設計にします。

7.2 Printを大量に出している

デバッグ中にPrintを大量に出すと、ログ出力が遅延要因になります。
実運用では、異常時だけ詳細ログを出す設計にした方が安定しやすいです。

7.3 スプレッドを見ていない

スプレッドが広い状態で注文すると、エントリー直後から不利な価格になりやすいです。
スプレッド条件は、注文前フィルターとして確認します。

7.4 口座タイプを考慮していない

MQL5では、netting口座とhedging口座でポジション管理の考え方が異なります。
netting口座では銘柄ごとにポジションが統合され、hedging口座では複数ポジションを持てる場合があります。

7.5 OrderSendの結果を確認していない

OrderSendを呼んだだけでは、意図した約定が成立したとは限りません。
MqlTradeResultのretcode、deal、order、commentを確認し、失敗時の処理を分ける必要があります。

8. 再発防止策

【結論】
再発防止には、EAの処理を役割ごとに分離し、注文前後のログを標準化することが有効です。
相場認識、フィルター判定、シグナル判定、注文前チェック、注文送信、約定後管理を分けると、遅延の原因を追いやすくなります。

EAの処理は、次の流れで整理します。

相場認識
↓
フィルター判定
↓
シグナル判定
↓
リスク確認
↓
注文前チェック
↓
注文送信
↓
約定後管理
↓
決済・停止判定

8.1 ログ設計を標準化する

ログには、時刻、銘柄、スプレッド、注文条件、OrderCheck結果、OrderSend結果を入れます。
ログの粒度をそろえると、問題発生時に比較しやすくなります。

8.2 処理を新しいバー単位に寄せる

スキャルピングのようにティック単位の反応が必要なEAを除き、多くのロジックでは新しいバー単位の判定で十分な場合があります。
新しいバー単位にすると、不要な計算と注文判定を減らせます。

8.3 注文前チェックを関数化する

スプレッド、ロット、証拠金、取引時間、既存ポジション、ストップレベルの確認を関数にまとめると、実装漏れを減らせます。
注文処理を複数箇所に分散させると、エラー処理やログの差が生まれやすくなります。

9. 実運用での注意点

【結論】
実運用では、latency-problemsを完全にゼロにすることはできません。
EA設計では、遅延が発生しても損失が拡大しにくい条件、注文停止条件、リスク制限を入れる必要があります。

9.1 バックテスト結果は将来の利益を保証しない

バックテストは、過去データ上でロジックの挙動を確認するためのものです。
実運用では、スプレッド、約定、スリッページ、通信環境、ブローカー仕様が変わるため、バックテストと同じ結果になるとは限りません。

9.2 スプレッド拡大時の停止条件を入れる

指標発表前後や流動性が低い時間帯では、スプレッドが急に広がる場合があります。
スプレッドが一定以上の場合は新規注文を停止する設計にすると、不利な約定を避けやすくなります。

9.3 レバレッジとドローダウンを管理する

レバレッジが高いほど、少しの価格変動でも有効証拠金が大きく変動しやすくなります。
実運用前に、最大ドローダウン、連敗数、ロット上限、停止条件を決めておく必要があります。

9.4 デモ口座とリアル口座の差を確認する

デモ口座とリアル口座では、約定条件やスプレッドの動きが異なる場合があります。
デモ口座で問題がなくても、リアル口座では注文結果や約定価格が変わることがあります。

10. まとめ

【結論】
MQL5のlatency-problemsは、EA内部の処理、インジケータ取得、注文前チェック、通信環境、ブローカー仕様を分けて確認すると解決しやすくなります。
ログで遅延箇所を特定し、OnTickを軽くし、OrderCheckとMqlTradeResultで注文条件と結果を確認することが基本です。

重要なポイントは次のとおりです。

• OnTickの処理時間を測定する
• CopyBufferは必要な本数だけ取得する
• インジケータハンドルはOnInitで作成する
• OnDeinitでIndicatorReleaseを使う
• OrderSend前にOrderCheckを使う
• MqlTradeResultのretcodeを確認する
• スプレッド、約定差、ブローカー条件を確認する
• バックテストだけで判断しない
• フォワードテストで実運用に近い挙動を確認する

latency-problemsへの対応は、単に高速化するだけでは不十分です。
遅延が起きた場合でも、リスクが拡大しにくいEA設計にすることが重要です。

FAQ

MQL5のlatency-problemsとは何ですか？

MQL5のlatency-problemsとは、EAの処理、注文送信、約定結果の取得、通信環境などで遅れが発生する問題です。EA内部の処理遅延と、取引サーバー側の約定遅延を分けて確認する必要があります。

OnTickが遅い場合は何を確認すべきですか？

OnTickが遅い場合は、全履歴走査、大量のCopyBuffer、過剰なPrint、毎ティックのファイル書き込みを確認します。新しいバー単位で十分な処理は、毎ティックではなくバー更新時に限定すると軽くなります。

OrderSendが遅い場合はEAコードだけを直せばよいですか？

OrderSendが遅い場合、EAコードだけでなく通信環境、VPS、ブローカーの約定方式、スプレッド、サーバー応答も確認します。OrderSend前後の時刻差とMqlTradeResultのretcodeをログに残すと切り分けやすくなります。

CopyBufferはlatency-problemsの原因になりますか？

CopyBufferは、取得本数が多すぎる場合や複数インジケータを毎ティックで大量に取得する場合に処理負荷の原因になります。必要な本数だけ取得し、ハンドルはOnInitで作成する設計が基本です。

バックテストで遅延を確認できますか？

バックテストではEA内部の処理負荷やロジックの挙動は確認できますが、実際の通信遅延やリアルな約定差は完全には再現されません。実運用前にはフォワードテストでスプレッド、約定差、取引頻度を確認する必要があります。

latency-problemsを防ぐためにVPSは必要ですか？

VPSは取引サーバーとの距離や稼働安定性を改善しやすい手段ですが、すべての遅延を解消するものではありません。EAの処理負荷、注文前チェック、スプレッド条件も同時に確認する必要があります。

実運用で特に注意すべき点は何ですか？

実運用では、スプレッド拡大、スリッページ、約定遅延、ブローカー仕様、口座タイプの違いに注意します。バックテスト結果は将来の利益を保証しないため、フォワードテストとリスク制限を組み合わせて確認します。