Last Updated on 2026年9月21日 by oba3
XRPレジャー（XRP Ledger・XRPL）が、複数の取引を一つにまとめて原子的に処理する「Batch V1.1」の有効化へ向けた段階に入っている。最大8件の取引を同じバッチへ格納でき、「すべて成功するか、すべて失敗するか」を選択できるため、トークン化資産の移転と代金支払いを同じ処理単位で成立させることが可能になる。これはXRPの価格材料としてではなく、資産を渡したのに代金を受け取れないといった決済リスクをオンチェーン上で減らす機能として見る必要がある。特に証券、ファンド持分、担保などがXRPL上で扱われる場合、資産側と支払い側を別々に処理していた市場業務をDvP型へ近づける基礎機能になり得る。
何が起きたのか？
XRPLの参照サーバーソフトウェア「xrpld」3.3.0は2026年8月6日に公開され、Batch V1.1が新しいAmendmentとして実装された。Batchトランザクションでは最低2件、最大8件の内部取引を一つの外側トランザクションへまとめられる。
処理方法は4種類あり、機関決済で特に重要なのが「All or Nothing」だ。このモードでは内部取引の一つでも失敗すれば、他の取引も成立しない。例えば一方の口座からトークン化資産を送り、もう一方から代金となるステーブルコインを送る二つの取引を同じバッチへ入れれば、片方だけが成立する状態を避けられる。
複数アカウントが参加するバッチにも対応しており、それぞれの関係者による承認が必要になる。仕様ではトークンやNFTを異なる口座間で信頼を置かず交換する用途も想定されている。
Batch V1.1は9月15日にメインネットで必要な80％超のバリデーター支持を記録した。XRPLではこの水準を連続2週間維持するとAmendmentが有効化されるため、支持が維持されれば9月29日前後に利用可能になる見通しだ。現時点ではまだ有効化前であり、日付は最終確定ではない。
なぜ重要なのか？
金融取引では、売買が合意されたことと決済が完了したことは別だ。例えばトークン化された債券を買う場合、買い手から代金が送られたのに債券が届かない、あるいは売り手が債券を移転したのに支払いが完了しないという片側決済のリスクがある。
伝統金融ではこれを減らすため、証券の受け渡しと資金決済を連動させるDvP、つまりDelivery versus Paymentが使われる。Batch V1.1自体が証券専用のDvPサービスを提供するわけではないが、資産移転と支払いを同じ原子的な処理へまとめることで、その仕組みをオンチェーン上に構築しやすくする。
重要なのは高速化だけではない。二つ以上の処理の間に生じる時間差と相手方リスクを、プロトコル側の処理条件で小さくできる点にある。
市場構造への影響
トークン化金融では、資産をブロックチェーンへ載せるだけでは市場基盤は完成しない。発行された資産を売買した後、誰が資金を払い、誰が所有権を受け取り、その二つをどのタイミングで確定させるかまで設計する必要がある。
Batch V1.1では異なる口座の取引も同じバッチへ入れられるため、複数の金融主体が参加する処理にも応用できる。資産運用会社、取引所、カストディ、マーケットメーカーなどが別々の口座を利用していても、必要な署名を集めたうえで一連の処理を一括実行する設計が可能になる。
これによりXRPLの競争軸も、単純な送金速度から、複数の金融処理を安全に組み合わせられるかへ広がる。トークン化資産が増えるほど、発行機能だけでなく決済時の原子性が重要になるためだ。
資金・規制・流動性との関係
原子的決済は決済リスクを減らせる一方、流動性管理の方法も変える。従来型市場では取引をまとめて相殺するネッティングによって必要資金を圧縮する仕組みがある。すべての取引を即時かつ総額で決済すれば、参加者が事前に用意する資金や資産が増える場合もある。
そのため機関投資家にとって重要なのは「即時決済できるか」だけではない。どの資産を支払い手段として使うのか、資金をいつ確保するのか、失敗したバッチをどう再処理するのか、既存のカストディや会計システムとどう接続するのかまで含めた設計が必要になる。
またBatch V1.1が有効化されても、そこに載る証券やファンドが自動的に規制要件を満たすわけではない。原子的処理は技術的な決済機能であり、資産発行、本人確認、保管、投資家資格などの制度要件とは別に管理する必要がある。
初心者向け補足
原子的決済とは、複数の処理を「全部成功するか、全部取り消すか」にする仕組みだ。例えばAさんが100ドル相当のトークンをBさんへ送り、Bさんが代わりに100ドルのステーブルコインをAさんへ送る場合、片方だけ成功すると一方が損失を負う可能性がある。
Batch V1.1のAll or Nothingを使えば、両方が成功できる場合だけ処理を成立させられる。最大8件までまとめられるため、単純な二者間交換だけでなく、手数料支払いなどを含む複数工程にも利用できる。
なお、Batch V1.1は以前のBatch機能を修正したものだ。旧版では2026年2月に内部取引の認証に関する重大な脆弱性が発見され、有効化前に停止された。修正版では認証処理が見直され、3.3.0へBatch V1.1として再実装されている。
Web3Timesの視点
Batch V1.1を見るうえで、最大8件の取引をまとめられること自体が最も重要なわけではない。機関金融にとって価値があるのは、資産と資金という異なる移転を一つの成否条件へまとめられる点だ。
今後見るべきなのはAmendmentの有効化だけではない。資産運用会社や取引所が実際にどの資産と決済通貨を組み合わせるのか、ステーブルコインやトークン化預金とのDvPが実装されるのか、さらに即時決済とネッティングによる資金効率をどう両立させるのかが焦点になる。
トークン化金融では「資産をオンチェーンで発行できる」段階から、「資産と代金を安全に交換できる」段階へ移る必要がある。Batch V1.1はその決済部分を支える汎用機能であり、XRPLが機関向け市場で評価される際も、XRPの値動きではなく、現実の金融取引をどこまで原子的に完結できるかが重要な指標になる。
