MQL5 modular EA designの作り方｜分割設計と実装手順

リファレンス
目次

1. MQL5のモジュラーEA設計とは

1.1 定義（結論）

【結論】モジュラーEA設計とは、売買ロジックを機能ごとに分割し、独立した部品として組み立てる開発手法です。
この構造により、再現性・検証性・拡張性が大幅に向上します。

【定義】モジュラー設計とは、システムを「役割単位（モジュール）」に分解し、それぞれを独立して開発・管理する設計思想です。

MQL5におけるEA（自動売買プログラム）は、従来は1つのファイル（.mq5）にすべてのロジックを詰め込むケースが一般的でした。しかし、この方法では以下の問題が発生します。

  • ロジックが複雑化し、修正が困難になる
  • 特定条件（spreadやslippage）への対応が後付けになりやすい
  • 検証結果の再現性が低下する

モジュラー設計では、例えば以下のように役割を分離します。

  • エントリー条件（例：移動平均クロス）
  • 決済条件（例：利確・損切り）
  • フィルター（例：スプレッド拡大時は停止）
  • 注文処理（execution・order条件）

この分割により、「どのロジックが利益に寄与しているか」を個別に検証できるようになります。

初心者がつまずきやすいポイントとして、「分割しすぎて逆に分かりにくくなる」ケースがあります。
まずは「エントリー」「決済」「フィルター」の3つに分けるだけで十分です。

1.2 なぜモジュラー設計が重要なのか

【結論】EAの収益性は「ロジックの良さ」だけでなく、「検証の正確さ」に依存するため、モジュラー設計が必要になります。

EA開発では、単に勝てるロジックを作るだけでは不十分です。
重要なのは「その結果が再現できるかどうか」です。

例えば以下のようなケースがあります。

  • バックテストでは好成績だが、フォワードで崩れる
  • 特定期間だけ機能する最適化（過剰最適化）
  • spreadやslippageの影響を考慮していない

これらはすべて「ロジックの分離不足」が原因で発生します。

モジュラー設計を採用すると、以下の改善が可能です。

  • フィルター単体で検証できる
  • エントリーだけ差し替えて比較できる
  • execution条件（約定方式）の影響を切り分けられる

つまり、「何が原因で勝ったのか」を分解して検証できるようになります。

特に実務では、以下の要素が収益に大きく影響します。

  • spread（スプレッド：売買価格差）
  • slippage（スリッページ：注文価格ズレ）
  • execution（約定処理の仕組み）

これらを一体化したままでは、正しい評価ができません。

1.3 従来のEA設計との違い

【結論】従来のEAは「1つのロジックに依存する構造」、モジュラー設計は「組み合わせ可能な構造」です。

従来型EA（単一構造）の特徴は以下です。

  • すべてのロジックがOnTick内に集中
  • 条件分岐（if文）が増え続ける
  • 修正時に全体へ影響が出る

一方、モジュラー設計では以下のように変わります。

  • 各機能を別ファイル（.mqh）で管理
  • シンプルなインターフェースで接続
  • 部品単位で交換可能

具体的なイメージは以下です。

// モジュラー構造の例（簡略）
if(FilterCheck() && EntrySignal())
{
    ExecuteOrder();
}

この構造により、例えば以下が簡単に実現できます。

  • エントリーだけ別ロジックに差し替える
  • スプレッドフィルターだけ追加する
  • 特定時間帯のみ無効化する

注意点として、「単一EAの方が速いのでは？」という疑問があります。
実際には、適切に設計すればパフォーマンス差はほぼ無視できるレベルです（環境依存）。

むしろ、保守性・検証性の向上によるメリットの方が圧倒的に大きいです。

2. モジュラーEA設計の全体構造

2.1 基本構成（役割分解）

【結論】モジュラーEAは「エントリー・決済・フィルター・リスク・実行」の5つに分解すると、最も実用的かつ再利用しやすい構造になります。

モジュラー設計では、EAを機能単位に分割します。最も基本的かつ実務で使いやすい分解は以下の通りです。

  • Entry Module（エントリー判定）
    売買シグナルを生成（例：移動平均クロス、RSI条件）
  • Exit Module（決済ロジック）
    利確・損切り・トレーリングストップなど
  • Filter Module（取引フィルター）
    不利な状況を回避（spread拡大・重要指標・時間帯）
  • Risk Module（資金管理）
    ロット計算、最大損失制御
  • Execution Module（注文処理）
    注文送信・slippage許容・約定管理（execution）

この分解により、「どの要素が利益・損失に影響しているか」を個別に検証できます。

初心者のよくある失敗は、「すべてEntryに詰め込む」ことです。
フィルター（例：スプレッド制限）をEntry内に書くと、検証不能になります。

2.2 データフロー（処理の流れ）

【結論】処理順序は「Filter → Entry → Risk → Execution → Exit」に固定すると、ロジックの一貫性が保たれます。

EAはTick（価格更新）ごとに処理されます。モジュラー構造では、以下の順序で処理します。

  1. Filter：取引して良い状態か確認
  2. Entry：エントリー条件を判定
  3. Risk：ロットサイズを計算
  4. Execution：注文を実行
  5. Exit：ポジションの管理・決済

この流れを崩すと、以下の問題が発生します。

  • 無駄な注文（Filter前にEntry判定）
  • ロット異常（Risk未適用）
  • 不正確なバックテスト

シンプルな実装例：

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

    if(EntrySignal())
    {
        double lot = CalculateLot();
        ExecuteOrder(lot);
    }

    ManageExit();
}

重要なのは、「各モジュールは1つの責務のみ持つ」ことです。
例えば、Entryでロット計算をしてはいけません。

2.3 インターフェース設計の考え方

【結論】モジュール間は「シンプルな戻り値」で接続することで、依存関係を最小化できます。

モジュラー設計では、「どう繋ぐか」が最重要です。
基本方針は以下です。

  • 入力：価格データや指標値
  • 出力：boolまたはenum（シンプルな状態）

例：

bool EntrySignal()
{
    return (iMA(NULL,0,10,0,MODE_SMA,PRICE_CLOSE,0) >
            iMA(NULL,0,20,0,MODE_SMA,PRICE_CLOSE,0));
}

このように「true/false」で返すことで、他モジュールと簡単に接続できます。

より発展的には、enumを使います。

enum SignalType
{
    SIGNAL_NONE,
    SIGNAL_BUY,
    SIGNAL_SELL
};

この設計により、以下が可能になります。

  • ロジック差し替えが容易
  • テストの自動化
  • 複数戦略の統合

注意点として、「モジュール間でグローバル変数を共有する」のはNGです。
依存関係が増え、デバッグ不能になります。

2.4 実務で意識すべき設計ポイント

【結論】「拡張前提」で設計しないと、後から必ず作り直しになります。

実務では以下を意識してください。

  • Filterは最優先で独立させる（spread・slippage対策）
  • Riskは必ず独立（資金管理は別軸）
  • Executionはブローカー仕様に依存するため分離

特にexecution（約定処理）は、環境によって大きく変わります。

  • Instant Execution
  • Market Execution
  • ECN環境

これをEntryと混ぜると、移植不能になります。

3. MQL5でのモジュラーEA設計手順

3.1 手順（全体フロー）

【結論】最初は「分解 → 分離 → 接続 → 検証」の4ステップで進めると、初心者でも破綻せず構築できます。

モジュラーEAは以下の手順で構築します。

  • ① ロジックを機能単位に分解する
  • ② 各機能を.mqhファイルとして分離する
  • ③ 共通インターフェースを設計する
  • ④ OnTickで統合する
  • ⑤ テスト・検証を行う

この順番を守る理由は、「後戻りコストを最小化するため」です。
いきなりコードを書くと、後から分離できなくなります。

初心者の失敗パターン：

  • いきなりOnTickに全ロジックを書く
  • 分割せず最適化を始める
  • フィルターを後付けする

まずは「紙に分解を書く」だけでも精度が上がります。

3.2 ディレクトリ構成例

【結論】Includeフォルダにモジュールを分離することで、再利用性と可読性が大きく向上します。

基本構成は以下です。

/MQL5
 ├── Experts/
 │    └── ModularEA.mq5
 └── Include/
      └── Modules/
           ├── Entry.mqh
           ├── Exit.mqh
           ├── Filter.mqh
           ├── Risk.mqh
           └── Execution.mqh

各ファイルの役割：

  • Entry.mqh → エントリー判定のみ
  • Exit.mqh → 決済管理
  • Filter.mqh → spread・時間制御
  • Risk.mqh → ロット計算
  • Execution.mqh → 注文処理

この分離により、「1ファイル＝1責務」が成立します。

注意点：

  • ファイルを細かくしすぎない（最初は3〜5個で十分）
  • 名前は必ず役割ベースにする（例：Logic1.mqhは禁止）

3.3 コード例（最小構成）

【結論】最小構成は「Filter → Entry → Execution」の3つだけで動作します。

まずはシンプルな構成から始めます。

Entryモジュール

// Entry.mqh
bool EntrySignal()
{
    double ma_fast = iMA(NULL,0,10,0,MODE_SMA,PRICE_CLOSE,0);
    double ma_slow = iMA(NULL,0,20,0,MODE_SMA,PRICE_CLOSE,0);

    return (ma_fast > ma_slow);
}

Filterモジュール

// Filter.mqh
bool FilterCheck()
{
    double spread = (Ask - Bid) / _Point;
    return (spread < 20); // スプレッド制限
}

Executionモジュール

// Execution.mqh
void ExecuteOrder(double lot)
{
    MqlTradeRequest request;
    MqlTradeResult result;

    ZeroMemory(request);

    request.action = TRADE_ACTION_DEAL;
    request.symbol = _Symbol;
    request.volume = lot;
    request.type   = ORDER_TYPE_BUY;
    request.price  = Ask;
    request.deviation = 10; // slippage許容

    OrderSend(request, result);
}

メインEA

#include <Modules/Entry.mqh>
#include <Modules/Filter.mqh>
#include <Modules/Execution.mqh>

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

    if(EntrySignal())
    {
        ExecuteOrder(0.1);
    }
}

この形で「最低限のモジュラーEA」が完成します。

3.4 テスト方法（重要）

【結論】モジュール単位で検証しないと、最適化の罠に必ずハマります。

テストは以下の順序で行います。

  • ① 単体テスト（モジュール単位）
  • ② 統合テスト（EA全体）
  • ③ フォワードテスト（リアル環境）

具体例：

  • FilterだけON/OFFして影響を見る
  • Entryだけ差し替えて比較する
  • slippage値を変えて検証する

重要ポイント：

  • バックテスト結果は「仮説」でしかない
  • フォワードテストで崩れるケースは非常に多い

よくある失敗：

  • 最適化だけで完成と判断する
  • spread固定で検証する
  • execution条件を無視する

実務では、Myfxbookなどでフォワード公開することで、データの透明性を確保できます。

4. モジュラー設計が必要な理由

4.1 再現性の担保

【結論】モジュラー設計は「どの要素が結果を生んだか」を分離できるため、再現性を担保できます。

EAの評価で最も重要なのは、「同じ条件で同じ結果が出るか」です。
しかし、単一構造のEAでは以下が混在します。

  • エントリー条件
  • フィルター（spread・時間帯）
  • execution条件（約定方式・slippage）

これらが一体化していると、「勝因」が特定できません。

モジュラー設計では、例えば以下が可能です。

  • Filterを無効化して影響を測定
  • Entryだけ変更して比較
  • slippage設定だけ変えて検証

つまり、結果を構成要素ごとに分解できる状態になります。

再現性が低いEAの典型例：

  • バックテストは良いがフォワードで崩壊
  • パラメータ変更で結果が激変
  • 通貨ペアを変えると機能しない

これらは「分離されていないロジック」に起因します。

4.2 最適化の罠回避

【結論】モジュラー設計は「過剰最適化（オーバーフィッティング）」を構造的に防ぎます。

EA開発では、最適化機能を使ってパラメータを調整することが一般的です。
しかし、以下の問題が発生します。

  • 特定期間にだけ最適化された設定
  • ノイズに適応しただけのロジック
  • 将来再現しない結果

これがいわゆる「最適化の罠」です。

モジュラー設計では、以下のアプローチが可能になります。

  • Entryロジックは固定し、Filterのみ調整
  • Risk管理を別軸で最適化
  • execution条件を独立検証

これにより、「どこまで信じてよいか」の判断が可能になります。

重要な考え方：

  • パラメータではなく「構造」を評価する
  • 汎用性のあるロジックを優先する

初心者の典型的ミス：

  • パラメータ調整だけで勝とうとする
  • フィルターを後付けで最適化する

4.3 市場変化への耐性

【結論】モジュラー設計は「ロジックの差し替え」が容易なため、市場変化に強い構造になります。

市場は常に変化します。

  • ボラティリティの変化
  • スプレッドの拡大
  • 流動性の低下
  • execution環境の変化

単一構造EAでは、これらに対応するには「全体を書き直す」必要があります。

一方、モジュラー設計では以下が可能です。

  • Entryだけ新ロジックに差し替え
  • Filterを追加（例：重要指標回避）
  • Risk管理を強化

つまり、部分的な修正で全体を最適化できる構造です。

実務で重要なポイント：

  • 通貨ペアごとにFilterを変更
  • ブローカーごとにexecutionを調整
  • 市場状況に応じてEntryを差し替え

注意点：

  • モジュール間の依存が強いと意味がない
  • インターフェース設計が崩れると再利用不可

5. 他のEA設計手法との比較

5.1 比較対象となる設計手法

【結論】EA設計は大きく「単一ロジック型」「最適化依存型」「AI型」「モジュラー型」に分類でき、それぞれ強みとリスクが異なります。

代表的な設計手法は以下の通りです。

  • 単一ロジックEA
    1つの売買ルールのみで構成（例：移動平均クロスのみ）
  • パラメータ最適化型EA
    過去データに合わせてパラメータを調整
  • AI・機械学習EA
    データから自動でルール生成（ブラックボックス化しやすい）
  • モジュラーEA設計
    機能ごとに分割し組み合わせる構造

初心者が誤解しやすい点として、「AI＝最強」という認識がありますが、実務では検証性と再現性の問題が大きく、必ずしも優位とは限りません。

5.2 比較軸による整理

【結論】長期運用を前提にする場合、「再現性・拡張性・最適化耐性」でモジュラー設計が優位になります。

以下の観点で比較します。

設計手法再現性拡張性開発コスト最適化耐性実運用適性
単一ロジック低〜中低低低低
最適化型低低中非常に低低
AI型不明（環境依存）中高中不安定
モジュラー型高高中高高

重要ポイント：

  • 単一ロジックはシンプルだが崩れやすい
  • 最適化型は短期的に強く見えるが再現性が低い
  • AI型は検証難易度が高くブラックボックス化しやすい
  • モジュラー型は「検証可能な構造」を持つ

5.3 実務での使い分け

【結論】短期検証は単一ロジック、長期運用はモジュラー設計が合理的です。

用途別の使い分けは以下です。

単一ロジックEAが適するケース

  • ロジック検証の初期段階
  • アイデアの有効性確認
  • 学習目的

最適化型EAが適するケース

  • 限定的な短期運用
  • 特定市場に特化した戦略
    ※ただしリスクは高い

AI型EAが適するケース

  • 大量データを扱う研究用途
  • 特定条件下でのパターン検出
    ※運用には慎重な検証が必要

モジュラー設計が適するケース

  • 長期運用（最重要）
  • 複数戦略の統合
  • フォワードテスト前提の開発

実務で最も重要なのは以下です。

  • 「なぜ勝っているか説明できるか」
  • 「市場が変わっても対応できるか」

この2点を満たすのがモジュラー設計です。

5.4 よくある誤解と注意点

【結論】モジュラー設計は万能ではなく、「設計の質」に依存します。

よくある誤解：

  • 分割すれば勝てる → 誤り
  • モジュール数が多いほど良い → 誤り
  • AIと組み合わせれば無敵 → 不確実

注意点：

  • モジュール間の依存が強いと意味がない
  • インターフェース設計が不十分だと破綻する
  • 検証プロセスを省略すると効果が出ない

つまり、モジュラー設計は「検証可能性を高める手段」であり、利益を保証するものではありません。

6. よくある失敗と注意点

6.1 過剰分割（アンチパターン）

【結論】モジュールは細かくしすぎると逆効果になり、「管理不能な設計」になります。

モジュラー設計の初学者が最もやりがちな失敗が「分割しすぎ」です。

典型例：

  • Entryをさらに細分化（MA用、RSI用、条件別など）
  • Filterを細かく分けすぎる（時間・曜日・spread別など）
  • 1関数＝1ファイルにしてしまう

この結果、以下の問題が発生します。

  • どこで何をしているか分からない
  • 修正時に複数ファイルを横断する必要がある
  • デバッグコストが増大する

適切な粒度は以下です。

  • Entry（1つ）
  • Exit（1つ）
  • Filter（1つ）
  • Risk（1つ）

まずはこの単位から始めるべきです。

判断基準：

  • 「そのモジュール単体でテストできるか」
    →できないなら分割しすぎです。

6.2 インターフェース不統一

【結論】モジュール間の接続仕様がバラバラだと、再利用も拡張もできなくなります。

モジュラー設計では「接続ルール」が重要です。
これが崩れると、単一構造よりも悪化します。

よくある問題：

  • 戻り値の型が統一されていない
  • グローバル変数で値を共有している
  • モジュールが他モジュールに依存している

NG例：

// Entryがグローバル変数を直接操作
double signal;

void EntryCheck()
{
    signal = 1;
}

改善例：

bool EntrySignal()
{
    return true;
}

設計ルール：

  • 戻り値はboolまたはenumで統一
  • 引数で必要なデータを渡す
  • グローバル変数は極力使わない

これにより、「モジュールの独立性」が維持されます。

6.3 フィルター軽視（致命的ミス）

【結論】Filterを軽視すると、バックテストと実運用の乖離が発生し、EAは破綻します。

初心者ほど「エントリー精度」に注目しますが、実務では以下が重要です。

  • spread（スプレッド）
  • slippage（価格ズレ）
  • execution（約定方式）

これらを無視すると、以下の現象が起きます。

  • バックテストでは勝つがリアルで負ける
  • 指標発表時に大損する
  • スプレッド拡大でエントリーが悪化

最低限入れるべきフィルター：

bool FilterCheck()
{
    double spread = (Ask - Bid) / _Point;

    if(spread > 20) return false;   // スプレッド制限
    if(Hour() < 6 || Hour() > 23) return false; // 時間制限

    return true;
}

重要な考え方：

  • 「いつトレードするか」より「いつしないか」が重要

6.4 テスト不足（最も多い失敗）

【結論】バックテストのみで判断すると、高確率で実運用に失敗します。

EA開発で最も多い失敗が「検証不足」です。

典型的な誤り：

  • 最適化結果だけで完成と判断
  • 1期間のバックテストのみ
  • フォワードテストを行わない

正しい検証フロー：

  • ① バックテスト（仮説確認）
  • ② パラメータ変更テスト（安定性確認）
  • ③ フォワードテスト（実環境検証）

特に重要なのがフォワードテストです。

理由：

  • slippageが再現されない
  • execution条件が異なる
  • 市場構造が変化する

実務では、以下の観点で評価します。

  • ドローダウン（DD）
  • プロフィットファクター（PF）
  • 連敗耐性

注意点：

  • デモとリアルでも差が出る
  • ブローカーによって結果が変わる

6.5 モジュール依存の増大

【結論】モジュール同士が依存し始めると、モジュラー設計のメリットは消えます。

悪い設計例：

  • EntryがFilter内部を参照
  • RiskがExecutionに依存
  • モジュール同士が相互参照

この状態になると：

  • 修正が連鎖する
  • テスト不能になる
  • バグが再現しない

対策：

  • 依存は「一方向」に限定する
  • 中央制御（OnTick）でのみ接続する

7. 実務での使いどころ

7.1 EA開発（商用・研究）

【結論】モジュラー設計は「検証の透明性」を確保できるため、商用EA・研究用途の標準構造として有効です。

実務でEAを扱う場合、最も重要なのは「説明可能性」です。
つまり、なぜこのEAが勝っているのかを説明できるかが問われます。

モジュラー設計では以下が可能になります。

  • Entry単体の勝率・期待値を検証
  • Filterの有無による差分分析
  • Risk設定ごとのDD（ドローダウン）比較

例えば：

  • Entryは高勝率だがDDが大きい
    → Riskモジュールで制御
  • Filterを追加するとPF（プロフィットファクター）が改善
    → 実運用に採用

このように、「意思決定の根拠」を構造的に持てるのが強みです。

研究用途ではさらに有効です。

  • 複数ロジックのA/Bテスト
  • 同一条件での比較検証
  • ロジック単位での評価

注意点：

  • モジュール単体の結果だけで判断しない
  • 必ず統合後の挙動も確認する

7.2 ポートフォリオ運用

【結論】モジュラー設計は複数戦略を統合しやすく、ポートフォリオ運用に直結します。

単一EAでは、1つのロジックに依存します。
しかし実務では、以下のような分散が必要です。

  • 通貨ペア分散（EURUSD / USDJPY など）
  • ロジック分散（トレンド / 逆張り）
  • 時間軸分散

モジュラー設計では、以下のように構成できます。

  • EntryA（トレンド系）
  • EntryB（逆張り系）
  • 共通Filter（spread・時間）
  • 共通Risk（資金管理）

この構造により：

  • ロジックごとの成績を比較可能
  • 不調な戦略だけ停止できる
  • 相関の低い組み合わせを構築できる

重要なポイント：

  • 相関管理（同時損失を避ける）
  • DDの合成（ポートフォリオ全体のリスク）

初心者の失敗：

  • ロジックを増やすだけで分散した気になる
    → 実際は同じ市場条件で同時に負けるケースが多い

7.3 EA販売・公開（信頼性の担保）

【結論】モジュラー設計は「ブラックボックス化を回避」できるため、信頼性向上に寄与します。

EAを公開・販売する場合、以下の問題が発生します。

  • 利用者がロジックを理解できない
  • バックテスト結果への不信
  • フォワードとの乖離

モジュラー設計では、以下が可能です。

  • ロジック単位で説明できる
  • フィルターの意図を明示できる
  • 検証データを分解して提示できる

例えば：

  • 「このEAはスプレッド20以下でのみ動作」
  • 「指標発表時は停止する設計」

これらを明確に説明できることで、信用コスト（評判リスク）を低減できます。

また、フォワードテスト公開（例：Myfxbook）と組み合わせることで、

  • 入出金の影響を排除したデータ
  • 裁量なしの純粋な挙動

を示すことができます。

注意点：

  • 説明できないロジックは信頼されない
  • 「勝率」だけでは評価されない

7.4 運用フェーズでの実践ポイント

【結論】モジュラー設計は「改善サイクルを高速化」できるため、継続的な運用に強いです。

実運用では、以下のサイクルを回します。

  • 検証（バックテスト）
  • 実験（フォワード）
  • 分析（原因特定）
  • 改善（モジュール修正）

モジュラー構造では、このサイクルが高速化します。

例：

  • DD増加 → Riskモジュール調整
  • 勝率低下 → Entry差し替え
  • 不安定 → Filter追加

この「部分修正」ができることが最大の価値です。

逆に単一構造では：

  • 全体を書き直す必要がある
  • 修正の影響範囲が不明
  • 検証コストが増大

結果として、改善速度が大きく落ちます。

8. FAQ（よくある質問）

8.1 モジュラーEAは初心者でも作れますか？

【結論】可能ですが、「最小構成（Entry・Filter・Execution）」から始めるのが現実的です。
最初から完全分離を目指すと挫折しやすいため、まずは3モジュール構成で動作させ、徐々に拡張します。

8.2 mqhファイルは必須ですか？

【結論】必須ではありませんが、モジュラー設計を行うなら実質的に必須です。
.mqhを使うことで「機能ごとの分離」と「再利用」が可能になります。1ファイル内で分割することも可能ですが、管理性は大きく劣ります。

8.3 最適化（Optimization）は不要になりますか？

【結論】不要にはなりませんが、「依存度を下げる」のが正しい使い方です。
モジュラー設計では、最適化は補助的に使い、構造（ロジック自体）の優位性を優先します。

8.4 MT4でも同じ設計は可能ですか？

【結論】可能ですが、MQL5の方が構造的に適しています。
MQL5はクラス・構造体・イベント処理が強化されており、モジュラー設計との相性が良いです。MT4でも.mqh分割は可能ですが、拡張性は制限されます。

8.5 フィルターはどこまで必要ですか？

【結論】最低限「spread・時間帯・重要指標」は必須レベルです。
これらを入れないと、バックテストと実運用で結果が乖離します。

目安：

  • spread制限（例：20ポイント以下）
  • 時間制御（流動性の低い時間帯を除外）
  • 指標回避（高ボラティリティ対策）

8.6 AI（機械学習）EAとの違いは何ですか？

【結論】モジュラーEAは「説明可能」、AI EAは「ブラックボックス化しやすい」という違いがあります。
AIは強力ですが、なぜ勝ったか説明しづらく、検証難易度が高い傾向があります。モジュラー設計はその逆です。

8.7 パフォーマンス（処理速度）は落ちませんか？

【結論】通常は問題にならないレベルです。
関数分割によるオーバーヘッドは微小であり、Tick処理において実用上の影響はほぼありません（環境依存）。

8.8 モジュラー設計にすると必ず勝てるようになりますか？

【結論】なりません。モジュラー設計は「検証精度を上げる手段」であり、利益を保証するものではありません。
ただし、再現性・改善速度・リスク管理の観点で優位になるため、長期的な期待値は改善しやすくなります。

9. まとめ（結論）

【結論】モジュラーEA設計は「再現性・拡張性・検証性」を高めるための基盤であり、長期運用を前提とするならほぼ必須の設計です。

本記事の要点は以下です。

  • モジュラー設計は「機能分割」によってEAを構築する手法
  • Entry・Filter・Risk・Executionを分離することで検証精度が向上
  • 最適化ではなく「構造」で優位性を作ることが重要
  • 単一構造や最適化依存型よりも長期運用に適している

実務での判断基準：

  • 再現できるか（フォワードで崩れないか）
  • 分解して説明できるか（勝因の特定）
  • 部分修正で改善できるか（市場変化対応）

推奨アクション：

  • まずは「Entry・Filter・Execution」の3分割でEAを構築
  • フィルター（spread・slippage・時間）を必ず組み込む
  • モジュール単位でテストし、影響を可視化する

重要な認識：

  • モジュラー設計は「勝つための魔法」ではない
  • しかし「負けにくくする構造」は作れる

この設計を採用することで、
「偶然勝つEA」から「再現できるEA」へ移行できます。