開発依頼ガイド

EAのログ出力を増やしたい時に整理すること|Experts・Journal・CSV・通知

EAファンクラブ

EAを使っていると、「なぜ注文しなかったのか」「なぜ決済されなかったのか」「どの条件で停止したのか」「通知が送られたのか」を後から確認したい場面があります。

そのような時に役立つのが、Expertsログ、Journalログ、CSV出力、通知ログなどの記録です。

ただし、ログは増やせばよいというものではありません。出力が多すぎると、重要な情報が埋もれたり、バックテストが重くなったり、長時間稼働時にファイルが大きくなったりする場合があります。

また、ログには口座番号、Webhook URL、APIキー、トークン、認証情報など、公開すべきではない情報が含まれる可能性があります。ログ出力を増やす場合は、何を出すかだけでなく、何を出さないかも整理する必要があります。

この記事では、EAのログ出力を増やしたい時に、開発依頼前に整理したいExpertsログ、Journalログ、CSV出力、通知ログ、出力タイミング、ログ量、機密情報、検証条件をまとめます。

なお、この記事はEA改修や開発依頼前の技術確認を目的とした内容です。特定の売買手法、推奨エントリー、推奨決済、推奨ロット、利益保証を行うものではありません。

この記事で確認すること

確認項目内容依頼前の確認ポイント
ExpertsログEA側が出力する動作ログです。判定、注文、決済、停止理由、エラーを確認します。
JournalログMT4/MT5全体の操作・注文・接続ログです。取引許可、注文結果、接続、プラットフォーム側の状態を確認します。
CSV出力履歴や状態をCSVファイルへ保存する方式です。列構成、保存場所、追記方法、ファイル肥大化を確認します。
通知ログDiscordやメールなどの通知結果を記録します。送信成功、失敗、HTTP結果、通知対象を確認します。
ログ量どの程度詳しく出すかです。検証用と実運用用で出力粒度を分けます。
機密情報ログに出してはいけない情報です。口座番号、トークン、Webhook URL、APIキーをマスクします。

EAのログ出力を増やす目的

EAのログ出力を増やす目的は、EAの挙動を後から確認できるようにすることです。

たとえば、EAが注文しない場合、エントリー条件が未成立なのか、スプレッドで止まったのか、時間帯で止まったのか、自動売買が許可されていないのか、証拠金不足なのかをログで切り分けます。

確認したいことログで見る内容出力例
EAが起動したか初期化、認証、設定読込の状態です。INIT_OK、AUTH_OK、PARAM_CHECK
注文しなかった理由エントリー条件、スプレッド、時間帯、証拠金などです。entry_skip、spread_block、time_block
注文結果注文送信、約定、失敗、retcodeです。order_send、order_success、order_fail
決済理由TP、SL、建値、トレーリング、手動決済などです。close_reason、trail_close、be_close
通知結果通知を送ったか、失敗したかです。notify_success、notify_fail
外部連携結果WebRequest、CSV、Google Sheetsなどの状態です。external_status、http_status、csv_write

依頼前には、「何を確認するためにログを増やしたいのか」を明確にしてください。

ExpertsログとJournalログの違い

EAのログ確認では、ExpertsログとJournalログを分けて見ることが重要です。

Expertsログは、EA側が出力する動作記録です。Journalログは、MT4/MT5側の操作、注文、接続、プラットフォーム状態を含む記録です。

ログ種類主な内容確認に向いていること
ExpertsログEAが出力するログです。EA内部の判定、見送り理由、注文処理、決済理由を確認します。
JournalログMT4/MT5全体のログです。取引許可、注文結果、接続状態、プラットフォーム側エラーを確認します。
Strategy Testerログバックテスト時のログです。検証条件、バックテスト時の判定、速度、エラーを確認します。
CSVログEAがファイルに保存する構造化ログです。履歴集計、Excel確認、長期検証に使います。
通知ログ通知送信の結果です。Discord、メール、外部送信の成功・失敗を確認します。

「EAが動かない」という相談では、Expertsログだけでなく、Journalログも必要になる場合があります。

どの処理にログを追加するか整理する

ログ出力を増やす場合は、EA全体に無差別にログを追加するのではなく、処理の責務ごとに分けて整理します。

signal、execution、risk、exit、notification、external control、manual、UI などを分けておくと、後から原因を追いやすくなります。

ログ分類確認内容出力例
signalエントリー条件やシグナル判定です。signal_check、score、gate_result
execution注文送信や約定結果です。order_send、retcode、deal_ticket
risk証拠金、ロット、最大損失、停止条件です。margin_check、risk_block、lot_calc
exit決済、建値、トレーリング、一括決済です。close_reason、be_check、trail_modify
notification通知送信や送信失敗です。notify_event、send_result、http_status
external control外部シートやWebRequest制御です。external_status、sheet_read、apply_result
manualボタン操作や手動操作です。button_click、manual_close、action_result
UIパネル表示やオブジェクト管理です。ui_state、object_audit、layout_state

依頼時には、「注文しない理由を知りたい」「決済しない理由を知りたい」「通知失敗を知りたい」など、確認したい目的ごとにログ分類を整理してください。

ログレベルを整理する

ログ出力には、通常運用で見るログと、検証時だけ見る詳細ログがあります。

すべての詳細ログを常時出すと、ログが多くなりすぎて確認しづらくなります。そのため、ログレベルや出力モードを分けることが重要です。

ログレベル内容使いどころ
OFFログを最小限にします。本番運用でログを抑えたい時に使います。
ERRORエラーや失敗だけ出します。注文失敗、通信失敗、認証失敗の確認に使います。
INFO主要な状態変化を出します。起動、注文、決済、停止状態を確認します。
DEBUG判定過程を詳しく出します。開発中や不具合調査で使います。
TRACE非常に細かい処理を出します。短時間の再現検証に限定して使います。
COMPACT重要項目だけ簡潔に出します。バックテストや長時間稼働で使いやすい形式です。

開発中は詳細ログ、本番運用ではコンパクトログというように、用途ごとに切り替えられる設計にすると扱いやすくなります。

CSV出力で整理すること

CSV出力は、ログや履歴を表形式で保存したい場合に使います。

Expertsログは確認しやすい一方で、長期集計やExcelでの分析には向かない場合があります。CSV出力を追加すると、取引履歴、判定結果、日次集計、エラー履歴などを後から整理しやすくなります。

CSV項目内容依頼前の確認ポイント
保存場所Filesフォルダや共通フォルダです。MT5のファイルアクセス範囲を確認します。
ファイル名CSVの名前です。EA名、口座、日付、銘柄を含めるか確認します。
列構成保存する項目です。time、symbol、event、ticket、profitなどを整理します。
追記方式既存ファイルへ追記する方式です。ヘッダー重複やファイル肥大化に注意します。
日別分割日付ごとにファイルを分けます。長期運用時に確認しやすくなります。
文字コードUTF-8などの保存形式です。日本語やExcel表示の文字化けに注意します。
削除ルール古いCSVをどう扱うかです。保存期間、上限容量、手動削除を確認します。

CSV出力を依頼する場合は、何を保存するかだけでなく、どの形式で、どの頻度で、どのくらい保存するかを整理してください。

CSVログ出力の設計であわせて確認したいページ

EAのログ出力を増やす場合は、ExpertsログやJournalログだけでなく、CSVへ何を残すか、どの保存先を使うか、どの粒度で出力するかも整理しておくと確認しやすくなります。

確認したい内容関連ページ確認ポイント
EAログの基本EAログとは|Expertsログ・Journalログで確認する動作記録の基本Expertsログ、Journalログ、entry_skip、close_reasonなどの基本を整理します。
CSVログ出力の設計MQL5ファイル操作・CSVログ出力完全ガイドFilesフォルダ、Commonフォルダ、FileOpen、FileWrite、文字コードを確認します。
発注・決済ログ設計MQL5でEAのログ設計を行う方法OrderSend、retcode、GetLastError、発注前ブロック、注文後エラーを分けて確認します。

通知ログで整理すること

Discord通知やメール通知を使うEAでは、通知が成功したか、失敗したかをログに残すことが重要です。

通知が届かない場合、EAが通知を送っていないのか、WebRequestが失敗したのか、外部サービス側で拒否されたのかを切り分ける必要があります。

通知ログ項目内容出力例
notify_event通知対象イベントです。ENTRY、CLOSE、ERROR、INIT
notify_target通知先です。DISCORD、MAIL、LOG_ONLY
send_result送信結果です。success、fail、skip
http_statusWebRequest結果です。200、204、400、401、403、429
error_detail失敗理由です。timeout、not_allowed、rate_limit
throttle_state連投防止で見送ったかです。duplicate_skip、interval_skip
masked_target通知先の識別情報です。Webhook URLはマスクします。

通知ログには、Webhook URLやトークンをそのまま出さないようにしてください。

ログを出しすぎるリスク

ログは不具合調査に役立ちますが、出しすぎると逆に問題になる場合があります。

特に、OnTickごとに詳細ログを出すEAでは、バックテストが遅くなったり、Expertsログがすぐに大量になったり、重要なエラーが見つけにくくなることがあります。

リスク内容対策
ログ量が多すぎる重要な情報が埋もれます。ログレベルやカテゴリ別ON/OFFを用意します。
バックテストが遅くなる出力処理が負荷になります。BT用のCOMPACTログを用意します。
ファイルが肥大化するCSVやテキストが増え続けます。日別分割や保存上限を検討します。
機密情報が出る口座番号やトークンが漏れる可能性があります。マスク処理を入れます。
本番運用で見づらい通常運用に不要な詳細が多くなります。AdminDevとUserLiveで出力を分けます。
処理が重くなる描画や注文処理に影響する場合があります。必要なイベントだけ出力します。

ログ出力を増やす場合は、検証に必要なログと、本番運用に残すログを分けて設計することが重要です。

機密情報をログに出さない

ログには、後から確認するための情報を残しますが、すべてをそのまま出してよいわけではありません。

口座番号、認証キー、APIキー、Webhook URL、Google Sheetsのトークン、外部URL、個人情報に近い内容は、ログへ出す場合にマスクが必要です。

情報扱い
口座番号必要に応じて一部マスクします。123****789
Webhook URL原則そのまま出しません。https://…/****
APIキー原則そのまま出しません。key=****
トークン原則そのまま出しません。token=****
メールアドレス必要に応じてマスクします。a***@example.com
外部URL公開してよい範囲か確認します。ドメインのみ表示する場合があります。
注文情報検証に必要な範囲で出します。ticket、symbol、lot、price

問い合わせ時にログを共有する場合も、機密情報が含まれていないか確認してください。

ログ出力のON/OFFを整理する

ログ出力は、必要に応じてON/OFFできるようにしておくと便利です。

すべてのログを1つのON/OFFで管理するのではなく、カテゴリごとに切り替えられると、不具合調査や本番運用で使いやすくなります。

切替項目内容使いどころ
基本ログ起動、停止、注文、決済などです。通常運用でも確認したいログです。
判定ログエントリー条件やスコアです。注文しない理由の確認に使います。
リスクログ証拠金、ロット、停止条件です。ブロック理由の確認に使います。
決済ログTP、SL、BE、TRAIL、一括決済です。決済しない理由の確認に使います。
通知ログDiscordやメール送信の結果です。通知不達の確認に使います。
外部連携ログWebRequestや外部シート連携です。通信失敗や反映失敗の確認に使います。
CSVログCSV保存の有無です。履歴集計や検証記録に使います。
詳細ログ開発・調査用の細かいログです。短時間の検証に限定します。

依頼前には、どのログを常時ONにしたいか、どのログは検証時だけONにしたいかを整理してください。

バックテスト用ログと実運用ログを分ける

バックテストでは、短時間に大量の判定が行われるため、ログを出しすぎると非常に重くなる場合があります。

そのため、バックテストでは要点だけを出すCOMPACTログ、本番運用ではエラーや主要イベントだけを出すログ、開発検証では詳細ログというように分けると扱いやすくなります。

環境推奨されるログ方針確認すること
開発中詳細ログを使います。判定、注文、決済、エラーを追跡します。
バックテストCOMPACTログを使います。速度低下とログ量を抑えます。
デモ口座INFOとERROR中心にします。実運用前の挙動を確認します。
リアル口座重要ログとエラーログ中心にします。ログ過多を避けます。
不具合調査時一時的にDEBUGを有効化します。再現条件を絞って確認します。
配布版必要最小限にします。利用者が読みやすいログにします。

ログ方針は、AdminDevとUserLiveで分けておくと、開発・検証・配布時の混乱を防ぎやすくなります。

依頼前に用意するとよい資料

ログ出力の追加や強化を依頼する場合は、現在のログ、確認したい内容、出力したい項目、出力先を整理します。

資料内容注意点
現在のソースコードmq5、mqhなどのソース一式です。ex5だけでは直接改修できない場合があります。
現在のログExpertsログ、Journalログ、バックテストログです。問題が出た時間帯を含めます。
確認したい内容注文しない理由、決済しない理由、通知失敗などです。ログ追加の目的を明確にします。
出力したい項目symbol、magic、ticket、reason、retcodeなどです。必要な項目に絞ります。
CSV列案CSV保存したい列構成です。日付、イベント、注文情報、結果などを整理します。
通知ログ要件通知成功・失敗の確認内容です。Webhook URLやトークンはマスクします。
ログ量の希望詳細、通常、コンパクトなどです。本番用と検証用を分けます。
検証条件銘柄、時間足、期間、口座、再現手順です。同じ条件で再確認できるようにします。

依頼前チェック表

チェック項目確認内容
ログを増やす目的を整理した注文、決済、停止、通知、外部連携など、何を確認したいか分けます。
出力先を決めたExperts、Journal、CSV、通知、画面表示を整理します。
ログ分類を整理したsignal、execution、risk、exit、notification、external controlを分けます。
ログレベルを決めたERROR、INFO、DEBUG、TRACE、COMPACTなどを整理します。
CSV出力の列を決めたtime、symbol、event、ticket、result、reasonなどを整理します。
通知ログの項目を決めたnotify_event、send_result、http_status、error_detailを確認します。
ログ量を制御する方針を決めたOnTick連続出力、BT負荷、長期運用時の肥大化を避けます。
機密情報の扱いを決めた口座番号、トークン、Webhook URL、APIキーをマスクします。
本番用と検証用を分けたAdminDevとUserLiveでログ粒度を分けます。
現在のログを保存した問題発生時刻を含むExpertsログとJournalログを保存します。
再現条件を整理した銘柄、時間足、期間、setファイル、操作手順を記録します。
ソースコードの有無を確認したmq5、mqhがあるかを確認します。

FAQ

EAのログ出力だけを増やせますか?

ソースコードがあり、出力したい処理箇所が確認できる場合は相談できます。ただし、ログを増やしすぎると重くなったり確認しづらくなったりするため、出力目的とログ量を整理する必要があります。

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

ExpertsログはEA側の出力、JournalログはMT4/MT5全体の操作・注文・接続ログです。EA内部の判定はExperts、取引許可や注文結果はJournalもあわせて確認します。

CSV出力を追加すると何が便利ですか?

取引履歴、判定結果、エラー履歴、日次集計などを表形式で確認しやすくなります。ただし、列構成、保存場所、追記方式、ファイル肥大化を事前に整理する必要があります。

ログが多すぎる場合はどうすればよいですか?

ログレベル、カテゴリ別ON/OFF、COMPACTログ、出力間隔、イベント時のみ出力などを使って、必要なログだけを出す設計にします。

通知が届かない原因もログで確認できますか?

通知ログを追加すれば、通知イベント、送信先、送信結果、HTTPステータス、エラー内容、連投防止で見送ったかを確認できる場合があります。

ex5ファイルだけでもログ出力を追加できますか?

ex5だけでは既存EAへ直接ログ出力を追加できない場合があります。通常はmq5やmqhなどのソースコードが必要です。ソースがない場合は、補助EAや外部監視ツールとして検討する場合があります。

関連ページ

EAのログ出力を増やす時は、見積依頼前の資料整理に加えて、コンパイル確認、通知、外部シート連携との関係も確認すると、ログの出力目的や出力先を整理しやすくなります。

関連ページ確認ポイント
EA開発の見積依頼前に整理すること|仕様書・ログ・setファイル・検証条件ログ追加を含むEA開発・改修依頼前に、仕様、ログ、setファイル、検証条件を整理します。
MQL5のコンパイルエラー修正を依頼する前に確認すること|エラー行・include・BOMログ追加後のコンパイルエラー、include不足、BOM、MetaEditorエラーを確認する時に使います。
EAに通知機能を追加したい時に整理すること|Discord・メール・LINE・ログ出力通知成功、通知失敗、HTTP結果、通知対象イベントをログで追跡する時に確認します。
EAに外部シート連携を追加したい時に整理すること|Google Sheets・CSV・WebRequestCSV出力、Google Sheets連携、WebRequest結果などの外部連携ログを整理する時に確認します。

まとめ

EAのログ出力を増やしたい場合は、単にログを多く出すのではなく、何を確認するためのログなのかを最初に整理することが重要です。

Expertsログ、Journalログ、CSV出力、通知ログは役割が異なります。注文しない理由、決済しない理由、通知失敗、外部連携失敗、パネル操作など、確認したい内容ごとにログ分類を分けてください。

また、ログ量が多すぎると、バックテストが重くなったり、重要な情報が見つけにくくなったりします。ログレベル、カテゴリ別ON/OFF、COMPACTログ、CSV出力、保存期間などを整理すると扱いやすくなります。

ログには、口座番号、Webhook URL、APIキー、トークンなどの機密情報をそのまま出さないように注意してください。依頼前には、現在のログ、確認したい内容、出力したい項目、出力先、ログ量、検証条件、ソースコードの有無をまとめておくと確認が進めやすくなります。

ABOUT ME
記事URLをコピーしました