暗号資産の運用で「収益機会」より先に最適化すべきは鍵管理です。MPC（Multi‑Party Computation）ウォレットは、秘密鍵を単一の場所に置かず、複数の端末・当事者でしきい値署名（Threshold Signature Scheme, TSS）を行う方式です。単独鍵や紙フレーズの脆弱性を現実的なコストで減らしつつ、取引スピードと可用性を両立できます。本稿は投資家が自力で回せる実務プレイブックに特化して解説します。
MPCウォレットの要点
MPCは「完全な秘密鍵」をどこにも作らず、各参加者が鍵断片（シェア）を保持し、m-of-nのしきい値を満たしたときだけ署名が成立します。代表的な性質は次のとおりです。
- 単一点障害の排除：一つの端末や保管場所の侵害では資産を奪取できません。
- チェーン非依存：多くの実装はチェーン上でのマルチシグ記録を不要とし、手数料や可視性への影響が限定的です。
- ポリシー内蔵：送金先ホワイトリスト、金額・時間帯・承認者ロールなどを運用ポリシーとして組み込めます。
マルチシグとの違い（投資家視点）
可視性と手数料
マルチシグはチェーンに「複数署名の形跡」が残る設計が多く、対応チェーンや手数料が影響します。MPCはオフチェーン協調で単一署名に見えるため、手数料は通常の送金と同等で、アドレス形状も一般アドレスと同じです。
互換性と拡張性
マルチシグはチェーンごとに仕様が異なり、DeFi連携で制約が出やすい一方、MPCはアプリケーション側の実装で多数チェーンを横断しやすい傾向があります。
復旧とローテーション
マルチシグの鍵ローテーションはオンチェーン変更を伴いがちですが、MPCはシェア再生成（DKG再実行）で構成変更が柔軟です。
脅威モデルと現実解
個人投資家が直面する主要リスクを、MPCでどう抑えるかを明文化します。
- 端末侵害（マルウェア・盗難）：1台喪失では資産移動不可。署名端末をOS別に分散し、画面内キーロガー対策として承認時に送金先と金額の目視確認を必須化します。
- フィッシング・ドレイナー：コントラクト承認（Permit/Approve）の上限無制限が致命傷になりがち。ポリシーで新規コントラクトとの初回接続を要審査、かつ承認上限を金額・期間で制限します。
- インサイダー/共謀：しきい値を超えた結託を抑止するため、役割分離（発注・承認・最終送信）と、オフライン保管シェアを必須ロールに指定します。
- バックアップ喪失：紙フレーズに相当する単独復旧手段は作らず、地理分散したシェアで冗長化します。
推奨アーキテクチャ（個人〜小規模運用）
再現性の高い2パターンを提示します。いずれも3-of-5を基本に、即時性と冗長性のバランスを取ります。
パターンA：取引用ホット＋管財用セミコールド
- シェア構成：自分のスマホ、自分のPC、オフライン用ラップトップ、家族/信頼者、紙ではなく暗号化USB。
- 承認ポリシー：日中（09:00–23:00）・1回50万円/日100万円までスマホ＋PCの2シェアで即時可。超過金額や深夜帯は3シェア（オフライン端末必須）。
- 用途：CEX入出金、少額DeFi、NFT決済。
パターンB：長期保管ボールト
- シェア構成：自分PC、家族、税理士・弁護士等の職業受託者、オフサイト金庫、予備端末。
- 承認ポリシー：タイムロック48時間＋3シェア必須。ホワイトリスト口座にのみ送金可。
- 用途：長期BTC/ETH、LPトークン保管、DAOトレジャリーの個人持分管理。
トレード運用：スピードと安全性の両立
DEXでは承認の回数が多く、CEXでは入出金のタイミングが収益を左右します。MPCポリシーを次のように調整します。
- 金額リミットの二層化：少額は自動承認、中額は二者承認、大口は三者＋タイムロック。
- 宛先ホワイトリスト：自分名義のCEX入金アドレス、ブリッジの公式コントラクト、頻用のDeFiゲートのみ許可。
- 時間帯制限：流動性が薄くスリッページが増える深夜帯は自動承認を停止。
- チェーン別ガバナンス：EVM系は高速承認、UTXO系はUTXO集約を月次実行して手数料を最適化。
具体シナリオ：数値入りテンプレート
例）現物と先物のベーシストレードを常時回す投資家の設定。
- 日次自動枠：100万円（CEX間の証拠金リバランス）。
- 時間帯：08:00–24:00のみ自動。その他は二者承認。
- DEX新規コントラクトは常に三者承認＋5万円上限＋7日失効。
- アドレス管理：CEX 4口座、ブリッジ2本、自己保管ボールト1口座のみホワイトリスト。
この設計で、日常の回転は摩擦を減らしつつ、想定外の大口流出を構造的にブロックできます。
事故対応プレイ
- 端末紛失：そのシェアを速やかに失効し、DKGで再発行。しきい値未満なら資産は動かないため落ち着いて対処。
- フィッシング承認：承認権限を即時停止、ApproveをRevoke、ホワイトリストと自動承認枠を一時ゼロ化。
- 共謀疑い：監査ログから署名参加者を特定、役割の一時停止、しきい値比率の見直し。
パフォーマンスとコスト
署名はオフチェーンで合意形成後、チェーンには通常の単一署名として流します。送金手数料は通常と同等、追加コストは運用基盤や端末の整備に限られます。DEX実行時のレイテンシは実装依存ですが、ローカル2シェア構成で数百ms〜数秒程度が目安です。
対応チェーンとDeFiの注意
主要EVM、UTXO（BTC系）、一部非EVMチェーンに対応する実装が一般的です。DeFiではPermit/Permit2、Permit for ERC‑20/721/1155など承認仕様が複数あるため、ポリシーで初回承認を必ず人間がレビューする運用を入れてください。
単独鍵からの移行手順
- 新規にMPCボールトを作成（3-of-5）。
- 既存ウォレットから少額テスト送金で受領・送金を往復確認。
- UTXO資産は手数料の安い時間帯に集約してから移管。
- DeFiポジションは閉じてから移管、または許可を安全に移譲。
- 旧ウォレットのシード・JSONは安全に破棄し、誤送金防止のためアドレス帳から削除。
落とし穴と対策
- 承認上限が大きすぎる：初期は1回50万円／日100万円程度で運用し、必要に応じて増やします。
- ホワイトリスト放置：四半期ごとに棚卸しし、使わない宛先は削除。
- バックアップの集中配置：地理分散＋保管者分散が原則。
- Approveの無制限：金額・期間上限をルール化、Revokeを月次ルーチンに。
今日から動ける10ステップ
- 主要資産・用途別に「ホット」「セミコールド」「ボールト」を区分。
- 3-of-5のシェア配布計画を紙に書く（端末・人・場所）。
- 自動承認枠と時間帯を数値で決める。
- 宛先ホワイトリストの初期セットを作る。
- Revoke手順をブックマークし、月次で実施。
- 紛失時の連絡先と再発行手順を1枚にまとめる。
- DEX用の承認上限テンプレを2種類（小口/中口）用意。
- UTXO集約の月次実行日をカレンダー化。
- ログの保存先を決め、承認者ごとに可視化する。
- 半年ごとにポリシーとしきい値を見直す。
まとめ
MPCウォレットは「速さ」と「安全性」を両立させる現実解です。鍵を分散し、承認を設計し、運用ログを残す——この3点を押さえれば、裁量トレードでもシステマティック運用でも、資産保全の土台を強化できます。
コメント