DeFi保険で何が守れるか｜ヘッジとの違いと損失の原因ごとの備え方

ある会社の財務チームが、ETHを担保にステーブルコインを借り、それを別のDeFiプロトコルに預けて運用しています。経営会議で、こう聞かれました。「DeFi保険に入っておけば、相場が下がっても安心なのでは？」

DeFi保険と呼ばれる商品で補償が出るのは、プロトコルが悪用されたときなど、契約で決めた事故です。通常の価格下落、金利の変動、インパーマネントロス（流動性提供で生じる変動損失）は、対象外になり得ます。ですから、答えは「いいえ」です。逆に、先物を売って相場の下落に備えても、プロトコルの悪用による損失は埋まりません。

しかも、後で見るように、「DeFi保険」と呼ばれる商品には、法律上の保険契約ではなく、支払いが約束されていないものもあります。

そこで、損失を原因ごとに分けて、守り方を割り当てます。

• 事故による損失は、補償やカバーで
• 価格・金利の変動は、ヘッジで
• どちらでも守れない引き出し停止などは、利用上限と運用のルールで

以下では、この財務チームの財務・リスク担当の立場で、守り方の割り当て、ヘッジの量の決め方、請求の判定、事故のときの復旧、監視までを見ていきます。

まず、損失の原因ごとに分ける

同じ1億円のDeFiポジションでも、損失の原因が違えば、守り方は変わります。原因には、次のようなものがあります。

• 担保資産の価格下落、借入金利の上昇、清算
• スマートコントラクトの脆弱性、オラクルの異常、ブリッジの停止
• ステーブルコインのデペッグ、署名鍵の侵害、取引の誤送信

これらは互いに連鎖し得ますが、同じリスクではありません。原因ごとの主な守り方と、守った後も残るものは次のとおりです。

どの手段にも、残るリスクがあります。残る分は、利用上限や現金の余力などで抑えます。超過損害向けの補償は、一定額を超えた分の損失を補う商品です。

この表を、ポジションごとのリスク台帳にします。各行には次のことを書き込みます。

• 最大損失と、起きやすさ
• 気づくまでの時間と、移す先
• 除外される場合と、社内の責任者

保険料、カバーの利用料、ヘッジ費用を比べるのは、その後です。何を移せて何が残るかを先に書かないと、同じ損失を二重に守る一方で、別の損失が無防備になります。

事故への補償と、値動きへのヘッジは何が違うか

法律上の保険契約、保険の代わりとなる裁量型のカバー、デリバティブによるヘッジは、別々の手段です。

補償・カバーが見るのは「事故」

補償の商品が判定するのは、「対象の事故が起き、契約期間中に、対象のアドレスが、決められた損失を被ったか」です。たとえばNexus Mutualの公式ドキュメントでは、商品ごとに補償条件、猶予期間、損失の証明が決められています。請求は、その条件に照らして査定されます。

ただし、Nexus Mutualの公式FAQによれば、同社のカバー（以下「裁量型カバー」）は保険契約ではありません。同社が明示する保険の代わりの商品で、損失が出たときの支払いに法的な義務がない、裁量型です。どの請求に支払うかの最終判断は、メンバー側にあると説明しています。これは同社の商品についての説明で、ほかの商品の性質を示すものではありません。

請求の査定は、2025年11月から、公開された3名の専門家による請求委員会（Claims Committee）が担っています（2026年9月24日時点）。

購入の前には、次のことを確かめます。

• 対象のプロトコル・チェーン・アドレス、開始時刻、除外
• 損失の計算方法、請求期限、支払いに使う資産
• 法的な支払義務があるか、誰が判定するか

ヘッジが見るのは「値動きへの反応」

一方、ヘッジが扱うのは、ポジションの価値が市場の値動きにどれだけ反応するかです。

冒頭の会社のように、ETHを担保にステーブルコインを借りて運用しているなら、反応するものは5つあります。ETH価格、借入金利、運用先の利回り、ステーブルコインの価格、担保率です。

まず、小さな価格の変化に対して損益がどれだけ動くか（デルタ）を見積もり、先物などで打ち消します。ただ、大きく動くと、この反応の度合い自体が変わります。オプションを含む場合は、デルタ自体の変わり方（ガンマ）、時間の経過による変化（シータ）、価格の変動の激しさによる変化（ベガ）も監視します。

2つの分かれ目

分かれ目は「事故か、市場の変動か」です。悪用でプロトコルの残高が失われたなら、補償の候補になります。通常の価格下落やインパーマネントロスは、補償の対象外になり得ます。

デペッグにも注意が要ります。参照する市場、しきい値、続いた時間、回復の条件が合わなければ、実際の損失と支払いがずれます。これがベーシスリスクです。

設計例：ETH担保で借りて運用する場合

冒頭の会社の数字を仮に置いてみます。設計時点の時価が1億円、借入が4,000万円です。事業として許せる30日間の損失は800万円とします。これは投資の推奨ではなく、責任の分け方を具体的にするための例です。

1. 市場の損失を測る：ETHが20%下落、ステーブルコインが5%デペッグ、借入金利が上昇する、という厳しい場面を計算します。1つずつの場合と、同時に起きた場合の両方です。清算価格に近づくと、損失が値動きに比例しなくなる点も含めます。
2. ヘッジを割り当てる：ETHの正味のデルタの一部を、先物で打ち消します。100%を機械的に打ち消すことはしません。調整し直す幅、資金調達率の上限、証拠金の余力、取引先ごとの上限を決めます。
3. 事故の損失を割り当てる：貸し借りのプロトコルと運用先のプロトコルを別々に扱います。補償商品ごとに、条件、上限、期間、アドレスの証明を突き合わせます。複数のプロトコルを経由するトークンなら、どこまでが対象かも確かめます。
4. 移せない分を抑える：次のことに備えて、利用上限、現金の余力、手動での停止、退避のための復旧手順書を用意します。ガス代の高騰、オラクルの停止、ヘッジ市場の板が消えること、請求の否認、裁量型カバーに法的な支払義務がないこと、支払いの遅れです。

採用するかの判断は、「800万円を完全に消す」ことではありません。次の2つを比べます。

• 総費用：保険料またはカバーの利用料、オプション料、資金調達率、スリッページ、運用の人件費
• 対策をした後の、厳しい場面での損失

平均的な損失の見込みが小さくても、テールリスクは別です。事業の停止や顧客資産の毀損に直結するものは、別の上限で管理します。

ヘッジの量は、残高ではなく正味の反応から決める

ポジションの値動きへの反応は、担保の額だけでは決まりません。借入、LPトークン（流動性提供トークン）、報酬トークン、オプションの性質、清算の条件も効いてきます。そのため、担保と同じ額の先物を売るだけでは足りません。

出発点は、ポジションごとの数量とデルタを掛け合わせて足した、正味の反応です（式は後半の「実装する人向けの詳細」）。ただし、それがそのまま発注する量になるわけではありません。次の制約をかけます。

• 調整し直す幅：小さな変化ごとに売買すると費用がかさむため、金額またはデルタで許す幅を決める。
• 流動性の制約：普段の出来高ではなく、荒れたときの板の厚さで、1回の最大の発注量と、分けて出す時間を決める。
• 取引相手ごとの上限：DeFiの損失を、中央集権の取引所が破綻するリスクへ丸ごと移さない。
• 資金調達率の制約：無期限先物の資金調達率（funding rate）が上限を超えたら、期限付きの先物、オプション、現物を減らす方法へ切り替える。
• オラクル価格との差：担保のプロトコルが使う価格と、ヘッジ市場の価格のずれ（ベーシス）を、別の指標で監視する。

ヘッジの目的は、元のポジションの損益を打ち消すことです。そのため、「ヘッジで利益が出たか」だけでは、効いたかは分かりません。元のポジションと合わせた損益、荒れたときの追跡のずれ、調整し直しの費用、証拠金不足の有無を、同じ時系列で確かめます。

請求の判定は、自動化より「後で説明できること」を優先する

完全に自動のパラメトリック判定（指標が条件を満たせば支払う方式）が向くのは、客観的な参照値としきい値で事故を十分に表せる場合です。

しかし、プロトコル悪用の原因、利用者の実際の損失、回収できた額、除外に当たるかは、1つの価格フィードだけでは決められません。Nexus Mutualの請求査定資料も、事故の詳細と損失の証明を確かめ、補償条件に合うかを査定しています。

2026年9月24日時点の同資料では、手順は次のとおりです。

• 請求委員会の3名が、72時間の投票期間に1人1票を投じる
• 3名中2名が承認すれば、請求が認められる
• 投票の終了後、24時間の待機期間を置いてから支払える

2025年11月までは、NXM（Nexus Mutualのトークン）をステーク（預け入れ）したメンバーの投票で判定していました。なお、条件に合うことは、法的な支払義務を意味しません。裁量型である点は変わりません。

実例：Euler Financeの事件

2023年3月13日、Euler Financeの事件で約1億9,700万ドルが流出しました。査定者は、まずこれが補償対象の事故に当たると判断しました。そのうえで、請求を1件ずつ、次の3点で確かめています。

• 事故の時点で、有効なカバーがあったか
• 損失の証明が出されたか
• 請求額が、実際の損失と一致するか

結果、プロトコル向けカバーの請求9件に計2,389,227.88ドルが支払われました。Sherlockの超過損害向けカバーでは、請求1件に100万ドルが支払われています。同じカバーのもう1件は、50万ドルの免責額を差し引いていなかったため、否認されました。

事故の認定と、請求ごとの損失の確認を、分けて記録する。それが、後で説明できる判定の土台になります。

オラクルを使うなら、異議が出る前提で

UMA Optimistic Oracle V3の保険チュートリアルは、次の流れを示しています。請求内容を表明し、異議申立期間に反論を受け、解決した後に結果を返して、支払う流れです。

保証金と異議申立期間の長さは、トレードオフです。一方は、うその申告を争う経済的な意味。もう一方は、支払いの遅れです。公式ドキュメントも、大きな価値を動かす複雑な要求では、保証金と異議申立期間を引き上げることを検討するよう説明しています。

オンチェーンに何を置き、何をオフチェーンに残すか

公開チェーンに書いた情報は、ずっと残ります。請求の証拠には、本人情報や取引明細のような、公開できない情報も含まれます。そのため、「透明性」のために全データを公開するのは不適切です。オンチェーンには中身そのものではなく、版、ハッシュ、時刻、状態の移り変わりを置きます。

見る権限が要る証拠は、暗号化して持ちます。後から証拠を出すときは、ハッシュで購入時・事故時の記録と一致することを確かめられます。

事故のとき、判定と支払いを分けて復旧する

請求から支払いまでを1回の取引にまとめると、困ったことになります。異議、回収額の変更、送金ネットワークの停止、資金不足を、安全に扱えないのです。

そこで、請求の流れを段階に分けます。請求、証拠の確認、承認または否認、支払いの確保、支払い済み、の順です。異議が出たとき、オラクルの食い違いや資金不足のときは、理由を付けて別の状態へ移します。状態名と守るべきルールは後半にまとめました。

紛争と人による訂正の運用はスマートコントラクト保険の請求紛争と人による訂正で詳しく扱っています。支払いの状態の一般的な作り方はパラメトリック保険のスマートコントラクト設計をご覧ください。

3つの台帳を突き合わせて監視する

運用では、3つの台帳を別々に持ちます。

1. DeFiの元のポジション
2. 保険または裁量型カバー
3. ヘッジのポジション

これらを同じ評価時刻にそろえて突き合わせます。よくある失敗は「補償のずれ」です。元のポジションが増えたのに、補償額やヘッジの量が更新されていない状態です。

見る項目は次のとおりです。

• エクスポージャー（損失を受ける可能性のある額）、担保率、清算までの距離、引き出せる額
• 補償の開始・終了、上限、対象アドレス、猶予期間、請求期限、法的な支払義務の有無、判定する主体
• ヘッジ後のデルタ、証拠金、資金調達率、取引相手ごとの残高、清算価格までの距離
• オラクルの鮮度、参照市場のあいだのベーシス、チェーンの停止、ガス代、ブリッジの状態
• 対策前後の厳しい場面での損失、移す費用、移せていない額、責任者、期限

アラートは、次の行動につながる形で出します。「ETHが下落した」ではありません。たとえば次のような出し方です。

• 対策後の厳しい場面での損失が、許容額を超えた
• 補償の終了まで7日
• 担保のプロトコルとヘッジ市場のベーシスが、しきい値を超えた

自動売買が失敗したときに手で対応する責任者、承認の流れ、待てる最長の時間も、復旧手順書に書いておきます。

使わない方がよいとき、PoCで確かめること

次のどれかに当たる手段は、採用しません。

• 損失の定義があいまい、または事故の後に証拠を再現できない
• 荒れたときにヘッジ市場が消える、または補償の上限が小さすぎる
• 裁量型カバーの支払判断や、法的な支払義務がないことを受け入れられない
• 利用料と運用費用が、許せる損失を上回る

複数の主体で突き合わせる必要がなく、社内のDBと承認ログで足りるなら、請求の状態をスマートコントラクトに置かない方が簡潔です。

PoCは、平時の購入・売買のデモでは判断しません。次を合格の条件にします。

• 価格の急落、デペッグ、金利の上昇、プロトコル悪用を、1つずつ・同時に再生し、対策後の損失と残るリスクを説明できる。
• オラクルの停止、チェーンの混雑、取引所APIの停止、板の消失のときに、自動処理が損失を広げない側で止まり、手で復旧できる。
• 同じ請求、オラクル報告、ヘッジ注文を送り直しても、二重支払・二重発注にならない。
• 補償条件、購入時のアドレス、事故前の残高、回収額から、損失の証明を再現できる。
• 毎日、元のポジション・補償・ヘッジの量のずれを見つけられる。
• 管理鍵の侵害を想定し、停止・権限の失効・再開を、複数の承認で実行できる。

よくある質問

DeFi保険を買えば相場下落も補償されますか？

いいえ。補償やカバーが対象にするのは、プロトコルの悪用など契約で定義した事故です。通常の価格下落、金利変動、インパーマネントロスは対象外になり得るため、市場変動はヘッジや利用上限で別に扱います。

Nexus Mutualのカバーは保険ですか？

公式FAQによれば保険契約ではなく、支払いに法的義務のない裁量型のカバーです。購入前に、対象アドレス、除外、損失計算、請求期限に加え、判定主体と法的支払義務がないことを受け入れられるかを確認します。

DeFi保険とヘッジはどちらを優先すべきですか？

優先順位ではなく、損失原因で分けます。事故による損失は補償、価格・金利への感応度はヘッジ、どちらでも移せない流動性停止や鍵侵害は利用上限と運用統制で抑える、という割り当てを台帳で管理します。

実装する人向けの詳細

ヘッジ数量の出発点

時点tの概算のヘッジ数量は、各ポジションiの数量とデルタから、hedge_qty(t) = -Σ(quantity_i × delta_i)で出します。これは執行量の最終値ではありません。前半の制約（調整し直す幅、流動性、取引相手ごとの上限など）をかけてから発注します。

請求の状態と、守るルール

最低限、ACTIVE → CLAIMED → EVIDENCE_REVIEW → ACCEPTED/DENIED → PAYMENT_RESERVED → PAIDを分けます。異議はDISPUTED、オラクルの食い違いや資金不足は理由コード付きのEXCEPTIONへ移します。

• 冪等性（同じ請求を二重に処理しない）：claim_id = hash(cover_id, incident_id, claimant)を一意にし、タイムアウトの後も別IDで再請求しない。
• 確定性：ACCEPTEDになった判定は、送金に失敗してもDENIEDへ戻さない。支払処理待ちだけを再試行する。
• 訂正：過去の判定を上書きしない。元のIDを参照するCORRECTED状態と、追加の支払い・回収の方針を残す。
• 停止権限：新規購入の停止、請求受付の停止、判定の停止、支払いの停止を別々の権限にし、1本の鍵で全部を操作できないようにする。
• 再開の条件：原因、影響範囲、残高の整合、オラクルの鮮度、未処理の待ち行列、承認者を確かめて、段階的に戻す。

関連記事

• DeFiの技術マップ（DeFi全体の構成を確認する場合）
• 企業向けDeFiプロトコルの調査・評価｜採用前に確認する7つの証拠
• 企業財務のDeFi運用ポリシー｜利用上限・承認・停止・資金回収
• DeFiポジション監視と清算リスク対策｜閾値・通知・自動対応
• ステーブルコインのデペッグ対応｜停止・償還・売却・再開の手順
• パラメトリック保険のスマートコントラクト設計｜指標・支払・例外

XTELAができること

私たちは、DeFiポジションのリスク台帳、オラクル、請求・支払の状態機械、権限、監視、障害時の復旧手順書を設計し、スマートコントラクト・監視基盤・取引連携のPoCとして開発します。原ポジション・補償・ヘッジの3台帳の照合や、価格急落とプロトコル悪用を同時に再生する試験環境づくりも行います。貴社のDeFi運用でリスク移転の設計を具体化する段階で、お問い合わせからご相談ください。

主要参考資料

• Nexus Mutual: Cover Products
• Nexus Mutual: FAQ（裁量型カバーの法的性質）
• Nexus Mutual: Claim Assessment
• Nexus Mutual: Euler Finance Exploit Claims
• UMA: Optimistic Oracle V3 Insurance Tutorial
• UMA: Custom Bond and Liveness Parameters

資料の確認日と注意

一次情報は2026年9月24日に最終確認しました。その時点の公開情報にもとづく技術・運用設計の解説で、保険・投資の助言ではありません。