MQL5 Equity Protectionの実装方法｜口座破綻を防ぐ手順

1. MQL5のEquity Protectionとは何か

【結論】Equity Protectionとは「口座全体の損失拡大を防ぐために、Equity（有効証拠金）が一定ラインを下回った時に自動で取引を制御する仕組み」である。
【結論】個別のStop Lossでは防げない“口座破綻リスク”を抑える最終防衛ラインである。

1.1 定義

【結論】Equity Protectionは「含み損を含めた資産（Equity）を基準に、強制的にポジション決済または新規注文停止を行うリスク管理手法」である。

【定義】

• Equity（有効証拠金）：現在の残高＋含み損益を含めたリアルタイム資産
• Balance（残高）：確定済み損益のみを反映した金額

重要なのは「BalanceではなくEquityを見る」という点である。
Balanceは含み損を反映しないため、危険な状態を見逃す可能性がある。一方、Equityは現在のリスクを正確に反映する。

1.2 関連用語の整理

【結論】Equity Protectionを理解するには、証拠金関連の基本概念を最低限押さえる必要がある。

• Equity：現在の実質資産（含み損益込み）
• Balance：確定済み資産
• Margin（必要証拠金）：ポジション維持に必要な資金
• Free Margin（余剰証拠金）：追加注文に使える資金
• Drawdown（ドローダウン）：資産の最大下落率

例えば、含み損が大きくなった場合、Balanceは変わらないがEquityは急減する。この差が破綻の引き金になる。

1.3 なぜ初心者ほど必要か

【結論】初心者は「含み損を放置する傾向」が強いため、Equity Protectionがないと資金が一気に崩壊しやすい。

典型的な失敗パターンは以下：

• ナンピン（負けポジションの追加）
• グリッド戦略でポジション増加
• 「戻るだろう」という根拠のない放置
• Stop Loss未設定

これらは短期的には利益を出すこともあるが、相場が一方向に動いた場合に一撃で口座が破綻する構造を持つ。

Equity Protectionはこの問題に対して：

• 一定ラインで強制終了する
• 被害を限定する
• 再起可能な状態を残す

という役割を持つ。

1.4 なぜ個別のStop Lossでは不十分か

【結論】Stop Lossは「個別トレード単位」、Equity Protectionは「口座全体」を対象にするため役割が異なる。

Stop Lossの限界：

• 複数ポジションが同時に損失拡大するケースに弱い
• ナンピン・グリッドでは機能しにくい
• slippageやexecution遅延で想定外損失が出る

一方、Equity Protectionは：

• 全ポジションをまとめて管理する
• 異常時（急変動・スプレッド拡大）でも最終防衛になる
• 「口座単位のリスク」を制御できる

したがって、実務では
Stop Loss＋Equity Protectionの併用が基本構成になる。

2. MQL5でEquity Protectionを実装する手順

【結論】Equity Protectionは「Equityを監視 → 閾値と比較 → 条件成立で全決済＋新規停止」という3ステップで実装できる。
【結論】実務では「誤作動防止（spread・slippage・execution）」と「再発防止フラグ管理」が必須になる。

2.1 実装の基本ロジック

【結論】ロジックはシンプルだが、トリガー条件と実行処理の設計が重要になる。

基本フロー：

1. 現在のEquityを取得
2. 基準値（初期資金 or 最大Equity）を決定
3. 許容ドローダウン率を設定
4. 閾値を下回ったら発動
5. 全ポジションを決済
6. 新規注文を停止

ポイント：

• Equityはリアルタイム値を使う
• ドローダウンは％で管理する方が汎用性が高い
• 発動後の「再エントリー防止」が必須

2.2 実装手順（そのまま使える形）

【結論】以下の手順をそのまま実装すれば、最低限のEquity Protectionは機能する。

手順

• ① 初期Equityを記録（OnInitで保存）
• ② 毎Tickで現在Equityを取得
• ③ 許容ドローダウン率を設定（例：20%）
• ④ 閾値を計算
• ⑤ 条件判定
• ⑥ 全ポジション決済
• ⑦ 新規注文停止フラグをON

コード例（最小構成）

double initial_equity;
bool trading_stopped = false;

int OnInit()
{
    initial_equity = AccountInfoDouble(ACCOUNT_EQUITY);
    return(INIT_SUCCEEDED);
}

void OnTick()
{
    if(trading_stopped) return;

    double current_equity = AccountInfoDouble(ACCOUNT_EQUITY);
    double max_dd_percent = 20.0;

    double threshold = initial_equity * (1.0 - max_dd_percent / 100.0);

    if(current_equity <= threshold)
    {
        CloseAllPositions();
        trading_stopped = true;
    }
}

全決済処理

void CloseAllPositions()
{
    for(int i = PositionsTotal() - 1; i >= 0; i--)
    {
        ulong ticket = PositionGetTicket(i);
        if(PositionSelectByTicket(ticket))
        {
            string symbol = PositionGetString(POSITION_SYMBOL);
            long type = PositionGetInteger(POSITION_TYPE);
            
            if(type == POSITION_TYPE_BUY)
                trade.PositionClose(symbol);
            else if(type == POSITION_TYPE_SELL)
                trade.PositionClose(symbol);
        }
    }
}

2.3 実務で必要な追加ロジック

【結論】上記コードのままでは実運用に耐えないため、最低限以下を追加する。

① spread異常時の誤作動防止

• スプレッド急拡大で誤発動する可能性
• 対策：spreadフィルターを追加

double spread = SymbolInfoDouble(_Symbol, SYMBOL_ASK) - SymbolInfoDouble(_Symbol, SYMBOL_BID);
if(spread > MaxSpread) return;

② slippage・execution対策

• 約定遅延で意図通りに決済できない
• 対策：リトライ処理 or OrderSendResult確認

③ trade context busy対応

• 複数EAや高速処理で発生
• 対策：Sleep＋再試行

④ VPS環境の考慮

• 通信遅延で発動タイミングがズレる
• 特に指標発表時は注意

2.4 よくある失敗

【結論】Equity Protectionは「動かない・遅れる・暴発する」の3つが典型的な失敗。

失敗① 初期Equityの扱いミス

• 再起動で値がリセットされる
  → ファイル保存 or GlobalVariable使用が必要

失敗② 全決済漏れ

• ループ処理の不備
  → 逆順ループ必須

失敗③ 新規注文停止しない

• 決済後にEAが再エントリー
  → フラグ管理必須

失敗④ ロットサイズとの不整合

• 巨大ロットで一撃DD
  → lot size制御と併用が前提

2.5 なぜこの構造が必要か

【結論】Equity Protectionは「最後の安全装置」であり、発動時は異常状態であるため確実性が最優先。

• 通常ロジックは利益最大化
• Equity Protectionは損失最小化
• 役割が完全に異なる

したがって：

• シンプルに作る
• 確実に動かす
• 例外処理を厚くする

これが実務設計の基本になる。

3. Equity Protectionの仕組みとリスク管理の本質

【結論】Equity Protectionは「口座の現在リスク（含み損）をリアルタイムで監視し、破綻ライン到達前に強制的に損失を確定させる仕組み」である。
【結論】利益を増やす機能ではなく、「資金を守り再起可能性を残す」ための最終防衛ラインである。

3.1 なぜEquityベースで管理するのか

【結論】Equityは「今この瞬間の損益」を反映するため、リスク検知が最も早い。

• Balanceは確定損益のみ → 含み損を無視する
• Equityは含み損益込み → 現在の危険度を正確に反映

具体例：

• Balance：100万円
• 含み損：-30万円
• Equity：70万円

この場合、Balanceだけ見ていると安全に見えるが、実際は危険域に入っている。
したがって、破綻回避にはEquity基準が必須になる。

3.2 ドローダウンとの関係

【結論】Equity Protectionは「最大ドローダウン（Max DD）を強制的に制限する装置」である。

ドローダウンとは：

• 資産のピークからの最大下落率
• トレード戦略の「耐久性」を示す指標

Equity Protectionの役割：

• DDが一定ラインを超える前に停止
• 破綻（ゼロカット・ロスカット）を防ぐ
• 資金曲線の崩壊を防ぐ

重要なポイント：

• DDは一度深くなると回復が困難
• 例：-50% → 元に戻すには+100%必要

したがって、
深いDDを許さないこと自体が戦略の一部になる。

3.3 トレード戦略との関係

【結論】Equity Protectionの重要性は戦略タイプによって大きく変わる。

逆張り・ナンピン系

• 含み損を前提に利益を狙う
• 一方向トレンドに弱い
  → 必須レベルで必要

グリッド戦略

• ポジションが増加し続ける構造
• Margin圧迫 → 強制ロスカットリスク
  → 最重要

トレンドフォロー

• 損切りが明確
• 含み損が比較的小さい
  → 必須ではないが保険として有効

スキャルピング

• 保有時間が短い
• execution / slippageの影響が大きい
  → 効果は限定的

つまり、
「損失を引き延ばす戦略ほど重要度が高い」。

3.4 なぜ破綻を防げるのか（構造）

【結論】破綻は「損失の加速」によって起こるため、その前に強制停止することで防げる。

破綻の典型構造：

1. 含み損が増加
2. Marginが圧迫
3. 強制ロスカット発動
4. 連鎖的に損失確定

Equity Protectionはこの流れを：

• 「2」の段階で遮断する
• 自分のルールで終了する

つまり：

• ブローカー任せのロスカット → 最悪条件で執行
• 自前のEquity Protection → まだ余裕のある段階で終了

この差が長期的な生存率を大きく変える。

3.5 限界と誤解

【結論】Equity Protectionは万能ではなく、「損失制御の一手段」に過ぎない。

よくある誤解：

• 入れれば勝てる → 誤り
• DDがなくなる → 誤り
• 利益が増える → 直接は増えない

実際には：

• 利益機会も同時に遮断する
• 早期停止により期待値が下がる場合もある
• 過剰に厳しい設定は逆効果

重要な理解：

• 「勝つための機能」ではない
• 「死なないための機能」である

4. 他のリスク管理手法との比較

【結論】Equity Protectionは「口座全体の最終防衛」、他手法は「個別または事前のリスク管理」であり、役割が異なる。
【結論】単体で使うのではなく、Stop Loss・ロット制御・トレーリング等と組み合わせることで初めて実務的に機能する。

4.1 比較対象の整理

【結論】主要なリスク管理手法は「対象範囲」と「発動タイミング」で分類できる。

• Equity Protection：口座全体・事後制御
• Stop Loss：個別ポジション・事前設定
• Trailing Stop：個別ポジション・利益保護
• Lot Size制御：エントリー前・リスク固定
• Drawdown制御（固定）：口座全体・閾値管理

補足：

• execution遅延・slippageの影響はすべての手法で考慮が必要
• スプレッド（spread）拡大時は挙動が変わる

4.2 手法ごとの比較（表形式想定）

【結論】「どの段階でリスクを抑えるか」が選択の基準になる。

重要なポイント：

• Stop Lossは「局所最適」
• Equity Protectionは「全体最適」
• Lot制御は「事前リスク制限」

4.3 なぜEquity Protectionが必要なのか

【結論】他手法では「同時多発リスク」や「戦略構造リスク」を完全には防げない。

典型例：

• 複数通貨で同時に逆行
• グリッドでポジション増加
• 指標発表で急変動（execution遅延＋slippage）

この場合：

• Stop Loss → 個別には機能するが合計損失は止まらない
• Trailing Stop → 利益時しか機能しない
• Lot制御 → エントリー後の暴走には無力

したがって、
最後に全体を止める仕組みが必要になる。

4.4 実務での使い分け

【結論】以下の組み合わせが最も再現性が高い。

基本構成（推奨）

• Lot Size制御（1トレードあたりリスク固定）
• Stop Loss（個別損失制御）
• Equity Protection（最終防衛）

応用構成

• Trailing Stop（利益最大化）
• 時間フィルター（セッション制御）
• スプレッドフィルター（異常回避）

この構成により：

• 事前・個別・全体の3層でリスクを制御
• 単一障害点（Single Point of Failure）を排除

4.5 よくある誤った使い方

【結論】Equity Protection単体に依存すると、逆にリスクが増える場合がある。

誤り① Stop Lossなし

• 全てをEquity Protection任せ
  → DDが深くなりすぎる

誤り② ロット過大

• Lot制御を無視
  → 一撃で閾値到達

誤り③ 閾値が極端

• 厳しすぎる → ノイズで停止
• 緩すぎる → 発動前に破綻

誤り④ 戦略との不整合

• トレンド戦略に過度な制限
  → 利益機会損失

4.6 なぜ複合的なリスク管理が必要か

【結論】市場リスクは単一原因ではないため、単一手法ではカバーできない。

リスクの種類：

• 価格変動リスク
• executionリスク（約定遅延）
• slippage
• spread拡大
• システム遅延（VPS・通信）

これらは同時に発生するため：

• 一つの手法では防げない
• 多層防御が前提になる

5. よくある失敗と注意点

【結論】Equity Protectionは「設定・実装・運用」の3点で事故が起きやすい。ここを誤ると、未発動・誤発動・過剰停止が発生する。
【結論】特に「閾値設定」「実行タイミング」「全決済の確実性」が実務上の重要ポイントである。

5.1 閾値設定のミス

【結論】閾値（ドローダウン％）の設定次第で、機能しないか過剰停止する。

典型例

• 厳しすぎる（例：5%）
  • 小さな含み損で即停止
  • ノイズでトレード不能になる
• 緩すぎる（例：50%）
  • 発動前に実質的に破綻

実務の目安

• トレンド型：10〜20%
• グリッド・ナンピン：20〜30%（※戦略依存）

理由：

• ボラティリティ（ATR）や通貨ペア特性に依存するため固定値は危険
• バックテスト＋フォワード検証で最適化する必要がある

5.2 初期Equity・基準値の扱いミス

【結論】基準となるEquityを誤ると、誤発動または未発動が起こる。

よくあるミス

• EA再起動で初期Equityがリセットされる
• 入出金で基準がズレる
• 複数EAで別々の基準を持つ

対策

• GlobalVariableまたはファイルで永続化
• 最大Equity（ピーク）を基準にする
• ポートフォリオ単位で管理する

5.3 全決済処理の不備

【結論】決済ロジックの不備は「ポジション取りこぼし」を引き起こす。

典型的な問題

• ループ順序ミス（順方向で処理）
• PositionSelectの失敗未チェック
• 一部ポジションのみ決済

対策

• 逆順ループ（必須）
• エラーチェックを入れる
• 決済後に再確認ループ

補足

• execution遅延・slippageにより一度で決済できない場合あり
• リトライ処理を入れると安全性が上がる

5.4 新規注文停止の漏れ

【結論】決済後に再エントリーしてしまう事故は非常に多い。

原因

• フラグ管理がない
• OnTickで通常ロジックが継続

対策

• グローバルフラグで完全停止
• 注文関数の前にチェックを入れる

if(trading_stopped) return;

実務ポイント

• 「停止状態」をログ出力して可視化する
• VPS再起動時の復元も考慮

5.5 実行タイミングの問題（OnTick依存）

【結論】OnTickのみで制御すると「発動遅延」が起こる可能性がある。

問題の本質

• Tickが来ないと判定が実行されない
• 急変動時に間に合わない

対策

• OnTimer併用（ミリ秒〜秒単位）
• 高頻度Tickの通貨を使う
• VPS環境で安定稼働させる

5.6 スプレッド・市場状態による誤作動

【結論】spread拡大や市場停止（market closed）で想定外動作が発生する。

典型例

• 指標発表でspread急拡大 → 誤発動
• 流動性低下 → 約定失敗（off quotes）

対策

• spreadフィルター導入
• 市場状態チェック（取引時間・流動性）

5.7 ロットサイズとの不整合

【結論】lot size制御と組み合わせないと、Equity Protectionの前に破綻する。

問題

• 過大ロット → 一撃で閾値到達
• 期待値以前にリスク過大

対策

• リスク固定（例：1〜2%/トレード）
• 証拠金チェック（OrderCalcMargin）

5.8 複数EA・手動トレードとの干渉

【結論】口座単位制御のため、他EAや裁量トレードと競合する。

典型問題

• 別EAが再エントリー
• 手動トレードが巻き込まれる

対策

• MagicNumberで分離
• 口座全体での設計を前提にする
• ポートフォリオ管理に統合

5.9 なぜこれらの問題が起きるのか

【結論】Equity Protectionは「異常時に動くロジック」であるため、通常ロジックより厳密な設計が必要。

• 通常時 → 利益最適化
• 異常時 → 即時停止

このギャップが：

• 実装漏れ
• テスト不足
• 想定外の市場条件

を引き起こす。

したがって：

• 異常系テスト（急変動・スプレッド拡大）を必ず行う
• フォワードテストで検証する

6. 実務での使いどころ（戦略別）

【結論】Equity Protectionは「すべての戦略で必須ではない」が、「含み損を抱える設計」では必須レベルになる。
【結論】戦略特性（保有時間・損切り構造・ポジション増加性）によって導入優先度が変わる。

6.1 必須ケース（導入しないと破綻しやすい）

【結論】ポジションが増える／損失を引き延ばす戦略では、Equity Protectionがないと長期生存が難しい。

グリッドEA

• 一定間隔でポジションを積み増す構造
• トレンド発生時に含み損が指数的に増加
• Margin圧迫 → 強制ロスカットの典型

ポイント：

• 最大ポジション数 × ロット × ボラ（ATR）で最悪シナリオを見積もる
• Equity Protectionで「撤退ライン」を固定する

ナンピン（平均化）戦略

• 負けポジションを増やして平均単価を下げる
• 戻りが来ないと損失が拡大し続ける

注意：

• “いつか戻る”前提は破綻要因
• Equity Protectionで上限損失を定義する

高頻度・多通貨運用

• 複数シンボルで同時に逆行するリスク
• 相関（correlation）により一斉DDが発生

対策：

• 口座全体でのDD上限を設定（Equity基準）
• ポートフォリオ単位で制御

6.2 推奨ケース（導入で安定性が上がる）

【結論】必須ではないが、入れることで「想定外リスク」に耐性がつく。

裁量＋EA併用

• 手動エントリーが混在
• ルール逸脱の可能性がある

効果：

• 人為的ミスのカバー
• 想定外ポジションの自動整理

スイング〜デイトレード

• 保有時間が中程度
• 指標発表や週跨ぎのギャップリスク

補足：

• spread拡大・slippageが発生しやすい
• Equity Protectionで「週跨ぎリスク」を限定

複数EAポートフォリオ

• EA同士の干渉（同時損失）が起こる
• 個別最適が全体最適にならない

対策：

• 口座全体のリスクを統合管理
• 個別EAのStop Lossだけでは不十分

6.3 不要または効果が限定的なケース

【結論】厳格なリスク制御が既にある戦略では、優先度は下がる。

厳格Stop Loss型（トレンドフォロー）

• 1トレードごとに損失が固定
• ポジション数も制限される

結果：

• 口座全体DDが自然に抑制される
• Equity Protectionは保険レベル

超短期スキャルピング

• 保有時間が極端に短い
• Tick単位で完結

制約：

• execution遅延・slippageの影響が大きい
• Equity判定が間に合わない場合がある

6.4 実務での設計パターン

【結論】戦略別に「発動条件」と「停止範囲」を変えると実用性が上がる。

パターン① 固定ドローダウン型

• 初期Equityから-20%で停止
• シンプル・再現性高い

パターン② トレーリングEquity型

• 最大EquityからのDDで判定
• 利益確保に有効

例：

• +30%到達後 → -10%で停止

パターン③ 時間フィルター併用

• 指標発表前後で停止
• spread異常時の誤作動回避

パターン④ シンボル分離型

• 通貨ペアごとにリスク管理
• EURUSDとUSDJPYを分離

6.5 導入時のチェックリスト

【結論】以下を満たさない場合、導入しても期待通りに機能しない。

• ロットサイズが適正か（過大でないか）
• Stop Lossが設定されているか
• 最大ポジション数が制御されているか
• VPS環境が安定しているか
• executionエラー（off quotes等）に対応しているか

6.6 なぜ戦略依存になるのか

【結論】Equity Protectionは「戦略の欠点を補う装置」であり、戦略構造によって必要性が変わる。

• 損失を早期確定する戦略 → 必要性低
• 損失を引き延ばす戦略 → 必要性高

したがって：

• まず戦略のリスク構造を理解する
• 次にEquity Protectionを設計する

この順序が重要になる。

7. 応用：高度なEquity Protection設計

【結論】実務では「固定閾値」だけでなく、最大Equity・時間・シンボル・市場状態を組み合わせた多層設計にすると安定性が大きく向上する。
【結論】目的は“早すぎる停止”と“遅すぎる停止”の両方を回避し、期待値を落とさずに破綻リスクだけを削ること。

7.1 トレーリングEquity（ピーク基準DD）

【結論】最大Equity（ピーク）からのドローダウンで判定すると、利益確保とリスク制御を同時に実現できる。

考え方

• 最高到達Equityを記録
• そこからの下落率で停止
• 利益が乗るほど許容損失額が拡大しない（＝利益を守る）

手順

• ① max_equity を更新
• ② 現在Equityとの乖離率を算出
• ③ 閾値超過で停止

double max_equity = 0.0;
bool trading_stopped = false;

void UpdateMaxEquity()
{
    double eq = AccountInfoDouble(ACCOUNT_EQUITY);
    if(eq > max_equity) max_equity = eq;
}

void CheckTrailingDD()
{
    if(trading_stopped) return;

    double eq = AccountInfoDouble(ACCOUNT_EQUITY);
    double dd_limit = 10.0; // 10%

    double dd = (max_equity - eq) / max_equity * 100.0;

    if(dd >= dd_limit)
    {
        CloseAllPositions();
        trading_stopped = true;
    }
}

注意点

• 初期化タイミング（OnInit）で max_equity を設定
• 再起動時の復元（GlobalVariable）
• 急騰直後のノイズで誤発動しやすい

7.2 時間フィルター・イベント連動

【結論】経済指標や市場時間に連動させると、spread拡大やslippageによる誤作動を回避できる。

用途

• 指標発表前後（高ボラ・execution不安定）
• ロールオーバー時間（スプレッド拡大）
• 市場クローズ直前

実装例

• 特定時間帯は判定をスキップ
• もしくは閾値を一時的に緩和

bool IsHighRiskTime()
{
    int hour = TimeHour(TimeCurrent());
    return (hour == 23); // 例：ロールオーバー
}

void SafeCheck()
{
    if(IsHighRiskTime()) return;
    CheckTrailingDD();
}

理由

• spread急拡大でEquityが一時的に悪化
• 実際のリスクではないノイズで停止するのを防ぐ

7.3 シンボル別・ポートフォリオ別管理

【結論】通貨ペアごと、またはEAごとに分離すると「局所的な異常」で口座全体を止めるのを防げる。

パターン

• シンボル単位DD管理
• MagicNumber単位管理
• ポートフォリオ単位管理

例

• EURUSDのみ異常 → USDJPYは継続
• 特定EAのみ停止

double GetSymbolEquity(string symbol)
{
    double profit = 0;
    for(int i=0;i<PositionsTotal();i++)
    {
        ulong ticket = PositionGetTicket(i);
        if(PositionSelectByTicket(ticket))
        {
            if(PositionGetString(POSITION_SYMBOL) == symbol)
                profit += PositionGetDouble(POSITION_PROFIT);
        }
    }
    return AccountInfoDouble(ACCOUNT_BALANCE) + profit;
}

注意点

• 完全分離は難しい（証拠金は共有）
• 相関（correlation）を考慮する必要あり

7.4 段階的停止（ソフト→ハード）

【結論】一発停止ではなく「段階制御」にすると、期待値低下を抑えられる。

段階設計

• DD 10%：新規エントリー停止
• DD 15%：ロット半減
• DD 20%：全決済

if(dd >= 10 && dd < 15) disable_new_entry = true;
if(dd >= 15 && dd < 20) reduce_lot = true;
if(dd >= 20) CloseAllPositions();

メリット

• 早期にリスク縮小
• 利益機会を完全には失わない

デメリット

• ロジック複雑化
• テスト難易度上昇

7.5 実運用を前提とした設計ポイント

【結論】実運用では「確実性」と「復元性」を最優先にする。

必須要素

• 状態の永続化（GlobalVariable / ファイル）
• ログ出力（発動理由・時刻）
• リトライ処理（execution失敗対策）

環境依存リスク

• VPS遅延
• 回線断
• ブローカー仕様（約定ルール・スリッページ）

テスト手順

• バックテスト（ロジック確認）
• フォワードテスト（実環境検証）
• 異常系テスト（急変動・spread拡大）

7.6 なぜここまで設計が必要か

【結論】Equity Protectionは「通常時ではなく異常時にのみ動く」ため、通常ロジック以上に設計精度が要求される。

• 通常：利益最適化
• 異常：即時停止

このギャップにより：

• テスト不足が発生しやすい
• 想定外条件でバグが出る

したがって：

• シンプルな核ロジック＋周辺防御
• 多層フィルター
• 再現性のある設計

が必要になる。

8. FAQ（よくある質問）

【結論】Equity Protectionは「口座全体の損失制御」という役割に特化しており、用途・設定・他手法との関係を正しく理解することが重要である。

8.1 Equity ProtectionとStop Lossの違いは？

【結論】Stop Lossは個別ポジション、Equity Protectionは口座全体を対象とする。
Stop Lossはエントリー時に設定する「局所的な損切り」であり、複数ポジションの合計損失は制御できない。一方、Equity Protectionは全ポジションを対象にし、総損失が一定ラインに達した時点で強制停止する。

8.2 何％で設定するのが適切？

【結論】一般的には10〜30%だが、戦略とボラティリティに依存する。
トレンドフォローなら10〜20%、ナンピンやグリッドなら20〜30%が目安。ただし、ATR（ボラティリティ）や通貨ペア特性、ロットサイズによって最適値は変わるため、バックテストとフォワードテストで検証が必要。

8.3 必ず導入すべき？

【結論】ナンピン・グリッドでは必須、それ以外は任意だが推奨。
含み損を前提とする戦略では未導入だと破綻確率が高い。厳格なStop Lossを持つ戦略では必須ではないが、想定外の相場（急変動・スプレッド拡大）への保険として有効。

8.4 利益最大化に寄与する？

【結論】直接的には寄与しない。目的は損失制限である。
Equity Protectionは「勝つための機能」ではなく「負けすぎないための機能」。早期停止により利益機会を逃すこともあるが、長期的には資金生存率を高める。

8.5 バックテストだけで十分？

【結論】不十分。フォワードテストが必須。
バックテストではexecution遅延、slippage、spread拡大などが正確に再現されない。特に急変動時の挙動はフォワード環境（デモまたは小額リアル）で確認する必要がある。

8.6 複数EAで共有できる？

【結論】可能だが競合制御が必要。
口座全体を対象とするため、他EAや手動トレードも影響を受ける。MagicNumberによる分離やポートフォリオ単位での設計を行わないと、意図しない停止や再エントリーが発生する。

8.7 VPS環境での注意点は？

【結論】遅延と接続断により発動タイミングがズレる可能性がある。
VPSの品質やブローカーサーバとの距離によってexecution速度が変わる。特に指標発表時はslippageやoff quotesが発生しやすいため、リトライ処理やログ監視が重要。

8.8 Equity Protectionだけで安全になる？

【結論】ならない。他のリスク管理と併用が前提。
Lot Size制御・Stop Loss・スプレッドフィルターなどと組み合わせることで初めて実務的に機能する。単体ではリスクの一部しかカバーできない。