XRPレジャー（XRP Ledger・XRPL）では、重大な署名検証バグによって撤回されたバッチ機能の置換版であるバッチV1.1（BatchV1_1）が、次期ソフトウェア向けに実装されている。権限委任V1.1（PermissionDelegationV1_1）、機密送金（ConfidentialTransfer）、スポンサー（Sponsor）、動的多目的トークン（DynamicMPT）も開発コードへ取り込まれているが、5機能がメインネットで正式な検証者投票へ入ったことは確認できない。今回見るべきなのは新機能の数ではなく、脆弱性の発見、旧機能の停止、別識別子での再実装、正式リリース、検証者合意という段階を分けて管理できるかである。
何が起きたのか？
旧バッチ機能は、複数の取引を一つに束ね、指定した条件に従って処理するために設計された。しかし2026年2月、内部取引の署名確認に重大な欠陥が見つかった。
問題を発見したのは、プラナミャ・ケシュカマット（Pranamya Keshkamat）氏と、セキュリティ基盤カンティナAI（Cantina AI）の解析システムであるエイペックス（Apex）だった。静的解析による報告を受け、開発側が再現コードと単体試験で影響を確認した。
欠陥が悪用された場合、一部の署名者を確認した段階で、内部取引全体に必要な承認まで完了したように扱われる可能性があった。攻撃者が対象口座の秘密鍵を持たなくても、資金移動や台帳状態の変更を実行できる深刻な問題だった。
旧バッチはメインネットで有効になる前の投票段階にあり、利用者資産の流出は確認されていない。検証者には反対票を投じるよう通知され、緊急版リップルド3.1.1ではバッチ（Batch）と内部署名修正機能のfixBatchInnerSigsが非対応に変更された。開発用ネットワークは更新に伴ってリセットされたが、メインネットには同機能が導入されていなかった。
現在、修正内容を取り込んだバッチV1.1が旧版とは異なる識別子で実装されている。ただし、公式の既知の修正機能一覧では正式リリースやメインネット投票の開始を確認できず、開発ブランチへの統合と本番採用は区別する必要がある。
なぜ重要なのか？
ブロックチェーンでは、開発コードへ機能が追加されたこと、安定版ソフトウェアとして配布されたこと、検証者が支持したこと、本番環境で有効になったことは、それぞれ別の段階である。コードが完成しても、ネットワーク規則が自動的に変わるわけではない。
XRPLの修正機能は、各サーバーが信頼する検証者の80％を超える支持が2週間続いた場合に有効化される。支持率が条件以下へ下がれば期間はリセットされる。これは全世界の検証者を一つの機関が中央集計する仕組みではなく、各運営者が設定する信頼対象を基に合意状況を判断する方式である。
旧バッチの被害を防いだ直接の要因は、外部研究者による発見と責任ある開示だった。投票期間そのものがバグを見つけたわけではない。ただし、機能がまだ有効化されていなかったため、問題のある規則が本番台帳へ入る前に停止できた。
修正版の存在も安全性を保証しない。安定版への搭載、追加レビュー、試験環境での動作確認、検証者の投票を経て初めて、本番利用に耐えるかが判断される。
市場構造への影響
バッチV1.1は機関専用ではなく、複数処理をまとめる汎用的な基盤である。承認されれば、資産発行、権限設定、送金などを指定した実行条件の下で処理し、不完全な状態が残る危険を抑えられる可能性がある。
権限委任V1.1も、バグによって無効化された旧権限委任機能の置換版である。口座の全権限を渡さず、許可した操作だけを別の口座へ任せる構想で、資産保有者と日常業務の担当者を分ける運用に関係する。
スポンサーは、企業や発行者が利用者の取引手数料や口座準備金を補助しながら、利用者自身が鍵と口座の管理権を維持するための機能である。機密送金は、多目的トークンの残高や送金額を公開台帳上で秘匿しつつ、発行者や監査主体などが必要な情報を検証できる仕組みを目指している。
動的多目的トークンは、発行時に変更可能と指定した特定属性を後から更新できるようにする構想であり、すべての設定を自由に書き換える機能ではない。これらは機関利用にも関係するが、正式リリース、投票、有効化、ウォレット対応が完了するまでは利用可能な本番機能ではない。
資金・規制・流動性との関係
金融機関が台帳上で資産を扱う場合、処理速度だけでなく、操作権限、費用負担、情報開示、監査可能性を管理しなければならない。今回の機能群は、それぞれ異なる運用上の課題へ対応する部品として設計されている。
権限委任とスポンサーが実用化されれば、資産を保有する秘密鍵を業務担当者へ渡さず、事業者が利用費用を負担するサービスを構成しやすくなる。ただし、スポンサーが負担する金額や対象取引をどこまで制御できるかは、正式仕様と実装を確認する必要がある。
機密送金も匿名化によって規制対応を不要にする仕組みではない。本人確認、不正資金対策、監査、当局からの開示要求へ対応できる情報アクセスがなければ、金融事業での導入は難しい。
また、修正機能が有効になった後、非対応のサーバーは新しい台帳規則へ正常に追随できない状態になる可能性がある。80％条件を決める検証者投票と、一般ノードや関連サービスの更新状況は別だが、どちらも業務継続には欠かせない。
初心者向け補足
XRPLの修正機能とは、台帳上の取引規則を追加または変更する仕組みである。アプリへボタンを追加する更新とは異なり、有効化されるとネットワーク全体が新しい規則に基づいて取引を処理する。
検証者は、取引と次の台帳内容が正しいかを確認するサーバーである。誰か一社がすべての検証者を任命するのではなく、各サーバー運営者が信頼する検証者群を設定する。
今回の5機能は、開発コードへ実装されていることが確認できる一方、すべてが安定版へ正式搭載され、メインネット投票に入ったとは確認できない。開発中、正式リリース済み、投票中、有効化済みという段階を混同しないことが重要である。
Web3Timesの視点
今回の評価軸は、5つの機能が機関向けサービスを便利にするかだけではない。旧バッチでは、署名検証の一部にある小さな処理ミスが、他人の口座から内部取引を実行できる重大な危険へつながった。
その後、旧機能への反対投票が促され、緊急版で非対応化され、置換版が別の識別子として再実装された。この手順により、旧コードと修正版を区別し、検証者が改めて採否を判断できる。
同時に、検証者投票が存在するから開発主体の影響がなくなるわけではない。どの機能を実装し、どのリリースへ含め、既定の投票方針をどう設定するかは開発と配布を担う側の重要な判断である。
次に確認すべきなのは、バッチV1.1などがどの安定版へ搭載されるか、公式の既知の修正機能一覧で投票状態がどう変わるか、外部監査や試験結果が公開されるかである。新機能の豊富さより、脆弱性を本番導入前に止め、修正版を再び公開検証へ戻せる工程こそ、XRPLを長期的な資産基盤として評価する材料になる。
