清算ウォッシュアウト：売り圧力の枯渇と清算連鎖の継続を区別する

実践の流れ

1. スキーマを確認するポジション側、約定規模、および破産価格を別々に表示します。
2. バーストを特定する過去の基準値と絶対的な最小値を使用してください。
3. 価格推移を観察するK内での侵入と回収が必要です。
4. 圧力の枯渇を検証強度は低下するが、新たな最低値は現れない。
5. 取引、または継続候補を記録サンプルには、競合する両方の分岐を含める。

強制的なポジション決済は価格底値シグナルではない

ウォッシュアウトとは、強い強制的なポジション圧力の後に回復が見られる現象を指します。疲弊は、その後の挙動を通してのみ評価できます。価格が動き続ける場合、継続または連鎖が関連する競合仮説となります。検出器は、うまく終了した清算を後から選択するのではなく、両方の分岐を保持する必要があります。

Bybit allLiquidationでは、Sをポジション側（Buy：ロングポジションが清算されたことを意味し、pは破産価格[1]）と定義しています。一方、PublicTradeでは、Sをテイカー側（[2]）と定義しています。そのため、同じフィールド名でも解釈が異なります。破産価格にサイズを乗算し、その結果を「実際に執行された名目値」と表記すると、データが誤って表示されます。

清算ヒートマップは、脆弱な価格帯を推定することが多く、イベントフィードは、取引所の製品カバレッジ内で発生した事象を報告します。色分けされたレベルは、必ずしも保留注文を示すものではありません。清算取引が既に取引記録に反映されている場合は、清算取引量を総取引量に再度加算しないようにしてください。

爆発、浸透、回収、強度の低下

提案する強気反転では、イベント前から既知の支持水準 S、事前の A=ATR14、buffer=max(2 ticks,0.10A) を固定する。イベント時刻の一分間ごとに、清算されたロング建玉の数量を集計する。バーストは、該当する活動レジームの過去の第99百分位を超え、かつ銘柄ごとの絶対最小数量以上でなければならない。過去の窓の多くがゼロなら、百分位条件だけでは不十分である。

価格が S−buffer を下回った後、K=3 本以内に終値が S+buffer を上回って戻ることを要求する。直近の確定済み一分間の清算数量は、最初のバーストの半分未満であり、少なくとも N=1 本の確定済み足でイベント安値を更新していない必要がある。K、N、百分位、半分という比率、絶対下限は提案パラメータである。各条件は、必要な窓が完了して初めて利用できる。

水準を回復しない清算バーストや、清算の強度が持続しながら安値を更新し続ける動きは、継続候補に分類する。清算数量が大きいだけで買ってはいけない。弱気版ではショート建玉の清算、抵抗水準の上抜け、その後の抵抗水準より下への回帰を使う。

ローリングストリームは、複数の重複するバーストを生成する可能性があります。event_id を 1 つ割り当て、新しいバーストが古いイベントを延長するか、クールダウン後に別のイベントを開始するかを指定します。このベースラインは、K を繰り返しリセットして、敗北反転仮説を無期限に維持することはありません。

on_completed_minute(t):
  if not price_and_liquidation_window_received(t): return
  if not valid_prior_percentile_ATR_and_support(t): return
  long_liq = sum(normalized_long_liquidated_size in minute t)
  burst = long_liq>past_p99 and long_liq>=minimum_size
  if no_active_event:
    if burst and low[t]<support-buffer and cooldown_satisfied:
      start_event_once(t,support=support,buffer=buffer,low=low[t],
                       burst_size=long_liq,expiry=t+3)
    return
  if t>event.expiry:
    expire(); return
  prior_low = event.low
  no_new_low = low[t]>=prior_low
  event.low = min(prior_low,low[t])
  if close[t]>event.support+event.buffer and long_liq<0.5*event.burst_size
       and no_new_low and t>event.start:
    signal_at_received_close(t); consume_event()
  elif low[t]<prior_low and intensity_persists:
    record_continuation_observation()
# A new burst inside the event never resets its original start or expiry.

単位、データの利用可能時刻、建玉残高

正規化されたサイズ、または明示的に推定された想定元本を選択してください。契約の数量表記規則を適用し、線形商品と逆商品に同じ換算方法を使用しないでください。中間価格を使用して値を近似する場合は、結果を推定想定元本と呼んでください。メッセージには複数のイベントを含めることができ、スナップショットラベルは、注文板スナップショットのように過去の清算集計を消去する必要があることを意味するものではありません。

受信時刻とイベント時刻の両方を保持してください。遅延したメッセージは、取引所のタイムスタンプが古いという理由だけで、以前の取引を承認することはできません。変動時に欠落したデータは欠落したままにしておく必要があります。それをゼロの清算で置き換えると、見かけ上の枯渇が生じてしまいます。

OI は任意の補助情報である。Bybit は両側を合計した openInterest と片側の singleOpenInterest を区別し、リニア商品とインバース商品では単位も異なる。極端な変動時にはエンドポイントが遅延する場合がある [3]。同じフィールドとスキーマ版を一貫して使用する。OI の減少だけでは、損失を受けた側も次の価格方向も特定できない。

後期の期間をカバーする OI 観測値を、急速な清算シグナルと同時発生的なものとして扱わないでください。データは利用可能時間を使用して結合し、最新の観測値の経過時間を保持してください。そうしないと、一見有益な OI の下落が、アクセス可能になる数分前にモデルに組み込まれてしまう可能性があります。

合成反転と合成継続の例

support=100、事前の ATR=2、tick=0.05 とすると、バッファは 0.20 となる。バーストの一分間にロング建玉の清算数量が 120 単位となり、過去の p99=80 と下限 50 を上回り、価格は 98.80 に達する。次の一分間は 40 単位、安値 99.00、終値 100.30 である。強度は半分を超えて減少し、安値の更新はなく、回復閾値を上回った。

100.35 で買い、ストップ 98.60、目標 103.85 とすれば、リスク 1.75、潜在リワード 3.50、費用前で 2R となる。最初に利用できる気配値が既に 101.40 なら、リスクは 2.80、その目標までのリワードは 2.45 となる。事前に定めた最小リワード／リスク比 1.5 に満たないため、未発注の注文を却下する。利用できなかった以前の終値で約定したと仮定してはならない。

継続例では、120 単位のバーストの後に 180 単位、安値 97.60、終値 98.00 が続く。水準回復がなければウォッシュアウトのエントリーもない。別の経路では、第二の清算波より前に有効なエントリーが成立している。98.60 の防御ストップが 98.30 で約定すると、100.35 からの損失は 2.05 となる。フィルターはすべての清算連鎖を除けず、損失を知った後に過去のシグナルを書き換えてはならない。

確認後のエントリーと流動性リスク

必要な確認データをすべて受信してからのみ送信してください。保護ストップは、event_lowから凍結バッファを差し引いた値です。ターゲットは既知のスイングまたは同時期のVWAP参照値でも構いませんが、残りの利益が不十分な場合は、事前のルールに従って拒否する必要があります。ポジションサイズは、正確な底値を捉えたいという欲求ではなく、ストップ距離と予想コストに基づいて決定されます。

一つの清算連鎖の中で、無制限のナンピンや再エントリーを繰り返すことを避ける。複数回の試行を許可する戦略では、個々の注文の名目リスクだけでなくイベント全体のリスクと費用を測る。新しい候補が発生しても、以前の損切り記録を消してはならない。

スプレッドの拡大、板厚の縮小、処理の遅延により、ストップ注文の執行がトリガーからずれることがあります。意図したサイズの板厚で成行注文をシミュレーションしてください。イベントフィードは清算に関する証拠であり、反転エントリーに必要な流動性が確保されることを保証するものではありません。

確認情報が取引に利用可能となる前に価格が予定目標まで回復したなら、機会を逃したと記録する。非常に速い反発では特に重要である。遅い確認後のエントリーについて、後から得られる枯渇の証拠を利用しながら、それより前の反発による収益も得たと主張することはできない。

継続は重要な対照群である

価格のみのスイープ/水準回復、水準回復なしのバースト、水準回復ありのバーストの3つのグループを作成します。清算データが価格変動以外の情報を提供するのか、それとも単にボラティリティが高いものだけを選択するのかを検討します。水準回復なしのグループは、宣伝用の例でしばしば見落とされている持続的な連鎖反応を測定します。

フィードのカバレッジ、欠損した分、イベント数、取引数、未約定、費用控除後の期待損益、ドローダウン、裾野の大損失を報告する。取引費用、ファンディング費用、遅延は取引所に合わせる。後から収集した履歴データには、実稼働システムでは間に合わなかったイベントが含まれる場合がある。

時系列順に分割し、1 つのカスケード内のすべてのバーストを同じフォールドに保持します。隣接するフロア、パーセンタイル、タイムアウトをテストします。ボトムキャッチの成功例やいくつかの P&L のスクリーンショットだけでは、完全なメソッドを検証することはできません。堅牢性には、代替のフィード品質の仮定と、データ障害のために取引不能になったイベントの記録を含める必要があります。

よくある落とし穴

この手法を使う前のチェックリスト

ご自身のデータで確認した項目にチェックを入れてください。進捗はこのブラウザに保存されますが、戦略の収益性を認定するものではありません。

• 清算された建玉の側と、テイカー側を混同していない。
• 推定想定元本は正しくラベル付けされ、正規化されています。
• フィード間隔が欠落した場合、ゼロイベントで置き換えられることはありません。
• サポートとATRは、バースト発生前から存在していました。
• エントリーは必要な確認データをすべて受信した後である。
• 複合側と片側OIは混在しません。
• 清算連鎖が継続する例も対照サンプルに保持している。

研究資料

各資料は、その横に記載された定義や根拠を支えています。擬似コード、架空の例、提案パラメータは別途検証が必要です。

1. All LiquidationBybit. 取引所の対応範囲と、建玉の側、清算数量、破産価格の各フィールドを確認した。 確認日: 2026-10-11.
2. Public TradeBybit. スキーマの混同を避けるため、テイカー側と約定価格の意味を確認した。 確認日: 2026-10-11.
3. Get Open InterestBybit. OI の単位、二つの OI フィールド、API 遅延に関する注意を確認した。 確認日: 2026-10-11.

関連する手法