ソーシャルリカバリー（Social Recovery）とは｜秘密鍵を失ってもウォレットを復元できる仕組みと2026年の実装

ソーシャルリカバリー（Social Recovery）は、あらかじめ登録しておいた複数のガーディアン（復元承認者）のうち規定数が承認すると、一定の待機期間を経て、ウォレットの署名鍵を新しい鍵に交換できるスマートアカウント（コントラクト型ウォレット）の復元機構です。秘密鍵やシードフレーズ（12〜24語の復元用単語列）を失っても、ガーディアンの承認によって資産へのアクセスを取り戻せます。平常時の取引は本人の鍵1本だけで行い、ガーディアンが関与するのは復元時だけ、という点で、毎回の取引に複数署名を求めるマルチシグとは役割が異なります。

2026年8月時点では、Safeが公式に管理する監査済みのSocial Recovery Module、メールアドレスをガーディアンにできるZK Emailの復元モジュール、Ethereum Foundation系のPSEが2026年3月に公開したSocial Recovery SDKなど、既製の実装が揃い、復元ロジックを自前で書く前に既製の選択肢を評価できる段階になっています。一方で、2024年6月には単一ガーディアン構成のLoopringウォレットから約500万ドルが流出し、復元経路の設計を誤ると、復元機構そのものが攻撃経路になることが実証されました。本記事は、仕組み、守れる範囲と守れない範囲、ガーディアン構成・閾値・待機期間という設計の3変数、2026年の実装の選択肢、EIP-7702で拡張したEOAでの制約、導入判断までを、2026年8月時点の一次情報で整理します。スマートアカウント領域の全体像はAA完全マップ2026を参照してください。

仕組み — 平常時は本人の鍵1本、復元時だけガーディアンが動く

ソーシャルリカバリーの土台は、「アカウント」と「鍵」の分離です。EOA（Externally Owned Account：秘密鍵1本で直接操作する従来型アカウント）は秘密鍵とアカウントが1対1で固定されているため、鍵を失った瞬間にアカウント上のすべてへ恒久的に到達不能になり、後から復元機構を差し込む余地がありません。これに対してコントラクト型のアカウントは「どの署名を有効とみなすか」をコード側で定義できるため、一定の条件を満たしたときに有効な署名鍵そのものを交換（ローテーション）できます。この前提となるアカウント構造は、ERC-4337ベースのスマートアカウント（ERC-4337の事業者向け解説）か、後述するEIP-7702で実行を委任したEOAです。

この設計を体系化したのが、Ethereum共同創設者Vitalik Buterinが2021年1月に公開した提案です。日常の取引は単一の署名鍵で行い、鍵を失ったときだけ、最低3名のガーディアンの過半数投票で署名鍵を交換する、という現在の基本形はこの提案に基づいています（Vitalik Buterin: Why we need wide adoption of social recovery wallets、2021年1月11日）。

復元の典型的な流れは次のとおりです。

• 登録：ウォレット作成時または任意の時点で、複数のガーディアン（他者のウォレットアドレス、自分の別端末、ハードウェアウォレット、機関など）と、復元に必要な承認数（閾値）を登録します。
• 平常時：取引は本人の署名鍵だけで実行します。ガーディアンは資産に触れる権限を持たず、何も関与しません。
• 復元申請：鍵を失ったユーザーが新しい鍵を生成し、「署名鍵をこの新しい鍵に交換する」復元手続きを開始します。
• 承認：ガーディアンが承認を出し、閾値（例：5名中3名）に達すると復元が成立します。
• 待機期間：成立後も一定時間（実装により36時間〜数日）は実行されません。この間、本人（現在の鍵の保持者）は不正な復元をキャンセルできます。
• 完了：待機期間の経過後、署名鍵が新しい鍵に切り替わり、失った鍵は無効になります。

マルチシグ（複数署名：毎回の取引に規定数の署名を要求する方式）との違いは、平常時の関与にあります。マルチシグは取引のたびに複数署名が必要で、ソーシャルリカバリーは平常時1鍵・復元時のみ複数承認です。両者は排他ではなく、Safeのようなマルチシグアカウントに復元モジュールを追加する併用構成も一般的です（Safeのモジュラー設計）。

何から守れて、何から守れないか — Loopring事件の教訓

ソーシャルリカバリーの守備範囲は正確に理解しておく必要があります。

主目的は「紛失」からの復旧です。秘密鍵の紛失、端末の故障・買い替えによるアクセス喪失、シードフレーズのバックアップ喪失からは、新しい鍵への交換でアクセスを回復できます。ただし、この復旧は無条件に保証されるものではありません。鍵が健在なうちに復元設定を済ませていること、復元時に閾値分のガーディアンが承認に応じられること、復元モジュール・通知・実行経路が健全に機能していることがすべて前提で、この前提を維持すること自体が後述する運用設計の対象です。また、端末の「盗難」は紛失と同列には扱えません。端末とともに認証鍵が攻撃者の手に渡った可能性がある場合は、次に述べる「鍵の盗難」のケースとして、攻撃者に資産を移される前に復元を完了できるかという時間の問題になります。ZK Emailの復元モジュールの脅威モデルも、失った鍵からの復旧（lost credential）と盗まれた鍵への防御（stolen credential）を別の問題として区別しています（zkemail/email-recovery）。

「鍵の盗難」には条件付きで対抗できます。鍵を盗まれた場合でも、本人が先に復元を実行すれば、盗まれた鍵そのものを無効化できます。ただしこれは攻撃者との時間競争であり、待機期間と本人への通知が機能していることが前提です。逆に、攻撃者が復元機構を悪用して署名鍵を自分の鍵に交換しようとする攻撃もあり得るため、待機期間中の通知とキャンセル手段は復元機構の必須要素です。

一方で、復元経路の追加は攻撃面の追加でもあります。新たに増えるリスクは主に3つです。第一に、閾値分のガーディアンが結託すれば本人の意思に反して鍵を交換できる「共謀」。第二に、攻撃者が本人を装ってガーディアンに承認を依頼する「なりすまし」。第三に、ガーディアンが依存するインフラ自体の侵害です。

第三のリスクを実証したのが2024年6月のLoopring事件です。Loopringのスマートウォレットでは、ガーディアンを運営元の提供する「Loopring Official Guardian」1つだけにしている利用者が多数おり、攻撃者はこのOfficial Guardianの2要素認証サービスの欠陥を突いて所有者になりすまし、復元手続き（所有権のリセット）を承認させて約500万ドル相当を流出させました（Halborn: Explained: The Loopring Hack、2024年6月）。教訓は2つあります。ガーディアンが実質1者に集中すると、その1者の侵害が全ウォレットの侵害に直結すること。そして復元機構は、使われていない平常時にも攻撃面として存在し続けることです。なお、Loopringウォレット自体は2025年6月30日にサービスを終了しています（プロトコルとしてのLoopring L2とは別です。Loopring Wallet Closure Announcement、2025年5月）。

スマートアカウント全体の攻撃面（アカウント本体・Bundler・Paymaster）はAAセキュリティリスクで整理しています。ソーシャルリカバリーは「アカウントの所有権を移す権限」を外部に配る行為なので、この記事で扱う攻撃面の中でも影響が最も大きい部類に入ります。

設計の3変数 — ガーディアン構成・閾値・待機期間

ソーシャルリカバリーの安全性と実用性は、実装の選択よりも先に、次の3変数の設計で決まります。

ガーディアン構成の原則は、「同一の事故・攻撃で規定数が同時にやられない」ことです。家族3人が同じ家に住み、全員のスマートフォンが同じクラウドアカウントに紐づいているなら、名目上3名でも障害単位としては1です。Vitalik Buterinの2021年の提案では、ガーディアン同士が互いを知らないことが共謀リスクを下げるとされ、多様な社会的つながりからの選定と、機関ガーディアン（復元承認をサービスとして提供する事業者）を1つ含める構成が推奨されています。逆に、Loopring事件が示したとおり、運営者提供のガーディアン1つだけに依存する構成は、利便性と引き換えに運営者を単一障害点にします。

閾値は、共謀への耐性（高いほど安全）と復元の成功率（低いほど確実）のトレードオフです。見落とされやすいのは後者で、登録数Mを増やしすぎると、数年後に全員と連絡が取れる保証がなくなります。閾値を満たせなくなった時点でソーシャルリカバリーは機能を失うため、本人の鍵が健在なうちにガーディアン構成を定期的に見直すこと（構成変更にも待機期間を設けるのが通例です）が、閾値の数字そのものと同じくらい重要です。

待機期間は、不正な復元に本人が気付いてキャンセルするための時間です。Argent（現Ready）系の商用実装では、ガーディアンによる復元の実行とガーディアン構成の変更に36時間のセキュリティ期間を設け、この間に本人が復元をキャンセルできます（Argent Support: How to recover my wallet with guardians、2026年8月11日閲覧）。SafeのSocial Recovery Moduleでも、復元成立から確定までの猶予期間（grace period）内は現所有者がキャンセルできる設計です（Candide Docs: Account Recovery、2026年8月11日閲覧）。待機期間は通知とセットで初めて機能します。オンチェーンの復元開始を監視して本人へメール・プッシュ通知する経路がなければ、どれだけ長い待機期間も検知の機会になりません。

なお、自社サービスの運営者がガーディアンの1つに入る構成は、復元の成功率を上げる現実的な選択肢ですが、設計上は「運営者が単独で閾値を満たさない」ことが自己保管（self-custody：運営者が利用者の鍵を持たないこと）の前提になります。また、運営者が復元にどこまで関与するかによっては、暗号資産のカストディ（他人のための管理）該当性という規制上の論点が生じ得ます。該当性の判断は弁護士等の専門家の領域です。論点の整理はAAの規制該当性で扱っています。

2026年の実装ランドスケープ — 自前で書く前に確認する選択肢

復元ロジック（承認の検証、閾値管理、待機期間、キャンセル）は、誤りが即座に資産喪失につながる典型的な高リスク部位です。2026年8月時点では次のような既製の選択肢が揃っており、自前実装は既製モジュールで満たせない特殊要件がある場合の最後の選択肢と考えるべきです。

出典：Safe: Introducing Candide's Social Recovery Module、Candide Docs: Account Recovery、zkemail/email-recovery、Clave: ZK Email Recovery Beta、2025年2月25日、PSE Blog: Social Recovery SDK、2026年3月2日、privacy-ethereum/social-recovery-sdk、Argent Support: How to recover my wallet with guardians、Coinbase Help: Recover your smart wallet（いずれも2026年8月11日閲覧）。

この一覧には、初期の解説記事からの重要な変化が反映されています。ソーシャルリカバリーの代表例として長く言及されてきたプロダクトのうち、Loopringウォレットは2025年6月30日にサービスを終了し、Argentは2025年にReadyへリブランドしました（Argent Support: Argent is now Ready、2026年8月11日閲覧）。一方で、方式としてのソーシャルリカバリーは、特定プロダクトの機能から、ERC-7579（モジュール型スマートアカウントの標準）に準拠した交換可能なモジュールへと重心を移しています。ガーディアンの形も、オンチェーンのアドレスに限らず、メールアドレス（zkEmail：メールの受信・返信をゼロ知識証明でオンチェーン検証する技術）やパスキー、パスポートといった、ウォレットを持たない人・手段をガーディアンにできる方向へ広がりました。これは「ガーディアンを頼める相手が周囲にいない」という、ソーシャルリカバリー普及の実務上の最大の障壁への対応です。

主鍵側の認証をパスキーにする設計（パスキーウォレットの解説）と、復元側をどうするかは独立した意思決定です。パスキーはクラウド同期で端末紛失に耐えますが、同期アカウント自体の喪失には別の復元経路が必要で、Base Accountのrecovery key（事前登録した予備の署名者）のような自己完結型の方式か、メール・ガーディアンによるソーシャルリカバリーが、その受け皿になります。

EIP-7702のEOAでソーシャルリカバリーは成立するか

2025年5月7日に有効化されたEthereumのPectraアップグレードに含まれるEIP-7702により、既存のEOAもアドレスを変えないままスマートコントラクトへ実行を委任できるようになりました。委任先のコントラクトが復元モジュールを備えていれば、MetaMaskのような既存EOAウォレットのユーザーにも復元機構を後付けできます（EIP-7702: Set Code for EOAs（Final））。

ただし、ERC-4337型のスマートアカウントと決定的に違う制約が1つあります。EIP-7702では、元のEOAの秘密鍵を無効化することも権限を降格することもできません。委任の設定・変更・解除は常に元の鍵の署名で行えるため、元の鍵は恒久的に全権を持ち続けます。この制約から、7702アカウントにおける復元の守備範囲は次のように整理できます。

• 盗難にはほぼ無力です。鍵を盗んだ攻撃者は、委任先に何が設定されていても、生の鍵で委任自体を書き換え・解除できます。スマートアカウント側の復元・ロック機構では対抗できません。
• 紛失には条件付きで有効です。鍵を失う前に委任と復元設定が済んでいれば、委任先コントラクト内の署名者（パスキーなど）を復元機構で交換し、アカウントの操作を回復できます。ただし失われたEOA鍵そのものは交換できないため、以後そのアカウントの委任構成を変更する手段は失われたままです。
• 事前設定がなければ何も救えません。復元機構は鍵が健在なうちに仕込む保険であり、紛失後に後付けする手段はありません。

「署名鍵を完全に引退させられる」復元を求めるなら、アカウント自体をコントラクトとして作るERC-4337型が必要です。EIP-7702は既存EOA資産を移動せずに体験を改善する移行期の解であり、鍵管理の到達点ではない、というのが2026年時点の実務的な整理です。EIP-7702自体の解説はEIP-7702の事業者向け解説を参照してください。

導入判断 — ソーシャルリカバリーを選ぶ場面と別の選択肢

ソーシャルリカバリーが適するのは、「運営者が利用者の鍵を預からない（自己保管を維持する）」ことと「鍵の紛失を利用者の自己責任で終わらせない」ことを両立させたいサービスです。コンシューマ向けのウォレット、資産やNFTを保有させるアプリ、機種変更が日常的に起きるモバイル中心のプロダクトが典型です。

一方で、鍵の紛失対策はソーシャルリカバリーだけではありません。

• MPC（Multi-Party Computation：秘密鍵を複数の断片に分散して保管・署名する技術）：鍵そのものを単一障害点にしない方式で、「鍵を失った後に交換する」ソーシャルリカバリーとは対策の層が異なります。両者は排他ではなく組み合わせも可能です。役割分担はMPCとAAの併用設計で扱っています。
• 自己完結型の予備鍵（Base Accountのrecovery phrase／recovery key等）：第三者の承認を介さず、本人が保管するrecovery phraseから予備の署名者（recovery key）を事前に生成・登録しておく方式です（Coinbase Help: Recover your smart wallet、2026年8月11日閲覧）。ガーディアンを頼める相手や運用体制が不要な代わりに、recovery phraseの保管という「シードフレーズ問題」が形を変えて残ります。
• マルチシグ：法人トレジャリーのように毎回の取引に複数承認を要求すべき資金には、復元機構の前にマルチシグが基本です。そのうえで復元モジュールを併用できます。

判断の中心に置くべきは、「復元経路の追加は攻撃面の追加である」という本記事で繰り返してきた原則です。誰に（家族・機関・運営者・メールアドレス）、どれだけの承認権を配り、待機期間と通知で不正をどう検知するか。この設計を説明できない状態で実装だけを選ぶと、Loopring事件と同じ構造（利便性のために復元経路を1点に集中させ、その1点が破られる）を再生産することになります。

よくある質問

ガーディアンは平常時に私のウォレットを操作できますか？

できません。ガーディアンが持つのは復元手続きに対する承認権だけで、資産の送金や取引への署名はできません。承認も閾値に達しなければ効力がなく、達した後も待機期間中は現在の鍵の保持者がキャンセルできます。ただし、閾値分のガーディアンが結託すれば待機期間の経過後に署名鍵を交換できるため、「規定数が共謀しない・同時に侵害されない」構成にすることが安全性の前提です。

ガーディアンと連絡が取れなくなったらどうなりますか？

残りのガーディアンで閾値を満たせる間は復元可能です。たとえば3-of-5構成なら、2名と連絡が取れなくなっても復元できます。閾値を満たせなくなるとソーシャルリカバリーは機能しないため、登録数には余裕を持たせ、本人の鍵が使えるうちにガーディアン構成を定期的に見直して入れ替えることが運用の基本です。多くの実装では、この構成変更にも待機期間が設けられています。

ソーシャルリカバリーがあればシードフレーズは不要になりますか？

設計次第で不要にできます。Ready（旧Argent）系のウォレットは、シードフレーズを利用者に渡さず、ガーディアンによる復元だけでアクセス喪失に備える設計を商用運用してきました。ただしその場合、復元手段はガーディアン構成の健全性だけに依存するため、ガーディアンの登録・見直しを利用者が実際に行うことが前提になります。復元用の単語列（Base Accountのrecovery phraseなど）を本人が保管する方式とどちらを取るかは、対象ユーザー層の運用能力に合わせた選択です。

関連記事

全体像と前提：

• AA完全マップ2026 — スマートアカウント領域の全体俯瞰と、認証・鍵管理におけるソーシャルリカバリーの位置づけ
• ERC-4337の事業者向け解説 — 鍵ローテーションを完全に行える4337型アカウントの基礎
• EIP-7702の事業者向け解説 — 既存EOAへの委任と、その鍵管理上の制約

組み合わせる設計要素：

• パスキーウォレットの仕組み — 主鍵側をパスキーにする設計と、その紛失時の受け皿
• MPCとAAの併用設計 — 鍵の分散保管（MPC）と鍵の交換（ソーシャルリカバリー）の役割分担
• Safeのモジュラー設計 — マルチシグコアに復元モジュールを追加する構成

リスクと規制：

• AAセキュリティリスク — アカウント・Bundler・Paymaster3層の攻撃面
• AAの規制該当性 — 運営者ガーディアンとカストディ該当性の論点整理

XTELAが支援できる範囲

ソーシャルリカバリーの導入は、モジュールの組み込み作業よりも「誰に承認権を配るか」「待機期間と通知で不正をどう検知するか」という復元経路の設計の比重が大きい仕事です。XTELAは、ガーディアン構成・閾値・待機期間の設計、既製モジュール（Safe Social Recovery Module、zkEmail等）の比較選定、共謀・なりすまし・運営者集中を含む脅威の洗い出し、実装、監査前の設計整理まで、Web3サービスの技術面を支援しています。運営者がガーディアンに入る場合のカストディ該当性など、法令・会計・税務の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術構成の整理を支援します。

ソーシャルリカバリー・スマートウォレット設計について相談する

主要参考資料

• Vitalik Buterin: Why we need wide adoption of social recovery wallets（2021年1月11日）
• ERC-4337: Account Abstraction Using Alt Mempool（2026年8月11日閲覧）
• EIP-7702: Set Code for EOAs（Final、2026年8月11日閲覧）
• Safe: Introducing Candide's Social Recovery Module（2026年8月11日閲覧）
• Candide Docs: Account Recovery（2026年8月11日閲覧）
• zkemail/email-recovery: ZK Email Account Recovery（2026年8月11日閲覧）
• Clave: Universal Recovery — A Social Recovery Solution Utilizes ZK-Email（PoC解説、2023年12月25日）
• Clave: Clave Unveils the New ZK Email Recovery Beta（2025年2月25日）
• PSE Blog: Social Recovery SDK: design, implementation and learnings（2026年3月2日）
• privacy-ethereum/social-recovery-sdk（2026年8月11日閲覧）
• Argent Support: How to recover my wallet with guardians (onchain)（2026年8月11日閲覧）
• Argent Support: Argent is now Ready（リブランド告知、2026年8月11日閲覧）
• Halborn: Explained: The Loopring Hack（2024年6月）
• Loopring: Wallet Closure Announcement（2025年5月）
• Coinbase Help: Recover your smart wallet（2026年8月11日閲覧）
• Base Docs: Base Account Overview（2026年8月11日閲覧）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。各実装の提供状況、監査状態、対応アカウント規格は今後変わり得ます。導入判断の際は最新の公式ドキュメントを確認し、カストディ該当性など法令・会計・税務の判断は有資格の専門家に相談してください。