MT4のコンパイルでFX自動売買EAを更新する手順とエラー対処

MT4のコンパイルは、EAのソースであるmq4ファイルをMetaEditorで開き、F7で実行します。ただし、EX4がフォルダにあるだけでは、今の修正が反映された証拠にはなりません。今回のビルド結果と、MT4が読み込むファイルまで確認することが大切です。

FX自動売買のEAを修正したのに動きが変わらない場合も、文法エラー、別フォルダへの出力、以前の入力設定の引き継ぎでは対処が異なります。この記事ではWindows版のMT4とMetaEditorを前提に、mq4からex4を作る手順、エラーと警告の読み方、古い実行ファイルとの取り違えを順に整理します。

FX自動売買向けMT4のコンパイル手順

mq4とex4の違いを確認する

mq4はMQL4で書かれた編集用のソース、ex4はMT4で読み込む実行ファイルです。ソース内の売買条件を変えた場合は、その内容を実行ファイルにする工程が必要になります。ファイル名の末尾だけを変更しても、この変換は行われません。

手元のファイル	役割	今回行うこと
EA本体の.mq4	編集・ビルドの対象	MetaEditorで開いてコンパイルする
.ex4のみ	ビルド済みの実行ファイル	ソースの修正ではなく、配布元の対応環境と導入先を確認する
.mqh	本体から読み込む補助ソース	配布構成を保ち、これを使うEA本体をビルドする
.mq5または.ex5	MT5向けのソース・実行物	MT4向けファイルと取り違えていないか確認する

この関係はMetaQuotesのコンパイル解説で確認できます。ここではEA本体のmq4からex4を作る作業に絞ります。すでにex4を受け取っている方の設置や稼働設定は、MT4へのEAインストール手順を先に確認すると整理しやすくなります。

なお、同じ拡張子でもEA本体、インジケーター、補助ファイルは役割が異なります。「mq4だから全部を同じ場所へ入れる」と考えず、配布元の説明で本体名とフォルダ構成を確かめてください。mq4が複数ある場合は、何を実行するためのファイルなのかを先に決めます。

使うMT4の保存先から開く

MT4を複数入れている場合、最初につまずきやすいのが作業先の混同です。A社のMT4で使いたいのに、B社のMT4に付属するMetaEditorで別のmq4を開いていると、コンパイルが成功しても目的の画面には反映されません。デスクトップのファイルをいきなりダブルクリックする前に、実際に使うMT4を起点にしましょう。

対象のMT4で「ファイル」から「データフォルダを開く」を選び、MQL4内のExpertsを確認します。EAの配布フォルダがある場合は、その中の本体mq4を探します。MetaQuotesのMQL4のファイル構成の説明でも、EAとIncludeなどの配置先が区別されています。インストール先らしいフォルダを推測するより、使うMT4自身から開く方が取り違えを防げます。

ファイルの拡張子が見えない場合は、OSの表示設定で拡張子を表示してから判別します。見た目の名前だけでは、SampleEA.mq4とSampleEA.ex4の区別がつきにくくなります。また、テキストエディターで保存したファイルなら末尾が.mq4.txtになっていないかも確認してください。ファイル名の前半が同じというだけで、ソースとして開けたことにはなりません。

続いて、そのMT4の「ツール」からMetaEditorを起動します。F4でも呼び出せることはMT4公式ヘルプのツールメニューで案内されています。MetaEditorの「ファイル」から、先ほど確かめたmq4を開いてください。開いているタブの名前だけでなく、そのファイルがどのフォルダにあるかも確かめます。

たとえばダウンロード先にあるSampleEA.mq4と、稼働用フォルダにあるSampleEA.mq4は、同名でも別のファイルです。片方だけを修正しても、もう片方まで書き換わるわけではありません。作業中は本体を一つに決め、どこを編集し、どこへ成果物を渡すのかを明確にします。

ここで見ている保存場所と、配布元が指定する配置場所に食い違いがあれば、まずその理由を確認します。関連ファイルをばらばらの場所へ移して帳尻を合わせると、次に更新するときに同じ問題が起きやすくなります。

F7の結果と出力先を確かめる

MetaEditorでEA本体のmq4を選んだら、変更内容を保存してF7を押します。コンパイルボタンからも実行できます。ほかのファイルを複数開いているときは、今アクティブなタブが対象のEA本体かを直前に確認してください。補助ソースのタブを見ていたまま操作しないことがポイントです。

結果の見方は、まず「エラーがゼロか」、次に「警告があるか」の順です。0 errors、0 warningsなら、コンパイラーが今回検出したエラー・警告はありません。一方、0 errorsでも警告が残る場合は、その意味を確認してから動作確認に進みます。表示が消えたことや画面が固まらなかったことを、成功判定に使わないでください。

コンパイルにかかった時間の長短も、EAの正しさを表すものではありません。ビルド成功、意図した条件での動作、運用成績は別の確認です。ここでの到達点は「編集したソースを実行ファイルにできた」と確認するところまでになります。

エラーは先頭の原因から直す

エラーが残っているなら、修正版のビルド成功とは判断できません。エラー一覧では説明文だけでなく、対象ファイル、行、列を確認します。本体のmq4で起きているのか、読み込んだmqhで起きているのかによって、見る場所が変わるためです。

先頭付近の一つの書き間違いが、後続の行にも影響する場合があります。たくさん並んだメッセージを一度に消そうとせず、最初に現れた原因候補を一つ修正して再コンパイルし、残った結果を見直しましょう。行番号は原因を探す手掛かりであり、その行だけ直せば解決するという意味ではありません。

メッセージの例	最初に確認するもの	避けたい直し方
undeclared identifier	名前の綴り、宣言の有無、使える範囲	意味の分からない変数を追加して数だけ合わせる
semicolon expected	該当箇所と直前の文の終わり	指摘された行へ機械的に記号を足す
unbalanced braces	波括弧の対応、貼り付けたコードの範囲	関数や条件の構造を見ずに括弧を消す
include先を開けない	指定名、配布ファイル、参照先の一致	include行を削除して依存関係を隠す
EX4を書き込めない	出力先と書き込み状態	文法だけを直し続ける

表は原因を調べ始めるための整理です。実際のメッセージや番号はMQL4公式のコンパイルエラー一覧と照合してください。特に読み書きの失敗は、売買ロジックの書き方とは別に、保存先の問題として調べる必要があります。

ネット上のコードを貼り付けた直後なら、コードの前後が欠けていないか、説明文まで入っていないか、全角の記号が混ざっていないかを見ます。既存の関数へ入れる一部分なのか、ファイル全体を置き換えるサンプルなのかも区別します。別のEAのOnInitをそのまま追加して関数を重複させると、元の問題とは別の不具合を増やしてしまいます。

配布されたEAでコードの意味が分からない場合は、注文処理や損失制限をコメントアウトして通すより、対象のメッセージと必要ファイルを配布元へ確認する方が適切です。認証情報や口座番号を添える必要はありません。問い合わせでは本体名、エラー全文、ファイル名と行番号、直前に変更した範囲が分かれば、話を進めやすくなります。

警告と依存ファイルを見分ける

warningはerrorとは扱いが異なります。警告があっても実行ファイルが生成されることはありますが、警告がない場合と同じ判断にはしません。MQL4公式の警告一覧には、未使用変数、初期化されていない可能性のある変数、型変換による情報欠落、戻り値の未確認などが挙げられています。

たとえば注文関連の関数で戻り値を確認していない警告なら、注文が通らなかった場合にどう扱うかという、運用上の確認につながります。型変換の警告なら、小数部分などを失ってもよい値なのかが論点です。警告の数を減らすためにキャストや不要な代入を足すのではなく、「この処理はどんな値を想定しているか」を確認しましょう。

また、ほかのファイルを使うEAでは、本体mq4だけ受け取ってもビルドできない場合があります。#includeで指定した補助ソースが必要なら、指定名と実ファイルを照合します。標準のIncludeを探す山括弧と、本体側のフォルダを探す引用符では、検索先が異なります。この違いは公式の#include仕様に示されています。

「ファイルが見つからないから、とりあえず全部Includeへ入れる」という対処は避けます。元のフォルダ構成が分かる配布物を確認し、指定された相対的な位置関係に合わせてください。mqhを直したときも、最終的に利用するEA本体へ戻ってビルド結果を確認します。補助ファイルだけの確認で作業を終えないことが大切です。

古いソースについても、コンパイルを通すためだけに#property strictを外す方法を第一候補にしない方がよいでしょう。モードを変えて見えなくなった指摘と、原因を修正して解消した指摘は区別できます。まず対象の言語と配布元の対応環境を確認し、その環境で修正すべき箇所を絞ります。

MT4のコンパイル後に反映を確認する

ソースと実行物を三点照合する

0 errorsを確認しても、思った変更がMT4で見えない場合は、コードを再修正する前にファイルの流れを追います。確認するのは「編集したソース」「そこから出力されたex4」「目的のMT4が使うex4」の三つです。一つずつつながれば、コンパイルと導入のどこで食い違っているかを判断しやすくなります。

まずMetaEditorで開いている本体mq4の保存先を確認し、そのフォルダにある同名ex4を見ます。次に目的のMT4からデータフォルダを開き、利用するEAのex4がそこにあるかを照合します。ファイル名が一致していても、保存先や更新日時が違えば同じ実行物とは限りません。

修正前からex4が置いてあるフォルダでは、「ex4がある」という事実だけでは今回の成功を示せません。直前のコンパイルにエラーがあったなら、そのex4は少なくとも修正版と確認できていない状態です。存在を根拠に再稼働させず、成功結果と対応する生成物を確認してください。

見つかった状態	次に見る場所	まだ言えないこと
コンパイル結果にerrorがある	MetaEditorのエラー一覧	修正版のEX4が完成したとは言えない
成功したが出力先が違う	本体mq4の場所とMT4のデータフォルダ	稼働側が新しい版とは言えない
更新日時は合うが変更が見えない	EAの識別表示・入力値・適用チャート	コードが古いと即断できない
新しい版であることを確認できた	デモでの初期化と想定動作	売買条件や運用成績が正しいとは言えない

別のPCやVPSへ渡す場合は、ビルド用PCで成功しただけで完了にしません。転送元と転送先の名前、サイズ、更新日時を見比べ、稼働先で読み込まれた版を確認します。更新日時はコピー方法などで変わるため、単独の証拠として決めつけず、次の識別表示と組み合わせると判断が確かになります。

たとえば、作業フォルダのSampleEA.ex4だけが新しく、稼働用フォルダの同名ファイルは以前のままなら、まず配布経路の問題を解消します。反対に両方が一致しているなら、むやみに同じコピー操作を繰り返す必要はありません。確認結果に応じて、次に見る場所を変えるのが診断の目的です。

識別表示で新しい版か確かめる

ソースを編集できる場合は、動作に関係しない識別表示を設けると、新しい版が読み込まれたかを確認できます。売買条件やロットを試しに変える必要はありません。既存の初期化処理を読める方であれば、その中にビルド識別用の出力を一行加える方法があります。

下は、既存のOnInit関数の中へ追加する一文の例です。EA全体のサンプルではないため、ファイルの先頭へそのまま置いたり、OnInit関数をもう一つ作ったりしないでください。既存処理を理解できない場合はコードを変更せず、配布元が用意したバージョン表示を使います。

Print("BUILD_CHECK=review-A; file=", __FILE__,
      "; built=", __DATETIME__, "; compiler=", __MQL4BUILD__);

この例では、今回だけの目印であるreview-A、ソースのファイル名、コンパイル時点の日時、コンパイラーのビルド番号を出します。使っている定数の意味はMQL4公式の定義済みマクロ一覧、出力方法はPrintの仕様で確認できます。

再コンパイルして成功を確認したあと、デモ用MT4のエキスパート欄などで今回の出力を探します。現在の日時に近い行を見て、対象EAの名前と新しい目印が対応しているかを照合してください。昔出力された同名EAの行や、別チャートで動くEAの行を根拠にしないようにします。

目印は新しいのに挙動が変わらないなら、少なくとも単純な旧版の取り違えとは別の原因を調べられます。逆に目印が見つからないだけでは、すぐに旧版と断定できません。初期化処理の途中で止まっている、確認する欄や時刻が違う、そもそもそのEAを適用していないなどの可能性も残ります。

識別用の目印を入れた場合は、目的の修正内容そのものもソースで見直します。目印が新しいことは「その版を読み込んだ」という確認であって、意図した条件式まで変更済みという証明ではありません。確認用表示だけ更新し、肝心の修正を別ファイルに残したまま、という取り違えもここで防ぎます。

この確認のために、注文のたびに大量の表示を出す必要はありません。初期化時の短い目印で目的を満たせるようにします。画面を他人に見せる場合も、口座番号や接続先など無関係な情報を含めず、必要な部分だけを共有してください。

入力値の引き継ぎを確認する

「ロットの既定値を書き換えたのに、MT4上では元の数値のまま」という場合、コンパイル失敗とは限りません。MetaQuotesのプログラム実行と再コンパイルの説明では、入力項目の構成を変えずに再コンパイルした場合、以前に指定した入力値が引き継がれることが説明されています。既定値だけの変更は、項目構成の変更には含まれません。

たとえば検証用EAでロットの既定値を0.10から0.20へ変えても、チャート側で0.03を指定していたなら、その0.03が使われる場合があります。この数値は仕組みを説明する架空の例であり、推奨ロットではありません。ソースの既定値と、現在のEAの設定画面に表示されている値を分けて確認します。

一方、入力項目の名前・型・順序・数を変えると扱いが変わります。更新前の設定がそのまま通用すると思い込まず、実際の設定画面で必要な値を見直してください。とくに損切り、数量、識別用の番号などは、更新後の値を確認してから検証を再開します。

反映されない原因を調べるために、入力設定をいきなり初期化するのはおすすめしません。意図して設定した値まで消えると、版の違いと設定の違いを同時に追うことになります。まず今の表示値と期待値を比較し、その項目だけをデモ環境で変更して確認する方が、原因を切り分けやすくなります。

また、同じEAを複数チャートへ適用していると、片方だけ設定が違うことも考えられます。識別表示が合っているのに結果が違う場合は、EA名だけでなく、通貨ペア・時間足・チャート側の入力値を確認しましょう。「同じファイルを使った」と「同じ条件で動かした」は分けて考えると整理できます。

本番へ渡す前にデモで検証する

ビルドできたら、すぐ本番口座のEAへ上書きするのではなく、デモ環境で版と設定を確認します。稼働中のEAは、再コンパイルによって初期化処理が呼び直される場合があります。現在の運用チャートを、単にコンパイルの成否を試す場所にしない方がよいでしょう。

自動売買の停止設定とEAプログラムの実行停止も同じ意味ではありません。MT4のEA設定の公式ヘルプでは、自動売買を許可しない場合もEA自体は動作でき、売買操作が制限されることが示されています。表示や初期化を確かめたい作業と、注文を出して確かめる作業を分けてください。

最初は「新しい識別表示が出る」「意図した入力値になっている」「初期化時のエラーがない」の三点を確認します。その後、対象の通貨ペアと時間足など、EAの前提に合わせて動作検証を進めます。注文が出ないことだけを根拠にコンパイル失敗と判断せず、条件未成立と実行時のエラーを区別しましょう。

EAからカスタムインジケーターを使う構成では、本体がビルドできても、利用時の配置や指定名を別に確かめる必要があります。インジケーター側の準備が課題なら、MT4のカスタムインジケーター導入と確認を確認してください。本記事のビルド診断と、利用する部品の導入作業を分けると、確認漏れを減らせます。

一から自分の売買条件を形にすることが目的なら、NoCode EA StudioのEA作成方法と受取条件を確認する選択肢もあります。条件ブロックで組み立て、MT4用のEX4を受け取れるサービスですが、既存mq4の修理を代行する案内ではありません。受け取りには所定のパートナーリンクからの口座開設と口座認証が必要です。既存ソースを修正したい方は、そのコードと依存ファイルの確認を続けましょう。

MT4のコンパイル確認を終える基準

MT4のコンパイル作業は、F7を押して終わりではありません。「対象のソースをビルドできた」「目的のMT4がそのEX4を使う」「実際の設定値を確認した」という三段階がそろうと、次の動作検証へ進めます。エラーの数だけを見るより、どこまで確認済みかを明確にする方が役立ちます。

• EA本体のmq4と保存先が、今回編集した対象と一致している
• 今回のコンパイルにエラーがなく、警告の内容を確認している
• 出力したEX4と稼働先のEX4を照合し、版を確認している
• デモ環境で入力値と初期化結果を見てから動作検証へ進む

エラーが残ればMetaEditorへ、成功したのに版が違えば保存先と転送先へ、版が合うのに数値が違えば入力設定へ戻ります。この順番なら、再インストールやコードの全面変更に進む前に、今の問題に必要な確認へ絞れます。ビルド成功は利益や損失回避を保証するものではないため、確認できた版と設定を前提に検証を続けてください。