流動性集約を評価するために必要なデータは？
流動性集約とは（定義）
流動性集約とは、複数の市場ソースからの流動性を、取引のマッチングと執行のために単一の利用可能なビューへ統合するプロセスです。実務上は、取引所、仲介業者、または社内システムにまたがって、見積（クオート）やオーダーフローを集約し、買い手と売り手がより効率的に相互作用できるようにすることが含まれます。
流動性集約を評価するには、まず（1）何が集約されているのか、（2）それがどこから来ているのか、（3）それがあなたが観測する執行可能な結果へどのように変換されるのかを説明するデータが必要です。これらの要素がなければ、観測された挙動が集約メカニズムによるものなのか、それとも市場環境の変化によるものなのかを判断できません。
直接の回答：必要なデータ
流動性集約の評価には、次の4つのデータ群が必要です：入力、出所（provenance）、鮮度（timeliness）、品質チェックです。
- 入力（何が集約されているか）
- クオート関連の項目：ビッド/アスク水準、クオートのタイムスタンプ、深さまたは価格あたりのサイズ指標（利用可能な場合）。
- 執行関連の項目：約定価格、約定時刻、数量。
- ルーティング/マッチング関連の項目：ソース間で注文がどのようにマッチングまたはルーティングされるか（高レベルの説明でも重要です）。
- 出所（各入力がどこから来るか）
- ソースの識別：各データストリームの取引所、仲介業者、社内プール、またはフィード提供者。
- データ収集方法：ストリーミングかポーリングか、スナップショットか増分更新か。
- 変換に関する注記：集約ルール、単位変換、レイテンシ補正、またはフィルタリング。
- 鮮度（データがどれだけ新しく、比較可能か）
- タイムスタンプの定義：タイムスタンプがクオート作成時刻、受信時刻、またはシステム時刻を表すのか。
- 更新頻度とジッター：データがどれくらいの頻度で変わるか、更新タイミングのばらつき。
- 同期：複数ソースが時間的に整列しているか、それとも観測された差がタイミングのアーティファクトである可能性があるか。
- 品質チェック（評価に使えるかどうか）
- 欠損とギャップ：データがいつ・どこで落ちるのかを定量化する。
- 一貫性チェック：単位（ベース/クオート）、小数点、符号の取り決めを検証する。
- 重複と並び替え：繰り返しのスナップショット、順序のない更新、またはクロックのドリフトを検出する。
- 比較可能性：データストリームが同じ「もの」（例：表示される深さ vs. 執行可能な深さ）を測定していることを確認する。
データの使われ方：具体例つき
単純な評価アプローチは、「集約ビュー」を基礎となるソースと比較することです。ただし、時間と品質を制御します。
例（前提ベースでありリアルタイムではない）：あなたが（a）ソースAのクオート、（b）ソースBのクオート、そして（c）集約側（アグリゲータ）での集約クオートまたは執行結果を観測できるとします。
- 明示的な時間窓を定義（1分のウィンドウを仮定）し、同期ルールを設定（タイムスタンプは同じ時間基準にあると仮定）。
- 集約されたビッド/アスクが、単に単一ソースのものではなく、ソース群で利用可能な流動性の組み合わせを表しているかを測定する。
- 同じ時間窓で、どちらのソースが示す価格を超える価格で執行が見られる場合、その食い違いは、変換ルール、古いクオート、レイテンシ、または異なる流動性定義を示唆し得ます。
重要な点は、同じメカニズムでも、タイムスタンプの解釈、フィルタリングルール、「深さ」がどう定義されているかによって見え方が変わり得ることです。そのため、鮮度と出所のデータが必要であり、任意ではありません。
重大な制約と失敗モード
良いデータがあっても、いくつかの制約によって評価が破綻することがあります。
- タイミング失敗モード：ソース間でタイムスタンプが比較できない場合、差異を集約によるものだと帰属してしまう可能性がありますが、実際には遅延した更新が原因かもしれません。
- 定義の不一致：「流動性」は、表示されるクオート、執行可能なクオート、またはルーティングされたオーダーフローを意味し得ます。測定される項目が、集約側で用いられている定義と一致しない場合、結論が誤りになります。
- 古いデータ失敗モード：過去データや頻度の低い更新の入力は、現在の条件では成り立たない関係を保持してしまうことがあります。
- 執行とコストによる歪み：観測された約定は、コスト、約定時点でのスプレッド、そして会場固有のメカニクスの影響を受け得ます。過去の関係は将来の結果を保証しません。
結果は市場環境、コスト、執行、そして管轄（jurisdiction）によって変わるため、あなたが用いたデータ窓と前提に条件づけて、発見事項を組み立てる必要があります。
エビデンス・チェックリスト：検証と次の質問
評価を独立に検証するには、次の「監査可能（ready-to-audit）」な質問に答えられることを確認してください。
- すべての入力ストリームに、その出所と収集方法がタグ付けされていますか？
- 各タイムスタンプが何を表すのか（クオート時刻 vs. 受信時刻）を把握していますか？
- 欠損データを定量化し、低品質な期間を除外またはフラグ付けできますか？
- 集約変換ルール（フィルタリング、変換、またはルーティングロジックなど）についてのドキュメントはありますか？
これらの質問のいずれかの答えが「不明（unknown）」であれば、その評価は不完全として扱ってください。
DOCUMENT END