単一の復元フレーズを単純にコピーして複数の場所に分けて保管する方法と比べて、Shamirバックアップのシェア方式は実際に何が優れているのか？
単純な復元フレーズのコピーとShamirバックアップのシェアでは、それぞれが防ごうとしている方向が根本的に異なる。同じ完全な復元フレーズを3部コピーして別々に保管すれば、確かに「一箇所が盗難や損壊に遭って全体のバックアップを失う」というリスクは減らせる——しかし、その完全なコピーのうちどれか一つでも見つかれば、攻撃者は完全な鍵を手に入れる。コピー数を増やしても「単一のコピーが読み取られる」ことに対する防御は一切強化されない。
Shamirバックアップのシェアの重要な違いは、単一のシェアそれ自体が数学的に意味のある情報を構成しない点にある。攻撃者が保管しているシェアの一つを手に入れたとしても、閾値の数に達していなければ、そのシェアは彼にとって完全に無価値だ。これはシェア方式が「紛失」と「単一の場所が侵害される」という2つのリスクを同時に扱うことを意味する。一方、単純なコピーは前者しか扱っておらず、後者には一切対処していない。
Shamirバックアップが数学的にこれほど安全であるなら、なぜ記事は一般ユーザーには必ずしも適していないと示唆しているのか？本質的な問題は何なのか？
本質的な問題は数学的な安全性そのものではなく、「数学的な安全性」と「自分自身がその仕組み全体を正しく操作し覚えていられるかどうか」がまったく別の問題であるという点にある。Shamirバックアップの暗号学的保証は本物であり、十分に検証されている。問題はユーザー側にある——閾値構造では、シェアの総数、復元閾値、そしてどのシェアがどのバックアップセットに属するかを正確に覚えておく必要があり、そのメタデータ自体が失われたり誤って記憶されたりすれば、物理的なシェアがすべて完全な状態であっても鍵を復元できない。
だからこそ記事は「運用の複雑さそのものが新たな攻撃対象領域になる」と強調しているのだ。単一の復元フレーズを適切に保管するという基本的な習慣すらまだ確立していない一般ユーザーにとって、正確な記憶を要求する閾値方式を早計に積み重ねることは、むしろ運用面でのミスを起こしやすくする——そして運用面での失敗は、統計的には、攻撃者が単一のバックアップを積極的に探し出す必要があるリスクよりも、頻繁に起こりうる。
Shamirバックアップを使うと決めた場合、実際の設定時に見落としやすいが後で大きな問題になる細部はあるか？
特に見落とされやすい細部が2つある。1つ目は先述の単語リストの非互換性の問題だ。SLIP-39のシェアで使われる単語は、標準的なBIP-39の復元フレーズの単語と完全には一致しない。標準的なBIP-39復元フローしかサポートしていないウォレットでSLIP-39のシェアを使って復元しようとすると、単純に失敗する。将来復元に使うデバイスやソフトウェアが明示的にSLIP-39をサポートしていることを事前に確認する必要がある——「どうせ復元フレーズ形式なのだから互換性があるはずだ」と仮定してはならない。
2つ目の見落とされやすい細部は、閾値設定が自分の実際の保管能力と一致している必要があるという点だ。「5-of-7」は「2-of-3」よりも安全に聞こえるが、実際に本当に信頼でき、長期的に安定した保管場所が3箇所しかないのに無理に7つのシェアと7つの保管場所を用意しようとすれば、管理の難易度が自分の対応能力を超えてしまい、先述した「運用の複雑さそのものがリスクになる」の具体例になってしまう。閾値を設定する前に、自分が実際に長期的かつ安定的に維持できる保管場所の数を正直に棚卸しし、そこから逆算してシェア数と閾値を決めるべきであり、逆に安全そうに聞こえる数字を先に決めるべきではない。
シェア分割を完全に使わない、あるいは全面的にShamirバックアップに切り替える以外に、両者の中間にあたる、リスクを比較的抑えられる方法はあるか？
ある。よくある折衷案は、唯一の復元フレーズをすぐさま丸ごとシェア方式に置き換えるのではなく、Shamirバックアップをもともと想定していた地理的分散のための追加的な冗長層として使いながら、従来の方法（例えば金属板）で適切に保管した完全なバックアップを主要な復元手段として残しておくことだ。こうすることで、まだ十分に習熟していない新しい仕組みにすべてを賭けるのではなく、シェア方式が本当に得意とすること（地理的分散、複数者による分散保管）を担わせつつ、日常的に頼るのはすでに慣れていて運用リスクが低い単一バックアップのプロセスのままにできる。
もう一つの実践的な方法は、まず低価値のテスト用ウォレットで分割・分散保管・再構築の全プロセスを一度通しで実行し、閾値構造や単語リストの互換性といった細部を本当に理解しているかを確認することだ。説明書を見なくてもこのプロセスをスムーズに実行できるようになってから、実際の主要資産のバックアップをそちらに移行することを検討すべきであり、初めての操作でいきなり主要資産を使って試すべきではない。
単一の復元フレーズ（seed phrase）バックアップに対する最も一般的な批判は、それが「資産の完全な管理権を持つこと」を「この一枚の紙や金属板を所持していること」と同一視してしまう点にある——誰かがあなたの復元フレーズを手に入れ、それを使う方法を知っていれば、あなたの資産は事実上その人のものになり、第二の防衛線は存在しない。SLIP-39として標準化されたShamirバックアップは、まさにこの問題を解決するために設計されている——完全な復元フレーズを、シェア（share）と呼ばれる複数の断片に分割し、単一のシェアだけでは完全な鍵を復元できないようにする。事前に設定された閾値の数のシェアを集めて初めて復元できる仕組みだ。これは一見、単純なセキュリティの向上のように聞こえるが、実際のトレードオフは「分割数が多いほど安全」という単純な話よりもはるかに複雑である。
この仕組みは、1979年に暗号学者Adi Shamirが提案したShamir's Secret Sharingという暗号アルゴリズムに基づいており、重要な数学的保証がある——閾値の数のシェアに満たない限り、それらのシェアだけでは元の鍵に関する情報がほとんど得られない。これは、例えば単一の復元フレーズを半分に切るのとは根本的に異なるレベルの安全性である。半分に切った場合、その半分自体がすでに全体についての相当量の情報を漏らしてしまう。Trezorの実装を例にとると、ユーザーはシェアの総数と復元に必要な閾値をカスタマイズできる——例えば5つのシェアを生成し、元の鍵を復元するには少なくとも3つが必要という「3-of-5」方式が一般的だ。これは最大2つのシェアを失っても残りの3つで資産を復元できることを意味する。逆に、閾値が3の場合、誰かが2つのシェアしか入手できなければ、その2つのシェアはそれ単体では完全に無意味である。
単一の復元フレーズバックアップの核心的な弱点は単一障害点（single point of failure）である——その紙をどれだけ頑丈な金庫に保管しようと、どれだけ耐久性のある金属板に刻もうと、その唯一のバックアップが「発見され」かつ「理解される」という2つの条件を同時に満たした瞬間、すべては終わる。Shamirバックアップはこの単一障害点を、複数の物理的な場所に分散保管される複数のシェアへと分割し、攻撃者が複数の場所を同時に突破しなければならないという意味で難易度を大幅に引き上げる——単一の保管場所が盗難、火災、自然災害に遭うことを懸念するユーザーにとって、これは実質的なリスク分散になる。
バックアップの分割は「単一バックアップの紛失や盗難」に関するリスクを変えるが、別のリスク——運用の複雑さそのものが新たな攻撃対象領域とユーザーエラーの原因になる——を排除するわけではなく、むしろ拡大させかねない。閾値方式では、シェアの総数と復元閾値の組み合わせを正確に覚えておく必要がある。後になって自分が設定したのが「3-of-5」だったか「2-of-3」だったか忘れてしまったり、どのシェアがどのバックアップセットに属するか混同してしまったりすれば、事実上自分自身も解けないパズルに資産を閉じ込めてしまうことになる——こうした過剰設計による自業自得のロックアウトは珍しくない。さらに、SLIP-39が使用する単語リストは標準的なBIP-39の単語リストと完全には一致しないため、シェアを一般的なウォレットの通常の復元フローにそのまま使うことはできない。将来復元に使うウォレットソフトウェアやハードウェアが実際にSLIP-39をサポートしているか確認しておく必要があり、そうでなければどれだけ丁寧にシェアを保管していても無意味になる。複数のデバイスや場所に保管を分散させることは、それぞれの保管場所の物理的セキュリティに対する相応の信頼も必要とする——保管場所が分散すればするほど、管理と検証の複雑さも増していく。
Shamirバックアップは、自分が何をしているかをすでに正確に理解しており、地理的分散に対する実際のニーズがあるユーザーに向いている傾向がある——資産規模が十分に大きい、あるいはもともとバックアップを複数の都市や異なる信頼レベルの家族・友人に分散配置する計画がある場合、あるいは機関投資家による複数人での共同管理のような状況だ。単一の復元フレーズを安全に保管する安定した習慣すらまだ確立できていない一般ユーザーにとっては、シェア方式を早計に導入することは、既存の運用リスクの上に新たな複雑さを積み重ねるだけになりかねない——得られるセキュリティ上の利益が、自分自身の手続き上のミスによる資産喪失リスクを上回らない可能性がある。
分割バックアップ方式を導入するかどうかを決める前に、正直に一つの問いに答える価値がある——今のあなたにとって、単一のバックアップが誰かに発見され理解されるリスクと、自分自身がバックアップを紛失したり混同したりするリスク、どちらがより差し迫っているか？もし本当の懸念が「唯一のバックアップが見つかってしまうのが怖い」ことなら、Shamirバックアップは真剣に検討する価値がある。しかし、もし本当の悩みが「自分がバックアップを紛失したり混同したりするのが怖い」ことであれば、シェア方式はその既存の問題をむしろ悪化させる可能性が高い。その場合は、単一の復元フレーズの金属バックアップと保管場所をしっかり固めることの方が、より現実的な優先事項となる。