PasskeyやAccount Abstractionの普及で、Web3ウォレットはシードフレーズ中心の設計から変化しています。スマートアカウントによる復旧、権限管理、ガス代肩代わりの仕組みと、ハードウェアウォレットが担う役割を整理します。
背景と今回の論点
Web3ウォレットでは、秘密鍵とシードフレーズを利用者自身が管理する従来型モデルに加え、Passkeyやスマートアカウントを使う設計が広がっています。背景にあるのがAccount Abstraction（アカウント抽象化）です。ウォレットを単なる秘密鍵の保管場所ではなく、条件付きで処理を実行できるアカウントへ発展させる考え方です。
これにより、ガス代の肩代わり、複数操作の一括処理、鍵の追加や変更、柔軟な復旧などを実装できます。一方、使いやすくなったからといって秘密鍵管理のリスクが消えるわけではありません。むしろ「誰が、どの条件で署名できるか」を理解することが重要になります。
Passkeyはシードフレーズの代用品ではない
Passkeyは公開鍵暗号を利用した認証方式で、端末の生体認証やPINなどと組み合わせて利用できます。パスワードのような共有秘密をサーバーへ送らないため、偽サイトへパスワードを入力させる典型的なフィッシングへの耐性を高められます。
ただしWeb3でPasskeyを採用した場合の鍵管理方法はウォレットごとに異なります。Passkey自体がブロックチェーン上の秘密鍵を必ず置き換えるわけではなく、スマートアカウントを操作する認証鍵として利用される場合もあります。
そのため「Passkeyだからシードフレーズ不要」という機能説明だけで判断せず、鍵がどこで生成・保存されるのか、端末紛失時にどう復旧するのか、クラウド同期や第三者サービスへの依存があるのかを確認する必要があります。
プログラム可能なアカウントが変えるもの
Ethereum系で利用されるERC-4337では、従来のExternally Owned Accountとは異なるスマートアカウント型の運用が可能です。Bundlerがユーザー操作をまとめて処理し、Paymasterを利用すればサービス側がガス代を負担する設計もできます。
セキュリティ面で重要なのは、署名条件をプログラムできる点です。例えば複数鍵による承認、利用上限、特定条件での復旧など、単一の秘密鍵だけに依存しない設計が可能になります。
一方で、リスクの場所も変わります。スマートコントラクトの実装、BundlerやPaymasterなど周辺インフラ、復旧ルール、権限設定が新たな検証対象になります。従来型ウォレットの「秘密鍵を守る」という問題が、「アカウント全体の権限構造を守る」という問題へ拡張されると考えるべきです。
ハードウェアによる署名はどう位置付けるか
スマートウォレットが普及しても、重要な秘密鍵をネットワークから分離して管理する考え方は有効です。ハードウェアウォレットは秘密鍵を端末内部で管理し、トランザクションへの署名を専用端末上で行うことで、PCやスマートフォンへの鍵露出を抑える役割を持ちます。
将来的には、日常操作をPasskey、重要操作をハードウェアウォレット、緊急時を別の復旧鍵というように、複数の認証手段を役割別に組み合わせる設計も考えられます。
ただし複雑化は新たな運用リスクになります。利用者が復旧条件や署名権限を理解していなければ、設定ミスやサービス終了時に資産へアクセスしにくくなる可能性があります。シードレスという言葉だけでなく、障害時に自分がどこまで復旧できるかを見ることが重要です。
まとめ
Web3ウォレットは、単一の秘密鍵とシードフレーズを守るモデルから、Passkey、スマートアカウント、複数鍵、復旧ポリシーを組み合わせるモデルへ進化しています。
重要なのはシードフレーズの有無ではなく、最終的な署名権限、鍵の保存場所、復旧経路、外部サービスへの依存関係を把握することです。ハードウェアウォレットも含め、それぞれの技術を競合する選択肢としてではなく、異なるリスクを分離するためのセキュリティ層として設計する視点が今後さらに重要になります。