注文の執行時間：初回約定、全量完了、時計のずれを区別する

「買い」のクリックは要求であり、表示価格で取引が成立した確認ではありません。送信、検証、約定、返信を分けます。拒否や一部成立もあります。業者を比較するなら測定の始点・終点と価格基準を決め、費用、約定と失敗を一緒に調べます。

注文の執行で起きること

要求はサーバーへ届き、検証を受け、商品・執行モード・充足方針に応じて約定、一部約定、失敗となります。一注文に複数の約定と時刻が結び付く場合があります。端末への返信到着はサーバーの成立より後のイベントで、クリック時刻とも違います。

通信と処理・約定の時間を分けます。「20ms」という広告も端点、時計、標本と注文状態が必要です。遅延は各段階の合計で、遅い段階が支配することがありますが、時間だけで価格は決まりません。相場変化、利用可能数量、注文条件も関係します。

InstantとMarket Execution

MT5にはInstant、Request、Market、Exchange Executionがあります。銘柄ごとの利用可否は業者が設定します。Instantは要求価格を使い、条件によってリクオートが返る場合があります。全要求の成立保証ではありません。Marketは改めて価格交渉せず、そのモードで決まる価格を受け入れますが、検証や充足条件まで消えるわけではありません。

成行だから画面価格も全量約定も保証される、とは扱いません。流動性、方針、約款に従って滑り、拒否、一部成立の可能性を調べます。実際の約定と残数量を記録します。

時間と品質を左右する条件

執行方針から会社の役割、価格源、経路、拒否条件を確認します。ECNのラベルだけでは、CFD業者が常に代理人で要求をそのまま外部へ流すと証明できません。Last lookは調べるべき執行条件、PFOFは商品・法域別の注文経路報酬に関する論点です。どちらも契約の代わりではありません。顧客取引と業者のヘッジを混同しません。

サーバー所在地、接続とソフトが遅延の一部へ影響します。VPSは連続接続や通信区間の短縮に役立つ場合があっても、流動性や約定価格を供給・保証しません。平常・急変時とも価格と数量は変わり得ます。一つのヒゲや不利な約定だけでストップ狩りや不正な原因を断定せず、注文とBid/Askの証拠を残します。

架空EUR/USDの滑りを計算する

要求時点のAskを1.08500、100,000 EURの買い約定を1.08550とします。1pip＝0.0001、口座への通貨換算なし。この数値はNFPの実測滑りや典型的な遅延ではありません。

同じAsk基準で1.08490に買えたら1pip有利です。売りでは高い価格が有利になります。100や200pipsの値幅を計画する場合、50 USDは計画変動の小さい割合になっても無関係にはなりません。繰返す差は保有スタイルを問わず積み重なります。

表示スプレッドと執行品質を一緒に評価する

基準を決めて実際の約定価格と明示費用を比べます。実際のAsk/Bidの入口・出口で計算した損益には、スプレッドとその約定の滑りが既に反映されています。もう一度引きません。別の費用分解としてスプレッド、手数料、価格乖離を比べる場合も重複を避けます。保有金利や換算は別途加わり得ます。スプレッドと手数料も同じ基準で確認します。

EUのMiFID II第27条は価格、費用、速度、執行・決済可能性などを考慮し、個人顧客では価格と直接の執行費用を含む総合的な対価を示します。要素が自動的に同じ重みという意味ではありません。顧客の特定指示は対象部分に影響します。最良執行は体制・過程の義務で、全約定の絶対的最安値保証とは扱いません。これは外国制度の比較です。日本では契約法人、登録と商品範囲を確認し、外国免許を国内の許可と同一視しません。

デモと実口座の違いを具体的に確認する

デモの執行仕様は業者次第です。例えばIGの英国ヘルプは、デモで滑りや特定の価格・数量による拒否、一部の金利・強制決済が反映されないことを示しています。操作の練習にはなっても実口座の執行品質の実測ではありません。これは英国資料の範囲で、日本口座全ての仕様ではありません。

ライブの店頭CFDに公開取引所の板が必ず見えるとは限らず、「デモより少し悪い」と定量化もできません。使うシミュレーターとライブの規則を読み分けます。

初回約定では注文が完了していない

架空の1ロット注文を、同じ始点・時計で50msに0.5、80msに0.3、900msに0.2ずつ成立させます。リクオートも残数量取消もない仮定です。

数量加重平均は0.5×50＋0.3×80＋0.2×900＝229msですが、229msに全量が終わったわけではありません。初回、平均、完了は別の問いへの答えです。MT5は一注文に複数dealを紐づける場合を説明しています。同じ注文番号で全約定を保存します。

自分の執行を測る方法

要求、状態、注文ID、全約定、数量、該当Bid/Askを保存します。各時刻のイベント、時計、タイムゾーン、精度を記録します。端末ログはサーバーの成立ではなくメッセージ到着を記録している場合があります。違う時計の数値をそのまま引きません。JSTとUTCへ表示をそろえることと、二台の時計の時刻ずれを直すことも別です。

追加例：同じ表示時刻でも0msとは限らない

架空の端末時計で送信1000ms、返信1090ms。サーバー時計の受信は960ms、約定1000msとします。サーバー時計が端末基準より60ms遅れていると別途分かっている場合、共通基準で受信1020ms、約定1060msです。送信から受信20ms、処理40ms、返信到着まで30ms、合計90ms。送信→約定は60msです。

サーバー約定1000−端末送信1000＝0msと引くのは誤りです。時刻差60msを推定できる証拠がなければ送信→サーバー約定の60msは算出できませんが、同じ端末時計の要求→返信90msは別の測定として残せます。この例の時計差は仮定で、特定業者の仕様や通信実測ではありません。

銘柄、数量、時間帯など同条件を比べ、失敗も全要求の母集団に含めます。中央値だけでなく拒否率と遅い裾も示します。数十件だけで普遍的な品質を確定しません。契約法人の確認と現行方針を使い、具体的な不一致の説明を求めます。日本の税区分も名称でなく取引内容と相手方により確認する別の論点であり、速度比較に一律の税率を混ぜません。

確認を実行へつなげる

1. 初回、全量、返信を分け、同条件、時計、拒否率、遅い例と中央値を報告する。
2. 売買方向、価格基準、注文種類を決め、有利・不利の差を比較する。偏りは説明を求める材料で、単独で操作の証明ではない。
3. 銘柄別のモードと充足条件を確認する。ストップは価格保証ではなく、指値は価格を制限しても未成立になり得る。
4. 実際の約定と費用を一度だけ照合し、金利・換算を加える。実約定損益から滑りとスプレッドを二重に引かない。
5. 日本の登録と対象商品を確認する。個人店頭FXの最大25倍の枠も約定品質や損失額の保証ではありません。