持ち運べるウォレットには、権限を止める責任者が必要だ

分析 | 2026年10月14日。

10月13日の発表は、制御機能のさらなる拡充を予告している。一方、PrivyのXRPL文書は既にポリシーの適用を説明している。これらの資料だけでは、実際の提供範囲は明確にならない。仕様の記載は、個々のアプリが何を有効にしているかを証明するものではない。より長く問われるのは、所有者がウォレットを移行し、アクセスを失い、あるいは自動支出を止めるときに、制御権がどう変わるかだ。本稿ではこれらを分けて考える。一つの実演が成功しても、ほかの場面まで機能するとは限らないからだ。

エクスポートは移行のテストである

Privyのエクスポートガイドでは、利用できる経路がウォレットの作成環境によって異なる。製品チームにとって有用な検証は、エクスポートボタンを見つけるだけでは終わらない。架空の所有者が、許可された支払いを実行できる状態を用意する。テスト環境で別の画面に移った後も、自分のアカウントを特定し、権限を理解し、同じ許可済みの操作を完了できるだろうか。

次に制限を試す。以前の仕組みなら拒否される操作を、新しい画面から要求する。制限が維持されたのか、なくなったのか、再設定が必要なのかを記録する。これは受け入れテストの提案であり、特定の実装に制限の回避経路があるという主張ではない。移行可能性を約束するなら、所有者が得るものと、同時に引き受ける責任の両方を説明すべきだ。

この違いには事業上の意味もある。明確な退出手順は一つのアプリへの依存を減らし得る一方、防護策の変化が十分に説明されなければ、所有者の運用負担を増やしかねない。エクスポートの件数だけでは、このトレードオフは見えない。

回復すべきなのは適切な権限である

XRPLの鍵管理ガイドは、マスター鍵の無効化に先立ち、別の承認手段を備えるよう求めている。ここから本稿が問うのは、回復手続きが何を取り戻すのかという、より広い設計上の問題だ。ログインの回復、署名能力の回復、権限を変更する権限の回復は、それぞれ評価する必要がある。

所有者が端末を失い、エージェントには依然として操作権限がある場面を想定する。回復訓練では、誰が介入でき、どのような証拠を提示し、従来のどの権限が残るのかを確認したい。失敗する回復要求も試すべきだ。アカウント名を知っていても、必要な証明を欠く人物に制御権を渡してはならない。

有用な完了記録は、二つの結果を同時に示す。正当な所有者が再び操作できることと、廃止するはずの権限が本当に使えなくなったことだ。利便性だけを回復し、後者を確認しない検証は不十分である。

支出を止める責任者を明らかにする

Privyの制御モデルでは、一つの鍵または必要な承認数を満たす鍵の組に、ウォレットの所有権を割り当てる。本稿が提案する評価では、続いて人の責任を問う。問題が起きたとき、その権限を使う責任は誰にあるのか。

仮想的なエージェント用ウォレットについて、支出を要求できる主体、上限を変更できる主体、許可を終了できる主体を記録する。役割が重なっていてもよいが、それは意図した設計であるべきだ。財務担当者が活動を観察できることを、停止する権限があることと取り違えてはならない。

最も示唆に富む訓練は、許可を撤回した後に始まる。以前の権限で新しい要求を送り、拒否されることを確認する。一方、既に署名または送信された要求は別に調べる。撤回成功のメッセージが、それ以前のすべての操作まで解決すると想定すべきではない。新たな権限行使を止めることと、既存の処理を調べることを区別する必要がある。

安全に失敗できるかを測る

これらの訓練は、機能一覧の有無よりも有用な調達上の問いを示す。想定した所有者は、画面の変更、アクセスの喪失、委任の撤回を経ても制御権を保てるだろうか。

信頼できる答えには、テスト結果、明示された責任者、明確な限界が必要だ。どの保護が維持され、どれが意図的に置き換えられ、どれが別の当事者の対応可能性に依存するかも説明したい。そうした証拠があってこそ、回復を曖昧な約束にせず、停止権限を誰も引き受けない責任にせずに、移行可能性を実質的なものにできる。