3行のコードがポジションを守った: Hyperliquidの清算リスクアラート

8月27日、HYPEは時価総額約189億ドルで史上最高値86.71ドルを記録した。同じ時間帯に、Hyperliquid上のロング側清算額は24時間で2,188万ドルに達した。ラリーに乗っていたレバレッジロングが急激な日中リバーサルで吹き飛ばされたからだ。建玉残高(OI)は時価総額196.3億ドルに対して34.7億ドルで、時価総額比のレバレッジエクスポージャーは約17.7%に達していた。

この数字が示すのは重要な事実だ。市場が最も熱狂していた瞬間、市場の建玉残高のかなりの割合が強制決済の直前に迫っていた。清算リスクアラートを組み込んでいたトレーダーは、強制清算が起きる数時間前から圧力が高まっていることを把握していた。そうでないトレーダーは、ポジションが消えて初めてそれを知った。

この記事では、HyperTrackerのAPIを使ってHyperliquid上の清算リスクアラートを実際に構築する方法を解説する。動作するPythonコード、コホートの重大度でルーティングするティアード・アーキテクチャ、そして孤立したスパイクと広範なデレバレッジイベントを区別するマルチアセット相関検出器を提供する。

清算リスクエンドポイントが返すデータ

HyperTrackerの清算リスクエンドポイントはGET /api/external/{segmentId}/assets/liquidation-riskにある。16のコホートセグメントIDのいずれかを渡すと、そのコホートがオープンポジションを持つすべてのアセットをリスクエクスポージャー順にランキングして返す。各アイテムには3つのフィールドが含まれる。

• totalValue: そのコホートにおけるアセットの建玉残高合計
• riskValue: 清算閾値の75%以内にあるポジションのドル額
• percentRisk: 総エクスポージャーに対するリスク額の比率

16のコホートは2つの軸に分かれる。8つはパープエクイティでウォレットを分類(Shrimp から Leviathan)、8つは全期間PnLで分類(Money Printer から Giga-Rekt)。LeviатhanのETH上のpercentRiskが急騰した場合、強制決済の規模は市場を動かすほど大きい。Shrimpコホートが急騰した場合はノイズだ。この非対称性こそ、すべてのコホートを横断した単純な平均値がアラートとして無意味な理由であり、ティアード・ルーティングが重要な理由でもある。

コホートインパクトによるティアードアラートの構築

最もシンプルな清算リスクモニターはすべてのコホートを同等に扱う。しかしそれは誤ったアプローチだ。Leviathanの清算とFishの清算が市場に与える影響は、桁が違うからだ。より優れたアプローチは、各コホートが持つ想定エクスポージャーに基づいてティアを割り当て、ティアごとに異なるルーティングを行うことだ。

Tier 1: クリティカルコホート

Leviathan(セグメントID 7)、Tidal Whale(ID 6)、Money Printer(ID 8)。これらはプラットフォーム上で最大のウォレットと最も収益性の高いトレーダーを表す。彼らのポジションが清算付近に集中すると、強制売却の規模が連鎖的な価格変動を引き起こす可能性がある。即座にアラートを発火させ、ポジションの自動削減を検討すること。

Tier 2: 警告コホート

Whale(ID 5)、Small Whale(ID 4)、Smart Money(ID 9)。意味のある資本規模だが、単独でカスケードを引き起こす可能性は低い。手動レビューとストップ管理の引き締めのためにアラートを出す。

Tier 3: 情報提供

その他すべて: Apex Predator(ID 3)、Dolphin(ID 2)、Fish(ID 1)、Shrimp(ID 16)、残りのPnLコホート(ID 10〜15)。これらは時系列データベースにバックテストとリサーチ用として記録するが、アラートチャンネルにはプッシュしないこと。すべてに反応するアラートシステムは、やがて誰にも無視されるシステムになる。

以下がPythonの実装だ。各ティアのコホートをポーリングし、重み付きスコアを計算して適切なアラートチャンネルにルーティングする。

import requests, time

API_BASE = "https://ht-api.coinmarketman.com/api/external"
TOKEN = "YOUR_JWT_TOKEN"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}

# Tier definitions: cohort_id -> (name, weight)
TIER_1 = {7: ("Leviathan", 2.0), 6: ("Tidal Whale", 1.5), 8: ("Money Printer", 1.3)}
TIER_2 = {5: ("Whale", 1.0), 4: ("Small Whale", 0.8), 9: ("Smart Money", 1.2)}
TIER_3_IDS = [3, 2, 1, 16, 10, 11, 12, 13, 14, 15]

def get_risk(segment_id):
    url = f"{API_BASE}/{segment_id}/assets/liquidation-risk"
    resp = requests.get(url, headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["items"]

def weighted_score(coin, tier):
    total_w, w_sum = 0, 0
    for seg_id, (name, weight) in tier.items():
        assets = get_risk(seg_id)
        match = next((a for a in assets if a["coin"] == coin), None)
        if match:
            w_sum += match["percentRisk"] * weight
            total_w += weight
    return w_sum / total_w if total_w else 0

def scan():
    all_assets = get_risk(7)  # use Leviathan as asset index
    for asset in all_assets:
        coin = asset["coin"]
        t1 = weighted_score(coin, TIER_1)
        t2 = weighted_score(coin, TIER_2)
        if t1 >= YOUR_CRITICAL_THRESHOLD:
            send_critical_alert(coin, t1)
        elif t2 >= YOUR_WARNING_THRESHOLD:
            send_warning_alert(coin, t2)

while True:
    scan()
    time.sleep(300)  # 5-min poll matches API refresh

閾値と重みについて一言。 上記のティア割り当てと重みは例示的な出発点に過ぎない。HyperTrackerはウォレットをコホートに分類する。特定のアラート閾値、ポジションサイジングルール、リスク管理パラメータを規定するものではない。閾値と重みはいずれも、自身のリスク許容度とバックテストの結果に基づいてキャリブレーションすること。

マルチアセット相関スパイクの検出

単一アセットの孤立したスパイクと、BTC、ETH、SOLが同じコホートで同時に清算リスクが上昇する状況は根本的に異なる。後者はより広範なデレバレッジのシグナルだ。この違いが重要なのは、相関したスパイクはポートフォリオ内の複数ポジションに同時に強制売却が発生し、ダメージが複合的に拡大するからだ。

検出ロジックはシンプルだ。各アセットの重み付きリスクスコアを計算した後、同時に閾値を超えているものの数を数える。その数が第2の閾値を超えた場合(例えば、3つ以上のアセットが同時に上昇した場合)、アラートの重大度を引き上げる。

def detect_correlation(tier, threshold):
    """Count assets above threshold in a given tier."""
    all_assets = get_risk(list(tier.keys())[0])
    elevated = []
    for asset in all_assets:
        score = weighted_score(asset["coin"], tier)
        if score >= threshold:
            elevated.append((asset["coin"], score))
    return elevated

elevated = detect_correlation(TIER_1, YOUR_CRITICAL_THRESHOLD)
if len(elevated) >= 3:  # example threshold - calibrate to your model
    send_correlated_alert(elevated)  # highest severity

なぜこれが重要なのか。2026年8月後半のラリーを例に考えてみよう。HYPEが史上最高値を記録する一方で、すべての時間足でロング側の清算が支配的だった。アラートシステムが個別のアセットだけを監視していた場合、BTC、ETH、HYPEそれぞれについて独立したアラートが発火し、いずれも通常のスパイクとして分類されていただろう。相関検出器があれば、3つ全体にまたがるパターンを認識し、単一の高重大度アラートにエスカレートしていた。「ポートフォリオ全体で広範なロング清算圧力が高まっている」と。

リスクスコアとコホートバイアスの組み合わせ

清算リスクは圧力が高まっていることを教えてくれる。しかし方向は教えてくれない。そこでバイアスエンドポイントの出番だ。HyperTrackerのGET /api/external/{segmentId}/biasは、特定のアセットに対してコホートがネットロングかネットショートかを返す。2つのエンドポイントを組み合わせることで、アラートシステムに方向性のコンテキストが加わる。

• 清算リスク高 + コホートがロング寄り = 強制売却が発生すれば価格は下落する
• 清算リスク高 + コホートがショート寄り = 強制買い戻し(ショートスクイーズ)が価格を押し上げる

この違いは対応を変える。ロングポジションを保有していて、Leviathanコホートも清算リスクが高い状態で大きくロングに傾いている場合、潜在的なカスケードと同じ方向にいることになる。それはポジション縮小のシグナルだ。しかしLeviathanがリスク上昇の状態で大きくショートに傾いている場合、ショートスクイーズはむしろあなたのロングポジションに有利に働く可能性がある。

def get_bias(segment_id, coin):
    url = f"{API_BASE}/{segment_id}/bias"
    resp = requests.get(url, headers=HEADERS)
    data = resp.json()
    match = next((a for a in data["items"] if a["coin"] == coin), None)
    return match["bias"] if match else "neutral"

# In your alert handler:
coin, score = "ETH", weighted_score("ETH", TIER_1)
if score >= YOUR_CRITICAL_THRESHOLD:
    bias = get_bias(7, coin)  # Leviathan bias
    msg = f"ALERT: {coin} risk={score:.1f}%, Leviathan bias={bias}"
    send_critical_alert(msg)

ポーリングからWebhookへのアップグレードパス

上記のコードサンプルはすべてRESTポーリングを5分間隔で使用しており、HyperTrackerのデータ更新サイクルと一致している。Pulseティアアカウント($179/mo)にとって、これが正しいアーキテクチャだ。データを取得し、スコアリングし、必要であればアラートを発火させ、スリープして繰り返す。

ただしポーリングには構造的な弱点がある。アラートのレイテンシはポーリング間隔とコンピューティング時間の合計になる。最後のポーリング直後にリスクスパイクが発生した場合、最大5分間それを検知できない。ほとんどのリスク管理ユースケースではこれで十分だが、自動ポジションサイジングや高頻度戦略には不十分だ。

アップグレードパスはWebhookによるデリバリーで、Flowティア($799/mo)以上で利用できる。Webhookを使えば、HyperTrackerはデータを更新した直後にリスクデータをエンドポイントにプッシュするため、ポーリングループが完全に不要になる。コードはシンプルになり(スケジューラもスリープサイクルも不要)、レイテンシはネットワーク通信時間まで低下する。

Streamティア($1,999/mo)では、WebSocket接続が継続的な更新を提供する。パターンはリクエスト-レスポンスからイベント駆動型に変わる。リスク変化をサブスクライブし、到着次第処理し、ほぼリアルタイムでアラートを発火させる。

まずポーリングから始め、必要になったらアップグレードする。 Pulseティアの$179/moで、動作するアラートパイプラインを構築するのに必要なものはすべて揃う。5分ごとのポーリングはほとんどのリスク監視に十分だ。Webhookまたは WebSocketへの移行は、低レイテンシが必要になったとき、つまり通常人間よりも速く調整する自動ポジション管理を実行するときだけ検討すればよい。

閾値のキャリブレーション: ヒストリカルデータによるバックテスト

どんなアラートシステムも、難しいのはコードではなく閾値だ。低すぎると誤検知に溺れる。高すぎると重要なカスケードを見逃す。

HyperTrackerは約4週間のヒストリカルコホートメトリクスデータを提供しており、最近の市場状況に対して閾値をバックテストするには十分だ。アプローチはヒストリカルリスクスコアを取得し、価格データと重ね合わせて、大きな価格変動に先行したpercentRiskの値を特定することだ。

実践的なキャリブレーションのワークフロー:

1. BTC、ETH、最も取引頻度の高いアセットについて、Tier 1コホートの4週間分の日次リスクスナップショットを取得する
2. 大きなドローダウンが発生した日付をマークする(24時間以内に10%以上の値動き)
3. 各ドローダウン前のポーリング間隔で、重み付きpercentRiskがどの水準にあったかを測定する
4. 日常的な変動で毎日発火せずに、ほとんどのドローダウンの前に発火していたであろう水準にアラート閾値を設定する

これは一度やれば終わりの作業ではない。市場構造は変化する。レバレッジへの食欲はセンチメントとともに変動する。8月初頭の慎重な調整後の局面(HYPEが30日間で約20%下落していた時期)に機能した閾値は、同月後半にHYPEを史上最高値に押し上げた熱狂的なラリー中には必ずしも機能しない。最低でも月に1回はキャリブレーションを見直すこと。

本番環境への展開

動作するアラートパイプラインには、コアスコアリングロジック以外にもいくつかの要素が必要だ。

• 永続的な状態管理: 閾値を下回る場合でも、計算したすべてのリスクスコアを保存する。ヒストリカルスコアがキャリブレーションデータセットになる。シンプルな時系列データベース(InfluxDB、TimescaleDB、プロトタイピングならSQLiteでも可)が機能する。
• 重複排除: コインが3回連続のポーリングで閾値を超えた場合、同じメッセージを3回送るのではなく「依然として上昇中」フラグ付きのアラートを1回送る。アラート疲労はあらゆる監視システムの有用性を破壊する。
• クールダウンロジック: アラートが発火してトレーダーが対応した後、設定可能なクールダウン期間中は同じアセットの再アラートを抑制する。そうしないと、すでに対処済みのリスクについてシステムがしつこく通知し続ける。
• ダッシュボードオーバーレイ: リスクスコアを価格データと並べてGrafanaやRetoolに流し込む。視覚的なパターン認識はログ出力を読むより速く、閾値キャリブレーションを直感的にする。

清算リスクアラートパイプラインを構築する

HyperTrackerのAPIは16の行動コホートにわたって事前計算済みの清算リスクスコアを提供する。コホートごとに1回のRESTコール、5分ごとに更新される。まず無料ティアで試し、本番アラートの準備ができたらPulse($179/mo)にスケールアップしよう。

APIキーを取得する

清算のカスケードは事前に予定を教えてくれない。祝日の週末、オラクルの不一致、そしてレバレッジが過密になったまさにその瞬間に発生する。それを生き延びるトレーダーたちに一貫して共通するのは一つだけだ。価格が動く前に、圧力が高まっていることを知っていた。適切なエンドポイントをポーリングし、適切なコホートで重み付けし、適切なチャンネルにルーティングする数行のコード。それがスマートフォンへのアラートと、受信トレイへの清算通知の違いだ。