FXトレンドフォローEAの設計入門｜初心者がMQL5で自動売買を作る手順

最終更新: 2026年07月

トレンドフォローは、FX自動売買の中で最もシンプルかつ理解しやすい戦略だ。移動平均線のゴールデンクロスで買い、デッドクロスで売る——この原始的なロジックをMQL5でコード化するだけで、24時間稼働するEAが完成する。しかし「シンプルだから簡単」は大きな誤解だ。リペイントを引き起こすコードの書き方、iMA()ハンドルの誤用、バックテスト過最適化の罠——初心者が陥るポイントは実装の細部に潜んでいる。本稿では、アルゴリズム取引ファンドで培った経験をもとに、リペイント回避コードや重複発注防止の実装まで、SERP上位記事には載っていない技術的詳細を含めて解説する。なお、自動売買はリスクも自動化する。EA稼働による損失は自己責任となることを最初に明記しておく。

1. トレンドフォローEAとは何か

トレンドフォローEAとは、移動平均線のクロスなどのテクニカル指標をシグナルとして、FX相場のトレンド方向へ自動でエントリー・エグジットを実行するMQL5プログラムのことだ。設計ロジックがシンプルなためEA入門として広く使われるが、リペイント回避・重複発注防止という実装上の落とし穴が初心者を悩ませる。

なぜトレンドフォロー戦略をEA化するのか

FXの売買戦略は大きく「トレンドフォロー（順張り）」と「逆張り」に分類される。トレンドフォローはその名の通り、相場の方向性に乗って利益を狙う手法だ。

EAとして実装するメリットは明確だ。人間が感情に左右されてルールを破ることを、コードは絶対にしない。エントリー条件をコードで定義してしまえば、深夜でも週明けのギャップでも、設定したルール通りに機能する。特にトレンドフォロー戦略は「クロスが発生したらエントリー」という判定ロジックが単純なため、EA化に最も適した戦略カテゴリーの一つだと言える。

ただし、EAはリスクも自動化する。稼働させるだけで利益が保証されるわけではなく、設計上のミスやパラメータ選択の誤りが損失を拡大させることもある。この前提は常に念頭に置いておきたい。

ゴールデンクロス/デッドクロス戦略の基本

移動平均線のクロス戦略は、2本の移動平均線（短期・長期）の交差をトレンド転換のシグナルとして使う。

• ゴールデンクロス（GC）: 短期MAが長期MAを下から上に突き抜ける → 上昇トレンド発生 → 買いエントリー
• デッドクロス（DC）: 短期MAが長期MAを上から下に突き抜ける → 下降トレンド発生 → 売りエントリー

直感的には「価格が上昇し始めたら買う」という単純なルールだ。数理的には、短期MAが長期MAを上回った瞬間は、短期の平均取得コストが長期の平均取得コストを上回ったことを意味する。市場参加者全体の平均コストが上昇局面に転じたというシグナルとして解釈できる。

sys-tre.comのデータによれば、順張りEAの典型的な勝率は40〜60%の範囲が正常とされる。これは直感に反するかもしれないが、損小利大（リスクリワード比1:1.5〜1:2.0以上）の設計により、勝率が50%を下回っても利益が出る構造になっている（sys-tre.com調べ）。

2. 移動平均線の種類と選択基準

SMA・EMA・LWMAの特性比較（表付き）

MQL5のiMA()関数では、複数種類の移動平均線を指定できる。それぞれの計算方法が異なるため、適したタイムフレームも変わる。

タイムフレーム別の使い分け

**SMA（単純移動平均）**は、直近N本の終値を単純に平均したものだ。計算式はシンプルで解釈しやすいが、最新価格と古い価格を等しく扱うため、トレンド転換への反応はやや遅れる。長期足（日足・週足）ではこの「遅延」が逆にノイズフィルターとして機能し、ダマシシグナルを減らす効果がある。

**EMA（指数移動平均）**は、最新の価格ほど大きい重みを指数的に与える。式にすると EMA_t = α × Price_t + (1-α) × EMA_{t-1} となり、αが大きいほど直近価格への感度が高い。MQL5の MODE_EMA 指定でこれを使える。1時間足・4時間足のスキャルピングからスイングトレードまで最も広く使われる種類だ。

**LWMA（線形加重移動平均）**は、直近価格に線形の重みを付ける。1分・5分・15分以下の短期足で価格の動きに即座に反応させたい場合に有効だが、ノイズも拾いやすくなるためダマシシグナルが増えやすい。初心者はまずEMAから始め、慣れてからLWMAを試すのが現実的な順番だと思う。

3. MQL5でトレンドフォローEAを実装する

EA全体の最小構造（OnInit/OnDeinit/OnTick）

MQL5のEAは3つのイベントハンドラを中心に構成される。

//--- グローバル変数
int fastHandle;  // 短期MAのハンドル
int slowHandle;  // 長期MAのハンドル

input int    FastPeriod = 5;    // 短期MA期間
input int    SlowPeriod = 20;   // 長期MA期間
input double LotSize    = 0.1;  // ロット数

//--- OnInit: EAが起動した時に1回だけ実行される
int OnInit() {
    fastHandle = iMA(_Symbol, _Period, FastPeriod, 0, MODE_EMA, PRICE_CLOSE);
    slowHandle = iMA(_Symbol, _Period, SlowPeriod, 0, MODE_EMA, PRICE_CLOSE);

    if(fastHandle == INVALID_HANDLE || slowHandle == INVALID_HANDLE) {
        Print("MAハンドルの取得に失敗しました コード=", GetLastError());
        return INIT_FAILED;
    }
    return INIT_SUCCEEDED;
}

//--- OnDeinit: EAが停止した時に1回だけ実行される
void OnDeinit(const int reason) {
    IndicatorRelease(fastHandle);
    IndicatorRelease(slowHandle);
}

//--- OnTick: 新しいティック（価格変動）のたびに実行される
void OnTick() {
    // ここにエントリーロジックを記述する（後述）
}

iMA()ハンドルの正しい取得方法

MQL4経験者が最初に戸惑うのがこの構造だ。MQL4では iMA() が直接値を返したが、MQL5では「ハンドル（整数のID）」を返す。実際の数値は別途 CopyBuffer() で取得する必要がある。これがMQL4からMQL5へ移行する際の最大の落とし穴だ。MQL5のMetaEditorセットアップや基本文法から順を追って確認したい場合は、MQL5でFX EAを一から作る実装手順も合わせて参照してほしい。

// OnInit()の中で一度だけ実行する
int fastHandle = iMA(
    _Symbol,     // 通貨ペア（現在のシンボル）
    _Period,     // タイムフレーム（現在の時間軸）
    FastPeriod,  // 移動平均期間
    0,           // シフト（通常0）
    MODE_EMA,    // MA種類（MODE_SMA / MODE_EMA / MODE_LWMA）
    PRICE_CLOSE  // 計算に使う価格（終値）
);

// ハンドルが無効な場合は必ずチェックする
if(fastHandle == INVALID_HANDLE) {
    Print("エラー: iMA()ハンドル取得失敗 コード=", GetLastError());
    return INIT_FAILED;
}

ハンドルは OnInit() で一度取得したら OnTick() の中で毎回 iMA() を呼ぶ必要はない。ハンドルを保持しておき、必要なタイミングで CopyBuffer() を使って値を取得する仕組みだ。

CopyBufferとArraySetAsSeriesの理由

// OnTick()の中で毎回実行する
double fast[], slow[];

// ArraySetAsSeries(true): インデックス[0]が最新バーになるよう設定する
ArraySetAsSeries(fast, true);
ArraySetAsSeries(slow, true);

// CopyBuffer: ハンドルからデータを配列にコピーする
// 引数: ハンドル, バッファ番号(0), 開始位置(0=現在), コピー数, コピー先配列
if(CopyBuffer(fastHandle, 0, 0, 3, fast) < 3) return;  // 3本分コピー
if(CopyBuffer(slowHandle, 0, 0, 3, slow) < 3) return;

ArraySetAsSeries() を true で設定すると、fast[0] が現在形成中のバー、fast[1] が1本前の確定済みバー、fast[2] が2本前の確定済みバーになる。この設定がなければ配列の方向が逆になり、インデックスの解釈が混乱する。

リペイントを防ぐクロス判定ロジック（確定バー参照）

これが本稿で最も強調したい実装ポイントだ。SERP上位の解説記事の多くが明記していない箇所でもある。

// ❌ 間違い: [0]（形成中バー）を参照するとリペイントが発生する
bool goldenCrossWrong = fast[0] > slow[0] && fast[1] <= slow[1];

// ✅ 正しい: [1]と[2]（確定済みバー）だけを使う
bool goldenCross = fast[1] > slow[1] && fast[2] <= slow[2];
bool deadCross   = fast[1] < slow[1] && fast[2] >= slow[2];

なぜ [0] を使うとリペイントが発生するのか。インデックス [0] のバーは現在価格の変動とともに常に更新されている。バックテスト時には「バーが確定した時点の値」が記録されてしまうため、リアルタイムでは存在しなかったシグナルがバックテスト上では発生したように見える。これがバックテストとリアル成績の乖離を引き起こす主因の一つだ。

ゴールデンクロス・デッドクロスエントリーコード

以下がエントリーまでの完全なOnTick()実装だ。

#define MAGIC_NUMBER 20260101

// 自分のEAのポジション数を数える関数（後述のSection 4で詳細解説）
int CountMyPositions() {
    int count = 0;
    for(int i = 0; i < PositionsTotal(); i++) {
        if(PositionGetTicket(i) > 0) {
            if(PositionGetInteger(POSITION_MAGIC) == MAGIC_NUMBER &&
               PositionGetString(POSITION_SYMBOL) == _Symbol)
                count++;
        }
    }
    return count;
}

void OnTick() {
    // --- NewBar検出（バー確定後のみ処理する）---
    static datetime lastBarTime = 0;
    datetime currentBarTime = iTime(_Symbol, _Period, 0);
    if(currentBarTime == lastBarTime) return;
    lastBarTime = currentBarTime;

    // --- MAバッファ取得 ---
    double fast[], slow[];
    ArraySetAsSeries(fast, true);
    ArraySetAsSeries(slow, true);
    if(CopyBuffer(fastHandle, 0, 0, 3, fast) < 3) return;
    if(CopyBuffer(slowHandle, 0, 0, 3, slow) < 3) return;

    // --- クロス判定（確定バー[1][2]を使用） ---
    bool goldenCross = fast[1] > slow[1] && fast[2] <= slow[2];
    bool deadCross   = fast[1] < slow[1] && fast[2] >= slow[2];

    // --- 重複発注チェック ---
    if(CountMyPositions() > 0) return;

    MqlTradeRequest request = {};
    MqlTradeResult  result  = {};

    if(goldenCross) {
        // 買いエントリー
        request.action    = TRADE_ACTION_DEAL;
        request.symbol    = _Symbol;
        request.volume    = LotSize;
        request.type      = ORDER_TYPE_BUY;
        request.price     = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
        request.sl        = 0;   // ストップロスは別途設定推奨
        request.tp        = 0;   // テイクプロフィットは別途設定推奨
        request.magic     = MAGIC_NUMBER;
        request.comment   = "GoldenCross";
        request.deviation = 10;
        OrderSend(request, result);
        if(result.retcode != TRADE_RETCODE_DONE)
            Print("買い注文エラー retcode=", result.retcode);
    }

    if(deadCross) {
        // 売りエントリー
        request.action    = TRADE_ACTION_DEAL;
        request.symbol    = _Symbol;
        request.volume    = LotSize;
        request.type      = ORDER_TYPE_SELL;
        request.price     = SymbolInfoDouble(_Symbol, SYMBOL_BID);
        request.sl        = 0;
        request.tp        = 0;
        request.magic     = MAGIC_NUMBER;
        request.comment   = "DeadCross";
        request.deviation = 10;
        OrderSend(request, result);
        if(result.retcode != TRADE_RETCODE_DONE)
            Print("売り注文エラー retcode=", result.retcode);
    }
}

このコードは意図的にストップロスを省略した最小構造だ。実運用では必ずSLとTPを設定すること。SLなしのEAは予期しない相場急変で口座全損のリスクがある。

Claudeと会話しながらインジケータが作れるHedgrow FXはこちら — MQL5のコード設計やパラメータの壁打ち相手としてAIを活用できる。

4. 設計で絶対に押さえるべき3つのポイント

ポイント1: バー確定後にエントリーする（NewBar検出）

OnTick() は1分間に何十回も呼ばれる。ゴールデンクロスが発生した直後の1分間、何十回もエントリー判定が走れば重複発注のリスクが生まれる。そこで「新しいバーが確定した時だけ処理を実行する」NewBar検出パターンを使う。

// OnTick()の先頭に配置する
static datetime lastBarTime = 0;
datetime currentBarTime = iTime(_Symbol, _Period, 0);
if(currentBarTime == lastBarTime) return;  // 同じバーの2回目以降はスキップ
lastBarTime = currentBarTime;
// ここより下がバー確定後のエントリーロジック

static 変数は関数呼び出し間で値が保持される。lastBarTime に前回処理したバーの開始時刻を記録し、同じバーの2回目以降の OnTick() は即座に return する仕組みだ。シンプルだが効果は絶大で、このパターンを入れるだけでダマシシグナルの重複実行を確実に防げる。

ポイント2: 重複発注を防ぐ（マジックナンバーによるポジション管理）

マジックナンバーはEAが発注した注文を識別するための整数IDだ。同じEAが異なる通貨ペアや同じ口座で複数稼働する場合でも、マジックナンバーで自分のポジションだけを正確に識別できる。

#define MAGIC_NUMBER 20260101

// 自分のEAのポジション数を数える関数
int CountMyPositions() {
    int count = 0;
    for(int i = 0; i < PositionsTotal(); i++) {
        if(PositionGetTicket(i) > 0) {
            if(PositionGetInteger(POSITION_MAGIC) == MAGIC_NUMBER &&
               PositionGetString(POSITION_SYMBOL) == _Symbol) {
                count++;
            }
        }
    }
    return count;
}

エントリーロジックの直前に if(CountMyPositions() > 0) return; を挟むだけで、ポジション保有中は新規エントリーを抑制できる。逆に最大ポジション数を2〜3に増やしたい場合は条件を > 2 に変えるだけだ。この関数をグローバルに定義しておけば、複数のEAファイルにコピーして使い回せる。

ポイント3: エラーハンドリングの基本

OrderSend() は必ずしも成功するとは限らない。スリッページが大きい場合、サーバーの応答遅延、証拠金不足など様々な理由で注文が失敗する。最低限のエラー処理を入れておかないと、EA停止時に原因追跡が困難になる。

// OrderSend後の戻りコードを必ずチェックする
if(result.retcode == TRADE_RETCODE_DONE) {
    Print("注文成功: チケット=", result.order,
          " 約定価格=", result.price,
          " ロット=", result.volume);
} else {
    Print("注文失敗 retcode=", result.retcode,
          " GetLastError=", GetLastError());
    // 主要なretcodeの意味:
    // 10004: 再クォート（価格が変わったので再送信が必要）
    // 10006: 拒否（ブローカー側で注文を拒否）
    // 10014: 無効なボリューム（ロット数が最小・最大範囲外）
    // 10019: 証拠金不足
}

TRADE_RETCODE_DONE（10009）が成功を示す定数だ。失敗時は retcode の数値をMetaQuotes公式ドキュメントで確認する習慣をつけると、デバッグ時間が大幅に短縮できる。EAのログをMetaTrader上のExpertタブで確認することも合わせて覚えておきたい。

5. バックテストで戦略を検証する

ストラテジーテスターの設定（全ティック推奨）

MT5のストラテジーテスターでは「モデル」を選択する箇所がある。

• 全ティック（Every tick based on real ticks）: ブローカーから取得した実際のティックデータを使用。最も精度が高いが時間がかかる
• 全ティック（Every tick）: 1分足から補完生成したティック。全ティック実データより若干精度が下がる
• OHLC（1分足）: 4本値のみ使用。最速だが精度が低く、スキャルピング戦略には不向き

初心者は「全ティック（Every tick）」モードを選択することを推奨する。ブローカーからの実ティックデータ取得は追加の設定が必要なケースが多いため、まずはこのモードで精度と速度のバランスを取る。

バックテスト期間はsys-tre.comの調査によれば最低でも1年以上、可能なら3〜5年が推奨される。また統計的有効性には年間100回以上の取引が必要とされる（sys-tre.com調べ）。期間が短すぎると、たまたま相性の良い相場環境を引いただけの「偶然の好成績」を信頼してしまう危険がある。日足EAで月2〜3回程度しか取引しないような設計では、5年分のデータでも100〜180回にしかならない。取引頻度とバックテスト期間の両方を意識する必要がある。

見るべき指標と合格ライン

プロフィットファクター（PF）は「総利益 ÷ 総損失」で計算する指標だ。PF=1.5は「利益が損失の1.5倍」を意味する。PFが高いほど良いが、2.0を大幅に超えるバックテスト結果は過最適化の疑いがある。バックテスト成績を額面通りに信じず、後述のウォークフォワード分析で検証することが必要だ。PFの合格ラインの考え方や文脈依存の解釈については、FXバックテストのプロフィットファクター基準で詳しく解説している。

ウォークフォワード分析で過最適化を防ぐ

バックテストで最も危険な罠が過最適化（カーブフィッティング）だ。パラメータを特定期間のデータに合わせすぎると、その期間では完璧な成績を出しても、未来の相場では全く機能しないEAができあがる。

ウォークフォワード分析（WFA）はこの問題を検出するための手法だ。

1. インサンプル（IS）期間でパラメータを最適化する
2. アウトオブサンプル（OOS）期間で最適化したパラメータのまま検証する
3. IS期間とOOS期間を時間軸にそってスライドさせながら繰り返す

日足EAの場合、IS期間を4〜5年、OOS期間を1年の比率（4:1〜5:1）が推奨される（OANDA Japan調べ）。

過最適化の定量的な判断基準として、myforex.comの調査では「ウォークフォワード効率≥50%」が目安とされる。またkaigaifx-wiki.co.jpによれば「OOS期間の成績がIS期間の60〜70%以上」であれば過最適化の可能性が低いと判断できる。

この基準を下回るEAは、いくらバックテストのPFが高くても実運用に持ち込むべきではない。WFA効率が30%台のEAはフォワードテスト期間中に急速に成績が悪化する傾向があることも、実装検証の中で繰り返し確認できた。

6. 初心者がハマる典型的なミス5選

ミス1: 全力ロットでいきなり本番稼働

EA設計が完成した直後、「これは勝てる」という確信から最大ロットで本番稼働させてしまうケースが多い。

1トレードあたりのリスクは口座残高の1〜2%以内に収めるのが基本だ（sys-tre.com調べ）。10万円の口座なら1トレード1,000〜2,000円のリスクに相当する。USD/JPYで1pip=100円とすると、50pipsのストップロスで0.02〜0.04ロットが上限になる。

最初の3〜6ヶ月はミニロット（0.01〜0.1）で稼働させ、EAの挙動を実際の相場で確認することを強く推奨する。バックテストでは確認できない「予期しない挙動」は必ず存在する。資金管理はEA設計の一部だ。

ミス2: バックテストPFが高くてもリアルで失敗する理由

MT5のストラテジーテスターが生成するバックテストには構造的な限界がある。技術的な理由を具体的に挙げる。

• バックテストはブローカーが公式に公開しているレートを使うが、実際の過去ティックとは微妙に異なる場合がある
• デフォルトでスプレッドが固定値（例: 20ポイント固定）でシミュレートされる。リアル相場のスプレッドは経済指標発表時に10倍以上に拡大することがある
• スリッページ（注文価格と約定価格のズレ）がバックテストではゼロに近い状態でシミュレートされる
• 大口注文による価格影響（マーケットインパクト）は全く考慮されない

これらの「理想化」が積み重なると、バックテストPF=2.0がリアルではPF=1.1程度に落ちるケースも珍しくない。バックテストはあくまで「過去の仮想成績」であり、将来の利益を保証するものではないことを肝に銘じてほしい。

ミス3: 過最適化（カーブフィッティング）とは

移動平均のパラメータ（期間）をバックテスト上で最も成績が良い値に合わせ込む作業を繰り返すと、過去のデータに「だけ」最適化されたEAができあがる。

判断の目安は「パラメータを±20%変化させても成績が大きく変わらないか」だ。FastPeriod=5が最良でも、4や6に変えると急激に成績が悪化するなら、そのパラメータは相場の本質を捉えていない可能性が高い。パラメータはなるべく少なく（3〜5個以内）、値はキリの良い整数（5, 10, 20, 50, 100）を使うシンプル設計が過最適化を防ぐ最良の処方箋だ。

ミス4: スプレッドとスリッページを無視する

バックテスト設定でスプレッドを「固定0ポイント」や「現在のスプレッド」に設定したまま検証すると、実際より楽観的な結果が出る。

スプレッドは時間帯や市場環境によって変動する。東京時間のドル円は3〜5ポイントが相場だが、流動性が低下する時間帯や経済指標発表直後には50ポイント以上に拡大することもある。バックテスト設定では「現在のスプレッド × 2〜3倍」の固定スプレッドを入力して、悲観的なシナリオでも利益が出るか確認することを推奨する。

ミス5: レンジ相場でもEAを動かし続ける

トレンドフォローEAは、相場がトレンドを形成している時だけ機能する。レンジ（横ばい）相場では、短期MAと長期MAが頻繁に交差してダマシシグナルが連発し、小さな損失が積み重なる。

これを防ぐフィルターとして、ADX（Average Directional Index）をトレンド確認指標として追加する手法がある。ADXが25以上の時だけエントリーを許可する実装が一般的だ。ただしフィルターを追加するほどパラメータ数が増えて過最適化リスクも高まるため、最初はシンプルな設計から始めて段階的に改善することを推奨する。

7. 完成したEAをVPS環境で24時間稼働させる

フォワードテストへの移行基準

バックテスト検証が完了したら、次のステップはフォワードテスト（実際の相場でのデモトレード）だ。

フォワードテストの合格ラインとして、sys-tre.comでは「PF1.3以上・最大DD20%以下・6ヶ月以上」が基準とされる。バックテストの合格ラインより意図的に低く設定されているのは、リアル相場ではバックテストより成績が落ちることを前提にしているためだ。

6ヶ月未満のフォワード期間でリアル稼働に移行する誘惑に駆られることが多い。しかし6ヶ月という期間は、トレンド相場・レンジ相場の両方が含まれる可能性を高めるために最低限必要な時間だ。焦りは最大の敵だと心得てほしい。

VPS運用で得られるメリット

EA（自動売買）を24時間稼働させるには、MT5を起動したままPCを常時電源オンにしておく必要がある。VPS（仮想専用サーバー）を使えばこの問題を解決できる。

VPS運用の主なメリットは4つある。

1. 接続安定性: 家庭用インターネット回線の切断リスクを排除できる
2. 低レイテンシ: ブローカーサーバーと地理的に近いVPSを選べば注文遅延を最小化できる
3. 電力コスト削減: 24時間PCを稼働させるより月額VPS費用の方が安いケースが多い
4. PCのフリーズリスク排除: 家庭用PCの再起動でEAが停止するリスクがなくなる

VPSの選択基準は「ブローカーのサーバーと同じデータセンター（またはネットワーク的に近い場所）」だ。東京に日本法人を持つブローカーなら東京リージョンのVPS、ロンドン拠点なら欧州リージョンを選ぶ。フォワードテストもVPS環境で実施することが望ましい。PC稼働のフォワードテストとVPS稼働のリアル運用では、微妙なレイテンシの差が高頻度取引では影響する場合がある。

まとめ

トレンドフォローEAの設計において、特に強調したい点を整理する。

技術的な核心は3つだ。まず、MQL5のiMA()はMQL4と異なりハンドルを返すため、CopyBuffer() での値取得が必須だ。次に、クロス判定は必ず確定済みバー（[1][2]）を参照してリペイントを回避する。そしてマジックナンバーを使った CountMyPositions() 関数で重複発注を防ぐ。

検証の核心はウォークフォワード分析だ。バックテストのPFだけを信頼するのは危険で、WF効率≥50%（myforex.com基準）かつOOS成績がIS期間の60〜70%以上（kaigaifx-wiki.co.jp基準）を確認してから実運用を検討する。

最後に。自動売買はリスクも自動化することを忘れないでほしい。本稿で解説したコードと手法は学習目的のものであり、特定のEAによる利益を保証するものではない。1トレードあたりのリスクを口座残高の1〜2%以内に抑え、常に資金管理を優先した運用を心がけてほしい。

Claudeと会話しながらインジケータが作れるHedgrow FXはこちら — EA設計からバックテスト分析まで、AIをパートナーにした実装が可能だ。

よくある質問（FAQ）

Q: MQL4で書いたEAをMQL5に移植する時の最大の違いは何ですか？ A: 最大の違いはiMA()などのテクニカル指標関数の仕様変更です。MQL4では iMA() が直接値を返しましたが、MQL5では「ハンドル」を返すため、別途 CopyBuffer() で値を取得する必要があります。注文関数もOrderSend()の引数構造が大きく変わっており、MqlTradeRequest構造体を使う形式になっています。

Q: リペイントしているかどうか、どうやって確認すればいいですか？ A: MT5のビジュアルモード（ストラテジーテスターでVisual Modeにチェック）でバックテストを再生し、シグナルが過去のバーに遡って変化しないか目視確認するのが最も簡単です。コードの中で [0] インデックスを参照している箇所を [1] に修正するだけで大半のリペイント問題は解決します。

Q: 移動平均の期間はどうやって決めればよいですか？ A: 「この数値が正解」という普遍的な答えはありません。短期MA=5〜25、長期MA=20〜200の範囲でウォークフォワード分析を実施し、IS期間で複数のパラメータセットが同程度の成績を示す「安定ゾーン」を探すアプローチが定石です。パラメータを±20%変えても成績が大きく変わらない値を選ぶことが過最適化防止につながります。

Q: バックテスト期間はどのくらい取ればいいですか？ A: sys-tre.comの調査では最低1年以上、可能なら3〜5年が推奨されています。期間だけでなく取引回数も重要で、年間100回未満では統計的有効性が低くなります。日足EAで取引頻度が月2〜3回の場合、3年分でも70〜100回程度にしかならないため、複数の通貨ペアでの検証を合わせて行うことを推奨します（sys-tre.com調べ）。

Q: VPSはどれくらいのスペックが必要ですか？ A: MT5を1〜3個程度のEAで稼働させる場合、CPU1コア・メモリ1GB・ストレージ30GBのエントリープランで問題ないケースが多いです。複数の通貨ペアで複数のEAを同時稼働させる場合はメモリ2〜4GBのプランを選んでください。Windows Server環境を選ぶとMT5のインストールが最もスムーズです。

Q: フォワードテストとバックテストの成績が大きく乖離する場合はどうすべきですか？ A: まずバックテストのスプレッド設定を見直してください。悲観的なスプレッド設定でも乖離が大きい場合は、EAのロジックがその期間の相場に過最適化している可能性があります。最適化期間を変えてウォークフォワード分析を再実施し、OOS成績のIS比率（目標60〜70%以上）を再確認することを推奨します（kaigaifx-wiki.co.jp基準）。

Q: トレンドフォローEAにストップロスは必須ですか？ A: 必須です。ストップロスなしのEAは、予期しない急騰・急落（フラッシュクラッシュ、重大な経済指標ショック）で口座全損のリスクがあります。ストップロスはエントリー価格からの固定pips（例: 50pips）、または直近のスイング安値・高値を参照したATR×2などの動的設定が一般的です。

Q: AIを活用してEA設計を効率化する方法はありますか？ A: MQL5のコード設計やパラメータ選択にAIを活用するアプローチが広まっている。Claudeと会話しながらインジケータが作れるHedgrow FXでは、EAのロジック設計や実装上の疑問をAIに直接問いかけながら作業を進めることができる。ロジックの壁打ち相手としてAIを使いつつ、バックテストとWFAの検証は必ず人間が実施するというハイブリッドアプローチが現実的だ。AIが生成したコードも、MetaTraderのストラテジーテスターで必ず検証すること。

免責事項

本記事は情報提供・教育目的のみで提供されるものです。記事内のコードおよびバックテスト結果は特定の将来パフォーマンスを保証するものではありません。FX取引は元本保証のない高リスク投資であり、証拠金以上の損失が発生する場合があります。EA稼働による取引判断は自己責任で行ってください。投資判断を行う際には、ファイナンシャルアドバイザーへの相談を推奨します。記事内の統計・指標データは出典元のリサーチ結果を引用したものであり、将来の市場動向を予測するものではありません。

著者: アルゴリズム取引ファンド出身の金融工学専門家。MQL5によるEA開発・バックテスト検証・VPS実運用を経験。