はじめての方も読めるよう、専門用語はカンタンな言葉に言い換えながら解説します。「なんとなく聞いたことある」レベルの知識で大丈夫です。
- EA = Expert Advisor。MT4/MT5上で動く自動売買プログラム
- ドローダウン = 資産の最大下落幅(リスク指標)
リスク管理モジュール設計
ドローダウン15%で全停止する Guardian モジュールの設計と実装
最終更新: 2026-05-05
EAが暴走しても損失を限定するための「最終防衛ライン」。15%という数字の根拠と、実際にPython/MQL5でどう実装するかをサンプルコード付きで共有します。
なぜ「15%」なのか
個人の心理的耐性、Kelly基準の保守的下限、業界の慣行 (大手CTAの多くがMDD 20%以下を目標) から、15%は実務的な妥協点として広く使われています。Kelly基準で計算する勝率55%/RR 1.5の戦略の最適fは約16%、その半分のHalf Kellyを取ると8%リスク。連敗を考慮するとMDDは15-25%の範囲に収まります。
Guardian モジュールが守るもの
- 残高ピーク比 -X% で全エントリー停止
- 日次損失 -Y% で当日停止
- 週次損失 -Z% でリカバリーモード (ロット半減)
- システム異常 (API応答なし等) で安全側に倒す
Python 実装サンプル
import json, datetime as dt
from pathlib import Path
STATE_FILE = Path("guardian_state.json")
DD_THRESHOLD = 0.15 # 残高ピーク比 -15%
DAILY_THRESHOLD = 0.03 # 日次 -3%
WEEKLY_THRESHOLD = 0.05 # 週次 -5%
class Guardian:
def __init__(self, current_balance):
self.state = self._load()
self.balance = current_balance
self.state.setdefault("peak", current_balance)
if current_balance > self.state["peak"]:
self.state["peak"] = current_balance
def _load(self):
if STATE_FILE.exists():
return json.loads(STATE_FILE.read_text(encoding="utf-8"))
return {}
def save(self):
STATE_FILE.write_text(json.dumps(self.state, ensure_ascii=False, indent=2), encoding="utf-8")
def can_open(self):
peak = self.state["peak"]
dd = (peak - self.balance) / peak
if dd >= DD_THRESHOLD:
return False, f"DD {dd:.1%} ≥ {DD_THRESHOLD:.0%}"
# 日次/週次のチェックは省略 (同様のロジック)
return True, "OK"
g = Guardian(current_balance=985_000)
ok, reason = g.can_open()
print(ok, reason)
g.save()
MQL5 実装のポイント
MQL5では AccountInfoDouble(ACCOUNT_BALANCE) で残高、HistorySelect で過去のディール一覧を取得できます。ピーク残高はファイルに保存して再起動後も保持。
double g_peak = 0;
void CheckGuardian() {
double balance = AccountInfoDouble(ACCOUNT_BALANCE);
if (balance > g_peak) g_peak = balance;
double dd = (g_peak - balance) / g_peak;
if (dd >= 0.15) {
ExpertRemove(); // EA停止
Print("Guardian発動: DD=", dd*100, "%");
}
}
停止後の再開条件 (重要)
Guardian発動後、感情で再開すると同じ事を繰り返します。再開条件を事前に文章化することを強く推奨します。例:
- 原因の特定: 戦略劣化 / バグ / 市場構造変化のどれか
- 対応の実装: コード/パラメータ修正済み
- OOS再検証: 直近1ヶ月のデータでバックテスト → 想定範囲内
- 初期ロット: 通常の1/4で1週間運用 → 問題なければ段階増額
運用の現実
私の運用では、Guardianが過去2年で2回発動しました。1回は単純なバグ (ロット計算の小数点ズレ)、もう1回は市場構造変化 (低ボラ環境への戦略不適合)。どちらも事後分析で気づいたもので、Guardianがなければ被害は3倍以上だったと思います。
まとめ
Guardianは「使う日のためだけに毎日動かす保険」です。使わない日が9割以上ですが、使う日に資金の半分を守ります。実装コストは数時間、効果は計り知れません。
コメントを残す