要旨：MPC（Multi‑Party Computation）ウォレットは「秘密鍵をひとつにまとめない」ことによって、紛失や単独乗っ取りの単一障害点（Single Point of Failure）を排除する鍵管理方式です。従来のマルチシグと異なり、オンチェーンに複数署名の痕跡を残さず、EVM系・BTC系・Solana等の異なる署名方式にも柔軟に対応できます。本稿では、仕組み・設計・セットアップ・日次運用・障害対応・相続まで、個人投資家でも実装可能な水準に落として具体的に解説します。
MPCウォレットの仕組みを最短理解
MPCウォレットでは、秘密鍵は最初から存在せず、鍵シェア（秘密分散片）が各デバイスに生成・保持されます。送金などの署名が必要なときだけ、各シェアが暗号プロトコルに従って部分署名を作り、これらを合成して最終署名を得ます。代表的にはECDSAやEdDSA（Schnorrを含む）に対応し、t-of-nの閾値（しきい値）署名を実現します。結果として「署名は完成するが、完全な秘密鍵はどこにも復元されない」ため、単独デバイスの流出・紛失が致命傷になりにくい利点があります。
マルチシグと何が違うのか
マルチシグはオンチェーンで複数署名を検証するため、ガス代増（チェーンによる）や実装制約、チェーン互換の課題が発生しやすい一方、可視性・監査性は高い特徴があります。対してMPCはオフチェーンで閾値署名を作るため、チェーン側からは「通常の単一署名トランザクション」に見えます。したがって手数料や対応チェーンの広さで優位になりやすく、既存アドレス形式を変えずに移行できるケースも多いです。ただし、監査ログの自前設計やセキュアチャネルの確保など、オフチェーン運用の作り込みが重要になります。
t-of-n設計：現実的なパターン
個人～小規模チームで現実的な構成は次のとおりです。
- 2/3構成：メイン端末（スマホ）＋自宅端末（PC）＋オフライン保管デバイス（USB/HSM等）。日常はスマホ＋PCで承認し、緊急時はPC＋オフラインの組み合わせで復旧できます。
- 3/5構成：スマホ×2（メイン/予備）＋PC＋オフラインデバイス＋信頼できる第三者（弁護士・家族代表）。高額運用や相続設計を見据える場合に有効です。
- 2/2/3の職務分離：オペレーター、リスク管理、監査（読み取りのみ）に役割を分け、送金承認は2/3、設定変更は全会一致などのポリシーをルール化します。
初期セットアップ：安全に始める手順
- デバイスを決める：日常用スマホは最新OSに更新し、生体認証＋PINの二段構え。PCは専用ユーザーと標準権限。バックアップ用はオフラインで初期化。
- 乱数源を確保：オフライン端末で乱数デバイス（TRNG）またはOSのCSPRNGを利用。ネット接続前に鍵シェアを生成できる実装を選びます。
- 鍵シェア暗号化：各シェアをパスフレーズと端末固有情報で二重暗号化。復号に2要素を必要とする形にして、物理盗難への耐性を上げます。
- 保管ポリシー：オフラインデバイスは耐火耐水の金庫へ。場所は分散し、地理的相関（同一建物・同一市区）を避けます。
- 監査ログの仕組み：トランザクション提案、各シェアの承認者、承認時刻、IP（概位）、金額、宛先、リスクスコアなどをCSV/JSONで自動保存。後述の「日次運用」と連携します。
日次運用フロー（最小限で実務的）
- 送金は二段階承認：オペレーターが提案、リスク管理者が別デバイスで承認。同一デバイスでの連続承認は禁止にします。
- アローワリスト：頻出宛先は事前登録し、少額上限（例：相場換算で1日10万円）を自動許可。新規宛先は常に2/3承認＋待機時間（Time‑lock）を課します。
- 金額・時間帯ポリシー：一定額超は追加承認者を要求。深夜帯（例：22:00–6:00）は承認不可などを機械的に適用します。
- DeFi操作の分離：ブリッジ・DEX・レンディング等の承認（approve）は金額上限と期限（短期）を必須化。無期限approveは避け、不要になれば速やかに取り消します。
- 毎日のログ点検：自動レポートをメール/チャットに配信。未承認提案、失敗署名、失敗アクセス、ポリシー違反を一覧化し、翌営業日までに起票します。
事故対応（インシデントレスポンス）
- デバイス紛失：当該シェアを即無効化（ローテーション）。t-of-nを満たす残余シェアで資産を避難。新デバイスに再配布。
- パスフレーズ漏えい：二要素のうち片方の妥協に留まるならリスク評価の上で即日ローテーション。両方が漏れた疑いがあれば、緊急モードで全資産を隔離先に退避。
- ソーシャルエンジニアリング：チャット・電話での緊急装い要請は必ずコールバック・本人確認・合言葉を要求。即時振込はしないルールを徹底します。
- DeFi契約の不具合：無期限approveを取り消し、被疑アドレスを宛先ブラックリストへ。ブリッジ停止・TVL急減などの兆候時は一旦ポジションを縮小。
バックアップと相続設計
MPCは「復元可能で、かつ本人以外が勝手に復元しにくい」設計が肝です。
- 暗号化シェアの紙・金属保管：パスフレーズのヒントやKDFパラメータは別保管。同一場所に集約しないこと。
- エスクロー型相続：第三者（弁護士等）が持つシェアは、遺言書・信託契約に基づく時間遅延と通知の条件付き解放にします。
- 定期点検：半年ごとに復旧ドリル（模擬的なデバイス喪失）を実施し、復元時間・手順を記録。失敗があれば手順書を改訂します。
費用とツール選定の実務観点
MPCは大別して「自前運用（オープン実装＋クラウド/HSM）」と「サービス提供（SaaS/カストディ型）」があります。自前は柔軟・低ガス・ログ完全掌握の反面、可用性設計と監視責任が増します。サービス型は導入容易・24/7監視・保険等の付帯がある一方、事業者リスク・価格改定・KYC/地域制限に注意が必要です。いずれにせよ、署名ポリシーを自分で決めて実装できるかが選定の基準になります。
よくある失敗と対策
- 同一ネットワークにシェアを集約：同一Wi‑Fiで同時承認は避け、キャリア回線＋別回線の組み合わせを標準とします。
- オフラインシェアの暗号化不足：暗号化なしのUSB保管は論外。強固なKDF（反復回数/メモリ強度）を設定します。
- 無期限approveの放置：定期棚卸しで権限を取り消す。監査レポートに自動で「期限切れ間近」を出すと運用が回りやすいです。
- ログの未整備：誰が、いつ、どこで、何を承認したかを残さないと、事後検証も再発防止もできません。
ケーススタディ：個人投資家の現実解
例として、暗号資産の管理残高が数百万円規模で、月に数回の送金・DeFi操作を行うケースを想定します。
- 構成：2/3（スマホ・PC・オフラインUSB）。承認はスマホ＋PC、設定変更はPC＋USB。
- ポリシー：新規宛先は2/3＋24時間待機。既存宛先は1日10万円まで自動許可。深夜帯は承認不可。
- DeFi：approveは都度・金額限定・7日で失効。ブリッジは高負荷時は停止、代替ルートを準備。
- バックアップ：暗号化シェアを金庫と貸金庫に分散。半年ごとに復旧ドリル。
- 監査：毎朝メールに前日ログを自動配信。異常時は即時隔離用アドレスへ退避。
チェックリスト（導入前の最終確認）
- t-of-nと役割分担は妥当か（最小2/3、重要設定は厳格）
- デバイスの物理分散・ネットワーク分散は実現できているか
- 承認フローと金額・時間帯ポリシーはツールで強制できるか
- 監査ログは自動保存・自動配信されているか
- バックアップと相続の実地リハーサルを済ませたか
まとめ
MPCウォレットは「鍵を分散して守る」設計思想そのものであり、個人投資家でも現実的に導入できます。肝は、（1）適切なt-of-n、（2）機械で強制される承認ポリシー、（3）即応できる事故対応計画、（4）定期的な復旧ドリルの四点です。ここまで整えば、日常の利便性を犠牲にせずに強固なセルフカストディを実現できます。
コメント