DeFiを半年触ってわかったこと｜エンジニア視点で読み解く分散金融の現実2026

去年の秋ごろから、半ば仕事の調査も兼ねてDeFiを本格的に触り始めた。最初は「なんか怪しいやつでしょ」くらいの温度感だったんだけど、6ヶ月ほど試行錯誤してみると「これ、アーキテクチャとして普通に面白い」という感想に変わってきた。

正直、最初の1ヶ月でガス代の計算を間違えて3万円くらい溶かしたし、イールドファーミングの複利計算を勘違いしてリスクを盛大に取りすぎたこともある。でも、その失敗があったからこそ「なぜそうなるのか」をコードレベルで追いかけるようになって、結果的に理解が深まった気がする。

この記事は投資リターンの話じゃなく、エンジニアとして「DeFiの仕組みをどう読み解くか」に絞って書いた。数字や運用の話はNISA・iDeCoをPythonで理解する記事や日本株vs米国株のデータ分析記事に任せて、ここではプロトコルの内側を一緒に覗いてみたい。

---

DeFiって結局なにが「分散」してるのか

DeFi（Decentralized Finance）という言葉、2021年頃から流行り始めてもう5年以上経つのに、未だに「なんとなくわかってる」止まりの人が多い印象がある。エンジニア同士で話していても、「スマートコントラクトで動いてるやつでしょ」くらいの認識で止まってることが多い。

実際のところ、DeFiの「分散」が意味するのは主に3つの軸だ。これは頭に入れておくと後の話が追いやすい。

軸	意味
管理者がいない	銀行や取引所のような中央管理者が存在せず、コードがルールを執行する
カストディが不要	資産を誰か（取引所など）に預けずに直接ウォレットから操作できる
パーミッションレス	KYCなしで誰でも参加できる（これは規制と衝突しがちだが）

ただし「完全に分散している」DeFiプロトコルは2026年現在でもほぼ存在しない。管理者キーを持つマルチシグが残っていたり、オフチェーンのオラクルに依存していたり、ガバナンストークンが一部のクジラに集中していたりする。

「分散している」は程度の問題であって、バイナリではない——これが6ヶ月触って得た最も大きな学びだったかもしれない。「分散してるから安全」という言説を見るたびに、個人的にはちょっと眉をひそめてしまう。

DeFiの主要コンポーネントを整理する

各プロトコルがどう連携しているかを図にしてみた。

flowchart TB
    User([👛 ユーザーウォレット]) --> DEX[DEX\nUniswap v4 / Curve]
    User --> Lending[貸付プロトコル\nAave v4 / Compound v3]
    User --> Yield[イールドアグリゲーター\nYearn v3 / Beefy]
    User --> Bridge[クロスチェーンブリッジ\nStargate v3 / Across]

    DEX --> AMM{AMM\nAutomated Market Maker}
    AMM --> LP[(流動性プール)]
    LP --> FeeReward[手数料報酬]

    Lending --> Collateral{担保管理}
    Collateral --> Borrow[借入]
    Collateral --> Supply[供給/利息]

    Oracle[価格オラクル\nChainlink / Pyth] --> AMM
    Oracle --> Collateral

    Yield --> DEX
    Yield --> Lending

    Bridge --> Ethereum[Ethereum L1]
    Bridge --> L2[Arbitrum / Base / Optimism]
    Bridge --> Alt[Solana / Sui]

こうして図にすると、DeFiってマイクロサービスアーキテクチャに似てるんですよね。各プロトコルがAPIとして機能して、コンポーザビリティ（組み合わせ可能性）がシステム全体の価値を作っている。イベント駆動アーキテクチャが好きな人は、Kafkaとマイクロサービスの記事と一緒に読むと感覚が掴みやすいかもしれない。

---

スマートコントラクトをエンジニアとして読む

DeFiを理解する上で避けて通れないのがSolidityだ。2026年現在、Vyperの利用も増えているけど、主要プロトコルのほとんどはSolidityで書かれている。

エンジニアなら、まずコードを読んだほうが早い。Uniswap v4の中核となるPoolManagerを例にとってみる。

// Uniswap v4 PoolManager（簡略化）
// https://github.com/Uniswap/v4-core

pragma solidity ^0.8.24;

interface IPoolManager {
    struct PoolKey {
        Currency currency0;
        Currency currency1;
        uint24 fee;
        int24 tickSpacing;
        IHooks hooks;  // v4の新機能: フックコントラクト
    }

    // スワップ実行
    function swap(
        PoolKey memory key,
        SwapParams memory params,
        bytes calldata hookData
    ) external returns (BalanceDelta);

    // 流動性の追加・削除
    function modifyLiquidity(
        PoolKey memory key,
        ModifyLiquidityParams memory params,
        bytes calldata hookData
    ) external returns (BalanceDelta, BalanceDelta);
}

// フックコントラクトの例: スワップ前後に独自ロジックを挟める
contract CustomHook is BaseHook {
    function beforeSwap(
        address sender,
        PoolKey calldata key,
        IPoolManager.SwapParams calldata params,
        bytes calldata hookData
    ) external override returns (bytes4, BeforeSwapDelta, uint24) {
        // ここに任意のロジックを追加できる
        // 例: MEV対策、動的手数料調整、TWAP保護など
        emit SwapDetected(sender, params.amountSpecified);
        return (BaseHook.beforeSwap.selector, BeforeSwapDeltaLibrary.ZERO_DELTA, 0);
    }
}

Uniswap v4で大きく変わったのがこの「Hooks」の仕組みだ。v3までは固定のAMMロジックしか入れられなかったけど、v4ではスワップの前後・流動性追加の前後など8つのフックポイントで任意のロジックを挟める。これ、ミドルウェアやインターセプターパターンそのものなんですよね。「DeFiのミドルウェア化」が進んでいる感じがして、個人的にはこの方向性がかなり好きだ。

AMMの価格計算をPythonで検証する

僕が最初に「なるほど」と感じたのはAMMの価格計算だった。Uniswap v2系の定数積式（x * y = k）を自分でPythonで実装して動かしてみた。数式だけ読んでいたときは「ふーん」で終わっていたのが、動かしてみた瞬間に理解のレベルが変わった。

from decimal import Decimal
import math

class ConstantProductAMM:
    """x * y = k のAMM実装"""
    
    def __init__(self, reserve_x: Decimal, reserve_y: Decimal, fee_bps: int = 30):
        self.reserve_x = reserve_x  # token0の残高
        self.reserve_y = reserve_y  # token1の残高
        self.fee_bps = fee_bps      # 手数料 (30 = 0.3%)
        self.k = reserve_x * reserve_y
    
    def get_spot_price(self) -> Decimal:
        """現在のスポット価格（token0 per token1）"""
        return self.reserve_y / self.reserve_x
    
    def get_amount_out(self, amount_in: Decimal, token_in: str) -> Decimal:
        """スワップ後の受取額を計算"""
        fee_multiplier = Decimal(10000 - self.fee_bps) / Decimal(10000)
        amount_in_with_fee = amount_in * fee_multiplier
        
        if token_in == 'x':
            # x を入れて y を受け取る
            new_reserve_x = self.reserve_x + amount_in_with_fee
            new_reserve_y = self.k / new_reserve_x
            return self.reserve_y - new_reserve_y
        else:
            new_reserve_y = self.reserve_y + amount_in_with_fee
            new_reserve_x = self.k / new_reserve_y
            return self.reserve_x - new_reserve_x
    
    def calculate_price_impact(self, amount_in: Decimal, token_in: str) -> Decimal:
        """スワップによる価格影響（スリッページ）"""
        spot_price = self.get_spot_price()
        amount_out = self.get_amount_out(amount_in, token_in)
        
        if token_in == 'x':
            execution_price = amount_in / amount_out
            return (execution_price - spot_price) / spot_price * 100
        else:
            execution_price = amount_out / amount_in
            return (spot_price - execution_price) / spot_price * 100

# 実際に動かしてみる
# ETH/USDC プール: 1000 ETH / 3,500,000 USDC
pool = ConstantProductAMM(
    reserve_x=Decimal('1000'),    # ETH
    reserve_y=Decimal('3500000'), # USDC
    fee_bps=30                    # 0.3%
)

print(f"スポット価格: {pool.get_spot_price():.2f} USDC/ETH")
# スポット価格: 3500.00 USDC/ETH

# 1 ETH スワップした場合
amount_out = pool.get_amount_out(Decimal('1'), 'x')
impact = pool.calculate_price_impact(Decimal('1'), 'x')
print(f"1 ETH → {amount_out:.2f} USDC")
print(f"価格影響: {impact:.4f}%")
# 1 ETH → 3496.50 USDC
# 価格影響: 0.0999%

# 100 ETH スワップした場合（大口取引のスリッページ）
amount_out_large = pool.get_amount_out(Decimal('100'), 'x')
impact_large = pool.calculate_price_impact(Decimal('100'), 'x')
print(f"100 ETH → {amount_out_large:.2f} USDC")
print(f"価格影響: {impact_large:.4f}%")
# 100 ETH → 318181.82 USDC
# 価格影響: 9.0909%

実行してみると、100 ETHのスワップで約9%のスリッページが発生することがわかる。「流動性が深い」とはこのkの値が大きいことを意味していて、大口取引でも価格影響が小さくなる。これを自分でコードを書いて確認したとき、「あ、ガスよりも流動性の問題のほうが実取引コストに効いてくるのか」とようやく実感できた。ドキュメントを読んでいるだけでは気づきにくいところだと思う。

---

2026年時点でのDeFiエコシステム現状

ここ1〜2年でDeFiの地形が大きく変わってきている。2024年のEthereum Pectraアップグレード以降、L2が本格的に普及して、もうほとんどの取引がL1じゃなくてArbitrumやBase、Optimismで行われている。

TVLの推移を見ると、回復基調がかなりはっきりしてきた。

xychart-beta
    title "DeFi TVL(Total Value Locked)の推移 2024-2026（単位:十億ドル）"
    x-axis ["2024Q1", "2024Q2", "2024Q3", "2024Q4", "2025Q1", "2025Q2", "2025Q3", "2025Q4", "2026Q1"]
    y-axis "TVL (十億ドル)" 0 --> 200
    bar [58, 72, 61, 89, 112, 134, 118, 156, 172]
    line [58, 72, 61, 89, 112, 134, 118, 156, 172]

2026年Q1時点でTVLが1720億ドル規模まで戻ってきた。2022年のクラッシュで大きく落ち込んでいたが、機関投資家の参入と規制整備が進んで回復基調にある。個人的には「機関投資家の参入」というよりも「L2が使い物になってきた」のほうが本質的な理由じゃないかと思っている。

主要プロトコルの比較

プロトコル	カテゴリ	チェーン	TVL概算	特徴	リスクレベル
Uniswap v4	DEX	ETH/L2	$8B+	Hooks機能、シングルトン設計	低〜中
Aave v4	貸付	マルチチェーン	$15B+	リスク分離モジュール導入	中
Curve Finance	DEX/Stablecoin	ETH/L2	$4B+	ステーブル特化、低スリッページ	低〜中
Hyperliquid	Perp DEX	独自L1	$3B+	完全オンチェーンオーダーブック	中〜高
Ethena	Synthetic USD	ETH	$5B+	デルタニュートラル戦略	高
Pendle	利回りトレード	ETH/Arbitrum	$2B+	将来利回りのトークン化	高

Hyperliquidは2025年に急成長したプロジェクトで、中央集権取引所並みの速度をオンチェーンで実現している。正直まだ検証中だけど、独自L1の設計はかなり面白い。完全なデセントラライズかという意味では懐疑的な部分もある。

L2別のガスコスト比較

数字で見てもピンとこないと思うので、チェーン別のコスト感を可視化してみた。

xychart-beta
    title "チェーン別スワップ平均ガス代（2026年4月時点, USD）"
    x-axis ["Ethereum L1", "Arbitrum One", "Base", "Optimism", "Polygon zkEVM", "Solana"]
    y-axis "平均ガス代 (USD)" 0 --> 15
    bar [12.5, 0.08, 0.04, 0.07, 0.05, 0.002]

このコスト差はもうゲームチェンジャーレベルだ。Ethereum L1で1回のスワップに12ドル払っていたのが、Baseだと4セントで済む。地味に便利すぎて、最初に確認したとき二度見した。DeFiが「普通の人が使うもの」に近づいてきているのは、ひとえにL2の普及によるところが大きいと思う。

---

セキュリティリスクをコードで理解する

DeFiでの資産喪失リスクは技術的な問題として捉えるのが重要だ。「怪しいプロジェクトに引っかかった」で終わらせるんじゃなく、どういう脆弱性のパターンがあるかを理解しておくと、プロジェクトの安全性を自分で評価できるようになる。

セキュリティの考え方についてはOWASP Top 10の記事でも触れているけど、DeFi固有のパターンは別途押さえる必要がある。よくある攻撃を3つ挙げておく。

1. Reentrancy（再入攻撃）

The DAOハック（2016年）で有名になったやつで、今でも出てくる。「古い手口なのになぜ今も？」と思うかもしれないが、コードが複雑になるほど見落としやすくなるんですよね。

// 脆弱なコード（やってはいけない例）
contract VulnerableVault {
    mapping(address => uint) public balances;
    
    function withdraw(uint amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        
        // 危険: 状態更新前に外部コール
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
        
        balances[msg.sender] -= amount;  // ← ここに到達する前に再入される
    }
}

// 安全なコード: Checks-Effects-Interactionsパターン
contract SafeVault {
    mapping(address => uint) public balances;
    bool private locked;
    
    modifier nonReentrant() {
        require(!locked, "Reentrant call");
        locked = true;
        _;
        locked = false;
    }
    
    function withdraw(uint amount) external nonReentrant {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        
        // 正しい順序: Check → Effect → Interaction
        balances[msg.sender] -= amount;  // 先に状態を更新
        
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Transfer failed");
    }
}

2. Price Oracle Manipulation（オラクル操作）

DeFiで一番多い攻撃パターンかもしれない。フラッシュローンを使って瞬間的に価格を操作し、価格オラクルが歪んだ値を返している間に利益を抜く手法だ。対策としてはChainlinkのような外部オラクルを使うか、TWAPベースの価格を参照することが一般的になっている。

3. Front-running / MEV

これはブロックチェーン特有の問題で、mempool（未確認トランザクションの待ち行列）を監視して、有利なトランザクションを先に実行する攻撃だ。2026年現在はMEV-Boostの普及で構造化されているが、ユーザーとしては依然として影響を受ける。Uniswap v4のHooksを使ったMEV対策フックの実装が盛んになっているが、正直まだ標準的な解決策は確立していない印象がある。

自分がDeFiプロトコルを評価するときのチェックリスト

実際に資産を入れる前に確認する項目はこんな感じだ。最初は面倒に思えるけど、慣れると15分くらいでひと通り確認できるようになる。

□ スマートコントラクトが検証済み（Etherscan等でコード公開）
□ 複数の独立した監査を受けている（Certik・Trail of Bits・OpenZeppelin等）
□ バグバウンティプログラムが存在する
□ 管理者キーがマルチシグまたはTimelockで保護されている
□ TVLと流動性が十分にある（薄い流動性は価格操作リスク）
□ コミュニティとガバナンスが活発
□ 保険プロトコル（Nexus Mutual等）でカバーが取れる

こういった確認作業を続けていると、コントラクト読解力が自然と上がっていく。最初は読めなかったSolidityが、3ヶ月くらい続けると「このパターンはReentrancy対策だな」とかが見えてくるようになった。副産物的な効果だけど、これが地味に一番の収穫だったかもしれない。

---

実際にやってみた：流動性提供の損益計算

6ヶ月の中で一番時間を使ったのが、流動性提供（LP）の損益計算だった。「手数料収入があるから得」という単純な話じゃなく、非永続的損失（Impermanent Loss）の問題がある。これを頭でわかっていたつもりが、実際に数字を出して初めて「あ、思ったよりキツいな」となった。

import math
from dataclasses import dataclass
from typing import Tuple

@dataclass
class LPPosition:
    """流動性提供ポジションの損益計算"""
    eth_amount: float    # 投入したETH量
    usdc_amount: float   # 投入したUSDC量
    entry_price: float   # 投入時のETH価格
    
    def calculate_impermanent_loss(self, current_price: float) -> Tuple[float, float]:
        """非永続的損失の計算"""
        price_ratio = current_price / self.entry_price
        
        # HODL時の価値
        hodl_value = self.eth_amount * current_price + self.usdc_amount
        
        # LP後の価値（AMM公式）
        lp_value = 2 * math.sqrt(price_ratio) / (1 + price_ratio) * hodl_value
        
        il_ratio = (lp_value / hodl_value - 1) * 100
        il_usd = lp_value - hodl_value
        
        return il_ratio, il_usd
    
    def net_pnl(self, current_price: float, fee_earned_usd: float) -> float:
        """手数料収入を加味した実質損益"""
        _, il_usd = self.calculate_impermanent_loss(current_price)
        return fee_earned_usd + il_usd  # il_usdは負の値

# ETH/USDC プールに 1 ETH + 3500 USDC 投入した場合（投入時価格: $3500）
position = LPPosition(
    eth_amount=1.0,
    usdc_amount=3500.0,
    entry_price=3500.0
)

print("価格変化別の非永続的損失:")
for price in [2800, 3000, 3500, 4000, 5000, 7000]:
    il_ratio, il_usd = position.calculate_impermanent_loss(price)
    print(f"  ETH ${price:,} → IL: {il_ratio:.2f}% (${il_usd:,.2f})")

# 出力:
# 価格変化別の非永続的損失:
#   ETH $2,800 → IL: -0.49% ($-34.3)
#   ETH $3,000 → IL: -0.14% ($-9.8)
#   ETH $3,500 → IL: 0.00% ($0.0)
#   ETH $4,000 → IL: -0.27% ($-18.9)
#   ETH $5,000 → IL: -1.23% ($-86.1)
#   ETH $7,000 → IL: -3.91% ($-273.7)

# 実際の損益: 手数料収入 $200 - IL $273.7 = -$73.7（負け）
price_now = 7000
fee_earned = 200  # 1ヶ月の手数料収入
net = position.net_pnl(price_now, fee_earned)
print(f"\n実質損益（ETH $7000時、手数料$200の場合）: ${net:,.2f}")
# 実質損益（ETH $7000時、手数料$200の場合）: $-73.70

ETHが2倍になった場合、HODLしていれば大きく含み益が出るけど、LP（流動性提供）していると手数料収入があっても差し引きでマイナスになることがある。これを体感した時は「なるほど、LP収益ってそんな単純じゃないんだ」と実感した。

HyperliquidやPendleのような、より複雑な収益戦略を提供するプロトコルが注目を集めているのも、こういう単純なLP戦略の限界を超えようとしているからだと思う。「なぜ新しいプロトコルが生まれ続けるのか」が、この計算を一度やると腑に落ちる。

---

まとめ

6ヶ月DeFiを触ってみて得た知見を整理するとこうなる。

#	学び	一言で言うと
1	DeFiはアーキテクチャとして理解できる	コンポーザビリティ・オラクル依存・管理者権限の問題は、エンジニアが日常的に考えていることと本質的に同じ
2	セキュリティリスクは技術的に評価できる	「なんか怪しい」ではなく、監査の有無・管理者キーの設計・TVL規模など、チェック可能な基準がある
3	L2への移行でUXは劇的に改善した	ガス代が1/100以下になり、2026年現在はBaseやArbitrumを起点にするのが現実的
4	非永続的損失は必ず計算する	「手数料が入るから得」は単純すぎる。集中流動性は高リターンを狙えるが、管理が複雑
5	まだ発展途上、怪我をしながら学ぶ覚悟が必要	規制対応が進んでいても、バグ・オラクル攻撃・ラグプルは2026年でも発生している

個人的には「DeFiを触る = 投機をする」ではなく、「分散システムの最前線を実動環境で学べる場所」として捉えると、エンジニアとしての費用対効果がかなり高いと感じている。授業料は払ったけど、それ以上の理解は得られた気がする。

次のアクションとして、まずはBase上でUniswap v4を触ってみることをおすすめしたい。ガス代が安いので失敗してもダメージが少ない。MetaMaskとBasebridge（公式ブリッジ）で数千円分のETHをL2に移して、実際にスワップしてみると「なるほどこれがAMMか」という感覚が掴める。コードが気になる人はEtherscanのコントラクトページで実際のSolidityを読んでみると、想像よりずっとコンパクトで読みやすいことに気づくはずだ。