リクオート・約定拒否とは — 注文が通らない仕組みと発生原因の整理

FXやCFDの取引を続けていると、「発注したのに約定しなかった」「別の価格を提示された」という経験をすることがあります。これがいわゆる リクオート(Requote) や 約定拒否(Order Rejection) と呼ばれる現象です。仕組みを理解しないまま遭遇すると、単なる不具合やトラブルのように感じてしまいがちですが、実際にはブローカーの約定方式や市場の流動性状況に根ざした、構造的に起こりうる現象だと考えられます。本記事では、リクオートと約定拒否の定義、発生原因、ブローカー方式による違い、cBotで扱う際の注意点までをフラットに整理します。

リクオートと約定拒否は「不利な約定」ではなく「そもそも約定が成立しない、または別条件を再提示される」現象だという点を最初に押さえておくと、後の話が追いやすくなります。

リクオートとは何か

リクオート(Requote)は、トレーダーが発注した価格でその時点の相場が存在せず、ブローカー側から 別の価格が再提示される 現象です。旧来のディーリングデスク方式(DD方式)や、一部のマーケットメイカー型口座で見られる仕組みで、トレーダーは提示された新しい価格を「承諾する」か「拒否する」かを選ぶ形になります。

たとえばUSDJPYで150.000での買い注文を出した直後に、ブローカーのシステム内で150.003という価格が提示され、トレーダーがそれを受け入れるかどうかを判断する、といった流れです。承諾すれば新しい価格で約定し、拒否すれば注文自体が成立しません。

約定拒否とは何か

約定拒否(Order Rejection)は、発注そのものが システム側で受け付けられない 現象です。リクオートのように代替価格が提示されるのではなく、注文がそのまま不成立に終わります。

NDD方式(No Dealing Desk)やSTP方式(Straight Through Processing)を採用するブローカーでは、注文が流動性提供業者(LP)に直接転送される仕組みが一般的です。この場合、リクオートという概念自体が存在しないことが多い一方で、LP側で提示価格の有効期限が切れていたり、必要な流動性が確保できなかったりすると、約定拒否という形で結果が返ってくることがあります。

つまり、リクオートはDD方式に多い現象、約定拒否はNDD/STP方式でも起こりうる現象 と整理できます。ブローカーの約定方式によって、遭遇しやすい現象の種類が変わる点は覚えておくとよいでしょう。

リクオート・約定拒否が起きやすい主な状況

いくつかの典型的な状況で、発生頻度が高くなりやすい傾向があります。

ひとつは 重要経済指標の発表前後 です。米雇用統計(NFP)、FOMC、各国CPI、日銀会合などのタイミングでは、価格が瞬時に大きく動くため、提示価格の有効期限がすぐに切れやすく、リクオートや約定拒否が増える傾向があります。

もうひとつは 流動性が薄い時間帯 です。日本時間早朝や、主要市場の取引時間外で板が薄い局面では、LP側で十分な流動性を確保できず、約定拒否が発生しやすくなります。

そのほか、急騰急落で価格が走っている荒い相場 や、サーバー負荷が高いタイミング(複数の重要指標が重なる時間帯など) でも、通常より発生率が上がりやすいと考えられます。

よくある誤解

誤解1: 「リクオートは常にブローカーが不利な価格を提示してくる」

実際には、リクオートで提示される価格が発注価格より有利になるケースもあります。ただし、価格が大きく動く局面では不利な方向に振れる頻度が相対的に高くなりやすいため、「一方向に偏る」と決めつけるのではなく「非対称に不利側へ偏りやすい場面がある」という前提で捉えておくのが実情に近いと考えられます。

誤解2: 「NDD/STP方式ならリクオート・約定拒否は起きない」

NDD/STP方式ではリクオートという概念自体が存在しないブローカーが多いものの、約定拒否がゼロになるわけではありません。LP側の流動性状況やシステム負荷によっては、NDD/STP方式でも約定拒否は発生しうる点に注意が必要です。方式の違いは「起きやすさの傾向」であって、「発生しない保証」ではないと整理しておくと誤解を避けやすくなります。

取引コストや約定プロセス全般については、別記事「スリッページとは — 約定価格のズレが生じる仕組みとリスク管理の基礎」もあわせて参考になります。

実装上の注意点

cBotやインジケーターで自動売買を組む場合、リクオート・約定拒否への対応をあらかじめ設計に組み込んでおくことが重要です。

ひとつは 約定結果の確認処理 です。cTrader APIでは発注後に約定結果(成功・拒否・エラーコードなど)が返ってきます。この結果を毎回チェックし、拒否された場合の再発注ロジックやログ記録を用意しておくと、「注文を出したつもりが実は成立していなかった」という事故を防ぎやすくなります。

もうひとつは 再発注時の条件見直し です。約定拒否が発生した直後にそのまま同条件で即座に再発注すると、同じ理由で再度拒否される可能性があります。価格の再取得や、許容スリッページ幅の調整を挟んでから再発注する設計にしておくと、無駄なリトライを減らしやすくなります。

最後に、拒否イベントのログ化 を推奨します。発生日時、銘柄、注文条件、拒否理由(取得できる場合)を記録しておくと、指標発表時間帯や特定の時間帯に集中していないかを後から検証できます。ブローカー選定や運用ルールの見直しの根拠資料としても活用できる情報です。

まとめ

リクオートと約定拒否は、発注した価格や条件で取引が成立しない現象であり、ブローカーの約定方式(DD/NDD/STP)や市場の流動性状況によって発生しやすさが変わります。リクオートはDD方式に多い「代替価格の再提示」、約定拒否は方式を問わず起こりうる「注文そのものの不成立」という違いを押さえておくと、現象を正しく切り分けやすくなります。

実運用では、約定結果の確認処理・再発注時の条件見直し・拒否イベントのログ化、という3点を最低ラインとして組み込んでおくと安心です。cBotへの具体的な実装手法や約定処理の設計については、ai-programming.xyz のスクール教材や、本ブログの記事一覧でも順次取り上げていきます。

本記事は一般的な情報提供を目的としています。投資助言ではありません。 取引判断はご自身の責任で行ってください。