MQL5 EAリスクモデル実装ガイド｜安全な資金管理設計

この記事の結論

MQL5のEAリスクモデルは、エントリー条件とは別に「どれだけの損失を許容するか」を制御する設計です。
固定ロットだけで動かすのではなく、口座残高、有効証拠金、損切り幅、銘柄仕様、ドローダウン状態を組み合わせて判断します。
EAでは、シグナル判定の後にリスク確認を置き、注文前にロット、証拠金、ストップレベル、既存ポジションを確認する構造が扱いやすくなります。
バックテスト結果は将来の利益を保証しないため、実運用前にフォワードテストで約定差、スプレッド拡大、ドローダウンを確認する必要があります。

1. この設計が必要な理由

【結論】
MQL5のEAにリスクモデルが必要な理由は、売買シグナルが正しくても、ロット、損切り、連敗、スプレッド拡大で損失が大きくなる場合があるためです。
EAの品質はエントリー条件だけでは決まりません。
損失をどの範囲に抑えるかを、注文前と保有中の両方で管理する必要があります。

MQL5のEAでは、OnTick で相場データを受け取り、条件判定、リスク確認、注文送信、ポジション管理を順番に行う構造が一般的です。
この流れの中でリスクモデルを独立させると、売買ロジックを変更しても資金管理のルールを維持しやすくなります。

リスクモデルは利益を増やす魔法の仕組みではありません。
リスクモデルの役割は、損失幅、取引頻度、ロット、停止条件を明確にし、検証しやすいEA構造を作ることです。

1.1 リスクモデルが防ぐ主な問題

リスクモデルは、次のような問題を抑えるために使います。

• 損切り幅に対してロットが大きすぎる
• 連敗時も同じ条件で取引を続けてしまう
• スプレッド拡大時に不利な注文を出してしまう
• 証拠金不足や銘柄仕様の違いで注文が失敗する
• バックテストでは許容できたドローダウンが実運用で大きくなる

MQL5のEAでは、シグナルの精度だけでなく、取引条件の悪化に耐えられる設計が重要です。

1.2 エントリーロジックとの分離

リスクモデルは、エントリー方向を決める処理とは分けて設計します。
エントリーロジックは「買うか、売るか、見送るか」を判断します。
リスクモデルは「その注文を出してよいか、どのロットにするか、停止すべきか」を判断します。

この分離により、移動平均クロス、ブレイクアウト、押し目買いなどのロジックを差し替えても、資金管理の基準を保ちやすくなります。

2. EA全体の設計思想

【結論】
MQL5のEAリスクモデルは、相場認識から注文送信までの流れに、複数の安全確認を挟む設計にします。
単一の条件で取引を許可するのではなく、残高、証拠金、損切り幅、スプレッド、ポジション状態を順番に確認します。

EA全体は、次の順序で構成すると管理しやすくなります。

相場認識
↓
フィルター判定
↓
シグナル判定
↓
リスク確認
↓
注文前チェック
↓
注文送信
↓
約定後管理
↓
決済・停止判定

リスクモデルは、この中の「リスク確認」「注文前チェック」「約定後管理」「決済・停止判定」に関係します。
特に自動売買では、想定外の連敗や取引条件の変化をコードで扱える形にしておく必要があります。

2.1 リスクモデルの入力情報

リスクモデルでは、最低限次の情報を使います。

• 口座残高
• 有効証拠金
• 最大許容リスク率
• 損切り幅
• 最小ロット
• 最大ロット
• ロットステップ
• ティックバリュー
• ティックサイズ
• 現在スプレッド
• 既存ポジション数
• 日次損失または累積ドローダウン

これらの値は、口座、銘柄、ブローカー仕様により異なる場合があります。
EAの入力パラメータだけで完結させず、実行時に銘柄仕様を取得して判断する構造が重要です。

2.2 状態管理としてのリスク制御

EAのリスク制御は、単発の if 文だけでは管理しにくくなります。
連敗数、当日の損失、保有中ポジション、停止状態などを状態として保持すると、動作理由を追跡しやすくなります。

例として、EA内部に次の状態を持たせます。

• 通常稼働
• 新規停止
• 決済のみ許可
• 日次損失上限到達
• 最大ドローダウン到達

MQL5のEAでは、OnTick が新しいティックごとに呼ばれるため、状態を毎回確認してから次の処理へ進む構造にします。

3. 基本構造

【結論】
MQL5のEAリスクモデルは、OnInit で初期化し、OnTick で毎回リスク状態を確認し、OnDeinit で必要な後処理を行う構造にします。
インジケータを使う場合は、ハンドル作成と CopyBuffer による値取得を分けて実装します。

基本構造は、次のように分けます。

• 初期化処理
• 相場データ取得
• シグナル判定
• ロット計算
• 取引可否判定
• 注文前チェック
• 注文送信
• ポジション管理
• 停止条件の判定

この分割により、バックテストで問題が出たときに原因を探しやすくなります。

3.1 OnInitの役割

OnInit は、EA起動時の初期化処理です。
インジケータハンドル、入力パラメータの確認、初期残高の記録などを行います。

リスクモデルでは、最大リスク率や損失上限が不自然な値になっていないかを確認します。
不正な設定であれば、INIT_FAILED を返してEAを停止させる設計が安全です。

3.2 OnTickの役割

OnTick は、新しいティックを受信したときに実行されるEAの中心処理です。
リスクモデルでは、毎回のティックで取引許可状態、スプレッド、既存ポジション、口座状況を確認します。

新規注文は、シグナルが出た後にリスク確認を通過した場合だけ送信します。
この順番を守ると、シグナルが出てもリスク条件に合わない取引を見送れます。

3.3 OnDeinitの役割

OnDeinit は、EA停止時の後処理です。
インジケータハンドルを使う場合は、必要に応じて IndicatorRelease で解放します。

リスクモデル自体は後処理が少ない場合もあります。
ただし、ログ出力や一時状態の保存を行う設計では、終了理由を記録すると検証しやすくなります。

4. 主要モジュールの役割

【結論】
EAリスクモデルは、ロット計算、注文前チェック、損失制限、ポジション管理を別モジュールとして扱うと保守しやすくなります。
各モジュールが単一の役割を持つほど、バックテストとフォワードテストで原因分析がしやすくなります。

主要モジュールは、次のように整理できます。

4.1 ロット計算モジュール

ロット計算は、リスクモデルの中心です。
固定ロットだけでは、損切り幅が広い場面や残高が変化した場面でリスクが安定しません。

リスク率ベースの計算では、許容損失額を先に決めます。
その後、損切り幅、ティックバリュー、ティックサイズからロットを計算し、最小ロット、最大ロット、ロットステップに合わせます。

4.2 注文前チェックモジュール

注文前チェックは、OrderSend の前に行う確認です。
MQL5では、MqlTradeRequest に注文内容を入れ、必要に応じて OrderCheck で証拠金や取引条件を確認してから OrderSend を使います。

注文前チェックを入れることで、証拠金不足、無効なロット、ストップレベル違反などを検出しやすくなります。

4.3 損失制限モジュール

損失制限モジュールは、一定以上の損失が発生したときに新規注文を止める処理です。
日次損失、週次損失、最大ドローダウン、連敗数などを条件にできます。

この処理は、相場急変やスプレッド拡大時の損失拡大を抑える目的で使います。
ただし、停止条件を厳しくしすぎると取引機会が大きく減る場合があります。

5. 実装パターン

【結論】
MQL5のEAリスクモデルは、固定ロット、残高比例、リスク率ベース、ボラティリティ調整の順に複雑になります。
中級者向けのEAでは、リスク率ベースを中心にし、必要に応じてATRなどで損切り幅を調整する設計が扱いやすくなります。

実装パターンは、EAの目的と検証段階に応じて選びます。
最初から複雑なモデルにすると、損益変動の原因が分かりにくくなります。

5.1 固定ロット

固定ロットは、常に同じロットで取引する方法です。
実装は簡単ですが、損切り幅が変化するロジックでは、1回あたりの損失額が大きく変わります。

固定ロットは、売買ロジックの初期検証には使いやすい方法です。
ただし、実運用を想定する段階では、残高や損切り幅との関係を確認する必要があります。

5.2 リスク率ベース

リスク率ベースは、1回の取引で許容する損失を口座資金の一定割合にする方法です。
たとえば、有効証拠金の1%を許容損失として、損切り幅からロットを逆算します。

この方法では、損切り幅が広いほどロットは小さくなります。
損切り幅が狭いほどロットは大きくなりますが、最小ロット、最大ロット、ロットステップで必ず補正します。

5.3 ボラティリティ調整

ボラティリティ調整では、ATRなどを使って相場変動に応じた損切り幅やロットを決めます。
MQL5では、iATR でハンドルを作成し、CopyBuffer でATR値を取得する流れになります。

ボラティリティ調整は相場変動を反映しやすい一方で、ATR期間や倍率に依存します。
過去データに合わせすぎると、フォワードテストで崩れやすくなります。

6. サンプルコード

【結論】
MQL5でEAリスクモデルを実装する場合は、ロット計算、銘柄仕様の確認、OrderCheck、OrderSend を分けて書くと安全に検証しやすくなります。
次のコードは検証用の最小構成であり、実運用前には銘柄、時間足、ブローカー条件に合わせた確認が必要です。

以下は、リスク率ベースのロット計算と注文前チェックを含むサンプルです。
売買シグナル部分は簡略化し、リスクモデルの流れを中心にしています。

#property strict

input double RiskPercent = 1.0;
input int StopLossPoints = 300;
input int MaxSpreadPoints = 30;

bool tradingStopped = false;

int OnInit()
{
   if(RiskPercent <= 0.0 || RiskPercent > 5.0)
   {
      Print("RiskPercent is outside the allowed range.");
      return INIT_FAILED;
   }

   if(StopLossPoints <= 0)
   {
      Print("StopLossPoints must be greater than zero.");
      return INIT_FAILED;
   }

   return INIT_SUCCEEDED;
}

void OnDeinit(const int reason)
{
   Print("EA stopped. reason=", reason);
}

void OnTick()
{
   if(tradingStopped)
      return;

   if(!IsSpreadAcceptable())
      return;

   if(PositionSelect(_Symbol))
      return;

   int signal = GetSampleSignal();
   if(signal == 0)
      return;

   double lot = CalculateRiskLot(StopLossPoints);
   if(lot <= 0.0)
      return;

   if(signal > 0)
      SendMarketOrder(ORDER_TYPE_BUY, lot, StopLossPoints);
   else
      SendMarketOrder(ORDER_TYPE_SELL, lot, StopLossPoints);
}

int GetSampleSignal()
{
   MqlTick tick;
   if(!SymbolInfoTick(_Symbol, tick))
      return 0;

   if(tick.ask > tick.bid)
      return 1;

   return 0;
}

bool IsSpreadAcceptable()
{
   MqlTick tick;
   if(!SymbolInfoTick(_Symbol, tick))
      return false;

   double point = SymbolInfoDouble(_Symbol, SYMBOL_POINT);
   if(point <= 0.0)
      return false;

   int spreadPoints = (int)MathRound((tick.ask - tick.bid) / point);
   if(spreadPoints > MaxSpreadPoints)
   {
      Print("Spread is too wide. spreadPoints=", spreadPoints);
      return false;
   }

   return true;
}

double CalculateRiskLot(const int stopLossPoints)
{
   double equity = AccountInfoDouble(ACCOUNT_EQUITY);
   double riskMoney = equity * RiskPercent / 100.0;

   double tickValue = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_VALUE);
   double tickSize = SymbolInfoDouble(_Symbol, SYMBOL_TRADE_TICK_SIZE);
   double point = SymbolInfoDouble(_Symbol, SYMBOL_POINT);

   double minLot = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
   double maxLot = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MAX);
   double lotStep = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);

   if(equity <= 0.0 || riskMoney <= 0.0 || tickValue <= 0.0 || tickSize <= 0.0 || point <= 0.0)
      return 0.0;

   double priceRisk = stopLossPoints * point;
   double lossPerLot = priceRisk / tickSize * tickValue;

   if(lossPerLot <= 0.0)
      return 0.0;

   double rawLot = riskMoney / lossPerLot;
   double normalizedLot = MathFloor(rawLot / lotStep) * lotStep;

   if(normalizedLot < minLot)
   {
      Print("Calculated lot is below minimum lot. lot=", normalizedLot);
      return 0.0;
   }

   if(normalizedLot > maxLot)
      normalizedLot = maxLot;

   return NormalizeDouble(normalizedLot, 2);
}

bool SendMarketOrder(const ENUM_ORDER_TYPE orderType, const double lot, const int stopLossPoints)
{
   MqlTick tick;
   if(!SymbolInfoTick(_Symbol, tick))
      return false;

   double point = SymbolInfoDouble(_Symbol, SYMBOL_POINT);
   int digits = (int)SymbolInfoInteger(_Symbol, SYMBOL_DIGITS);

   double price = 0.0;
   double stopLoss = 0.0;

   if(orderType == ORDER_TYPE_BUY)
   {
      price = tick.ask;
      stopLoss = price - stopLossPoints * point;
   }
   else if(orderType == ORDER_TYPE_SELL)
   {
      price = tick.bid;
      stopLoss = price + stopLossPoints * point;
   }
   else
   {
      return false;
   }

   MqlTradeRequest request;
   MqlTradeResult result;
   MqlTradeCheckResult check;

   ZeroMemory(request);
   ZeroMemory(result);
   ZeroMemory(check);

   request.action = TRADE_ACTION_DEAL;
   request.symbol = _Symbol;
   request.volume = lot;
   request.type = orderType;
   request.price = NormalizeDouble(price, digits);
   request.sl = NormalizeDouble(stopLoss, digits);
   request.deviation = 20;
   request.type_filling = ORDER_FILLING_FOK;

   if(!OrderCheck(request, check))
   {
      Print("OrderCheck failed. retcode=", check.retcode);
      return false;
   }

   if(check.retcode != TRADE_RETCODE_DONE)
   {
      Print("OrderCheck rejected the request. retcode=", check.retcode);
      return false;
   }

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

   if(result.retcode != TRADE_RETCODE_DONE && result.retcode != TRADE_RETCODE_PLACED)
   {
      Print("Order was not completed. retcode=", result.retcode);
      return false;
   }

   return true;
}

6.1 コードの要点

このコードでは、RiskPercent と StopLossPoints からロットを計算します。
計算後に、最小ロット、最大ロット、ロットステップに合わせて補正します。

OrderSend の前に OrderCheck を使うことで、証拠金や注文条件の問題を検出しやすくしています。
ただし、OrderCheck を通過しても、実際の約定時には価格変動や約定方式の影響を受ける場合があります。

6.2 netting口座とhedging口座の違い

MQL5では、口座タイプによりポジション管理の考え方が変わります。
netting口座では、同一銘柄のポジションは基本的に1つに集約されます。
hedging口座では、同一銘柄で複数ポジションを持てる場合があります。

リスクモデルでは、既存ポジションの扱いを口座タイプに合わせる必要があります。
サンプルコードでは簡略化のため、PositionSelect(_Symbol) が真なら新規注文を見送る構造にしています。

7. 設計パターン比較

【結論】
リスクモデルの設計は、単純さ、制御力、検証しやすさのバランスで選びます。
複雑なリスク制御ほど柔軟になりますが、パラメータ依存と過剰最適化のリスクも大きくなります。

7.1 単純な設計を先に検証する

EAのリスクモデルは、単純な設計から検証する方が原因分析しやすくなります。
最初から複数の停止条件やボラティリティ調整を入れると、成績変化の原因が分かりにくくなります。

まずは固定ロットまたはリスク率ベースで売買ロジックの性質を確認します。
その後、ドローダウン停止やスプレッド制限を追加すると、設計変更の効果を比較しやすくなります。

7.2 複雑な制御を入れる条件

複雑な制御は、明確な目的がある場合に入れます。
たとえば、スプレッド拡大時の損失が大きい場合はスプレッド制限を追加します。
連敗後の損失拡大が問題なら、連敗数に応じた新規停止を検討します。

目的が曖昧なパラメータ追加は、過剰最適化につながりやすくなります。

8. バックテストで確認すべき項目

【結論】
バックテストでは、総損益だけでなく、最大ドローダウン、連敗数、損益比、取引回数、スプレッド条件を確認します。
リスクモデルの評価では、利益よりも損失の出方と停止条件の動作を重視します。

バックテストで確認すべき項目は次の通りです。

• 総損益
• 最大ドローダウン
• 勝率
• 損益比
• 取引回数
• 連敗数
• スプレッド条件
• 期間依存性
• パラメータ依存性
• ロット推移
• 証拠金維持率の低下

8.1 最大ドローダウンを見る理由

最大ドローダウンは、資金曲線のピークからどれだけ落ち込んだかを示します。
リスクモデルでは、総損益が良くても最大ドローダウンが大きすぎる場合、実運用に耐えにくい可能性があります。

ドローダウン許容度は、運用資金、取引頻度、レバレッジにより変わります。
レバレッジが高いほど、同じ価格変動でも資金への影響が大きくなりやすくなります。

8.2 パラメータ依存性を見る理由

リスク率、損切り幅、ATR倍率、停止条件を少し変えただけで成績が大きく変わるEAは、再現性が低い可能性があります。
バックテストでは、単一の最良値だけでなく、近い値でも極端に崩れないかを確認します。

パラメータに強く依存する設計は、過去データに合わせすぎている場合があります。
過剰最適化を避けるには、複数期間と複数銘柄で挙動を確認します。

9. フォワードテストで確認すべき項目

【結論】
フォワードテストでは、バックテストでは見えにくい約定差、スプレッド拡大、取引頻度、VPS環境での安定性を確認します。
EAリスクモデルは、実際の取引環境で停止条件と注文前チェックが機能するかを見なければ評価できません。

フォワードテストで確認すべき項目は次の通りです。

• 約定差
• スプレッド拡大時の挙動
• 取引頻度
• ドローダウン
• バックテストとの乖離
• ブローカー差
• VPS環境での安定性
• 注文失敗時のログ
• 日次損失上限の動作
• ポジション管理の安定性

9.1 バックテストとの乖離

バックテストとフォワードテストでは、スプレッド、約定、価格更新、サーバー環境が異なる場合があります。
そのため、バックテストで良い成績でも、フォワードテストで同じ結果になるとは限りません。

リスクモデルでは、損失が想定より大きくなった場面を記録します。
原因がスプレッドなのか、ロット計算なのか、約定差なのかを分けて確認します。

9.2 VPS環境での安定性

EAを継続稼働する場合、VPS環境での接続安定性も確認します。
通信断、再起動、取引サーバーとの遅延により、注文や決済のタイミングが変わる場合があります。

リスクモデルには、EA再起動後も既存ポジションを正しく認識する処理が必要です。
OnInit 後に現在のポジション状態を確認し、内部状態と実口座の状態がずれないようにします。

10. 実運用での注意点

【結論】
実運用では、ブローカー仕様、約定方式、スプレッド、取引可能時間、口座タイプによりEAの挙動が変わる場合があります。
リスクモデルは、バックテストの成績ではなく、実際の取引条件に耐えられるかを確認してから使う必要があります。

実運用では、次の点に注意します。

• スプレッド拡大で成績が悪化する場合がある
• 約定遅延やスリッページが発生する場合がある
• デモ口座とリアル口座で約定条件が異なる場合がある
• ブローカー仕様により最小ロットやストップレベルが異なる
• 取引可能時間外では注文が失敗する場合がある
• 高レバレッジではドローダウンが大きくなりやすい
• バックテスト結果は将来の利益を保証しない

10.1 ストップレベルとフリーズレベル

銘柄には、ストップレベルやフリーズレベルが設定されている場合があります。
損切りや利確の価格が現在価格に近すぎると、注文や変更が拒否されることがあります。

注文前チェックでは、損切り幅が銘柄の取引条件に合っているかを確認します。
条件を満たさない場合は、注文を送信しない設計にします。

10.2 注文失敗時の扱い

注文が失敗した場合に、無条件で再送信を繰り返す設計は避けます。
連続再送信は、相場急変時や接続不安定時に想定外の挙動につながる場合があります。

注文失敗時は、戻り値、リターンコード、スプレッド、価格、ロットをログに残します。
再試行する場合は、回数、間隔、条件を明確に制限します。

11. よくある設計ミス

【結論】
EAリスクモデルでよくある失敗は、固定ロットだけで判断すること、銘柄仕様を見ないこと、注文前チェックを省くことです。
リスク制御は、エントリー条件より後に付け足すのではなく、EA設計の中心に置く必要があります。

よくある設計ミスは次の通りです。

• 損切り幅を使わずにロットを決める
• 最小ロット、最大ロット、ロットステップを確認しない
• ティックバリューとティックサイズを無視する
• スプレッド制限を入れない
• OrderCheck を使わずに注文する
• 口座タイプの違いを考えない
• 連敗時も同じ条件で新規注文を続ける
• バックテストの最良パラメータだけを信じる
• フォワードテストを省略する

11.1 ロット補正不足

計算上のロットが、銘柄のロットステップに合わない場合があります。
たとえば、ロットステップが0.01の銘柄と0.1の銘柄では、補正方法が変わります。

不正なロットを送信すると注文が拒否される場合があります。
そのため、ロット計算後は必ず銘柄仕様に合わせて補正します。

11.2 最新足だけで判断する問題

インジケータを使うEAでは、最新足と確定足の違いに注意します。
最新足はティックごとに値が変わるため、シグナルが頻繁に変化する場合があります。

確定足を使う設計では、CopyBuffer で取得した配列のインデックスに注意します。
ArraySetAsSeries を使う場合、通常は配列インデックス0が最新、配列インデックス1が1本前の足になります。

12. まとめ

【結論】
MQL5のEAリスクモデルは、ロット計算、注文前チェック、損失制限、ポジション管理を分離して設計することが重要です。
エントリー条件が同じでも、リスクモデルの作り方で損失の出方と検証しやすさは大きく変わります。

EAの設計では、売買シグナルの前後にリスク確認を置きます。
特に、損切り幅、許容リスク、銘柄仕様、スプレッド、証拠金、口座タイプを確認する構造が必要です。

バックテストでは、総損益だけでなく最大ドローダウン、連敗数、パラメータ依存性を確認します。
フォワードテストでは、約定差、スプレッド拡大、VPS環境、ブローカー差を確認します。

リスクモデルは利益を保証するものではありません。
リスクモデルは、EAの損失条件を明確にし、実運用前の検証をしやすくするための設計です。

FAQ

Q1. MQL5のEAリスクモデルとは何ですか？

MQL5のEAリスクモデルとは、ロット、損切り、証拠金、ドローダウン、取引停止条件を管理する設計です。売買シグナルとは別に、取引してよい条件を判断します。

Q2. 固定ロットだけでは不十分ですか？

固定ロットは初期検証には使いやすい方法です。ただし、損切り幅や口座資金が変わると1回あたりの損失が安定しないため、実運用を想定する場合はリスク率ベースの検証が必要です。

Q3. OrderSendの前にOrderCheckは必要ですか？

注文前に OrderCheck を使うと、証拠金、ロット、注文条件の問題を検出しやすくなります。OrderCheck を通過しても約定を保証するものではないため、OrderSend 後の結果確認も必要です。

Q4. リスク率は何%にすべきですか？

リスク率は、資金量、ロジックの連敗傾向、許容ドローダウンにより変わります。特定の数値を最適と断定せず、複数条件でバックテストとフォワードテストを行う必要があります。

Q5. netting口座とhedging口座でリスク管理は変わりますか？

変わります。netting口座では同一銘柄のポジションが集約されやすく、hedging口座では複数ポジションを持てる場合があるため、既存ポジションの確認方法とロット管理を口座タイプに合わせます。

Q6. バックテストで特に見るべき項目は何ですか？

バックテストでは、総損益だけでなく、最大ドローダウン、連敗数、損益比、取引回数、スプレッド条件、パラメータ依存性を確認します。リスクモデルでは損失の出方が重要です。

Q7. フォワードテストはなぜ必要ですか？

フォワードテストでは、バックテストでは見えにくい約定差、スプレッド拡大、ブローカー差、VPS環境の安定性を確認できます。実運用前に、注文前チェックと停止条件が実環境で機能するかを見る必要があります。

Q8. ATRを使ったリスクモデルは有効ですか？

ATRを使うと相場変動に合わせて損切り幅やロットを調整しやすくなります。ただし、ATR期間や倍率に依存しやすいため、過剰最適化を避ける検証が必要です。