ステーブルコインがデペッグしたら｜財務担当の初動と売却・償還・保有の判断

2023年3月、USDCの発行体Circleが公表しました。Silicon Valley Bankに置いていた33億ドルが、USDC準備金の約8%にあたる、という内容です。市場ではUSDCの価格が1ドルから離れました。

その後Circleは、この預金が使えるようになるという当局の発表を受け、1対1の償還を続けると説明しています（Circle公式発表、2023年3月12日）。

このとき、USDCを事業資金や支払いの原資として持っていた会社の財務責任者は、次のことに迷ったはずです。

• 今すぐ売るべきか。売るなら、実際にいくらで売れるのか
• 発行体で額面どおりに償還できるのか。手元のUSDCは、発行体が受け付ける正式なものか
• 明日の支払いに、このUSDCを使ってよいのか

市場の価格は1ドルから離れた一方で、発行体は1対1の償還を続けると説明しました。この事例が示すのは、市場の価格、準備資産に手が届くか、銀行の営業時間、発行体での償還が、それぞれ別の状態だということです。取引所の価格だけを見て慌てて売ると、償還できたはずのものを安く手放すことになりかねません。

そこで、ステーブルコインが1ドルや1円から離れたときの対応は、3段で進めます。まず自動の支払いや運用を止める。調べている間も自動の処理が動き続けると、損失が広がったり、同じ処理が二重に走ったりするからです。次に、市場の価格、償還できるか、トークンの種類、実際に売れる量を調べる。そして、売る・償還する・交換する・持ち続けるを比べ、承認した範囲だけを動かします。

以下は、この流れを警報から再開まで追う運用手順書（ランブック）です。財務責任者、システム設計者、運用担当者に向けて書いています。DeFiの担保に入れている場合の話も途中で扱います。主に法定通貨担保型のステーブルコインを念頭に置いています。基礎から確かめたい場合はステーブルコインの基礎とステーブルコインの仕組み・種類・日本市場を先に読むと、流れがつかみやすくなります。

何が起きたら警報を出すか

取引所の1つの価格は、その取引所で最後に成立した価格にすぎません。財務部門（トレジャリー）が実際に回収できる額は、次のことでも変わります。

• 発行体へ額面で償還できるか
• 持っているチェーンとコントラクトが、正式に対応しているか
• 売りたい量を売ったとき、いくらになるか

そこで監視では、次の4種類の信号を別々に記録します。

警報は、価格のずれ幅、続いている時間、実際に売れる量、償還できるか、いくつの価格源で確かめたか、の組み合わせで出します。

「1%乖離」のような数値は、全社共通の安全基準ではありません。次のことから、平時に決めておきます。

• 保有の目的と、どこまで損失を許せるか
• 普段の市場の揺れ幅と、支払いの期限
• 担保として使っているなら、清算される水準

データが欠けたときや、価格源どうしの値が食い違うときも、警報の対象にします。

バーゼル銀行監督委員会の暗号資産基準（2026年1月1日適用）は、安定化の仕組みが意図どおり働いているかを監視する体制を求めています。準備資産の構成、評価の頻度、データの十分さ、ストレス時の償還能力を評価する考え方です（Basel Framework SCO60）。

銀行向けの基準を、一般企業にそのまま当てはめるわけではありません。ただ、「価格だけで健全かどうかを判断しない」設計の根拠として使えます。

対応を7つの段階に分ける

対応には、気づいた直後に資産を守る動きと、原因を確かめた後に資産を動かす動きがあります。この2つは別の段階です。そのため「平常か緊急か」の2つでは粗すぎます。止めることと、資産を動かすことも、同じ操作にはしません。

段階ごとに、進む条件、できる操作、承認者、戻る先を決めます。

各段階で戻る・止める条件と、システム上の状態名は、後半の「技術担当と決めておくこと」にまとめました。

最初の15分：自動の支払いを止め、残高を記録する

初動の目的は、底値を当てることではありません。意図しない損失の広がりと、同じ処理の二重実行を止めることです。担当者は次の順で動きます。

1. 警報を確かめる：価格の取得時刻、銘柄記号、チェーン、トークンのコントラクト、見積の基準通貨、情報源を確かめます。複数の市場で計算し直します。
2. 自動処理を止める：新規受入、支払、定期購入、利回り運用、担保追加、リバランス、ブリッジを止めます。承認済みで実行を待つ処理も、1つずつ止めます。読み取りと監視は続けます。
3. 残高を一斉に記録する：ウォレット、カストディ、取引所、DeFiのポジションを、同じ基準時刻で保存します。未確定のトランザクションと、未処理の売掛・買掛も含めます（スナップショット）。
4. 必要な資金を切り分ける：給与・仕入・顧客への払戻しなどの期限と通貨を書き出します。投資・運用の残高とは混ぜません。
5. 情報の出どころを1つにする：指揮者、財務の執行、技術、経理、法務・広報の窓口を決め、次の更新時刻を知らせます。

止めるための権限が1つの鍵に集まっていると、困ったことになります。停止APIや、スマートコントラクトの一時停止（pause）の権限です。鍵が盗まれたときや、担当者がいないとき、手順が動きません。

権限は、次のように分けておきます。

• 通常の資産移動、緊急停止、方針変更を別々の権限にする
• 監視設定とログ削除の権限も分ける
• 止めるのは少人数で速く、再開と資産移動は複数の承認で

売る・償還する・持ち続けるを、手元に残る額で比べる

市場価格が0.98ドルでも、選べる道は会社によって違います。発行体で1ドルで償還できる会社もあれば、二次市場でしか売れない会社もあります。USDCは、発行体が1対1でのドル償還を掲げています（Circle Docs: What is USDC?）。

比べるのは額面ではありません。かかる時間と失敗の確率も入れた、回収の見込み額です。

回収できる額 ＝ 売却額 − 手数料 − ガス代 − 価格滑り − 為替コスト − 失敗したときの損失見込み

道ごとの選べる条件と、よくある失敗は次のとおりです。

DEX交換の行にあるサンドイッチ攻撃は、取引の前後に他人の売買を差し込まれ、不利な価格で約定させられる攻撃です。MEV対策は、こうした取引の順番を操作されることから守るための対策です。

どの道でも、まず少額で試します。確かめることは次のとおりです。

• 保有継続：監視と上限が実際に働くか。
• 発行体償還：少額のburn（焼却）・送付、受付ID、銀行への着金。
• CEX売却：入庫の反映、指値の約定、出金。
• DEX交換：見積と実際の約定の差、最低受取額（minimum received）、残高の突き合わせ。
• 別チェーンへ移動：コントラクト、チェーン、burn/mint（焼却と発行）、到着した残高。

動かす前に、手元のトークンの種類を確かめる

同じ「USDC」という表示でも、中身は3種類あり得ます。発行体が直接発行したネイティブのUSDC、ブリッジで別チェーンに発行したラップ資産、取引所の中の残高です。それぞれ、回収の道が違います。

そのため資産台帳では、銘柄記号ではなく、発行体・チェーン・コントラクト・トークンの種類の組み合わせで見分けます。発行体の対応チェーンとコントラクトアドレスは、カストディや取引所の入出庫対応とは別に確かめます。

CircleのCircle Mint資料は、対応外のトークンを送らないよう明記しています。USDTやブリッジ経由のUSDCなどです。同じエコシステムでも、特定の層や経路だけを受け付ける場合があるとしています（Circle Supported Chains and Currencies）。「同じ銘柄だから発行体へ送れば償還できる」と判断してはいけません。

別のチェーンへ移しても、価格のリスクは消えません。むしろ、ブリッジ・証明者（attester）・確定・宛先チェーンのリスクが加わります。

緊急時に初めての道を使うのは避けます。平時から、次のことを試しておきます。

• 許可するコントラクトの一覧と最大額
• 対応チェーン
• 障害のときの返金手順

発行体をまたぐ交換の設計は複数発行体ステーブルコインの相互運用設計で詳しく扱っています。

DeFiで使っているなら、売る前に清算までの余裕を見る

ステーブルコインを、DeFiの担保、借入、流動性プール、ボールトの中身として使っている場合は事情が違います。プロトコルの中のポジションは、ウォレットの残高を売っても、そのまま残るからです。

ポジションごとに、次のことを記録します。

• 担保の価値を決めるオラクル、清算閾値、借入資産
• 引き出せる額、待機期間（クールダウン）、プール内の比率
• 管理者による一時停止、依存する別のステーブルコイン

対応する順番は、次の4つで決めます。

1. 清算までの余裕
2. 顧客資産と支払いの義務
3. 解除に必要なトランザクションの数と時間
4. 実行したときの市場への影響

担保を足せば清算は遅らせられます。ただ、問題の資産をかえって多く抱えることもあります。

自動化するなら、価格がある値を割ったら即座に交換する、という作りは避けます。まず警報の段階へ移り、追加のデータを確かめ、上限付きの提案を出し、複数で承認します。清算閾値の監視と通知の設計はDeFiポジション監視と清算リスク対策を参照してください。

BIS Innovation Hubとイングランド銀行のProject Pyxtrialは、準備資産と発行残高をほぼリアルタイムに監視する必要を示しています。急な償還の需要を追うためです（Project Pyxtrial最終報告、2024年7月）。

ステーブルコインを持つ企業の財務部門も、トークンの価格だけを見ていては足りません。自社のポジションと、償還の道がどれだけ混んでいるかを、合わせて見る必要があります。

動かすときは、二者承認と少額の試しから

緊急時の権限は、統制を省いてよい権限ではありません。

提案する人は、次の項目を申請します。対象資産と数量、経路と宛先、見積と最低受取額、有効期限、許容する損失、止める条件です。別の承認者は、トークンのコントラクト、チェーン、宛先、権限設定の版を確かめます。署名する人は、承認されたデータのハッシュと、実際のトランザクションを突き合わせます。

最初の試しは、業務上意味のある最小の額で行います。発行体、取引所、DEXのどれでも同じです。APIの応答だけで成功とはしません。オンチェーンでの確定、取引所の残高、銀行への着金、会計帳簿まで追いかけます。

試しがうまくいっても、一度に全部は動かしません。1回の上限、時間あたりの上限、累計の上限を決めて、分けて動かします。

緊急時の権限は、平時の財務統制とつなげておきます。方針の版管理、職務分離、鍵管理、三者照合（帳簿・保管先の記録・オンチェーンの残高の突き合わせ）の基礎は企業のデジタル資産保有と内部統制で整理しています。カストディ方式と、保管先からの退出テストは機関投資家向け暗号資産カストディ設計で詳しく扱っています。

いつ再開してよいか

価格が1ドルに戻っても、償還待ちの行列、入出庫の停止、チェーンの障害、残高の食い違いが残っていることがあります。そのため、価格の回復だけでは通常運用に戻せません。再開の申請には、次のものを添えます。

• 複数市場の買値・売値、実行可能な流動性、観測期間、データ欠損の有無
• 発行体の最新の告知、償還の試験結果、対応チェーン・コントラクト、銀行または取引所への着金結果
• ウォレット、カストディ、取引所、DeFi、帳簿の残高の突き合わせと、まだ解けていない差
• 終わっていない支払・受入・注文・トランザクションの処理結果
• 試し実行の申請、承認、署名対象、約定、手数料、費用控除後の回収額
• 顧客・取引先への影響、通知内容、残る制限、次回の更新

再開は、次の順で少しずつ進めます。

1. 監視
2. 読み取りだけの照会
3. 少額の受入
4. 少額の支払
5. 制限付きの自動処理
6. 通常の上限

どの段階でも、価格のずれ、償還の遅れ、残高の食い違い、チェーンやカストディの停止が出たら、前の段階へ戻します。

平時に確かめておく12項目

1. 資産を、発行体、チェーンID、コントラクト、トークンの種類で見分けている。
2. 価格、実際に売れる量、償還、基盤の健全性を、別々に監視している。
3. 警報のしきい値に、続いている時間、情報源の数、データが欠けたときの条件がある。
4. 受入、支払、運用、担保、ブリッジを、1つずつ止められる。
5. 停止、資産移動、方針変更、ログ管理の権限が分かれている。
6. すべての保管先とDeFiのポジションを、同じ基準時刻で記録できる。
7. 発行体償還、CEX、DEX、別チェーンの実行上の制約を、定期的に試している。
8. 見積の有効期限、最低受取額、1回・時間あたり・累計の上限がある。
9. タイムアウトの後は状態を照会し、反映されていないと確かめる前に送り直さない。
10. 給与、仕入、顧客への払戻しなどに要る資金を、別の資産で確保している。
11. 再開の条件に、市場価格だけでなく、償還・着金・残高の突き合わせが入っている。
12. 机上演習と少額の試しを行い、連絡先と承認者を更新している。

よくある質問

何%の乖離で止めるべきですか？

全社共通の正解の数値はありません。保有目的、損失許容度、平時の価格の揺れ幅、支払期限、担保の清算点から平時に決めます。警報の条件には、価格のずれ幅に加えて、続いている時間、情報源の数、償還の停止、データ欠損を組み合わせます。警報は「売る」判断ではありません。「止めて確かめる」段階へ移る合図として扱います。

価格が戻ったらすぐ再開してよいですか？

価格の回復だけでは再開しません。償還の受付、入出庫、チェーンやカストディの稼働、残高の突き合わせ、終わっていない処理の結果を確かめます。そのうえで、読み取りだけの照会から少額の受入・支払へと、段階的に戻します。途中でまた乖離や食い違いが出たら、前の段階へ戻します。

技術担当と決めておくこと

ここからは、監視・停止・執行の仕組みを作る技術担当と、財務責任者がすり合わせておく内容です。

信号ごとの確認先と、警報に使う値

• 市場価格：独立した価格源、各市場の板・プール
• 実際に売れる量：見積API、オンチェーンでの試算、取引所の稼働状況
• 償還の道：発行体の稼働状況ページ・技術文書・契約窓口
• 資産・基盤の健全性：発行体の一次情報、チェーン、保管先

警報には、例えば price_deviation_bps、duration_seconds、executable_depth、redemption_status、source_count を使います。bpsは、ずれ幅をベーシスポイントで表したものです。

7つの段階の状態名と、戻す・止める条件

記録の結び付けと、二重実行の防止

incident_idに、次のものを結び付けます。価格の観測値、残高、未完了の支払、担保、承認、見積、注文・償還ID、トランザクションハッシュ、会計仕訳です。

APIのタイムアウトは、失敗と決めつけません。同じ冪等キー（同じ依頼を何度送っても1回分しか処理しないための識別子）で状態を照会します。反映されていないと確かめずに送り直すと、二重売却や二重償還につながります。

回収額の式と、資産の識別子

net_proceeds = gross_amount - fee - gas - slippage - FX_cost - expected_failure_loss

式の net_proceeds は費用控除後の回収額、expected_failure_loss は実行が失敗したときの損失の見込みです。

資産台帳の識別子は issuer + chain_id + contract_address + representation（発行体・チェーン・コントラクト・トークンの種類）です。

再開の各段階で前へ戻す条件

price_deviation、redemption_delay、reconciliation_break、chain_or_custody_unavailable を、前の段階へ戻す条件にします。

関連記事

• 企業財務のDeFi運用ポリシー｜利用上限・承認・停止・資金回収
• アルゴリズミック型ステーブル失敗事例｜Terra/Luna 崩壊の構造
• Health Factor と清算ボット｜清算の仕組みと事業化

XTELAができること

私たちは、価格・オンチェーン・カストディ・業務データをつないだ乖離の監視、状態管理、二者承認のワークフロー、少額の試し実行、残高照合、監査ログを設計・開発します。貴社の保有先と支払業務に合わせた7状態の手順を、机上演習とPoC（概念実証）で動く形にするところから始められます。進め方はお問い合わせからご相談ください。

主要参考資料

• Basel Committee on Banking Supervision: SCO60 Cryptoasset exposures（2026年9月24日確認）
• BIS Innovation Hub: Project Pyxtrial – Monitoring the backing of stablecoins（2026年9月24日確認）
• Circle: $3.3 Billion of USDC Reserve Risk Removed, Dollar De-peg Closes（2023年3月12日）
• Circle Docs: What is USDC?（2026年9月24日確認）
• Circle Docs: Supported Chains and Currencies（2026年9月24日確認）

資料の確認日と注意：一次資料は上の各資料に記した日に確認しました。一般的な技術・業務設計の解説であり、投資・法務・税務・会計の助言ではありません。実行時点の一次情報を確認し、必要に応じて専門家に相談してください。