MQL5デバッグ・ログファースト開発完全ガイド｜Print・Expertsログ・再現条件の整理

MQL5でEAやインジケーターを開発していると、「コンパイルは通るのに動かない」「EAを入れても注文しない」「CopyBufferで値が取れない」「WebRequestや通知が失敗する」「バックテストでは動くのに通常チャートでは動きが違う」といった問題が起きることがあります。

このような不具合を確認する時に重要なのは、いきなりコードを大きく書き換えることではありません。まず、どの処理まで進んだのか、どの条件で止まったのか、どの値が想定と違うのかをログで追える状態にすることが重要です。

この記事では、MQL5開発におけるログファースト開発の考え方を整理します。Print、PrintFormat、Expertsログ、Journalログ、GetLastError、retcode、MetaEditorデバッガ、ブレークポイント、変数確認、再現条件、サポート依頼前の情報整理まで、実務で原因を追いやすくするための確認手順をまとめます。

なお、この記事はMT5 / MQL5の開発、デバッグ、ログ確認、不具合確認、開発依頼前整理を目的とした技術記事です。特定の売買判断、利益、勝率、損失回避、推奨ロット、推奨銘柄を案内するものではありません。

この記事で確認すること

MQL5デバッグで最初に考えること

MQL5の不具合調査では、最初に「どこが間違っているか」を断定しようとするよりも、「どこまで処理が進んだか」を確認できるようにします。たとえば、EAが注文しない場合でも、シグナルが不成立なのか、発注前チェックで止まったのか、OrderSendやCTradeで注文が失敗したのか、そもそもOnTickが動いていないのかで対応が変わります。

そのため、MQL5開発では、ログを後付けの確認手段ではなく、設計の一部として考えます。OnInitで初期状態を出す、OnTickで判定の入口を出す、フィルターで止めた理由を出す、注文処理ではretcodeを出す、外部連携では送信結果を出す、といった形で、責務ごとにログを分けます。

ログが不足している状態でコードだけを見ても、「条件が成立していない」のか「条件は成立したが発注を止めた」のか「注文は送ったが失敗した」のかが分からないことがあります。ログファースト開発は、この曖昧さを減らすための考え方です。

ログファースト開発とは

ログファースト開発とは、動作確認や不具合調査をしやすくするために、処理の入口、判定、見送り理由、実行結果、エラー情報をあらかじめログとして残す考え方です。MQL5では、PrintやPrintFormatを使ってExpertsログへ情報を出力できます。

ログファースト開発では、単に「ログを多く出す」ことが目的ではありません。必要なのは、後から読んだ時に原因を確認られるログです。たとえば、すべてを「ENTRY NG」とだけ出しても、スプレッドで止まったのか、ロットで止まったのか、証拠金で止まったのか、取引時間で止まったのかが分かりません。

ログは、開発者だけでなく、検証担当者、運用者、サポート担当者が確認する情報でもあります。そのため、ログには、処理名、状態、理由、主要値、現在値、設定値、チケット番号、Magic Number、銘柄、時間足などを必要に応じて含めます。一方で、口座番号、パスワード、Webhook URL、APIキー、認証トークンなどの機密情報は出さないようにします。

PrintとPrintFormatの使い分け

MQL5では、ログ出力にPrintやPrintFormatを使えます。Printは複数の値を簡単に出せるため、簡単な確認に向いています。PrintFormatは、文字列の形式を整えながら出力できるため、ログを一定の形式に揃えたい場合に向いています。

ログ調査では、毎回出力形式が変わると検索しにくくなります。そのため、重要な状態は、接頭辞やキー名を固定して出すと便利です。たとえば、INIT、SIGNAL、FILTER、PRECHECK、ORDER、EXIT、WEBREQUEST のように処理の種類を分けると、Expertsログ内で検索しやすくなります。

開発初期はログを多めに出して構いません。ただし、長時間稼働するEAやインジケーターでは、毎ティックで大量にログを出すと、ログが読みにくくなり、ファイルサイズも増えます。通常ログ、詳細ログ、異常時ログを分ける設計が必要です。

ExpertsログとJournalログの違い

MT5でログを確認する時は、ExpertsログとJournalログを分けて見ます。Expertsログは、EAやインジケーターが出力したログや実行時のエラー確認に使います。Journalログは、MT5全体の操作、接続、取引許可、プラットフォーム側の状態を確認する時に使います。

EAが動かない時、Expertsログだけを見ても分からないことがあります。自動売買が許可されていない、サーバー接続が不安定、取引が無効、チャートへの適用時に問題がある、といった環境側の情報はJournalログに出ることがあります。

GetLastErrorとretcodeを分けて見る

GetLastError()は_LastErrorの値を返しますが、呼び出しても値は自動的に0へ戻りません。処理単位ごとに新しいエラーだけを確認したい場合は、対象処理の直前でResetLastError()を使って境界を作ります。

注文処理ではGetLastErrorだけで成否を判断せず、OrderSend()の戻り値に加えてMqlTradeResult.retcodeも確認します。端末側の実行時エラーと、取引サーバーから返る処理結果は別の情報です。

MQL5の注文処理や外部連携では、GetLastErrorとretcodeを混同しないことが重要です。GetLastErrorは、MQL5関数の実行時エラーを確認するために使います。一方、取引リクエストの結果では、MqlTradeResultのretcodeを確認する場面があります。

注文が失敗した時に、GetLastErrorだけを見ても原因が十分に分からない場合があります。OrderSendやCTradeの結果では、注文サーバー側が返すretcodeを確認し、無効な価格、無効なStops、取引不可、リクエスト拒否、証拠金不足などを分けて確認する必要があります。

注文処理のログでは、「注文しようとした内容」と「注文結果」を分けて出すと確認しやすくなります。たとえば、BUY 0.10 lotを送ろうとしたのか、実際にサーバーがどのretcodeを返したのか、SL/TP距離やスプレッドが関係しているのかを見られるようにします。

MetaEditorデバッガの使いどころ

MetaEditorにはデバッグ機能があります。ブレークポイントを置いて処理を一時停止し、変数の値や処理の流れを確認できます。ログだけでは追いにくい条件分岐や、どの行まで処理が進んでいるかを確認する時に役立ちます。

ただし、EAのすべての不具合をデバッガだけで解決しようとすると、実際のチャート環境、ティック、取引サーバー、外部連携、Strategy Testerとの差を見落とすことがあります。デバッガは、ログ確認と組み合わせて使うものとして考えると安全です。

OnInitで残すログ

OnInitは、EAやインジケーターが起動した時に実行される初期化処理です。ここでは、inputの確認、インジケーターハンドルの作成、ファイルパス、外部連携設定、認証状態、初期化成功/失敗を確認します。

OnInitで何もログを出していないと、EAが起動しているのか、設定不正で止まったのか、ハンドル作成に失敗したのかが分かりにくくなります。特に、CopyBufferを使うEA、WebRequestを使うEA、CSVやファイル出力を使うEAでは、OnInit時点のログが重要です。

OnTickで残すログ

OnTickはEAで価格更新ごとに呼び出される処理です。OnTick内で毎回詳細ログを出しすぎるとログが膨大になりますが、処理の入口、判定タイミング、新バー判定、シグナル判定、発注前チェック、注文実行の流れは追えるようにしておく必要があります。

特に、EAが注文しない場合は、OnTickが動いていないのか、新バー判定で止まっているのか、シグナル不成立なのか、フィルターで止まっているのかを分けます。すべてを「注文なし」として扱うと、原因を追えません。

OnTimerで残すログ

OnTimerは、一定間隔で処理を行うためのイベントです。状態確認、外部連携、定期ログ、通知、パネル更新、長時間稼働の監視などに使えます。OnTickと違い、ティックが来ない時間帯でも定期処理を行える点が特徴です。

ただし、OnTimerに重い処理を入れすぎると、EA全体の動作に影響することがあります。外部連携、CSV書き込み、通知送信、状態集計などは、実行間隔、失敗時の再試行、ログ粒度を決めておく必要があります。

OnTradeTransactionで残すログ

OnTradeTransactionは、注文、約定、ポジション変化などの取引イベントを確認する時に使います。EAが注文を送った後、実際にどのようなイベントが発生したのかを追うために役立ちます。

注文送信時のログだけでは、約定したのか、拒否されたのか、部分約定したのか、履歴にどのように残ったのかが分かりにくいことがあります。OnTradeTransactionを使う場合は、イベント種別、注文番号、Deal番号、ポジションID、Magic Number、銘柄、方向などを必要に応じてログ化します。

ただし、OnTradeTransactionのログは多くなりやすいため、すべてを細かく出し続けるのではなく、開発時・検証時・異常時で粒度を分けるのがよいです。

CopyBufferとiCustomのデバッグ

EAからインジケーター値を使う場合、iCustomやCopyBufferを使うことがあります。CopyBufferで値が取れない場合、インジケーターハンドルの作成失敗、パラメータ不一致、取得本数不足、配列方向の誤解、確定足と現在足の混同などが原因になることがあります。

この種の不具合では、値が0なのか、EMPTY_VALUEなのか、取得に失敗しているのかを分けて確認することが重要です。単に「インジ値が0」と見える場合でも、実際にはCopyBufferが失敗して、配列に値が入っていないだけの場合があります。

OrderSendとCTradeのデバッグ

注文処理の不具合では、シグナル判定と注文送信を分けて確認します。シグナルが出ていないのにOrderSendやCTradeを疑っても原因に到達できません。逆に、シグナルは出ているのに発注前チェックや注文送信で止まっている場合は、retcodeや銘柄仕様を確認する必要があります。

OrderSendを使う場合は、MqlTradeRequestとMqlTradeResultを分けてログに残します。CTradeを使う場合でも、BuyやSellの戻り値だけでなく、ResultRetcode、ResultRetcodeDescription、GetLastErrorなどを確認します。

WebRequest・通知・外部連携のデバッグ

WebRequest、Discord通知、Google Sheets連携、Webhook通知などを使う場合は、EA本体の売買処理と外部連携処理を分けて確認します。通知が届かないことと、EAの売買判定が間違っていることは別問題です。

外部連携では、MT5側のWebRequest許可URL、送信ON/OFF、送信先の応答、タイムアウト、JSON形式、文字コード、改行、認証情報の扱いなどを確認します。ログには、送信成功/失敗、HTTPステータス、GetLastError、送信対象イベントを残します。ただし、Webhook URL、APIキー、tokenの実値は出さないようにしてください。

再現条件を記録する

不具合調査で重要なのは、「一度だけ起きた」ではなく、「どの条件で起きたか」を記録することです。MQL5の不具合は、銘柄、時間足、スプレッド、口座タイプ、取引時間、setファイル、バックテスト条件、外部連携の状態によって再現性が変わることがあります。

再現条件が曖昧なままだと、開発側で同じ状態を作れず、原因確認が遅くなります。特に、EAの注文失敗、通知失敗、CopyBuffer失敗、バックテスト時だけの不具合は、再現条件の記録が重要です。

CSVログの保存先・書込み・列構成を設計する

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

MQL5でCSVログを出力する理由

EAの動作確認では、ExpertsログやJournalログを確認することが基本です。しかし、長期間の検証、複数条件の比較、フィルターごとの停止回数、注文結果の集計、バックテスト条件別の比較を行う場合、テキストログだけでは扱いにくいことがあります。

CSVログを出力しておくと、Excel、Google Sheets、Python、集計ツールで後から分析しやすくなります。たとえば、どのフィルターで止まった回数が多いか、OrderCheckで失敗した理由は何か、曜日や時間帯でシグナル発生数が違うか、バックテスト条件ごとの結果がどう変わるかを確認しやすくなります。

特にEA設計パターンで signal、filter、risk、execution、exit を分けている場合、それぞれの段階をCSVへ記録すると、EAが注文しない理由や、検証条件ごとの違いを追いやすくなります。

ExpertsログとCSVログを分ける

Expertsログは、EAの動作をその場で確認するために使いやすいログです。初期化成功、ハンドル作成失敗、OrderSend失敗、OnTimer動作など、EAの状態確認に向いています。一方で、行ごとの形式が自由なため、後から集計するには加工が必要です。

CSVログは、列を固定して保存するため、後から集計しやすい形式です。日付、銘柄、時間足、イベント種別、シグナル、フィルター結果、ロット、価格、retcode、コメントなどを列にしておけば、表計算ソフトで並べ替えや集計ができます。

実務では、Expertsログに原因追跡用の要約を出し、CSVログに検証・集計用の構造化データを出すのが扱いやすいです。どちらか一方だけに寄せるのではなく、役割を分けて使います。

保存場所：FilesフォルダとCommonフォルダ

MQL5でファイルを扱う時は、保存場所を理解しておく必要があります。通常のFileOpenでは、MT5データフォルダ内のMQL5\Files配下が使われます。FILE_COMMONを指定すると、複数のMetaTraderから共通で使えるCommon Files領域を利用できます。

EAごと、端末ごとにログを分けたい場合は通常のFilesフォルダが扱いやすいです。複数MT5間で共通のログや設定ファイルを使いたい場合はCommonフォルダが候補になります。ただし、Commonフォルダを使う場合は、複数EAや複数端末から同じファイルへ同時アクセスしないように注意が必要です。

ファイルが見つからない場合は、EAを動かしているMT5のデータフォルダを確認します。複数のMT5を使っている場合、別の端末データフォルダを見ていることもあります。

FileOpenの基本

FileOpenは、MQL5でファイルを開くための関数です。CSVログを出力する場合は、FILE_WRITE、FILE_READ、FILE_CSV、FILE_ANSI、FILE_COMMONなどのフラグを組み合わせて使います。

FileOpenに失敗した場合は、INVALID_HANDLEが返ります。その場合はGetLastErrorをログに出し、ファイル名、保存場所、権限、テスター環境、同時アクセスを確認します。

int OpenCsvFile(string file_name)
{
   ResetLastError();

   int handle = FileOpen(file_name,
                         FILE_READ | FILE_WRITE | FILE_CSV | FILE_ANSI,
                         ',');

   if(handle == INVALID_HANDLE)
   {
      PrintFormat("CSV_OPEN_FAIL file=%s last_error=%d",
                  file_name,
                  GetLastError());
      return INVALID_HANDLE;
   }

   PrintFormat("CSV_OPEN_OK file=%s handle=%d", file_name, handle);
   return handle;
}

この例では、CSV形式、ANSI文字コード、半角コンマ区切りでファイルを開いています。既存ファイルへ追記する場合は、FileSeekで末尾へ移動してからFileWriteを行います。

FileOpenフラグの考え方

FileOpenでは、どのような形式でファイルを開くかをフラグで指定します。CSVログでは、FILE_CSVとFILE_WRITEを使うことが多いです。既存ファイルの末尾に追記したい場合は、FILE_READも組み合わせて使うと扱いやすくなります。

文字コードは環境や確認方法によって扱いが変わります。日本語を含むCSVをExcelで確認する場合、文字化けの可能性があるため、実際の環境で表示確認を行ってください。ログ内の項目名を英数字中心にしておくと、文字化けや列崩れのリスクを減らせます。

FileWriteでCSVへ出力する

FileWriteは、開いたファイルへデータを書き込むために使います。FILE_CSVで開いたファイルに対してFileWriteを使うと、引数ごとに列として出力されます。

CSVログでは、最初にヘッダー行を出し、その後にデータ行を追加していく構成が扱いやすいです。ヘッダー行には、time、symbol、timeframe、event、signal、reason、price、volume、retcodeなど、後から集計したい列を並べます。

void WriteCsvHeader(int handle)
{
   FileWrite(handle,
             "server_time",
             "symbol",
             "timeframe",
             "event",
             "signal",
             "reason",
             "price",
             "volume",
             "retcode",
             "comment");
}

void WriteCsvLogRow(int handle,
                    string event_name,
                    string signal_name,
                    string reason,
                    double price,
                    double volume,
                    int retcode,
                    string comment)
{
   FileWrite(handle,
             TimeToString(TimeCurrent(), TIME_DATE | TIME_SECONDS),
             _Symbol,
             EnumToString((ENUM_TIMEFRAMES)Period()),
             event_name,
             signal_name,
             reason,
             DoubleToString(price, _Digits),
             DoubleToString(volume, 2),
             retcode,
             comment);
}

この例では、CSVのヘッダー行とデータ行を分けています。event列には、SIGNAL、FILTER、RISK、ORDER、EXIT、ERRORなどを入れると、後からイベント種別で集計しやすくなります。

追記方式とヘッダー行の扱い

CSVログでは、EA起動ごとに新規ファイルを作る方法と、既存ファイルに追記する方法があります。検証単位でファイルを分けたい場合は新規ファイル、日別に継続記録したい場合は追記方式が扱いやすいです。

追記方式では、ファイルが空の場合だけヘッダー行を書き、既存ファイルにデータがある場合は末尾へ移動してデータ行だけ追加します。ヘッダー行が毎回増えると、後から集計しにくくなります。

int OpenCsvForAppend(string file_name)
{
   ResetLastError();

   int handle = FileOpen(file_name,
                         FILE_READ | FILE_WRITE | FILE_CSV | FILE_ANSI,
                         ',');

   if(handle == INVALID_HANDLE)
   {
      PrintFormat("CSV_OPEN_FAIL file=%s last_error=%d",
                  file_name,
                  GetLastError());
      return INVALID_HANDLE;
   }

   bool is_empty = (FileSize(handle) == 0);

   FileSeek(handle, 0, SEEK_END);

   if(is_empty)
      WriteCsvHeader(handle);

   PrintFormat("CSV_READY file=%s empty=%s",
               file_name,
               is_empty ? "Y" : "N");

   return handle;
}

この例では、FileSizeで空ファイルかどうかを確認し、空の場合だけヘッダー行を書いています。その後、FileSeekで末尾へ移動して追記できるようにしています。

CSVファイル名の設計

CSVログのファイル名は、後から見た時に内容が分かるように設計します。EA名、銘柄、時間足、日付、検証IDなどを含めると、ファイルを探しやすくなります。

ただし、ファイル名に口座番号、個人情報、token、Webhook URLなどを含めてはいけません。共有する可能性があるログファイルには、機密情報を入れない設計にしてください。

string BuildDailyCsvFileName(string prefix)
{
   MqlDateTime dt;
   TimeToStruct(TimeCurrent(), dt);

   string file_name = StringFormat("%s_%s_%s_%04d%02d%02d.csv",
                                   prefix,
                                   _Symbol,
                                   EnumToString((ENUM_TIMEFRAMES)Period()),
                                   dt.year,
                                   dt.mon,
                                   dt.day);

   return file_name;
}

この例では、prefix、銘柄、時間足、日付を含めたファイル名を作成しています。日別ファイルにすると、ログ肥大化を抑えやすくなります。

EA検証ログの列設計

EA検証用のCSVログでは、後から何を確認したいかによって列を決めます。単に価格や注文番号だけを保存しても、なぜエントリーしたのか、なぜ見送ったのかを確認できません。

signal、filter、risk、execution、exitを分けているEAでは、各段階の結果を列にして保存すると、検証時に分析しやすくなります。

SIGNAL / FILTER / RISK / ORDER / EXIT をCSVで分ける

EAが注文しない理由を確認するには、どの段階で止まったかを記録する必要があります。シグナルが出ていないのか、フィルターで止まったのか、リスク確認で止まったのか、OrderSendで失敗したのかを分けて保存します。

CSVのevent列にSIGNAL、FILTER、RISK、ORDER、EXITを入れておくと、後からイベント種別ごとの件数を集計できます。reason列には、NO_SIGNAL、SPREAD、TIME_FILTER、BAD_VOLUME、NOT_ENOUGH_MARGIN、ORDER_RETCODEなどを入れると原因別に確認できます。

バックテストでCSVを出力する時の注意

ストラテジーテスターでCSVログを出力する場合、通常の実チャートとは保存場所や確認手順が異なることがあります。テスター実行後にファイルが見つからない場合は、テスター用のFilesフォルダや、実行しているMT5のデータフォルダを確認してください。

バックテストでは、全ティックや1分OHLCなどのモデル、対象期間、スプレッド、銘柄、時間足、setファイルが結果に影響します。CSVログには、検証条件を識別できる情報を入れると、後から比較しやすくなります。

ただし、バックテスト中に毎ティック大量のCSV出力を行うと、テスト速度が低下したり、ファイルが肥大化したりします。必要なイベントだけを出力する、詳細ログON/OFFをinputで切り替える、日別または検証ID別にファイルを分けると扱いやすくなります。

input bool InpEnableCsvLog = true;
input bool InpVerboseCsvLog = false;

void LogSignalEvent(string signal_name, string reason)
{
   if(!InpEnableCsvLog)
      return;

   if(!InpVerboseCsvLog && reason == "NO_SIGNAL")
      return;

   int handle = OpenCsvForAppend(BuildDailyCsvFileName("eaf_signal_log"));

   if(handle == INVALID_HANDLE)
      return;

   WriteCsvLogRow(handle,
                  "SIGNAL",
                  signal_name,
                  reason,
                  SymbolInfoDouble(_Symbol, SYMBOL_BID),
                  0.0,
                  0,
                  "");

   FileClose(handle);
}

この例では、CSVログのON/OFFと詳細ログON/OFFを分けています。通常検証では重要イベントだけを出し、詳細検証時だけNO_SIGNALなどの細かいログを出す設計です。

OnInit、OnTimer、OnDeinitとCSV出力

CSVログ出力は、イベント処理と組み合わせて設計します。OnInitではログ設定やファイル作成可否を確認します。OnTickではシグナルや注文に関係するイベントを記録します。OnTimerでは定期監視や通知キューの状態を記録できます。OnDeinitでは終了理由や最終状態を記録できます。

ただし、ファイルを開きっぱなしにする設計と、必要な時だけ開いて閉じる設計にはそれぞれ注意点があります。必要な時だけ開いて閉じる方が単純ですが、頻度が高いと負荷が増えます。開きっぱなしにする場合は、OnDeinitで必ず閉じる必要があります。

ログ肥大化対策

CSVログは便利ですが、出力しすぎるとファイルが肥大化します。特にOnTickで毎ティック出力する設計は、バックテストでも実運用でもログ量が増えやすくなります。

ログ肥大化を防ぐには、イベント単位で出力する、エラー時だけ出力する、詳細ログON/OFFを用意する、日別ファイルに分ける、最大行数や最大ファイルサイズを意識するなどの対策が必要です。

文字コードと区切り文字の注意点

CSVログでは、文字コードと区切り文字にも注意が必要です。日本語を含むCSVをExcelで開くと、環境によって文字化けすることがあります。また、区切り文字が半角コンマの場合、コメント内にコンマが含まれると列崩れの原因になることがあります。

実務では、CSVの列名やreasonを英数字中心にすると、文字化けや集計時のトラブルを減らせます。日本語コメントを出す場合は、実際にExcelやGoogle Sheetsで開いて確認してください。

また、ログ項目に改行、タブ、カンマ、引用符が含まれると、後から集計しにくくなる場合があります。comment列は短くし、必要なら詳細はExpertsログ側に出す設計が扱いやすいです。

機密情報をCSVに出さない

CSVログは、検証依頼やサポート時に共有される可能性があります。そのため、口座番号、氏名、メールアドレス、パスワード、APIキー、Webhook URL、token、ライセンスキーなどの機密情報を出力してはいけません。

外部連携や通知機能を検証する場合でも、ログに出すのは送信種別、送信結果、HTTPステータス、エラー種別程度に抑えます。Webhook URL全体やAPIキーをそのまま出すと、第三者に悪用される危険があります。

Google Sheets連携前のローカル記録として使う

EAの検証記録をGoogle Sheetsへ送信する場合でも、まずはローカルCSVへ記録する設計が有効です。WebRequestや外部サービス連携は、通信エラー、URL設定、権限、レート制限、レスポンス形式などの影響を受けます。

ローカルCSVへ保存しておけば、外部送信に失敗しても、EA側で何が起きたかを後から確認できます。外部連携は便利ですが、EA本体の検証ログを完全に外部サービスへ依存させない方が安全です。

実務では、EA内部でイベントを生成し、CSVへ保存し、必要に応じてOnTimerで外部送信するように分けると扱いやすくなります。CSVは検証の基準となる記録、外部シートは共有・閲覧用と考えることもできます。

ログに出してよい情報・出してはいけない情報

ログは不具合調査に役立ちますが、何でも出してよいわけではありません。特に、口座番号、認証情報、Webhook URL、APIキー、token、外部エンドポイントの実値は、ログに出さないようにしてください。

共有用のログを作る場合は、必要な技術情報を残しつつ、機密情報はマスクします。たとえば、Webhook URLは***masked***、tokenは先頭数文字だけ、口座番号は出さない、といったルールを決めておくと安全です。

デバッグ時の確認順序

MQL5の不具合調査では、確認順序を決めておくと効率的です。いきなりコード全体を読むより、コンパイル、配置、起動、初期化、判定、発注前チェック、注文結果、決済、通知、外部連携の順に確認すると原因を絞り込みやすくなります。

症状別の確認表

不具合の症状ごとに、最初に見る場所は変わります。コンパイルエラー、起動失敗、注文しない、通知されない、バックテストと通常チャートで違う、といった症状を分けて確認してください。

バックテストと通常チャートの違いを記録する

バックテストで動くEAが、通常チャートでは同じように動かないことがあります。原因として、ティックの流れ、スプレッド、サーバー時間、外部連携、WebRequest、取引許可、約定条件、銘柄仕様の差などが考えられます。

バックテスト時は、銘柄、時間足、期間、スプレッド、モデル、初期残高、setファイル、テスターのログを記録します。通常チャートでは、実際のExpertsログ、Journalログ、チャート状態、EAのinput、通信状態を記録します。

バックテスト結果は、将来の結果を保証するものではありません。ここでは、EAの処理が想定どおりに動いているか、ログで原因を追えるか、設定条件を再現できるかを確認する材料として扱います。

問い合わせ前・開発依頼前に整理すること

不具合相談や開発依頼では、「動きません」「注文しません」だけでは確認が難しくなります。開発者やサポート側が再現しやすいように、対象ファイル、環境、setファイル、ログ、スクリーンショット、発生手順を整理してください。

記事固有の実務チェック表

CSV出力の不具合と提出する仕様を確認する

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

MQL5のファイル操作では、ファイルが作成されない、CSVが空になる、ヘッダーが毎回増える、文字化けする、バックテスト後にファイルが見つからない、ログが大きくなりすぎる、といった不具合が起きることがあります。

開発依頼前に整理するCSVログ仕様

EAや検証補助ツールでCSVログ出力を依頼する場合は、何を記録したいのかを事前に整理してください。単に「ログをCSVに出したい」だけでは、必要な列、出力タイミング、保存場所、ファイル名、文字コード、ログ量、機密情報の扱いが不明です。

特に、バックテスト検証用なのか、実運用の記録用なのか、サポート確認用なのかで設計が変わります。検証用なら詳細なシグナル・フィルター情報が必要ですが、実運用ではエラーや注文結果中心に絞る方が扱いやすい場合があります。

実務チェック表

よくある質問

MQL5のデバッグでは最初に何を見るべきですか？

最初に、コンパイルエラー、配置先、OnInitログ、Expertsログ、Journalログを確認します。EAが動かない場合でも、初期化失敗、シグナル不成立、発注前チェック停止、注文失敗、外部連携失敗など原因が分かれるため、順番に分けて確認することが重要です。

PrintとPrintFormatはどちらを使えばよいですか？

簡単な確認ならPrintでも十分です。ログ形式を揃えたい場合、複数の値を見やすく並べたい場合、検索しやすいログを残したい場合はPrintFormatが向いています。実務では、重要なログほど形式を揃えると確認しやすくなります。

ExpertsログとJournalログは何が違いますか？

ExpertsログはEAやインジケーターの内部処理確認に使います。JournalログはMT5全体の操作、接続、取引許可、プラットフォーム側の状態確認に使います。EAが動かない時は、両方を見る方が原因を追いやすくなります。

GetLastErrorだけ見れば注文失敗の原因は分かりますか？

GetLastErrorだけでは不十分な場合があります。OrderSendやCTradeの注文結果では、MqlTradeResultやResultRetcodeなどでretcodeを確認する必要があります。注文要求の内容と注文結果を分けてログに残してください。

MetaEditorデバッガは必ず使うべきですか？

必須ではありませんが、条件分岐や変数の値を確認したい場合には役立ちます。ただし、ティック、取引サーバー、外部連携、通常チャート環境の問題はログで追う方が確認しやすい場合もあります。デバッガとログを併用するのが現実的です。

CopyBufferで値が取れない時は何を確認しますか？

ハンドルが有効か、BarsCalculatedで必要本数が揃っているか、CopyBufferの戻り値が想定どおりか、配列方向や確定足の指定が正しいかを確認します。値が0なのか、取得に失敗しているのかをログで分けることが重要です。

ログには何でも出してよいですか？

いいえ。EA名、バージョン、銘柄、時間足、retcode、GetLastErrorなどは原因確認に役立ちますが、口座番号、パスワード、Webhook URL、APIキー、tokenなどの機密情報はログに出さないようにしてください。

不具合相談前に何を準備すればよいですか？

対象ファイル名、バージョン、setファイル、Expertsログ、Journalログ、発生時刻、銘柄、時間足、スクリーンショット、再現手順を整理してください。認証情報やWebhook URLなどはマスクして共有する必要があります。

MQL5でCSVログを出すには何を使いますか？

主にFileOpen、FileWrite、FileCloseを使います。CSV形式で出力したい場合は、FileOpenでFILE_CSVを指定し、FileWriteで列ごとの値を書き込みます。

CSVログはExpertsログの代わりになりますか？

完全な代わりではありません。Expertsログはその場の原因追跡に向いており、CSVログは集計や検証比較に向いています。両方を役割分担して使うのが実務的です。

バックテストで出力したCSVが見つからない時はどうしますか？

通常のMQL5\Filesではなく、テスター側のFilesフォルダに出力されている場合があります。実行しているMT5のデータフォルダ、テスター環境、FILE_COMMONの有無を確認してください。

CSVが文字化けする場合はどうしますか？

文字コードと表示ソフト側の読み込み設定を確認します。ログ項目名やreasonを英数字中心にすると、文字化けや集計時のトラブルを減らしやすくなります。

OnTickで毎回CSV出力してもよいですか？

推奨しません。OnTickは呼び出し頻度が高いため、毎ティック出力するとログが肥大化しやすくなります。イベント発生時、エラー時、詳細ログON時などに絞る設計が扱いやすいです。

CSVに口座番号やWebhook URLを出してもよいですか？

出さないでください。CSVログは共有される可能性があるため、口座番号、パスワード、APIキー、token、Webhook URL、ライセンスキーなどの機密情報は出力しない設計にします。

関連する確認ページ

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

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

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

まとめ

MQL5のデバッグでは、いきなりコード全体を疑うのではなく、処理の入口、初期化、シグナル、フィルター、発注前チェック、注文結果、決済、通知、外部連携を分けて確認することが重要です。PrintやPrintFormatを使い、Expertsログで処理の流れを追えるようにしてください。

注文失敗では、GetLastErrorだけでなく、retcodeやMqlTradeResultを確認します。CopyBufferでは、ハンドル、BarsCalculated、戻り値、配列方向、確定足を分けて確認します。WebRequestや通知では、MT5側の許可URL、HTTP応答、送信ON/OFF、外部側の応答を確認します。

ログは多ければよいわけではありません。原因を追える形式で、必要な情報だけを整理して出すことが大切です。Webhook URL、APIキー、token、口座番号、パスワードなどの機密情報はログへ出さないようにしてください。

不具合相談や開発依頼を行う場合は、対象ファイル、setファイル、Expertsログ、Journalログ、スクリーンショット、発生時刻、再現手順を整理してください。再現条件を残しておくことで、開発側・検証側・運用側の確認が進めやすくなります。

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

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

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

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

利用条件・相談窓口