FXデモ口座ブローカーにおける約定品質の評価

デモ文脈で「約定品質」を定義する

約定品質とは、注文の実際の結果が、トレーダーがその注文条件と市場の現実から期待する内容にどれだけ近いかを表します。デモ口座では、「約定（execution）」はしばしばエミュレーションです。いくつかのメカニクス（注文のマッチング、気配値、レイテンシのシミュレーション）を再現することはあっても、必ずしも実取引と同じ配管（仕組み）を再現するとは限りません。したがって、「どのブローカーが最良か」を当てることが目的ではなく、デモで測定可能で再現可能な約定特性を評価することが目的です。

有用な切り分けは次のとおりです：

• 注文処理メカニクス（プラットフォームが成行注文、指値注文、部分約定、時間有効期限（time-in-force）をどう扱うか）
• 約定価格の形成（提示された価格が約定にどう変換されるか）
• コストと制約のモデリング（スプレッド、手数料、マージン規則、ならびに注文受理に影響するあらゆる制限）

測定できるものから始める：具体的な約定要因

まずは、リアルタイムの市場データを必要とせず、ログ（または再現可能なテストハーネス）から測定できる要因から着手します。

1. 注文タイプの忠実度 管理されたシナリオで、成行と指値の両方をテストします。

• 成行注文では、期待される挙動を「約定は、直近で利用可能な気配値の近くで発生する」と定義し、そのズレを記録します。
• 指値注文では、期待される挙動を「約定は、モデル化された価格が指値を越える（または越えたものとして扱われる）ときにのみ発生する」と定義します。

2. 明示された前提のもとでのスリッページ挙動 スリッページは、参照価格と約定した価格の差です。デモでは、参照を明確に述べる必要があります（たとえば、「注文が受理された瞬間にプラットフォームが表示しているミッド価格（mid price）」を、プラットフォームが記録したものとして用いる、など）。その後、次を計算します：

• 絶対スリッページ = |約定価格 − 参照価格|
• 方向付きスリッページ = 約定価格 − 参照価格

前提：参照のタイムスタンプと、プラットフォームの表示気配値が、測定方法に対して時間的に整合していること。整合を検証できない場合は、結果を市場への影響に関する「真実」として扱わず、内部整合性チェックとして扱ってください。

3. 部分約定と注文ライフサイクル 約定品質には、注文が次のように扱われるかが含まれます：

• 部分約定されるか、またシステムが約定数量をどう決めるか
• time-in-force のルールに従って、キャンセル／期限切れが正しく行われるか
• ライブモードで適用されるのと同じ理由で拒否されるか（そのルールがモデル化されている場合）

ライフサイクル全体を記録します：送信 → 受理 → 約定（場合によっては複数回に分かれる）→ クローズ／キャンセル。

エビデンスの限界：デモ結果で証明できないこと

デモの約定品質には、重大な制限と失敗パターンがあります。

• 異なる市場データモデル：デモは別のフィードを使う、またはマッチングロジックを簡略化しているかもしれません。つまり「良いデモ約定」は、ライブの約定品質を保証しません。
• 異なるレイテンシとキューイング：デモが遅延、板の厚み、キューの順番をシミュレートしない場合、スリッページ統計は実条件より良く見える可能性があります。
• コスト表現の不一致：スプレッド、手数料、手数料（fees）が簡略化されているかもしれません。約定が妥当に見えても、総コストは過小評価されることがあります。
• 1つのシナリオへの過剰適合：単一のテスト期間（1日、1セッション、1つのボラティリティ・レジーム）では、誤解を招く結論につながる可能性があります。
• 非定常なメカニクス：デモシステムは更新され得ます。先月は安定していた測定が、後に安定し続けるとは限りません。

注意すべき具体的な失敗パターン：デモが約定を「簡単に」許してしまう可能性があります（たとえば、交差が仮説に過ぎないのに、指値注文を即座に約定させる）。あるいは、現実的な注文マッチングとは独立した約定ロジックを適用しているかもしれません。いずれの場合も、あなたの指標はシミュレータのアーティファクトになり、ライブ約定の指標にはなりません。

独立して実行できる検証チェックリスト

単発の判断ではなく、制御された再現可能なチェックを使います。

1. 測定プロトコルを作成する 次を書き出します：

• 使用する注文タイプ
• 使用するサイズ
• 参照価格の定義
• タイムスタンプと約定価格をどう取得するか

2. 条件を変えて繰り返す 異なる時間帯やボラティリティ・レジーム（たとえば、落ち着いた局面と活発な局面）で、また複数の注文サイズでテストを実行します。前提：デモの挙動が十分に一貫しており、繰り返しによって変動が意味のある形で明らかになること。

3. 予測ではなく内部整合性を比較する 権威あるライブのベンチマークにアクセスできない場合、デモ指標を予測として解釈しないでください。代わりに、デモが自ら説明している注文ルール（たとえば、指値の交差ロジック）と整合しているか、そしてコストやスリッページのパターンが妥当な形で変化するかを確認するようにします。

DOCUMENT END