カテゴリー: EA開発

EAの設計・要件定義・開発に関する記事

  • 【無料EA公開】ドンチャンブレイクアウトのMQL4ソースコードと検証結果

    「無料で使えるEAのソースコードを全文公開します」。ただし、正直に言っておきたいことがあります。このEAをそのまま実運用に投入すれば、おそらく損をします。それでも公開する理由は、EAの中身がどう動いているかを透明に見せたほうが、ブラックボックスの有料EAよりも役に立つと考えているからです。

    本記事では、ドンチャンブレイクアウトという古典的なトレンドフォロー手法をMQL4で実装したミニEAのソースコードを全文掲載します。さらに、Pythonで模擬データを使ったバックテストを行い、期待値・プロフィットファクター・t値などの統計指標を正直に示します。「勝つEA」を売り込む記事ではありません。「どう検証するか」を示す記事です。

    ドンチャンブレイクアウトとは

    ドンチャンブレイクアウトは、過去N日間の最高値を上に抜けたら買い、最安値を下に抜けたら売り、というシンプルなルールです。1960年代にリチャード・ドンチャンが体系化した、世界最古クラスのシステムトレード手法です。

    トレンドが続いているときは利益を乗せやすく、レンジ相場ではダマシに何度も刺されるという特徴があります。ロジックが単純な分、何が起きているかを自分の目で確認しやすく、EAの学習教材として最適です。

    EAの仕様

    • エントリー: 1本前の足の終値が、その前20本の最高値(最安値)を突破したとき
    • 損切り: ATR(14)の2倍の距離にストップを設置
    • 決済: ストップアウトのみ(利確はトレーリングストップで追跡)
    • トレーリング: 30pips以上の利益で10pips幅のストップに追跡開始
    • ポジション: 1ポジション方式(保有中は新規エントリーしない)
    • タイムフレーム: 日足推奨(任意の時間足で動作)

    MQL4ソースコード(全文)

    以下がコンパイル可能な完全なソースコードです。MT4のMetaEditorに貼り付けてコンパイルすれば、すぐにテストできます。

    //+——————————————————————+
    //| DonchianBreakout.mq4 |
    //| rehav trading system |
    //| 無料公開用サンプルEA – ドンチャンブレイクアウト |
    //+——————————————————————+
    #property copyright "rehav trading system"
    #property link "https://www.rehavtrading.com"
    #property version "1.01"
    #property strict

    //— 入力パラメータ
    input int ChannelPeriod = 20; // チャネル期間(高値・安値の参照本数)
    input int ATRPeriod = 14; // ATR期間
    input double ATRMultiplier = 2.0; // SLのATR倍率
    input double Lots = 0.01; // ロットサイズ
    input int MagicNumber = 20260918; // マジックナンバー
    input int Slippage = 3; // 許容スリッページ(ポイント)
    input bool UseTrailingStop = true; // トレーリングストップ有無
    input int TrailStartPips = 30; // トレーリング開始利益(pips)
    input int TrailStepPips = 10; // トレーリング幅(pips)

    //— グローバル変数
    double gPipPoint;

    //+——————————————————————+
    //| 初期化関数 |
    //+——————————————————————+
    int OnInit()
    {
    if(Digits == 3 || Digits == 5)
    gPipPoint = Point * 10.0;
    else
    gPipPoint = Point;

    Print("DonchianBreakout EA 初期化完了。チャネル期間=", ChannelPeriod,
    " ATR倍率=", ATRMultiplier, " ロット=", Lots);
    return(INIT_SUCCEEDED);
    }

    //+——————————————————————+
    //| 終了関数 |
    //+——————————————————————+
    void OnDeinit(const int reason)
    {
    Print("DonchianBreakout EA 終了。理由=", reason);
    }

    //+——————————————————————+
    //| OnTick – 毎ティック実行 |
    //+——————————————————————+
    void OnTick()
    {
    // — 既存ポジションの管理 —
    ManagePositions();

    // — 新規エントリー判定(新しい足の始値のみ) —
    if(!IsNewBar())
    return;

    // シグナル判定
    int signal = CheckSignal();
    if(signal == 0)
    return;

    // 既存ポジションがあればエントリーしない(1ポジション方式)
    if(HasOpenPosition())
    return;

    // — エントリー実行 —
    double atr = GetATR();
    double slDistance = atr * ATRMultiplier;

    if(signal == 1) // 買いシグナル
    {
    double price = Ask;
    double sl = price – slDistance;
    int ticket = OrderSend(Symbol(), OP_BUY, Lots, price, Slippage,
    sl, 0, "DonchianBuy", MagicNumber, 0, clrBlue);
    if(ticket < 0)
    Print("買い注文失敗: ", GetLastError());
    else
    Print("買いエントリー: ticket=", ticket, " price=", price, " SL=", sl);
    }
    else if(signal == -1) // 売りシグナル
    {
    double price = Bid;
    double sl = price + slDistance;
    int ticket = OrderSend(Symbol(), OP_SELL, Lots, price, Slippage,
    sl, 0, "DonchianSell", MagicNumber, 0, clrRed);
    if(ticket < 0)
    Print("売り注文失敗: ", GetLastError());
    else
    Print("売りエントリー: ticket=", ticket, " price=", price, " SL=", sl);
    }
    }

    //+——————————————————————+
    //| 新しい足かどうかの判定 |
    //+——————————————————————+
    bool IsNewBar()
    {
    static datetime lastBarTime = 0;
    datetime currentBarTime = iTime(Symbol(), Period(), 0);
    if(currentBarTime != lastBarTime)
    {
    lastBarTime = currentBarTime;
    return true;
    }
    return false;
    }

    //+——————————————————————+
    //| ドンチャンブレイクアウトのシグナル判定 |
    //| 1本前の足の終値が、その前N本の高値(安値)を突破したかを判定 |
    //| 戻り値: 1=買い, -1=売り, 0=シグナルなし |
    //+——————————————————————+
    int CheckSignal()
    {
    // bar1の終値
    double prevClose = iClose(Symbol(), Period(), 1);

    // bar2〜bar(N+1)の最高値・最安値(直前のN本、bar1は除外)
    int highIdx = iHighest(Symbol(), Period(), MODE_HIGH, ChannelPeriod, 2);
    int lowIdx = iLowest(Symbol(), Period(), MODE_LOW, ChannelPeriod, 2);
    double highest = iHigh(Symbol(), Period(), highIdx);
    double lowest = iLow(Symbol(), Period(), lowIdx);

    if(prevClose > highest)
    return 1;
    else if(prevClose < lowest)
    return -1;

    return 0;
    }

    //+——————————————————————+
    //| ATRの取得 |
    //+——————————————————————+
    double GetATR()
    {
    return iATR(Symbol(), Period(), ATRPeriod, 1);
    }

    //+——————————————————————+
    //| オープンポジションの有無 |
    //+——————————————————————+
    bool HasOpenPosition()
    {
    for(int i = OrdersTotal() – 1; i >= 0; i–)
    {
    if(OrderSelect(i, SELECT_BY_POS, MODE_TRADES))
    {
    if(OrderSymbol() == Symbol() && OrderMagicNumber() == MagicNumber)
    return true;
    }
    }
    return false;
    }

    //+——————————————————————+
    //| ポジション管理(トレーリングストップ) |
    //+——————————————————————+
    void ManagePositions()
    {
    if(!UseTrailingStop)
    return;

    for(int i = OrdersTotal() – 1; i >= 0; i–)
    {
    if(!OrderSelect(i, SELECT_BY_POS, MODE_TRADES))
    continue;
    if(OrderSymbol() != Symbol() || OrderMagicNumber() != MagicNumber)
    continue;

    double trailStart = TrailStartPips * gPipPoint;
    double trailStep = TrailStepPips * gPipPoint;

    if(OrderType() == OP_BUY)
    {
    if(Bid – OrderOpenPrice() >= trailStart)
    {
    double newSL = Bid – trailStep;
    if(newSL > OrderStopLoss() || OrderStopLoss() == 0)
    {
    if(!OrderModify(OrderTicket(), OrderOpenPrice(), newSL, 0, 0, clrBlue))
    Print("トレーリング変更失敗(Buy): ", GetLastError());
    }
    }
    }
    else if(OrderType() == OP_SELL)
    {
    if(OrderOpenPrice() – Ask >= trailStart)
    {
    double newSL = Ask + trailStep;
    if(newSL < OrderStopLoss() || OrderStopLoss() == 0)
    {
    if(!OrderModify(OrderTicket(), OrderOpenPrice(), newSL, 0, 0, clrRed))
    Print("トレーリング変更失敗(Sell): ", GetLastError());
    }
    }
    }
    }
    }
    //+——————————————————————+

    バックテスト結果(2つの市場環境で比較)

    実ティックデータが入手できないため、Pythonで幾何ブラウン運動(GBM)による模擬的な日足データを2,520本(約10年分)生成し、EAと同じロジックでトレードを再現しました。これは実口座での利益を保証するものではありません。ロジックの妥当性を統計的に確認するのが目的です。

    2つのシナリオを比較しました:

    • パターンA(ランダムウォーク): トレンドのない市場。価格は純粋なランダムウォーク。
    • パターンB(レジーム混合): 250日ごとに「上昇トレンド」「レンジ」「下降トレンド」が交代する市場。現実のFX相場に近い構造。

    検証結果サマリー

    指標 パターンA(トレンドなし) パターンB(レジーム混合)
    総トレード数 329 355
    勝率 54.4% 65.9%
    プロフィットファクター 0.84 1.46
    期待値(1トレード) -75円 (-7.5pips) 154円 (15.4pips)
    t値 -1.5 3.22
    最大ドローダウン 36934円 12118円
    平均保有日数 2.2日 2.2日
    総損益 -24517円 54536円

    結果から読み取れること

    パターンA(トレンドなし): 損失

    プロフィットファクター0.84、期待値は1トレードあたり-75円の損失。t値は-1.5で、統計的に有意な損失システムであることを示しています。トレンドのない市場でトレンドフォロー手法を使うと、構造的に損をします。これはバグではなく、手法と市場環境のミスマッチです。

    パターンB(レジーム混合): 利益

    プロフィットファクター1.46、期待値は1トレードあたり154円の利益。t値は3.22で、2.0を超えているため統計的に有意な利益システムと言えます。トレンド期にブレイクアウトで乗せた利益が、レンジ期の損失を上回った結果です。

    つまり、ドンチャンブレイクアウトは「トレンドがあるときにこそ機能する」ことが数字で裏付けられました。トレンドの有無を判定するフィルタを追加すれば、パターンAのような環境での損失を減らせるはずです。

    この検証の限界(正直な注意点)

    • 模擬データを使用: 実際のFX価格データではありません。スプレッド・スワップ・スリッページを含んでいません。これらを含めると結果は悪化します。
    • スプレッド未考慮: 実運用ではエントリー時点ですでにスプレッド分のマイナスからスタートします。特にレンジ期の頻繁なエントリーでは無視できないコストです。
    • 最適化未実施: チャネル期間20・ATR倍率2.0は一般的な値ですが、最適化は行っていません。パラメータの過剰最適化はカーブフィッティングの罠に繋がります。
    • 1通貨ペアのみ: ポートフォリオ効果(複数通貨での分散)は考慮していません。

    これらの限界を理解した上で「それでもこのEAをベースに改良したい」と考えるなら、それがまさにEA開発と監査の価値がある部分です。

    ここからどう改良するか

    このEAをベースに、次のような改良が考えられます:

    • トレンドフィルタの追加: 200日移動平均線の向きでトレンドの有無を判定し、トレンド時のみエントリー
    • スプレッドガード: スプレッドが一定以上のときはエントリーをスキップ(実運用必須)
    • 時間フィルタ: 流動性が低い時間帯のエントリーを回避
    • 複数通貨のポートフォリオ化: 1通貨のレンジ期間を他通貨のトレンドで補う

    これらの改良を設計して実装し、統計的に有意かどうかを検証する。それがEA監査サービスEA作成代行でやっていることです。

    カスタムEAの開発を依頼しませんか?

    この記事のEAは学習用サンプルですが、あなたのトレードロジックをMQL4/MQL5で実装できます。検証しやすいログ仕様を標準装備し、納品後の期待値照合もそのまま行えます。

    ✅ あなたの裁量ルールのEA化

    ✅ 監査済み戦略の実装

    ✅ スプレッドガード・ログ出力など実運用仕様を標準装備

    MT4インジケーターやEAの作成を依頼する(ココナラ) →(納期3営業日以内)

    まずは1,000円のEAクイック診断で、お手持ちのEAの数値診断も可能です。

    まとめ: 透明性が信頼に繋がる

    無料EAを公開して「そのままでは損をする」と正直に書くのは、販売側としては珍しいかもしれません。しかし、EAの価値はロジックの魔法ではなく、検証と改良のプロセスにあります。

    ソースコードを公開し、限界も明記する。その上で「ここをどう直せば良くなるか」を示す。これが、私がEA開発と監査で大切にしている考え方です。

    もしあなたが「動くけど中身が分からないEA」を持っているなら、ぜひ10年データで統計監査にチャレンジしてみてください。数字で見える化すれば、次に何をすべきかが必ず見えます。

    ※ 本記事のバックテストは模擬データによるシミュレーションであり、実取引の結果ではありません。過去の実績が将来の成果を保証するものではありません。

  • EA開発は検証設計で決まる — t値・スプレッド会計・Bid歪みを開発前に組み込む

    EA開発は検証設計で決まる — t値・スプレッド会計・Bid歪みを開発前に組み込む

    「バックテストは完璧だったのに、フォワードで急に負け始めた」
    そんな相談を、これまで何度も受けてきました。

    原因はコードのバグでも、スピード不足でもありません。検証方法を「作った後」に決めていたことです。

    これは仕方のないことです。EAが完成してからバックテストをかけると、人はどうしても「良く見える条件」を後から選んでしまいます。スプレッドを少し狭く。好調な年だけを期間に。取引回数が増えるパラメータだけを採用。どれも不正ではなく、ただの「選択」です。でも、その選択の積み重ねが、実運用で崩れるEAを生みます。

    この記事では、開発のスタートラインで決めておくべき数値を3つだけに絞って解説します。t値・スプレッド会計・Bid歪み。この3つを仕様書に書いてから開発に入るだけで、完成後の後悔をかなり減らせます。

    なぜ「後から検証」では間に合わないのか

    バックテストは、条件を選べる分だけ自由に良く見せられます。

    • スプレッドを現在より狭く設定する
    • 好調な年だけを期間に選ぶ
    • 取引回数が増えるパラメータだけを採用する

    ここに悪意はありません。ただ、先に検証方法を決めていないと、あとから都合の良い条件を選んでしまうのが人間です。開発前に「何をどう検証するか」を文書化しておけば、この後付けの条件選択を構造的に防げます。

    外注する場合はもっとシンプルです。検証設計を発注書に一文書き加えるだけで、納品物の質が変わります。外注前に整理すべき項目は要件定義チェックリストにまとめています。

    検証設計に入れるべき3つの数値

    1. t値 — 「偶然ではない」ことを数字で保証する

    t値は「期待値÷ばらつき」で算出される統計量で、その利益が偶然のブレではないかを判定します。

    目安はシンプルです。取引件数300件以上・t値2.0以上を、設計段階の合格ラインに設定してください。

    期間5年で取引が100件未満のEA — どれだけプロフィットファクターが優秀でも、統計的には「まだ何とも言えない」状態です。年ごとの期待値のばらつき(標準偏差)も合わせて見ることで、「特定の1年だけ稼いだEA」を早い段階でふるい落とせます。

    2. スプレッド会計 — 実測よりやや広めで計算する

    スプレッドは時間帯で変動します。特にロールオーバー(日本時間の朝6〜7時前後)は一時的に拡大します。その時間帯にエントリーするEAを「平均スプレッド」だけで検証すると、実態より有利な数字が出ます。

    設計段階での合格条件はこうです。実測の1.2〜2倍のスプレッドでも利益が残ること

    当サイトの監査実録でも、スプレッドを2倍にしただけで利益が消えるロジックを複数確認しています。これは口座選び以上に、EAの命運を分ける項目です。詳しくはスプレッドとスワップの正直会計で解説しています。

    3. Bid歪み — エントリー時刻の実際の約定価格を疑う

    ヒストリカルデータの多くはBid終値ベースで記録されています。ところがロールオーバー直後の0時台は、Bid価格が一時的に不自然に沈む(または跳ねる)ことがあるのです。その瞬間にエントリーするロジックは、データ上だけ有利に見えてしまいます。

    実際の監査では、特定時刻のエントリーが実コスト比で数pips不利になっていたケースを確認しています。対策はシンプルです。エントリー時刻を、歪みが重なりやすい時間帯からずらして、同じ期待値が出るか再検証すること。時間帯別の分析例は東京時間のドリフト検証で公開しています。

    開発前に決める検証チェックリスト

    この6項目を、そのまま仕様書や発注書に貼ってください。

    項目 合格ラインの例
    テスト期間 5年以上(理想は10年)・複数年で傾向一致
    データ精度 ティック精度99%以上(または実ティック)
    統計性 300取引以上・t値2.0以上
    コスト スプレッド2倍で利益が残る・スワップを含む
    エントリー時刻 ロールオーバー帯のBid歪みを再検証済み
    頑健性 パラメータ±20%で成績が急落しない

    これを開発者と発注者の間で共有するだけで、「検証済み」の基準がぶれなくなります。頑健性の作り方は過剰最適化を防ぐ設計の実践ガイドで詳しく扱っています。

    すでに動いているEAはどうするか

    「もう開発済みだから遅い」と思うかもしれませんが、そんなことはありません。検証設計は後から当てはめることもできます。

    まずはEAが稼がない理由を数字で特定する5つのチェックポイント、または無料のEAセルフチェックシート(20問)で、今の信頼度を自分で点検してみてください。5分で終わります。

    🔧 EAの開発・検証はプロに任せたい方へ

    この記事で紹介した検証設計(t値・スプレッド会計・Bid歪みの確認)を組み込んだ形で、EA・インジケーターの開発を承っています。仕様の段階から検証設計を一緒に決めるので、「動くけど根拠が不明」なEAにはなりません。

    MT4インジケーターやEAの作成を依頼する(ココナラ) →(納期3営業日以内)

    今あるEAが本当に稼げるか先に知りたい方には、EAクイック診断(1,000円・1営業日)。テスト条件そのものを検証するEA監査もご利用いただけます。

    コミュニティの啓発活動の一環として、ドンチャンブレイクアウトの無料EA(ソースコード全文公開)も公開しています。MQL4の学習教材としてご活用ください。

    検証設計は、いわば「EAの信用性を作る工程」です。開発前にかける1時間が、完成後の数千時間の運用と、失う可能性のある資金を守ります。

    まずは上の表を、今あなたが動かしているEA、あるいは今検討しているEAに当てはめてみてください。何個埋まりますか?


  • EAのパラメータ設計で最も失敗しやすい3つのパターン — 過剰最適化を防ぐ実践ガイド

    EAのパラメータ設計で最も失敗しやすい3つのパターン — 過剰最適化を防ぐ実践ガイド

    「バックテストで年利200%を出したはずのEAが、リアル口座に投入した途端に右肩下がりで大切な資金を溶かしていく…」そんな悪夢のような運用失敗に頭を抱えたことはありませんか?実は、トレードロジック自体の不備よりも「パラメータの決め方」で致命的なミスを犯しているケースが後を絶ちません。素晴らしいエントリーロジックであっても、数値設定ひとつでバックテストの成績は天国にも地獄にも化けてしまうのです。

    当サイトの監査現場でも、パラメータ過剰調整による口座破綻のご相談が絶えません。損失回避のためにまず重要なのは、過去データへの過剰適合(カーブフィッティング)の恐怖と仕組みを正しく理解することです。本記事では、EA監査実録で繰り返し見つかった3つの典型的な失敗パターンと、過剰最適化を防ぐ実践的な設計ルールを詳しく解説します。

    前回の「要件定義チェックリスト」では外注前の準備工作を扱いましたが、今回はその先について解説します。具体的には、パラメータをどう設計し、どう検証するかという実装レベルの話題です。

    なぜパラメータ設計だけでEAの命運が分かれてしまうのか?

    EA開発において最も危険な瞬間は、「バックテストの成績があまりにも良すぎた時」です。プロフィットファクター(PF)が2.5を超え、最大ドローダウンが5%未満という美しい右肩上がりのグラフを見たとき、多くの開発者は「ついに聖杯を完成させた」と錯覚してしまいます。しかし当方の監査現場の経験が教えるのは、バックテストが完璧で美しすぎるEAほど、リアル運用で瞬時に崩壊するという恐ろしい現実です。

    その根本的な原因は、「過剰最適化(オーバーフィッティング)」の罠にあります。過去の相場データにパラメータを極限までフィットさせるほど過去成績は跳ね上がりますが、未知の未来相場には一切通用しなくなります。リアル口座の資金を一瞬で失うリスクを避けるには、設計段階から「頑健性(robustness)」を組み込むことが不可欠です。

    失敗パターン1 — なぜ「全通り最適化」はリアル運用で崩壊するのか?

    最も頻出する第1の失敗は、EAに含まれる全パラメータを広範囲で総当り最適化し、最も利益が出た組み合わせをそのまま採用する手法です。例えば、移動平均線の期間を10〜200、ストップロスを20〜100pips、テイクプロフィットを10〜200pipsでそれぞれ1刻みでテストしたと仮定します。この場合、パラメータの組み合わせは数十万通り以上に達し、その中から最高成績の数値を抽出するため、見かけ上は完璧なバックテスト結果が完成します。

    しかし、これは過去相場に存在するランダムなノイズに合わせて無理やり曲線を引いているに過ぎません。市場構造やボラティリティがわずかでも変化した瞬間に期待値はマイナスへ転落し、一気に口座資金を食い潰す結果となります。

    過剰最適化の危険な兆候を「t値」でどう見抜くのか?

    当サイトの監査実録において、ロジックの優位性を判定するコア指標として活用しているのが「t値(t-value)」です。t値とは、トレード群の平均利益が偶然ではなく統計的に有意(実質的な優位性がある)かどうかを示す数値です。一般的にt値が2.0以上であれば、その成績が偶然の産物ではない可能性が高くなります。

    しかし、数十万通りの最適化結果から選ばれた最高点のt値が高くても、それは単に「最も運が良かった数値」を拾い上げただけに過ぎません。当方の監査では、最適点単体だけでなく、その前後左右に位置する「周辺パラメータ」のt値分布を詳細に追跡します。

    最適点の周辺でt値が急激に悪化・低下する場合、その数値はパラメータの僅かなズレで成績が急落する「破局的な崖」の上に立っています。逆に、パラメータを前後にずらしてもt値が2.0前後で安定して推移するならば、その設計はリアル相場でも耐えうる堅牢な構造であると判断できます。

    失敗パターン2 — なぜスプレッドの変動を無視すると期待値が消え去るのか?

    第2の失敗パターンは、バックテスト時にスプレッド(bid-ask spread)を固定値などの楽観的な条件で計算し、パラメータを決定してしまうことです。ここで必須となるのが、リアル運用時の取引コストを正確に織り込む「スプレッド会計」の思想です。

    多くのEA開発者は、バックテストの設定画面で「固定1.0pip」などの理想的なスプレッドを入力して検証を行います。しかし、実際のライブ口座ではスプレッドは常に変動しており、早朝のロールオーバー時や指標発表時には平常時の3〜5倍以上に拡大します。ストップロス(SL)が20pipsのEAにおいてスプレッドが5pips広がれば、実質的なリスクは25pipsに跳ね上がり、想定リスクが25%も増大していることになります。

    バックテストの盲点となる「bid歪み」とは何か?

    さらに見落とされがちな落とし穴として「bid歪み」の問題が挙げられます。MT4/MT5のバックテストではBid価格ベースで計算が進みますが、買いポジションの決済や売りポジションの約定はAsk価格で行われます。このBidとAskの構造的ズレを無視してパラメータを組むと、特に取引回数の多いスキャルピングEAではバックテストとリアル運用で深刻な乖離が発生します。

    当方の監査実録データによると、変動スプレッドとbid歪みを正確に反映して再検証した結果、バックテスト上でプロフィットファクター1.8を誇っていたEAが1.2まで急落した事例が多数存在します。PF1.2であれば耐えられますが、最悪のケースではPF1.0を割り込み、運用した瞬間に損失を生み出す「期待値マイナスのEA」であったことが露呈します。

    失敗パターン3 — なぜ隠れコストを排除した「正直会計」が必要なのか?

    第3の失敗パターンは、トレードにかかる全コストを誤魔化さずに計上する「正直会計」の欠如です。バックテストでいくら利益が出ていても、リアル運用で発生する実コストを排除していては資金を守ることはできません。正直会計で必須となるコスト要素は以下の通りです。

    • スプレッド(早朝や指標発表時の広がりを含む変動スプレッド)
    • 外付け取引手数料(往復7〜10ドル/ロット相当のコスト)
    • スワップポイント(日をまたいでポジションを保有する際の金利差調整額)
    • スリッページ(発注価格と約定価格の間に生じる不可避な価格ズレ)

    これらの隠れコストを差し引いた純利益(net pips / net R)でパラメータを評価しない限り、リアル運用の成績はバックテストを確実に下回ります。当サイトの監査現場で最も多い指摘事項も、「スワップコストの無視」や「スリッページ0設定」であり、これらはパラメータ設計の段階で修正すべき重大な欠陥です。

    特にスワップポイントは、数日〜数週間保有するスイング系EAにおいて無視できない固定費用となります。週末をまたぐトリプルスワップなどで数pips分の利益が吹き飛ぶことも珍しくありません。スワップを無視したパラメータ設計は、「金利ゼロで無限に資金を借りられる」という現実離れした妄想の上で運用しているのと同じ状態なのです。

    過剰適合を防ぐ!正しいパラメータ設計の4ステップとは?

    上記の失敗パターンを回避し、リアル相場でも安定した利益を生み出すための正しいパラメータ設計手順をまとめました。当方の監査業務でも推奨している標準手順は以下の4ステップです。

    • 1. 最適化範囲を論理的に絞り込む:全パラメータの同時最適化を避け、インジケーターの計算根拠に基づき「意味のある範囲(例:短期MAなら3〜50、長期MAなら50〜200)」に限定してテストします。
    • 2. Walk-Forward分析(フォワード検証)を行う:ヒストリカルデータを「学習期間」と「検証期間」に分割し、学習期間で導いたパラメータが未知の検証期間でも機能するかを期間をずらしながら検証します。
    • 3. 周辺パラメータの分布で堅牢性(robustness)を判定する:決定した数値の前後(±10%〜20%)にズラした際、t値やプロフィットファクターが急落せず平坦な高水準を維持できるか確認します。
    • 4. 正直会計で純期待値(net)を再計算する:変動スプレッド・手数料・スワップ・スリッページを全計上した上で、1トレードあたりの純期待値が明確にプラスであることを実証します。

    これら4つのステップを愚直に実行することこそが、大切な資産を相場の波から守り抜く唯一の道筋となります。

    まとめ:あなたのEAは本当にリアル相場に耐えられますか?

    EA運用の成否を決めるのは、華やかなエントリーロジックの凄さではなく、パラメータ設計と検証における「誠実さ」です。全通り最適化の甘い誘惑を捨て、正直会計でリアルな取引コストを計上し、周辺パラメータで頑健性を証明する。この基本原則を徹底するだけで、リアル口座で資金を溶かすリスクを劇的に低減させることができます。

    あなたが現在運用しているEAや開発中のパラメータは、本当に過剰適合の罠をクリアできていますか?少しでも数値の信頼性に不安を感じたなら、一度立ち止まって設定を見直してみることを強くおすすめします。

    当方のEA監査サービスでは、これらの高度な統計検証手法を用いてパラメータの健全性を徹底的に診断しています。大切な自己資金を投入する前に、第三者の客観的な数字でリスクを洗い出してみませんか?


    関連記事

    🔧 EA開発・パラメータ設計でお困りではありませんか?

    当方では、FX EAの開発代行およびパラメータ設計の検証を承っております。過剰最適化を防ぐ設計ルールの適用、Walk-Forward分析、正直会計に基づく期待値検証まで、実運用で機能するEAを3営業日以内でお納めします。

    EA作成代行サービス(coconala)

    EA監査サービス(coconala) — 既存EAの過剰最適化チェック・期待値検証初回限定3,000円(通常5,000円) / まずは1,000円のEAクイック診断

    なお、稼がない原因を上から順に数字で切り分ける手順は、EAが稼がない理由を数字で特定する5つのチェックポイントでまとめています。パラメータ以外に原因がある場合の診断にも使えます。


  • EA作成を外注する前の要件定義チェックリスト — 失敗しない7項目

    EA作成を外注する前の要件定義チェックリスト — 失敗しない7項目

    「月利◯%で放置して稼げる勝てるEAを作ってください」— ココナラなどでEA作成を外注する際、実はこれが最も失敗しやすい危険な依頼文です。「プロに頼めば良い感じに作ってくれるだろう」と丸投げした結果、納品されたのはバックテストすらまともに動かない欠陥プログラムだった…というトラブルが後を絶ちません。

    なぜこのような失敗が起きるのでしょうか?開発者は相場の予言者ではなくプログラマーだからです。検証されていない曖昧なロジックを丸投げされると、開発側は「それっぽく動作するシステム」を作るしかなく、期待値の裏付けがないEAが完成してしまうのです。

    貴重なお金と開発期間を無駄にするリスクを回避するために、外注前の要件定義で必ず決めておくべき7つのチェックリストをまとめました。

    外注トラブルを防ぐ!発注前に確定すべき7つの要件定義リスト

    開発者との認識ギャップを防ぎ、意図通りの動作を実現するために、発注前に以下の7項目を文章化しておきましょう。

    • 1. 対象通貨ペアと時間足: 稼働させるシンボルと時間足を明確に指定します。複数ペア運用の場合はマジックナンバーの分離方針も併せて定義します。
    • 2. エントリー条件と発生頻度: 時刻ベースの固定エントリーか、インジケーター等のシグナル判定か。エントリーのタイミングと想定頻度を正確に取り決めます。
    • 3. SL/TP(損切り・利益確定)の計算基準: 固定pipsで指定するのか、ボラティリティ(ATR等)基準か。最小値の設定やTP未設定(SLのみ)の可否も明記します。
    • 4. マジックナンバーによる個別管理: 1つの口座内で複数のEAや複数通貨ペアを同時運用する場合、注文の混同を防止するために必須となる仕様です。
    • 5. スプレッドガードの設置: エントリー時刻のスプレッドが設定値を超えた場合、当日のトレードを自動送信スキップする機能です。スプレッド感度の高いEAには欠かせません。
    • 6. 詳細なログ出力機能: 注文が通った瞬間の実効スプレッド・約定価格・損益を毎日ログに残す仕様です。運用開始後の期待値照合を行うために最も重要な項目と言えます。
    • 7. ソースコード(.mq4/.mq5)納品の有無: 納品物が実行ファイル(.ex4/.ex5)のみか、ソースコードも含まれるか。将来のロジック改修や第三者による統計監査の可否を左右します。

    なぜ「監査→設計→実装」の順番が安全なのか?

    開発者にロジックを完全丸投げするのではなく、統計的に優位性が実在する現象(例: 特定時間帯の価格アノマリー)を出発点に設計することで、期待値の見通しは劇的に向上します。

    もしすでに手元にアイデアや既存EAがあるなら、いきなり新規開発を発注するのではなく、まずは統計監査で期待値を確定させることが資産を守る鉄則です。

    その上で判明した課題を設計に落とし込み、実装へ進む流れこそが、無駄な開発費用と資金消失を防ぐ最も安全な手順となります。

    納品後に必ず実行すべき「期待値の答え合わせ」

    無事にプログラムが納品されたら、いきなりリアル口座で稼働させるのではなく、以下の検証プロセスを必ず実行してください。

    • バックテストでの再現性確認: 指定した条件通りにトレードが再現されるか、ストラテジーテスターでチェックする
    • デモ口座での期待値照合: 実運用ログ(項目6の仕様)を出力させ、1ヶ月のデモ稼働で検証値と整合しているか数字で確認する

    この照合を行うことで、今回の外注開発が成功だったのかを客観的な数字で判定できます。

    なお、当ブログの運営体制では、事前の要件定義サポートから開発・監査まで3営業日以内で柔軟に対応可能です。

    📦 EAの作成・監査を承っています

    このブログの運営者は、EAの統計監査(ソースコード不要・ex4のみで可能)とEA作成代行(MQL4/MQL5)をココナラで承っています。いずれも納期は3営業日以内です。

    ライト監査は初回限定3,000円(通常5,000円)です。

    EA監査サービス → | まずは1,000円のEAクイック診断EA作成代行 →

    関連記事: EAのバックテストはこう読む — 見抜く3つの数字 / EA運用は口座で決まる — 正直会計の考え方