企業がDeFiで資金運用するときのルール｜損失の上限・預け先の制限・引き揚げ手順

Aaveには、リスクの高い担保で損失が広がるのを抑える「Isolation Mode」という仕組みがありました。借りられる資産と債務の上限を絞るものです。ところが2026年4〜5月に各市場へ展開されたAave v3.7で、Isolation Modeと債務上限の管理は廃止されました。代わりに、eMode（資産のグループごとに条件を変える仕組み）のカテゴリに「isolated」という設定を加える形に整理されています。

もし企業が、この仕組みを頼りに自社のリスク管理を組んでいたらどうなるでしょう。預け先のプロトコルは、ガバナンスの決定で仕組みそのものを変えます。プロトコルの安全装置は、企業の上限の代わりにはなりません。

では、余剰資金をDeFiで運用する企業は、何から決めればよいのか。最初に決めるのは、利回りの目標ではなく「失ってよい金額」です。そこから次の順に決めていきます。

1. 依存先ごとの上限
2. 使ってよいチェーン・コントラクト・操作の一覧（許可台帳）
3. 承認の分担と、止める条件
4. 資金を戻す手順

そのうえで、機械で止められる項目と、人が判断する項目を分けて運用します。

DeFiの運用では、上限を超える、ガバナンスで仕組みが変わる、価格の情報がおかしくなる、ステーブルコインの価格がずれる、ブリッジが止まる、資金が戻らない、といった事態が起こりえます。「承認者を増やす」「監査済みのプロトコルだけを使う」だけでは、これらをまとめて抑えられません。

以下では、社内の運用ルールを「ルール外の送金は機械が止める」「あとから誰が何をしたか追える」仕組みに落とす方法を、CFOや財務・リスク管理の責任者が決める順に説明します。保有全般の内部統制（職務分離・日次照合・退出）は企業のデジタル資産保有と内部統制で扱っています。ここでは、DeFiで運用する場合に上乗せする部分を扱います。

利回りより先に、失ってよい範囲を数字で決める

最初に決めるのは、使うプロトコルではありません。DeFi運用に回せる資金と、最大の損失です。

まず、次のお金を除きます。

• 運転資金
• 税金・給与・仕入などの確定した支払
• 法定通貨で最低限持っておく額

残った資金に対して、上限を段階ごとに置きます。DeFi全体、チェーン、プロトコル、資産、戦略、ブリッジ、発行体ごとの上限です。

注意したいのは、複数のポジションが同じものに頼っている場合です。同じステーブルコイン、同じ価格情報の提供元（オラクル）、同じブリッジ、同じ管理鍵。これらに頼っているなら、商品ごとの上限を足すだけでは、集中のリスクをつかめません。

上限の例は次のとおりです。

それぞれの上限で何を数えるか（判定対象）は、後半にまとめています。

数字はあくまで例です。適切な値は、会社の資金需要、資本、法域、契約、会計方針で変わります。上限には、次のことも添えます。

• 何に対する割合か（分母）と、どの価格で、いつ評価するか
• まだ確定していない取引をどう数えるか
• 超えたとき、いつまでに解消するか

「TVL（プロトコルへ預けられた資産総額）が大きい」「監査を受けた」は参考にはなります。ただし、自社の損失上限の代わりにはなりません。

「使ってよい相手」を、住所のレベルで一覧にする

担当者が「Aaveに預ける」と言っても、名前だけで判断していると、次のような事故を防げません。

• 同じ名前の偽サイトにつないでしまう
• 別のチェーンの、似た相手につないでしまう
• コントラクトの中身が差し替えられていることに気づかない
• 相手に無制限の引き出しを許してしまう（無制限のトークン承認）

だから、使ってよい相手を、表示名ではなく住所（コントラクトアドレス）のレベルで一覧にしておきます。これが許可台帳です。台帳には、どのチェーンの、どのアドレスに、どの操作を、いくらまで、いつまで許すか、と、その根拠と承認者を書きます。台帳の版も管理します。記録する項目と検証の方法は後半にまとめています。

金融庁のDeFi技術リスク調査は、DeFiには信頼を置く点（トラストポイント）が複数あると示しています。ウォレット、ユーザーインターフェース、ノードの提供者、オラクル、ガバナンスなどです。そのうち最も弱い箇所を分析する必要がある、としています。

企業の台帳でも、「分散型だから運営する主体は評価しない」とはしません。アップグレード、停止、価格、画面（フロントエンド）、鍵。それぞれの権限を誰が持つかを別々に記録します。台帳に載せる前のプロトコル評価の手順は企業向けDeFiプロトコルの調査・評価にまとめています。

2026年7月には、FATFがDeFiの規制上の課題に関する報告書を公表し、金融庁も日本語で紹介しています。報告書が扱うのは次の3点です。

• DeFiのマネロン等のリスク
• 既存のFATF基準の当てはめ方
• 「支配または十分な影響力を持つ者」の判断基準

取引相手が見えにくいDeFiを使うなら、台帳の根拠資料に、運営主体の有無と資金の流れの確認結果も残しておくと説明しやすくなります。

機械に任せるルールと、人が決めるルールを分ける

運用の方針には、2種類の条件があります。

まず、人の判断が要る条件です。契約に合っているか、会計でどう分類するか、評判、監査報告書で十分か、といったものです。これらは、人が判断して台帳に反映した結果を使います。

一方、取引のその場で白黒をつけられる条件もあります。宛先、関数、資産、金額、期間、累計の使用額、承認の数です。こうした条件は、できるだけ署名の前か実行の時点で、機械が拒否するようにします。

つまり、方針のすべてをスマートコントラクトに書く必要はありません。

仕組みは、申請・署名・実行の3段階で組みます。どの段階で何を止めるかは、後半で説明します。

「いま預けている・申請中・引き出し待ち」を区別して記録する

ウォレットの残高だけでは、いま何が起きているかを表せません。たとえば次のものが見えません。

• 承認済みだが、まだ実行していない取引
• プロトコルへ預けた資産、引き出し申請中の資産
• 報酬、借入、清算される可能性

そこで、操作ごとに1つの番号を付け、申請から会計の仕訳までを結びます。そして、各操作が「申請中」「承認済み」「送信済み」「確定」「運用中」「引き出し中・完了」のどこにあるかを記録します。購入から保管までの状態の進め方はデジタル資産保有の内部統制で解説しています。DeFiでは、預けた後の状態を足します。状態ごとの条件は後半の表にまとめています。

見張るのは価格だけでなく、「権限」と「戻せるか」

見張る対象は、3つにまとめられます。

• お金の状態：価格、担保、清算までの余裕、ステーブルコインの価格のずれ、利用率、引き出せる流動性。
• 誰かが仕組みを変えていないか：コントラクトの中身、管理者・緊急停止の権限者、ガバナンスの提案、一時停止の状態。価格情報の更新時刻も含む。
• 道具が動くか：ブロックの生成・確定、画面（フロントエンド）とRPC（ブロックチェーンとやり取りする窓口）が使えるか。

台帳の値は、ウォレットの画面だけに頼りません。独立したRPCまたはノードから、コントラクトの状態とイベントをもとに組み立て直します。担保率と清算までの余裕の具体的な監視はDeFiポジション監視と清算リスク対策、ガバナンス提案や権限変更の検知はDeFiガバナンス変更の監視で扱います。

冒頭のAaveの例のように、プロトコルの仕組みはガバナンスで変わります。自社の台帳との違いを見つけたら、変更後も方針に合っているかを判定し直します。

毎日の突き合わせでは、3つの記録を比べます。(1)社内のポジション台帳、(2)ウォレット・カストディの記録、(3)独立して取ったオンチェーンの状態です。組み立て方はデジタル資産保有の内部統制で詳しく整理しています。DeFiでは、預けたトークンの枚数だけでなく、次のものも分けて突き合わせます。

• 裏付けになる資産への換算額
• 借入、まだ受け取っていない報酬
• 引き出しの制約、トークン承認の残り

異常時は、増やす操作だけを止め、引き揚げる道は残す

異常に気づいたとき、すべての操作を一律に止めてしまうと、損失の拡大は防げても、資金の引き揚げや担保の追加まで妨げてしまう場合があります。

そこで平時のうちに、操作を2つに分けておきます。

• 止めるのは「リスクを増やす操作」：新しく預ける、借りる、別のチェーンへ送る、トークン承認を増やす
• 止めないのは「リスクを減らす操作」：返す、承認を取り消す、引き出す、既知の保管先へ戻す

兆候ごとの動き方は次のとおりです。

それぞれで人が確かめることは、後半にまとめています。

金融庁の調査も、緊急停止だけでなく、不測の事態への方針・手順と、定期的な訓練が必要だとしています。ただし、プロトコル側の一時停止の権限を、企業が操作できるとは限りません。自社でできるのは、次のようなことです。

• 新しい署名を止める、許可台帳を失効させる
• 承認を取り消す、返済・引き出しをする
• 代わりのRPCから直接実行する

本番の前に、少額で「止める・戻す・突き合わせる」を試す

本番に出すかは、監査報告書やこれまでの稼働期間だけでは決めず、実際に止めて戻せるかを試してから決めます。

まず、フォーク環境（本番のチェーンを写した試験環境）かテストネットで機能を確かめます。そのうえで実際のチェーンで、失ってもよい限られた額を使い、次の操作を通します。

• 預ける、交換する、報酬を受け取る、返す、引き出す
• トークン承認を取り消す、RPCを切り替える
• 画面（フロントエンド）を使わずに直接実行する

さらに、わざと異常を起こします。コントラクトの差し替え、価格の停止、ガス代の高騰、チェーンの巻き戻り（再編成）、一時停止、流動性の不足、署名者の不在です。気づいてから、判断・回収・会計の突き合わせまでにどれだけ時間がかかるかを測ります。

timelock（実行までの待機時間）にも注意が要ります。OpenZeppelinのTimelockController解説が示すように、待機時間があれば、管理者の操作を確かめて退出する時間を作れます。一方で、提案者や実行者が動けなくなると、操作が止まる構成もあります。

外部プロトコルのtimelockが、自社の監視の間隔・意思決定・回収にかかる時間より短いと、変更に気づいても資金を戻せません。timelockの長さの決め方はマルチシグ・タイムロックの本番権限設計で扱います。

本番採用を見送るのは、どんなときか

次のどれかに当てはまるなら、本番採用を見送ります。

• 管理者、アップグレード、オラクル、ブリッジ等の実質的な権限と依存先を列挙できない。
• ウォレット画面を使わずに現在のポジションと回収用トランザクションを再構成できない。
• 想定損失を含めても給与・税金・仕入等の確定支払を維持できない。
• 許可外のアドレス・関数・金額を署名前または実行時に止められない。
• 緊急停止時の意思決定者、連絡先、復旧条件、会計処理の確認先が決まっていない。
• 限定額の退出テストが成功せず、残っているトークン承認と残高ゼロを確認できない。

運用ポリシーの受入条件を一枚にまとめる

最初の一歩は、1番目です。取締役会または権限者が「失ってよい額」を数字で決めることから始めます。

1. 取締役会または権限者が目的、原資、DeFi総額、最大損失、停止条件を承認している。
2. チェーン・資産・プロトコル・コントラクト・関数・依存先を版管理した許可台帳がある。
3. 申請者、評価者、署名者、照合者、例外承認者を分け、代替要員を定めている。
4. 単一商品だけでなく共通の発行体、オラクル、ブリッジ、管理鍵を束ねて上限判定する。
5. calldataの解読結果と人の申請を結び、許可外操作を取引前に拒否する。
6. 操作IDで申請、承認、トランザクション、イベント、ポジション、仕訳を追跡できる。
7. 価格、担保、流動性、権限、アップグレード、一時停止、回収可能性を継続監視する。
8. 異常時にリスク増加操作を止めつつ、返済・引出・承認取消の経路を維持する。
9. 限定額で退出し、内部台帳・ウォレット記録・オンチェーン状態を照合している。
10. 法務、税務、会計、投資の判断を担う社内権限者と外部の相談先が決まっている。

実装チームに渡す仕様

ここからは、CFOが決めた方針を受けて、仕組みを作る実装チーム向けの内容です。

上限ごとの判定対象

• DeFi総額：時価と引出可能額の小さい方
• 共通依存先：発行体、ブリッジ、オラクル、管理主体
• プロトコル：供給額、借入額、未請求報酬
• 単一操作：送金・交換・供給・借入の予定額
• 損失・価格乖離：取得価額、時価、基準価格との差

許可台帳の項目と検証方法

許可台帳には表示名ではなく、チェーンID、コントラクトアドレス、プロキシと実装の関係、許可する関数、資産、最大金額、トークン承認額、期限、根拠資料、承認者、policy_versionを記録します。

申請・署名・実行の3層

1. 申請層: 人が読める申請と実際のcalldataを生成し、見積価格、有効期限、最低受取額、想定後ポジションを固定します。
2. 署名層: MPC（複数者で署名能力を分散する方式）またはマルチシグで、申請者・検証者・署名者を分けます。署名画面はトランザクションハッシュだけでなく、calldataを解読した結果を表示します。
3. 実行層: 許可リスト、関数制限、支出上限、頻度上限、timelockをGuardや専用実行コントラクトで強制します。

Safe公式Docsは、所有者（owner）の署名閾値に加え、Guardが取引の前後を検査し、Moduleが署名確認を迂回して実行できる構造を説明しています。Guardだけを入れて安心せず、Moduleの経路も同じ許可台帳の対象にします。

またSafeの警告どおり、壊れたGuardは全取引を止め得ます。監査、テスト、無効化・回収の経路が必要です。供給・借入・交換など操作ごとに承認内容（intent）を固定する方法とウォレット権限の分け方は機関DeFiの取引承認とウォレット権限、署名と鍵の分離は機関投資家向け暗号資産カストディ設計で詳しく扱います。

ポジションの状態

各操作へ一意なtreasury_operation_idを付け、申請、署名、トランザクション、イベント、プロトコル持分、会計仕訳を結びます。

APIがタイムアウトしても、失敗と決めつけて再送しません。同じ操作ID、nonce、トランザクションハッシュ、イベントを照会してから再実行します。二重の供給や交換を防ぐための冪等性（同じ操作を二度実行しない性質）で、考え方は保有全般の記事と同じです。

障害時に人が確かめること

• オラクル停止・乖離：代替価格、プロトコルの価格採用状況
• コントラクトのアップグレード：コード差分、監査、管理者、発効時刻
• ステーブルコインの価格乖離：償還、流動性、他ポジションとの共通依存
• プロトコルの一時停止：許可された操作、ガバナンスの告知、オンチェーン状態
• 鍵・端末侵害：未確定トランザクション、Module、所有者、トークン承認

XTELAができること

私たちは、プロトコルと権限の調査、許可台帳、ウォレットと承認の流れ、取引前の方針判定、オンチェーン監視、日次照合を組み合わせたDeFi運用の仕組みを設計・開発します。まず限定額で「止める・戻す・照合する」を通すPoC（概念実証）と障害訓練を行い、貴社の運用体制に合わせて本番へ広げます。実装の範囲の整理はお問い合わせからご相談ください。

主要参考資料

• 金融庁「分散型金融システムのトラストチェーンにおける技術リスク等に関する研究」（2026年8月12日確認）
• 金融庁「FATFによるDeFiに係る規制上の課題に関する報告書の公表について」（2026年9月24日確認）
• Safe Docs: Smart Account Concepts（2026年9月24日確認）
• Safe Docs: setGuard（2026年9月24日確認）
• Aave Docs: Changelog（v3.7 Part 1・Part 2）（2026年9月24日確認）
• aave-v3-origin: Aave v3.7 changelog（Isolation Mode廃止の記載、2026年9月24日確認）
• OpenZeppelin Docs: Access Control and TimelockController（2026年9月24日確認）
• 企業会計基準委員会「実務対応報告」（会計判断の確認先、2026年8月12日確認）

資料の確認日と注意

一次資料の最終確認日は2026年8月12日で、Aave・Safe・OpenZeppelin・FATF関連の記述は2026年9月24日に確認し直しました。Aave v3.7によるIsolation Modeの整理は、2026年9月24日時点の内容です。

公開資料に基づく一般的な技術・業務設計の解説です。DeFiの仕様、管理権限、法令、会計基準、税務上の取扱いは変わり得るため、投資・法務・税務・会計の個別判断は実行時点の一次資料をもとに専門家へご確認ください。