執行（Execution）トラブルでよくあるミス（そして中立的に確認する方法）
人々が執行トラブルについて誤解しがちな点
執行トラブルは、たいてい「市場が自分に不利に動いた」ことや、注文タイプの選択が悪かったことと混同されます。実際には、執行トラブルとは、注文を出したときにあなたが期待していた執行結果と、実際に観測される結果が一致しないことを意味します。
よくあるミスは、執行を単一の出来事として扱うことです。現実には、執行は複数のステップにまたがります。注文を送信すること、プラットフォーム／提供業者がそれを受け取ること、約定またはルーティングすること、そして最後に約定（fill）をあなたへ報告することです。どこかのステップで問題が起きれば、結果は変わり得ます。
もう一つのミスは、安定した仕組みと変動する条件を混ぜてしまうことです。市場価格の変化や流動性の変化は変動要因であり、あなたのコントロール外です。取引コスト（手数料やスプレッドなど）も、実現された結果の一部です。提供業者の挙動やシステムの性能も、追加のばらつきを生むことがあります。これらの原因を分けないと、ある要因が「すべてを引き起こした」と誤って結論づけてしまう可能性があります。
メカニクス：そもそも「執行（execution）」とは何か、どんな入力が重要か
明確に考えるために、注文を出した時点で「何を期待していたか」を定義してください。典型的な期待される入力には、次のようなものが含まれます。注文の方向と数量、注文タイプ（成行と指値）、意図したエントリー価格（指値注文やトリガー注文の場合）、そして制約（たとえば時間制限や価格制限など）。
次に、実際に得られたものと比較します。約定価格（複数の場合もあります）、全約定か部分約定か、報告された執行時刻（複数の場合もあります）、そして「rejected（拒否）」「expired（失効）」「filled（約定）」のようなステータスメッセージです。
重要な中立的ポイント：「執行トラブル」は自動的に「悪い」ものではありません。注文タイプがどう機能するかについてのあなたの前提が、現実と一致していなかったことを示している場合もあります。たとえば、市場があなたの指値に到達しない限り、指値注文は約定しないことがあります。これは期待される挙動であり、必ずしも執行の不具合を意味しません。
証拠と例：ミス、結果、確認
よくあるミスの一つは、約定しなかったことが「予想されていた非約定」であるのに、執行のせいにしてしまうことです。たとえば、（買いの場合）現在の価格より下に指値注文を出しても、市場がその水準で一度も取引しなければ、約定は起きません。その結果、システムエラーではなく「約定条件（fulfillment condition）」の問題だったのに、状況を誤って報告してしまう可能性があります。
もう一つのミスは、期待値と観測結果を比較するときにコストを無視することです。約定価格が「近い」としても、実現された収益性はスプレッド、手数料、その他の手数料によって支配されることがあります。中立的な確認では、前提を明示します。どのコストが含まれていたのか、どの正確な約定価格が使われたのか、そして比較が「同じ土俵（apples-to-apples）」になっているかどうかです。
三つ目のミスは、最終的な損益のようなデータ点を一つだけ使うことです。より良い確認は、証拠の連鎖に焦点を当てます。注文の送信時刻、途中で起きたステータスの変化、執行のタイムスタンプ、そして正確な約定価格（複数の場合もあります）。大きな差が見える場合は、複数の原因を検討してください。価格変化が速いこと、流動性が低下していること、意思決定から約定までのレイテンシー、部分約定などです。
制約とリスク：把握しておくべきこと
執行結果は、市場環境、コスト、執行方法、そして取引会場と提供業者のルールによって変わります。そのため、過去のパターンは将来の結果を確実に予測しません。
監視すべき少なくとも一つの重大な失敗パターンは、部分約定です。注文が複数の価格水準で約定することもあれば、注文が部分的にしか約定しないこともあります。これは平均約定価格を変え得るだけでなく、下流のエクスポージャーにも影響し得ます。
もう一つの失敗パターンは、制約による注文の拒否または失効です。注文が拒否された場合、「expected（期待される）」取引はそもそも存在しません。期待した利益と観測された結果を比較することは無効になります。
検証：適用できる中立的なチェックリスト
単一の原因を前提にしない中立的なチェックリストを使ってください：
- 前提を書き出す：注文タイプ、意図した価格、そしてその特定のセットアップで「expected fill（期待される約定）」が意味していたもの。
- 報告された項目で結果を確認する：ステータス（filled/rejected/expired）、約定価格（複数の場合もあります）、および執行タイムスタンプ。
- 原因を分ける：市場の値動き vs 取引コスト vs 報告されたシステム／提供業者の挙動。
- 同じ前提で（手数料を含めて）再計算し、比較が一貫していることを確認する。
- 何かが異常に見える場合は、「執行チェーンのどのステップに対応づけられるか」が分かるまで「unknown cause（原因不明）」として扱う。
DOCUMENT END