はじめに（この記事で分かること）#

Moneroの台帳は、送金元・送金先・金額を外から読めないように作られている。その仕組みはBitcoinとMoneroの追跡可能性で説明した。ところが、ウォレットを開いた瞬間から、台帳の外側で別の情報が流れ始める。ウォレットは残高を確かめるためにどこかのノードへ接続し、送金するときはそのノードに取引を手渡す。

Moneroの公式ドキュメントは、他人のノード（リモートノード）が知りうるものとして、利用者のIPアドレス、送った取引、その取引が使った出力を挙げている。台帳の暗号がどれほど強くても、「このIPアドレスから、この時刻に、この取引が出された」という記録は、ノードの運営者の手元に残りうる。

この記事は、ウォレットを選ぶ前に知っておきたい「ノードとの関係」を中心に、主要なウォレットの設計の違い、ハードウェアウォレットとバックアップ、まだ稼働していないFCMP++への備えを整理する。どのウォレットが一番よいかは書かない。脅威モデルによって答えが変わるからだ。

前提: 脅威モデルの整理#

脅威モデル入門の5種類の相手のうち、この記事の対策が効くのは主に二者だ。

一つはISPだ。自分のノードを何も設定せずに動かすと、取引は普通のインターネット回線で送り出される。公式ドキュメントは、この既定の状態について、ISPと最初に取引を受け取るノードに対してはDandelion++も保護にならないと書いている。

もう一つは、リモートノードの運営者だ。これは5種類の分類にそのまま当てはまらない、暗号資産に特有の相手である。公開ノードの運営者が誰かは、多くの場合わからない。公式のGUIガイドは、利用者の匿名性を剥がすことだけを目的に運営されている公開ノードがあると警告している。

効かない相手もはっきりしている。取引所や両替サービスの本人確認記録は、ノードの設定では消えない。法執行機関が端末を押収すれば、ウォレットファイルとシードがそのまま証拠になる。この記事の対策は「台帳の外で、通信からつながりが漏れる経路」を細くするものであって、入口と出口の記録の問題はMoneroの入手方法や取引所の本人確認で提出した情報の行き先で扱う領域に残る。

フルノードとリモートノード#

Moneroのウォレットはブロックチェーンそのものを持たない。公式ドキュメントの説明では、ウォレットはフルノードか剪定（pruning）したノードに接続し、自分宛ての入金を探すためにチェーンを走査する。そのノードが自分の機械で動いていればローカルノード、他人の機械で動いていればリモートノードと呼ぶ。

自分でノードを持つ代償は、ディスクと時間だ。Moneroの技術仕様のページは、2026年10月5日時点のチェーンの大きさを、フルノードで約265GiB、剪定したノードで約105GiBとしている。剪定とは、リング署名のデータのうち必須でない部分の8分の7を捨て、ランダムな8分の1だけを残す仕組みで、Moneropediaは取引履歴をすべて保ったまま容量の約3分の2を節約できると説明している。ノードを動かす本体はmonerodというデーモンで、公式のGUIとCLIに同梱されている。

リモートノードの利点は、その全部を省けることだ。巨大なデータを落とす必要も、同期を待つ必要もない。そのぶん、ウォレットがチェーンをどう見るかを第三者に委ね、その第三者が利用者について何かを知りうる状態になる。公式ドキュメントはこの交換条件をそのまま書いている。

公式のMonero GUIは、この選択を「ウォレットモード」として利用者に示している。シンプルモードは公開リモートノードに自動で接続する。シンプルモード（ブートストラップ）は、リモートノードで当面の操作をしながら、裏で自分のノードにチェーン全体を同期する。アドバンストモードでは自分のノードを使うか、接続先のリモートノードを自分で指定する。公式のGUIガイドによれば、任意のリモートノードを指定できるのはアドバンストモードだけだ。

ここで一つ誤解しやすい点がある。自分のノードを動かせば、それだけで私的になるわけではない。公式ドキュメントの要約は「自分のノードを動かすこと自体は、必ずしもプライベートではない」と書き出している。理由は次の節で扱う。

リモートノードに見えるもの#

見えるもの、見えないもの#

Moneroの公式ドキュメント「Remote Nodes and Privacy」は、リモートノードにできないことと、知りうることを分けて書いている。

できないことのほうから見ると、リモートノードは秘密鍵もウォレットファイルも受け取らない。だから資金を使うことも盗むことも、利用者に代わって取引を作ることもできない。金額を復号することも、残高を直接見ることもできない。ウォレットはブロックを丸ごと受け取り、手元の秘密の閲覧鍵（ビューキー）で自分のものを探す。ノードは、ブロックを渡しただけでは、そのうちどの出力が利用者のものかを知らない。

知りうるものとして、ドキュメントは四つを挙げる。利用者のIPアドレス。利用者が送る取引（その中身の多くは暗号で守られている）。その取引がどの出力を使っているか。そして、ノードを「信頼済み（trusted）」に設定した場合には、どの出力を利用者が持っているか。信頼済みのノードには、キーイメージが使用済みかどうかの確認など、より踏み込んだ問い合わせが送られる。ドキュメントは、エアギャップ型のウォレットの一部は信頼済みノードがないと動かず、そのため所有する出力をノードに明かすことになると注記している。

ここから読み取れること（推測を含む）を整理しておく。リモートノードは、台帳を読むだけでは分からない「この取引を最初に持ち込んだのはこのIPアドレスだ」という対応を、構造的に手にする立場にある。その対応が記録され、運営者が法的要請や侵害で第三者に渡せば、台帳の外の手がかりになる。運営者が実際に記録しているかどうかは、外からは確かめられない。

悪意のあるノードにできること#

記録すること以外にも、ドキュメントは不誠実なノードが利用者を妨害する方法を挙げている。取引の中継を遅らせる、または拒む。入金が遅れて見える、あるいは見えなくなるようにデータを隠す。誤解を招くデータを返す。ドキュメントが例に挙げるのは、手数料の見積もりを水増しすることと、リングのおとりを偏らせてリング署名のプライバシーを弱めようとすることだ。ドキュメントは「確定前に必ず手数料を確認する」よう勧めている。

GUIのリモートノード案内も、悪意ある公開ノードの手口として「平文のIPアドレスと取引IDを結びつけること」と「偽のおとりを渡して、どの出力が本当に使われたかを割り出すこと」を挙げている。Featherのドキュメントは、本物の入力を明かしうる攻撃について成功の見込みは低いとし、Featherが検知すれば警告すると書いている。

Dandelion++との関係#

Dandelion++ は、2020年5月のv0.16.0.0でMoneroに加わった仕組みで、取引をすぐに全方向へ広げず、まず細い一本道（stem）で何回か受け渡してから拡散させる。ネットワークを観測する者が「最初に流したノード」を推定しにくくするためだ。

ただし、Dandelion++ が守るのはノード同士の伝わり方だ。リモートノードを使うとき、ウォレットは取引をそのノードに直接手渡す。ノードの運営者から見れば、取引を誰から受け取ったかは明らかで、Dandelion++ はこの最初の一歩を隠さない。公式ドキュメントも、自分のノードを既定の設定で動かす場合について、Dandelion++ は発信元をたどりにくくするが、ISPと最初に送られる先のノードには保護にならないと書いている。さらに、外からの接続を受けていないノードは他人の取引をstemで中継しないので、そのノードがstemで送る取引は本人のものだと分かってしまう、という注記もある。

Tor・I2P経由の接続#

公式ドキュメントは、プライバシーの高い順に構成を並べた比較表を載せている。要点を日本語にすると次のようになる。

構成取引とIPアドレスを結びつけられる者補足
ローカルノード＋--proxyと--tx-proxyいないP2P通信全体をプロキシ経由にし、自分の取引は匿名ネットワークで送る
ローカルノード＋--tx-proxyいない取引はTor/I2Pで送る。ブロック同期は平文の回線なので、ノードを動かしていること自体は見える
リモートノードにTor/I2Pの秘匿サービスとして接続いない運営者は取引を見るが、IPアドレスは見ない
平文のリモートノードにTor経由で接続いないSSL/TLSがなければ、Torの出口リレーも通信を見て改ざんできる
VPN経由でリモートノードに接続VPN事業者運営者に見えるのはVPNのIPアドレス
SSL/TLSでリモートノードに接続ノード運営者経路上の第三者は読めないが、運営者はIPと取引を見る
ローカルノードを既定設定で動かすISPと接続先のノード（可能性）Dandelion++ は効くが、ISPと最初の送り先には効かない
SSL/TLSなしでリモートノードに接続運営者と経路上の誰でも最もプライベートでない

--tx-proxyはmonerodの設定で、Moneroのリポジトリにある匿名ネットワークの文書によれば、Tor/I2P上で扱うのはハンドシェイク、定期的な同期メッセージ、取引の配信に限られる。同じ文書は限界も書いている。同期メッセージに現在時刻が含まれるため、onionアドレスと平文のIPアドレスを結びつける手がかりになりうること。送金のときだけmonerodを起動するような使い方は、ISPが利用者と取引を結びつける材料になりうること。同じ接続で複数の取引を送ると、受け取った側が同じ送り主だと推定できること。

ここで出てくるVPNの行は見落とされやすい。VPNはノードの運営者からIPアドレスを隠すが、その情報はVPN事業者に移るだけだ。VPN事業者を信頼できるかどうかはノーログVPNの記事の論点になる。Tor・I2Pの秘匿サービスとして接続する構成は、運営者からIPアドレスを隠しつつ、経路の暗号化も兼ねる。ただし、運営者が取引そのものを見ることは変わらない。Torを使った通信全般に残る時刻の相関の問題は、タイミング相関の記事で扱っている。

ウォレットの設計の違い#

比較表#

getmonero.orgのダウンロードページは、第三者のウォレットを「Moneroのコアチームが管理していない」と断ったうえで、二つに分けて載せている。チェーンを手元で走査する「ローカル同期」型（ANONERO、Cake Wallet / Monero.com、Feather、Monerujo、Monfluo、Stack Wallet、Unstoppable）と、サーバー側で走査する「リモート同期」型（Edge）だ。後者についてページは、サーバーを自分で管理していなければプライバシーが下がりうると注記している。理由はページに書かれていないが、サーバー側で入金を探すには閲覧に必要な鍵をサーバーに預ける形になるためとみられる（当サイトの推測）。

ここではローカル同期型の代表として、公式のMonero GUI/CLI、デスクトップ向けのFeather、モバイル中心のCake Walletを並べる。版番号は2026年11月8日にGitHubのリリースで確認した。

項目Monero GUI / CLIFeatherCake Wallet
確認した版0.18.5.4（GUIは2026-10-17公開。公式ブログの告知は10-16）2.9.1（2026-11-02公開）6.5.3（2026-11-05公開）
対応OSGUI: Windows・macOS・Linux。CLI: 加えてAndroid・FreeBSDなどのビルドもあるLinux・Windows 10以降・macOS 14以降。Tails向けの手順ありAndroid・iOS・macOS・Linux。Windows版の新規リリースは停止中
ノード接続自分のノード（同梱のmonerod）か、指定したリモートノード。シンプルモードは公開ノードに自動接続既定では、厳選リストからランダムに選んだリモートノード。初回起動時に接続方法を選べる既定はCake Wallet自身のノード（SSL）。他の公開ノードや自分のノードを追加できる
Tor・プロキシSOCKS5プロキシ設定（v0.17.0.1から、Tailsでは自動で有効）。monerod側で--tx-proxyTorを同梱。既定では「初回同期の後はTorに切り替え」、取引の配信はTor経由Torを内蔵（公式は実験的機能と表記）。既定では無効。onionノードを用意
シードの形式25語公式文書で今回は未確認新規は16語のPolyseedが既定。25語や12語のBIP39も選べる
閲覧専用ウォレット対応対応対応
ソースコード公開（monero-project）公開（BSD-3-Clause）公開（MIT）
配布物の検証binaryFateのGPG鍵で署名したハッシュ一覧（hashes.txt）を正とする開発者のGPG鍵（指紋を複数の経路で照合するよう案内）GitHubリリース、App Store、Google Play、F-Droid（Cakeのリポジトリ）など

表の各項目は、それぞれの公式文書の書き方を写したもので、同じ基準で試験したものではない。たとえば「Tor対応」という一語でも、どの通信がTorを通るかは製品ごとに違う。

Monero GUI / CLI#

公式ウォレットの特徴は、ノードとの関係を利用者が最もはっきり選べることだ。自分のノードを動かし、monerodに--tx-proxyを設定すれば、公式ドキュメントの比較表の上位の構成になる。代わりに、ディスクと同期時間がそのまま必要になる。2026年5月の0.18.5.0では、デーモンとウォレットにSOCKS v5の対応が加わり、UPnPによる自動のポート開放が削除された。

配布物の検証について、ダウンロードページは、ダウンロードしたアーカイブのSHA256を確かめるよう勧め、「壊れたアーカイブは資金の喪失につながりうる」と書いている。正とするのはGPGで署名されたハッシュ一覧で、署名はソースコードに含まれるbinaryFateの鍵で確かめる。初心者向けのWindowsの手順と、上級者向けのコマンドラインの手順が別に用意されている。

Feather#

Featherはデスクトップ向けのウォレットで（公式の対応OSはLinux・Windows・macOS）、ノードとTorの扱いを文書で細かく説明している。既定では、Moneroのコミュニティで信頼されている人が運営する高性能なリモートノードの厳選リストから、ランダムに一つ選んで接続する。初回起動時には、どこかへ接続する前に接続方法を選べる。

Torの扱いは、Featherの公式文書によれば次のとおりだ。リリースにはTorの実行ファイルが同梱されている。既定の設定は「初回同期の後はTorに切り替える」で、ウォレットの同期だけはTorを通さず、それ以外の通信はTorを通す。同期を通さない理由として、文書はTor経由の同期が遅いことを挙げている。「常にTor」「Torを使わない」も選べる。ローカルノードへの通信はTorを通らない。TailsやWhonixの上で動かした場合は、アプリの設定に関係なくすべてTorを通る。

ノードの説明では、リモートノードは利用者のアドレスや残高を知らず、送金先も金額も知らないとしたうえで、悪意あるノードにできることとして、手数料を操作して取引を目立たせること、平文の回線を使っている場合に送信取引とIPアドレスを結びつけることを挙げている。後者については、既定では取引はTorで配信されると書いている。

ここから読み取れること（推測）として、Featherの既定設定では、取引の配信はTorで守られる一方、初回同期の間は平文の回線でリモートノードに接続しているので、ノードの運営者には「このIPアドレスがMoneroのウォレットを同期している」ことは見えうる。同期もTorに通したいなら「常にTor」を選ぶことになり、その代わり同期が遅くなる。

配布物は開発者のGPG鍵で署名されている。公式文書は鍵の指紋（8185 E158 A333 30C7 FD61 BC0D 1F76 E155 CEFB A71C）を示したうえで、Matrixのチャンネル、monero.town、X、DNSのTXTレコードなど複数の経路で同じ指紋かを照合し、食い違いがあればすぐ開発者に報告するよう求めている。

Cake Wallet#

Cake Walletは、Moneroを含む多数の暗号資産を扱うモバイル中心のウォレットで、MITライセンスでソースコードを公開している。公式文書によれば、Android・iOS・macOS・Linuxで使え、Windows版はデスクトップアプリを作り直している間、新しいリリースが止まっている（v6.x以前のバイナリのみ）。

ノードの扱いでは、Cake Walletが自社で運営するノードが既定になっている。公式文書の一覧（v6.5.0時点）では、既定のCake Walletノードに加え、Feather、MoneroDevs、Seth For Privacy、StormyCloudなどのノードがプリセットされている。文書自身が「他人のノードを使うと、その運営者はウォレットの問い合わせを見られる」と書き、自分のノードを立てることを最大のプライバシーの改善として挙げている。ノードを追加するときの「Trusted」の設定は、自分が管理するノードにだけ使うよう注意している。

Torは内蔵されているが、公式文書は実験的機能と位置づけ、すべての接続がTorを通るわけではないと書いている。オンにすると同期は大幅に遅くなる。Tor使用中はCake Walletが運営するonionノード（Cake Wallet (Tor)）を選べる。為替レートの取得やスワップの見積もりについて「Torのみ」や「無効」を選ぶ設定もある。

ここから読み取れること（推測）として、Cake Walletを既定のまま使うと、Moneroの通信もアプリ内の両替機能の通信も同じ事業者のインフラに集まりうる。ノード、為替レートの取得、スワップ、購入の各機能について、どこへ何が送られるかを設定画面で一つずつ確かめる必要がある。アプリ内の購入やスワップは第三者の事業者が提供しており、それぞれの本人確認や地域の制限は、その事業者の規則による。Cake Wallet自体がMoneroの利用を地域で制限したという公式発表は、今回の確認では見つからなかった。

その他のモバイルウォレット#

ダウンロードページのローカル同期型の一覧には、MonerujoやANONERO、Stack Walletなども並んでいる。今回はこれらの公式文書までは確認していないので、比較表には載せていない。選ぶときに確かめる点は、上の三つと同じだ。既定でどのノードにつながるか。Torを通るのはどの通信か。シードの形式はほかのウォレットで復元できるか。配布物を何で検証するか。

ハードウェアウォレットとバックアップ#

対応状況#

getmonero.orgのダウンロードページ（2026年11月8日参照）は、Monero対応のハードウェアウォレットとして次を挙げている。LedgerはNano S、Nano S Plus、Nano Xで、GUI、CLI、Cake Wallet / Monero.com、Feather、Monerujoから使える。TrezorはModel T、Safe 3、Safe 5で、GUI、CLI、Featherから使える。

ウォレット側の文書は、この一覧と少しずつ違う。Featherの文書はLedgerのStaxとFlexも対応機種に含め、Trezor Safe 7は「Moneroがまだ実装していない新しい通信方式を使う」ため現時点で非対応としている。Cake Walletの文書は、LedgerとTrezorの両方でMoneroに対応するとし、TrezorはModel One、Model T、Safe 3、Safe 5、Safe 7を認識すると書いている。どの機種がどのウォレットで動くかは、使う前に両方の公式文書で確かめるのが確実だ。

ハードウェアウォレットが守るのは、秘密の使用鍵だ。送金の署名は機器の中で行われ、パソコンやスマートフォンがマルウェアに侵されていても、使用鍵そのものは取り出されにくい。一方で、ハードウェアウォレットはノードとの関係を何も変えない。ウォレットアプリはこれまでどおりノードに接続し、取引を送る。IPアドレスと取引の対応の問題は、ここまでの節の対策で別に扱う必要がある。

シードとビューキーの性質#

MoneropediaによればMoneroのニーモニックシードは16語か25語で、公式ウォレットは25語を使う。シードには資金を見ることと使うことの両方に必要な情報がすべて含まれ、Moneropediaはシードを渡すことを「他人に資金への完全なアクセスを許すのと同じ」と書いている。16語の形式（Cake Walletの既定のPolyseedなど）は、ウォレットの復元高さも含む点が25語と違う。Cake Walletの文書は、12語のBIP39形式で作ったMoneroウォレットはほかのMoneroウォレットで復元できるとは限らないと注記しており、その場合は25語の形式や鍵で移す方法を示している。

ビューキー（秘密の閲覧鍵）は、シードとは性質が違う。Moneropediaは、ビューキーはそのアカウントに関わる取引を見るために必要で、他人と共有できる鍵だと説明している。ビューキーだけを持つ「閲覧専用ウォレット」は、公式ガイドによれば入金を見ることはできるが、送金に署名することはできない。出金も確実には見えないため、出金のあるウォレットでは表示される残高が正しくなくなる。正しい残高を出すには、各出力のキーイメージを取り込む必要がある。

この性質から読み取れること（推測）として、ビューキーを渡す相手は、資金は動かせなくても、そのアドレスへの入金の履歴をすべて読める。税務の相談や監査のためにビューキーを渡すことは正当な使い道だが、渡した相手が記録を保存し、第三者に渡しうることは、取引所に本人確認書類を出すのと同じ構造になる。

バックアップで気をつけること#

シードを書き写した紙や金属板は、ウォレットそのものと同じ価値を持つ。端末が押収されたり盗まれたりしても、シードが別の場所にあれば資金は復元できる。逆に、シードを見つけた人は、端末がなくても資金を動かせる。Moneropediaは、オンラインのウォレットには失っても困らない額以上を置かず、保管にはコールドウォレットや紙のウォレットを使うよう勧めている。

写真やクラウドのメモにシードを残すと、それはクラウド事業者のアカウントの安全性に依存する。アカウントの復旧経路がどう弱点になるかはアカウント復旧経路の記事で扱っている。シードとあわせて、ウォレットを作った日付か復元高さを控えておくと、復元時の同期を短くできる（Cake Walletの文書は復元高さや日付の指定を案内している）。

FCMP++前後の互換性#

2026年11月8日時点で、FCMP++ はMoneroのメインネットで稼働していない。これはBitcoinとMoneroの追跡可能性で書いた2026年11月1日時点の確認と変わらない。

公式の記録で確かめられることは多くない。getmonero.orgのブログで最も新しいリリースは、2026年10月16日の0.18.5.4で、公式ブログはこれを「バグ修正を含む小規模なリリース」と説明している。ハードフォークやFCMP++ の日程には触れていない。2026年5月10日の公式ブログ記事「Deprecating Monero's Custom Transaction Unlock Time」は、取引に独自のロック解除時刻を設定する機能をFCMP++ のフォークで合意レベルで廃止すると書き、同時に「この記事の執筆時点でFCMP++ のフォーク日は決まっていない」と明記している。同じ記事は、FCMP++ に対応したウォレットはロックされた出力のキャッシュを持つ設計になる予定だとしている。

公式でない情報もある。開発者jeffro256がGitHubで公開している作業計画fcmp-carrot-planは、自ら「拘束力のない作業用の草案」と断ったうえで、2026年11月8日の参照時点で、FCMP++ とCarrotの有効化を2027年第17週と見積もっている。報道では、Cryptonewsが2026年10月23日の更新で、公式のフォーク日は未発表、試験用ネットワークのビルドでは閲覧専用とコールドウォレット、ハードウェアウォレット、マルチシグ、取引の証明がまだ動かないと伝えている。これは報道であって、公式の発表ではない。

ここから先は推測になる。過去のMoneroのネットワークアップグレードでは、フォーク前に対応版のソフトウェアが公開され、利用者はウォレットとノードを更新してきた。FCMP++ も、ウォレットとノードの両方の更新が必要になるとみられる。上の報道が正しければ、ハードウェアウォレットや閲覧専用ウォレットを使う人は、対応が他より遅れる可能性がある。シードの形式やビューキーの扱いが変わるかどうかについて、2026年11月8日時点で公式の説明は確認できなかった。

利用者の側で今できることは限られる。使っているウォレットの公式の告知経路（GitHubのリリース、公式ブログ、署名つきの配布物）を把握しておくこと。そして、フォーク前後に「アップグレードが必要」と称して偽のウォレットを配る詐欺が出ることを想定し、配布物の署名を確かめる手順を今のうちに一度試しておくことだ。

FCMP++ が稼働しても変わるのは台帳の上の匿名集合で、この記事で扱ったノードとの関係は変わらない。リモートノードは引き続き、取引を誰から受け取ったかを知る立場にある。

限界と残るリスク#

ノードの設定をどれだけ整えても、守れないものがある。

一つ目は、入口と出口だ。日本では、日本暗号資産等取引業協会の規則（2026年7月版、第4条第3項）が、移転記録の追跡ができない、または著しく困難な暗号資産について、問題が解決されない限り取り扱ってはならないと定めている。国内の登録業者でMoneroは扱われていない。国内業者からほかの暗号資産を外へ送る段階では、改正犯罪収益移転防止法のトラベルルールに基づき、送り先の情報の登録が求められる。EUでは、暗号資産市場規則（MiCA）第76条3項が、保有者と取引履歴を特定できない限り、匿名化機能を内蔵した暗号資産の取引を取引プラットフォームの運営規則で認めないよう求めている。マネーロンダリング防止規則（AMLR）第79条1項は、暗号資産サービス事業者などが匿名性を高める暗号資産を含む匿名の口座を持つことを禁じ、2027年7月10日から適用される。こうした規制のもとで、Moneroを手に入れる経路と手放す経路の記録は、ウォレットの選び方とは関係なく残る。詳しくはMoneroの入手方法にまとめてある。

二つ目は、端末だ。ウォレットファイル、シードのメモ、アプリの取引履歴（Cake Walletには送金先のアドレスを手元に保存する設定がある）は、端末が押収されれば読まれる。追跡を難しくするサービスの運営者が刑事責任を問われた例として、混合機能を持つウォレットSamourai Walletの共同創業者2名が2025年11月に禁錮刑を言い渡された事件がある。ただしこれは送金業の運営をめぐる共謀の事件で（IRS-CIの発表は、犯罪収益と知りながら送金していたとしている）、個人がMoneroを保有したり自分のウォレットを使ったりすることそのものを違法とした例ではない。経緯はチェーン解析の記事で扱っている。

三つ目は、Torや秘匿サービスの限界だ。ノードの運営者からIPアドレスを隠しても、運営者は取引そのものを見る。同じ接続で複数の取引を送れば同じ送り主だと推定されうることは、Moneroの匿名ネットワークの文書自身が書いている。送金の時刻と、ほかの場所での行動の時刻が一致すれば、台帳とは別の経路で結びつけられる余地も残る。

四つ目は、ソフトウェアそのものだ。Moneroの公式ブログは2021年9月と2023年6月に、公式ウォレットのおとりの選び方にバグがあり、プライバシーに影響していたことを事後報告している。2021年の報告では、v0.14.1.0からv0.17.2.2までの版で、取引量が多い状態が続くと本物の出力を明かす取引が作られうる不具合があり、v0.17.2.3で修正された。2023年の報告では、v0.13.0.2からv0.18.2.1までの版で、ちょうど10ブロック前の出力がおとりに選ばれない不具合があり、v0.18.2.2で修正された。ウォレットを最新に保つことは必要だが、それでも未知のバグが残る可能性はなくならない。偽のウォレットや改ざんされた配布物も、署名の確認を省けば防げない。

Moneroを使えば追跡されない、とは言えない。台帳の設計が隠すものと、ノード・端末・入出金経路が漏らすものは、別々に評価する必要がある。

まとめ#

読者の立場によって、今日やる一つの確認は違う。

少額をスマートフォンで持っている初心者は、使っているウォレットの設定画面を開き、いまどのノードに接続しているかを確かめる。既定のノードのままなら、その運営者が誰で、Torがオンかオフかを把握するだけでも、自分の取引とIPアドレスを誰が結びつけうるかが分かる。

デスクトップで日常的に送金する人は、公式ドキュメントの比較表のどの行に自分がいるかを確かめる。リモートノードにSSL/TLSなしで接続していれば最も弱い行にいる。秘匿サービスとしての接続か、自分のノードと--tx-proxyの組み合わせに移せるかを検討する。

開発者や、ノードを自分で立てられる人は、剪定ノードで約105GiB（2026年10月時点）のディスクを用意できるかを確かめる。立てるなら、--tx-proxyまで設定しないと既定のままではISPに対して取引の発信元が見えうることを前提にする。

ハードウェアウォレットを持っている人は、自分の機種がgetmonero.orgの一覧と使うウォレットの文書の両方に載っているかを確かめ、シードの控えとは別に、配布物の署名を確かめる手順を一度通しておく。FCMP++ のフォークが近づいたときに、偽の「アップグレード版」を見分けるためだ。

暗号資産のプライバシーの記事全体の地図は暗号資産の金融プライバシー完全ガイドにある。

出典#

すべて2026-11-08に参照。