---
title: "清算キーパーが機能しないとどうなるか"
description: "一つの清算ボットが停止しても通常は代替できますが、市場全体で執行が遅れると不健全なローンが不良債権になり得ます。障害の経路、経済性、プロトコルの安全策を解説します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 清算キーパーが機能しないとどうなるか

> 教育目的の情報であり、投資助言ではありません。DeFi のレンディングおよび清算システムでは、急速かつ取り返しのつかない損失が生じる可能性があります。

<a id="answer"></a>

## 直接の答え

一つの清算キーパーが機能しなくても、通常は一件のトランザクションが送信されないかリバートするだけで、直ちにプロトコル全体の障害にはなりません。多くのレンディングプロトコルには専任のキーパーが存在せず、清算はパーミッションレスです。そのため、別のボット、コントラクト、またはユーザーがトランザクションを送信できます。例えば Aave は、条件を満たすポジションをネットワーク参加者なら誰でも清算でき、清算の競争は非常に激しいと説明しています。

深刻なのは集団的な機能不全です。経済的に成立する価格で執行できる、または執行しようとする参加者が一人もいない状況です。金利が積み上がり、担保価格が動き続ける間も、ポジションは清算しきい値を下回ったままになる可能性があります。清算が再開しても、回収額がそのポジションに割り当てられた債務と費用を下回れば、差額は当該プロトコルの会計処理に従って不足額または不良債権になります。

不足額を誰が負担するかはプロトコルごとに異なります。Compound III の `absorb` は債務超過となったアカウントの債務をプロトコルに移し、ベース資産の準備金を使用する一方で、プロトコルが担保を受け取ります。Maker の `Dog.bark` は安全でない Vault の債務をプロトコルに移し、担保オークションを開始して、その債務を会計システムに記録します。ほかのシステムでは、準備金、保険基金や安定化基金、ガバナンスによる資本再編、損失の社会化、またはこれらの組み合わせが使われる場合があります。

したがって、借り手にとって清算の自動化は損切りサービスではありません。しきい値を越える前にポジションを監視し、債務を返済するか担保を追加するのが安全な対応です。清算の遅れは担保損失を増やし、回収不能な不足額が生じる可能性も高めます。

<a id="mechanism"></a>

## 仕組み

一般的な外部清算人による処理には、五つの段階があります。

1. **清算資格の判定：** プロトコルは設定されたオラクルを参照し、アカウントが清算しきい値を越えたかを判定します。市場価格がすでに動いていても、オラクルが古い、または停止していると、この状態変更が遅れたり妨げられたりします。
2. **検出と価格評価：** オフチェーンのボットがポジションをインデックス化し、清算をシミュレーションして担保の売却代金を見積もり、利益が出る機会かどうかを判断します。
3. **トランザクションの取り込み：** 清算人は必要な債務資産を用意してトランザクションを送信し、ブロックスペースを競います。混雑、低すぎる手数料、RPC の障害、nonce の競合、または別の清算人による先行執行のために、トランザクションが保留されたままになったりリバートしたりすることがあります。
4. **コントラクトの実行：** コントラクトは現在価格、アカウントの状態、close factor またはオークションの上限、一時停止制御、利用可能な流動性を確認します。これらの入力のいずれかが変わると、シミュレーション時には有効だったトランザクションも失敗する可能性があります。
5. **担保の処分：** 清算人またはプロトコルは、取得した担保を売却、ヘッジ、または競売にかける必要があります。流動性が薄く下落相場であれば、見かけ上のボーナスが損失に変わることがあります。

清算人の判断を単純化すると `expected profit = liquidation incentive - gas - price impact - hedge cost - expected revert loss` です。資本コストやプロトコル手数料が加わる場合もあります。担保をオラクル価格に近い水準で売却できない、または執行できる見込みが低いなら、提示されたボーナスが大きくても十分ではありません。

障害は全面的ではなく、局所的であることが少なくありません。一つのアカウント、担保タイプ、チェーン、オラクル、RPC プロバイダー、またはオークションが機能しなくても、ほかは継続できます。例えば Maker の Liquidation 2.0 ドキュメントには、担保ごとの上限と全体のオークション上限、オークションのリセット、キーパーへのインセンティブ、四段階のサーキットブレーカーが記載されています。こうした制御は、そのシステム内で執行遅延がどのように波及するかを変えます。

<a id="example"></a>

## 計算例

清算条件を満たすアカウントに `100,000 USDC` の債務があり、担保価値が `103,000 USDC` だとします。単純化したプロトコルでは、清算人が `50,000 USDC` を返済し、`52,500 USDC` 相当の担保を取得できます。グロスのインセンティブは `5%` です。

- 担保の売却では、価格への影響によって `2,000 USDC` のコストが見込まれます。
- Gas と優先手数料は `700 USDC` です。
- リバートまたは競争に負けるトランザクションの期待コストは `300 USDC` です。
- したがって期待利益は `52,500 - 50,000 - 2,000 - 700 - 300 = -500 USDC` です。

合理的な清算人は待つか、このアカウントを見送る可能性があります。誰も執行せず担保がさらに `5%` 下落すると、その価値は `97,850 USDC` となり、追加の金利や手数料を考慮する前でも、元の債務に対して `2,150 USDC` の不足が生じます。その後の清算で損失を減らすことはできても、すでに失われた担保価値を作り出すことはできません。

これは説明用の例であり、実際に稼働している特定の市場をモデル化したものではありません。実際の close factor、ボーナス、オラクル価格、プロトコル手数料、準備金の規則、トランザクションコストは、現行のコントラクトと公式ドキュメントで確認する必要があります。例えば Aave が公表している規則では、ヘルスファクターとポジション規模に応じて清算可能な最大割合が変わります。

<a id="risks"></a>

## リスクと安全策

- **借り手側の対策：** 清算しきい値を意図的に上回る余裕を確保し、独立したアラートを設定し、返済または担保追加の手段を事前にテストしてください。混雑時にもフロントエンド、自動化サービス、清算人が利用できるとは限りません。
- **プロトコル側の対策：** 堅牢なシステムはオラクルとトランザクション基盤を分散させ、ボーナスと最小ポジション規模を調整し、清算量に上限を設け、適切な場合には部分清算や一括清算をサポートします。また、危機の前に一時停止、オークションのリセット、準備金、不足額の処理方法を定めます。
- **清算人側の対策：** 運用者は複数の RPC エンドポイントを使用し、署名前にオンチェーンの状態と照合し、保留中の状態に対してシミュレーションを行い、nonce の置換を管理してスリッページに上限を設け、単一の取引所やフラッシュ流動性源への依存を避けるべきです。
- **貸し手と預金者の確認事項：** 不良債権を処理する正確な損失負担順位を確認してください。どの準備金がどの市場をカバーするのか、誰がパラメーターを変更できるのか、準備金に流動性があり利用可能なのか、使い尽くされた後に何が起きるのかを検証します。

執行を保証できる安全策はありません。インセンティブは平常時には小さすぎても、パラメーターの変更後には過大になったり悪用されたりする可能性があります。一時停止やサーキットブレーカーは、誤ったオラクルやコントラクトによる被害を抑えられる一方、意図的に清算を止め、価格リスクの蓄積を許すこともあります。重要なのは、価格、流動性、ネットワーク、インフラに同時にストレスがかかったとき、システム全体がどう動くかです。

<a id="misconceptions"></a>

## よくある誤解

### 誤解 1：すべてのプロトコルが一つの信頼できるキーパーを任命する

多くのプロトコルでは、どのアドレスでも清算できます。名前の付いたボットは、参加者の一つ、またはインターフェース提供者にすぎない場合があります。その停止が問題になるのは、代わりに執行できる者がいない場合だけです。

### 誤解 2：清算条件を満たしたポジションは、すでに清算されている

清算条件を満たすことはコントラクト上の状態であり、清算は別のトランザクションまたはオークションです。執行が成功し、その結果の債務と担保が会計処理されるまでは、市場エクスポージャーが残ります。

### 誤解 3：gas を上げれば必ず障害を解決できる

トランザクション手数料を増やせば取り込みの優先順位は上げられますが、古いオラクル、停止中の市場、資本不足、allowance の不足、変化したアカウント状態、採算の合わない担保売却、コントラクトのリバートは修復できません。

### 誤解 4：不良債権が生じると、貸し手は直ちに同額を失う

不良債権はまず、プロトコルが定める損失負担順位に従って処理されます。準備金などのバックストップが吸収する場合もあります。貸し手やガバナンストークン保有者が影響を受けるかどうかは、適用される規則と利用可能な資源によって決まり、その時期も不足額が生じた瞬間とは異なる場合があります。

<a id="related"></a>

## 関連トピック

- [暗号資産の清算](/ja/crypto/liquidation/)
- [清算ボーナス](/ja/crypto/liquidation-bonus/)
- [清算クローズファクター](/ja/crypto/liquidation-close-factor/)
- [オラクル価格の陳腐化](/ja/crypto/oracle-price-staleness/)
- [暗号資産デリバティブの保険基金](/ja/crypto/insurance-fund/)

<a id="sources"></a>

## 出典

- [ヘルスファクターと清算](https://aave.com/help/borrowing/liquidations) - Aave（参照日：2026-08-21）
- [Compound III ドキュメント：清算](https://docs.compound.finance/liquidation/) - Compound（参照日：2026-08-21）
- [Liquidation 2.0 モジュール](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) - Maker Protocol Technical Docs（参照日：2026-08-21）

Source: https://wiki.fcontext.com/ja/crypto/liquidation-keeper-failure/index.mdx