DeFi借入の清算を避けるには｜Aaveポジションの監視とアラートの決め方

ある事業者の財務チームが、Aaveで暗号資産を担保に借入をしていました。ある深夜、担保の価格が急に下がります。監視のアラートは出ていました。けれど当番の担当者が気づき、返済用の資金を用意し、署名者をつかまえたころには、ポジションはもう清算されていました。

アラートが鳴っていたのに、なぜ間に合わなかったのか。気づいてから手を打ち終えるまでには、判断、資金の用意、署名、送信、確定と、いくつもの手順があります。警報の線が清算の線に近すぎると、その時間が残りません。

清算を避ける鍵は、プロトコルの清算線そのものではありません。その手前に引く3本の線です。

• 警戒の線：見張りを強める
• 手動対応の線：人が承認して動く
• 自動対応の線：仕組みが自動で動く

線の位置は、価格を取ってから、判断、署名、送信、確定までにかかる時間から逆算します。資金や署名者がつかまらない場合も含めて試しておけば、清算線に届く前に手を打てます。

以下では、清算される側（借り手）の運用として、見張る値、状態の流れ、実行の方式、責任の分担、本番前の試験を順に具体化します。扱うのは投資判断ではなく、システムと運用の設計です。Health Factorの計算式や、清算する側（清算ボット）の仕組みはHealth Factorと清算ボットで解説しています。

清算の線と警報の線は、別の数字にする

Aaveは、担保価値、借入残高、各担保の清算閾値からHealth Factorを計算します。1未満になると清算の対象です。公式ページも、市場の変動、担保価値、借入残高によってHealth Factorが変わると説明しています（Aave: Health Factor & Liquidations）。

Compound IIIの考え方は違います。アカウントの流動性を、各資産の価格、残高、清算用の担保係数（liquidate collateral factor）から評価します。これが負になると清算できる状態です（Compound III Documentation: Liquidation）。

ですから、監視の画面に全プロトコル共通の「Health Factor」の列を1つ作るだけでは、意味を取り違えます。保存するのは、プロトコルごとの生の値と、その仕様の版、ブロック番号、価格の更新時刻です。複数のプロトコルを並べて見るための共通の指標は、そろえ直した早期警戒値として、別の項目で持ちます。

値は4種類あり、混ぜて使うとそれぞれ別の失敗につながります。

それぞれの値をどこから取るかは、後半の「実装する人向けの詳細」にまとめています。

何を見張ればよいか

残高と価格だけを見ていても、「今すぐ対応できるか」は分かりません。見張る対象は3つに分け、同じ時点にそろえて評価します。

1. ポジション：担保・債務の残高、利息の指数、担保としての利用設定、プロトコルのリスク設定値、ポジションが属する市場・チェーン。
2. 価格・市場：プロトコルが参照するオラクル価格とその更新状態。必要に応じて、DEXの流動性、価格への影響、ガス価格。
3. いま実際に動けるか：ガス代の残高、返済に使う資金、署名者など、実際に手を打つための条件。確かめる項目の一覧は後半にまとめています。

清算の判定に使われるのは、プロトコルが参照するオラクル価格です。そのため外部の市場価格は、早めの警戒には使えても、プロトコルの清算判定値の代わりにはなりません。

Chainlink Data Feedsの利用者向け文書は、価格フィードごとに更新頻度が違うと説明しています。そのうえで、利用する側が最終更新時刻を確かめること、合理的な範囲を外れた回答を拒む回路遮断器を検討することを勧めています（Chainlink: Using Data Feeds）。

とはいえ、自前で価格の新しさを判定しても、プロトコル内部と同じ結果になるとは限りません。監視画面では「プロトコルが採用した価格」と「監視系が観測した外部価格」をはっきり分けて表示します。

通知と自動実行を、状態で使い分ける

ポジションの状態は次のように移ります。英語は、システム上の状態名です。

要注意は、見張る頻度を上げる状態です。要対応は、承認または自動実行を始める状態です。

線は、行きと帰りで位置をずらします。値が線の近くを行ったり来たりすると、通知や取引が連発してしまうからです。たとえば要注意へ移る値と、平常へ戻る値を別にします。一定のブロック数だけ続いたこと、データの品質に問題がないことも条件に加えます。

不明は、障害の状態です。前回のHealth Factorが安全でも、確かめられなければ平常のままにはしません。確かめるのは、最新ブロックとの差、最後の価格更新、複数のRPCが一致するか、プロトコルが一時停止していないかです。確かめられないときは、リスクの高い操作を止めます。人に通知し、代わりのRPCや公式画面で突き合わせる手順に切り替えます。

線の位置は「対応にかかる時間」から逆算する

線の位置は、手を打ち終えるまでに要る時間の合計、いわば「遅れの持ち時間」から逆算します。時間は、次の区間ごとに測ります。

測るときは、厳しい場面を想定します。

• 担保の価格が下がり、同時に借りている資産の価格が上がる
• オラクルの更新がまとめて入る
• ガス代が高騰して、送信が遅れる

こうした場面で、線に届いてから清算線までの最短時間を計ります。金融庁のDeFi技術リスク研究も、市場の急変とガスの高騰で清算処理が正常に動かないリスクを挙げています（金融庁「分散型金融システムのトラストチェーンにおける技術リスク等に関する研究」）。

こうした時間を測らずに、Aaveの清算線がHealth Factor 1だからといって、1.01を共通の自動対応の線にするのは危険です。

返済・担保追加・縮小のどれで対応するか

清算までの余裕を広げる代表的な操作は、債務の返済、担保の追加、ポジションの縮小です。どれが効くかは、プロトコル、資産、チェーン、承認済みの権限、使える流動性で変わります。事前に比べておきます。

• 債務の返済：リスクを直接減らしやすい方法です。ただし返済する資産が同じチェーンに要ります。交換が必要なら、価格への影響と、失敗したときの残高を考えます。
• 担保の追加：元のポジションを保てます。ただし、同じ方向に価格が動く資産を足すと、余裕が急に減ることがあります。
• ポジションの縮小：担保を売って返済する方法です。承認、引出の可否、交換、返済を1つの取引でまとめて行えるかを確かめます。途中で失敗して、担保だけが動くことがないようにします。
• 何もしない：小額のポジション、実行コストが清算の損失を上回る場合、データが不明なとき。こうした場合に自動で動かないという判断も、事前に決めておきます。

自動化のコントラクトや外部のキーパー（自動実行者）に、何でもできる権限を渡したとします。清算のリスクが、今度は鍵・実装・依存するサービスのリスクに置き換わります。

渡す権限は、次の範囲に絞ります。

• 対象のプロトコル、資産、最大額、期限
• 許容するスリッページ（注文時と約定時の価格のずれ）
• 呼び出せる関数

一時停止と権限の取り消しは、別の管理者が実行できるようにしておきます。

自動実行で、同じ返済を2回送らないためには

アラートが2回届き、同じ返済を2回送ってしまうと、余計な資金が動いたり、送信が詰まったりします。これを防ぐため、対応ごとに「どのポジションを・どのブロックで・どの版のルールで」動かしたかを組み合わせた操作IDを付けます。

もう一つ、結果を確かめるところまで作ります。自動化の基盤が「実行成功」と返しても、プロトコルの状態が意図どおりに変わったとは限りません。取引の成否、イベント、残高、債務、健全性を、同じ操作に結び付けて確かめます。具体的な処理の順番は、後半にまとめています。

アラートを受けた後、誰が何をするか

責任の分担は、アラートが鳴った後の動きまで書いておきます。

通知先が1人だけ。休日に署名者がいない。返済資産を動かすのに別部門の承認が要る。冒頭の深夜の例のような、こうした業務上の遅れは、コードでは解消できません。

手順書には、次のことまで入れておきます。

• アラートの重要度と、応答までの時間
• 代わりの担当者と、上位への引き継ぎ
• 権限の停止と、事後のふり返り

本番に出す前に、何を壊して試すか

本番の前に、わざと故障を起こして試します。

• RPCが古いブロックを返す、接続が切れる、複数のRPCで最新ブロックが一致しない。
• オラクル価格の更新が止まる、急変する、外部の市場価格とずれる。
• ガス価格が上限を超える、取引が保留のままになる、nonceがぶつかる。
• 返済資産が足りない、トークンの承認がない、交換の許容スリッページを超える。
• 署名者が応答しない、鍵が止められる、自動化サービスが二重に通知する。
• リスク設定値やコントラクトアドレスが、ガバナンスで変更される。
• 対応中にHealth Factorが回復する、または清算できる状態へ悪化する。

合格の条件は「アラートが出た」ではありません。次の5つを満たすことです。

• 誤って平常と判定しない
• 二重に実行しない
• 権限の上限を超えない
• 目標時間内に、実行するか人へ引き継げる
• 実行後のポジションを確かめ直せる

障害訓練では、「自社の監視が止まった」と「プロトコル自体が止まった」を別々に練習します。リスク設定値の変更を事前に知る仕組みはDeFiガバナンス変更の監視と影響分析で扱っています。

自動の清算回避を作らない方がよいのは、どんなときか

次のような場合は、自動の清算回避の仕組みを入れない選択があります。

• 小額で短期のポジション
• 清算の損失より、監視・緊急資金・当番体制の費用が大きい
• 対応の権限を安全に任せられない

借入の比率を下げる、ポジションを持たない、清算のない構成に変える。その方が単純で堅牢なこともあります。

また、外部の監視サービスだけに頼る場合も注意が要ります。公式計算の再現、データの新しさの確認、資金、署名、障害時の手順書を自社で持てないなら、本番運用の統制として足りません。サービスを入れるかどうかではなく、2つで判断します。清算線までに対応を終えられる確率と、失敗したときの最大損失です。

実装する人向けの詳細

ここからは、監視と自動対応の仕組みを作る開発・SREの担当者向けの内容です。

4種類の値の更新元

• プロトコル固有の清算判定値：公式コントラクトと仕様
• 早期警戒値：運用ポリシー
• ストレス後の予測値：シナリオ計算
• データ品質：ブロック、オラクル、RPCの監視

「いま実際に動けるか」で確かめる項目

• RPCへの到達性、チェーンの最新ブロックとの遅れ
• nonce、署名者、ガス用の残高
• 返済資産・追加担保の利用可能額、トークン承認の状態、送信済みのトランザクション

二重実行を防ぐ処理の順番

各対応にposition ID + trigger block + policy versionから一意な操作IDを作り、次の順で処理します。

1. 対象ブロックでプロトコルの公式値とデータ品質を取り直す。
2. 現在の状態、未完了の操作、利用可能な残高、トークン承認を確認する。
3. シミュレーションで失敗（revert）、受取量、ガス、実行後の健全性を確認する。
4. 署名の直前にブロックと閾値を再評価し、悪化・回復の双方で方針を判定する。
5. トランザクションハッシュを操作へ保存してから配信する。
6. タイムアウト時は同じ処理をすぐに再実行せず、nonce、レシート、差し替え送信を照合する。
7. 確定後にプロトコルからポジションを取り直し、期待値ではなく実際の値でVERIFIEDへ移す。

実装チェックリスト

• プロトコル・市場・チェーンごとの公式の清算式とコントラクトアドレスを版管理している。
• 早期警戒値とオンチェーンの清算判定値を別の項目で保存している。
• ブロック番号、オラクルの更新時刻、RPCの最新ブロックの差、インデクサーの遅れを監視している。
• NORMAL、WATCH、ACTION_REQUIRED、EXECUTING、UNKNOWN、LIQUIDATABLEを区別している。
• 価格の急変から確定までの遅延の持ち時間をストレスシナリオで計測している。
• 返済・担保追加・縮小の資金、権限、最大額、スリッページを定義している。
• タイムアウト後にレシートとnonceを照合し、同じ処理を無条件に再実行しない。
• 実行後に公式値を取り直し、清算までの余地の回復を検証している。
• 通知先、応答時間、代行者、一時停止の権限、事後レビューの責任が決まっている。
• 監視の費用と残るリスクを、低レバレッジやポジションを持たない案と比べている。

DeFiの基礎と各レンディング方式を順に確認する場合はDeFi学習ロードマップ、企業としての運用上限と回収手順は企業財務のDeFi運用ポリシー、損益の集計は複数ウォレット・チェーンのDeFi損益集計も参照してください。

XTELAができること

私たちは、借入ポジションのデータモデル、監視の状態、権限表、緊急時の手順書を設計し、故障注入までを含めて監視と自動対応の仕組みを開発します。貴社の実際のポジションで閾値から確定までの時間を測るPoC（概念実証）から始め、清算線の手前で確実に動く運用に仕上げます。ご相談はお問い合わせからどうぞ。

参考資料

• Aave: Health Factor & Liquidations（2026年9月24日確認）
• Compound III Documentation: Liquidation（2026年9月24日確認）
• Chainlink Documentation: Using Data Feeds
• 金融庁「分散型金融システムのトラストチェーンにおける技術リスク等に関する研究」

資料の確認日と注意

Aave、Compound III、Chainlinkの公式資料は2026年8月13日に確認し、AaveとCompound IIIの清算条件は2026年9月24日に確認し直しました。

システムと運用の設計の解説です。個別の投資判断や法務・会計・税務の判断は、各分野の専門家へご確認ください。