MQL5バックテストとフォワードテスト設計

この記事の結論

MQL5のバックテストとフォワードテストは、EAの売買ロジックを別々の角度から検証するための工程です。
バックテストは過去データでロジックの傾向を確認する作業であり、フォワードテストは未使用期間やデモ環境で再現性を確認する作業です。
バックテストで良い結果が出ても、将来の利益や実運用での成績は保証されません。
EAを設計する場合は、バックテストで仮説を絞り込み、フォワードテストでスプレッド、約定、ブローカー条件の差を確認する流れが重要です。
過剰最適化を避けるには、パラメータを増やしすぎず、期間外データで性能が大きく崩れないかを確認する必要があります。

1. このロジックの役割

【結論】
MQL5におけるバックテストとフォワードテストの役割は、EAの売買ロジックが過去データだけに依存していないかを確認することです。
バックテストは仮説検証、フォワードテストは再現性確認として分けて考えます。

バックテストとフォワードテストを混同すると、EAの評価が過去データへの適合度だけに偏りやすくなります。
MQL5のEAでは、OnTickで売買条件を判定し、必要に応じてインジケータハンドル、CopyBuffer、注文前チェック、ポジション管理を組み合わせます。
そのため、検証では売買条件だけでなく、注文処理や約定条件も含めて確認する必要があります。

【定義】
バックテストとは、過去の価格データを使ってEAの動作と成績を確認する検証です。
フォワードテストとは、最適化に使っていない期間やデモ環境で、EAの再現性を確認する検証です。

1.1 バックテストで分かること

バックテストでは、EAが過去相場に対してどのように動いたかを確認できます。
主に以下の項目を見ます。

• 総損益
• 最大ドローダウン
• 勝率
• 損益比
• 取引回数
• 連敗数
• 期間ごとの成績差
• パラメータ変更に対する感度

バックテストは、売買ロジックの方向性を確認するために有効です。
ただし、バックテストは将来の相場や実際の約定条件を完全に再現するものではありません。

1.2 フォワードテストで分かること

フォワードテストでは、EAが過去データに合わせすぎていないかを確認します。
バックテストで使っていない期間、またはデモ口座などの環境で動かすことで、より実運用に近い問題が見えやすくなります。

フォワードテストで重要なのは、利益額だけではありません。
取引回数、ドローダウン、約定差、スプレッド拡大時の挙動、VPS環境での安定性も確認します。

2. 基本的な考え方

【結論】
MQL5でEAを検証する場合は、バックテストを「作る工程」、フォワードテストを「崩れにくさを見る工程」として分けると整理しやすくなります。
バックテストだけで実運用判断を行うと、過剰最適化を見落としやすくなります。

EAの検証は、次の流れで進めます。

売買仮説の作成
↓
バックテスト
↓
パラメータ調整
↓
期間外データで確認
↓
フォワードテスト
↓
実運用リスクの確認

MQL5のEAでは、ロジックの良し悪しだけでなく、イベント処理の設計も成績に影響します。
OnInitではインジケータハンドルの作成、OnTickではシグナル判定、OnDeinitでは必要に応じたハンドル解放を行います。
この構造が不安定だと、バックテストでは動いてもフォワード環境で想定外の挙動が起きる場合があります。

2.1 バックテストは仮説の絞り込みに使う

バックテストは、売買条件がまったく機能していないロジックを早い段階で除外するために使います。
たとえば、移動平均クロス、ATRフィルター、時間帯フィルターなどを組み合わせた場合、各条件が成績にどの程度影響しているかを確認できます。

ただし、条件を増やしすぎると、過去データにだけ合ったロジックになりやすくなります。
パラメータを細かく調整するほど、フォワードテストで崩れる可能性も高くなります。

2.2 フォワードテストは再現性を確認する

フォワードテストは、EAの動作が検証外の環境でも大きく崩れないかを確認する工程です。
特に、スプレッド、約定遅延、スリッページ、取引時間、ブローカー仕様の差が影響します。

バックテストとフォワードテストの成績が完全に一致する必要はありません。
重要なのは、取引傾向、リスク量、ドローダウン、ロジックの動作理由が説明できる範囲に収まっているかです。

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

【結論】
MQL5のEA検証では、単一のバックテスト結果だけで判断せず、期間分割、パラメータ安定性、フォワード確認を組み合わせます。
この組み合わせにより、過去データへの依存を見つけやすくなります。

代表的な設計パターンは、次の3つです。

3.1 単純バックテスト型

単純バックテスト型は、ひとつの期間でEAを動かして成績を確認する方法です。
初心者がEAの動作確認を始める段階では扱いやすい方法です。

一方で、特定の期間だけに合った結果を見抜きにくい欠点があります。
この方法だけで実運用判断を行うことは避けるべきです。

3.2 期間分割型

期間分割型は、過去データを調整用期間と確認用期間に分ける方法です。
調整用期間でパラメータを選び、確認用期間で成績が大きく崩れないかを見ます。

この方法は、過剰最適化の発見に役立ちます。
ただし、確認用期間も過去データであるため、実際の約定条件までは確認できません。

3.3 フォワード運用確認型

フォワード運用確認型は、バックテスト後にデモ環境や小さな検証環境でEAを動かす方法です。
実際のティック更新、スプレッド、約定、サーバー時間、VPS環境の影響を確認できます。

実運用に近い問題は、フォワードテストで初めて見えることがあります。
たとえば、スプレッド拡大時にエントリーが増える、約定遅延で損切り位置がずれる、取引時間外に注文が拒否される、といった問題です。

4. 実装方法

【結論】
MQL5で検証しやすいEAを作るには、シグナル判定、フィルター判定、注文前チェック、ログ出力を分けて実装します。
検証用のログを残すことで、バックテストとフォワードテストの違いを追跡しやすくなります。

EAの基本構造は、次のように分けます。

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

MQL5では、インジケータ関数の多くが値を直接返すのではなく、ハンドルを作成してからCopyBufferで値を取得します。
このため、OnInitでハンドルを作成し、OnTickで値を取得し、OnDeinitで必要に応じてIndicatorReleaseを行う設計が基本になります。

4.1 検証しやすいEA構造

検証しやすいEAでは、次の処理を分けます。

• シグナル判定
• フィルター判定
• ロット計算
• 既存ポジション確認
• 注文前チェック
• 注文送信
• エラーハンドリング
• ログ出力

シグナル判定と注文処理をひとつの長いOnTickに詰め込むと、検証結果の原因を追いにくくなります。
バックテストとフォワードテストを比較する記事テーマでは、処理を分離することが特に重要です。

4.2 ログで比較できる項目を残す

フォワードテストでは、売買結果だけでなく、EAがなぜ取引したかを確認できるログが必要です。
たとえば、次の情報を残します。

• エントリー時刻
• 売買方向
• インジケータ値
• スプレッド
• ロット
• 損切り幅
• 注文前チェックの結果
• OrderSendの結果

ログが不足していると、バックテストとフォワードテストの差がロジック由来なのか、約定条件由来なのか判断しにくくなります。

5. サンプルコード

【結論】
バックテストとフォワードテストを比較するEAでは、売買シグナルだけでなく、スプレッド確認、CopyBufferの取得判定、OrderCheck、OrderSend結果の記録が重要です。
次のコードは、検証用の構造を示すサンプルです。

以下のコードは、移動平均線を使った簡易的な検証用サンプルです。
実運用を前提とした完成EAではありません。
ロット、損切り、取引時間、銘柄条件は、検証目的に応じて調整する必要があります。

#property strict

input int FastMAPeriod = 20;
input int SlowMAPeriod = 50;
input double Lots = 0.10;
input int StopLossPoints = 300;
input int TakeProfitPoints = 600;
input int MaxSpreadPoints = 30;

int fastHandle = INVALID_HANDLE;
int slowHandle = INVALID_HANDLE;

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

   if(fastHandle == INVALID_HANDLE || slowHandle == INVALID_HANDLE)
   {
      Print("Failed to create indicator handle");
      return INIT_FAILED;
   }

   return INIT_SUCCEEDED;
}

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

   if(slowHandle != INVALID_HANDLE)
      IndicatorRelease(slowHandle);
}

void OnTick()
{
   if(!IsSpreadAcceptable())
      return;

   if(PositionSelect(_Symbol))
      return;

   double fastMA[];
   double slowMA[];

   ArraySetAsSeries(fastMA, true);
   ArraySetAsSeries(slowMA, true);

   int fastCopied = CopyBuffer(fastHandle, 0, 0, 3, fastMA);
   int slowCopied = CopyBuffer(slowHandle, 0, 0, 3, slowMA);

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

   bool buySignal = (fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2]);
   bool sellSignal = (fastMA[1] < slowMA[1] && fastMA[2] >= slowMA[2]);

   if(buySignal)
      SendMarketOrder(ORDER_TYPE_BUY);

   if(sellSignal)
      SendMarketOrder(ORDER_TYPE_SELL);
}

bool IsSpreadAcceptable()
{
   long spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);

   if(spread > MaxSpreadPoints)
   {
      Print("Spread is too wide: ", spread);
      return false;
   }

   return true;
}

void SendMarketOrder(ENUM_ORDER_TYPE orderType)
{
   double volumeMin = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double volumeMax = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double volumeStep = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);

   double volume = NormalizeVolume(Lots, volumeMin, volumeMax, volumeStep);

   if(volume < volumeMin || volume > volumeMax)
   {
      Print("Invalid volume after normalization: ", volume);
      return;
   }

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

   double price = (orderType == ORDER_TYPE_BUY) ? tick.ask : tick.bid;
   double sl = 0.0;
   double tp = 0.0;

   if(orderType == ORDER_TYPE_BUY)
   {
      sl = price - StopLossPoints * _Point;
      tp = price + TakeProfitPoints * _Point;
   }
   else
   {
      sl = price + StopLossPoints * _Point;
      tp = price - TakeProfitPoints * _Point;
   }

   MqlTradeRequest request;
   MqlTradeResult result;
   MqlTradeCheckResult check;

   ZeroMemory(request);
   ZeroMemory(result);
   ZeroMemory(check);

   request.action = TRADE_ACTION_DEAL;
   request.symbol = _Symbol;
   request.volume = volume;
   request.type = orderType;
   request.price = price;
   request.sl = NormalizeDouble(sl, _Digits);
   request.tp = NormalizeDouble(tp, _Digits);
   request.deviation = 20;
   request.type_filling = ORDER_FILLING_FOK;

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

   if(!OrderSend(request, result))
   {
      Print("OrderSend failed. retcode=", result.retcode);
      return;
   }

   Print("Order sent. retcode=", result.retcode,
         " order=", result.order,
         " deal=", result.deal,
         " spread=", SymbolInfoInteger(_Symbol, SYMBOL_SPREAD));
}

double NormalizeVolume(double volume, double minVolume, double maxVolume, double step)
{
   volume = MathMax(minVolume, MathMin(maxVolume, volume));
   double steps = MathFloor((volume - minVolume) / step);
   return NormalizeDouble(minVolume + steps * step, 2);
}

5.1 コードで見るべきポイント

このサンプルでは、MQL5らしい構造として次の点を入れています。

• OnInitでインジケータハンドルを作成する
• CopyBufferで移動平均線の値を取得する
• 取得件数が不足した場合は処理を止める
• 最新足ではなく確定足を使ってシグナル判定する
• スプレッドが広い場合は注文しない
• ロットを最小ロット、最大ロット、ロットステップに合わせる
• OrderSend前にOrderCheckを行う
• OrderSend結果をログに残す

最新足は形成中で値が変わるため、シグナル判定に使うとバックテストとフォワードで挙動がずれやすくなります。
検証では、確定足を使う設計のほうが比較しやすくなります。

5.2 実運用向けに不足している処理

このサンプルには、実運用で必要になりやすい処理がすべて含まれているわけではありません。
実運用を検討する場合は、次の要素を追加して検証します。

• 取引可能時間の確認
• ストップレベルの確認
• フリーズレベルの確認
• 証拠金確認
• netting口座とhedging口座の差
• 約定方式に応じたtype_fillingの調整
• 連続エントリー制御
• 日次損失制限
• 最大ドローダウンによる停止処理

ブローカーや銘柄により、使用できる約定方式、最小ロット、ストップレベルは異なります。
注文処理を含むEAでは、銘柄仕様を前提にしたチェックが必要です。

6. パターン別比較

【結論】
バックテスト、期間外テスト、フォワードテストは、それぞれ確認できる内容が異なります。
EAの評価では、ひとつの検証方法だけでなく、複数の検証を組み合わせることが重要です。

バックテストは、EAの仮説を素早く検証するために使います。
フォワードテストは、バックテスト結果が実際の環境でも大きく崩れないかを確認するために使います。

6.1 どの順番で使うべきか

一般的な順番は、次の通りです。

1. 単純バックテストでロジックが動くか確認する
2. パラメータを大きな範囲で確認する
3. 期間外データで成績の崩れ方を見る
4. 複数の相場局面で確認する
5. フォワードテストで再現性を確認する
6. 実運用前にリスク制御と停止条件を確認する

この順番にすると、実運用前に見つけるべき問題を段階的に整理できます。

7. 誤作動しやすい場面

【結論】
バックテストとフォワードテストの差は、ロジックの問題だけでなく、価格データ、スプレッド、約定、ティック更新、口座条件の違いから発生します。
差が出た場合は、成績だけでなく取引ログと注文条件を確認します。

EAが誤作動しやすい場面には、次のようなものがあります。

• スプレッドが急に広がる時間帯
• 指標発表前後の価格急変
• 流動性が低い時間帯
• 週明けや週末の価格ギャップ
• 約定方式が想定と異なる銘柄
• ストップレベルが広い銘柄
• 最新足でシグナルを判定している場合
• CopyBufferの取得件数を確認していない場合

7.1 最新足を使う場合の注意点

最新足はまだ確定していないため、ティックごとにインジケータ値が変わります。
最新足のクロスやブレイクを使うと、バックテストとフォワードテストで取引位置がずれる場合があります。

確定足を使う設計にすると、シグナルが固定されるため、検証結果を比較しやすくなります。
一方で、エントリーは遅くなる場合があります。

7.2 スプレッド拡大の影響

スプレッドが広がると、エントリー価格と決済価格が不利になりやすくなります。
特に、短期売買や小さな利幅を狙うEAでは、スプレッド差が成績に大きく影響します。

バックテストでは良い結果でも、フォワードテストで成績が悪化する場合は、スプレッド条件を確認します。
MaxSpreadPointsのような上限を設けると、検証条件を管理しやすくなります。

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

【結論】
バックテストでは、総損益だけでなく、最大ドローダウン、取引回数、連敗数、パラメータ依存性を確認します。
利益額だけを見ると、リスクや過剰最適化を見落としやすくなります。

バックテストで確認すべき主な項目は、次の通りです。

8.1 パラメータ依存性を見る

パラメータを少し変えただけで成績が大きく崩れるEAは、過去データに強く依存している可能性があります。
たとえば、移動平均線の期間を20から21に変えただけで大きく悪化する場合は、設計を見直す必要があります。

安定した設計では、近いパラメータ範囲でも極端に結果が変わりにくい傾向があります。
ただし、安定したバックテスト結果であっても、将来の利益は保証されません。

8.2 取引回数を見る

取引回数が少なすぎる場合、結果が偶然に左右されやすくなります。
一方で、取引回数が多すぎる場合は、スプレッドや約定差の影響を受けやすくなります。

EAの時間足、売買ロジック、銘柄特性に応じて、必要な取引回数は変わります。
検証では、取引回数とドローダウンを合わせて確認します。

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

【結論】
フォワードテストでは、バックテストとの成績差だけでなく、約定差、スプレッド拡大時の挙動、VPS環境での安定性を確認します。
実運用に近い問題は、フォワードテストで見つかることがあります。

フォワードテストで確認すべき項目は、次の通りです。

• 約定価格と想定価格の差
• スプレッド拡大時のエントリー抑制
• 取引頻度
• ドローダウン
• バックテストとの乖離
• ブローカー差
• VPS環境での安定性
• ログ出力の不足
• 取引時間外の動作
• サーバー時間の影響

9.1 バックテストとの乖離を見る

フォワードテストで成績が悪化した場合、原因を分類します。
主な原因は、ロジックの過剰最適化、スプレッド差、約定差、取引頻度の変化、価格データの差です。

乖離を確認するときは、損益だけで判断しません。
エントリー回数、保有時間、損切り回数、利確回数、最大含み損も比較します。

9.2 VPS環境での安定性を見る

EAを常時稼働させる場合、VPS環境での安定性も確認します。
通信遅延、端末再起動、チャート設定、EAの再初期化、ログ容量などが運用に影響する場合があります。

OnInitとOnDeinitの処理が適切でないと、再起動後にインジケータハンドルが作成されない、またはログから原因を追えない場合があります。
フォワードテストでは、EAを長時間動かしたときの安定性も確認します。

10. 実運用での注意点

【結論】
MQL5のEAを実運用に近づける場合は、バックテストの成績ではなく、リスク管理、約定条件、ブローカー仕様、停止条件を重視します。
自動売買には損失リスクがあり、検証結果は将来の利益を保証しません。

実運用では、次の点を確認します。

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

10.1 netting口座とhedging口座の違い

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

バックテスト条件とフォワードテスト環境の口座タイプが異なると、ポジション管理の挙動が変わる可能性があります。
PositionSelectや既存ポジション確認の実装は、口座タイプを考慮して設計します。

10.2 ロットと証拠金の確認

ロット計算では、最小ロット、最大ロット、ロットステップ、証拠金、損切り幅、ティックバリュー、ティックサイズを考慮します。
固定ロットだけで検証すると、資金量が変わった場合のリスクを見落としやすくなります。

リスク率ベースのロット計算を使う場合でも、銘柄仕様に合うようにロットを丸める必要があります。
OrderCheckを使うと、注文前に証拠金や取引条件の問題を確認しやすくなります。

11. 改善案と代替手段

【結論】
バックテストとフォワードテストの差を小さくするには、ロジックを複雑にするよりも、検証条件を明確にし、パラメータ依存を下げることが重要です。
改善は、売買条件、フィルター、リスク制御、ログ設計の順に整理します。

改善案として、次の方法があります。

11.1 パラメータを減らす

パラメータが多いEAは、過去データに合わせやすくなります。
フィルターを増やすほど、バックテストでは良く見えてもフォワードテストで崩れる可能性があります。

改善では、まず不要な条件を減らします。
次に、近いパラメータ範囲で成績が極端に変わらないかを確認します。

11.2 ロジックの役割を分ける

EAの条件は、役割ごとに分けると検証しやすくなります。
たとえば、トレンド判定、エントリー判定、決済判定、リスク制御を分けます。

役割が混ざると、成績が変化した原因を特定しにくくなります。
バックテストとフォワードテストを比較する場合は、どの条件が差を生んだのかを追える構造が必要です。

12. まとめ

【結論】
MQL5のバックテストとフォワードテストは、どちらか一方で完結するものではありません。
バックテストで仮説を検証し、フォワードテストで再現性と実運用に近いリスクを確認する流れが重要です。

バックテストでは、総損益だけでなく、最大ドローダウン、取引回数、連敗数、スプレッド条件、パラメータ依存性を確認します。
フォワードテストでは、約定差、スプレッド拡大、ブローカー差、VPS環境での安定性を確認します。

MQL5のEAでは、OnInit、OnTick、OnDeinit、インジケータハンドル、CopyBuffer、OrderCheck、OrderSendを正しく分けて扱うことが重要です。
検証しやすい構造にしておくと、バックテストとフォワードテストの差を分析しやすくなります。

バックテスト結果は将来の利益を保証しません。
実運用前には、フォワードテスト、リスク制御、停止条件、ブローカー仕様の確認が必要です。

FAQ

Q1. MQL5のバックテストとフォワードテストの違いは何ですか。

バックテストは過去データでEAの動作を確認する検証です。フォワードテストは、未使用期間やデモ環境でEAの再現性を確認する検証です。

Q2. バックテストで良い結果なら実運用してもよいですか。

バックテスト結果だけで実運用判断を行うのは危険です。スプレッド、約定差、ブローカー仕様、過剰最適化の影響を確認するためにフォワードテストが必要です。

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

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

Q4. バックテストとフォワードテストの結果が違う原因は何ですか。

主な原因は、価格データの差、スプレッド条件、約定遅延、スリッページ、取引時間、ブローカー仕様、過剰最適化です。成績だけでなく、取引ログと注文条件を確認します。

Q5. MQL5のEAでCopyBufferを使うときの注意点は何ですか。

MQL5では、インジケータハンドルを作成してからCopyBufferで値を取得する構造が多く使われます。取得件数が不足した場合は処理を止め、最新足と確定足の違いにも注意します。

Q6. 過剰最適化を避けるにはどうすればよいですか。

パラメータを増やしすぎず、近い値で成績が極端に変わらないかを確認します。調整に使っていない期間やフォワードテストで、成績が大きく崩れないかを見ることも重要です。

Q7. OrderCheckはなぜ必要ですか。

OrderCheckは、OrderSendの前に証拠金、ロット、銘柄条件などの問題を確認するために使います。実運用では、最小ロット、最大ロット、ロットステップ、ストップレベルなどが注文可否に影響します。

Q8. デモ口座のフォワードテストだけで十分ですか。

デモ口座のフォワードテストは有用ですが、リアル口座と約定条件が異なる場合があります。実運用前には、ブローカー条件、スプレッド、約定方式、リスク許容度を別途確認する必要があります。