Uniswap v3 集中流動性｜資本効率10倍とLPの運用負担

Uniswap v3 の最大の発明は「集中流動性」。流動性供給者（LP: Liquidity Provider＝プールに資産を預ける側）が「ここからここまでの価格帯にだけ流動性を出す」という指定ができる仕組みだ。v2 では LP の資金は0円〜無限大まで広く薄く分散されていたが、v3 では「現在価格付近に集中投下する」ことで、同じ資金量で10〜100倍の取引量を捌けるようになった。

ただし、うまい話には裏がある。v3 で資本効率を上げた分だけ、LP は「価格がレンジ外に出ると一切手数料が入らない」というリスクと運用負担を抱える。本記事は事業者目線で、v2 と v3 の使い分け、業界特化型 v3 のユースケース、自社採用の判断軸を整理する。

目次

1. なぜ事業者が v3 を理解する必要があるのか
2. 集中流動性とは — 「価格帯指定の流動性供給」
3. v2 vs v3 の使い分け — LP の意思決定コスト軸
4. ティックと手数料階層
5. 業界特化型 v3 のユースケース
6. 3つの戦略を選ぶ — 使う/組む/乗っかる
7. 開発期間とコスト、日本の規制論点
8. まとめ

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

「Uniswap v2 で十分」と考える事業者は多い。確かに自社トークン上場や fork DEX の最初の選択肢は v2 が現実的だ（実装が軽い、規格が枯れている、地雷が既知）。

だが2026年現在、機関流動性は v3 系（または同等の集中流動性設計）に乗っている。BlackRock BUIDL を含む RWA Vault が DeFi で流動性を持つときも、効率の良い v3 系プールが主流（Uniswap v3 の TVL・取引高は DefiLlama、公式 Docs を参照）。

事業者目線では:
- 自社トークンをマーケットメイクする際、v2 か v3 か の選択が必要
- 業界特化 AMM（ステーブル特化、LST 特化、RWA 特化）を組む場合、ほぼ v3 系設計が選ばれる
- 既存 v3 プールに流動性供給して収益を得る運用商品を組む場合、リスクとリターンの構造を理解する必要

2. 集中流動性とは — 「価格帯指定の流動性供給」

v2 の流動性は「無限分散」

v2 では、LP が ETH と USDC を預けると、その資金は「0円〜∞」の全価格帯に薄く広く配分される。実際には ETH 価格が $3,000 付近で取引されているとしても、$1 や $10,000 の取引にも備えて資金が「死蔵」されている。

v3 の流動性は「集中投下」

v3 では LP が「$2,800〜$3,200 の範囲にだけ流動性を出す」と指定できる。この範囲（レンジ）内では、同じ資金量で v2 の10倍以上の取引量を捌ける（極端な狭レンジなら100倍以上。設計詳細は Uniswap v3 ホワイトペーパー / 公式 Docs、ソースコード を参照）。

トレードオフ: レンジ外では何も入らない

v3 の弱点は「価格がレンジ外に出ると、その LP は何も手数料を稼げない」ことだ。

例: $2,800〜$3,200 にレンジを指定した LP が $3,200 突破時には、LP のポジションは100% USDC になる（ETH を売り尽くす）。ETH 価格が $3,500 に上がっても、もう何もできない。レンジを再設定（再 deposit）するまで休眠状態。

これは「v2 の何もしない LP」と比べて、v3 の LP はアクティブな運用が必要であることを意味する。

3. v2 vs v3 の使い分け — LP の意思決定コスト軸

事業者目線で v2 と v3 の使い分けを「LP の意思決定コスト」軸で整理する。

事業者の選択指針

• 自社トークンの初期上場: v2 が無難。素人 LP（一般保有者）が参加しやすい
• 業界特化型 AMM 構築: v3 設計が現実的。マーケットメイカー LP を集める前提
• 機関向けマーケットメイキング: v3 を選ぶ機関が圧倒的多数
• 長期保有資産の運用: v2 系の「ほっといても回る」LP が向く

4. ティックと手数料階層

ティック（Tick）= 価格の刻み

v3 の「レンジ指定」は連続的ではなく、離散的な「ティック」単位で行う。ティックは価格を細かく刻んだ目盛りで、隣接するティック間の価格差は約 0.01%。LP は「ティック A からティック B まで」と指定する。

事業者目線では、ティックは「LP のポジションを管理する最小単位」と理解しておけば良い。ティック数学そのものを覚える必要はないが、自社で v3 fork を組む場合は、ティック幅（tickSpacing）の設計が大きな影響を持つ。

手数料階層

v3 にはプール作成時に「手数料階層」を選ぶ仕組みがある:

自社トークンの上場では、0.30% が標準。ステーブル特化なら 0.01% を選ぶ。

5. 業界特化型 v3 のユースケース

v3 の集中流動性は「特定の価格帯に集中させる」発想から、業界特化 AMM の基盤として広く採用されている。

ステーブル特化（Curve 系含む）

ステーブルコイン間（USDC/USDT、DAI/USDS 等）は価格が常に $1 付近で動く。狭レンジ（$0.99〜$1.01 等）に集中投下すれば、超効率的なスワップが実現できる。実際 Curve は v3 とは独立した StableSwap 設計だが、思想は近い。

LST 特化（ETH ↔ stETH 等）

stETH はリベース型でステーキング報酬がトークン残高の増加として反映され、対ETHの交換レートは1:1ペッグ付近で安定する（二次市場では僅かなディスカウント/プレミアムが生じる）。価格変動幅が小さいため集中流動性で効率化しやすい。

RWA 特化

トークン化米国債（BUIDL、OUSG 等）は価格安定性が高い。集中流動性で機関取引のスプレッドを最小化できる。

6. 3つの戦略を選ぶ — 使う / 組む / 乗っかる

A: 使う（v3 プールに LP として参加）

自社の暗号資産を v3 プールに LP 投下して手数料収益を得る。

• 採用条件: マーケットメイキングの知見・分析体制
• メリット: v2 比10倍以上の資本効率
• デメリット: アクティブ運用負担、IL リスクの増幅

B: 組む（v3 fork で業界特化 AMM 構築）

ステーブル特化、LST 特化、RWA 特化など、業界特化型の AMM を v3 設計で組む。

• 採用条件: 自社の差別化軸が「特定資産間の効率的スワップ」
• 開発期間: 2-4人月 + 監査 $40K-150K（規模・新規性で変動）
• 想定例: 業界横断ステーブルスワップ、LST 集約 DEX

C: 乗っかる（既存 v3 を使ったプロダクト）

LP 自動運用 bot、レンジ管理ツール、機関向けマーケットメイキングサービス等。

• 採用条件: アクティブ運用の自動化技術
• メリット: 既存流動性に乗れる、開発工数小

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

v3 fork のコスト目安

開発合計: 4-7人月（約 $40K-105K）

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

• 注（監査）: $40K-150K。規模・コード新規性・監査ファーム（簡易な個別契約か、複数社/トップティアか）で大きく変動。簡易な fork は下限、新規性が高い・複数社起用は上限。

日本の規制論点

v3 特有の集中流動性であっても、日本の規制上の論点の枠組みは AMM 全般と共通する。立場ごとに整理する。

LP として v3 プールに参加する場合: 受け取った手数料収益や IL を含む損益の扱いが問題になる。個人が暗号資産で得た利益は原則として雑所得（総合課税）として扱われ、法人の場合は期末時点の時価評価（活発な市場が存在する暗号資産の評価益・評価損の計上）が論点になり得る。v3 ではレンジ外でポジションが片側資産に寄る（ETH を売り尽くして USDC 100% になる等）ため、レンジ再設定のたびに実質的な資産の入れ替えが発生し、損益認識のタイミングが v2 の「預けて放置」より複雑になりやすい点に注意が必要だ。

v3 fork DEX を業として運営する場合: 自社で AMM を立ち上げ、不特定多数のユーザーに暗号資産の交換機会を提供する形態では、資金決済法上の暗号資産交換業に該当しないか、また取り扱う資産（特にステーブルコインや RWA トークン）次第では資金移動業・電子決済手段等取引業・金融商品取引法の論点が重なり得る。RWA 特化型でトークン化証券を扱う場合は金商法（有価証券の募集・取扱い）の検討が不可欠だ。

いずれの論点も個別具体的な事業設計・取扱資産によって結論が変わるため、自社のコンプライアンス部門および暗号資産・金融規制に明るい弁護士への確認を前提とすべきだ。なお、v2 の定数積モデルにおける同種の論点については Uniswap v2 定数積モデル も参照されたい。

過去のインシデントから学ぶ設計教訓 — precision と TWAP 操作リスク

v3 系の集中流動性で自社プールを組む際、必ず想定すべきリスクが precision（量子化誤差）と TWAP（時間加重平均価格）操作攻撃 の2つだ。

precision リスク: v3 では価格を tick = log(price) / log(1.0001) で離散化（量子化）して扱う。tickSpacing が広い手数料階層（例: 1.00% / tickSpacing=200）では「1 tick あたり 2% 程度の価格段差」になる。低流動性プールで、攻撃者が大きな取引で price tick を一気にジャンプさせる、あるいは特定の tick に薄く流動性を出してフェイク価格を作る、といった操作が成立しやすい。

TWAP 操作攻撃: v3 プールは Oracle（外部プロトコルが価格を引く参照源）として TWAP を露出する。これは「ブロックごとのスポット価格を直接読むと単一ブロック内の瞬間的な価格操作に弱いため、一定時間の加重平均を取ることで操作耐性を高める」という設計思想に基づくものだ。ところがこの前提は「プールに十分な流動性があり、価格を一定時間動かし続けるコストが極めて高い」場合にしか成り立たない。低流動性プールの TWAP を Lending プロトコル等が担保評価に使っていた場合、攻撃者は薄い板を安価に押し上げ、TWAP を歪めて担保価値を不当に膨らませ、その水増しされた担保で過大な借入を行って持ち逃げする という攻撃が成立する。なぜ起きるかを一言で言えば、「価格の参照源として使ったプールの流動性が、その価格に依存して動く資金（担保・借入枠）の規模に見合っていなかった」からだ。

歴史的にこのパターンは繰り返されてきた。Solana 上の Mango Markets 事件（2022年10月、約 1.1 億 USD の被害） は厳密には Uniswap v3 ではなく Mango Markets 独自の Oracle 設計の問題だが、攻撃者は自プラットフォーム上で薄い MNGO トークンの価格を吊り上げ、膨らんだ担保評価を背景に巨額を借り出してプロトコルを実質的に空にした。「低流動性 Oracle の価格操作 → 過大担保評価 → 借入横領」という構図は、EVM 系の Inverse Finance 事件（2022年4月） でも見られ、ここでは低流動性プールから引いた価格を担保評価に使っていたことが直接の引き金になった。チェーンも実装も違うが、根っこの設計上の弱点は同一である。

では事業者はどう防ぐか。第一に、Oracle として v3 TWAP を採用するなら、対象プールの流動性と「価格を動かし続けるのに必要なコスト（操作コスト）」を必ず見積もる。操作コストが、その価格に依存して動く資金規模を十分上回る——目安として TVL の数倍の操作コストを要求できる——プールでなければ Oracle に使うべきではない。第二に、流動性が薄いうちの新興トークン v3 プールを Lending の担保価格源にしない。立ち上げ初期は TWAP が安価に操作可能であり、Mango・Inverse 両事件が示したのはまさにこの「薄い板を担保評価に直結させた」設計の危うさだ。第三に、単一 Oracle に依存せず、Chainlink 等の独立した外部 Oracle と v3 TWAP の差分を常時監視し、乖離が閾値を超えたら担保評価・清算を一時停止するサーキットブレーカーを組み込む。これらは後付けが難しく、設計段階で織り込んでおくべき防御策だ。

出典: Rekt News - Mango Markets、Rekt News - Inverse Finance を参照。

8. まとめ

事業者目線で Uniswap v3 を理解する要点は4つ。

1. 集中流動性 = 「価格帯指定の流動性供給」で資本効率10-100倍
2. 代償は LP のアクティブ運用負担。素人 LP には v2、プロ LP には v3
3. 業界特化型 AMM（ステーブル/LST/RWA 特化）は v3 設計が主流
4. 3戦略「使う/組む/乗っかる」で開発工数と差別化のトレードオフを判断

詳しくは DeFi完全マップ 2026 と Uniswap v2 定数積モデル を参照。

関連記事

集中流動性の文脈を理解した上で、設計判断を進めるのに有用な記事を選びました。

• Uniswap v2 定数積モデル — 本記事 3章「v2 vs v3 の使い分け」の比較対象。素人 LP 向け・fork 容易な v2 の設計思想を押さえる
• Uniswap v4 Hooks アーキテクチャ — v3 の集中流動性 + Hooks のカスタム機能で「業界特化 v3」を超える設計を組む次の選択肢
• Curve StableSwap 不変量 — 本記事 5章「ステーブル特化」と同じ問題を、A パラメータで解く別アプローチ
• MEV と AMM — 本記事 7章で言及した TWAP 操作攻撃と JIT 流動性の防御策を、運営側目線で深掘り
• 価格インパクトとスリッページ — v3 LP として収益を取る側ではなく、機関・大口として取引する側のコスト計算

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