2026年版:ステーブルコインの作り方

最終更新日: 2026年2月3日3分で読めます

ステーブルコインを取り巻く状況は、ここ数年で劇的に変化した。かつては規制上のグレーゾーンだったものが、明確なルール、定義されたパスウェイ、そして前例のない機会を備えた構造化された市場へと結晶化した。流通額は3,000億ドルを超え、2030年には1.9兆ドルに達するとの予測もある中、ステーブルコインは暗号資産の取引ペアからコアとなる金融インフラへと進化しつつある。

本ガイドでは、2026年にステーブルコインを構築する上で理解しておくべき技術的、規制的、戦略的側面のすべてを解説する。

新たな規制の現実

長年、ステーブルコイン発行者は法的な曖昧さの中で活動していた。ある州ではマネートランスミッターライセンス、別の場所ではオフショア構造といった具合に、管轄区域や取り締まりの気分によって解釈が異なるパッチワークだった。その時代は2025年についに終わりを迎えた。

現在、グローバルなステーブルコインの状況を規定する主要な規制枠組みは3つある。米国のGENIUS Act、欧州連合のMiCA、そしてアジア太平洋地域全体で足並みを揃えつつある一連の枠組みだ。これらは合わさって、ステーブルコインの発行を規制上のグレーゾーンから、明確なルール、定義された資本要件、明示的な技術的義務を伴うライセンス制の金融行為へと変貌させた。

開発者にとっての意味

これらの枠組みは、コードを一行書く前からスマートコントラクトのアーキテクチャを規定する。特に、世界各地の管轄区域が発行者に対して収斂しつつある制約には3種類ある。

規制上のコントロール: ステーブルコインのコントラクトを完全にイミュータブルかつ管理者なしにすることはできない。取引を凍結、差し押さえ、取り戻す能力が必要になる。
準備金要件: ユーザーがステーブルコインを発行するために1ドルを預けたとしても、それを自由に扱うことはできない。預け入れられた資金は、事前に承認された資産のリストの中で、常に準備金として保有することがますます求められている。
開示/ライセンス: 準備金の規模は、会計・監査要件に重要な影響を及ぼす。準備金が500億ドルを超える場合、GENIUS Actでは会計事務所による年次監査と月次アテステーションが義務付けられる。

これらは後から追加してもよいオプション機能ではなく、発行のための法的な前提条件である。自身のユースケースにおける規制要件の詳細については、上記でリンクした法的文書を参照するか、デジタル資産を専門とする弁護士に相談すること。

無料ガイド

銀行のためのデジタルアセット

トークン化預金によりクロスボーダー決済コストを40〜60%削減。大手銀行がどのように実現しているか、そのステップバイステップガイドを入手してください。

ガイドをダウンロード

ステーブルコインのモデルを選ぶ

規制要件を考慮するのは一つの判断だ。それに加えて、どのステーブルコインモデルを構築するかも決める必要がある。

選択する安定化メカニズムによって、資本要件から技術アーキテクチャ、規制当局による製品の分類方法まで、すべてが決まる。規制当局から見ればすべてのモデルが同等というわけではなく、暗号資産の黎明期には成功していたアプローチの中には、規制された市場から事実上完全に排除されているものもある。各モデルには、戦略的な目標とターゲットとする管轄区域の両方に合致させなければならない、それぞれ異なるトレードオフがある。

法定通貨担保型ステーブルコイン

法定通貨担保型ステーブルコインは、伝統的な通貨による直接的な担保によってペッグを維持する。流通しているトークン1枚につき、同額のUSDが準備金口座に保管されている。このモデルは3,000億ドル超のステーブルコイン市場の90%以上を占める。

仕組み

ユーザーが1,000ドルを預けると、発行者は1,000トークンを発行する。そのドルは、分別された準備金、つまり銀行預金、短期国債、マネーマーケットファンドへと流れ込む。ユーザーがトークンを現金に償還すると、このプロセスは逆になる。トークンがバーンされ、その後ドルがユーザーのアカウントに戻る。

ペッグは裁定取引によって維持される。トークンが二次市場で0.99ドルで取引されている場合、裁定業者が安く買い、発行者に1.00ドルで償還することでスプレッドを得る。このメカニズムが価格をペッグへと押し戻す。

経済性

100億ドル規模のステーブルコインは、現在の国債金利では準備金利息として年間約4億~5億ドルを生み出す。規制上、保有者に利回りを渡すことが禁じられているため、これらはすべて発行者が保持する。これは強力なユニットエコノミクスを生み出す一方で、多額の事前資本を必要とする。利回りが意味を持つほどの水準になるにはかなりの準備金が必要であり、新規参入者にとっては鶏と卵の問題を生む。

運用上の要件

法定通貨担保型ステーブルコインの運用には、銀行との関係(暗号資産関連企業にとってしばしば困難)、カストディインフラ、リアルタイムのトレジャリー管理、AML/KYCおよび規制報告のためのコンプライアンスチーム、そして適格な会計事務所とのアテステーション関係が必要となる。

事例

USDT(Tether)が1,400億ドル超でトップに立つ。USDC(Circle)は規制準拠の代替として450億ドルで続く。PYUSD(PayPal)は38億ドルに達した。

このモデルを選ぶべき場合

規制遵守が最優先である場合、銀行インフラへのアクセスがある場合、機関投資家向けまたは決済ユースケースをターゲットとする場合、そして準備金を賄うのに十分な資本がある場合。

暗号資産担保型ステーブルコイン

暗号資産担保型ステーブルコインは、他のデジタル資産による過剰担保によってペッグを維持し、すべてスマートコントラクトで管理される。法定通貨の準備金は存在せず、安定性は担保価値と発行済みトークンとの数理的な関係から生まれる。

仕組み

ユーザーは暗号資産(通常はETH、BTC、その他の主要資産)を担保としてスマートコントラクトに預け入れる。コントラクトは、指定された担保比率までステーブルコインを発行することを許可する。担保比率150%で150ドル相当のETHを預けた場合、最大100トークンまで発行できる。

重要なメカニズムは清算だ。担保価値が最低しきい値を下回った場合(例:担保が負債の120%まで下落した場合)、誰でも清算を実行し、ステーブルコインの負債を返済する代わりに割引価格で担保を受け取ることができる。これにより清算人はシステムの支払能力を維持するインセンティブを得る一方、ステーブルコイン保有者を担保不足から保護する。

ガバナンス

集中管理された発行者を持つ法定通貨担保型ステーブルコインとは異なり、暗号資産担保型システムは通常、分散型ガバナンスを通じて運営される。トークン保有者は、担保タイプ、安定化手数料(金利)、担保タイプごとの負債上限、清算ペナルティといった重要なパラメータについて投票する。これは柔軟性をもたらす一方でリスクも生む。ガバナンスの判断を誤れば安定性を脅かしかねない。

ペッグの安定性

現代的なシステムには、USDCのような承認済みステーブルコインとの1:1の直接スワップを可能にするPeg Stability Module(PSM)が含まれることが多い。これにより価格に強固な床と天井が生まれるが、集中型担保への依存が生じる。

事例

DAI(MakerDAO)は流通量約50億ドル。LiquityのLUSDは、ETHのみを担保とするより分散化された代替案を提供する。

このモデルを選ぶべき場合

法定通貨の銀行取引を完全に避けたい場合、ユーザーが分散化を重視する場合、そして清算メカニズムとガバナンスの複雑さを受け入れられる場合。

アルゴリズム型ステーブルコイン

アルゴリズム型ステーブルコインは、外部の担保なしに、自動化された供給調整によってペッグの維持を試みる。プロトコルは、目標ペッグからの価格乖離に基づいてアルゴリズム的にトークンを発行・バーンする(例:トークンが1ドルを上回って取引された場合、プロトコルは供給を増やすために新しいトークンを発行する)。

アルゴリズム型ステーブルコイン市場は、ピーク時の200億ドル超から縮小し、合計5億ドル未満となっている。決済や機関投資家向けユースケースで意味のある採用を達成したアルゴリズム型ステーブルコインは存在しない。

(理論上の)仕組み

純粋なアルゴリズム型ステーブルコインは、デュアルトークンまたはシニョリッジモデルを採用する。ステーブルコインが1ドルを上回って取引される場合、プロトコルは新しいトークンを発行し(多くの場合、二次的な「シェア」トークンの保有者に対して)分配し、価格がペッグに戻るまで供給を増やす。1ドルを下回って取引される場合、プロトコルはボンドを提供するか、供給を減らすためのバーンメカニズムを発動する。

根本的な課題は反射性だ。下落局面では、このメカニズムは市場参加者が将来の利益を期待してボンドやシェアトークンを購入することを前提とする。しかし信頼が失われると、まさに最も必要とされるタイミングでこれらの二次的トークンへの需要が消失し、デススパイラルを引き起こす。

terra/lunaの崩壊

Terra's USTは2022年5月に崩壊する前、流通量180億ドルに達していた。この崩壊により約600億ドルの価値が消失した。これにより、規制当局やほとんどの市場参加者の目から見て、純粋なアルゴリズム型アプローチの信頼は根本的に失墜した。

規制上の扱い

GENIUS Actは、決済用ステーブルコインの枠組みからアルゴリズム型ステーブルコインを明示的に除外している。MiCAの枠組みは準備資産を要求する。これは、アルゴリズム型ステーブルコインが規制対象の決済レール、銀行との関係、機関投資家による採用への道にアクセスできないことを意味する。

このモデルを選ぶべき場合

選ぶべきではない(申し訳ないが)。規制上の除外、風評の損害、メカニズムの脆弱性により、アルゴリズム型ステーブルコインは真剣なアプリケーションには実用的ではない。

技術アーキテクチャの詳細

以上の背景を踏まえた上で、実際の構築について見ていこう。実際にステーブルコインを構築するにはどうすればよいのか。

本番環境向けのステーブルコインを構築するには、高度なスマートコントラクトエンジニアリング、セキュリティインフラ、運用ツールが必要となる。デプロイするコードは単なるトークンではなく、規制当局を満足させ、敵対的な状況を生き抜き、場合によっては数十億ドル規模の価値を扱う金融商品である。GENIUS Actの技術的義務(凍結、差し押さえ、ブラックリスト機能)は提案ではない。初日からコントラクトアーキテクチャに組み込まれていなければならない。

このセクションでは実装のための技術的基盤を提供する。まずは、規制要件とセキュリティのベストプラクティスの両方を満たすスマートコントラクトパターンから始めよう。

コアとなるスマートコントラクト

準拠したステーブルコインのスマートコントラクトは、トークン規格そのもの、アクセス制御メカニズム、供給管理機能、コンプライアンス制御という、複数の相互に連動するコンポーネントを実装する必要がある。良いニュースは、実戦で鍛えられたビルディングブロックがすでに存在することだ。OpenZeppelinの監査済みコントラクトは、数十億ドル規模の展開価値に耐えてきた基盤を提供する。重要なのは、これらのプリミティブを、自身の規制・運用コンテキストが求める特定の機能で拡張することだ。

Base token implementation

まずはコントラクトの骨格から始めよう。ここでは複数のOpenZeppelinベースコントラクトを継承し、それぞれが特定の機能を提供する。ERC20Upgradeableは標準的なトークンインターフェースを、ERC20PausableUpgradeableは緊急停止機能を、AccessControlUpgradeableはきめ細かな権限設定を、そしてUUPSUpgradeableはトークン残高を移行することなくコントラクトをアップグレード可能にする。

冒頭のロール定義は権限構造を確立する。あらゆることができる単一の「オーナー」を置く代わりに、責務を分離している。minterは供給の拡大を、burnerは償還処理を、pauserは緊急事態の管理を、blacklisterはコンプライアンス対応を担当する。この分離は、セキュリティの観点(一つの鍵が侵害されてもすべてが侵害されるわけではない)からも、運用上の明確さ(コンプライアンスチームがミント機能にアクセスする必要はない)からも重要だ。

solidityCopied
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts-upgradeable/access/AccessControlUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC20/extensions/ERC20PausableUpgradeable.sol";

contract RegulatedStablecoin is
Initializable,
ERC20Upgradeable,
ERC20PausableUpgradeable,
AccessControlUpgradeable,
UUPSUpgradeable
{
bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");
bytes32 public constant PAUSER_ROLE = keccak256("PAUSER_ROLE");
bytes32 public constant BLACKLISTER_ROLE = keccak256("BLACKLISTER_ROLE");
bytes32 public constant UPGRADER_ROLE = keccak256("UPGRADER_ROLE");

  mapping(address => bool) private _blacklisted;

  event Blacklisted(address indexed account);
  event UnBlacklisted(address indexed account);
  event Mint(address indexed minter, address indexed to, uint256 amount);
  event Burn(address indexed burner, uint256 amount);

  /// @custom:oz-upgrades-unsafe-allow constructor
  constructor() {
      _disableInitializers();
  }

  function initialize(
      string memory name,
      string memory symbol,
      address defaultAdmin
  ) public initializer {
      __ERC20_init(name, symbol);
      __ERC20Pausable_init();
      __AccessControl_init();
      __UUPSUpgradeable_init();

      _grantRole(DEFAULT_ADMIN_ROLE, defaultAdmin);
      _grantRole(MINTER_ROLE, defaultAdmin);
      _grantRole(BURNER_ROLE, defaultAdmin);
      _grantRole(PAUSER_ROLE, defaultAdmin);
      _grantRole(BLACKLISTER_ROLE, defaultAdmin);
      _grantRole(UPGRADER_ROLE, defaultAdmin);
  }

  function decimals() public pure override returns (uint8) {
      return 6; // USDC convention for USD stablecoins
  }

}

ここでは典型的な18ではなく6桁の小数を使用している点に注意してほしい。これは、ドル建てステーブルコインにおけるUSDCの慣例に従っている。セントにきれいに対応し、2桁の精度しか必要としない通貨に対して18桁という不自然な精度を避けられる。これは早い段階で下し、永久に付き合うことになる設計上の決定なので、自身のユースケースを慎重に検討すること。

供給管理:ミントとバーン

mint関数とburn関数は、トークンが流通に入り、また流通から出ていく場所だ。法定通貨担保型モデルでは、ユーザーがドルを預け入れたときにミントが発生し、償還時にバーンが発生する。これらの操作は厳密に制御されなければならない。承認された財務オペレーションだけが新しいトークンを作成できるべきであり、すべてのミントは実際に準備金口座に入ってくるドルに対応していなければならない。

onlyRole\(MINTER\_ROLE\)修飾子は、ミント権限を付与されたアドレスのみがこの関数を呼び出せることを保証する。whenNotPaused修飾子は緊急時のミントを防ぐ。そして重要な点として、ミント前に受取人がブラックリストに載っていないことを確認する。制裁対象のアドレスのためにトークンを作成したくはないはずだ。

burnFrom関数は、ユーザーが自分に代わってトークンをバーンすることを償還コントラクトに承認する、一般的な償還フローを処理する。\_spendAllowanceの呼び出しは承認を検証・減算し、不正なバーンを防ぐ。

solidityCopied
// Minting - only authorized minters (typically treasury operations)
function mint(address to, uint256 amount)
  external
  onlyRole(MINTER_ROLE)
  whenNotPaused
{
  require(!_blacklisted[to], "Recipient is blacklisted");
  _mint(to, amount);
  emit Mint(msg.sender, to, amount);
}

// Burning - for redemptions
function burn(uint256 amount)
external
onlyRole(BURNER_ROLE)
whenNotPaused
{
_burn(msg.sender, amount);
emit Burn(msg.sender, amount);
}

// Burn from specific address (for redemption processing)
function burnFrom(address account, uint256 amount)
external
onlyRole(BURNER_ROLE)
whenNotPaused
{
_spendAllowance(account, msg.sender, amount);
_burn(account, amount);
emit Burn(account, amount);
}

ブラックリストの実装

ここでGENIUS Actの凍結要件を実装する。ブラックリストは概念的にはシンプルで、アドレスからブール値へのマッピングにすぎないが、それを転送フローに組み込むことこそが効果を発揮させる。\_update関数(OpenZeppelinのERC-20がすべての転送、ミント、バーンで呼び出す)をオーバーライドすることで、ブラックリストに載ったアドレスがいかなる状況でもトークンを送受信できないようにする。

isBlacklistedビュー関数は誰でもアドレスのステータスを確認できるようにする。これは、トークンとやり取りする前にコンプライアンスを検証する必要がある連携プロトコルにとって重要だ。イベント(Blacklisted、UnBlacklisted)は、すべてのコンプライアンス対応について監査可能なオンチェーンの記録を作成する。

solidityCopied
function blacklist(address account)
     external
     onlyRole(BLACKLISTER_ROLE)
 {
     require(!_blacklisted[account], "Already blacklisted");
     _blacklisted[account] = true;
     emit Blacklisted(account);
 }

function unBlacklist(address account)
external
onlyRole(BLACKLISTER_ROLE)
{
require(_blacklisted[account], "Not blacklisted");
_blacklisted[account] = false;
emit UnBlacklisted(account);
}

function isBlacklisted(address account) external view returns (bool) {
return _blacklisted[account];
}

// Override _update to enforce blacklist on all transfers
function _update(
address from,
address to,
uint256 amount
) internal virtual override(ERC20Upgradeable, ERC20PausableUpgradeable) {
require(!_blacklisted[from], "Sender is blacklisted");
require(!_blacklisted[to], "Recipient is blacklisted");
super._update(from, to, amount);
}

一時停止機能

すべてを止める必要がある場合もある。コントラクトで発見された重大な脆弱性、協調的な攻撃、あるいは規制当局の命令によって、直ちにすべての転送を停止する必要が生じるかもしれない。一時停止機能はこの緊急ブレーキを提供する。

solidityCopied
function pause() external onlyRole(PAUSER_ROLE) {
  _pause();
}

function unpause() external onlyRole(PAUSER_ROLE) {
_unpause();
}

\_updateはERC20PausableUpgradeableを継承しているため、\_pause\(\)を呼び出すと、\_unpause\(\)が呼び出されるまですべての転送がrevertするようになる。PAUSER_ROLE,を誰が保持するかは慎重に検討すること。緊急時に迅速にアクセスできる必要がある一方で、荒らし行為のベクトルになるほど広く分散させるべきではない。

アップグレード可能性

スマートコントラクトはデフォルトではイミュータブルだが、規制対象の金融インフラは進化していく必要がある。バグ修正、新たなコンプライアンス要件、機能追加はいずれもアップグレードの能力を必要とする。UUPSパターンは、アップグレードロジックを実装コントラクト自体の中に置き、\_authorizeUpgrade関数によって認可された当事者だけがアップグレードをトリガーできるようにする。

solidityCopied
function _authorizeUpgrade(address newImplementation)
  internal
  override
  onlyRole(UPGRADER_ROLE)
{}

// Version tracking for upgrade history
function version() external pure returns (string memory) {
return "1.0.0";
}

バージョン関数はシンプルだが価値がある。現在どの実装バージョンがアクティブなのかを誰でも検証できるようにするもので、デバッグや監査証跡にとって重要だ。本番環境では、タイムスタンプ、以前の実装アドレス、オンチェーンに保存されるか、コンテンツハッシュ経由で参照されるアップグレードの理由といった、より詳細なアップグレード追跡の追加を検討すること。

高度なコンプライアンス機能

基本的な実装はGENIUS Actのコア要件をカバーするが、高度なステーブルコイン運用ではしばしば追加の機能が必要になる。これらの高度な機能は、特定の規制シナリオや機関投資家の要件に対応するものだ。

クローズドループシステム向けのホワイトリストモード

ブラックリストが特定の悪意ある主体をブロックするのに対し、いくつかのユースケースでは逆のアプローチ、すなわち事前に承認されたアドレスのみがトークンを保有・転送できるようにすることが求められる。このような「クローズドループ」モデルは、すべての参加者がステーブルコインに触れる前にKYCを完了しなければならない機関投資家向けの環境に適している。

この実装では、トグル(whitelistEnabled)と、承認済みアドレス用の別のマッピングが追加される。有効化されると、\_updateのオーバーライドはブラックリストのステータスに加えてホワイトリストのステータスもチェックする。なお、fromがゼロアドレスの場合(ミント)はホワイトリストに登録されていないアドレスへのミントを、toがゼロアドレスの場合(バーン)はホワイトリストに登録されていないアドレスからのバーンを、それぞれ明示的に許可している点に注意してほしい。これにより発行者は、正式にホワイトリストに登録される前の新規ユーザーに対してミントすることでオンボーディングできる。

solidityCopied
bool public whitelistEnabled;
mapping(address => bool) private _whitelisted;

bytes32 public constant WHITELISTER_ROLE = keccak256("WHITELISTER_ROLE");

event WhitelistEnabled();
event WhitelistDisabled();
event Whitelisted(address indexed account);
event RemovedFromWhitelist(address indexed account);

function enableWhitelist() external onlyRole(DEFAULT_ADMIN_ROLE) {
whitelistEnabled = true;
emit WhitelistEnabled();
}

function disableWhitelist() external onlyRole(DEFAULT_ADMIN_ROLE) {
whitelistEnabled = false;
emit WhitelistDisabled();
}

function addToWhitelist(address account)
external
onlyRole(WHITELISTER_ROLE)
{
_whitelisted[account] = true;
emit Whitelisted(account);
}

function removeFromWhitelist(address account)
external
onlyRole(WHITELISTER_ROLE)
{
_whitelisted[account] = false;
emit RemovedFromWhitelist(account);
}

// Modify _update to check whitelist when enabled
function _update(
address from,
address to,
uint256 amount
) internal virtual override {
require(!_blacklisted[from], "Sender is blacklisted");
require(!_blacklisted[to], "Recipient is blacklisted");

  if (whitelistEnabled) {
      // Allow minting (from = 0) and burning (to = 0)
      if (from != address(0)) {
          require(_whitelisted[from], "Sender not whitelisted");
      }
      if (to != address(0)) {
          require(_whitelisted[to], "Recipient not whitelisted");
      }
  }

  super._update(from, to, amount);

}

クローバック機能

一部の管轄区域、特にStablecoins Ordinanceの下にある香港では、裁判所命令に基づいてトークンをあるアドレスから別のアドレスへ強制的に移動させる能力が求められる。これは最も侵襲的なコンプライアンス機能であり、保有者の同意なしにトークンを移動させることを発行者に許すものだ。

実装自体はシンプルだが、その含意は重大だ。reasonパラメータはクローバックが発生した理由についてオンチェーンの記録を作成し、イベントは完全な透明性を提供する。クローバック操作にはマルチシグの承認を要求し、各クローバックを特定の法的命令に紐づける詳細なオフチェーンの記録を維持することを検討してほしい。

solidityCopied
bytes32 public constant CLAWBACK_ROLE = keccak256("CLAWBACK_ROLE");

event Clawback(
address indexed from,
address indexed to,
uint256 amount,
string reason
);

function clawback(
address from,
address to,
uint256 amount,
string calldata reason
) external onlyRole(CLAWBACK_ROLE) {
require(bytes(reason).length > 0, "Reason required");
_transfer(from, to, amount);
emit Clawback(from, to, amount, reason);
}

暗号資産担保型システム向けのオラクル連携

法定通貨担保型ではなく暗号資産担保型のステーブルコインを構築している場合、信頼できる価格フィードは重要なインフラとなる。ポジションが健全か清算対象かを決定する担保比率は、正確でタイムリーな価格データに完全に依存する。

Chainlinkはオンチェーン価格オラクルの業界標準となっている。以下の連携パターンは、適切な安全性チェックとともに価格を取得する方法を示している。鮮度のチェック(1時間未満の価格データを要求する)は、システムが古い情報に基づいて動作することを防ぐ。これは、価格が数分以内に大きく動きうる高ボラティリティの局面で極めて重要となる。

getCollateralRatio関数は、ユーザーのポジションの担保価値(担保量に現在価格を掛けたもの)を未返済の負債と比較することで、現在の健全性を計算する。liquidate関数は、誰でも担保不足のポジションを清算し、負債を返済して担保とボーナスを受け取ることを可能にする。このボーナスは、清算人がポジションを監視し迅速に行動するインセンティブとなり、システムの支払能力を維持する。

solidityCopied
import "@chainlink/contracts/src/v0.8/interfaces/AggregatorV3Interface.sol";

contract CollateralizedStablecoin {
AggregatorV3Interface internal priceFeed;

  uint256 public constant LIQUIDATION_THRESHOLD = 150; // 150%
  uint256 public constant LIQUIDATION_BONUS = 10; // 10% bonus for liquidators

  struct Vault {
      uint256 collateralAmount;
      uint256 debtAmount;
  }

  mapping(address => Vault) public vaults;

  constructor(address _priceFeed) {
      priceFeed = AggregatorV3Interface(_priceFeed);
  }

  function getLatestPrice() public view returns (uint256) {
      (
          ,
          int256 price,
          ,
          uint256 timeStamp,
      ) = priceFeed.latestRoundData();

      // Staleness check - revert if price is older than 1 hour
      require(block.timestamp - timeStamp < 3600, "Stale price data");
      require(price > 0, "Invalid price");

      return uint256(price);
  }

  function getCollateralRatio(address user) public view returns (uint256) {
      Vault memory vault = vaults[user];
      if (vault.debtAmount == 0) return type(uint256).max;

      uint256 collateralValue = (vault.collateralAmount * getLatestPrice()) / 1e8;
      return (collateralValue * 100) / vault.debtAmount;
  }

  function liquidate(address user) external {
      require(
          getCollateralRatio(user) < LIQUIDATION_THRESHOLD,
          "Position is healthy"
      );

      Vault storage vault = vaults[user];
      uint256 debtToCover = vault.debtAmount;
      uint256 collateralToSeize = (debtToCover * (100 + LIQUIDATION_BONUS)) /
          (getLatestPrice() / 1e8);

      // Transfer stablecoins from liquidator to protocol
      // Transfer collateral to liquidator with bonus
      // Clear vault

      vault.collateralAmount = 0;
      vault.debtAmount = 0;
  }

}

マルチシグとタイムロック

本番環境のデプロイでは、重要な操作を単一の鍵に信頼させるべきではない。マルチシグウォレットは複数の当事者によるトランザクションの承認を要求し、タイムロックは強制的な待機期間を追加することで、コミュニティが提案された変更に反応する時間を確保する。

以下のパターンは、タイムロックで保護されたミントを示している。即座に実行するのではなく、ミント操作はまずそのパラメータとアンロック時刻を記録して提案される。遅延期間が経過した後にのみ、操作を実行できる。ミントのような日常的な操作(準備金がすでに検証されている場合)については、24時間の遅延がセキュリティと運用効率のバランスを取る。コントラクトの動作を根本的に変えうるアップグレードについては、より長い遅延(7日以上)を設けることで、変更に異論があるユーザーに離脱する時間を与える。

ブラックリスト登録は、意図的にタイムロック要件から除外されている点に注意してほしい。資産を凍結する裁判所命令を受け取った場合、24時間待つのではなく、即座に行動する必要がある。

solidityCopied
import "@openzeppelin/contracts/governance/TimelockController.sol";

contract StablecoinGovernance {
TimelockController public timelock;

  uint256 public constant MINT_DELAY = 24 hours;
  uint256 public constant UPGRADE_DELAY = 7 days;

  mapping(bytes32 => uint256) public pendingOperations;

  function proposeMint(address to, uint256 amount) external {
      bytes32 operationId = keccak256(abi.encode("mint", to, amount));
      pendingOperations[operationId] = block.timestamp + MINT_DELAY;
  }

  function executeMint(address to, uint256 amount) external {
      bytes32 operationId = keccak256(abi.encode("mint", to, amount));
      require(
          block.timestamp >= pendingOperations[operationId],
          "Timelock not expired"
      );
      require(pendingOperations[operationId] != 0, "Operation not proposed");

      delete pendingOperations[operationId];
      // Execute mint
  }

}

セキュリティ上の考慮事項

コントラクトのロジック自体を超えて、本番環境のステーブルコインには包括的なセキュリティプラクティスが必要となる。

アクセス制御のチェックリスト

デプロイの前に、以下を確認すること。すべての特権的な関数に適切なロールチェックがあること、ロールの割り当てが最小権限の原則に従っていること(誰も必要以上のアクセス権を持たない)、重要なロール(admin、upgrader)がマルチシグの承認を要求すること、緊急時の手順が文書化されテストされていること、そしてチームメンバーが離脱した場合や鍵が侵害された可能性がある場合の鍵ローテーション手順が確立されていること。

監査要件

本番環境のステーブルコインには、複数の独立したセキュリティ監査が必要となる。標準的な実務には、信頼できる企業(Trail of Bits、OpenZeppelin、Consensys Diligence、Halbornなど)による少なくとも2回の監査、重要な不変条件(総供給量が残高の合計と一致すること、ブラックリストに載ったアドレスが転送できないこと)の形式的検証、担保型システムのための経済的な監査(極端な市場状況下での清算メカニズムのストレステスト)、そして本番環境における自動化された不変条件チェックによる継続的な監視が含まれる。

監査をチェックボックス的な作業として扱わないこと。早い段階で監査人を関与させ、システムを深く理解する時間を与え、重大な指摘事項だけでなく、すべての指摘事項に対応すること。徹底した監査のコストは、本番環境でのエクスプロイトのコストに比べれば取るに足らないものだ。

継続的な監視

本番環境に自動化された不変条件チェックをデプロイすること。総供給量が残高の合計と一致していること、ブラックリストに載ったアドレスが転送できないこと、そしてロールの割り当てが想定される構成と一致していることを監視する。異常な活動パターンに対するアラートを設定すること。

マルチシグ要件

本番環境のデプロイでは、重要な操作を単一の鍵に信頼させるべきではない。すべてのadmin関数に対してマルチシグウォレット(Gnosis Safeなど)を使用すること。緊急性のない操作についてはタイムロックを検討する。ミントに対する24時間の遅延はエラーを検知する時間を与え、アップグレードに対する7日間の遅延は変更に異論があるユーザーに離脱する時間を与える。ブラックリスト登録はタイムロックから除外すべきである点に注意してほしい。資産を凍結する裁判所命令を受け取った場合、即座に行動する必要がある。

リエントランシー対策

標準的なERC-20の転送はリエントランシーの脆弱性を生まない(外部コントラクトを呼び出さないため)が、DeFiプロトコルとの連携、コールバックパターン、外部システムとの統合には、OpenZeppelinのReentrancyGuardを使用すべきである。信頼できない外部コントラクトとやり取りする関数にはnonReentrant修飾子を適用すること。

ブロックチェーンプラットフォームの選定

規制戦略を定義し、ステーブルコインのモデルを選び、スマートコントラクトのアーキテクチャを設計したら、もう一つ基礎的な決定が残っている。それは、実際にどこでこれを動かすのかということだ。

ブロックチェーンインフラの選択は、ステーブルコインの機能、コスト、市場リーチを根本的に左右する。1年前であれば、この決定は一握りの汎用チェーンから選ぶことを意味していた。今日では、その状況は専門化された選択肢へと分裂している。Stripe、Circle、Tetherといった大手による、ステーブルコイン専用のL1も含まれる。各プラットフォームはトランザクションコスト、スループット、エコシステムへのアクセス、規制上の位置づけにおいて異なるトレードオフを持つため、まずどこでローンチするかを見極めるためのデューデリジェンスを行いたいところだ。

単一のチェーンでローンチすることを選ぶ場合もあるが、多くの成功したステーブルコインの実態はマルチチェーン展開である。例えば、USDCは30以上のチェーンで稼働しており、PaypalのPYUSDはEthereum、Solanaにまたがり、まもなくStellarとStableにも広がる予定だ。

新しくステーブルコインを構築する場合、取るべきアプローチはおおむね次のようになるだろう。

コアとなるユースケースに合った1つの主要チェーンでローンチする。
そのチェーン上で運用手順とセキュリティプラクティスを確立する。
ユーザーの需要と戦略的価値に基づいて、二次的なチェーンへ拡大する。
クロスチェーン転送にはブリッジングプロトコル(CCTP、Wormhole NTT、LayerZero)を使用する。

自前構築か既製サービスか:ホワイトラベルの判断

ステーブルコインインフラ市場は劇的に成熟してきた。規制準拠のプロバイダーは今や、すでにコンプライアンスの枠組みが整った、数年ではなく数か月で市場投入できるターンキーの発行サービスを提供している。問題は、ホワイトラベルソリューションに能力があるかどうかではなく、自身の特定の要件がカスタム開発を正当化するかどうかだ。

技術的な複雑さを軽減し、より早く市場に出したい開発者向けに、以下を含む複数のソリューションが利用可能だ。

Paxos

Paxosは、市場で最大級のステーブルコインの一部を支えるインフラだ。PYUSD(PayPal)、BUSD(Binanceとのパートナーシップが終了する前)、そしてPaxos自身のUSDPがある。NYDFS、MAS(シンガポール)、FIN-FSA(アブダビ)からライセンスを取得しており、取得に何年もかかったグローバルな規制上のカバレッジを提供する。2025年11月のFordefi買収により、機関投資家向けウォレットインフラが提供に加わり、より完全なスタックが実現した。

Paxosはまた、パートナーが容易に統合できるようGlobal Dollar Networkの取り組みも立ち上げており、準備金管理、コンプライアンス、規制要件についてはPaxosに任せられるようにしている。

Coinbase Custom Stablecoins

Coinbaseは2025年12月、ホワイトラベルのステーブルコインソリューションであるCoinbase Custom Stablecoinsを立ち上げ、パートナーがUSDCを裏付け担保としてブランド化したステーブルコインを発行できるようにした。このモデルは巧妙で、新しい準備金管理インフラを構築する代わりに、Coinbaseは事実上USDCにカスタムブランディングを施してラップしている。パートナーは、独自のブランドアイデンティティを維持しながら、USDCの流動性とコンプライアンス上のメリットを享受できる。

CoinbaseはOCCのチャーターを申請しており、これが実現すればステーブルコイン活動に対する直接的な連邦規制の対象となる可能性がある。既存の取引所インフラは即座に流動性ソリューションを提供し、ブランド化されたステーブルコインは初日からUSDC/USDの取引ペアを活用できる。カストディインフラ(Coinbase PrimeおよびCoinbase Custodyを通じて)はすでに機関投資家グレードだ。

Brale

Braleは、マルチチェーンでの展開能力を伴う、より速い市場投入時間に焦点を当てている。PaxosやCoinbaseが規制上の実績や機関投資家との関係を強調するのに対し、Braleはカスタマイズ性と柔軟性を強調する。同社のプラットフォームは複数のチェーンへの同時デプロイをサポートし、トークンの機能やコンプライアンスルールについてより高い構成可能性を持つ。

カスタム開発を選ぶべき場合

ホワイトラベルソリューションは、利便性と引き換えに管理権限を犠牲にする。このトレードオフはほとんどの開発者にとって理にかなっているが、追加のコスト、時間、複雑さをかけてでもカスタム開発をする価値があるシナリオも存在する。

プロバイダーがサポートしていない独自の安定化メカニズム(アルゴリズム的な要素、新しい担保タイプ、利回りを生む構造)が必要な場合、共有インフラでは希薄化してしまう独自技術による戦略的差別化が求められる場合、地理的・規制的要件がプロバイダーの能力を超える場合(一部の管轄区域では現地インフラが求められることがある)、長期的なコスト経済性が規模が大きくなるにつれて自社インフラを有利にする場合(流通額100億ドル超では計算が変わる)、あるいはプロバイダーがサポートできない、またはサポートしないカスタムのコンプライアンスやガバナンス機能が必要な場合には、カスタム開発を検討してほしい。

中核となる発行にはホワイトラベルを使いつつ、独自の流通層とアプリケーション層を構築するというハイブリッドなアプローチが、多くの場合最良のバランスを提供する。準備金管理と規制コンプライアンスはPaxosやCoinbaseに任せ、自身は製品を差別化するユーザー体験、統合、機能に集中するというやり方だ。

結論

2026年にステーブルコインを構築するということは、わずか2年前とさえ根本的に異なる状況を乗りこなすことを意味する。GENIUS ActとMiCAを通じて規制上の明確性がもたらされ、定義されたパスウェイと同時に明確な要件も生まれた。技術的なパターンは、実戦で鍛えられたアーキテクチャと監査済みのライブラリとともに、十分に確立されている。戦略上の問いは、ステーブルコインが主流の採用を達成するかどうかではなく、数兆ドル規模へとスケールしていく市場に向けてどう自らを位置づけるかだ。

成功する開発者は、技術的な卓越性と規制上の高度な理解を組み合わせるだろう。彼らはインフラを慎重に選び、初日からコンプライアンスをアーキテクチャに組み込む。規制遵守が負担ではなく競争優位であることを認識しながら。

インフラのパートナーを探しているだろうか?Alchemyは、USDCやPYUSDから主要なL1/L2ネットワークまで、業界トップのステーブルコイン、発行者、チェーンを支えている。ノードインフラ、Token API、マルチチェーン展開のいずれが必要であっても、スタックのあらゆるレベルとやり取りしながらステーブルコインを市場に投入できる。会話を始めるには営業チームに問い合わせること。

よくある質問

ステーブルコインの主な種類は?

ステーブルコインは3つのカテゴリーに分かれる。法定通貨担保型(USDのような伝統的な通貨で担保される)、暗号資産担保型(過剰担保を伴うデジタル資産で裏付けられる)、そしてアルゴリズム型(自動化された供給調整を用いるが、現在ではおおむね規制対象市場から除外されている)だ。

ステーブルコインを構築するにはどのブロックチェーンを選ぶべきか?

セキュリティ、分散性、パフォーマンス、そしてターゲットとするユースケースに基づいてブロックチェーンを選ぶこと。成功しているほとんどのステーブルコインは複数のチェーンに展開しており、1つの主要チェーンから始めて、ユーザーの需要と戦略的価値に基づいて拡大していく。

法定通貨担保型ステーブルコインはどのようにペッグを維持するのか?

ペッグは裁定取引によって維持される。トークンが1ドルを下回って取引されると、裁定業者が安く買い、発行者から1ドルで償還することで、価格をペッグへと押し戻す。すべてのトークンは、準備金口座にある同額のドルによって裏付けられている。

ステーブルコインのスマートコントラクトに組み込むべきコンプライアンス機能は何か?

GENIUS ActやMiCAのようなグローバルな規制枠組みでは、凍結、差し押さえ、クローバックの能力を初日からコントラクトに組み込むことが求められる。これらはオプション機能ではなく、発行のための法的な前提条件だ。

ステーブルコインの準備金証明(proof of reserves)はどのように機能するのか?

準備金証明は、暗号学的検証とオラクルデータを用いて、オフチェーン資産によるトークンのリアルタイムでの1:1の裏付けを示すものであり、定期的な監査を超えて、継続的な支払能力の検証へと移行する。

自分でステーブルコインを作ることはできるか?

可能だが、規制上のライセンス取得、スマートコントラクト開発、銀行との関係、コンプライアンスインフラ、そして準備金のための相当な資本を乗り越える必要がある。PaxosやCoinbaseのようなプロバイダーによるホワイトラベルソリューションは、より速い市場投入への道を提供する。

ステーブルコインのスマートコントラクトにおけるセキュリティ要件とは?

本番環境のステーブルコインには、複数の独立したセキュリティ監査、重要な不変条件の形式的検証、特権的な操作に対するマルチシグ制御、そしてコントラクトの挙動に対する継続的な自動監視が必要となる。

ホワイトラベルソリューションを使うべきか、それともカスタム構築すべきか?

PaxosやCoinbaseのようなプロバイダーによるホワイトラベルソリューションは、コンプライアンスが組み込まれた、より速い市場投入を提供する一方で、管理権限を犠牲にする。独自のメカニズム、独自技術、あるいはプロバイダーがサポートしない機能が必要な場合にのみ、カスタム構築を行うこと。

なぜアルゴリズム型ステーブルコインは推奨されないのか?

GENIUS Actはアルゴリズム型ステーブルコインを明示的に除外し、MiCAは準備資産を要求し、Terra/Lunaの崩壊はこのモデルの信頼を根本的に失墜させた。これらは規制対象の決済レールや機関投資家による採用への道にアクセスできない。

暗号資産担保型ステーブルコインはどのように機能するのか?

ユーザーは100%を超える比率(通常150%)で暗号資産を担保として預け入れ、担保比率までステーブルコインを発行できる。担保価値が最低しきい値を下回ると、清算人が割引価格の担保と引き換えに負債を返済する。

Alchemy Newsletter

リリース情報をいち早く受け取る

ニュースレターに登録する

Alchemyの最新のプロダクト情報とリソースをお届けします

80,000人以上が購読中

メールアドレスを入力すると、当社のマーケティング情報およびプロダクト最新情報の受信に同意したことになります。Alchemyが受け取った情報をプライバシー通知に従って取り扱うことに同意するものとします。購読はいつでも解除できます。

お知らせ

Glamsterdam: Ethereum開発者のための完全ガイド

GlamsterdamはSepoliaで稼働中です。開発者にとって何を意味するか、Alchemyがネットワークアップグレードにどう備えたかをまとめた完全ガイドです。

金融

トレーディングチームが低レイテンシーRPCにAlchemyを選ぶ理由

トレーディングチームがAlchemyを選ぶのは、市場が動くときの低レイテンシーな読み取りと書き込み、そして出来高のピーク時でも資金が決済される際の信頼できる記録のためだ。

技術

東京で構築するなら、どのRPCプロバイダーを選ぶべきか

東京を提供するRPCプロバイダー5社を、5つのチェーンでベンチマークした。比較結果と、レイテンシに敏感なチームにとって差が出るポイントを示す。

2026年版:ステーブルコインの作り方

新たな規制の現実

開発者にとっての意味

銀行のためのデジタルアセット

ステーブルコインのモデルを選ぶ

法定通貨担保型ステーブルコイン

仕組み

経済性

運用上の要件

事例

このモデルを選ぶべき場合

暗号資産担保型ステーブルコイン

仕組み

ガバナンス

ペッグの安定性

事例

このモデルを選ぶべき場合

アルゴリズム型ステーブルコイン

(理論上の)仕組み

terra/lunaの崩壊

規制上の扱い

このモデルを選ぶべき場合

技術アーキテクチャの詳細

コアとなるスマートコントラクト

Base token implementation

ブラックリストの実装

一時停止機能

高度なコンプライアンス機能

クローズドループシステム向けのホワイトリストモード

クローバック機能

暗号資産担保型システム向けのオラクル連携

マルチシグとタイムロック

セキュリティ上の考慮事項

アクセス制御のチェックリスト

監査要件

継続的な監視

マルチシグ要件

リエントランシー対策

ブロックチェーンプラットフォームの選定

自前構築か既製サービスか:ホワイトラベルの判断

Paxos

Coinbase Custom Stablecoins

Brale

カスタム開発を選ぶべき場合

結論

よくある質問

ステーブルコインの主な種類は?

ステーブルコインを構築するにはどのブロックチェーンを選ぶべきか?

法定通貨担保型ステーブルコインはどのようにペッグを維持するのか?

ステーブルコインのスマートコントラクトに組み込むべきコンプライアンス機能は何か?

ステーブルコインの準備金証明(proof of reserves)はどのように機能するのか?

自分でステーブルコインを作ることはできるか?

ステーブルコインのスマートコントラクトにおけるセキュリティ要件とは?

ホワイトラベルソリューションを使うべきか、それともカスタム構築すべきか?

なぜアルゴリズム型ステーブルコインは推奨されないのか?

暗号資産担保型ステーブルコインはどのように機能するのか?

Alchemy Newsletter

ニュースレターに登録する

関連記事

Glamsterdam: Ethereum開発者のための完全ガイド

トレーディングチームが低レイテンシーRPCにAlchemyを選ぶ理由

東京で構築するなら、どのRPCプロバイダーを選ぶべきか