mql5 market-closedエラーの原因と対処法【完全ガイド】

リファレンス
目次

1. mql5 market-closedとは何か

【結論】
「market-closed」は市場が閉場しているため注文が拒否されるエラーであり、取引時間外に発注した場合に発生する正常な挙動です。

【定義】
MQL5における「market-closed」とは、OrderSendなどの注文処理時に取引可能時間（Trading Session）外であるため約定できない状態を指します。

1.1 market-closedエラーの定義

「market-closed」は、価格が存在しないのではなく、取引そのものが許可されていない状態です。

具体的には以下のような特徴があります。

  • 注文処理（OrderSend）が失敗する
  • エラーコードとして返される
  • MT5のJournalログに記録される
  • EA（自動売買）でも同様に発生する

重要なポイントは以下です。

  • 「market-closed」は異常ではなく仕様通りの挙動
  • スプレッド（spread）やスリッページ（slippage）とは無関係
  • execution（約定方式）の問題でもない

1.2 どのタイミングで発生するか

このエラーは、主に「市場が閉じている時間」に発生します。代表的なケースは以下です。

■ 典型的な発生タイミング

  • 週末（土日）
    → FX市場は基本的に土日はクローズ
  • 祝日・流動性低下時間
    → 年末年始・クリスマスなど
  • 通貨ペアごとの取引時間外
    → CFD・指数・コモディティは時間が異なる
  • ブローカーのメンテナンス時間
    → サーバー停止や一時的な取引制限

1.3 初心者が誤解しやすいポイント

初心者が混同しやすいエラーとの違いを明確にします。

■ よくある誤解

  • ❌ 「価格が取れていない（no prices）」
  • ❌ 「約定できない（off quotes）」
  • ❌ 「通信エラー」

→ 実際は単純に取引時間外

■ なぜ誤解が起きるのか

  • MT5は価格表示はされていても取引できない場合がある
  • サーバー時間と日本時間のズレがある
  • EAが自動で注文を出すため気づきにくい

1.4 実務的な理解ポイント（重要）

実務で重要なのは以下の3点です。

  • 価格があっても取引できない時間は存在する
  • シンボル（銘柄）ごとに取引時間は異なる
  • EAは時間制御をしないと必ずエラーになる

■ 具体例

  • USDJPY → ほぼ24時間（平日）
  • 日経225 → 取引時間が限定される
  • ゴールド（XAUUSD） → 一部時間で停止

1.5 このエラーを放置するとどうなるか

  • 無駄な注文リトライが発生
  • EAのパフォーマンス低下
  • ログが汚染される
  • 約定機会のロス

→ 特に自動売買では必ず制御が必要

2. market-closedエラーの原因

【結論】
market-closedは「取引時間（セッション）外」または「サーバー側で取引不可と判定された状態」で発生します。原因は時間管理とブローカー仕様に集約されます。

【定義】
market-closedの原因とは、MT5サーバーが注文受付可否を判断するロジック（取引時間・状態フラグ）によって、注文が拒否される仕組みを指します。

2.1 取引時間（Trading Session）の仕組み

MT5では、各シンボル（通貨ペア・指数など）ごとに取引可能な時間帯（Trading Session）が定義されています。

■ 重要ポイント

  • 取引時間は「ブローカー側」で管理される
  • 同じUSDJPYでもブローカーごとに微妙に異なる
  • EAはこの時間を無視しても注文は出せるが、サーバーで拒否される

■ MQL5での内部構造

取引時間は以下で取得可能です。

datetime from, to;
if(SymbolInfoSessionTrade(_Symbol, DAY_OF_WEEK, 0, from, to))
{
   // 取引可能時間
}

■ なぜ必要か

  • 不正な時間の注文を防ぐ
  • 流動性が低い時間帯のリスク回避
  • 市場の公平性維持

2.2 サーバー時間とローカル時間のズレ

MT5の判定はローカルPCではなくサーバー時間基準です。

■ よくある誤解

  • 日本時間で「平日」＝取引可能 → ❌
  • 実際はサーバー時間で判定 → ⭕

■ 典型的なズレ

  • 日本時間（月曜朝）でもサーバーは日曜
  • ロンドン時間との時差
  • サマータイム（DST）の影響

■ 確認方法

datetime server_time = TimeCurrent();

■ なぜ問題になるか

  • EAが誤ったタイミングで注文を出す
  • バックテストと実運用で差が出る
  • 時間フィルターが機能しない

2.3 ブローカー依存の制約

market-closedはブローカー仕様の影響を強く受ける点が重要です。

■ 主な制約

  • 祝日スケジュール
  • メンテナンス時間
  • 流動性低下時の停止
  • 特定銘柄の取引制限

■ 例

  • CFD（指数） → 取引時間が限定
  • 仮想通貨 → 24時間だがメンテあり
  • ゴールド → 一部時間停止

■ 実務的なリスク

  • ブローカー変更でEAが動かなくなる
  • 同じロジックでも結果が変わる

2.4 関連エラーとの違い

market-closedと混同されやすいエラーを整理します。

■ エラーの本質比較

  • market-closed
    → 取引時間外（構造的に注文不可）
  • off quotes
    → 価格が取得できない（流動性不足・約定不可）
  • no prices
    → データ未配信
  • trade disabled
    → ブローカー側で取引禁止

■ 判別の考え方

  • 時間の問題か？ → market-closed
  • 価格の問題か？ → off quotes / no prices
  • 制限の問題か？ → trade disabled

2.5 なぜEAで頻発するのか

手動トレードよりもEAで頻発する理由は明確です。

■ 理由

  • 時間を考慮せず常時注文する
  • 高頻度ロジック（スキャルピング）
  • セッション切り替えを検知しない

■ 結果

  • 無駄なOrderSend増加
  • execution失敗
  • ログ肥大化
  • 約定効率低下

2.6 本質まとめ

  • market-closedの原因は時間とサーバー制御
  • 回避には取引時間の明示的な制御が必須
  • EA設計では「時間フィルター」は基本機能

3. market-closedエラーの解決方法

【結論】
market-closedは取引時間を判定して注文を制御することで確実に回避できる。最短解決は「時間確認→EAにフィルター実装」です。

【定義】
解決方法とは、取引可能時間内のみで注文（OrderSend）を実行するよう制御する手順を指します。

3.1 即時チェックリスト

まずは手動・環境レベルで確認すべきポイントです。
このチェックで約8割は解決します。

■ チェック手順

  • 現在が取引時間か確認（平日か＋時間帯）
  • MT5の「気配値表示」で価格更新されているか確認
  • 該当シンボル（例：USDJPY）が取引可能か確認
  • 別の通貨ペアで注文テスト
  • ブローカーの取引時間・メンテナンス情報を確認
  • VPSや回線の接続状態を確認

■ よくある見落とし

  • 日本時間では平日でも「サーバー時間は日曜」
  • CFDや指数は取引時間が限定
  • 深夜帯にスプレッド（spread）が異常拡大

3.2 MQL5での回避コード

EAで確実に回避するには、注文前に取引可能時間をチェックする必要があります。

■ 取引時間チェックの基本コード

bool IsTradingAllowed()
{
   datetime from, to;
   datetime now = TimeCurrent();
   int day = TimeDayOfWeek(now);

   if(SymbolInfoSessionTrade(_Symbol, (ENUM_DAY_OF_WEEK)day, 0, from, to))
   {
      if(now >= from && now <= to)
         return true;
   }
   return false;
}

■ 注文前の制御

if(IsTradingAllowed())
{
   // OrderSendなど実行
}
else
{
   Print("Market is closed");
}

■ なぜ必要か

  • サーバー側で拒否される前に制御できる
  • 無駄なOrderSendを防止
  • execution（約定）成功率を向上

3.3 EAに組み込むべき実務ロジック

market-closed対策は単体ではなく、トレード条件の一部として設計するのが重要です。

■ 推奨フィルター構成

  • 取引時間フィルター（必須）
  • スプレッドフィルター（spread制限）
  • スリッページ（slippage）制御
  • 約定条件（execution type）の確認
  • ポジション数制限

■ 実装イメージ

if(IsTradingAllowed() && SpreadCheck() && PositionCheck())
{
   // 安全な注文実行
}

■ 理由

  • market-closed単体対策では不十分
  • 実務では「総合的な注文品質管理」が必要
  • リスク（約定拒否・滑り）を同時に抑制

3.4 よくある失敗と対策

■ 失敗①：時間チェックをしていない

→ 対策：必ずTimeCurrent()でサーバー時間を使用

■ 失敗②：シンボルごとの差を無視

→ 対策：_Symbolごとにセッション取得

■ 失敗③：無限リトライ

while(!success) OrderSend(...);

→ 対策：回数制限＋時間条件を追加

■ 失敗④：バックテストだけ正常

→ 原因：テスターは常時市場が開いている場合あり
→ 対策：フォワードテストで確認

3.5 実務での最適解

最も再現性が高い構成は以下です。

  • 取引時間を「事前に遮断」
  • 注文前に複数条件チェック
  • エラー発生時はログ記録のみ

■ 最適フロー

  1. 時間チェック
  2. スプレッド確認
  3. シグナル判定
  4. OrderSend実行

3.6 代替手段

開発工数を抑える場合の簡易策です。

  • 手動で取引時間を固定（例：9時〜23時）
  • EAの稼働時間を制限
  • VPSの稼働スケジュール調整

※ただし精度は低く、ブローカー差異に弱い

3.7 重要ポイント

  • market-closedは「事前チェック」で防げる
  • 注文前に時間判定するのが最適
  • EAでは必須の基本機能

4. 他エラーとの違いと比較

【結論】
market-closedは「時間の問題」であり、他のエラー（off quotes・no pricesなど）は価格・通信・制御の問題です。原因の切り分けが最短解決につながります。

【定義】
エラー比較とは、発生原因（時間・価格・制御）ごとに分類し、適切な対処法を選ぶための判断基準です。

4.1 主要エラーの構造比較

以下は、実務で混同されやすいエラーの整理です（表形式を想定）。

■ エラー比較一覧

エラー名原因発生タイミング主な対処
market-closed取引時間外セッション外・週末時間フィルター実装
off quotes価格取得不可（流動性不足）指標時・急変時slippage調整・再試行
no prices価格未配信接続直後・停止時データ更新待ち
trade disabled取引禁止銘柄制限・口座制限ブローカー確認
trade context busy処理競合高頻度注文時処理待機・制御

■ 本質的な違い

  • market-closed → 時間が原因（取引不可）
  • off quotes → 価格が原因（約定不可）
  • no prices → データが原因（取得不可）
  • trade disabled → 制限が原因（禁止）

4.2 判別フロー

エラー発生時は、以下の順序で切り分けると効率的です。

■ 判別ステップ

  1. ログ（Journal）を確認
    • エラーコード・メッセージを取得
  2. 現在時刻を確認
    • TimeCurrent()でサーバー時間確認
  3. 取引時間内か判定
    • → NGなら market-closed
  4. 価格が更新されているか確認
    • → NGなら no prices
  5. スプレッド・約定条件確認
    • → NGなら off quotes

■ コードでの判別例

int error = GetLastError();

if(error == TRADE_RETCODE_MARKET_CLOSED)
{
   Print("Market closed");
}

4.3 なぜ比較が重要か

エラーを正しく分類できないと、誤った対策を実装するリスクがあります。

■ よくある誤対応

  • market-closedに対してslippage調整 → 無意味
  • off quotesに時間フィルター → 効果なし
  • no pricesにOrderSend連打 → 逆効果

■ 実務リスク

  • 無駄な注文増加
  • execution失敗率上昇
  • EAの期待値低下
  • ログ肥大化

4.4 EA設計における最適アプローチ

エラーは個別対応ではなく、構造的に分類して制御するのが最適です。

■ 推奨設計

  • 時間系エラー → 時間フィルター
  • 価格系エラー → spread / slippage制御
  • 処理系エラー → リトライ制御

■ 実装イメージ

if(!IsTradingAllowed()) return;

if(!SpreadCheck()) return;

if(!ExecutionCheck()) return;

// OrderSend

4.5 代替手段・他手法との違い

■ シンプルEAの場合

  • 固定時間フィルターのみ
    → 簡単だが精度低い

■ 高度EAの場合

  • セッション取得＋動的制御
    → 精度高いが実装コスト増

■ 判断基準

  • 再現性重視 → セッション取得
  • 開発速度重視 → 固定時間

4.6 重要ポイント

  • エラーは「原因別」に分類する
  • market-closedは時間問題
  • 誤判定が最大のリスク

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

【結論】
market-closed対策で最も多い失敗は「時間管理の誤認」と「EA未実装」です。サーバー時間基準での制御と再試行ロジックの設計が必須です。

【定義】
ここでの失敗とは、market-closedの原因を誤解し、不適切な実装や運用によりエラーを繰り返す状態を指します。

5.1 典型的なミス一覧

■ ミス①：ローカル時間で判定している

datetime now = TimeLocal(); // NG

→ 問題点

  • MT5はサーバー時間で判定するためズレが発生
  • 日本時間では取引可能でも実際は不可

→ 対策

datetime now = TimeCurrent(); // OK

■ ミス②：シンボルごとの取引時間を無視

→ 問題点

  • 通貨ペア・CFD・指数で取引時間が異なる
  • 一律の時間制御では対応不可

→ 対策

  • SymbolInfoSessionTradeで銘柄ごとに取得
  • _Symbol単位で制御

■ ミス③：無限リトライロジック

while(!success)
{
   OrderSend(...);
}

→ 問題点

  • market-closedでは永遠に成功しない
  • CPU負荷・ログ肥大・口座制限のリスク

→ 対策

  • リトライ回数制限
  • 時間条件でブロック

■ ミス④：バックテスト依存

→ 問題点

  • ストラテジーテスターは常時取引可能な場合がある
  • 実運用でmarket-closed多発

→ 対策

  • フォワードテスト（実環境）で検証
  • VPS環境で確認

■ ミス⑤：エラー無視

→ 問題点

  • GetLastError()を見ていない
  • 原因分析ができない

→ 対策

int error = GetLastError();
Print("Error: ", error);

5.2 EA設計上のリスク

market-closedを放置すると、単なるエラーではなく戦略全体の品質低下につながります。

■ 主なリスク

  • 約定機会の損失
  • 無駄な注文処理増加
  • スリッページ（slippage）悪化
  • スプレッド（spread）拡大時の誤発注

■ なぜ起きるか

  • 時間フィルター未実装
  • execution条件の未考慮
  • 高頻度ロジック（スキャル）

5.3 実務で重要な注意点

■ 注意①：時間は「固定」ではなく「動的」

  • サマータイム（DST）でズレる
  • ブローカーごとに変更される

→ 固定時間ではなくセッション取得が安全

■ 注意②：複合条件で制御する

単純な時間チェックだけでは不十分です。

■ 推奨条件

  • 取引時間
  • スプレッド
  • ボラティリティ（ATRなど）
  • ポジション状態

5.4 実務ベースの安全設計

■ 最小構成（初心者向け）

if(IsTradingAllowed())
{
   OrderSend(...);
}

■ 推奨構成

if(IsTradingAllowed() && SpreadCheck() && RiskCheck())
{
   OrderSend(...);
}

■ 理由

  • エラーの多くは複合要因
  • 単一対策では再発する

5.5 失敗を防ぐチェックリスト

  • サーバー時間で判定しているか
  • 銘柄ごとの取引時間を取得しているか
  • 無限リトライになっていないか
  • ログを確認しているか
  • フォワードテストを実施したか

5.6 重要ポイント

  • 最大のミスは「時間認識のズレ」
  • EAは必ず時間制御を入れる
  • 無限リトライは絶対に避ける

6. 実務での使いどころ（運用視点）

【結論】
market-closed対策は単なるエラー回避ではなく、取引品質（約定率・期待値）を向上させるための重要なフィルターです。戦略設計の一部として組み込むことで再現性が高まります。

【定義】
実務での使いどころとは、取引時間・流動性・約定条件を考慮し、無駄な注文を排除してパフォーマンスを最適化する運用方法を指します。

6.1 トレード制御としての活用

market-closed対策は「時間フィルター」として活用します。

■ 基本的な使い方

  • 取引時間内のみEAを稼働
  • セッションごとにロジックを切り替え
  • 流動性が低い時間帯を除外

■ セッション別の考え方

  • アジア時間
    → ボラティリティ低い（レンジ傾向）
  • ロンドン時間
    → トレンド発生しやすい
  • ニューヨーク時間
    → ボラティリティ最大

■ 実務ポイント

  • 戦略ごとに適切な時間帯を選ぶ
  • market-closed対策＝「時間選別ロジック」

6.2 リスク管理への応用

market-closedを考慮することで、不要なリスクを回避できます。

■ 回避できるリスク

  • スプレッド（spread）急拡大
  • 約定拒否（execution failure）
  • スリッページ（slippage）増大
  • 流動性不足による価格飛び

■ 具体的な活用

if(IsTradingAllowed() && Spread < MaxSpread)
{
   OrderSend(...);
}

■ なぜ有効か

  • 市場が閉じる直前・直後は不安定
  • 約定品質が著しく低下する

6.3 パフォーマンス最適化

market-closed対策は、EAの無駄な処理削減にも直結します。

■ 改善ポイント

  • 不要なOrderSend削減
  • ログ出力の最適化
  • CPU負荷軽減
  • VPSコスト最適化

■ 結果

  • 約定率向上
  • トレード精度向上
  • ドローダウン（DD）抑制

6.4 実務レベルの設計パターン

■ パターン①：時間フィルター型（基本）

if(IsTradingAllowed())
{
   Trade();
}

→ 初心者向け・実装容易

■ パターン②：セッション戦略型

if(IsLondonSession())
{
   TrendStrategy();
}
else if(IsAsiaSession())
{
   RangeStrategy();
}

→ 戦略分岐で期待値改善

■ パターン③：総合フィルター型

if(IsTradingAllowed() && SpreadCheck() && VolatilityCheck())
{
   OrderSend(...);
}

→ 実務で最も再現性が高い

6.5 他手法との違い

■ market-closed対策あり

  • 無駄な注文が減る
  • execution成功率が高い
  • 安定したパフォーマンス

■ market-closed対策なし

  • エラー頻発
  • 約定率低下
  • ロジックの信頼性低下

■ 本質的な違い

  • 対策あり → 環境適応型EA
  • 対策なし → 単純ロジックEA

6.6 実務での最適解

以下の3点を満たす構成が最適です。

  • 取引時間を事前に遮断
  • 複数条件（spread・slippage）で制御
  • エラー発生前に回避

■ 推奨フロー

  1. 時間チェック
  2. 市場状態チェック（spread・volatility）
  3. シグナル判定
  4. 注文実行

6.7 重要ポイント

  • market-closed対策＝時間フィルター
  • 約定品質と期待値に直結
  • EA設計では必須機能

7. よくある質問（FAQ）

【結論】
market-closedに関する疑問の多くは「取引時間」「サーバー時間」「ブローカー仕様」の3点で説明できます。ここを理解すれば再発防止が可能です。

【定義】
FAQは、実務で頻出する疑問に対して短く明確に答えることで、即時解決と再現性を高めるセクションです。

7.1 market-closedはバグですか？

→ いいえ。正常な仕様です。
市場が閉じている時間に注文した場合、MT5サーバーが自動的に拒否します。

7.2 土日以外でも発生するのはなぜ？

→ ブローカーの取引時間や祝日が影響します。
特にCFDや指数、ゴールドなどは取引時間が限定されています。

7.3 自動売買（EA）で回避できますか？

→ 可能です。時間フィルターを実装すれば防げます。
SymbolInfoSessionTrade＋TimeCurrent()で制御します。

7.4 デモ口座でも発生しますか？

→ はい。発生します。
デモでもリアルと同様に取引時間制限があります。

7.5 通貨ペアごとに違いはありますか？

→ あります。銘柄ごとに取引時間は異なります。
FXはほぼ24時間（平日）ですが、CFDや指数は制限あり。

7.6 VPSを使えば防げますか？

→ 直接は防げません。
VPSは接続安定性には有効ですが、market-closedは時間の問題です。

7.7 エラーコードはどこで確認できますか？

→ JournalログまたはGetLastError()で確認できます。

int error = GetLastError();
Print(error);

7.8 off quotesとの違いは？

→ 原因が異なります。

  • market-closed → 時間外
  • off quotes → 価格取得・流動性問題

7.9 バックテストでは出ないのに本番で出るのはなぜ？

→ テスターは常時取引可能な場合があるためです。
実運用では必ず時間制御が必要です。

7.10 何時から何時まで取引可能ですか？

→ ブローカー・銘柄によって異なるため固定ではありません。
正確にはSymbolInfoSessionTradeで取得する必要があります。

7.11 重要ポイント

  • market-closedは仕様であり回避可能
  • 原因は「時間」と「ブローカー仕様」
  • EAでは必ず時間フィルターを実装する

8. まとめ

【結論】
market-closedは取引時間外に発生する正常なエラーであり、EAでは時間フィルターを実装することで完全に回避可能です。

【定義】
まとめとしての要点は、原因（時間）→対策（事前制御）→運用（フィルター化）の流れで理解することです。

8.1 本記事の重要ポイント整理

■ 基本理解

  • market-closed＝市場が閉じている状態
  • エラーではなく仕様
  • サーバー時間で判定される

■ 原因（Why）

  • 取引時間（Trading Session）外
  • ブローカーの制限
  • サーバー時間とのズレ

■ 解決（How）

  • TimeCurrent()で時間取得
  • SymbolInfoSessionTradeで取引時間確認
  • 注文前にフィルター実装

■ 比較（vs 他エラー）

  • market-closed → 時間問題
  • off quotes → 価格問題
  • no prices → データ問題

8.2 実務での最適アクション

再現性の高い運用は以下の通りです。

■ 推奨フロー

  1. 取引時間チェック
  2. スプレッド（spread）確認
  3. ボラティリティ・条件判定
  4. OrderSend実行

■ 推奨設計

if(IsTradingAllowed() && SpreadCheck() && RiskCheck())
{
   OrderSend(...);
}

8.3 リスクと期待値の観点

■ 対策なし

  • エラー頻発
  • 約定率低下
  • 期待値のブレ増大

■ 対策あり

  • 無駄な注文削減
  • execution安定
  • 長期的にパフォーマンス向上

8.4 最終結論

  • market-closedは回避できるエラー
  • 原因は「時間」
  • 解決は「事前制御」
  • EAでは必須機能