テザーは9月3日、ウォレット開発キット「WDK（Wallet Development Kit）」で作成したコマンドライン版ウォレットの内部仕組みを公開しました。時間制限付きの解錠中はソフトウェアが個々の支払い承認なしで取引を要求できる一方、同じ利用者権限で動作する別プロセスが署名を要求できる問題や、承認確認の実効性に関する課題も浮き彫りになっています。
テザーWDKとは？——CLIウォレットが示す新しい設計思想
テザーWDKとは、テザーが提供するウォレット開発キットです。時間制限付きでウォレットを解錠し、その間はソフトウェアが個々の支払い承認なしで取引を要求できます。シードはAES-256-GCMで暗号化され、鍵はscryptで導出されるのが主な特徴です。
今回は、このWDKで作成したコマンドライン版ウォレットの設計が解説されました。中心となるのは「時間制限付き解錠」のコンセプトで、利用者が解錠した期間中は、AIエージェントや自動化プログラムが都度の操作なしで支払いを実行できるようになります。
注目すべきは、鍵を利用者の手元に置くことと、エージェントに与える支出権限の範囲が、明確に別々の判断として設計されている点です。「鍵の保持」と「支出権限の委任」を混同すると、セキュリティ設計に綻びが生じかねません。
解錠の技術的仕組み：AES-256-GCMとscrypt、そして5分セッション
技術面では、解錠前のシードがAES-256-GCMで暗号化され、鍵はscryptで導出されます。scryptは計算コストが高く、パスフレーズへの総当たり攻撃に対する耐性を高めるために採用されています。
macOSとLinuxでは、常駐プロセスの接続口がOS上の所有者に限定されます。これは、他の利用者のプロセスからの不正なアクセスを防ぐための措置です。ただし、プログラムごとの資格情報は存在しないため、同じ利用者として動作するプロセスが接続口に到達できれば、パスフレーズを再入力せずに署名を要求できます。
セッションの既定値は解錠から5分です。早期の施錠や有効期限の無効化も選択できるため、利用シーンに応じてリスクを調整できます。
なぜ「確認画面」だけでは支出権限を制御しきれないのか
送金ツールは既定で試行モードです。送金先や金額、手数料を確認してから実行する手順が推奨されていますが、常駐プロセスは事前の確認が行われた証明を求めません。
さらに、宣言された書き込み操作を呼び出す別の経路も存在します。どんなに丁寧な承認画面を用意しても、他の経路を制御しなければ支出権限が定まらないことを意味しており、UIの改善だけでは解決できない構造的な課題です。
つまり、確認画面の有無ではなく、確認を経由せずに書き込み操作へ到達できる経路をどう塞ぐかが設計の成否を分けるポイントです。
ALLOW/DENYポリシーの限界とアプリケーション側の責務
WDKにはALLOW/DENY形式のローカルな取引ポリシーが用意されています。しかし、価格の取得や累積支出の記録は自動化されていません。たとえば「1日あたりの上限」を設定する場合、アプリケーション側で過去の支出を保存し、同時実行を整合的に扱う仕組みを独自に実装する必要があります。
テザーは、エージェントに委ねた権限を利用者の理解と一致させる責任は、製品側に残ると説明しています。WDKはあくまで基盤を提供するものであり、実際のリスク管理はそれを利用する製品ごとに設計されるべきだという立場です。
AIエージェント時代のウォレット設計に求められるもの
AIエージェントが自律的に取引を行う時代が近づく中、ウォレットの設計思想は転換点を迎えています。都度承認のモデルではエージェントの自由度を損ない、完全な自動化は不正利用のリスクを高めます。
テザーWDKが提示する時間制限付き解錠は、その中間を狙った設計です。しかし、今回明らかになった課題を踏まえると、技術基盤の整備だけでなく、利用者への説明責任や運用上のガードレールを含めた総合的な設計が不可欠です。
ウォレットの信頼性は、結局のところ製品がどう使い、どう説明するかにかかっています。テザーが設計課題まで率直に示したことは、今後のウォレット開発における議論の土台になるでしょう。
