Uniswap v2 定数積モデル(x*y=k)|DEX構築の判断軸
約14分で読めます
約14分
目次(タップで折りたたみ)
本記事は技術解説であり、投資・税務・法務助言ではありません。判断は専門家にご相談ください。
「自社で発行したトークンの値段を、どうやって市場で決めるか」 ——これは Web3 事業を組み立てる際の最初の難問の一つだ。証券取引所のような「板(オーダーブック)」を自前で用意するのは現実的でない。そこで答えとして広く採用されているのが、Uniswap が2018年に世に出した AMM(Automated Market Maker:自動マーケットメイカー) という仕組みで、その中核が 「定数積モデル(x*y=k)」 だ。
定数積モデルは「人手を介さず、数式だけで誰でも・いつでも・どんな値段でも売買を成立させる」というシンプルな発明で、ローンチから約8年経った2026年でも、Uniswap v2 を中心とする AMM 系プロトコルは DeFi の最も基礎的なレイヤーであり続けている。本記事は、定数積モデルの仕組みを事業オーナーに分かる言葉で解説し、その上で「自社トークンを Uniswap に上場する」「v2 fork で自社 DEX を持つ」「サードパーティ DEX に乗る」の3つの戦略をどう選ぶかを整理する。
目次
- なぜ事業者が「定数積モデル」を理解する必要があるのか
- 定数積モデル(x*y=k)の仕組みを平易に
- v2 fork で詰まる典型3パターン(実装地雷)
- v2 / v3 / v4 の使い分け — LP 視点での意思決定
- 3つの戦略を選ぶ — 上場/fork/乗っかる
- 開発期間とコスト、日本の規制論点
- まとめ
1. なぜ事業者が「定数積モデル」を理解する必要があるのか
「Uniswap」と聞くと「投機家が使う DEX」というイメージを持つかもしれない。だが事業者目線で見ると、Uniswap は別の意味を持つ:
- 自社トークンを発行したとき、最初に上場する場所
- 自社の暗号資産在庫を、いつでも円・ドル相当物に換えられる出口
- 「自社 DEX を持つ」を fork で実現する場合の参考実装
ここで「Uniswap に上場する」は厳密には「Uniswap 上に流動性プールを作る」を意味する。中央集権取引所(バイナンス・コインベース等)の上場と違って、Uniswap には審査も上場費用もない。誰でも数分で自社トークンと ETH(または USDC)の流動性プールを作れる。
この「誰でも開ける市場」がなぜ成立するか、その裏側にあるのが定数積モデルだ。仕組みを理解しないまま「とりあえず Uniswap に流動性出しておけば良い」と判断すると、後述する「実装地雷」を踏んで、自社トークンが想定外の挙動をする事故が起きる。
2. 「x かける y は一定」を事業オーナー向けに
公式そのものは怖くない
定数積モデルの公式は「x × y = k」というだけのもの。x と y はそれぞれ「プールの中にある2種類のトークンの数」、k は「掛け算した結果(定数 = 取引前後で変わらない値)」を意味する。事業オーナーに必要なのは公式の暗記ではなく、何を意味しているかの直感。次のように読み替えると分かりやすい。
プールの中にある「2種類のトークンの数を掛け算した値」が、取引の前と後で常に等しくなるように、価格が自動調整される
例えば「自社トークン A を10,000個、USDC を10,000枚」入れたプールがあるとする。掛け算は 10,000 × 10,000 = 1億。これが k = 1億 の状態だ。
誰かが USDC 1,000枚 を入れて A トークンを買おうとする。プール内の USDC は 10,000 + 1,000 = 11,000枚 になる。掛け算 k = 1億 を保つために、プール内の A トークンは 1億 ÷ 11,000 ≒ 9,091個 まで減らされる。差分の 10,000 - 9,091 = 909個 が買い手に渡る A トークンだ。
このとき価格は「USDC 1,000枚で A トークン909個」、つまり A の価格は約 1.10 USDC/個。最初に「A の価格を 1 USDC にしてプールを作った」のだから、買い注文で価格が10%上がったことになる。(説明のため手数料は無視している。実際の v2 では入力額から 0.30% が差し引かれてから計算される)
重要なポイント3つ
事業オーナーが押さえておくべき定数積モデルの性質は3つ。
性質1: 大きく買えば買うほど、価格が指数的に上がる
少額の買いなら価格はほとんど動かないが、プールに対して大きな買い注文を入れると価格が急上昇する。これを「スリッページ(注文を出した瞬間と約定価格のズレ)」「価格インパクト(注文によって価格が動く量)」と呼ぶ。プールの流動性(k の大きさ)が小さいほど、これらが大きく出る。
性質2: プールが空になることはない
x または y がゼロになると k = 0 で破綻するが、定数積モデルでは数式上 x が 0 に近づくと A の価格が無限大になるため、どんなに買いが入ってもプールが完全に空にはならない。「最後の1個」は理論上、無限のコストを払わないと買えない。事業者にとっては「プロトコルとして枯渇しない」という保証になる。
性質3: 流動性供給者(LP)はリスクと引き換えに手数料を受け取る
プールに2種類のトークンを入れる人を LP(Liquidity Provider:流動性供給者) と呼ぶ。LP はスワップ手数料(v2 では一律 0.30%)を受け取る代わりに、「インパーマネントロス(IL: 一時的損失)」というリスクを抱える。ただし2025年11月の fee switch 有効化以降は、0.30% のうち 0.25% が LP、0.05% がプロトコルに配分される。2つのトークンの価格比が大きく動くほど、LP は「ただ持っていた方が得だった」状態になる。価格インパクト・スリッページの数学的詳細は価格インパクトとスリッページ、LP がさらされる MEV(サンドイッチ攻撃・JIT 流動性) の構造もあわせて押さえておくと、自社上場後のリスク評価が立体化する。
3. v2 fork で見落としやすい3つの落とし穴
「自社 DEX を持つなら Uniswap v2 を fork(オープンソースのコードを複製して自社用に改変すること)すれば良い」と考える事業者は多い。コード自体はオープンソース、開発期間は最短1人月程度で済む。だが XTELA が自社実装支援した案件で繰り返し見てきた「典型的な落とし穴」が3つある。
地雷1: Fee-on-Transfer トークン
Fee-on-Transfer トークンとは、送金(transfer)するたびに手数料が自動で徴収される仕組みがあらかじめ組み込まれたトークンのこと(例: 送ると5%が運営に回り、残り95%だけ相手に届く)。AMM プールでこの手のトークンを扱うと、「送った額」と「実際にプールに届いた額」がズレてしまい、x*y=k の計算が狂う。
具体的には、v2 のコードは「100枚送れば相手に100枚届く」前提で書かれているので、Fee-on-Transfer トークンを扱うとプールの会計がズレ続け、最終的に大きな損失が出る。対策は v2 に「Fee-on-Transfer 対応」の特殊コードを足すこと。Uniswap 公式の v2 ライブラリには対応版(SwapExactTokensForTokensSupportingFeeOnTransferTokens 等)が用意されているが、fork でそれを抜くと地雷を踏む。
地雷2: Rebasing トークン
Rebasing トークンとは、保有量(残高)が時間とともに自動で増減するトークンのこと。誰かが送金しなくても、各アドレスの残高が一定タイミングで勝手に書き換わる(旧仕様の stETH や一部のアルゴリズミックステーブル等)。プールが「いま自分はこのトークンを何枚持っているはず」と想定している残高と、実際の残高がズレてしまうのが問題になる。
v2 プールに rebasing トークンを入れると、プールの残高が外部から勝手に変わってしまい、k の不変性が破れる。攻撃者が rebase のタイミングを狙うと、プールから資金を引き抜ける事故が起きる。
地雷3: Reentrancy(再入攻撃)
v2 のコードは古典的な reentrancy 対策が施されているが、fork で独自フックを追加すると対策が壊れることがある。特に「ユーザー定義の callback」「Hooks 的な拡張」を v2 に足すなら、reentrancy 防御を最初に確認する必要がある。
これらの地雷は、いずれもコードを fork した後の「カスタマイズ」段階で踏むことが多い。XTELA は自社 DEX を組む案件では、必ず監査前の設計レビュー(pre-audit review)で fork 部分のリスクをチェックする。
4. v2 / v3 / v4 の使い分け — LP 視点での意思決定
Uniswap には複数バージョンが存在する。事業者目線でいつどれを使うべきかを整理する。
| バージョン | 特徴 | 事業者にとってのメリット | 事業者にとってのデメリット |
|---|---|---|---|
| v2(2020年5月) | シンプルな x*y=k | fork が容易(〜1人月)、規格が安定 | LP の資本効率が低い |
| v3(2021年5月) | 集中流動性(特定の価格帯にだけ流動性を提供できる) | LP の資本効率が大幅に向上(理論上は最大数千倍、実運用では概ね10〜100倍程度)、機関採用しやすい | 実装が複雑(〜4人月)、LP の運用も難しい |
| v4(2025年1月メインネット) | Hooks(プールの動作を自社コードでカスタマイズ可能) | カスタム AMM が組める | 新規格、規格未確定リスク残る |
LP の意思決定軸
LP(流動性供給する側)にとっては:
- v2 = 「ほっといても回る」シンプルさ。トークンペアが安定(長期的に価格比が大きく動かない)な場合に向く
- v3 = 「価格帯を予測してそこに集中投下する」アクティブ運用。専門の LP 業者(マーケットメイカー)向け
- v4 = カスタム手数料、独自ロジックを組みたい上級事業者向け
自社 DEX を組むなら最初の選択肢は v2
「自社 DEX を持ちたい」場合の現実的な選択肢は v2 fork だ。理由は3つ。
- 実装期間が短い: 0.5〜1人月で動く実装ができる
- 監査範囲が限定的: $15K-60K 程度(v3 は $40K-150K)。規模・コード新規性・監査ファーム(簡易な個別契約か、複数社/トップティアか)で大きく変動する
- 規格が枯れている: 10年の実績で、踏むべき地雷も既知になっている
v3 を選ぶのは、業界特化型 DEX(ステーブル間スワップ専用、機関向け等)で集中流動性が必要な場合に限られる。
5. 3つの戦略を選ぶ — 上場 / fork / 乗っかる
事業者が Uniswap(とその系統の AMM)に関わる戦略は3パターンに整理できる。
A: 使う(Uniswap に自社トークンを上場)
自社トークンを発行して、それを Uniswap に流動性プールとして上場する。最も多く取られるパターン。
メリット:
- 開発期間ゼロ(プール作成は数分)
- グローバル流動性に即接続できる
- 自社で板を管理する負担がない
デメリット・リスク:
- 自社トークンの価格を完全には制御できない(LP の動きで変動)
- インパーマネントロスを LP に強いる構造のため、LP 確保が必要
- 自社で初期流動性を提供する資金が必要(一般的には数千万円〜数億円規模)
適する事業フェーズ: 自社トークンを発行してすぐ、グローバル流動性に乗りたい
B: 組む(v2 fork で自社 DEX を構築)
Uniswap v2 のコードを fork して、自社専用または業界特化型の DEX を立ち上げる。
メリット:
- 手数料(取引手数料)を自社収益として吸収できる
- 業界特化型の UX を組める
- 自社トークンと相性の良い経済設計が可能
デメリット・リスク:
- 流動性ゼロから集める必要がある(LP インセンティブ設計が必須)
- 監査・運用コストの継続的負担
- セキュリティ事故時の責任を自社が負う
適する事業フェーズ: 業界特化型の差別化が必要、運用人員を確保できるスタートアップ
開発期間目安: 0.5〜1人月(フロント別途)。監査費は $15K-60K(規模・コード新規性・監査ファームで大きく変動。簡易な fork は下限、新規性が高い・複数社起用は上限)。
C: 乗っかる(既存 DEX のフロントエンドや集約レイヤーを提供)
自社では DEX のコアを組まず、Uniswap や 1inch、CowSwap などの上で動くフロントエンドや、特定セグメント向けのアグリゲータを提供する。
メリット:
- 開発期間が短い(フロントとAPI連携のみ)
- 流動性は既存 DEX に依存できる
- セキュリティリスクは限定的
デメリット・リスク:
- 接続先 DEX の仕様変更に振り回される
- 差別化が UX/業界知見に限定される
適する事業フェーズ: 既存事業の周辺拡張、特定セグメント特化
3戦略の比較
| 判断軸 | A: 使う | B: 組む | C: 乗っかる |
|---|---|---|---|
| 開発工数 | 小(数分) | 中(〜1人月) | 小〜中(〜2か月) |
| 監査コスト | 不要 | $15K-60K | 軽微 |
| 自社収益 | 自社トークン価値上昇 | 取引手数料 | UX 価値 |
| 必要な運用人員 | 小 | 中(Solidity 1-2人) | 小 |
| 差別化余地 | 小 | 大 | 中 |
注: 監査コストは規模・コード新規性・監査ファーム(簡易な個別契約か、複数社/トップティアか)で大きく変動する。簡易な fork は下限、新規性が高い・複数社起用は上限。
6. 開発期間とコスト、日本の規制論点
自社トークン上場の法的論点
日本で自社トークンを発行する場合、まず確認すべきは「金融商品取引法での有価証券該当性」と「改正資金決済法での暗号資産該当性」だ。
- ファンド型・配当型トークンは「有価証券」とみなされると、第二種金融商品取引業の登録が必要
- 暗号資産該当の場合は、自社発行であっても流通量によっては暗号資産交換業ライセンスが論点になる
- 国内取引所への上場には別途審査がある(Uniswap への上場は自由)
これらは法務助言の領域。コンプラ部門と弁護士に必ず確認すること。XTELA は「法令対応をサービスとして請け負わない」立場なので、技術側の論点のみ整理する。
v2 fork DEX の実装コスト
| 項目 | 目安 |
|---|---|
| Solidity 実装 | 0.5-1人月 |
| フロントエンド | 1-2人月 |
開発合計: 1.5〜3人月(約 $15K-45K)(1人月 ≒ $10K-15K で換算)
―― 以下は別途・規模で変動 ――
- 注: 監査 $15K-60K(規模・コード新規性・監査ファーム(簡易な個別契約か、複数社/トップティアか)で大きく変動。簡易な fork は下限、新規性が高い・複数社起用は上限)
- 注: Oracle 統合(必要時) $10K/年
- 注: バグバウンティ 月額 $5K-20K
- 注: インデックス・データ基盤 The Graph 利用料 月額数千ドル
- 注: 外部法務(弁護士費用の目安) 初期の法的整理+意見書として一時 $20K-80K(約300万-1,200万円)。これは外部弁護士に支払う費用の目安であり、XTELA のサービスではない(XTELA は弁護士業務を提供しない)
7. まとめ
事業者目線で Uniswap v2 定数積モデルを理解する要点は5つ。
- x*y=k は「プール内のトークン数の積を一定に保つ」だけのシンプルなルール。これが「誰でも開ける市場」を成立させる
- 3つの性質(大量買いで価格が指数的に上がる/プールは枯渇しない/LP は IL リスクを負う)を押さえる
- v2 fork で詰まる地雷(Fee-on-Transfer、Rebasing、Reentrancy)は事前に対応
- v2 / v3 / v4 の使い分けは LP の運用負担と事業差別化のバランスで決める
- 3戦略「使う/組む/乗っかる」は開発工数・収益・差別化のトレードオフで選ぶ
自社トークンを発行する事業、業界特化型 DEX を構築する事業、DeFi 接続フロントエンドを提供する事業——どの形でも Uniswap 系 AMM の理解は前提知識として欠かせない。
詳しくは DeFi完全マップ 2026 で全体像と他プロトコルとの関係を整理している。
関連記事
v2 を理解した上で「次に何を読めば自社の意思決定が前に進むか」を整理しました。
- Uniswap v3 集中流動性 — v2 の「ほっといても回る」LP に対し、v3 はアクティブ運用が前提。LP の意思決定コスト軸で v2/v3 を比較する続編
- Uniswap v4 Hooks アーキテクチャ — v2 fork でカスタム機能を足す代わりに、v4 Hooks で「v4 の流動性に乗りつつ自社差別化」する選択肢
- 価格インパクトとスリッページ — 本記事「性質1: 大量買いで価格が指数的に上がる」を、機関・大口取引者のコスト計算として深掘り
- MEV と AMM — 自社トークンを v2 に上場した後にユーザーから「MEV で損した」と言われる前に押さえる防御設計
- DeFi完全マップ 2026 — マネーレゴ4層構造で v2 が「第1層 価格発見」に位置する全体像
XTELA の DEX 実装支援知見
本セクションは XTELA のサービス紹介です。本文中立の技術解説とは分離して掲載しています。
XTELA は2015年以降、50案件以上のブロックチェーン開発支援を行ってきました。AMM/DEX 関連について、以下のような支援が可能です:
- v2 fork DEX の自社実装支援: Fee-on-Transfer / Rebasing トークン対応、reentrancy 防御の事前レビュー
- 自社トークン上場の前段設計: 初期流動性プールのサイジング、LP インセンティブ設計
- 業界特化 AMM の設計: ステーブル特化、ロイヤリティ付き、機関向け permissioned 等
- 監査前の設計レビュー: 監査費を最小化するための事前 issue 潰し
「自社トークンを Uniswap に上場するか」「v2 fork で自社 DEX を持つか」の意思決定段階から、実装・監査・運用までを並走支援しています。
本記事は XTELA JAPAN 株式会社が作成しました。 DeFi 開発に関するご相談は無料技術相談からお問い合わせください。