Uniswap v4 Hooks とは｜カスタム AMM 設計の新規格

2025年1月にメインネット稼働した Uniswap v4 の核心は「Hooks」という拡張ポイントだ。「プールの動作をカスタムコードで上書きできる」設計で、業界特化型 AMM・ロイヤリティ AMM・ダイナミック手数料 AMM 等が組めるようになった（出典: Uniswap 公式 Docs、v4 ソースコード (v4-core)）。本記事は事業者目線で、Hooks が事業に何をもたらすかを整理する。

目次

1. なぜ事業者がこれを理解する必要があるのか
2. なぜ Uniswap は v4 で「Hooks 化」したのか — v2/v3 からの設計思想の変化
3. Hooks とは — 「プールのイベントに反応するカスタムコード」
4. Singleton と Flash Accounting — Hooks を成立させる土台のアーキテクチャ
5. Hooks で組める代表ユースケース — 各機能が事業にどう効くか
6. v2 fork / v3 fork との比較
7. Hooks のリスク — 「自社で書き換えられる」の裏側
8. 事業者の判断軸 — 既存 Hook を使う／自作する／カスタム AMM を建てる
9. 開発期間とコスト、日本の規制論点
10. BUSL ライセンスとエコシステムの現状
11. まとめ

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

「業界特化型 AMM」「自社トークン専用の経済設計」「ゲーム/エンタメ向けカスタム DEX」——こうしたニーズが2024年以降増えている。v4 Hooks はこれらを実装する標準ツールになりつつある。

事業者にとっての本質はシンプルだ。これまで「自社独自の取引ルールを持つ DEX」を作ろうとすると、Uniswap のコードをまるごとフォーク（コピーして改造）し、自前で流動性をゼロから集め、AMM の中核ロジックまで含めて全部監査する必要があった。v4 Hooks は、この「全部作り直す」を「動作の一部だけ差し替える」に変える。中核の取引エンジンと流動性インフラは Uniswap のものに乗ったまま、自社の差別化ロジックだけを「Hook」という小さな追加コードとして書く——という分業ができるようになった。

これは単なる機能追加ではなく、「DEX を作る」という事業の作り方そのものを変える話であり、だからこそ経営層・事業責任者が押さえておく意味がある。

ただし v4 は2025年1月メインネット稼働なので、まだ枯れた規格ではない。事業者は採用タイミングを判断する必要がある。

2. なぜ Uniswap は v4 で「Hooks 化」したのか — v2/v3 からの設計思想の変化

v4 Hooks を理解するには、Uniswap がどう進化してきたかを押さえると腑に落ちる。

v2 → v3 → v4 の流れ

• v2（2020年）: 「x × y = k」の定数積モデル。シンプルで誰が作っても同じ動作。流動性は0〜無限大の全価格帯に薄く広がる。
• v3（2021年）: 「集中流動性」を導入。LP が「この価格帯だけに流動性を置く」と指定できるようになり、資本効率が大きく向上した。ただしプールの動作ロジック自体は依然として Uniswap が決めたもので固定。事業者がカスタマイズしたければ、やはり全体をフォークするしかなかった。
• v4（2025年1月）: プールの動作に「差し込み口（Hooks）」を設けた。LP の流動性管理は v3 譲りの集中流動性のまま、その「前後」に自社ロジックを挿入できる。

Uniswap の戦略意図 — 「プラットフォーム化」

v2/v3 で起きていたのは、他社が Uniswap のコードをフォークして競合 DEX を乱立させる現象だった（SushiSwap や PancakeSwap が代表例）。Uniswap からすれば、自社の技術が外で使われても自社には流動性も手数料も入らない。

v4 の Hooks は、この構図を反転させる狙いがある。「フォークして出て行く」のではなく「Uniswap の上に乗って Hook を書く」方が、流動性も開発工数も得——という設計にすることで、カスタム AMM のエコシステムを Uniswap 本体の周りに引き寄せる。つまり Uniswap 自身が「単一の DEX」から「カスタム DEX を作るためのプラットフォーム」へと立ち位置を変えたのが v4 だ（出典: Uniswap 公式ブログ「Our Vision for Uniswap v4」）。

事業者目線で言えば、これは「Uniswap の流動性とブランドに相乗りしながら差別化できる」という選択肢が初めて整ったことを意味する。

3. Hooks とは — 「プールのイベントに反応するカスタムコード」

仕組み

Uniswap v4 のプールには「イベント発生時に呼び出される拡張点」（beforeSwap/afterSwap など、プール操作の前後にカスタムロジックを差し込むためのフック関数群）が複数組み込まれている:

• beforeInitialize / afterInitialize: プール初期化時
• beforeSwap / afterSwap: スワップ時
• beforeAddLiquidity / afterAddLiquidity: 流動性追加時
• beforeRemoveLiquidity / afterRemoveLiquidity: 流動性削除時
• beforeDonate / afterDonate: 寄付時

これらに対して、事業者が 「Hook」と呼ばれる自社コード を登録すると、対応するイベント発生時に Hook が呼ばれて、プールの動作をカスタマイズできる。

「before」と「after」の違いがなぜ重要か

差し込み口が「操作の前（before）」と「後（after）」に分かれているのには意味がある。

• before 系（例: beforeSwap）は、スワップが実行される前に割り込む。ここでは「このスワップを許可するか」「手数料をいくらにするか」「そもそも独自の計算式で約定させてしまうか」といった、取引の中身そのものを変えることができる。
• after 系（例: afterSwap）は、スワップが終わった後に割り込む。「取引結果を記録する」「ロイヤリティを徴収する」「LP の残高を自動でリバランスする」といった、事後処理に向く。

事業者にとっての勘所は、「取引の挙動を変えたいなら before、取引に付随する処理を足したいなら after」というざっくりした切り分けだ。

Hook の権限は「アドレスに刻まれる」— 平易な補足

v4 では、ある Hook がどのイベントに反応するか（=どんな権限を持つか）を、Hook コントラクトのアドレス（住所）そのものに埋め込むという独特の設計を採る。これにより、プールは余計な確認をせずに「この Hook は beforeSwap だけ動く」と即座に判断でき、ガス（手数料）を節約できる。

実務上の含意は、Hook を作るときは「狙ったアドレスが出るまでアドレス生成を回す」工程が要るという点だ。事業者が「自作 Hook」を検討する際、この一手間が地味に開発コストへ効いてくる。

直感的説明

事業オーナー向けに:

Uniswap v3 までは「プールの動作は決まっていて、誰でも同じ」。v4 Hooks は「プールの動作の一部を、自社で書き換えられる」

これにより「Uniswap の流動性インフラに乗りつつ、自社独自の経済設計を組み込む」事業が可能になった。

4. Singleton と Flash Accounting — Hooks を成立させる土台のアーキテクチャ

Hooks ばかりが注目されるが、v4 にはそれを支える2つの土台技術がある。両者を理解すると「なぜ v4 が成立するのか」が見えてくる。

Singleton — 全プールを1つのコントラクトに集約

v3 までは「1プール＝1コントラクト」だった。USDC/ETH プールも、自社トークン/USDC プールも、それぞれ別々のスマートコントラクトとしてデプロイされる。新しいプールを作るたびに、新しいコントラクトを丸ごとブロックチェーン上に設置するコストがかかっていた。

v4 では、すべてのプールを「PoolManager」という1つのコントラクトの中で管理する（これを Singleton＝単一インスタンス設計と呼ぶ）。プールは「コントラクト」ではなく、PoolManager 内部の「データ」として表現される。

これが効くポイント:

• プール作成コストの激減: Uniswap は v4 でプール作成のガスコストが約99%削減されると説明している（出典: Uniswap 公式ブログ）。多数のプール（=多数の通貨ペアや、Hook 違いの派生プール）を建てるビジネスほど効果が大きい。
• マルチホップが速い: A→B→C と複数プールを経由する取引で、従来は「コントラクトをまたぐたびにトークンを送る」必要があった。Singleton では全プールが同じコントラクト内にあるため、途中の送金を省ける。

Flash Accounting — 「最後に差額だけ精算する」会計方式

Singleton と対になるのが Flash Accounting だ。

従来は、スワップや流動性操作の1ステップごとに実際のトークン送金（transfer）が発生していた。送金はブロックチェーン上で高コストな操作なので、複数ステップの取引はそのぶんガスがかさむ。

Flash Accounting では、取引の途中は「誰が誰にいくら貸し借りしているか（delta＝差分）」を帳簿上で記録するだけにしておき、一連の操作がすべて終わった最後に、ネット（差し引き）の残高変化だけを1回で精算する。1回の取引で「スワップして、流動性を足して、また別のスワップ」を連続しても、実際のトークン移動は最終差額の1回で済む。

これを技術的に可能にしているのが、Ethereum の トランジェント・ストレージ（EIP-1153、取引が終わると自動で消える一時的な記憶領域） で、永続的な保存より大幅に安いコストで「途中の貸し借り」を保持できる（出典: Uniswap 公式 Docs「Flash Accounting」）。

なぜこの2つが Hooks に効くのか

Hooks は「操作の前後に処理を差し込む」仕組みだ。素朴に作れば、Hook が動くたびにトークン送金が発生し、ガスが膨らんで実用に耐えない。Singleton と Flash Accounting があるからこそ、「Hook で複雑なロジックを挟んでも、最後にまとめて精算するからガスが現実的に収まる」。

事業者目線の含意: v4 上のカスタム AMM は、ガス効率を理由に諦めていた凝った経済設計（毎スワップでのリバランス、複数プール連動など）が、コスト的に成立しやすくなったということだ。

5. Hooks で組める代表ユースケース — 各機能が事業にどう効くか

以下はいずれも、Uniswap 公式の周辺リポジトリ（v4-periphery）にサンプル実装が置かれているか、コミュニティで広く議論されている代表例だ。ただし公式サンプルは「参考実装」であり、そのまま本番投入できる完成品ではない点に注意（出典: Uniswap GitHub (v4-periphery)）。

ユースケース1: ダイナミック手数料（動的手数料）

通常 AMM の手数料は固定（0.30% 等）。Hooks を使えば「ボラティリティが高い時は手数料を上げ、低い時は下げる」動的調整ができる。beforeSwap でスワップ直前に手数料率を書き換えるイメージだ。

事業効果:
- LP の収益最適化: 価格が荒れて損失リスクが高い局面では手数料を厚く取り、LP の取り分を守る。
- MEV の抑制・内部化: 後述する MEV（取引順序操作で抜かれる利益）を、手数料設計で取り返す／LP に還元する設計が組める。
- 競争力ある通常時手数料: 平常時は手数料を下げてトレーダーを呼び込み、ボラ時だけ上げる、という出し分けで取引量と LP 保護を両立できる。

ユースケース2: TWAMM（時間分散約定）

TWAMM（Time-Weighted Average Market Maker） は、大口注文を「一度に全部約定せず、時間をかけて少しずつ自動で約定していく」仕組み。大口を一気に出すと価格を大きく動かして自分が損をする（プライスインパクト）が、小分けにすれば平均的に良い価格で執行できる（出典: Uniswap 公式ブログ「Uniswap v4 TWAMM Hook」）。

事業効果:
- トレジャリー運用・大口の自社トークン売買: DAO やプロジェクトが自社トークンを市場で少しずつ売る／買い戻す際に、価格を崩さず執行できる。
- 機関投資家向けの執行品質: 「大口でも価格を壊さず約定できる場」を売りにできる。

ユースケース3: オンチェーン指値注文（Limit Order）

通常 AMM は成行注文のみ。Hooks で「指定価格に到達したら自動的に約定」する指値注文機能を組み込める（v4-periphery に LimitOrder のサンプル実装あり）。

事業効果:
- CEX 並みの UX を v4 上で実現: 「この価格で売りたい」という、これまで中央集権取引所でしか出せなかった注文を、自社 DEX 上で提供できる。
- 板取引に近い体験: トレーダーの定着率・取引頻度を上げる差別化要素になる。

ユースケース4: カスタム Oracle（独自の価格参照）

Hooks を使って、プールの取引データを元に「操作されにくい価格情報（Oracle）」をオンチェーンで提供できる。v4-periphery には幾何平均オラクル（GeomeanOracle）やボラティリティ・オラクル（VolatilityOracle）のサンプルがある。

事業効果:
- 自社プロダクトへの価格供給: レンディング（貸付）やデリバティブなど、正確な価格が要る自社サービスに、操作耐性の高い価格を供給できる。
- 外部依存の削減: 外部 Oracle サービスへの依存・コストを減らせる場合がある。

ユースケース5: LP の自動リバランス

afterSwap などをトリガに、「LP が置いた流動性の価格帯を、相場に合わせて自動で寄せ直す」設計が組める。v3 の集中流動性は資本効率が高い反面、価格が動くと流動性が「効かない帯」に取り残されるため、本来は LP が手動で置き直す必要があった。これを Hook で自動化する。

事業効果:
- LP 体験の改善: 「置きっぱなしでも効率が落ちにくい」プールは、LP を集めやすい。
- ただし最重要の注意点: 後述する Bunni の事案は、まさにこの「自動リバランスのロジック」を突かれて約840万ドルが流出したケースだ。自動リバランスは最も事故が起きやすい領域であり、設計・監査の難度が高いことを強く意識すべき。

ユースケース6: MEV の内部化

MEV（Maximal Extractable Value） とは、取引の並べ替えや割り込みによって第三者（多くはボット）が抜き取る利益のこと。通常の AMM では、この利益はトレーダーや LP から外部のボットへ漏れていく。

Hooks では、ダイナミック手数料や独自の約定ロジックを組み合わせて、「本来外部に抜かれていた MEV を、プール側（＝LP やプロトコル）に取り込む」設計を狙える。

事業効果:
- LP への還元原資: 抜かれていた価値を LP に戻せれば、流動性を集めるインセンティブになる。
- 健全な取引環境の訴求: 「サンドイッチ攻撃に強い DEX」として差別化できる。
- 注意: MEV 内部化は研究・実装ともに発展途上の難しい領域で、誰でも簡単に組めるものではない。

ユースケース7: 業界特化型制限（permissioned AMM）

例えば「KYC 通過者のみスワップ可能」「特定時間帯は取引停止」「取引額の上限制限」など、業界特化型の制限を beforeSwap 等で組み込む。

事業効果: 機関向け permissioned AMM、特定要件を満たす DEX 等。なお「規制対応」を機能として保証するものではなく、要件適合は必ず法務確認が前提（後述）。

6. v2 fork / v3 fork との比較

注: 監査コストは規模・コード新規性・監査ファーム（簡易な個別契約か、複数社/トップティアか）で大きく変動する。簡易な fork は下限、新規性が高い・複数社起用は上限。v4 Hooks は新規格ぶん難度が高く、同規模の v2/v3 fork より上振れしやすい。

事業者の選び方

• 「Uniswap の流動性を活用しつつ、自社の差別化を加えたい」 → v4 Hooks
• 「完全に独立した自社 DEX」 → v2/v3 fork
• 「最短ローンチ・最小工数」 → v2 fork

7. Hooks のリスク — 「自社で書き換えられる」の裏側

「動作を自社で書き換えられる」という v4 最大の利点は、そのまま最大のリスクでもある。プールの中身を差し替えられるということは、差し替えたコードにバグがあればプールの資産が危険にさらされるということだ。

リスク1: Hook 自体のバグ

Hook は事業者が書く追加コードだ。Uniswap のコア（PoolManager）が監査済みでも、その上に乗せる Hook が監査されているわけではない。beforeSwap で価格計算を書き換えるような Hook は、計算式のわずかなズレ（丸め方向の誤り、桁あふれ等）がそのまま資産流出につながる。

リスク2: 悪意ある Hook

Hook はプール作成者が自由に指定できる。つまり「一見ふつうのプールに見えて、実は出金を妨害する／手数料を不当に抜く Hook が仕込まれている」プールが存在し得る。ユーザー・LP 側は「このプールにどんな Hook が付いているか」を確認せずに資金を入れると、想定外の挙動に巻き込まれる。事業者が他社の Hook 付きプールに自社資金や顧客資金を置く場合は、その Hook の素性確認が必須だ。

リスク3: 監査範囲の拡大

v4 のカスタム AMM は、監査対象が「AMM ロジック」だけでなく「Hook と、Hook がコアとやり取りする境界（コールバックの信頼性、Hook 権限フラグの整合、複数プールをまたぐ再入可能性 reentrancy）」にまで広がる。既存の AMM 監査ノウハウはそのままでは効かず、監査の難度・費用・期間がいずれも増す。監査ファーム側の v4 経験もまだ蓄積途上だ。

実例: Bunni の約840万ドル流出（2025年9月）

Hook のリスクが「理屈」ではないことを示す代表的な事案が、Uniswap v4 上に構築された DEX「Bunni」だ。

• 2025年9月、Bunni は約 840万ドル相当（Unichain 上で約600万ドル、Ethereum 上で約240万ドル）を失う攻撃を受けた。
• 原因は、Bunni 独自の「流動性分布関数（LDF, Liquidity Distribution Function）＝自動リバランスのロジック」にあった丸め方向のバグ。攻撃者は特定サイズのスワップを繰り返してリバランス計算を狂わせ、本来取り出せる以上のトークンを引き出した（フラッシュローン＋微小出金＋サンドイッチを組み合わせた手口）。
• 重要なのは、これが Uniswap v4 のコア（PoolManager）の問題ではなく、その上に乗せた Bunni 側のカスタムロジック（＝Hook 的な独自実装）に起因した点だ。
• Bunni は全チェーンで出金を停止し、最終的に2025年10月、復旧に必要な監査費用（6〜7桁ドル規模）を賄えないとして恒久的なサービス停止を発表した。

（出典: Rekt News 、各報道。事案の技術詳細は監査各社の分析記事を参照）

事業者にとっての含意:
- Hook のコードは「Uniswap が監査している」訳ではない: コアと Hook は別物。Hook を自社実装するなら自社の責任で監査が必要。
- 自動リバランス等の「凝った経済設計」ほど事故率が高い: 利点が大きい機能ほど、攻撃面も広い。Bunni はまさに自動リバランスを突かれた。
- 採用先 Hook の運用実績・監査履歴を必ず確認: 「Uniswap v4 上で動く」だけでは安全性の根拠にならない。
- 新規格特有の地雷を事前に潰す: コールバックの信頼性、Hook 権限フラグの整合、複数プールをまたぐ再入可能性など、v4 固有の論点を監査スコープに必ず含める。

仕様の成熟度

v4 は2025年1月メインネット稼働（出典: Uniswap 公式 Docs）。2026年6月時点で約1年半の運用実績で、v3（5年）、v2（10年）と比べると新しい。考慮すべき点:
- 監査ファームの v4 監査経験がまだ少ない
- ライブラリ・ツールチェーンが成熟途上
- Hook を含む設計パターンのベストプラクティスが確立途上

採用タイミングの目安:
- 本番ローンチを急ぐ場合: v2/v3 fork が無難
- 2026-2027年に向けて新規プロダクトを設計: v4 Hooks を視野に入れる
- 業界特化型・差別化重視: v4 Hooks が有力（v2/v3 では実現困難な設計が多い）

8. 事業者の判断軸 — 既存 Hook を使う／自作する／カスタム AMM を建てる

「v4 Hooks を使う」と一口に言っても、関わり方の深さで3段階ある。コスト・リスク・差別化のバランスがそれぞれ大きく違うので、ここを取り違えると見積りが狂う。

選択肢A: 既存の Hook を「使う」

ダイナミック手数料や TWAMM など、すでに公開・実績のある Hook をそのまま採用する。

• コスト感: 最小。自作コードがないぶん、監査も「組み合わせ部分」に限定できる。
• 差別化: 限定的（他社も同じ Hook を使える）。
• 向く事業者: 「枯れた機能を早く・安全に載せたい」ケース。
• 必須の確認: その Hook の監査履歴・運用実績・メンテナンス主体。Bunni の教訓どおり、「v4 上で動く」だけでは安全の根拠にならない。

選択肢B: 自社で Hook を「書く」

自社独自のロジック（業界特化の取引制限、独自の手数料設計など）を Hook として実装する。

• コスト感: 中〜大。Hook 設計・実装に概ね数人月、加えてHook を含むスコープの監査が新規格ぶん割高（後述のコスト表参照）。アドレスに権限を刻む v4 特有の作法など、独自のハマりどころもある。
• 差別化: 高い。自社だけの動作を作り込める。
• 向く事業者: 「他社にない取引体験・経済設計で勝負したい」ケース。
• 最大の注意: ここが最も事故が起きやすい層。書いたコードがそのまま資産リスクになる。価格計算や自動リバランスに踏み込むなら、設計段階からのレビューと厚めの監査を前提に。

選択肢C: v4 上に「カスタム AMM を建てる」

Hook を中核に据え、独自の AMM 商品（独自不変量・独自の流動性管理など）を v4 の土台の上に構築する。Bunni はこの類型に当たる。

• コスト感: 最大。実装・監査・運用のすべてが重く、継続的なメンテとセキュリティ投資が要る。
• 差別化: 最大。事実上「新しい DEX プロダクト」を持てる。
• 向く事業者: DEX そのものを事業の核に据える企業。
• 最大の注意: 撤退コストまで含めて見積もる。Bunni は攻撃後、復旧監査費（6〜7桁ドル）を賄えずに事業停止に至った。「作る費用」だけでなく「守り続ける費用」が事業の前提になる。

まとめると

早く安全に → A（既存 Hook を使う）／差別化したい → B（自作 Hook）／DEX を事業の核にする → C（カスタム AMM）。Aから順にコストとリスクが跳ね上がるので、「どこまでやるか」を最初に決めるのが事業判断の起点になる。

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

v4 Hooks 採用のコスト目安

開発合計: 4-8人月（約 $40K-120K）

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

• 注（監査）: $60K-200K。規模・コード新規性・監査ファーム（簡易な個別契約か、複数社/トップティアか）で大きく変動する。簡易な fork は下限、新規性が高い・複数社起用は上限。v4 Hooks は監査対象が Hook とコアの境界にまで広がるため、難度・費用とも v3 と同等以上に振れやすい。
• 注（外部法務／弁護士費用の目安）: 初期の法的整理＋意見書として一時 $20K-80K（約300万-1,200万円）が目安。暗号資産交換業の登録取得・維持や本格的な業者化を目指す段階では年間費用が別途かかる。これは外部弁護士に支払う費用の目安であり、XTELA のサービスではない（XTELA は弁護士業務を提供しない）。
• 注（継続防御）: Bunni 事案（7章）が示すとおり、本番運用後も継続的な監査・バグバウンティ・防御の費用を見込む。規模で変動。

日本の規制論点

v4 Hooks 自体の規制論点は v2/v3 と同等（暗号資産交換業、金商法）。Hook で組み込む機能次第で追加論点が出る:

• KYC 統合 Hook: 改正資金決済法・犯収法との接続
• 取引制限 Hook: 投資勧誘・適合性原則
• ロイヤリティ Hook: 著作権法・著作隣接権

コンプラ部門と弁護士に必ず確認。XTELA は弁護士資格を持たないため、規制適合そのものを請け負うことはせず、技術設計上の論点整理にとどめる点をあらかじめお断りする。

なお Hook の安全性については、本記事 7章で扱った Bunni の事案（自社カスタムロジックの丸めバグで約840万ドルが流出し、2025年10月にサービス停止）が、コスト見積りに「継続的な監査・防御の費用」を必ず織り込むべき理由を示している。

10. BUSL ライセンスとエコシステムの現状

BUSL ライセンス — 「すぐに丸ごとコピーして商用利用」はできない

Uniswap v4 のコアコードは BUSL（Business Source License、ビジネスソースライセンス） の下で公開されている。これは「ソースは読めるが、一定期間は無断での商用・本番利用が制限される」タイプのライセンスだ。v4 のコアは概ね2027年に MIT ライセンス（自由に利用可能）へ移行する予定で、それまでの商用利用には Uniswap ガバナンスによる追加利用許諾（Additional Use Grant）が必要になる（出典: Uniswap 公式 Docs、v4-core リポジトリの LICENSE）。

事業者への含意:
- 「v4 のコアをフォークして自前の競合 DEX を出す」という使い方は、ライセンス上の制約がかかる可能性がある。最新のライセンス条文と許諾状況を必ず法務確認すること。
- 一方で、v4 のデプロイ済みコントラクト上に Hook を載せて使う通常の利用は、この制限とは別の話になる。「自社が何をしたいか」によってライセンス上の評価が変わるため、設計初期に整理しておきたい。

（v2 のコアは GPL、v3 も当初 BUSL で公開され、2023年4月に GPL（GNU General Public License）へ移行した経緯があり、Uniswap は段階的にオープン化してきた。v4 もこの流れに沿う。）

エコシステムの現状

• 公式の参考実装: TWAMM、指値注文、各種 Oracle などのサンプル Hook が Uniswap の周辺リポジトリ（v4-periphery）で公開されている。ただしいずれも「参考実装であり本番完成品ではない」と明記されている（出典: Uniswap GitHub (v4-periphery)）。
• コミュニティ Hook の蓄積: 有志がまとめる Hook の事例集・テンプレート集が複数存在し、設計の出発点として参照できる。
• 実運用の教訓も蓄積中: Bunni の事案のように、本番で資金を失う失敗例も出ており、「何が危ないか」の知見も同時に積み上がっている。

総じて、v4 のエコシステムは「機能は出揃いつつあるが、安全な作り方のベストプラクティスはまだ固まりきっていない」段階だ。早期に動くメリットと、枯れていないことのリスクを天秤にかける局面と言える。

11. まとめ

事業者目線で v4 Hooks を理解する要点を整理する。

1. Hooks = プールの動作を自社コードでカスタマイズできる拡張点。before/after の差し込み口に自社ロジックを挿す。
2. 土台は Singleton（全プールを1コントラクトに集約）と Flash Accounting（最後に差額だけ精算）。これがあるからカスタム AMM がガス的に成立する。
3. 設計思想の転換: Uniswap は「単一 DEX」から「カスタム DEX を作るプラットフォーム」へ。フォークさせず自社の上に乗せる戦略。
4. 代表ユースケース: ダイナミック手数料、TWAMM、オンチェーン指値、カスタム Oracle、LP 自動リバランス、MEV 内部化、業界特化制限。
5. 最大の利点は最大のリスク: 書き換えられる＝バグがそのまま資産リスク。Bunni（約840万ドル流出、2025年）が示すとおり、自作・カスタム化ほど監査と継続防御が重い。
6. 関わり方は3段階: 既存 Hook を使う（軽い）／自作する（中）／カスタム AMM を建てる（重い）。最初に「どこまでやるか」を決める。
7. ライセンスと成熟度: コアは BUSL で当面は商用フォーク制限あり（2027年に MIT 化予定）。機能は出揃いつつあるが安全な作り方は確立途上。

詳しくは Uniswap v2 定数積モデル、Uniswap v3 集中流動性、DeFi完全マップ 2026 を参照。

関連記事

Hooks 採用を判断する前後に、設計選択肢の幅を持つために参照したい記事を整理しました。

• Uniswap v2 定数積モデル — 「最短ローンチ・最小工数」なら v4 ではなく v2 fork が現実的。本記事 4章の比較対象として
• Uniswap v3 集中流動性 — v3 fork で完全独立する案と、v4 Hooks で乗っかる案を並べて比較する
• MEV と AMM — 本記事「ダイナミック手数料」が MEV 抑制に寄与する仕組みを、CowSwap / Flashbots と並べて整理
• Curve StableSwap 不変量 — 業界特化型 AMM のもう一つの実装パターン。Hooks ではなく独自不変量で組む選択肢
• DeFi完全マップ 2026 — Hooks が事業に何をもたらすかを「使う/組む/乗っかる」3戦略マップ上で位置付ける

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