Reading the Hyperliquid Order Book Through the API: Depth, Spread, and What They Actually Tell You

By @CoinMarketMan - 27-May-2026

HyperliquidのオーダーブックをAPIで読み解く：深度、スプレッド、そしてそれらが実際に示すもの

多くの個人トレーダーはHyperliquidのUIでオーダーブックをちらりと見て、片側に緑のバー、もう片側に赤のバーがあるのを確認し、何となくの印象を形成する。緑が赤より多ければ「買い手が優勢」ということだ。その印象は、正しい場合よりわずかに間違っている場合の方が多い。オーダーブックはトレーディングにおける最も情報密度の高いデータ構造の一つであり、一般的に表示される方法は、重要な情報のほとんどすべてを圧縮して表示してしまっている。

同じデータへのプログラマティックなアクセスをHyperliquid APIを通じて行うことで、オーダーブックを構造化されたシグナルに変換できる。バーを読むのではなく、流動性の形状を読むようになる。つまり、どこに集中しているか、価格が近づいたときにどう変化するか、そしてスプレッドが自身の最近の履歴に対してどう動いているかを読むのだ。コホートポジショニングデータと組み合わせることで、これらの読み取りはUIでは答えられない疑問に答える。誰が流動性を提供しているのか、誰がそれを取っているのか、そして表示されているビッドが本物の意図なのか、それともタッチされたら消えるノイズなのか。

この記事では、APIを通じてHyperliquidのオーダーブックを読み解く実践的な手法を解説する。深度とスプレッドが実際に何を測定しているのか、すべてのパーペチュアル資産で繰り返し現れる3つのブック形状、そしてオーダーブックの読み取りをコホートデータと組み合わせてノイズからシグナルをフィルタリングする方法について説明する。

オーダーブックが実際に表すもの

パーペチュアル先物のオーダーブックは、マーケットの両側に置かれているリミット注文のスナップショットである。各レベルには、特定の価格で利用可能な累積数量が表示される。「スプレッド」は最高ビッドと最低アスクの差である。「深度」は、ミッドを中心としたある価格帯内にどれだけのボリュームがあるかを示す。

オーダーブックを見た目以上に読み取りにくくしている2つの要素がある。

**流動性は約束ではない。**ビッドとして置かれている注文は、誰かが売る意思がある場合に、その価格で買うという申し出である。メイカーはその注文をミリ秒単位でキャンセルできる。活発なパーペチュアルのオーダーブックに表示されているもののほとんどは、価格が近づくと消える日和見的な流動性である。
**表示が情報を圧縮している。**UIのオーダーブックは通常、各サイド10〜20レベルを表示する。APIは各サイドで50以上を公開し、さらにそれらのレベルがどのように変化してきたかの完全な時系列も提供する。シグナルは、UIに収まらないレベルとダイナミクスの中にある。

APIは両方を提供する。つまり、任意の瞬間のスナップショットと、ブックが秒単位でどのように進化するかを追跡する能力である。分析的な優位性はここから始まる。

プログラムでオーダーブックを取得する

Hyperliquidのオーダーブックは、パブリックWebSocketおよびRESTエンドポイントを通じてアクセスできる。HyperTracker APIはこのアクセスをラップして正規化し、履歴の永続化を追加し、コホートポジショニングデータをオーバーレイする。

基本的なスナップショット取得:

import requests

# BTCパーペチュアルの現在のオーダーブックを取得
ob = requests.get(
    "https://api.hypertracker.cmm.app/orderbook/BTC",
    headers={"Authorization": "Bearer YOUR_API_KEY"}
).json()

# 構造:
# {
#   "timestamp": "2026-05-25T14:30:00Z",
#   "mid": 81234.50,
#   "spread_bps": 1.2,
#   "bids": [{"price": 81234.0, "size": 4.5}, ...],
#   "asks": [{"price": 81235.0, "size": 3.8}, ...],
#   "depth_1pct": {"bid": 142.3, "ask": 138.7},   # ミッドから1%以内のBTC
#   "depth_5pct": {"bid": 1284.5, "ask": 1247.2}, # ミッドから5%以内のBTC
# }

各取得で最も有用な派生メトリクス:

mid — 最良ビッドと最良アスクの平均、分析目的における「真の」価格
spread_bps — ベーシスポイントでのスプレッド(1 bps = 0.01%)、資産間比較のために正規化
depth_1pct / depth_5pct — バンド内の総待機サイズ。特定のバンドでのビッド深度とアスク深度の比率が不均衡シグナルとなる
depth_imbalance — (bid_depth - ask_depth) / (bid_depth + ask_depth)、-1から+1の範囲

繰り返し現れる3つのオーダーブック形状

何百ものオーダーブックスナップショットにわたって、3つの構造的パターンが名前を付ける価値があるほど頻繁に現れる。

1. 壁

周囲のレベルよりもはるかに大きなサイズを持つ単一レベル(または密集したクラスター)。多くの場合、隣接レベルの平均サイズの5〜10倍。ビッド側では「床」のように見え、アスク側では「天井」のように見える。

意味するもの:そのレベルで確信を持っている実際の買い手/売り手(価格を守る)、または小規模トレーダーを退散させることを意図したスプーフィングのいずれか。

違いを見分ける方法:**価格が壁に触れるのを待つ。**壁がタッチを通じて維持されれば、それは本物である。価格が近づいた瞬間に引き戻され、価格が離れた後に異なるレベルに再び現れる場合、それはスプーフィングの可能性が高い。ただし、HyperLiquidのオーダーブックの透明性により、大量のスプーフィングはCEXよりも可視的であり、したがってあまり一般的ではない。

2. フェード

最初の数レベルを超えると深度が急激に薄くなるブック。最良ビッドと最良アスクにはそれぞれまともなサイズがあるが、ミッドから1%離れると、ブックの上部にあった深度から80%以上低下している。

意味するもの:マーケットメイカーがタイトで低確信の流動性を提供している。彼らは小さな取引を促進する意思はあるが、サイズのある動きを吸収する意思はない。これは低ボラティリティの横ばい期間における一般的な形状である。

読み方:**フェード形状のブックはヒゲが発生しやすい。**流動性が急速に薄くなると、中程度のマーケット買いが複数レベルをスイープし、単一のキャンドルで価格を2〜3%押し上げることがある。フェード形状のブックでストップを設定したポジションを保持している場合、表示されているスプレッドが示唆するよりも高いヒゲリスクを予想すべきである。

3. スタック

複数のレベルにわたって深度がほぼ均一なブック。多くの場合、互いに30%以内のサイズを持つ5〜10レベルがある。ブックには「肩」がある。つまり、上部だけでなく、数パーセント下にも実質的な深度がある。

意味するもの:複数のマーケットメイカーが競合しているか、本物の双方向の関心がある。これは秩序ある価格発見をサポートする形状である。大きな取引は1つのレベルをスイープする代わりに、多くのレベルにわたって吸収される。

読み方:**スタック形状のブックはヒゲに強い。**スタックブックでの5%のマーケット注文は、フェードブックでの同じ注文よりもミッドの移動がはるかに小さい。マーケットエントリーのサイジングを行っていて、ブックがスタック形状である場合、過度なスリッページを予想することなく、より積極的になることができる。

Three Book Shapes

文脈におけるスプレッド

スプレッド単体では解釈が難しい。なぜなら、適切な参照が資産固有だからだ。BTCパーペチュアルは通常Hyperliquidで1〜2 bpsのスプレッドで取引される。ロングテールのHIP-3マーケットは30〜50 bpsかもしれない。シグナルは絶対値ではなく、資産自体の最近のベースラインに対する変化である。

追跡する価値のある3つのスプレッドパターン:

圧縮:スプレッドが最近のベースラインを下回って狭まる。タイトなスプレッドがより積極的なフローを引き寄せるため、価格の動きに先行することが多い。持続的な圧縮は、何かが起ころうとしていることを示す先行指標である。

拡大:スプレッドが急激に拡大する。ニュースイベント、清算カスケード、またはファンディングの極端な状況の間に多く発生する。瞬間的なスプレッドの拡大はスリッページ警告でもある。拡大中のマーケット注文は予想よりも悪く約定される。

パルシング:スプレッドが2つの可視的な状態(例:1 bpsと3 bps)の間で振動する。多くの場合、規則的なリズムで。通常、単一のマーケットメイカーがクオート提供を支配し、レベルをリズミカルに引き戻して置き換えていることを示す。

絶対的なbpsではなく、24時間中央値に対する比率としてスプレッドを追跡する。これにより、資産間で正規化され、クリーンな「これは正常か」という測定が得られる。

オーダーブックの読み取りとコホートデータの組み合わせ

オーダーブックのメカニクスを実際のトレーダーの優位性に変えるのは、誰が取引しているかをレイヤーすることだ。オーダーブックの読み取りは流動性の形状を教えてくれる。コホートデータはテイカーとメイカーの構成を教えてくれる。

実践的な組み合わせ:

セットアップ:ビッド側の壁 + Money Printerコホートが最近の時間でロングを増やしている。 本物のビッドウォールには通常、資本が必要である。コホートデータがMoney Printerウォレットが同じ時間枠でロングエクスポージャーを蓄積していることを示す場合、壁はスプーフィングよりも防御的(本物の買い手)である可能性が高い。

セットアップ:フェード形状のブック + Exit Liquidityコホートがテイカーボリュームを支配している。 薄いブックと、テイカー側を駆動する不採算コホートの組み合わせは、典型的な混雑した負け組パターンである。反転の最初の兆候は、薄い流動性を不均衡に速くスイープする。

セットアップ:スタックブック + コホートのコンセンサスが形成されている。 ブックが健全で、高PnLコホートが方向性に収束しているとき、ポジションサイジングはより積極的にできる。マーケットは構造的に、大きな影響なしにあなたのエントリーを吸収できる。

これらはトレードではなく、フィルターである。オーダーブックの形状だけではノイズが多すぎる。コホートポジショニングだけでは実行ダイナミクスを見逃す。組み合わせは、どちらか単独よりも選択的であり、その背後にある数学はスクリーニング関数でエンコードするのが簡単である。

Book Plus Cohort

実践的な考慮事項と限界

いくつかの正直な注意事項:

**オーダーブックデータは高頻度である。**有用なオーダーブックモニターは、数秒ごとにスナップショットを取得する。これは資産ごとに1分間に多数のリクエストを意味する。無料ティアのAPIアクセス(1日100リクエスト)では、実際のモニタリングを維持できない。本格的なオーダーブック作業にはPulse($179/月)以上が必要である。

**レイテンシーが重要である。**RESTスナップショットは、解析する時点で1〜3秒古くなっている。実行時の決定には、WebSocketストリームが必要である。HyperTracker APIは両方を含む。分析用のRESTとリアルタイム用のWebSocketである。

**オーダーブックメトリクスは急速に劣化する。**30秒前のスナップショットは、現在のブック形状についてほとんど何も教えてくれない。古いデータで決定を下してはいけない。戦略がサブ秒の鮮度を必要とする場合、インフラストラクチャはそれをサポートする必要がある。

**意味があるように見えるもののほとんどはノイズである。**オーダーブックは常にパルスし、シフトする。見かけ上の「パターン」のほとんどは何も予測しない。行動する価値のあるシグナルは、複数のスナップショットにわたって持続し、他の独立したシグナル(コホートポジショニング、ファンディングレート、オンチェーンフロー)と一致するものである。単一スナップショットの読み取りは、ほとんどが娯楽である。

これが可能にするもの

Hyperliquidで自動化システムを構築するトレーダーにとって、プログラマティックなオーダーブックアクセスは、UIからは実用的でない戦略のクラスを開く。

スプレッド裁定:ブレイクアウトに先立ってエントリーするためにスプレッド圧縮を監視
流動性考慮型の実行:ブック形状がクリーンな約定をサポートする場合にのみマーケット注文をルーティング
アンチスプーフィングフィルター:シグナルウェイティングでタッチ時に引き戻される壁を割り引く
コホート条件付きブック読み取り:高PnLトレーダーが同意するセットアップにバイアスをかけるために、上記すべてをコホートポジショニングでフィルタリング

これらのいずれもUIでは実現できない。すべてがAPIに対する数百行のPythonで実現できる。

Hyperliquidのオーダーブック + コホートデータへのプログラマティックアクセスを取得 →

より大きな枠組み

UIはカジュアルな観察のために構築されている。APIは分析作業のために構築されている。ほとんどの個人トレーダーはUIを通じてマーケットとやり取りするため、ほとんどの個人トレーダーは同じパターンを見て、同じ不完全な情報に基づいて行動する。オーダーブックデータで意味のある作業を行うトレーダーは、それをプログラムで取得し、歴史的に永続化し、UIが公開しないコホートポジショニングのような構造的シグナルと組み合わせる人々である。

情報の優位性は複利的に増大する。APIを通じてブックを読むたびに、次の日にパターンを認識するのに役立つプライベートデータセットを構築している。そのデータセットこそが実際の優位性である。オーダーブックは単にデータが存在する場所である。