リクオートとは？Instant/Requestの仕組み・起こる場面・EAでの対処と防止策【MT4/MT5】

リクオートとは――その1クリックが“別の価格”に変わる瞬間

「今だ！」と成行注文を送ったのに、約定せず“新しい価格で取引しますか？”と再提示（リクオート）が出る――これがリクオートです。リクオートが発生するかどうかは口座や銘柄の注文執行方式によります。多くはInstant/Request Execution（画面価格で約定する前提）で起こり、サーバ処理の間に価格が動いて元の価格で約定できなくなったときに、新しい価格が提示されます。
対してMarket Executionの場合は原則リクオートなし。提示確認を挟まず、その時点で約定可能な価格に“滑って”執行されます（＝スリッページ）。

自分の口座がInstant/Requestか、MarketかをMT5で確認する

① シンボル仕様を確認する（稼働口座の実行方式）

1. MT5で気配値表示（Market Watch）→ 通貨ペアを右クリック → Specification（仕様）。
2. 中央の表でExecution欄を確認。例：Market / Instant / Request / Exchange。
3. Marketなら、原則リクオートは起きません（滑って約定）。Instant/Requestはリクオートの可能性があります。

注意：同じブローカーでも口座タイプや銘柄によって実行方式が異なることがあります。必ず実際に取引する銘柄で確認してください。

② ストラテジーテスターで「実行方式」を切り替えて挙動を検証

• テスター画面右上の「$」アイコン（シンボル設定）→ Executionで Request/Instant/Market を切替。
• 同じEA・同じ期間で比較すると、Instant/Requestではリクオートや拒否が出やすく、Marketでは滑りが発生しやすい傾向が確認できます。

③ バックテストのログで「Requote」を確認

EAの自動売買でリクオートが起こったとき、どうなる？

• ポップアップは出ません。サーバからエラーとして返るだけで、ポジションは開きません。
• 代表的なコード：MT4: ERR_REQUOTE (138)、MT5: TRADE_RETCODE_REQUOTE (10004)。
• MT5では応答構造体（MqlTradeResult）に再提示価格（Bid/Ask）が入るため、EA側で新価格を取得して再送できます。

なぜ起きる？（Instant/Requestの特性）

• 要求価格が古い：送信〜処理の間に価格が動き、画面価格で約定できない。
• 許容乖離（Deviation/Slippage）の設定が厳しすぎる：Instant/Requestではこの許容が効くため、小さすぎると弾かれる。
• 市場条件：高ボラ・薄商い・大口・回線遅延が重なると再提示が起きやすい。

EAの正しい対処フロー（雛形）

1. 最新レート取得 → 再送：MT4はRefreshRates()、MT5はSymbolInfoTick()。
2. Deviation/Slippageを現実的に：戦略の時間軸とボラに合わせ、過小設定を避ける。
3. 短い待機＋再試行（回数上限）：ERR_REQUOTE / TRADE_RETCODE_REQUOTEなどの一過性エラーに限定。
4. 口座選定：スキャル系はMarket/ECN/STPで滑り許容の方が一貫性を得やすい場合が多い。

int TryBuy(double lots,int maxTry=3,int slippage=10){ for(int i=0;i<maxTry;i++){ RefreshRates(); int tk=OrderSend(Symbol(),OP_BUY,lots,Ask,slippage,0,0,"EA",0,0); if(tk>0) return tk; int err=GetLastError(); if(err==ERR_REQUOTE || err==ERR_PRICE_CHANGED || err==ERR_OFF_QUOTES){ Sleep(200+100*i); // 短いバックオフ continue; } return -1; } return -1; }

#include <Trade/Trade.mqh> CTrade trade;

bool TryBuy(double lots,int maxTry=3,int devPts=10){
trade.SetDeviationInPoints(devPts);
for(int i=0;i<maxTry;i++){
MqlTick t; SymbolInfoTick(_Symbol,t);
if(trade.Buy(lots,_Symbol,t.ask,0,0)) return true;
uint rc=trade.ResultRetcode();
if(rc==TRADE_RETCODE_REQUOTE || rc==TRADE_RETCODE_REJECT){
Sleep(200+100*i);
continue;
}
return false;
}
return false;
}

どのような場面で起こる？

• 高ボラティリティ時：重要指標・要人発言・ニュース直後のギャップや連続気配。
• 薄商い・流動性不足：板が薄く、希望価格では埋まらない。
• 大口発注：一撃のロットが大きいほど、再提示・部分約定・拒否のリスク。
• 回線やレイテンシ：遠隔・不安定な回線は注文到達の遅れを招く。
• 口座/銘柄仕様：Instant/Requestの採用やフリーズレベル・最小距離の制約。

リクオートが取引に与える影響

• 機会損失：押し目・戻りの最良価格を逃し期待値が低下。
• 約定遅延：再提示の承諾待ちの間に相場が進む。
• 心理負荷：連発するとルール逸脱・クリック連打・ロット肥大化を招きがち。
• EA/スキャルの致命傷：数pipsの世界ではリトライ遅延や不成立が痛い。(関連記事：スキャルピングEAの落とし穴）

例： 1.10000で買う想定が、リクオートで1.10050提示。10ロットなら0.5pips差でもP/Lへの影響は無視できません。

スリッページとの違い

リクオートを防ぐ（減らす）実践策

① 口座・方式の見直し

• Market/ECN/STP口座を選択（構造的にリクオートなし）。
• ブローカーの約定率・平均スリッページの開示値を確認。

② 発注設計のチューニング

• ロット分割：一発大口より複数回に分ける。
• 高ボラ直撃の回避：重要指標の前後・ロールオーバー帯は抑制。
• 指値/逆指値の特性理解：サーバ登録の保留注文はリクオートにならないが、Stop系は滑りやすい、Limit系は有利側のみが原則（未充足なら不成立）。

関連記事：EA注文タイプとリスク比較｜成行・ストップ・SL/TPとVPS停止時の安全性

③ レイテンシと安定性

• サーバ近接VPSで往復遅延を短縮。
• 有線接続・冗長回線で通信の安定性を確保。

関連記事：レイテンシを下げるVPSロケーション選び｜EquinixとNY4/LD4/TY3の基礎・ストップ型EAの影響

④ プラットフォーム/EA設定

• Max Deviation（許容乖離）を現実的に。小さすぎるとInstant/Requestで弾かれやすい。
• EAに再試行ロジック・ログ記録・フォールバック（未約定時の代替手順）を実装。

すぐ使えるチェックリスト

• □ 稼働銘柄のExecutionは何か（図1で確認）。
• □ Instantタイプの口座を使う場合、テスターでExecution切替＆ログ検証をしたか（図2・図3）。
• □ Deviation/Slippageが戦略の時間軸とボラに合っているか。
• □ ロット分割・指標回避・近接VPSなどの運用面を整えているか。
• □ EAにリクオート対策の定型フロー（最新レート→再送→上限回数→ログ）があるか。

よくある誤解

• 「リクオート＝不正」ではない。 Instant/Requestの仕組みと市場状況の結果。ただし頻発するなら口座や運用の見直しサイン。
• 「Market＝常に有利」でもない。 リクオートは避けられるが、滑りは増える。総合P/Lで評価を。

まとめ――“弾かれない設計”でEAの実力を引き出す

リクオートはInstant/Requestの宿命的現象。だからこそ、（1）実行方式の把握、（2）Deviation/Slippageの現実設定、（3）再試行ロジックとロット設計、（4）低遅延で安定した環境――この4点を整えるだけで、あなたの損益曲線は“弾かれない未来”へ近づきます。今日から図1〜図3の手順で、あなたの口座とEAを見直してみてください。

FAQ（初心者向け）