資産を守れない運用は、稼ぐ戦略より先に破綻します。MPCウォレット（Multi‑Party Computation）は、秘密鍵を「どこにも単独で存在させない」設計により、ハッキング・紛失・内部不正による単一点障害を実質的に排除します。取引所（CEX）カストディや単一ハードウェアウォレット依存からの脱却を狙う個人投資家・小規模チーム向けに、実装から日常運用までを実務目線で解説します。
MPCの要点：なぜ“鍵を1本にしない”のか
従来は「12/24語のシード＝単一点障害」。漏えい・紛失・強要のいずれかで資産は消えます。MPCは秘密鍵を数個の計算参加者（デバイス/人/サーバ）に分散し、各参加者が鍵の“断片（秘密分散のようなもの）”を保持します。署名はしきい値署名（TSS: Threshold Signature Scheme）で行い、例えば2-of-3や3-of-5など所定人数が揃った場合のみ署名が成立します。完成した秘密鍵はどこにも生成されず保存もされません。
マルチシグとの違い
- チェーン互換性：マルチシグはチェーンごとに仕様差（例：BitcoinのマルチシグとEVMのマルチシグコントラクト）。MPCは通常、基盤の署名アルゴリズム（ECDSA/EdDSA等）に依存しつつアドレス形式をシングルキーと同様に保てるため、互換性が高く移行も容易です。
- プライバシー/手数料：マルチシグはオンチェーンに「複数署名」を示す痕跡が出る場合があり、手数料も膨らみやすい。一方MPCはオンチェーン上は単一署名と同等なので、手数料・露出面で有利です。
- 運用柔軟性：マルチシグは設定変更にオンチェーン手続きが要る設計が多いのに対し、MPCはオフチェーンで参加者追加/削除やしきい値変更のワークフローを柔軟に設計できます。
最低限の暗号メカニズム理解（投資家向け超要約）
MPCは各参加者が鍵素材（シェア）を持ち寄り、対話型プロトコルで署名の一部（部分署名）を生成し、集約して最終署名にします。代表的にはECDSA‑TSS（EVM・BTC系）とEdDSA‑TSS（Solana等）。いずれも「誰か1人の端末に完全鍵が再構成されない」ことが肝です。
注意すべきはランダムネス（nonce）と反復攻撃耐性。不適切な乱数やエラー時の再送が続くと鍵漏えいに繋がる設計もあり得ます。プロバイダを使う場合は、TSS実装が学術的に検証され、リプレイ/サイドチャネル対策が明示されているか確認します。
設計例：個人〜小規模チームの2‑of‑3/3‑of‑5
個人投資家向け（2‑of‑3）
- 構成：自宅PC、スマホ（物理生体＋PIN）、オフサイト端末（実家の金庫/貸金庫）。
- 通常運用：PC＋スマホで承認（2/3）。
- 障害時：スマホ紛失→PC＋オフサイト端末で復旧。PC損傷→スマホ＋オフサイト。
- セキュリティ強化：各端末はOSのフルディスク暗号化、YubiKey等の2FA、端末紛失時のリモートワイプを有効化。
小規模チーム（3‑of‑5）
- 構成：代表、トレーダーA、トレーダーB、バックオフィス、外部監査役（顧問）。
- 通常運用：トレーダー2名＋バックオフィスで日常送金を承認（3/5）。
- 高額時：金額・先方ホワイトリスト・送金時間帯でポリシールールを設定し、代表/監査役の追加承認が必須に。
- BCP：地域分散（関東/関西/海外）し、自然災害や停電でも3名を確保。
承認ポリシーと日常フロー（EVM系の具体例）
- 送金リクエスト作成：送付先アドレスはホワイトリスト登録（登録は別経路で多要素承認）。
- リスク検査：チェーン上のラベル、過去トランザクション履歴、スキャム判定を自動チェック。
- 上限管理：1日上限（例：100,000 USDT）、1回上限、時間帯ルール（夜間は上限低め）。
- ガス戦術：
maxFeePerGas/maxPriorityFeePerGasの自動最適化。過度なガスは別承認。 - 署名：参加者にプッシュ通知→各端末で生体認証→TSSで部分署名→集約。
- ブロードキャスト：RPCの正当性（エンドポイント改ざん対策）を監視しつつ送信。
- 後監査：誰が何をいつ承認したかを不可改ざんログに保存（WORMストレージ等）。
DeFi連携の落とし穴と実務対策
- 無制限許可（infinite approval）：DEX/コントラクトへの無制限
approveは厳禁。承認額は最小、取引後はrevokeで取り消し。 - フロント実装のフィッシング：正規UI風のドメインで
permitやsetApprovalForAllを誘導される。ドメイン固定のブックマーク運用＋トランザクションシミュレーションで検知。 - メンンプール監視とスナイプ：高額送金はメンンプール観測で狙われやすい。ポリシーで速度優先（適正チップ）と分割送金を組み合わせる。
- ブリッジ利用：資産移動はハイリスク。公式ルーター優先、金額上限、到着チェーンでの受け先もホワイト化。
障害/インシデント時の復旧手順（テンプレ）
- インシデント宣言（Slack/メールで定型フォーマット）。
- ポリシー自動切替：高額送金凍結、夜間承認停止、全承認に監査役必須。
- 端末隔離：紛失/マルウェア疑い端末のネット遮断・失効。
- 再しきい値化（ローテーション）：新メンバーで鍵シェアを再生成、旧シェアは完全破棄。
- 権限棚卸し：DeFiの
approve撤回、APIキー再発行、RPC/ノードの切替。 - 事後レビュー：原因分析→恒久対策（教育・プレイブック更新）。
コスト感と選択肢
MPCは（1）SaaS型を使う、（2）自前構築、の2系統。SaaSは月額/従量課金が発生しますが、監査ログ、ポリシー、端末管理、HSM連携などの運用機能が一括で手に入ります。自前は初期学習と保守コストが重く、暗号実装の取り扱いを誤ると本末転倒です。少額から始め、中長期での手数料・機会損失・事故期待値まで含めてTCOで比較します。
数値で考える期待損失
単一鍵の年間漏えい確率をp、損害額をLとすると期待損失はp×L。MPC 2‑of‑3で各端末の独立侵害確率をqとすれば、攻撃者が同時に2台を落とす確率は概ね3q^2(1−q)+q^3。端末分散とオペレーション統制（場所・OS・人の独立性）が確保されるほどqは小さく抑えられ、期待損失は急減します。
導入ステップ（チェックリスト形式）
- しきい値決定（2/3 or 3/5）。高額用に上位ポリシーも用意。
- 参加者と端末の地理分散、通信手段の冗長化。
- OS暗号化・生体/PIN・セキュリティキー、MDM/ワイプ設定。
- ホワイトリスト運用、送金上限、時間帯ルール、相手先検査。
- ログのWORM保管、アラートのしきい値、定期監査（四半期）。
- DeFi権限の定期
revoke、承認額最小化。 - BCP：災害・停電・通信断・海外出張時の承認確保策。
- 年1回の鍵シェア再生成（人事異動・端末更新を兼ねる）。
失敗パターンと対策
- 「MPCにしたから安全」と過信し、無制限
approveや怪しいサイト署名を許す → UI固定＋シミュレーション＋権限棚卸しを儀式化。 - 承認者が物理的に近接し、同時に盗難・災害に遭う → 地理分散と時間帯分散。
- 復旧手順が属人化 → プレイブック化し演習。
まとめ
MPCは「鍵の単一点障害」を除去し、チーム運用の統制・監査・BCPを同時に引き上げます。トレードの勝ち負けは市場次第でも、カストディ事故は設計で回避可能です。少額から2‑of‑3を導入し、運用に乗せながら3‑of‑5や高額ポリシーへ段階的に拡張してください。
コメント