ライトニングノードとは？LND・Core Lightningの違いと安全な始め方

本記事にはアフィリエイト広告（PR）を含む場合があります。

※本記事にはアフィリエイト広告（A8.net）を含みます。内容は2026年8月17日にLND、Core Lightning、Bitcoin Coreの公式資料で確認しています。本記事は技術上の一般情報であり、ノード収益や資金回収を保証しません。

ライトニングノードは、ビットコインをチャネルにロックし、オフチェーン決済を送受信・中継するソフトウェアです。自分で運用すれば送受信の制御やプライバシーを改善できますが、サーバーを立てるだけで利益が出る仕組みではありません。

特に重要なのはバックアップです。オンチェーンウォレットのseedだけでは、進行中のチャネル状態をそのまま復元できません。この記事ではLNDとCore Lightning（CLN）の違い、Bitcoin backend、テスト手順、API保護、復旧設計、流動性と費用を順に整理します。

Bitcoin Coreの容量とVPS選びは、先にフルノードの必要容量・VPS比較で確認できます。P2P接続の基礎はビットコインP2Pネットワークの仕組みで説明しています。

ライトニングノードで何ができるのか

ライトニングネットワークでは、2者がオンチェーン取引でチャネルを作り、その後の残高更新を双方で署名します。支払いは複数ノードを経由でき、中継ノードはポリシーに応じた手数料を設定できます。

ノード運用の目的は、少なくとも次の3つに分けます。

• 自分の支払い・受取：自分で鍵とチャネルを管理し、外部カストディへの依存を減らす
• アプリ開発：invoice、payment、APIを使うサービスをregtestやsignetで検証する
• ルーティング：複数チャネルの流動性を置き、他者の支払いを中継する

目的で必要な資金、接続数、可用性、バックアップが変わります。自分の少額支払いを試すだけなら、大規模な公開ルーティングノードは不要です。

LNDとCore Lightningの違い

LNDはLightning Labs、Core LightningはBlockstreamを中心に開発されるオープンソース実装です。どちらもLightningの共通仕様を実装しますが、Bitcoin backend、API、拡張、バックアップ形式は同じではありません。

項目	LND	Core Lightning
Bitcoin backend	Bitcoin Core、btcd、Neutrinoに対応。公式は性能面から同一機器・同一ネットワークのfull backendを推奨	公式入門は同期済みbitcoindを前提に説明
主な管理API	gRPC・REST。macaroonで権限を管理	Unix Domain Socket上のJSON-RPC。遠隔利用は保護されたREST・gRPC等を選ぶ
拡張	Lightning Terminal、Loop、Poolなど	プラグイン構造とJSON-RPC API
root secret	aezeedなど。オンチェーン鍵とノード鍵を復元	現行の新規ノードはmnemonic、旧版はcodex32/hexなど版で形式が異なる
静的チャネル復旧	channel.backupのStatic Channel Backup	emergency.recover

「人気」「速い」「稼げる」という印象で選ばず、使うウォレットやアプリの対応、保守できるAPI、バックアップを自分で復旧試験できるかで選びます。LNDのバックアップをCLNへ、または逆方向へそのまま使うことはできません。

最初はregtestとsignetで試す

mainnetでチャネルを開く前に、資金を失わない環境で運用手順を通します。

1. ローカルregtest：複数ノード、チャネル開設、支払い、協調close、force-close、再起動を自分のPC内で試す
2. signet：外部ピアとの接続、数日間の稼働、監視、バックアップ退避、障害復旧をテスト用コインで確認する
3. 少額mainnet：失っても生活に影響しない金額で、1チャネルから始める
4. 復旧後に拡大：バックアップから資金を戻す流れを確認してから、チャネル数と金額を増やす

Core Lightning公式はローカルregtest用のstartup_regtest.shを案内しています。LNDもregtest・simnet・signetを利用できます。第三者のワンクリック配布物を使う場合も、その配布者がseed、チャネルDB、アップデートをどう扱うかを確認してください。

Bitcoin backendを先に決める

LNDの場合

LND公式Get Startedは、LND単体の最小目安として2GB RAM、1GHz quad core、5GB storage、品質のよいSSDを挙げています。ただし、Bitcoin Coreを同じ機器で動かすなら、そのCPU、メモリ、約600GBの初回取得、保存容量も加わります。

LNDはpruned Bitcoin Coreを利用できますが、公式は過度なpruningが性能へ影響し得ると説明しています。ZMQまたはRPC polling、RPC認証、backendの配置も設計が必要です。インターネットへBitcoin RPCを直接公開しません。

Core Lightningの場合

Core Lightning公式入門は、mainnetで同期済みbitcoindを起動してからlightningdを動かす流れを示しています。pruned nodeは慎重に管理しないと問題が起き得るとも注意しています。

CLNはbitcoin-cli経由でbitcoindへアクセスします。別ホストへ分離する場合はRPC接続と認証情報の保護が必要です。まず同じホストまたは閉じたネットワークで構成を理解します。

ローカル機とVPSの選び方

場所	利点	注意点
ローカルPC	regtestが簡単、追加契約不要、APIを外へ出さずに試せる	スリープ、家庭回線、停電、端末故障
自宅専用機	秘密情報をクラウド事業者から分離、常時稼働しやすい	電気代、SSD故障、ルーター設定、物理バックアップ
VPS	固定環境、遠隔管理、常時接続、公開ノード向き	毎月費用、root管理、事業者依存、認証情報流出、容量

LND単体の最小2GB RAMを、そのままBitcoin Core込みのVPS推奨値にしないでください。初回同期、mempool、チャネルDB、監視ツールを同居させれば余裕が必要です。pruningの可否もLNDとCLNで同じ判断ではありません。

現在価格と円換算は ビットコイン円換算ツール で確認できます（BTC・ETH・XRP対応）。

必要書類がそろっているかは 口座開設の準備チェック で確認できます。

金額別に買える数量は ビットコインはいくらから買える？ で確認できます（500円・1,000円・1万円ぶんの数量を表示）。

購入までの流れは ビットコインの買い方4手順 にまとめています（必要書類の判定ツール付き）。

毎月いくらから積み立てられるかは 積立は毎月いくらから？ で計算できます（年率0%・-20%の場合も併記）。

必要なサーバースペックは Botサーバーの必要スペック診断 で確認できます。

自宅PCとVPSのコスト差は Botは自宅PCとVPSどちらが安い？ で計算できます。

XServer VPSの現行SSD容量とBitcoin Coreの必要量はフルノードのVPS比較表に整理しています。XServer VPS公式仕様の4GB/150GBや8GB/400GBはBitcoin Coreの全履歴保存には足りません。pruned backendでも初回全量取得と復旧時の再同期は必要です。

バックアップはseedだけでは足りない

ライトニングでは、両者が更新する最新チャネル状態が重要です。古い状態を復元・公開すると、プロトコル上のペナルティにより資金を失う可能性があります。一般的なファイルの定期コピーと同じ感覚で、稼働中のDBを復元しないでください。

LNDの復旧資料

LND公式は、次を別々に扱っています。

• aezeed：オンチェーン鍵とノード鍵のroot。これだけで稼働中チャネルを元の状態へ戻すものではない
• Static Channel Backup：channel.backup。ピアへ災害を通知し、最新commitmentのforce-closeを依頼するための情報
• 最新channel database：有用だが、クラッシュしたノードから回収した最新状態以外を安易に使うと危険

LND公式Disaster recoveryは、SCBによる復旧で全チャネルが閉じられ、資金がオンチェーンへ戻る時期も一定ではないと説明しています。SCBは「チャネルを開いたまま再開するバックアップ」ではありません。

SCBは新しいチャネルが開くたび更新されるため、別の機器へ自動退避します。seedとSCBを同じVPSだけに置けば、VPS喪失時に両方失います。同じseedで2台のLNDを同時に動かしてはいけません。

Core Lightningの復旧資料

CLN公式は次の3要素を分けています。

• root secret：現行の新規版ではmnemonic、旧版はcodex32/hexなど。オンチェーン資金には必須だがチャネル資金には不十分
• emergency.recover：チャネルごとに更新される静的復旧情報。ピアの協力を必要とする最後の手段
• database：稼働中チャネルの詳細状態。古いsnapshot復元は永久的な資金喪失につながり得る

Core Lightning公式Backupは、snapshot方式のDBバックアップを非推奨とし、リアルタイムDB replicationを推奨しています。root secretをバックアップ先へ含めれば、そのコピーを盗んだ人が資金を盗めるため、暗号化とアクセス分離が必要です。

復旧コマンドはノードの版、DB backend、残っているファイルで変わります。検索結果のコマンドをそのまま実行せず、旧ノードを停止したまま、利用中の版と一致する公式手順を確認します。

watchtowerはバックアップの代わりではない

watchtowerは、自分のノードがオフラインの間に相手が古いcommitmentを公開した場合を監視し、違反への対応を助ける仕組みです。LND公式は、自分と別の機器・ネットワーク・場所にあるwatchtowerを使う考え方を示しています。

しかし、watchtowerはseed、SCB、root secret、emergency recovery、最新DBを復元しません。自分のノード障害、ディスク消失、資格情報漏洩、ピア不在をすべて解決するものでもありません。バックアップ、監視、watchtowerは別々の対策として設計します。

APIと認証情報を公開しない

LNDのmacaroon

LNDのmacaroonはAPI権限を持つbearer credentialです。admin.macaroonは全権限を持つため、Webアプリ、チャット、Git、バックアップログへ渡しません。

外部アプリには必要なRPCだけを許すcustom macaroonを作り、IPや権限を制限します。macaroonファイルを削除するだけでは発行済み資格情報を無効化できない場合があるため、漏洩時は公式のroot key失効手順を使います。

Core LightningのRPC

CLNの基本JSON-RPCはUnix Domain Socketです。同一ホストのファイル権限で守り、ソケットをWeb公開しません。遠隔アプリは公式が案内する保護されたREST、gRPC、WSSなどを使い、TLSとクライアント認証、最小権限を設計します。

SSH、LND gRPC/REST、CLN API、Bitcoin RPCを全世界へ開ける構成は避けます。P2Pの公開ポートと管理APIは別です。

チャネル開設前に理解する流動性

チャネル残高には方向があります。

• local balance / outbound capacity：自分から送れる側の残高
• remote balance / inbound capacity：自分が受け取れる側の余地

自分が資金を出してチャネルを開くだけでは、通常はoutbound側から始まります。受取や双方向ルーティングにはinbound capacityも必要です。支払い、相手からのチャネル、スワップ、リバランスなどで方向を変えられますが、それぞれ手数料、相手方リスク、オンチェーン取引が伴います。

「接続数が多い有名ノードへ開けば儲かる」とは限りません。支払い需要のある経路、両方向の流動性、相手の稼働、fee policyが合わなければ転送は発生しません。

ルーティング収益は費用控除後で見る

ルーティング手数料の売上だけで判断せず、少なくとも次を差し引きます。

• チャネル開設・協調close・force-closeのオンチェーン手数料
• リバランスやswapの手数料
• VPS、ストレージ、監視、バックアップの費用
• チャネルに置いたBTCを他用途へ使えない資本コスト
• 障害対応と流動性管理に使う時間

LND公式のfee資料も、高すぎれば経路に選ばれず、低すぎれば流動性が一方向へ失われ、収益性を損ね得ると説明しています。固定の最適手数料率はありません。

最初の目標は利益ではなく、支払い成功率、停止検知、バックアップ更新、協調closeとforce-closeの理解です。少額で費用台帳を作り、数か月の実測がない段階で高額チャネルへ増やしません。

稼働後に確認する項目

実装ごとのCLIで、状態を定期確認します。

確認項目	LNDの例	Core Lightningの例
ノード同期・接続	lncli getinfo	lightning-cli getinfo
資金とチャネル	lncli walletbalance / listchannels	lightning-cli listfunds / listpeerchannels
保留中close	lncli pendingchannels	チャネル状態とオンチェーン取引を個別確認
fee・転送	lncli feereport / forwarding history	fee policyとforwarding履歴を確認

出力にはnode ID、channel point、IP、残高、取引情報が含まれる場合があります。質問サイトやSNSへJSON全体を貼らず、必要な行だけ伏せ字にします。CLI名称やfieldは版で変わるため、利用中の公式API referenceを参照してください。

mainnetへ進む前のチェックリスト

• regtestでopen、payment、cooperative close、force-closeを実行した
• signetで再起動、数日停止、更新、監視通知を試した
• root secretと静的チャネル復旧情報を別機器へ退避した
• バックアップが新チャネル作成時に更新されることを確認した
• 古いDB snapshotを復元しない理由を説明できる
• LND macaroonまたはCLN RPCを最小権限で保護した
• Bitcoin RPCとLightning管理APIを公開していない
• 受取に必要なinbound capacityを理解した
• 開設・close・rebalancing・VPS費用を記録する台帳がある
• 失っても生活に影響しない初回金額を決めた

一つでも確認できなければ、mainnetへ進まずregtest・signetで手順をやり直します。

まとめ

LNDとCore Lightningは、Bitcoin backend、API、認証、拡張、バックアップ形式が異なります。どちらを選んでも、root secretだけでは稼働中チャネルを元の状態へ戻せません。LNDのSCBとCLNのemergency recoveryは、ピアと協調してチャネルを閉じ、オンチェーンへ資金を戻す最後の手段です。

ローカルregtest、signet、少額mainnetの順に、停止と復旧を実際に確認してください。VPSは常時稼働に便利ですが、秘密鍵、管理API、チャネルDBを守る責任は運用者にあります。ルーティング手数料は売上であり、オンチェーン費用、流動性調整、VPS代、時間を差し引いた利益ではありません。

よくある質問

ライトニングノードを動かすと必ず手数料収入がありますか？

ありません。経路として選ばれ、実際に支払いを中継した場合だけ設定した手数料が発生します。チャネル開設、close、リバランス、VPSの費用を上回る保証はありません。

LNDのseedだけでチャネル資金を復元できますか？

seedだけで稼働中チャネルを元の状態へ戻すことはできません。LNDはaezeedと最新のStatic Channel Backupを併用し、ピアへforce-closeを依頼する災害復旧を案内しています。復旧するとチャネルは閉じられます。

Core Lightningのhsm_secretだけで十分ですか？

オンチェーン資金のrootには必要ですが、チャネル内資金には不十分です。ノード版に合うroot secret形式、最新のemergency.recover、または正しく同期された最新DBの復旧設計が必要です。古いDB snapshotは使わないでください。

最初からVPSのmainnetで始めてもよいですか？

勧めません。ローカルregtestとsignetでバックアップ、再起動、force-close、API保護を確認し、mainnetは失っても影響のない少額から始めます。VPS契約は常時稼働が必要になってから比較できます。

この記事について

執筆・編集：Bitcoin Analyze 編集部

金融庁・国税庁および各事業者の公式資料にあたり、基準日と定義を固定したうえで記事を作成しています。価格予測や利益保証は扱いません。事業者の条件は変更されるため、最終的な判断は公式情報をご確認ください。

主な参照先

• 金融庁「暗号資産（仮想通貨）関係」

編集方針と広告開示/免責事項/訂正のご連絡