マルチシグウォレットはセキュリティを本当に向上させるのか？脅威モデルで検証する

マルチシグネチャウォレット——M-of-N の鍵がすべてトランザクションに署名しなければ実行できないウォレット——は、シングルキーのホットウォレットからの明白なアップグレードとして一般に紹介される。DAO、取引所、および本格的な暗号資産ネイティブ企業の多くは、何らかの形のマルチシグ（Safe、Squads、Multisig.js、閾値署名バリアントなど）を通じてトレジャリーを管理している。

その評判は十分に根拠のあるものだが、特定の脅威モデルに対してのみ有効である。マルチシグは資産が盗まれる最も一般的な手口のいくつかを無効化するが、他の手口にはほとんど効果がない。以下では率直な視点から、マルチシグが実際に強みを発揮する場面、限界がある場面、そして導入によってかえってセットアップが安全でなくなる可能性がある場面を整理する。

マルチシグとは何か——簡単に

2-of-3 マルチシグでは、3つの秘密鍵が存在し、そのうちの任意の2つがトランザクションに署名しなければオンチェーンで実行されない。ウォレット自体はスマートコントラクト（Ethereum / EVM の世界では）、またはネイティブなマルチシグ出力タイプ（Bitcoin では P2SH/P2WSH による）である。コントラクトが署名を検証し、トランザクションを転送する。

EVMエコシステムで最も広く使われている実装は Safe（旧 Gnosis Safe）である。Solana では Squads が同じ役割を担う。Bitcoin はネイティブなマルチシグサポートの長い歴史を持ち、PSBT ワークフローを通じてハードウェアウォレットと組み合わせて使われることが多い。

閾値署名スキーム（TSS、FROST、MPC）は、オンチェーンの単一鍵で同様の結果を達成する——各署名者は秘密鍵のシェアを保持し、それを再構築することなく共同で署名する。脅威モデルの観点からは、後述するいくつかの注意点はあるものの、以下のポイントのほとんどが両者に等しく当てはまる。

マルチシグが無効化するもの（朗報）

シングルキーの侵害

これが最大のメリットである。署名者の1人のハードウェアウォレットが盗まれ、1人の携帯電話がマルウェアに感染し、1人のシードフレーズが漏洩しても、その単一の鍵を持つ攻撃者は資産を移動できない。少なくとも他の M-1 個の鍵を同時に侵害する必要がある。

2-of-3 のセットアップでは、攻撃者は2つの独立したエンドポイントを侵害しなければならない——理想的には異なる人物が異なるハードウェアで、異なる物理的な場所に保管しているもの。同一ウィンドウ内で2つの独立した侵害が発生する確率は、1つの侵害が発生する確率よりも通常は桁違いに低い。

インサイダーリスク

単独でフルカストディを持つ人物は、激高して離脱したり、裏切ったり、強制されたり、単純に壊滅的なミスを犯す可能性がある。マルチシグは共謀を強制する。DAOや企業にとって、これがしばしば主要な動機となる——外部攻撃者に対するセキュリティ上の利点は、内部の一個人に対するガバナンス上の利点よりも副次的なものである。

鍵の紛失からの回復

N > M の M-of-N セットアップでは、1つの鍵を失っても壊滅的ではない。残りの署名者が資産を新しいマルチシグに移動し、失われた鍵を交換できる。これはシングルキーカストディからの大きな改善であり、シングルキーでは1つのシードフレーズを失うと永久に失われる。

ユーザーへのフィッシング

多くのウォレットフィッシング攻撃（偽のエアドロップサイト、悪意のあるトークン承認、ドレイナーコントラクト）は、ユーザーが単一のブラウザセッションで悪意のあるトランザクションに署名することに依存している。マルチシグは別の面での確認ステップを追加する——Safe のようなUI、または複数のデバイスでのハードウェア承認——これにより、ユーザーが意図していなかった何かに署名しようとしていることに気づく別の機会が生まれる。

マルチシグが無効化しないもの（不都合な真実）

これが多くの簡易的な解説が省略するセクションである。

マルチシグ自体のスマートコントラクトのバグ

マルチシグはスマートコントラクトである。コントラクトにバグがあれば、どれほど慎重な鍵管理をしても意味がない。史上最も高額なマルチシグインシデント——2017年11月のParity マルチシグフリーズ——は鍵の侵害ではなく、コントラクトのバグによるものだった。単一のトランザクションによって約1億5000万ドル相当の ETH が永久にアクセス不能となった。

現代の Safe は Ethereum 上で最も監査されたコントラクトの一つであり、これまで良好な実績を保っているが、要点は変わらない。「守るべき秘密鍵1つ」を「信頼すべきスマートコントラクト1つ」に置き換えているのである。その信頼は監査と時間によって繰り返し獲得されなければならない。

署名UIの侵害

ほぼすべてのマルチシグの署名は何らかのインターフェースを通じて行われる——SafeのウェブUI、ウォレットプラグイン、カスタムダッシュボード。そのインターフェースが侵害された場合（DNSハイジャック、依存関係へのサプライチェーン攻撃、悪意のあるブラウザ拡張機能）、攻撃者は署名者Aに「alice.eth に 1 ETH を送信する」と表示しながら、実際にはハードウェアウォレットへの署名のために「attacker.eth に 1000 ETH を送信する」というトランザクションを送信することができる。

多くのハードウェアウォレットは実際の宛先アドレスを表示するが、署名者は日常的に流し読みをする。2025年初頭のBybit インシデントは Safe UI の侵害によるものであった。すべての署名者が通常の取引だと思って承認する一方で、プロキシコントラクトが改変されていた。

マルチシグは1つの鍵しか持たない攻撃者から守ってくれる。すべての署名者の前に間違ったトランザクションを提示できる攻撃者からは守ってくれない。

複数の署名者に対する協調フィッシング

署名者が特定されており連絡が取れる場合——公開されている Safe アドレスを持つトレジャリーでは通常そうである——攻撃者は全員を標的にできる。各署名者に同じフィッシングキャンペーンを実行する。待つ。3人中2人が同じ日に疲れていたり、注意散漫であったり、油断していれば、閾値に達する。

これが実際には巧みに運営されているマルチシグに対する最も現実的な攻撃であり、その防御策はほとんどが技術的ではなく手続き的なものである。署名UIとは独立した別チャネル（Signal、別のチャット、電話通話）でのすべてのトランザクションの帯域外確認、および $X を超えるトランザクションは署名前に必ず生で議論するという厳格なポリシーが必要だ。

オフチェーンの鍵ストレージの侵害

「署名鍵」が実際には2人のエンジニアの MetaMask シードフレーズと事務所の金庫にあるハードウェアウォレット1台による 2-of-3 である場合、それはマルチシグに見せかけた OPSEC の問題である。技術的には閾値を満たしているが、多様性は見かけだけだ。2人のエンジニアのマシンへのラップトップマルウェア感染、または事務所への単一の侵入で、閾値が侵害されうる。

真の多様性には以下が必要である:

• 異なるハードウェアモデル。（Ledger 1台、Trezor 1台、Keystone 1台。）
• ソフトウェア署名には異なるオペレーティングシステム。
• 永続的なストレージには異なる物理的な場所。
• 該当する場合は、異なる脅威プロファイルを持つ異なる人物。

閾値を超えた損失

回復のもう一つの側面として、2-of-3 で2つの鍵を失うと永久に失われる。3-of-5 で3つの鍵を失っても同様だ。M と N の差が大きいほど、単一の損失に対して安全だが——しかし攻撃者が M 人の署名者をフィッシングで見つけやすくなる。

これは避けられないトレードオフである。M が高いほど外部攻撃に対して安全だが、回復は困難になる。M が低いほど回復しやすいが、攻撃も容易になる。両方を最適化できる設定はない。

マルチシグがかえって事態を悪化させる場合

いくつかの率直なケースを挙げる:

• 非常に少額の残高の場合、マルチシグの運用上のオーバーヘッド（トランザクションの調整、EVM でのガスコスト、学習コスト）により、シングルキーカストディでは発生しなかったミスが生じる可能性がある。200ドル程度のポケットマネー的な暗号資産には、ハードウェアバックアップのシングルキーが適切なツールである。
• マルチシグをリカバリースキームとして扱うソロユーザーが、実際には自分だけが管理するデバイスに3つの鍵をすべて保管している場合、マルチシグは脅威モデルを変えることなく複雑性を加えるだけとなる——今日1台のデバイスを侵害できる単独の攻撃者は、おそらくすべてを侵害できる。
• 実際には署名者の多様性がない組織の場合——同じオフィス、同じVPN、同じSSOを使用している全員——閾値は形式的なものになってしまう。

3つのケースすべてにおいて、答えは「シングルキーカストディを使う」ではない。「マルチシグを正しく使うか、それを行うカストディアンを使う」である。しかし、運用上の実践に関わらず、コントラクトタイプだけで安全性が確保されると思い込むことが、世間の注目を集める損失につながるのである。

適切な運用の姿

2-of-3 または 3-of-5 のマルチシグは、以下のすべてが真である場合にトレジャリー管理として機能する:

• 署名者は異なる人物であり、可能であれば異なる管轄区域にいる。
• 署名デバイスは異なるハードウェアブランドで、異なるOSを使用している。
• トランザクション確認には、署名UIから独立した別のコミュニケーションチャネルを使用する。
• いずれかの署名者が承認する前に、期待される差分（コールデータ、ターゲット、値）に対してトランザクションのペイロードを検証するための文書化されたプロセスが存在する。
• マルチシグコントラクト自体が十分に監査されており（2026年時点では Safe が保守的なデフォルトである）、バージョンが固定され既知のものである。
• 署名者の交代手順が存在し、リハーサルされている。

これは、多くのチームが最初に想定するよりも厳しい規律である。良い知らせは、その規律が一度限りの投資であること。悪い知らせは、その規律がコントラクトよりもずっと重要だということである。

ドメインとの関係

名前管理はオフチェーンの世界でマルチシグに最も強く類比できるものの一つである。単一パスワードの背後にある単一のレジストラアカウントで管理されるドメインは、シングルキーウォレットである。レジストラロック + レジストリロック + DNS プロバイダーでの 2FA + 複数の権威ある DNS プロバイダーで保護されたドメインは、構造的にマルチシグである。つまり、名前が移動する前に複数の独立した要素がそれぞれ侵害される必要がある。

Namefi はこれをさらに発展させ、所有権をオンチェーンの記録として表現し、マルチシグウォレットで直接保持できるようにする。トレジャリーを守るのと同じ閾値スキームが、今度はDNS コントロールプレーンを守ることができる——単一のフィッシング被害者が、トレジャリーを単独では引き出せないのと同様に、会社のドメインを失うことはできなくなる。脅威モデルのアップグレードは両方の世界で同じである。「1つのクレデンシャルを信頼する」を「N の独立した要素のうち M を侵害する」に置き換えることだ。

参考文献・さらに詳しく

• Safe — スマートアカウントコントラクトと監査.
• IETF FROST — RFC 9591, the Flexible Round-Optimized Schnorr Threshold protocol.
• Bitcoin — BIP-174 PSBT.
• Parity — マルチシグフリーズのポストモーテム.
• a16z crypto — Safe マルチシグ運用の実践ガイド.