ステーブルコインで海外送金する仕組み｜為替・規制の確認・二重送金の防ぎ方

日本のある送金会社が、新しいサービスを始めようとしています。日本の企業がシンガポールの取引先へ代金を払うとき、その支払いを米ドル建てのステーブルコイン（USDC）で運ぶサービスです。取引先には、シンガポールの銀行口座へ現地通貨で届けます。

企画を任された事業責任者が流れを書き出すと、困る場面がすぐに見つかりました。日本の企業は円を払ったのに、シンガポールの取引先には現地通貨が届かない。見積りのレートが切れたのか、シンガポール側の資金が足りないのか、規制の確認で止まっているのか。チェーン上の送金だけを作っていると、誰の責任で止まったのかを説明できません。

通信が途中で切れたときも危険です。結果が分からないまま送り直すと、同じ代金が二重に出ていくおそれがあります。

しかもこの送金会社は、ただの仲介役ではありません。日本で送金の仕事をするには登録が要り、登録を受けた事業者として規制の確認を担う立場に立ちます。どこまでを自社が引き受け、どこをシンガポール側の事業者や、交換用の資金を出す会社に任せるのか。まずそれを決めなければ、止めるべき送金を誰も止められません。

では、このサービスを本番で事故なく動かすには、何をそろえればよいのか。短く答えると、円の入金から現地通貨の払出しまでを1本の送金として扱うことです。お金の動きと規制の確認情報に同じ送金番号を付けます。そうすれば、どの会社が、いつ、送金を進める・止める・埋め合わせるのかを後から追えます。

一方、代金を払う日本の企業の経理担当が知りたいことは、もっと単純です。いつ着くのか。全部でいくらかかるのか。銀行送金のままの方がよい場合はないのか。送金会社はこの問いにも答えられなければなりません。以下では、送金会社が設計を進める順に、使う側の企業から見た答えもあわせて追っていきます。

この記事でわかること

• 日本の企業の支払いが通る5つの段階と、それぞれを誰が担うか
• 最初の1本の送金ルートで取り決めること（為替・資金・規制・払出し）
• PoCで確かめることと、ステーブルコインを使わない方がよい条件

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

日本の企業の支払いは、どんな段階を通って届くか

さきほどの送金会社のサービスで、日本の企業がシンガポールの取引先へ代金を払う流れを追ってみます。システムの処理は次の5段階です。

1. 円を受け取る（オンランプ）：送金人の法定通貨を受け取る。担うのは銀行・資金移動業者・登録事業者など。この例では日本の送金会社がここに立つ。
2. 為替と資金を押さえる：元の通貨、決済用ステーブルコイン、受取通貨の交換枠を確保する。担うのは為替・流動性提供者と資金管理部門。
3. 規制の確認：原則として資金は動かさず、保留しておく。担うのは各国・地域の規制対象事業者。日本の送金会社も、シンガポール側の事業者も含まれる。
4. チェーン上で送る（オンチェーン決済）：許可したトークン・チェーンの上で移す。担うのは送金側または流動性提供者。
5. 現地通貨で払い出す（オフランプ）：受取側で償還・交換し、受取人へ法定通貨を払い出す。担うのは受取側の登録事業者・銀行など。この例ではシンガポール側の事業者が担う。

送金会社が4のチェーン上の送金だけを切り出すと、困ったことが起きます。入金後にレートが切れたとき、シンガポール側の流動性が尽きたとき、規制の確認で止まったとき。そのどれも、責任者が決まらないのです。利用企業に「代金はいまどこにあるのか」と聞かれても答えられません。

BIS（国際決済銀行）のCPMI報告も同じ見方です。ステーブルコインの国際送金利用は「arrangement（仕組み全体）」として評価すべきだとしています。そこには規制、ガバナンス、相互運用に加え、流動性と信用・決済リスクが含まれます。トークンを移すだけで便益が保証されるわけではない、という整理です（CPMI「Considerations for the use of stablecoin arrangements in cross-border payments」）。だからシステムも、チェーンの中ではなく、入口から出口までをひとまとまりとして作ります。

最初の1本の送金ルートで何を取り決めるか

さきほどの送金会社が最初に作るのは、日本からシンガポールへの法人支払の1本です。同じUSDC送金でも、米国からフィリピンへの個人送金とは条件が違います。必要な免許、データ、上限が異なり、営業時間や流動性も変わります。

そこで製品全体を一度に作ろうとせず、まずこの1本について次の項目を固めます。

• 当事者：送金人、受取人、送金側事業者、受取側事業者、流動性提供者、カストディ主体（この例なら、送金人は日本の企業、受取人はシンガポールの取引先、送金側事業者は日本の送金会社）
• 資産：元の通貨、決済用ステーブルコイン、受取通貨、許可するチェーンと公式トークンコントラクト
• 金額条件：1件・日次の上限、最小額、手数料、レートが切れた後の扱い
• 時間条件：受付時間、銀行の締切時刻、チェーン上で確定したとみなす条件、払出しの目標時間
• 担当の分担：本人確認、制裁・AML（マネーロンダリング対策）、トラベルルール情報、鍵管理、為替、返金、凍結、顧客連絡
• 国・地域ごとの条件：各社が行う行為、登録・許認可、送れる相手、データ保存・国外移転の要件

最後の項目は、日本の送金会社にとって「自社がどの登録のもとで、どの行為を担うか」を決めることでもあります。

これらは利用規約に書くだけでは足りません。機械で判定できる設定にして、取引ごとにその時点の版を残しておきます。規制や提携条件を変えたとき、過去の取引へ新しいルールを誤って当てはめないためです。

受取額を約束するには、為替と資金をどう押さえるか

このサービスで運ぶUSDCは米ドル建てです。そのため、円から現地通貨への送金には少なくとも2つの価格が関わります。「円→ドル相当」と「ドル相当→受取通貨」です。

使う側の企業から見ると、気になるのは取引先に実際に届く金額と、全部でかかる費用です。チェーン手数料が小さくても、それだけでは受取額は決まりません。為替スプレッド、オンランプ・オフランプの手数料、受取側の銀行手数料まで含める必要があります。

送金会社の側では、レートを示すときに、金額・手数料・有効期限などを1つの見積りとして保存し、後から変えられないようにします。見積りを出すだけでシンガポール側の流動性を予約しなければ、表示した受取額を払えないおそれが残ります。

固定レートを約束するなら、見積りの有効期間と同じだけ在庫か与信枠を押さえておきます。期限が切れたら、チェーンへ送る前に見積りを出し直します。送った後で見積りし直し、不足分を利用企業に請求するやり方は避けるべきです。

送金会社の資金管理担当は、流動性の確保のしかたを3つのやり方から選びます。

• 事前配置（prefunding）：受取側にステーブルコインと法定通貨をあらかじめ置いておく。少額・高頻度で、払出しの速さを優先するルートの出発点
• 都度調達（just-in-time）：取引ごとに市場で調達する。件数が少なく、在庫のコストを抑えたいルートの出発点
• 相殺（netting）：複数ルートの入出金を相殺し、差額だけを調達する

ただし都度調達は、市場の休止や銀行の締切、スプレッドの拡大が重なると、払出し時間を保証しにくくなります。上限を超えたら自動で止める仕組みが要ります。

異なる通貨を両側で同時に受け渡せないと、別のリスクも生まれます。片側だけ支払い、反対側を受け取れない為替決済リスクです。CPMIはこれを減らす仕組みとしてPvP（Payment versus Payment）を整理しています。2つの通貨の支払を、互いに条件付けて行う決済です（CPMI「Facilitating increased adoption of payment versus payment」）。1つのチェーン上のトークン移転が一度に完結しても、日本とシンガポールの両端の銀行入出金まで自動でPvPになるわけではありません。

規制の確認では何を満たす必要があるか

ここは、登録を受けた事業者として送金会社が自分で担う部分です。

トラベルルールとは、送金にかかわる事業者同士で、送金人と受取人の情報を受け渡すルールです。事業者はこの情報を取得・保持し、相手に通知します。もとはFATF（金融活動作業部会）の勧告16（Recommendation 16）で、国際送金の透明性を高めるための枠組みです。

2025年6月の改訂では、次の点が明確になりました。

• 支払の流れの途中にいる各事業者の責任
• 一定の国際送金に伴う情報
• 詐欺・誤送金への対策

各国は2030年末までに、この改訂を導入することが求められています（FATFの公式発表）。導入時期は国・地域ごとに違います。そのため、ルールには国・地域ごとの適用開始日を持たせておきます。

日本の企業やシンガポールの取引先の担当者の氏名・住所などは、チェーン上の取引に書き込んではいけません。パブリックチェーンに個人情報を書くと、削除や訂正が難しく、公開範囲も制御できないからです。これらは暗号化して、チェーンの外でシンガポール側の事業者へ渡します。チェーン上には通常のトークン移転の情報だけを残し、社内では共通の送金番号で結びつけます。

日本の送金会社には、日本の制度も直接かかわります。電子決済手段等取引業者などが、指定された国・地域の外国事業者へ移転するとき、送金人・受取人の情報を通知する仕組みです。

対象の国・地域は、相手側の制度整備に合わせて更新されます。2026年7月7日にも対象を追加する改正が公布され、8月3日から適用されています（金融庁「国又は地域を指定する件の一部改正」パブリックコメントの結果等）。対象外のウォレットとの取引でも、所有者情報の収集・保存が求められる場合があります（金融庁の制度整備資料）。国の一覧はプログラムに直接書き込まず、法務・コンプライアンスが承認したルールとして版ごとに管理します。

制裁への対応も、トークンの種類ではなく、国・地域と当事者で決まります。OFAC（米国財務省外国資産管理室）は、米国の制裁義務は仮想通貨にも法定通貨にも同じように適用されるとしています。リスクに応じた制裁コンプライアンスには、リストとの突き合わせなどを含めるべきだという立場です（OFAC Virtual Currency FAQs）。

アドレスを突き合わせるだけでは足りません。送金人・受取人、相手事業者、所在地、ウォレットの履歴まで審査します。疑いが晴れるまで送信を保留できる仕組みも必要です。

シンガポールの取引先に本当に払い出せるかを、先に確かめる

ステーブルコインをシンガポール側で受け取れても、希望の通貨に換え、取引先の銀行口座へ払えなければ送金は終わりません。そして、対応国の一覧に載っていても、実際に払い出せるとは限りません。

発行体や事業者の「対応国」には2つの意味が混ざっています。その国の銀行口座から発行・償還できる範囲と、現地通貨の払出しサービスを使える範囲です。この2つは同じとは限りません。

USDCの発行体であるCircleのサービス、Circle Mintを例に見てみます。

• 公式ドキュメントでは、USDC/EURCの発行・償還、チェーン上の移転、通貨間交換のAPI（cross-currency API）は別々の機能として説明されている（Circle Mint Docs）
• 銀行送金（wire transfer）に対応する国の一覧は、銀行パートナーの追加で変わる。最新情報は問い合わせるよう明記されている（Supported Countries）
• 第三者へUSDC/EURCを送るStablecoin Payoutsは、提供元がCircle LLC（米国）、Circle Singapore、Circle SAS（フランス）に限られ、個別に有効化を頼む必要がある
• トラベルルール情報が必要になる条件も提供元ごとに違う。米国は3,000米ドル相当以上、シンガポール・フランスは全金額（Send a Stablecoin Payout）

さきほどの送金会社も、「シンガポール」が一覧にあるだけで、この送金ルートが成り立つと判断してはいけません。契約と検証環境（sandbox）で、次の点を確かめます。

• 通貨、銀行の送金網、法人の所在地
• 取引の種類、上限
• 名義の確認、返金できるかどうか

対応チェーンも同じです。USDTなど対応外のトークンや、ブリッジ経由のUSDC（bridged USDC）には注意が要ります。Circle Mintのアドレスへ送ると資金を失うおそれがあると、Circleが警告しています（Supported Chains and Currencies）。画面上の名前や記号では判断せず、受け付けるチェーンとトークンを許可リストで管理します。

送金の結果が分からないとき、どうするか

たとえば送金会社がシンガポール側の事業者に払出しを依頼し、返事が来なかったとします。国際送金では、こうした返事の途切れ（タイムアウト）を「失敗」と見なしてはいけません。それは「結果不明」です。結果が分からないまま送り直すと、チェーン上の送金や銀行払出しが二重になるおそれがあります。シンガポールの取引先に、同じ代金が二度届くことになります。

そこで、送金の状態を成功・失敗の2つだけにしません。途中の段階ごとに状態を持たせ、結果不明のものは自動で送り直さず、人が確認します。

• チェーン上で確定した送金は巻き戻せない。誤りは、埋め合わせの取引で直す
• 銀行払出しは、照会して未処理だと確かめてから再試行する
• 着金後の訂正は、新しい返金・回収の手続きとして扱う

状態の一覧は後半の「送金の状態と、やり直しの方針」にまとめています。

PoCでは、失敗したときに最後まで片付くかを確かめる

送金会社がPoCで1件の送金を成功させても、本番に出せるかは判断できません。少なくとも次の場面を試し、帳簿の差がゼロになるまでの時間と、人の手が入った回数を測ります。

• 見積りの有効期間内の正常な送金。原資金の入金前と入金後それぞれでの見積り切れ
• 受取側の流動性不足、レート上限の超過、銀行の営業時間外
• 制裁・AMLの誤検知、トラベルルール情報の不足、相手事業者の応答停止
• チェーンへの送信のタイムアウト、確定の遅れ、別のチェーン・トークンへの誤送金
• オフランプAPIのタイムアウト、銀行による拒否、受取名義の不一致、結果通知の二重到着
• 返金、凍結、一部だけの払出し、手数料の差額、日次・月次の突き合わせ
• 鍵やAPI認証情報の入替え、事業者の切替え、ルールの版を更新している最中に続く取引

使う側の企業から見た着金時間は、「送金開始からチェーン上の確定まで」ではありません。「送金人の資金が確定してから、受取人に法定通貨が着くまで」です。送金会社もこの時間を測ります。比べる指標は次のとおりです。

• 所要時間（p50・p95。半分の送金が収まる時間と、95%が収まる時間）
• 失敗率、結果不明率、手動介入率
• 1件あたりの全費用、拘束される流動性、返金が終わるまでの時間

チェーンの部分だけ速くても、オフランプや手動審査が遅ければ、送金ルート全体は速くなりません。シンガポールの取引先にとっては、口座に着いた時刻がすべてです。

ステーブルコインを使わない方がよいのはどんなときか

次のような場合は、ステーブルコインの層を加えるほど、鍵管理、コンプライアンス、帳簿の突き合わせ、流動性管理のコストが増えるおそれがあります。使う側の企業から見ても、自社の支払いがこれに当たるなら、銀行送金のままで困らないかもしれません。

• 両端が同じ通貨である
• 既存の銀行送金網が必要な時間内に動き、休日対応も要らない
• 取引件数が少ない

送金会社の側では、次のような送金ルートは本番化を先送りすべきです。

• 受取側で安定したオフランプを契約できない
• 規制上の役割分担を確定できない
• 価格の提示と流動性の予約を一体で提供できない

比べるときは「チェーン手数料と銀行手数料」ではなく、同じ取引条件で次を測ります。入口から出口までの全費用、p95の着金時間、失敗・返金時の運用費、拘束資金、規制対応費です。BISの報告が指摘するとおり、ステーブルコインの便益は、送金ルートごとの摩擦を実際に減らせる場合に限られます。

開発チームが決める実装の詳細

ここからは、さきほどの送金会社で実際にシステムを作る開発チームの話です。データ・台帳・状態・APIをどう設計するかを見ていきます。

各段階でシステムが確定する情報

5つの段階ごとに、次の情報を確定させて記録します。

tx hashはチェーン上の取引の識別子です。払出しの目標時間は、SLO（サービス水準の目標）として設定に持たせます。

送金ルートの取り決めを版で残す

取り決めは corridor_version として取引に保存します。許可チェーン、上限、必要な確認項目、接続事業者の版を、後から再現できるようにするためです。

見積りのデータ例

見積り（quote）は、次の値を1つにまとめて変更できない形で保存します。

{
  "quote_id": "qt_...",
  "source_amount": {"currency": "JPY", "value": "1000000"},
  "settlement_asset": {"symbol": "USDC", "chain": "...", "contract": "..."},
  "destination_amount": {"currency": "...", "value": "..."},
  "fees": [{"type": "fx"}, {"type": "onramp"}, {"type": "network"}, {"type": "offramp"}],
  "expires_at": "...",
  "liquidity_reservation_id": "lr_...",
  "corridor_version": "..."
}

quote_id だけを発行し、受取側の流動性を予約しない設計では、表示した受取額を払えないおそれが残ります。

社内の帳簿：ウォレット残高をそのまま業務の残高にしない

日本の企業からの1件の送金には、いくつものお金が同時に存在します。顧客から受け取った原資金、予約済みの流動性、決済中のステーブルコインがあります。さらに受取側の払出し債務、手数料、返金債務もあります。ウォレット残高だけでは、どの取引にいくら拘束されているかを説明できません。

社内の台帳では、少なくとも次の残高を別々に持ちます。

tx receiptは、チェーンが返す取引の処理結果です。

台帳の仕訳と外部の処理は、同じトランザクションの中では完了しません。そこでoutboxパターンを使います。API要求を送る前に「実行予定」を記録し、外部IDを受け取ってから結果を追記するやり方です。処理が途中で止まっても再開できます。

送金会社の日次の突き合わせでは、銀行、オンランプ、ウォレット、オフランプの4つを、payment_id と外部参照番号で照らし合わせます。一方、シンガポール側の1社の中で入金を検知し、確定させ、会計につなぐ仕組みは事情が違います。ここで見ているのは、日本の送金会社から見た、送金ルート全体にまたがる多者間台帳です。

規制情報と取引を結びつけるID

トラベルルール情報はチェーンの外でやり取りし、社内では次のキーで関連付けます。

• payment_id：送金ルート全体の取引ID
• travel_rule_message_id：送受信した規制情報の参照ID
• screening_case_id：送金人・受取人・相手事業者・ウォレットの審査ケース
• tx_hash：オンチェーン送金の識別子
• payout_reference：受取側の銀行払出しの識別子

送金の状態と、やり直しの方針

状態は9つに分け、右端の列に各状態でのやり直し・取消の方針を書いています。

冪等キーとは、同じ要求を何度送っても1回分しか処理されないようにする識別子です。

クロスチェーン移転を使う場合は、焼却（burn）、証明（attestation）、発行（mint）をさらに別の状態にします。CircleのCCTPは3段階で動きます。送信元でUSDCを焼却し、CircleのAttestation Serviceが署名し、送信先で発行します。

公式のトラブルシューティングは、焼却済み、証明待ち、発行未実行を分けて診断しています。証明には一度しか使えないnonceが含まれ、同じ証明で発行できるのは最初の1回だけです（Circle CCTP Troubleshooting、Retry a Failed Mint）。ただし、CCTPのこの二重実行防止が、オフランプの銀行払出しにまで効くと考えてはいけません。

API：命令・結果通知・照会を別々に作る

日本の送金会社、流動性提供者、シンガポール側の事業者のように、複数の事業者をまたぐ送金ルートでは、同期APIを連ねるだけで完了させると、1社の遅れで全体がタイムアウトします。APIでは「命令を受け付けたこと」と「外部で完了したこと」を区別します。完了は、署名付きwebhook（相手から届く結果通知）か、定期的な照会（polling）で確定させます。

• 命令：POST /payments、POST /payments/{id}/fund、POST /payments/{id}/settle。すべてで、呼び出し側が生成する冪等キーを必須にする
• イベント：source.funded、compliance.held、onchain.final、payout.paid。イベントIDと連番を保存し、重複や順不同の到着を受け入れる
• 照会：GET /payments/{id}。現在の状態に加え、外部参照番号、金額、ルールの版、最後に確認した時刻を返す

イベント本文に載せる個人情報は最小限にします。受信側は、権限付きAPIで詳細を取りに行く形です。ログへ氏名・住所・本人確認書類を複製しないでください。監査ログには、誰がどのルールの版で承認・停止したかを残します。

銀行やカード網と接続する場合も、既存の網はオンランプ・オフランプと顧客との接点として残ります。ステーブルコインは中間決済の一方式という扱いです。

ISO 20022（金融機関どうしのメッセージの国際標準）のメッセージ定義を使う場合は、公式カタログの現行版を確認します。接続先の利用者団体が定める利用規則もあわせて確認します（ISO 20022 Catalogue of Messages）。独自JSONの項目名を似せただけで、ISO 20022準拠と称してはいけません。

対応チェーンの許可リスト

画面の表示名やシンボルでは判断しません。chain ID、発行体公式のトークンコントラクト、入出庫APIの対応、この組み合わせを許可リストにします。

関連して読む

• ステーブルコインとは？仕組み・種類・日本市場の最新動向を徹底解説（基礎はこちら）
• GENIUS Actと日本のステーブルコイン規制の違い｜2026年日米比較
• 複数発行体ステーブルコインの相互運用設計｜交換方式と障害対応
• ステーブルコインのデペッグ対応｜停止・償還・売却・再開の手順
• クロスチェーンブリッジ開発とは？自社チェーンに必要な理由と設計の考え方

XTELAができること

私たちXTELAは、貴社が最初に立ち上げる1つの送金回廊について、資金とデータの流れ、事業者間の責任分界、多者間台帳・状態・APIを設計し、オンチェーン監視や鍵管理を含めて開発します。見積り失効、結果不明、銀行による拒否、返金までを検証環境で再現するPoCを組み、本番に移せるかを数字で判断できる形にします。登録・許認可などの法的な判断は弁護士と連携して進めます。回廊の設計から相談したい場合はお問い合わせフォームからご連絡ください。

主要参考資料

• BIS/CPMI: Considerations for the use of stablecoin arrangements in cross-border payments（2023年10月31日）
• BIS/CPMI: Facilitating increased adoption of payment versus payment（2023年3月27日）
• FATF: Recommendation 16 on Payment Transparency更新（2025年6月18日、同年10月28日更新）
• FATF: 2025 Targeted Update on Virtual Assets and VASPs（2025年6月26日）
• 金融庁: 犯罪収益移転防止法施行令第十七条の二及び第十七条の三に基づき国又は地域を指定する件の一部改正（パブリックコメントの結果等）（2026年7月7日公布、8月3日適用）
• 金融庁: Travel Rule対象国・地域の指定改正案の公表（2026年5月1日、5月19日更新）
• 金融庁: 電子決済手段等取引業・電子決済等取扱業を行うみなさまへ
• 金融庁: 電子決済手段・暗号資産のTravel Rule制度整備資料（2023年5月26日）
• OFAC: Questions on Virtual Currency
• Circle: Circle Mint Docs（2026年9月24日確認）
• Circle: Supported Countries（2026年9月24日確認）
• Circle: Send a Stablecoin Payout（2026年9月24日確認）
• Circle: Supported Chains and Currencies（2026年9月24日確認）
• Circle: CCTP Technical Guide（2026年8月12日確認）
• Circle: Troubleshoot CCTP Transfers（2026年8月12日確認）
• Circle: Retry a Failed Mint（2026年9月24日確認）
• ISO 20022: Catalogue of Messages（2026年8月12日確認）

資料の確認日と注意

一次資料は2026年9月24日（一部は2026年8月12日）に確認しました。本記事はそれに基づく技術・業務設計の整理です。対応する国・地域、トラベルルールの情報項目、製品仕様、対応国・通貨・チェーンは、その後も変わり得ます。法務・規制・制裁・会計・税務の助言ではありません。登録の要否などの個別判断は、各法域の専門家に確認してください。