Rippleは、複数の台帳操作をまとめて成功または失敗させることができるXRP LedgerのBatchトランザクションを、資産運用会社が利用に向けて準備していると発表しています。しかし、緊急のソフトウェアリリースにより、注目は9月29日の有効化見込みから10月9日のセキュリティ修正へと移りました。この機能そのものは具体的であり、機関採用が依然として実現前の段階であることを示す証拠もまた具体的です。

中心的な約束はシンプルです。関連する一連の手順を1回の台帳締めのうちに決済すること。トークンを引き渡して支払いを受け取る必要がある資産運用会社は、先に資産を送金して入金を待つのではなく、オール・オア・ナッシングの交換を好むかもしれません。交換の両側を1ステップで決済することは、従来の証券市場で長年確立されてきたDVP(デリバリー・アンド・ペイメント)規律であり、Batchはその台帳ネイティブ版を提供するよう設計されています。RippleXは、この機能の準備を進める資産運用会社や商用プロジェクトについて、機関の関心に関する先行報道で取り上げた通り説明しています。ただしその説明の中で、メインネットでBatchトランザクションを実際に稼働させている実運用の資産運用会社が名指しで公表されることはありませんでした。

JUST IN: Brad Garlinghouse highlights why Ripple cannot control the $XRP Ledger Ripple operates only a small share of XRPL validators, and the $150M+ hack involving co-founder Chris Larsen showed that the company cannot reverse transactions or recover lost $XRP . pic.twitter.com/Pt4czYNSf1 — crypto.news (@cryptodotnews) September 27, 2026

タイムラインは当初の9月末の見込みより前に変わりました。XRP Ledger財団のリリース告知は、バージョン3.4.1をセキュリティに関わる問題への緊急アップデートとして位置付けています。この版ではfixBatchV1_2が追加され、サーバーに速やかなアップグレードを求めるとともに、絶対多数の支持が続けば10月9日に修正が有効になる見込みとされています。XRP Ledgerでの修正の有効化は一方的なスイッチではなく分散型のバリデータ投票に委ねられているため、タイミングは特定の組織ではなくネットワークの運営者に左右されます。これは条件付きの見込みであり、確定したローンチの約束ではありません。

Batchは1回の台帳締めの中で操作を調整する

XLS-0056仕様は、2〜8件の内部トランザクションを保持する外側のトランザクションを記述しています。関係するアカウントはこのまとまりを承認し、選択されたモードが内部操作が失敗した場合の挙動を制御します。台帳はこのまとまりを1回の締めで処理するため、個別に送信されたトランザクションの間に生じる隙間、すなわち一方の参加者だけが取引の一部だけを持つ事態を回避できます。

例えば、ファンドがトークン化された債券クレームを譲渡し、ドルトークンを受け取るケースを考えます。通常の2件のトランザクションを別々に送信した場合、最初が成功して2件目が失敗すると、当事者間に運用上の争いと損失の可能性が生じます。オール・オア・ナッシングモードでは、意図した交換が完了するには両方の内部操作が成功しなければなりません。トークン、支払手段、取引相手、権限がすでに整っている前提で、これが機関にとって最も説得力のあるユースケースです。

Batchは債券を作成したり、オフチェーンの所有権を検証したり、銀行に支払トークンの償還を強制したりするものではありません。Batchがうのは台帳操作の調整です。法的な決済の最終性、譲渡制限、保管、償還は依然として関連する制度や機関に依存します。技術的にアトミックな譲渡は、DVPの一部にすぎないため、この区別は重要です。

JUST IN: $XRP Ledger's Batch feature passes, set for activation on September 29 The upgrade, which has secured 29 Yes votes, will allow up to 8 XRPL transactions to be bundled into one, enabling atomic asset swaps, bundled DEX trades, $NFT -for- $NFT exchanges and single-transaction… pic.twitter.com/7CH34N1Yat — crypto.news (@cryptodotnews) September 15, 2026

単一アカウントのチュートリアルは、より単純なケースを示しています。1つのアカウントからの複数の操作を、指定したモードでパッケージ化できます。マルチアカウントトランザクションでは、残高や権限が影響を受けるアカウントの署名が加わります。その調整された署名プロセスはマルチアカウントのチュートリアルで説明されています。

4つのモードが4つの異なる取引条件を生む

ALLORNOTHINGは純粋な双方向取引です。必要な内部操作がすべて成功しなければ、意図したグループは決済されません。ONLYONEは代替案を試し、最初の成功で停止します。例えば異なる許容価格での注文などです。UNTILFAILUREは失敗に達するまで一連の処理を実行します。INDEPENDENTは同一ラッパー内の操作が個別に成功または失敗することを許容します。4つのモードすべてを日常的な意味で「アトミック」と呼ぶと、部分実行の可能性が隠れてしまいます。

モードは製品設計を左右します。1件の支払いに対して2つの資産を動かすファンドは、単一の失敗した譲渡がパッケージ全体を取り消すべきかを判断する必要があります。フォールバック注文を出すマーケットメイカーはONLYONEを好むかもしれません。複数の支払いを配信する発行者は独立した結果を受け入れられるかもしれませんが、その場合、運用チームはどの受取人に支払われたかを突き合わせる必要があります。モードはリスクの決断であり、フォーマットの選択ではありません。

8操作の上限も現実の制約です。1,000件の投資家への送金を決済しようとする運用会社は、現行の提案では1,000件すべてを1つのBatchにまとめられません。8操作パッケージ理論上最小の125パッケージであっても、それらのグループ同士はアトミックではありません。手数料、署名、アカウントシーケンス管理、サービス容量は、オフチェーンの業務プロセスを考慮する前から実際的な制約となります。

先行の技術レポートは、このアップグレードの長い開発と監査の歴史に言及しています。この経緯はタイミングの判断には関連しますが、その上に構築されたすべてのアプリケーションが監査済みだとする主張と混同すべきではありません。

外側の成功コードは会計上の罠

仕様によれば、内部トランザクションが失敗しても、外側のBatchトランザクションはtesSUCCESSを報告できる可能性があります。外側の結果が対象とするのはシーケンスと手数料の処理です。支払いや引き渡しが実際に発生したかを知るには、ソフトウェアが内部トランザクションのメタデータ個々の結果コードを検査する必要があります。汎用的な成功ステータスを資産移動の計上に変換するバックオフィスを持つ機関にとって、これは極めて具体的な統合リスクです。

外側の結果のみを読み取り、トークン化された証券を顧客に計上するトレードフィードを想像してください。該当する内部譲渡が成功していなければ、フィードと台帳は食い違います。システムはすべての内部操作をその親トランザクションおよびその結果と関連付ける必要があります。仕様は、エクスプローラやインデクサでParentBatchIDの関係を利用することを推奨しており、トレーディングデスクは正常系だけでなくすべてのモードで失敗をテストすべきです。

外側のトランザクションは実在しトランザクションIDを持つため、この誤りは通常の管理統制をすり抜ける可能性があります。1トランザクション=1業務取引を前提に構築された照合システムは、最初のチェックを通過してしまうかもしれません。適切な統制は、業務指示をモード、完全な署名済みパッケージ、すべての内部結果、そして最終的な資産残高と紐付けます。これは、ネットワーク層が正しく動作していても、資産運用会社が果たさなければならない作業です。

JUST IN: Asset managers are preparing for $XRP Ledger's next payments upgrade Batch V1.1 can bundle up to eight transactions into one operation, with RippleX saying commercial projects are already being built around the feature ahead of activation. pic.twitter.com/DmleX4GBiA — crypto.news (@cryptodotnews) September 20, 2026

計算は地味ですが示唆的です。8つの内部トランザクションを含む最大サイズのBatchは外側の送信としては1件ですが、少なくとも8回の結果確認に加え、外側の手数料とシーケンスの確認が必要になります。1,000の内部操作を表す125の完全なパッケージでは、バックオフィスに必要なのは125個の緑色のステータスではなく、1,000件の操作レベルの結果です。

セキュリティ修正が有効化のストーリーを変える

財団の9月25日の告知によると、fixBatchV1_2は誤ったラッパーの内部トランザクションを拒否するほか、追加のセキュリティおよび安定性の修正を含みます。この変更のセキュリティに関わる性質のため、ソースコードは一時的に非公開とされ、後日の公開と振り返りが約束されています。これにより、公開前に外部者が正確なパッチを検証することは制限されます。この種の一時的なコード非公開は、ソフトウェア業界で広く行われている協調脆弱性開示の慣行です。これは正確な帰属を保つ理由ではあっても、未公表の悪用可能性を推測する理由ではありません。

告知によれば、3.4.1満のサーバーは、修正が有効になった時点でアップグレードしていない場合、amendment blocked(修正ブロック)状態になります。したがって、バリデータの投票とノードのアップグレードは本番アクセスにとって重要です。支持を示すクォーラムの形成は、すべてのウォレット、カストディアン、APIプロバイダ、会計ツールがBatchに対応したことを意味しません。以前のXRPLノードアップグレードの報道は、先行リリースにおける修正ブロックの運用上の影響を示しています。

省略できない歴史もあります。2月の脆弱性開示では、資金のない署名者が先頭に現れた場合に他の署名者の認可チェックをスキップしうる、初期のBatch設計の欠陥が記述されていました。当該修正はまだ稼働していませんでした。セキュリティ監査に関する報道は、独立したレビューが実運用前に問題を捕捉した経緯を検証しています。9月のパッチは別途記述されたラッパーの問題に関するものであり、どちらの事例も現行設計が安全でないことを証明するものではありませんが、いずれも展開時期が精査に値する理由を説明しています。

機関が得られるものと、依然として必要なもの

支払いに対するアトミックな引き渡しが最も強力なユースケースです。運用会社は同じ台帳上でトークンの譲渡と支払いを調整し、逐次送金が生む一時的なエクスポージャーを限定できます。発行者は、プロトコルが許容するトランザクションタイプであれば、アカウント設定、認可、発行手順をまとめられます。取引会社は代替の執行経路を利用できます。これらはあくまで能力であり、実際の資産や取引が存在することの証拠ではありません。

トークン化資産には、発行者、トランスファーエージェントその他の責任主体、適格保有者の規則、保管手続き、許容できる償還条件を備えた支払手段が必要です。Batchはオンチェーンの足を所定のルールで実行させることはできますが、別の管轄で証券を法的に有効にしたり、無関係な操作に対する顧客の同意を得たり、商業銀行での外部キャッシュレッグを保証したりすることはできません。より広い背景として、資産運用業界がトークン化ファンドや債券の実験を続けていることがあり、実運用の取引量が存在する前から決済メカニクスは繰り返し問われる運用上の課題であり続けています。

Rippleの主張はその最も強い形で評価されるべきです。台帳レベルのメカニズムは開発者の調整作業を減らし、部分決済の失敗という現実のクラスを排除できます。XRPLの機能概要は、他の機関向け機能と並べてBatchを紹介が、各修正はそれぞれ独自のプロセスを踏みます。今後、名指しされた運用会社が、正しく照合された内部結果とともに実際のトークン化資産のライブかつ反復可能な決済を示せば、採用の主張には確固たる裏付けが伴うことになります。

限界も同様に明確です。パイロットを準備している会社は、Batchを実運用で使う資産運用会社ではありません。公表されている準備の主張からは、取引量、削減された手数料、回避された決済紛争、あるいはどの機関がオフチェーンの義務を負うかは分かりません。発表が真実であっても、それだけではより大きな結論を支えるには早すぎる場合があります。

台帳の投票は準備状況の最初のテストにすぎない

fixBatchV1_2の10月9日有効化の見込みは、バリデータの支持が持続するかにかかっています。運営者は互換性のあるソフトウェアを実行する必要があります。仕様が推奨する通り、ウォレットは署名を求める前に、ユーザーにすべての内部操作と選択されたモードを表示しなければなりません。インデクサは親と子の結果を公開する必要があります。カストディアンにはマルチアカウント署名に対するポリシーチェックが求められます。資産運用会社には照合と法務文書が必要です。

こうした準備状況すべてを示す単一の数値は存在しません。バリデータの投票はプロトコル変更への合意を測るものです。本番のテストは、実際のユーザーが記録の不一致なく、失敗したBatchの準備、署名、送信、検査、復旧を行えるかどうかにあります。未解決の商業的問いは、修正とツール群が稼働した後、どの名指しされた機関が反復可能なユースケースを示すかというものです。

注目ポイント

• 修正の状況:fixBatchV1_2が支持を維持し、想定された10月9日に有効化されるかどうか。
• サーバーのアップグレード:セキュリティ修正が必須になる前に3.4.1を実行している運営者の割合。
• 情報開示:非公開とされているパッチソースの公開と、約束された振り返り。
• 内部結果:モード表示、親リンク、操作レベルの結果に対するウォレットとインデクサの対応。
• 本番の証拠:ライブのBatch取引量とその決済統制を報告する、名指しされた資産運用会社。

FAQ

XRPL Batchは現在メインネットで稼働していますか?

関連する修正とその稼働状況は、公開時点で確認する必要があります。9月25日のリリースでは、バリデータの支持が続けば10月9日に有効化される見込みのセキュリティ修正が説明されていました。

1つのBatchに含められるトランザクションの数は?

公開されているXLS-0056仕様では、現行設計における内部トランザクションは最小2件、最大8件と定められています。

###はすべての内部操作の成功を保証しますか?

グループ全体の同時成功を前提に設計されているのはオール・オア・ナッシングモードのみです。他のモードは意図的に異なる部分実行のパターンを許容します。

1つの資産運用会社がすべての取引相手に代わって署名できますか?

いいえ。マルチアカウントのBatchでは、影響を受けるアカウントがプロトコルの署名ルールに従って署名済みのまとまりを承認する必要があります。

tesSUCCESSは取引が決済済みであることを意味しますか?

それ単独では意味しません。外側の結果が成功していても内部操作が失敗している可能性があるため、システムは各内部結果と残高を検査する必要があります。

Batchによってトークン化証券は法的に決済されますか?

Batchはオンチェーンの手順を調整できます。法的権利、償還、および外部の支払レッグは、資産の条件と適用されるインフラに依然として依存します。

バージョン3.4.1で何が変わりましたか?

財団は、誤ったラッパーの内部トランザクションの拒否を含むfixBatchV1_2を追加する緊急セキュリティリリースであると説明しています。

資産運用会社はライブ利用を実証していますか?

Rippleは準備を進めていると報告していますが、引用された公開情報の中で、反復可能なライブのBatch決済を実運用で行う運用会社は名指しされていません。

これは投資助言ではなく教育的分析です。本記事は情報提供および教育目的のみを意図したものであり、金融または投資に関する助言を構成するものではありません。記載の数値は執筆時点で入手可能な規制届出および報道に基づき、開示のたびに変動します。いかなる証券または資産の売買・保有の推奨も含みません。必ずご自身で調査してください。情報は2026年9月29日時点で正確です。