MQL5のtick processing optimization実装と最適化設計

この記事の結論

MQL5のtick processing optimizationは、EAのOnTickで毎ティック実行する処理を整理し、不要な計算・重複注文・過剰なインジケータ取得を減らす設計です。
毎ティック処理、確定足ごとの処理、一定間隔の処理を分離すると、EAの挙動を検証しやすくなります。
インジケータ値はOnInitでハンドルを作成し、OnTickでは必要なタイミングだけCopyBufferで取得する構造にします。
ただし、処理を軽くしても売買成績が改善するとは限りません。バックテストとフォワードテストで、約定差・スプレッド・取引頻度・ドローダウンを確認する必要があります。

1. このロジックの役割

【結論】
MQL5のティック処理最適化は、EAの判断処理を軽くしながら、売買条件の判定タイミングを明確にするための設計です。
OnTickにすべての処理を詰め込むのではなく、処理の頻度ごとに役割を分けます。

ティックとは、銘柄価格が更新されたときに発生する価格更新イベントです。MQL5のEAでは、新しいティックを受信するとOnTickが呼び出されます。

ティック処理最適化で重要なのは、単に処理速度を上げることではありません。EAが「いつ相場を確認し、いつ注文判定を行い、いつ注文を送るか」を明確にすることが目的です。

【定義】
ティック処理最適化とは、OnTickで実行する処理を必要最小限に整理し、足更新・シグナル判定・注文管理・ログ出力を適切な頻度に分ける設計です。

1.1 ティックごとに実行すべき処理

毎ティック実行が向いている処理は、価格更新に強く依存するものです。

• 現在価格の取得
• スプレッド確認
• 保有ポジションの急変監視
• 決済条件の一部確認
• トレーリングストップの更新

ただし、すべてのEAで毎ティック決済管理が必要になるわけではありません。ロジックが確定足ベースで動く場合は、決済判定も足更新時に限定できる場合があります。

1.2 毎ティック実行を避けたい処理

重い処理や、足が確定するまで結果が変わりにくい処理は、毎ティックで実行する必要がない場合があります。

• 複数インジケータのCopyBuffer取得
• 長い期間の配列計算
• 複数銘柄の一括走査
• ファイル出力
• 過剰なPrint出力
• 注文送信条件の重複判定

MQL5のEAでは、OnTickの呼び出し頻度が相場状況により大きく変わります。流動性が高い時間帯では、同じ処理が短時間に何度も実行されるため、処理分離が重要になります。

2. 基本的な考え方

【結論】
ティック処理最適化では、処理を「毎ティック」「新しい足」「一定間隔」「注文直前」に分けます。
この分離により、EAの負荷を抑えながら、売買判断の再現性を確認しやすくなります。

MQL5のEAは、OnInit、OnTick、OnDeinitを中心に構成します。インジケータハンドルはOnInitで作成し、終了時にOnDeinitで解放します。OnTickでは、価格更新時に必要な判定だけを実行します。

ティック処理最適化の基本順序は、次のように整理できます。

ティック受信
↓
スプレッド・取引条件の確認
↓
新しい足かどうかの判定
↓
必要な場合だけインジケータ値を取得
↓
フィルター判定
↓
シグナル判定
↓
リスク確認
↓
注文前チェック
↓
注文送信または見送り

2.1 確定足ベースにする理由

確定足ベースの判定は、シグナルの再現性を確認しやすい方法です。形成中の足は価格更新のたびに値が変わるため、バックテストと実運用で判定タイミングがずれやすくなります。

移動平均線やATRなどを使う場合、最新足ではなく1本前の確定足を使うと、条件の変化を追跡しやすくなります。ただし、短期売買では反応が遅れる場合があります。

2.2 処理回数を減らすだけでは不十分

処理回数を減らすだけでは、EAの品質は上がりません。重要なのは、売買判断に必要な情報を失わずに、不要な処理だけを減らすことです。

例えば、エントリー判定は新しい足だけで十分でも、急なスプレッド拡大や既存ポジションの管理は毎ティック確認したほうがよい場合があります。

3. 代表的な設計パターン

【結論】
ティック処理最適化の代表パターンは、新足判定、処理間隔制御、インジケータ取得の遅延、注文重複防止です。
EAの目的により、複数のパターンを組み合わせます。

ティック処理を整理するときは、売買ロジックと実行制御を分けて考えます。売買ロジックは「条件が成立したか」を判定し、実行制御は「今その判定を実行すべきか」を決めます。

3.1 新しい足だけでシグナル判定する

新足判定は、確定足ベースのEAで最も使いやすい方法です。前回確認した足の時刻を保存し、現在の足時刻が変わったときだけシグナル判定を実行します。

この方式では、同じ足の中で何度もエントリー条件を満たす問題を避けやすくなります。

3.2 一定秒数ごとに処理する

一定間隔制御は、毎ティック処理が不要な監視処理に向いています。TimeCurrentを使って前回処理時刻との差を確認し、指定秒数を超えた場合だけ処理します。

この方式は、複数銘柄監視やログ出力の制御に使いやすいです。ただし、秒数ベースの制御はティックが来ない時間帯には実行されません。厳密な時間処理が必要な場合はOnTimerの利用も検討します。

3.3 インジケータ値の取得回数を制限する

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

インジケータハンドルはOnInitで一度作成し、OnTickで毎回作り直さないようにします。毎ティックでハンドルを作ると、処理が重くなり、管理も複雑になります。

3.4 注文の重複送信を防ぐ

OnTickは短時間に何度も呼ばれるため、条件が成立した状態でOrderSendを繰り返す危険があります。

注文前には、既存ポジション、未決注文、取引可能時間、スプレッド、ロット制限、証拠金を確認します。さらにOrderCheckで注文内容を事前確認すると、実行前の問題を検出しやすくなります。

4. 実装方法

【結論】
MQL5でティック処理を最適化する実装では、OnInitで準備し、OnTickで軽い制御を行い、新しい足のときだけ重い判定を実行します。
インジケータ値はCopyBufferの取得件数を確認してから使います。

実装では、次の役割を分けます。

• OnInit：インジケータハンドル作成、初期値設定
• OnTick：ティック受信時の処理制御
• IsNewBar：新しい足の判定
• UpdateIndicatorValues：必要なインジケータ値の取得
• CheckSignal：売買シグナル判定
• CheckTradePermission：注文前の条件確認
• OnDeinit：インジケータハンドル解放

4.1 新足判定の基本

新しい足を判定するには、現在足の開始時刻を取得し、前回保存した時刻と比較します。

bool IsNewBar()
{
   static datetime last_bar_time = 0;
   datetime current_bar_time = iTime(_Symbol, _Period, 0);

   if(current_bar_time == 0)
   {
      return false;
   }

   if(current_bar_time != last_bar_time)
   {
      last_bar_time = current_bar_time;
      return true;
   }

   return false;
}

この関数は、足が切り替わった最初のティックだけtrueを返します。確定足ベースのシグナル判定では、このタイミングで1本前の足のインジケータ値を使います。

4.2 スプレッド確認を先に行う

スプレッドが広い状態では、同じシグナルでも取引結果が悪化する場合があります。エントリー判定の前にスプレッドを確認すると、条件外の注文を避けやすくなります。

bool IsSpreadAcceptable(const int max_spread_points)
{
   long spread = 0;

   if(!SymbolInfoInteger(_Symbol, SYMBOL_SPREAD, spread))
   {
      Print("Failed to get spread");
      return false;
   }

   return (spread <= max_spread_points);
}

スプレッドの許容値は銘柄、時間足、売買ロジックにより変わります。固定値を使う場合でも、バックテストとフォワードテストで挙動を確認する必要があります。

5. サンプルコード

【結論】
以下のコードは、移動平均線を使った確定足ベースの判定例です。
OnTickでは新しい足のときだけCopyBufferを実行し、注文前にスプレッドとOrderCheckを確認します。

このサンプルは検証用の最小構成です。実運用では、銘柄仕様、口座タイプ、既存ポジション、取引時間、ロット制限、ストップレベル、フリーズレベルを追加で確認します。

#property strict

input int FastMAPeriod = 20;
input int SlowMAPeriod = 50;
input int MaxSpreadPoints = 30;
input double FixedLot = 0.10;

int fast_ma_handle = INVALID_HANDLE;
int slow_ma_handle = INVALID_HANDLE;

int OnInit()
{
   fast_ma_handle = iMA(_Symbol, _Period, FastMAPeriod, 0, MODE_SMA, PRICE_CLOSE);
   slow_ma_handle = iMA(_Symbol, _Period, SlowMAPeriod, 0, MODE_SMA, PRICE_CLOSE);

   if(fast_ma_handle == INVALID_HANDLE || slow_ma_handle == INVALID_HANDLE)
   {
      Print("Failed to create moving average handle");
      return INIT_FAILED;
   }

   return INIT_SUCCEEDED;
}

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

   if(slow_ma_handle != INVALID_HANDLE)
   {
      IndicatorRelease(slow_ma_handle);
   }
}

void OnTick()
{
   ManageOpenPosition();

   if(!IsSpreadAcceptable(MaxSpreadPoints))
   {
      return;
   }

   if(!IsNewBar())
   {
      return;
   }

   if(BarsCalculated(fast_ma_handle) < SlowMAPeriod ||
      BarsCalculated(slow_ma_handle) < SlowMAPeriod)
   {
      Print("Indicator bars are not ready");
      return;
   }

   double fast_ma[];
   double slow_ma[];
   ArraySetAsSeries(fast_ma, true);
   ArraySetAsSeries(slow_ma, true);

   int fast_copied = CopyBuffer(fast_ma_handle, 0, 0, 3, fast_ma);
   int slow_copied = CopyBuffer(slow_ma_handle, 0, 0, 3, slow_ma);

   if(fast_copied < 3 || slow_copied < 3)
   {
      Print("CopyBuffer failed or not enough data");
      return;
   }

   const int closed_bar = 1;
   const int previous_closed_bar = 2;

   bool buy_signal = (fast_ma[previous_closed_bar] <= slow_ma[previous_closed_bar] &&
                      fast_ma[closed_bar] > slow_ma[closed_bar]);
   bool sell_signal = (fast_ma[previous_closed_bar] >= slow_ma[previous_closed_bar] &&
                       fast_ma[closed_bar] < slow_ma[closed_bar]);

   if(HasOpenPosition())
   {
      return;
   }

   if(buy_signal)
   {
      SendMarketOrder(ORDER_TYPE_BUY);
   }
   else if(sell_signal)
   {
      SendMarketOrder(ORDER_TYPE_SELL);
   }
}

bool IsNewBar()
{
   static datetime last_bar_time = 0;
   datetime current_bar_time = iTime(_Symbol, _Period, 0);

   if(current_bar_time == 0)
   {
      return false;
   }

   if(current_bar_time != last_bar_time)
   {
      last_bar_time = current_bar_time;
      return true;
   }

   return false;
}

bool IsSpreadAcceptable(const int max_spread_points)
{
   long spread = 0;

   if(!SymbolInfoInteger(_Symbol, SYMBOL_SPREAD, spread))
   {
      Print("Failed to get spread");
      return false;
   }

   return (spread <= max_spread_points);
}

bool HasOpenPosition()
{
   return PositionSelect(_Symbol);
}

void ManageOpenPosition()
{
   if(!PositionSelect(_Symbol))
   {
      return;
   }

   // This sample keeps position management minimal.
   // Stop loss, take profit, and trailing logic should be designed separately.
}

bool NormalizeLot(double &lot)
{
   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(min_lot <= 0.0 || max_lot <= 0.0 || lot_step <= 0.0)
   {
      Print("Invalid volume settings");
      return false;
   }

   lot = MathMax(min_lot, MathMin(max_lot, lot));
   lot = MathFloor(lot / lot_step) * lot_step;
   lot = NormalizeDouble(lot, 2);

   return (lot >= min_lot && lot <= max_lot);
}

bool SendMarketOrder(const ENUM_ORDER_TYPE order_type)
{
   double lot = FixedLot;

   if(!NormalizeLot(lot))
   {
      return false;
   }

   double price = 0.0;

   if(order_type == ORDER_TYPE_BUY)
   {
      price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
   }
   else if(order_type == ORDER_TYPE_SELL)
   {
      price = SymbolInfoDouble(_Symbol, SYMBOL_BID);
   }
   else
   {
      return false;
   }

   if(price <= 0.0)
   {
      Print("Invalid order price");
      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;
   request.price = price;
   request.deviation = 20;
   request.type_filling = ORDER_FILLING_FOK;

   if(!OrderCheck(request, check))
   {
      Print("OrderCheck failed: ", GetLastError());
      return false;
   }

   if(check.retcode != TRADE_RETCODE_DONE)
   {
      Print("OrderCheck retcode: ", check.retcode);
      return false;
   }

   if(!OrderSend(request, result))
   {
      Print("OrderSend failed: ", GetLastError());
      return false;
   }

   if(result.retcode != TRADE_RETCODE_DONE)
   {
      Print("OrderSend retcode: ", result.retcode);
      return false;
   }

   return true;
}

5.1 コードの要点

このコードでは、インジケータハンドルをOnInitで作成し、OnTickでは足が切り替わった場合だけCopyBufferを呼び出します。

CopyBufferでは3本分の値を取得しています。配列を時系列として扱うため、インデックス0は形成中の足、インデックス1は直近の確定足、インデックス2はその1本前の確定足です。

5.2 注文処理の注意点

注文処理では、MqlTradeRequest、MqlTradeResult、MqlTradeCheckResultを使います。OrderSendの前にOrderCheckを実行することで、証拠金不足や注文条件の不備を検出しやすくなります。

サンプルでは固定ロットを使っていますが、実運用では残高、有効証拠金、損切り幅、ティックバリュー、ティックサイズ、最小ロット、最大ロット、ロットステップを考慮したロット計算が必要です。

6. パターン別比較

【結論】
ティック処理最適化では、EAの目的に合わせて処理制御パターンを選びます。
確定足型、毎ティック型、時間間隔型には、それぞれメリットと弱点があります。

処理パターンは一つに固定する必要はありません。例えば、スプレッド確認は毎ティック、シグナル判定は新足、集計ログは一定間隔というように分けると、EAの構造を整理しやすくなります。

7. 誤作動しやすい場面

【結論】
ティック処理最適化で誤作動しやすい場面は、重複注文、形成中の足の利用、CopyBuffer取得不足、口座タイプ差の見落としです。
処理を軽くするほど、必要な確認まで省略しないように注意します。

7.1 同じ足で複数回注文する

OnTickは同じ足の中で何度も呼ばれます。注文済みかどうかを確認しない場合、同じシグナルで複数回注文する可能性があります。

netting口座では同一銘柄のポジションが統合される構造になり、hedging口座では複数ポジションを持てる構造になります。ポジション確認の実装は、口座タイプに合わせて設計する必要があります。

7.2 最新足の値でシグナルが変わる

インジケータ配列でインデックス0を使うと、形成中の足の値を使うことになります。形成中の足はティックごとに変わるため、シグナルが出たり消えたりする場合があります。

確定足ベースのEAでは、インデックス1以降を使う設計が一般的です。

7.3 CopyBufferの戻り値を確認しない

CopyBufferの取得件数が期待値未満でも処理を続けると、未設定値や古い値で判定する危険があります。

CopyBufferを使う場合は、戻り値が必要本数以上であることを確認します。必要に応じてBarsCalculatedも確認します。

7.4 ログ出力が多すぎる

Printを毎ティックで大量に出力すると、テスターや実行環境の負荷が増えます。ログは異常時、状態変化時、一定間隔に絞ると確認しやすくなります。

8. バックテストで確認すべき項目

【結論】
バックテストでは、処理速度だけでなく、取引回数、最大ドローダウン、スプレッド条件、パラメータ依存性を確認します。
ティック処理を変えると、エントリー回数や判定タイミングが変わる場合があります。

バックテストで確認する項目は次のとおりです。

• 総損益
• 最大ドローダウン
• 勝率
• 損益比
• 取引回数
• 連敗数
• スプレッド条件
• 期間依存性
• パラメータ依存性
• シグナル発生回数
• 注文失敗回数
• テスター上の処理時間

8.1 取引回数の変化を見る

ティック処理を新足判定に変更すると、同じロジックでも取引回数が減る場合があります。取引回数が減った理由が、重複注文の防止なのか、必要なシグナルの取り逃しなのかを分けて確認します。

8.2 スプレッド条件を変えて確認する

スプレッド条件に強く依存するEAは、実運用で成績が変動しやすくなります。固定スプレッドだけでなく、広めのスプレッド条件でも挙動を確認します。

8.3 パラメータ依存性を確認する

特定の移動平均期間、スプレッド上限、処理間隔だけで結果が極端によい場合、過剰最適化の可能性があります。周辺パラメータでも大きく崩れないかを確認します。

バックテスト結果は将来の利益を保証しません。バックテストは、ロジックの再現性と弱点を確認するための検証工程です。

9. フォワードテストで確認すべき項目

【結論】
フォワードテストでは、バックテストと実行環境の差を確認します。
特に約定差、スプレッド拡大、VPS環境、ブローカー仕様の違いを確認します。

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

• 約定差
• スプレッド拡大時の挙動
• 取引頻度
• ドローダウン
• バックテストとの乖離
• ブローカー差
• VPS環境での安定性
• 注文失敗ログ
• CopyBuffer取得失敗の有無
• 処理遅延の有無

9.1 ティック頻度の違いを確認する

バックテストとリアルタイム環境では、ティックの発生頻度やスプレッド条件が異なる場合があります。毎ティック処理を前提にしたEAでは、この差が売買判断に影響します。

9.2 VPS環境での安定性を確認する

VPSでEAを動かす場合、ネットワーク遅延、端末の負荷、稼働時間、ログ増加を確認します。軽い処理に見えるEAでも、複数銘柄や複数時間足を扱うと負荷が増える場合があります。

9.3 注文失敗ログを確認する

OrderCheckやOrderSendの戻り値をログに残すと、注文が見送られた原因を確認しやすくなります。スプレッド、証拠金、約定方式、取引時間、ロット制限などの条件が原因になる場合があります。

10. 実運用での注意点

【結論】
実運用では、ティック処理を軽くしても、スプレッド、約定遅延、スリッページ、ブローカー仕様により結果が変わります。
EAは検証済みの条件から外れると、想定と異なる挙動になる場合があります。

ティック処理最適化は、EAの実行品質を整えるための設計です。利益や損失の結果は、ロジック、相場環境、取引条件、リスク管理により変わります。

10.1 スプレッド拡大への対応

重要指標発表時や流動性が低い時間帯では、スプレッドが広がる場合があります。スプレッドが広い状態でエントリーすると、損益比が悪化しやすくなります。

10.2 約定条件の差

デモ口座とリアル口座では、約定条件が異なる場合があります。注文が通る速度、スリッページ、約定方式、拒否される条件をフォワードテストで確認します。

10.3 レバレッジとドローダウン

レバレッジが高いほど、同じ値動きでも口座への影響が大きくなりやすいです。ドローダウン許容度を決め、ロット計算と停止条件を設計する必要があります。

10.4 注文前チェックを省略しない

処理を軽くする目的でOrderCheckやロット制限確認を省略すると、注文失敗の原因を見落としやすくなります。最小ロット、最大ロット、ロットステップ、証拠金、ストップレベル、フリーズレベルは銘柄ごとに確認します。

11. 改善案と代替手段

【結論】
ティック処理最適化を改善するには、処理頻度の分離、状態管理、ログ制御、ロット計算の独立化を進めます。
売買ロジックと実行制御を分けるほど、検証と修正がしやすくなります。

11.1 状態管理を導入する

EAの状態を明示すると、重複注文や不要な処理を避けやすくなります。

待機中
↓
シグナル確認中
↓
注文前チェック中
↓
注文送信済み
↓
ポジション管理中
↓
停止条件確認

状態管理を使うと、OnTickが何度呼ばれても、現在の状態に応じた処理だけを実行できます。

11.2 ロット計算を分離する

ロット計算は、シグナル判定とは別の機能として扱います。固定ロット、残高比例、リスク率ベース、ボラティリティ調整では、必要な入力値が異なります。

11.3 OnTimerを使う

OnTimerは、一定間隔で処理したい場合に使えます。OnTickが来ない時間帯でも時間イベントを使えるため、監視や集計に向いています。

ただし、OnTickとOnTimerで同じ状態を更新する場合は、処理の競合を避ける設計が必要です。

12. まとめ

【結論】
MQL5のtick processing optimizationでは、OnTickの処理を軽くするだけでなく、売買判断のタイミングを明確にすることが重要です。
新足判定、CopyBufferの取得制御、注文前チェック、状態管理を組み合わせると、EAの検証と運用監視がしやすくなります。

MQL5のEAでは、インジケータハンドルをOnInitで作成し、必要なタイミングでCopyBufferを使って値を取得します。毎ティックで重い処理を実行するのではなく、処理頻度に応じて役割を分けると、EAの構造が明確になります。

実運用では、バックテストと同じ条件で動くとは限りません。スプレッド、約定遅延、スリッページ、口座タイプ、ブローカー仕様、VPS環境により結果は変わります。実運用前には、バックテストとフォワードテストの両方で再現性を確認する必要があります。

FAQ

Q1. MQL5のtick processing optimizationとは何ですか？

MQL5のtick processing optimizationとは、EAのOnTickで実行する処理を整理し、必要なタイミングだけ重い判定を行う設計です。新足判定、CopyBufferの取得制御、注文重複防止などを組み合わせます。

Q2. OnTickでは毎回すべての処理を実行すべきですか？

OnTickで毎回すべての処理を実行する必要はありません。価格監視やポジション管理は毎ティック、シグナル判定は新しい足だけ、ログ出力は一定間隔というように分けると管理しやすくなります。

Q3. CopyBufferは毎ティック実行してもよいですか？

CopyBufferは毎ティック実行できますが、確定足ベースのEAでは新しい足のときだけ取得すれば十分な場合があります。取得後は戻り値を確認し、必要本数に満たない場合は判定を中止します。

Q4. 新足判定を使うメリットは何ですか？

新足判定を使うと、同じ足でシグナル判定を何度も行う問題を避けやすくなります。確定足を使う設計では、バックテストとフォワードテストの比較もしやすくなります。

Q5. ティック処理を軽くするとEAの成績は改善しますか？

ティック処理を軽くしても、EAの成績が改善するとは限りません。処理最適化は実行品質を整える設計であり、売買結果はロジック、相場環境、スプレッド、約定条件、リスク管理により変わります。

Q6. バックテストでは何を確認すべきですか？

バックテストでは、総損益、最大ドローダウン、勝率、損益比、取引回数、スプレッド条件、パラメータ依存性を確認します。ティック処理を変更した場合は、取引回数と判定タイミングの変化も確認します。

Q7. フォワードテストでは何を確認すべきですか？

フォワードテストでは、約定差、スプレッド拡大時の挙動、取引頻度、ドローダウン、バックテストとの乖離、ブローカー差、VPS環境での安定性を確認します。

Q8. 注文前にOrderCheckは必要ですか？

注文処理を含むEAでは、OrderSendの前にOrderCheckを使うと注文条件の不備を検出しやすくなります。証拠金、ロット、約定方式、銘柄仕様などに問題がある場合、注文送信前に原因を把握しやすくなります。