本シリーズを追ってきた人なら、multisig を支出ルールとして見る像ができているはずだ：m 本／n 本 の鍵が署名し、チェーンが閾値を強制し、お金が動く。プロトコル、派生パス、Schnorr 集約の地平線 を扱ってきた。どの場面でも答えられていたのは：お金を動かすために誰が署名しなければならないか、という問いだった。
本稿は別の問いについてだ：その署名者の一人が永遠に消えたらどうなるのか？ Multisig はひとつの答えを持っている。ソーシャル・リカバリ（social recovery） は別の答えを持つ。マーケティング用語では似て見える — どちらも「一人以上が関わる」を含む — が、解いている問題は別だ。本稿は並べて比較する記事で、両者を混同しないようにするためのもの。
TL;DR
- Multisig は 今この瞬間、誰が支出できるか に答える。各トランザクションは閾値分の共同署名者の署名を要する。チェーン自身がそれを強制する。
- ソーシャル・リカバリ は 鍵を失ったら、誰に助けられて戻れるか に答える。ウォレットは普段は 1 人の署名者（あなた）に管理される。別個の ガーディアン 群が集まって、ウォレットを新しい鍵に再結びつける リカバリ・トランザクション を承認できる。
- Multisig は支出ごとに 能動的。ソーシャル・リカバリは呼び出すまで 受動的 で、呼び出しても支出鍵を置き換えるのであって、支出に共同署名するわけではない。
- どちらもアクセス喪失からは守る。攻撃者がアクセスを 獲得する ことから本当に守るのは multisig だけ — 通常の支出に複数署名を要求するのは multisig だけだから。
- 排他的ではない。最も頑健な現実のセットアップは、multisig の支出ルールと、共同署名鍵の 1 本を失った場合に回すソーシャル・リカバリ風の機構を組み合わせる。
「ソーシャル・リカバリ」が実際に意味すること
ソーシャル・リカバリ、Ethereum エコシステムが有名にしたその意味でのもの、はスマート・コントラクト・ウォレットから来ている — Argent が初期の概念実証、Safe と ERC-4337 のエコシステムが主流化させた。仕組み：あなたのウォレットはスマート・コントラクトで、通常運用では 1 本 の署名鍵によって管理される。コントラクトには recoverWallet(newKey) 関数が組み込まれていて、ウォレット作成時に指名した ガーディアン の定足数によってのみ呼び出せる。
ガーディアンは日々のトランザクションに共同署名しない。あなたの代わりに 支出 はできない。彼らの権限はもっと狭い：あなたが「署名鍵を失った、リセットしたい」と言えば、彼らは集合して、ウォレットの制御鍵を失われたものから新しいものへと入れ替えるリカバリ・トランザクションに署名できる。その後、新しい鍵で通常通り支出に戻る。
典型的なセットアップでは 5 名のガーディアン、リカバリ閾値は 3-of-5。3-of-5 はリカバリの閾値であって支出の閾値ではない。日々の支出は今もあなたの 1 本の鍵だけで足りる。
ソーシャル・リカバリの原罪は、スマート・コントラクトを必要とすることだ — つまり Ethereum と EVM 系チェーンではネイティブに動く（特にアカウント・アブストラクション／ERC-4337 経由）が、Bitcoin やその他の UTXO チェーンには簡単には移植できない。Bitcoin で最も近いアナログは、共同署名者のひとりが「リカバリ・サービスか信頼できる人」となる multisig だ。構造的には似ているが概念的には別物 — Bitcoin 版では、信頼できる人がリカバリだけでなく支出にも署名している。
仕組み：それぞれが「鍵を失った」をどう扱うか
最悪のケースを具体的に想像してほしい：スマホを海に落とし、そのスマホ用の seed 紙は財布の中（こちらも海の中）、紛失した鍵の有効なバックアップは無い。
2-of-2 multisig の下（SSP のデフォルト）：ウォレットは 凍結 される。あらゆる支出に両署名が必要だが、署名者は 1 人しか残っていない。これを救うスマート・コントラクトの裏技は無い；オンチェーンの支出ルールは 2-of-2、それまでだ。あなたのリカバリ経路は 2 本目の seed — self-custody チェックリスト が両方の seed を負担を担うものとして扱うのは、まさにこのシナリオのためだ。
2-of-3 multisig の下（セレクター記事 のソロ・冗長セットアップ）：ウォレットは なお運用可能 だ。3 本のうち 2 本を持っており、チェーンはそれを有効な定足数として受け入れる。支出もできるし、新しい 3 本目の鍵と組んだ別の 2-of-3 ウォレットへ資金を移すこともでき、失われた古い鍵は無関係になる。
ソーシャル・リカバリのウォレット の下：ウォレットは これも運用可能 だが、別経路で。署名鍵の定足数は無く、署名鍵は 1 本（失われたもの）。代わりにガーディアンに連絡し、リカバリ・トランザクションへの署名を依頼する。閾値が承認された後、ウォレットは新しい支出鍵に再結びつけられる（あなたの管理下）。それから 1 鍵での支出に戻る。
両方のリカバリは表面的には似ている — 「信頼できる当事者の定足数に自分の代わりに署名してもらう」 — が、行っていることは違う。Multisig のリカバリはずっと存在していた 既存の定足数 を使う。ソーシャル・リカバリは、まさにこの場合のためにだけ存在する 潜在的な定足数 を起動する。
それぞれが守るもの（と守らないもの）
両アーキテクチャとも アクセス喪失 から守る：鍵を失ってもリカバリできる。
鋭く分かれるのは 無断の支出からの保護 だ。
Multisig は単一鍵の盗難から守る。 攻撃者があなたのラップトップをフィッシングしてホット・ウォレットを空にしたり、ハードウェア・デバイスを盗んだりしても — n 本のうち 1 本 しか持っておらず、お金は動かせない。完全な支出閾値に届かない。前シリーズの 7 つの障害モード 記事が、これが実際にどれだけ重要かを述べている：単一鍵の侵害はリテール self-custody での支配的な攻撃ベクトルで、multisig がその答えだ。
ソーシャル・リカバリは単一鍵の盗難からはまったく守らない。 標準的なソーシャル・リカバリのモデルでは、あなたの 1 本の署名鍵が毎トランザクションに署名する。その鍵が侵害されると、攻撃者は即座にウォレットを空にする — そして ソーシャル・リカバリのプロセスは助けにならない。なぜなら、ガーディアンが介入する前に資金はすでに消えているからだ。リカバリは 喪失 のための道具であって 盗難 のためのものではない。
両者を重ねることもできる：スマート・コントラクト・ウォレットは multisig の支出ルール と ソーシャル・リカバリ式の鍵ローテーション機構の両方を実装できる。現代の ERC-4337 スタック（プロトコル文脈は アカウント・アブストラクションの解説 を参照）はこれを組み合わせ可能にする。だが純粋なソーシャル・リカバリ単独はリカバリの物語であって、セキュリティの物語ではない。
実用的な比較
| 性質 | Multisig (2-of-2 / 2-of-3) | ソーシャル・リカバリ |
|---|---|---|
| 日々の UX | 各共同署名デバイスで署名 | 1 台のデバイスで署名 |
| 単一鍵の盗難に耐える | はい | いいえ |
| 単一鍵の喪失に耐える | 2-of-2：いいえ；2-of-3：はい | はい（ガーディアン経由） |
| Bitcoin で動く | はい | いいえ（スマート・コントラクトが要る） |
| Ethereum/EVM で動く | はい（BIP48 / Safe） | はい（Argent、Safe、ERC-4337） |
| リカバリにかかる時間 | 即時（生き残った定足数で署名） | 数時間〜数日（ガーディアン調整） |
| 信頼の前提 | 共同署名鍵を保持するデバイス／人 | 悪意ある結託をしないと信頼するガーディアン |
| オンチェーン可視性 | multisig 出力として可視（Schnorr 集約されない限り） | ほとんどの時間、単一鍵ウォレットに見える |
表で注目すべき 2 つのパターン：
第一に、multisig はより広い道具 だ。より多くのチェーンで動き、より多くの攻撃に耐え、現在プロトコル・レベルでより良く監査されている。ソーシャル・リカバリは 選択肢である場合 には UX 上より親しみやすいが、適用範囲は狭い。
第二に、信頼の前提が違う。Multisig は、共同署名鍵を保持するデバイスが同時に全て侵害されないことに信頼を置く。ソーシャル・リカバリは、十分な数のガーディアンが資金を奪うために結託しないことに信頼を置く。両者ともふさわしいユーザにとって妥当な信頼モデルだが、同じモデルではない。
いつどちらが欲しいか
- あなたが 1 台のデバイスのソロ・ユーザで、世界の他は UX 砂漠：ソーシャル・リカバリの勝ち。Argent / Safe / smart-account のフローは本当に最も摩擦の少ない self-custody の選択肢で、鍵紛失のシナリオは初心者が実際に直面することが最も多いもの。欠点 — 盗難への保護がない — は意識的に受け入れる、できれば 5 桁未満の残高との引き換えに。
- ソロ・ユーザだが、保有が非自明：multisig の勝ち。SSP の 2-of-2 デフォルトは盗難に対するハードルを上げ、2-of-3 バリアントは鍵紛失への弾力性を加え、両者とも特定のスマート・コントラクト・プラットフォームではなく公開規格に基礎づけられている。摩擦は実在するが、賭けに比して妥当だ。
- 組織・パートナーシップ・ファミリーオフィス：multisig は必須；ソーシャル・リカバリは人間工学的な追加要素だ。すべての支出に対する真の共同管理が欲しい、リカバリだけのではなく。多くの組織は multisig の支出ルールに加え、署名者が去る場合の別個で慎重な鍵ローテーション手続きへと落ち着く。
- その中間で、Ethereum 上：両方をレイヤする。Safe 風のスマート・コントラクト・ウォレットは、2-of-3 multisig の支出ルール と ソーシャル・リカバリのローテーション・フローを上に重ねて運用できる。アカウント・アブストラクション のエコシステムが向かう先がそこだ。
本シリーズの読者の大半が使う具体的な SSP 2-of-2 セットアップでは、ソーシャル・リカバリは今のところ機能ではない — 設計による。共同署名者の両方が あなた、リカバリの物語は「2 本目の seed を使う」、価値は安価に得られる盗難耐性にある。ソーシャル・リカバリは別の問題を解く — 「custody には慣れた、もう少し楽にしてくれ」の後で出てくる問題だ。
あなたにとってこれが意味すること
ファイルに収めるべき 3 つの要点：
- 互いの代替品ではない：「ソーシャル・リカバリがあるから multisig は要らない」と謳うウォレットがあれば、それはマーケティングであって工学ではない。リカバリは喪失から守り、multisig は盗難から守る。それぞれが答えている問いは重ならない。
- あなたの SSP 2-of-2 セットアップは 支出ルール の製品 だ。デバイスの 1 台の喪失は 2 本目の seed から回復され、ガーディアン定足数から回復されるのではない。本シリーズの最終記事 — Multisig の障害モードと SSP がそれをどう緩和するか — がその回復が障害モードごとに正確にどう展開されるかを辿る。
- 前へ建てよ、横へではない：本当にあなたのスタックが 2-of-2 を超える成長を見たとき、次の段はソーシャル・リカバリで multisig を置き換えるのではなく、地理的に分離された鍵を持つ 2-of-3 multisig だ。本シリーズの 2-of-3 の記事（セレクター）がその移行を準備する；次に来る single-signer multisig の記事が、その将来のセットアップがどう「1 つのウォレット」に感じられ続けるかを説明する。
