rehav trading system

タグ: EA

  • EAの利益は実力か偶然か — t値でエッジを検定する監査実録

    EAの利益は実力か偶然か — t値でエッジを検定する監査実録

    「PF1.9で勝率68%です。これ、実力ですよね?」——監査の相談で、僕が最初に開く数字はPFでも勝率でもありません。取引回数と、利益のばらつきです。

    なぜなら、バックテストの利益には「たまたまプラスだった」という可能性が必ず含まれるからです。平均利益が小さく、1回ごとの振れ幅が大きければ、PF1.9でも「利益ゼロのEAと、統計的には区別できない」ことがある。

    この記事では、その区別を数字で行うt値の計算手順と読み方を、監査実録の事例と一緒に解きます。電卓があれば今日のうちに計算できます。

    この記事でわかること

    • t値の意味と、電卓だけで出る計算手順
    • PF1.9が「統計的にはゼロ」になった監査事例
    • bid基準の歪みでt値2.14が1.84に変わった理由
    • 「あと何トレードで判断がつくか」を逆算する式

    PF1.9でも「ゼロと区別できない」ことがある

    結論から言います。EAの利益が本物かどうかは、平均利益を「平均自身のゆらぎ」で割った数字(t値)で判別がつきます。PFが見せるのは見かけの総括で、この判別力を持っていません。

    監査で持ち込まれたEA(事例A・匿名化)は、こんな成績でした。取引58回、平均利益+6.2pips、1回ごとのばらつき(標準偏差)31pips。

    0.1ロット(1万通貨)で換算すると、標準偏差31pipsは「1トレードあたり約3,000円の振れ幅」です。平均利益の6.2pipsは約620円。つまりこのEAは、1回に約3,000円の波を起こしながら、1回あたり620円ずつ貯めている。

    トレードごとの損益のばらつきと平均の関係のイメージ図

    ここで効いてくるのが取引回数です。標準偏差を√n(回数の平方根)で割ると、「平均という数字そのもののゆらぎ(標準誤差)」が出ます。

    • 事例A: 31 ÷ √58 = 約4.1pips(平均のゆらぎ)
    • 平均6.2pips ÷ ゆらぎ4.1pips = t値 1.52

    t値1.52。「利益ゼロのEAと区別できる」という水準に届いていません。平均利益はしっかりプラスなのに、です。

    監査事例 取引回数 平均 標準偏差 t値 判定
    A(PF1.9) 58回 +6.2pips 31pips 1.52 ゼロと区別できない
    B(PF1.3) 214回 +4.1pips 28pips 2.14 区別できる水準

    平均利益はA(6.2pips)のほうが高いのに、判定はBが上です。回数が違うだけ。PFは分子の見かけを見せてくれますが、分母にあたる「証拠の重み」までは見せてくれません。だから監査では、PFの前にt値を計算します。

    あなたのEAの成績表、取引回数から確認したことはありますか?

    t値は電卓で出る — Statementから出す5分の手順

    結論、t値に必要な数字は3つだけです。取引回数n、平均利益、標準偏差SD。MT4のStatement(取引履歴)から全部拾えます。

    1. MT4の「履歴」タブのStatementから、トレードごとの損益をpipsで1列に並べる(コピーして表計算に貼り付け)
    2. 平均を出す(Excelなら =AVERAGE(範囲))
    3. 標準偏差を出す(Excelなら =STDEV.S(範囲))
    4. 電卓で 平均 ÷ (標準偏差 ÷ √回数) を計算する
    5. 出た数字を下の表と比べる

      6. 1点だけ注意です。Statementの損益額をpipsに直すときは、通貨ごとのpip価値で割ってください。たとえばUSDJPYを1万通貨(0.1ロット)で持てば、1pipsは約100円です。ロットが混ざるEAは、ここでpips列そのものが崩れます(可変ロットの例外で再登場します)。

    数式を1行で書くと、t値 = 平均利益 ÷ (標準偏差 ÷ √取引回数) です。割り算が2回できるだけ。統計の専門書は不要です。

    t値(目安) 読み方
    1.0未満 ノイズの範囲。エッジの証拠としては扱わない
    1.0〜1.96 傾向はあるが、偶然の可能性を除外できない
    1.96以上 ざっくり「ゼロと区別できる」水準(95%相当の目安)
    3.0以上 強い。ただし前提の確認がより重要になる

    ※1.96は正規分布を仮定した概数です。FXのように1撃で大勝ちが混ざる分布では、外れ値を外して再計算すると実態に近づきます(この記事の最後で扱います)。

    だから何、というと、この5分で「疑う順番」を作れることです。監査の実務でも、成績表を開いたら最初にこの計算をします。数字の並びが立ってから、個別のトレードを見に行く。

    t値2.14が1.84に下がった場所 — bidの基準

    ここからが監査実録の本題です。結論、t値は「会計が正しい」前提でしか意味を持ちません。約定価格の基準が違うだけで、判定が変わります。

    EAのテストの多くは、1本の価格系列(Bid)から作られます。ところが現実の約定は、買いはAskで入り、決済はBidで出る。テストがBid系列だけで往復を計算していると、往復のスプレッド分を利益に載せていないことがあります。

    askとbidの価格の差と、bid系列のみでテストする場合のイメージ図

    事例Bの再検証では、bid/askの会計に直しただけで成績が動きました。平均利益+4.1pips→+3.4pips、標準偏差28→27pips。

    • 修正前: 4.1 ÷ (28 ÷ √214) = t値 2.14(区別できる)
    • 修正後: 3.4 ÷ (27 ÷ √214) = t値 1.84(水準を割る)

    0.7pipsの差です。平均6pips前後のEAなら利幅の1割以上にあたります。1つの設定差で「区別できる」が「区別できない」に落ちました。

    しかもこれで終わりではありません。スプレッドは時間帯で広がるものなので、固定スプレッド前提のテストなら、コストの実態はさらに重くなります。その辺りの実測はバックテストと実運用のスプレッド差の検証記事にまとめています。

    だから何、というと、t値の分子(平均)と分母(ゆらぎ)が「正直会計」で揃って初めて、比較が公平になる、です。数字が出ることと、数字が正しいことは別の話です。

    あと何トレードで判断がつくか — 逆算の式

    「区別できる水準」に届くのに必要な取引回数は、最初から計算できます。式はこうです。

    必要回数 n =(目安のt値 × 標準偏差 ÷ 平均利益)の2乗

    平均3.0pips・標準偏差28pipsのEAで、t値2を目指すとします。n =(2 × 28 ÷ 3)の2乗 = 約349。約350トレード必要です。

    このEAが月10トレードなら、必要な証拠が揃うまで3年弱かかる。待つ以外の選択肢は2つあります。

    1. テスト期間を最初から長く取る(10年分の分足データなどで回数を稼ぐ)
    2. live(またはデモ)の検証データを先に貯め始める

    2つ目は、EAを止めずに回し続けて実行の記録を取る方法です。liveデータはbid基準の歪みもスワップも最初から織り込み済みの会計になります。

    【広告】PR

    live検証でEAを24時間止めずに回すなら、VPS(仮想サーバー)の利用が選択肢になります。費用感は月数百円から(最新の料金は公式ページで確認してください)。

    XServer VPS for FXの公式ページを見る

    デモ口座でも、この「liveの会計」の役割は果たせます。bid/askの実行は記録されますし、スプレッドの時間変動も最初から織り込み済みです。まずはデモで検証用の記録を貯めるのが、ハードルの低い始め方です(口座開設は書類の提出だけで当日〜数日で終わります。キャンペーンや条件は各社の公式ページで確認してください)。

    今日からできる最初の一歩: いま動かしているEAのStatementから、取引回数・平均・標準偏差の3つの数字を拾って、電卓で平均 ÷ (標準偏差 ÷ √回数) を計算してください。5分で、「あなたのEAの証拠は今どの水準か」が見えます。

    t値だけを信じないための4つの例外

    t値は強い道具ですが、合否を決める道具ではありません。監査で必ず確認する例外を4つ、先に挙げておきます。

    1. 分布の歪み: 1撃の大勝ちが混ざると、pipsベースの前提が崩れます。外れ値を外して再計算すると実態に近づきます。極端な例はデータ破損で勝率96%が52%になった監査実録です。
    2. 可変ロット: ロットを積むEAでは、pipsの平均と損益の平均が別物になります。ロットで重み付けした損益で計算し直す必要があります。
    3. レジーム前提: その期間の相場環境がたまたま味方だった可能性は、t値では排除できません。複数期間・ウォークフォワードで崩れるなら、過剰最適化の4つのサインを疑います。
    4. コスト反映漏れ: スワップや手数料が入っていないStatementがあります。長期保有型のEAほど差が大きくなります(扱い方は正直会計の記事)。

    t値の役割は「疑う順番を作ること」です。順番が立ったら、その順に潰していく。監査とは、この繰り返しです。

    まとめ: 冒頭の問いに答えます

    「PF1.9は実力ですか?」——答えは、取引回数とばらつき次第、です。t値1.52なら、今の証拠では偶然の範囲を外れていません。証拠(回数)を増やすか、会計(bid基準・コスト)を直すかの2択になります。

    判断に迷ったEAを止めるか続けるかは、別の基準で決めます。その方法はドローダウン判別3ステップにまとめました。この記事のt値は「エッジがあるか」を測る道具、あちらは「今耐えるべきか」を測る道具、という分担です。

    あなたのEAのt値は、今日の電卓で出せます。その数字は、2を超えていますか? それとも、これから証拠を増やす側ですか?

    本記事は検証手法の解説であり、特定の取引や商品の推奨ではありません。統計値はあくまで目安で、将来の成績を保証するものではありません。

    t値の計算から始める、EA監査

    EA監査(バックテストの設計検証・実運用との差分解)を承っています。納品はご依頼から3営業日以内をめどに、判断根拠が残る検証ログの形でお返しします。「エッジが本物か確認したい」EAがあれば、まずは相談からどうぞ。

    EA監査を相談する(ココナラ)

    あわせて読みたい: EAのバックテストはこう読む — 信頼できるか見抜く3つの数字 / 勝率7割でも資産が減る トランザクションコストの正体【監査実録】 / EA作成を外注する前の要件定義チェックリスト

  • EAをいつ止めるかは数字で決める — ドローダウン判別3ステップ【監査実録】

    EAをいつ止めるかは数字で決める — ドローダウン判別3ステップ【監査実録】

    朝の口座チェックで「止める?」と迷ったら読む記事です

    EAが動く時間に口座を開いたら、含み損が資金の9%まで膨らんでいた。この瞬間、あなたならどう判断しますか?「ここで止めたら負けが確定する」と眺めて塩漬けにする人、怖くなって底値で止めてしまう人。監査の仕事をしていると、どちらの後悔も定期的に見てきました。

    実は、EA運用で一番高くつくのは、「止めるか続けるか」を気持ちで決めることです。この記事では、監査現場で実際に使っている「想定内か、想定外か」の判別フレームを3ステップで紹介します。読み終わるころには、今抱えている含み損が止めるべきものかどうかを、5分で判定できるようになっています。

    ドローダウン判別の3ステップの流れ(バックテスト確認、口座の測定、原因の切り分け)

    結論: 止める基準は「想定内か、想定外か」の2択に落とす

    先に結論を言います。EAを止めるか続けるかは、今のドローダウンがバックテストの最大ドローダウンの範囲内か、範囲外か、この1点だけで分けてよいのです。

    範囲内なら、それはEAの仕様です。設計時に織り込み済みの損失であって、止める理由にはなりません。範囲外なら、何かが壊れています。壊れたものを「まだ耐えよう」と続けるのは、もはや設計の延長ではなく、別の賭けに切り替わった状態です。

    監査実録で言えばこうです。あるEAは、バックテストの最大ドローダウン4.2%で設計されていました。ところが実運用では9.8%まで落ち込んだ。差の原因を順に潰していくと、(1)バックテストのスプレッドが固定値前提だった(実市場は特定の時間帯に大きく開く)、(2)テスト環境と実サーバーの間に時刻ずれがあり、エントリー時間帯がずれていた——この2つが、設計にない損失を作っていました。時刻ずれの正体はバックテストを狂わせる「時刻ずれ」の記事で、スプレッドの時間変動の実測はスプレッドの実測比較の記事で、それぞれ詳しく扱っています。

    バックテストの曲線と実運用の曲線のドローダウン差の比較イメージ

    つまり、この判断に必要なのは度胸ではなく、2つの数字の比較だけです。以下でその数字の出し方を整理します。

    ステップ1: バックテストから引き出すのはPFではなく「3つの数字」

    判別の材料として使うのは、利益率でもプロフィットファクターでもなく、最大ドローダウン(%)、最大連敗数、回復までの期間の3つです。この3つが「このEAはどこまで痛いのか」の設計値になります。PFが良いからといってDDが浅いとは限りません。利益と痛みは別の分布で動くからです。

    引き出す数字 意味 判別での使い方
    最大ドローダウン(%) 過去データ上の最悪の落ち幅 今のDDがこれを超えている=想定外
    最大連敗数 連続損失の設計上限 連敗が上回っている=確率が合っていない
    回復までの期間 DDから回復するまでのトレード数・日数 回復に要した期間が著しく長い=市場が変わった兆候

    連敗は「確率」で、気持ちでなく判断できる

    なぜ連敗数まで拾うのか。確率で考えると意外なことが見えてきます。勝率55%のEAなら、7連敗は1,000トレードの運用の中で3〜4回は起きる、ごく普通の現象です(0.45の7乗を連続出现の期待値に直すとこの程度になります)。ところが12連敗は、同じ勝率なら約1万5,000回に1回しか来ない順番です。「今8連敗中。もう壊れた?」という相談は、実際には設計範囲内であることが多い。反対に、テスト上あり得ない連敗が出ているなら、それは止まるべきサインです。

    ドローダウンは金額でなく「%」で見る

    心に刺さるのは金額のほうですが、判別に使うのは%です。理由は2つ。1つは、バックテストと実運用で資金の規模が違っても、%なら同じ物尺で比べられるから。もう1つは、ロットを固定している場合、資金が減るほど同じ損失円の%が重くなるからです。含み損50万円は、資金500万円なら10%、資金100万円なら50%。物差しを揃えないと、比較の前で議論が終わってしまいます。

    ステップ2: 今の口座のドローダウンを同じ物差しで測る

    測り方は単純です。口座のDD% = (含み損 + 直近の確定損) ÷ 評価残高 × 100。ピークからの下落幅で見る方法もありますが、EA運用の判別なら「今の含み損」と「直近で確定した損失」を足した落ち幅で十分です。

    ここで浮かび上がるのが、ロットと資金の関係です。1回の損切り幅(ストップロス)を20pipsと設計した場合、ドル円などの主要ペアでは1万通貨(0.1ロット)あたり1pips=約100円が目安なので、1回の損失は約2,000円。資金100万円なら0.2%です。ところが1.0ロットなら2万円、同じ資金で2%。同じ「20pipsの損失」でも、ロット次第でこのEAは別の機械になります。

    ロット SL20pipsの1回の損失目安 資金100万円に対する割合
    0.01ロット(1,000通貨) 約200円 0.02%
    0.1ロット(1万通貨) 約2,000円 0.2%
    0.5ロット(5万通貨) 約10,000円 1.0%
    1.0ロット(10万通貨) 約20,000円 2.0%

    ※pipsあたりの金額はペアとレートで変わります。机上の目安として使い、実際の1回の損失は運用履歴で確認してください。

    もう1つ。1回の実損は設計値より少し大きくなるのが普通です。スプレッドとスリッページで、実際の損切りは20pipsをわずかに超えます。見込みは常に保守側で。この「正直に数える」考え方は、スプレッドとスワップの正直会計の記事で詳しくまとめています。また、通信遅延がスリッページを上乗せする話はVPSの遅延と約定品質の実測の記事にあります。

    リスクを小さく試したいなら、1回の損失を数百円単位に縮められる小ロットの口座タイプを使う方法もあります。監査でいただく相談でも、まずは小さく回して設計の実感を掴む流れを推奨しています。【広告】PR XMの口座タイプと最小ロットの条件は公式ページで最新をご確認ください(口座タイプ・キャンペーンは変動するため、申込前に公式での確認をお願いします)。

    ステップ3: 「想定外」だったときに疑う4箇所

    数字が想定外だったら、止めてから原因を探すのが正しい順番です。壊れたものを動かし続けるリスクのほうが、休止させる機会費用より大きいからです。そして疑う場所は、監査の経験上、おおむねこの4つに集約されます。

    ① 時刻ずれ

    テスト環境と実サーバーの時刻がずれると、エントリー時間帯そのものが変わります。「朝の動きに乗る」設計なのに、実運用では昼の動きに乗っていた、というケースは実在します。

    ② スプレッドの拡大帯

    テストが固定スプレッド前提だと、市場が実際に開く時間帯のコストが計算に入っていません。エントリーがロンドン勧定やNYオープンに集中するEAほど、この差が積み上がります。

    ③ 過剰最適化

    特定の相場レンジでだけ機能するパラメータだった場合、レンジが終わった瞬間に想定外の落ち方をします。テスト期間が1年を切る場合や、パラメータの微調整で成績が激変する場合は特に警戒してください。見抜き方は過剰最適化を数字で見抜く4つのサインにまとめています。

    ④ データ品質(Bidの歪み)

    テストデータがBidベースなのか、スプレッドが反映されているのかで、逆指値やトレーリングの挙動は変わります。検証設計の記事で扱ったとおり、データの前提は成績の前提です。極端な例はデータ破損で勝率96%が52%になった監査実録です。

    この4つを順に潰していくと、「設計4.2%・実運用9.8%」のような差の9割は説明がつきます。原因が判明したら、修正して再テスト。テストが想定を取り戻すまで再開しない、が監査の基本手順です。

    止めるときの手順: 降り方は事前にルール化しておく

    想定外と判別したら、次の順で降ります。迷いを入れる場所は1つもありません。

    • EAの自動売買を停止する(まず新規エントリーを止める)
    • 保有ポジションは「即時に成行で全部処理する」か「逆指値を置いて任せる」か、運用開始前に決めておいたルールで機械的に処理する
    • 停止時のDD%、止めた理由、直近の相場環境を1行で記録する(再検証の材料になる)
    • 原因特定と再テストが終わるまで、再開しない

    2つ目のポジション処理を「その日の気分」で決めないことが重要です。底で全部切った直後に戻る相場は、監査データの中でも珍しくありません。止める判断は正しくても、降り方が感情だと総合計で負けが残ります。

    まとめ: 冒頭の問いに答えます

    「含み損9%。止める?続ける?」——答えはこうです。バックテストの最大DDが9%より浅ければ、それは想定外なので止める。深ければ、設計範囲内なので、次に見るのは連敗数とロット。判断に心拍数は使いません。

    今日からできる最初の一歩: いま動かしているEAのバックテスト結果を開いて、最大DD・最大連敗数・回復期間の3つの数字を控えてください。それを口座画面の%と並べる。この5分で、あなたのEAが「計算通り」なのか「計算外」なのかが分かります。あなたのEAのドローダウンは、設計の内側ですか、それとも外側ですか?

    数字で判断したいEA、お預けください

    EA監査(バックテストの設計検証・実運用との差分解)を承っています。納品はご依頼から3営業日以内をめどに、判断根拠が残る検証ログの形でお返しします。「止めるか続けるか」を数字で決めたいEAがあれば、まずは相談からどうぞ。

    EA監査を相談する(ココナラ)

    あわせて読みたい: 勝率7割でも資産が減る トランザクションコストの正体【監査実録】 / EAのバックテストはこう読む — 信頼できるか見抜く3つの数字 / EA作成を外注する前の要件定義チェックリスト

  • 「EAが月曜朝に止まっている」原因は4つ: VPS再起動の予防設定と復旧手順

    「EAが月曜朝に止まっている」原因は4つ: VPS再起動の予防設定と復旧手順

    金曜の夜まで正常に動いていたEAが、月曜の朝は静かになっている。チャートはもう動き出しているのに、エキスパートタブの表示が金曜のままで止まっている。こんな月曜を、一度でいいから経験したくないのが、EA運用者の本音だと思います。

    ここで問題なのは、EAが止まること自体だけではありません。止まっていた時間は、成績表に「何もなかった時間」として紛れ込むことです。バックテストには「EAが動かなかった月曜」は存在しないのに、リアル口座の成績には存在する。このズレに気づかないまま運用を続けると、EAの実力を読み誤ります。

    この記事では、EAを止める原因を4つに分類し、それぞれの予防設定と、止まっていた時間をログから見つける方法、そして月曜に止まっていたときの復旧手順を解説します。監査でEAの生死を記録から判定する際に使っている、同じ見方です。

    この記事でわかること

    • EAが週末・月曜に止まる4つの原因と、ログに残る痕跡
    • StatementとJournal の「時間の穴」から停止区間を特定する方法
    • Windows UpdateとMT4の、再起動後に自動で戻す設定手順
    • 木曜に15分で終わる週末前の点検リスト
    • VPSの容量・プランを見直す3つの確認観点

    EAを止める4つの犯人と、ログに残る痕跡

    月曜朝にEAが止まっているとき、原因は大きく4つに分類できます。それぞれ痕跡の残し方が違うので、まずはこの表で全体像をつかんでください。

    原因 起きる仕組み 残る痕跡
    Windows Update VPSのOSが更新を適用し、設定したアクティブ時間の外で再起動する Journalの起動記録が週末〜未明に増える
    VPS側のメンテ・障害 提供元の計画メンテナンスや、ホスト障害で仮想マシンが再起動する 提供元の障害・メンテ告知と時刻が一致する
    リソースの枯渇 ログやヒストリデータの蓄積でディスクが圧迫され、書き込みや動作が止まる(メモリ不足も同様) ログファイルの肥大化、古いログの欠落
    EA・MT4内部のエラー 連続する注文エラーや無効なパラメータでEAが自ら停止する エキスパートタブにエラーコードが連続記録される

    この4分類がなぜ重要か。原因ごとに「効く予防策」が違うからです。Windows Updateには設定変更が効きますが、VPS障害には設定が効きません。原因を間違えると、対策ばかり打って同じ事故が再発します。

    週末にVPSが再起動してEAが静止するイメージ

    止まっていた時間は、記録の「穴」から見つかる

    EAが止まっていた時間は、自分から申告しません。しかし、ログには必ず穴が残ります。監査でEAの稼働状況を判定するとき、私はまずこの3つの記録を突き合わせます。

    1. Statement(口座明細)の日付:取引履歴のタイムスタンプに、本来トレードする時間帯なのに数日空白があれば止まっていた可能性が高い
    2. Journal(ジャーナル):MT4の起動・再接続の記録が、自分が再起動した覚えのない時間帯に残っていないか
    3. EA自身のログ:Printで時刻を残すEAなら、ログの連番が途切れている区間が停止時間

    月曜の夜にこの3つを10分見比べるだけで、「止まっていたのは土曜3時から月曜9時まで」のような区間が特定できます。ここまで特定できれば、原因の4分類に当てはめるだけです。未確認のまま「なぜか止まってた」で終わらせると、同じ月曜が再来週にも待っています。

    なお、ログの timestamp がサーバー時間で記録される点には注意してください。MT4の表示時間との差(2〜3時間程度になることがある)を確認しないと、停止区間を実際より長く見積もってしまいます。時間のずれ自体の調べ方は、過去記事「バックテストのtimestampずれ問題」で詳しく扱っています。

    再起動直後のトレードは、スプレッド会計で不利になる

    ここが、単なる「止まる・動く」の話と違う専門的な論点です。再起動したEAが月曜オープン直後に即エントリーする仕様なら、スプレッドが広がりやすい時間帯と重なって、コスト面で不利な約定が積みやすくなります。

    市場が閉じていた後の最初のティック付近は、スプレッドが平常より広くなりやすく、Bid/Ask の表示も不安定になります。これを金額で考える「スプレッド会計」で試算してみましょう。1万通貨単位の取引で、平常より0.5pips広いスプレッドが20回発生すると、差し引きでおよそ1,000円(試算)です。月1回なら年間1.2万円。EAの利率から見れば小さいようで、停止直後の不利な約定を黙って成績に混ぜると、EAの実力判定そのものがずれる点が問題です。

    監査の現場では、ここを「正直会計」で扱います。停止からの復旧直後の取引は、平常の相場と分けて数える。混ぜたままだと、復旧後の成績でEAを過大にも過小にも評価します。同時に、停止期間がある月は取引回数そのものが減るので、t値などの統計指標の信頼性も下がります。回数が減っても平均が保つ理由を説明しなければ、その月の成績と統計指標は参考値どまりです。

    月曜オープン直後のスプレッドや Bid/Ask の歪みについて詳しくは、過去記事「スプレッドの時間帯変化とバックテストの再現性」で検証方法を扱っています。

    Windows Updateを、EAの休みに合わせる設定手順

    4つの犯人のうち、いちばん防御しやすいのがWindows Updateです。設定はVPSにリモート接続して10分で終わります。手順はWindowsのバージョンで表示が多少違うため、項目名は目安として、該当する項目を探してください。

    1. アクティブ時間を設定する:「設定→Windows Update→アクティブ時間」で、EAを動かす主要時間帯を指定します。指定時間帯の外での再起動を避ける狙いです。設定できる上限時間はWindowsのバージョンに依存するため、実際に選択できる範囲を画面で確認してください
    2. 更新の自動再起動を極力減らす:更新が適用されるタイミングは自分で計画的に。「更新の一時停止」が使える場合は EA の重要なイベント(指標や決済予定)がない週にまとめて適用します
    3. 完全な無効化は推奨しない:セキュリティ更新を止め続けると、VPS が他の脅威に晒されます。無効化より「適用のタイミングを自分で管理する」方針が安全です
    4. VPS提供元のメンテ告知を確認する:管理コンソールの通知設定をメール受信にしておくと、計画メンテの告知がメールで届きます。自分のOS更新計画と重ならないか照合する材料になります

    念のため書き添えると、Windows Update以外にも、VPS提供元の計画メンテナンスが週末に行われるケースはあります。こちらは設定で回避できないため、告知メールを受け取り、事前に自分のEAを止める・再開する運用ルールを決めておくのが現実的な自衛です。「気づかなかった」をゼロにすることが、事故を最小にします。

    週末前の点検リストで事故を先取りするイメージ

    再起動後にEAを自動で戻す、MT4側の設定

    予防しても再起動はゼロになりません。だから、「再起動してもEAが戻る構造」を作っておきます。設定は一度やれば効果が続くタイプです。VPSの画面でMT4が永続する前提で、次の3つを整えてください。

    1. スタートアップにMT4を登録する:WindowsのスタートアップフォルダにMT4のショートカットを置くと、再起動後にMT4が自動起動します
    2. 自動ログインを有効にする:ログイン時にパスワードを保存する設定にしておくと、再起動後も口座へ接続します。セキュリティとこの設定はトレードオフのため、VPSのパスワード管理方針とセットで判断してください
    3. チャートテンプレートと通知を整える:EAを付けたチャートのプロファイルを保存し、スマホへのプッシュ通知とメール通知を設定しておくと、停止やエラーに気づくのが何時間も早くなります(MetaQuotes ID の設定が必要です)

    通知設定の効果は大きいです。月曜の朝に気づけば損失は小さくて済みますが、翌週の水曜まで気づかないままだと、話は別です。EAは通知を送るだけなので、「届いた通知を見る習慣」までセットで運用します。

    木曜に15分: 週末をまたぐ前の点検リスト

    停止事故の多くは、週末をまたぐ前に先取りできます。私は週末をまたぐEAの点検を木曜の夜にすることを推奨しています。金曜だと市場が閉じるまで時間がなく、見つけた問題への対処が週明けに持ち越されるためです。

    1. エキスパートタブを開き、直近3日のエラーがないか確認する
    2. VPSの残りディスク容量を確認する(ログの肥大が怪しい場合は旧ログをバックアップ後に整理)
    3. Windows Updateの保留中の更新がないか、なければ週末はそのまま、あれば適用を計画する
    4. VPS提供元の管理画面で、週末のメンテ告知を確認する
    5. EAごとに「週末ポジションを持つ設定か」を再確認し、方針とズレていないか見る

    15分というのは、この5項目に慣れた状態での実測目安です。初回は30分ほど見ておくと安心です。このルーティンの本質は、止まる原因を「月曜の朝に発見」から「木曜の夜に発見」へ前倒しすることです。発見が3日前倒しできると、事故はほぼ「予定された対処」に変わります。

    VPSを見直すなら、確認する3つのスペック

    点検を重ねても容量不足が続くなら、VPS自体の見直しどきです。 選択の基準は、料金より先にこの3つです。

    1. ディスクとメモリの容量:ログの肥大や複数ペア運用に耐えるか。安プランでギリギリの運用は、停止事故の温床になります
    2. データセンタの所在地:MT4サーバーに近い拠点(多くは東京・NY・ロンドン)が望ましいです。ping とスリッページの関係は過去記事「VPSのレイテンシーとEAのスリッページ」で解説しています
    3. メンテと障害の履歴:週末や深夜のメンテ頻度を、提供元の告知ページで確認する。よく見る時間帯が自分の主戦場とかぶると苦しくなります

    主要なVPS各社の料金やスペックは変動するため、最新の条件は各社の公式ページで確認してください。

    【広告】PR

    EAの24時間稼働に向けて、主なVPSの公式ページを確認できます(条件は変動するため各社ページで最新をご確認ください)。

    月曜に止まっていたときの、正しい復旧手順

    万が一、月曜にEAが止まっていたら、順番が大事です。反射的に再起動する前に、この順で進めてください。

    1. 証拠を残す:エキスパートタブとJournalの画面を保存する。原因の4分類に当てはめないと、再発防止が曖昧になります
    2. 市場の状況を見る:月曜オープン直後はスプレッドも広がりやすい時間帯です。復旧直後に即エントリーする仕様のEAなら、エントリーの条件を一度確認する
    3. 再開し、通知を確認:EAを再開したら、数時間後に通知が届くか確かめる。通知が出ないEAだと、次の停止に気づけません
    4. 正直会計で記録する:停止区間と復旧直後の取引月を、平常の運用記録と分けて保存する。EAの実力判定に使う月は、この記録を外したもので再計算する

    この最後の記録をつい省きがちですが、省くと月次の成績が連続して読めなくなります。監査で月次成績を判定するとき、停止月を含めたままの平均は、私は評価に使いません。「止まらない時間」がどれだけあったかを、運用記録として並べて初めて、EAの成績は正直になるからです。

    今日できる最初の一歩は、アクティブ時間の確認

    全部を一度にやる必要はありません。今日の最初の一歩は10分です。VPSにリモート接続して、Windows Updateのアクティブ時間が、EAを動かしたい時間帯をカバーしているか確認する。それだけです。

    そこから先は、起床後の通知確認を1週間、木曜15分の点検を1か月続けてみてください。停止事故というのは、起きたときの被害より、起きていた時間に気づく速さで甚大さが決まります。あなたのEAの月曜が、静かな朝で終わることを願っています。

    まとめ: 止まらないEAより、「止まったと気づける」EA

    EAが月曜朝に止まる原因は、Windows Update、VPS側のメンテ・障害、リソース枯渇、 EA・MT4内部のエラーの4つに分類でき、それぞれ痕跡の残し方が違いました。記録の穴から停止区間を特定し、再起動直後のトレードはスプレッド会計で分けて数え、木曜15分の点検で原因を前倒しに潰す。これが、VPS上のEAを止めないための基本セットです。

    「自分のEA、実は先週の月曜も止まっていたかも」。もしそう思えたなら、今すぐエキスパートタブを開いてみてください。その一手が、月曜の静寂を防ぐ一番の近道です。

    関連記事

    EAの停止原因と記録の見方を、プロに確認してもらいませんか。

    EA監査では、Statement・Journal・EAログを突き合わせ、停止区間やコストの混入を含んだ「正直な成績」に整理します。納期は3営業日以内が目安です。内容によって対応可否が変わるため、まずは無料相談からご相談ください。

    EA監査の内容を確認する

    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る

  • EA開発はコードを書く前に決まる: 条件設計とt値・スプレッド会計・Bid歪みの実務チェック

    EA開発はコードを書く前に決まる: 条件設計とt値・スプレッド会計・Bid歪みの実務チェック

    「この条件を足せば、EAはもう少し勝てるはず」。そう考えてコードを一行変え、バックテストを回す。数字がよくなると、すぐ実運用に入れたくなるものです。

    でも、改善したのは売買ルールでしょうか。それとも、たまたま過去の値動きに合うよう調整しただけでしょうか。

    EA開発で怖いのは、動かないコードだけではありません。動くのに、根拠が弱いコードです。この記事では、エントリー条件を追加する前に決めたい仕様、検証の順番、t値・取引コスト・Bidデータの点検方法を、実務で使えるチェック表にして整理します。

    この記事でわかること

    • EAの条件を「思いつき」から検証可能な仕様に変える方法
    • t値を使うときの意味と、過信を避ける確認手順
    • スプレッド・スリッページ・スワップを損益へ反映する考え方
    • Bidデータの歪みや欠損を見つけるチェックポイント
    • 今日からできる、小さなEA開発の一歩

    EA開発の検証設計を考えるデスクのイラスト

    EAの条件追加は、コードを書く前に文章で固定する

    先に「何を、いつ、どう判定するか」を文章で決めると、テスト結果を読み違えにくくなります。曖昧な条件は、実装者の解釈やテスト後の後付け判断を混ぜるからです。

    たとえば「押し目で買う」だけではEAの仕様になりません。どの時間足の、どの確定足を使うのか。押し目の幅を何で測るのか。条件が成立した瞬間に発注するのか、次の足の始値で入るのか。停止条件は何か。これらが未定なら、同じ言葉から別のEAができあがります。

    まず、条件を次のように分解します。数値は例です。実際の採用値は、対象通貨ペアと取引時間、データの仕様に合わせて決めてください。

    仕様項目 決める内容 曖昧なままのリスク
    判定時点 確定足のみか、ティックごとか 未来情報の混入、再現性の低下
    価格系列 Bid、Ask、仲値のどれを使うか 発注価格と判定価格のズレ
    シグナル 指標、期間、閾値、比較方法 後から条件を増やす余地
    決済 損切り、利確、時間決済、反対シグナル 損失が想定外に伸びる可能性
    例外処理 取引停止時間、注文拒否、最大保有数 異常時に意図しない注文を繰り返す

    仕様を文章で残すと、検証で変えたものも追えます。つまり、勝ちやすい条件探しより先に「同じ条件を誰でも再現できる状態」を作るのです。

    例外条件こそ、損益グラフに出る前に決める

    EAは通常時より、想定外の場面で設計品質が表れます。週明けの窓、指標前後の急変、通信断、約定拒否、最小ロット未満の計算などは、平均損益だけでは見えにくいからです。

    最低限、注文に失敗した場合の再試行回数、同一シグナルの重複発注防止、最大ポジション数、損切り注文を置けない場合の動作を決めます。「失敗したらもう一度」では危険です。何秒後に何回まで試し、どの条件なら停止するかを明記します。

    こうした仕様は、見栄えのよいバックテストを作るためではありません。実運用でEAが何をするかを、先に人間が理解するためにあります。

    t値は「勝てる証明」ではなく、偶然を疑う入口

    t値は平均的な成績がばらつきに比べてどれほど大きいかを見る指標で、将来利益を保証しません。サンプル数、独立性、分布の偏り、試した条件の数を無視すると、数字だけが一人歩きします。

    単純な平均リターンの検定では、t値は「標本平均 ÷ 標準誤差」で計算します。標準誤差は、標準偏差を標本数の平方根で割った値です。たとえば取引ごとの損益を使う場合、損益の平均とばらつき、取引数が必要になります。

    ただし、FXの取引損益は常に独立とは限りません。同じ相場局面で連続してポジションを持つと、隣り合う取引の成績が似ることがあります。大きな利益が数回だけ含まれる場合も、平均値は見かけ上よくなります。通常のt値をそのまま「有意」と読み替えないでください。

    確認 見る理由 手順
    損益単位 ロットや通貨で比較が歪む R倍数、pips、資産比率などを明記
    取引数 少数の大勝ちに左右される 期間別・相場局面別にも分ける
    連続性 取引の独立性を損なう 日・週単位の集計やブロック再標本化を検討
    試行回数 多数試行から良い結果だけ選ぶ 試した条件数と選定ルールを記録
    未使用期間 作成データへの過剰適合を検出 条件決定後の期間で一度だけ評価

    検証済みの個別案件では、バックテスト表示上の勝率96%が、元データを再点検すると52%になった例もありました。これは全EAに当てはまる割合ではありません。数字が派手でも、元データと計算過程を確かめる必要がある、という監査事例です。

    t値を出す前に、まず取引履歴の欠損・重複、損益計算、試行回数を確認します。t値は最後の飾りではなく、検証設計の一部として扱いましょう。

    価格データからコスト計上と未使用期間の検証へ進む流れ

    スプレッド会計を入れると、勝ちトレードの見え方が変わる

    取引コストは、勝ち負けを決めたあとに引くのではなく、売買の成立条件に組み込みます。特に短期EAでは、小さなコスト差が期待値を削るからです。

    基本の損益は、決済損益からスプレッド、手数料、スリッページ、スワップを差し引いて考えます。口座タイプによって、スプレッドが狭い代わりに取引手数料がある場合もあります。比較するときは「表示スプレッド」だけでなく、同じロット・通貨ペア・時間帯で総コストをそろえます。

    例として、1回の取引で往復コストが平均0.8pips、年間取引数が1,000回なら、単純合計は800pips相当です。これは特定口座の実測値ではなく、計算方法を示す仮定例です。1pipの金額は通貨ペア、ロット、口座通貨で異なるため、自分の条件で換算してください。

    だから何か。バックテストの利益が800pips未満なら、この仮定のコストだけで優位性が消える可能性があります。実際には各取引のコスト分布を使い、平均だけでなく悪化側も検証します。

    正直会計では、バックテストの設定値を「実測」と呼びません。固定スプレッドを設定したなら固定値テスト、変動スプレッドのティックデータを使ったならそのデータ範囲のテスト、と記録します。約定遅延を再現できない環境なら、その制約も結果に添えます。

    コスト表は平均だけでなく、時間帯ごとに作る

    平均スプレッドだけでは、EAが実際に入る瞬間のコストが隠れます。流動性が薄い時間や指標時には、通常時間と異なる値が出ることがあります。

    取引履歴にエントリー時刻を残し、時間帯別にスプレッドとスリッページを集計します。取引の多い時間がコストの高い時間と重なれば、月平均より悪い条件で運用しているかもしれません。曜日、セッション、指標前後を分けるのも有効です。

    費目 記録するもの 見落としやすい点
    スプレッド 発注時のBid/Ask差 固定値で全時間を代用していないか
    手数料 往復・片道、ロット単位 口座通貨への換算時点
    スリッページ 要求価格と約定価格の差 バックテストでゼロ扱いになっていないか
    スワップ 保有日数、通貨ペア、方向 日々変動や付与日の違い

    口座のスプレッド、手数料、スワップは変更されることがあります。利用前に各社の公式ページで、対象口座・取引時間・適用条件を確認してください。広告や比較ページの数字だけで判断しないことが、検証の再現性を守ります。

    Bidの歪みは、ローソク足の外側に潜む

    Bid系列だけの異常は、チャートの形より先にデータ品質の問題として調べます。FXの多くのチャートはBid価格を基準に表示され、買い注文はAskで成立します。Bidだけ見て売買条件を作ると、実際の約定可能価格とずれる場合があります。

    たとえば、短時間だけ価格が飛ぶ、同じ時刻に重複したティックがある、High/Lowが前後の値とかけ離れる、BidとAskの差が不自然に広がる、といった異常です。これが実市場の急変か、データ配信の欠損かは、一本のチャートだけで断定できません。

    確認では、(1)タイムスタンプの重複・逆行、(2)OHLC整合性、(3)隣接ティックの変化幅、(4)スプレッドの分布、(5)別データソースとの同時刻比較を行います。比較元が異なる場合は、サーバー時刻、夏時間、価格更新頻度が一致しているかもそろえます。

    怪しい値を見つけても、都合よく削除してはいけません。元データを保管し、除外条件を先に定義し、除外前後の結果を両方報告します。データを整える操作そのものが、EAの成績を変えるからです。

    BidとAskの差や急変データを点検するイメージ

    検証は「作った期間」と「触っていない期間」を分ける

    条件を決めた期間だけで成績を評価すると、偶然に合った設定を選びやすくなります。開発用データで調整した後、未使用期間や別の相場局面で同じルールを試します。

    実務では時系列を崩さず、過去側を設計・調整に使い、後ろ側を検証用に確保します。検証結果を見て条件を変えたら、その期間はもう「未使用」ではありません。再び別の期間を用意するか、評価を探索的な結果として扱います。

    結果はPFや勝率だけでなく、最大ドローダウン、取引回数、連敗、平均保有時間、月別損益、コスト控除前後を並べます。相場環境別に分けると、利益が特定の数か月だけに集中しているかも見つけやすくなります。

    過去記事の監査事例では、勝率96%と表示されたEAを元データから再検証したところ52%になったケースがありました。原因が違えば必要な対策も違います。数字の大きさより、再現可能な計算過程を確かめることが先です。

    今日できる最初の一歩は、条件を一枚に書くこと

    いきなりEAを作り直す必要はありません。まずは一つのエントリー条件を、検証可能な文章にします。この作業なら、今日30分ほど確保して始められます。所要時間は内容による目安です。

    1. 対象通貨ペアと時間足を書く
    2. シグナル判定を確定足・ティックのどちらで行うか決める
    3. Bid/Askのどの価格を条件と発注に使うか記す
    4. 損切り、利確、時間決済、最大保有数を書く
    5. スプレッド・手数料・スリッページ・スワップの前提を記録する
    6. 開発用期間と未使用の検証期間を分ける
    7. 条件変更のたびに、変更理由と試行回数を残す

    そして小さなデモ検証へ進みます。最初からリアル口座で試す必要はありません。デモ環境でも、注文拒否や価格更新、EAログの読み方を確認できます。ただし、デモの約定条件が実口座と同じとは限らないため、差は別途記録します。

    「勝てそうな条件を見つける」より、「何を試し、何がわかり、次に何を変えるか」を残す。これが、再現できるEA開発の出発点です。

    まとめ: 良いEAは、結果より先に検証の筋道がある

    EAの開発では、条件をコードにする前に文章で固定し、t値を過信せず、取引コストを損益へ反映し、Bidデータの品質を確かめます。さらに、調整に使った期間と未使用期間を分けます。

    派手な勝率の裏に、データ欠損や過剰な条件調整が隠れていないか。最初に抱いた不安への答えは、数字を一つ増やすことではなく、数字がどう作られたかを追える状態にすることです。

    まずは今あるEAのエントリー条件を一つ、紙に書き出してみませんか。そこから、次の検証が始まります。

    関連記事

    EAの条件を、検証できる形に整理しませんか。

    EA作成代行では、売買条件や例外処理を確認し、仕様に沿った実装と検証を進めます。納期は3営業日以内が目安です。内容や難易度により対応可否・納期が変わるため、購入前にご相談ください。

    EA作成代行の内容を確認する

    EAを動かす土台はVPSです

    MT4を24時間止めずに動かすにはVPSが必要です。まずは無料のお試しで動作を確認できます。

    ABLENET VPSを公式サイトで見る(最大10日間無料) →

    ※本記事にはアフィリエイト広告も含みます。

    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る

  • 同じEAなのにテスト結果が毎回違う — バックテストを狂わせる「時刻ずれ」の正体

    同じEAなのにテスト結果が毎回違う — バックテストを狂わせる「時刻ずれ」の正体

    「同じEA、同じ期間、同じ設定のはずなのに、口座を変えてバックテストしたら成績がガラリと崩れた」「先月やった検証をやり直したら、なぜか結果が微妙に違う」。こうした経験は、検証のやり方が悪いわけではありません。背後には、チャート上では見えない「時刻のずれ」と「データ品質の差」という犯人がいることが多いのです。

    この記事でわかること:

    • バックテストの再現性を壊す3種類の「ずれ」(バータイムスタンプ・サーバー時刻/DST・ブローカー間のデータ差)
    • それぞれがEAの成績をどう歪めるのか
    • 監査現場で実際に使う、ずれを検出する4つの突合チェック
    • 再現性のある検証を設計する3つのポイント

    まず結論 — バックテストを狂わせるのは3種類の「ずれ」

    EAの検証結果が環境間で再現できないとき、原因はほぼ次の3種類に分類できます。それぞれ「何がずれるか」も「どう検出するか」も違います。

    ずれの種類 何がずれるか 主な症状 検出方法
    バーのタイムスタンプ チャート上の「時刻」と実際のティック到達時刻 シグナルが1本ずれる・高値/安値の使い方が変わる 複数時間足での突合
    サーバー時刻・DST ブローカーのサーバー時間と日本時間の対応(年2回1時間) 「東京時間のつもり」が7時に動く・3月と11月の成績だけ落ちる 年別・月別の成績分解
    ブローカー間のデータ差 提示レート・欠損・更新頻度が口座ごとに異なる 口座を替えると同じEAで期待値が変わる 2データソース突合

    以下で順番に、それぞれのずれがどう成績を歪めるかを見ていきます。

    1つ目: バーのタイムスタンプ — 「8:00の足」には8:00〜8:59が詰まっている

    1分足のバーに実際のティックが到達する様子のイメージ図

    図: バーのスタンプは「開始時刻」。実際のティックはその後の1分間に到達します。

    MT4のヒストリカルデータでは、各バーに「開始時刻」でタイムスタンプが押されます。8:00のM1バーには、8:00:00〜8:59:59のティックの結果がすべて詰まっているのです。

    ここで注意したいのが「8:00になったら判定する」タイプのEAです。テスター上では8:00バーの情報で判定が走りますが、実運用では8:00ちょうどに約定できるとは限りません。ティックの到達順序や、Close[1]のような「1本前の確定足」の参照位置が1本ずれるだけで、シグナルの回数は変わってしまいます。

    同じ理由で、上位足(1時間足など)を参照するEAは「どのタイミングでその足が確定したとみなすか」で結果が変動します。期間の区切り方ひとつで、同じロジックが別の取引をすることがあるのです。

    2つ目: サーバー時刻とDST — 「日本時間のつもり」が1時間ずれる

    サーバー時間と日本時間が1時間ずれるイメージ図

    図: 多くの海外ブローカーのサーバー時間は、年2回のサマータイム切替で日本時間との時差が1時間動きます。

    海外ブローカーのサーバー時間はGMT+2またはGMT+3に設定されていることが多く、多くの場合は米国のサマータイム(DST)に連動して、春と秋の年2回、1時間ずつ切り替わります。つまり、コード上の「同じ8時」でも、3月と11月では指し示す日本時間が1時間違うのです。

    「東京時間の朝に買う」つもりでサーバー時刻を指定したEAは、切替のたびに実際の取引時刻がずれます。時間帯依存の戦略ほど、このずれの影響をまともに受けます。

    見分け方は年別・月別の成績分解です。3月と10〜11月の境目だけ成績の質が変わるEAは、この「DSTのずれ」を疑う兆候です。監査では単月ごとに成績を分離して、時刻指定が切替日をまたいでいないかを確認します。

    3つ目: ブローカー間のデータ差 — 「同じUSDJPYのM1」は存在しない

    これが最も見落とされやすいポイントです。通貨ペアの名前が同じでも、ブローカーごとの提示レートは独立しています。流動性の供給元が違えば、スプレッドも、板が薄い時間帯の一瞬の異常値も、データの欠損の入り方も別物です。

    つまり、口座Aのデータで導いた期待値は、口座Bではそのまま成立しません。これはEAの欠陥ではなく、検証データの「出身」の問題です。監査では2つのデータソースを突合して、対象口座に固有の歪み(例: 特定の時間帯だけ突出して広いスプレッド)を検出してから期待値を計算します。

    このあたりの考え方や事例は、口座ごとの正直会計の記事と、データ破損を見抜いた監査実録で詳しく解説しています。

    監査で使う4つの突合チェック

    では、こうしたずれを実際にどう検出するのか。監査工程で使う4つのチェックを紹介します。

    1. バー数カウント: 期間 × 期待されるバー本数(週末・祝日を除く)と、実際のデータのバー数を比較します。欠損や重複はここで浮かび上がります。
    2. 2ソース突合: 別のデータソースの週足終値と突き合わせ、差分が閾値を超える週がないかを確認します。固有の歪みはここで検出します。
    3. DST境界テスト: 3月・10月末の切替周辺だけを単月で分離して成績を比較します。時間帯指定のEAはここで本質が現れます。
    4. スプレッド実測ログ: エントリー予定時刻の実スプレッドを数日分記録し、テスターが仮定したコストと比較します。テスターのスプレッド固定値は、実コストの代表値とは限りません。

    この4つは特別なツールがなくても、MT4の履歴と地道な突合作業で再現できます。ただ、10年分のM1データ相手にやると数時間はかかるのが実情です。

    再現性を確保する3つの設計

    ずれを検出するだけでなく、EAや検証の設計段階で「ずれに強い構造」にしておくことが可能です。

    • サーバー時刻で書く: コード内の時刻指定はすべてサーバー時間で統一し、日本時間への固定換算(「-6時間」のような固定オフセット)を書かない。DSTは切替のたびに対応が変わる前提で書きます。
    • 確定したバーだけ参照する: シグナル判定は「1本前の確定足」のみを参照する設計にすると、ティックの到達順序に左右されにくくなります。
    • 本番と同じ口座のデータで検証する: 厳密です。別のデータで検証せざるを得ない場合は、実スプレッドの差を上乗せする悲観会計で評価します。

    まとめ — 数字を信じる前に「ずれ」を疑う

    バックテストが再現できないのは、ほとんどの場合EAの欠陥ではなく、検証環境のずれです。バーのタイムスタンプ、サーバー時刻とDST、ブローカー間のデータ差。この3つを知っているかどうかで、「この数字は信じられるか」という判断の精度が変わります。

    あなたのEAの最後のバックテストは、どのブローカーの、どの時間軸のデータで走ったものだったか、今一度思い返してみてください。答えに迷ったら、それが監査のスタート地点です。

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

    このブログの運営者は、EAの統計監査をココナラで承っています。ソースコードがなくても(ex4のみで)統計検証・データ品質チェック・ストレステストが可能で、納期は3営業日以内です。本記事のような時刻ずれ・データ突合のチェックも監査工程に含まれます。

    EA監査サービスを見る → ｜ まずは1,000円のEAクイック診断

    関連記事: EAのバックテストはこう読む — 見抜く3つの数字 / EA開発は検証設計で決まる — t値・スプレッド会計・Bid歪み


    EAを動かす土台はVPSです

    MT4を24時間止めずに動かすにはVPSが必要です。まずは無料のお試しで動作を確認できます。

    ABLENET VPSを公式サイトで見る(最大10日間無料) →

    ※本記事にはアフィリエイト広告も含みます。

    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る

  • 勝率96%のEAを本物のデータで再検証したら52%になった — データ破損を見抜いた監査実録

    勝率96.4%。10年間の利益プラス5,000万円。

    こんな数字を載せたバックテスト報告書を前にすると、頭の中で2つの声が同居しませんか。「さすがに嘘でしょ」という声と、「でも本当だったら凄い」という声です。

    私が監査したEAの1つに、まさにこの成績を掲げるものがありました。結論からお伝えすると、テストに使われた価格データそのものが壊れていました。販売ページの数字は、本人にとっては真実でも、本物の市場では再現できない成績だったのです。

    この記事では、どこに違和感があって、どうやって破損を突き止めたのかを監査実録として記録します。

    最初の違和感: 勝ちは「数字の綺麗さ」に隠れる

    報告書を最初に見たとき、注目したのは勝率ではありません。数字同士のバランスです。

    • 勝率96.4%なのに、利益ファクターと損切りの平均を比べると損失が不自然に小さい
    • 10年の運用で最大ドローダウンがほぼゼロに近い
    • 取引回数は多くないのに、利益額だけが際立って大きい

    どれか1つなら「優秀なEA」の説明がつきます。しかし3つが同時に揃うと、話が違ってきます。数字の綺麗さは、しばしば「壊れた前提」の産物だからです。

    検証の切り口: まずデータそのものを疑う

    監査ではEAの中身より先に、テストに使われた価格データを取り直すところから始めます。理由はシンプルです。どんなに優れたロジックでも、入力される価格が壊れていれば出力は全て信用できません。

    そこで同じ期間のM1データを別ソースから取得し、販売者のテスト条件をそのまま再現しました。

    ここで勝率96.4%のはずのEAが、52〜53%に落ちたのです。

    犯人は「終値のフリをした始値」だった

    データを比較して分かったのは、驚くべきことに「Close」として記録された数列が、同じ足の「Open」とほぼ一致していたことでした。

    つまり、EAが「前の足の終値でエントリーしたつもり」で計算していた価格は、実際にはその足の始値だったわけです。

    このズレ、1回あたりでは数pips程度です。しかし仕組みは厄介です。

    • EAはバー確定時にClose価格でエントリー判定する設計だった
    • データのClose列が実は始値なので、判定と記録された約定価格が毎回系統的にズレる
    • そのズレが数百回の取引で積み重なり、勝率を96%まで押し上げていた

    未来の情報を見ているわけではありません。それだけに、一見「もっともらしく」見えるのが質の悪いところです。

    再検証の結果を比べる

    項目 販売者の報告 本物のデータで再現
    勝率 96.4% 52〜53%
    データのClose列 （壊れたまま） Open列とほぼ一致していた
    スプレッド込みの期待値 大きくプラス ほぼゼロ〜マイナス圏

    勝率が半分になるだけでなく、取引コストを正直に計上すると期待値が消える。これが「数字は真実でも、前提が嘘」のパターンです。

    なぜ壊れたデータでテストしてしまうのか

    ここで販売者を一概に詐欺師と決めつけるのは早すぎます。実務的には、次のような経路で壊れたデータが流入します。

    • 海外の格安・無料のヒストリカルデータ配布元の品質問題（足の欠落、列のズレ）
    • CSVを自分で加工する際の列入力ミスやタイムゾーンのずれ
    • bidとaskが混在したデータでの約定シミュレーション

    悪意がなくても、データが壊れていれば結果は同じです。購入する側に「数字の真偽を確認する手段」がないことが、本当の問題です。

    自分でできる3つのチェック

    監査を依頼するまでもなく、次の3つは誰でも確認できます。

    1. CloseとOpenの一致検査 — 保守的なデータでは各足のCloseとOpenが長期間にわたり高頻度で一致することはありません。不自然に一致が多いデータは要警戒です。
    2. スプレッドの実測比較 — テスト条件のスプレッド設定が、自分の口座の実測値（特に東京時間帯）と同じかを確認します。設定が甘いと成績は実際より良く見えます。
    3. t値による統計検証 — 利益が「偶然」でないことを数字で示すのがt値です。詳しくは「EAのバックテストはこう読む — 信頼できるか見抜く3つの数字」で解説しています。

    この3つを通過して初めて、報告書の数字を「検討材料」として扱う価値が生まれます。別の監査実録「勝率7割でも資産は減る」の記録も、あわせて読むと判断の精度が上がります。

    EAのテスト成績、信じていいか迷っていませんか？

    EAの報告書と実データを突き合わせて、「この数字を信じていいか」を判定します。データ破損・スプレッド会計・統計的有意性まで、根拠の数字つきのPDF報告書でお返しします。

    ▸ EAバックテスト検証｜実データで監査します（納期3営業日以内）

    まずは無料のEAセルフチェックシート（20問・無料PDF）からでも構いません。

    おわりに: その数字、どこのデータで作りましたか？

    EA選びで最も怖いのは、正直な人が壊れたデータを信じ込んでいるケースです。販売者も購入者も悪意がないのに、数字だけが嘘をつく。

    あなたが今運用中、あるいは購入を検討中のEAの成績は、どんなデータソースで作られていますか？その問いにすぐ答えられないなら、まずデータの確認から始める価値があります。


    EAを動かす土台はVPSです

    MT4を24時間止めずに動かすにはVPSが必要です。まずは無料のお試しで動作を確認できます。

    ABLENET VPSを公式サイトで見る(最大10日間無料) →

    ※本記事にはアフィリエイト広告も含みます。

    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る

  • VPSの通信遅延がEAのスリッページを引き起こす — ping値と約定品質の関係を実測で読む

    VPSの通信遅延がEAのスリッページを引き起こす — ping値と約定品質の関係を実測で読む

    VPS選びで「価格」ばかり気にしていませんか？

    月額数百円の差を見比べて、一番安いプランを選ぶ。それは悪くない判断です。ただ、EA運用で見落としがちなのが「通信遅延(ping)」です。

    VPSからブローカーサーバーまでの往復時間が長いと、EAの発注から約定までにタイムラグが生じます。数十ミリ秒の差が、スリッページとしてコストを積み上げていきます。

    当サイトの監査実録では、この遅延がEAの期待値を静かに削る例を複数確認しています。

    なぜVPSのpingがEAに効くのか

    EAは「価格が条件を満たしたら発注する」というロジックで動きます。ここで重要なのは、条件判定と実際の発注の間に必ず通信が挟まることです。

    • EAが価格条件を判定（MT4内で完結）
    • 発注リクエストをVPSからブローカーサーバーへ送信
    • ブローカー側で約定処理
    • 約定結果をVPSへ返す

    この2〜4の往復にかかる時間がping値です。自宅PCから運用する場合、日本のブローカーへ50〜100ms、海外ブローカーへ200ms以上がざらです。

    VPSをブローカーサーバーと同じデータセンターに置けば、この値は1〜5msに縮みます。

    ping値がスリッページに与える影響

    具体的な数字で考えましょう。

    EAが「1.10500で買」と判定した瞬間、価格は生きて動いています。発注リクエストがサーバーに届くまでに10msかかると、その間に価格が1.10502に動いているかもしれません。

    結果として1.10502で約定する。0.2pipsのスリッページです。

    これが1回なら微々たるものです。しかしEAは月に数百、数千回エントリーします。

    • 1日10回のエントリー × 0.2pipsのスリッページ = 1日2pips
    • 月20営業日で40pips
    • 年間で480pips

    480pipsは、多くのEAにとって利益と損失の境界線になり得ます。

    「正直会計」で見る隠れコスト

    当サイトで重視している「正直会計」の観点で言えば、スリッページはスプレッドと同じくトランザクションコストの一部です。

    バックテストでスプレッド2pipsのEAがあったとします。実際の運用でスリッページが平均0.3pips乗るなら、実質コストは2.3pips。これを無視してバックテスト通りに稼ぐと計算するのが一番の罠です。

    監査では、この「見えないコスト」を含めた実質期待値を計算します。テスト上はPF1.2のEAが、スリッページを計上するとPF1.05に落ちる例を確認しています。詳細は「勝率7割でも資産は減る」の監査実録で解説しています。

    VPS選びでpingを確認する3つのポイント

    VPS比較記事（4社を横並びで選び分け）でも触れていますが、ここではpingに焦点を絞ります。

    1. ブローカーのサーバー位置を先に確認する

    これが一番大切です。XMならサーバーはオランダ・英国・キプロス。日本のVPSを選ぶと、物理距離が遠くpingは150ms以上になります。

    ブローカーと同じ地域のVPSを選ぶのが基本です。

    2. VPS事業者のデータセンター所在地を確認する

    「FX向けVPS」をうたっていても、実際のサーバーは日本国内というケースがあります。海外ブローカーを使うなら、欧州（ロンドン・アムステルダム）にデータセンターがあるVPSを選んでください。

    3. 実際にpingを計測する

    VPSを借りたら、まずMT4のブローカーサーバーに対してpingを打ってください。MT4の「接続状態」の右下に表示されるms値が目安です。

    10ms未満なら優秀。10〜30msなら実用範囲。50msを超えるなら、VPSの地域を見直すべきです。

    【広告】PR

    EA運用に適したVPSをお探しの方へ。ブローカーサーバーに近い欧州データセンターを提供するVPSの代表的な選択肢:

    ▸

    ※本記事にはアフィリエイト広告も含みます。

    XServer VPS for FX（東京・ニューヨーク拠点あり）

    ▸ シンクラウド for FX（国内クラウド・低遅延設定）

    VPSの信頼性: 停止時間がEA運用に与える影響

    pingと並んで重要なのが「止まらないこと」です。

    EA運用中にVPSが停止すると、以下のリスクが生じます。

    • 建玉を抱えたままEAが停止 → 損切りが発動しない
    • 再起動後にEAが再接続 → 古い価格データで誤発注する可能性
    • 停止中のスワップ変更を検知できない

    月額数百円のVPSと月額2,000円のVPSの差は、停止頻度に表れます。稼働率99.9%と99.99%の差は、年間で約8時間の停止差です。8時間の間に重要な経済指標が発表されていたら、と想像してみてください。

    VPS費用をEAの利益で回収できるか

    VPS代は固定費です。月額1,000〜3,000円のVPSを借りたとき、EAの月利がこれを上回る必要があります。

    0.1ロット（1万通貨）で運用する場合、1pips=100円です。月額2,000円のVPSを回収するには月20pipsの利益が必要。スプレッド+スリッページ込みで月20pipsを安定して超えるEAであれば、VPS代は十分に回収可能です。

    逆に、月利10pips未満のEAではVPS代が利益を食いつぶします。EA運用は口座で決まる — スプレッドとスワップの「正直会計」で解説した通り、EAの期待値を正会計で把握した上でVPSを導入するのが正しい順序です。

    【広告】PR

    EA運用環境の安定性を高めるもう一つの選択肢:

    ▸ ABLENET VPS（FX向け最適化・高稼働率）

    ▸ お名前.comデスクトップクラウド（手軽に始めるVPS）

    pingと約定品質を監査で確認する

    VPSを導入しても、それが本当にEAの約定品質を改善しているかは実運用データでしか分かりません。

    当サイトのEA監査では、以下を確認します。

    • バックテストの約定価格と実運用の約定価格の差（スリッページの実測）
    • エントリー時のbid/askの歪み（bid歪み）
    • スプレッド会計を含めた実質期待値の再計算
    • t値による統計的優位性の検証（利益が偶然でないことの証明）

    EAのバックテストはこう読む — 信頼できるか見抜く3つの数字でも触れた通り、バックテストの数字だけでは見えないコストがあります。VPS環境で運用中のEAが本当にバックテスト通りの性能を出しているか、数字で確認したい場合は監査をご利用ください。

    EAの実運用成績を数字で監査しませんか？

    バックテストと実運用の乖離をスリッページ・スプレッド会計・t値で特定します。VPS環境の約定品質も含めて、EAが本当に機能しているかを数字で確認できます。

    ▸ EAバックテスト検証｜実データで監査します（納期3営業日以内）

    VPSは安くて速いのが理想です。しかし「安い」だけではEAの期待値を削る可能性があります。まずはご自身のブローカーのサーバー位置を確認し、そこから最適なVPSを選んでみてください。


    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る

  • EAが稼がない理由を数字で特定する5つのチェックポイント

    EAが稼がない理由を数字で特定する5つのチェックポイント

    「バックテストでは稼いでいたのに…」を、推測ではなく数字で切り分ける

    「バックテストは絶好調だったのに、リアル口座に投入した途端に右肩下がりで大切な資金が減っていく…」
    「いくら設定を変更しても一向に利益が出ず、どこを修正すればいいのか皆目見当がつかない…」
    期待を込めて稼働させたEAが期待通りに稼がないとき、焦って勘や思いつきでパラメータを弄ってしまうのは最も危険な悪手です。

    相場での損失拡大を防ぐためにまず行うべきなのは、感情や推測を一切排して『数字』で原因を冷静に切り分けることです。
    当サイトの監査実録でも、稼がない原因を正しく数値化することで、無駄な資金消失を防げた事例が多数あります。
    この記事では、不調なEAを診断する際に必ずチェックすべき5つのポイントを、実際の監査業務で使っているプロの視点から詳しく解説します。

    チェック1: 1トレードあたりの「期待値(R)」は本当にプラスか？

    EAの真の性能は、単なる表面上の勝率だけでは決して測れません。
    最も重要なのは、1トレードあたりの平均期待値（平均損益 ÷ 損切り幅 ＝ 期待値R）が明確にプラスであるかという一点に集約されます。
    例えば勝率70%のEAであっても、リスクリワード比（損益比）が悪ければ、一度の負けで利益を吹き飛ばし期待値は簡単にマイナスへと転落します。

    期待値の異常を素早く察知するには、MT4/MT5のストラテジーテスターレポートを活用するのが近道です。
    レポート内の「Total Trades（総取引数）」「Profit Factor（プロフィットファクター）」「Expected Payoff（期待利回り）」という3つの数字を確認するだけで、最初の見当を付けることができます。
    この3つの数字を用いた正確な分析手法については、バックテストの報告書を3つの数字で読むで詳しく解説しています。

    チェック2: トランザクションコストを「正直会計」で計上できているか？

    バックテスト上のスプレッド設定がリアル運用環境より楽観的すぎる場合、テスト結果は綺麗な黒字でも実運用は無惨な赤字になります。
    特に注意すべきは、エントリー時刻における実測スプレッドの拡大であり、早朝のロールオーバー時間帯では平常時の数倍に膨れ上がります。
    薄利多売を狙うスキャルピング系や深夜・早朝エントリー系のEAでは、わずか1〜2pipsのコスト見積もり誤差によって期待値のすべてが消失してしまいます。

    当方の監査現場でも、取引コストの過小評価によってリアル口座の資金を削られているケースが後を絶ちません。
    実測スプレッドの計測方法と、取引コストが期待値に与える影響の計算手順については、トランザクションコストの正直会計を参考にしてください。

    チェック3: 過去データに過剰適合（カーブフィッティング）していないか？

    パラメータを過去のヒストリカルデータに過剰に最適化させると、バックテストのグラフは完璧な右肩上がりになりますが、未来のリアル相場に投入した瞬間に脆く崩れ去ります。
    過剰適合を見抜く検証方法は非常にシンプルで、検証期間を前半と後半に2分割し、前半のみで最適化を行って後半期間で再テスト（フォワードテスト）を実行することです。

    もし前後半で期待値のプラス・マイナスが逆転してしまうなら、その設定は単に過去の相場ノイズを拾い上げただけの危険な「カーブフィッティング」です。
    パラメータ設計時に陥りやすい典型的な失敗例と対策については、EAのパラメータ設計で最も失敗しやすい3つのパターンでまとめています。

    チェック4: 運用環境（口座タイプ・VPS）は検証時の前提条件と一致しているか？

    EAが叩き出す期待値は、実際に取引を行う口座の約定スピードやサーバー環境に大きく依存します。
    どれほど優れたロジックであっても、スプレッドが広い口座・注文処理が重いサーバー・通信遅延の大きいVPS環境では、本来あったはずのエッジが完全に相殺されてしまいます。
    検証時に前提としていた口座タイプ（スワップフリー設定やボーナス口座の可否など）と、現在のリアル運用環境が正しく合致しているかを必ず再確認してください。

    通信遅延によるパフォーマンス悪化を防ぐための適切なVPS選びに関しては、EA用VPS徹底比較にて遅延・コスト・操作性の観点から厳選4社を比較検証しています。

    チェック5: その成績は統計的に「本物」と言えるか？（サンプル数とt値）

    5つのチェックの中で最も重要かつ本質的なのが、取引結果の統計的信頼性です。
    総トレード数が極端に少ない場合、どんなに素晴らしい利益が出ていたとしても、それは単なる偶然の偏りに過ぎないリスクが残ります。

    信頼性の客観的指標となるのがt値2.0以上という基準であり、これは偶然によってその成績が発生した可能性が極めて低い（統計的に有意である）ことを意味します。
    最低でも10年以上のバックテストデータと数百回以上のトレードサンプルが揃って初めて、期待値が本物であるかの議論が可能になります。
    当ブログのリスクオンドリフトの実測検証でも、このt値を用いた厳格な基準で売買シグナルの真偽を判定しています。

    原因が分かったらどうする？「改善」か「停止」かの判断基準

    5つのチェックポイントを通じてEAが稼がない原因を特定できたら、次にとるべきアクションは以下の3つに整理されます。

    • コスト・環境問題が原因の場合：利用する口座の変更やVPS環境の見直しを行うことで、運用成績を劇的に改善できる可能性が高いです。
    • 設計・パラメータ問題が原因の場合：エントリー時間帯の絞り込み、手仕舞いロジックの変更、各種フィルタの再構築によって期待値を復活させられる可能性があります。
    • そもそもロジックにエッジがない場合：これ以上の資金消失を避けるため、未練を捨てて即座に稼働を停止し、次の有望な戦略にリソースを集中するのが正解です。

    「自分で数字を切り分ける時間がない」「第三者の客観的なデータで正確な診断をしてほしい」と感じたなら、プロによるEA監査サービスをご活用ください。
    当方では10年分以上の実データを用いた正直会計の再検証を行い、あなたのEAが「運用可能・条件付き運用・運用不可」のいずれに該当するかを明確なt値とともに判定いたします。
    実際の監査報告書の精度については、以下の匿名化サンプルレポート（PDF）でご確認いただけます。

    🔎 EAの稼がない原因を、10年データで数字で判定

    このブログの運営者は、統計検証の思想を踏まえたEA監査(ライト監査/フル監査/フル監査＋救済案)をココナラで承っています。ソースコード不要で始められるライト監査から、改善構成の設計まで含むフル監査＋救済案まで。納期は3営業日以内です。

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

    EA監査サービスを見る(ココナラ) →

    まず気軽に試すなら: レポートの数字だけで1営業日で判定するEAクイック診断(1,000円)もあります → EAクイック診断を見る(ココナラ) (無料のセルフチェックシート(20問)も公開中です)

    あなたが現在お使いのEAは、これらの5つのチェックポイントを無事にクリアできていますか？
    大切な自己資金を守り着実に増やしていくために、まずは1つの数字から診断を始めてみませんか？


    実際のMQL4ソースコードを見たい方は、無料EA公開記事(ドンチャンブレイクアウト)で全文を確認できます。

    EAを動かす土台はVPSです

    MT4を24時間止めずに動かすにはVPSが必要です。まずは無料のお試しで動作を確認できます。

    ABLENET VPSを公式サイトで見る(最大10日間無料) →

    ※本記事にはアフィリエイト広告も含みます。

    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を動かす土台はVPSです

    MT4を24時間止めずに動かすにはVPSが必要です。まずは無料のお試しで動作を確認できます。

    ABLENET VPSを公式サイトで見る(最大10日間無料) →

    ※本記事にはアフィリエイト広告も含みます。

    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る

  • 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運用は口座で決まる — 正直会計の考え方


    検証の前提になる取引条件を確認する

    スプレッドや手数料はEAの成績を左右します。公式で最新の条件を確認しておきましょう。

    FXTFの口座開設・最新のスプレッドを見る →

    ※本記事にはアフィリエイト広告も含みます。

    EAの検証・監査・制作を承っています

    このブログで使っているのと同じ検証の目線で、買う前の数字の検品から、実データでの監査、死因の解剖、月次の健康診断、インジケーター制作まで承っています。

    EA監査・検証の出品一覧を見る