Solana DvPとは？機関向けアトミック決済の仕組みと未解決点

売り手Aが債券トークン1口を渡し、買い手Bが100万円相当の支払いトークンを払う場面を考えます。従来の別送では片方だけが先に確定する恐れがあります。Solana DvPは、双方を期限付きエスクローへ預け、そろったときだけ同時交換し、そろわなければ返すことで、この片渡しをオンチェーンで防ぎます。

\n

本稿は、この一例を通して仕組み、委任型との違い、未解決点、導入判断を順に解説します。技術的な同時実行と、法的・資金的な決済完了は別です。この原則を先に押さえ、後半では各リスクに固有の判断材料だけを示します。Solana Foundationの一次資料を基準に2026年10月7日に最終更新し、仕様変更や公式発表が確認できた場合は見直します。責任編集は本サイト編集部（暗号資産・ブロックチェーン技術担当）です。

\n

なお、本稿は公開資料に基づく技術・制度の一般的な解説です。特定の暗号資産、トークン化証券、決済サービスへの投資や利用を推奨するものではなく、個別案件の法律・会計・投資助言でもありません。

Solana DvPとは何か

Solana Foundationは2026年10月6日、金融機関向けのアトミック決済プログラム「Solana DvP」を公開しました。MITライセンスで提供され、プログラム所有のエスクローを介して二つの資産を条件付きで交換する設計です。公式発表が示しているのは、再利用可能な技術標準とその設計意図であって、特定金融機関の本番導入、取引量、監査完了、障害対応実績ではありません。

DvPはDelivery versus Paymentの略で、日本語では「証券の引渡しと資金の支払いを結び付ける決済」と考えると分かりやすいでしょう。ここでいうDeliveryは荷物の配送ではなく、証券や資産の移転です。Paymentはその対価となる資金の移転を指します。二つの移転を条件付きで結ぶことで、「証券を渡したのに代金を受け取れない」「代金を払ったのに証券が届かない」という元本リスクを抑える考え方です。

証券と支払いを条件付きで結ぶDvP

DvPの本質は速度ではなく条件付けにあります。証券レッグと資金レッグの双方が実行できる場合に限って決済を成立させ、条件を満たさなければ一方だけを確定させないことが重要です。BISが示してきたDvPの枠組みにも複数のモデルがあり、個々の移転をグロスで結ぶ方法や、ネット差額を決済する方法などがあります。そのため、DvPという言葉だけで処理方式、決済時点、流動性負担まで一つに決まるわけではありません。

アトミックという語は、複数の処理を分割できない一まとまりとして扱う性質を表します。両方が成功するか、全体が失敗するかのどちらかに寄せる考え方です。ただし、オンチェーン上の命令が不可分に実行されても、チェーン外の名簿、契約、銀行預金、原資産の管理まで自動的に同時更新されるとは限りません。どこまでを一つの原子的な処理に含めたかを確認する必要があります。

2026年10月6日に公開された機関向け標準

Solana DvPは、金融機関がトークン化資産の決済フローを構築する際の共通部品として位置付けられています。対応するトークンプログラム、参加者の役割、エスクロー口座、期限、成立・返還の状態遷移を標準化することで、案件ごとに基本部分を一から作る負担を減らす狙いがあります。オープンソースであることは検証や改修をしやすくしますが、それだけで個別実装の安全性や規制適合性が保証されるわけではありません。

また「機関向け」は、機関による採用済みを意味しません。金融機関が必要とする権限管理、資産分離、期限、監査可能性などを意識した設計という意味で読むのが適切です。公開資料では、本番導入機関、実取引量、監査報告、サービス水準、障害時の補償までは確認できません。評価の出発点は発表の大きさではなく、コード、権限、契約、決済資産、運用手順を案件単位で確かめることです。

プログラム所有エスクローで同時交換する仕組み

Solana DvPのプログラム型では、売り手と買い手が交換対象をそれぞれプログラム所有の分離エスクローへ預けます。エスクローとは、取引が完了するまで第三の仕組みが資産を一時的に保持する考え方です。ここでは人間の仲介者が自由に資産を動かすのではなく、あらかじめ定めたプログラムの条件に従って移転または返還を実行します。

典型的には、売り手が資産トークンを、買い手が支払いトークンを用意します。取引条件には、対象ミント、数量、相手方、期限などが含まれます。両レッグが正しく預託され、条件が一致すれば交換へ進みます。片方の預託が欠ける、数量が違う、期限を過ぎるといった場合には、成立させず返還できる経路を設けます。

両レッグを分離エスクローへ預託

「レッグ」は取引を構成する一方の移転を意味します。資産を渡す側が証券レッグ、代金を渡す側が資金レッグです。二つを別々のエスクロー口座に置くのは、どの資産がどの取引のために拘束されているかを明確にし、他の残高と混ざるのを避けるためです。預託中は当事者が通常の口座から自由に使える残高ではなくなるため、資金繰りやキャンセル条件も運用設計に含めなければなりません。

預託は安全性を高める一方、確認点も増やします。トークン口座の所有者、ミントの権限、凍結状態、Transfer Hookなどの拡張機能、数量の桁、手数料の扱いが想定どおりでなければ、片方を預けた後にもう片方が進まない可能性があります。誰が取引条件を作成し、誰が検証し、誤った条件をどう取り消すかを決める必要があります。

成立なら交換、期限切れなら返還

両方の預託と条件がそろったとき、プログラムは資産トークンを買い手へ、支払いトークンを売り手へ移します。この二つを一つの処理として成立させることで、オンチェーン上の片渡しを避けます。どちらかの移転が実行できなければ、全体を成立させないのがアトミック決済の要点です。

一方、相手方が期限までに預託しない場合に資産が永久に拘束される設計では実用的ではありません。そこで期限切れ後に返還できる経路を置きます。返還は取引の失敗をなかったことにする魔法ではなく、拘束されたオンチェーン資産を元の管理へ戻す処理です。返還を誰が開始できるか、期限の基準となる時刻、ネットワーク障害中の扱い、再試行、手数料負担は別に定める必要があります。

状態	オンチェーンで起きること	実務で確認すること
条件作成	対象資産、数量、相手方、期限を設定	入力承認、照合、誤設定の取消方法
預託中	各レッグを分離エスクローへ移す	残高拘束、権限、トークン拡張の影響
成立	両レッグを同じ処理で交換	受取口座、会計記録、法的効力
期限切れ	成立させず返還経路へ進む	返還開始者、再試行、例外報告

委任型DvPとの違い

Solanaの公式資料には、プログラム所有エスクロー型とは別に、delegate（委任）権限を使うDvPの教育用実装があります。委任型では各当事者がトークンをエスクローへ預ける代わりに、決済エージェントへ一定数量を動かす権限を付与します。エージェントは一つの取引内で資産と支払いの移転を実行します。

両方式は「一取引内で二つの移転を行う」という結果が似ていても、信頼する対象が違います。委任型では、権限を与えられた決済エージェントが正しい条件で命令を組み立てることを信頼します。エスクロー型では、資産をプログラム所有口座に預け、コード化された状態遷移を信頼の中心に置きます。どちらにも鍵管理、コード、設定、運用のリスクがあり、単純な優劣では選べません。

委任型は決済エージェントを信頼する

delegateは口座の所有権そのものではありませんが、承認された範囲でトークンを移転できる強い権限です。決済エージェントの秘密鍵が侵害された場合や、誤った取引条件を組み立てた場合の影響を考えなければなりません。権限付与の数量、対象口座、有効期間、取消手順、署名ポリシー、監査ログを明確にします。

委任型の利点は、専用のカスタムプログラムを導入せず、既存のトークン権限と取引の原子性を使える点です。しかし公式の教育用コードは、監査、法務、鍵管理などをせず本番で使うことを戒めています。サンプルが動くことは、本番の可用性、規制対応、例外処理、安全性を証明しません。

単一delegate制約とエスクロー型の使い分け

トークン口座のdelegateには制約があり、同じ残高について複数の業務へ同時に独立した委任を組みたい場合、設計が複雑になります。既存のdelegateを変更すると別の業務へ影響する可能性もあるため、口座分離や権限の再設定を含めて考える必要があります。複数案件、複数エージェント、長期の未決済取引を扱うほど、権限の棚卸しが重要になります。

使い分けでは、資産を事前に拘束できるか、誰を信頼するか、キャンセルや期限切れをどう扱うか、Token-2022の拡張と両立するか、監査人が状態を追えるかを比較します。エスクロー型は条件と状態を明示しやすい一方、専用プログラムの監査と運用が必要です。委任型は構成が比較的軽い一方、エージェントと委任権限への依存が中心になります。

SPL TokenとToken-2022への対応

公式仕様では、資産レッグと支払いレッグの各ミントについてSPL TokenまたはToken-2022を扱えます。つまり、両方がSPL Token、両方がToken-2022、一方ずつを使う組み合わせを検討できます。ただし「プログラム種別に対応する」ことと「すべての拡張の組み合わせで成立する」ことは同義ではありません。

2つのトークンプログラムを扱える

各レッグでは、ミントの所有プログラム、送信元・受取先のトークン口座、decimals、必要な追加アカウントを正しく渡します。Aの債券がToken-2022、Bの支払いがSPL Tokenなら、それぞれ別の命令形式と検証条件を満たさなければなりません。名称やシンボルではなくミントアドレスを許可リスト化し、数量と小数桁をテストします。

事前検証が必要な拡張と失敗条件

必須なのは、Transfer Hook、Transfer Fee、Non-Transferable、Pausable、Default Account Stateなど、移転結果を変える拡張の組み合わせ試験です。Transfer Hookが追加アカウントを要求する、口座が凍結・停止される、手数料控除で受取数量が条件とずれる、といった場合は預託・成立・返還のいずれかが失敗し得ます。Permanent DelegateやTransfer Hookはコンプライアンスに使えますが、誰が変更できるかも監査対象です。

要検証は、拡張設定の更新、エスクロー口座への移転許可、期限切れ返還、受取人側の口座作成です。正常系だけでなく、Aだけが預託した後にミントが停止された場合まで再現します。KYC・AMLや法的適合性はトークン機能から自動的には得られません。一般的な鍵・権限管理は最後のチェック表で担当者まで定めます。

J.P. Morganの関与：確認できること／できないこと

Solana Foundationの発表で確認できるのは、J.P. Morganが決済実務と機関要件の知見を提供したことです。確認できないのは、同行による採用、本番運用、共同商品の提供、顧客資産を使う実取引、コード監査の実施です。

確認できること	確認できないこと
設計に対する実務知見の提供	J.P. Morganによる導入・運用
公式発表での協力者としての記載	共同サービス、取引参加、性能保証

したがって「J.P. Morgan採用」と言い換えず、今後は同行自身の導入発表、対象法人、稼働環境、監査資料が出たかを分けて確認します。

アトミック決済でも残る法的・通貨上の論点

Solana DvPが直接扱うのは、プログラムが認識できるトークンと条件です。その範囲では両レッグを同時に実行できます。しかし、トークンが表す原資産の所有権、裁判上の効力、倒産時の扱い、支払いトークンの償還価値は、スマートコントラクトだけでは決まりません。

この切り分けは、技術を過小評価するためではありません。技術が減らせるリスクを正確に認識し、残るリスクへ契約、法的意見、資産管理、準備資産、業務統制など別の対策を割り当てるためです。「アトミックだから決済リスクがゼロ」とまとめず、リスクの種類ごとに評価します。

トークン移転と原資産の権利移転は同義ではない

トークン化証券には、発行者自身が公式な所有記録としてトークンを使う構造もあれば、第三者が保有する証券への経済的な権利を別のトークンで表す構造もあります。トークンを受け取った人が原資産の直接の所有者になるのか、第三者への請求権を持つのか、議決権や配当請求権があるのかは、発行書類、契約、名簿、準拠法によります。

このため、オンチェーンでトークンが買い手へ移った時点と、法的に証券の権利が移った時点が常に同じとは限りません。トークン台帳と公式名簿のどちらが優先するか、不一致時にどう訂正するか、カストディアンや名義人が誰か、倒産時に顧客資産として分離されるかを確認します。SEC資料も、トークン化の形式によって保有者の権利が大きく異なり得る点を示しています。

技術的確定と法的ファイナリティを分ける

技術的確定は、ネットワーク上で取引が取り消されにくい状態になったことを示します。法的ファイナリティは、適用法のもとで決済がいつ最終となり、後からどのような理由で争われ得るかという問題です。秒単位で技術的に確定するという説明だけでは、無権限取引、詐欺、誤送信、制裁違反、倒産手続きでの効力まで答えられません。

実務では、取引規則に決済完了時点を定義し、ネットワーク記録との対応を明記します。プログラム上の成立、社内台帳への計上、法的名簿の更新、顧客への通知が異なる時点なら、どの時点から市場・信用リスクが移るかも定めます。紛争時の準拠法、裁判管轄、訂正取引の方法、損失負担も必要です。

現金レッグの信用と償還性は別途評価する

支払い側にUSDCなどの民間発行トークンを使う場合、チェーン上で支払いが届いても、それが中央銀行マネーと同じ信用を持つとは限りません。発行者の支払能力、準備資産の質と分別、額面償還の条件、利用者資格、銀行営業時間、手数料、凍結権限、デペッグの可能性が残ります。

反対に、中央銀行マネーや商業銀行預金と接続する場合は、公開チェーンのトークンだけで完結せず、外部システムとの同期が必要になることがあります。Bank of EnglandのProject Meridian Securitiesは、DLT上の証券と中央銀行マネーの決済を同期させる方向を検証しています。どの決済資産を選ぶかは、速度だけでなく信用、流動性、法的地位、アクセス可能性で判断します。

関連する基礎として、民間発行の決済トークンの仕組みや信用リスクはステーブルコインとは何かも参照できます。ただし、名称がステーブルコインでも額面価値が保証されるわけではなく、銘柄と発行構造ごとの確認が必要です。

外部台帳との接続と流動性の課題

資産レッグと資金レッグが同じSolana上にあり、一つの取引で両方を更新できるなら、技術的な原子性を設計しやすくなります。しかし、証券がSolana、資金が銀行のRTGS、所有者名簿が別のデータベースにある場合、複数システムの状態を同時にそろえなければなりません。

外部台帳が停止したり、メッセージが遅れたり、一方では確定したのに他方では拒否されたりすると、同一台帳内で避けた片渡しが別の境界で再び生じ得ます。接続方式には資産のロック、条件付き支払い、コーディネーター、タイムアウトなどが考えられますが、それぞれ新たな信頼対象と障害点を持ちます。

別台帳連携では元本リスクが再び生じ得る

別台帳間で「ほぼ同時」に二つの処理を行うだけでは、厳密な原子性とは限りません。一方が最終化した後にもう一方が失敗すれば、参加者は受け取るはずの資産を得られない可能性があります。同期のための中間者がいる場合は、その中間者の権限、可用性、破綻時の扱いも評価対象です。

Project Juraのような実証は、ホールセールCBDCとトークン化資産を組み合わせたDvPや、複数通貨のPvPについて技術的可能性を示しました。ただし、技術実証は中央銀行が実際にその通貨を発行する政策判断や、非居住金融機関へアクセスを認める制度判断を代替しません。実証で動いた範囲と商用制度の範囲を混同しないことが大切です。

Project Jura、Agorá、Meridianなどの実証が示すのは、DLT資産と中央銀行・商業銀行マネーを同期する選択肢です。Solana DvPの性能や商用統合を証明するものではありません。比較で重要なのは、資産と資金が同一台帳にあるか、実資金か、既存RTGS・名簿とどこまで接続したかという境界です。

即時決済は流動性需要を増やす可能性がある

決済期間を短くすると、相手方の信用にさらされる時間を縮められます。一方、取引を即時かつグロスで決済するには、その瞬間に売却資産と支払資金の両方を用意しなければなりません。従来は複数取引を相殺して差額だけを用意できた場面でも、個々の取引を即時決済すると日中流動性や事前資金の需要が増える可能性があります。

エスクローへの事前預託も同じトレードオフを持ちます。片渡しを防ぐ代わりに、成立まで資産を他用途へ使えません。参加者は、決済リスク削減の効果と、担保・現金の拘束、資金調達費用、キャンセル率、ピーク時の残高を比較します。アトミック化すれば必ず全体コストが下がるとは断定できません。

導入判断：本番前チェックリスト

最後は既出論点を説明し直すのではなく、導入可否を決める成果物へ落とします。優先度が「必須」の項目が未決なら本番へ進まず、「要検証」は試験結果と残余リスクを承認者へ示します。

優先度・確認対象	失敗時の影響	主な責任者
必須：権利移転時点、準拠法、倒産時の扱い	トークンを得ても法的権利を得られない	法務・商品責任者
必須：決済資産の発行者、償還、凍結、デペッグ	受領額の価値や換金性が不足する	財務・リスク管理
必須：監査対象コミット、プログラムID、更新権限	脆弱性や無承認変更で資産を失う	技術責任者・監査担当
必須：鍵の多者承認、上限、失効、復旧	不正移転または業務停止	セキュリティ・運用
必須：KYC・AML、制裁、ウォレットと顧客の対応	禁止取引や報告漏れ	コンプライアンス
要検証：片側未預託、期限切れ、停止ミント、RPC障害	成立不能、返還遅延、状態誤認	開発・SRE・業務運用
要検証：事前預託額、ピーク残高、資金調達費	流動性不足や採算悪化	財務・トレジャリー
状況次第：外部名簿、銀行、カストディとの同期	システム境界で片渡しが再発	アーキテクト・各接続先

試験証跡には取引ID、署名、承認、照合結果、例外処理を残します。障害時は停止判断者、顧客連絡、当局報告、残高照合、再開承認を決め、結果不明の命令は状態照会後に再送します。責任分界を契約と手順書の両方に反映して、初めて運用可能性を評価できます。

承認会議では、取引成功率だけでなく、片側だけの預託件数、期限切れから返還までの時間、手動介入件数、資産拘束時間、照合不一致、権限変更の履歴を提示します。小額・限定参加者の段階から上限を設け、異常時に新規取引を止めても既存エスクローを安全に成立または返還できるかを確かめます。外部委託先がある場合は、サービス水準だけでなく、ログの取得権、事故通知の期限、再委託、契約終了時の鍵とデータの引継ぎも対象です。

また、法務・技術・業務が別々に「問題なし」と判定するだけでは不十分です。同じ取引IDを基準に、オンチェーン残高、顧客台帳、会計記録、法的名簿が一致することを通しで試験します。返還できたことだけでなく、返還後に顧客へ何を通知し、手数料や価格変動の損失を誰が負担するかまで合意しておくと、標準の採用可否を具体的に判断できます。

まとめ：Solana DvPは同時交換の標準、決済全体の保証ではない

Solana DvPは、資産トークンと支払いトークンをプログラム所有の分離エスクローへ預け、条件成立時に同時交換し、期限切れ時に返還できる機関向け標準です。オンチェーンの片渡しを防ぐという課題に対し、再利用可能な仕組みを提供します。SPL TokenとToken-2022へ対応し、委任型とは異なる信頼境界を持ちます。

一方で、アトミック実行は、原資産の法的権利、法的ファイナリティ、決済トークンの信用、外部台帳との同期、流動性、鍵管理、規制対応を自動的に解決しません。J.P. Morganの関与も、公開情報上は決済実務の知見提供であり、採用や本番取引の確認ではありません。

導入可否を判断するときは、「両レッグを同時に動かせるか」に加え、「何の権利が移るか」「何で支払うか」「失敗時に誰が戻すか」「外部システムとどこで接続するか」を順に確認してください。技術標準の価値と残る制度・運用リスクを分けて見ることが、過大評価にも過小評価にもならない出発点です。