こんにちは、よだかです。
ここしばらく、perp（無期限先物）市場を継続的に観測するためのRadarを作っています。
開発を始めた時点では「PLI Radar」と呼んでいました。
PLIはPerp Load Imbalanceの略で、ざっくり言えば、
市場に積み上がっているポジション負荷と、その負荷を市場が処理する能力の不均衡を見る
という発想です。
ただ、実際に観測機を作り、取得するデータや検知条件を詰めていく中で、少しずつ違和感が出てきました。
どうも自分が見たいものは「Loadそのもの」ではありません。
最近は、より上位の観測対象を**Perp Market Fragility（無期限先物市場の脆弱性）**として捉えた方が、実際にやっていることを正確に説明できそうだと考えています。
今回は、その理解更新と現在の開発状況を一度整理します。
PLIからPerp Market Fragilityへ観測対象を更新する
PLIを考え始めたとき、中心にあったのは建玉残高（Open Interest、OI）でした。
市場にどの程度ポジションが積み上がっているのか。その負荷に対して市場の流動性が小さければ、急変時に大きな価格変動や清算フローが発生しやすくなるのではないか。
出発点としてはかなり単純です。
ただし、実際に観測しようとすると、
OIが増えた＝市場が脆弱になった
とは言えません。
OIが急増していても、注文板が十分に厚く、売買スプレッドも安定しているのであれば、単純に取引が活発になっているだけかもしれません。
逆にOIの変化がそれほど大きくなくても、注文板が薄くなり、スプレッドが急速に拡大しているのであれば、追加の注文フローに対して市場が弱くなっている可能性があります。
そこで現在は、
- 市場にどれくらい負荷があるのか
- その負荷をどれくらい吸収できるのか
- すでに市場にストレスが表面化しているのか
を分けて観測しています。
PLIを捨てたというより、
PLIは、より大きな「Perp Market Fragility」という観測対象の中に含まれる一つの仮説だった
と考える方が近そうです。
【PLIからPerp Market Fragilityへの概念更新】
なお、Perp Market Fragilityという言葉自体を新しく作ったわけではありません。
金融研究では、市場のFragilityは、基礎的・非基礎的なショックに対して価格反応が増幅されやすい状態として整理されています。
2025年のGoldstein、Huang、Yangによるレビュー論文でも、financial market fragilityは、ショックに対する市場価格の反応が増幅される状態として整理されています。
Fragility of Financial Markets — Annual Review of Financial Economics
今回の開発では、その一般的な概念をperp市場の短期観測へ落とし込もうとしている、と考える方が正確そうです。
見たいのは急変ではなく急変に弱い状態である
Radarで見たいのは、暴落や清算が発生したこと自体ではありません。
それなら価格変化や清算データを直接見れば済みます。
狙っているのは、その少し手前です。
追加のショックや注文フローが入ったとき、通常より大きな反応を起こしやすい市場状態を、事前に観測できないか。
この問いを扱っています。
ここでは「事前」という言葉にも注意が必要です。
現時点で、
Radarが発火すれば、その後に急変する
ことを確認できているわけではありません。
今作っているのは、
将来的な市場反応の増幅と関係があるかもしれない状態を、未来情報を使わずに継続観測する仕組み
です。
価格予測器でもなければ、清算予測器でもありません。
まして、そのまま売買注文を出すbotでもありません。
まずは市場状態を観測し、「ここは調べる価値がありそうだ」という候補を残すところまでをRadarの役割にしています。
この慎重さは、最近のperp市場研究を見ても必要そうです。
2026年7月に公開された、7件の暗号資産perp清算カスケードを調べたプレプリントでは、価格、レバレッジ、注文フローなどを比較しても、全イベントに共通する単一の事前指標は確認されていません。
イベントごとに「どこに兆候が現れるか」が異なる可能性が示されています。
少なくとも現段階では、「これ一つを見ればFragilityが分かる」という単一指標を作るより、複数の市場状態を分けて観測する方が自然だと考えています。
市場の脆弱性を三つの観測軸に分ける
現在のRadarでは、主に三つの軸を見ています。
建玉負荷を見る
一つ目は建玉残高（OI）の変化です。
ここでは、市場に残っているデリバティブのエクスポージャーが短時間でどの程度増減しているかを見ます。
ただし、OIにはかなり強い留保があります。
OIが増えたからといって、
- レバレッジが高くなった
- ロングに偏った
- 清算価格に近づいた
- 強制清算が近い
とは言えません。
現在は、OIを市場に残っているポジション負荷を見るための代理変数として扱っています。
吸収余力を見る
二つ目は注文板の厚さです。
現在は、基準価格から一定bps以内に存在する注文量を使い、その短時間変化を見ています。
板が急速に薄くなれば、同じサイズの成行注文でも価格を大きく動かしやすくなる可能性があります。
その意味で、注文板の厚さを表示上の吸収余力として使っています。
ここにも重要な留保があります。
表示されている板＝実際に約定可能なすべての流動性ではありません。
2026年のBitcoin perpetualを扱った研究では、清算カスケード時に、事前の表示板から推定される価格影響と実際の約定価格への影響との差を調べ、表示されていない流動性の存在を推定しています。
著者は、ストレス時ほど表示板厚が実際の約定可能流動性の不完全な代理になる可能性を指摘しています。
したがって、現在のRadarで測っているものを「市場の処理能力そのもの」と呼ぶのは強すぎます。
今のところは、
公開注文板から観測できる表示上の吸収余力
くらいに置いておくのが適切です。
市場ストレスを見る
三つ目は売買スプレッドです。
最良買値と最良売値の距離が急速に広がっているのであれば、市場の流動性状態に何らかの変化が起きている可能性があります。
ここでは平均的なスプレッド水準だけでなく、その市場自身の通常分布からどれくらい外れているかを見る方向で実装しています。
BISの研究では、株式、外国為替、国債市場について、平均スプレッドだけでなくスプレッド分布の歪度や尖度などを見ることで、平均的な流動性改善の裏側で極端な非流動性状態が増えているケースを分析しています。
対象市場は異なりますが、「平均値だけでなく分布の裾を見る」という発想には共通する部分があります。
【現在観測しているものと未検証領域】
この上下を混ぜないことは、現段階ではかなり重要です。
Hyperliquidをprimary reference venueとして実装する
現在、Radarのprimary reference venueとして使っているのがHyperliquidです。
ここでいうvenueは、単純な「取引場所」という意味では使っていません。
市場マイクロストラクチャの文脈では、注文が提示され、板が形成され、売買が成立する取引システムの単位をtrading venueなどと呼びます。
暗号資産では、中央集権型取引所、オンチェーン注文板、プロトコル固有のマッチングシステムなどで構造が大きく異なります。
そのため、この開発記録では、
特定の注文受付・価格形成・約定ルールとデータ取得仕様を持つ市場システムの単位
くらいの意味でvenueという言葉を使います。
「取引所」と訳すと中央集権型取引所まで含意してしまう場合があり、「取引会場」とすると物理的な場所の印象が強いため、以降はvenueのまま書きます。
また、Hyperliquidをreference venueと呼ぶのも、
Hyperliquidがperp市場全体を代表している
という意味ではありません。
あくまで、
Radarの観測方法と実装をまず成立させるための主要な参照対象
という意味です。
Hyperliquidでは公式APIから、
- L2注文板
- 最良気配
- 建玉残高
- マーク価格
- オラクル価格
などをリアルタイムに取得できます。
公式WebSocket仕様にはl2Bookやbbo、activeAssetCtxなどがあり、activeAssetCtxには建玉残高も含まれています。
Hyperliquid WebSocket Subscriptions
注文板は価格・時間優先で処理されるオンチェーンの指値注文板として実装されています。
Hyperliquid Order Book Documentation
WebSocket切断時には再接続後のスナップショット取得を前提とすることも公式仕様に記載されています。
Hyperliquid WebSocket Documentation
こうした仕様が、現在作っている観測機と比較的相性が良いです。
ただし、Hyperliquidをreference venueにしたからといって、
Hyperliquidで得た30秒OI変化の閾値を、他venueにもそのまま使う
ようなことは考えていません。
共通化したいのは数値ではなく、
- 建玉負荷
- 吸収余力
- 市場ストレス
という観測上の役割です。
何を観測値として使うか、どの時間幅を見るか、どの程度を異常と呼ぶかはvenueごとに検証する必要があります。
【reference venueと外部検証venueを分ける】
この区別は、今後かなり重要になると思います。
dYdXで同じ観測概念が成立するかを試す
現在はHyperliquidだけでなくdYdXでも観測を試しています。
dYdXにもIndexerとWebSocketがあり、リアルタイム市場データや注文板を取得する仕組みがあります。
公式ドキュメントでも、取引botや分析ツール向けにREST APIとWebSocketが提供されています。
dYdX Integration Documentation
dYdXのIndexer実装にも、v4_marketsやv4_orderbookなどのWebSocketチャンネルがあります。
ただし、実際に観測してみるとHyperliquidとはかなり事情が違います。
現時点では、
- スプレッド変化は30秒を中心に観測可能
- OIは更新が疎いため保留
- 板厚は「本当に板がゼロなのか」「取得上そう見えているのか」を区別する定義問題が残っている
という状態です。
ここから分かってきたのは、
同じperp市場でも、同じ観測概念を同じデータで表現できるとは限らない
ということです。
たとえば「建玉負荷」という概念自体はHyperliquidとdYdXで共通していても、30秒単位の変化を見るために十分な頻度でOIが更新されなければ、同じDetectorは作れません。
「吸収余力」についても、板データの取得仕様や復元方法が異なれば、Hyperliquidと同じ5bps板厚をそのまま比較してよいとは限りません。
したがって現在確認しているのは、
Hyperliquidで作ったRadarをdYdXへ移植できるか
というより、
Perp Market Fragilityという同じ観測対象を、dYdXではどの程度観測可能なのか
です。
現在走らせている検証結果次第では、
- 主要な観測venueとして残す
- スプレッドなど一部だけを見る補助venueにする
- 別のvenueへ置き換える
という可能性をすべて残しています。
dYdXを採用すること自体が目的ではありません。
絶対値ではなく市場ごとの短時間変化を見る
現在のRadarでは、OIや板厚の絶対値そのものより短時間変化を重視しています。
たとえば、
OIが1億ドルなら危険
というような判定はしていません。
BTCと小型銘柄では市場規模も通常の変動幅も違います。
そこで現在は、
venue × market × 指標 × 観測窓
ごとに分布を分けています。
Hyperliquidでは現在、
- OI変化：30秒・60秒
- 板厚変化：30秒・60秒
- スプレッド変化：30秒中心
を残しています。
dYdXでは現時点でスプレッド変化の30秒が中心です。
この分布の裾を使って、
その市場自身の通常状態から、どの程度外れた変化なのか
を見る設計です。
ここでもまだ、本番用の異常判定閾値を決めたわけではありません。
現在残っているDetector候補は、
- 建玉負荷の上昇
- 吸収余力の低下
- スプレッド拡大
- 建玉負荷上昇＋吸収余力低下
の四つです。
最後の、
建玉負荷↑ × 吸収余力↓
が、もともとのPLIに最も近い状態です。
つまりPLIは消えたのではなく、Perp Market Fragilityを見る複数Detectorの一つとして残っています。
データが取れたことと観測できたことを分ける
Radarを作っていて思った以上に時間を使っているのが、データ品質の部分です。
数字が取得できたからといって、そのまま観測値として使えるわけではありません。
たとえば注文板なら、
- 必要な価格帯全体を取得できているか
- 一部だけ欠落していないか
- 接続切断前後の状態を誤って比較していないか
- 古い値を現在値として使っていないか
を区別する必要があります。
板の取得に失敗した状態を、
板厚ゼロ
として処理すれば、存在しないFragilityを大量に検出することになります。
そのため現在のRadarでは、値そのものだけでなく、
- 有効
- 部分取得
- 古い
- 観測準備未完了
といった状態も管理しています。
接続が一度切れた場合も、切断前のデータと復旧後のデータをそのままつないで変化量を作りません。
こうした処理を入れていくと、Radar開発のかなりの部分が、
異常を見つける処理より、正常に観測できていることを保証する処理
になります。
これは実際に作ってみるまで、あまり強く意識していなかった部分でした。
三日間の独立Runで観測量の安定性を確かめる
10月5日から、現在の仕様を固定したまま長時間Runを開始しています。
今回は24時間のRunを3本、独立した単位として連続実行します。
72時間分を最初から一つのデータとしてまとめないのは、日をまたいで同じ分布が再現されるかを比較したいからです。
今回確認するのは主に、
- 30秒・60秒の変化分布が日をまたいでも安定するか
- 以前の分布から作った候補閾値を新しい日のデータへ固定適用すると、何回程度発火するか
- 30秒と60秒の発火がどの程度重なるか
- OI上昇と板厚低下が同時に発生する頻度
- スプレッドをbpsで測る現在の方法が市場ごとに安定しているか
- dYdXを今後も主要な観測venueとして使えるか
です。
ここでも、今回のRunで「儲かる閾値」を探すことはしません。
閾値を変えたり、Detectorを増やしたり、結果を見て後から条件を合わせたりもしません。
現在の観測定義を固定した状態で、
そもそも同じものを複数日にわたって安定して測れているのか
を確認します。
【現在の開発位置】
今回はかなり地味な段階です。
ただ、観測器を作る以上、この辺りを飛ばしてしまうと、
たまたま一日のデータに合ったDetector
を作ってしまう可能性があります。
ここには、もう少し時間を使う必要がありそうです。
Perp Market Fragilityを検知できたとはまだ言わない
ここまで実装を進めたことで、最初よりは観測対象がかなり明確になりました。
一方で、現時点で分かっていないことも多くあります。
まず、
このRadarが本当にPerp Market Fragilityを検知できているかは未確認です。
今見ているのはFragilityと関係しそうな状態変数です。
まだ、
- Detector発火後に価格反応が本当に増幅するのか
- 清算や強制フローが増えるのか
- 方向予測に使えるのか
- 実際の取引機会につながるのか
- OI・板厚・スプレッドの三軸で十分なのか
- Hyperliquid以外へ一般化できるのか
は確認できていません。
特に、板厚については表示注文板だけでは実際の約定可能流動性を完全には捉えられない可能性があります。
OIについても、レバレッジや清算距離を直接測っているわけではありません。
スプレッドも、Fragilityを作る原因ではなく、すでに市場ストレスが表面化した結果である可能性があります。
この三つを一つの「Fragility指数」にまとめるところまでは、まだ進めていません。
むしろ現段階では無理にまとめず、
建玉負荷
表示上の吸収余力
市場ストレス
を別々に観測し、その関係を見る方が良さそうです。
PLIという名前で開発を始めましたが、実装を進める中で、
見たかったのはLoadそのものではなく、市場が追加のショックをどの程度吸収できる状態にあるのか
だったことが少しずつ整理されてきました。
ただし、その状態をPerp Market Fragilityとして実際に観測できているかは、まだ別の問いです。
まずは現在走らせている三日間のRunを待ちます。
そこから先で、Detectorの閾値や、その発火後に市場で何が起きているのかを見ていくことになりそうです。
それでは、また。
関連記事
- 🛠️開発記録#574(2026/9/19) PLI研究の一区切り──清算を追う研究から市場ストレスの観測へ
今回の直接の前段です。PLIを売買シグナルではなく、市場ストレス候補を拾う観測機へ切り替えた時点の整理です。 - 🛠️開発記録#570(2026/9/15) 追加研究の限界価値を考える回：市場横断観測機の作成を通して
BinanceからHyperliquidへの価格伝播などを調べたCross-Venue Fragility研究です。同じFragilityという言葉を使っていますが、こちらはvenue間の伝播を扱い、今回の記事では個々のperp市場内部の状態を扱っています。 - 🛠️開発記録#572(2026/9/17) 清算エッジ探索をどうフェーズシフトするか？
「見えること」と「実際に取れること」を分けて考え始めた記事です。今回のRadarでも、異常候補を観測できたことと、それが取引可能なedgeであることは分けて検証します。