MQL5 no pricesエラーの原因と解決手順【完全ガイド】

リファレンス
目次

1. MQL5「no prices」エラーとは何か（定義 / What）

【結論】
「no prices」エラーは、価格データ（Bid/Ask）が取得できていない状態で注文処理を行ったときに発生するエラーです。多くの場合、環境やタイミングの問題であり、適切なチェックで回避可能です。

【定義】
「no prices」とは、取引に必要な現在価格（Bid/Ask）が未取得または無効な状態を示すエラーコードです。

1.1 no prices エラーの基本理解

MQL5でのトレード処理（OrderSend / OrderCheck）は、必ず現在の価格データ（Bid/Ask）を前提に実行されます。
この価格が取得できていない場合、注文の「execution（約定処理）」が成立せず、エラーとして返されます。

重要ポイント（短文化）：

  • 価格が「0」または「未取得」＝注文不可
  • サーバーからの価格配信が前提
  • EAのロジック以前に「データ不足」で失敗する

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

「no prices」は特定の条件下で発生しやすい特徴があります。

主な発生タイミング：

  • EA起動直後（OnInit直後）
  • 初回Tickがまだ来ていない状態
  • 市場クローズ時（週末・祝日）
  • シンボル未選択（MarketWatch未登録）
  • サーバー未接続状態
  • VPS再起動直後（データ未同期）

補足：

  • 「Tick」とは価格更新イベント（価格が動く瞬間）
  • Tickが来ない＝価格データが更新されない

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

多くの初心者が「ロジックのバグ」と誤認しますが、実際は環境依存の問題であるケースが大半です。

よくある誤解：

  • ❌ コードの書き方が間違っている
    → 実際は価格データ未取得
  • ❌ OrderSendの使い方ミス
    → 実際はBid/Askが0
  • ❌ ブローカーの不具合
    → 実際は市場が閉じている

1.4 関連する概念（エンティティ整理）

このエラーを理解するには、以下の関連概念が重要です：

  • Bid / Ask：売値・買値（取引の基準価格）
  • spread：BidとAskの差（広がると異常の可能性あり）
  • execution：注文が実際に約定する処理
  • slippage：注文価格と約定価格のズレ
  • order条件：価格・ロット・時間などの成立条件

これらのうち「価格」が成立していないのが「no prices」です。

1.5 他エラーとの違い（簡易整理）

似たエラーと混同されやすいため、最低限の違いを押さえておきます。

  • no prices
    → 価格そのものが存在しない（未取得）
  • off quotes
    → 価格はあるが約定できない（流動性不足）
  • market closed
    → 取引時間外でそもそも取引不可

この違いを理解することで、無駄なデバッグを回避できます。

1.6 この章の実務的ポイント

  • no pricesは「ロジック問題ではない」ケースが多い
  • 原因の8割は「データ未取得」または「タイミング」
  • 対策は「事前チェック」でほぼ防げる

2. 【結論】no prices エラーの解決手順（How）

【結論】
「no prices」エラーは、価格取得（Bid/Ask）と環境状態を事前にチェックすることでほぼ100%回避可能です。特に「SymbolInfoTick」と「接続状態」の確認が最重要です。

2.1 最短チェックリスト（即解決用）

以下を上から順に確認すれば、多くの場合その場で解決できます。

  • サーバーに接続されているか
  • シンボルが有効（選択済み）か
  • Tickデータが取得できているか
  • Bid / Ask が0でないか
  • 市場が開いているか（取引時間内）
  • spread（スプレッド）が異常でないか

重要ポイント（短文化）：

  • 「価格取得できているか」だけ見ればよい
  • ロジック前に“環境チェック”が必要

2.2 安全な実装パターン（コード例）

以下は、実務で使うべき「no prices回避テンプレート」です。

MqlTick tick;

// シンボルの有効化
if(!SymbolSelect(_Symbol, true))
{
   Print("SymbolSelect failed");
   return;
}

// Tickデータ取得
if(!SymbolInfoTick(_Symbol, tick))
{
   Print("Tick取得失敗");
   return;
}

// Bid / Askチェック
if(tick.bid == 0 || tick.ask == 0)
{
   Print("価格未取得（no prices回避）");
   return;
}

このコードの役割：

  • SymbolSelect → MarketWatchに登録
  • SymbolInfoTick → 最新価格取得
  • bid/askチェック → 実行ガード

2.3 注文前チェック（実務レベル）

注文（OrderSend）前には、必ず以下を入れます。

// スプレッドチェック（例：20ポイント以上は回避）
double spread = (tick.ask - tick.bid) / _Point;

if(spread > 20)
{
   Print("スプレッド異常");
   return;
}

理由：

  • spread拡大＝流動性低下 → no pricesやoff quotesに繋がる

2.4 接続状態チェック（見落としがち）

if(!TerminalInfoInteger(TERMINAL_CONNECTED))
{
   Print("サーバー未接続");
   return;
}

補足：

  • VPS環境では特に重要
  • 接続断＝価格データ停止

2.5 よくある失敗パターン

初心者がよくやるミス：

  • ❌ OnInitで即OrderSendする
    → Tick未取得でno prices
  • ❌ SymbolSelectを省略
    → データが来ない
  • ❌ Bid/Askチェックなし
    → 不安定な注文
  • ❌ spread無視
    → execution失敗

2.6 なぜこの手順で解決できるのか

理由はシンプルです：

  • no prices = 「価格が存在しない」
  • 上記チェック = 「価格が存在する状態を保証」

つまり、

👉 「存在しないデータを使わない」設計にする

これが本質です。

2.7 それでも解決しない場合の優先順位

以下の順で疑います：

  1. VPSの通信遅延・切断
  2. ブローカーの仕様（銘柄制限）
  3. 取引時間（特にマイナー通貨）
  4. サーバー側の一時的問題

※頻発する場合は運用停止を検討（リスク管理）

2.8 実務でのベストプラクティス

  • 注文前に必ず「価格検証関数」を通す
  • 共通関数化して再利用
  • ログ（Experts / Journal）で必ず確認

3. なぜ「no prices」が発生するのか（仕組み / Why）

【結論】
「no prices」は、MT5内部で価格データ（Tick）がまだ配信・更新されていない状態で処理が走ることにより発生します。つまり原因は「データ未同期」です。

【定義】
MT5における価格データは、サーバーからのTick配信に依存するリアルタイムデータであり、常に存在するわけではありません。

3.1 価格データ取得の仕組み（MT5内部）

MQL5では、価格は以下の流れで取得されます。

  1. ブローカーサーバーからTick（価格更新）が送信される
  2. MT5ターミナルが受信・キャッシュする
  3. EAがSymbolInfoTick等で取得する

重要ポイント（短文化）：

  • 価格は「取得するもの」であり常に存在しない
  • Tickが来ないと価格は更新されない

3.2 Bid / Ask が存在しない状態とは

通常、Bid（売値）とAsk（買値）は常にあると思われがちですが、実際には以下の状態では「存在しない」とみなされます。

  • 初回Tick未到達（EA起動直後）
  • シンボル未購読（SymbolSelect未実行）
  • サーバー未接続
  • 市場停止（週末・祝日）
  • 流動性枯渇（極端なケース）

このとき：

  • bid = 0
  • ask = 0

となり、「no prices」が発生します。

3.3 初回Tick問題（最重要）

最も頻出する原因がこれです。

状況：

  • EA起動（OnInit）
  • まだTickが来ていない
  • 価格データが空

結果：
→ OrderSendすると no prices

重要ポイント：

  • 「OnInit直後に注文」は危険
  • OnTickで1回以上Tickを受けてから処理する必要あり

3.4 シンボル未購読問題

MT5では、すべての通貨ペア・銘柄が自動でデータ配信されるわけではありません。

条件：

  • MarketWatchに表示されていない
  • SymbolSelectしていない

結果：
→ Tickが来ない → 価格未取得

補足：

  • 特にマイナー通貨・CFDで発生しやすい

3.5 サーバー接続とデータ同期

接続状態も直接影響します。

  • 接続あり → Tick配信あり → 価格取得可能
  • 接続なし → Tick停止 → 価格取得不可

VPS環境では：

  • 再起動直後
  • ネットワーク遅延

で発生しやすい

3.6 市場状態（取引時間）の影響

市場が閉じている場合：

  • Tickが来ない
  • 価格が更新されない

代表例：

  • 週末（FXは土日停止）
  • 祝日
  • 銘柄ごとの取引時間制限

3.7 spread・流動性との関係

厳密には「no prices」とは別ですが、関連があります。

  • 流動性低下 → spread拡大
  • 極端な場合 → 価格更新停止

結果：
→ no prices や off quotes に繋がる

重要概念：

  • spread = 市場の健全性指標
  • slippage / execution にも影響

3.8 なぜ環境依存エラーなのか

まとめると：

  • コードではなく「外部データ」に依存
  • サーバー・時間・接続の影響を受ける
  • 同じEAでも環境で発生率が変わる

つまり：

👉 no prices = 「データ供給の問題」

3.9 実務的な理解

実運用では以下の認識が重要です：

  • エラーは「例外」ではなく「前提条件違反」
  • 価格取得を保証する設計が必須
  • executionの安定性に直結する

4. よくある原因別の対処法（原因→解決）

【結論】
「no prices」は原因ごとに対処すれば確実に防げます。最も重要なのは「シンボル・Tick・接続」の3点を事前に保証することです。

4.1 原因① シンボル未選択（SymbolSelect問題）

【結論】
シンボルが有効化されていないと、Tickが配信されず価格が取得できません。

【対処方法】

if(!SymbolSelect(_Symbol, true))
{
   Print("シンボル選択失敗");
   return;
}

ポイント：

  • MarketWatchに表示されているか確認
  • 自動売買では明示的にSymbolSelectする

よくある失敗：

  • バックテストでは動くのに本番で動かない
  • マイナー通貨・CFDで発生

4.2 原因② Tick未取得（初回Tick問題）

【結論】
Tickを1回も受信していない状態では、価格は存在しません。

【対処方法】

MqlTick tick;

if(!SymbolInfoTick(_Symbol, tick))
{
   Print("Tick未取得");
   return;
}

if(tick.bid == 0 || tick.ask == 0)
{
   Print("価格未初期化");
   return;
}

代替手段：

  • OnTickで処理する
  • 初回はスキップするロジックを入れる
static bool is_ready = false;

if(!is_ready)
{
   is_ready = true;
   return;
}

4.3 原因③ 市場クローズ（取引時間外）

【結論】
市場が閉じている間はTickが更新されず、価格は実質「停止」します。

【対処方法】

datetime time = TimeCurrent();

// 取引時間の簡易チェック（例：土日回避）
if(TimeDayOfWeek(time) == 0 || TimeDayOfWeek(time) == 6)
{
   Print("市場クローズ");
   return;
}

実務ポイント：

  • 銘柄ごとに取引時間が異なる
  • CFD・指数は特に注意

4.4 原因④ スプレッド異常（流動性低下）

【結論】
spreadが極端に広がると、価格取得やexecutionが不安定になります。

【対処方法】

double spread = (tick.ask - tick.bid) / _Point;

if(spread > 30) // 許容値は戦略依存
{
   Print("スプレッド異常");
   return;
}

理由：

  • 流動性低下 → 価格更新遅延
  • slippage増加 → 約定失敗

4.5 原因⑤ サーバー未接続

【結論】
接続が切れていると、Tickが完全に停止します。

【対処方法】

if(!TerminalInfoInteger(TERMINAL_CONNECTED))
{
   Print("未接続");
   return;
}

実務で重要：

  • VPS環境では最優先チェック
  • 再接続ロジックも検討

4.6 原因⑥ ブローカー仕様・銘柄制限

【結論】
ブローカーごとに「取引可能時間」「最小ロット」「流動性」が異なります。

対処：

  • 取引時間の確認
  • 銘柄ごとの仕様チェック
  • SymbolInfo系で取得

補足：

  • 深夜・早朝は流動性低下しやすい
  • 仮想通貨CFDなどは特に差が大きい

4.7 原因⑦ VPS・通信遅延

【結論】
通信遅延によりTick配信が遅れると、価格未取得状態が発生します。

対処：

  • VPSのリージョンをブローカーに近づける
  • Ping確認
  • 再接続処理

4.8 原因別まとめ（実務用）

優先順位順：

  1. SymbolSelect（最頻出）
  2. Tick未取得（初回問題）
  3. 接続状態
  4. 市場時間
  5. spread / 流動性
  6. VPS / ブローカー仕様

4.9 再発防止の設計

実務では以下を必ず実装：

  • 注文前チェック関数（共通化）
  • 価格バリデーション
  • ログ出力（原因特定）

例：

bool IsTradeReady()
{
   MqlTick tick;

   if(!SymbolInfoTick(_Symbol, tick)) return false;
   if(tick.bid == 0 || tick.ask == 0) return false;
   if(!TerminalInfoInteger(TERMINAL_CONNECTED)) return false;

   return true;
}

5. 他のエラーとの違い（比較 / vs）

【結論】
「no prices」は価格が存在しない状態、一方で他のエラーは「価格はあるが条件を満たさない状態」です。“データ未取得か、条件不一致か”で切り分けるのが最短です。

【定義】
エラー分類は以下の2系統に分かれます：

  • データ未取得系：no prices
  • 約定条件不一致系：off quotes / invalid price など

5.1 主要エラー比較（実務用整理）

エラー名主な原因発生タイミング対処難易度再発率
no prices価格未取得（Bid/Ask=0）起動直後・未接続・未購読低中
off quotes流動性不足・約定不可急変動・低流動性時中高
market closed取引時間外週末・祝日低低
invalid price指定価格が無効指値・逆指値設定時中中

重要ポイント（短文化）：

  • no prices＝「そもそも価格がない」
  • off quotes＝「価格はあるが約定できない」

5.2 no prices vs off quotes

違いの本質：

  • no prices
    → 価格データが存在しない（Tick未取得）
  • off quotes
    → 価格は存在するがexecution不可（流動性不足・価格ズレ）

実務的判断：

  • Bid/Askが0 → no prices
  • Bid/Askはあるが注文失敗 → off quotes

補足：

  • off quotesはslippageやspread拡大と強く関連

5.3 no prices vs market closed

違いの本質：

  • no prices
    → 市場状態に関係なく発生（接続・Tick問題）
  • market closed
    → 明確に取引時間外

判断方法：

if(TimeDayOfWeek(TimeCurrent()) == 0 || TimeDayOfWeek(TimeCurrent()) == 6)
{
   // market closed の可能性高
}

重要ポイント：

  • market closedは予測可能
  • no pricesは環境依存で不定期発生

5.4 no prices vs invalid price

違いの本質：

  • no prices
    → 価格そのものが未取得
  • invalid price
    → 指定した注文価格が不正（古い・ズレ）

例：

  • no prices → tick.bid = 0
  • invalid price → tick.bidはあるが注文価格が乖離

5.5 実務での切り分けフロー

以下の順で確認すると効率的です：

  1. Bid / Askが0か？
    → YES → no prices
  2. 接続されているか？
    → NO → no prices
  3. 市場時間内か？
    → NO → market closed
  4. spreadが異常か？
    → YES → off quotes可能性
  5. 注文価格が現在価格と乖離しているか？
    → YES → invalid price

5.6 なぜ切り分けが重要か

理由：

  • エラーごとに対処法が全く違う
  • 誤診すると無限デバッグになる
  • 実運用では機会損失に直結

例：

  • no prices → 待てば解決する場合あり
  • off quotes → 条件変更しないと解決しない

5.7 実務的な判断基準（重要）

  • 「価格があるか？」を最初に確認
  • 次に「約定できるか？」を見る
  • 最後に「条件が正しいか？」を確認

この順序でほぼすべてのエラーは分類可能です。

6. よくある失敗・ハマりポイント

【結論】
「no prices」はコードの問題ではなく“前提条件の未チェック”で発生するケースが大半です。特に「初回Tick・シンボル・接続」の見落としが致命的です。

6.1 初回Tick問題を無視する

【結論】
EA起動直後は価格データが未取得のため、即注文すると高確率でno pricesが発生します。

よくあるコード：

// NG例：OnInitで即注文
OrderSend(...);

改善策：

  • OnTickで処理する
  • 初回はスキップする
static bool is_ready = false;

if(!is_ready)
{
   is_ready = true;
   return;
}

理由：

  • Tick（価格更新）が1回も来ていない状態ではBid/Askが無効

6.2 SymbolInfoTickを使わない

【結論】
価格取得を確認せずに注文すると、内部状態に依存した不安定な挙動になります。

NGパターン：

double price = SymbolInfoDouble(_Symbol, SYMBOL_BID);
// そのまま使用

改善策：

MqlTick tick;

if(!SymbolInfoTick(_Symbol, tick)) return;
if(tick.bid == 0 || tick.ask == 0) return;

理由：

  • SymbolInfoDouble単体では「更新状態」が保証されない

6.3 取引時間フィルタを実装していない

【結論】
市場クローズ時はTickが停止するため、no pricesと誤認する原因になります。

改善策：

datetime now = TimeCurrent();

if(TimeDayOfWeek(now) == 0 || TimeDayOfWeek(now) == 6)
{
   return;
}

補足：

  • CFD・指数は時間がさらに複雑
  • ブローカー仕様に依存

6.4 VPS環境を軽視する

【結論】
VPSでは通信遅延・再接続・データ未同期が頻発し、no pricesの発生率が上がります。

よくある状況：

  • VPS再起動直後
  • ネットワーク一時断
  • サーバー切替

改善策：

if(!TerminalInfoInteger(TERMINAL_CONNECTED))
{
   return;
}

実務ポイント：

  • Pingが高いとTick遅延
  • execution品質にも影響

6.5 spreadチェックをしていない

【結論】
spread拡大は流動性低下のシグナルであり、no pricesやoff quotesの前兆になります。

改善策：

double spread = (tick.ask - tick.bid) / _Point;

if(spread > 30)
{
   return;
}

理由：

  • 流動性が薄いと価格更新が不安定
  • slippage増大 → 約定失敗

6.6 ログ（Experts / Journal）を見ない

【結論】
ログを確認しないと、原因の特定がほぼ不可能です。

確認すべき場所：

  • Expertsタブ（EAのログ）
  • Journalタブ（システムログ）

見るべき内容：

  • エラーコード
  • 発生タイミング
  • 接続状態

6.7 エラーを無視して処理を続行する

【結論】
エラーを無視すると、連続失敗→ロジック崩壊→資金リスクに繋がります。

NG例：

OrderSend(...);
// エラー未チェック

改善策：

  • 戻り値チェック
  • エラーログ出力
  • 再試行制御

6.8 共通チェックを実装していない

【結論】
毎回個別に処理を書くと、チェック漏れが必ず発生します。

改善策（テンプレ化）：

bool IsTradeReady()
{
   MqlTick tick;

   if(!SymbolInfoTick(_Symbol, tick)) return false;
   if(tick.bid == 0 || tick.ask == 0) return false;
   if(!TerminalInfoInteger(TERMINAL_CONNECTED)) return false;

   return true;
}

6.9 実務的な失敗まとめ

頻出順：

  1. 初回Tick無視
  2. SymbolSelect未実装
  3. 接続チェックなし
  4. spread未考慮
  5. ログ未確認

6.10 この章の重要ポイント

  • no pricesは「設計ミス」で防げる
  • 失敗の多くは“確認不足”
  • 再発防止は「共通化」が鍵

7. 実務での使いどころ（運用設計）

【結論】
「no prices」対策は単なるエラー回避ではなく、EAの安定稼働と約定品質（execution）を担保する設計要素です。注文前のバリデーションを標準化することで、機会損失と異常約定を同時に抑制できます。

7.1 安全な注文フロー設計

【結論】
注文は「価格取得 → 検証 → 注文」の3段階で実装することで安定します。

推奨フロー：

  1. Tick取得（SymbolInfoTick）
  2. 価格検証（Bid/Ask, spread）
  3. 環境検証（接続・取引時間）
  4. 注文実行（OrderSend / OrderCheck）

コード例（最小テンプレ）：

bool IsTradeReady(MqlTick &tick)
{
   if(!SymbolInfoTick(_Symbol, tick)) return false;
   if(tick.bid == 0 || tick.ask == 0) return false;

   if(!TerminalInfoInteger(TERMINAL_CONNECTED)) return false;

   double spread = (tick.ask - tick.bid) / _Point;
   if(spread > 30) return false;

   return true;
}

// 使用例
MqlTick tick;
if(!IsTradeReady(tick)) return;

// ここでOrderSend

ポイント：

  • 「OrderSend前に必ず通す」設計にする
  • 条件を満たさない場合は“何もしない”

7.2 エラー回避ロジックのテンプレート化

【結論】
共通関数として切り出すことで、開発効率と再現性が大幅に向上します。

実務メリット：

  • バグの局所化（1箇所修正で全体反映）
  • チェック漏れ防止
  • 複数EAで再利用可能

発展形（拡張例）：

enum TradeStatus
{
   TRADE_OK,
   NO_CONNECTION,
   NO_PRICE,
   HIGH_SPREAD
};

TradeStatus CheckTradeStatus(MqlTick &tick)
{
   if(!TerminalInfoInteger(TERMINAL_CONNECTED)) return NO_CONNECTION;

   if(!SymbolInfoTick(_Symbol, tick)) return NO_PRICE;
   if(tick.bid == 0 || tick.ask == 0) return NO_PRICE;

   double spread = (tick.ask - tick.bid) / _Point;
   if(spread > 30) return HIGH_SPREAD;

   return TRADE_OK;
}

7.3 リスク管理との関係（重要）

【結論】
no prices対策は、単なるエラー回避ではなく“期待値とドローダウン管理”に直結します。

影響構造：

  • 注文失敗 → 機会損失
  • 無理な注文 → slippage増加
  • 不安定execution → パフォーマンス劣化

例：

  • トレンド初動で注文失敗 → エントリー遅延
  • 高spread時に無理に注文 → 損益悪化

重要ポイント：

  • 「取引しない判断」も戦略の一部
  • 無理なexecutionは長期でマイナス期待値

7.4 EA設計への組み込み方

【結論】
no prices対策は「例外処理」ではなく、コアロジックの一部として設計する必要があります。

設計レイヤー：

  • シグナル生成（エントリー条件）
  • フィルタ層（価格・環境チェック）
  • 実行層（OrderSend）

構造イメージ：

// シグナル判定
if(!SignalCondition()) return;

// 環境チェック
MqlTick tick;
if(!IsTradeReady(tick)) return;

// 注文
ExecuteTrade(tick);

7.5 マルチシンボル・マルチタイムフレーム対応

【結論】
複数銘柄を扱う場合、シンボルごとに価格取得状態が異なるため個別チェックが必須です。

注意点：

  • シンボルごとにTick到達タイミングが違う
  • 流動性（spread）も銘柄依存

対策：

  • 配列・ループで個別チェック
  • SymbolSelectを事前実行

7.6 VPS運用での最適化

【結論】
VPSでは「接続・遅延・同期」を前提に設計しないと、no pricesの発生率が上がります。

対策：

  • ブローカーと同リージョンのVPSを使用
  • 再接続チェックを定期実行
  • 起動直後は一定時間待機

実務ポイント：

  • Ping（レイテンシ）はexecution品質に直結
  • 不安定環境では“保守的なフィルタ”が有効

7.7 実務でのベストプラクティス

  • 注文前チェックを必須化（例外ではない）
  • spreadフィルタを必ず実装
  • ログを体系的に出力
  • エラーごとに分岐処理

短文化まとめ：

  • 「価格がないなら取引しない」
  • 「条件が悪いなら待つ」
  • 「すべてはexecution品質のため」

8. FAQ（よくある質問）

【結論】
「no prices」は多くが一時的なデータ未取得であり、事前チェックと待機ロジックで解消できます。頻発時のみ環境・設計を見直します。

【定義】
FAQでは、実務で頻出する疑問に対し短く再利用可能な回答を提示します。

8.1 no pricesは致命的エラーですか？

いいえ。多くは一時的な状態です。
ただし頻発する場合は、接続・Tick取得・シンボル設定のいずれかに問題があります。

8.2 バックテストでも発生しますか？

発生する場合があります。
ヒストリカルデータ不足や、テスターの初期状態でTickが未生成のときに起こります。

8.3 SymbolInfoTickとRefreshRatesの違いは？

  • SymbolInfoTick：現在のTick構造体を取得（推奨）
  • RefreshRates：価格の更新要求（旧来の手法）

実務ではSymbolInfoTickを優先します。

8.4 spreadは関係ありますか？

直接原因ではありませんが、関係します。
spread拡大＝流動性低下のため、価格更新遅延やexecution不安定を引き起こします。

8.5 VPSだと発生しやすいですか？

はい、発生確率は上がります。
通信遅延・再接続・同期遅れにより、Tick未取得状態が増えるためです。

8.6 自動売買は止めるべきですか？

一時的なら不要です。
ただし連続発生する場合は、リスク管理の観点から一時停止を検討すべきです。

8.7 ログはどこを見ればよいですか？

以下を確認します：

  • Experts（EAの動作ログ）
  • Journal（接続・システムログ）

エラーの発生タイミングと環境状態を必ず確認してください。

8.8 OnInitで注文しても大丈夫ですか？

基本的に推奨されません。
初回Tick未到達のため、no pricesが発生しやすいです。

9. まとめ（再現性のある対策）

【結論】
「no prices」は価格データ未取得が原因のため、注文前チェックを徹底すればほぼ完全に回避可能です。重要なのは「環境確認をロジックに組み込むこと」です。

9.1 最重要ポイント（3行要約）

  • no prices = Bid/Askが取得できていない状態
  • 対策 = Symbol・Tick・接続の事前チェック
  • 実務 = 注文前バリデーションを必須化する

9.2 再現性のある対策フロー

以下の順序で実装すれば、安定した運用が可能です。

  1. シンボル有効化（SymbolSelect）
  2. Tick取得（SymbolInfoTick）
  3. Bid / Ask検証（0チェック）
  4. 接続確認（TerminalInfoInteger）
  5. spreadフィルタ
  6. 注文実行（OrderSend）

9.3 実務テンプレート（最終形）

bool IsTradeReady(MqlTick &tick)
{
   if(!TerminalInfoInteger(TERMINAL_CONNECTED)) return false;

   if(!SymbolInfoTick(_Symbol, tick)) return false;
   if(tick.bid == 0 || tick.ask == 0) return false;

   double spread = (tick.ask - tick.bid) / _Point;
   if(spread > 30) return false;

   return true;
}

// 実行例
MqlTick tick;
if(!IsTradeReady(tick)) return;

// 注文処理
// OrderSend(...)

9.4 設計レベルでの本質

  • エラーは「例外」ではなく前提条件違反
  • executionの品質は事前チェックで決まる
  • 無理な注文は期待値を下げる行動

9.5 運用視点での重要性

  • no prices放置 → 機会損失
  • 無理な注文 → slippage増加
  • 不安定運用 → ドローダウン悪化

したがって：

👉 「取引しない判断」も戦略の一部

9.6 最終アクション

  • 注文前チェック関数を必ず実装する
  • ログを確認し原因を特定する
  • VPS・ブローカー環境も最適化する