Off quotes / リクオート（MT5/MQL5）を完全解決

EAを動かしていて、ジャーナルやExpertタブに off quotes（10021）や requote（10004）が出ると「ブローカーに約定拒否された」ように見えて不安になりますが、この2つは資金やロットの問題ではなく「価格」の問題です。あなたが送った価格と、サーバーがいま持っている価格が合わなかった——それだけのことで、原因のほとんどは相場急変・許容スリッページ・執行方式・回線遅延のどれかに落ちます。

この記事は、MT5でEAを使う人とMQL5でEAを書く人の両方に向けて、10021（TRADE_RETCODE_PRICE_OFF）と10004（TRADE_RETCODE_REQUOTE）、そしてMT4時代のエラー136/138の正体・原因・即できる対処・コード側での恒久対策までを一本にまとめた決定版です。エラーコード全般の一覧は MQL5 / MT5 エラーコード対処法の総合ガイド を参照してください。

---

この2つ（+MT4の136/138）は何が違うのか

「価格が合わない」系の拒否は、サーバーの返事の仕方で2種類あります。

① TRADE_RETCODE_PRICE_OFF = 10021（処理できる気配値がない）

OrderSend() の結果 MqlTradeResult.retcode に入る値で、**「リクエストを処理するための気配値がない（There are no quotes to process the request）」**という拒否です。サーバー側に有効な価格がない、または送られた価格が現在の気配値から離れすぎて処理できない状態を指します。

意味: リクエストを処理する気配値がない
定数: TRADE_RETCODE_PRICE_OFF
値  : 10021

② TRADE_RETCODE_REQUOTE = 10004（リクオート＝新価格の再提示）

同じく OrderSend() のretcodeで、こちらは単なる拒否ではなく**「その価格ではダメだが、この新しい価格ならどうか」という再提示（リクオート）です。MqlTradeResult の bid / ask にサーバーが提示し直した価格**が入って返ってきます。

意味: リクオート（Requote）— 新価格の再提示
定数: TRADE_RETCODE_REQUOTE
値  : 10004

// ログで確認できる典型的な出力例
2026.07.07 21:30:02.118 EA_NAME EURUSD,M5: OrderSend error 10004 (requote)
2026.07.07 21:30:02.310 EA_NAME EURUSD,M5: OrderSend error 10021

③ MT4時代のエラー136 / 138

MQL4（MT4）では同じ現象が GetLastError() のエラーコードで返っていました。

MT4定数	値	対応するMT5 retcode
ERR_OFF_QUOTES	136	10021 (TRADE_RETCODE_PRICE_OFF)
ERR_REQUOTE	138	10004 (TRADE_RETCODE_REQUOTE)

古いEAの解説記事やMT4版EAのログで「error 136」「error 138」を見たら、この記事の内容がそのまま当てはまります（MT4では RefreshRates() で価格を取り直してから再送するのが定石でした。MT5での書き方は後述）。

実務上の切り分け：

retcode	サーバーの言い分	EAが取るべき行動
10004 (requote)	「価格が動いた。新価格を提示する」	最新価格で再送（または見送り）
10021 (price off)	「処理できる気配値がない」	少し待って最新ティックで再送

どちらも一時的（リトライ可能）なエラーであり、コード修正や設定変更で「絶対に出なくする」ことはできませんが、頻度は大幅に減らせます。

---

まず30秒でできる切り分け

1. いつ出たかをジャーナルの時刻で確認する
   • 雇用統計・FOMC等の指標発表の瞬間 → 正常な相場急変。EAが指標フィルターを持っているなら有効化する
   • サーバー時刻の0時前後（ロールオーバー）や週明けの窓 → 気配値が薄い時間帯。仕様の範囲
   • 時間帯に関係なくランダムに頻発 → 回線・VPS・deviation設定を疑う
2. どの銘柄で出たかを確認する
   • マイナー通貨ペア・エキゾチック・CFDなど流動性の低い銘柄に偏っていれば、銘柄側の気配値の薄さが原因
3. 手動発注では出るかを試す
   • 手動のクイック注文が普通に通るのにEAだけ拒否される → EAの deviation（許容スリッページ）が絞られすぎている可能性が高い

この3つで「相場のせい」「銘柄のせい」「設定・環境のせい」のどれかに当たりを付けてから、次の原因別対処に進みます。

---

原因と対処（5パターン）

① 相場急変・指標スパイク（送った価格が届く前に古くなった）

症状： 経済指標の発表時刻、要人発言、月曜早朝などに集中して 10004/10021 が出る。

原因： EAがティックを受けて価格を計算し、注文がサーバーに届くまでの数十〜数百msの間に価格が数pips動いた。送った価格はもう存在しないので、サーバーはリクオート（10004）か気配値なし（10021）を返します。エラーというより、速い相場では起きて当然の現象です。

対処：

1. 指標前後の新規エントリーを止める（ニュースフィルター）。当サイト配布EAは EconomicFilter を標準搭載
2. deviation（許容スリッページ）を現実的な値に広げる（②参照）
3. リトライロジックを入れる（後述のコード）

---

② deviation（許容スリッページ）が絞られすぎている

症状： 穏やかな相場でもポツポツ出る。手動注文は通るのにEAだけ拒否される。

原因： MqlTradeRequest.deviation は「送った価格から何ポイントまでのズレなら受け入れるか」の宣言です。ここを 0〜数ポイントに絞ると、通常のティック更新程度のズレでも拒否対象になります。**pipsではなくpoints（5桁ブローカーなら 1 pip = 10 points）**である点の勘違いも定番です。

対処：

1. deviation を 10〜30 points（= 1〜3 pips）程度から様子を見る。スキャルでなければ 20 points が無難な出発点
2. 「deviation=5 のつもりが 0.5 pips だった」のような単位の取り違えがないか確認
3. スリッページを一切許したくない戦略なら、拒否は仕様と割り切りリトライ回数だけ制御する

---

③ 執行方式の違い（リクオートは instant 執行の現象）

症状： ブローカーAでは頻発するのに、ブローカーBでは一度も見ない。

原因： リクオート（10004）は instant execution（インスタント執行） 特有の現象です。instant執行は「この価格で約定させろ」という注文なので、価格が動くとサーバーは新価格を再提示（リクオート）します。一方 market execution（マーケット執行） は「今の市場価格で約定させろ」という注文なので、リクオートは原理的に発生せず、**代わりにズレた価格でそのまま約定（スリッページ）**します。

つまり「リクオートが出ない = 優秀」ではなく、拒否されるか・滑って約定するかのトレードオフです。シンボルの執行方式はMT5の「銘柄の仕様（Specification）」の Execution 欄、またはコードでは SYMBOL_TRADE_EXEMODE で確認できます。

対処：

1. 自分の口座の執行方式を確認する（多くの海外ブローカーの標準口座はmarket執行で、リクオート自体が出ない）
2. リクオート頻発が戦略の妨げになるなら、market執行の口座タイプ・ブローカーを検討する
3. market執行でも deviation を尊重するブローカーとしないブローカーがあるため、極端な滑りが許容できない場合は約定履歴で実スリッページを検証する

---

④ 気配値が薄い・止まっている時間帯や銘柄

症状： サーバー時刻の0時前後（ロールオーバー）、週明けのオープン直後、クリスマス等の閑散期、マイナー銘柄で 10021 が出る。

原因： ロールオーバー時はスワップ処理のため一時的に気配値の配信が止まったりスプレッドが極端に開いたりします。週明けオープン直後や流動性の低い銘柄では、そもそも処理できる気配値が細い。この状態で発注すると 10021（気配値なし）になります。

対処：

1. サーバー時刻23:55〜0:05前後の新規エントリーを避ける（時間フィルター）
2. 週明けオープン直後の数分を避ける（AvoidMondayOpen 系の設定）
3. スプレッドフィルター（MaxSpread）を入れる。気配値が薄い時間はスプレッドが開くため、実質的にこの時間帯を自動回避できる

---

⑤ 回線遅延（VPSがブローカーサーバーから遠い）

症状： 時間帯・銘柄に関係なく、他の環境より明らかに頻度が高い。ping値が大きい。

原因： 注文がサーバーに届くまでの往復時間（レイテンシ）が長いほど、その間に価格が動く確率が上がります。自宅PCや、ブローカーサーバーの所在地（ロンドン・ニューヨーク等が多い）から遠いリージョンのVPSで動かしていると、10004/10021 の頻度が構造的に上がります。MT5の右下に表示される ping がひとつの目安です（数百msは明確に不利、数十ms以下が望ましい）。

対処：

1. MT5右下のping値を確認し、常時大きいならEAの実行環境を見直す
2. ブローカーサーバーに近いリージョンのVPSに移す。正直なところ、レイテンシ由来の 10004/10021 はコードでは減らせず、物理的に近づくのが唯一の対策です。選び方は EA向けVPSの選び方 にまとめています
3. スキャル系EAほどレイテンシの影響が大きい。日足・H4系のEAならこの原因の優先度は低い

---

MQL5でこのエラーを減らすコード（EA開発者向け）

方針は3つです。(1) deviation を現実的に設定する、(2) 拒否されたら最新ティックを取り直して再送する、(3) リトライするのは価格系retcodeだけに限定する。

deviation をポイント単位で適正に設定する

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
req.action    = TRADE_ACTION_DEAL;
req.symbol    = _Symbol;
req.type      = ORDER_TYPE_BUY;
req.volume    = lots;
req.deviation = 20;   // 許容スリッページ 20 points（5桁なら2.0pips）
// req.price / req.sl / req.tp / req.magic なども設定する

deviation の単位は points です。5桁（3桁）表示のブローカーでは 10 points = 1 pip。0や極端に小さい値は拒否率を不必要に上げます。

価格系retcodeだけリトライする（最新ティックで再送）

ポイントは、リトライのたびに SymbolInfoTick() で価格を取り直すこと（古い価格のまま再送しても同じ拒否が返るだけです）と、リトライ対象を 10004/10021 に限定することです。資金不足（10019）や不正リクエスト（10013）を機械的に再送しても意味がなく、ログを汚すだけです。

bool IsRetryableRetcode(uint rc)
{
   return (rc == TRADE_RETCODE_REQUOTE       // 10004
        || rc == TRADE_RETCODE_PRICE_OFF);   // 10021
}

// 最新ティックで価格を更新しながら最大3回まで再送する
bool SendWithRetry(MqlTradeRequest &req, MqlTradeResult &res, int maxTries = 3)
{
   for(int attempt = 0; attempt < maxTries; attempt++)
   {
      MqlTick tick;
      if(!SymbolInfoTick(req.symbol, tick))
      {
         Print("SymbolInfoTick failed: ", GetLastError());
         return false;
      }
      req.price = (req.type == ORDER_TYPE_BUY) ? tick.ask : tick.bid;

      if(OrderSend(req, res) && res.retcode == TRADE_RETCODE_DONE)
         return true;                          // 約定成功

      if(!IsRetryableRetcode(res.retcode))
      {
         PrintFormat("OrderSend failed (no retry): retcode=%d", res.retcode);
         return false;                         // 価格系以外はリトライしない
      }
      PrintFormat("Retry %d/%d after retcode=%d", attempt + 1, maxTries, res.retcode);
      Sleep(200 + 150 * attempt);              // 200ms→350ms→500ms と小さく待つ
   }
   Print("Order abandoned after retries (price kept moving).");
   return false;
}

Sleep() の待ち時間を段階的に伸ばしているのは、急変の瞬間に0msで連打しても同じ拒否を食らい続けるためです。逆に待ちすぎるとエントリー価格が戦略の想定から離れていくので、リトライは2〜3回で諦めるのが健全です。指値注文（TRADE_ACTION_PENDING）の場合、成功時のretcodeは TRADE_RETCODE_PLACED（10008）になる点にも注意してください。

リクオート（10004）の再提示価格を使う

10004 のとき、MqlTradeResult の bid / ask にサーバーの再提示価格が入っています。上のように最新ティックで再送すれば実用上は十分ですが、instant執行で「再提示価格が許容範囲内なら受ける」ロジックを組みたい場合は res.ask / res.bid と元の想定価格の差をpointsで比較してから再送する形になります。

そもそも発注しない時間帯を作る

コードでのリトライは対症療法です。ロールオーバー前後・指標前後・スプレッド拡大時に新規を止めるフィルターのほうが根本的に効きます。

// スプレッドフィルターの例: 開いている時間帯は新規を見送る
long spreadPts = SymbolInfoInteger(_Symbol, SYMBOL_SPREAD);
if(spreadPts > MaxSpreadPoints)
{
   // 新規エントリーを見送る（10021が出やすい薄い時間帯を自動回避できる）
   return;
}

FXEA365が配布しているEAは、このスプレッドフィルター・指標フィルター・価格系retcodeの自動リトライを標準実装しています。

---

優先度チェックリスト

優先	確認	対処
🚨 まず	指標発表・急変の瞬間に集中しているか	ニュースフィルター有効化・その時間は仕様と割り切る
🚨 まず	deviation が小さすぎないか（単位はpoints）	10〜30 pointsへ・pips/points取り違え確認
⚠️ 次	ロールオーバー・週明け・閑散銘柄に偏るか	時間フィルター＋スプレッドフィルター
⚠️ 次	執行方式がinstantか	market執行の口座も検討（滑りとのトレードオフ）
⚠️ 次	pingが大きいか（数百ms）	サーバーに近いVPSへ移す
🛠 開発	リトライが価格系retcode限定か	SymbolInfoTick で取り直し＋2〜3回で打ち切り

---

まとめ

• 10021（TRADE_RETCODE_PRICE_OFF）は「処理できる気配値がない」、10004（TRADE_RETCODE_REQUOTE）は「新価格の再提示」。MT4時代の 136/138 と同じ価格拒否ファミリーで、資金やロットの問題ではない。
• 原因は 急変相場・deviation過小・instant執行・薄い気配値の時間帯/銘柄・回線遅延 の5つに集約される。
• リクオートはinstant執行特有の現象で、market執行では代わりにスリッページとして現れる。「出ない = 良い」ではなくトレードオフ。
• EA開発者は 最新ティックで取り直す2〜3回のリトライ（10004/10021限定）＋ deviation の適正化 ＋ 時間/スプレッドフィルターで恒久対策する。レイテンシ由来の分だけは物理対策（ブローカーに近いVPS）でしか減らない。

エラーコード全般は MQL5 / MT5 エラーコード対処法の総合ガイド を、これらの対策を標準実装した無料EAは EA一覧 を参照してください。

---

FAQ

Q: 10004 と 10021 はどちらが深刻ですか？

どちらも一時的な価格系エラーで、深刻度に大差はありません。10004 は「新価格を再提示された」、10021 は「処理できる気配値がなかった」という返事の違いです。単発なら放置で問題なく、特定の時間帯や銘柄で頻発する場合だけ原因（指標・ロールオーバー・deviation・回線）を潰してください。

Q: リクオートが一度も出ないブローカーは優秀なのですか？

執行方式の違いである可能性が高いです。market執行の口座ではリクオートは原理的に発生せず、価格が動いた場合は**ズレた価格でそのまま約定（スリッページ）**します。拒否されるか滑るかのトレードオフなので、約定履歴で実際のスリッページを確認して判断してください。

Q: MT4のEAで error 136 / 138 が出ます。同じ対処でいいですか？

はい。136（ERR_OFF_QUOTES）は10021、138（ERR_REQUOTE）は10004に相当し、原因も対策も共通です。MQL4では再送前に RefreshRates() を呼んで Bid / Ask を最新化するのが定石で、MQL5の SymbolInfoTick() での取り直しと同じ発想です。

Q: バックテストでは出ないのに本番で出ます。

正常です。Strategy Testerには「注文がサーバーに届くまでの遅延」と「その間の価格変動」が存在しない（あるいは単純化されている）ため、10004/10021 はフォワードでのみ顕在化します。バックテストが良くても、本番ではdeviation設定・リトライ・実行環境（VPS）の整備が別途必要です。