Yearn v3 Strategy｜Vault 内部の複合運用設計

「自社で Vault プロダクトを組むとき、内部運用はどう設計するか」——この問いに対する代表的な答えが Yearn v3 Strategy アーキテクチャ。本記事は事業者目線で、これを「複数のファンドマネージャーを雇う設計」として整理する。

目次

1. なぜ事業者がこれを理解する必要があるのか
2. Yearn とは — 「預けるだけ」を発明したプロジェクト
3. Yearn v3 Strategy とは — ファンドマネージャーの集合
4. v1 → v2 → v3 への設計進化
5. Strategy ローテーションとパフォーマンスフィー設計
6. 自社 Vault に応用する判断
7. 開発期間とコスト、日本の規制論点
8. まとめ

1. なぜ事業者がこれを理解する必要があるのか

事業者が「機関顧客向け預金商品」「業界特化型運用 Vault」を組むとき、内部運用を:

• 1つの DeFi に集中: シンプルだがリスク高
• 複数の DeFi に分散: リスク分散できる

後者を実現する標準設計が Yearn v3 Strategy。だが、なぜ「Yearn」がその標準になったのか。設計を語る前に、このプロジェクトが何を解いてきたかを押さえておきたい。

2. Yearn とは — 「預けるだけ」を発明したプロジェクト

成り立ち — 1人の開発者の自動化ツールから始まった

Yearn Finance（当初は iearn）は、南アフリカの開発者 Andre Cronje が 2020 年に公開したプロジェクトだ。出発点は壮大なものではなく、彼自身が手作業でやっていた作業の自動化だった。

2020 年の DeFi は「DeFi サマー」と呼ばれる利回り急騰期にあった。Aave、Compound、MakerDAO といった Lending プロトコルが乱立し、同じ USDC を預けてもどこに預けるかで金利が日々入れ替わる状態だった。最も利回りの高い場所を探し、資金を移し替える——この「イールドファーミング」を手作業でやるのは、ガス代も手間も膨大だった。

Cronje が作ったのは、複数の Lending プロトコルの金利を監視し、最も利回りの高い先へ自動で資金を移すスマートコントラクトだった。ユーザーは USDC を預けるだけでよく、最適化はコントラクトが担う。これが「預けるだけで運用が自動化される」という、後の Yearn の中核思想になる。

YFI の公平ローンチ — DeFi の歴史的事件

Yearn が DeFi 史に名を刻んだのは、技術だけでなく YFI トークンの配布方法による。Cronje は平素から次のように語っていた。

「I test in prod（私は本番環境でテストする）」 ——そして YFI 自体についても 「価値のないトークン（valueless / worth nothing）」 と公言していた。

2020 年 7 月にガバナンストークン YFI を発行する際、Cronje は当時として異例の配布を行った。

• 事前マイニング（premine）なし — 開発者・チーム・投資家への先行割り当てがゼロ
• VC 割り当てなし、プライベートセールなし
• 初期ミント 30,000 YFI（その後ガバナンスによる調整を経ている）を、プロトコルに流動性を提供したユーザーへ完全に分配

創業者自身が特別枠を一切持たないこの配布は「公平ローンチ（fair launch）」と呼ばれ、DeFi における「コミュニティ所有」の象徴的事例になった。「価値がない」とされた YFI はその後、需要の集中で一時 Bitcoin 1 枚を上回る価格をつけ、ガバナンスは DAO（yearn.finance コミュニティ）へ移管された。事業者にとっての教訓は価格ではない。トークン配布の設計そのものが、プロジェクトの信頼性とコミュニティの結束を決定づけるという事実だ。

Yearn が解いた問題 — 「複雑な利回り運用」を「預けるだけ」に変換

Yearn の本質は、ひとことで言えば抽象化だ。

DeFi で利回りを最大化しようとすると、本来ユーザーは次を自分でやらねばならない:

• 複数プロトコルの金利・報酬トークンを比較し続ける
• 報酬トークン（COMP、CRV 等）を売却して元資産に戻す（自動複利）
• ガス代と機会損失を勘案して資金移動のタイミングを決める
• 各プロトコルのスマートコントラクトリスクを評価する

Yearn の Vault は、これら全てをコントラクト側に押し込む。ユーザーに見えるのは「資産を預ける／引き出す」だけ。複雑な運用ロジックは Strategy という部品の中に封じ込められる。後述する v3 の Vault / Strategy 分離アーキテクチャは、この「複雑さをどこに閉じ込めるか」という設計思想の到達点だ。

事業者が Yearn を Vault 設計の参考にすべき理由はここにある。Yearn は単なる「高利回りツール」ではなく、運用の複雑さをエンドユーザーから隠蔽し、シンプルな預金体験に変換する設計パターンの原典なのだ。

3. Yearn v3 Strategy とは — ファンドマネージャーの集合

直感的説明

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

つまり「1つの Vault に複数の Strategy（=ファンドマネージャー）を雇って、運用を分散させる」設計。

Strategy の役割

各 Strategy は「特定の DeFi 運用に特化した個別ロジック」だ。例:

• Strategy A: Aave USDC プールに預けて利息収益
• Strategy B: Curve USDC/DAI プールで流動性供給収益
• Strategy C: Pendle PT（Principal Token、元本部分を分離したトークン）で固定利回り
• Strategy D: Yearn 自身の別 Vault に再投資

ユーザーが Vault に USDC を deposit すると、Strategy A/B/C/D に自動配分される。各 Strategy の収益は Vault に還元され、ユーザーは「シンプルな USDC 預金」体験で運用利回りを受け取る。

4. v1 → v2 → v3 への設計進化

Yearn のアーキテクチャは、運用の自動化を「どこまで、どう部品化するか」を巡って 3 世代を経てきた。事業者が Vault を自前で設計するなら、この進化の「なぜ変えたか」こそが最も学びになる。

v1 (2020) — 単機能の自動最適化

最初の Vault（当時 yVault）は、特定の単一戦略を実装した一枚岩のコントラクトだった。USDC を預けると、決め打ちされた運用先（例: Curve プールへの流動性供給と報酬の自動複利）で回す。シンプルで強力だったが、戦略を変えるにはコントラクトごと作り直す必要があり、柔軟性に乏しかった。

v2 (2021-2023) — Strategy の概念を分離

v2 で Yearn は Vault と Strategy を初めて分離した。

• Vault = ユーザー資産を預かり、会計・入出金を担う「器」
• Strategy = 実際の運用ロジックを担う「部品」

これにより、1 つの Vault に複数の Strategy をぶら下げ、配分を調整できるようになった。運用先の追加・差し替えが Vault を作り直さずに可能になり、Yearn は急速に対応プロトコルを増やせた。一方で、Strategy は Yearn 独自の Vault インターフェースに強く結合しており、Strategy を書くには Yearn 固有の作法を深く理解する必要があった。これが外部開発者の参入障壁になっていた。

v3 (2023-) — Tokenized Strategy と ERC-4626 への全面移行

v3 の最大の転換は、Strategy 自体を独立した ERC-4626 準拠の Vault にしたこと——これが「Tokenized Strategy（トークン化された戦略）」だ。

v2 では Strategy は Vault の従属部品にすぎなかった。v3 では各 Strategy がそれ単体で完結する標準 Vaultとして動く。結果として:

• モジュール性の徹底: Vault は「複数の ERC-4626 Strategy に資産を配る Allocator（配分器）」に純化。Strategy は単独でも、別の Vault の部品としても使える
• 開発参入障壁の低下: Strategy が標準インターフェース（ERC-4626）で書けるため、Yearn 固有の作法に縛られず、外部開発者が Strategy を持ち込みやすくなった
• 構成の自由度: 「Vault の中に Vault」を入れ子にでき、複数 Strategy の並列配置・動的配分・無停止での追加削除が自然に表現できる
• 権限の分離: 運用者（Strategy 配分を動かす役割）と管理者（緊急停止・パラメータ変更）を役割ごとに分けやすい設計に

なぜ「分離アーキテクチャ」へ進んだのか。理由は明快だ。v2 の密結合ではStrategy の安全性レビューと Vault の会計ロジックが絡み合い、監査範囲が膨らみ、外部の Strategy を信頼して組み込むのが難しかった。各 Strategy を標準化された独立 Vaultとして切り出せば、Strategy 単位で監査・検証・差し替えができる。Yearn は「複雑さを部品の境界で封じる」方向に舵を切ったのだ。

事業者目線の含意は次の通り。v3 の方が運用柔軟性が高く、Strategy 単位でリスクを隔離できるため機関顧客向け商品設計に向く。そして Strategy が ERC-4626 標準である以上、自社開発の Strategy を他プロジェクトと相互運用させたり、第三者監査を受けやすくしたりできる。

補足: ERC-4626 とは — トークン化された Vault（預けると預り証トークンを受け取り、引き出すと元資産が戻る金庫）の入出金・残高計算インターフェースを統一した標準規格。Fei Protocol の Joey Santoro らが中心となり 2022 年に策定された。Yearn は早期からその採用・普及を推進し、v3 でこの規格を全面採用した。Vault 同士・Strategy 同士が「同じコンセント形状」で繋がるため、組み合わせ（コンポーザビリティ）が一気に容易になる。

現在の立ち位置 — ERC-4626 標準化への影響と機関利用

Yearn は単なる一プロダクトを超え、DeFi の Vault 設計の事実上のリファレンスになっている。ERC-4626 が業界標準として普及した今、新規プロジェクトが Vault を組むときの出発点は「Yearn v3 がどう解いたか」になることが多い。Strategy を独立 Vault として切り出す設計、無停止での Strategy ローテーション、フィー会計の分離——これらは機関向けの運用商品（透明性・監査性・リスク隔離が要件になる領域）が求める性質と一致している。だからこそ、自社で「機関顧客向け預金商品」「業界特化型 Vault」を組む事業者にとって、Yearn の設計は模倣すべき青写真として価値を持つ。

5. Strategy ローテーションとパフォーマンスフィー設計

Strategy ローテーション

市場環境の変化で、収益性の高い DeFi 運用は時期によって変わる。「Strategy ローテーション」は、Vault が定期的に Strategy 配分を見直し、効率の高い Strategy に資金を寄せる仕組み。

例:
- 第1四半期: Aave 利率が高い → Strategy A 60%、他 40%
- 第2四半期: Pendle PT 利率が魅力的 → Strategy C 50%、他 50%

ローテーションは:
- 自動（ボラティリティ・利回り指標で機械的に判断）
- 半自動（運用チームが提案し、ガバナンスで承認）
- 手動（運用チームが裁量で実行）

パフォーマンスフィー

事業者の収益源として、Vault は以下のフィーを設計可能（Yearn V3 の基本設定は performance fee 10%・management fee 0%。以下は一般的な設計レンジ）:

機関向け Vault では Performance Fee が主要収益源。

6. 自社 Vault に応用する判断

採用すべきケース

• 複数の DeFi 運用を組み合わせるプロダクト
• リスク分散が顧客にとっての価値
• 機関向け（運用詳細の透明性が求められる）

採用しないケース

• 単一プロトコルへの預入ラッパー
• 個人向けで運用詳細を隠したい場合

設計の核心

• Strategy のセキュリティレビュー: 各 Strategy が独立して安全か（reentrancy（再入攻撃、同一関数を入れ子で呼び出される脆弱性）対策、外部 DeFi の依存リスク）
• 緊急 pause 機能: 特定 Strategy で問題が起きたとき、その Strategy だけ止められる
• 収益のフェアな分配: パフォーマンスフィーの計算が透明

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

Vault + Strategy のコスト目安

※為替は約 150 円/USD で換算。

注: 監査費用は規模・コード新規性・監査ファーム（簡易な個別契約か、複数社/トップティアか）で大きく変動する。ERC-4626 準拠の標準的な Vault + Strategy で新規性が低ければ下限、外部 DeFi 連携が複雑・新規性が高い・複数社を起用する場合は上限に振れる。

日本の規制論点

コンプラ部門と弁護士に必ず確認。

過去のインシデントから学ぶ設計教訓 — Iron Bank / Strategy スタック損失事例

Yearn の Strategy 設計を採用する際、想定すべき事例が 外部 Lending プロトコル経由の連鎖損失。Yearn は過去、複数の Strategy が Iron Bank（Cream Finance の lending マーケット） に資金を回しており、Iron Bank 側の問題（複数の hack 事案）に Strategy が連動した。Strategy 単体は監査済みでも、Strategy が deposit する 外部プロトコル側で hack や bad debt が発生すれば、Strategy 経由で Vault 損益に波及する 構造的リスクが顕在化した。

さらに、Yearn には過去「Strategy が外部プロトコルで資金を引き戻せなくなる（スタックする）」事例もあり、Vault からの withdraw が一時的に制約されたケースがある。

事業者にとっての含意:
- Strategy の「独立性」と「外部依存」のトレードオフ: 単一プロトコル接続より分散の方が一見安全だが、依存先が増えるほど監視対象も増える
- 緊急 pause を Strategy 単位で実装する: 1 Strategy で問題が起きても、他 Strategy と Vault 本体は動き続けられる構造
- 「即時引き出し可能な準備金」を Vault レイヤーで保持: 全資金を Strategy に流すと withdraw が外部プロトコルの状態に依存する
- 外部 Lending を使う Strategy では、対象プロトコルの監査履歴・bad debt 履歴を継続監視

この教訓は v3 の設計思想と地続きだ。v3 が Strategy を独立 Vault として切り出し、Strategy 単位の緊急停止やリスク隔離を重視するのは、まさにこうした外部依存の連鎖損失を局所化するためでもある。分離アーキテクチャは美学ではなく、過去の痛みから導かれた実務的な答えだ。

出典: Yearn 公式ドキュメント、Rekt News（Cream Finance / Iron Bank 関連事案） を参照。

8. まとめ

3つの要点:

1. Yearn v3 Strategy = 複数のファンドマネージャーを並列に雇う設計
2. Strategy ローテーションで市場環境に応じて配分動的調整
3. 機関向け Vault では Performance Fee が主要収益源

詳しくは ERC-4626 Vault標準 と DeFi完全マップ 2026 を参照。

関連記事

Strategy の運用先を理解し、Vault 設計の解像度を上げるための記事を選びました。

• ERC-4626 Vault 標準 — Yearn Strategy が依拠する規格本体。Vault と Strategy の関係を規格レベルで押さえる
• Aave v3 利率モデル — Strategy 運用先の代表「Aave 預入」の利率モデルと利用率
• Pendle PT/YT 分離 — Strategy 運用先のもう一つの代表「Pendle PT で固定利回り化」の数学的背景
• Morpho Blue — 本記事「Strategy がスタックする外部 Lending 連鎖損失」と関連する MetaMorpho 構成の代替設計
• Curve StableSwap 不変量 — Strategy B（Curve 流動性供給）の運用基盤。LP 収益の出所

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