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

MQL5でEA、インジケーター、スクリプト、補助ツールを開発・改修する場合、不具合の原因を正確に追うには、ログの出し方と再現条件の整理が重要です。

「動かない」「注文されない」「決済されない」「通知が届かない」「バックテストでは動くがリアル環境では違う」「コンパイルエラーが出る」といった状況では、画面だけを見ても原因を特定できないことがあります。

Expertsログ、Journalログ、MetaEditorのエラー、GetLastError、MqlTradeResult.retcode、setファイル、銘柄名、時間足、発生時刻、直前の操作を組み合わせて確認する必要があります。

この記事では、MQL5のデバッグとログファースト開発の考え方を、開発、検証、不具合調査、開発依頼前整理、販売後サポートで使いやすい形に整理します。

このページは、MT5 / MQL5の技術学習記事です。投資判断、売買タイミング、利益保証、勝率保証、損失回避保証、推奨ロット、推奨銘柄、特定ブローカー誘導を目的とした内容ではありません。

この記事で確認すること

ログファースト開発とは

ログファースト開発とは、EAやインジケーターの動作を後から確認できるように、最初からログ設計を含めて開発する考え方です。

MQL5では、条件が未成立だったのか、データ取得に失敗したのか、risk制御で止まったのか、注文リクエストが失敗したのか、通知だけが失敗したのかを分けて記録すると、不具合調査が進めやすくなります。

ログファースト開発では、ログを大量に出せばよいわけではありません。必要な時に、必要な情報を、同じ形式で追えることが重要です。

1. MetaEditorで最初に確認すること

MQL5開発で最初に確認するのは、MetaEditor上でコンパイルエラーが出ていないかです。

EAやインジケーターは、コンパイルできなければMT5上で正常に動作確認できません。実行時の不具合を調べる前に、まずコンパイル結果を確認します。

コンパイルエラーは、1つの原因から複数行に連鎖して出ることがあります。上から順番に確認し、最初の根本原因を探すことが大切です。

2. コンパイルエラーの行番号とメッセージの読み方

MetaEditorのエラー欄では、ファイル名、行番号、列番号、エラーメッセージを確認します。

よくあるコンパイルエラーには、未定義識別子、型不一致、括弧不足、セミコロン不足、関数引数の不一致、includeファイル不足、文字コード由来のエラーなどがあります。

エラーが表示された行だけでなく、その直前の行やブロック全体を見ることも重要です。括弧不足やセミコロン不足は、実際の原因が表示行より前にある場合があります。

3. Printログの基本

PrintやPrintFormatは、EAやインジケーターの状態をExpertsログへ出すためによく使われます。

Printログでは、単に「OK」「NG」と出すだけではなく、どの関数で、どの銘柄・時間足で、どの条件を確認し、どの結果になったのかを残すと調査しやすくなります。

PrintFormat("DIAG/SIGNAL symbol=%s tf=%s gate=%s reason=%s",
            _Symbol,
            EnumToString(_Period),
            "NG",
            "spread_limit");

上記は、ログ形式の考え方を示す最小例です。売買ロジックや推奨設定を示すものではありません。

Printログは便利ですが、出しすぎると読みにくくなります。ログカテゴリ、理由コード、出力頻度を整理して使ってください。

4. ExpertsログとJournalログの違い

MT5で不具合を調査する時は、ExpertsログとJournalログを分けて確認します。

Expertsログは、EAやインジケーター側のPrint、エラー、状態出力を確認する場所です。Journalログは、MT5端末、取引サーバー、ストラテジーテスター、接続、読み込みなどの端末側情報を確認する場所です。

「EAが動かない」と感じる場合でも、ExpertsログだけでなくJournalログも確認してください。EA側の条件未成立なのか、MT5端末側の問題なのかを分ける必要があります。

5. GetLastErrorを使う時の注意

GetLastErrorは、直近のエラー番号を確認するために使います。

ただし、GetLastErrorの値だけを見ても、原因を断定できるとは限りません。どの関数を呼び出した直後に確認したのか、対象symbolやtimeframeは何だったのか、戻り値はどうだったのかを一緒に記録する必要があります。

ResetLastError();

int copied = CopyRates(_Symbol, PERIOD_M15, 0, 10, rates);

if(copied < 10)
{
   int err = GetLastError();

   PrintFormat("DIAG/DATA copy_rates_failed symbol=%s tf=%s requested=%d copied=%d error=%d",
               _Symbol,
               "PERIOD_M15",
               10,
               copied,
               err);
}

この例は、データ取得失敗時のログ形式を示すものです。実際のEAでは、必要本数、対象時間足、再試行方針、データ不足時の扱いを仕様として決めてください。

GetLastErrorの値を確認した後は、必要に応じてエラーの意味を確認します。ただし、エラー番号だけでなく、前後のログも必ず確認してください。

6. MqlTradeResult.retcodeを記録する理由

注文処理の不具合では、GetLastErrorだけでなく、MqlTradeResult.retcodeを確認することが重要です。

MQL5の注文処理では、取引リクエストを送った後に、取引サーバー側の応答としてretcodeが返る場合があります。注文できなかった理由を確認するには、retcode、order、deal、comment、request内容を合わせて記録します。

注文処理を調査する場合は、execution層のログとして、requestとresultを分けて記録すると確認しやすくなります。

7. 再現条件を整理する方法

不具合調査で最も重要なのは、再現条件を整理することです。

「たまに動かない」「急に止まった」「昨日は動いた」といった情報だけでは、原因を追うことが難しくなります。いつ、どのEAで、どの銘柄・時間足で、どのsetファイルを使い、どの操作をした時に発生したのかを整理してください。

再現条件は、開発者だけでなく検証担当者にとっても重要です。同じ条件で再確認できる形に整理してください。

8. setファイル・銘柄・時間足・発生時刻の記録

MQL5の不具合調査では、同じEAでもsetファイル、銘柄、時間足、発生時刻が違うと、再現できない場合があります。

特に、外部連携、時間制御、スプレッド制御、マルチタイムフレーム、インジケーター連携、ファイル出力を含むEAでは、条件差が調査結果に大きく影響します。

setファイルには、通知設定、WebRequest URL、外部連携設定、認証に関わる値が含まれる場合があります。共有前に必ず内容を確認してください。

9. ログが多すぎる時の整理方法

ログは重要ですが、多すぎるログは逆に原因調査を難しくします。

毎tickで大量にPrintを出す、同じメッセージを連続出力する、判定値をすべて出し続ける、外部連携ログを毎回詳細表示する、といった状態では、必要な情報が埋もれてしまいます。

ログ量の調整では、必要な情報を消しすぎないことも重要です。通常運用、検証、バックテスト、詳細調査でログレベルを分けると確認しやすくなります。

10. 外部連携エラーを調査する時の流れ

WebRequest、Discord通知、Google Sheets連携、外部API、認証処理を含むEAでは、外部連携特有の確認が必要です。

外部連携エラーでは、EA側のデータ生成、MT5のWebRequest許可、URL、HTTP応答、外部サービス側の状態を分けて確認します。

Webhook URL、GAS URL、APIキー、認証トークンの実値は、本文、ログ、スクリーンショット、問い合わせ本文へそのまま含めないでください。

11. バックテスト中のログ確認

バックテスト中のログは、リアル環境のログと見え方が異なる場合があります。

Strategy Testerでは、テスト条件、ヒストリカルデータ、テストモデル、スプレッド、外部連携の扱い、ファイル出力先、ログ量が結果や確認しやすさに影響します。

バックテスト結果は、将来の結果を保証するものではありません。結果画面だけでなく、条件、setファイル、ログ、テストモデルをセットで確認してください。

12. 問い合わせ前に送る情報

MQL5の不具合調査を相談する場合は、状況を再現できる情報を整理してください。

ログだけ、スクリーンショットだけ、結果画面だけでは不足する場合があります。setファイル、対象EA、発生時刻、銘柄、時間足、Expertsログ、Journalログをセットで整理すると確認しやすくなります。

問い合わせが必要な場合は、必要情報を整理したうえで、対象範囲、再現条件、確認したログをまとめてください。

13. 送ってはいけない情報

ログやsetファイル、スクリーンショットを送る時は、機密情報が含まれていないか確認してください。

送ってよいか判断できない情報は、そのまま送らず、まずマスクまたは削除してください。

MQL5デバッグ・ログファースト確認チェック表

MQL5のデバッグや不具合調査では、以下を確認してください。

よくある質問

Printログを増やせば原因は分かりますか？

ログを増やすだけでは原因が分からない場合があります。どの関数で、どの条件を確認し、どの結果になったのかを分類して出すことが重要です。ログ量が多すぎる場合は、カテゴリや出力頻度を整理してください。

ExpertsログとJournalログはどちらを見ればよいですか？

両方を確認してください。ExpertsログはEAやインジケーター側の状態確認に使い、JournalログはMT5端末、取引サーバー、テスター、接続状態の確認に使います。

GetLastErrorはいつ確認しますか？

失敗する可能性のある関数を呼び出した直後に確認します。どの関数の直後なのか、戻り値はどうだったのか、対象symbolやtimeframeは何かを合わせてログに残してください。

注文エラーではretcodeも必要ですか？

必要です。注文処理では、GetLastErrorだけでなく、MqlTradeResult.retcode、order、deal、comment、request内容を確認すると、取引サーバー側の応答を追いやすくなります。

ログが多すぎる場合はどう整理しますか？

同じ理由の連続出力を抑制し、INFO、WARN、ERROR、DEBUGなどの分類を分けます。通常運用、検証、バックテストでログ量を切り替える設計も有効です。

問い合わせ時にソースコードは必要ですか？

内容によります。既存EAやインジケーターの改修、ロジック調査、コンパイルエラー確認では必要になる場合があります。一方で、動作確認だけなら、setファイル、Expertsログ、Journalログ、スクリーンショット、発生条件で確認できる場合もあります。

Webhook URLやAPIキーを送ってよいですか？

送らないでください。Webhook URL、GAS URL、APIキー、認証トークンなどの実値は、ログ、スクリーンショット、問い合わせ本文に含めないようにしてください。

バックテストのログとリアル運用ログは同じですか？

同じとは限りません。バックテストではテスター環境、ヒストリカルデータ、外部連携制限、ログ量の違いがあり、リアル運用ではサーバー応答、通信、スプレッド、通知先などが影響します。

コンパイルエラーが複数ある時はどこから直しますか？

基本的には上から順番に確認し、最初の根本原因を探します。1つの括弧不足や型不一致が、後続の複数エラーを発生させることがあります。

ログとスクリーンショットは両方必要ですか？

両方あると確認しやすくなります。ログは内部状態や時系列、スクリーンショットは画面状態や設定の見た目を確認するために使います。口座番号や個人情報は隠してください。

関連する技術講座

MQL5のデバッグやログ設計を確認する場合は、エラーコード、関数、注文管理、EA設計、ファイル出力、イベント処理、長時間稼働の講座もあわせて確認してください。

関連する確認ページ

デバッグや不具合調査を進める場合は、setファイル、開発依頼資料、バックテスト、外部連携、サポート依頼の整理も確認してください。

購入前・利用前に確認するページ

EA、インジケーター、補助ツールを利用する前には、商品一覧、導入ガイド、動作環境、購入前確認、利用上の注意も確認してください。

まとめ

MQL5の不具合調査では、エラーコードの意味だけでなく、ログの出し方、確認順序、再現条件の整理が重要です。

MetaEditorでコンパイルエラーを確認し、ExpertsログとJournalログを分けて見ます。処理失敗時はGetLastError、注文処理ではMqlTradeResult.retcodeを確認し、対象銘柄、時間足、setファイル、発生時刻と合わせて記録してください。

ログは多ければよいわけではありません。INIT、GATE、SIGNAL、RISK、EXECUTION、EXIT、NOTIFY、FILEなど、目的別に分類し、通常運用、検証、バックテストでログ量を切り替えると確認しやすくなります。

外部連携を含むEAでは、Webhook URL、GAS URL、APIキー、認証トークンなどの実値をログや問い合わせ本文に含めないようにしてください。

学習内容を確認しても整理が難しい場合は、EA名、バージョン、setファイル、Expertsログ、Journalログ、発生時刻、スクリーンショットを整理したうえで相談してください。