MQL5 Multi-Logic EA設計を実コードで解説｜LogicSlot・Magic Number・Snapshotを分ける理由

MQL5でEAを拡張していくと、1つのEA内に複数のロジックを入れたくなる場面があります。

たとえば、順張りロジック、逆張りロジック、時間足違いのロジック、買い専用・売り専用ロジック、検証中の追加ロジックなどです。しかし、複数ロジックを1本のEAへ入れる場合、単に条件式を増やすだけでは危険です。

Magic Numberが混ざる、どのロジックのポジションか分からなくなる、決済対象を間違える、同じポジションを複数ロジックが管理してしまう、検証OFFのロジックが実売買へつながる。このような問題を避けるには、LogicSlot・Magic Number・Snapshot・Close Scopeを分けて設計する必要があります。

この記事では、MQL5のMulti-Logic EA設計を、学習用に一般化したコード断片で解説します。完成EAソース全文、外部シート制御、認証、endpoint、token、URL、実運用set値、中核エントリー条件は公開しません。

この記事で扱う範囲

Multi-Logic EAとは

Multi-Logic EAとは、1つのEA内で複数の売買ロジックや管理単位を扱う設計です。

ただし、複数の条件式を1つのOnTick内へ並べるだけでは、Multi-Logic EAとしては不十分です。ロジックごとに、設定、状態、Magic Number、ポジション集計、実行可否、決済対象を分ける必要があります。

複数ロジック化で最も避けたいのは、ロジック追加によって既存ロジックの発注・決済・リスク管理が混線することです。

LogicSlotでロジック単位を固定する

LogicSlotとは、1つのロジックを管理するための単位です。

LogicSlotには、少なくとも次の情報を持たせます。

• logic_id
• 表示名
• 有効・無効
• Magic Number
• trade routeの有効・無効
• 現在の停止理由
• ポジション集計結果

このようにロジック単位を明示すると、Logic1は稼働中、Logic2は監査のみ、Logic3は未接続、というように段階を分けて検証できます。

Magic Numberをロジックごとに分ける理由

MqlTradeRequestのmagicはEA識別用の値として設定できます。Multi-Logic EAでは、LogicSlotごとにMagicを固定し、POSITION_MAGICなど実際の保有状態と突き合わせることで、他ロジックのPositionを誤って自分のSnapshotへ混ぜない設計にします。

Magic Numberは、EAが発注した注文やポジションを識別するために使います。

複数ロジックEAで同じMagic Numberを使い回すと、次のような問題が起きます。

Multi-Logic EAでは、原則としてロジックごとに一意のMagic Numberを持たせます。

Position Snapshotを分ける理由

Position Snapshotとは、現在のポジション状態を集計した一時的な状態情報です。

複数ロジックEAでは、チャート全体のポジションだけでなく、LogicSlotごとのポジション状態を作ることが重要です。

たとえば、Logic1はBUYを1本保有中、Logic2はノーポジション、Logic3はSELLを1本保有中、という状態を分けて確認できる必要があります。

Snapshotを分けずに全体ポジションだけを見ていると、ロジックごとの判定や決済対象を誤りやすくなります。

trade_routeを段階的に接続する

複数ロジックEAでは、新しいロジックを作った直後に実売買へ接続しない方が安全です。

推奨される段階は次の通りです。

この段階を飛ばすと、未検証のロジックが実売買へつながり、既存ロジックへ影響する可能性があります。

Close Scopeを分ける理由

複数ロジックEAでは、決済対象の範囲も明確に分ける必要があります。

たとえば、Logic1のTrail決済がLogic2のポジションを閉じてはいけません。Logic2のシグナルExitがLogic1のポジションを閉じるのも危険です。

そのため、決済処理では次のようなscopeを確認します。

• 対象symbolが一致しているか
• 対象Magic Numberが一致しているか
• 対象方向が一致しているか
• 対象Logic IDとPosition Snapshotが一致しているか
• close対象が現在のLogicSlotの範囲内か

Close Scopeを設計しておくと、決済処理を追加しても他ロジックのポジションを巻き込みにくくなります。

ロジック別riskとEA全体riskを分ける

マルチロジックEAのrisk管理は、各LogicSlotに対するロジック別riskと、EA全体に適用する全体riskを分けて扱います。

ロジック別riskでエントリー可能と判定されても、EA全体の最大ポジション、合計ロット、証拠金、損失制限などにより実行を止める場合があります。

この場合はシグナル不成立を示すNO_SIGNALではなく、RISK_BLOCKとして記録します。ログにはlogic_id、Magic Number、停止理由、現在値、上限値を残すと、どの段階で止まったか確認しやすくなります。

実コード断片1：LogicSlot定義

以下は、実際のEAで使う考え方を学習用に簡略化したコード例です。完成EAのソース全文ではなく、構造を理解するための抜粋です。

// 学習用に一般化したLogicSlot定義例です。
// 実運用EAの完成ソースではありません。

struct LogicSlot
{
   int    id;
   string name;
   long   magic;
   bool   enabled;
   bool   tradeRouteEnabled;
   string runtimeReason;
};

#define LOGIC_COUNT 3

LogicSlot g_logicSlots[LOGIC_COUNT];

void InitLogicSlots()
{
   g_logicSlots[0].id = 1;
   g_logicSlots[0].name = "Logic1";
   g_logicSlots[0].magic = 910001;
   g_logicSlots[0].enabled = true;
   g_logicSlots[0].tradeRouteEnabled = true;
   g_logicSlots[0].runtimeReason = "OK";

   g_logicSlots[1].id = 2;
   g_logicSlots[1].name = "Logic2";
   g_logicSlots[1].magic = 910002;
   g_logicSlots[1].enabled = true;
   g_logicSlots[1].tradeRouteEnabled = false;
   g_logicSlots[1].runtimeReason = "AUDIT_ONLY";

   g_logicSlots[2].id = 3;
   g_logicSlots[2].name = "Logic3";
   g_logicSlots[2].magic = 910003;
   g_logicSlots[2].enabled = false;
   g_logicSlots[2].tradeRouteEnabled = false;
   g_logicSlots[2].runtimeReason = "DISABLED";
}

実際のEAでは、認証、外部制御、口座条件、エラー処理、ログ出力などを分けて設計します。この記事では、公開できる範囲の構造だけを取り上げています。

このコードの役割

Logic2のように、ロジックは有効でも実売買は無効にし、audit onlyとしてログ確認だけ行う段階を作れます。

実コード断片2：Magic Number重複を確認する

以下は、LogicSlotごとのMagic Numberが重複していないか確認する学習用コード例です。

// 学習用に一般化したMagic重複チェック例です。
// 実運用EAの完成ソースではありません。

bool ValidateLogicMagicNumbers()
{
   for(int i = 0; i < LOGIC_COUNT; i++)
   {
      if(g_logicSlots[i].magic <= 0)
      {
         Print("DIAG/LOGIC: event=VALIDATION_FAIL",
               " logic=", g_logicSlots[i].name,
               " reason=INVALID_MAGIC");
         return false;
      }

      for(int j = i + 1; j < LOGIC_COUNT; j++)
      {
         if(g_logicSlots[i].magic == g_logicSlots[j].magic)
         {
            Print("DIAG/LOGIC: event=VALIDATION_FAIL",
                  " reason=DUPLICATE_MAGIC",
                  " logic_a=", g_logicSlots[i].name,
                  " logic_b=", g_logicSlots[j].name);
            return false;
         }
      }
   }

   Print("DIAG/LOGIC: event=VALIDATION_OK",
         " reason=UNIQUE_MAGIC");

   return true;
}

実際のEAでは、認証、外部制御、口座条件、エラー処理、ログ出力などを分けて設計します。この記事では、公開できる範囲の構造だけを取り上げています。

このコードの役割

Magic Number重複は、複数ロジックEAで特に避けたい事故です。起動時に検出し、問題がある場合は安全側で停止または対象ロジックを無効化します。

実コード断片3：ロジック別Position Snapshot

以下は、Magic Number単位で現在ポジションを集計する考え方を簡略化した例です。売買判断や中核Entry条件は含めていません。

// 学習用に一般化したPosition Snapshot例です。
// 実運用EAの完成ソースではありません。

struct PositionSnapshot
{
   int    count;
   int    buyCount;
   int    sellCount;
   double totalVolume;
   double floatingProfit;
   bool   hasPosition;
};

PositionSnapshot BuildPositionSnapshotForMagic(long magic)
{
   PositionSnapshot snap;
   snap.count = 0;
   snap.buyCount = 0;
   snap.sellCount = 0;
   snap.totalVolume = 0.0;
   snap.floatingProfit = 0.0;
   snap.hasPosition = false;

   for(int i = PositionsTotal() - 1; i >= 0; i--)
   {
      ulong ticket = PositionGetTicket(i);

      if(ticket == 0)
         continue;

      if(!PositionSelectByTicket(ticket))
         continue;

      if(PositionGetString(POSITION_SYMBOL) != _Symbol)
         continue;

      if((long)PositionGetInteger(POSITION_MAGIC) != magic)
         continue;

      long type = PositionGetInteger(POSITION_TYPE);
      double volume = PositionGetDouble(POSITION_VOLUME);
      double profit = PositionGetDouble(POSITION_PROFIT);

      snap.count++;
      snap.totalVolume += volume;
      snap.floatingProfit += profit;

      if(type == POSITION_TYPE_BUY)
         snap.buyCount++;

      if(type == POSITION_TYPE_SELL)
         snap.sellCount++;
   }

   snap.hasPosition = (snap.count > 0);
   return snap;
}

実際のEAでは、認証、外部制御、口座条件、エラー処理、ログ出力などを分けて設計します。この記事では、公開できる範囲の構造だけを取り上げています。

このコードの役割

このようにSnapshotを作っておくと、各LogicSlotが自分のMagic Numberのポジションだけを確認できます。

実コード断片4：LogicSlotを順番に監査する

以下は、複数LogicSlotを順番に確認し、audit logを出す学習用コード例です。発注処理や中核エントリー条件は含めていません。

// 学習用に一般化したLogicSlot監査例です。
// 実運用EAの完成ソースではありません。

void PrintLogicAudit(const LogicSlot &slot,
                     const PositionSnapshot &snap,
                     string eventName,
                     string reason)
{
   Print("DIAG/LOGIC_AUDIT: logic=", slot.name,
         " magic=", slot.magic,
         " event=", eventName,
         " reason=", reason,
         " pos_count=", snap.count,
         " buy=", snap.buyCount,
         " sell=", snap.sellCount,
         " trade_route=", slot.tradeRouteEnabled);
}

void RunLogicSlotAudit()
{
   for(int i = 0; i < LOGIC_COUNT; i++)
   {
      LogicSlot slot = g_logicSlots[i];
      PositionSnapshot snap = BuildPositionSnapshotForMagic(slot.magic);

      if(!slot.enabled)
      {
         PrintLogicAudit(slot, snap, "SKIP", "LOGIC_DISABLED");
         continue;
      }

      if(!slot.tradeRouteEnabled)
      {
         PrintLogicAudit(slot, snap, "AUDIT_ONLY", slot.runtimeReason);
         continue;
      }

      PrintLogicAudit(slot, snap, "READY", "TRADE_ROUTE_ENABLED");

      // 実際のEAでは、この後にsignal / guard / executionを分けて設計します。
      // この記事では中核エントリー条件と発注処理は扱いません。
   }
}

実際のEAでは、認証、外部制御、口座条件、エラー処理、ログ出力などを分けて設計します。この記事では、公開できる範囲の構造だけを取り上げています。

このコードの役割

新しいロジックを追加する場合、いきなり実売買へ接続せず、このようなaudit段階を挟むことで安全に検証できます。

実コード断片5：Close ScopeをMagicで限定する

以下は、決済対象をLogicSlotのMagic Numberに限定する考え方を示した学習用コード例です。実際の決済送信処理は含めていません。

// 学習用に一般化したClose Scope確認例です。
// 実運用EAの完成ソースではありません。

bool IsPositionInLogicScope(ulong ticket, const LogicSlot &slot)
{
   if(ticket == 0)
      return false;

   if(!PositionSelectByTicket(ticket))
      return false;

   if(PositionGetString(POSITION_SYMBOL) != _Symbol)
      return false;

   if((long)PositionGetInteger(POSITION_MAGIC) != slot.magic)
      return false;

   return true;
}

void PlanCloseForLogic(const LogicSlot &slot)
{
   int targetCount = 0;

   for(int i = PositionsTotal() - 1; i >= 0; i--)
   {
      ulong ticket = PositionGetTicket(i);

      if(!IsPositionInLogicScope(ticket, slot))
         continue;

      targetCount++;

      Print("DIAG/CLOSE_SCOPE: logic=", slot.name,
            " event=TARGET_FOUND",
            " ticket=", ticket,
            " magic=", slot.magic);
   }

   Print("DIAG/CLOSE_SCOPE: logic=", slot.name,
         " event=PLAN_SUMMARY",
         " target_count=", targetCount);
}

実際のEAでは、認証、外部制御、口座条件、エラー処理、ログ出力などを分けて設計します。この記事では、公開できる範囲の構造だけを取り上げています。

このコードの役割

実際の決済処理を行う前に、対象scopeをログで確認できるようにしておくと、誤決済の確認がしやすくなります。

Magic Numberを注文・ポジション・履歴で照合する

以下のコード例は、個別の処理と確認項目を読むためのものです。複数の例をそのまま一つのEAへ連結する前提ではありません。初期化、値の取得、状態更新、終了処理をそれぞれの例で区別して確認してください。

Magic Numberとは何か

Magic Numberは、EAが自分の注文やポジションを識別するために使う番号です。

MQL5では、発注時にMagic Numberを設定し、その後のポジション確認、注文履歴、約定履歴、決済対象判定で参照します。Magic Numberを使うことで、同じ口座内に複数のEAや裁量注文が混在していても、どの注文をどの処理対象にするかを分けやすくなります。

Magic Numberは、発注時に設定して終わりではありません。EAの運用では、発注、保有中ポジション、決済、履歴確認、ログ出力まで一貫して追跡できる形にしておくことが重要です。

Magic Number設計で最初に決めること

Magic Numberを決める時は、番号そのものよりも、何を分けたいのかを先に整理します。

特に、複数EA運用、複数ロジックEA、コピーEA、半裁量EAでは、Magic Numberが決済対象や履歴集計の基準になります。番号を後から変えると、既存ポジションとの整合が崩れる場合があるため、開発初期に設計しておく必要があります。

複数EA運用でのMagic Number設計

同じMT5口座で複数EAを動かす場合、EAごとに異なるMagic Numberを使うのが基本です。

たとえば、トレンド系EA、レンジ系EA、コピーEA、決済補助ツールを同じ口座で使う場合、それぞれが同じMagic Numberを使っていると、ポジション検索、決済、履歴確認の対象が混ざりやすくなります。

複数EAを同じ口座で運用する時は、EA名、設置チャート、対象銘柄、時間足、Magic Number、決済対象、コピー対象を一覧化しておくと、後から確認しやすくなります。

CTradeでMagic Numberを設定する場合

CTradeを使う場合は、通常、注文前にSetExpertMagicNumber()でMagic Numberを設定します。

CTrade trade;

int OnInit()
{
   trade.SetExpertMagicNumber(10001);
   return INIT_SUCCEEDED;
}

void OpenBuy()
{
   trade.Buy(0.10, _Symbol);
}

このように設定しておくと、CTrade経由の注文にMagic Numberを付与できます。ただし、EA内で複数ロジックを扱う場合は、注文直前にどのMagic Numberを使うのかを明確にする必要があります。

void OpenByLogic(const int logic_id)
{
   long magic = 0;

   if(logic_id == 1)
      magic = 11001;
   else if(logic_id == 2)
      magic = 12001;
   else
      return;

   trade.SetExpertMagicNumber(magic);
   trade.Buy(0.10, _Symbol);
}

CTradeを使う場合の注意点は、EA全体で1つのCTradeインスタンスを使っている時に、直前に設定したMagic Numberが次の注文にも影響する可能性があることです。複数ロジックで使う場合は、発注直前にMagic Numberを設定し、ログにも記録しておくと確認しやすくなります。

MqlTradeRequestでMagic Numberを設定する場合

MqlTradeRequestを直接使う場合は、request.magicへMagic Numberを設定します。

MqlTradeRequest request;
MqlTradeResult  result;

ZeroMemory(request);
ZeroMemory(result);

request.action  = TRADE_ACTION_DEAL;
request.symbol  = _Symbol;
request.volume  = 0.10;
request.type    = ORDER_TYPE_BUY;
request.price   = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
request.magic   = 10001;
request.comment = "EAFC_L1_BUY";

OrderSend(request, result);

MqlTradeRequestでは、注文要求の各項目を明示的に設定できます。そのため、Magic Number、注文コメント、type_filling、deviation、SL / TP、発注理由ログを細かく制御したい場合に向いています。

CTradeは簡潔に注文処理を書きたい場合に向いています。一方、MqlTradeRequestは、注文内容、結果、ログ、チェック処理を細かく制御したい場合に向いています。Magic Numberをどこで設定するかも、この使い分けに合わせて決めます。

Magic 0と裁量注文の扱い

MT5では、裁量注文やMagic Numberを設定していない注文がMagic 0として扱われることがあります。

EA側でMagic 0をどのように扱うかは、必ず仕様として決めておく必要があります。特に、裁量注文をEAの決済対象に含めるのか、完全に除外するのか、監視だけするのかを曖昧にしないことが重要です。

安全側にするなら、通常の自動売買EAではMagic 0を決済対象から除外します。半裁量EAやコピーEAでMagic 0を扱う場合は、設定名、ログ、マニュアルで「裁量注文を対象にする」ことが分かるようにしておく必要があります。

POSITION_MAGICでポジションを絞り込む

EAが保有中ポジションを処理する時は、POSITION_MAGICを確認して対象を絞り込みます。

bool IsMyPosition(const ulong ticket, const long expected_magic)
{
   if(!PositionSelectByTicket(ticket))
      return false;

   string symbol = PositionGetString(POSITION_SYMBOL);
   long magic    = PositionGetInteger(POSITION_MAGIC);

   if(symbol != _Symbol)
      return false;

   if(magic != expected_magic)
      return false;

   return true;
}

この確認を入れずにポジションを処理すると、同じ口座内の別EAや裁量ポジションまで決済対象に入る可能性があります。特に、一括決済、トレーリングストップ、ナンピン、損益合算、Basket管理では、Magic Numberの絞り込みが重要です。

複数ロジックEAではLogicごとにMagicを分ける

1つのEAにTrend、Reverse、Range、Breakoutなど複数ロジックを入れる場合、EA単位だけでなく、ロジック単位でMagic Numberを分ける設計が有効です。

複数ロジックEAでMagic Numberを1つにしてしまうと、どのロジックが建てたポジションなのか、どのロジックの決済対象なのか、どの履歴を検証すべきなのかが分かりにくくなります。

このように分けておくと、ポジション確認、決済、履歴集計、バックテスト分析、ログ確認がしやすくなります。

Magic Numberの番号体系を決める

Magic Numberは、重複しなければよいというだけではありません。後から見た時に意味が分かる番号体系にしておくと、ログ確認や問い合わせ対応がしやすくなります。

番号体系を決める時は、桁数をそろえる、EA IDとロジックIDを分ける、検証環境と運用環境を混同しない、将来のロジック追加分を残す、といった観点で整理します。

たとえば、10000番台をEA A、20000番台をEA B、下2桁をロジック番号にするなど、ルールを決めておくと、ログやCSVを見た時に原因を追いやすくなります。

注文・ポジション・約定履歴で確認するMagic

Magic Numberは、発注時だけでなく、注文、ポジション、約定履歴で確認します。

発注前、発注結果、保有中ポジション、履歴確認を分けて確認すると、Magic Numberの設定漏れや対象外ポジションの混入を見つけやすくなります。

約定履歴をMagic Numberで確認する

バックテストや運用後の確認では、保有中ポジションだけでなく、履歴側のMagic Numberも確認します。

ポジションがすでに決済されている場合、現在のポジション一覧だけでは原因を追えません。注文履歴や約定履歴を確認し、どのMagic Numberが、どの注文を出し、どの約定につながったのかを追跡します。

void PrintDealMagic(const datetime from_time, const datetime to_time)
{
   if(!HistorySelect(from_time, to_time))
      return;

   int total = HistoryDealsTotal();

   for(int i = 0; i < total; i++)
   {
      ulong deal_ticket = HistoryDealGetTicket(i);
      long magic = HistoryDealGetInteger(deal_ticket, DEAL_MAGIC);
      string symbol = HistoryDealGetString(deal_ticket, DEAL_SYMBOL);
      double volume = HistoryDealGetDouble(deal_ticket, DEAL_VOLUME);

      Print("DEAL_MAGIC_CHECK",
            " ticket=", deal_ticket,
            " symbol=", symbol,
            " magic=", magic,
            " volume=", DoubleToString(volume, 2));
   }
}

履歴確認を行う時は、対象期間、対象銘柄、対象Magic Number、注文コメント、deal ticket、order ticketを一緒に出すと、発注から約定までの流れを追いやすくなります。

Hedging / Netting口座での注意点

MT5には、Hedging口座とNetting口座があります。Magic Numberの扱いでも、口座方式の違いを意識する必要があります。

Hedging口座では、ポジションごとにMagic Numberを確認しやすい一方、複数ポジションをまとめて決済する処理では対象範囲を慎重に絞る必要があります。

Netting口座では、同一銘柄のポジションが統合されるため、複数EAや複数ロジックを同じ銘柄で動かす場合に、Magic Numberだけで期待どおりに分離できるかを検証する必要があります。

コピーEAでのinclude / exclude設計

コピーEAでは、Magic Numberをコピー対象の選別条件として使うことがあります。

たとえば、コピー元口座に複数EAや裁量注文が混在している場合、すべてのポジションをコピーするのではなく、特定のMagic Numberだけをコピーする、または特定のMagic Numberを除外する設計が必要になることがあります。

コピーEAでMagic Numberを使う場合は、コピー元とコピー先のどちらのMagic Numberを見るのか、コピー先でMagic Numberを引き継ぐのか、コピー先専用Magicに置き換えるのかを事前に決めておく必要があります。

OrderCheckとMagic Numberの関係

OrderCheckは、発注前に証拠金、ロット、StopLevelなどを確認するための処理です。Magic Numberそのものの妥当性を保証するものではありません。

そのため、OrderCheckを通過しても、Magic Numberが間違っていれば、意図しないEAやロジックの注文として記録される可能性があります。発注前チェックでは、取引条件だけでなく、対象Magic Numberもログに出して確認することが大切です。

OrderCheckは発注条件の確認、Magic Numberは注文やポジションの識別という役割で分けて考えると、実装とログ確認を整理しやすくなります。

よくある失敗例

失敗1：複数ロジックで同じMagic Numberを使う

同じMagic Numberを使うと、ポジション集計、決済対象、損益集計が混ざります。Multi-Logic EAでは、LogicSlotごとに一意のMagic Numberを持たせることが基本です。

失敗2：Position Snapshotを全体集計だけにする

全体ポジションだけを見ると、どのロジックが何を保有しているのか分かりません。LogicSlotごとにSnapshotを作る必要があります。

失敗3：audit onlyを挟まずに実売買へ接続する

新しいロジックを追加した直後にtrade routeを有効化すると、想定外の発注や既存ロジックへの影響が出る可能性があります。まずはaudit onlyでログ確認します。

失敗4：決済scopeが広すぎる

symbolだけで決済対象を選ぶと、他Magicのポジションまで巻き込む可能性があります。symbol、magic、logic_idの対応を確認します。

失敗5：enabledとtradeRouteEnabledを混同する

ロジックを検証対象として有効にすることと、実売買へ接続することは別です。enabled=trueでもtradeRouteEnabled=falseにして、監査だけ行う段階を持つと安全です。

失敗6：ログにlogic_idやmagicを出していない

複数ロジックEAでは、ログにlogic_idやmagicが出ていないと、どのロジックの処理か分かりません。LOGIC_AUDIT、CLOSE_SCOPE、ORDERログなどに識別情報を含めます。

失敗7：ロジック間で状態変数を共有する

複数ロジックでsignal、candidate、execution、Position Snapshotなどの状態変数を使い回すと、別ロジックの状態が混入する可能性があります。状態はLogicSlot単位で保持し、EA全体で共有する値とは明確に分離します。

ログで確認するポイント

Multi-Logic EAでは、Expertsログで次の情報を確認できると原因を確認しやすくなります。

ログ確認の基本は、次のページも参考にしてください。

MT5のログ確認方法｜Experts・Journalの見方

Magic Numberの運用変更と検証記録

以下のコード例は、個別の処理と確認項目を読むためのものです。複数の例をそのまま一つのEAへ連結する前提ではありません。初期化、値の取得、状態更新、終了処理をそれぞれの例で区別して確認してください。

ログに残すべきMagic Number関連項目

Magic Numberの不具合は、見た目だけでは分かりにくいことがあります。発注したつもりのEAと、実際にポジションを処理しているEAが違う場合、ログで追跡できなければ原因調査が難しくなります。

ログでは、Magic Numberだけでなく、symbol、ticket、order、deal、logic_id、position type、volume、comment、retcodeを一緒に残すと確認しやすくなります。

ログ出力例

Magic Number関連のログは、発注前、発注結果、ポジション走査、対象外スキップの各段階で出すと原因を追いやすくなります。

Print("MAGIC_SET",
      " symbol=", _Symbol,
      " logic_id=", logic_id,
      " magic=", magic,
      " lot=", DoubleToString(lot, 2));

Print("POSITION_SCAN",
      " ticket=", ticket,
      " symbol=", symbol,
      " magic=", pos_magic,
      " volume=", DoubleToString(volume, 2));

if(pos_magic != expected_magic)
{
   Print("MAGIC_MISMATCH",
         " ticket=", ticket,
         " expected=", expected_magic,
         " actual=", pos_magic,
         " action=POSITION_SKIP");
}

このようにログを分けておくと、「注文時点でMagicが違った」のか、「保有ポジションの確認時に対象外として除外した」のか、「履歴側で想定外のMagicになっていた」のかを原因を確認しやすくなります。

よくある失敗パターン

Magic Number設計でよくある失敗は、番号の重複だけではありません。発注、決済、履歴、コピー、裁量注文の扱いがそろっていないことが問題になります。

Magic Numberの不具合は、発注直後には気づかず、決済時、コピー時、バックテスト分析時に表面化することがあります。そのため、発注段階からログに残す設計が重要です。

開発・改修依頼前に整理したい項目

EA開発や既存EA改修を依頼する場合は、Magic Numberの扱いを事前に整理しておくと、仕様の認識違いを減らせます。

開発や改修の相談では、Magic Numberだけでなく、対象銘柄、時間足、ポジション数、決済条件、コピー対象、ログ確認方法も合わせて整理してください。

実務チェックリスト

• EAごとのMagic Numberを一覧化した
• 同じ口座で使う他EAとMagic Numberが重複していないことを確認した
• CTradeを使う場合、発注前にSetExpertMagicNumber()を呼ぶ位置を確認した
• MqlTradeRequestを使う場合、request.magicに意図した値を設定していることを確認した
• ポジション処理時にPOSITION_MAGICで対象を絞り込んでいる
• Magic 0を裁量注文として扱うのか、EA対象に含めるのかを決めた
• 複数ロジックEAでは、logic_idとMagic Numberをセットで管理している
• コピーEAでは、include / exclude対象のMagic Numberを決めた
• Hedging / Netting口座で期待どおりに対象判定できるか確認した
• 発注前、ポジション確認、履歴確認のログにMagic Numberを出している

Magic Number設計を後から変更する時の注意点

Magic Numberは、EAを公開した後や、すでにポジションを保有している状態で簡単に変更すべき項目ではありません。新しい注文だけを見ると問題がないように見えても、既存ポジション、履歴集計、コピーEA、決済補助ツール、バックテスト結果との整合が崩れることがあります。

特に、稼働中EAのMagic Numberを変更すると、変更前に建てたポジションをEAが自分の管理対象として認識できなくなる場合があります。その結果、決済対象から外れる、トレーリング対象から外れる、ナンピン管理の対象外になる、履歴集計で別EA扱いになる、といった問題が起きます。

Magic Numberを変更する場合は、単にinput値を変更するだけでなく、既存ポジションをどう扱うか、履歴をどう読むか、ログ上で変更前後をどう区別するかまで決めておく必要があります。販売用EAや購入者向けEAでは、Magic Number変更時の注意点をマニュアルやHELPにも記載しておくと、問い合わせ時の確認がしやすくなります。

Magic Numberと注文コメントを併用する理由

Magic NumberだけでもEAの識別はできますが、実務上は注文コメントも併用すると確認しやすくなります。Magic Numberは機械的な識別番号として使い、注文コメントは人間がログや履歴を見た時に意味を理解しやすくする補助情報として使います。

たとえば、Magic Numberが11001だけでは、どのEAのどのロジックなのかをすぐに判断できない場合があります。注文コメントにEA名、ロジック名、方向、バージョン、検証区分などを短く入れておくと、履歴確認や問い合わせ対応で役立ちます。

ただし、注文コメントはブローカーや取引環境によって一部変更されたり、長すぎる文字列が切り詰められたりする場合があります。そのため、識別の主軸はMagic Numberに置き、コメントは補助情報として扱うのが安全です。

Magic Number設計とバックテスト確認

Magic Numberは、実運用だけでなくバックテスト確認でも重要です。複数ロジックEAや複数設定を比較する場合、Magic Number、注文コメント、ロジックIDが整理されていないと、どのロジックがどの損益を出したのか、どの条件で注文されたのかを後から確認しにくくなります。

バックテストでは、最終損益だけでなく、注文履歴、約定履歴、Expertsログ、CSVログを確認します。Magic Numberをログに出しておくことで、複数ロジックの成績を分けて確認したり、対象外ポジションを誤って処理していないか確認したりできます。

バックテストでは、同じEAを何度も設定変更して検証することがあります。その場合、Magic Numberを毎回変えるべきか、同じEAとして固定するべきかは検証目的によって異なります。ロジック別に比較したい場合はMagicを分け、同一ロジックのパラメータ差を比較したい場合は、Magicだけでなくsetファイル名やログ上の設定名も合わせて記録してください。

Magic Numberをinputにするか固定値にするか

EA開発では、Magic Numberをinputで変更できるようにするか、ソース内の固定値として扱うかも設計対象になります。

検証用EAや開発中EAでは、Magic Numberをinputにしておくと、複数チャートや複数条件でテストしやすくなります。一方、販売用EAや利用者向け配布版版では、購入者が不用意に変更して既存ポジションとの整合を崩す可能性もあるため、表示名、初期値、マニュアル説明、変更時の注意を整える必要があります。

Magic Numberをinputにする場合は、Inputs画面で意味が分かる名前にし、初期値と変更時の注意を明確にします。たとえば「EA識別番号」「ロジック1用Magic Number」「コピー対象Magic」など、用途が分かる表記にすると、設定ミスを減らしやすくなります。

問い合わせ時に確認したいMagic Number情報

EAの注文や決済に関する問い合わせでは、Magic Numberの情報が不足していると原因の確認が難しくなります。単に「EAが決済しない」「別ポジションを触ったように見える」という説明だけでは、EA側の対象判定、裁量注文、別EA、コピーEA、口座方式のどこに原因があるか判断しにくくなります。

問い合わせ前には、Expertsログ、取引履歴、対象ポジションのticket、Magic Number、注文コメント、EA設定画面のスクリーンショットを整理しておくと、確認がスムーズになります。口座番号、認証情報、個人情報、Webhook URL、APIキーなどは共有しないでください。

開発依頼前に整理する情報

複数ロジックEAの開発や改修を依頼する場合、次の情報を先に整理しておくと仕様のすれ違いを減らせます。

• ロジック数
• 各ロジックの役割
• 各ロジックのMagic Number
• 同時稼働するか、どれか1つだけ動くか
• BUY / SELLの扱い
• 各ロジックの保有上限
• 各ロジックの決済scope
• 全体リスク管理とロジック別リスク管理の関係
• 新規ロジックはaudit onlyから始めるか
• ログに出すlogic_id、magic、reasonの粒度

仕様書、setファイル、ログ、スクリーンショットを整理する場合は、次のページも確認してください。

MT5開発依頼前に用意する資料まとめ｜仕様書・setファイル・ログ・スクリーンショット

公開しない情報

この記事では、MQL5のMulti-Logic EA設計を学ぶために、公開可能な範囲だけを一般化して解説しています。以下は公開しません。

• 完成EAソース全文
• 外部シート参照による動作制御ロジック
• 外部シートCSV取得、解析、時間枠、方向制御ロジック
• 認証、口座許可判定、購入者管理ロジック
• endpoint、token、URL、Google Sheet ID、Webhook URL、GAS URL
• APIキー、認証トークン、口座番号、サーバー名
• 実運用set値
• 中核エントリー条件
• 中核Trail / Nanpin判定
• 独自優位性のある売買判定式
• 利益保証、勝率保証、推奨ロット、推奨銘柄、推奨エントリー

本記事は、投資判断や売買指示ではなく、MQL5開発におけるMulti-Logic EAの構造、Magic Number、Snapshot、Close Scopeを理解するための技術解説です。

よくある質問

Multi-Logic EAとは何ですか？

1つのEA内で複数のロジックや管理単位を扱うEAです。複数条件を並べるだけではなく、LogicSlot、Magic Number、Snapshot、Close Scopeを分けて管理する必要があります。

ロジックごとにMagic Numberを分ける必要がありますか？

基本的には分けるべきです。同じMagic Numberを使うと、ポジション集計や決済対象が混ざり、誤決済や検証不能につながる可能性があります。

enabledとtradeRouteEnabledは何が違いますか？

enabledはロジック自体を確認対象にするかどうか、tradeRouteEnabledは実売買へ接続するかどうかです。enabled=trueでもtradeRouteEnabled=falseなら、audit onlyとしてログ確認だけ行えます。

Position Snapshotはなぜ必要ですか？

ロジックごとの保有数、方向、ロット、損益を分けて確認するためです。全体集計だけでは、どのロジックのポジションか確認にくくなります。

Close Scopeとは何ですか？

決済対象の範囲です。Multi-Logic EAでは、symbolだけでなくMagic NumberやLogicSlot単位で対象を限定し、他ロジックのポジションを巻き込まないようにします。

新しいロジックはすぐ実売買へ接続してよいですか？

避けた方が安全です。まずはLogicSlot定義、Snapshot確認、audit only、pre-route gateの順に進め、ログ確認後にtrade routeを有効化する流れが安全です。

このコードは完成EAとして使えますか？

いいえ。この記事のコード例は、Multi-Logic EA設計の考え方を理解するために簡略化した学習用コードです。完成EAとしてそのまま使うことは想定していません。

実際のEAソース全文は公開されていますか？

公開していません。完成EAソース全文、外部シート制御、認証、endpoint、token、URL、実運用set値、中核エントリー条件は公開対象外です。

関連する確認ページ

確認したい内容に応じて、次のページを参照してください。本文中ですでに案内したページは、ここでは重ねて掲載していません。

あわせて確認したいページ

今回の確認内容に関連する補足ページです。必要な項目だけ確認してください。

まとめ

MQL5でMulti-Logic EAを設計する時は、複数の条件式を1つのEAへ並べるだけでは不十分です。

特に、次の4点を分けておくと、誤発注・誤決済・検証不能を防ぎやすくなります。

• LogicSlot：ロジックごとの設定・状態・実行可否を管理する
• Magic Number：注文とポジションをロジック単位で識別する
• Position Snapshot：ロジック別の保有数・方向・損益を固定して確認する
• Close Scope：決済対象をsymbolとmagicで限定する

新しいロジックを追加する時は、いきなり実売買へ接続せず、defined、snapshot only、audit only、pre-route gate、trade route enableのように段階を分けて検証すると安全です。

完成EAの中核ロジックを公開しなくても、LogicSlot、Magic Number、Snapshot、Close Scopeの考え方を理解しておくことで、複数ロジックEAの設計・検証・不具合調査がしやすくなります。

お問い合わせはEAFC公式LINEへ

EAFCサイト内の記事、商品、導入前確認、設定確認、ログ確認、開発依頼前のご相談など、各種お問い合わせはEAFC公式LINEより受け付けています。

※投資助言、売買指示、利益保証、推奨ロット、推奨銘柄の案内は行っておりません。

口座番号、認証情報、Webhook URL、GAS URL、APIキーなどの機密情報は送信しないでください。

利用条件・相談窓口