MT5 EAのMagic Number設計｜複数EA・複数ロジック・コピーEAで分ける考え方

MT5でEAを複数使う場合や、1つのEAに複数ロジックを入れる場合は、Magic Numberの設計が重要になります。

Magic Numberは、EAが注文、ポジション、約定履歴を識別するために使う番号です。ただし、単に「EAごとの番号」と考えるだけでは不十分です。複数EA、複数ロジック、コピーEA、裁量注文、決済対象、履歴集計、ログ確認を分けるための管理キーとして設計する必要があります。

Magic Numberの設計が曖昧なままEAを動かすと、別EAのポジションを決済する、裁量ポジションをEAが拾う、コピー対象外の注文まで同期する、複数ロジックの履歴が混ざる、ナンピンや一括決済の対象を誤る、といった問題につながる場合があります。

このページでは、MT5 EAのMagic Number設計を、複数EA運用、CTrade、MqlTradeRequest、POSITION_MAGIC、注文履歴、Hedging / Netting口座、コピーEA、ログ確認の観点から整理します。

なお、このページはMT5 / MQL5開発における技術確認を目的とした内容です。売買判断、推奨エントリー、推奨ロット、利益保証、損失回避保証を行うものではありません。

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は注文やポジションの識別という役割で分けて考えると、実装とログ確認を整理しやすくなります。

ログに残すべき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やUserLive版では、購入者が不用意に変更して既存ポジションとの整合を崩す可能性もあるため、表示名、初期値、マニュアル説明、変更時の注意を整える必要があります。

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キーなどは共有しないでください。

関連ページ

まとめ

MT5 EAのMagic Numberは、EAを識別するための番号であると同時に、複数EA、複数ロジック、コピーEA、裁量注文、決済対象、履歴確認を分けるための重要な管理キーです。

CTradeを使う場合はSetExpertMagicNumber()、MqlTradeRequestを使う場合はrequest.magicを確認し、保有中ポジションではPOSITION_MAGIC、注文・約定履歴ではORDER_MAGICやDEAL_MAGICを確認します。

複数EA運用や複数ロジックEAでは、Magic Numberの重複を避けるだけでなく、番号体系、Magic 0の扱い、Hedging / Netting口座、コピーEAのinclude / exclude条件、ログ項目まで含めて整理してください。

Magic Number設計を先に決めておくと、誤決済、誤コピー、履歴混在、問い合わせ時の原因不明を減らしやすくなります。EAを導入・開発・改修する前に、どの注文をどのEAが管理するのかを明確にしておきましょう。