企業がDeFiプロトコルを採用する前に｜「監査済み」だけで決めない7つの確認

ある会社の財務部門が、手元の資金の一部をDeFiで運用できないかを検討しています。候補のプロトコルの公式サイトには、「監査済み」とはっきり書いてあります。

ところが、セキュリティ担当が調べると、気になることが出てきました。監査報告書が見ていたのは、ある時点のコードと、ある1つのチェーンでした。自社が実際に呼ぶことになるのは、別のチェーンの別の市場で、プロキシの先にある実装も違うかもしれません。これでは、「監査済み」は判断の根拠になりません。

同じ名前のプロトコルでも、チェーンや市場が違えば、中身は別物です。実際に動くコード、管理者、担保、価格の取り方、止め方まで変わります。

では、採用するかどうかを何で決めればよいのか。答えは、実際に呼ぶチェーンとコントラクトを特定し、そのうえで集めた証拠です。

• 権限、外部への依存、流動性、退出の手段など、7つの観点で証拠をそろえる
• 点数を付ける前に、不合格の条件に引っかからないかを確かめる
• 最後は、自社の利用上限と停止の条件を付けた「条件付きの採用」として決める

以下では、この財務部門とセキュリティ担当が、候補の比較から導入後の見直しまでを進める流れで見ていきます。特定の銘柄の推奨や、投資の判断は扱いません。DeFiの全体像はDeFi完全マップ 2026、学ぶ順番はDeFi学習ロードマップが入口になります。

最初に、実際にお金が通る道を特定する

同じ名前のプロトコルでも、次のものが違えば、コード、管理者、担保、オラクル、流動性、止め方も変わります。

• チェーン、市場（market）、ボールト
• フロントエンド、ルーター
• プロキシ経由で動く実装コントラクト

監査報告書が評価した版と、自社が呼ぶデプロイが一致しなければ、「監査済み」は根拠になりません。そこで候補に点数を付ける前に、評価する対象を1件ずつはっきりさせます。用途、チェーン、入口と実装のコントラクト、資産、依存先、特別な権限、確認した日時です。記録の形の例は、後半の「実装する人向けの詳細」に載せました。

アプリのURLやトークンのシンボルは、偽のフロントエンドや偽のトークンでも同じに見せられます。だから、見分ける手がかりにはしません。公式のアドレス一覧、ブロックエクスプローラー、プロキシの保存領域、検証済みのソース、実行時のchainId（チェーンの番号）を照らし合わせます。アプリの側でも、想定外のチェーンやアドレスへの署名を拒否します。

Aaveも、デプロイしたアドレスを一覧（address book）として公開しています。「公式Docsに名前がある」ことと「つなぐ先が同じ」ことを、分けて確かめる材料になります。

何を確かめるか：7つの証拠

金融庁のDeFiの技術リスクの調査は、スマートコントラクト、オラクル、ガバナンス、相互運用、緊急停止、不測時の対応などを横断して整理しています。OWASP SCSVSも、アーキテクチャ、コード、ビジネスロジック、アクセス制御、外部通信、オラクル、ブリッジなどを、別々の検証群として扱います。

企業の評価でも、コードの監査だけにまとめません。次の7つを並行して確かめます。それぞれ、何を問い、どうなら止めるかを示します。

1. 範囲とコード：何が実行され、後から変えられるか。実装を特定できない、監査していない差分を説明できないなら止める。
2. 権限とガバナンス：誰が資金・ルール・実装を変えられるか。1つの鍵で資金の移転やアップグレードができる、変更に退出の前に気づけないなら止める。
3. 経済・会計：どんな状態で債務超過や取り付けが起きるか。会計を計算し直せない、損失の上限を置けないなら止める。
4. 外部への依存：どの第三者の障害が、資金の損失につながるか。1つの依存先が止まったり改ざんされたりしたときに、安全な状態へ移れないなら止める。
5. 流動性と出口：ふだんと、市場が荒れたときに、撤退できるか。必要な期限内に退出する道がない、自前の流動性で指標が回っているだけなら止める。
6. セキュリティ運用：異常に誰が気づき、封じ込め、復旧するか。重大なときの責任者・権限・復旧の条件が分からないなら止める。
7. 自社の統制：プロトコルが正常でも、自社の側で失わないか。トークンの承認が無制限、職務が分かれていない、台帳を照らし合わせられないなら止める。

それぞれで集める最低限の証拠は、次のとおりです。

各行には、「確認済み」「条件付き」「未確認」「不合格」のどれかを付けます。あわせて、証拠のURL・ブロック番号・取得日時・担当者を記録します。

資料がないことを低い点数として平均に混ぜると、重大な穴が、ほかの項目の点数に隠れてしまいます。だから、重大な権限や、お金の通り道が確かめられていないなら、平均を見ずに採用を止めます。

監査報告書は、どこまで読めばよいか

監査の件数を数えるだけでは、評価された範囲と本番のデプロイの差が見えなくなります。報告書ごとに、次のことを抜き出します。

• 対象のリポジトリ、コミット、コントラクト、チェーン
• 監査日、手法、重大度の定義
• 修正の確認、対象から外した範囲

そのうえで、監査したコミットから今の実装までの差分を確かめます。追加されたモジュール、初期化の値、権限の引き渡し、外部への依存の変更も見ます。

• コードが同じか：エクスプローラーの検証済みソースだけでなく、実行時のバイトコードとコンパイラの設定、リンクされたライブラリ、プロキシの実装を照らし合わせる。
• 見つかった問題：Critical/Highだけでなく、「認識済み（acknowledged）」「一部修正」「運用で軽減」とされた項目の担当と期限を確かめる。
• 検証の深さ：単体テストがあるかではなく、壊しにいった証拠を見る。資産の保存則、持分の価格、清算、権限の範囲を、性質ベースのテスト、ファジング（大量の入力を自動で試す手法）、フォーク環境のテストで試したか。
• 変更の管理：アップグレード提案のcalldata（コントラクトへ渡す呼び出しの中身）、シミュレーションの結果、タイムロックの後に実行されたトランザクションが、承認した中身と一致するかを確かめる。

OWASP SCSVSは、評価の範囲・合否・証拠をはっきり示す公開型（open-book）の検証を勧めています。自動のツールだけでは足りない、とも説明しています。監査は大事な証拠の1つですが、安全の保証や継続的な見張りの代わりにはなりません。監査の進め方はスマートコントラクト監査の工程と費用目安で扱っています。

管理者が「何をできるか」を1つずつ書き出す

「管理者がいるか、いないか」だけでは判断できません。見るのは、実際にどんな操作ができるかです。たとえば次の3つです。

• 実装を差し替えられるのは誰か
• 資金を動かせるのは誰か
• 即時に止められるのは誰か

権限を持つ役割をアドレスごとに書き出し、それぞれが何を、どの上限で、何秒後に実行できるかを表にします（書き出す役割の一覧は後半）。

DAOの投票の仕組みがあっても、緊急停止の権限者やマルチシグが、投票を経ずに即時に広い操作をできることがあります。その場合、実際に信頼しなければならない相手は、投票ではなくその権限者です。

OpenZeppelinのTimelockControllerは、管理の操作を遅らせ、利用者が変更を確かめて退出する時間を作ります。ただし、遅らせる仕組みがあるだけでは足りません。次のことを確かめます。

• 提案、取消、実行、遅延の変更を、誰ができるか
• 最低の遅延が、自社が気づいて退出するまでの時間より長いか
• 緊急の手段で、タイムロックを飛ばせないか

待ち時間の考え方はマルチシグ・タイムロックの本番権限設計で詳しく扱います。

マルチシグのSafeに付けるモジュールも確かめます。モジュールは、ふだんの承認の流れとは別に、どんなトランザクションでも実行できます。公式Docsも、信頼でき監査されたモジュールだけを有効にするよう警告しています。

だから、署名者としきい値だけで評価しません。有効なモジュール、Guard（取引の前後に追加のチェックを行う仕組み）、fallback handler、所有者が別のSafeである場合の入れ子の構造までたどります。

操作ごとに、誰が行い、そのとき自社がどう身を守るかは次のとおりです。

遅延・上限と、変更に気づく方法は、後半の表にまとめています。

オラクル、ブリッジ、流動性は、損失につながる1本の道として試す

依存先は、一覧にするだけでは足りません。わざと故障を起こし、自社のポジションにどう伝わるかを確かめます。

• 貸付の場合：オラクルの誤った値や更新の停止が担保の価値に入り、清算と流動性不足を通じて、回収できない債務（bad debt）に至る。
• ブリッジの資産の場合：送り元でロックした資産、検証者、メッセージの確定、発行の上限のどれかが破れると、担保の価値そのものが失われうる。

Chainlinkの公式Docsは、フィードごとの性質を確かめる必要があると説明しています。取引時間、流動性、価格の乖離、更新の頻度などです。そして、利用する側で、最新の回答の時刻や妥当性を確かめる必要があるとしています。

「Chainlinkを使用」の一行では、分からないことがたくさんあります。対象のフィード、プロキシのアドレス、最大の更新間隔（heartbeat）、更新のきっかけになる乖離幅、L2のシーケンサーが止まったときの扱い、代わりの手段です。

試すことは、次の4つです。

1. 価格を急に動かす・止める・逆に動かし、預入、借入、引出、清算がどう変わるかを、フォーク環境で再生する。
2. 主な流動性の提供者を引き揚げさせ、自社の想定額を期限内に退出させた場合のスリッページと、残るポジションを測る（取引量ではなく自社の額で測る）。
3. ブリッジ、L2のシーケンサー、キーパー（清算などの処理を外から呼び出すボット）、RPCを別々に止め、失敗が安全な取り消し（revert）か、未確定の状態か、誤った成功かを分ける。
4. 同じ資産を、担保、流動性提供の持分、ボールトの持分として重ねて数えない。元の資産・発行体・ブリッジ・オラクルへの集中を、一つずつほどいて見る。

今の担保の構成、流動性、上限、オラクル、アップグレードの権限が過去と違えば、過去の実績はそのまま当てはまりません。だから、「過去最大の価格変動に耐えた」だけで合格にはしません。

点数を付ける前に、不合格の条件を確かめる

点数を平均すると、隠れてしまう問題があります。たとえば1つの鍵で全資金を動かせるという問題が、ドキュメントの充実やTVLの大きさの加点で埋もれます。先に不合格の条件（ハードゲート）で判定し、通った候補だけを比べます。

合格に届かなくても、条件を付ければ採用できる場合があります。

• 対象の同一性：差分を自社でレビューした
• 最大損失：ポジション・資産ごとの上限で縛る
• 変更までの猶予：即時に変えられる対象を限り、見張る
• 退出の可能性：段階的な引き出しと、代わりの流動性を確保する
• 運用の可能性：使う時間と上限を限る

合格しても、結論は「安全」ではありません。どの用途で、どの資産・チェーン・アドレスを、いくらまで、どの期間、どの見張りと停止の条件で使えるかという、条件付きの決定です。残るリスクの責任者、見直しの日、必ず見直しをするきっかけを、承認の記録に残します。採用した後の上限・許可の台帳・回収の手順は企業財務のDeFi運用ポリシーで扱います。

PoCでは、利回りではなく壊れ方を確かめる

本番前のPoCで、預け入れと引き出しが成功するだけでは足りません。フォーク環境で今のコントラクトの状態を固定し、実際に想定する取引額と、自社のウォレットの方針を使って、次のことを試します。

• 想定外のチェーン、偽のトークン、偽のフロントエンド、アドレスのすり替えを、署名の前に拒否できる。
• トークンの承認を必要な額・期間に限り、緊急時に取り消せる。
• オラクルの停止、価格の急変、流動性の流出、ガスの高騰、RPCの食い違い、チェーンの再編成のときに、2重に実行しない。
• アップグレード、ロールの変更、上限の変更、一時停止に気づき、新しい取引を自動か手動で止められる。
• ポジション、ウォレット、社内の台帳、会計の記録を、ブロックハッシュとトランザクションの単位で照らし合わせられる。
• 担当者の不在、署名端末1台の紛失、外部の見張りの停止を含む、机上と実地の演習で復旧できる。

受け入れの物差しは、平均の年利（APY）ではありません。最大のポジション、最大の追加の損失、退出し終えるまでの時間、照らし合わせが済んでいない件数、重大な変更に気づくまでの時間、取引を止めていた時間、復旧後に残高が一致するかです。

これらを満たせないなら、上限を下げる、機能を手動の承認へ戻す、依存を減らす、あるいは採用しない、のどれかを選びます。

導入した後は、何かが変わるたびに見直す

プロトコルの実装や管理者、担保などは、導入した後も変わります。そのため評価書は、作った日から古くなっていきます。定期的な見直しに加えて、次のものが変わった時点で評価し直します。

• 実装、管理者・署名者、タイムロック
• オラクル、ブリッジ、担保資産、リスクの設定値
• 監査の結果、重大な事故、利用規約・運営主体

Aaveのガバナンスフォーラムで示された「Aave Risk Framework」の提案（ARFC）も、同じ考え方です。資産を採用するときだけでなく、資産ごとの四半期の見直しを前提にしています。発行・焼却の権限の追加、コントラクトのアップグレード、ブリッジの経路の変更といった重要な変更のときにも、評価し直すとしています。

見張りは、プロトコル側のダッシュボードだけに頼りません。次のものを、独立したRPCと複数の通知の経路で観測します。

• 自社のポジション、トークンの承認、純流出、持分の価格
• オラクルの鮮度、プロキシの実装、ロール、一時停止
• ガバナンスの提案

運用の手順書には、更新前の安全な上限に戻す手順を入れます。新しい取引を止めても、返済や引き出しを妨げない操作の順番も入れます。ガバナンス提案の検知と影響の分析はDeFiガバナンス変更の監視と影響分析、本番後の見張りと緊急対応はスマートコントラクト本番運用で扱っています。

最初にやる3つ

ここまでの内容は多いので、始めるときは次の3つからにします。

1. 対象のアドレスを特定する：用途、チェーン、入口と実装のコントラクト、資産を固定する。
2. 権限の表を作る：実装を差し替えられる人、資金を動かせる人、即時に止められる人を、アドレスごとに書き出す。
3. 不合格の条件を確かめる：5つの判定項目に引っかからないかを、点数を付ける前に見る。

実務で使う最終確認

• 用途、チェーンID、全コントラクトのアドレス、資産、ブロック、確認日時を固定した。
• 監査対象のコミットと本番のバイトコード、プロキシの実装、初期化の値、監査していない差分を照らし合わせた。
• 所有者、管理者、緊急停止の権限者、マルチシグ、モジュール、タイムロックと、実行できる操作を書き出した。
• 資産・負債の不変条件、清算、上限、担保・流動性・発行体の集中をストレステストした。
• オラクル、ブリッジ、シーケンサー、キーパー、RPC、フロントエンド、カストディを、損失につながる道として試した。
• 自社の想定額の退出、一時停止中の返済・引き出し、障害後の照合・復旧を再現した。
• 不合格の条件、分からない点、残るリスク、利用上限、停止の条件、責任者、見直しのきっかけを承認した。
• 法務・規制・税務・会計と投資の判断を、技術の評価と分けて、社内の担当へ回した。

実装する人向けの詳細

ここからは、評価の記録や権限の表を実際に作る担当者向けの補足です。

評価対象の記録の例

1件の評価対象を、次のような形で固定します。

{
  "use_case": "stablecoin collateral lending",
  "chain_id": 1,
  "entry_contract": "0x...",
  "implementation": "0x...",
  "block_number": 0,
  "assets": ["asset address ..."],
  "dependencies": ["oracle", "bridge", "keeper", "frontend", "RPC"],
  "privileged_roles": ["upgrade", "pause", "risk parameter"],
  "evidence_checked_at": "2026-08-13"
}

アドレスごとに書き出す役割

• アップグレード管理者、プロキシ管理者、所有者
• 一時停止の権限者、緊急停止権限者
• リスク設定の担当、オラクル管理者、ブリッジの中継者
• 資金管理、Safeのモジュール

特権操作ごとの遅延と検知

XTELAができること

私たちは、採用候補のデプロイと資金経路の棚卸し、脅威モデル、権限と依存関係の可視化、フォーク環境での故障注入を行い、監視・停止・照合・復旧までを実装できる受入基準に落とし込みます。評価の結果をそのままPoC（概念実証）として動かし、貴社が条件付きで採用できるかを確かめます。DeFi導入前の技術評価のご相談はお問い合わせからどうぞ。

主要参考資料

• 金融庁「分散型金融システムのトラストチェーンにおける技術リスク等に関する研究」研究結果報告書（DeFiの技術リスク、緊急停止、不測時対応。2026年8月13日確認）
• OWASP Smart Contract Security Verification Standard（アーキテクチャ、コード、権限、オラクル、ブリッジ等の検証群。2026年8月13日確認）
• OWASP SCSVS: Assessment and Certification（評価範囲、証拠、自動検査の限界。2026年8月13日確認）
• OpenZeppelin Contracts: Access Control（管理権限、2段階移管、タイムロック。2026年9月24日確認）
• Safe Docs: Smart Account Modules（モジュールの実行権限とセキュリティ上の注意。2026年9月24日確認）
• Chainlink Docs: Selecting Quality Data Feeds（フィードの市場・流動性・更新特性と利用側の検証。2026年8月13日確認）
• Aave Governance: [ARFC] Aave Risk Framework（四半期の見直し、重要変更時の再評価。2026年9月24日確認）
• BGD Labs: Aave Address Book（公式デプロイアドレスの一覧。2026年8月13日確認）

資料の確認日と注意

一次情報は2026年8月13日に最終確認し、Aaveのリスクフレームワーク、OpenZeppelin、Safeの記述は2026年9月24日に確認し直しました（ARFCの内容は2026年9月24日時点）。公開情報にもとづく一般的な技術・運用評価の解説で、特定のDeFiプロトコル、トークン、投資行動を勧めるものではありません。安全性や収益も保証しません。仕様、管理権限、デプロイ、流動性、制度は変わるため、導入時点の一次資料とオンチェーンの状態を確認してください。法務・税務・会計の判断は、専門家へご確認ください。