MQL5とPythonを連携したEA設計と実装方法

この記事の結論

MQL5でPythonによるデータ分析をEA設計に組み込む場合は、MQL5側とPython側の役割を分離することが重要です。
MQL5のEAは価格取得、注文前チェック、注文送信、ポジション管理を担当し、Pythonは集計、特徴量作成、検証、シグナル補助を担当します。
Pythonの分析結果をそのまま売買判断に使うのではなく、MQL5側でスプレッド、ロット、証拠金、既存ポジション、取引時間を再確認する必要があります。
バックテスト結果は将来の利益を保証しないため、Python分析を使うEAでもフォワードテストと実運用条件の確認が必要です。

1. この設計が必要な理由

【結論】
MQL5とPythonを連携する設計が必要になる理由は、EAの取引処理とデータ分析では求められる役割が異なるためです。
MQL5はMetaTrader 5上の取引実行に適しており、Pythonは大量データの分析や特徴量作成に適しています。

MQL5のEAは、ティック受信、注文管理、ポジション管理、口座情報の取得に強い構造です。
一方で、PythonはCSVやデータフレームを使った集計、統計処理、機械学習前処理、可視化に向いています。

【定義】
MQL5 Pythonデータ分析設計とは、MQL5で取得した価格や取引データをPythonで分析し、その結果をEAの判断材料として使う構成です。

この設計では、Pythonを売買判断の中心に置きすぎないことが重要です。
EAの最終判断は、MQL5側で取引条件を確認してから行う構造にします。

1.1 MQL5だけで完結させにくい処理

Python連携が向いている処理には、次のようなものがあります。

• 長期間データの集計
• 複数銘柄の特徴量作成
• ボラティリティや相関の分析
• 売買条件ごとの成績比較
• パラメータごとの検証結果整理
• レポート用データの加工

MQL5でも配列やファイル処理は使えます。
ただし、分析対象が増えるほど、EA本体に分析処理を詰め込む設計は保守しにくくなります。

1.2 Python分析をそのまま取引に使う危険性

Pythonで有効に見える分析結果でも、実際のEAではスプレッド、約定遅延、ロット制限、証拠金、ブローカー仕様の影響を受けます。
分析結果をEAに渡す場合でも、MQL5側で再確認する層が必要です。

Pythonのシグナルは、EAにとって「取引候補」です。
最終的な注文可否は、MQL5側のリスク制御と注文前チェックで決めます。

2. EA全体の設計思想

【結論】
MQL5とPythonを連携するEAでは、分析、判定、注文、管理を分離します。
この分離により、Python分析の変更がEAの注文処理へ直接影響しにくくなります。

基本思想は、Pythonを補助分析層として扱うことです。
EAの中核は、MQL5側の状態管理、リスク管理、注文前チェックに置きます。

MQL5 Python連携EAは、次の流れで設計すると整理しやすくなります。

価格データ取得
↓
データ出力
↓
Python分析
↓
分析結果の読込
↓
フィルター判定
↓
シグナル判定
↓
リスク確認
↓
注文前チェック
↓
注文送信
↓
約定後管理

2.1 役割を分ける理由

EA本体に分析処理、注文処理、検証用ログをすべて混ぜると、どの条件が成績に影響したのか分かりにくくなります。
役割を分けると、問題が起きたときに原因を切り分けやすくなります。

Python分析の結果が不安定なのか、EAの注文条件が厳しすぎるのか、約定環境が影響しているのかを分けて確認できます。

2.2 MQL5側で必ず持つべき責任

MQL5側では、次の責任を持たせます。

• 最新データと確定足データの区別
• 既存ポジションの確認
• ロット制限の確認
• 証拠金の確認
• スプレッドの確認
• 取引可能時間の確認
• 注文前の妥当性確認
• 注文結果の記録
• エラー時のログ出力

Pythonが買いまたは売りの候補を返しても、EAは無条件で注文してはいけません。
MQL5側で取引条件を再確認することで、実運用時の事故を抑えやすくなります。

3. 基本構造

【結論】
基本構造は、MQL5がデータを書き出し、Pythonが分析し、MQL5が結果を読み込む形です。
EAはOnTickを中心に動き、初期化はOnInit、終了処理はOnDeinitで整理します。

MQL5のEAでは、OnTickが新しいティックを受信したときに呼び出されます。
Python分析の結果を使う場合でも、毎ティックで重い処理を実行する構造は避けます。

3.1 推奨するファイル連携の構成

初心者から中級者向けには、CSVファイルを使った分離構成が扱いやすいです。

MQL5 EA
  price_data.csv を出力
  signal_result.csv を読込

Python
  price_data.csv を分析
  signal_result.csv を出力

CSV連携は単純ですが、ファイル更新タイミングの管理が必要です。
EAが読み込む前にPython側の書き込みが完了しているかを確認する設計にします。

3.2 OnInit、OnTick、OnDeinitの役割

OnTickにすべてを詰め込むと、処理の見通しが悪くなります。
一定間隔で十分な処理はOnTimerに分けると、EAの設計が整理しやすくなります。

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

【結論】
MQL5 Pythonデータ分析EAでは、データ取得、分析結果読込、シグナル判定、リスク管理、注文管理を別モジュールとして考えます。
各モジュールの責任を分けるほど、検証と修正がしやすくなります。

EA設計では、単なる条件分岐ではなく状態管理を意識します。
状態管理とは、EAが現在どの段階にいるのかを明確に扱うことです。

4.1 データ出力モジュール

データ出力モジュールは、MQL5側の価格データや取引状態をCSVに保存します。
Pythonはこのデータを使って分析します。

出力する候補は次の通りです。

• 日時
• 始値
• 高値
• 安値
• 終値
• ティックボリューム
• スプレッド
• 保有ポジション状態
• 直近の損益

最新足を使うか、確定足を使うかは明確に分けます。
未確定の最新足はティックごとに値が変わるため、検証結果と実運用の挙動がずれやすくなります。

4.2 Python分析モジュール

Python分析モジュールは、MQL5から出力されたデータを読み込み、分析結果を作成します。
分析結果は、EAが読みやすい単純な形式にします。

例として、次のような列を使います。

Pythonの出力は複雑にしすぎないことが重要です。
EA側で解釈しにくい形式にすると、エラー処理と検証が難しくなります。

4.3 リスク管理モジュール

リスク管理モジュールは、Python分析とは独立して動かします。
シグナルがどれだけ強く見えても、リスク条件に反する場合は注文しない構造にします。

確認する項目は次の通りです。

• 1回の取引で許容する損失
• 最大ドローダウンの許容範囲
• 連敗時の停止条件
• 1日の最大損失
• 最大ポジション数
• レバレッジによる証拠金負荷

バックテストで良い結果が出ても、実運用では約定条件やスプレッドが変わる場合があります。
リスク管理は、分析結果より優先して評価します。

4.4 注文管理モジュール

注文管理モジュールは、MqlTradeRequest、MqlTradeResult、MqlTradeCheckResultを使って注文処理を整理します。
OrderSendの前には、OrderCheckで注文条件を確認する設計が望ましいです。

注文前には、少なくとも次の項目を確認します。

• 取引が許可されているか
• ロットが最小ロット以上か
• ロットが最大ロット以下か
• ロットステップに合っているか
• 必要証拠金を満たしているか
• ストップレベルに反していないか
• フリーズレベルに反していないか
• スプレッドが許容範囲内か
• netting口座とhedging口座の違いを考慮しているか

5. 実装パターン

【結論】
実装パターンは、CSV連携、定期実行、シグナルファイル読込の3つに分けると設計しやすくなります。
最初はCSV連携から始め、安定してから処理の自動化を広げる方法が現実的です。

Python分析をEAに組み込む方法は複数あります。
重要なのは、EAの取引処理を分析処理に依存させすぎないことです。

5.1 CSVで価格データを渡す

MQL5側は、確定足のデータをCSVに出力します。
Python側は、CSVを読み込んで分析します。

この方式は実装が単純です。
ただし、ファイルの読み書きタイミングを管理しないと、古いシグナルを読んでしまう可能性があります。

5.2 Pythonの分析結果をシグナルとして読む

Pythonは、分析結果をシグナルファイルとして保存します。
MQL5側は、そのファイルを読み込み、シグナルの時刻と有効期限を確認します。

EAは、Pythonのシグナルだけで注文しません。
MQL5側のフィルターとリスク確認を通過した場合のみ、注文候補として扱います。

5.3 OnTimerで読み込み頻度を制御する

毎ティックでファイルを読むと、処理負荷が増えます。
シグナルが数秒から数分単位で十分な場合は、OnTimerで読み込み頻度を制御します。

OnTimerを使うと、価格更新と分析結果読込の責任を分けやすくなります。
スキャルピングのように反応速度が重要な設計では、ファイル連携の遅延も検証対象になります。

6. サンプルコード

【結論】
サンプルコードでは、MQL5側で確定足データを書き出し、Pythonのシグナル結果を読み込み、注文前チェックへ進む流れを示します。
コードは検証用の最小構成であり、実運用では銘柄仕様と口座条件に合わせて調整が必要です。

以下のコードは、EA設計の骨格を示すサンプルです。
Python本体の分析処理はEAの外側で実行する前提です。

#property strict

input double RiskPercent = 1.0;
input int MaxSpreadPoints = 30;
input string PriceFileName = "price_data.csv";
input string SignalFileName = "signal_result.csv";

datetime last_bar_time = 0;
string latest_signal = "NONE";
datetime latest_signal_time = 0;

int OnInit()
{
   EventSetTimer(10);
   Print("EA initialized for MQL5 and Python data analysis workflow");
   return INIT_SUCCEEDED;
}

void OnDeinit(const int reason)
{
   EventKillTimer();
   Print("EA stopped. reason=", reason);
}

void OnTimer()
{
   ReadPythonSignal();
}

void OnTick()
{
   if(IsNewBar())
   {
      WriteClosedBarData();
   }

   if(latest_signal == "NONE")
      return;

   if(!IsSpreadAcceptable())
      return;

   if(!IsSignalFresh())
      return;

   if(HasOpenPosition())
      return;

   double lot = CalculateSampleLot();
   if(lot <= 0.0)
      return;

   if(latest_signal == "BUY")
      SendMarketOrder(ORDER_TYPE_BUY, lot);
   else if(latest_signal == "SELL")
      SendMarketOrder(ORDER_TYPE_SELL, lot);
}

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 WriteClosedBarData()
{
   MqlRates rates[];
   ArraySetAsSeries(rates, true);

   int copied = CopyRates(_Symbol, _Period, 1, 100, rates);
   if(copied < 50)
   {
      Print("Not enough closed bar data");
      return;
   }

   int file_handle = FileOpen(PriceFileName, FILE_WRITE | FILE_CSV | FILE_COMMON, ',');
   if(file_handle == INVALID_HANDLE)
   {
      Print("Failed to open price file. error=", GetLastError());
      return;
   }

   FileWrite(file_handle, "time", "open", "high", "low", "close", "tick_volume", "spread");

   for(int i = copied - 1; i >= 0; i--)
   {
      FileWrite(file_handle,
                TimeToString(rates[i].time, TIME_DATE | TIME_MINUTES),
                DoubleToString(rates[i].open, _Digits),
                DoubleToString(rates[i].high, _Digits),
                DoubleToString(rates[i].low, _Digits),
                DoubleToString(rates[i].close, _Digits),
                (long)rates[i].tick_volume,
                (int)rates[i].spread);
   }

   FileClose(file_handle);
}

void ReadPythonSignal()
{
   int file_handle = FileOpen(SignalFileName, FILE_READ | FILE_CSV | FILE_COMMON, ',');
   if(file_handle == INVALID_HANDLE)
   {
      latest_signal = "NONE";
      return;
   }

   if(!FileIsEnding(file_handle))
   {
      string header_time = FileReadString(file_handle);
      string header_signal = FileReadString(file_handle);
   }

   string signal_time_text = "";
   string signal_value = "NONE";

   while(!FileIsEnding(file_handle))
   {
      signal_time_text = FileReadString(file_handle);
      signal_value = FileReadString(file_handle);
   }

   FileClose(file_handle);

   if(signal_value != "BUY" && signal_value != "SELL" && signal_value != "NONE")
   {
      latest_signal = "NONE";
      Print("Invalid signal value from Python: ", signal_value);
      return;
   }

   latest_signal = signal_value;
   latest_signal_time = StringToTime(signal_time_text);
}

bool IsSignalFresh()
{
   if(latest_signal_time == 0)
      return false;

   int valid_seconds = PeriodSeconds(_Period) * 2;
   return (TimeCurrent() - latest_signal_time) <= valid_seconds;
}

bool IsSpreadAcceptable()
{
   long spread = 0;
   if(!SymbolInfoInteger(_Symbol, SYMBOL_SPREAD, spread))
   {
      Print("Failed to get spread. error=", GetLastError());
      return false;
   }

   return spread <= MaxSpreadPoints;
}

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

double CalculateSampleLot()
{
   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 0.0;
   }

   double equity = AccountInfoDouble(ACCOUNT_EQUITY);
   double sample_lot = MathMax(min_lot, equity * RiskPercent / 100000.0);
   sample_lot = MathMin(sample_lot, max_lot);
   sample_lot = MathFloor(sample_lot / lot_step) * lot_step;

   return NormalizeDouble(sample_lot, 2);
}

bool SendMarketOrder(ENUM_ORDER_TYPE order_type, double lot)
{
   MqlTradeRequest request;
   MqlTradeResult result;
   MqlTradeCheckResult check;

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

   double price = 0.0;
   if(order_type == ORDER_TYPE_BUY)
      price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
   else
      price = SymbolInfoDouble(_Symbol, SYMBOL_BID);

   if(price <= 0.0)
   {
      Print("Invalid order price");
      return false;
   }

   request.action = TRADE_ACTION_DEAL;
   request.symbol = _Symbol;
   request.volume = lot;
   request.type = order_type;
   request.price = price;
   request.deviation = 20;
   request.magic = 20260511;
   request.comment = "Python analysis sample";

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

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

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

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

   Print("Order sent. ticket=", result.order, " deal=", result.deal);
   return true;
}

6.1 サンプルコードの読み方

このサンプルでは、確定足を使ってCSVを書き出します。
CopyRatesの開始位置を1にしているため、未確定の最新足ではなく、直近の確定足から取得します。

Pythonの分析結果は、signal_result.csvから読み込みます。
シグナルが古い場合や不正な値の場合は、注文候補として扱いません。

6.2 ロット計算の注意点

サンプルのロット計算は簡略化されています。
実運用では、損切り幅、ティックバリュー、ティックサイズ、証拠金、銘柄仕様を使って計算する必要があります。

固定ロットだけで設計すると、口座残高の変化や銘柄ごとの値動きに対応しにくくなります。
リスク率ベースの計算を使う場合でも、最小ロット、最大ロット、ロットステップを必ず確認します。

7. 設計パターン比較

【結論】
MQL5とPythonの連携方式は、実装しやすさ、遅延、検証しやすさで選びます。
初心者から中級者は、CSV連携とMQL5側の注文前チェックを組み合わせる構成から始めると管理しやすくなります。

7.1 比較時に見るべき基準

比較する基準は、実装の簡単さだけではありません。
実運用では、遅延、停止時の挙動、エラー時の復旧、ファイル更新の整合性も重要です。

Python連携は便利ですが、EAの依存先が増えます。
Python側が停止した場合にEAがどう動くかを決めておく必要があります。

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

【結論】
バックテストでは、Python分析の有無だけでなく、シグナルの再現性、取引回数、ドローダウン、スプレッド条件を確認します。
良い総損益だけで判断すると、過剰最適化に気づきにくくなります。

確認すべき項目は次の通りです。

• 総損益
• 最大ドローダウン
• 勝率
• 損益比
• 取引回数
• 連敗数
• スプレッド条件
• 期間依存性
• パラメータ依存性
• Pythonシグナルの発生頻度
• シグナル有効期限切れの回数
• OrderCheckで拒否された回数

8.1 Python分析で起きやすい過剰最適化

Pythonでは多くの特徴量を作りやすいため、過去データに合いすぎた条件を作ってしまう場合があります。
パラメータを増やすほど、バックテストの見た目は良くなっても、フォワードで崩れやすくなります。

過剰最適化を避けるには、期間を分けた検証が必要です。
学習または調整に使った期間と、評価に使う期間を分けることで、再現性を確認しやすくなります。

8.2 バックテストとファイル連携の注意点

バックテストで外部ファイルを使う場合、テスター環境のファイル配置や更新タイミングに注意が必要です。
実運用と同じタイミングでシグナルが利用できるとは限りません。

Python分析を後から適用した結果と、EAがその時点で読めた結果は異なる場合があります。
検証では、未来のデータを誤って使わない設計にします。

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

【結論】
フォワードテストでは、Python分析結果が実時間で安定して生成され、EAが古いシグナルを使わずに動くかを確認します。
バックテストで見えにくい約定差、スプレッド拡大、ファイル更新遅延を重点的に見ます。

確認すべき項目は次の通りです。

• 約定差
• スプレッド拡大時の挙動
• 取引頻度
• ドローダウン
• バックテストとの乖離
• ブローカー差
• VPS環境での安定性
• Python処理の停止時の挙動
• 古いシグナルを無視できているか
• シグナル生成時刻と注文時刻の差

9.1 デモ口座とリアル口座の違い

デモ口座とリアル口座では、約定条件やスプレッド条件が異なる場合があります。
Python分析が同じシグナルを出しても、実際の注文結果は環境により変わります。

フォワードテストでは、注文が通ったかどうかだけでなく、想定価格とのずれも確認します。
短期売買ほど、わずかな遅延やスプレッド拡大が成績に影響しやすくなります。

9.2 VPS環境での確認

Python連携EAをVPSで動かす場合、Python実行環境、ファイル保存場所、権限、時刻設定を確認します。
EAだけが正常でも、Python側が停止するとシグナル更新が止まります。

EAは、Python側が停止した場合に注文しない状態へ移る設計が必要です。
停止時に最後のシグナルを使い続ける設計は、意図しない注文につながる可能性があります。

10. 実運用での注意点

【結論】
実運用では、Python分析の精度よりも、EAが危険な条件で注文しないことを優先します。
スプレッド、約定、証拠金、ロット制限、ブローカー仕様を確認し、想定外の状態では取引を止める設計が必要です。

Python分析を使うEAでも、金融リスクは消えません。
バックテスト結果は将来の利益を保証しないため、実運用前にはフォワードテストを行います。

10.1 実運用で変わりやすい条件

実運用では、次の条件が変わる場合があります。

• スプレッド
• 約定速度
• スリッページ
• 取引可能時間
• 最小ロット
• 最大ロット
• ロットステップ
• ストップレベル
• フリーズレベル
• 証拠金率
• netting口座とhedging口座の扱い

これらの条件は、Python分析だけでは判断できません。
MQL5側で銘柄情報と口座情報を確認し、取引可否を決めます。

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

レバレッジが高いほど、少ない証拠金で大きなポジションを持てます。
一方で、想定と逆方向に動いた場合のドローダウンも大きくなりやすいです。

Python分析で勝率が高く見えても、損失幅が大きいロジックでは口座資金が急減する場合があります。
EA設計では、勝率だけでなく損益比と最大ドローダウンを確認します。

10.3 注文を止める条件

実運用では、注文する条件だけでなく、注文しない条件を明確にします。

• Pythonシグナルが古い
• ファイル読込に失敗した
• スプレッドが広い
• 証拠金が不足している
• 連敗数が上限を超えた
• 1日の損失上限に達した
• 取引時間外である
• ブローカー側で取引が制限されている

停止条件を設計しておくと、想定外の状態で注文し続けるリスクを抑えやすくなります。

11. よくある設計ミス

【結論】
よくある設計ミスは、Pythonの分析結果を過信し、MQL5側の状態管理と注文前チェックを省略することです。
EAでは、分析結果よりも実際の取引条件を優先して確認する必要があります。

11.1 古いシグナルを使ってしまう

Pythonが出力したシグナルには、有効期限を持たせます。
時刻を確認しないEAは、相場状況が変わった後でも古いシグナルで注文する可能性があります。

11.2 最新足と確定足を混同する

最新足はティックごとに変化します。
バックテストで確定足を使っていたのに、実運用で未確定足を使うと、シグナルの再現性が低くなります。

11.3 Python側の停止を想定していない

Python処理が停止した場合、EAはシグナル更新が止まったことを検出する必要があります。
最後のシグナルを使い続ける設計は避けます。

11.4 OrderCheckを省略する

OrderSendの前にOrderCheckを使うと、証拠金不足や注文条件の問題を事前に検出しやすくなります。
Python分析が有効でも、実際の注文条件を満たさない場合は注文できません。

11.5 ロット制限を無視する

ロット計算では、最小ロット、最大ロット、ロットステップを確認します。
計算上のロットが正しく見えても、銘柄仕様に合わないロットでは注文が拒否される場合があります。

12. まとめ

【結論】
MQL5 Pythonデータ分析EAは、MQL5を取引実行とリスク管理の中心に置き、Pythonを分析補助として使う設計が適しています。
分析結果を注文に直結させず、MQL5側で状態管理、注文前チェック、実運用リスク確認を行うことが重要です。

MQL5とPythonの連携では、役割分担が設計の中心になります。
Pythonは分析と特徴量作成に向いていますが、取引条件の最終判断はMQL5側で行います。

EA設計では、次の点を守ると検証しやすくなります。

• MQL5とPythonの役割を分ける
• 確定足と最新足を区別する
• 古いシグナルを使わない
• OrderCheckで注文前確認を行う
• ロット制限と証拠金を確認する
• バックテストとフォワードテストを分ける
• スプレッド、約定、ブローカー差を考慮する
• Python側の停止時に注文しない設計にする

Python分析を使うことで、EAの検証や特徴量作成はしやすくなります。
ただし、分析機能を増やすほど過剰最適化のリスクも高まります。
実運用前には、バックテストだけでなくフォワードテストで再現性を確認する必要があります。

FAQ

MQL5でPythonデータ分析を使う目的は何ですか？

MQL5でPythonデータ分析を使う目的は、EAの取引データや価格データを集計し、売買判断の補助情報を作ることです。最終的な注文可否は、MQL5側でリスク条件と取引条件を確認して決めます。

PythonのシグナルだけでEAを動かしてもよいですか？

PythonのシグナルだけでEAを動かす設計は避けるべきです。MQL5側でスプレッド、ロット、証拠金、既存ポジション、取引時間を確認してから注文候補として扱います。

MQL5とPythonの連携はCSVでも実装できますか？

CSV連携は、初心者から中級者でも扱いやすい実装方法です。ただし、ファイル更新タイミング、古いシグナル、読込失敗時の処理を設計する必要があります。

バックテストでPython分析を使うときの注意点は何ですか？

バックテストでは、未来のデータを誤って使わないことが重要です。Pythonで後から分析した結果と、EAがその時点で利用できた結果を混同しないようにします。

Python連携EAでよくある失敗は何ですか？

よくある失敗は、古いシグナルを使い続けること、OrderCheckを省略すること、ロット制限を確認しないことです。Python側の停止時に注文を止める設計も必要です。

Python分析を使えばEAの成績は安定しますか？

Python分析は検証や特徴量作成をしやすくしますが、成績の安定を保証するものではありません。スプレッド、約定条件、ブローカー仕様、相場環境により結果は変わります。

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

フォワードテストでは、Pythonのシグナル生成時刻、EAの読込時刻、注文時刻の差を確認します。約定差、スプレッド拡大、VPS環境での安定性も確認対象です。