清算指標の使い方

清算指標の符号と分布を読み、よくある二つの読み違いを避けて、戦略に組み込む。

急落の後、清算履歴にとても深いマイナスの棒が出た——多くのロングが強制決済されたのか、それともこの銘柄の数値はもともとマイナスに偏りがちなのか。0 はその銘柄の平常の水準ではなく、この点がこの棒の読み方を決めます。価格帯ごとの清算マップを見ているなら、それは別の推定です。清算マップの読み方を参照してください。

清算指標とは？

清算指標は、一定期間にショートとロングのどちらが多く強制決済されたか、その差がどれだけ異常かを測る Blave 独自の指標です。清算とは、レバレッジをかけたポジションが取引所に強制決済されることです。ロングが強制決済されると取引所は売り注文を出し、ショートが強制決済されると買い注文を出します。

正の値はショートの清算が多く、負の値はロングの清算が多いことを示し、0 はその銘柄の平常の水準ではありません。数値に上限・下限はありません：

分布は非対称で、下側（ロングの清算）が上側より深くなっています。以下は Blave が実測した分位数で、1 時間足、timeframe 24h、期間 2024-09-15〜2026-09-14、1 時間ごとに 1 つの値（n = 17,520）です：

最も重要な二点

0 はその銘柄の平常の水準ではない

0 より大きい値はショートの清算がロングより多く、0 より小さい値はロングの清算がショートより多いことを示します。ただし、長期的にロングの清算が多めの銘柄は数値が系統的にマイナスに偏るので、0 はその銘柄の「平常の水準」ではありません。

上の測定期間（1 時間足、timeframe 24h）で 0 を上回った時間の割合は、上の表のとおりです。同じ 0 でも、BTC ではほぼ中央値ですが、DOGE ではすでに大半の時間よりショート清算寄りです。

元データはサンプリングで、大きな相場では過小評価される

取引所が公開する強制決済データには配信の上限があり、同じ時刻の大量の強制決済がすべて送られるわけではありません。そのためこれはサンプリングで、相場が激しいほど過小評価が大きくなります。データが途切れている間、数値はその期間に清算がなかったかのように見え、データ欠損とは表示されません。

ですから、一本の棒の深さを正確な清算規模とみなさず、その銘柄自身の分布のどちらの端にあるかを見てください。

清算データで戦略をどう作る？

現在、清算データを使う公式戦略はないため、以下の三つの使い方はすべて例示で、バックテストしていません。コード中のしきい値は上で実測した分位数を出発点として借りたもので、パラメータスキャンの結果ではありません。スキャン方法はしきい値のスキャン方法を参照してください。

1. 非対称なしきい値：清算が集中した期間に印を付ける

最も直接的なのは、数値が分布の両端に入った期間に印を付ける方法です。下側の裾が深いので、両側に同じ絶対値のしきい値を使わないでください。BTC なら p1 は約 −3.8、p99 は約 +3.3 です。

LONG_FLUSH_TH  = -3.8   # 例示：BTC 1h × 24h の p1 付近
SHORT_FLUSH_TH = 3.3    # 例示：BTC 1h × 24h の p99 付近

liq = fetch_liquidation(SYMBOL, INTERVAL, START, END, hdrs, timeframe='24h')
df['LIQ'] = liq['alpha']
long_flush  = df['LIQ'] <= LONG_FLUSH_TH    # ロング清算の集中
short_flush = df['LIQ'] >= SHORT_FLUSH_TH   # ショート清算の集中

印を付けたあとどう取引するかは自分で研究してください。清算が集中したあとに価格が反転するのか継続するのか、Blave は検証していません。分位点は銘柄によっても違い、ETH、SOL、DOGE の p1 はいずれも BTC より深いので、銘柄を変えたら計算し直します。

2. 0 ではなく、その銘柄自身の分位点をしきい値にする

0 は均衡点ではないので、「0 より大きければショート清算が多い」という書き方は、DOGE のように長期的にマイナス寄りの銘柄では歪みます。代わりにその銘柄の過去一定期間の分位点をしきい値にすると、長期的な偏りの影響を受けにくくなります。

# 例示：過去 180 日の分位点をしきい値に。窓の長さはスキャンしていない
lo = df['LIQ'].rolling('180D').quantile(0.01)
hi = df['LIQ'].rolling('180D').quantile(0.99)
extreme = (df['LIQ'] <= lo) | (df['LIQ'] >= hi)

窓が短すぎると、しきい値が直近の相場に引きずられて漂います。また、窓をその銘柄のデータが出始めたばかりの区間（BTC、ETH は 2023-01 ごろ）にかけないでください。その区間の数値はまだ安定しておらず、偽の極端値が算出されます。

3. リスク管理：清算が集中している間は新規エントリーを控える

より保守的な使い方は、既存戦略のエントリー条件に加えるものです。数値がどちらかの端に入っている間は新規ポジションを持ちません。使い方 1 の二つのしきい値を流用し、compute_entry は元の戦略のエントリー条件に置き換えてください。

# 例示：数値がどちらかの端にあるときはエントリーしない
flush = (df['LIQ'] <= LONG_FLUSH_TH) | (df['LIQ'] >= SHORT_FLUSH_TH)
entry = compute_entry(df) & ~flush

この組み合わせはバックテストしておらず、清算の集中を避けると成績が改善するかも検証していません。「清算の波が来たばかり」を新規エントリーを止める条件にしているだけです。

timeframe と足の周期はどう選ぶ？

清算指標の設定は二つあります。timeframe はどれだけの期間の清算を見るかで、15min、1h、4h、8h、24h、3d から選べ、既定は 24h です。周期（period）は値を取る頻度を決め、5min、15min、1h、4h、8h、1d から選べます。timeframe を変えると分布も変わります。同じ期間を timeframe 1h（1 時間足）で測ると次のとおりです：

24h と比べると、1h は両端が狭く、中央値はどの銘柄も 0.00、0 を上回る割合も半分に近くなります。しきい値は timeframe に合わせて計算し直し、一方の数値をもう一方に流用しないでください。15min、4h、8h、3d は本文では測定していません。

しきい値はどうスキャンする？

分位数は出発点にすぎません。ロング側とショート側のしきい値にそれぞれ候補値を一列並べ（例：p1、p2、p5 対 p99、p98、p95）、組み合わせごとにバックテストし、最も高い一マスではなく、成績がどれもそこそこ良い一帯を選びます。

results = []
for q_lo in [0.01, 0.02, 0.05]:
    for q_hi in [0.95, 0.98, 0.99]:
        lo = df['LIQ'].rolling('180D').quantile(q_lo)
        hi = df['LIQ'].rolling('180D').quantile(q_hi)
        extreme = (df['LIQ'] <= lo) | (df['LIQ'] >= hi)
        entry = compute_entry(df) & ~extreme
        results.append((q_lo, q_hi, backtest(entry)))   # backtest は自分のバックテスト関数に置き換え、どの組み合わせも手数料を引いてから比べる

timeframe、銘柄、足の周期のどれかを変えたらスキャンし直してください。最高点ではなく平坦な一帯を選ぶ理由は過剰最適化を避けるを参照してください。

データスタジオではどこで見る？

どの指標と組み合わせる？

以下は組み合わせの考え方で、検証済みの結論ではありません。

API や Blave Agent でデータを取るときの注意点は？

清算指標のエンドポイントは GET /liquidation/get_alpha で、パラメータは symbol、period、timeframe（既定 24h）と開始・終了日（start_date、end_date）です。Blave Agent では fetch_liquidation が対応します。返されるのは確定済みの足だけで、項目は timestamp、alpha、stat、1 年を超える期間は自動で切り詰められます。最も早い銘柄（BTC、ETH）のデータは 2023-01-01 からで、それ以前の数値は 0 です。他の銘柄はさらに遅いことがあります。データが出始めたばかりの区間の数値はまだ安定していないので、しきい値の設定に使わないでください。

get_alpha の stat オブジェクトは最新の数値について説明します：

清算マップ、マップ変化、取引所別集計のエンドポイントとフィールドは清算マップの読み方を参照してください。