約定拒否やリクオートは、損益表に書かない代わりに別の台帳に回数として残すのが扱いやすい設計です。理由は単純で、通らなかった注文には確定した損益が存在せず、無理に損益へ混ぜると実績の数字が検証不能になるからです。代わりに「発注試行」を分母にした拒否率と、仮定約定による影の損益を別勘定で持つ。この記事では、その記録項目・集計の型・そしてこの記録が役に立たない条件までをまとめます。
約定拒否とリクオートは何が違う？
まず言葉を揃えます。実務上は次の三つを分けて扱うと混乱が減ります。
- リクオート（Requote）：発注した価格では約定できず、業者側が新しい価格を提示して承諾を求めてくる状態。トレーダーが承諾すれば約定し、拒否すれば不成立になります。
- 約定拒否（Reject）：提示の打診なしに注文そのものが差し戻される状態。価格条件、数量、証拠金、取引可能時間など原因はさまざまです。
- スリッページ：約定はしたが、発注時に見えていた価格と約定価格がずれた状態。これは「通った取引」なので損益表に入ります。
スリッページは約定済みなので通常の成績に含め、リクオートと拒否は不成立なので別台帳、というのが切り分けの基本線です。約定したずれの測り方は約定ずれを測る記録項目と集計の型で扱っているので、本稿は「そもそも通らなかった側」に絞ります。
プラットフォーム側にも識別の手がかりがあります。たとえばMetaTrader 4のエラーコード一覧にはRequote、Off quotes、Price changedといった区分が定義されており、MetaTrader 5のトレードサーバーのリターンコードにもTRADE_RETCODE_REQUOTE、TRADE_RETCODE_REJECT、TRADE_RETCODE_PRICE_CHANGEDなどが用意されています。番号や名称の細部は使用環境の公式リファレンスで確認してください。ここで重要なのは、コードが分かれているということは、原因も分けて記録できるということです。
損益に混ぜてよいのか？──別勘定にする理由
「取れたはずの利益」を損益に足したくなる気持ちは分かりますが、足すと三つの問題が出ます。
- 検証不能になる：仮定約定の価格は自分で決めた数字なので、後から誰も再現できません。実績と推定が同じ列に並ぶと、口座残高との突き合わせもできなくなります。
- 都合のよい仮定が混入する：通らなかった注文は、たいてい値が走っている瞬間に発生します。「発注時の表示価格で約定していたら」と仮定すると、勝ち側に偏りやすい。
- 改善の打ち手が見えなくなる：拒否は手法の問題ではなく、執行環境または発注設定の問題です。損益に溶かすと、どちらを直すべきか分からなくなります。
口座の実績値と推定値を分ける発想は、入出金やスワップの扱いと同じです。実額で追う列と、分析用の推定列を物理的に別シートに置く考え方は本当の成績を出す、入出金記録の設計と揃えておくと、後から集計式を書くときに楽になります。
何を記録する？──最小6項目
続けられることが最優先なので、項目は絞ります。次の表は筆者が最小構成として考えている型です。実績ではなく設計案として読んでください。
| 項目 | 内容 | 意図 |
|---|---|---|
| 発注時刻（秒まで） | サーバー時刻またはPC時刻のどちらかに統一 | 時間帯別・イベント別に切るため |
| 銘柄・数量・注文種別 | 通貨ペア、ロット、成行／指値／逆指値、決済か新規か | 成行と指値では拒否の意味が違う |
| 結果区分 | リクオート承諾／リクオート拒否／約定拒否／自己都合の取り消し | 業者側要因と自分側要因を分ける |
| エラー内容 | プラットフォームが返したコードまたは文言をそのまま | 後から原因を再分類できる |
| 発注時の提示価格と、その直後の価格 | 発注意図価格と、5〜10秒後などあらかじめ決めた時点の価格 | 影の損益を一定の規則で出すため |
| 再発注の有無と結果 | 再発注したか、何秒後か、いくらで約定したか | 「拒否の実コスト」はここに出る |
「発注時の提示価格と直後の価格」は、計測時点を先に決めておくことが肝心です。都度その場で有利な時点を選ぶと、数字が意味を失います。5秒後なら全件5秒後、と固定します。
集計はどう設計する？
集めたら、次の三つの見方で回すと使えます。
1. 試行ベースの拒否率
分母を「約定件数」ではなく「発注試行件数」にします。拒否率＝（リクオート件数＋拒否件数）÷発注試行件数。約定件数を分母にすると、拒否が増えるほど分母が小さくなり、率が過大に出ます。
そのうえで、時間帯（早朝の流動性が薄い時間、指標発表前後、ロールオーバー付近）、銘柄、注文種別で層別します。全体の率を1つ出しても打ち手にならず、「特定の条件でだけ起きている」かどうかが分かって初めて設定変更の判断材料になります。
2. 再発注コスト
拒否されて再発注した取引について、最初の発注意図価格と、実際に約定した価格の差を集計します。これは推定ではなく実測なので、信頼度が高い数字です。ここが恒常的に不利方向へ偏るなら、許容スリッページ幅の設定、注文方式、発注タイミングのいずれかを見直す候補になります。
3. 影の損益（別勘定）
不成立に終わった注文について、「あらかじめ決めた規則で約定したと仮定した場合の結果」を別シートに置きます。たとえば次のような場面です。発注から5秒後の提示価格で約定したと仮定し、実際のルール通りの損切り・利確で決済した場合の損益を機械的に計算する。これを実績の損益表には絶対に足さないまま、月次で「影の損益の合計」として並べて眺めます。
見たいのは金額そのものではなく、符号の偏りと分散です。影の損益がプラスに偏り続けるなら執行環境が足を引っ張っている可能性があり、符号がばらついているなら拒否は単なるノイズで、気にするコストの方が大きいかもしれません。
この記録が機能しない相場条件・使い方
以下の条件では、この記録から結論を出すべきではありません。
- 件数が足りない：拒否は通常まれな事象です。月に数件では時間帯別に割った瞬間に各セルが1〜2件になり、偏りか偶然かを区別できません。層別するなら、まず全体の件数が十分に溜まるまで待つ。
- 原因が混ざっている：証拠金不足、最小ロット違反、ストップレベル（現在価格から一定距離以内に逆指値を置けない制約）違反は自分側の問題です。これを業者側要因と同じ列に積むと、率が意味を失います。結果区分を分ける理由はここにあります。
- 仮定約定が非現実的な場面：拒否が出る瞬間は、たいていスプレッドが開き、板が薄い瞬間です。「見えていた価格で約定できたはず」という仮定自体が成り立たないことが多く、影の損益は上振れしやすい。あくまで方向性を見る参考値にとどめます。
- ログが残らない発注：スマホアプリでは、拒否のメッセージが数秒で消えて記録を取り損ねることがあります。取り逃しが系統的に発生すると、拒否率は実態より低く出ます。入力の崩れ方についてはスマホ取引で崩れる判断と、潰す手順の考え方が参考になります。
- 業者間の比較に流用する：同じ時刻に同じ条件で並行発注していない限り、自分の記録は他社との比較には使えません。相場状況が違えば拒否率は簡単に変わります。
なお、国内の店頭外国為替証拠金取引の執行に関しては、金融庁の「金融商品取引業者等向けの総合的な監督指針」や一般社団法人金融先物取引業協会の自主規制規則など、参照できる枠組みがあります。自分の記録に不自然な偏りが見えたときは、まず利用している口座の取引約款と注文執行に関する説明資料を読み直すのが先で、記録だけで何かを断定することはできません。
まとめ
通らなかった注文の扱いは、次の三つに整理できます。
- 損益には混ぜない。実績列と推定列を物理的に分ける
- 回数と条件を残す。分母は発注試行件数、結果区分で自分側要因と環境要因を分離する
- 仮定の規則を先に固定する。影の損益は「何秒後の価格か」を全件共通にして初めて比較可能になる
この記録の目的は、業者を責める材料を集めることでも、取れなかった利益を数えて悔しがることでもありません。自分の手法が、自分の執行環境で成立しているかどうかを確かめるためのものです。拒否率が低く影の損益にも偏りがないなら、この台帳は「問題がない」という確認だけして閉じてよい。逆に特定条件に集中しているなら、手法のロジックではなく発注設定や取引時間帯の方を動かす判断材料になります。
最後に注意点です。ここで示した項目や集計方法は、検証の枠組みの一例であり、特定の判断や取引を推奨するものではありません。記録から得られる数字は過去の観測にすぎず、将来の執行品質や損益を保証しません。証拠金取引は損失が預託額を超える可能性があり、最終的な判断と結果はご自身の責任になります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
この記事は情報の提供を目的としたもので、特定の金融商品の売買をすすめるものではありません。売買の判断は、ご自身の責任で行ってください。（運営者情報）
