MQL5 CTradeとMqlTradeRequestの違い｜標準ライブラリとOrderSend直書きの使い分け

MQL5でEAの注文処理を実装する時は、主に2つの書き方があります。1つは標準ライブラリのCTradeを使う方法、もう1つはMqlTradeRequestとMqlTradeResultを使ってOrderSendを直接呼び出す方法です。どちらも注文処理に使えますが、役割、記述量、制御できる範囲、ログ確認のしやすさが異なります。

CTradeは、Buy、Sell、PositionClose、PositionModifyなどのメソッドを使って、注文・決済・ポジション変更を比較的シンプルに書ける標準ライブラリです。一方、MqlTradeRequestを使う方法では、注文リクエストのaction、type、symbol、volume、price、sl、tp、deviation、magic、type_filling、type_timeなどを明示的に組み立ててOrderSendへ渡します。

実務では、「CTradeの方が簡単だから常にCTradeでよい」「MqlTradeRequestの方が細かく書けるから常に直書きがよい」と単純には決められません。EAの目的、注文方式、ログ確認、OrderCheckの有無、口座方式、複数EA運用、開発・検証時の追跡性によって使い分けます。

この記事では、MQL5のCTradeとMqlTradeRequest / OrderSend直書きの違いを、注文処理、発注前チェック、ResultRetcode、MqlTradeResult、Magic Number、type_filling、Hedging / Netting口座、OnTradeTransaction、ログ設計の観点から整理します。

この記事は、MT5 / MQL5のEA開発、注文処理、発注前チェック、ログ確認、実装方式の比較を目的とした技術記事です。特定の売買判断、利益、勝率、損失回避、推奨ロット、推奨銘柄を案内するものではありません。

この記事で確認すること

CTradeとMqlTradeRequestの違い

CTradeは、MQL5標準ライブラリに含まれる取引用クラスです。EAでよく使う注文、決済、変更処理をメソッドとしてまとめており、Buy、Sell、PositionClose、PositionModifyなどを呼び出すことで、基本的な注文処理を実装できます。

MqlTradeRequestは、注文リクエストの内容を細かく指定するための構造体です。OrderSendへ渡すことで注文を送ります。CTradeよりも記述量は増えますが、注文内容を明示的に組み立てられるため、詳細な注文仕様、ログ確認、発注前チェック、特殊な注文方式を扱いやすくなります。

大まかに言えば、CTradeは「よく使う取引処理を簡潔に書くための標準ライブラリ」、MqlTradeRequestは「注文リクエストを自分で細かく作るための構造体」です。どちらを使う場合でも、発注前チェック、ログ確認、retcode確認、Magic Number管理はEA側で設計する必要があります。

CTradeが向いているケース

CTradeは、基本的なEA注文処理を整理して書きたい場合に向いています。Buy、Sell、PositionClose、PositionModifyなどのメソッドが用意されているため、成行注文、決済、SL/TP変更を比較的短いコードで実装できます。

たとえば、単一銘柄、単一ロジック、基本的な成行注文、決済、トレーリング、建値移動を扱うEAでは、CTradeで十分に整理できる場合があります。前段でsignal、filter、riskを分け、最後のexecution責務でCTradeを呼び出す構成にすると保守しやすくなります。

ただし、CTradeを使う場合でも、戻り値だけで注文結果を判断しないようにしてください。ResultRetcode、ResultDeal、ResultOrder、ResultComment、GetLastErrorを確認し、必要に応じてOnTradeTransactionでも取引イベントを追跡します。

#include <Trade/Trade.mqh>

input long InpMagicNumber = 1884001;
input int InpDeviationPoints = 20;

CTrade trade;

int OnInit()
{
   trade.SetExpertMagicNumber(InpMagicNumber);
   trade.SetDeviationInPoints(InpDeviationPoints);

   PrintFormat("INIT_CTRADE magic=%I64d deviation=%d",
               InpMagicNumber,
               InpDeviationPoints);

   return INIT_SUCCEEDED;
}

この例では、CTradeを使う準備としてMagic Numberと許容スリッページを設定しています。CTradeを使うEAでも、初期化時に設定値をログへ出しておくと、後から確認しやすくなります。

MqlTradeRequest / OrderSend直書きが向いているケース

MqlTradeRequestを直接組み立てる方法は、注文仕様を明示的に管理したい場合に向いています。request.action、request.type、request.symbol、request.volume、request.price、request.sl、request.tp、request.deviation、request.magic、request.type_filling、request.type_timeなどを細かく設定できます。

OrderCheckとOrderSendを同じrequestで確認したい場合、MqlTradeRequest直書きは扱いやすいです。発注前にOrderCheckで証拠金、ロット、SL/TP距離、StopLevelなどを確認し、通過したrequestをOrderSendへ渡す流れを作れます。

また、注文リクエストの中身をCSVログやExpertsログへ出したい場合も、requestを明示的に持つ設計の方が検証しやすくなります。EAが注文しない理由や、注文が拒否された理由を追う時に、requestとresultをセットで記録できます。

bool SendMarketOrderByRequest(ENUM_ORDER_TYPE order_type,
                              double volume,
                              double sl,
                              double tp)
{
   MqlTradeRequest request;
   MqlTradeResult result;

   ZeroMemory(request);
   ZeroMemory(result);

   request.action = TRADE_ACTION_DEAL;
   request.symbol = _Symbol;
   request.volume = volume;
   request.magic = InpMagicNumber;
   request.type = order_type;
   request.deviation = InpDeviationPoints;
   request.price = (order_type == ORDER_TYPE_BUY)
                   ? SymbolInfoDouble(_Symbol, SYMBOL_ASK)
                   : SymbolInfoDouble(_Symbol, SYMBOL_BID);
   request.sl = sl;
   request.tp = tp;
   request.comment = "EA_REQUEST_ORDER";

   ResetLastError();

   bool sent = OrderSend(request, result);

   PrintFormat("ORDER_SEND sent=%s retcode=%d order=%I64u deal=%I64u comment=%s last_error=%d",
               sent ? "Y" : "N",
               result.retcode,
               result.order,
               result.deal,
               result.comment,
               GetLastError());

   return sent;
}

この例では、MqlTradeRequestを自分で作り、OrderSendへ渡しています。CTradeよりも記述量は増えますが、注文リクエストの内容を明示的に確認できます。

Buy / SellとMqlTradeRequestの対応関係

CTradeのBuyやSellを使う場合でも、内部的には注文リクエストを作ってサーバーへ送るという考え方は同じです。MqlTradeRequestを直接使うと、その注文リクエストを自分で明示的に作ることになります。

たとえば、CTradeのBuyは買い成行注文を簡潔に書くためのメソッドです。MqlTradeRequestで同じような注文を作る場合は、TRADE_ACTION_DEAL、ORDER_TYPE_BUY、symbol、volume、ask価格、SL、TP、magicなどを指定します。

比較すると、CTradeは呼び出しが短く、MqlTradeRequestは指定項目が明示的です。どちらが上位・下位というより、EAの目的と検証方針に合わせて使い分けるものです。

OrderCheckと組み合わせるならrequest直書きが分かりやすい

OrderCheckを使って発注前確認を行う場合、MqlTradeRequestを明示的に作る設計は分かりやすいです。OrderCheckは、注文リクエストがサーバー側で受け付けられそうか、証拠金や取引条件に問題がないかを確認するために使います。

CTradeを使う場合でもOrderCheckは利用できますが、そのためにはCTradeとは別にMqlTradeRequestを作る必要があります。つまり、OrderCheckを厳密に行いたいEAでは、最初からrequestを作る構成にしておくと、OrderCheckとOrderSendの流れを揃えやすくなります。

bool CheckRequestBeforeSend(const MqlTradeRequest &request)
{
   MqlTradeCheckResult check;
   ZeroMemory(check);

   ResetLastError();

   bool ok = OrderCheck(request, check);

   PrintFormat("ORDER_CHECK ok=%s retcode=%d balance=%.2f equity=%.2f margin=%.2f free_margin=%.2f comment=%s last_error=%d",
               ok ? "Y" : "N",
               check.retcode,
               check.balance,
               check.equity,
               check.margin,
               check.margin_free,
               check.comment,
               GetLastError());

   return ok;
}

この例では、OrderCheckの結果をログに出しています。OrderCheckに通ったから必ず約定するという意味ではありませんが、発注前に不正なロット、証拠金不足、SL/TP距離の問題を検出しやすくなります。

CTradeでもResultRetcodeは必ず確認する

CTradeのBuyやSellはboolを返しますが、戻り値だけを見て注文結果を判断するのは不十分です。注文が失敗した場合、ResultRetcodeやResultCommentに原因が出ることがあります。

MqlTradeRequest / OrderSendの場合は、MqlTradeResult.retcode、order、deal、commentを確認します。CTradeの場合は、trade.ResultRetcode、trade.ResultOrder、trade.ResultDeal、trade.ResultCommentを確認します。どちらの方式でも、注文結果ログを標準化しておくことが重要です。

void PrintTradeResult(string action_name, bool result)
{
   PrintFormat("%s result=%s retcode=%d order=%I64u deal=%I64u comment=%s last_error=%d",
               action_name,
               result ? "Y" : "N",
               trade.ResultRetcode(),
               trade.ResultOrder(),
               trade.ResultDeal(),
               trade.ResultComment(),
               GetLastError());
}

このように、CTradeの結果ログを共通関数化しておくと、Buy、Sell、PositionClose、PositionModifyの結果を同じ形式で確認できます。

Magic Numberの扱いの違い

CTradeでは、SetExpertMagicNumberを使ってMagic Numberを設定します。これにより、CTradeで送る注文にMagic Numberを付けられます。複数EAや複数ロジックを運用する場合、Magic Numberは非常に重要です。

MqlTradeRequestを直接使う場合は、request.magicへMagic Numberを明示的に設定します。どちらの方式でも、注文時にMagic Numberを付けるだけでなく、ポジション管理時にPOSITION_MAGICを確認する必要があります。

input long InpMagicNumber = 1884001;

void SetupCTrade()
{
   trade.SetExpertMagicNumber(InpMagicNumber);
   PrintFormat("MAGIC_SET_CTRADE magic=%I64d", InpMagicNumber);
}

void SetupRequestMagic(MqlTradeRequest &request)
{
   request.magic = InpMagicNumber;
   PrintFormat("MAGIC_SET_REQUEST magic=%I64d", request.magic);
}

CTradeでもMqlTradeRequestでも、Magic Numberを設定し忘れると、あとからEAのポジションを識別しにくくなります。特に、複数EA、複数銘柄、複数ロジック、裁量注文が混在する口座では、Magic Number設計を先に決めておくことが重要です。

deviationとtype_fillingの扱い

注文処理では、deviationとtype_fillingも重要です。deviationは、注文価格からどの程度の価格ずれを許容するかをpointsで指定します。CTradeではSetDeviationInPointsで設定できます。MqlTradeRequestではrequest.deviationに指定します。

type_fillingは、注文の約定方式に関係する項目です。銘柄やブローカーの仕様によって利用できるfilling modeが異なる場合があります。MqlTradeRequestを使う場合は、request.type_fillingを明示的に指定できます。

注文が拒否される場合、ロットやSL/TPだけでなく、filling modeが原因になることもあります。銘柄仕様を確認し、SymbolInfoIntegerなどで利用可能な条件を確認する設計が必要です。

Hedging口座とNetting口座での注意点

CTradeとMqlTradeRequestのどちらを使う場合でも、Hedging口座とNetting口座の違いを無視できません。Hedging口座では、同一銘柄に複数ポジションを持てる場合があります。Netting口座では、同一銘柄のポジションが統合される形になります。

CTradeのPositionClose(_Symbol)のような書き方は簡潔ですが、複数ポジションや複数Magic Numberを扱うEAでは、対象ポジションを正しく選ぶ必要があります。MqlTradeRequestを使う場合も、どのポジションを対象にするのかを明確にしなければなりません。

複数EAを同じ口座で使う場合、symbolだけで判断すると、別EAや裁量注文のポジションを誤って処理する可能性があります。symbol、Magic Number、ticket、position typeを確認してから決済・変更へ進めます。

bool IsMyPosition()
{
   if(!PositionSelect(_Symbol))
      return false;

   long magic = (long)PositionGetInteger(POSITION_MAGIC);

   if(magic != InpMagicNumber)
   {
      PrintFormat("POSITION_SKIP reason=MAGIC_MISMATCH position_magic=%I64d ea_magic=%I64d",
                  magic,
                  InpMagicNumber);
      return false;
   }

   return true;
}

この例では、選択したポジションのMagic Numberを確認しています。Hedging口座で複数ポジションを扱う場合は、ポジション一覧をループし、ticket単位で管理する設計も検討します。

EA設計ではexecution責務に分ける

CTradeを使うか、MqlTradeRequestを使うかに関係なく、注文処理はexecution責務として分離するのが基本です。signal、filter、risk、executionを混ぜると、注文しない理由や注文失敗の理由が分かりにくくなります。

signalは、BUY候補、SELL候補、候補なしを返します。filterは、スプレッド、時間帯、最大ポジション数、上位足条件などを確認します。riskは、ロット、証拠金、SL/TP距離、StopLevelを確認します。executionは、CTradeまたはOrderSendで注文を送ります。

void OnTick()
{
   if(!IsNewBar(_Symbol, PERIOD_CURRENT))
      return;

   int signal = EvaluateEntrySignal();

   if(signal == 0)
   {
      Print("ENTRY_SKIP reason=NO_SIGNAL");
      return;
   }

   if(!PassEntryFilters(signal))
      return;

   if(!CheckEntryRisk(signal))
      return;

   ExecuteEntry(signal);
}

この構造にしておくと、ExecuteEntryの中でCTradeを使うか、MqlTradeRequest / OrderSendを使うかを切り替えやすくなります。注文方式の違いをEA全体へ広げず、execution内に閉じ込められます。

実装方式を切り替えられる設計

検証用EAでは、CTrade版とMqlTradeRequest版を比較したい場合があります。そのような場合は、注文実行方式をinputで切り替えるより、内部のexecution関数で方式を分け、ログ名も明確にすると比較しやすくなります。

ただし、実運用EAで注文方式を頻繁に切り替えられるようにすると、設定ミスや検証漏れの原因になることがあります。開発・検証用の切替と、利用者向けのUserLive設定は分けて管理する方が安全です。

enum TradeExecutionMode
{
   EXECUTION_CTRADE = 0,
   EXECUTION_REQUEST = 1
};

input TradeExecutionMode InpExecutionMode = EXECUTION_CTRADE;

bool ExecuteEntry(int signal)
{
   if(InpExecutionMode == EXECUTION_CTRADE)
   {
      Print("EXECUTION_MODE mode=CTRADE");
      return ExecuteEntryByCTrade(signal);
   }

   if(InpExecutionMode == EXECUTION_REQUEST)
   {
      Print("EXECUTION_MODE mode=REQUEST");
      return ExecuteEntryByRequest(signal);
   }

   Print("EXECUTION_FAIL reason=UNKNOWN_MODE");
   return false;
}

この例では、execution方式を分けています。実務では、検証用のAdminDev機能として使い、通常利用者向けには固定方式にするなど、運用上の安全性も考慮します。

OnTradeTransactionで結果を追跡する

CTradeでもMqlTradeRequestでも、注文送信後に実際の取引イベントを追跡するにはOnTradeTransactionが役立ちます。注文送信結果と、注文・約定・決済イベントは分けて確認します。

CTradeのResultRetcodeやMqlTradeResult.retcodeは、注文送信の結果確認に使います。一方で、OnTradeTransactionは、取引イベントが発生した時に呼ばれます。約定通知、決済通知、CSVログ、外部連携へつなげる場合は、OnTradeTransactionのログも重要です。

void OnTradeTransaction(const MqlTradeTransaction &trans,
                        const MqlTradeRequest &request,
                        const MqlTradeResult &result)
{
   PrintFormat("TRADE_TX type=%d order=%I64u deal=%I64u symbol=%s volume=%.2f price=%.5f retcode=%d",
               trans.type,
               trans.order,
               trans.deal,
               trans.symbol,
               trans.volume,
               trans.price,
               result.retcode);
}

OnTradeTransactionはイベントごとに呼ばれるため、ログの出しすぎには注意します。重要イベントだけをCSVへ保存し、通知はOnTimerのキュー処理へ渡す設計にすると安定しやすくなります。

注文ログを比較できる形にする

CTradeとMqlTradeRequestを比較する場合、ログの形式がバラバラだと検証しにくくなります。CTradeでもrequest直書きでも、ORDER_REQUEST、ORDER_CHECK、ORDER_SEND、TRADE_TXのようにログ名を揃えておくと、あとから検索しやすくなります。

ログ名を固定すると、Expertsログ、CSVログ、バックテスト結果を横断して確認しやすくなります。EAが注文しない理由を調べる時は、注文処理だけでなく、SIGNAL、FILTER、RISKで止まっていないかも確認してください。

CTradeとMqlTradeRequestの選び方

実装方式を選ぶ時は、EAの規模、注文仕様、検証のしやすさ、運用者の理解しやすさを基準にします。単純な成行注文と決済が中心ならCTradeで十分な場合があります。注文リクエストを細かく制御したい、OrderCheckとOrderSendを同じrequestで扱いたい、ログを細かく残したい場合は、MqlTradeRequest直書きが向いています。

ただし、どちらを選んでも、EA設計の基本は同じです。signal、filter、risk、execution、exit、notification、logを分け、注文前の確認と注文後の結果確認をログに残します。

バックテストで確認すること

CTradeとMqlTradeRequestを比較する時は、バックテストで損益だけを見るのではなく、注文処理の流れをログで確認します。どの方式で注文したか、OrderCheckを通ったか、OrderSendがどう返したか、retcodeは何だったか、OnTradeTransactionでどのイベントが出たかを確認します。

バックテストでは、実チャートと異なる約定条件になる場合があります。特にスプレッド、deviation、filling mode、取引時間、ブローカー仕様は、実環境でも確認が必要です。バックテストで通った注文が、実チャートで常に同じように通るとは限りません。

よくある不具合と確認ポイント

CTradeとMqlTradeRequestの使い分けでよくある不具合は、注文結果を確認していない、OrderCheckを通さずに注文している、Magic Numberを設定していない、type_fillingが銘柄条件に合っていない、Hedging / Netting口座の違いを考慮していない、といったものです。

開発依頼前に整理すること

CTradeまたはMqlTradeRequestを使うEAの開発を依頼する場合は、「どちらの方式で書くか」だけでなく、注文仕様を整理することが重要です。買い注文、売り注文、ロット、SL/TP、Magic Number、OrderCheck、type_filling、決済方法、ログ形式を事前に決めておくと、実装後の認識違いを減らせます。

特に、証拠金・ロット・StopLevel確認を重視するEAでは、OrderCheckをどこで使うかを整理してください。CTrade中心で実装する場合でも、risk責務でOrderCheckを行い、execution責務でCTradeを呼ぶ構成にできます。

実務チェック表

よくある質問

CTradeとMqlTradeRequestはどちらを使うべきですか？

基本的な成行注文や決済を簡潔に書きたい場合はCTradeが扱いやすいです。注文リクエストを細かく制御したい場合、OrderCheckとOrderSendを同じrequestで管理したい場合、詳細ログを重視する場合はMqlTradeRequest直書きが向いています。

CTradeを使えばOrderCheckは不要ですか？

不要とは限りません。CTradeは注文実行を簡潔にするためのクラスです。証拠金、ロット、StopLevel、SL/TP距離を事前に確認したい場合は、OrderCheckやSymbolInfoを組み合わせる方が安全です。

CTradeの戻り値だけで注文結果を判断できますか？

戻り値だけでは不十分です。ResultRetcode、ResultOrder、ResultDeal、ResultComment、GetLastErrorを確認してください。さらに、OnTradeTransactionで注文・約定・決済イベントを追跡すると確認しやすくなります。

MqlTradeRequest直書きは難しいですか？

CTradeより指定項目は増えますが、注文内容を明示的に管理できます。OrderSend、OrderCheck、MqlTradeResult、type_filling、type_timeなどを理解する必要があります。詳細な注文仕様や検証ログを重視する場合は有効です。

Magic NumberはCTradeでも必要ですか？

複数EA運用や裁量注文との区別を考えるなら必要です。CTradeではSetExpertMagicNumber、MqlTradeRequestではrequest.magicで設定します。ポジション管理時にはPOSITION_MAGICも確認してください。

どちらの方式でもログは必要ですか？

必要です。CTradeでもMqlTradeRequestでも、注文前の条件、OrderCheck結果、OrderSend結果、retcode、comment、OnTradeTransactionを記録しないと、注文しない理由や注文失敗の原因を追いにくくなります。

関連ページ

CTradeとMqlTradeRequestの違いを整理する時は、CTradeの基本、EA設計、OrderCheck、注文・ポジション管理、Magic Number、Hedging / Netting、CSVログもあわせて確認すると、実装と検証の切り分けがしやすくなります。

まとめ

MQL5のCTradeとMqlTradeRequest / OrderSend直書きは、どちらもEAの注文処理に使えます。CTradeはBuy、Sell、PositionClose、PositionModifyなどを簡潔に書きやすく、基本的な注文・決済処理に向いています。MqlTradeRequestは注文リクエストを明示的に組み立てられるため、詳細制御、OrderCheck連携、注文ログ確認に向いています。

どちらを使う場合でも、注文処理はexecution責務として分け、signal、filter、riskと混同しないことが重要です。注文前にスプレッド、ロット、証拠金、StopLevel、Magic Number、口座方式を確認し、注文後はretcode、order、deal、comment、OnTradeTransactionをログで確認します。

CTradeかMqlTradeRequestかという選択は、EAの目的、注文仕様、検証のしやすさによって変わります。簡潔さを重視するならCTrade、詳細制御とログ追跡性を重視するならMqlTradeRequest直書きが候補になります。重要なのは、どちらの方式でも「なぜ注文したか、なぜ注文しなかったか、注文結果がどう返ったか」を確認できる設計にすることです。