MT5でEAが動かない原因をログ分析で特定する方法

1. MT5ログ分析とは何か

【結論】MT5ログ分析とは、MetaTrader5が自動出力するログ（記録）を読み取り、EAの挙動・エラー・注文処理の詳細を可視化して問題を特定する手法です。
【結論】バックテストでは見えない「リアル環境の問題」を特定できるため、EA開発・運用では必須の工程です。

1.1 MT5ログ分析の定義

【結論】MT5ログ分析とは、MT5が出力するログファイルを解析し、取引（execution）・スプレッド（spread）・スリッページ（slippage）・エラーの原因を特定する作業です。

【定義】
ログとは、MT5やEA（自動売買プログラム）が実行した処理を時系列で記録したテキストデータです。

MT5では主に以下のログが出力されます：

• Expertsログ：EAの動作・Print出力・注文処理
• Journalログ：MT5全体の動作・接続・サーバー通信

これらを分析することで、以下が明確になります：

• なぜ注文が通らなかったのか
• なぜエントリーしなかったのか
• なぜエラーが発生したのか
• 実際の約定条件（execution条件）はどうだったのか

重要なポイントは、「ログは事実そのもの」であることです。
主観ではなく、実際に何が起きたかを証明する唯一のデータになります。

1.2 ログで分かる情報一覧

【結論】ログを見ることで、トレードの結果だけでなく「内部の処理過程」まで追跡できます。

代表的に確認できる情報は以下です：

• 注文処理
  • OrderSend（注文送信）
  • OrderCheck（事前チェック）
  • execution（約定結果）
• 市場条件
  • spread（スプレッド）
  • slippage（スリッページ）
  • 価格（Bid / Ask）
• エラー情報
  • invalid volume（ロット不正）
  • not enough money（証拠金不足）
  • off quotes（価格取得不可）
• EA内部処理
  • Printログ（デバッグ用出力）
  • 条件分岐の通過状況

例えば、エントリーされなかった場合でも、

• スプレッドが広すぎた
• 条件が満たされていなかった
• 注文が拒否された

といった原因をログから特定できます。

これは、単に「結果を見る」バックテストとは決定的に異なります。

1.3 なぜログ分析が重要なのか

【結論】ログ分析を行わないと、EAの不具合や誤動作の原因はほぼ特定できません。

理由は以下の通りです：

• バックテストは理想環境
  → 実際のexecutionやslippageが再現されない
• フォワードテストは結果しか見えない
  → なぜその結果になったか分からない
• ログは「過程」を記録している
  → 原因まで追跡できる

つまり、

• バックテスト：結果
• フォワード：現実の結果
• ログ分析：原因

という役割分担になります。

特に実務では、以下の場面で必須です：

• EAが動かない
• 想定と違うタイミングでエントリー
• 損益が想定とズレる
• 特定のブローカーでのみ不具合

ログを見ずに判断すると、誤った結論に至る可能性が高いです。

よくある失敗（この段階での注意点）

• ログを見ずに「EAが壊れている」と判断する
• 結果だけ見て原因を推測する
• デモとリアルの違いを考慮しない

ログ分析は「推測を排除するための手段」です。
必ず事実ベースで判断する必要があります。

2. MT5ログの種類と保存場所

【結論】MT5ログは「Experts（EAの動作）」と「Journal（全体の動作）」の2種類があり、問題の原因に応じて見る場所を切り替えることが重要です。
【結論】初心者はまずExpertsログを確認し、必要に応じてJournalで補完します。

2.1 MT5ログの種類

【結論】MT5のログは用途ごとに分かれており、役割を理解すると原因特定の速度が大きく向上します。

主なログは以下の2つです：

Expertsログ（EAログ）

・EAの動作履歴
・Printログ（デバッグ出力）
・注文処理（OrderSend / OrderCheck）
・ロジックの分岐状況

→ EAの問題を調べるときは最優先で確認

Journalログ（全体ログ）

・サーバー接続状況
・注文結果（execution）
・エラー（trade error）
・市場状態（market closed / off quotes）

→ 通信・ブローカー・環境問題の確認に使用

2.2 ログの保存場所

【結論】ログはMT5の「データフォルダ」に保存されており、直接ファイルとして確認することも可能です。

GUIから開く方法（最短ルート）

1. MT5を開く
2. メニュー「ファイル」→「データフォルダを開く」
3. 以下のフォルダに移動

• MQL5/Logs → Expertsログ
• Logs → Journalログ

ファイル構造

• ExpertsログMQL5/Logs/YYYYMMDD.log
• JournalログLogs/YYYYMMDD.log

補足

・ログは日付ごとに分かれている
・古いログは自動削除される場合あり
・テキスト形式（.log）で保存

2.3 ExpertsとJournalの違い

【結論】Expertsは「EA内部」、Journalは「外部環境」を見るためのログです。

実務での使い分け

• EAが動かない
  → Expertsログ
• 注文が通らない
  → Experts → Journalの順で確認
• 約定がおかしい（slippage・execution）
  → Journalログ

よくある失敗

• Journalだけ見てEAの問題を判断する
• Expertsログを見ずに原因を推測する
• 日付を間違えてログを確認する

特に多いのは「ログを見ているつもりで、違う日付を見ている」ケースです。
必ず発生時刻と一致するログを確認してください。

なぜこの構造なのか（補足）

MT5は以下のように役割分離されています：

• EA（ロジック）
• ターミナル（実行環境）
• サーバー（ブローカー）

ログもこれに対応して分かれているため、
原因ごとに見るログを変える必要があります。

3. MT5ログ分析のやり方

【結論】MT5ログ分析は「該当時間のログを特定 → 前後を追跡 → 原因を特定」の3ステップで行います。
【結論】エラー1行だけで判断せず、前後のログを必ず確認することが最重要です。

3.1 基本手順（最短ルート）

【結論】まずはMT5内のログ画面で確認し、異常箇所を特定します。

以下の手順で実施します：

1. MT5を開く
2. 「ターミナル」ウィンドウを表示（Ctrl+T）
3. 「Experts」または「Journal」タブを選択
4. 該当時間帯のログを探す
5. Ctrl+Fでキーワード検索（error / failed / invalidなど）
6. 該当ログの前後を確認する

検索キーワード例

• error
• failed
• invalid
• reject
• not enough money

重要ポイント

・「エラーが出た行」だけでは原因は分からない
・必ずその前後のログを見る

3.2 ファイルログの確認手順

【結論】長時間のログや詳細分析は、ファイル（.log）を直接確認すると効率が良いです。

手順

1. MT5 →「ファイル」→「データフォルダを開く」
2. 以下に移動
   • Expertsログ：MQL5/Logs
   • Journalログ：Logs
3. 該当日付のログファイルを選択
4. テキストエディタで開く（メモ帳など）
5. Ctrl+Fで検索

分析のコツ

・時間（timestamp）で絞る
・同じエラーが連続していないか確認
・ログの流れを時系列で読む

3.3 効率的な分析テクニック

【結論】ログ分析は「時間・条件・結果」の3点で整理すると精度が上がります。

テクニック① 時間軸で追う

ログはすべて時系列です。

例：

10:00 条件チェック
10:00 OrderSend
10:00 error

→ この流れで原因を特定する

テクニック② エラーから逆引き

エラーコードを起点に分析します。

例：

• invalid volume → ロットサイズ異常
• not enough money → 証拠金不足
• off quotes → 価格取得不可

→ エラーの直前のログが原因

テクニック③ Printログを活用

EAにデバッグ出力を入れると分析効率が大幅に上がります。

Print("Spread=", SymbolInfoInteger(_Symbol, SYMBOL_SPREAD));
Print("Lot=", lot_size);
Print("Condition=", condition_flag);

これにより：

• 条件が成立しているか
• 変数の値が正しいか
• ロジックが通過しているか

を確認できます。

3.4 実務での分析フロー（重要）

【結論】実務では以下の順番で分析すると最短で原因に到達します。

1. 現象を特定
   • エントリーされない
   • エラーが出る
   • 損益がズレる
2. 該当時間を特定
3. Expertsログ確認
   • ロジック
   • OrderSend
4. Journalログ確認
   • execution
   • サーバー応答
5. 前後ログで原因特定

よくある失敗

• エラー行だけ見て判断する
• Printログを入れていない
• 時間軸を無視する
• 別の日のログを見ている

特に「Printログ未使用」は致命的です。
内部状態が見えないため、原因特定が困難になります。

なぜこの手順が必要なのか

ログは単なるテキストではなく、

• EAの判断
• 市場条件（spread / slippage）
• execution結果

が連続した「因果関係の記録」です。

したがって、1行ではなく流れで読む必要があります。

4. ログの読み方と仕組み

【結論】MT5ログは「時間 → 処理 → 結果」の順で並ぶため、1行単位ではなく流れで読むことが重要です。
【結論】注文（OrderSend）から約定（execution）までの一連の流れを理解すると、原因特定の精度が大幅に上がります。

4.1 ログの基本構造

【結論】ログは「タイムスタンプ・発生元・メッセージ」の3要素で構成されています。

典型的なログ形式：

2026.04.01 10:00:00.123    Experts    OrderSend request

構成要素

• 時間（timestamp）
  → いつ発生したか（ミリ秒単位）
• モジュール
  → Experts / Journal / Trade など
• メッセージ
  → 実際の処理内容

読み方のポイント

• 同一時刻の連続ログをまとめて見る
• 時間のズレ（遅延）に注意
• 同一EAかどうかを確認

4.2 注文処理のログの流れ

【結論】注文は「送信 → チェック → 約定」の順で処理され、ログも同じ順序で出力されます。

典型的な流れ

Print: 条件成立
OrderSend request
OrderCheck result
Trade request sent
Execution result

各ステップの意味

• 条件成立
  → EAのロジックが通過
• OrderSend
  → 注文送信
• OrderCheck
  → サーバー側で事前チェック
• Execution
  → 実際の約定結果

分析のポイント

・OrderSendが無い → 条件未成立
・OrderCheckで失敗 → 条件・パラメータ異常
・Executionで失敗 → サーバー・市場条件

4.3 エラーが出る仕組み

【結論】エラーは「EA」「MT5」「ブローカー」のいずれかの層で発生します。

エラーの発生パターン

1. EA側（ロジック・パラメータ）
   • invalid volume
   • invalid stops
2. MT5側（環境・状態）
   • trade context busy
   • no connection
3. サーバー側（市場・ブローカー）
   • off quotes
   • market closed

例：not enough money

OrderSend request
OrderCheck failed: not enough money

→ 原因：証拠金不足
→ 対処：ロットサイズ調整

例：off quotes

Trade request sent
Off quotes

→ 原因：価格が取得できない
→ 要因：

• スプレッド急変
• 流動性不足
• サーバー遅延

4.4 ログから因果関係を読み取る

【結論】ログ分析は「結果 → 直前 → さらに前」と逆方向に追うと効率が良いです。

手順

1. 最終結果（エラー・失敗）を特定
2. 直前のログを見る
3. 条件・環境を確認

具体例

10:00:00 OrderSend
10:00:00 OrderCheck
10:00:01 not enough money

→ 結果：注文失敗
→ 直前：チェック実行
→ 原因：証拠金不足

4.5 よくある読み間違い

• エラーだけ見て原因を決める
• 時間の順序を無視する
• ExpertsとJournalを混同する
• Printログを見ていない

特に多いのは「原因と結果の逆転」です。
ログは必ず時間順に読む必要があります。

なぜこの仕組みなのか

MT5の処理は以下の構造です：

• EA（判断）
• ターミナル（送信）
• サーバー（execution）

ログはこの処理をそのまま記録しているため、
システムの流れを理解するとログも自然に読めるようになります。

5. よくあるエラーと原因

【結論】MT5のエラーはパターン化されており、ログから原因を特定し、対応策を適用すればほとんど解決可能です。
【結論】エラー名だけで判断せず、発生前後のログと市場条件（spread・execution）を必ず確認することが重要です。

5.1 代表的なエラー一覧

【結論】以下のエラーは発生頻度が高く、最初に覚えるべき基本パターンです。

5.2 エラー別の原因と対処

【結論】エラーは「パラメータ」「環境」「市場条件」の3分類で整理すると解決しやすくなります。

invalid volume

原因：

• ロットサイズが最小単位に合っていない
• ブローカーの制約違反

対処：

• SymbolInfoDoubleで最小ロットを取得
• ロットを正規化する

double min_lot = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_MIN);
double lot_step = SymbolInfoDouble(_Symbol, SYMBOL_VOLUME_STEP);
lot = MathMax(min_lot, lot);
lot = NormalizeDouble(lot, 2);

not enough money

原因：

• 証拠金不足
• ロットサイズ過大

対処：

• ロットを下げる
• free marginを確認

double margin = AccountInfoDouble(ACCOUNT_FREEMARGIN);

off quotes

原因：

• 価格更新が止まっている
• スプレッド急拡大
• サーバー遅延

対処：

• リトライ処理を実装
• spreadフィルタを追加

trade context busy

原因：

• 注文処理が重複
• 非同期処理の競合

対処：

• 処理間に待機を入れる

Sleep(100);

invalid stops

原因：

• SL/TPが近すぎる
• ブローカー制限違反

対処：

• 最小ストップ距離を取得

double stop_level = SymbolInfoInteger(_Symbol, SYMBOL_TRADE_STOPS_LEVEL);

5.3 ログから原因を特定する手順

【結論】エラー特定は「エラー行 → 直前ログ → 条件確認」の順で行います。

手順

1. エラー行を特定
2. 直前のログを確認
3. 以下をチェック
   • ロット
   • spread
   • slippage
   • execution条件
4. EAの条件分岐を確認

実例

OrderSend request
OrderCheck failed: invalid volume

分析：

• OrderSendは実行されている
• OrderCheckで失敗
• 原因：ロット不正

5.4 実務でのエラー分析の考え方

【結論】エラーは単発ではなく、環境・条件・ロジックの組み合わせで発生すると考えるべきです。

重要な視点：

• spreadが広がっていないか
• execution条件が変わっていないか
• ブローカーごとの差異

例：

• デモでは通るがリアルで失敗
  → execution / slippageの影響

よくある失敗

• エラー名だけで判断する
• ロット・証拠金を確認していない
• ブローカー仕様を無視する
• 一度のログだけで結論を出す

特に多いのは「環境要因の見落とし」です。
ログは必ず複数回・複数条件で確認する必要があります。

なぜエラー分析が重要なのか

エラーは単なる障害ではなく、

• ロジックの欠陥
• リスク管理の不足
• 市場条件への非対応

を示すシグナルです。

したがって、エラー分析＝EA改善の最短ルートになります。

6. 他手法との比較

【結論】ログ分析は「原因特定」に特化した手法であり、バックテストやフォワードテストとは役割が異なります。
【結論】最適な運用は「バックテスト → フォワード → ログ分析」の組み合わせです。

6.1 ログ分析とバックテストの違い

【結論】バックテストは「理想環境の結果」、ログ分析は「実環境の原因」を扱います。

補足

バックテストは高速かつ効率的ですが、

• slippage（滑り）
• 約定拒否
• サーバー遅延

などは正確に再現されません。

そのため、バックテストだけでは実運用の問題は見えません。

6.2 ログ分析とフォワードテストの違い

【結論】フォワードテストは「結果の検証」、ログ分析は「結果の原因分析」です。

補足

フォワードテストでは、

• なぜエントリーしなかったか
• なぜ損失が出たか

は直接分かりません。

→ ここでログ分析が必要になります。

6.3 手法の使い分け（実務フロー）

【結論】3つの手法は組み合わせて使うことで最大の効果を発揮します。

推奨フロー

1. バックテスト
   → 戦略の有効性を検証
2. フォワードテスト
   → 実環境での挙動確認
3. ログ分析
   → 問題の原因特定

実務での具体例

ケース：エントリー回数が少ない

• バックテスト
  → 問題なし
• フォワード
  → エントリー少ない
• ログ分析
  → spreadフィルタで弾かれている

→ 原因特定完了

6.4 他の代替手段との比較（軽く触れる）

【結論】ログ分析の代替はほぼ存在せず、唯一の一次情報源です。

代替手段

• トレード履歴
  → 結果のみ
• グラフ分析
  → 視覚的だが曖昧
• バックテストレポート
  → 仮想データ

→ いずれも「原因」は分からない

よくある誤解

• バックテストが良ければ問題ない
• フォワードで勝てばOK
• ログは開発者だけのもの

これらはすべて不十分です。

特に、

• execution
• slippage
• spread

はリアル環境でしか確認できません。

なぜログ分析が必要なのか

トレードシステムは

• ロジック（EA）
• 市場条件
• ブローカー仕様

の3要素で成立します。

ログ分析は、この3つを同時に可視化できる唯一の手段です。

7. よくある失敗と注意点

【結論】ログ分析で最も多い失敗は「部分的な情報だけで判断すること」であり、必ず時間軸と前後関係を含めて分析する必要があります。
【結論】初心者は「ログを見る習慣」と「検証の再現性」を意識するだけで、分析精度が大きく向上します。

7.1 ログを見ないまま判断する

【結論】ログを確認せずに原因を推測するのは、最も非効率かつ危険な判断です。

よくあるケース：

• 「EAが動かない＝バグ」と決めつける
• 「注文が通らない＝ブローカーの問題」と断定する

しかし実際は：

• 条件未成立
• spread制限
• ロット設定ミス

などが原因であることが多いです。

対策

・必ずログを確認してから判断する
・最低でもExpertsログはチェックする

7.2 時間軸を無視する

【結論】ログは時系列データであり、順序を無視すると原因を誤認します。

典型的なミス

10:00 error
10:00 OrderSend

→ 実際はOrderSend → errorの順

対策

・タイムスタンプを必ず確認
・同時刻ログはまとめて読む

7.3 エラーだけを見る

【結論】エラーは結果であり、原因はその前のログにあることがほとんどです。

NG例

not enough money

→ これだけでは不十分

正しい見方

OrderSend request
OrderCheck
not enough money

→ ロット・証拠金が原因と分かる

対策

・最低でも3行以上前まで確認
・「流れ」で読む

7.4 デモとリアルの違いを無視する

【結論】デモとリアルではexecution条件が異なり、同じEAでも結果が変わる可能性があります。

主な違い：

• spread（リアルは変動が大きい）
• slippage（リアルは発生する）
• execution速度

よくある誤解

• デモで動いた＝本番でも同じ
  → 誤り

対策

・リアル口座のログを必ず確認
・execution条件を前提に設計する

7.5 Printログを使っていない

【結論】Printログがないと、EA内部の状態が見えず原因特定が困難になります。

問題点

• 条件が成立しているか分からない
• 変数の値が確認できない

推奨コード

Print("Spread=", SymbolInfoInteger(_Symbol, SYMBOL_SPREAD));
Print("Lot=", lot);
Print("Signal=", signal_flag);

対策

・重要な変数は必ず出力
・条件分岐前後にログを入れる

7.6 単発ログで結論を出す

【結論】ログは一回ではなく、複数回の挙動を比較することで精度が上がります。

NG例

・1回のエラーで原因確定

正しい方法

・複数トレードで比較
・異なる時間帯で検証
・複数ブローカーで確認

7.7 ブローカー仕様を考慮していない

【結論】ブローカーごとに条件が異なるため、同じEAでも結果が変わることがあります。

影響する要素：

• 最小ロット
• ストップレベル
• execution方式
• スプレッド

対策

・SymbolInfoで仕様を取得
・ブローカーごとに検証

なぜこれらの失敗が起きるのか

ログ分析は、

• ロジック
• 市場条件
• 実行環境

を同時に扱うため、単純な判断では対応できません。

そのため、

「推測ではなく記録で判断する」習慣が必要です。

8. 実務での使いどころ

【結論】MT5ログ分析は「開発・検証・運用」のすべての工程で使われ、EAの再現性と期待値を担保するための中核手段です。
【結論】特に実務では「問題発生後」ではなく、常時監視・定期確認として使うことでリスクを大幅に低減できます。

8.1 EA開発時の使いどころ

【結論】EA開発ではログ分析がないと、ロジックの正しさを検証できません。

主な用途：

• 条件分岐の確認
• エントリー判定の検証
• パラメータの妥当性確認

具体例

ケース：エントリーしない

ログ：

Signal=false
Spread=25

→ 分析：

• シグナル未成立
• spreadフィルタで除外

対応

• 条件の見直し
• spread許容値の調整

開発時の基本フロー

1. Printログを実装
2. バックテスト実行
3. ログ確認
4. 条件と実行結果を照合

注意点

• ログを入れすぎるとノイズになる
• 必要な変数に絞る

8.2 フォワード運用時の使いどころ

【結論】フォワードではログ分析により、異常検知と原因特定を即時に行えます。

主な用途：

• エントリー漏れの確認
• 約定異常（slippage / execution）の検出
• 環境変化の把握

具体例

ケース：エントリー回数が減少

ログ：

Spread=40
Condition=true
No trade

→ 分析：

• 条件は成立
• spreadが広すぎる

→ 結論：市場環境変化

運用時のチェック項目

• spreadの平均値
• executionの成功率
• エラー発生頻度

実務ポイント

• 日次でログ確認
• 異常時は即分析
• 長期トレンドも確認

8.3 商用判断（重要）

【結論】商用判断では、リアル口座のログが最も信頼できるデータです。

理由：

• 実際のexecution条件を反映
• slippage・遅延が含まれる
• ブローカー差異が反映される

判断基準の例

• エラー発生率が低い
• execution成功率が安定
• spread条件で大きく崩れない

NG判断

• バックテストのみで判断
• デモ口座のみで判断

8.4 リスク管理としてのログ分析

【結論】ログ分析は単なるデバッグではなく、リスク管理ツールとして機能します。

検出できるリスク：

• 過剰ロット（資金管理ミス）
• execution悪化（スリッページ増加）
• 市場環境変化（spread拡大）

実務での活用

• 異常値の検知
• ドローダウン原因の特定
• 戦略の停止判断

8.5 なぜログ分析が期待値に影響するのか

【結論】ログ分析により、再現性の低い要素を排除できるため、期待値が安定します。

トレードの結果は以下で構成されます：

• ロジック
• execution
• 市場条件

ログ分析はこの3つを同時に検証できるため、

• 不確実性を減らす
• 再現性を高める

結果として、期待値のブレを抑えます。

よくある失敗（実務編）

• 問題が起きたときだけログを見る
• リアル口座のログを確認しない
• 単一条件でしか検証しない

→ これではリスク管理が不十分です。

実務まとめ（短文化）

• ログは常時確認する
• 問題は即分析する
• リアル環境を基準にする

9. FAQ

【結論】MT5ログ分析は「場所・種類・読み方」を理解すれば、初心者でも実務レベルで活用できます。
【結論】多くの疑問は「ログを見る場所」と「読み方」を押さえることで解決します。

9.1 MT5ログはどこにありますか？

【結論】MT5のログは「データフォルダ内のLogsフォルダ」に保存されています。

手順：

1. MT5を開く
2. 「ファイル」→「データフォルダを開く」
3. 以下を確認
   • MQL5/Logs（Expertsログ）
   • Logs（Journalログ）

9.2 ExpertsとJournalの違いは何ですか？

【結論】ExpertsはEAの内部ログ、JournalはMT5全体のログです。

• Experts
  → ロジック・Print・OrderSend
• Journal
  → execution・通信・エラー

EAの問題はまずExpertsを見るのが基本です。

9.3 ログ分析は必須ですか？

【結論】はい。EA開発・運用では必須です。

理由：

• 原因特定ができる唯一の手段
• バックテストでは見えない問題を検出できる
• 再現性の確認に必要

9.4 エラーが出ていないのに動かないのはなぜですか？

【結論】多くの場合、条件未成立またはフィルタによる除外です。

確認ポイント：

• spread制限
• 時間フィルタ
• シグナル条件

Printログを使うと原因が特定できます。

9.5 バックテストだけでは不十分ですか？

【結論】不十分です。実環境の挙動は再現されません。

不足する要素：

• slippage
• execution
• サーバー遅延

→ ログ分析で補完する必要があります。

9.6 ログはどのくらい保存されますか？

【結論】日付ごとに保存されますが、古いログは自動削除される場合があります。

対策：

• 必要なログは手動保存
• 定期的にバックアップ

9.7 Printログは使うべきですか？

【結論】必須です。デバッグ効率が大幅に向上します。

例：

Print("Spread=", SymbolInfoInteger(_Symbol, SYMBOL_SPREAD));
Print("Lot=", lot);
Print("Condition=", condition_flag);

→ 内部状態を可視化できる

9.8 ログ分析だけで問題は解決できますか？

【結論】多くの場合は解決できますが、環境要因も併せて確認が必要です。

補足：

• ブローカー仕様
• execution条件
• 市場状況

これらと組み合わせて判断することで精度が上がります。