2026年版 Monero フルノード運用ガイド:セルフホスティング完全マニュアル

リモートノードに接続する Monero ウォレットを開くたびに、あなたは見知らぬ第三者に対して暗黙のうちに三つの問いを投げかけています。「このブロックチェーンの状態は正確か?」「私の IP アドレスを秘密にしてくれるか?」「必要なときにオンラインでいてくれるか?」というものです。2026 年になっても、驚くほど多くのユーザーが GUI ウォレットのデフォルトで提供されるノードをそのまま信頼しています。しかし Monero のブロックチェーンは 2025 年末から 2026 年初頭にかけて約 200 GB を超え、最新のデスクトップ機なら週末のうちに同期を完了できる規模です。自前の monerod インスタンスを動かすことは、鍵管理の習得に次いで、Monero ユーザーが取れる最大のプライバシー向上策です。本ガイドではハードウェア選定、Linux・macOS・Windows それぞれでの monerod のインストール、初期同期を乗り切る方法、RPC インターフェースの堅牢化、そして余裕があればパブリックリレーとしてノードを公開する手順までを順を追って解説します。これにより、MoneroSwapper でコインをスワップするウォレットも、中央集権型ではなくコミュニティ運営のサーバーに依拠できるようになります。

2026 年に自前の Monero ノードを動かす意義

Monero ウォレットがノードに求めるものは三つだけです。現在のブロック高、受信トランザクションを検知するためのブロックスキャン、そして送信トランザクションのブロードキャストです。リモートノードを使うと、これら三つすべてでメタデータが漏れます。ノード運営者はどの IP がどのブロックを要求したかを見て、あなたが Monero ユーザーであることを知り、トランザクションのブロードキャストと送信元 IP を結びつけることができます。Monero のプロトコルレベルのプライバシー(リング署名、ステルスアドレス、RingCT、Bulletproofs、Dandelion++)はオンチェーンデータの秘匿には優れていますが、あなたが問い合わせるノードソフトウェアとの関係までは隠せません。

• ネットワーク層のプライバシー:セルフホスト型ノードならウォレットは localhost と通信します。スキャンパターン、復元高、アドレスの購読情報はあなたのマシンの外に出ません。
• 検閲耐性:リモートノードはあなたのトランザクションのリレーを拒否したり、古いチェーンデータを返したりすることがあります。自前の monerod は嘘をつきません。
• トラストレスな検証:受け取ったコインが本当に正規チェーン上に存在し、改竄されたリモートが捏造したものでないことを独立に検証できるのは、自分が制御するノードだけです。
• レジリエンス:パブリックリモートノードは落ちたり、ポートが変わったり、クライアントをレートリミットしたりします。自前の monerod はあなたのマシンが動いている限りオンラインです。
• 貢献:すべてのフルノードは Monero の P2P メッシュを強化します。自分のウォレットだけにサービスを提供するノードであっても、パブリックノードを運営するボランティアの負荷を減らすことに繋がります。

要するに、リモートノードは利便性の問題を解決する代わりにメタデータの問題を生みます。monerod を自分で動かせばその両方が解決でき、2026 年現在、必要なハードウェアはハードウェアウォレット 1 台よりも安く揃います。

Monero フルノードのハードウェア要件

Monero は他のレイヤー 1 ノードと比べて、ハードウェアに対する要求が異例なほど緩やかです。ブロックチェーンは大きいですが巨大ではなく、同期は CPU バウンドではなく主に I/O バウンドで、デーモンは 0.18.x シリーズを通じて継続的に最適化されてきました。下表に、本当に必要な要件と快適さを得るための推奨スペックをまとめます。

SSD ストレージは最大の加速要因です。Monero の LMDB データベースは同期中に数百万回のランダム読み出しを行い、HDD では SSD なら 1 日で済む同期が 1 週間に伸びることもあります。500 GB のコンシューマー向け SSD(Samsung 870 EVO、Crucial MX500、WD Blue)で十分以上で、現在はスワップ 1 回の失敗手数料より安く買えます。外付け SSD を付けた Raspberry Pi 4 でも動きますが、同期には 4〜7 日かかると見ておくべきです。

Cuprate はどうか

2026 年は、monerod の Rust 実装である Cuprate が使用可能なプレリリース段階に到達した年です。まだドロップイン置換にはなっておらず、ほとんどのユーザーは getmonero.org で配布されている C++ 版 monerod を使い続けるべきです。Cuprate は実装多様性(独立した第二の実装はプロトコルレベルの単一栽培リスクを下げる)の観点で重要で、ウォッチする価値はありますが、本ガイドはリファレンスかつ監査済みの本番デーモンである monerod に焦点を当てます。

monerod のインストール手順

どのプラットフォームを選ぼうとも手順は同じです。公式アーカイブをダウンロードし、binaryFate の有名な GPG 鍵で署名されたハッシュファイルに対して署名を検証し、展開し、設定ファイルを書き、起動し、同期を見守るというものです。無作為な GitHub フォーク、ミラー、あるいは「簡単インストーラー」と称するウェブサイトのバイナリは決して使わないでください。正規ソースは getmonero.org/downloads のみです。

1. 公式バイナリのダウンロード:自分のプラットフォーム向けのバイナリを getmonero.org/downloads から取得します。Linux x64 のスタティックビルド、macOS のユニバーサルビルド、または Windows 64-bit のインストーラー/zip を選んでください。同じページから hashes.txt もダウンロードします。
2. GPG 署名の検証:hashes.txt は binaryFate の鍵で署名されています(フィンガープリントは Monero 公式サイトおよび KeyOxide に公開)。鍵をインポートし、gpg --verify hashes.txt を実行して "Good signature" 行を確認します。続いて shasum -a 256(macOS/Linux)または certutil -hashfile(Windows)でアーカイブのハッシュを取り、hashes.txt の該当行と比較します。一致しなければ即座に中止してください。改竄されたファイルです。
3. アーカイブの展開:恒久的な場所に展開します。例えば Linux なら /opt/monero、macOS なら /Applications/monero、Windows なら C:\Monero。フォルダ内には monerod、monero-wallet-cli、その他のツールが単なるバイナリとして入っています。インストーラーがシステムファイルに触れることはありません。
4. データディレクトリの作成:バイナリとは別の場所、たとえば Linux/macOS なら ~/.bitmonero(デフォルト)、Windows なら D:\monero-data を用意します。ブロックチェーンのデータベースはここに格納されます。
5. monerod.conf の作成:データディレクトリに置きます。最小限の妥当な設定例:data-dir=/var/lib/monero、log-file=/var/log/monero/monerod.log、log-level=0、no-igd=1、hide-my-port=1、rpc-bind-ip=127.0.0.1、rpc-bind-port=18081、restricted-rpc=1、confirm-external-bind=0。RPC 制限の詳細は後述します。
6. monerod の初回起動:Linux では ./monerod --config-file ~/.bitmonero/monerod.conf --detach。macOS でも Terminal から同じコマンド。Windows では Command Prompt から monerod.exe を起動するか、NSSM でサービスとしてラップします。
7. サービスとして登録:再起動後も自動で立ち上がるようにします。Linux では /etc/systemd/system/monerod.service に systemd ユニットを作成し、ExecStart=/opt/monero/monerod --config-file /etc/monerod.conf --non-interactive を記述、その後 systemctl enable --now monerod。macOS では ~/Library/LaunchAgents/ に launchd plist を配置。Windows では NSSM(nssm install monerod)を使います。
8. 同期の監視:別シェルから ./monerod status で接続するか、curl で http://127.0.0.1:18081/get_info に問い合わせます。target_height と height が一致し、synchronized が true に変わるのを待ちます。
9. RPC ポートの保護確認:Linux なら ss -tlnp | grep 18081、Windows なら netstat -an | findstr 18081 で、デーモンが 127.0.0.1 にバインドされており、0.0.0.0 にバインドされていないことを確認します。認証なしで 0.0.0.0 にバインドされている場合、意図せずオープンノードを公開してしまっています。直ちに設定を修正してください。
10. ウォレットを 127.0.0.1:18081 に接続:新規ウォレットがブロックをスキャンできることを確認します。これが動けばローカルノードのセットアップは完了です。

制限なしの RPC ポート(デフォルト 18081)を公開 IP にバインドしては絶対にいけません。--restricted-rpc フラグが存在するのには理由があります。フル RPC には悪用可能なメソッド(トランザクションの探査、メンプール詳細の問い合わせ、ウォレットの強制再スキャン)が含まれています。パブリックノードでは --rpc-restricted-bind-port=18089 --rpc-bind-ip=127.0.0.1 を使い、インターネットに公開するのは 18089 だけにしてください。

初期ブロックチェーン同期で何が起きるか

初期ブロックダウンロード(IBD)はノード運用のなかで最も時間がかかり、最も壊れやすい段階です。SSD と 100 Mbps 回線を備えた最新のデスクトップなら 12〜36 時間、USB-3 SSD を付けた Pi 4 なら 4〜7 日、HDD ならどこかで諦めて SSD を買いに行くことになります。

プロセスはフェーズに分かれます。まず monerod がシードノードに接続してピアリストを学習します。次にブロックをバッチでダウンロードし、LMDB に書き込みつつリング署名、RingCT 証明、Bulletproofs を検証していきます。新しいブロック(Bulletproofs+ を含む重い検証)では CPU がスパイクしますが、古いレガシーブロックの書き込み中はほとんどアイドルです。

同期時によくある問題と対処法:

• 特定の高さで同期が止まる:多くは LMDB 内のブロック破損です。monerod を停止し、monerod --reorg-notify を実行するか、単純に lmdb/ フォルダを削除して再起動します。最初から再ダウンロードになりますが、最もクリーンな対処です。
• 「Failed to verify block」エラー:ほぼ確実にディスクの問題です。SSD の SMART ステータスを確認してください。安価な USB エンクロージャは書き込みを静かに落とすことがあります。
• ピア探索が非常に遅い:コミュニティのピアリストから --add-peer node.moneroworld.com:18080 のように明示的なピアを追加します。
• 同期終盤のメモリ使用量が高い:デフォルトの fast-async ではなく db-sync-mode=safe:sync を設定します。多少速度を犠牲にメモリプロファイルが平坦になります。
• 同期中にウォレットが誤った残高を表示する:ノードがまだ追いついていません。get_info で synchronized: true になるまで残高を信用しないでください。

2026 年に特に重要な注意点として、テストネットでの FCMP++ 展開前活動と進行中のプロトコル研究により、0.18.x シリーズのポイントリリースは例年より頻繁になると見込まれます。月次でアップデートを確認するカレンダーリマインダーを設定し、リリースノートを必ず読んでください。一部のアップグレードにはネットワークのハードフォーク前に全ノードがアップデートしなければならないコンセンサスレベルの変更が含まれます。

プルーニング済みノード vs フルノード:トレードオフ

monerod は二つのモードをサポートします。フルノードはブロックチェーン全体をディスク上に保持し、プルーニング済みノードは約 3 分の 2 のデータ(具体的にはある一定の深さより古いリング署名データの大半で、新ブロックの検証にはもう不要なもの)を破棄します。

プルーニング済みノードは約 200 GB ではなく約 60 GB を使い、同期も速く、ウォレットに対する RPC は同じものを提供します。代償は、プルーニング済みノードは他のピアに古いトランザクションデータを提供できないことです。ネットワーク内に十分な数のフルノードが存在することに依存します。プライバシーと検証の観点では、ウォレット運用者にとってプルーニング済みノードはフルノードと同等です。ネットワーク健全性の観点では、フルノードのほうが寛大な貢献です。

プルーニングを有効にするには、初回同期の前に monerod.conf に prune-blockchain=1 を追加します。既存のフル DB を再同期なしでクリーンにプルーニングすることはできません。ディスクに余裕があればフルノードを動かしてください。プルーニング済みノードを動かす他の人々の追いつきを助けられます。ディスクがタイト(Raspberry Pi、小型 VPS)ならプルーニングを選びます。どちらでもあなたのウォレットのプライバシーは同等に保たれます。

ウォレットを自前ノードに接続する

デーモンが synchronized: true を報告したら、ウォレットを接続します。公式 Monero GUI では:設定 → ノード → 「ローカルノード」を選ぶか、リモートデーモンアドレスとして 127.0.0.1:18081 を空の認証情報で貼り付けます。Feather Wallet では:設定 → Node → 「Custom」 → 127.0.0.1:18081。monero-wallet-cli では --daemon-address 127.0.0.1:18081 付きで起動します。

Cake や Monerujo のようなモバイルウォレットには二つの選択肢があります。家庭サーバーで monerod を動かし、Tailscale/WireGuard 経由でスマートフォンから接続する(推奨)、または別ポートの制限付き RPC を Tor の Hidden Service として公開するかです。Tor 経由ならプライバシーは保たれ(クリアネットを経由せず .onion 経由で自前ノードに到達)、ただしセットアップは少し増えます。具体的な tor-service ユニットや HiddenServiceDir の行については Monero のドキュメントを参照してください。

MoneroSwapper でコインをスワップする場合、同じセルフホスト型ノードが入金 XMR の検証層として機能します。スワップ完了後、ローカルの monerod が第三者ノードに資金の実在を尋ねることなく独立に入金を確認します。これこそが要点であり、エンドツーエンドで自前のインフラを信頼するということです。

よくある落とし穴とセキュリティ強化

多くのノード運営者がトラブルに陥るパターンは三つに集約されます。保護されていない RPC を公開してしまう、古いソフトウェアを動かし続ける、怪しい「簡単ノード」Docker イメージを信頼する、です。順に見ていきましょう。

RPC のオープン公開は最悪のミス

rpc-bind-ip=0.0.0.0 を設定しながら restricted-rpc=1 と --rpc-restricted-bind-port を指定していなければ、管理用 RPC メソッドにアクセスできる認証なしのパブリックデーモンを稼働させていることになります。インターネット上の誰もがそれをスキャンし、メンプールを問い合わせ、サーバーを DoS する高負荷操作を強制できます。公開ポートでは必ず制限付き RPC を使用し、非制限 RPC は 127.0.0.1 のみにバインドしてください。

古いデーモンはネットワークから締め出される

Monero は 6〜12 ヶ月ごとにハードフォークし、古い monerod はアップグレード高以降にネットワークから強制切断されます。Monero のリリース通知を購読し、/r/Monero をウォッチし、次のフォーク前にアップデートしてください。0.18.x シリーズは典型的に年 2〜4 回のポイントリリースがあります。git pull またはバイナリ差し替え、サービス再起動、で完了です。

サードパーティ製ノードイメージを避ける

「ワンクリックで Monero を動かす」Docker イメージや非公式インストーラーは、悪意のあるパッチの常習的なベクターです。パッチはしばしば巧妙で、ログエンドポイントへ IP を漏らす改変版 `monerod` や、漏洩した鍵で署名するウォレットなどがあります。バイナリは getmonero.org または Monero の GitHub リリースページのもの(いずれも binaryFate の署名付き)のみを使用してください。

ファイルシステムとバックアップ

LMDB データベースは自己修復型でバックアップ不要です。いつでも再同期できます。バックアップが必要なのは monerod.conf と、ノードと一緒に保管しているウォレットファイルです。ウォレットファイル(.keys)はサイズが小さく、保存時は暗号化すべきです。

パブリックノードとして公開する:コミュニティへの貢献

帯域が無制限で、安定した家庭サーバーや VPS を持っているなら、ノードを Monero エコシステム全体に開放することを検討してください。パブリックノードはコミュニティのディレクトリ(monero.fail、xmrnodes)に掲載され、自前の monerod を運用しないウォレットに使われます。ボランティアがいなければ、それらのウォレットにはプライバシーを尊重する選択肢がそもそも存在しなくなってしまいます。

パブリックホスティングの手順:

• ファイアウォールとルーターでポート 18080(P2P)を開放し、受信接続を受け付けます。これは認証なしのピアツーピアトラフィックで、公開しても安全です。
• 制限付き RPC を別ポートでパブリックインターフェースにバインドします:rpc-restricted-bind-ip=0.0.0.0、rpc-restricted-bind-port=18089、加えて public-node=1。
• 非制限ポートには rpc-bind-ip=127.0.0.1 を維持し、18081 を公開しないでください。
• 制限付きポートが使用中であることを確認した後にのみ confirm-external-bind=1 を設定します。
• tor を動かし、127.0.0.1:18089 を指す HiddenService スタンザを追加することで .onion アドレスを公開することも可能です。
• monero.fail の GitHub リポジトリにプルリクエストを送って自ノードを掲載するか、xmrnodes に自分で登録します。

控えめなパブリックノードでも 1 日に数十〜数百のウォレットクライアントにサービスを提供できます。多くの運営者は定常状態の帯域が 1 Mbps 未満と報告しており、まともな家庭回線なら十分収まる範囲です。

よくある質問

本当にフルノードが必要ですか、それともリモートノードで十分ですか?

少額を時々使う程度ならリモートノードでも実用的です。Monero のプロトコルは依然としてオンチェーンのプライバシーを保護します。しかしプライバシーが重要な用途、事業用の保有、または高額スワップを繰り返す場合、自前ノード以外に、信頼するリモートに対して IP とトランザクションの相関を漏らさない手段はありません。2026 年時点のハードウェア障壁はわずかなものです。

2026 年現在、初期同期にはどれくらいかかりますか?

SSD と 100 Mbps 回線を備えたデスクトップで 12〜36 時間。USB-3 SSD 付きの Raspberry Pi 4 で 4〜7 日。HDD では数日から数週間。最大の変数は CPU や帯域ではなくディスク I/O です。

自前ノードが同期している間、一時的にリモートノードを使えますか?

はい。多くのウォレットはノードをオンザフライで切り替えられます。待っている間は Tor の Hidden Service 経由のリモート(xmrnodes.org の .onion アドレスを探してください)を使い、ローカルの monerod が追いついたら 127.0.0.1 に切り替えます。

プルーニング済みノードはフルノードよりプライバシーが低いですか?

いいえ。プルーニングは他のピアに古いブロックを提供するために必要なデータを削るだけです。ウォレット側から見れば、プルーニング済みノードもフルノードと同じプライバシー特性で新しいトランザクションを検証し、送信をブロードキャストします。

どのポートを開ける必要がありますか?

ウォレット専用ノードなら受信ポートは不要です。送信用に 18080(P2P)があれば十分です。パブリックノードならファイアウォールとルーターで受信 18080(P2P)と受信 18089(制限付き RPC)を開きます。18081(非制限 RPC)は決してインターネットに公開しないでください。

ノードを動かすと ISP に対して匿名性が損なわれますか?

ISP はあなたが他の Monero ノードとポート 18080 で通信していることを見られます。それすら隠したい場合は --tx-proxy tor,127.0.0.1:9050 と --anonymous-inbound を付けて monerod を Tor 経由で動かしてください。パフォーマンスは若干落ちますが、ネットワーク層のプライバシーは大幅に強化されます。

日本の規制との関係はどうですか?

日本では金融庁(FSA)が暗号資産関連事業者を監督し、日本暗号資産取引業協会(JVCEA)が業界自主規制を担っています。Monero(モネロ)を含む匿名性の高い暗号資産は国内取引所での取り扱いが認められていませんが、自分自身で monerod を動かすこと自体は規制対象ではなく、技術的・教育的な活動として位置づけられます。税務面では国税庁の指針により暗号資産の売買差益や交換取引は雑所得として申告対象になります。スワップ取引を行った場合はその時点での日本円換算額を記録し、確定申告に備えてください。フルノード運用は単なるソフトウェアの稼働であり、日本銀行が監督する資金移動や為替取引には該当しません。

自前ノードは MoneroSwapper のようなサービスとどう組み合わせますか?

MoneroSwapper のような非カストディアル型スワップアグリゲーターを使うと、スワッププロバイダはあなたが支配するアドレスに XMR を送信します。セルフホスト型ノードはチェーン状態について第三者を信頼することなく、入金を独立に確認します。非カストディアル型スワップとセルフホスト型ノードを組み合わせることで、単一のワークフローから二つの主要な信頼前提が排除されます。完全な流れについては当ブログの匿名スワップガイドを参照してください。

FCMP++ でノードが壊れる心配は?

ありません。FCMP++ の展開は将来の Monero ハードフォークで予定されたブロック高で行われます。その高さの前に monerod をアップデートしておけば(通常 2〜3 ヶ月の事前通知期間があります)、新ルールは自動的に有効化されます。アップデートを怠ることだけが破綻の原因になります。

結論

2026 年に Monero フルノードを動かすことは、もはや 2019 年のような週末プロジェクトではありません。Linux でのクリーンインストールは集中して取り組む 1 時間と、バックグラウンドでの 1 日の同期で済みます。Windows や macOS でも体感は似たようなものです。プライバシー上のリターンは恒久的です。そのマシン上で動かすあらゆるウォレットは localhost と通信し、ブロードキャストするあらゆるトランザクションは自前のデーモンが発信し、確認するあらゆる残高は自分が信頼するチェーンに対して独立に検証されます。すでにMonero ハードウェアウォレットをセットアップしているなら、自前ノードの追加はプライバシースタックをエンドツーエンドで自分のものにするための論理的な次の一歩です。MoneroSwapper を介して定期的に他のコインを XMR に交換しているなら、これはプライベートなスワップを完全に主権的なものへと変える欠けたピースです。Monero コミュニティはこうした小さな自助の積み重ねの上に築かれており、わからない用語が出てきたら用語集を引きながら進めるという習慣こそ、すべてのノード運営者が出発点にしたものです。