Monero のサブアドレスとペイメントID：今も使えるもの
直近の Monero 取引 1,463 件のうち 92.8% に「ペイメントID らしきもの」が入り、旧式の 32 バイト長 ID は 1 件もありませんでした。サブアドレスの正体、パディングの理由、受け取り側がやりがちな 5 つの誤りを整理します。
Monero の取引のおよそ 93% にはペイメントID が付いていて、そのほとんどは意味を持ちません。 2026年10月24日のブロック 3,791,102〜3,791,141 には通常取引が 1,463 件ありました。うち 1,357 件（92.8%）の extra フィールドに nonce があり、その 1,355 件はちょうど 9 バイト——0x01 のマーカーと 8 バイトの暗号化ペイメントID です。2017 年に取引所が配っていた 32 バイトの長い ID を持つ取引は 1 件もありません。公式 Moneropedia は明快で、長いペイメントID は 0.15 で削除され、もはや使えません。つまりオンチェーンで「ペイメントID らしく見えるもの」の圧倒的多数は、ウォレットが意図的に入れたパディングです。
アドレスとペイメントID は別物で、混同がサポート問い合わせの大半を生みます。 Monero のアドレスは 95 文字です：1 バイトのネットワーク接頭辞、32 バイトの spend 公開鍵、32 バイトの view 公開鍵、4 バイトのチェックサムを、base58 で 8 バイトずつ区切って符号化します——11 文字のブロックが 8 つと、5 バイトの末尾が 7 文字、これで 95 になります。接頭辞が先頭文字を決め、cryptonote_config.h では標準アドレスが 18（4 で始まる）、サブアドレスが 42（8 で始まる）、統合アドレスが 19 です。統合アドレスは同じ内容に 8 バイトのペイメントID を埋め込んだもので、77 バイト・106 文字、先頭はやはり 4 です。ペイメントID は（統合形式を除き）アドレスの中には存在せず、取引の extra フィールドにメタデータとして載ります。
サブアドレスは手持ちのアドレスに鍵を 1 回足しただけで、二つ目のウォレットではありません。 サブアドレス（アカウント、インデックス）の spend 公開鍵は、主 spend 公開鍵に「主 view 秘密鍵＋アカウント番号＋サブアドレス番号」のハッシュを加えたもので、view 鍵は共通です。アカウント 0・インデックス 0 が主アドレスそのもので、ウォレットが一覧の先頭に置くのはそのためです。インデックスは 32 ビット整数なので、1 アカウントで 42 億 9,496 万 7,295 通りの用途にラベルを付けられ、2 つ目のシードもバックアップも要りません。顧客ごと・注文ごと・請求書ごとに別の Monero アドレスを渡せるのはこの仕組みによるもので、チェーン側には無関係に見える宛先が並び、手元にはラベルの付いた 1 つの勘定だけが残ります。
このパディングは意図的で、ソースコードにも書かれています。 cryptonote_tx_utils.cpp の取引構築は `bool add_dummy_payment_id = true;` から始まり、長い ID も短い ID も渡されていなければ null の hash8 を暗号化して付け加えます。コメントには「時間が経つにつれ大多数の取引がこうなるはず」とあります。無効化されるのは 2 つの場合：すでにペイメントID を持つ取引か、「宛先 1 つ＋おつり」より多い取引です。オンチェーンのサンプルはこの規則にほぼ一致しました。nonce を持つ 1,357 件はすべて出力がちょうど 2 つ、nonce のない 106 件のうち 96 件は 3 つ以上（3 出力が 49 件、4 出力が 16 件、16 出力が 1 件）でした。例外の 10 件は 2 出力でありながらパディングしなかったウォレットです。
プライバシー上の効果は両方向に働き、そこが要点です。 支払う側にとってパディングは利点で、本当にペイメントID を持つ取引と持たない取引が区別できなくなり、誰が取引所に送金しているかが漏れません。受け取る側にとっては、頼りにしていた信号が消えます——チェーンを見ても、送金者が入力した ID かウォレットが生成した ID かは判断できません。だからこそ入金の突合はアドレス、できれば専用サブアドレスに紐づけるべきで、ペイメントID に紐づけるべきではありません。今もペイメントID で顧客と入金を結びつけているなら、93% がノイズのフィールドで照合していることになります。
サブアドレスも 8 バイトのペイメントID も追加コストはなく、手数料はどちらでも変わりません。 2026年10月24日 14:00 UTC 前の 10 ブロック、326 件の取引で、手数料率は 1 バイトあたり 20,000／80,000／320,000 piconero の 3 つの帯に分かれ、それぞれ 179 件・74 件・39 件でした。手数料の中央値は 44,570,000 piconero＝0.00004457 XMR、CoinGecko の XMR 597.78 ドルでは約 0.027 ドルです。入力 1・出力 2 の取引は 1,534 バイト、入力 2・出力 2 は 2,220 バイト。サブアドレスの出力は通常の出力で、同じ tagged key、同じ 30 数バイト、割増はありません。8 バイトのペイメントID は tx_extra に 9 バイトを足しますが、そのフィールドはもともとパディングされるので、有効にしてもサイズは変わりません。実際に効くのはウォレットが選ぶ優先度で、同じ取引でも最大 16 倍の差になります。
交換注文の場面では、ルールは 1 つに絞られます——95 文字を貼る、それだけです。 当サイトの注文フォームが求めるのは XMR アドレス 1 つだけで、通貨カタログでは xmr の hasExtraId が false、つまり記入すべきタグ欄も、創作すべきペイメントID もありません。注文 API はアドレスが 256 文字未満の文字列かどうかしか見ないため、106 文字の統合アドレスも検証を通り、チェーン上でも受け取れます。ただし注文が求めているものではなく、そうした違いが入金を手動審査に送り込みます。2026年10月24日 14:05 UTC の見積 API は、100 USDT-TRC20 → 0.16382091 XMR、500 → 0.82593、1,000 → 1.652442、5,000 → 8.264534 を返し、1 XMR は 592.31 USDT でした。取引所の出金フォームがペイメントID を尋ねてきたら空欄にしてください。こちらが要求していない ID は突合の役に立ちませんし、32 バイトの長い ID はそもそもブロードキャストできません。 (XMR→USDT 出口ルート)
受け取り側が今もやりがちな 5 つ。 第一に、ペイメントID を必須扱いして、ID なしで届いた入金を拒否すること。資金はアドレスに着いており、欠けているのは支払いではなく欄です。第二に、95 文字と明記されたフォームに 106 文字の統合アドレスを貼ること。事業者によっては即座に無効と判定します。第三に、すべての用途で 1 つのサブアドレスを共有すること。サブアドレスが解こうとした「共有アドレス」問題を自分で作り直しているだけです。第四に、統合アドレスへの一括送金。暗号化ペイメントID の経路は宛先がちょうど 1 つであることを要求し、cryptonote_tx_utils.cpp の構築処理は複数出力の宛先でエラーになります。第五に、新しいサブアドレスなら金額やタイミングも隠れると思うこと。隠れません。顧客同士を切り離す、それだけです。
サブアドレスを正しく運用するのに必要なのは 3 つの習慣です。 作成時にラベルを付けること。ラベルのない行が 200 個あるウォレットは突合できない台帳です。返金用アドレスは同じシードの別サブアドレスにすること。失敗した注文が顧客に見えるアドレスへ戻る事故を防げます。そして読み取り専用の会計にはシードではなく view キーを使うこと。view キーは金額を見せても使う権限は与えず、問いに答えられる最小の露出です。時間について、抽出した 40 ブロックの平均間隔は 105.9 秒（目標 120 秒）でしたから、10 確認はおよそ 20 分。この待ち時間は宛先が主アドレスでもアカウント 3 の 87 番サブアドレスでも変わりません。
覚えておく価値のあるルール。 ペイメントID は共有アドレスに貼られたラベル、サブアドレスはそれ自体がアドレスであるラベルです。2026 年は、受け取り側を自分で握れるところでは後者を使い、他人のフォームがペイメントID を尋ねてきたら空欄にする。以上の数値はすべて 2026年10月24日 14:00 UTC 前後のチェーンと当サイトのエンドポイントによるもので、1,463 件の取引、326 件の手数料サンプル、1 XMR = 592.31 USDT（現物 597.78）でした。価格は動くので、拘束力があるのは交換ページのリアルタイム見積もりだけです。 (XMR→USDT 出口ルート)