発行体の違うステーブルコインを交換するには｜4つの方式と失敗時の戻し方

ある決済事業者が、アプリで複数の円建てステーブルコインを扱おうとしています。発行体A社のコインも、B社のコインも、利用者には1つの残高のように見せたい。支払先がB社のコインしか受け取らなければ、アプリの中でA社のコインをB社のコインに替えて払う、という使い方です。

画面の設計は難しくありません。困るのは、交換が途中で失敗したときです。

• A社のコインは引き落とされたのに、B社のコインが届かない。
• 通信が切れてアプリが依頼を送り直し、同じ交換が2回実行される。

利用者から見れば、どちらもお金が消えたか、二重に動いたかです。しかも、確定したチェーン上の取引は、データベースのように取り消せません。

ここで思い出したいのは、コインが誰の約束なのかです。円建てのコインを円に戻す（償還する）約束をしているのは、それを発行した会社です。つまりコインは、発行した会社の債務（借り）です。同じ1円でも、発行体が違えば別の会社の債務なので、同じ資産ではありません。

そのため交換の方式は、途中で誰が資金と信用のリスクを引き受けるかで選びます。また、チェーン上の取引は取り消せないので、1件の交換は段階ごとに記録し、失敗したら逆向きの取引で埋め合わせます。

日本でも動きがあります。金融庁のFinTech実証実験ハブでは、みずほ銀行・三菱UFJ銀行・三井住友銀行による共同発行の実証が支援されました（金融庁「FinTech実証実験ハブ・決済高度化プロジェクト」）。3行は2026年6月10日、共同発行コインの実取引を2026年度中に始めることをめざす方針を出しています。運営・ガバナンスを共同で検討する協議会も設けました（3行の共同発表）。複数の発行体のコインが並べば、冒頭の決済事業者と同じ問いが日本でも現実になります。

ただ、2026年9月24日時点で、別の発行体のコイン同士をどうつなぐかの仕様は公表されていません。以下は特定プロジェクトの仕様を推測したものではありません。一次資料と決済システムの原則から組み立てた設計です。

この記事でわかること

• 同じ通貨のコインでも、発行体ごとに分けて扱う理由
• 交換の4つの方式と、それぞれで誰がリスクを持つか
• 二重に動かないためのルール、失敗時の埋め合わせ方、PoCの合格条件

ステーブルコインの仕組みや種類の基礎はステーブルコインとは？仕組み・種類・日本市場の最新動向で解説しています。

同じ「1円」のコインは、なぜ同じ資産ではないのか

銀行預金なら、他行から振り込まれた1円を「どの銀行の1円か」と気にせず使えます。BISのエルナンデス・デ・コス総支配人は、2026年4月20日の日本銀行での講演で、マネーに要る性質を2つ挙げました（BIS講演「Stablecoins: framing the debate」2026年4月20日）。

• 単一性：形の違うマネーが、金融機関をまたいで額面どおりに完全に置き換えられること
• 相互運用性：利用者が基盤やネットワークをまたいで、確定性をもってお金を送受信できること

BISは2025年の年次経済報告第3章でも、ステーブルコインは3つの試験を満たさないと評価しています。単一性、弾力性（需要に応じて供給を伸び縮みさせられること）、健全性（不正や犯罪に使われにくいこと）です（BIS Annual Economic Report 2025 第3章）。ステーブルコインでは、単一性と相互運用性は自然には生まれません。

さきほどの決済事業者が分けて扱うべきものは、3つあります。

そのため、コインを記号や表示名だけで見分けてはいけません。少なくとも次の6つの組み合わせで資産を見分けます。通貨、発行体、商品、チェーン、コントラクト、約款の版です。

似た話に、同じコインを別のチェーンへ移す仕組みがあります。CircleのCCTPはその一つです。送信元のチェーンでUSDCを焼却（burn）し、Circleの署名付き証明（attestation）を経て、送信先のチェーンで発行（mint）します。流動性プールやラップトークンは使いません（Circle CCTP公式Docs）。

ただし、これが動かすのは同じ発行体・同じ銘柄だけです。A社の円建てコインをB社の円建てコインに替える仕組みではありません。同じ資産を複数のチェーンへ広げるときの総供給量の管理は、トークン化資産のマルチチェーン設計で扱っています。

交換の4つの方式は、誰がリスクを引き受けるかで選ぶ

4つの方式の違いは、画面やAPIにはありません。交換の途中で誰が相手方のリスク・資金・障害対応を引き受けるかが違います。なお、どの方式でも、額面が同じだからといって無条件に1:1で交換する作りにはしません。理由は、後の「額面が1:1でも、交換価格が1:1とは限らない」で説明します。

共通台帳＋アトミックスワップ

複数の発行体のコインを同じ台帳に載せます。2つの資産の引落しと受渡しを、同じトランザクションで行います。

• 強み：片側だけ完了するリスクを抑えられる。監視や本人確認の情報もそろえやすい
• 弱み：台帳の障害が、全員の障害になる。1:1の価格と償還の力は、別に裏付けが要る
• 向く場面：発行体どうしが、共通の台帳・ガバナンス・稼働時間に合意できる

発行体間のburn/mint

A社のコインを焼却するか償還として受け付けます。発行体どうしで資金を決済した後、B社がコインを発行します。

• 強み：ラップした資産を増やさない。最後に誰の債務になるかがはっきりする
• 弱み：チェーン上の処理と銀行側の資金決済を、完全に一度の処理にはできない。発行体どうしの限度額・突き合わせ・埋め合わせの取り決めが要る
• 向く場面：発行体どうしの契約と日中の資金、共通のメッセージ仕様を持てる

マーケットメーカー

流動性を出す会社がA社のコインを受け取り、手元のB社のコインをすぐに払い出します。在庫は後で配り直します。

• 強み：発行体どうしがリアルタイムにつながっていなくても速い。価格を示せる
• 弱み：在庫切れ、スプレッド、相手の破綻、デペッグのリスクが、流動性を出す会社に集まる
• 向く場面：取引量が予測でき、複数の流動性提供者から競って見積りを取れる

ハブ／共通の決済資産

A社のコインをいったん銀行預金などの共通の決済資産に戻します。その資産でB社のコインを発行するか買います。2つの工程は、交換を仲立ちするシステム（ルータ）が束ねます。

• 強み：新しい発行体をつなぎやすい。発行体どうしを総当たりでつなぐ必要がない
• 弱み：ハブに集中する。円への払戻しに営業時間と手数料がかかる。2つの工程のあいだに価格と時間の差が出る
• 向く場面：今の銀行の決済網につなげ、ハブ運営者の責任と復旧計画を決められる

同じ台帳に載っていても、B社がA社のコインを償還する義務は生まれません。逆に台帳が違っても、発行体どうしの契約と十分な資金があれば交換は組めます。

まず決めるのは「どのチェーンを使うか」ではありません。受け取る人が最後にどの会社のコインを持ちたいか、誰が交換を引き受けるか、お金を最後にどこで確定させるかです。共通台帳での同時の受け渡しは、証券と資金の例で証券とステーブルコインのアトミックDvP設計に詳しく書いています。

1件の交換を、8つの段階で追う

方式が違っても、利用者に1つのAPIを出すための段階はそろえられます。1回の交換に、全体で一意の交換番号を付けます。呼び出す側にも、送り直しても二重に実行されないための依頼番号を付けてもらいます。そのうえで、次の8段階を順に記録します。

1. 受付：資産・金額・受取人を受け付ける
2. 審査済み：本人確認（KYC）・制裁・利用資格を判定する
3. 見積り済み：経路・価格・期限を固定する
4. 予約済み：出す側のコインの在庫と限度を押さえる
5. 送信元が確定：A社のコインの引落しが確定する
6. 決済中：交換と、発行体どうしの決済を進める
7. 受取側が確定：B社のコインの発行・送付が確定する
8. 突き合わせ済み：3つの帳簿を突き合わせて完了する

本人確認の結果を「通過／不通過」だけにすると、発行体ごとに違う利用資格を表せません。判定の結果には、次の情報を持たせます。

• 誰が、いつ確認したか。対象の国と顧客区分
• 送る・受け取る・持つ・償還する、それぞれの可否
• 判定基準の版と、有効期限

B社がA社の判定をそのまま使う場合も、B社が受け入れられる属性と確かさの水準を契約で決めます。最終的に判断した会社も記録に残します。

FATFは2026年3月、ステーブルコインのリスクとして2つを挙げました。仲介者を通さないウォレット間の取引と、発行体の統制が届きにくいクロスチェーンの活動です（FATF Targeted Report）。本人確認の情報を渡し合うのは、便利さのためだけではありません。どの段階で誰が取引を止められるかまで、決めておく必要があります。

お金が二重に動かないために守る5つのルール

いちばん危ないのは、冒頭のような「片側だけ正しい」状態です。送信元が戻ったのに送信先が残る。同じ依頼を2回処理する。予約と実際の残高がずれる。次のルールは、自動テストと日々の突き合わせの両方で確かめます。

1. 送信元が確定する前に、送信先を確定しない：早く払うために仮に払い出すなら、立替え分として別の勘定にします。上限と、損をかぶる会社も決めます。
2. 1つの依頼番号から確定する取引は1件だけ：APIの再送、キューの再配信、ノードのタイムアウトが起きても、同じ交換をやり直しません。
3. 予約した残高と、使える残高を分ける：見積りが成立したら、出す側のコインを予約します。期限切れや失敗のときは、必ず予約を外します。
4. 金額の出入りを説明できるようにする：入った金額＝出た金額＋手数料＋スプレッド＋端数、が取引ごとに成り立つようにします。差額を雑収益などに紛れ込ませません。
5. 3つの帳簿を突き合わせる：チェーン上の残高、ルータの内部の補助簿、発行・償還や銀行決済の記録を、同じ交換番号で突き合わせます。

トランザクションハッシュ（チェーン上の取引番号）を得た時点では、まだ台帳での確定も、突き合わせも済んでいません。CPMI・IOSCO（決済と証券の国際基準をつくる機関）も、重要なステーブルコインの仕組みについて、次の点を明確にするよう求めています。ガバナンス、リスク管理の全体、決済の確定性、資金決済です（CPMI・IOSCO最終ガイダンス）。そこでこの設計では、ハッシュを得たことを「成功」とはしません。完了とみなすのは、3つがそろった時点です。各台帳の確定条件を満たし、受取人が使えるようになり、突き合わせが済んだ時点です。

額面が1:1でも、交換価格が1:1とは限らない

どちらも「1円」で償還できるコインでも、いつでも無制限に1:1で替えられるとは限りません。交換の経路には、次のものが乗るからです。

• 償還の受付時間、出す側の発行上限、チェーン上の手数料
• 在庫を持つコスト、発行体の信用、障害のリスク

FSB（金融安定理事会）の勧告も、1つの法定通貨を参照するグローバル・ステーブルコインについて求めています。利用者の法的な請求、適時の償還、額面での償還、安定化と健全性の要件を明確にすることです（FSB最終勧告）。交換をつなぐ層が、発行体ごとの償還の力を代わりに保証するわけではありません。

ルータは、取引の前に見積りを返します。レート、手数料、最低受取額、有効期限、経路、確定の見込みです。利用者が同意してから、初めて予約します。

画面に「1:1」と出してよいのは、条件がそろうときだけです。差額を運営者が負担する契約があり、在庫が十分にあり、上限を超えたら見積りを止める場合です。発行体別・チェーン別に、在庫、予約、日中の出入り、償還できる額を持っておきます。次のどれかが起きたら、自動で止めます。

• 出す側のコインの使える在庫が、安全のための余裕を下回る
• 市場価格か直接の償還価格が、決めておいた乖離幅を超える
• 発行体の発行・償還、本人確認の判定、台帳の監視のどれかが止まる
• 突き合わせの差が決めた件数・金額を超え、原因が分からない

価格が外れたとき、コインを持つ側がどう止め、償還・売却・交換を比べるかはステーブルコインのデペッグ対応にまとめています。

失敗したら、取り消さずに逆向きの取引で埋め合わせる

確定したチェーン上の取引は、データベースの取消しのようには消せません。段階ごとに、次のどれを行うかを決めておきます。再試行、予約の取消し、別の経路への切替え、返金、新しい逆向きの取引、手動での保留です。主な失敗と対応は次のとおりです。

障害のときに誰が責任を持つかも、先に決めます。

• 発行体：発行・凍結・償還と、商品の条件
• ルータの運営者：経路の選択、状態の管理、突き合わせ
• 流動性を出す会社：見積りと在庫
• 台帳・ブリッジの運営者：メッセージの伝達と確定性

発行体が償還を止めたからといって、ルータの運営者が技術障害として補償できるわけではありません。逆に、ルータが二重に実行したなら、発行体の準備資産の問題ではありません。ルータ側の実装の責任です。

日本で作るとき、どの機能が規制に当たるかを確かめる

資金決済法第2条第10項は、「電子決済手段等取引業」に当たる行為を並べています。電子決済手段の売買や、ほかの電子決済手段との交換がその一つです。その媒介・取次ぎ・代理や、他人のための管理等も含みます（e-Gov法令検索「資金決済に関する法律」）。「ルータ」と呼んだり、スマートコントラクトで作ったりしても、それだけで当たらなくなるわけではありません。

技術チームは、次の5つの問いの答えを、処理の流れの図（シーケンス図）とAPIの権限表にします。

1. 誰が利用者から注文を受けるか
2. 誰が秘密鍵と残高を管理するか
3. 誰が交換の条件を示すか
4. 誰が発行体へ償還を請求するか
5. 障害のとき誰が資金を返すか

登録・契約・会計・税務の判断は、この資料をもとに進めます。日本と米国の制度の違いはGENIUS Actと日本のステーブルコイン規制の違いで整理しています。送金元の入金から送金先の払出しまでをつなぐ作り方は、ステーブルコイン国際送金の実装設計で扱っています。

PoCでは、障害の後も帳尻が合うかを確かめる

AからBへ1回交換できるデモを見せても、つなぎ方の検証にはなりません。PoC（本番前の小さな試験）では少なくとも2つの発行体と2つの台帳を使います。次の測定と、わざと障害を起こす試験を合格条件にします。

• 受付から受取側の確定までの時間を、経路ごとに測れる（p50・p95・最大。p50は半分の交換が収まる時間、p95は95%が収まる時間）
• APIの再送とキューの重複を各100回以上起こしても、確定する取引が1件だけになる
• 送信先の停止、署名付き証明（attestation）の遅れ、ノードの切断、見積りの期限切れ、在庫切れを再現し、決めておいた埋め合わせの状態へ移る
• 1日の終わりに、チェーン上、内部の補助簿、発行・償還の記録の差が0で、全件を交換番号から追える
• 発行体別・チェーン別の在庫上限と損失上限を超える前に、自動で止まる
• 本人確認の情報の期限切れや、判定基準の版の食い違いを見つけ、出す側のコインを送る前に止める
• 運用担当が、保留中の1件について、原因・責任を持つ会社・次の処理・利用者への連絡を画面から判断できる

この条件を満たして初めて、4つの方式のどれが自社に合うかを比べられます。共通台帳、発行体間のburn/mint契約、マーケットメーカー、ハブへの接続です。比べる軸は、自社の取引量・稼働時間・リスクの許容度です。つなぐとは「多くのチェーンへつながること」ではありません。違う会社の債務を、確定性と責任の分担を失わずに受け渡せることです。

よくある質問

同じ円建てのステーブルコインなら1:1で交換できますか？

額面が同じでも、交換価格がいつも1:1になるとは限りません。発行体の信用、償還の受付時間と手数料、出す側の在庫、チェーン上の手数料が経路に乗るためです。画面で1:1と出すなら、差額を誰が負担するかを契約で決めます。在庫や乖離幅の上限を超えたら、見積りを止める仕組みも要ります。

CircleのCCTPを使えば、発行体の違うステーブルコイン同士を交換できますか？

できません。CCTPは、Circleが出すUSDCを送信元のチェーンで焼却し、送信先のチェーンで同じUSDCを発行する仕組みです。同じ発行体・同じ銘柄を、チェーン間で動かすだけです。A社のコインをB社のコインに替えるには、この記事の4方式のどれかを使います。そのうえで、誰が資金と信用のリスクを持つかを別に決めます。

実装する人向けの詳細

ここからは、さきほどの決済事業者でルータを作る開発チームの話です。

資産IDと、要素ごとに持つ情報

資産は、少なくとも currency + issuer_id + instrument_id + network_id + contract_address + terms_version を正規の資産IDとして持ちます。3つの要素ごとに、システムが持つ情報は次のとおりです。

8つの状態

1回の交換に全体で一意の transfer_id と、呼び出し側の idempotency_key（再送しても二重実行しないための一意キー）を付けます。状態は1から8の順に進みます。

5つのルールをコードで確かめる

• 1つの idempotency_key から確定取引は1件だけ。重複配信には、既存の状態を返す
• 金額の保存則は input = output + fee + spread + rounding を取引単位で検証する
• オンチェーン残高、内部補助簿、オフチェーン記録は同じ transfer_id で突合する

見積りで返す値

ルータは取引前に rate、fee、minimum_output、expires_at、経路、確定見込みを返します。利用者の同意後にだけ予約します。

関連記事

• ステーブルコインとは？仕組み・種類・日本市場の最新動向を徹底解説
• GENIUS Actと日本のステーブルコイン規制の違い｜2026年日米比較
• ステーブルコイン国際送金の実装設計｜為替・流動性・例外処理
• ステーブルコインのデペッグ対応｜停止・償還・売却・再開の手順
• 証券とステーブルコインのアトミックDvP設計｜同一台帳と別台帳

XTELAができること

XTELAは、複数発行体のステーブルコインをまたぐ交換の仕組みを、資産IDの設計、8状態の状態遷移、鍵と権限、在庫と停止条件の監視、3帳簿の照合、障害時の補償処理まで一続きで設計・開発しています。PoCでは正常系より先に、再送・重複・送信先の停止・在庫枯渇を注入して、帳尻が合うことを貴社の環境で確かめます。法的な判断は弁護士と連携して進めます。ステーブルコイン相互運用の設計について相談する

主要参考資料

• 金融庁: FinTech実証実験ハブ・決済高度化プロジェクト（複数銀行グループの共同発行実証）
• みずほ銀行・三菱UFJ銀行・三井住友銀行: 3行共同発行ステーブルコインの2026年度中の実取引の開始と共同で検討を進めるための協議会の設置について（2026年6月10日）
• 日本銀行: 技術革新と地政学リスクの下での通貨・決済システムの未来
• BIS: Pablo Hernández de Cos「Stablecoins: framing the debate」（2026年4月20日、日本銀行での講演）
• BIS: Annual Economic Report 2025 第3章「The next-generation monetary and financial system」
• CPMI・IOSCO: ステーブルコインの取決めへのPFMI適用に関する最終ガイダンス
• CPMI: Considerations for the use of stablecoin arrangements in cross-border payments
• FSB: Global Stablecoin Arrangementsに関する最終勧告
• Circle: Cross-Chain Transfer Protocol公式Docs
• FATF: Targeted Report on Stablecoins and Unhosted Wallets（2026年3月）
• e-Gov法令検索: 資金決済に関する法律

資料の確認日と注意

公表情報は2026年8月12日時点のものをもとにしています。3メガバンクの共同発行方針とBISの資料は、2026年9月24日に確かめ直しました。この日の時点で、異なる発行体のコイン同士をつなぐ仕様は公表されていません。3行の共同発行の商用仕様や参加者間の契約は推測していません。制度・製品仕様・対応ネットワークは変わり得るため、実装の前に最新の一次資料と、弁護士・会計士・税理士等の判断を確かめてください。