MBOとMBPの板情報データ：違いと仕組みを解説

MBO（注文単位）とMBP（価格単位）の板情報は、小さな名称の裏に大きな違いを隠しています。二つのベンダーが共に「Level 2」と称するデータを販売していても、その中身は異なります。MBPは各価格水準の合計数量を送信するのに対し、MBOは個々の注文を固有のIDを持つイベントとして送信します。一方は板情報の要約であり、もう一方は板を構築するための元帳です。後者は前者に比べ、桁違いの通信量を要します。

MBPとMBOの板情報に含まれる内容

MBP（Market By Price）は、集計された板情報です。各更新データには、サイド（売買）、価格水準、そこに存在する合計表示数量、場合によってはその背後にある注文数が含まれます。「MBP-10」として販売される商品は、各サイドの最良価格水準を十段階提供するもので、トレーディングプラットフォームの板や、あらゆる板情報チャートの階段状の表示に相当します。

MBO（Market By Order）はイベントストリームです。各メッセージは、ID、サイド、価格、表示数量、そしてその注文に何が起きたかという個別の注文情報を伝えます。事前の集計は一切行われません。同一価格に四十の注文が存在する場合、四十の個別メッセージがそれらを配置し、その水準の合計を知るためには、四十の注文すべてをメモリ上で保持する必要があります。

Level 1とLevel 2の市場データガイドでは、証券会社におけるリテール向け階層の名称が何を意味するかを解説しています。MBOとMBPは、ベンダーが「Level 2」と呼ぶ箱の中身を正確に示す名称であり、確認すべきはスキーマ名です。

MBOフィードが伝えるメッセージアクション

MBOフィードは、注文IDに適用されるアクションの分類です。通信量の大部分は以下の四つが占めます。

• Add（追加）：新しい注文が新しいIDで板に追加される。
• Modify（変更）：既存のIDの価格や数量が変更される。数量の増加や価格の変更は、その注文を新しい価格水準の最後尾へ移動させる。数量の削減は通常、順位を維持する。
• Cancel（取消）：IDが板から一部または全部削除される。
• Trade or fill（約定）：積極的な注文が、板にある一つ以上のIDと約定し、その数量を減少または消滅させる。

MBPにはこのような語彙はありません。MBPの更新は「この価格には現在これだけの数量がある」という水準に関する記述です。その数量が取消によって減ったのか、約定によって減ったのかは区別されず、更新データは同一に見えます。以下のパネルは、最も薄い板である最良気配値（サイドごとに一価格水準、この命名法ではMBP-1）における制限を示しています。

WITH
    ordered AS
    (
        SELECT
            row_number() OVER (ORDER BY sip_timestamp, sequence_number) AS msg_index,
            bid_price,
            bid_size,
            lagInFrame(bid_price) OVER (ORDER BY sip_timestamp, sequence_number) AS prev_bid_price,
            lagInFrame(bid_size)  OVER (ORDER BY sip_timestamp, sequence_number) AS prev_bid_size
        FROM global_markets.cache_stocks_quotes
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= '2026-06-16 14:00:00'
          AND sip_timestamp <  '2026-06-16 14:30:00'
          AND bid_price > 0
    ),
    classified AS
    (
        SELECT multiIf(
            bid_price != prev_bid_price, 'best bid price changed',
            bid_size  >  prev_bid_size,  'size joined at the best bid',
            bid_size  <  prev_bid_size,  'size left the best bid',
            'bid untouched, ask side updated') AS message_type
        FROM ordered
        WHERE msg_index > 1
    )
SELECT
    message_type,
    count()                                        AS message_count,
    round(100 * count() / sum(count()) OVER (), 1) AS share_pct
FROM classified
GROUP BY message_type
ORDER BY indexOf(['best bid price changed', 'size joined at the best bid', 'size left the best bid', 'bid untouched, ask side updated'], message_type)

その三十分間で、17.6%のメッセージが最良買気配を別の価格へ移動させ、17.4%が不変の買気配に数量を追加し、12%が不変の買気配から数量を削除し、53%が他方のサイドが動く間、買気配を維持しました。各グループは価格水準に関するネットの記述です。注文名は一切含まれず、どのような算術を用いても欠落したIDを復元することはできません。

各スキーマで回答可能なこと

MBP-10は「そこにどれだけの数量があったか」という問いに答えます。板の形状、板の不均衡、中間値付近の流動性、板情報チャートそのものがこれに該当します。これらには集計された水準で十分です。

MBOは「この注文に何が起きたか」という問いに答えます。注文参加時に自分の前にどれだけの数量があったか、注文が取消されるまでにどれだけ生存したか、最良気配にある受動的な注文が価格移動前に約定する確率はどれくらいか、といった問いです。これらの数量は集計された形式では存在せず、注文を合計して水準の合計値にすることは、それらを定義していた順序を破壊することになります。

キュー（待ち行列）の順位は最も顕著な例であり、これは価格優先・時間優先対当とプロラタ対当においてのみ意味を持ちます。到着順序が約定の優先順位を決定するためです。ここで重要になるのが約定サイズです。一つの大きな約定ではなく、多くの小さな約定によって水準が埋め尽くされるためです。

SELECT
    multiIf(size < 100,  '1 to 99 shares',
            size < 200,  '100 to 199 shares',
            size < 500,  '200 to 499 shares',
            size < 1000, '500 to 999 shares',
            '1000 or more shares')                 AS trade_size_bucket,
    count()                                        AS trade_count,
    round(100 * count() / sum(count()) OVER (), 1) AS share_pct,
    round(avg(size))                               AS avg_shares
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
  AND sip_timestamp >= '2026-06-16 14:00:00'
  AND sip_timestamp <  '2026-06-16 14:30:00'
  AND size > 0
GROUP BY trade_size_bucket
ORDER BY min(size)

百株未満の端株による約定が、当該期間の取引の92.3%を占め、最大のバケットである1000 or more sharesが0.1%を占めました。四千株を表示している水準にそれらのサイズが約定として流れても、キューの最後尾に並んだ注文は、数十回の約定を経ても約定しない可能性があります。MBPは四千株を表示しますが、MBOは列そのものを見せます。

どちらのスキーマも隠し注文（アイスバーグ注文）は表示しません。アイスバーグ注文は小さな一部のみを表示し、その分が約定するたびに新しいIDで更新されるため、予備の数量がメッセージに現れることはありません。

MBOからの板の再構築はステートマシンである

MBPフィードは答えを提示しますが、MBOフィードは入力データのみを渡し、正確な処理を求めます。

1. スナップショット、または空の板と取引所のクリアメッセージから開始する。
2. 注文IDをキーとして、すべての追加、変更、取消、約定を厳密な順序で適用する。
3. 戦略が読み取る価格水準ごとのインデックスを別途維持する。
4. シーケンス番号を監視し、欠落があれば最新のスナップショットから再同期する。

失敗時の挙動は静かです。取消を一つ見落とすと、幻の注文がセッション終了まで板に残り続け、その水準の数量を水増ししますが、例外は発生しません。MBPはより緩やかに劣化します。各更新が水準の合計を再提示するため、破損した値は数メッセージ以内に上書きされます。

また、MBOは取引所直結のフィードでのみ提供され、取引所ごとに板が存在するため、複数のフィードを実行・統合する必要があります。統合テープは構造上、要約されたものであり、その違いはSIPと取引所直結フィードで解説しています。

詳細なデータが帯域幅に与えるコスト

メッセージ数は、この違いを評価する正直な指標です。以下のパネルは、五つの主要銘柄について、同じ三十分間で統合最良気配値のメッセージ数と実際の約定数を比較したものです。

WITH
    quote_load AS
    (
        SELECT ticker, count() AS quote_messages
        FROM global_markets.cache_stocks_quotes
        WHERE ticker IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
          AND sip_timestamp >= '2026-06-16 14:00:00'
          AND sip_timestamp <  '2026-06-16 14:30:00'
        GROUP BY ticker
    ),
    trade_load AS
    (
        SELECT ticker, count() AS trades
        FROM global_markets.stocks_trades
        WHERE ticker IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
          AND sip_timestamp >= '2026-06-16 14:00:00'
          AND sip_timestamp <  '2026-06-16 14:30:00'
        GROUP BY ticker
    )
SELECT
    q.ticker                              AS ticker,
    round(q.quote_messages / 1000, 1)     AS quote_messages_thousands,
    round(t.trades / 1000, 2)             AS trades_thousands,
    round(q.quote_messages / t.trades, 1) AS quotes_per_trade_ratio
FROM quote_load AS q
INNER JOIN trade_load AS t ON t.ticker = q.ticker
ORDER BY quotes_per_trade_ratio DESC

SPYは、約定あたりの気配値トラフィックが最も多く、約定ごとに9.6メッセージ、三十分間で510千メッセージに達しました。五銘柄間の差は大きく、パネル下部のMSFTは、約定あたり0.7気配値メッセージと、約定一回につき一メッセージ未満でした。この列が何をカウントしているかを忘れないでください。すべての取引所を単一の最良気配値に集約したフィードにおける、サイドあたり一価格水準です。十段階の板情報商品はこれを倍増させ、注文単位のフィードはさらにそれを倍増させます。各取引所の各水準の背後にあるすべての注文が、約定の有無にかかわらず、独自の追加、変更、取消を生成するためです。同じ算術が、より大規模なオプション気配値フィードのサイズにも当てはまります。

戦略にはどの板情報フィードが必要か

ほとんどの作業はMBP-10で実行可能です。板情報チャート、不均衡指標、価格ごとの流動性測定、約定コストモデル、そして「どこにどれだけの数量が残っていたか」という研究上の問いのほとんどは、集計された水準から、わずかなメッセージ量で回答可能です。

MBOが必要となるのは、答えが特定の注文に依存する場合です。キューの順位、注文の生存期間、取消行動、最良気配での受動的な約定確率などがこれに当たります。列の二百株目か二万株目かによって成否が分かれる戦略は、集計データでは対応できず、ライセンス料、帯域幅、ストレージ、そして再構築された板を一日中正確に保つためのエンジニアリングコストを支払うことになります。

FAQ

MBOとMBPの市場データにはどのような違いがありますか？

MBP（価格単位）は各価格水準の表示数量を集計し、水準ごとに一つの更新を送信します。MBO（注文単位）は、個々の注文を固有IDとともに送信し、それに付随する追加、変更、取消、約定イベントを送信します。

Level 2データはMBOデータと同じですか？

通常は異なります。リテール証券会社の「Level 2」は、ほぼ例外なく集計された板情報、つまり五から二十段階の価格水準を持つMBPを指します。一部のベンダーは同じ階層名で注文単位のフィードを販売しているため、階層名ではなくスキーマ名が何を受信するかを決定します。

MBOフィードはMBPフィードよりどれくらい大きいですか？

取引所や銘柄によりますが、桁違いです。統合最良気配値だけでも、上記のパネルで最も活発な銘柄では約定あたり9.6メッセージに達しました。注文単位のフィードは、すべての取引所のすべての水準の背後にあるすべての追加、変更、取消を加算するため、約定しない大多数の注文を含めるとさらに膨大になります。

MBOデータからMBPの板を再構築できますか？

はい、それが通常のパイプラインです。注文IDをキーとする板に各注文イベントを適用し、水準ごとの合計を公開します。逆は不可能です。注文が水準の合計に集約された時点で、個々のIDや到着順序は失われるからです。

ここにあるすべてのパネルは、その背後にあるSQLとともに提供されています。別の銘柄やセッションで同じメッセージをカウントするには、Strasmoreターミナルで平易な英語で質問してください。