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を分けて見る

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失敗、バックテスト時だけの不具合は、再現条件の記録が重要です。

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

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

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

デバッグ時の確認順序

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

症状別の切り分け表

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

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

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

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

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

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

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

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

よくある質問

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のデバッグやログ確認を進める時は、エラーコード、EA設計、MQL5開発環境、ログの問い合わせ前確認、setファイル、バックテスト、外部連携を分けて確認すると、原因の切り分けがしやすくなります。

まとめ

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

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

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

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