Monero のビューキーとスペンドキー:違いを徹底解説
Monero のビューキーとスペンドキー:違いを徹底解説
確定申告で税理士に Monero の入金履歴を見せたいけれど、財布まるごと預けるのは絶対にイヤだ——そう感じた瞬間に、あなたはすでにこの二つの鍵が解こうとしている問題に出会っています。Bitcoin であれば一本の秘密鍵が残高表示から送金までを一手に握りますが、Monero は意図的に権限を「閲覧用」と「支払い用」に分割しています。この分離があるからこそ、プライバシーコインでありながら必要なときだけ監査に開けたり、公開残高つきの寄付ページを運用したり、本体資金には一切触れない軽量モバイルウォレットを動かしたりできるのです。それなのに、初心者の多くは二つを混同し、入力欄を取り違え、「片方を渡すと全部漏れるのでは」と誤解したまま運用を始めてしまいます。2026 年の今、FCMP++ がテストネットのロードマップに乗り、MoneroSwapper のような取引所が一日に何千件もの no-KYC スワップを処理する時代において、鍵の分離を理解することはもはや学術的な話題ではありません。きれいな監査証跡を残せるか、ウォレットを空にされるか——その分かれ目です。本稿では、それぞれの鍵が何をするか、何ができないか、そして Monero の暗号プリミティブがどのようにしてこの組み合わせを Bitcoin の単一鍵モデルでは再現不能なものへと変えているのかを、順を追って解き明かしていきます。
なぜ Monero は秘密鍵を二本に分けるのか
Monero のアカウントモデルは、2013 年にリング署名と一回限りのステルスアドレスを暗号通貨に持ち込んだプロトコル「CryptoNote」の系譜にあります。これらのプリミティブを成立させるために、ウォレットは性質の異なる二つの仕事をこなさなければなりません。一つはブロックチェーン全体を走査して自分宛の出力を識別すること、もう一つはその出力の支払いを承認すること。CryptoNote の設計者は、この「走査役」と「支払い役」を、32 バイトの種から導かれるけれど公開鍵上では暗号学的に無関係な二つのスカラー値に分けられることに気づきました。
その結果として生まれたウォレット ID は、秘密スペンドキー・秘密ビューキー、そしてそれぞれに対応する公開鍵——合計四つの数値を連結し、Base58 でエンコードして得られる、おなじみの 95 文字の Monero アドレスです。分割によって得られる実用的なメリットは大きく三つあります。
- 選択的な透明性:ビューキーを国税庁の調査官、取引所のコンプライアンス担当、寄付団体の監査人に渡せば、彼らは入金を検証できる一方で、コインを動かす力はまったく持てません。
- 軽量クライアント:モバイルウォレットや watch-only のデスクトップノードは、残高表示にビューキーがあれば十分です。だからこそスペンドキーをエアギャップ機にコールドストレージしたまま、日常利用するという運用が現実的になります。
- 多層防御:ビューキーが漏れても流出するのは取引履歴であって資金ではありません。盗難端末からの復旧は「金融事故」ではなく「プライバシー事故」として処理できるのです。
こうした仕組みは、信頼された第三者やゼロ知識のアドオンなしには Bitcoin の UTXO モデルでは実現できません。Monero はこれをプロトコル本体に焼き込んでいるため、公式 CLI から MoneroSwapper のホスト型スワップエンジンまで、あらゆる Monero ウォレットが二つの鍵を「独立にエクスポート・インポート・監査できる第一級のオブジェクト」として扱っています。
秘密ビューキーを深掘りする
秘密ビューキーは 32 バイトのスカラー値で、monero-wallet-cli や Feather Wallet では 64 桁の十六進文字列として表示されます。その唯一の暗号学的役割は、ウォレットが「自分のもの」になりうる全トランザクションについて、送信者と受信者の間の共有秘密を計算することです。誰かがあなたに XMR を送ると、送信者はあなたの公開スペンドキー、公開ビューキー、そして取引ごとに生成されるランダムな鍵を使って、一回限りのステルスアドレスを構築します。出来上がった出力はネットワーク上の誰の目にもただのノイズに映りますが、あなただけは秘密ビューキーで同じ共有秘密を再構築でき、「これは自分宛だ」と認識できるわけです。
ビューキーにできること
公開アドレスと秘密ビューキーがあれば、ソフトウェアはチェーンを走査して出力ごとに三つの情報を復号できます——受信者のステルスアドレス(その出力が自分のものであることの証明)、金額(RingCT のコミットメントから復号)、そして添付されている場合は payment ID です。これだけあれば完全な入金履歴を組み立てられます。事業者はこれで売上を把握し、寄付サイトはビューキーを公開して合計金額をリアルタイムに誰でも検証できるようにし、税務ソフトは支払い権限を一切求めずに取得原価レポートを生成します。
ビューキーにできないこと
ビューキーは取引に署名できません。キーイメージを生成できないので、ある出力が使用済みかどうかを証明することもできません。watch-only ウォレットでは、ユーザーがオフラインの支払いウォレットから署名済みのキーイメージファイルをインポートするまで、出金は不可視のままで、インポートして初めて残高が一致します。これこそが鍵分離が最も鮮やかに機能している例です——ビューキーは入ってくる金は見えるけれど、出ていった瞬間に見失います。ただし支払い側がキーイメージを共有してくれれば話は別です。
ビューキー周りでよくある失敗
最頻出のミスは、ビューキーを「ニーモニックシードを期待しているリストアウォレットの入力欄」に貼り付けてしまうことです。ウォレットはそれを受け入れ、まったく違うエントロピーからまったく違うスペンドキーを導出し、見た目はきれいだけれど一円も見えない無意味なウォレットを返してきます。もう一つの落とし穴は、ビューキーを公開ページに掲載してしまうこと。これは過去・未来の入金すべてを実名と永続的に結び付けることを意味します。ビューキーはローテーションできません——一度漏れたら永久に漏れたままです。銀行明細にアクセスできる読み取り専用 API トークンと同じ感覚で扱ってください。監査人にとっては便利、ストーカーにとっては致命的です。
秘密スペンドキーを深掘りする
秘密スペンドキーはもう一方の 32 バイトのスカラー値で、実際にコインを動かす権限を握っているのはこちらです。この一つの数値からウォレットは、自分が所有する出力ごとのキーイメージを導出し、すべての CLSAG リング署名に署名し、金額が負でないことを伏せたまま証明する Bulletproofs+ のレンジプルーフを生成します。スペンドキーを失えば、お金も失います。復旧はありません。サポート窓口もありません。チェーンの巻き戻しもありません。
スペンドキーがキーイメージを生み出す仕組み
ウォレットが受信する各出力に対して、Monero はキーイメージ——その出力の一回限りの公開鍵とウォレットの秘密スペンドキーの両方に依存する決定論的なハッシュ——を計算します。キーイメージは出力ごとに一意ですが、スペンドキーなしでは偽造不能であるため、Monero の二重支払い防止機構として機能します。トランザクションがブロードキャストされると、バリデータは「そのトランザクションに含まれるキーイメージのどれも過去にチェーン上に現れていない」ことを確認します。巧妙なのは、リング署名が真の署名者をおとり集合の中に隠してくれるおかげで、同じキーイメージを「それを生成したウォレット」と結び付けることはできない点です。
スペンドキーとニーモニックシード
ほとんどのユーザーは生の 64 桁十六進スペンドキーを目にしません。代わりに目にするのは、スペンドキー本体・チェックサム・誕生日(birthday)をエンコードした 25 語のニーモニックシード(新しいウォレットでは 16 語の Polyseed)です。ビューキーはそのスペンドキーから決定論的に導出されます——Keccak-256 でハッシュし、Ed25519 群位数で剰余を取るだけ。この導出があるおかげで、スペンドキー(あるいはシード)をバックアップしておけばウォレット全体を復元できます。ビューキーは自動的についてくる、というわけです。
スペンドキーを絶対に渡してはいけない理由
スペンドキーを渡すことは、機能的には「残高ぜんぶ」と「取引履歴ぜんぶ」を同時に他人に送りつけるのと同じです。「ウォレット認証キー」や「フルリストアキー」を求めてくるフィッシングサイトは、ほぼ間違いなくスペンドキーかシードを狙っています。まともな取引所・スワップサービス・監査会社がそれを必要とすることは絶対にありません。たとえば MoneroSwapper はスワップごとに新しい integrated address を発行し、顧客のスペンドキーには一切触れません。入金トランザクションへの署名とブロードキャストは、顧客が自分のウォレットから自分でおこないます。
ビューキー vs スペンドキー:横並びで比較
以下の表に実務上の違いをまとめました。どちらかの値を入力欄や画面、QR スキャナーに貼る前のチェックリストとして使ってください。
| 機能 | 秘密ビューキー | 秘密スペンドキー |
|---|---|---|
| 入金トランザクションの閲覧 | 可能 | 可能(導出されるビューキー経由) |
| 出金トランザクションの閲覧 | キーイメージをインポートした場合のみ | 可能 |
| 金額の復号 | 可能 | 可能 |
| トランザクションへの署名・ブロードキャスト | 不可 | 可能 |
| キーイメージの生成 | 不可 | 可能 |
| もう一方の鍵の導出 | 不可 | 可能(ビューキーはスペンドキーから導出) |
| 監査人への共有 | 安全に共有可 | 絶対不可 |
| 漏洩時のリスク | プライバシー喪失、資金損失なし | 資金の全損 |
| ニーモニックシードに格納 | 導出のみ、未格納 | 格納される |
| ローテーション | 不可 | 不可(新ウォレットへ資金移動が必須) |
「もう一方の鍵を導出できるか」の行に非対称性があることに注目してください。スペンドキーからビューキーは導けますが、その逆はできません。この一方通行の関係こそが、スペンドキーなら破滅的な場面でもビューキーは安全に公開できる理由です。
watch-only ウォレットの作り方:手順
これらの鍵を意識する最大のきっかけは、watch-only ウォレットを組みたいときでしょう。たとえばエアギャップ機に置いたコールドストレージの残高を、普段使いのスマホからモニタするケースです。ここでは公式の monero-wallet-cli を使った手順を紹介しますが、Feather Wallet、Cake Wallet、MyMonero でも GUI 版で同じことができます。
- オフライン端末で本体ウォレットを開き、プロンプトで
viewkeyと入力。64 桁の十六進文字列をコピーします。addressと入力して 95 文字のプライマリアドレスもコピー。スペンドキー・シード・その他の値はエクスポートしないこと。 - QR コードかエアギャップ用 USB で二つの文字列をオンライン端末へ運びます。スペンドキーやシードをオンライン機で入力するのは絶対に避けてください。
- オンライン機で
monero-wallet-cli --generate-from-view-key <name>を実行。プロンプトに従ってアドレスと秘密ビューキーを貼り付け、強固なウォレットパスワードを設定します。 - 資金を最初に受信したブロック高からチェーンを同期させます。入金は正しい金額で表示されますが、出金はキーイメージをインポートするまで "(unknown sent)" と表示されます。
- 出金残高を一致させるには、オフラインウォレットで定期的に
export_key_imagesを実行し、オンラインウォレットでimport_key_imagesをかけます。これは支払い権限を共有するものではなく、「特定の出力が既に使われた」という事実を共有するだけです。
ビューキーは「何が入ってきたか」に答え、スペンドキーは「何が出ていけるか」に答えます。もし二つ目の問いに答えるよう求めるサービスがあれば、その場で立ち去ってください——まっとうな業務フローでそれを必要とするものは一つもありません。
各キーの実例シナリオ
具体例を挙げると、違いが体に染みます。XMR で寄付を受け付けている小規模な OSS プロジェクトを考えてみましょう。メンテナはプライマリアドレスと秘密ビューキーを「透明性ページ」に掲載します。誰でもローカルで watch-only ウォレットを立て、チェーンを同期させ、四半期にどれだけの寄付が集まったかを独立に検証できます。一方でスペンドキーはハードウェアデバイス上で厳重に保管されているため、寄付者であれ将来プロジェクトを去るメンテナであれ、資金を動かすことはできません。これは典型的な「寄付の透明性パターン」で、Monero Community Crowdfunding System が長年運用してきた通りの仕組みです。
別のシナリオも考えてみましょう。日本に在住するフリーランスのジャーナリストが、年間の XMR 収入が暗号資産の雑所得 20 万円ライン(給与所得者の場合の確定申告要否の目安)に対してどの水準にあるかを税理士に示したいとします。彼女は税理士の事務所の監査用ノート PC 上に、自分のアドレスと秘密ビューキーから watch-only ウォレットを生成し、現在のブロックまで同期させ、復号済みの入金額を CSV にエクスポートします。税理士には総額が見える。彼女は支払い権限を一切手放さない。仮に契約が終わっても、彼女は資金を新しいウォレットへローテーションするだけで済みます——「税理士が動かせたかも」という不安ではなく、「気持ちのうえで線を引きたい」という理由でです。
三つ目はリカバリの例です。普段使いのスマホが盗まれ、そのスマホには「ハードウェアで守られたスペンドキーから派生した watch-only ウォレット」が入っていたとしましょう。窃盗犯はそのユーザーの入金履歴すべてを手に入れます——識別可能な相手から定期入金を受けていた場合、これは深刻なプライバシー被害です——が、1 piconero たりとも動かせません。Monero にリボーケーション機構はないので「無効化」はできませんが、ユーザーは新しいシードから新アドレスを作り、資金をそこへ移します。古いビューキーはそれが既に見た取引については未来永劫有効ですが、新しいウォレットは古いビューキーからは完全に不可視です。
三つのシナリオすべてで同じ性質が成り立っています——ビューキーは「受け取ったお金」についての過去と現在の問いに答え、スペンドキーだけが「次にお金がどこへ行けるか」に答える。MoneroSwapper のスワップフローも同じ性質に依存しています。顧客はエンドツーエンドで自分が管理するアドレスで XMR を受け取り、プラットフォーム側が顧客の代わりに支払いを実行できるような鍵を要求する瞬間はどこにも存在しません。
サブアドレスと鍵の関係:もう一歩踏み込む
本稿のここまでは「プライマリアドレス」と一対の鍵という最も基本的な構成を扱ってきましたが、実運用の Monero ウォレットでは多くの場合、サブアドレス(subaddress)という派生アドレスが使われます。サブアドレスは「メジャーインデックス × マイナーインデックス」の組によって決まる派生アドレスで、見た目は通常アドレスと区別がつきませんが、ブロックチェーン上では互いに紐づけ不能な独立した受け取り口として振る舞います。たとえば EC サイトが顧客ごとに別のサブアドレスを発行すれば、第三者は「同じウォレット宛である」とは判別できません。
ここで重要なのは、サブアドレスを生成・スキャンするために必要なのが「プライマリの秘密ビューキー」だけだという点です。ウォレットはビューキーをハッシュしてサブアドレス用の派生鍵を計算し、それを使ってチェーンを走査します。スペンドキーが関与するのは、サブアドレスに届いた出力を実際に動かす段階だけです。この性質は監査用途に強力な含意を持ちます——プライマリビューキーを監査人に渡せば、運用上どれだけサブアドレスを切っていても、すべての入金が一括で監査対象になる、ということです。逆に言えば、「特定のサブアドレスだけを監査対象にしたい」というニーズには標準のビューキーモデルでは応えられません。そのため、寄付プロジェクトでビューキーを公開する場合は、プライマリビューキーで「すべての帳簿」を晒すことになる、という点を必ず織り込んだうえで意思決定する必要があります。
運用前チェックリスト:日本のユーザー向け
日本国内で Monero を扱う場合、技術的なリスク以外に押さえておきたい論点が二つあります。一つは国税庁が暗号資産を雑所得(一部の例外を除く)として扱う枠組みであり、年間 20 万円超の所得が発生すれば確定申告が必要になる可能性が高いという点。もう一つは、国内取引所が金融庁の方針を受けて Monero の取り扱いを停止しているため、入手経路が必然的に海外取引所か no-KYC スワップ(MoneroSwapper など)になる点です。この二つを踏まえて、運用開始前に以下を確認しておくと事故が減ります。
- シードの物理バックアップ:クラウドに保存しない。金属プレート(Cryptosteel など)か防水紙に書き出し、できれば二箇所に分散して保管する。
- ビューキーの保管場所:会計用端末からはアクセス可能、私物デバイスからは隔離。クラウドメモアプリでの保管は避ける——漏えいすれば一生取り返しがつかない。
- 取得原価の記録:スワップ実行時のレート、日時、対価とした暗号資産を含めて記録。後から税理士に view-only ウォレットを渡しても、その時点で取得原価を再構成するのは困難。
- ハードウェアウォレットの検討:残高が一定額を超えたら Ledger か Trezor の Monero アプリへ移行を検討。スペンドキーがセキュアエレメントを離れない構成は、フィッシング耐性の観点で価値が大きい。
- watch-only 端末の OS 更新:ビューキーが入っている端末は、流出すればプライバシーの全損につながる。OS とウォレットアプリの自動更新を必ず有効化する。
FAQ
ビューキーだけ盗まれたら Monero も盗まれますか?
いいえ。ビューキーは入金トランザクションと金額を見るための鍵であり、署名やキーイメージ生成など、資金を動かす行為は一切できません。ビューキーの流出はプライバシー上の問題——過去・未来の入金がすべて漏れる側に可視化される——ではありますが、資金そのものはスペンドキーだけが握り続けます。
watch-only ウォレットでは、なぜ出金が見えないのですか?
出金の検知はキーイメージのマッチングで行われ、キーイメージは秘密スペンドキーからしか生成できないからです。watch-only ウォレットは「ある出力が存在する」ことまでは認識できても、「その出力がその後使われたかどうか」は判別できません。そこで、支払い側ウォレットからエクスポートした署名済みキーイメージファイルをインポートすると、その差分が埋まり、残高が一致します。
ビューキーはスペンドキーから導出されるのですか?それとも独立ですか?
標準的な Monero ウォレットでは、ビューキーはスペンドキーを Keccak-256 でハッシュし、結果を Ed25519 の群位数で剰余を取ることで決定論的に導出されます。25 語ニーモニックがスペンドキーだけをエンコードしているのはこのためで、ビューキーは自動的に付いてきます。独立したビューキーを使う高度な構成も存在しますが、一般向けのウォレットはすべて導出型を採用しています。
両方のキーを別々にバックアップすべきでしょうか?
シード(あるいは生のスペンドキー)さえバックアップしていれば、ビューキーはいつでも再生成できるので原則として不要です。とはいえ、監査人がアクセスできる場所にビューキーのコピーを別途置いておくユーザーも多くいます。これはセキュリティを弱めない便利な運用で、シードは現金のように、ビューキーは読み取り専用の銀行明細のように扱う、という分担が現実的です。
ビューキーが漏れたらローテーションできますか?
単独ではできません。ビューキーは数学的にアドレスと結びついているため、ローテーションするには新しいウォレット(新しいシード、新しいスペンドキー、新しいアドレス)を作り、資金を移すしかありません。ビューキー流出は「そのウォレットの生涯にわたるプライバシー事故」として計画に織り込み、許容できなくなった時点で移行する、というロードマップを持っておきましょう。
Ledger や Trezor のようなハードウェアウォレットはスペンドキーをどう扱いますか?
Ledger や Trezor で Monero アプリを動かすと、スペンドキーはセキュアエレメントから一歩も外に出ません。ホスト PC が保持するのはビューキーだけで(チェーンを走査するために必要)、未署名トランザクションをデバイスに送って内部で署名させます。これは鍵分離を物理的に最も美しく具現化した形と言えます——ビューキーは「使い勝手」が住む場所に、スペンドキーは「安全」が住む場所に、それぞれ置かれているのです。
取引所の入金履歴を税理士に渡すとき、ビューキーを使うのと CSV を使うのではどちらが良いですか?
用途次第ですが、長期的には「ビューキー+ローカル同期」の方が改ざん耐性に優れます。CSV は人間が編集できる単なるテキストファイルなので、税理士から見れば「クライアントが手で書き換えた可能性」をゼロにできません。一方、ビューキーを使って税理士事務所側で watch-only ウォレットを同期させれば、表示される金額はチェーン上の RingCT コミットメントを復号した結果そのものであり、第三者が改ざんできる経路がありません。両方を併用するのが現実解で、CSV は日々の記帳に、ビューキー同期は年度末の正本確認に使う、という運用が安定します。
FCMP++ が本番化したら、ビューキー・スペンドキーの仕組みは変わりますか?
外形的なユーザー体験——ビューキーで読み、スペンドキーで送る——は変わりません。FCMP++(Full-Chain Membership Proofs Plus Plus)はリングメンバーの選び方をリング 16 個から「チェーン全体」に拡張し、メタデータ漏えいを大幅に減らす更新で、鍵モデルそのものを置き換えるものではありません。とはいえキーイメージ周りの内部実装は更新されるため、watch-only と支払いウォレットの間で交換するキーイメージ形式に互換性のない変更が入る可能性はあります。テストネットの動向は引き続きウォッチしておいて損はないでしょう。
マルチシグとキーの「分割」は別物
「ビューキーとスペンドキーの分離」と、Monero のマルチシグ(M-of-N)でのキー分割は、しばしば混同されますが原理がまったく違います。前者は単一ユーザーが「閲覧の権限」と「支払いの権限」を縦に切り分けるための仕組みであり、信頼境界は基本的に「自分」と「自分以外」の間にあります。後者は複数の当事者が同時に署名しないと送金できない、という横方向の信頼分散です。たとえば 2-of-3 マルチシグを組めば、三つの秘密鍵シェアのうち任意の二つの保持者が合意した場合のみトランザクションが成立します——個別のシェアからスペンドキーを復元することは数学的にできません。
このため、組織で Monero 資金を管理する場合は、「ビューキーは経理に共有しておけば良いが、出金には常に CFO とテックリードの二者承認が要る」といった役割分解が、ビューキー公開とマルチシグの組み合わせで自然に表現できます。MoneroSwapper のような自己管理型サービスは、こうした組織運用と相性が良く、出金先アドレスを多者承認のマルチシグウォレットに指定するだけで、no-KYC のフローを保ったまま内部統制を効かせられます。鍵を「役割で縦に分け、人で横に分ける」——この二軸を意識すると、設計の自由度が一気に広がります。
まとめ
ビューキーとスペンドキーは「一つの秘密の半分ずつ」ではありません——役割の異なる二つの秘密であり、Monero プロトコルが最も有用な特性を獲得しているのは、両者を統合することを意図的に拒否しているからです。一度この分離の構造が腑に落ちると、watch-only ウォレット、監査ワークフロー、寄付の透明性、ハードウェアウォレットの設計のいずれもが、「巧妙なハック」ではなく「思慮深い設計の必然的な帰結」として見えてくるはずです。今日これから新しいウォレットを立ち上げるなら、シードをオフラインで書き留め、支払いが不要な端末向けにはビューキーだけを派生させ、出所のわからない入力欄にはどちらの値も決して貼り付けない——この三つを守るだけで、防御線は大きく前進します。そしてそのウォレットへ XMR を実際に入れる段になったら、MoneroSwapper が主要資産から no-KYC のスワップを提供してくれます。送付先はあなたが自分で管理するアドレスで、フローのどの段階でも一つの鍵すら要求されません——本稿を読み終えた今、まっとうなサービスに期待すべき挙動とは、まさにそれだ、ということがわかっていただけたはずです。
🌍 他の言語で読む