アトミックDvPの作り方｜証券トークンとステーブルコインを同時に決済する3方式

ある証券会社が、セキュリティトークン（ブロックチェーン上で発行した証券）の売買を始めようとしています。代金は、別の会社が発行するステーブルコインで受け渡す計画です。証券はセキュリティトークンの基盤に、お金はステーブルコインの台帳にあります。

設計を任された事業責任者が流れを追うと、怖い場面が見つかりました。買い手の代金はもう売り手へ渡った。ところがその直後、証券側の台帳が止まり、買い手に証券が届かない。払った分がまるごと失われかねない状態です。これを「元本リスク」と呼びます。

代金の支払いと証券の引渡しの片方だけが成立する時間が残れば、証券をトークンにしただけでは、この危険は消えません。

この危険をなくす決済の仕組みがDvP（Delivery versus Payment）です。証券の引渡しと代金の支払いを互いの条件にして、一方が行われなければ他方も行われないようにします（日本銀行の定義、JPX用語集）。それをブロックチェーン上で一度に行うのが「アトミックDvP」です。

では、どう作ればよいのか。証券とお金が同じ台帳にあれば、1回の処理で両方を書き換えられます。別々の台帳なら、2つの台帳の動きを合わせる工夫が要り、途中で止まったときの戻し方まで先に設計する必要があります。つまり、同じ台帳に置けるかどうかで作り方が変わります。以下では、この証券会社が方式を選び、PoCで確かめるまでの順に追っていきます。

この記事でわかること

• アトミックDvPの3つの作り方と、どれを選ぶかの目安
• いつ「決済が確定した」と言えるか、決済に使うお金の選び方
• PoCで最低限通す10の試験と、止まったときの戻し方

DvPの考え方はどの資産でも共通です。一方、トークン化した国債のレポ取引には固有の処理があります。値洗い、追加担保、利金の補償、担保差替え、満期の返却などです。こちらはトークン化国債のレポ取引設計で詳しく書いています。

「アトミック」とは、どんな結果で終わることか

「アトミック」は、2つの台帳がぴったり同じ時刻に書き換わる、という意味ではありません。外から見た最後の結果が、次のどちらかに必ず決着する、という意味です。

• 決済完了（SETTLED）：買い手へ証券、売り手へ代金が移り、どちらも取り消せない。
• 中止（ABORTED）：どちらの資産も元の持ち主へ戻り、また使える。

困るのは、その間の状態です。通信が切れた直後や、システムを再起動した直後には、どちらとも言えない時間が生まれます。これを「どちらか不明（UNKNOWN）」と呼びます。

ここで「たぶん成功した」「たぶん失敗した」と推測して送り直すと危険です。証券やお金が二重に動いたり、片方だけがもう一度動いたりします。どちらか不明の取引は別に取り置き、両方の台帳を確かめてから、決済完了か中止のどちらかに決着させます。

証券とお金を同じ台帳に置けるかで、作り方を選ぶ

BISの証券決済レビューは、こう整理しています。証券とお金のトークンが同じ台帳にあれば、アトミック決済用のスマートコントラクトでDvPを組める。一方、別々の台帳をまたぐと、元本リスクがまた入り込むことがある。

ですから方式は、新しさでは選びません。資産をどこに置けるか。誰を信頼できるか。障害のとき何を止められるか。この3つで選びます。

要点だけを比べると、次のとおりです。

同じ台帳に置けるなら：1回の処理で両方を書き換える

同じ台帳では、DvPのコントラクトが1回の取引（トランザクション）の中で両方を確かめ、同時に更新します。このとき頼るのは、共通台帳のバリデーター、コントラクト、管理権限です。

確かめる項目は次のとおりです。

• 買い手の資金残高と、売り手の証券残高
• 双方の移転権限と、投資家の適格性
• 取引の期限

すべて満たしたときだけ、2つの残高を更新します。1つでも欠ければ、取引全体を取り消せます（revert）。

ただし、1回の処理の中でも、実際には次のようなものが絡みます。

• 証券側と資金側のコントラクトをまたぐ呼び出し
• 一時停止・凍結の権限、アップグレード権限
• 手数料の差引き、端数、同じ銘柄に複数のトークンコントラクトがある場合

これらを固めておかないと、監査した処理の流れと、実際に動く流れがずれます。「1回の処理だから安全」とは言い切れないのはそのためです。

注文のときだけでなく、実行のときにも確かめ直します。証券が移せるか、使える資金残高があるか、の2点です。

同じ台帳に置くと、障害も同じ場所に集まります。バリデーターが止まったり管理鍵が盗まれたりすると、証券とお金の両方に同時に響きます。運用手順には次を入れます。決済を止める権限と再開の条件。管理者の操作を複数人で承認する仕組み。コントラクト更新のときの未決済取引の扱いです。

別々の台帳でHTLCを使うなら：期限の差と確定の時間を設計する

HTLCでは、一方が秘密の値を作り、そのハッシュ値だけを相手と共有します。証券とお金は、それぞれ鍵付きの箱のようなコントラクトに入れます。期限までに秘密の値を示せば受け取れ、期限を過ぎれば元の持ち主が取り戻せます。

どちらかが受け取ると、秘密の値が公開されます。もう一方も、同じ値で受け取れるようになります。頼るのは、各台帳でのハッシュと時刻の扱いと、参加者自身による見張りです。

後から受け取る側には時間が要ります。先の台帳で公開された値を見つけ、自分の取引を送り、確定を待つ時間です。2つの期限が同じだと、この時間が取れません。そのため、払戻しの期限には十分な差を付けます。

その差は「数ブロック」と決め打ちしません。各台帳の確定のしかた、最も長い停止時間、混雑、検閲への強さ、運用担当者が対応できる時間から決めます。

HTLCが向くのは、両方の台帳で同じハッシュ関数と期限ロックを使える単純な交換です。ところがセキュリティトークンでは、証券側で、受け取る人の本人確認・適格性、保有上限、移転の承認をそのつど判定することがあります。その可否をお金の側から安全に確かめられないと、お金だけが受け取れる時間が生まれます。

BISもProject Stellaなどを踏まえ、台帳をまたぐ方式は設計しだいで元本リスクを持ち込むと指摘しています。HTLCという名前だけで、アトミックだと考えないことが大切です。

別々の台帳で調整役を立てるなら：決定の残し方と戻し方を取り決める

調整役型は、2フェーズコミットの考え方を使います。証券台帳とお金の台帳が、それぞれ移転の条件を確かめ、資産を仮押さえします（prepare）。調整役は、両方から成功の証明を受けたときだけ確定（COMMIT）を決めます。どちらかが失敗したら中止（ABORT）です。

頼るのは、台帳どうしの検証、調整役と中継者（relayer。台帳のあいだで情報を運ぶ役）、そして回復の手順です。Cross Frameworkの公式ドキュメントは、この流れをアトミックコミットの手順として説明しています。そこでは、取引を始めたチェーン（initiator chain）が調整役になり、参加する各チェーンへ確定か中止を伝えます。

この方式は、別の台帳の適格性・許可リスト・残高を条件に入れやすいのが利点です。弱点は、仮押さえの後に調整役が止まると、資産が動かせないまま残ることです。そこで調整役を1つのプロセスに頼らず、次を用意します。

• 決定の記録を消えない形で残す、代わりの調整役に交代できる
• 同じ決定を何度でも配り直せる
• 参加する台帳の側から決定を問い合わせられる

待ち時間が過ぎても、調整役がすでに確定を決めているかもしれません。ですから、待ち時間が過ぎたことだけを理由に、一方の台帳が勝手に中止してはいけません。

国内では2023年に技術検証が行われています。CordaとGoQuorumという2つの台帳を、IBC/LCP（台帳どうしが互いの状態を確かめ合う仕組み）でつなぎました。そのうえでCross Frameworkを使い、デジタル証券とステーブルコインを同時に移す試験です（Datachain・三菱UFJ信託銀行の公式発表）。これは技術検証の成果です。法律や運用の条件をすべて満たした商用決済の証明とは、区別して読みます。

いつ「決済が確定した」と言えるか

取引がブロックに入ったこと。仕組みの上で取り消せなくなったこと。法律・契約の上で権利の移転が確定したこと。この3つは同じではありません。台帳ごとに、少なくとも次の3つの時点を決めておきます。

• 技術的な受理：バリデーターやシーケンサー（取引の順番を決めてまとめる役）が取引を受け付けた時点
• 仕組みの上での確定：合意の仕組みの上で、通常の手続きでは覆らないと扱う時点
• 法的な確定：参加者の規約、準拠法、倒産手続きまで含めて、移転を最終と扱う時点

このように、確定の時点は台帳の仕組みごとに違います。パブリックチェーンの承認数と、許可型台帳（permissioned ledger）の署名の必要数も、同じ物差しでは比べられません。確定の基準は台帳ごとに版を付けて管理します。DvPの「決済完了」の知らせは、証券とお金の両方がそれぞれの基準を満たしてから出します。つまり、確定の遅い方の台帳に合わせます。

CPMI-IOSCOの金融市場インフラのための原則（PFMI）は、決済がいつ確定し、いつ取り消せなくなるかに、はっきりした法的根拠を求めています。スマートコントラクトが成功したという技術上の事実だけでは、証券の権利移転も、倒産時の扱いも決まりません。

どの時点を法的な確定とするかは、スキームごとの法的判断で決まります。システムの側は、その結論を確定の基準と記録の要件として組み込みます。

決済に使うお金は、何で選ぶか

ステーブルコインを使えば、スマートコントラクトからお金の側を動かしやすくなります。一方で、次の点は銘柄とスキームによって違います。

• 持ち主が、誰に対して、どんな請求権を持つか
• 償還できる時間帯と、凍結の権限
• 発行体、保全資産、銀行、ネットワークが止まったときの影響

1トークン＝1円と表示されることと、中央銀行マネーで最終的に決済されることは同じではありません。

設計のときは、次を比べます。

• 発行・償還をするのは誰か、参加できるのは誰か、償還の締め時刻
• 資金を誰が供給するか、凍結や取引禁止リストの権限、手数料
• 障害のときに代わりとなるお金の受け渡し手段

ステーブルコインの種類はステーブルコインの仕組み・種類で確かめられます。

資金の量にも目を向けます。取引を1件ずつその場で決済する方式（即時グロス決済）は、元本リスクを減らせます。その代わり、取引ごとに証券とお金を前もって用意するので、必要な資金が増えることがあります。

ネッティング、待ち行列、優先度、日中与信（1日のうちに返す前提の一時的な貸付け）、担保、部分決済。これらを使うかどうかは、アトミックかどうかとは別の、資金繰りの設計です。「決済が速いほど、いつも資本の効率がよい」とは限りません。

国内ではどこまで検証が進んでいるか

ひとつはProject Trinityです。2025年8月22日に公表された実証で、セキュリティトークンを売買する取引（セカンダリー取引）をステーブルコインでDvP決済します（参加各社の共同発表）。参加するのは銀行・証券・ST基盤の8社です。

• 三井住友銀行、大和証券、SBI証券
• SBI R3 Japan、大阪デジタルエクスチェンジ、BOOSTRY
• Progmat、Datachain

将来像としては、約定後の即時グロス決済や、24時間365日の取引を掲げています。ただし開始時点で近い目標にしたのは、証券会社どうしがステーブルコインでT+2のDvPを行うことです。進め方は3段階です。業務要件を決め、技術を検証し、実際に発行したセキュリティトークンで業務運用を検証します。2026年9月24日時点では、次の段階に進んだという公式発表は見つかりませんでした。このように、「めざす将来像」と「いま検証が済んだ範囲」は分けて読む必要があります。

もうひとつは、お金の側にトークン化預金を使う検証です。次の6社が、2026年3月にこれを検証しました。

• SBI証券、大和証券、SBI新生銀行
• BOOSTRY、大阪デジタルエクスチェンジ、ディーカレットDCP

ディーカレットDCPが発行したデジタル社債とDCJPYを使いました。ibet for FinとDCJPYネットワークをつなぎ、エスクロー型のDvP決済を試しています。完了の公表は2026年4月24日です。今後は、限られた参加者で小さく始めることをめざします。システム連携、運用ルール、契約条件を順に整えるとしています（SBI証券の発表）。

同じ見方は、自社のPoCにも当てはまります。アトミックスワップのデモが成功しても、商用化が済んだとは言えません。合格の条件を広げて確かめます。参加者、資産、取引時間、取消し、デフォルト、資金の供給、顧客資産の管理、監査、法的な確定までです。

PoCで最低限通す10の試験

この証券会社がPoCで確かめるのは、次の10項目です。

• 正常な流れ：同じ決済IDで証券とお金が1回だけ移り、確定してから「決済完了」になる。
• 残高不足：どちらかの仮押さえが失敗し、両方とも移転もロックの残りもない。
• 重複送信：同じ指図を10回送っても新しい取引を作らず、同じ結果を返す。
• 途中停止：仮押さえの後、確定を決めた後、片方が確定した後。それぞれで処理を止め、再起動後に同じ決定へ決着する。
• 通信断：調整役、中継者、各ノードの間を切り、推測で送り直さず「どちらか不明」として取り置く。
• 期限の境目：HTLCの期限の直前・直後、時計のずれ、ブロック生成の遅れでも、片方だけが受け取られない。
• 確定の障害：チェーンの再編成（reorg。確定前のブロックが入れ替わること）、バリデーターやシーケンサーの停止を試し、両方が基準に届く前に完了を知らせない。
• 適格性の変更：注文の後に許可リスト、保有上限、凍結状態を変え、実行時のルールで安全に中止する。
• 突き合わせ：約定、両方の台帳、カストディ、会計に同じIDが残り、わざと作った差を見つけて取り置ける。
• 運用での復旧：復旧手順書だけを渡された別の担当者が、監査ログから状態を判断し、承認済みの手順で復旧できる。

性能は、1秒あたりの処理件数（TPS）の平均だけでは測りません。未確定の資産がどれだけたまるかを見ます。

• 仮押さえのまま止まっている件数
• 決済完了までの時間のp95/p99（95％・99％の決済が収まる時間）
• 「どちらか不明」から戻るまでの時間、資金が動かせない時間

よくある質問

HTLCだけでDvPは成立しますか？

成立する場合もあります。両方の台帳が同じハッシュ関数と期限ロックを使え、受け取りに追加の条件がない単純な交換です。

ただし、次のような条件では、片方だけが受け取られる時間が残ります。期限の差が短すぎる。片方の台帳が止まる、または検閲される。証券の側が、受け取る人の適格性をそのつど判定する。期限の差の根拠と、適格性をお金の側から確かめる方法まで設計して、はじめてDvPと呼べます。

ステーブルコインでDvPすれば元本リスクは無くなりますか？

引渡しと支払いを切り離せない形で処理すれば、「渡したのに受け取れない」という元本リスクは小さくできます。一方で、ステーブルコインそのものの信用・償還・凍結のリスクは残ります。中央銀行マネーでの最終決済とは性質が違います。発行体、償還の締め時刻、障害時に代わりとなるお金の受け渡し手段を、別に評価します。

実装する人向けの詳細

ここからは、この証券会社で決済の仕組みを作るアーキテクトと開発チームの話です。

すべての処理を結ぶ4つのID

すべての処理と記録は、少なくとも次の4つの識別子で結びます。

• trade_id：約定を一意に示すID
• settlement_id：DvP処理全体の冪等キー（同じ要求を何度送っても1回分しか処理されないようにする識別子）
• securities_tx_id：証券脚の台帳トランザクション
• cash_tx_id：資金脚の台帳トランザクション

同じsettlement_idをもう一度受け取っても、新しい移転は作りません。今の状態を返すのが基本です。約定を訂正するときは、同じIDを上書きしません。元の約定を取り消し、新しい版の決済指図を出します。

HTLCの秘密値と期限

一方が秘密値sを作り、ハッシュ値H(s)を共有します。証券と資金は、それぞれ「期限までにsを示せば受け取れ、期限を過ぎれば元の持ち主が取り戻せる」コントラクトへロックします。どちらかが受け取ったときにsが公開され、もう一方も同じ値で受け取れます。期限の差の決め方は、前半のとおりです。

再起動しても同じ判断ができる状態の持ち方

決済を指揮するプログラム（オーケストレーター）が、メモリの上だけで状態を持つとします。すると処理が止まった後、どこまで進んだかを戻せません。状態と、状態が変わった理由を永続化し、少なくとも次の順序をはっきりさせます。

1. 受信（RECEIVED）：署名済みの決済指図を受け取り、settlement_idの重複を除く。
2. 確認済み（VALIDATED）：約定の版、銘柄、数量、価格、当事者、ウォレット、期限、適格性を確かめる。
3. 仮押さえ中（PREPARING）：証券と資金を、移せない予約状態にする。両方に同じ取引内容のハッシュを記録する。
4. 仮押さえ済み（PREPARED）：両脚の仮押さえの証明と、観測したブロック・台帳の版を保存する。
5. 確定決定／中止決定（COMMIT_DECIDED / ABORT_DECIDED）：一度だけ決め、後から変えない。
6. 確定中／中止中（COMMITTING / ABORTING）：両方の台帳へ同じ決定を冪等に配る。
7. 確定待ち（FINALITY_WAIT）：両脚が各台帳の確定基準に届くまで、外へ完了を知らせない。
8. 決済完了／中止（SETTLED / ABORTED）：記録を固め、予約を解放する。
9. どちらか不明（UNKNOWN）：観測が食い違う、または片方へ届かない。新しい処理を止め、突き合わせる。

状態が変わるたびに、次を追記だけの記録として残します。操作者、時刻、使ったルールの版、要求内容のハッシュ、変わる前と後の状態、台帳の証明、失敗コードです。APIの応答が失われても、台帳の照会と決定の記録から同じ結果を組み立て直せること。これが合格の条件です。

チェーンの再編成（reorg）や、バリデーターどうしの食い違いを見つけたときも同じです。該当する範囲を「どちらか不明」へ戻します。逆向きの資産移転は自動で作らず、調べてから決めます。

片方の障害と待ち時間切れへの対応

障害ごとに、してはいけない動作と最初の対応を決めておきます。

補償の取引は、アトミックの代わりにはなりません。片方がすでに法的に確定し、巻き戻せない場合に限る例外の手続きです。新しいsettlement_id、元の取引への参照、権限者の承認、会計処理と顧客への通知を伴わせます。ふだんの再試行とは切り離して扱います。

約定・権利・資金をまたぐ突き合わせ

日中は出来事に応じて状態を更新し、少なくとも1日1回は全件を突き合わせます。対象はオンチェーンの記録どうしだけではありません。

• 取引所・PTSなどの約定、証券会社の売買記録
• 証券台帳、資金台帳、カストディ残高
• 会計仕訳

合計残高が合っていても、顧客ごとの配分がずれていれば合格ではありません。

突き合わせの記録には、次を持たせます。

• trade_id、settlement_id、両脚のトランザクションID
• 資産のコントラクトとアドレス、チェーン・台帳のID、数量、金額
• 当事者、実質的な所有者（beneficial owner）への参照
• ファイナリティに届いた時点、使ったルールの版

同じ名前のトークンや、別のチェーンにある同名の資産を取り違えないようにします。銘柄記号（シンボル）ではなく、発行体・ネットワーク・コントラクトを含む資産IDを使います。

証券トークンに移転の制限がある場合は、適格性ルールの版と判定の記録も結び付けます。証券を含むRWAトークン化の基礎はRWAトークン化の解説で補足しています。

関連記事

• トークン化国債のレポ取引設計｜担保管理・DvP・満期処理：値洗い、利金の補償、満期の同時決済などレポ固有の処理
• 複数発行体ステーブルコインの相互運用設計｜交換方式と障害対応：資金脚に複数の発行体が関わる場合の交換と回復
• ステーブルコインとは？仕組み・種類・日本市場の最新動向：資金脚に使う資産の基礎
• トークン化預金とは？開発に必要なシステム設計と企業導入の進め方：資金脚にトークン化預金を使う場合の基礎

XTELAができること

私たちは、証券脚・資金脚・約定系の責任の境目を整理し、台帳の配置と相互運用方式を比べたうえで、決済の状態遷移、冪等なAPI、照合と監視を設計・開発します。仮押さえ後の停止や通信断を意図的に起こす障害試験を含めたPoCを組み、貴社の担当者が法的な確定の判断に使える資産の流れ、権限、ファイナリティ、証跡を技術資料にまとめます。法的な判断は弁護士と連携して進めます。

証券トークンとデジタルマネーのDvP設計について相談する

主要参考資料

• 日本銀行: DVPとは何ですか？
• 日本取引所グループ: DVP決済
• BIS Quarterly Review: On the future of securities settlement
• ECB and Bank of Japan: Project Stella Phase 2
• CPMI-IOSCO: Principles for Financial Market Infrastructures
• Cross Framework Docs: Cross-chain Transaction
• Datachain・三菱UFJ信託銀行: クロスチェーンDvP技術検証
• Project Trinity: ステーブルコインを活用したDvP決済実証
• SBI証券: 国内初のトークン化預金によるセキュリティトークン決済の実発行検証の完了

資料の確認日と注意

公開された一次情報は2026年8月13日に確認しました（国内の実証の動きは2026年9月24日に確認）。内容は、その時点の情報にもとづく一般的な技術設計の解説です。個別の証券・電子決済手段・銀行預金の法的な分類、権利の移転、倒産時の扱いなどは、対象のスキームに即して弁護士などの専門家に確認してください。