AIで作るMT4 EAバックテスト完全ガイド【2026年版】
AIで作ったMT4 EAは、バックテストなしで本番運用してはいけません。見た目が優秀でも「オーバーフィッティング」や「未来参照バグ」が隠れていて、実運用で大きな損失を出すEAがほとんどです。この記事では、MT4のストラテジーテスターの設定から結果の読み方、AIコードの品質チェックまで、バックテストの全工程を完全解説します。
この記事で学べること：
- ストラテジーテスターのモデル選択・スプレッド設定の正しい知識
- プロフィットファクター・ドローダウン・シャープレシオの読み方と目安
- Dukascopyデータで99%モデリング品質を達成する手順
- AIが生成したEAに多い7つのバグとその修正方法
- オーバーフィッティングを見抜くウォークフォワードテストの実践手順
EAをAIで作る方法は別記事「AIを使ったMT4ツールの作り方【2026年版】」で詳しく解説しています。本記事は「作ったEAを正しく評価する」ための実践ガイドです。
バックテストとは？なぜ必要なのか
バックテストとは、過去の価格データを使ってEA（Expert Advisor：自動売買プログラム）の売買ロジックを再現し、仮想的な損益を計算することです。MT4にはこれを実行するための「ストラテジーテスター」が標準搭載されており、追加ツール不要で使用できます。
バックテストなしでは何が危ないのか
AIが生成したEAには、コードが正しく動いているように見えても、実際には誤った収益計算をしているケースが多くあります。代表的な3つのリスクを理解しておきましょう。
| リスク | 内容 | 結果 |
|---|---|---|
| 未来参照バグ | まだ確定していないローソク足のデータを参照してエントリー判断する | バックテストで高成績・実運用でほぼゼロ |
| オーバーフィッティング | 過去の特定データだけに最適化され、汎用性がゼロになる | バックテスト優秀・実運用で大損失 |
| スプレッド・スリッページ無視 | 実際の取引コストを考慮せずに採算ラインを計算している | 微妙に損益がプラスのEAが実際は赤字 |
バックテストはEAの「通過証明書」ではなく、これらのリスクを炙り出すための「審査プロセス」です。バックテストを正しく実施することで、実運用に値するEAかどうかを判断できます。
バックテストの限界も理解しておく
同時に、バックテストには根本的な限界があります。「過去に機能した」ことは「将来も機能する」ことを保証しません。相場環境は変化するため、バックテストで良い結果が出ても、必ずその後にフォワードテスト（デモ口座での実運用確認）を行う必要があります。
ストラテジーテスターの基本設定
MT4のストラテジーテスターは「表示」→「ストラテジーテスター」または「Ctrl + R」で起動できます。設定項目の中で最も重要なのが「モデル」の選択です。
テストモデルの選び方（全ティック・コントロールポイント・始値のみ）
MT4のストラテジーテスターには3種類のテストモデルがあり、それぞれ精度・速度・適切な用途が異なります。
| モデル | 仕組み | 精度 | 速度 | 適切なEA |
|---|---|---|---|---|
| 全ティック（Every Tick） | M1データから擬似ティックを補間生成 | 高い | 遅い | スキャルピング・SL/TPがスプレッドに近いEA |
| コントロールポイント | 各バーを12ポイントに分割してシミュレーション | 中程度 | 速い | デイトレード・スイングEAの初期検証 |
| 始値のみ（Open Prices Only） | 各バーの始値データのみ使用 | 低い（条件次第） | 最速 | ローソク足確定後のみトレードするEA・大量最適化スクリーニング |
モデル選択の判断基準：
3モデルすべてで結果がほぼ同じ → 「始値のみ」で十分
「全ティック」と「コントロールポイント」が同じで「始値のみ」だけ違う → 「コントロールポイント」を使用
すべてで結果が異なる → 「全ティック」を使用
「全ティック」は補間で作った「擬似ティック」であり、本物のティックデータではありません。標準状態では「モデリング品質：90%前後」にとどまります。99%を達成する方法は後述の「高品質ティックデータ」のセクションで解説します。
スプレッドの設定（保守的設定のすすめ）
ストラテジーテスター画面の「スプレッド」欄は、バックテスト中に適用するスプレッド幅をポイント単位で指定します。この設定を甘くすると、実運用では到底達成できない好成績が出てしまいます。
推奨設定：実際の平均スプレッドの1.5〜2倍
- 例）USD/JPYの平均スプレッドが1.0pipsのブローカー → バックテストは1.5〜2.0pipsで設定
- ニュース時間帯を含めた最悪ケースを想定することで、実運用との乖離を最小化できます
スキャルピングEAは特に厳しく設定してください。スキャルピングは利確幅が小さいため、スプレッドが1pips広がるだけで採算が大きく変わります。
期間と通貨ペアの選び方
テスト期間は短すぎると統計的に信頼できず、長すぎると古い相場環境（低ボラティリティ時代など）を含みすぎて現状に合わなくなります。EAの時間足に応じた目安は以下のとおりです。
| EAの時間足 | 最低テスト期間 | 推奨テスト期間 |
|---|---|---|
| M1〜M15 | 1年 | 2〜3年 |
| H1〜H4 | 3年 | 5〜7年 |
| D1以上 | 5年 | 10年以上 |
期間内にリーマンショック（2008年）、コロナショック（2020年）などの大相場変動を含めると、ロバスト性の評価精度が上がります。
バックテスト結果レポートの読み方
バックテスト完了後、「レポート」タブで詳細な成績データが確認できます。数値の見方を理解していないと、優秀に見えるEAが実は欠陥品だったり、その逆もあります。主要指標を順番に解説します。
プロフィットファクター（PF）
プロフィットファクター（PF）= 総利益 ÷ 総損失
EAの総合的な収益効率を示す最重要指標です。1.0を下回ると損失EAです。
| PF値 | 評価 |
|---|---|
| 1.0未満 | 損失システム（使用不可） |
| 1.0〜1.3 | 要改善（スプレッド変化で容易に損失転落） |
| 1.3〜1.5 | 実用最低ライン |
| 1.5〜2.0 | 良好 |
| 2.0〜3.0 | 優秀 |
| 3.0超 | 要注意（オーバーフィッティングの強い疑い） |
注意：PF3.0超は一見すると優秀に見えますが、バックテスト期間が短い・取引数が少ない・過度な最適化が行われたEAに多く見られます。総取引数が100回未満でPF3.0超の場合はほぼオーバーフィッティングです。
最大ドローダウン（絶対・相対）
ドローダウンは「口座残高のピーク時から最低点への落下幅」です。EAを実際に運用するうえで最も重要なリスク指標になります。
- 絶対ドローダウン：初期入金額から最低残高への金額差。「元手をどれだけ下回ったか」
- 相対ドローダウン：テスト期間中の最高残高から最低残高への下落率（%）。「ピークからどれだけ減ったか」
| 相対ドローダウン | 評価 |
|---|---|
| 10%以下 | 優秀 |
| 10〜20% | 良好（機関投資家でも許容される水準） |
| 20〜30% | 許容範囲内（厳格な資金管理が必要） |
| 30%超 | 危険域（精神的・資金的に継続困難） |
重要：ドローダウンはバックテスト期間全体の最大値を確認すること。直近の好調期だけ切り取ったバックテストはドローダウンが小さく見えますが、意味がありません。
シャープレシオ・リカバリーファクター・期待値
シャープレシオ：リスク1単位あたりのリターン。1.0以上が実用ライン、2.0〜3.0が優秀ですが、バックテストで2.0超でも実運用では1.0〜1.5程度に落ちることが多いです。
リカバリーファクター = 総損益 ÷ 最大ドローダウン：損失からの回復力を示します。1年間のバックテストで2.0以上が良好、5.0以上が優秀の目安です。
期待値（Expected Payoff）= (勝率 × 平均利益) − (敗率 × 平均損失)：1回のトレードで平均的に何pips/円を獲得できるかを示します。スプレッドコストの2〜3倍以上がひとつの目安です。
勝率だけを見てはいけない理由
勝率はトレードの「成功率」を示しているに過ぎず、収益性とは別物です。以下の2例を比較してください。
| EAパターンA | EAパターンB | |
|---|---|---|
| 勝率 | 70% | 30% |
| 平均利益 | 10pips | 50pips |
| 平均損失 | 20pips | 15pips |
| プロフィットファクター | 1.17（ほぼ損益分岐点） | 1.43（良好） |
勝率70%のパターンAより、勝率30%のパターンBの方が実際には優れたEAです。勝率だけでなく必ずPFと期待値をセットで評価してください。なお低勝率EAは負け続ける期間が心理的につらいため、実運用中に途中解除してしまうリスクも考慮が必要です。
高品質ティックデータの使い方（99%モデリング品質の達成）
MT4標準のバックテストは「全ティック」モードでもモデリング品質が90%前後にとどまります。これは実際のティックデータではなく、M1バーから補間した「擬似ティック」だからです。特にスキャルピングEAの場合、この10%の差が結果に大きく影響します。
Dukascopy + Tickstoryで99%を達成する手順
Dukascopyは2003年頃からの主要通貨ペアのティックデータを無料公開しています。これをTickstory（無料ツール）でMT4形式に変換することで、モデリング品質99%を達成できます。
手順1：Tickstory Liteをダウンロード・インストール
- Tickstory公式サイトから「Tickstory Lite（無料）」をダウンロード
- インストーラーを起動してデフォルト設定でインストール
手順2：データをダウンロード
- Tickstoryを起動し、「Dukascopy」データソースを選択
- 取得したい通貨ペア（例：USD/JPY）を選択
- 期間を設定（例：2014年〜2024年）してダウンロード実行
- 完了まで数分〜数十分かかります（USD/JPY 10年分は約1GB）
手順3：MT4形式にエクスポート
- Tickstoryの「Export」でMT4用フォーマット（.hst）に変換
- 出力先をMT4のHistoryフォルダに設定
（例：C:\Users\ユーザー名\AppData\Roaming\MetaQuotes\Terminal\[端末ID]\history\[ブローカー名]\） - MT4を再起動
手順4：確認
ストラテジーテスターでバックテストを実行し、レポートの「Modeling quality: 99.00%」を確認してください。90%のままであればM1データが不足しています。
Tick Data Suite（有料）との比較
| 項目 | Tickstory無料版 | Tick Data Suite（有料） |
|---|---|---|
| 価格 | 無料（一部機能制限） | 有料（買い切り） |
| モデリング品質 | 99%達成可能 | 99.9%達成可能 |
| 変動スプレッド対応 | 部分対応 | 完全対応 |
| スリッページシミュレーション | 限定的 | 詳細設定可能 |
| MT4との統合 | 手動エクスポートが必要 | 自動・シームレス |
| おすすめ対象 | 入門・学習・初期検証 | 本格運用・商用EA精密検証 |
最初はTickstory無料版から始めて問題ありません。本格的なEA開発や商用運用を考えている場合はTick Data Suiteへの移行を検討してください。
オーバーフィッティングを見抜く方法
オーバーフィッティング（カーブフィッティング）はMT4 EAバックテストで最も多く見られる問題です。特にAIで最適化されたパラメーターを使う場合は注意が必要です。
オーバーフィッティングの定義と見分け方
オーバーフィッティングとは、過去の特定データに過剰適合した結果、バックテストでは高成績でも実運用では機能しない状態のことです。
以下に当てはまる場合はオーバーフィッティングを強く疑ってください：
- パラメーターを±10〜20%変えると成績が急激に悪化する（感応度が高すぎる）
- テスト期間を少し変えると成績が大きく変動する
- 取引数が100回未満でPFが2.0を大きく超えている
- 特定の通貨ペアでしか機能せず、他のペアでは全く機能しない
- 多数のパラメーターを持つ複雑なEAで成績が非常に良い
パラメーター数の目安（数が多いほど危険）
信頼性のあるバックテスト結果を得るには、取引数 ÷ パラメーター数 ≥ 30 が目安です。
| パラメーター数 | 必要な最低取引数 |
|---|---|
| 1〜2個 | 30〜60回 |
| 3〜5個 | 90〜150回 |
| 6〜10個 | 180〜300回 |
| 10個超 | 300回以上（現実的に困難） |
AIが生成するEAは多くの場合パラメーターが多く、設定を細かく刻んで最適化するとオーバーフィットしやすい構造になります。AIへのプロンプトで「パラメーターは最小限（5個以内）にしてください」と明示することが重要です。
ウォークフォワードテストで本物かどうかを確認する
ウォークフォワードテストは、バックテスト期間を「最適化用（In-Sample）」と「検証用（Out-of-Sample）」に分割して、オーバーフィッティングを検出する手法です。
基本的な手順（ローリング方式）：
全体データ: 2014年〜2024年（10年間）
第1ウィンドウ:
In-Sample（最適化）: 2014年〜2021年（7年）
Out-of-Sample（検証）: 2022年（1年）
第2ウィンドウ:
In-Sample（最適化）: 2015年〜2022年（7年）
Out-of-Sample（検証）: 2023年（1年）
第3ウィンドウ:
In-Sample（最適化）: 2016年〜2023年（7年）
Out-of-Sample（検証）: 2024年（1年）
評価: 3つのOut-of-Sampleを合算した成績がEAの真の実力標準的な分割比率：In-Sample 70〜80%：Out-of-Sample 20〜30%
ウォークフォワード効率（WFE）で定量評価：
WFE = Out-of-Sample年率PF ÷ In-Sample年率PF
WFE > 0.7: 優秀（実運用可能）
WFE 0.5〜0.7: 良好（実運用可能）
WFE < 0.5: 高度にカーブフィット（実運用は危険）バックテストで優秀でも、WFEが0.5未満の場合は実運用をお勧めしません。
MT4最適化機能の正しい使い方
ストラテジーテスターの「最適化」機能を使うと、指定したパラメーター範囲を自動で試して最も成績が良い組み合わせを見つけられます。ただし使い方を誤るとオーバーフィッティングを助長します。
遺伝的アルゴリズムvsフル最適化
| 項目 | フル最適化（完全探索） | 遺伝的アルゴリズム（GA） |
|---|---|---|
| 手法 | 全組み合わせを網羅 | 自然選択で優良解を探索 |
| 速度 | 非常に遅い | 大幅に高速（数十〜数千倍速い） |
| 網羅性 | 完全（最適解を必ず発見） | 不完全（局所最適解に収束する場合あり） |
| MT4の自動切替 | 手動選択 | 組み合わせ数100万超で自動切替 |
実践的な使い分け：
- 最初はGAで候補パラメーター帯を絞り込む（広い範囲を高速スクリーニング）
- 絞り込んだ狭い範囲でフル最適化し、感応度マップを確認する
- ピーク値（最高成績の点）ではなく、近隣も安定している「台地状の領域」を選ぶ
急峻な山のようにパラメーターが1点だけ突出して良い場合は、オーバーフィッティングのサインです。少しパラメーターがずれると成績が崩壊するため、実運用では使えません。
最適化の基準は「残高」を使わない
「残高（Balance）の最大化」を目標にした最適化は最もオーバーフィットしやすい設定です。代わりに以下を使用してください。
- プロフィットファクター：収益効率を重視したい場合
- 期待値（Expected Payoff）：1トレードあたりの平均損益を重視する場合
- シャープレシオ：リスク調整後リターンを重視する場合
- カスタム指標：OnTester()関数でPF×リカバリーファクターなど独自指標を設定（最も推奨）
AIが生成したEAに多い7つのバグ
ChatGPTやClaudeが生成するMQL4コードには、共通して現れやすいバグパターンがあります。バックテスト前に必ずチェックしてください。
バグ1：未来参照（shift=0問題）【最頻出】
AIが生成するコードで最も多いのが「shift=0」を使った未来参照です。現在のローソク足（まだ確定していない足）のデータを参照すると、バックテストでは知り得ない情報を使ってしまいます。
// ❌ 危険なコード（shift=0は現在の未確定バー）
double rsi = iRSI(NULL, 0, 14, PRICE_CLOSE, 0); // 現在バーのRSI（未確定）
double close = iClose(NULL, 0, 0); // 現在バーの終値（未確定）
// ✅ 安全なコード（shift=1で確定済みバーを参照）
double rsi = iRSI(NULL, 0, 14, PRICE_CLOSE, 1); // 直前の確定バーのRSI
double close = iClose(NULL, 0, 1); // 直前の確定バーの終値インジケーターのバッファも同様です。[0]は現在バー（未確定）、
バグ2：OrderSendの戻り値チェック漏れ
// ❌ 危険（注文失敗を検知できない）
OrderSend(Symbol(), OP_BUY, 0.1, Ask, 3, 0, 0, "EA", 12345, 0, clrBlue);
// ✅ 安全（戻り値を確認してエラー処理）
int ticket = OrderSend(Symbol(), OP_BUY, 0.1, Ask, 3, stopLoss, takeProfit, "EA", 12345, 0, clrBlue);
if (ticket < 0) {
int error = GetLastError();
Print("OrderSend失敗: エラーコード ", error);
}バグ3：マジックナンバーなし（他EAのポジションを誤操作）
マジックナンバーがないと、同一口座で複数のEAを動かしたとき、別のEAが建てたポジションを誤って操作してしまいます。
// ❌ 危険（すべてのポジションを対象にしてしまう）
for (int i = 0; i < OrdersTotal(); i++) {
if (OrderSelect(i, SELECT_BY_POS)) {
OrderClose(OrderTicket(), OrderLots(), Bid, 3, clrRed);
}
}
// ✅ 安全（マジックナンバーと通貨ペアでフィルタリング）
int magicNumber = 20260101; // ユニークな番号を設定
for (int i = OrdersTotal() - 1; i >= 0; i--) {
if (OrderSelect(i, SELECT_BY_POS, MODE_TRADES)) {
if (OrderMagicNumber() == magicNumber && OrderSymbol() == Symbol()) {
OrderClose(OrderTicket(), OrderLots(), Bid, 3, clrRed);
}
}
}バグ4：OrdersTotal()のループ方向エラー
OrdersTotal()のループ中にOrderClose()を実行するとインデックスがずれます。ループは必ず逆方向（大きい数から小さい数へ）で行ってください。
// ❌ 危険（順方向ループ中のClose処理でインデックスずれが発生）
for (int i = 0; i < OrdersTotal(); i++) { ... }
// ✅ 安全（逆方向ループ）
for (int i = OrdersTotal() - 1; i >= 0; i--) { ... }バグ5：OnInit内での市場データアクセス
OnInit()はEA起動時（ティック受信前）に実行されるため、価格・ATRなどの市場データが確定していない場合があります。
// ❌ 危険（OnInit内での市場データへのアクセス）
int OnInit() {
double price = Ask; // ティックなしでは不安定
double atr = iATR(NULL, 0, 14, 0); // 初期化前のデータ
return INIT_SUCCEEDED;
}
// ✅ 安全（初回ティックでフラグを立てて初期化）
bool initialized = false;
int OnInit() {
initialized = false;
return INIT_SUCCEEDED;
}
void OnTick() {
if (!initialized) {
// ここで市場データを使った初期化処理
initialized = true;
}
// メインロジック
}バグ6：NormalizeDoubleなしの価格・ロット計算
価格やロット数を計算したとき、浮動小数点の誤差によってブローカーの最小ステップに合わない値になることがあります。
// ✅ 価格の正規化（Digits桁に合わせる）
double sl = NormalizeDouble(Ask - stopLossPips * Point, Digits);
double tp = NormalizeDouble(Ask + takeProfitPips * Point, Digits);
// ✅ ロット数の正規化（0.01単位）
double lots = NormalizeDouble(riskAmount / (stopLossPips * pipValue), 2);バグ7：リペイントするインジケーターの使用
一部のインジケーターは、バーが確定すると過去の値を書き換えます（リペイント）。バックテストでは書き換え後の「きれいな」値を見るため高成績に見えますが、リアルタイムでは書き換え前の値でトレードするため実際の動作と一致しません。ZigZag系・一部のシグナル系インジケーターは特に注意が必要です。
バックテスト前の品質チェックリスト
AIが生成したEAのコードをバックテストにかける前に、以下のチェックリストで確認してください。
| チェック項目 | 確認方法 |
|---|---|
| shift=0の使用箇所がない | メタエディターで「, 0」を検索して未来参照を排除 |
| OrderSend/Close/Modifyの戻り値を確認している | すべての注文関数に戻り値チェックとエラー処理がある |
| マジックナンバーが設定されている | 注文時とポジション操作時にマジックナンバーでフィルタリング |
| OrdersTotal()ループが逆方向になっている | Close/Delete処理を含むループは i = OrdersTotal()-1 から始まっている |
| OnInit内に市場データへのアクセスがない | Ask/Bid/ATR等の参照がOnTick内に移されている |
| NormalizeDoubleで価格・ロットを正規化している | OrderSendに渡す価格・ロット計算にNormalizeDoubleが適用されている |
| コンパイルエラー・警告がゼロ | メタエディターのコンパイル後「0エラー、0警告」を確認 |
| リペイントするインジケーターを使用していない | ZigZag・一部シグナル系インジケーターを使っていないか確認 |
フォワードテストで実運用前の最終確認
バックテストとウォークフォワードテストを通過したEAでも、必ずフォワードテスト（デモ口座での実運用確認）を行ってから本番投入してください。
| テストの種類 | 目的 | 推奨期間 |
|---|---|---|
| バックテスト | 過去データでの戦略有効性確認 | 上記参照 |
| ウォークフォワードテスト | オーバーフィッティングの検出 | バックテストと同時実施 |
| フォワードテスト（デモ） | 実リアルタイムの動作確認・最終検証 | 最低1ヶ月、理想3ヶ月以上 |
| 少額本番 | 実口座での約定・スプレッドの確認 | フォワードテスト後に段階的に |
デモ口座と本番口座の主な乖離要因：スプレッドの差（デモは狭い固定スプレッドが多い）、約定の遅延・リクオート（本番でのみ発生）、ストップレベルの差（本番では最小SL距離が大きい場合あり）。デモで機能しても本番で乖離する可能性があるため、本番移行は少額から段階的に行うことをお勧めします。
まとめ：バックテストの信頼性を高める7つのポイント
- データ品質を確保する：Tickstory + Dukascopyデータでモデリング品質99%以上を達成する
- スプレッドを保守的に設定する：実際の平均スプレッドの1.5〜2倍で設定する
- 十分な取引数を確保する：最低100回、理想200〜300回以上のトレード数
- 未来参照を徹底的に排除する：shift=0の使用箇所をすべてshift=1に修正する
- ウォークフォワードテストを実施する：WFE 0.5以上を確認してから実運用を検討する
- 複数の期間・通貨ペアで検証する：1つの条件だけで高成績でも過剰適合の可能性がある
- デモで最低1ヶ月フォワードテストを行う：バックテストと実運用の乖離を事前に確認する
AIを活用すれば、EAのコード生成は大幅に速くなりました。しかし「速く作れる」からこそ、バックテストの工程を省かずに丁寧に評価することが重要です。正しいバックテストプロセスを身につければ、実運用に耐えるEAと欠陥EAを明確に区別できるようになります。
EAのコード生成方法については「AIを使ったMT4ツールの作り方【2026年版】」で詳しく解説しています。合わせてご覧ください。
