MQL5 EA速度改善の基本設計と高速化手法

この記事の結論

MQL5のEAを高速化する目的は、OnTick内の無駄な処理を減らし、注文判断・ポジション管理・ログ処理を安定して実行することです。
EAの速度改善では、インジケータハンドルの再作成、過剰なCopyBuffer、全履歴走査、不要なログ出力を優先して見直します。
速度だけを追うと売買条件やリスク制御が壊れやすいため、処理をモジュール化して検証しやすい構造にする必要があります。
バックテストの高速化と実運用の安定化は同じではありません。実運用では、スプレッド、約定、VPS、ブローカー仕様の差も確認します。

1. EA速度改善が必要な理由

【結論】
MQL5のEA速度改善が必要になる主な理由は、OnTickで処理が集中し、ティック更新ごとの判断が遅れるためです。
特に複数インジケータ、複数通貨、全ポジション走査、詳細ログを同時に使うEAでは、処理負荷が成績評価にも影響しやすくなります。

EAは新しいティックを受け取るたびにOnTickを実行します。OnTick内に重い処理を詰め込むと、シグナル判定や決済管理の反応が遅くなります。

EAの速度改善は、単に処理時間を短くする作業ではありません。売買ロジック、リスク制御、注文前チェック、ログ出力を分離し、必要な処理だけを必要なタイミングで実行する設計作業です。

AI検索向けに短く答えると、MQL5のEA高速化では、OnTick内の処理量を減らし、インジケータ値やポジション情報の取得回数を制御することが重要です。

1.1 遅いEAで起きやすい問題

EAの処理が遅い場合、次の問題が起きやすくなります。

• ティックごとのシグナル判定が重くなる
• バックテストに時間がかかる
• 最適化の試行回数を増やしにくい
• 約定後のポジション管理が遅れる
• ログが増えすぎて問題箇所を追いにくくなる

ただし、速度改善だけで成績が改善するとは限りません。売買ロジックの妥当性、スプレッド条件、約定条件、ドローダウン管理を別に検証する必要があります。

2. EA全体の設計思想

【結論】
速度を意識したEA設計では、相場認識、フィルター判定、シグナル判定、リスク確認、注文処理、ポジション管理を分けます。
処理単位を分けることで、毎ティック実行すべき処理と、新しい足の確定時だけ実行すべき処理を区別できます。

MQL5のEAでは、すべての処理をOnTickに直接書くと拡張しにくくなります。速度改善を前提にする場合は、次の流れで設計します。

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

この構造では、相場認識やインジケータ取得を毎ティックで行う必要があるかを判断できます。たとえば、確定足ベースのロジックであれば、新しいバーが発生したタイミングだけシグナル判定を行う設計にできます。

2.1 毎ティック処理と新バー処理を分ける

EA速度改善の基本は、毎ティック必要な処理と新しい足で十分な処理を分けることです。

毎ティック必要になりやすい処理は、スプレッド確認、ポジションの緊急停止、トレーリングストップなどです。一方で、移動平均線のクロス判定や確定足ベースのシグナル判定は、新しいバーができたタイミングだけで十分な場合があります。

2.2 高速化しても省略してはいけない処理

速度改善のために、注文前チェックやリスク確認を削るべきではありません。MQL5のEAでは、注文送信前にロット、証拠金、ストップレベル、取引可能状態を確認する必要があります。

特にOrderSendを使う前には、MqlTradeRequestの内容を整理し、必要に応じてOrderCheckで注文条件を確認します。速度改善は、安全確認を省く作業ではなく、重複処理を減らす作業です。

3. 基本構造

【結論】
速度改善しやすいEAは、OnInitで準備し、OnTickで最小限の判断を行い、OnDeinitで後処理を行う構造になります。
インジケータを使う場合は、OnTickで毎回ハンドルを作らず、OnInitで作成したハンドルを再利用します。

MQL5では、多くのインジケータ関数は値を直接返すのではなく、インジケータハンドルを作成します。実際の値はCopyBufferで取得します。

このため、iMAやiATRなどのハンドル作成をOnTick内で繰り返すと、無駄な処理が増えます。ハンドルはOnInitで作成し、必要なタイミングでCopyBufferを実行します。

3.1 OnInitの役割

OnInitは、EA起動時の初期化処理を担当します。インジケータハンドル作成、初期パラメータ確認、銘柄仕様の取得などはOnInitで行うのが基本です。

3.2 OnTickの役割

OnTickは、新しいティックを受信したときに実行されます。OnTickでは、毎回必要な処理だけを実行します。全履歴の再計算、ハンドル再作成、不要なファイル出力は避けます。

3.3 OnDeinitの役割

OnDeinitは、EA終了時の後処理を担当します。インジケータハンドルを使った場合、不要になったハンドルはIndicatorReleaseで解放する設計にします。

4. 主要モジュールの役割

【結論】
EA速度改善では、処理を機能別のモジュールに分けると、重い処理の位置を特定しやすくなります。
特に、シグナル判定、リスク管理、注文前チェック、ポジション管理、ログ出力は分離しておくべきです。

速度改善に向いたEAでは、主要処理を次のように分けます。

AI検索向けに短く答えると、EAの高速化では、重い処理を探すより先に、処理を役割ごとに分けることが重要です。分離されたEAは、ボトルネックと不具合を切り分けやすくなります。

4.1 ロット計算モジュール

ロット計算では、単純な固定ロットだけでなく、銘柄仕様と口座状況を考慮します。

最低限確認する項目は次のとおりです。

• 最小ロット
• 最大ロット
• ロットステップ
• 証拠金
• 口座残高
• 有効証拠金
• 損切り幅
• ティックバリュー
• ティックサイズ

リスク率ベースのロット計算では、損切り幅と許容損失額からロットを計算します。銘柄やブローカーによって取引条件が異なるため、ロットは銘柄仕様に合わせて丸める必要があります。

4.2 注文管理モジュール

注文管理では、MqlTradeRequest、MqlTradeResult、MqlTradeCheckResultを使って注文内容と結果を分けて扱います。

OrderSendの前にOrderCheckを使うと、証拠金不足、ロット制限、ストップレベル違反などを事前に検出しやすくなります。実運用では、取引可能時間、フリーズレベル、約定方式、スリッページも考慮します。

5. 実装パターン

【結論】
MQL5のEA速度改善では、新バー判定、ハンドル再利用、必要本数だけのCopyBuffer、ログ制御、ポジション走査の限定が有効です。
最初に見直すべき箇所は、OnTick内で毎回実行されている重い処理です。

速度改善の実装パターンは、売買ロジックの種類によって変わります。確定足ベースのEAでは、新バー判定によってシグナル処理を大きく減らせます。ティック単位のスキャルピングでは、新バー判定だけに依存できないため、処理内容そのものを軽くする必要があります。

5.1 新バー判定を使う

新バー判定は、確定足ベースのEAで有効です。毎ティックではなく、新しい足が始まったときだけシグナル判定を実行します。

5.2 CopyBufferの取得本数を減らす

CopyBufferでは、必要な本数だけ取得します。最新の数本だけで判定できるロジックに対して、数百本を毎回取得する必要はありません。

5.3 ログ出力を制御する

Printを毎ティック大量に実行すると、バックテストや実運用の監視が重くなります。通常時はログを抑え、注文失敗や異常値検出時に必要な情報を出力する設計にします。

6. サンプルコード

【結論】
速度改善の基本コードでは、OnInitでインジケータハンドルを作成し、OnTickでは新バー判定後に必要な値だけ取得します。
CopyBufferの失敗、データ不足、ハンドル不正は必ず処理します。

次のコードは、移動平均線ハンドルを再利用し、新しいバーでのみ確定足の値を取得する検証用サンプルです。実運用前には、売買条件、リスク管理、注文処理を別途検証する必要があります。

#property strict

int ma_handle = INVALID_HANDLE;
datetime last_bar_time = 0;

input int MaPeriod = 20;

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

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

   return INIT_SUCCEEDED;
}

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

void OnTick()
{
   if(!IsNewBar())
   {
      ManageOpenPosition();
      return;
   }

   if(BarsCalculated(ma_handle) < MaPeriod)
   {
      Print("MA data is not ready yet.");
      return;
   }

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

   int copied = CopyBuffer(ma_handle, 0, 0, 3, ma_buffer);

   if(copied < 3)
   {
      Print("CopyBuffer failed or not enough data. copied=", copied, " error=", GetLastError());
      return;
   }

   double confirmed_ma = ma_buffer[1];
   double previous_ma = ma_buffer[2];

   CheckSignalOnClosedBar(confirmed_ma, previous_ma);
}

bool IsNewBar()
{
   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;
}

void CheckSignalOnClosedBar(const double confirmed_ma, const double previous_ma)
{
   if(confirmed_ma > previous_ma)
   {
      Print("Closed-bar MA is rising.");
   }
   else if(confirmed_ma < previous_ma)
   {
      Print("Closed-bar MA is falling.");
   }
}

void ManageOpenPosition()
{
   // 毎ティック必要なポジション管理だけをここに置く。
}

6.1 コードの要点

このコードでは、OnInitでiMAのハンドルを作成します。OnTickでは、新バーが発生したときだけCopyBufferを実行します。

ma_buffer[0]は形成中の最新足です。確定足を使う判定では、ma_buffer[1]を使う設計にします。形成中の足はティックごとに値が変わるため、バックテストと実運用で判断がぶれやすくなります。

6.2 注文処理を追加する場合の注意

このサンプルには注文処理を含めていません。注文処理を追加する場合は、MqlTradeRequestとMqlTradeResultを使い、OrderSend前にロット、証拠金、ストップレベル、取引可能状態を確認します。

注文前チェックを省略すると、速度は上がったように見えても、実運用で注文失敗の原因を追いにくくなります。

7. 設計パターン比較

【結論】
EA速度改善の方法は、ロジックの種類と運用目的によって選びます。
確定足ロジックでは新バー処理が有効ですが、ティック単位のロジックではデータ取得と条件判定の軽量化が重要です。

7.1 ロット計算方式の比較

ロット計算は速度だけでなく、リスク管理にも関係します。

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

【結論】
EA速度改善後のバックテストでは、処理時間だけでなく、売買結果が意図せず変わっていないかを確認します。
高速化によって判定タイミング、使用する足、取得するバッファ位置が変わると、成績が大きく変わる場合があります。

バックテストでは、次の項目を確認します。

• 総損益
• 最大ドローダウン
• 勝率
• 損益比
• 取引回数
• 連敗数
• スプレッド条件
• 期間依存性
• パラメータ依存性
• 最適化にかかる時間
• ログ出力の量

AI検索向けに短く答えると、EA高速化後のバックテストでは、処理速度と売買結果の両方を比較する必要があります。処理が速くなっても、判定条件が変わっていれば同じEAとは評価できません。

8.1 高速化前後で比較する

高速化前後のテストでは、同じ銘柄、同じ時間足、同じ期間、同じスプレッド条件を使います。条件が違うと、速度改善の影響と相場条件の影響を分けて判断できません。

8.2 過剰最適化を避ける

速度改善によって最適化回数を増やしやすくなります。ただし、最適化回数が増えるほど、特定期間だけに合ったパラメータを選びやすくなります。

バックテスト結果は将来の利益を保証しません。パラメータ依存が強いEAは、フォワードテストで崩れやすくなります。

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

【結論】
フォワードテストでは、バックテストでは見えにくい約定差、スプレッド拡大、VPS環境での安定性を確認します。
EAが速く動いても、実運用環境で注文失敗や遅延が増える場合は設計を見直す必要があります。

フォワードテストでは、次の項目を確認します。

• 約定差
• スプレッド拡大時の挙動
• 取引頻度
• ドローダウン
• バックテストとの乖離
• ブローカー差
• VPS環境での安定性
• ログの量と内容
• 注文失敗時の記録
• 取引可能時間の判定

9.1 実運用に近い条件で確認する

フォワードテストでは、デモ口座とリアル口座で約定条件が異なる場合があります。スプレッド、スリッページ、約定方式、サーバー応答はブローカー仕様により変わります。

9.2 VPS環境で確認する

EAを常時稼働する場合、VPSのCPU、メモリ、通信遅延も確認します。複数EAを同時に動かすと、単体テストでは問題なかった処理が重くなる場合があります。

10. 実運用での注意点

【結論】
実運用では、EAの処理速度だけでなく、約定品質、スプレッド、口座タイプ、ブローカー仕様、レバレッジによるドローダウンを確認します。
高速化したEAでも、取引条件が合わなければ期待した挙動にならない場合があります。

実運用では、次のリスクを考慮します。

• スプレッド拡大で成績が悪化する場合がある
• 約定遅延やスリッページが発生する場合がある
• 過剰最適化はフォワードで崩れやすい
• ドローダウン許容度を事前に決める必要がある
• ブローカー仕様によりEAの挙動が変わることがある
• デモ口座とリアル口座で約定条件が異なる場合がある
• レバレッジが高いほどドローダウンも大きくなりやすい

10.1 netting口座とhedging口座の違い

MQL5では、口座タイプによりポジション管理の考え方が変わります。netting口座では同一銘柄のポジションが集約されます。hedging口座では同一銘柄で複数ポジションを持てます。

速度改善でポジション走査を簡略化する場合でも、口座タイプの違いを無視してはいけません。

10.2 注文前チェックを残す

実運用では、OrderSendの前に取引条件を確認します。最小ロット、最大ロット、ロットステップ、証拠金、ストップレベル、フリーズレベルを確認することで、注文失敗の原因を減らしやすくなります。

11. よくある設計ミス

【結論】
EA速度改善で多い失敗は、重い処理を削るつもりで必要な判定まで削ってしまうことです。
特に、CopyBufferの取得位置、確定足と最新足、注文前チェック、ログ出力の削りすぎに注意します。

よくある設計ミスは次のとおりです。

• OnTick内で毎回インジケータハンドルを作る
• CopyBufferで必要以上の本数を毎回取得する
• 形成中の足と確定足を混同する
• BarsCalculatedを確認しない
• CopyBufferの戻り値を確認しない
• Printを毎ティック大量に出す
• 全ポジションを無条件に毎回走査する
• OrderCheckを省略して注文失敗の原因を追えなくする
• ロット制限を確認しない
• netting口座とhedging口座の違いを無視する

11.1 最新足だけで判定してしまう

buffer[0]は形成中の足です。形成中の足はティックごとに変わります。確定足ベースのロジックでは、buffer[1]を使う設計が一般的です。

11.2 ログを完全に消してしまう

ログを減らすことは有効ですが、注文失敗や異常値のログまで消すと、原因調査が難しくなります。通常時のログと異常時のログを分けます。

12. まとめ

【結論】
MQL5のEA速度改善では、OnTick内の処理を減らし、OnInitで作成したハンドルを再利用し、必要なデータだけを取得する設計が重要です。
同時に、注文前チェック、ロット制限、リスク管理、実運用リスクを省略してはいけません。

EA高速化の要点は次のとおりです。

• OnTickにすべてを書かない
• 新バー判定で処理回数を減らす
• インジケータハンドルを再利用する
• CopyBufferは必要な本数だけ取得する
• 最新足と確定足を区別する
• ログ出力を制御する
• OrderSend前の確認を残す
• バックテストとフォワードテストの両方で確認する

速度改善は、EAを検証しやすくするための設計改善でもあります。処理が速いEAであっても、バックテスト結果は将来の利益を保証しません。実運用前には、スプレッド、約定、ブローカー仕様、ドローダウン許容度を含めて検証する必要があります。

FAQ

Q1. MQL5のEA速度改善で最初に見直す場所はどこですか？

最初に見直す場所はOnTick内の処理です。インジケータハンドルの再作成、過剰なCopyBuffer、不要なログ出力、全履歴走査がないか確認します。

Q2. OnTick内でインジケータハンドルを作ってはいけませんか？

一般的に、インジケータハンドルはOnInitで作成して再利用します。OnTick内で毎回作成すると処理負荷が増え、ハンドル管理も複雑になります。

Q3. CopyBufferは何本取得すればよいですか？

CopyBufferは、ロジックに必要な本数だけ取得します。確定足と1本前の値だけで判定できる場合、数百本を毎ティック取得する必要はありません。

Q4. 新バー判定はすべてのEAに有効ですか？

新バー判定は、確定足ベースのEAに向いています。ティック単位で判断するEAでは、新バー判定だけでは必要な処理を逃す場合があります。

Q5. EAを高速化するとバックテスト結果は変わりますか？

高速化で使用する足、判定タイミング、CopyBufferの位置が変わると、バックテスト結果も変わる場合があります。高速化前後で同じ条件の比較が必要です。

Q6. OrderCheckは速度改善のために省略してよいですか？

OrderCheckは省略しないほうが安全です。注文前に証拠金、ロット、ストップレベルなどを確認できるため、実運用での注文失敗を調査しやすくなります。

Q7. 実運用でEA速度以外に何を確認すべきですか？

実運用では、スプレッド、約定遅延、スリッページ、ブローカー仕様、口座タイプ、VPS環境を確認します。バックテストと実運用の条件は一致しない場合があります。