執行（Execution）問題はどのように検証できますか？
「執行（execution problems）」を定義し、何を検証できるか
執行（Execution）問題とは、注文を出した結果が、提供者（プロバイダー）が適用すると述べている執行挙動と一致しない状況、または実際の注文処理により、予期しない遅延、拒否、部分約定、あるいは価格／配分（distribution）の結果が、主張されたプロセスと整合しないことが示される状況です。検証とは、観測可能な事実（タイムスタンプ、注文ステータスの変化、約定の詳細、メッセージログ）を挙げ、それを提供者の公開ドキュメントに記載されたルールと比較できることを意味します。
固定的な仕組みと変動する条件を分ける
執行の問題を正確に検証するには、構造として固定のものと、変わるものを分けます：
- 固定的な仕組み： 注文ライフサイクルの各ステップ（送信 → 承認 → ルーティング／キュー → 執行／約定 → 完了または取消）、および「市場（market）」と「指値（limit）」の意図がどのように解釈されるか。
- 変動する条件： 流動性の厚み、ボラティリティ、取引コスト（手数料／スプレッド／コミッション）、および外部の市場全体の出来事。
検証における重大なリスクは、「不一致＝問題」と決めつけてしまうことです。執行プロセスが説明どおりに機能していても、市場の動きによって、注文の送信から執行までの間に約定が変わることがあります。
再現できるエビデンス（証拠）チェックリストを作る
自己完結型の検証プロセスは、通常、次の3つの「文書とデータ」カテゴリを組み合わせます：
- イベントの証拠（何が起きたか）： 対象の注文について、ブローカー／プラットフォームのエクスポートデータを収集します。注文ID、各ステータス変更のタイムスタンプ、利用可能であればリクエスト／確認メッセージ、そして約定（fill）の全リスト（価格、数量、時間）です。提供者が集計結果のみを公開している場合は、その制約を記録します。
- ポリシーの証拠（何が起きるべきか）： 提供者の、執行および注文処理を説明する最新のドキュメントを使います（例：注文タイプ、執行会場またはルーティングの説明、ディーリングルール、見積（クオート）がどのように形成されるか）。調査している期間に一致するドキュメントの版を使用してください。
- 制約の証拠（なぜ結果が異なり得るか）： あなたが分析する例の前提を記録します。利用可能な流動性に対する取引サイズ、使用した概算コストモデル、そして参照価格として扱うもの（例：特定のタイムスタンプにおけるクオート）です。これらの前提は明示的に述べてください。
実務上の「計算例」は、ライブ価格がなくても有効な場合があります。たとえば、部分約定の連続を観測した場合、各瞬間の正確な市場価格が不明であっても、部分執行に関する文書化された注文処理と、約定の集計が整合しているかを検証できます。
制約（limitations）と失敗パターン（failure modes）を特定する
執行の検証には、少なくとも1つの重大な制約がよくあります：
- 正当な乖離： 市場が確認よりも速く動くため、または注文タイプが流動性と相互作用するために、執行結果は参照価格と異なることがあります。
- 観測の不完全さ： 一部のプラットフォームは、エンドツーエンドのメッセージログを完全には提供しないため、遅延がどこで発生したのかを正確に証明できません。
- 参照点の曖昧さ： 「あなたが見た価格」は、マッチングに使われた価格ではない可能性があります。特に、クオートが更新される場合や、変換／コスト要素が適用される場合です。
これらの制約により、検証は、観測された事実が文書化されたルールに矛盾するかどうかを判断することを目的とし、意図を推測したり将来のパフォーマンスを予測したりすることではありません。
明確な結論としての検証（そして次の質問）
堅牢な結論は、次のいずれかの形になります：
- 不一致の結論： 観測されたイベントのタイムライン、または取り扱い挙動が、その注文タイプに対する提供者の文書化された注文／執行ルールと矛盾している。
- 結論不能（inconclusive）： 観測データが、関連する文書化ルールと比較するには不十分である、または変動する条件が結果を支配している。
次に尋ねるべき質問： 「どのドキュメントのどのセクションが、注文タイプと観測されたステップ（承認、ルーティング、約定、取消）を規定しているのか。そして、そのステップとして記載された内容と、タイムスタンプおよび約定の詳細は一致しているのか？」