未約定注文の有効期限はどのように測定できますか？

直接の回答

未約定注文の有効期限は、(1) 注文の作成タイムスタンプ、(2) 注文が執行可能になるタイムスタンプ、(3) 設定された有効期限ルールとその目標時刻、そして(4) プラットフォームが注文を「期限切れ」または「キャンセル」としてマークしたタイムスタンプ（およびステータス）を記録することで測定できます。正確に測定するには、「開始時刻」として扱うもの、「有効期限時刻」として扱うもの、さらに「有効期限の前後で約定した（filled around expiry）」や「再接続後に期限切れになった（expired after reconnect）」のような曖昧なケースをどう扱うかを定義してください。

仕組みと定義

「未約定注文」とは、注文が即時に執行されないものであり、市場の条件がそのトリガー（たとえば、価格がある水準に到達すること）に一致するまで待ちます。「有効期限（Expiry）」とは、未約定注文が一定の時点を超えてアクティブのまま残ることを止める終端ルールです。

未約定注文の有効期限を測定するには、口語的な表現ではなく、測定可能な項目を使います。計算の基礎にできる一般的な項目は次のとおりです。

1. 開始タイムスタンプ：カウントダウンを開始すると考える瞬間です。これは多くの場合、注文作成時刻ですが、「created（作成）」「accepted（受理）」「became active（有効化）」を分けるシステムもあります。

2. 有効期限の設定：注文がアクティブであることをやめる時点を決めるルールです（たとえば、固定の終了時刻、または発注からの所要時間）。2つの注文がどちらも「expire（期限切れ）」になり得る一方で、期限切れの時刻が異なるため、この設定が必要です。

3. 目標の有効期限タイムスタンプ：設定から導かれる終了時刻です（たとえば、発注時刻 + 所要時間、または指定された時計時刻）。これは計画上の値であり、計算できます。

4. 観測された結果：実際に何が起きたかを示す、プラットフォーム報告のタイムスタンプとステータスです（たとえば、ステータスが「expired（期限切れ）」「cancelled（キャンセル）」「filled（約定）」になる）。これは測定された値です。

実用的な測定は、終端ステータスの観測タイムスタンプと目標の有効期限タイムスタンプの差、または観測された終端タイムスタンプと開始タイムスタンプの差です。両方の値で同じ時間基準を使ってください。

証拠または例

例としての測定アプローチ（前提を明示）：

• すべてのタイムスタンプが同じタイムゾーンで報告されていると仮定する、またはそれらを一つのタイムゾーンに一貫して変換する。
• プラットフォームが「expired（期限切れ）」ステータスのタイムスタンプを含む注文履歴エントリを提供していると仮定する。

測定手順：

1. 注文作成タイムスタンプ（開始）を取得します。これを T_start と呼びます。

2. 有効期限の設定を取得し、それから目標の有効期限タイムスタンプを導きます。これを T_target と呼びます。

3. 有効期限に対応する終端イベントを特定します。有効期限のプラットフォーム時刻を T_observed とし、終端ステータスを記録します。

4. 次の2つの値を計算します：

• 予定された所要時間：Δ_planned = T_target − T_start
• 実現した有効期限の遅れ：Δ_delay = T_observed − T_target

解釈：

• Δ_delay がゼロに近い場合、プラットフォームは意図した時刻の近くで注文を期限切れとしてマークしたことになります。
• Δ_delay が一貫して正の場合、システムは、何らかの処理遅延、再接続遅延、またはサイクル末尾の更新によって、期限切れを後で記録している可能性があります。
• 終端ステータスが「expired（期限切れ）」ではない場合（たとえば「filled（約定）」）、その注文にとって有効期限は終端結果ではありません。それでも測定は有効です。なぜなら、別の問いに答えているからです：「その終端ステータスは、どの時刻に発生したのか？」

このアプローチは、外部の相場見積もりに基づく推測ではなく、あなたのシステムにおける注文ライフサイクルの「有効期限」を検証するのに役立ちます。

制限とリスク（重大な失敗パターン）

測定にはいくつかの制限があります：

1. 時計とタイムゾーンの不一致 T_start、T_target、T_observed が異なる情報源またはタイムゾーンから来ている場合、プラットフォームが正しく動作していても、Δ_planned と Δ_delay が誤解を招く可能性があります。

2. 終端状態の曖昧さ 有効期限の直前のタイミングでは、注文が約定したり部分的に約定したり、執行判断の後に期限切れとしてマークされたりすることがあります。測定は、ステータス遷移の定義と、それをいつのタイムスタンプとして記録するかに依存します。

3. データのタイミングと接続性 リアルタイムの市場データを前提にしなくても、遅延したステータス更新、アプリケーションの更新タイミング、または監査ログの順序によって、「有効期限のドリフト（expiry drift）」のように見えるものを確認できます。

4. 市場条件の変動 注文のトリガー条件と、（まだアクティブであった場合に）執行されていたであろう時刻は、急速に変わり得ます。過去の関係は、将来の注文が同様に振る舞うことを保証しません。

5. 提供者または管轄ごとのライフサイクルルール 異なる執行会場、インフラ、運用ルールによって、「expired（期限切れ）」が運用上どういう意味になるかが変わります（たとえば、プラットフォームが注文のルーティングを停止するタイミングなど）。そのため、あなたの測定は普遍的なルールというより、プラットフォームのポリシーを反映している可能性があります。