MT4資産をMT5へ作り直す実務ノート｜移植ではなく再設計で考える理由

MT4で使っていたEAやインジケーターを、MT5でも使いたいという相談は多くあります。

しかし、MT4資産をMT5へ移す時に、単純な書き換えや自動変換だけで済むと考えると、実装後に問題が出やすくなります。

MQL4とMQL5では、注文管理、ポジション管理、履歴管理、インジケーターハンドル、イベント構造、標準ライブラリ、バックテスト環境が大きく異なります。関数名を置き換えるだけでは、MT5らしい安全なEA設計にならない場合があります。

MT4資産をMT5へ作り直す時に重要なのは、移植ではなく再設計として考えることです。既存ロジックの意図を確認し、MT5のOrder / Position / Deal、CTrade、CopyBuffer、OnTick構造、ログ設計、検証条件に合わせて組み直す必要があります。

この記事では、MT4資産をMT5へ作り直す時の設計判断を、開発実務ノートとして整理します。完成EAソース全文、外部シート制御ロジック、認証ロジック、endpoint、token、URL実値、実運用set値、中核Entry条件は公開しません。

本記事は、投資判断や売買指示ではなく、MT4 EA・インジをMT5向けに安全に再設計するための技術記事です。

この記事で扱う実務課題

なぜ単純移植ではなく再設計が必要なのか

MT4とMT5は、どちらもMetaTrader系のプラットフォームですが、内部の考え方は同じではありません。

特にEA開発では、注文・ポジション・履歴の扱いが大きく異なります。MT4では注文を中心に考える実装が多い一方、MT5ではOrder、Position、Dealを分けて考える必要があります。

そのため、MT4コードをMT5コードへ機械的に置き換えるだけでは、ポジション管理や注文結果確認が不十分になる可能性があります。

MT4資産をMT5化する時に確認するもの

MT4資産をMT5へ作り直す前に、まず既存資産の内容を整理します。

移行前にこの整理をしないまま作業を始めると、見た目は似ていても、MT5版で動作意図が変わる可能性があります。

Order / Position / Dealを分けて考える

MT5では、Order、Position、Dealを分けて考えることが重要です。

これはMT4資産の再設計で最も重要な差分の1つです。

MT4的な感覚で「注文＝ポジション＝履歴」のように扱うと、MT5では原因調査が難しくなります。

MT5版では、発注した事実、現在保有している状態、過去に約定した履歴を別々に確認できる設計にすることが重要です。

CTradeを使うか、MqlTradeRequestを使うか

MT5の発注処理では、CTradeを使う設計と、MqlTradeRequest / MqlTradeResultを直接扱う設計があります。

どちらが常に正解というより、EAの目的やログ要件によって選びます。

MT4資産をMT5化する時は、単にOrderSendを書き換えるのではなく、execution層として、注文前確認、発注、結果確認、retcodeログを分けて設計します。

インジケーター参照はCopyBuffer前提で見直す

MT4のインジケーター参照では、iCustomから直接値を受け取る実装が多く見られます。

MT5では、インジケーターハンドルを作成し、CopyBufferで値を取得する流れになります。

MT4版で「矢印が出たらEntry」だったとしても、MT5版では、どのbuffer、どのshift、どのbar timeの値を使うかを再設計する必要があります。

イベント構造をMT5向けに整理する

MT4資産をMT5へ作り直す時は、OnTickだけでなく、OnInit、OnDeinit、OnTimer、OnChartEventなどの役割も見直します。

MT4版でOnTickに多くの処理を詰め込んでいた場合、MT5版では責務ごとに分けることで安定性と調査性を高められます。

signal / execution / risk / exitを再設計する

MT4資産をMT5へ作り直す時は、既存ロジックをそのまま大きな関数へ詰め直すのではなく、責務分離を行います。

MT4版のコードが動いていたとしても、MT5版では、どこで判定し、どこで発注し、どこで止めたのかをログで追える構造に作り直す方が安全です。

実コード例1：MT4的な注文確認をそのまま持ち込まない

以下は、設計判断を理解するために一般化した比較用コード例です。完成EAのソース全文ではありません。

MT4資産をMT5へ作り直す時に起きやすいのが、「何か取引状態があるか」を1つの関数でまとめて確認してしまう設計です。

// 学習用の比較例です。
// MT4的な考え方をそのままMT5へ持ち込まないための説明用です。
// 実運用EAの完成ソースではありません。

bool HasAnyTradeLikeState_LegacyStyle()
{
   // 旧設計で起きやすい考え方：
   // ・注文、ポジション、履歴の責務が混ざる
   // ・symbolやmagicの確認範囲が曖昧になる
   // ・Entry判定と決済判定が同じ場所に集まりやすい
   // ・「今保有している」のか「注文を出した」のか「過去に約定した」のかが分からない

   bool hasSomething = false;

   // 疑似的な確認処理です。
   // 実際のMT5設計では、このようにまとめて判断しません。

   bool hasOrderLikeData = false;
   bool hasPositionLikeData = false;
   bool hasHistoryLikeData = false;

   if(hasOrderLikeData || hasPositionLikeData || hasHistoryLikeData)
      hasSomething = true;

   return hasSomething;
}

このように、注文・ポジション・履歴をまとめて「何かある」と扱うと、MT5では原因調査が難しくなります。

たとえば、EAが新規Entryを止めた時に、未約定注文があるから止めたのか、保有ポジションがあるから止めたのか、過去履歴を見て止めたのかが分かりません。

MT5向けに作り直す場合は、Order、Position、Dealを分けて確認し、それぞれの結果をSnapshotとして整理します。

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

struct TradeStateSnapshot
{
   int activePositionCount;
   int pendingOrderCount;
   int recentDealCount;
   bool hasActivePosition;
   bool hasPendingOrder;
   string reason;
};

TradeStateSnapshot BuildTradeStateSnapshot()
{
   TradeStateSnapshot snap;
   snap.activePositionCount = 0;
   snap.pendingOrderCount = 0;
   snap.recentDealCount = 0;
   snap.hasActivePosition = false;
   snap.hasPendingOrder = false;
   snap.reason = "INIT";

   // Position：
   // 現在保有しているポジションを確認する責務。
   // symbol、magic、ticket、side、volumeなどを確認対象にする。

   snap.activePositionCount = 0; // 実際はPositionSelect等で集計する
   snap.hasActivePosition = (snap.activePositionCount > 0);

   // Order：
   // 未約定注文や注文リクエスト状態を確認する責務。
   // 成行注文後の保有確認とは分けて考える。

   snap.pendingOrderCount = 0; // 実際はOrdersTotal等から必要範囲を集計する
   snap.hasPendingOrder = (snap.pendingOrderCount > 0);

   // Deal：
   // 過去に約定した履歴を確認する責務。
   // 現在保有しているかどうかとは分けて扱う。

   snap.recentDealCount = 0; // 実際はHistorySelect等で確認する

   snap.reason = "TRADE_STATE_SNAPSHOT_OK";
   return snap;
}

このように分けると、EAが止まった理由をログで追いやすくなります。

さらに、Entry前の判断では、TradeStateSnapshotをそのままOrderSendへ直結させず、GATEやriskへ渡します。

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

bool CanOpenNewEntryByTradeState(const TradeStateSnapshot &snap)
{
   if(snap.hasPendingOrder)
   {
      Print("DIAG/GATE: event=BLOCK",
            " reason=PENDING_ORDER_EXISTS");
      return false;
   }

   if(snap.hasActivePosition)
   {
      Print("DIAG/GATE: event=BLOCK",
            " reason=ACTIVE_POSITION_EXISTS");
      return false;
   }

   Print("DIAG/GATE: event=PASS",
         " reason=TRADE_STATE_OK");

   return true;
}

この例では、現在ポジションがある状態と、未約定注文がある状態を分けてGATE判定しています。

MT4資産の再設計では、「以前こう書いていたから同じように置き換える」のではなく、MT5で何を確認したいのかを責務ごとに分けます。特に、Order、Position、Dealを分けることで、Entry停止、決済対象、履歴確認、ログ調査の精度を上げやすくなります。

実コード例2：MT5向けにPosition Snapshotを作る

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。

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

struct PositionSnapshot
{
   int count;
   int buyCount;
   int sellCount;
   double totalVolume;
   double floatingProfit;
   string reason;
};

PositionSnapshot BuildPositionSnapshot(long magic)
{
   PositionSnapshot snap;
   snap.count = 0;
   snap.buyCount = 0;
   snap.sellCount = 0;
   snap.totalVolume = 0.0;
   snap.floatingProfit = 0.0;
   snap.reason = "INIT";

   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.reason = "POSITION_SNAPSHOT_OK";
   return snap;
}

MT5では、現在の保有状態をPosition Snapshotとして固定すると、Entry可否、risk、exit、ログ確認がしやすくなります。

特に、symbolとmagicを確認せずに全ポジションを扱う設計は避けるべきです。

実コード例3：signalとexecutionを分ける

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。実Entry条件や実発注処理は含めていません。

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

enum SignalSide
{
   SIGNAL_NONE = 0,
   SIGNAL_BUY,
   SIGNAL_SELL
};

struct SignalResult
{
   bool ready;
   SignalSide side;
   string reason;
};

struct ExecutionCandidate
{
   bool allowed;
   SignalSide side;
   string reason;
   string route;
};

SignalResult EvaluateSignal()
{
   SignalResult signal;
   signal.ready = false;
   signal.side = SIGNAL_NONE;
   signal.reason = "NO_SIGNAL";

   // ここでは中核Entry条件は扱いません。
   // MT4資産から移行する場合も、signalは候補生成に留めます。

   return signal;
}

ExecutionCandidate BuildExecutionCandidate(const SignalResult &signal)
{
   ExecutionCandidate candidate;
   candidate.allowed = false;
   candidate.side = signal.side;
   candidate.reason = signal.reason;
   candidate.route = "MT5_REDESIGN_ROUTE";

   if(!signal.ready)
      return candidate;

   // 実際のEAでは、この後にGATE / risk / duplicate controlを確認します。

   candidate.allowed = true;
   candidate.reason = "ENTRY_CANDIDATE_READY";
   return candidate;
}

MT4版でEntry判定とOrderSendが同じ場所にあった場合でも、MT5版ではsignalとexecutionを分ける方が安全です。

signalは候補を作り、executionは発注と結果確認を行います。

実コード例4：移行チェックログを残す

以下は、設計判断を理解するために一般化した学習用コード例です。完成EAのソース全文ではありません。

// 学習用に一般化したMT4→MT5再設計チェックログ例です。
// 実運用EAの完成ソースではありません。

void WriteMigrationCheck(string item,
                         string eventName,
                         string reason,
                         string detail)
{
   Print("DIAG/MT4_TO_MT5: item=", item,
         " event=", eventName,
         " reason=", reason,
         " detail=", detail);
}

void PrintMigrationChecklist()
{
   WriteMigrationCheck("ORDER_POSITION_DEAL",
                       "CHECK",
                       "REVIEW_REQUIRED",
                       "Separate order, position, and deal handling.");

   WriteMigrationCheck("INDICATOR_HANDLE",
                       "CHECK",
                       "COPYBUFFER_REQUIRED",
                       "Review iCustom handle and buffer access.");

   WriteMigrationCheck("RESPONSIBILITY",
                       "CHECK",
                       "SEPARATE_LAYERS",
                       "Separate signal, execution, risk, and exit.");

   WriteMigrationCheck("LOGGING",
                       "CHECK",
                       "ADD_REASON_LOG",
                       "Add event and reason logs for verification.");
}

MT4資産をMT5へ作り直す時は、変換作業だけでなく、再設計チェックをログや仕様書に残すと確認しやすくなります。

MT4インジケーターをMT5化する時の注意

MT4インジケーターをMT5へ作り直す場合も、単純な関数置換では足りないことがあります。

MT4版でチャートに矢印が出ていたとしても、MT5版ではEAから読みやすいbuffer設計にするかどうかを検討する必要があります。

MT4 EAをMT5化する時の注意

MT4 EAをMT5へ作り直す場合は、注文・ポジション・履歴の設計を見直します。

MT4版で動いていたEAでも、MT5版ではポジション管理と注文結果確認を明確にしないと、誤決済や原因不明の見送りにつながることがあります。

バックテスト条件はMT5で取り直す

MT4版のバックテスト結果がある場合でも、MT5版ではMT5のストラテジーテスターで再検証する必要があります。

MT4版とMT5版では、テスター条件、tick model、銘柄仕様、スプレッド、約定、履歴データの扱いが異なる可能性があります。

MT4版の成績をそのままMT5版の期待値として扱うのは避けるべきです。MT5版は、MT5環境で再検証します。

単純変換で起きやすい失敗

MT4資産をMT5へ単純変換すると、次のような問題が起きやすくなります。

単純変換は、短期的には早く見える場合があります。しかし、後から不具合調査や改修が難しくなりやすいため、再設計として進める方が安全です。

MT5再設計でログに残すべき情報

MT4資産をMT5へ作り直す時は、差分が分かるログを用意します。

MT4版とMT5版の比較では、損益だけでなく、Entry理由、見送り理由、決済理由、注文結果を比較できるログが重要です。

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

MT4資産をMT5へ作り直す相談をする場合、次の情報を整理しておくと確認がスムーズになります。

• 対象がEAかインジケーターか
• MT4版のファイル形式
• ソースコードの有無
• 既存setファイルの有無
• Entry条件の説明
• Exit条件の説明
• ナンピン、マーチン、複数ポジション管理の有無
• Magic Numberの使い方
• 手動ポジションを管理対象にするか
• 対象銘柄と時間足
• MT4版で使っていたインジケーター
• iCustomや外部ファイル参照の有無
• 通知、CSV、WebRequest、DLLの有無
• MT4版バックテスト結果
• MT5版で残したい挙動
• MT5化に合わせて改善したい点

ソースコードがない場合、完全な再現が難しいことがあります。その場合は、仕様書、画面、ログ、挙動説明、バックテスト結果、setファイルから再設計方針を検討します。

MT4版と同じ見た目にするか、MT5向けに改善するか

MT4資産をMT5へ作り直す時、見た目や操作感をどこまで維持するかも確認します。

移行時は、見た目を変えないことが常に正解ではありません。MT5向けに安全性、ログ、サポート性を高める再設計も検討します。

関連する技術講座・確認ページ

FAQ

MT4のEAをそのままMT5で使えますか？

基本的にはそのままでは使えません。MT4とMT5では、言語仕様、注文管理、ポジション管理、インジケーター取得、テスター環境が異なるため、MT5向けに作り直す必要があります。

自動変換ツールで変換すれば十分ですか？

十分でない場合があります。関数名が置き換わっても、Order / Position / Deal、CopyBuffer、CTrade、ログ設計、risk管理がMT5向けに整理されていないと、不具合調査や運用で問題が出やすくなります。

MT4版と完全に同じ挙動になりますか？

完全一致を前提にしない方が安全です。銘柄仕様、tick、スプレッド、約定、インジケーター計算、バックテスト条件が異なるため、MT5版として再検証が必要です。

MT4版のソースコードがなくてもMT5化できますか？

可能な場合もありますが、完全再現は難しくなります。仕様書、setファイル、画面、ログ、バックテスト結果、動作説明、インジケーター情報から再設計する必要があります。

MT4インジケーターをMT5 EAから使えますか？

MT4用インジケーターをそのままMT5 EAから使うことはできません。MT5用に作り直し、iCustomのhandle、CopyBuffer、buffer番号、shift、リペイントを確認する必要があります。

OrderSendの書き換えだけでMT5化できますか？

避けた方が安全です。発注処理だけでなく、ポジション確認、履歴確認、決済対象、risk、ログ、エラー確認をMT5向けに設計する必要があります。

CTradeを使えばMT5化は簡単になりますか？

CTradeは便利ですが、使えば自動的に安全になるわけではありません。発注前確認、retcode確認、Position Snapshot、Close Scope、ログ設計は別途必要です。

MT4版のバックテスト結果をMT5版の根拠にできますか？

参考にはできますが、そのまま根拠にはしない方が安全です。MT5版は、MT5のストラテジーテスター、銘柄仕様、tick model、スプレッド条件で再検証します。

関連する開発実務ノート

MT4資産をMT5へ作り直す場合は、MT5向けのEA設計、インジケーターEA化、バックテスト条件、商品化前チェックをあわせて確認すると、移植ではなく再設計として整理しやすくなります。

• MQL5 EA設計実務ノート｜signal・execution・risk・exitを分ける理由
• MQL5インジケーターEA化実務ノート｜サイン取得・確定足・リペイント確認の考え方
• MQL5バックテスト実務ノート｜検証条件・最適化・リアル差分を記録する考え方
• MQL5商品化・配布前チェック実務ノート｜Inputs・HELP・Snapshot・manual・UserLive化の基本

まとめ

MT4資産をMT5へ作り直す時は、単純な移植や関数置換ではなく、MT5向けの再設計として考えることが重要です。

特に、次の4点を見直すと、MT5版として安定した構造にしやすくなります。

• Order / Position / Deal：注文、現在ポジション、約定履歴を分けて扱う
• CTrade / MqlTradeRequest：発注処理と結果確認をexecution層として整理する
• CopyBuffer / indicator handle：MT4的なiCustom値取得をMT5向けに見直す
• signal / execution / risk / exit：判定、発注、リスク、決済を責務分離する

また、MT4版で動いていたという事実だけでは、MT5版の安全性や再現性は保証できません。MT5版として、検証条件、ログ、Position Snapshot、Close Scope、バックテスト、リアル差分を確認する必要があります。

完成EAの中核ロジックや実運用set値を公開しなくても、MT4資産をMT5向けに再設計する考え方を理解しておくことで、開発依頼、既存EA改修、インジケーター移行、検証、不具合調査、販売後サポートの品質を上げやすくなります。