ERC-4626 Vault とは|運用商品を自作か既存採用か

コラム

約17分で読めます

コラム

約17分

ERC-4626 Vault とは|運用商品を自作か既存採用か
目次(タップで折りたたみ)

    本記事は技術解説であり、投資・税務・法務助言ではありません。判断は専門家にご相談ください。

    「自社で『運用商品』を Web3 ネイティブに作りたい」「機関顧客向けに固定利回り・自動運用の暗号資産商品を組みたい」——こうしたニーズで最初にぶつかるのが「Vault(バルト=保管庫)」という概念だ。Vault とは、ユーザーが資産を預けると裏側で複数の DeFi を組み合わせて自動運用してくれる仕組みで、いわば「DeFi 版の投資信託」だ。

    そして DeFi 業界は2022年以降、Vault の標準仕様として ERC-4626(イーアールシー・よんろくにろく) という規格を採用してきた。2024年に DeFi へ登場した BlackRock の BUIDL 本体は ERC-20 トークンだが、これを基盤資産として ERC-4626 互換のラッパー Vault が組まれ、機関向け運用商品レイヤーで ERC-4626 が共通言語になりつつある。本記事は事業者目線で「ERC-4626 とは何か」「自社の運用商品にどう組み込むか」「自作・既存採用・接続の3戦略をどう選ぶか」を、専門用語を最小限に押さえて解説する。


    目次

    1. なぜ事業者が ERC-4626 を理解する必要があるのか
    2. ERC-4626 とは — 「DeFi 版投資信託規格」の中身
    3. なぜ規格が必要だったのか — Composability の核心
    4. 主要な Vault 設計の3類型 — Yearn / Pendle / ERC-7575
    5. 仕様の理想と実装の現実 — 差分マトリクス
    6. 互換性を壊す「3つの実装地雷」
    7. 3つの戦略を選ぶ — 自作/既存採用/接続
    8. 開発期間とコスト、日本の規制論点
    9. まとめ

    1. なぜ事業者が ERC-4626 を理解する必要があるのか

    「自社で運用商品を組む」という事業構想の現実は、5年前と今では全く違う。

    5年前(2021年): 各プロトコルが独自仕様で Vault を設計していたため、Vault 間の連携が困難。Yearn の Vault と Aave のプールをつなぐには、間に専用の「接続コード」を書く必要があった。

    今(2026年): 主要 Vault は ERC-4626 規格に準拠している。規格に乗った Vault 同士は、追加開発なしで組み合わせられる。「Pendle で固定利回り化された Aave 預金を、自社の Vault で運用する」といった複雑な構成も、配管工事的に組める。

    事業者にとっての含意:

    • 自社で Vault を組むなら、ERC-4626 準拠が前提(他の DeFi と組み合わせる将来性を確保するため)
    • 既存 Vault に乗るなら、ERC-4626 規格のおかげで複雑な接続コードが不要
    • 機関接続が前提なら、BUIDL や Ondo OUSG 本体は ERC-20 だが、これらを基盤資産とする ERC-4626 互換のラッパー Vault(Securitize の sToken、Elixir deUSD 等)が機関向け運用商品レイヤーの共通言語になっているため、規格理解は必須

    つまり ERC-4626 は「DeFi の運用商品レイヤーで何かをする際の共通言語」となっている。理解しないと事業設計の選択肢が狭まる。


    2. ERC-4626 とは — 「DeFi 版投資信託規格」の中身

    仕様の核心は4つの関数

    ERC-4626 規格の本質は、Vault が必ず備えるべき4つの基本操作を定めたことだ。

    ERC-4626 Vault の 4 関数インターフェース

    図: deposit/mint で資産を預けて shares を受け取り、withdraw/redeem で shares を返して資産を引き出す。資産指定(deposit/withdraw)と shares 指定(mint/redeem)の双方向ペアが揃うことで、他プロトコルからの組み合わせ呼び出しが容易になる。

    操作 意味
    deposit(預ける) 資産を Vault に預けて、引き換えに「Vault 株式(shares)」を受け取る
    withdraw(引き出す) 株式を返して、元の資産(+利回り)を引き出す
    mint(株式数指定で預ける) 「○○ shares を受け取りたい」と指定して、必要分の資産を預ける
    redeem(株式数指定で引き出す) 「○○ shares を返して、その分を引き出す」

    つまり、Vault は「運用ファンドの株式」のような形で持ち分を管理する。ユーザーは「いくら預けたか」ではなく「何 shares 持っているか」で自分の持ち分を把握する。Vault 内の資産が増えれば(運用が成功)、1 share あたりの価値が上がる。

    投資信託との対応

    事業オーナーに馴染みのある言葉で対応づける:

    投資信託(伝統金融) ERC-4626 Vault(DeFi)
    ファンドへの入金 deposit
    ファンドからの解約 withdraw / redeem
    受益証券(口数) shares
    基準価額 1 share あたりの資産価値
    運用報酬 Vault のマネジメントフィー
    信託銀行 スマートコントラクト(の保管機能)

    違いは「人間が介在しない」「24時間動く」「Composability で他の DeFi に乗せ替えられる」点。

    規格化のメリット

    規格があることで:
    - ウォレット表示の標準化: 主要ウォレットが Vault 株式を「運用ポジション」として認識・表示できる
    - 他プロトコルからの接続容易性: Lending プロトコルが Vault 株式を担保として受け入れやすい
    - 監査の効率化: 監査ファームが「規格通り実装されているか」を素早く確認できる
    - 機関採用の条件: 機関投資家は「業界標準規格」を採用条件にすることが多い


    3. なぜ規格が必要だったのか — Composability の核心

    DeFi の最大の価値は「Composability(コンポーザビリティ=組み合わせ可能性)」だ。各プロトコルが他のプロトコルの上に積み重ねられる「マネーレゴ」構造を持つ。

    ERC-4626 以前の世界では、Vault ごとに deposit / withdraw の関数名や引数が違ったため、「Vault A の出力を Vault B の入力に直接渡す」ことができなかった。間に「接続シム」を書く必要があり、これがバグの温床にもなっていた。

    ERC-4626 は「全ての Vault が同じ顔をする」ことを保証した。これにより:

    • Pendle で固定利回り化された stETH の Vault を、Yearn の Strategy が運用する
    • Morpho で借りた USDC を、Pendle PT に変換して、機関向け Vault に組み込む
    • Yearn Vault の株式を、Morpho / Aave 系の Lending マーケットで担保化する

    ——こうした ERC-4626 互換 Vault 同士の構成が、追加の接続コードを書かずに組めるようになった。一方、BUIDL のような permissioned な RWA トークン(ERC-20・転送制限つき)を組み込む場合は、KYC・転送制限・oracle・流動性への別途対応が必要で、規格準拠だけで自動的に組めるわけではない。

    事業者目線では、「ERC-4626 準拠で Vault を組めば、将来の DeFi 進化の波に乗りやすい」という保険的価値が大きい。


    4. 主要な Vault 設計の3類型 — Yearn / Pendle / ERC-7575

    ERC-4626 は基本規格だが、その上に乗る Vault 設計には複数の流派がある。事業者が「どの設計を真似るか」を選ぶ際の主要3類型を整理する。

    類型1: Yearn 型(Strategy 集約)

    Yearn Finance v3 が代表する設計。「Vault の中に複数の Strategy(運用戦略)がある」構造。

    • Vault: ユーザーが預ける窓口
    • Strategy: 預けられた資産を実際にどこで運用するかを実装する個別ロジック
    • 1つの Vault に複数の Strategy を組み合わせて、リスク分散できる

    事業者にとっての意味: 「複数の DeFi 運用戦略を組み合わせて、リスク調整した運用商品を提供したい」場合の参考設計。詳細な内部設計は Yearn v3 Strategy アーキテクチャ で深掘り。

    類型2: Pendle 型(PT/YT 分離)

    Pendle Finance が確立した設計。「1つの利回り資産を、元本部分(PT: Principal Token)と利回り部分(YT: Yield Token)に分離する」構造。

    例: stETH(ステーキング報酬がつく ETH)を Pendle に預けると、PT-stETH(一定期日で固定額の ETH に償還される)と YT-stETH(その期間中の変動利回りを受け取る)に分離される。

    • PT を買えば「固定利回り商品」になる(株でいうゼロクーポン債)
    • YT を買えば「利回りに賭ける投機商品」になる
    • ユーザーは目的別に PT または YT を選べる

    事業者にとっての意味: 「固定利回りプロダクトを設計したい」「機関顧客向けに利回りリスクをヘッジした商品を組みたい」場合の参考。Pendle PT は stETH・sUSDe など主要 LST/利回り資産を基盤に急成長中(BUIDL 等の RWA 利回りも流入しつつある)。具体的な数学と自社固定利回り商品への組み込み手順は Pendle PT/YT 分離 で深掘り。

    類型3: ERC-7575(マルチアセット Vault)

    ERC-4626 の拡張規格として2024年以降に登場した ERC-7575 は「1つの Vault で複数の基盤資産を扱える」設計。

    ERC-4626 は「1 Vault = 1 資産」が原則だったが、ERC-7575 では複数資産(例: USDC + USDT + DAI)をまとめて扱える。Curve 系のステーブル特化 AMM 等と相性が良い。

    事業者にとっての意味: 「複数資産を一括で管理する Vault」「ステーブル間スワップ機能を持つ Vault」を組む場合の参考。

    3類型の使い分け

    設計目的 推奨類型
    シンプルな自動運用商品 Yearn 型
    固定利回りプロダクト Pendle 型
    複数資産バスケット商品 ERC-7575

    5. 仕様の理想と実装の現実 — 差分マトリクス

    ERC-4626 規格は理想的だが、実装段階では「仕様の解釈の幅」がある。事業者として知っておくべき差分:

    観点 規格の理想 主要実装の現実
    shares 計算精度 任意精度の小数 整数演算で丸め誤差が出る(特に初回 deposit 時)
    withdraw の即時性 即時引き出し可能 Strategy 側で資産がロックされていると、待機期間が発生
    手数料の扱い 規格は明記しない 実装ごとにマネジメントフィー・パフォーマンスフィー設計が異なる
    報酬の自動複利 規格は強制しない Vault によって複利のタイミングが違う(毎ブロック / 一定間隔)
    緊急停止 規格は明記しない 監査済み実装には pause 機能があるが、規格としては任意

    事業者が ERC-4626 互換と謳う Vault を採用する場合、「規格に準拠している」ことだけでなく、これらの実装詳細を必ず確認する必要がある。


    6. 互換性を壊す「3つの実装地雷」

    XTELA が自社実装支援で見てきた典型的な「ERC-4626 互換と見せかけて、実は互換性を壊している」実装地雷を3つ。

    地雷1: shares 計算精度問題(初回 deposit 攻撃)

    ERC-4626 の最も有名な脆弱性。初回 deposit で1 wei(最小単位)だけ預けて1 share を mint した後、攻撃者が直接 Vault に大量の資産を送り込むと、「1 share の価値」が急上昇する。後から預ける一般ユーザーは、自分の預入額に対して shares が0個になる(丸め誤差で)損失を被る。

    対策: 初期化時にプロトコル自身が一定量の shares を bootstrap として預ける、または最小 deposit 額を設ける、virtual shares を実装する。OpenZeppelin の v4.9 以降では対策版が標準提供されている。

    過去の実事例:
    - Sonne Finance(2024年5月): Optimism 上の Compound v2 fork で、新規マーケットの最初のブロックを使った類似の初回 deposit 攻撃により、約 2,000万 USD が流出。ERC-4626 そのものの hack ではないが、「初回供給の取り扱い」が攻撃面になる点で同根の問題
    - Hundred Finance(2023年4月): Optimism 上の Compound fork で、cToken/Vault 系の rounding と share 価格操作を組み合わせた攻撃で約 700万 USD が流出
    - その他複数の小規模 ERC-4626 互換 Vault: bootstrap shares 未実装で同種の attack を受けた事例が散発

    教訓: 「規格に準拠しているか」だけでなく「初回 deposit 時に bootstrap shares を強制しているか/virtual shares が実装されているか」を必ず点検する。OpenZeppelin の標準実装をそのまま採用するのが最も安全。出典: Rekt News で各事案の詳細参照。

    地雷2: withdraw 経路の安全性

    Vault が内部で別の DeFi に資産を回しているため、withdraw 時に「別 DeFi から資産を引き戻す」処理が走る。この処理が失敗・遅延すると、ユーザーが引き出せない事故が起きる。Yearn の過去事例では、Strategy がスタックして数日間 withdraw 不可になった例がある。

    対策: Strategy ごとに「即時引き出し可能な準備金」を保つ、withdraw が失敗した場合のフォールバック経路を設計する。

    地雷3: 報酬の reentrancy

    Vault が deposit/withdraw 時に「報酬の自動精算」をする実装で、その精算処理に外部呼び出しが含まれる場合、reentrancy 攻撃の経路になりうる。

    対策: 報酬精算は state 更新の前に完了させる、checks-effects-interactions パターンを徹底する、ReentrancyGuard を全関数に適用する。

    これらは ERC-4626 規格そのものの問題ではなく、実装段階の問題。XTELA は監査前の設計レビューで、これら3地雷を必ず確認する。


    7. 3つの戦略を選ぶ — 自作 / 既存採用 / 接続

    事業者が ERC-4626 Vault に関わる戦略は3パターン。

    A: 自作(自社で ERC-4626 Vault を構築)

    ゼロから自社専用 Vault を実装する。

    典型例:
    - 業界特化型 Vault(不動産 RWA バスケット、企業財務向け流動性管理 Vault)
    - 機関向け permissioned Vault(KYC 通過者のみ deposit 可)
    - 自社サービス内蔵の運用商品(フィンテックアプリの内部運用)

    採用条件:
    - 自社の差別化軸が「運用商品そのもの」
    - Solidity 開発者と監査対応の体制
    - 規制対応の覚悟(金商法・投資運用業の論点)

    メリット: 強い差別化、運用手数料を自社収益化
    デメリット: 2-4人月の実装、$25K-80K の監査費(規模・コード新規性・監査ファームで変動)、継続運用負担

    B: 既存採用(Yearn / Pendle / Sommelier 等を組み込む)

    既存の ERC-4626 互換 Vault を、自社プロダクトの裏側で使う。

    典型例:
    - 自社預金商品の運用を Pendle PT で固定利回り化
    - 暗号資産の自動運用を Yearn Vault に委託
    - BUIDL を基盤資産にした商品を組成

    採用条件:
    - 自社の差別化は UX・チャネル
    - 採用先 Vault の監査実績と運用履歴を信頼できる

    メリット: 1-2か月で実装可能、規格化のおかげで接続コストが低い
    デメリット: 採用先のリスクを引き受ける、差別化が UX に限定される

    C: 接続(Vault を組み合わせる中間レイヤー)

    複数の ERC-4626 Vault を組み合わせる中間レイヤーを提供する。アグリゲータ・ルーター的なポジション。

    典型例:
    - 複数 Vault のリスクリターンを比較・最適配分するロボアドバイザー
    - 法人向けの Vault 接続コンソール(複数 DeFi 商品を一括管理)

    採用条件:
    - 自社の付加価値が「比較・選定・最適化」
    - データ基盤・分析能力

    メリット: 開発工数小、Vault 側の進化に乗れる
    デメリット: Vault の仕様変更に振り回されるリスク

    3戦略の比較

    判断軸 A: 自作 B: 既存採用 C: 接続
    開発工数 中(2-4人月) 小(1-2人月) 小(〜1人月)
    規制対応コスト
    差別化余地
    必要な運用人員 中(Solidity 1-2人)
    着手期間目安 3-6か月 1-2か月 1-2か月

    8. 開発期間とコスト、日本の規制論点

    自社 ERC-4626 Vault 構築のコスト目安

    XTELA の支援実績から:

    開発(実装)項目 目安
    Solidity コア実装(ERC-4626 互換) 2-3人月
    Strategy 実装(外部 DeFi 連携) 1-2人月
    フロントエンド 1-2人月

    開発合計: 4-7人月(約 $40K-105K)

    ―― 以下は別途・規模で変動 ――

    • 注(監査): $25K-80K。規模・コード新規性・監査ファーム(簡易な個別契約か、複数社/トップティアか)で大きく変動。簡易な fork は下限、新規性が高い・複数社起用は上限。
    • 注(バグバウンティ): 月額 $5K-30K。報酬プールの規模・TVL 連動で変動。
    • 注(外部法務(弁護士費用の目安)): 初期の法的整理+意見書として一時 $20K-80K(約300万-1,200万円)が目安。これは外部弁護士に支払う費用の目安であり、XTELA が法律事務を提供するものではない。暗号資産交換業の登録取得・維持や本格的な業者化を目指す段階では、別途継続的な費用が発生する。

    日本の規制論点

    日本で Vault 商品を扱う際の論点:

    領域 関連法 主な論点
    顧客から資金を集めて運用 金商法(投資運用業) 第二種金商業・投資運用業登録の要否
    自社財務オペで Vault に預ける (ライセンス不要だが) 期末時価評価の取扱い(2024年4月施行の見直しで対応)
    顧客への Vault 商品提供 金商法(金融商品取引業) 「投資勧誘」の該当性、適合性原則
    海外 Vault への接続 改正資金決済法・FATF 暗号資産のクロスボーダー送金、トラベルルール

    これらは法務助言の領域。コンプラ部門と弁護士に確認すること。

    税制との接続

    法人で Vault に資産を預ける場合、2024年4月施行の期末時価評価見直し(自己発行以外で第三者保有の暗号資産は一定要件下で対象外)に該当するかが論点。Vault の shares 自体が「暗号資産」「証券」「その他金融資産」のどれに分類されるかは、設計と発行体次第。税理士に確認すべき。


    9. まとめ

    事業者目線で ERC-4626 を理解する要点は5つ。

    1. ERC-4626 = DeFi 版投資信託規格。預ける・引き出すの基本操作が標準化され、Vault 同士の組み合わせが容易になった
    2. 規格の本質は Composability。規格に乗っておけば、将来の DeFi 進化に追随しやすい
    3. 3類型の使い分け: Yearn 型(Strategy 集約)、Pendle 型(固定利回り)、ERC-7575(マルチアセット)
    4. 互換性を壊す3地雷: shares 計算精度、withdraw 経路の安全性、報酬 reentrancy。事前レビュー必須
    5. 3戦略「自作/既存採用/接続」で開発工数・規制対応・差別化のトレードオフを判断

    詳しくは DeFi完全マップ 2026 で全体像と他プロトコルとの関係を整理している。


    関連記事

    ERC-4626 を自社の運用商品に組み込む3戦略(自作/既存採用/接続)を、隣接する設計に広げる記事を整理しました。

    • Yearn v3 Strategy アーキテクチャ — 本記事 4章 類型1「Yearn 型(Strategy 集約)」の内部設計を、複数ファンドマネージャーの並列運用として深掘り
    • Pendle PT/YT 分離 — 本記事 4章 類型2「Pendle 型」の元本/利息分離と、固定利回り商品設計のバックエンド
    • Aave v3 利率モデル — Strategy 内部運用先の代表。Vault 設計の前提となる Lending 利率の理解
    • Morpho Blue — ERC-4626 を MetaMorpho Vault として活用する代表事例。市場分離設計との接続
    • Flash Loan の実装と用途 — 本記事 6章「地雷1 初回 deposit 攻撃」「地雷3 reentrancy」の防御設計と関連する Vault 攻撃面

    XTELA の Vault 実装支援知見

    本セクションは XTELA のサービス紹介です。本文中立の技術解説とは分離して掲載しています。

    XTELA は2015年以降、50案件以上のブロックチェーン開発支援を行ってきました。Vault 関連について、以下のような支援が可能です:

    • ERC-4626 互換 Vault の自社実装: shares 計算精度の検証、初回 deposit 攻撃の防御、virtual shares 実装
    • Strategy 設計レビュー: 外部 DeFi 連携の安全性確認、withdraw 経路のフォールバック設計
    • 業界特化型 Vault 設計: 不動産 RWA、機関 permissioned、企業財務向け
    • 既存 Vault 接続の設計: Yearn / Pendle / Sommelier との API 連携、リスク比較分析
    • 監査前の設計レビュー: ERC-4626 互換と謳う実装の真の互換性検証、3地雷の事前潰し

    「Vault プロダクトを自社で組むか、既存を組み込むか、接続レイヤーで乗るか」の意思決定段階から、実装・監査・運用までを並走支援しています。

    無料技術相談はこちら

    本記事は XTELA JAPAN 株式会社が作成しました。 Vault 開発に関するご相談は無料技術相談からお問い合わせください。

    お問い合わせ

    どんなフェーズからでも、お持ちのアイデアや企画をもとにご提案可能です。
    まずはお気軽にご相談下さい!