Curve StableSwap とは｜ステーブル特化AMMの不変量

「自社でステーブルコインを発行したい」「既存のステーブルコイン（USDC、JPYC、Progmat Coin 等）を扱う商品を組みたい」——この場面で必ず登場するのが Curve Finance だ。Curve は2020年から運用されている DeFi の老舗 DEX で、「ステーブル間スワップ特化」という独自ポジションを確立している（TVL・取引高は DefiLlama、Curve 公式 Docs を参照）。本記事は事業者目線で、Curve の核心である「StableSwap 不変量」の仕組み、自社ステーブルコインの流動性ハブとしての位置付け、3つの戦略を整理する。

目次

1. なぜ事業者が Curve を理解する必要があるのか
2. StableSwap 不変量とは — 「価格が近いときだけ効率を上げる」設計
3. A パラメータとデペッグ時のダメージ
4. 円系ステーブル間・ドル系ステーブル間スワップの国内事例
5. 3つの戦略を選ぶ — 使う/組む/乗っかる
6. 開発期間とコスト、日本の規制論点
7. まとめ

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

ステーブルコインを扱う事業（送金、決済、預金、トークン化資産）には共通の課題がある:「自社が発行・採用するステーブルと、ユーザーが持っている同じ価値の別ステーブルとを、スリッページなく交換できる流動性」が必要だ。ここで重要なのは、StableSwap が効率を発揮するのは「同じ価値のはずの資産同士」、つまり同じ通貨建てのステーブル間（ドル系なら USDC ⇄ USDT、円系なら JPYC ⇄ JPYSC のように為替レートがほぼ 1:1 になる組み合わせ）だという点だ。例えば、自社サービスで JPYC を採用しているが、ユーザーは別の円ステーブル（JPYSC 等）を持っている——この場面で1:1（または僅かなスプレッド）で交換できるインフラが必要になる。なお JPYC（円ペッグ）と USDC（ドルペッグ）のように為替レートが約150倍違う異通貨間の両替は、StableSwap が想定する「1:1 付近の交換」とは別問題であり、為替レートを織り込むには別設計（Tricrypto 型等）が必要になる。

通常の AMM（Uniswap v2 等）でステーブル間スワップを行うと、定数積モデルの性質上、取引が大きくなるほどスリッページが急増し、同じ流動性で大口のステーブル間スワップを行うと Curve 比で不利になる。StableSwap は同一の流動性でより大きな取引まで低スリッページを維持できる。これを解決するのが Curve の StableSwap だ。

事業者目線で Curve は:
- 自社ステーブルコインの流動性ハブとして組み込む対象
- 他社ステーブルとの効率的なブリッジとして活用する対象
- 業界特化型 AMM を組む際の設計参考

2. StableSwap 不変量とは — 「価格が近いときだけ効率を上げる」設計

図: 価格 1:1 付近では平らな「足し算モード」で超低スリッページ、デペッグ領域に入ると Uniswap v2 の定数積カーブに漸近する「掛け算モード」へと自動で切り替わる。A パラメータが切替の鋭さを決める。

直感的説明

StableSwap 不変量は「Uniswap v2 の定数積モデル」と「シンプルな足し算（一定和）」を組み合わせた設計だ。

• 価格が1:1付近のときは「足し算モード」: 100枚預けたら、相手側 100枚が引き出せる（ほぼスリッページゼロ）
• 価格が大きく動いたとき（デペッグ）は「掛け算モード」: Uniswap v2 と同じ動きになって、価格が極端に動かないように防御する

つまり StableSwap は「普段は最高効率、緊急時は安全装置」という二面性を持つ AMM。

A パラメータの役割

このモード切替の「切れ味」を決めるのが A パラメータ だ。

• A が大きい（例: A=1000）→ 価格が大きくズレるまで「足し算モード」を維持。日常のスワップは超効率的
• A が小さい（例: A=10）→ 早めに「掛け算モード」へ。デペッグ時のダメージは小さいが、日常のスワップ効率も劣る

高信用なステーブルプールでは A は概ね数百〜2000 程度の高めの値（Curve の例示値では A=2000）が用いられる。実際の値はプール・時期で異なり、ガバナンスで段階的に調整される。

3. A パラメータとデペッグ時のダメージ

A パラメータの設計には事業者にとって重要なトレードオフがある。

A が大きすぎると：デペッグ時に LP が大損する

A を高く設定すると、価格が1:1からズレ始めても StableSwap は「足し算モード」を維持しようとする。ペッグが完全に崩れた場合（あるステーブルが半額になった等）、LP は「高価なステーブルを安く売り、安いステーブルを高く買う」逆裁定を強制される。

これが2022年5月の Terra/Luna 崩壊時に Curve UST プールで発生した。A が高く設定されていたため、UST のデペッグ初期に LP は損失を被った（Terra/Luna 崩壊全体の損失規模は Rekt News を参照）。

A が小さすぎると：日常スワップの効率が悪い

逆に A を低く設定すると、デペッグ耐性は上がるが、日常のスワップ効率が落ちる。これでは Curve を使う意味が薄れる。

事業者が押さえるべき設計判断

自社ステーブルコインを Curve に上場する場合、A パラメータの妥協点を見極める必要がある:

• 高信用なステーブル間（USDC/USDT 等）: 概ね数百〜2000 程度の高めの値（Curve の例示値では A=2000）。実際の値はプール・時期で異なる
• 新興ステーブルを含むプール: A=200 程度から開始、信用構築に応じて引き上げ
• アルゴリズミックステーブル: 警告的に A を低く保つか、そもそも Curve に上場しない判断もあり得る

4. 円系ステーブル間・ドル系ステーブル間スワップの国内事例

日本の事業者が実際に Curve（または StableSwap fork）を活用する場面を整理する。いずれも「同じ通貨建てで同じ価値のはずのステーブル同士」を効率交換する、StableSwap 本来の用途に沿った例だ。

想定シナリオ1: JPYC 採用サービスでの他円ステーブル流入対応

事業者が JPYC（円ペッグ）を採用したサービスを運営している。ユーザーが別の円ステーブル（JPYSC 等）で支払いたい場合、自社で JPYSC → JPYC 変換を提供する必要がある。発行体は違っても「1円 = 1ステーブル」を狙う同じ価値の資産同士なので、まさに StableSwap が最高効率を発揮する1:1付近のスワップだ。

• 自社で板を持つのは現実的でない
• 外部 DEX に依存することになる
• Curve（または国内 fork）に JPYC/JPYSC プールがあれば、内部で自動スワップ可能

ただし2026年5月現在、国内円ステーブル間プールは小規模で、大口取引にはスリッページが大きい。事業者は「自社で初期流動性を提供する」覚悟が必要。

想定シナリオ2: グローバル決済でのドル系ステーブル集約

国内事業者がグローバル決済を扱い、ユーザーから USDC・USDT・DAI など複数のドル系ステーブルを受け取る。社内会計や次工程では1種類（例: USDC）に寄せたい。

• USDC・USDT・DAI はいずれもドルペッグで価値はほぼ等しい（1:1付近）
• Curve の3資産ステーブルプール（USDC/USDT/DAI）はまさにこの用途のために存在し、超低スリッページで集約できる
• 受け取った各ステーブルを自動で基軸ステーブルへ寄せる窓口として組み込める

これは Curve メインネットの既存プールでそのまま実現できる、StableSwap の最も標準的な活用形だ。

補足: 異通貨（円⇄ドル）の両替は StableSwap の対象外

ここで誤解しやすいのが、JPYC（円）⇄ USDC（ドル）のように為替レートが約150倍違う異通貨ステーブル間の両替だ。これは「同じ価値のはずの資産を1:1で交換する」StableSwap の前提から外れるため、素の StableSwap プールには適さない。為替レートを織り込んだ交換が必要な場合は、Curve の Tricrypto 型（価格レンジが大きく動く資産向け）設計を fork する、あるいはオラクル価格を参照する別アーキテクチャを検討する必要がある。

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

A: 使う（既存 Curve プールで自社ステーブルを上場・運用）

• 採用条件: Curve の既存信頼性に乗る、初期流動性を提供できる資金
• メリット: グローバル流動性に即接続
• デメリット: A パラメータの設計は Curve コミュニティ依存

B: 組む（StableSwap fork で業界特化 DEX を構築）

• 採用条件: 業界特化（特定ステーブル集約、機関向け permissioned 等）の差別化軸
• 開発期間: 3-5人月、監査 $40K-150K（規模・コード新規性・監査ファームで大きく変動。簡易な fork は下限、新規性が高い・複数社起用は上限）
• 想定例: 国内ステーブル間スワップ専門 DEX、機関向け Progmat Coin スワップ

C: 乗っかる（Curve のフロントエンドや集約レイヤー）

• 採用条件: 自社の付加価値は UX・チャネル
• メリット: Curve の流動性に依存可能
• デメリット: Curve ガバナンスの意思決定に振り回されるリスク

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

StableSwap fork のコスト目安

開発合計: 5-8人月（約 $50K-120K）

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

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

Vyper の reentrancy 問題（2023年7月の Curve hack、流出規模は約 6,900万〜7,300万 USD と報道され、ホワイトハット返還後の純損失は約 2,000万 USD 程度。出典: Rekt News）の教訓を踏まえると、新規実装は Solidity 推奨。

日本の規制論点

自社ステーブル発行は改正資金決済法（資金移動業 or 信託受益権型）の枠組み。Curve 等のグローバル DEX に上場する場合、自社のライセンス範囲との整合性をコンプラ部門と弁護士に確認。

過去のインシデントから学ぶ設計教訓 — Vyper コンパイラ脆弱性 (2023年7月30日)

Curve を語る上で避けて通れないのが 2023年7月30日の Vyper コンパイラ脆弱性事件 だ。Curve の主要プールは Vyper 言語で書かれており、Vyper 0.2.15 〜 0.3.0 系で reentrancy lock の不具合（同一トランザクション内で守られるべきはずの関数が再入可能になっていた）が判明、これを突かれて複数の Curve プール（alETH/ETH、msETH/ETH、pETH/ETH、CRV/ETH 等）が攻撃され、流出規模は約 6,900万〜7,300万 USD と報道され、ホワイトハット返還後の純損失は約 2,000万 USD 程度とされる。攻撃直後は CRV トークン自体の売却圧力（創業者の DeFi 借入清算リスク）も連動して市場全体に波及した。

事業者にとっての含意:
- コンパイラ層の脆弱性は契約コードを正しく書いても回避できない: 使用言語・コンパイラのバージョンと CVE 履歴の継続的な監視が必須
- 新規実装は Solidity の主流バージョン採用が無難: Vyper を採用するなら最新版＋徹底的な reentrancy テスト
- エコシステム連鎖リスク: 単一プロトコルの hack でも、CRV のような基軸トークンが絡むと相関して全体評価が動く

出典: Curve Finance 公式 post-mortem、Rekt News - Curve Finance 等で詳細参照。

7. まとめ

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

1. StableSwap = 「価格が近いときだけ効率を上げる」二面性 AMM
2. A パラメータ が日常効率とデペッグ耐性のトレードオフを決める
3. 自社ステーブル発行者の流動性ハブとして活用する道がある
4. 3戦略「使う/組む/乗っかる」で開発工数と差別化のトレードオフを判断

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

関連記事

ステーブル間スワップの文脈から、隣接領域へ自然に広げるための記事を整理しました。

• CDP型ステーブル (MakerDAO/DAI) — 本記事「自社ステーブル発行者の流動性ハブ」を、発行側設計の観点から深掘り
• Balancer Weighted Pool — Curve に近い思想で「複数ステーブルを束ねるバスケット型」を組む別アプローチ
• Uniswap v3 集中流動性 — ステーブル特化なら 0.01% 手数料階層の v3 が選択肢。A パラメータ設計と並列で検討
• ステーブルコインとは？ — JPYC・Progmat Coin・Project Pax 等の国内3形態を、Curve の流動性ハブとどう接続するか
• DeFi完全マップ 2026 — Curve がマネーレゴ「第1層 価格発見」のステーブル特化として果たす全体上の位置

本記事は XTELA JAPAN 株式会社が作成しました。 ステーブルコイン関連のご相談は無料技術相談からお問い合わせください。