EAクラッシュデバッグのやり方｜原因特定と修正手順

リファレンス
目次

1. EAクラッシュデバッグとは何か

【結論】EAクラッシュデバッグとは、「EA（自動売買プログラム）が停止・異常終了する原因を特定し、再現・修正するための一連の分析作業」です。ログ・再現条件・コードの3点を軸に切り分けるのが最短ルートです。

1.1 EAクラッシュの定義と典型症状

【結論】クラッシュは「EAが正常な取引処理を継続できない状態」を指し、ログ異常・注文停止・強制終了として現れます。

【定義】
EAクラッシュ：MetaTrader（MT4/MT5）上で稼働するEAが、例外・ロジック不整合・環境要因により停止または異常動作する状態。

典型的な症状は以下です。

  • 注文が突然出なくなる（execution停止）
  • エラーログが連続出力される（Experts / Journal）
  • ターミナルがフリーズまたは再起動される
  • 特定条件（指標発表・スプレッド拡大・通信遅延）で停止

特に注意すべきは「見た目は動いているが注文しない状態」です。これはロジック上の条件不一致やスプレッド（spread）・スリッページ（slippage）制御の影響で発生します。

1.2 なぜデバッグが必要なのか（放置リスク）

【結論】クラッシュを放置すると「機会損失＋想定外リスク」が同時に発生し、検証結果の信頼性も崩壊します。

主なリスクは以下です。

  • 機会損失：本来エントリーすべき局面で注文できない
  • リスク逸脱：損切り（SL）やロット管理が機能しない
  • 検証破綻：バックテストとフォワード結果が乖離する
  • 信用コスト：第三者評価（Myfxbook等）の信頼低下

特にEA運用では「再現性」が最重要です。クラッシュがある状態では、同じ条件でも結果が変わるため、期待値評価（PFやDD）が無意味になります。

1.3 クラッシュ原因の分類（構造理解）

【結論】原因は「コード・取引条件・環境」の3レイヤーに分解すると、再現性高く切り分けできます。

主な原因は以下の3分類です。

■ コード起因（内部ロジック）

  • 配列外参照・NULL参照
  • 条件分岐ミス（if条件の不整合）
  • 無限ループ・過剰計算
  • 指標ハンドル（Indicator handle）の解放漏れ

■ 取引条件起因（マーケット依存）

  • スプレッド拡大（spread widening）
  • スリッページ過多（slippage）
  • 約定拒否（requote / off quotes）
  • 証拠金不足（margin不足）

■ 環境起因（外部要因）

  • VPS遅延・通信断
  • ブローカー仕様差（execution方式）
  • MT4/MT5のビルド差異
  • 指標データ未取得（CopyBuffer失敗）

重要なのは、「1つに決めつけないこと」です。例えば、スプレッド拡大で注文失敗 → その後のロジックが未処理 → EA停止、という複合パターンが多発します。

1.4 初心者が誤解しやすいポイント

【結論】多くの失敗は「ログ未確認」「再現性無視」「環境差の軽視」の3つに集中します。

よくある誤解と実態：

  • 「バックテストで動いた＝安全」
    　→ 実運用ではexecution条件・slippageが異なるため崩れます
  • 「エラーが出ていない＝正常」
    　→ 条件未達で注文していないだけのケースが多い
  • 「EAが止まった＝コードが悪い」
    　→ 実際は通信・ブローカー仕様の影響も大きい
  • 「たまに止まるだけだから問題ない」
    　→ 再現できない不具合は最も危険（期待値が歪む）

1.5 実務での位置づけ（運用と検証の分離）

【結論】デバッグは「開発工程」ではなく「運用工程の一部」として扱うべきです。

実務では以下のように扱います。

  • 開発段階：ロジック検証（Strategy Tester）
  • 検証段階：デモ口座フォワード（クリーンデータ）
  • 運用段階：リアル環境での差分監視

特に重要なのは「フォワードテストでのログ収集」です。
入出金や裁量の影響を排除した状態で、純粋な挙動を記録することで、クラッシュ原因の特定精度が大幅に上がります。

2. EAクラッシュの原因を特定するデバッグ手順

【結論】EAクラッシュの特定は「ログ確認 → 再現 → 切り分け → 修正」の順で進めると最短です。感覚ではなく、証拠（ログ・条件）ベースで判断します。

2.1 ログの確認（最優先）

【結論】デバッグの起点はログです。ExpertsログとJournalログの両方を確認し、エラーコードと発生タイミングを特定します。

確認手順：

  • MetaTraderを開く
  • 「ターミナル」→「エキスパート（Experts）」タブ
  • 「ジャーナル（Journal）」タブも同時に確認
  • エラー発生時刻・メッセージを記録

代表的なエラー例：

  • Trade context busy（取引処理競合）
  • Off quotes（価格取得不可）
  • Invalid stops（SL/TP不正）
  • Array out of range（配列外参照）

ポイント：

  • 「何が起きたか」ではなく「いつ・どの条件で起きたか」を見る
  • スプレッド（spread）やexecution状況とセットで確認する

2.2 再現条件の特定

【結論】再現できない不具合は修正できません。発生条件（時間・通貨・相場状態）を固定化します。

再現のためのチェック項目：

  • 通貨ペア（例：EURUSD / USDJPY）
  • 時間帯（ロンドン・NY・指標発表）
  • スプレッド状態（通常 or 拡大）
  • ボラティリティ（急変動時か）

実務的な方法：

  • Strategy Testerで同期間を再生
  • 同一パラメータで複数回実行
  • 発生タイミングをログと一致させる

注意点：

  • バックテストはexecutionやslippageが簡略化されている
  • 「完全再現」は難しいため「条件近似」でOK

2.3 コード単位での切り分け

【結論】原因は一気に探さず、処理単位（注文・指標・条件分岐）ごとに分割して検証します。

切り分けの基本：

  • 注文処理（OrderSend / trade.Buyなど）
  • 指標取得（iMA / CopyBuffer）
  • 条件判定（if文）

デバッグ例（MQL5）：

if(!PositionSelect(_Symbol))
{
   Print("No position found");
}

double ma = iMA(_Symbol, PERIOD_CURRENT, 20, 0, MODE_SMA, PRICE_CLOSE);
if(ma == 0)
{
   Print("Indicator error: MA is zero");
}

ポイント：

  • 異常値（0 / EMPTY_VALUE）を必ず検出する
  • Printログを積極的に埋め込む（ログ強化）

2.4 注文処理のチェック（execution周り）

【結論】クラッシュの多くは注文処理周りです。リクエスト→結果の一連を必ず検証します。

チェック項目：

  • ロットサイズ（適正か）
  • SL/TP（最小距離違反していないか）
  • スリッページ設定（過小でないか）
  • 価格取得（Bid/Askが正常か）

MQL5の例：

MqlTradeRequest request;
MqlTradeResult result;

request.action = TRADE_ACTION_DEAL;
request.symbol = _Symbol;
request.volume = 0.1;
request.type = ORDER_TYPE_BUY;
request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK);

if(!OrderSend(request, result))
{
   Print("OrderSend failed: ", result.retcode);
}

重要ポイント：

  • result.retcodeを必ず確認する
  • 成功/失敗を曖昧にしない

2.5 環境要因の切り分け（VPS・ブローカー）

【結論】同じEAでも環境が違えば結果は変わります。コード以外の要因を必ず除外します。

チェック対象：

  • VPS遅延（Ping値）
  • ブローカーのexecution方式（ECN / STP）
  • 最小ロット・最小ストップ距離
  • MT4/MT5のバージョン差

実務対応：

  • 別VPSで再現テスト
  • 別ブローカーで同一EAを稼働
  • デモ口座でクリーン検証

2.6 よくある失敗と対策

【結論】失敗パターンは固定化されています。事前に潰すことでデバッグ効率が上がります。

代表例：

  • ログを見ない
    　→ 必ずExperts/Journalを確認
  • 再現せず修正する
    　→ 修正前に再現条件を固定
  • 一気に修正する
    　→ 1箇所ずつ変更して検証
  • 環境差を無視する
    　→ VPS・ブローカーを分離検証

2.7 最短デバッグフロー（実務テンプレ）

【結論】以下のテンプレを使えば、再現性高く原因特定できます。

手順：

  1. ログ取得（Experts / Journal）
  2. 発生時間と条件を記録
  3. Strategy Testerで近似再現
  4. Printログを追加して再検証
  5. コード単位で切り分け
  6. 注文処理を重点確認
  7. VPS・ブローカー差を排除
  8. 修正 → 再テスト（必須）

3. EAクラッシュが発生する仕組み

【結論】EAクラッシュは「例外処理の欠落＋非同期な市場環境＋外部制約（ブローカー・通信）」の組み合わせで発生します。単一原因ではなく、複数要因が連鎖して停止に至るのが本質です。

3.1 EAの処理構造（イベント駆動モデル）

【結論】EAは「Tick（価格更新）」や「Timer」をトリガーに処理されるイベント駆動型です。この構造を理解しないと原因を誤認します。

【定義】
イベント駆動：価格更新（Tick）や時間イベントを契機に処理が実行される仕組み。

基本構造：

  • OnTick()：価格更新ごとに実行
  • OnInit()：起動時に1回実行
  • OnDeinit()：終了時に実行

重要ポイント：

  • Tickが来ないと処理は動かない
  • Tick頻度は通貨・時間帯で大きく変わる
  • 高頻度Tick時は処理負荷が急増する

クラッシュに繋がる例：

  • Tick集中時に重い処理 → 処理遅延 → 取引失敗
  • Tick依存ロジックで条件未評価 → 注文停止

3.2 非同期処理と取引制約（executionの罠）

【結論】EAは「同期的に見えて実際は非同期」です。注文リクエストと約定結果のズレが不具合の温床になります。

具体的なズレ：

  • 注文送信時の価格 ≠ 約定価格
  • リクエスト送信 → ブローカー処理 → 結果返却（遅延あり）
  • スリッページ（slippage）で条件崩壊

典型的な問題：

  • 価格取得直後に注文 → 既に価格変動 → Off quotes
  • スプレッド拡大 → SL/TP条件違反 → Invalid stops
  • 連続注文 → Trade context busy

重要ポイント：

  • 「送った＝通った」ではない
  • 常に結果（retcode）を確認する必要がある

3.3 データ取得とインジケータの罠

【結論】指標（indicator）や価格データの取得失敗は、クラッシュの隠れた原因です。

典型例：

  • CopyBufferが失敗 → 配列が空
  • iMAなどが初期化前 → 0を返す
  • ヒストリカルデータ未取得

よくあるバグ：

double ma = iMA(_Symbol, PERIOD_CURRENT, 20, 0, MODE_SMA, PRICE_CLOSE);
if(ma > Close[0])
{
   // 条件成立のはずが、実際はma=0で誤動作
}

対策の本質：

  • 値の妥当性チェック（0 / EMPTY_VALUE）
  • データ取得成功の確認
  • 初期化完了後にのみ使用

3.4 メモリ・リソース管理の問題

【結論】EAは軽量に見えてリソース制約があります。特に配列・ハンドル管理の不備はクラッシュに直結します。

代表的な問題：

  • 配列サイズ不足 → Array out of range
  • インジケータハンドル未解放
  • 無限ループによるCPU負荷増大

注意点：

  • MT4/MT5はサーバー型ではなくクライアント依存
  • VPS性能が低いと処理落ちが発生

再現しにくい理由：

  • 環境依存（CPU・メモリ・負荷）
  • 長時間稼働後に発生（リーク）

3.5 市場環境の変化（外部ショック）

【結論】クラッシュの多くは「異常な市場状態」で発生します。通常時だけでなく異常時の挙動設計が必須です。

典型ケース：

  • 指標発表（NFP・CPIなど）
  • スプレッド急拡大
  • 流動性低下（週末・ロールオーバー）

影響：

  • 約定拒否（execution failure）
  • 価格ギャップ（gap）
  • ストップ注文無効化

実務ポイント：

  • 「異常時に動かない設計」が重要
  • フィルタ（時間・スプレッド）で回避する

3.6 なぜ複合的に崩れるのか（連鎖構造）

【結論】クラッシュは単発ではなく「連鎖」で発生します。1つの異常が次の異常を誘発します。

典型的な連鎖：

  1. スプレッド拡大
  2. 注文失敗（Invalid stops）
  3. エラーハンドリング不足
  4. 状態不整合（ポジション認識ズレ）
  5. EA停止または暴走

この構造を理解すると、

  • 「最初の異常」を潰す
  • 「連鎖を止める処理」を入れる

という設計が可能になります。

4. デバッグ手法の比較と選び方

【結論】EAクラッシュの調査方法には複数ありますが、万能な手法はありません。初心者は「ログ確認 → Printデバッグ → ストラテジーテスター」の順で使い分けると、再現性と効率のバランスが最も良くなります。

4.1 代表的なデバッグ手法の全体像

【結論】EAのデバッグ手法は、大きく分けて「ログ確認」「コード内出力」「テスター検証」「実運用環境確認」の4系統です。

主な手法は次の通りです。

  • Experts / Journalログを読む
  • Print()で内部状態を出力する
  • Strategy Testerで再現検証する
  • VPSや実口座環境で挙動差を確認する

重要なのは、これらは競合関係ではなく補完関係だという点です。
たとえば、ログ確認だけでは「なぜその条件に入ったか」が分からず、Printデバッグだけでは「本番環境でしか起きないexecution差」を拾い切れません。

4.2 Printデバッグの特徴

【結論】Printデバッグは最も簡単で、初心者が最初に使うべき方法です。変数値・条件分岐・注文結果を可視化できます。

基本例：

Print("spread=", spread, " bid=", bid, " ask=", ask);
Print("signal_buy=", signal_buy, " positions=", PositionsTotal());
Print("retcode=", result.retcode, " volume=", request.volume);

向いている用途：

  • 条件分岐が正しく動いているか確認したい
  • spread, slippage, lot, price などの値を見たい
  • OrderSend前後の状態を確認したい

よくある失敗：

  • 出力が多すぎて逆に読めない
  • 重要な変数だけでなく全部出してしまう
  • 発生時刻を記録しない

コツは、「仮説ごとに必要な値だけ出す」ことです。
たとえば注文失敗を疑うなら、price / volume / SL / TP / retcode を優先して出力します。

4.3 ストラテジーテスターの特徴

【結論】ストラテジーテスターは再現性が高く、同じ条件で何度も検証できるのが最大の利点です。

向いている用途：

  • 特定期間だけ不具合が出る
  • 特定の通貨ペア・時間帯でのみ停止する
  • 修正前後の差分を確認したい

メリット：

  • 同条件で繰り返し検証できる
  • 再現性が高い
  • ロジック確認に強い

デメリット：

  • 本番のexecutionや通信遅延は完全再現できない
  • ブローカー差やVPS差は反映しにくい
  • 実際のslippageや約定拒否は限定的

つまり、テスターは「コード原因の切り分け」に強く、「本番環境依存の問題」には弱いです。
そのため、テスターで正常でも、リアルやデモのフォワードでは止まることがあります。

4.4 VPS・実運用環境での確認の特徴

【結論】VPSや実運用環境の確認は、本番特有の不具合を拾うために必要です。ただし再現性は低く、単独では原因特定しにくいです。

向いている用途：

  • VPSだけで停止する
  • 実口座だけ約定が崩れる
  • デモでは正常だがリアルで失敗する

確認すべき点：

  • Pingや通信断
  • ブローカーのexecution方式
  • 最小ロットやストップレベル
  • サーバー時間やセッション制約

よくある誤解は、「本番で起きたのだから本番だけ見ればよい」という考え方です。
実際には、本番環境はノイズが多く、再現条件の固定が難しいため、本番で現象を観測し、テスターやPrintで切り分ける流れのほうが効率的です。

4.5 初心者におすすめの使い分け

【結論】初心者は、まず簡単な方法で範囲を絞り、必要に応じて高度な方法に進むべきです。最初から全部やると情報量が多すぎて失敗しやすくなります。

おすすめ順序：

  • ① Experts / Journalログを見る
  • ② Print()を追加する
  • ③ Strategy Testerで再現を試す
  • ④ VPS・ブローカー差を確認する

この順が有効な理由は、コストが低い順だからです。
ログ確認は即実行でき、Printデバッグは修正も小さく、テスターは再現性を作りやすいです。
逆に、最初からVPSやブローカー差だけを疑うと、原因を広げすぎて収束しにくくなります。

4.6 他手法との違いをどう見るべきか

【結論】各手法の違いは「何を観測するための手段か」で考えると整理しやすいです。

整理すると次の通りです。

  • ログ確認：何が起きたかを見る
  • Printデバッグ：内部で何を判断したかを見る
  • テスター：同条件で再現できるかを見る
  • 実運用確認：本番固有の制約があるかを見る

この区別が曖昧だと、「ログに出ていないから問題なし」「テスターで動いたから安全」といった誤判断につながります。
EAクラッシュ調査では、観測対象ごとに手法を切り替えることが重要です。

5. EAクラッシュ時によくある失敗と注意点

【結論】デバッグが進まない原因の多くは「手順ミス」ではなく「思考ミス」です。特に「再現しないまま修正」「ログを見ない」「環境差を無視」の3点が主要因です。

5.1 ログを見ずに修正してしまう

【結論】ログを見ない修正は、原因不明のまま結果だけを変える行為です。再発率が高く、長期的に不利です。

よくある行動：

  • エラーが出ていそうだから条件を変更
  • 注文が出ないからロットやSLを適当に調整
  • Printを入れずにコードを変更

問題点：

  • 原因ではなく結果に対処している
  • 修正によって別のバグを誘発する
  • 再現性が失われる

対策：

  • 必ずExperts / Journalログを確認
  • 発生時刻とエラー内容を記録
  • 仮説 → 検証 → 修正の順を守る

5.2 再現しないまま修正する

【結論】再現できない不具合は「直ったかどうかも判定できない」ため、最も危険です。

典型例：

  • 「たまたま止まっただけ」と判断する
  • 一度だけ発生した現象を無視する
  • 修正後に同条件で検証しない

問題の本質：

  • 再現条件が不明 → 修正の正当性が不明
  • 環境依存バグが潜在化する

対策：

  • 発生条件（通貨・時間・spread・ボラ）を記録
  • Strategy Testerで近似再現
  • 修正後も同条件で再検証

重要ポイント：

  • 完全再現でなく「条件近似」で十分
  • 再現精度より「再現回数」を優先

5.3 一度に複数箇所を修正する

【結論】複数修正は原因の特定を困難にします。変更は必ず1箇所ずつ行います。

よくあるミス：

  • ロジック・注文処理・パラメータを同時変更
  • バグ修正と最適化を同時に行う

問題点：

  • どの変更が効いたか分からない
  • バグが残っていても見逃す

対策：

  • 修正は1箇所のみ
  • 修正ごとにテスト実施
  • 差分ログを比較する

実務ルール：

  • 「1修正 → 1検証 → 1記録」を徹底

5.4 環境差（VPS・ブローカー）を軽視する

【結論】EAは環境依存です。同じコードでも結果が変わるため、環境差の切り分けは必須です。

見落とされやすい要因：

  • VPSの遅延（Ping）
  • execution方式（ECN / STP）
  • ストップレベル制限
  • スプレッド特性

典型的な誤解：

  • 「テスターで動いたから問題ない」
  • 「デモで動くから本番でも同じ」

対策：

  • デモ口座とリアル口座を分離検証
  • 別ブローカーで比較
  • VPS変更で再テスト

5.5 エラーハンドリング不足

【結論】エラー処理を書いていないEAは、クラッシュではなく「沈黙停止」します。

典型的な問題：

  • OrderSend()の戻り値未確認
  • CopyBuffer()失敗時の処理なし
  • 異常値チェックなし

改善例：

if(!OrderSend(request, result))
{
   Print("Order failed: ", result.retcode);
   return;
}

if(result.retcode != TRADE_RETCODE_DONE)
{
   Print("Unexpected retcode: ", result.retcode);
}

重要ポイント：

  • 「成功した前提」で書かない
  • 常に失敗ケースを想定する

5.6 スプレッド・スリッページを考慮しない

【結論】多くのクラッシュは市場条件（spread / slippage）を無視した設計で発生します。

よくあるミス：

  • スプレッド上限チェックなし
  • slippage許容値が小さすぎる
  • 指標時の異常値を考慮していない

対策例：

double spread = (Ask - Bid) / _Point;
if(spread > 30) // 3.0pips相当
{
   Print("Spread too high: ", spread);
   return;
}

理由：

  • スプレッド拡大 → SL/TP条件違反 → 注文失敗
  • slippage過小 → 約定拒否

5.7 状態管理の不整合（ポジション認識ズレ）

【結論】ポジション状態の認識ミスは、クラッシュや暴走の直接原因になります。

典型例：

  • ポジション未取得なのに保有前提で処理
  • 同時注文の重複
  • クローズ済みなのに保有扱い

対策：

  • PositionSelect()で必ず確認
  • 注文前後で状態を更新
  • ローカル変数ではなく実データ参照

5.8 初心者が最初にやるべき最低限チェック

【結論】以下を守るだけで、致命的なクラッシュの大半は防げます。

チェックリスト：

  • ログを毎回確認する
  • 注文結果（retcode）を必ずチェック
  • spread上限を設ける
  • 異常値（0 / EMPTY_VALUE）を弾く
  • 修正は1箇所ずつ行う

6. 実務での使いどころ（どの場面でデバッグが重要か）

【結論】EAデバッグは「開発時だけ」では不十分です。実務では「開発・検証・運用」の全フェーズで継続的に行うことで、再現性と期待値の安定性が担保されます。

6.1 開発フェーズ（ロジック構築時）

【結論】開発段階では「クラッシュしない設計」を最優先にします。利益よりも安定性の確保が先です。

主なデバッグ対象：

  • 条件分岐（if）の論理整合性
  • 指標値の取得（iMA / CopyBuffer）
  • 配列・変数の初期化

実務ポイント：

  • 初期段階からPrintログを埋め込む
  • 異常値（0 / EMPTY_VALUE）を必ず弾く
  • 注文処理は仮でも必ずエラーチェックを入れる

よくある失敗：

  • 「まず動かす」ことを優先して例外処理を後回しにする
  • ロジック完成後にまとめてデバッグしようとする

結果として、バグが複合化して原因特定が困難になります。

6.2 検証フェーズ（バックテスト・フォワード）

【結論】検証段階では「再現性の確認」と「環境差の吸収」が目的です。ここでのデバッグが最も重要です。

検証の種類：

  • バックテスト（Strategy Tester）
  • デモ口座フォワード（クリーンデータ）

デバッグ観点：

  • 同条件で同結果になるか（再現性）
  • 特定期間だけ崩れないか
  • spread / slippage耐性があるか

重要ポイント：

  • バックテストだけでは不十分
  • デモフォワードで実環境に近づける
  • 入出金・裁量を排除して純粋な挙動を観測

実務的には、「クリーンなフォワードログ」が最も価値のあるデバッグデータになります。

6.3 運用フェーズ（リアル口座）

【結論】運用中もデバッグは継続します。目的は「異常の早期検知と被害最小化」です。

監視対象：

  • 注文頻度の異常（急減・急増）
  • エラーログの増加
  • DD（ドローダウン）の急変

対応フロー：

  • 異常検知 → ログ確認
  • 条件再現 → 原因仮説
  • 必要なら停止 → 修正

重要ポイント：

  • 「問題が出てから対応」では遅い
  • 定期的にログを確認する習慣が必要

6.4 市場イベント時（異常環境）

【結論】デバッグが最も重要になるのは「通常ではない市場」です。ここでの挙動がEAの本質を決めます。

対象イベント：

  • 重要指標（CPI / NFP）
  • 金融政策発表
  • 急激なトレンド転換

発生する問題：

  • スプレッド急拡大
  • slippage増大
  • execution失敗

実務対応：

  • 時間フィルタで停止
  • スプレッドフィルタを強化
  • 事前に挙動をテストしておく

6.5 複数EA・複数口座運用時

【結論】複数運用では「干渉」と「状態不整合」が発生しやすく、単体よりデバッグ難易度が上がります。

主な問題：

  • 同時注文によるTrade context busy
  • ロット管理の競合
  • ポジション認識のズレ

対策：

  • マジックナンバーで識別
  • EAごとに役割を分離
  • 注文タイミングを制御

重要ポイント：

  • 単体で安定していても、組み合わせで崩れる
  • 複数環境での再現テストが必須

6.6 実務での優先順位（リスク管理視点）

【結論】デバッグの優先順位は「利益」ではなく「リスク制御」で決めます。

優先順位：

  1. 注文失敗（execution問題）
  2. 損切り未動作（リスク逸脱）
  3. ロジック誤作動
  4. パフォーマンス低下

理由：

  • 上位ほど資金毀損リスクが高い
  • 下位は機会損失に留まる

この順で潰すことで、期待値（PF）と最大DDの安定化が可能になります。

6.7 長期運用でのデバッグ戦略

【結論】長期的には「バグを直す」より「バグが出ても崩れない設計」に移行する必要があります。

具体戦略：

  • フィルタ設計（時間・spread・ボラ）
  • フェイルセーフ（異常時は取引しない）
  • ログ監視の自動化

実務の本質：

  • 完全無バグは不可能
  • 「異常時に止まるEA」が最も安定

7. よくある質問（FAQ）

【結論】EAクラッシュデバッグで多い疑問は「再現性」「環境差」「検証手法」に集中します。ここで整理しておくことで、無駄な試行錯誤を減らせます。

7.1 バックテストで正常なら本番も問題ないですか？

【結論】問題ないとは言えません。バックテストはexecutionやslippageが簡略化されており、本番環境とは条件が異なります。

補足：

  • 約定拒否（Off quotes）は再現されにくい
  • スプレッド拡大も限定的
  • 通信遅延は考慮されない

したがって、デモフォワードでの確認が必須です。

7.2 エラーがログに出ていないのに動かないのはなぜですか？

【結論】エラーではなく「条件未達」や「ロジック停止」の可能性が高いです。

主な原因：

  • エントリー条件が厳しすぎる
  • スプレッド制限に引っかかっている
  • ポジション保有状態と誤認している

対策：

  • Printログで条件判定を可視化する
  • PositionSelect()で状態確認する

7.3 デモでは動くのにリアル口座で止まる理由は？

【結論】ブローカー仕様とexecution条件の違いが原因です。

代表的な差：

  • スプレッド（デモは狭い傾向）
  • slippage（リアルは大きい）
  • 約定方式（Instant / Market Execution）

対策：

  • リアルに近い条件でデモ検証
  • スプレッド・slippage耐性を持たせる

7.4 Printログはどこまで出力すべきですか？

【結論】「仮説検証に必要な最小限」に絞るべきです。多すぎると逆に分析不能になります。

目安：

  • 注文前後の状態（price / volume / SL / TP）
  • 条件判定（true/false）
  • エラーコード（retcode）

不要な出力：

  • 毎Tickの全変数
  • 意味のない文字列

7.5 EAがたまに止まるだけなら問題ないですか？

【結論】問題があります。再現しない不具合は最もリスクが高く、期待値を歪めます。

理由：

  • 重要な局面で停止する可能性がある
  • 検証結果と乖離する
  • DDが想定外に拡大する

対策：

  • 発生条件を記録
  • 再現を試みる
  • 原因を特定するまで放置しない

7.6 VPSを変えればクラッシュは解決しますか？

【結論】一時的に改善する可能性はありますが、根本解決ではありません。

理由：

  • VPSは環境要因の一部に過ぎない
  • コードやロジック問題は残る

正しい使い方：

  • 切り分け手段として使う
  • 別VPSで再現するか確認する

7.7 スプレッドやslippageはどこまで考慮すべきですか？

【結論】実運用を前提に「最悪ケース」を想定する必要があります。

目安：

  • スプレッド：通常の2〜3倍まで許容設計
  • slippage：ブローカー特性に応じて調整

理由：

  • 指標時や流動性低下で急拡大するため
  • 通常条件だけでは再現性が崩れる

7.8 完全にクラッシュしないEAは作れますか？

【結論】理論上は困難です。現実的には「クラッシュしにくい設計」「異常時に停止する設計」が最適です。

実務的な考え方：

  • 例外処理を徹底する
  • 異常条件では取引しない
  • ログ監視で早期検知する