海外FX/運用環境

MQL5の `OrderCalcMargin` 関数を用いて、エントリー直前の証拠金不足エラー（Error 134）を回避する

公開 2026.06.17 最終確認 2026.06.17 Execution

複利機能（残高に応じたロット計算）やナンピン（増し玉）機能を搭載したEAが、口座の資金限界を超えて注文を出そうとし、MT5のエキスパートログに「OrderSend Error 134 (ERRTRADENOTENOUGHMONEY)」を吐き出してフリーズする事故は非常に多く見られます。 これを未然に防ぐためには、MQL5のプログラミングにおいて、OrderS

MQL5の OrderCalcMargin 関数を用いて、エントリー直前の証拠金不足エラー（Error 134）を回避する

結論

複利機能（残高に応じたロット計算）やナンピン（増し玉）機能を搭載したEAが、口座の資金限界を超えて注文を出そうとし、MT5のエキスパートログに「OrderSend Error 134 (ERR_TRADE_NOT_ENOUGH_MONEY)」を吐き出してフリーズする事故は非常に多く見られます。 これを未然に防ぐためには、MQL5のプログラミングにおいて、OrderSend で実際の注文を投げる直前に **OrderCalcMargin() 関数を用いて「今から出そうとしているロット数に必要な証拠金」をシミュレート計算し、口座の「余剰証拠金（Free Margin）」を上回っていないかを事前にチェックする（if文で弾く）**というセーフティコードが推奨です。

なぜEA運用で重要か

「口座の残高が10万円で、レバレッジが1000倍だから、〇〇ロットまでは打てるはずだ」という人間側のどんぶり勘定は、システムトレードでは通用しません。 通貨ペアの価格変動、ブローカーごとの契約サイズの違い、週末のレバレッジ規制などによって、1ロットあたりの「必要証拠金」は刻一刻と変化します。証拠金不足エラー（Error 134）を出したEAは、そこで処理が止まってしまい、その後の重要な「決済（損切り）」の処理にすら進めなくなり、口座を放置状態にしてしまうという致命的なバグに直結します。

仕組み・条件

OrderCalcMargin の使い方と事前チェックのロジック：

double target_lot = 1.0; // 今からエントリーしたいロット数
double margin_required = 0.0; // 計算された必要証拠金を受け取る変数

// 現在のAsk価格で買い(ORDER_TYPE_BUY)を入れた場合の必要証拠金を計算
if(OrderCalcMargin(ORDER_TYPE_BUY, _Symbol, target_lot, SymbolInfoDouble(_Symbol, SYMBOL_ASK), margin_required))
{
    // 口座の現在の「余剰証拠金（Free Margin）」を取得
    double free_margin = AccountInfoDouble(ACCOUNT_MARGIN_FREE);
    
    // 余剰証拠金が必要証拠金を上回っているか（リスクを抑えたにエントリーできるか）チェック
    if(free_margin > margin_required)
    {
        // ここで初めて実際のOrderSend（エントリー処理）を行う
    }
    else
    {
        Print("証拠金不足のためエントリーをスキップします。必要:", margin_required, " 余剰:", free_margin);
    }
}

バックテストやリアル運用で壊れるポイント

• ギリギリの判定によるロスカット: 余剰証拠金が必要証拠金を「1円でも上回っていればエントリーする」というカツカツの設定にすると、エントリー直後のスプレッドによるマイナスだけで証拠金維持率が即座に低下し、ブローカーの強制ロスカット水準に抵触します。実用的なコードでは、if(free_margin > margin_required * 1.5) のように、証拠金に1.5倍〜2倍の「リスクを抑えたマージン（バッファ）」を持たせて判定するのがプロの書き方です。

どう確認するか

ご自身のEAに複利機能（AutoLot機能）がついている場合、デモ口座に「1万円」だけ入金し、EAの複利リスク設定を異常に高く（例：Risk=50%など）して稼働させてみてください。 もしEAがログに大量の赤いエラー（Error 134）を吐き出してフリーズするなら、そのEAには事前の証拠金チェック機能（フェイルセーフ）が実装されていません。逆に「証拠金不足です」と綺麗にPrint出力して待機するなら、優秀なプログラマーが設計したリスクを抑えたなEAです。

自分の検証スタンス

私はシステムトレードのコードを書く際、「注文（OrderSend）」は一番最後に、すべてのリスクを抑えた確認が終わった後にしか実行させないように設計しています。 「スプレッドは広すぎないか」「ストップレベルに違反していないか」「証拠金は足りているか」。これらの『関所（if文）』を全てノーエラーで通過したシグナルだけが、市場という戦場に送られます。プログラミングの美しさは、利益を出すロジックではなく、エラーを未然に防ぐ防御力にこそ宿ります。

関連して読む

• ExnessのRaw Spread・Zero・ProをEA目線でどう使い分けるか
• 最大連敗数からロットを決める考え方
• Exnessのレバレッジ無制限とEAロット計算
• ピラミッディング（増し玉）ロジックをEAに組み込む際の証拠金計算
• EAが突然「OrderSend Error 130」を連発する原因と解決策

免責

本記事は個人の検証メモであり、投資助言ではありません。バックテスト結果は将来の成績を保証しません。海外FXや自動売買には、法規制・レバレッジ・スプレッド拡大・約定遅延・スリッページなどのリスクがあります。条件は変わるため、最新情報は各公式ページで確認してください。