XRP Ledger（XRPL）で、主口座の秘密鍵を共有せず、別口座に限定的な操作権限を与える「PermissionDelegationV1_1」が有効化された。 結論として、銀行やステーブルコイン発行者は決済・顧客承認・資産管理の職務分離を台帳上で実装しやすくなる。一方、金額上限を自動設定する仕組みではなく、PaymentBurnには修正待ちの注意事項がある。
PermissionDelegationV1_1で何が変わったのか
CoinDeskは2026年10月8日、XRPLでPermissionDelegationV1_1が有効化されたと報じた。この機能は、資産を保有する口座の秘密鍵を別の担当者やシステムへ渡さず、特定の取引だけを実行できる権限を別口座へ割り当てるものだ。
XRPLの公式文書では、権限を与える側を「delegator」、実際に取引へ署名する側を「delegate」と呼ぶ。delegatorはDelegateSetトランザクションを送信し、delegateのアドレスと許可する操作を登録する。権限は後から更新でき、空の権限一覧を指定すれば既存の委譲を撤回できる。
これは主口座の管理権限そのものを移す仕組みではない。delegateは自分の鍵で署名し、与えられた取引種別または細分化された操作だけを実行する。RippleのRLUSDのようなステーブルコインや、XRPL上で発行されるトークン化ファンドを運用する事業者にとって、日常業務用のオンライン鍵と、発行・管理の中核鍵を分離できる点が重要だ。
銀行・ステーブルコイン発行者の職務分離を台帳上へ
銀行では、送金担当者、コンプライアンス担当者、システム管理者が異なる権限を持つのが一般的だ。Permission Delegationは、この社内統制をXRPLの取引ルールとして表現する。例えば、ステーブルコイン発行者は顧客確認を終えた利用者のトラストラインを承認する権限だけをコンプライアンス口座へ与え、発行主体の主鍵はオフラインに保管できる。
具体例がTrustlineAuthorizeだ。これはTrustSetの全機能を渡すのではなく、個別のトラストラインを承認する操作に限定した権限である。凍結にはTrustlineFreeze、解除にはTrustlineUnfreezeという別の権限が用意されている。RLUSDのような発行型資産では、顧客承認と凍結対応を別チームへ分ける設計が可能になる。
ただし、委譲だけで社内統制が完成するわけではない。本人確認の判定、制裁リスト照合、承認記録、障害時の停止手順はオフチェーン側にも残る。XRPL上の権限設定と、組織の承認フローや監査ログを一致させる必要がある。
DelegateSetの仕組みと実装時の確認事項
DelegateSetでは、Authorizeに権限を受ける口座を指定し、Permissionsに許可項目を列挙する。公式仕様上、1つのdelegateへ設定できる権限は最大10個で、指定内容は追加差分ではなく、その時点の権限一覧として置き換わる。更新時に項目を落とすと、その権限は撤回されるため、運用ツールは現在値を読み出してから完全な一覧を再構成すべきだ。
また、DelegateSet自体、鍵を変更するSetRegularKey、署名者リストを変えるSignerListSetなどは委譲できない。delegateが別のdelegateを増やしたり、主口座の認証構成を変更したりする連鎖を防ぐ設計である。delegateは台帳上に存在する資金提供済み口座である必要があり、取引手数料もdelegate側が負担する。
実務では、決済口座、コンプライアンス口座、資産管理口座を用途別に分けるだけでなく、各口座の鍵保管、監視、ローテーション、緊急失効を個別に設計したい。XRPLのマルチシグは複数署名による承認に向く一方、Permission Delegationは操作種類の制限に向く。高額送金ではマルチシグ、日常的な顧客承認では委譲というように、両者を補完的に使う考え方が現実的だ。
PaymentBurnの不具合と安全上の注意
XRPL公式文書は、fixCleanup3_4_0が有効になるまでPaymentBurnをdelegateへ付与しないよう警告している。PaymentBurnは、本来、発行済みのファンジブルトークンやMulti-Purpose Token（MPT）を焼却するための細分化権限だ。しかし修正前は、特定条件でdelegateが新しいトークンを発行できる場合がある。対象は発行型トークンであり、XRPを新規発行する問題ではない。
したがって、RLUSDなどの発行者やトークン化ファンドの管理者は、PermissionDelegationV1_1が有効になったことだけを見て全権限を展開すべきではない。PaymentBurnを設定候補から除外し、fixCleanup3_4_0の有効化を公式のAmendments情報で確認してから再評価する必要がある。
権限委譲は「操作の種類」を制限するが、「1日当たりの送金額」や「特定通貨だけ」といった任意の条件を自動で付ける仕組みではない。公式文書も、細分化権限は固定され、通貨ごとの独自ルールは作れないと説明している。金額制限が必要なら、署名前のアプリケーション制御、マルチシグ、監視と即時失効を組み合わせるべきだ。
XRPLのDEX・AMM・トークン化資産への影響
XRPLにはオーダーブック型DEXとAMMが組み込まれている。Permission Delegationは取引市場そのものの価格決定方式を変える更新ではないが、発行者側の運用リスクを分離しやすくするため、RLUSDやMPT、トークン化ファンドがDEX・AMMへ接続される際の管理基盤になり得る。
例えば、マーケット運用口座にはOfferCreateや決済に必要な権限だけを与え、トークン発行や凍結の権限を持たせない構成が考えられる。反対に、コンプライアンス口座にはTrustlineAuthorizeだけを付与し、市場で売買する権限を渡さない。これにより、マーケットメイカー用サーバーの鍵が侵害されても、発行者の全機能まで直ちに奪われる範囲を狭められる。
ただし、UniswapやAaveのようなEVM系DeFiで使われるスマートコントラクトのロール管理と、XRPLのPermission Delegationは同一ではない。XRPLでは許可できる取引種別や細分化権限がプロトコルで定義される。外部ブリッジやカストディを介してAave、Curveなどへ資産を持ち込む場合、そのコントラクト、ブリッジ、管理者鍵のリスクは別に評価しなければならない。
事業者が導入前に行うべき実務チェック
第一に、現行業務を「顧客承認」「凍結・解除」「決済」「市場取引」「発行・焼却」に分解し、XRPLのPermission Valuesへ対応付ける。対応する細分化権限がなければ、広い取引種別権限を安易に渡さず、マルチシグやオフチェーン承認を検討する。
第二に、テストネットでDelegateSetの登録、更新、全撤回を試し、想定外の操作が拒否されることを確認する。特に更新が権限一覧の置き換えである点、delegateごとにDelegate台帳エントリーが作られる点、委譲取引がトランザクションキューへ入らない点は、障害時の再送設計に影響する。
第三に、運用監視ではdelegateごとの送信元、取引種別、失敗コードを記録する。異常時には主口座からDelegateSetを送り、対象delegateの権限を撤回する手順を準備する。PaymentBurnは修正の有効化確認まで付与しない。RLUSDやトークン化ファンドを扱う場合、オンチェーン権限だけでなく、償還、準備資産、法令対応、カストディの管理も一体で監査する必要がある。
まとめ
PermissionDelegationV1_1は、XRPL上の口座管理を「1本の強い鍵」から、役割ごとに制限された複数口座へ分けるための基盤だ。銀行、RLUSDなどのステーブルコイン発行者、トークン化ファンド運営者は、決済とコンプライアンスを分離し、主鍵をオフラインに保ちやすくなる。
一方、委譲は金額上限ではなく操作種別の制限であり、固定された権限体系にも限界がある。PaymentBurnには公式警告が残るため、修正状況の確認、最小権限、マルチシグ、監視、緊急撤回を組み合わせることが重要だ。DEXやAMMの利用拡大を支える可能性はあるが、安全性は権限設計と日々の運用によって決まる。
