Last Updated on 2026年9月24日 by oba3
XRPレジャー（XRP Ledger・XRPL）が、口座の権限を別のアカウントへ限定的に委任できる「Permission Delegation」の修正版を再び導入している。2026年8月に公開されたXRPLの参照サーバーソフトウェア「xrpld 3.3.0」には、修正版となるPermissionDelegationV1_1が追加された。
この機能のポイントは、単に別のウォレットへ送金権限を渡せることではない。金融機関では、資金を保有する主体、送金を実行する担当、本人確認や規制対応を管理する担当などが分かれている。XRPL上でも権限を細かく分離できれば、銀行が既存業務で採用している役割分担を、オンチェーン決済の運用へ持ち込みやすくなる可能性がある。
何が起きたのか？
XRPLでは、特定のアカウントが保有する権限の一部だけを別のアカウントへ与えるPermission Delegationの開発が進められてきた。委任元となるアカウントは、別のアカウントに対してPaymentなど特定種類の取引を実行する権限を設定できる。
たとえば資産を保有するメイン口座の秘密鍵を日常業務から切り離したまま、別の業務用口座だけに送金権限を与えることができる。トークン発行者であれば、送金担当、トラストライン管理担当、本人確認を担う外部事業者などへ異なる権限を割り当てる設計も可能になる。
ただし、この機能は一度そのまま導入されたわけではない。旧PermissionDelegationでは2025年9月、委任取引の手数料処理に関する重大な不具合がテスト中に発見された。問題のある機能はメインネットでは有効化されておらず、バリデーターに反対票を投じるよう案内された後、旧版は無効化された。
その後、問題を修正したPermissionDelegationV1_1が開発され、2026年8月公開のxrpld 3.3.0へ組み込まれた。今回の動きは新機能の初登場というより、安全上の問題を受けて設計を修正し、再びネットワークでの導入プロセスへ戻したものと位置付けられる。
XRPLの新機能はソフトウェアへ追加されただけで自動的にメインネットへ適用されるわけではない。Amendmentと呼ばれる仕組みによってバリデーターが投票し、80％を超える支持を2週間維持することで有効化される。このため、ソフトウェアへの実装とメインネットで利用可能になる時点は分けて考える必要がある。
なぜ重要なのか？
銀行や決済会社の業務では、一人の担当者や一つのシステムが資金管理から規制確認、送金実行までをすべて自由に操作できる構造は一般的ではない。内部統制のため、業務ごとに権限を分離し、必要な操作だけを担当者やシステムへ許可する。
一方、ブロックチェーンでは秘密鍵を持つ主体が口座を広く操作できる設計が多く、金融機関が既存の権限管理をそのまま移植することが難しい場合がある。マルチシグによって複数署名を要求することはできても、「この担当者には送金だけ」「この事業者には本人確認後の承認だけ」といった業務単位の分離とは目的が異なる。
Permission Delegationは、この差を縮めるための仕組みになる。XRPLの仕様では、委任先へ取引種類単位またはより細かな権限を与えられるため、資産の所有者と実際の業務実行者を分離できる。
金融機関にとって重要なのは、オンチェーン取引の速度だけではない。誰がどの操作を実行できるのかを管理し、秘密鍵が侵害された場合の影響範囲を限定できることも、実運用へ組み込む条件になる。
市場構造への影響
この仕組みを市場構造から見ると、ブロックチェーンが金融機関の既存業務へ合わせ始めている点が重要になる。
初期の暗号資産では、ユーザー自身が秘密鍵を保有し、自分で取引へ署名するモデルが中心だった。しかし銀行や資産管理会社では、資金保有者、決済システム、コンプライアンス部門、外部カストディアンなど複数主体が一つの取引に関わる。
Permission Delegationでは、資産を保有するアカウントを維持したまま、決済処理を別の業務用アカウントへ任せることができる。さらにXRPLには、本人確認や法的資格などを証明するCredentialsや、入金相手を制限するDeposit Authorizationといった機能も用意されている。
これらが組み合わされば、本人確認を行う主体と、実際に送金を実行する主体を同じ組織にする必要はなくなる。外部の本人確認事業者が資格情報を発行し、金融機関側がその結果を使って取引可否を判断し、別のシステムが決済を実行するという役割分担も設計しやすくなる。
つまりオンチェーン決済が、単一ウォレットによる自己管理モデルだけでなく、既存金融で一般的な職務分掌を表現できるインフラへ近づくことになる。
資金・規制・流動性との関係
金融機関がブロックチェーン決済を導入する際には、資金移動そのものと同じくらいコンプライアンス処理が重要になる。送金元と送金先の確認、制裁対象との照合、顧客確認、取引権限の管理などを既存業務と整合させる必要があるためだ。
XRPLのCredentialsでは、特定のユーザーが必要な資格条件を満たしていることを台帳上で確認する仕組みが用意されている。Deposit Authorizationと組み合わせれば、特定条件を満たす相手からだけ資金を受け取る構成も可能になる。
Permission Delegationは、そのコンプライアンス判定を誰が管理し、誰が実際の取引を送信するかという運用面を補う。すべての権限を一つのホットウォレットへ集約せず、業務に必要な操作だけを別アカウントへ与えられるため、金融機関が内部統制を保ったまま決済を自動化しやすくなる余地がある。
これは直接、流動性を増やす機能ではない。ただし銀行や決済会社がオンチェーン資産を扱う際の運用障壁が下がれば、ステーブルコイン、トークン化預金、RWAなどを既存の決済業務へ接続できる参加者が増える可能性がある。
一方、技術的に権限分離ができることと、各国の金融規制を満たすことは別問題だ。必要な本人確認、取引監視、記録保存、責任分界は地域や金融商品によって異なる。XRPLの機能はそのための技術部品になり得るが、規制対応そのものを自動的に保証するわけではない。
初心者向け補足
Permission Delegationは、自分の口座を他人へ丸ごと渡す仕組みではない。メイン口座が保有する権限のうち、必要な操作だけを別のアカウントへ許可する機能だ。
たとえば企業の金庫を考えると分かりやすい。会社の資金そのものは本社が管理しながら、経理担当には支払いだけを許可し、本人確認担当には顧客承認だけを任せる。担当者が変われば、その権限だけを取り消すこともできる。
マルチシグとの違いも重要だ。マルチシグは一つの取引に複数人の承認を要求する仕組みで、Permission Delegationは特定の操作を別のアカウントへ任せる仕組みになる。両者は競合する機能ではなく、必要に応じて異なるセキュリティー設計へ利用できる。
また、旧版ではテスト中に重大な問題が発見されたが、メインネットで有効化される前だった。修正版のV1_1ではこの問題への対応が行われている。XRPLでは新しい取引ルールをバリデーター投票によって有効化するため、テスト、修正、再投入という段階を経て機能が導入される。
Web3Timesの視点
今回を見る際に焦点になるのはXRPの価格ではなく、金融機関の組織構造をブロックチェーン上でどこまで再現できるかだ。
銀行が既存決済をそのままオンチェーンへ移そうとしても、秘密鍵一つですべてを操作する仕組みでは内部統制と噛み合わない。資産管理、決済実行、本人確認、承認を分けられることは、処理速度より地味に見えるが、金融機関が実際の業務へ導入するうえでは重要な条件になる。
XRPLではCredentials、入金承認、権限委任など、決済そのものの周辺にある機能が増えている。これはブロックチェーンを単なる送金ネットワークとして高速化するのではなく、規制された金融業務を分業できる台帳へ近づけようとする方向と読める。
今後見るべきなのは、Permission Delegationが有効化されるかだけではない。銀行、ステーブルコイン発行者、カストディアン、本人確認事業者などが、それぞれ別の権限を持ったまま一つの決済フローへ参加できる実例が生まれるかが重要になる。
オンチェーン決済の普及を左右するのは、送金が数秒で完了するかだけではない。既存金融で長年使われてきた職務分掌、承認、監査、コンプライアンスを保ったまま、その処理を台帳上へ移せるかどうかである。Permission Delegationの再投入は、XRPLがその運用層まで取り込もうとしていることを示す動きといえる。
