Moneroのview key：読み取り専用ウォレットが見えるもの・見えないもの（2026）

view keyはMoneroウォレットの「読み取り専用の半分」であり、暗号資産の経理で最も過剰共有される秘密です。 標準的なMoneroアドレスは95文字に2つの公開鍵を詰めています：spend公開鍵Bとview公開鍵A。Aの秘密鍵がview key a、32バイトで通常は64桁の16進数です。aだけで、そのウォレットへの全入金を復号し金額を読めます。aだけでは、1 piconeroも動かせません。この非対称性こそが経理・監査・トレジャリーがview keyを求める理由であり、善意ではなくルールが必要な理由です。

この代数は写経ではなく、実装して確かめました。 ウォレットは保存されるのではなく導出されます：spend秘密鍵b = Hs(seed)、view秘密鍵a = Hs(b)、アドレスはvarint(18) || B || A || keccak256(keccak256(varint(18) || B || A))の先頭4バイトをbase58にしたもの。以下の記述を検証するため、この経路を一から実装しました。Keccak-256は標準ベクタ（空入力でc5d24601...）に一致。base58エンコーダはMonero公式tests/unit_tests/base58.cppの14個のブロックベクタすべてに合格し、8バイトFF..FFがjpXCZedGfVQになるケースと先頭ゼロの2ケースも含みます。端到端の確認としては、Moneroのウォレット直列化テストに直書きされた2組の公開鍵をテストネット接頭辞53で再エンコードすると9svHk1wHPo3...と9y52S6PH8tz...になり、Moneroがそれらウォレットファイルを命名する際の先頭6文字と一致します。

view keyで実際に何ができるか。 新しいシードからメインネットアドレスを導出しました：49DEK2pVdZBTkmY4yYkxs5EXMG45X83RygMDVi34zxC6HHDKMgKN4wrBv2xBs5oyamEu4Vy5RzZ3XU9Sn8XRVSrNGRzc1Um、95文字、接頭辞18。view keyは8b2f295c...5a05です。能力は2つ。第一に、各トランザクションはtx公開鍵Rを公開します。ウォレットは取引ごとに共有秘密aRを1回計算し、出力番号iごとにHi = Hs(aR || i)を求め、P' = Hi*G + Bを作ってオンチェーンの出力鍵と比較します。一致すれば「自分の出力」で、同じ共有秘密が金額を復号します。第二に、サブアドレスはview keyだけで導出できます：m = Hs('SubAddr' || a || major || minor)、D = B + mG、C = a*D。aと公開されたBだけで(0,1)(0,2)(0,3)のサブアドレス——84Y1S91V...、82b5J7zr...、88shGQ6Z...——を生成しました。各95文字、すべて8で始まり（接頭辞42）、spend鍵には一切触れていません。

そしてそれがリスクでもあります。 view keyは「読み取り専用だから無害」ではありません。ウォレットの存続期間中の全入金——過去も未来も、正確な金額と時刻つきで——を明かし、サブアドレスが同じ代数から出るため、これまで発行した全請求アドレスを1つのウォレットに結び付けます。出金は見えず、その欠落には実務上の帰結があります：読み取り専用ウォレットはkey imageを計算できません。key imageは(Hs(aR || i) + b) * Hp(P)で、bが無いからです。したがってどの出力が既に使われたか判別できず、spendウォレットが資金を動かすと表示残高は上振れします。view key側の残高は「利用可能」ではなく「累計受領」として扱ってください。テスト取引では、読み取り専用スキャンが出力1をサブアドレス(0,3)に一致させ金額も復号しましたが、計算できたのは支払側スカラーHs(aR || 1) = d2a1346b...までで、key imageはbを戻して初めて現れました。

生きたチェーンではこう見えます。 ブロック3,796,140（本日13:18:40 UTC）は30,980バイトに18件のトランザクションを含みます。38488d18...は2,220バイトで手数料0.0001776 XMR：1バイトあたり80,000 piconeroで、ノードが現在提示する下限20,000 piconero/Bの4倍です。入力2つはそれぞれ16のリングメンバーを持ち、出力2つの表示金額はどちらも0。この0は不具合ではなく、RingCTが金額を暗号化フィールドへ移し、チェーンにはコミットメントだけを残すためです。extraフィールドは0x01と32バイトのtx公開鍵で始まり、続いて0x02と9バイトのナンス（暗号化された支払いID）が入ります。外部の観察者ができるのは、出力が2つあると数えて推測することだけ。受取人のview keyができるのは、2つの候補出力鍵を試して1つの金額を復号することだけです。

ウォレットを渡さずに鍵だけ渡す。 メインのウォレットファイルをコピーするのではなく、読み取り専用ウォレットを別に作ります：monero-wallet-cli --generate-from-view-key audit.dat --restore-height N でview keyを貼り、--subaddress-lookahead を発行済みアドレスをカバーする値に設定します。先読みを超えた過去のサブアドレスは認識されないからです。復元高はどのフラグより重要です。ジェネシスから走査するのは無駄で、走査コストは現実にあります。直近30ブロックでは中央値67,089バイト、平均102,540バイト（30個のうち2個は取引1件以下）で、先端に追従するだけで1日約74 MB、年間約27 GBのチェーンデータに相当します。監査人には最初の入金予定直前の復元高を渡し、対象期間を書面にしてください。

露出を小さく保つ4つのルール。 1、渡すのはコピーだけ、原本は渡さず、業務終了時にコピーを削除する——鍵に期限はありません。2、鍵よりエクスポートを優先する。入金CSVは会計上の疑問のほとんどに答え、将来の入金は何も漏らしません。3、リアルタイム追跡が本当に必要なら、鍵に終了日と受取人リストを添え、保有者がそのウォレットへの以後の全入金を見ると想定する。4、view keyを対応するアドレスと同じ経路で送らない。一文字ずつ照合していない鍵を送らない。view keyもspend keyも64桁の16進で、コマンドを1つ間違えれば違う方を渡してしまいます。公開spend鍵と公開view鍵を秘密view鍵の隣に印字し、その組が請求書のアドレスに本当に属するか確認してください。

インスタント交換の位置づけ。 交換にview keyは不要で、要求されるべきでもありません。VeilSwapの注文エンドポイントが受け取るのは7項目：fromAsset、toAsset、fromAmount、toAddress、toExtraId、refundAddress、refundExtraId。返金アドレスは2026年10月25日以降必須、カタログは現在516資産・75ネットワーク（うち60がステーブルコイン）で、XMRにextra IDは不要です。見積の有効期間は120秒、入金窓は30分、支払いはプールが署名し、あなたのウォレットは関与しません。入金を「確認」するためにview keyを貼れと言うサービスがあれば危険信号です。入金アドレスとトランザクションハッシュだけで着金は証明でき、支払いを解放するのにそれ以上は要りません。

要するに。 view keyは収入を読む会計担当には正しい道具で、「他に何も読まれていない」ことを確実にしたい人には間違った道具です。できるならエクスポートを、必要なら期間限定の読み取り専用ウォレットを渡し、spend鍵——署名でき、key imageを計算できる唯一の鍵——は監査人が触れない機械に置いてください。レートは動くので、ここでの数字は時刻付きの記録です：本日14:03 UTC時点で100 USDT-TRC20は0.14880904 XMR（含意671.99 USDT/XMR、現物592.60）、10,000 USDTは16.61076502 XMR、1 XMRは574.509235 USDT、0.05 BTCは6.4437305 XMR。ページ上の実勢見積だけが意味を持ちます。 (XMR→USDT 出口ルート)