パスキーウォレットの仕組み2026｜WebAuthn×ERC-4337でシードフレーズをなくす設計と実装

パスキー（Face ID・Touch ID・Windows Helloなどの端末認証でログインする、パスワードに代わる認証方式。技術仕様はW3C標準のWebAuthn）を署名鍵にして、シードフレーズや秘密鍵の文字列を一度もユーザーに見せないウォレットは、既に実運用段階です。ERC-4337のスマートアカウントは署名検証ロジックをアカウント側で自由に実装できるため、パスキーが生成するP-256（secp256r1：パスキーやSecure Enclaveが使う楕円曲線。Ethereumの標準署名とは別の曲線）署名をオンチェーンで検証する構成が確立しており、CoinbaseのBase Account（旧Coinbase Smart Wallet）やSafeのパスキー署名者モジュールが本番投入しています（Base公式ドキュメント、Safe公式ドキュメント）。

最後まで残っていた「Ethereum本体（L1）ではP-256の検証コストが高すぎる」という制約も、2025年12月3日に有効化されたFusakaアップグレードで解消しました。P-256署名を1回6,900ガスで検証するprecompile（プロトコル組み込みの検証機能）がEIP-7951としてL1に追加され（EIP-7951仕様、Ethereum Foundation公式ブログ）、先行するRIP-7212を実装済みの主要L2と合わせて、Ethereum L1と主要L2ではパスキー署名の検証がsecp256k1署名と同水準の実用コストになりました。ただしprecompile未対応のチェーンでは今も約20万〜33万ガスのフォールバック実装に頼ることになるため、展開先ごとの対応状況の確認は引き続き必要です（後述の比較表参照）。また正確に言えば、これは「秘密鍵がなくなる」設計ではなく、鍵の生成・保管をOSの鍵保管領域とパスキー同期基盤へ委ねる設計です。成否を分けるのは署名方式の選択そのものではなく、端末紛失・プラットフォーム依存・提供者の事業継続まで含めた復旧経路の設計です。本記事では、仕組み、検証コストの実額、Base Account・Safeの設計比較と先行例Daimoの教訓、同期パスキーの脅威モデル、実装の落とし穴を、2026年8月11日時点の一次情報で整理します。AA（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）全体の採用判断はAA完全マップ2026を参照してください。

仕組み — パスキーの署名を、スマートアカウントが「ウォレットの鍵」として検証する

パスキーの実体は、WebAuthn仕様に基づいて認証器（authenticator：鍵の生成と署名を担うソフトウェア・ハードウェア）が管理するP-256の鍵ペアです。署名は認証器の中で行われ、アプリやWebサイト、ウォレット提供者に渡るのは署名結果と公開鍵だけで、秘密鍵が平文でこれらに渡ることはありません。ユーザーが行うのはFace IDやTouch IDによる認証だけで、生体情報も端末の外に送信されません（W3C WebAuthn仕様）。

ただし「秘密鍵がどこに保管されるか」は一通りではありません。iPhoneやAndroidで通常作成されるのは同期パスキーで、秘密鍵はiCloudキーチェーンやGoogle パスワード マネージャーに保存され、同じアカウントの端末間でエンドツーエンド暗号化により同期されます。Appleはパスキーをエンドツーエンド暗号化してiCloudキーチェーンで同期すると明記しており（Apple公式：パスキーのセキュリティについて）、Googleも多くのAndroid端末でパスキーが既定でGoogle パスワード マネージャーに保存され、同期とエンドツーエンド暗号化が行われることを明記しています（Google公式：AndroidとChromeのパスキー対応環境）。つまり、暗号化された状態ではありますが鍵データは端末間を移動します。一方、YubiKey等のセキュリティキーで作るdevice-bound（端末固定）のパスキーは、鍵がそのハードウェアから出ません。そもそもWebAuthn仕様自体は、認証器の実装としてソフトウェア実装からオフデバイス認証器まで幅広く許容しており、「パスキー＝ハードウェア内保管」を保証するものではありません（W3C WebAuthn仕様）。この保管モデルの違いは、後述の脅威モデルを考えるうえでの前提になります。

一方、Ethereumの従来型アカウント（EOA）はsecp256k1という別の曲線の署名しか受け付けないため、パスキーの署名をそのまま使えません。ここを埋めるのがERC-4337です。ERC-4337のスマートアカウントは、トランザクションに相当するUserOperationの署名検証をvalidateUserOp関数としてアカウント自身が実装します（ERC-4337仕様）。つまり検証ロジックにP-256検証を書けば、パスキーがそのままウォレットの署名鍵になります。ERC-4337の全体像はERC-4337の事業者向け解説で扱っています。

実装上の要点は「何に署名しているか」です。WebAuthnの署名対象はUserOperationのハッシュそのものではなく、authenticatorData（認証器の状態を示すバイト列）とclientDataJSON（ブラウザ・OSが生成するJSON）のSHA-256ハッシュを連結したデータです。ウォレットはWebAuthnのchallenge（署名要求に含めるランダム値）としてUserOperationのハッシュ（userOpHash）を渡し、オンチェーン側はclientDataJSONの中にそのuserOpHashが正しく入っていることまで検証して、初めて「このパスキーがこの操作を承認した」と言えます（base/webauthn-sol）。この再構成の詳細は後述の「実装の落とし穴」で扱います。

なお、ガス代をユーザーに持たせないPaymaster（ガス代肩代わり）との組み合わせは、パスキーウォレットの標準構成です。「アプリにログインする感覚でウォレットが作られ、ガス代も意識させない」体験の費用構造はガスレストランザクションの経済性で扱っています。

検証コストの現在地 — 2025年12月のFusakaで「L1では高すぎる」が終わった

P-256検証はEthereumが標準サポートするsecp256k1検証（ecrecover、3,000ガス）と違い、長らくSolidityで実装するしかなく、監査済み実装でも1回あたり数十万ガスを要していました。この構図を変えたのがprecompile化で、2026年8月時点の検証経路は次の3つです。

2つ補足します。第一に、EIP-7951はRIP-7212と同じインターフェースを保ったままL1へ持ち込む仕様で、RIP-7212に存在した境界条件の検証漏れ（無限遠点チェック等）を修正し、ガスコストはベンチマークに基づき3,450から6,900へ再設定されています（EIP-7951仕様）。L2の3,450ガスとL1の6,900ガスは同じ機能の別価格であり、どちらもsecp256k1検証と同水準の「実用コスト」です。

第二に、実装側はこの過渡期を「progressive precompile」パターンで吸収するのが標準です。まずprecompileアドレスの呼び出しを試み、存在しないチェーンでは監査済みSolidity実装へフォールバックする構成で、Base Accountが使うwebauthn-solもDaimoのp256-verifierもこの方式です（base/webauthn-sol、daimo-eth/p256-verifier）。この構成を採っておけば、precompile未対応チェーンでも動作自体は継続し、対応チェーンでは自動的に安くなります。ただし未対応チェーンでのフォールバック実行には上表のとおり数十万ガス台のコストが実際に発生するため、展開先ごとのprecompile対応有無は、動作可否ではなくコスト試算の確認事項として残ります。

実プロダクトの設計比較 — Base Account・Safe、そして先行例Daimoの教訓

パスキーウォレットの設計判断は「パスキーをアカウントの中でどう位置づけるか」と「パスキーを失ったときの復旧経路をどう作るか」の2点に集約されます。2026年8月時点で本番運用中のBase AccountとSafe、そしてこの構成を最初期に本番投入し、2026年2月にアプリ提供を終了したDaimo（公式リポジトリは2026年2月18日にarchiveされ、旧アプリからの資金引き出しを案内中。daimo-eth/daimo）は、それぞれ異なる答えを選んでいます。

この比較から読み取るべき共通項は、現行の2プロダクトも終了したDaimoも、「パスキー1本だけ」の状態を恒久運用として想定していないことです。いずれも「パスキーを失っても、オンチェーンに登録済みの別の鍵・別の署名者から復旧できる」経路を最初から用意しています。そしてDaimoの終了そのものが、もう1つの論点の実例になりました。公式リポジトリは「旧Daimoアプリは終了します。資金を引き出してください」と案内しており（daimo-eth/daimo）、提供者の事業継続は、パスキーウォレット選定における仮定の話ではなく現実の評価軸です。

もう1つ、事業者が見落としやすいのがドメイン依存の論点です。WebAuthnのパスキーはRP ID（Relying Party ID：パスキーを発行したサービスのドメイン）に紐づき、原則としてそのドメインのコンテキストでしか署名に使えません（W3C WebAuthn仕様）。Base Accountの場合、アプリからの署名リクエストはkeys.coinbase.comのポップアップへ渡して処理する構成で、パスキーはこのドメインのコンテキストで扱われます（Base公式ドキュメント：Popup Tips）。つまり提供者のサービスやドメインが止まると、資産はオンチェーンに無事でも「パスキーで署名する入口」が失われます。Base Accountが通常のEthereumアドレスをownerとして追加登録できるようにしているのは、この状況への備えとして読めます。Ethereumアドレスのownerは標準のECDSA署名で動くため、提供者のWebサイトを経由せず既存のEthereumツールでトランザクションを構成・署名する経路になり得ます（この機能は旧Coinbase Smart Walletのドキュメントで「Recovery Keys」として解説されていましたが、2026年8月11日時点では該当ページがBase Account概要へリダイレクトされるため、本記事はコントラクト実装のcoinbase/smart-walletを一次資料として参照しています）。自社サービスへウォレットを組み込む場合は、パスキーがどのドメインに紐づくか、提供者障害時にユーザーが資産へ到達する経路が何か、を選定段階で確認してください。SDKやウォレット基盤の比較軸はAA開発スタックの選定2026で扱っています。

「秘密鍵がなくなる」の正確な意味 — リスクは消えず、置き換わる

パスキーウォレットが解消するのは「ユーザー自身によるシードフレーズの保管」であり、鍵そのものは存在し続けます。変わるのは保管の責任主体で、それに伴いリスクの形も変わります。

同期パスキーは、鍵の防御をプラットフォームアカウントとその保護機構に委ねます。iPhoneやAndroidで作成したパスキーは、既定でiCloudキーチェーンやGoogle パスワード マネージャーによりユーザーのアカウントへエンドツーエンド暗号化で同期され、機種変更や端末紛失でも復元できます（Apple公式：パスキーのセキュリティについて、Google公式：AndroidとChromeのパスキー対応環境）。では「Appleアカウントを乗っ取られたら即座に資産を失うのか」というと、そこまで単純ではありません。Appleの場合、iCloudキーチェーンはAppleアカウントの資格情報が侵害されただけでは中身へ到達できないよう設計されており（Apple Platform Security：iCloud Keychainのセキュリティ概要）、新しい端末が同期へ参加するには、既存の信頼済み端末による承認か、エスクロー（預託）経由の復旧手続きの通過が必要です（Apple Platform Security：セキュアなキーチェーン同期）。同期パスキー経由の資産侵害が成立するのは、アカウント資格情報に加えて、既存端末の掌握や復旧手続きの突破まで達成された場合です。

したがって実務上の問いは「単一障害点かどうか」ではなく、資産の防御をプラットフォームアカウントの防御力にどこまで依存させるかです。この保護機構と復旧手続きの中身は同期事業者ごとに異なり、ウォレット提供者からは見えず、制御もできません。また攻撃とは逆方向の事故 — ユーザー自身がプラットフォームアカウントを失う、パスキーを誤って削除する、iPhoneからAndroidのように同期圏をまたぐ移行で引き継げない — は、攻撃がなくてもそのまま署名鍵の喪失になります。

この脅威モデルを踏まえた実務上の設計は、金額と用途で署名手段を分けることです。少額・高頻度の操作は同期パスキーで摩擦なく通し、高額の移転やアカウント構成の変更にはリカバリー用ownerや追加署名者の承認をオンチェーン側で要求する、という段階設計が、前章のプロダクトが実装している内容の一般形です。日常操作の権限を時間・金額・関数で絞る手法はSession Keyの設計で、ウォレット全体の脅威モデルはAAセキュリティリスクで扱っています。

なお、同期を避けたい場合はYubiKey等のセキュリティキーに作るdevice-bound（端末固定）のパスキーという選択肢もありますが、紛失＝喪失のリスクをユーザー個人が負う構成に戻るため、一般消費者向けサービスの既定にする設計は現実的ではありません。既定は同期パスキー、復旧はオンチェーンの第二経路、と役割を分けるのが2026年時点の実装水準です。

実装の落とし穴 — WebAuthn署名のオンチェーン検証で壊れやすい5点

パスキーウォレットの障害は、署名検証の周辺で起きます。自社実装・SDK選定のどちらでも、次の5点を確認してください。

1. 署名フォーマットの変換：認証器が返すWebAuthn署名はASN.1 DERエンコードされていますが、オンチェーン検証器が受け取るのは生の(r, s)値です。クライアント側でのデコード・変換を忘れると、正しい署名が全件検証失敗になります。
2. 署名対象の再構成：前述のとおり署名対象はauthenticatorData || SHA-256(clientDataJSON)です。コントラクト側はこの連結を再構成し、かつclientDataJSON内のtypeがwebauthn.getであること、challengeが期待するuserOpHashと一致することを検証する必要があります。webauthn-solはJSON内の位置をchallengeIndex・typeIndexとして受け取り、オンチェーンでのJSONパースを回避しています（base/webauthn-sol）。
3. challengeとリプレイ防止の分離：challengeへのuserOpHashのバインドは「何を承認したか」の検証であり、リプレイ防止はERC-4337アカウントのnonceが担います。challenge検証を省略した実装は、別操作への署名流用を許します。
4. low-s正規化：ECDSA署名は(r, s)と(r, n−s)の両方が数学的に有効という可鍛性（malleability）があります。検証側でsを曲線位数の半分以下に制限（low-s強制）しない実装は、同一承認から異なる署名が作れることになり、署名をIDとして扱う周辺システムを壊します。webauthn-solはlow-sを強制します（base/webauthn-sol）。
5. 認証器フラグの検証：authenticatorDataのフラグにはUP（User Present：ユーザーの関与確認）とUV（User Verified：生体認証・PIN等による本人確認）があり、少なくともUPの検証は必須、資産操作ではUV要求の要否をポリシーとして明示すべきです（W3C WebAuthn仕様）。

結論としては、この層を自作しないことが最も効果的な対策です。base/webauthn-sol、daimo-eth/p256-verifier（Veridise監査済み。Daimoアプリ終了後もリポジトリは公開・利用可能）、Safeのパスキーモジュールなど、監査済みで本番実績のある実装が公開されており、独自実装は差別化にならない一方で監査責任だけを増やします。

ユーザーはパスキーを受け入れるか — 2026年の採用状況

「パスキーの説明からユーザー教育を始める必要があるのでは」という懸念は、2026年時点では過去のものになりつつあります。FIDOアライアンスは2026年5月、世界で利用されるパスキーが推計50億に達し、10カ国11,000人の消費者調査で90%がパスキーを認知、75%が少なくとも1つのアカウントで有効化済みと発表しました（FIDOアライアンス、2026年5月7日）。

日本では、証券口座の乗っ取り・不正取引の多発を受けて、日本証券業協会が2025年10月15日に「インターネット取引における不正アクセス等防止に向けたガイドライン」を改正し、パスキー認証を例示する「フィッシングに耐性のある多要素認証」の実装・必須化を求めました（日本証券業協会、2025年10月15日）。主要証券のログインが順次パスキー化していくことは、金融サービスの利用者層が「生体認証で金融資産にアクセスする」体験を標準として学習していくことを意味します。ウォレットを組み込む事業者にとって、パスキーは「Web3特有の新奇なUX」ではなく、ユーザーが他の金融サービスで既に使っている認証UXへの合流になった、というのが2026年の状況です。なお、パスキーウォレットを自社サービスとして提供する場合に暗号資産交換業（カストディ業務）に該当し得るかという論点はアカウントアブストラクションの規制該当性で扱っています。

よくある質問

機種変更や端末紛失で、パスキーウォレットの資産は失われますか？

同期パスキー（iCloudキーチェーンやGoogle パスワード マネージャーに保存されたパスキー）であれば、同じプラットフォームアカウントに新端末でログインし、既存端末による承認や復旧手続きといった正規の手順を経ることでパスキーが復元され、資産へのアクセスも戻ります（Apple公式、Google公式）。失われるのは、プラットフォームアカウント自体を失った場合、パスキーを削除した場合、iPhoneからAndroidのように同期圏をまたいで移行しパスキーを引き継げなかった場合です。だからこそBase Accountの追加ownerのような、パスキーと独立したオンチェーンの復旧経路を、パスキーが使えるうちに登録しておく設計が必須です。

パスキーの秘密鍵や生体情報はブロックチェーンに記録されますか？

記録されません。オンチェーンに登録されるのはP-256の公開鍵（と署名の検証結果）だけです。秘密鍵は認証器と同期基盤の中にとどまって平文でアプリやサイトへ渡ることはなく、Face IDやTouch IDの生体情報はWebAuthnの仕様上、端末の外に送信されません（W3C WebAuthn仕様）。

ウォレット提供会社がサービスを終了したら、資産はどうなりますか？

資産そのものはスマートアカウントとしてオンチェーンにあり、提供会社は保有していません。ただしパスキーは提供者のドメイン（RP ID）に紐づくため、提供者のサイトが停止すると「パスキーで署名する入口」が失われます。Base Accountの場合、通常のEthereumアドレスをownerとして追加登録しておけば（コントラクトのMultiOwnableはパスキー公開鍵とEthereumアドレスのどちらもownerにできます）、提供者のWebサイトに依存せず、既存のEthereumツールでスマートアカウントのトランザクションを構成・署名する経路を残せます（coinbase/smart-wallet）。実際に2026年2月にアプリ提供を終了したDaimoは、ユーザーへ資金の引き出しを案内する形の撤退になりました（daimo-eth/daimo）。組み込みウォレットを選定する際は、この「提供者非依存の脱出経路」の有無を確認項目に含めてください。

既存のMetaMaskユーザーにもパスキー署名を提供できますか？

できます。2025年5月のPectraアップグレードで導入されたEIP-7702により、既存EOAはアドレスと資産を維持したままスマートコントラクトへ実行ロジックを委任でき、委任先がP-256検証を実装していればパスキーを追加の署名手段にできます。ただし委任後もEOAの秘密鍵が最上位権限であり続ける点が、本記事のパスキー主鍵型ウォレットとの本質的な違いです。詳細はEIP-7702の事業者向け解説とERC-4337 vs EIP-7702の判断軸を参照してください。

関連記事

全体像を押さえる：

• AA完全マップ2026 — AA採用判断の全体像。本記事の親記事
• ERC-4337の事業者向け解説 ／ EIP-7702の事業者向け解説

設計・実装を進める：

• AA開発スタックの選定2026 — SDK・Bundler・Paymaster・アカウント実装の選定基準
• Session Keyの設計 ／ AAセキュリティリスク ／ ガスレストランザクションの経済性

主要参考資料

• W3C: Web Authentication Level 3（2026年5月26日 Candidate Recommendation Snapshot）
• EIP-7951: Precompile for secp256r1 Curve Support（Final）
• Ethereum Foundation Blog: Fusaka Mainnet Announcement（2025年11月6日、有効化2025年12月3日）
• ERC-4337: Account Abstraction Using Alt Mempool
• RIP-7212: Precompile for secp256r1 Curve Support
• OP Stack Specification: Precompiles（P256VERIFYはFjordで追加）
• Arbitrum: AIP - Support RIP-7212（ArbOS 30）
• Polygon: PIP-27 Precompiled for secp256r1 Curve Support（Final）
• base/webauthn-sol: WebAuthn署名のSolidity検証ライブラリ
• coinbase/smart-wallet: Base Accountのコントラクト実装（MultiOwnable、2026年8月11日閲覧）
• Base: Base Account Documentation（2026年8月11日閲覧）
• Base: Popup Tips — keys.coinbase.comポップアップの挙動（2026年8月11日閲覧）
• daimo-eth/p256-verifier: 監査済みP-256検証コントラクト（約33万ガス）
• daimo-eth/daimo: Secure Enclave鍵によるERC-4337ウォレット実装（2026年2月18日archive、旧アプリは提供終了）
• Safe: Passkeys Overview（公式ドキュメント）
• Apple: パスキーのセキュリティについて（2026年8月11日閲覧）
• Apple Platform Security: iCloud Keychainのセキュリティ概要（2026年8月11日閲覧）
• Apple Platform Security: セキュアなキーチェーン同期（2026年8月11日閲覧）
• FIDO Alliance: World Passkey Day 2026発表（2026年5月7日）
• 日本証券業協会: インターネット取引における不正アクセス等防止に向けたガイドライン改正（2025年10月15日）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術解説であり、投資助言・法的助言ではありません。precompileの対応チェーン、各プロダクトの機能とドキュメント構成、パスキーの同期仕様、採用統計は今後変わり得ます。採用判断の際は必ず各プロジェクト・各プラットフォームの最新の公式ドキュメントを確認してください。