マルチシグと鍵管理：「単一の鍵」という単一障害点をなくす

分散システムの安全性は、最終的に「秘密鍵をどう守るか」に行き着きます。1本の鍵の紛失や盗難がすべてを失わせる構造を避けるために生まれたのが、マルチシグネチャとしきい値暗号の技術です。

マルチシグネチャ（M-of-N）の仕組みと具体例

マルチシグ（multisignature）は、資産の移動や重要な操作に「N人の鍵保有者のうちM人以上の署名」を要求する仕組みです。たとえば2-of-3のウォレットでは、3本の鍵のうち任意の2本が揃わなければ送金できません。1本の鍵が盗まれても資産は動かせず、1本を紛失しても残り2本で復旧できます。盗難耐性と紛失耐性を同時に高められるのが本質的な価値です。

典型的な2-of-3の鍵分散では、1本目を普段使うスマートフォンのウォレットアプリに、2本目を自宅の金庫に保管したハードウェアウォレットに、3本目を銀行の貸金庫や信頼できる第三者（弁護士など）に預けるといった配置が取られます。日常の送金には手元の1本と、もう1本を都度取り出して署名すれば十分で、3本すべてを一箇所にまとめないことで、空き巣や端末紛失といった単一の事故で資産全体を失うリスクを避けられます。

• 個人・企業のウォレット保護: 秘密鍵を自宅・金庫・信頼できる第三者などに分けて保管し、単一箇所の侵害で資産を失うリスクを排除する。取引所やカストディ事業者の内部統制（複数役職者の承認）にも使われる。
• エスクロー（第三者預託）: 買い手・売り手・仲裁者の2-of-3を組めば、取引が円満なら当事者2人の署名で決済し、揉めた場合のみ仲裁者が一方に加勢して解決できる。仲裁者は単独では資金に触れられない。

Bitcoinにおけるマルチシグ実装: P2SHとP2WSH

BitcoinのマルチシグはOP_CHECKMULTISIGというスクリプトオペコードで実現されます。初期には「N個の公開鍵とM-of-N条件」をそのまま送金先スクリプトに書く方式が使われましたが、スクリプトが長くなるほど手数料も嵩み、受け取り側は送金前に複雑な条件を知る必要がありました。2012年に導入されたP2SH（Pay-to-Script-Hash、BIP16）は、この問題を解決しました。実際の条件（redeem script）を明かさず、そのハッシュ値だけをアドレス（3から始まる）として公開し、資金を使う際に初めて条件を提示する方式です。

SegWit以降はP2WSH（Pay-to-Witness-Script-Hash）が主流になりました。redeem scriptと署名データをwitnessという別領域に分離することで、ブロックサイズの計算上「割引」が適用され、手数料が下がります。アドレスはbc1qから始まります。さらに2021年のTaproot以降は、MuSig2などの鍵集約プロトコルにより、複数署名者が協調してオンチェーン上は単一署名にしか見えないマルチシグを作れるようになり、手数料削減とプライバシー向上の両方が進んでいます。

Ethereumのスマートコントラクトウォレット

Ethereumなどのスマートコントラクト対応チェーンでは、マルチシグをコントラクト（プログラム）として実装するアプローチが主流です。代表格のGnosis Safe（現Safe）では、資産はコントラクトのアドレスが保有し、コントラクト内に「オーナーの一覧」と「しきい値M」が記録されています。送金などの取引提案に対してオーナーたちが署名を集め、しきい値に達した時点で誰かが実行トランザクションを送ると、コントラクトが署名を検証して初めて資産が動きます。

プログラムであることの強みは柔軟性です。オーナーの追加・削除やしきい値の変更、1日あたりの送金上限、特定操作の時間ロック（タイムロック）、緊急停止や相続の仕組みまで、運用ポリシーをコードとして組み込めます。一方で、コントラクト自体のバグが新たなリスクになることも歴史が示しており（2017年のParityウォレット事故では数十万ETHが凍結）、監査済みの実績ある実装を使うことが鉄則です。詳しくはスマートコントラクトを参照してください。

しきい値署名（TSS/MPC）とオンチェーンマルチシグの比較

マルチシグとよく混同される技術に、しきい値署名と秘密分散があります。いずれも「M-of-N」の性質を持ちますが、仕組みと性質は大きく異なります。

• マルチシグ: N人がそれぞれ独立した鍵を持ち、M個の署名がそのまま複数個チェーン上に記録される。構成が透明で監査しやすい反面、署名データが大きく、どの鍵が署名したかが公開される。
• しきい値署名（TSS: Threshold Signature Scheme）／MPC（Multi-Party Computation）: 1つの秘密鍵を数学的な「断片（シェア）」として分散生成し、完全な鍵をどこにも復元しないままM人の協調計算で単一の署名を作る。外部からは普通の1署名にしか見えないため手数料も匿名性も有利だが、プロトコルが複雑で実装の信頼性が問われる。
• Shamirの秘密分散（SSS）: 秘密（鍵やパスフレーズ）を多項式に埋め込んでN個の断片に分け、M個集めると元の秘密そのものを復元する古典的手法。バックアップには優れるが、復元の瞬間に完全な鍵が1か所に現れるため、署名のたびに使う運用には向かない。

DAOトレジャリー管理の実例

分散型自律組織（DAO）の資金運用は、マルチシグの実用例として最も規模が大きい分野の一つです。多くの大規模DAOは、コミュニティ投票で選出された複数名の署名者からなるSafeマルチシグを、資金執行の最終防衛線として運用しています。UniswapやENS、Gitcoinといった著名なDAOも、財団やコミュニティが管理するSafeを通じてトレジャリー（国庫）資金を管理しており、単独の管理者が資金を持ち逃げしたり、1人の鍵が漏洩しただけで資金が流出したりする事態を防いでいます。

• オンチェーン投票＋マルチシグ執行の二段構え: 提案はガバナンストークンによる投票で承認されるが、実際の送金は選出された署名者たちのマルチシグが実行する。投票結果の改ざんと、署名者の独断専行の両方を防ぐ。
• タイムロックとの組み合わせ: しきい値の署名が揃ってから一定時間（数日程度）が経過しないと実行されない仕組みを重ねることで、不正な提案が通っても、コミュニティが異議を唱えて対抗策を講じる猶予を確保する。
• 資金の階層化: 日常的な小口支出用のホットウォレットと、大部分の資産を保管する高しきい値のSafe（コールドトレジャリー）を分け、必要な分だけを都度移動させる運用が一般的。

鍵管理のベストプラクティスとソーシャルリカバリー

マルチシグを組んでいても、個々の鍵の管理がずさんであれば意味がありません。実務では次のような対策が定着しています。

• 署名者・保管場所の地理的分散: 同じ建物や同じクラウドサービスに鍵をまとめない。火災や自然災害、単一事業者の障害でまとめて失われるリスクを避ける。
• ハードウェアウォレットの使用: 秘密鍵をインターネットに繋がらない専用デバイス内で生成・保管し、マルウェアによる窃取を防ぐ。
• 署名フローの定期リハーサル: 実際に資金を動かさない訓練用の少額送金で、全署名者が手順どおり操作できるかを定期的に確認する。署名者の異動や退職時には鍵の失効・入れ替えも忘れずに行う。
• 署名者の任期制・入れ替え: 特定の個人に権限が固定化しないよう、DAOなどでは署名者を定期的に選挙で入れ替える運用が一般的。

個人向けウォレットでは、ソーシャルリカバリーウォレットという選択肢も普及しつつあります。あらかじめ指定した複数のガーディアン（信頼できる友人・別デバイス・専門サービスなど）のうち一定数以上が承認すれば、シードフレーズなしでもウォレットへのアクセスを取り戻せる仕組みです。仕組みとしてはM-of-Nの承認を求める点でマルチシグと同じ発想であり、DIDのセクションで触れた「鍵紛失時のリカバリー」問題への、ウォレット側からの一つの回答と言えます。

鍵管理は「技術の問題」であると同時に「運用の問題」です。マルチシグ・TSS・秘密分散はいずれも、単一障害点をなくすというP2P的な思想を、価値と権限の管理に持ち込んだものだと言えるでしょう。