mql5 not enough moneyの原因と解決方法

1. mql5「not enough money」とは何か

【結論】
「not enough money」は、証拠金（margin）が不足しているため注文が拒否されるエラーです。
ロットサイズや口座残高、レバレッジ設定が原因で発生します。

1.1 not enough moneyの定義

【結論】
MQL5における「not enough money」は、必要証拠金を満たしていない状態で発注した際に返されるエラーコードです。

【定義】

• 証拠金（margin）：ポジションを保有するために必要な担保資金
• 余剰証拠金（free margin）：現在利用可能な資金

MQL5では、注文時に内部で証拠金チェックが行われ、
以下の条件を満たさない場合にエラーとなります。

• FreeMargin ＜ RequiredMargin（必要証拠金）

このとき、TRADE_RETCODE_NO_MONEY が返され、
ログには「not enough money」と表示されます。

重要ポイント

• 「残高がある＝注文できる」ではない
• 必要なのは「余剰証拠金」

1.2 どのタイミングで発生するか

【結論】
このエラーは、注文送信時または事前チェック時に即座に発生します。

主に以下の処理で発生します。

• OrderSend() 実行時（実際の注文）
• OrderCheck() 実行時（事前検証）
• ポジション追加・ナンピン時
• ロットサイズを増やした場合

特に注意すべきケース

• 含み損がある状態での追加エントリー
• 複数ポジション同時保有
• スキャルピングでの連続発注

理由
ポジションを持つと証拠金が拘束され、
余剰証拠金（free margin）が減少するためです。

また、execution（約定処理）直前の価格変動や
slippage（スリッページ）によって、
想定より証拠金が増えるケースもあります。

1.3 関連する重要な概念

【結論】
「not enough money」を正しく理解するには、証拠金・ロット・レバレッジの関係をセットで把握する必要があります。

以下は必須エンティティです。

• lot size（ロットサイズ）
  → 取引量。大きいほど必要証拠金が増える
• leverage（レバレッジ）
  → 小さいほど証拠金が多く必要
• margin（証拠金）
  → ポジション維持に必要な資金
• free margin（余剰証拠金）
  → 新規注文に使える資金
• spread（スプレッド）
  → 実質的なコスト。広がると証拠金効率が悪化
• stop out（強制ロスカット）
  → 証拠金維持率が一定以下で強制決済

重要な構造

• ロット↑ → 必要証拠金↑
• レバレッジ↓ → 必要証拠金↑
• 含み損↑ → 余剰証拠金↓

よくある誤解

• 「残高が多いから安全」→誤り
• 「ロット固定で問題ない」→危険

実務視点では、
ロット設計と証拠金管理は同時に最適化する必要があります。

2. 解決方法（エラーを最短で解消する手順）

【結論】
「not enough money」は、ロット調整と証拠金の事前計算で確実に回避できます。
実務では「発注前に必要証拠金を計算する」ことが最重要です。

2.1 最短チェックリスト

【結論】
まずは以下を確認すれば、多くのケースは即解決できます。

• ロットサイズを下げる（最も即効性が高い）
• free margin（余剰証拠金）を確認する
• レバレッジ設定を確認する
• スプレッド拡大（spread widening）を考慮する
• 既存ポジションの影響を確認する

重要ポイント

• 迷ったら「ロットを半分」にする
• スプレッドが広い時間帯（指標・早朝）は避ける

よくある失敗

• デモで通る設定をそのまま実運用に使う
• 固定ロットで資金変動に対応しない

2.2 実務で使う解決手順（コード付き）

【結論】
「OrderSend前に証拠金を計算し、ロットを調整する」ことで再現性のある解決が可能です。

手順

① 余剰証拠金を取得

double freeMargin = AccountInfoDouble(ACCOUNT_FREEMARGIN);

② 必要証拠金を計算（OrderCalcMargin）

double marginRequired;
bool result = OrderCalcMargin(
   ORDER_TYPE_BUY,
   _Symbol,
   lot,
   SymbolInfoDouble(_Symbol, SYMBOL_ASK),
   marginRequired
);

③ 証拠金不足チェック

if(marginRequired > freeMargin)
{
   Print("Not enough money");
   return;
}

④ 注文実行（OrderSend）

// 条件を満たした場合のみ実行
OrderSend(request, result);

重要ポイント

• OrderCheckでも確認可能だが、OrderCalcMarginの方が軽量で高速
• execution前に必ずチェックすることでエラーを未然に防げる

2.3 ロットサイズの自動調整（実務必須）

【結論】
固定ロットではなく、リスクベースでロットを自動計算する設計が必須です。

方法①：残高ベース（シンプル）

double riskPercent = 1.0; // 1%
double balance = AccountInfoDouble(ACCOUNT_BALANCE);
double riskAmount = balance * (riskPercent / 100.0);

// 簡易ロット計算（例）
double lot = riskAmount / 100000;

方法②：ATRベース（推奨）

• ボラティリティ（価格変動）に応じてロット調整
• 高ボラ時はロット縮小 → リスク抑制

方法③：証拠金制限ベース

double maxMarginUse = freeMargin * 0.5; // 最大50%使用

重要ポイント

• 「ロット＝固定」は破綻リスクが高い
• 「リスク％」で管理すると再現性が高い

2.4 よくあるつまずきと対策

【結論】
エラーの多くは「計算ミス」または「想定外の市場条件」で発生します。

ケース①：スプレッド拡大

• 原因：指標発表・流動性低下
• 対策：スプレッドフィルター導入

double spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spread > maxSpread) return;

ケース②：複数ポジション

• 原因：証拠金が分散消費
• 対策：最大ポジション数を制限

ケース③：価格変動（slippage）

• 原因：execution直前の価格ズレ
• 対策：余裕を持った証拠金設計

2.5 他手法との違い（軽補足）

【結論】
「証拠金チェックなしの発注」は短期的には楽だが、実務では破綻しやすいです。

3. なぜ発生するのか（証拠金の仕組み）

【結論】
「not enough money」は、余剰証拠金（free margin）が必要証拠金を下回ると発生する構造的なエラーです。
単なる資金不足ではなく、証拠金計算ロジックの結果として必然的に発生します。

3.1 証拠金計算の基本構造

【結論】
必要証拠金は「取引量 × 価格 ÷ レバレッジ」で決まり、ロットとレバレッジの影響を強く受けます。

基本式（概念）

• 必要証拠金 ＝ 取引量（lot）× 現在価格 ÷ レバレッジ

具体例

• 1ロット（100,000通貨）
• 価格：1.1000
• レバレッジ：100倍

→ 必要証拠金 ≒ 1,100ドル

重要ポイント

• ロットが2倍 → 証拠金も2倍
• レバレッジが半分 → 証拠金は2倍

補足

• 通貨ペアやブローカーにより証拠金倍率は異なる
• CFDや指数では計算式が変わる場合あり

3.2 MT5内部の判定ロジック

【結論】
MT5は注文前に「証拠金チェック」を行い、条件を満たさない場合は発注を拒否します。

内部の判定フロー（簡略）

1. 必要証拠金（RequiredMargin）を計算
2. 余剰証拠金（FreeMargin）を取得
3. 比較判定
   • FreeMargin ≥ RequiredMargin → 発注可能
   • FreeMargin < RequiredMargin → エラー発生

この判定は以下で実行されます。

• OrderCheck()（事前検証）
• OrderSend()（実行時）

重要ポイント

• 発注前に必ずブロックされるため、約定はされない
• EAのロジック次第で回避可能

3.3 余剰証拠金が減る仕組み

【結論】
余剰証拠金は「ポジション」と「含み損」によって減少します。

構造

• FreeMargin = Equity − Margin

用語補足

• Equity（有効証拠金）：残高＋含み損益
• Margin（使用証拠金）：ポジション維持に必要な資金

つまり

• ポジション増加 → Margin増加 → FreeMargin減少
• 含み損増加 → Equity減少 → FreeMargin減少

重要ポイント

• 含み損でも証拠金は圧迫される
• ナンピンはFreeMarginを急速に消費する

3.4 見落としがちな発生要因

【結論】
実務では「計算外の変動」が原因でエラーになるケースが多いです。

① スプレッド拡大（spread widening）

• 指標発表・ロールオーバー時に発生
• 必要証拠金が想定より増加

② slippage（スリッページ）

• 約定価格がズレる
• 結果的に証拠金が増える場合あり

③ 通貨ペアごとの差異

• XAUUSD・指数などは証拠金が高い
• 通貨ごとにcontract sizeが異なる

④ 同時ポジションの影響

• マルチ通貨EAで発生しやすい
• 見えない証拠金消費が増える

3.5 なぜ初心者がハマるのか

【結論】
「残高」と「余剰証拠金」を混同することが主因です。

よくある誤解

• 残高がある → 取引できる（誤り）
• ロットが小さい → 安全（条件次第）

実際の判断基準

• 判断すべきは「FreeMargin」

さらに

• バックテストではスプレッドやexecutionが理想的
  → 実運用で初めてエラーが出る

4. よくある原因別の対処法

【結論】
「not enough money」は原因ごとに対処が異なります。ロット・証拠金・市場条件の3軸で切り分けることが最短解決です。

4.1 ロットが大きすぎる場合

【結論】
最も多い原因はロット過大です。ロットを下げるだけで即解決するケースが大半です。

原因

• 固定ロット設定（例：常に0.1 lot）
• 口座残高に対して過大なポジション
• ナンピン・マーチンでロット増加

対処

• ロットを半分〜1/3に縮小
• リスク％ベースに変更（推奨）

double riskPercent = 1.0;
double balance = AccountInfoDouble(ACCOUNT_BALANCE);
double lot = (balance * riskPercent / 100.0) / 100000;

注意点

• ロットを下げてもスプレッドやexecution条件次第で再発する
• 最小ロット制限（SYMBOL_VOLUME_MIN）にも注意

4.2 含み損で証拠金が圧迫されている場合

【結論】
含み損は余剰証拠金を直接削るため、新規注文ができなくなる主要因です。

原因

• ドローダウン（DD）増加
• ナンピン戦略
• トレンド逆行

対処

• 不要なポジションを決済
• 分割エントリーに変更
• DD制御ロジックを導入

double equity = AccountInfoDouble(ACCOUNT_EQUITY);
double balance = AccountInfoDouble(ACCOUNT_BALANCE);

if(equity < balance * 0.8) return; // DD20%で停止

注意点

• 含み損は「見えにくい証拠金消費」
• 複数ポジションで急激に悪化する

4.3 スプレッド拡大による証拠金不足

【結論】
スプレッド拡大は実運用特有の落とし穴で、バックテストでは再現されにくい重要要因です。

原因

• 経済指標発表
• ロールオーバー時間
• 流動性低下（早朝・週明け）

対処

• スプレッドフィルター導入

double spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spread > maxSpread) return;

• トレード時間制限（session filter）

注意点

• spreadは瞬間的に急拡大する
• execution時に想定より悪化するケースあり

4.4 レバレッジ設定が低い場合

【結論】
レバレッジが低いほど必要証拠金は増加し、同じロットでもエラーが発生しやすくなります。

原因

• ブローカー設定（例：1:25など）
• 規制口座（金融規制による制限）

対処

• レバレッジ設定の確認
• ロット縮小で対応

注意点

• レバレッジを上げるとリスクも増大
• 長期的にはロット設計の最適化が優先

4.5 複数ポジションによる証拠金圧迫

【結論】
複数通貨・複数ポジションは、見えない形で証拠金を消費します。

原因

• マルチシンボルEA
• 同時エントリー戦略
• 相関の高い通貨ペア

対処

• 最大ポジション数の制限

if(PositionsTotal() >= maxPositions) return;

• 通貨ごとの証拠金管理

注意点

• 相関（correlation）を考慮しないと過剰リスクになる
• ポートフォリオ全体で管理する必要あり

4.6 証拠金計算をしていない場合

【結論】
証拠金計算を省略したEAは、実運用ではほぼ確実にエラーを起こします。

原因

• OrderSendのみ実装
• OrderCalcMargin未使用
• テスト環境依存

対処

• 発注前に必ず計算

double marginRequired;
OrderCalcMargin(ORDER_TYPE_BUY, _Symbol, lot, Ask, marginRequired);

if(marginRequired > AccountInfoDouble(ACCOUNT_FREEMARGIN))
   return;

注意点

• 「動く」EAと「実運用できる」EAは別物
• 証拠金管理は必須要件

5. 他のエラーとの違い

【結論】
「not enough money」は証拠金不足による資金制約エラーであり、注文条件や市場状態の問題とは明確に異なります。
誤認すると対処を誤るため、エラーごとの性質を切り分けることが重要です。

5.1 代表的なエラーとの比較

【結論】
原因・発生箇所・対処方法で整理すると、適切な対応が即判断できます。

重要ポイント

• 「not enough money」は資金問題
• 「invalid系」は注文条件ミス
• 「off quotes」は流動性・execution問題

5.2 見分け方（ログとコードで判断）

【結論】
ログのエラーコードと返り値を確認すれば、原因は即特定できます。

MQL5での確認方法

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

主なリターンコード例

• TRADE_RETCODE_NO_MONEY → not enough money
• TRADE_RETCODE_INVALID_VOLUME → invalid volume
• TRADE_RETCODE_INVALID_STOPS → invalid stops

重要ポイント

• エラーメッセージではなく「retcode」で判定する
• 同じエラーでも環境によって表示文言が異なる場合あり

5.3 よくある誤認パターン

【結論】
初心者は「証拠金不足」と「ロット不正」を混同しやすいです。

誤認①：ロットが小さいのに注文できない

• 原因：free margin不足
• 対処：残高ではなく余剰証拠金を確認

誤認②：バックテストでは通るのに本番で失敗

• 原因：スプレッド・slippage差
• 対処：実環境前提で設計

誤認③：EAのバグと判断する

• 原因：証拠金管理未実装
• 対処：OrderCalcMarginを追加

5.4 他手法との違い（設計視点）

【結論】
エラー対応は「事後処理」ではなく、事前制御に組み込むべき設計要素です。

重要ポイント

• エラー処理より「発生させない設計」が重要
• EAはリスク管理アルゴリズムとして設計する必要あり

6. 実務での使いどころ（EA設計への組み込み）

【結論】
「not enough money」対策は単なるエラー処理ではなく、EAの中核となるリスク管理ロジックとして組み込む必要があります。
発注前の証拠金チェックとロット制御を一体化することで、実運用での安定性が大きく向上します。

6.1 発注前チェックの標準フロー

【結論】
実務では「条件確認 → 証拠金計算 → ロット調整 → 発注」の順で統一します。

標準フロー

1. スプレッド・時間条件の確認
2. ロットサイズの仮決定
3. OrderCalcMargin() で必要証拠金を算出
4. 余剰証拠金と比較
5. 問題なければ OrderSend() 実行

実装例

double freeMargin = AccountInfoDouble(ACCOUNT_FREEMARGIN);

// 仮ロット
double lot = 0.1;

// 必要証拠金
double marginRequired;
OrderCalcMargin(ORDER_TYPE_BUY, _Symbol, lot, Ask, marginRequired);

// スプレッドチェック
double spread = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spread > maxSpread) return;

// 証拠金チェック
if(marginRequired > freeMargin)
{
   Print("Skip: not enough money");
   return;
}

// 発注
OrderSend(request, result);

重要ポイント

• 発注ロジックの前に必ず配置
• すべてのエントリー条件より優先度が高い

6.2 ロット制御ロジックの設計

【結論】
ロットは「資金・リスク・市場条件」に応じて動的に決定する必要があります。

推奨アプローチ

① リスク％ベース

• 例：1トレードあたり資金の1%

② ボラティリティ連動（ATRなど）

• 相場が荒い → ロット縮小

③ 証拠金制限ベース

• FreeMarginの一定割合以内に抑制

実装イメージ

double freeMargin = AccountInfoDouble(ACCOUNT_FREEMARGIN);
double maxMarginUse = freeMargin * 0.3; // 最大30%

// 必要証拠金から逆算してロット調整
while(true)
{
   OrderCalcMargin(ORDER_TYPE_BUY, _Symbol, lot, Ask, marginRequired);
   if(marginRequired < maxMarginUse) break;
   lot -= 0.01;
   if(lot <= SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN)) break;
}

重要ポイント

• 「証拠金→ロット逆算」が最も実務的
• 市場条件（spread, slippage）も考慮する

6.3 リスク管理との統合

【結論】
証拠金管理は、ドローダウン（DD）制御や資金管理と一体で設計します。

必須要素

• 最大ドローダウン制限
• 同時ポジション数制限
• エクイティ（Equity）ベース停止

double equity = AccountInfoDouble(ACCOUNT_EQUITY);
double balance = AccountInfoDouble(ACCOUNT_BALANCE);

if(equity < balance * 0.8)
{
   Print("Trading stopped due to DD");
   return;
}

なぜ必要か

• 証拠金不足は「結果」であり、原因は資金管理
• DD制御なしでは再発する

6.4 VPS・実運用での注意点

【結論】
実運用では「環境要因」によって証拠金エラーの発生率が変わります。

注意ポイント

• スプレッドは時間帯で変動
• レイテンシ（latency）によるexecution遅延
• ブローカーごとの証拠金仕様差

対策

• ログ監視（Printログ）
• 再試行ロジック（一定回数まで）
• 時間帯フィルター（セッション管理）

int hour = TimeHour(TimeCurrent());
if(hour < 7 || hour > 22) return; // 低流動性時間を回避

重要ポイント

• バックテスト結果を過信しない
• 実運用では「安全側に倒す設計」が基本

6.5 よくある設計ミス

【結論】
多くのEAは「動くが安定しない」状態で止まっています。

典型的なミス

• OrderSendのみ実装（事前チェックなし）
• 固定ロット運用
• 複数通貨で証拠金を共有していない
• スプレッドを無視

結果

• not enough money多発
• ロジック停止
• 想定外のドローダウン

7. よくある失敗・注意点

【結論】
「not enough money」は単発のミスではなく、設計・運用の甘さが蓄積して発生するエラーです。
初心者は「見えない証拠金消費」と「環境差」を見落としやすいです。

7.1 バックテストでは出ない問題

【結論】
バックテストは理想環境のため、実運用でのみエラーが発生するケースが多いです。

原因

• スプレッドが固定・低い
• slippage（スリッページ）が考慮されない
• execution（約定処理）が高速・安定

実運用との差

• スプレッドは瞬間的に拡大する
• 約定価格がズレる
• レイテンシ（通信遅延）が存在する

対策

• スプレッドフィルター導入
• 余裕を持った証拠金設計（例：必要証拠金の1.2〜1.5倍）
• フォワードテスト実施

重要ポイント

• バックテスト＝動作確認
• 実運用＝リスク管理

7.2 固定ロットの危険性

【結論】
固定ロットはシンプルだが、資金変動に対応できず破綻リスクが高い設計です。

問題点

• 残高減少時でも同じロット
• DD（ドローダウン）時に証拠金不足発生
• 資金効率が最適化されない

例

• 残高10万円 → 0.1 lot（問題なし）
• 残高5万円 → 0.1 lot（過大リスク）

対策

• リスク％ベースへ変更
• 証拠金連動ロット設計

重要ポイント

• ロットは「固定」ではなく「変数」
• 資金曲線（equity curve）に連動させる

7.3 複数通貨・複数ポジションの罠

【結論】
マルチシンボル運用では、証拠金が同時に消費されるため予期せぬ不足が起きます。

原因

• 同時エントリー
• 相関の高い通貨ペア（例：EURUSDとGBPUSD）
• ナンピン・グリッド戦略

問題点

• 個別では安全でも、合計で証拠金不足
• FreeMarginの急減

対策

• ポジション総数制限

if(PositionsTotal() >= maxPositions) return;

• 通貨別リスク管理
• 相関（correlation）を考慮

重要ポイント

• EA単体ではなく「ポートフォリオ」で考える
• 証拠金は共有リソース

7.4 証拠金計算を省略するミス

【結論】
証拠金計算を省略したEAは、短期的には動くが長期的に必ず破綻します。

よくある状態

• OrderSendのみ実装
• エラーが出たら無視 or 再試行

問題

• エラー頻発
• ロジック停止
• 意図しないトレード機会損失

正しい設計

• OrderCalcMarginで事前計算

double marginRequired;
OrderCalcMargin(ORDER_TYPE_BUY, _Symbol, lot, Ask, marginRequired);

if(marginRequired > AccountInfoDouble(ACCOUNT_FREEMARGIN))
   return;

重要ポイント

• 「事前チェック」が必須
• エラーは回避するもの

7.5 スプレッド・時間帯を無視する

【結論】
市場環境を無視すると、同じロジックでも結果が大きく変わります。

危険な時間帯

• 早朝（流動性低い）
• ロールオーバー
• 経済指標発表時

対策

• 時間フィルター

int hour = TimeHour(TimeCurrent());
if(hour < 7 || hour > 22) return;

• スプレッド制限

注意点

• spreadは常に変動する
• executionの質はブローカー依存

7.6 初心者が陥る本質的なミス

【結論】
最大の問題は「証拠金を意識せずロジックを組むこと」です。

典型パターン

• 勝率だけを重視
• ロット固定
• DD無視

本質

• トレードは「資金管理」が中心
• エントリー精度はその後

重要ポイント

• 勝てるEA ≠ 生き残るEA
• 生存条件＝証拠金管理

8. FAQ（よくある質問）

【結論】
「not enough money」は証拠金管理の理解でほぼ解決できるエラーです。
よくある疑問を短く整理します。

8.1 not enough moneyはバグですか？

【結論】
いいえ、バグではありません。証拠金不足を検知する正常なエラーです。

MT5が注文前に証拠金チェックを行い、条件を満たさない場合に返されます。

8.2 残高があるのに注文できないのはなぜ？

【結論】
判断基準は残高ではなく**余剰証拠金（free margin）**です。

• 残高（balance）：口座の総資金
• 余剰証拠金（free margin）：新規注文に使える資金

含み損や既存ポジションでfree marginが減少していると発生します。

8.3 少額口座でも発生しますか？

【結論】
はい、発生します。ロットとレバレッジ次第で小額でも起きます。

特に

• レバレッジが低い
• ロットが相対的に大きい

場合は注意が必要です。

8.4 デモでは出ないのに本番で出るのはなぜ？

【結論】
スプレッド・execution環境の違いが原因です。

実運用では

• スプレッドが拡大する
• slippageが発生する
  → 必要証拠金が増える

ため、エラーが発生しやすくなります。

8.5 自動で回避する方法はありますか？

【結論】
あります。OrderCalcMarginで事前計算すれば回避可能です。

double marginRequired;
OrderCalcMargin(ORDER_TYPE_BUY, _Symbol, lot, Ask, marginRequired);

if(marginRequired > AccountInfoDouble(ACCOUNT_FREEMARGIN))
   return;

これにより、エラーを未然に防げます。

8.6 レバレッジを上げれば解決しますか？

【結論】
一時的には解決しますが、リスクが大きく増加するため推奨されません。

レバレッジを上げるよりも

• ロット調整
• リスク管理

の方が本質的な解決です。

8.7 スキャルピングで発生しやすいですか？

【結論】
はい、発生しやすいです。スプレッドとexecutionの影響が大きいためです。

短期売買では

• スプレッド変動
• 約定ズレ

が証拠金計算に影響します。

8.8 MT4でも同じエラーはありますか？

【結論】
概念は同じですが、内部仕様や関数が異なります。

• MT4：エラーメッセージ中心
• MT5：retcodeベースで判定

基本は同じく「証拠金不足」です。

9. まとめ

【結論】
「not enough money」の本質は証拠金管理の不備です。
ロット設計と事前チェックを実装すれば、再現性高く回避できます。

9.1 最重要ポイント

【結論】
判断基準は常に「余剰証拠金（free margin）」です。

• 残高ではなくfree marginを見る
• FreeMargin ＜ RequiredMargin でエラー発生
• 含み損・複数ポジションで急減する

重要な一文

• 「注文できるか」はfree marginで決まる

9.2 解決の再現性ある手順

【結論】
以下の手順を守れば、実務で安定して回避できます。

• ロットをリスク％で設計する
• OrderCalcMarginで事前に必要証拠金を計算する
• スプレッド・時間帯をフィルタリングする
• ポジション数とDDを制御する

if(marginRequired > AccountInfoDouble(ACCOUNT_FREEMARGIN))
   return;

重要ポイント

• エラー処理ではなく「発生させない設計」
• 証拠金チェックは必須ロジック

9.3 実務での最適な考え方

【結論】
EAは「エントリー精度」ではなく、資金管理アルゴリズムとして設計するべきです。

• ロットは固定ではなく動的に変える
• 証拠金は共有リソースとして扱う
• DD・equity・marginを統合管理する

重要な認識

• 勝率よりも生存率が優先
• 証拠金管理＝破綻回避のコア

9.4 次にやるべきこと

【結論】
以下を実装すれば、実運用レベルに到達します。

• ロット自動計算（risk per trade）
• 証拠金チェック（OrderCalcMargin）
• スプレッドフィルター
• DD制御ロジック