壁の内部のキュー：注文板密度における注文ポジションの分析

はじめに：集計された注文板が嘘をつく理由

注文板でトレードするすべてのトレーダーは同じ画面を見ています：左にbid、右にask、そして各価格レベルに — 指値注文の合計出来高を示す数字。例えば：

Price 10001  |  150 lots
Price 10000  |  2,400 lots   ← wall
Price  9999  |  80 lots

10000レベルに2,400ロット — これが「壁」（密度）です。そしてここに、ほとんどのトレーダーが無視する極めて重要な質問があります：2,400ロットの中で、私たちの注文は正確にどこにあるのか？

Price 10000  [ 1,800 lots BEFORE us ][ OUR ORDER 10 lots ][ 590 lots AFTER us ]

これは学術的な好奇心ではありません。約定する注文と約定しない注文の違いです。利益と損失の違いです。美しいエクイティカーブを示すバックテストと、戦略が機能しない現実の違いです。

キューポジションとは何か、なぜ計算するのか

FIFOキューの可視化：価格レベルでの他の注文の中でのトレーダーのポジション

FIFOと取引所の現実

取引所の大多数 — 伝統的な取引所（CME、NASDAQ）と暗号通貨取引所（Binance、Bybit、OKX）の両方 — は**Price-Time Priority（FIFO）**ルールを使用します。つまり、同じ価格では、先に出された注文が先に約定します。

成行売り注文が到着し、私たちのbid価格レベルに「ヒット」すると、キューの先頭から末尾に向かって順番に指値注文を約定させていきます。成行注文がキュー内の私たちの位置に到達するほど大きくなければ — 私たちは未約定のままです。

キューポジション価値の2つの要素

学術研究（Moallemi & Yuan、Columbia Business School、2017）は、キューポジション価値の2つの要素を特定しています：

1. 静的要素 — スプレッド獲得と逆選択のトレードオフ。キューの後方にいるほど、大きな情報を持つ注文（ノイズではなく）で約定される確率が高くなります。簡単に言えば：キューで最後に約定した場合 — 価格はすでにあなたに不利に動いている可能性が最も高いです。

2. 動的要素 — キューポジションの時間経過による改善がもたらすオプション性。私たちの前の注文がキャンセルされたり約定されたりすると、何もアクションを取らなくてもポジションが改善されます。

実証データは、ティックサイズの大きな商品では、キューポジションの価値がスプレッドサイズに匹敵し得ることを示しています。これは非常に大きな量です。

キューポジションの推定方法

推定問題

サイズSの指値注文を価格Pに出します。発注時点で、その価格レベルにはすでにQロットが存在しています。初期ポジションの推定値：

V̂(t₀) = Q(t₀)     — 私たちの前のロット数

次に、自分の価格レベルでのすべての出来高変化を追跡します。これはErik Rigtorpが記述し、Trading Technologies（TT）、Bookmapなどの製品に実装されている主要なアルゴリズムです。

更新アルゴリズム

価格レベルでの各減少ΔQについて、注文が私たちの前にあったのか後ろにあったのかを判断する必要があります：

約定（execution）とキャンセル（cancellation）を区別できる場合：

• 約定： 私たちの前のキューを一義的に減少させる → V̂ = max(V̂ + ΔQ, 0)
• キャンセル： 不確実性 — キャンセルされた注文は前にも後ろにもあり得た

キャンセルには確率モデルが使用されます：

V̂(n+1) = max(V̂(n) + p(n) × ΔQ(n), 0)

ここでp(n)はキャンセルされた注文が私たちの前にあった確率です。モデルの一族：

p(n) = f(V̂(n)) / (f(V̂(n)) + f(max(Q(n) - S - V̂(n), 0)))

ここでf(x)はln(1+x)や恒等関数のような増加関数です。直感：前の出来高が後ろの出来高に比べて大きいほど、キャンセルが前で発生した可能性が高くなります。

データレベルと暗号通貨市場の現実

推定精度はデータの粒度に直接依存します：

暗号通貨市場の状況：

• Binance — 100msごとの更新でL2 depthストリームを提供。L3（MBO）データは公開されていない。
• Coinbase — 完全なorder-by-orderデータを持つWebSocket経由のL3ストリームを提供する数少ないCEXの一つ。
• CME（BTC/ETH先物） — ITCHフィード経由の完全なMBOデータ。

ほとんどの暗号通貨トレーダーはL2で作業しており、確率的推定に頼っています。しかし、確率的推定でさえ、推定なしと比べると根本的に優れています。

可視化：ミニ注文板としての壁

各重要な密度（壁）を注文板内のミニ注文板として可視化することを提案します：

╔════════════════════════════════════════════════════════════════╗
║  Price 10001  │  150 lots                                     ║
╠════════════════════════════════════════════════════════════════╣
║  Price 10000  │  [████████████░░░▓▓░░░░░░░]  2,400 lots       ║
║               │   ↑ 1,800 前方  ↑ 自分  ↑ 590 後方            ║
║               │   消化速度: ~120 lots/秒                       ║
║               │   約定推定時間: ~15 秒                         ║
╠════════════════════════════════════════════════════════════════╣
║  Price  9999  │  80 lots                                      ║
╚════════════════════════════════════════════════════════════════╝

リアルタイムで計算されるもの

1. 注文の前のロット数 — 私たちに到達する前に約定またはキャンセルされる必要のある出来高の推定。

2. 注文の後ろのロット数 — 私たちの後に出された出来高。壁が末尾から急速に「膨張」している場合 — 他の参加者がこのレベルを魅力的と考えている。

3. キュー消化速度 — この価格レベルでの実際の取引（execution）から計算。lots/秒で表現。

4. 約定推定時間（ETF） — 注文が約定するまでの時間予測、lots_ahead / drain_rateとして計算。

5. 同一密度内の複数注文 — ボットは同じ壁内に複数の注文がある場合、各注文のポジションを追跡可能。

スキャルピングでの応用

ナイーブ vs キュー考慮型バックテストの比較：実際の約定確率 vs 楽観的推定

ローソク足ベースのバックテストの問題

OHLCVローソク足での古典的なバックテストは次のように機能します：価格が指値注文に到達した場合 — 約定とカウント。しかしこれは重大なエラーです：

例。 10000にbuy-limitがあります。1分足ローソクでlow = 10000。ローソク足バックテストはこれを約定とカウントします。しかし実際には：

• 10000レベルに5,000ロットの壁があった
• 注文はキューの末尾にあった（ポジション4,800）
• この1分間にそのレベルで取引された出来高は2,000ロットのみ
• 実際には注文は約定しなかった

キュー考慮型バックテストはこの問題を解決します：キューポジションをモデル化し、ティックデータからレベルでの取引出来高をカウントし、取引出来高が私たちのポジションに到達するのに十分だったかどうかを判定します。

1分間に複数回の約定

アクティブなスキャルピングでは、注文が1分以内に複数回約定・再発注されることがあります。ローソク足ベースのバックテストではこれをモデル化できません。キューモデリングを伴うティックレベル分析のみが以下を可能にします：

• 各約定の正確な時間を決定
• 注文を再発注する時間があるかどうかを理解
• 一定間隔内で戦略が実際に何回トリガーされたかを推定

約定までの時間予測

キューポジションと現在の壁の「消化」速度を知っているボットは以下が可能です：

1. ETAを計算 — 約定までの概算時間
2. ETAと価格変動予測を比較 — ETA = 30秒だが、モデルが10秒後にリバーサルを予測している場合、注文をキャンセルすべき
3. 注文サイズを適応 — pro-rata取引所（CME）ではより大きな注文がキューの先頭に近いが、FIFO取引所ではサイズはキューポジションに影響しない

消化速度と平均の比較

スキャルパーにとって非常に貴重な指標：現在のキュー消化速度 vs N本のローソクでの平均速度。

• 平均以上の速度 → 成行注文のアグレッション高い → 壁を「突破」する可能性 → 約定の可能性が高い
• 平均以下の速度 → 市場が「停滞」→ 壁は持ちこたえる → 注文は滞留し、価格が離れる可能性

既存の実装：市場概観

Trading Technologies（TT） — Position In Queue（PIQ）

最も成熟した実装。TTはFloating Order Bookカラムに各トレーダーの注文のPIQを表示します。フィードを通じてキューポジションデータを直接提供する取引所（CME、ICE）では正確な値が表示されます。その他では保守的な推定値。

Bookmap Quant

Bookmapのプロフェッショナル版（$499/月）には、注文キューポジションの可視化とイベントエクスポートが含まれます。Bookmap QuantはMBOデータを使用し、L0 APIにより任意のデータソース用のカスタムアダプターを構築できます。

CQG — Queue Position Estimation

CQGは先物市場向けにキューポジション推定を提供します。プラットフォームはL2/L3データに基づいて確率的PIQ推定を計算し、DOMTraderインターフェースに表示します。

Rithmic — Order Queue Data

Rithmicは、キューポジション推定用の低レイテンシーデータアクセスを提供するマーケットデータプロバイダーです。多くのプロップトレーディング企業やアルゴリズムトレーダーが独自のPIQモデルを構築するためのインフラストラクチャレイヤーとして使用しています。

Jigsaw Trading — Order Flow Visualization

Jigsaw Tradingは、キューポジション推定を伴う注文フロー可視化を専門としています。Depth & SalesおよびReconstructed Tapeツールは、トレーダーが価格レベルでの実際の執行状況を確認するのに役立ちます。

学術モデル

• Moallemi & Yuan（2017） — NASDAQ ITCHデータに基づくキューポジション評価の形式モデル
• Cont, Stoikov & Talreja（2010） — 生死過程システムとしての指値注文板モデル
• Gould & Bonart（2015） — 中間価格変動の予測因子としてのキューインバランス
• Deep Learningアプローチ — 約定確率と約定時間を推定するためのRNNモデル（Columbia、2022）

市場に存在しないもの

既存のどの製品も、スキャルピングボット向けにカスタマイズされた形式で暗号通貨市場の壁の内部構造の可視化を提供していません。 これがMarketmaker.ccが埋めることができるニッチです。

操作戦略への対抗

偽の壁の検出：本物の注文 vs 高いキャンセル率のスプーフィングブロック

壁の内部構造を理解することは、単に自分の執行を最適化するだけではありません。操作に対する保護のツールであり、巧みに使用すれば、大口プレイヤーの意図を読み取るツールです。

スプーフィング：偽の壁

スプーフィングは、執行前にキャンセルする意図で大きな注文を出すことです。目的は、需給に関する誤った印象を作ることです。

PIQ分析がどう役立つか：

• 壁の蓄積速度。 本物の壁は徐々に構築されます。スプーフィングの壁は瞬時に出現します。
• 価格接近時の行動。 本物の壁は留まります。スプーフの壁は「逃げます」。
• キャンセル率。 スプーファーは執行前に注文をキャンセルします。出された/キャンセルされた比率を追跡することで、リアルタイムのスプーフ検出が可能になります。
• 周期性。 スプーフィングは反復パターンをしばしば示します：出現 → 消失 → 新しいレベルで出現。

レイヤリング：カスケード型の偽のレベル

レイヤリングは、複数の価格レベルにわたって偽の注文を出すスプーフィングのより洗練された形態です。

PIQ分析がどう役立つか：

• 相関のあるキャンセル。 5つの連続レベルの注文が同時にキャンセルされた場合 — ほぼ確実に単一参加者によるレイヤリングです。
• 注文板の非対称性。 本物の流動性は通常、ほぼ均等に分布しています。
• 約定への反応。 本物の注文は約定し、「逃げません」。

アイスバーグ注文：隠れた流動性

アイスバーグは、小さな可視部分に分割された大きな注文です。一つの部分が約定されると、次が自動的に出現します。

PIQ分析がどう役立つか：

• 「不死身」のレベルパターン。 出来高は常に約定されているが減少しない。
• 吸収分析。 価格が壁にヒットし、可視出来高を約定させるが、壁が再生される。
• 吸収中のキュー挙動。 アイスバーグのスライスが約定してキューの末尾に再配置されるたびに、ポジションが「前にスライド」します。

壁の中の「見えない」参加者としてのマーケットメーカー

プロフェッショナルなマーケットメーカーはいくつかの戦術を使用します：

1. Quote stuffing — 競合他社のデータを「汚染する」ための大量の注文出し入れ
2. Penny jumping — 競合他社より1ティック良い注文を出して優先権を獲得
3. Dynamic quoting — キューインバランスの変化に応じたリアルタイムの注文適応
4. Level defense — 価格が近づくにつれて流動性を追加

実装：キューポジショントラッカーモジュールのアーキテクチャ

入力データ

1. WebSocket order book stream (L2 depth):
   - Best bid/ask updates
   - Depth updates (volume at each price level)

2. WebSocket trade stream:
   - Each trade: price, volume, side (buy/sell), timestamp

3. Own orders (from the trading bot):
   - order_id, price, size, placement timestamp

コアアルゴリズム（Pythonライクな擬似コード）

class QueuePositionTracker:
    def __init__(self, order_price, order_size, initial_depth):
        self.price = order_price
        self.size = order_size
        self.queue_ahead = initial_depth  # V̂(t₀) = Q(t₀)
        self.queue_behind = 0
        self.fill_velocity = EMA(span=30)  # EMA of fill rate

    def on_trade(self, trade_price, trade_size):
        """Called on each trade at our price level"""
        if trade_price == self.price:
            self.queue_ahead = max(self.queue_ahead - trade_size, 0)
            self.fill_velocity.update(trade_size)

    def on_depth_change(self, new_depth, change_type):
        """Called when depth changes at our price level"""
        if change_type == 'cancel':
            total = self.queue_ahead + self.size + self.queue_behind
            p_ahead = log(1 + self.queue_ahead) / (
                log(1 + self.queue_ahead) + log(1 + self.queue_behind)
            )
            cancelled = abs(new_depth - total)
            self.queue_ahead = max(
                self.queue_ahead - p_ahead * cancelled, 0
            )
            self.queue_behind = max(
                self.queue_behind - (1 - p_ahead) * cancelled, 0
            )
        elif change_type == 'new_order':
            added = new_depth - (self.queue_ahead + self.size + self.queue_behind)
            self.queue_behind += added

    @property
    def estimated_time_to_fill(self):
        """Estimated time to fill in seconds"""
        if self.fill_velocity.value <= 0:
            return float('inf')
        return self.queue_ahead / self.fill_velocity.value

    @property
    def fill_probability(self, horizon_sec=60):
        """Probability of fill within a given horizon"""
        expected_volume = self.fill_velocity.value * horizon_sec
        return min(expected_volume / max(self.queue_ahead, 1), 1.0)

重要なエッジケース

1. 壁が完全に「食い尽くされた」 — queue_aheadが0に下がった場合、次の成行注文が私たちを約定させる
2. 大量キャンセル（壁の撤退） — 壁が突然消え、queue_aheadが急激に変化
3. 注文が移動された — キャンセルして再発注すると、キューの末尾に行く
4. 同じ壁内の複数注文 — それぞれが独立して追跡される

ダッシュボードとバックテスト用の指標

リアルタイム（スキャルピングターミナル）

バックテスト用（キュー考慮型シミュレーション）

1. キュー調整済み約定率 — キューポジションを考慮した実際に約定した注文の割合
2. 実効約定レイテンシー — 発注から執行までの実際の時間
3. 約定あたりの逆選択 — 約定後の平均的な不利な価格変動
4. キュー速度相関 — キュー消化速度と後続の価格変動との相関

ソーシャルオーダーブック：壁の中のチーム注文

3層可視性モデル：壁の中の個人注文、サブスクリプション、チームポジション

Tier 1：取引所またはトレーディングプラットフォーム

取引所やトレーディングターミナルであれば、すべてのユーザーの注文ポジションについて絶対的な知識を持っています。プラットフォームは、他の参加者の身元を明かすことなく、各ユーザーに注文の前後にどれだけの「他の」出来高があるかを表示できます。

Tier 2：Marketmaker.ccプラットフォーム — 個人注文 + ソーシャルレイヤー

Marketmaker.ccでは、壁の中で3層の注文可視性モデルの実装を計画しています：

個人注文 — 基本レイヤー。各トレーダーは個別の指標を持つすべての自分の注文を見ることができます。

サブスクリプション注文（シグナルプロバイダー） — サブスクリプション経由でポジションを共有するトレーダー。オプトインメカニズム：リーダーがポジションを表示するかどうかを決定。

チーム注文（トレーディングチーム / ファンド） — プロフェッショナルグループにとって最も価値のあるレイヤー。解決する問題：注文の競合、流動性配分、チームリスクモニタリング、教育。

パーミッションモデル

┌─────────────────────────────────────────────────────────────┐
│  トレーダーの注文                                              │
│                                                              │
│  閲覧可能:                                                    │
│  ├── トレーダー自身       → 常に                              │
│  ├── サブスクライバー     → トレーダーが有効化した場合          │
│  │   ├── 表示遅延         → 設定可能 (0s–60s)                 │
│  │   ├── サイズ表示       → はい / 非表示 / 丸め               │
│  │   └── ETA表示          → はい / いいえ                      │
│  └── チーム               → チームに所属している場合            │
│      ├── 遅延             → 設定可能 (0s–5s)                   │
│      ├── サイズ表示       → はい (リスク管理のため)             │
│      └── ロール可視性     → トレーダー / マネージャー / ビューワー│
└─────────────────────────────────────────────────────────────┘

完全な透明性：DEX取引所とオンチェーン注文板

オンチェーン注文板を持つDEX取引所 — 主に**Hyperliquid** — では、すべての注文が特定のウォレットアドレスに紐づいています。集計された壁だけでなく、各参加者の個々の注文を見ることができます。

ただし、このデータをリアルタイムで処理するには、独自のHyperliquidブロックチェーンノードの運用が必要です。

操作者注文の自動識別

第4の可視化レイヤー — 参加者タイプによるアルゴリズム的注文分類：マーケットメーカー、スプーファー、リテール。分類アルゴリズムは複数のレベルで動作します：スプーフィング検出、マーケットメーカー分類、スクイーズシナリオ検出、トレーダーデジタルフィンガープリンティング。

詳しくはシリーズの次の記事で："トレーダーのデジタルフィンガープリント：注文板の行動からマーケットメーカーを特定する方法"

結論

注文板密度内の注文ポジション分析は、「注文板を見る」ことから「市場微細構造を理解する」ことへの次の進化ステップです。これは以下が交差する領域です：

• キュー理論 — キューのモデリング
• 確率的注文フローモデル — 約定確率の推定
• 機械学習 — スプーフィング検出と壁の行動予測
• 低レイテンシーエンジニアリング — リアルタイムでのデータ受信と処理

現時点で、暗号通貨市場のどの製品も、ユーザーの注文ポジション、ETA推定、スプーフィング検出、キュー考慮型バックテストを単一のインターフェースで統合した「ミニ注文板としての壁」の包括的な可視化を提供していません。

Marketmaker.ccでは、ソロスキャルパーからプロップトレーディングチームまで、すべてのトレーダーにこの分析をアクセス可能にする取り組みを行っています。

出典と参考文献

• Moallemi C.C., Yuan K. — "A Model for Queue Position Valuation in a Limit Order Book" (Columbia Business School, 2017)
• Cont R., Stoikov S., Talreja R. — "A Stochastic Model for Order Book Dynamics" (2010)
• Gould M.D., Bonart J. — "Queue Imbalance as a One-Tick-Ahead Price Predictor" (2015)
• Rigtorp E. — "Estimating Order Queue Position" (rigtorp.se)
• Do B.L., Putniņš T.J. — "Detecting Layering and Spoofing in Markets" (SSRN, 2023)
• Trading Technologies — PIQ Documentation
• Bookmap — Iceberg Orders Tracker Knowledge Base