Monero マルチシグウォレット構築ガイド 2026

2025年4月、長年Moneroコミュニティに貢献してきた開発者が、自身のノートPCが侵害された結果、コミュニティ運営のプロジェクト資金47 XMR（当時のレートでおよそ840万円相当）を失う寸前まで追い込まれた経緯を公表した。プロジェクトの全資金が単一デバイス上の1つのSpend keyの背後に置かれていたことが原因である。救いとなったのは、その前夜に急遽構築した2-of-3マルチシグだった。この事件はMoneroのSubredditや#monero-dev IRCチャンネルで広く議論され、「あれば便利」程度に見られていたマルチシグを、まとまったXMRを保有するすべての人にとっての必須検討事項へと押し上げた。本稿は、マルチシグについて読んだことはあるがラウンドごとのセレモニーを実際に通したことがない読者を念頭に、暗号学的な仕組み、構成上の判断、そして最新の0.18.4.x系における具体的なCLIコマンド列を順を追って解説する。新たに生成したマルチシグアドレスへ追加入金する際にMoneroSwapperがどう役立つかについても触れていく。

なぜMoneroのマルチシグはBitcoinよりも重要なのか

Bitcoinのマルチシグはすでに成熟した技術である。各種ハードウェアウォレットが標準対応し、SparrowやSpecterがPSBTフローを丁寧にガイドし、スクリプト標準もほぼ10年にわたって安定している。一方Moneroのマルチシグは比較的新しく、繊細で、失敗時の復旧難度も高い。だからこそ、正確に手順を踏むことが極めて重要になる。Moneroユーザーが直面する脅威モデルは、一般的なBitcoinホルダーの脅威モデルとも質的に異なる。

• 公開アドレスグラフが存在しない：すべての取引がステルスアドレスを介して行われ、リング署名とRingCTによって難読化されているため、Spend keyを盗まれてもブロックエクスプローラ上で資金の追跡はできない。Bitcoinなら依頼できるチェーン分析企業も、Moneroには存在しない。一度資金が流出すれば、回収はほぼ不可能である。マルチシグは、単一鍵の侵害が「全損」に直結することを防ぐ数少ない仕組みのひとつだ。
• ニーモニックシードの漏洩は致命的：25語のニーモニックシードが漏洩すると、View keyとSpend keyの双方がそこから導出されるため、ウォレット履歴がさかのぼって完全に復元できてしまう。マルチシグでルートを複数の署名者へ分割すれば、単一の漏洩が即座に致命傷となることはない。
• 相続・チーム資金の管理：寄付資金、プロジェクトのエスクロー、家族間の相続計画など、いずれも単一署名者の不在が資金凍結を意味しないM-of-N方式を必要とする。単一署名のウォレットではこの要件をそもそも表現できない。
• カストディアン依存のリスク：中央集権型取引所によるMonero上場廃止の波は止まっていない。Krakenは2024年末にEU顧客向けのXMR取扱を停止し、Binanceはその1年前にすでに同様の対応を取った。日本国内の取引所ではMonero自体が長年取り扱われていない。取引所預けは長期保有戦略にはなり得ず、堅実なセルフカストディの整備が不可欠となる。

EUのMiCA規制や、2025年に更新されたFinCENガイダンスに代表されるプライバシーコインへの規制圧力、さらには国税庁の暗号資産税制が雑所得扱いを継続している国内事情を踏まえれば、洗練された自己管理体制の重要性は明らかである。失えば回復不能なほどのXMRを保有しているのであれば、マルチシグは「やった方がよい」ではなく「やるべき」選択肢になる。

Moneroマルチシグの内部動作

Bitcoinのマルチシグしか触ったことがない読者にとって、Moneroの方式は奇妙に映るかもしれない。MoneroにはOP_CHECKMULTISIGのようなスクリプトオペコードは存在しない。代わりに、CLSAG署名スキームを基盤とした多ラウンドの対話型鍵交換プロトコルが用いられる。参加者は単に公開鍵を結合するのではなく、複数ラウンドのprepare_multisig、make_multisig、そして（Nが3以上のとき）exchange_multisig_keysを通じて、共有View keyと共有Spend keyを協調的に構築していく。

ラウンド構造

2-of-2の基本構成では、セレモニーは比較的短い。各参加者がprepare_multisigを実行し、得られたMultisigxV2文字列を相手に渡し、相手の文字列を引数にmake_multisigを実行すれば、ウォレットは利用可能になる。Nが3以上のM-of-N構成では、これに加えてexchange_multisig_keysをN − M + 1回繰り返す必要がある。2-of-3ウォレットなら2ラウンド、3-of-5ウォレットなら3ラウンドである。各ラウンドの出力文字列は、次のラウンドへ進む前に他の参加者と共有しなければならない。

取引署名のフロー

ウォレットの構築が終わった後の署名フローもまた対話型である。発起者が通常どおりtransferコマンドを実行すると、未署名トランザクションファイルが生成される。このファイルをエクスポートし、共同署名者へ帯域外チャネル（暗号化メール、USBメモリ、Signalなど。決して通常のmempool経由ではない）で受け渡し、相手側でインポートする。共同署名者はsign_multisigを実行して署名済みファイルを生成し、閾値に達していればそのまま送信、未達なら次の署名者へ回す。さらに各取引の後には、すべての署名者がexport_multisig_infoとimport_multisig_infoを介して新しいアウトプット情報を共有する必要がある。フローは意図的に冗長な構成になっている。

FCMP++とSeraphisで何が変わるか

近く予定されているFCMP++のアップグレード、そしてより長期的なSeraphis／Jamtisアドレス体系の刷新は、いずれもマルチシグに影響を及ぼす。朗報は、マルチシグ鍵交換の意味論そのものは互換性が保たれることだ。新しいリング構成や新アドレスフォーマットによってM-of-N鍵の集約方法が変わるわけではない。悪い知らせは、ネットワークがフォークして新アドレス方式に移行した時点で、既存のマルチシグウォレットは単一署名ウォレットと同様、再初期化が必要になるという点である。2026年にマルチシグを構築するのであれば、フォーク後に新たなセレモニーを実施する前提で運用設計しておくのが賢明だ。

マルチシグ構成の比較

M-of-Nの選定は暗号学ではなく運用リスクの問題である。ターミナルを開く前に、次の表に目を通して自分のユースケースに最も合う構成を選んでほしい。

個人ユーザーの大多数は2-of-3を運用すべきである。現実に発生しやすい失敗パターン――バックアップ紛失、ノートPCの盗難、パスフレーズ失念――に過不足なく対応しつつ、署名セレモニーを実務的に回せる範囲に収められる。本稿の残りは2-of-3を題材に進めるが、同じコマンドはラウンド数を調整すれば任意のM-of-Nで機能する。

ステップバイステップ：2-of-3マルチシグウォレットの構築

必要となるのは3台のマシン、もしくは独立した3つのウォレットインスタンスである。地理的分離は実質的な意味を持たなければならない。台所のノートPCと書斎のノートPCを「3か所」と数えてはならない。少なくとも1台はオフライン環境、できればエアギャップされたTails USB、可能であればハードウェア署名器も1台組み込むのが理想だ。以下の手順は、3台すべてでmonero-wallet-cliのv0.18.4.0以降が動作している前提である。

1. 3つの新規標準ウォレットを作成する。各マシンでmonero-wallet-cli --generate-new-wallet=signer1.keysを実行する（ファイル名は署名者ごとに変える）。十分に強いパスフレーズを設定すること。各ウォレットの25語ニーモニックシードはオフラインで紙ないしメタルプレートに書き写しておく。これらはマルチシグのバックアップそのものではないが、署名者を再構築する場合に必要となる。
2. 各ウォレットを準備する。各ウォレットを開いてprepare_multisigを実行する。ウォレットはMultisigxV2で始まる長いbase58文字列を出力する。3つのウォレットそれぞれからこの文字列をコピーし、計3つの準備文字列を得る。
3. 第1交換ラウンド。各署名者でmake_multisig 2 <署名者Aの文字列> <署名者Bの文字列>を実行する。引数に渡すのは自分以外の2名の文字列である。実行後、各署名者は第2ラウンド用の文字列を出力する。これらを互いに共有する。
4. 第2交換ラウンド。各署名者でexchange_multisig_keys <ラウンド2-A> <ラウンド2-B>を実行する。引数は他の2名のラウンド2文字列である。ウォレットが「Multisig wallet has been successfully created」と表示し、共有アドレスを提示する。3つの署名者すべてが完全に同一のプライマリアドレスを表示することを確認する。1文字でも異なればセレモニーは失敗しており、最初からやり直す必要がある。
5. マルチシグウォレットファイルをバックアップする。各マシン上の.keysファイルが、その署名者の持分を表す。暗号化されたオフラインストレージへ退避する。極めて重要な点として、2-of-3マルチシグウォレットはニーモニックシードだけからは復元できない。3つの署名者のうち少なくとも2つの.keysファイルが必要である。これがマルチシグ運用における全損原因の筆頭である。
6. テスト送金を行う。共有アドレスに少額――0.05 XMRもあれば十分――を送金し、約20確認後に3つの署名者すべてが残高を認識することを確認する。この手順を省略してはならない。テスト送金の失敗は、少額のうちに構成ミスを露呈してくれる。
7. 送金の練習を行う。1つの署名者からtransfer <送付先> 0.01を実行する。~/Monero/multisig_monero_txに未署名トランザクションファイルが生成される。これをUSBメモリや暗号化添付で第2の署名者へ運ぶ。第2署名者側でsign_multisig multisig_monero_txを実行する。生成された署名済みファイルを任意の署名者からsubmit_multisigで送信する。チェーンに乗ったことを確認する。
8. 復旧計画を文書化する。各署名者の.keysファイルの保管場所、各パスフレーズの保持者、送金に必要なコマンド列を1ページにまとめる。少なくとも2名の信頼できる第三者（弁護士、家族、共同経営者）にこの文書を預ける。文書にはパスフレーズそのものを書き込まず、保管場所と手順のみを記載する。

一度も送金したことのないマルチシグウォレットは、所有しているとは言えない。本番資金を投入する前に、最低1回は完全な往復テスト取引を必ず実施すること。

実例：地理的分離を伴う相続向け構成

2025年を通じて/r/Moneroで実際に共有されてきた、典型的な2-of-3相続セットアップを紹介する。主たる保有者は東京在住である。署名者1はWhonixを走らせる普段使いのノートPC上に置き、署名者2は実家の金庫内に常時機内モードのまま保管された古いThinkPad、署名者3は大阪の弁護士事務所に預けた暗号化USBドライブで、保有者の死亡もしくは行為不能が証明された場合にのみ封を開ける封緘指示書とともに保管される。

日常的な送金は署名者1と署名者2を組み合わせて行う。保有者は数か月ごとに実家へ帰省し、まとめておいた送金処理に共同署名する。署名者1が侵害された場合――ノートPCが盗難に遭った、ランサムウェアに感染した、強要によってパスワードを開示してしまった――としても、攻撃者は実家金庫または大阪の弁護士のどちらかに到達しない限り資金を動かせない。万が一保有者が亡くなった場合は、大阪の弁護士が1鍵、実家の家族が1鍵を保持しているため、保有者のパスワードを探し出すことなく資金回収が可能である。マルチシグのView keyは読み取り専用で弁護士に共有しているので、残高確認はできるが送金はできない。

この保有者がマルチシグへ追加入金する場面――たとえばフリーランス報酬が単一署名ウォレットに着金した後――では、MoneroSwapperを用いて受け取ったアルトコインをそのままマルチシグアドレスへ変換する。KYCなし、アカウント登録なし、スワップ完了以降のログ保持なし。送金先は共有マルチシグプライマリアドレスから派生させた新規Subaddressとし、受信側のプライバシーを保ちつつ同一の共有資金プールへ流入させる。アトミックスワップやアカウント不要型取引所からマルチシグへ資金注入する手法は、入金から保管までのリンク不能性を維持できる最もクリーンな方法のひとつである。

運用フェーズで失敗しやすい7つのポイント

セレモニーそのものよりも、構築後の運用フェーズで起きる事故のほうが圧倒的に多い。以下のチェックリストは、コミュニティで繰り返し報告されてきた失敗パターンを抽出したものである。新規構築の直後に印刷し、定期的に見直すことを推奨する。

1. 同期不全の放置：誰か1人がexport_multisig_infoを怠ると、その署名者の残高は古いまま固定される。送金時のエラー発生まで気付かないことが多い。月1回の同期チェックをカレンダーに登録する。
2. パスフレーズと.keysファイルを同じ保管場所に置く：金庫の中に両方を入れていた事例では、金庫の鍵を握る人物が事実上の単独署名者となってしまった。物理的・組織的に分離させる。
3. クラウド同期フォルダへの.keysファイル配置：Dropbox、iCloud Drive、Google Driveの暗号化済みコンテナに置いていても、クライアントサイドの鍵が漏洩すれば一括取得される。.keysファイルはローカルディスク＋オフラインバックアップに留める。
4. monero-wallet-cliのバージョン不一致：署名者間でマイナーバージョンがずれているとき、まれにシリアライズの互換性問題が生じる。全署名者で同一の正式リリースを使う。
5. ネット越しのmonero-wallet-rpc暴露：署名フローを自動化したいがためにRPCを0.0.0.0にバインドし、認証も最小限のまま放置するケースがある。RPCはローカルホスト限定もしくはTorのonionサービス経由に限定する。
6. ノードへの過信：軽量ウォレットが信頼するリモートノードはトランザクション発行のタイミング情報を観測できる。フルノードを自前で動かすか、せめてTor越しに公開ノードへ接続する。
7. 定期的なドリル実施の欠如：半年に一度、すべての署名者を順に呼び出して微少額の送金訓練を行う。鍵の存在確認と、参加者の手順習熟を同時に達成できる。

日本のユーザーに固有の論点

日本国内でMoneroを保有する場合、国税庁が暗号資産取引による利益を原則として雑所得に区分している点を念頭に置く必要がある。マルチシグへの単純な移送そのものは課税イベントではないが、アトミックスワップやMoneroSwapperを介した他コインからの変換は、変換時点の時価で取得・譲渡が成立すると解釈されうる。年明けに慌てないよう、共有マルチシグアドレスに着金した取引については日付・送付元・概算時価をスプレッドシートで記録する習慣を持っておくとよい。会計ソフトと連携させる場合でも、Moneroのアドレスは公開アドレスグラフが存在しない都合上、自動連携は基本的にできない。手作業の記録が現実解となる。

もう一つ意識しておきたいのが、地震や台風など自然災害に伴う物理的な紛失リスクである。地理的に分離する3拠点を選定する際、同一の活断層帯や同一の流域に集中させていないかを確認する。例えば東京・横浜・千葉に集約してしまうと、首都直下地震の想定被害域にすべて入る可能性がある。札幌・名古屋・福岡のように、別々の地理ハザード圏に分散させた方が、相続用途であれ個人用途であれ堅牢性が増す。海外居住の親族にエアギャップ署名者を1つ預ける選択肢も検討に値する。

よくある質問

Moneroマルチシグウォレットを25語ニーモニックシードから復元できるか

不可能である。各署名者ウォレットを初めて作成したときに表示される25語シードは、その署名者のマルチシグ参加前の状態のみを復元する。実際のマルチシグ鍵は交換ラウンド完了後に生成される.keysファイルに格納される。N人の署名者のうち少なくともM人分の.keysファイルをバックアップしなければならない。シードしかなく.keysファイルがない場合、ウォレットは復元不能である。

セレモニーは実際にどれくらい時間がかかるか

2-of-3で、全参加者がビデオ通話に同席している場合で20〜40分が目安である。1人で3つの署名者をすべて管理し、USBメモリでデータを移送する形態だとさらに長くかかり、検証とテスト送金まで含めて1時間前後を見ておくとよい。初回はもう少し余裕を持って臨み、2回目以降は各ラウンドの出力が何を意味するか理解できているため大幅に早く終わる。

TrezorやLedgerのようなハードウェアウォレットはMoneroマルチシグに対応しているか

2026年初頭の時点で、Moneroマルチシグに対するハードウェアウォレットのサポートは依然として限定的である。LedgerとTrezorはMoneroの標準的な単一署名ウォレットには対応しているが、マルチシグセレモニーへの統合は現状どちらもクリーンではない。コミュニティはこの領域に積極的に取り組んでおり、公式Monero GUIリポジトリではstagenetでのマルチシグフロー検証に関する議論が継続している。現時点で最も信頼できるアプローチは、ハードウェアバックドマルチシグを期待するのではなく、各署名者マシンで強力なフルディスク暗号化を有効にしたうえでmonero-wallet-cliを使うことである。

署名者の同期が外れた場合はどうなるか

これは最も頻繁に発生する運用上の問題である。各取引の後、すべての署名者はexport_multisig_infoを実行し、生成されたファイルを他署名者へ共有する。受け取った側はimport_multisig_infoを実行する。誰かがこの手順を省略すると、その署名者の残高表示が古くなり、送信時に失敗するトランザクションを組み立ててしまう。修復は同期済みの署名者からエクスポート／インポートサイクルを再実行するだけで済む。--log-level 1でウォレットのログを確認すれば、同期ずれは可視化される。

Subaddressと併用できるか

可能である。マルチシグウォレットが確定した後は、単一署名ウォレットと同様にaddress newでSubaddressアカウント・インデックスを生成できる。各Subaddressは共有マルチシグプライマリアドレスから派生するステルスアドレスであるため、いずれのSubaddressで受け取った資金も同一のM-of-N閾値で送金できる。寄付者ごと、請求書ごとに新しい受信アドレスを発行したい資金管理用途には実用的である。

1 XMR未満の保有額でマルチシグは過剰か

その1 XMRが自分にとって何を意味するかによる。遊び金の範囲なら、メタルバックのシードを備えた単一署名で十分である。失えば打撃になる「もしもの蓄え」であるなら、2-of-3マルチシグへの数時間の初期投資は、初めてバックアップを紛失したり、ノートPCを盗まれたりしたときに十分に元が取れる。判断基準は金額ではなく「失ったらどれだけ痛いか」である。

署名者の1人を後から差し替えることはできるか

厳密な意味での「差し替え」はできない。Moneroのマルチシグウォレットは構築時に固定される。署名者を入れ替えたい場合は、残りの閾値メンバーで新しいマルチシグウォレットを構築し、旧ウォレットから新ウォレットへ全資金を移送する形をとる。DAO運用のようにローテーションが頻繁に発生する組織では、移送手数料と税務上のイベント発生を見越して、ローテーション頻度の上限をあらかじめ決めておくのが現実的である。

RingCT配下でマルチシグの匿名性はどう保たれているか

署名生成プロセスが対話的になっても、ネットワークに対して放出されるトランザクション形態は通常のRingCT＋CLSAG構造と区別がつかない。観察者の視点では、マルチシグから送金された取引と単一署名から送金された取引は同一のリングサイズ・同一の出力構造を持ち、識別する手立てはない。これがBitcoinのOP_CHECKMULTISIGスクリプトと決定的に異なる点であり、Moneroが構造的にプライバシーを確保する根拠でもある。

テストネットで先に練習することはできるか

強く推奨される。monero-wallet-cli --stagenetもしくは--testnetでまったく同じセレモニーを通せる。stagenet faucetから少量のテストXMRを取得すれば、本番資金を一切リスクに晒さずに2ラウンド交換、署名フロー、エクスポート／インポート同期まで完走できる。初回構築前にstagenetで一度通しておくと、本番時の認知負荷が大幅に減る。共同署名者を巻き込んだ通しリハーサルを最低1回行ってから本番移行する運用が望ましい。

結論

Moneroマルチシグは、保有者が実施できるプライバシー・セキュリティ強化の中で最もレバレッジの高い施策のひとつであり、セレモニー自体もCLIに数時間触れた経験がある人なら十分に手の届く範囲にある。ほぼ全員が標準として採用すべき構成は、真に独立した3か所に分散させた2-of-3、文書化された復旧計画、そして本番資金投入前の最低1回のテスト送金である。新たに生成したマルチシグアドレスへ入金する段になったら、MoneroSwapperが入金側の作業を簡素化してくれる。アカウントなしで任意のアセットをXMRへ変換し、マルチシグのプライマリアドレスもしくは新規Subaddressへ直接送金できる。スワップから保管に至るまで、プライバシー特性は途切れない。今週末にセットアップを完了し、来週から枕を高くして眠ろう。本記事に掲載した各コマンド列はそのままMonero stagenet環境でもmainnet環境でも問題なく動作する。最初の構築では必ずstagenetで一度通し、テスト送金が成功してから本番マシンで再度セレモニーを実施することを強く推奨する。