ビットコインのLightning Networkとは？チャネル・送受信・費用の仕組み

ビットコインは世界中で送れる暗号資産ですが、少額の支払いをするたびにブロックチェーンへ取引を記録すると、混雑時の手数料や承認待ちが負担になることがあります。そこで生まれた仕組みの一つが「Lightning Network（ライトニングネットワーク）」です。

Lightningは、ビットコインを別の銘柄へ変えるためのサービスではありません。BTCの保有者同士が「支払いチャネル」という仕組みを使って、オンチェーンの取引回数を抑えながら支払いをやり取りするネットワークです。この記事では二人が架空のチャネルを開いて支払い、閉じるまでを追い、送れない・受け取れないときに何を区別すべきかを説明します。

先に結論：BTCの台帳を使いながら、支払いをチャネル内で更新する

オンチェーンとは、ビットコインのブロックチェーン本体へ記録される取引です。Lightningでは、二人が協力して管理するチャネルへBTCを割り当て、支払いごとにチャネルの残高配分を更新します。個々の支払いは毎回ブロックチェーンへ直接記録されるわけではありません。チャネルを開くときと閉じるときには、通常オンチェーンの取引が関わります。

たとえば二人が共同で使う封筒にあらかじめお金を入れ、「今はAがいくら、Bがいくら持つ」という記録を書き換えていくイメージです。ただし現金を封筒へ入れるのとは異なり、Lightningではビットコインの取引や暗号技術を使って双方の権利を守る設計がされています。正確な仕組みはLightning Labsのチャネルのライフサイクルに説明があります。

架空の例：10万satを二人のチャネルで管理する

sat（サトシ）はビットコインの小さな単位で、1 BTC＝1億satです。ここでは、アキさんとベニさんの間で10万satのチャネルを開いたと仮定します。初期状態ではアキさん側に10万sat、ベニさん側に0satがあるとします。合計の容量は10万satです。説明を簡単にするため、この数値ではチャネル開設費、予備残高、送金手数料などを省いています。

アキさんがベニさんへ2万satを払うと、チャネルの中の配分はアキさん8万sat、ベニさん2万satになります。続けてアキさんが1万satを払うと7万と3万になります。さらにベニさんがアキさんへ5,000satを戻すと、配分は7万5,000satと2万5,000satです。合計は常に10万satのままで、誰かが同じBTCを新規発行したわけではありません。

この表が意味するのは、支払いのたびに権利の配分が変化するということです。「送るたびにBTCが別チェーンへ移る」「Lightningの残高は新しいトークンへ交換された」という理解は正しくありません。BTCの単位についてはBTCとsatoshiの単位も参考になります。

チャネルを開くとき・閉じるときは何をする？

チャネルを開くには、一方または両方がBTCを割り当てるオンチェーン取引が必要になります。二者が共同で管理する仕組みが作られ、その中の残高配分を何度も更新できます。二人が協力して閉じる場合は、最終残高に応じてBTCを受け取れるようにオンチェーンの取引を作成します。

一方が応答しない場合などには、非協力的な閉鎖、英語でforce closeと呼ぶ方法があります。最新の残高配分を表す取引を使って、相手の協力がなくてもチャネルから資金を取り出せる設計ですが、待機期間や手数料などの制約があり得ます。これは「相手が消えても必ず即座に全額取り戻せる」保証ではありません。

Lightningのチャネルでは古い状態を悪用されないようにする仕組みも重要です。古い残高配分の不正使用を監視・対処する必要があることがあり、チャネルを自分で運営するならソフトウェアのバックアップや監視を理解する必要があります。Lightning Labsのwatchtower資料には、古い状態を公開する不正への対応が示されています。

なぜ送れる残高と受け取れる残高が違う？

チャネルの合計容量が10万satでも、その全額をどちらの方向にも送れるとは限りません。先ほどの最終状態なら、アキさん側に7万5,000sat、ベニさん側に2万5,000satという偏りがあります。アキさんがベニさんに送れる金額は、自分側の残高が上限の目安ですが、実際には手数料・予約残高・チャネル制限なども関係します。

反対に、アキさんがベニさんから受け取れる上限の目安は、相手側が支払える2万5,000satです。これが「インバウンド流動性＝受け取りの余力」「アウトバウンド流動性＝送る余力」という言葉の意味です。残高があるのに送金できない、支払先のインボイスが正しいのに受け取れない、といった場面ではこの方向別の余力が問題になることがあります。

実際のLightningでは単純にこの数字をそのまま手数料なしで全部送れるわけではありません。Lightning Labsの流動性ガイドも、送る方向と受け取る方向を分けて説明しています。

二人が直接つながっていなくても支払える理由

世界中の利用者が互いに一つずつチャネルを開いていたら膨大な数が必要です。Lightningでは、途中のノードを経由して支払いを届ける仕組みがあります。アキ→ベニ→チカという経路があり、アキさんがチカさんへ払いたいなら、間にいるベニさんのチャネルを経由できる場合があります。

ここでも各区間の方向別の余力が大切です。アキからベニへ十分送れても、ベニからチカへ送る余力が足りなければその経路では支払えません。別の経路が見つかれば支払えることもありますが、常に成功する保証はありません。ルーティングには中継ノードへの手数料が生じる場合もあります。

経路の途中にいる人が支払額を横取りできないよう、Lightningには支払いの成立条件を連動させる仕組みがあります。その設計は複雑ですが、初心者が押さえるべきことは「途中の経路が必要」「各区間の流動性が必要」「成立前と成立後は違う」という三点です。Lightning Labs FAQではノードとルートが説明されています。

オンチェーン送金とLightning送金の違い

オンチェーン送金はブロックチェーンへ取引を提出し、ネットワークによる承認を待ちます。Lightningの支払いは開かれたチャネルを通じて状態を更新するため、少額の支払いを短時間で扱える場合があります。ただし「Lightningなら必ず瞬時」「常に手数料0円」という説明は正確ではありません。

チャネルの開設・閉鎖にはオンチェーン費用が発生し得ます。途中のルーティングにも手数料があり、ソフトウェアやサービスが別の料金を設定する場合もあります。チャネルの容量が足りない、経路が見つからない、インボイスが期限切れといった理由で支払いが失敗することもあります。

送金の基礎は暗号資産の送金方法で説明しています。送付先がLightningの支払い先を指定しているのか、通常のBTCアドレスを指定しているのかは必ず区別してください。別の仕組みへ適当に送れば、救済が難しいケースもあり得ます。

Lightningウォレットの「管理方式」を区別する

Lightning対応を掲げるアプリでも、利用者自身がチャネルと秘密鍵を管理する方式や、サービス事業者が資金・チャネルの一部を管理する方式などがあります。自分で管理する場合は復旧・監視・バックアップの責任が増え、事業者に預ける場合はその運営体制、利用停止、出金制約の影響を受けます。「Lightningは分散型だからどのアプリも自己管理」という理解は誤りです。

また、Lightningの受信設定やチャネル状態は、一般的なオンチェーンBTCのシードフレーズだけで全情報が必ず復元するとは限りません。バックアップに必要なデータは実装やサービスによって違うため、ウォレットの公式説明を確認します。復旧の場面で知らない人にリカバリーフレーズを伝えてはいけません。保管全般は暗号資産の保管方法に整理しています。

5,000sat支払うときに起こる分岐を考える

架空の利用者が5,000satの請求情報を受け取ったとします。まず、ウォレットがLightningの支払いに対応しているか確認します。次に支払先・金額・必要なら有効期限を照合します。最後に経路の見積り手数料と送信可能額を確認して、内容に納得した場合だけ支払います。

残高画面に10,000satと表示されていても、実際の経路の送金可能額が3,000satなら、5,000satは通せないことがあります。また支払いボタンのあとに通信が途切れた場合、支払いが失敗したと決めつけず、ウォレットの支払い履歴や状態を確認します。二重払いを避けるために、同じ請求情報へ何度も操作を繰り返さないことが大切です。

送信完了の確認では、画面の「処理中」「失敗」「成功」などの意味を、そのウォレットの公式ヘルプに沿って読みます。オンチェーンのTxIDがないから異常だとは限りません。チャネル内支払いとオンチェーン送金では履歴の確認方法が異なるからです。一方、Lightningの送金IDらしき文字列が表示されても、それだけで最終的な受取を保証するものではありません。

Lightningの安全性と限界をどこで見る？

Lightningには高速な少額支払いという利点がありますが、チャネルの監視やバックアップ、ノードの接続状況、中継経路、アプリの実装などを考える必要があります。強制閉鎖が起こるとオンチェーンの待機が必要な場合があり、混雑時には費用も高くなり得ます。利用者がサービスを自分で運営するか、カストディ型サービスに任せるかでもリスクが異なります。

「チャネルの資金は2人のものだから一方が自由に取れるのでは？」という疑問に対しては、双方の署名や過去状態への対処が設計に含まれると理解できます。ただし、古いチャネル状態を不正利用される危険や、実装上の欠陥などが完全に消えるわけではありません。LightningはBTCの通常のチェーンに依存しており、チェーンそのものが不要になる技術ではありません。

使う前に何を確認するとよい？

Lightningで支払いを受け付ける相手先なら、Lightning対応か、請求情報の形式と有効期限、表示された金額の単位を確かめます。支払う側は送金可能額と手数料、失敗した場合の扱いを確認します。受け取る側は受信余力とバックアップ・復旧方法、資金の管理主体を確かめます。

ウォレットを選ぶ際は、サービスが実際にどの方法で残高を管理し、失敗時に何を表示し、必要なときにオンチェーンBTCへ戻せる条件をどう案内しているかが判断材料です。特定のサービスに秘密鍵を渡す前提ではありません。学習だけならチャネルを開いたり、実際に送金したりする必要もありません。

三つのノードを通る場合：途中の送信余力が足りないとどうなる？

アキさん・ベニさん・チカさんという三つのノードが、アキ―ベニ、ベニ―チカの二本のチャネルでつながっている想定例を考えます。アキさんはチカさんへ5,000satを払いたいのですが、直接つながっていません。そこでアキからベニへ、続いてベニからチカへという経路で支払いを通そうとします。ここでは経路手数料を省いた単純な説明です。

アキ―ベニ間ではベニに向かって送れる余力が12,000sat、ベニ―チカ間ではチカに向かって送れる余力が3,000satしかないとします。最初の区間は5,000satを送れますが、次の区間で不足するため、この経路では5,000satの支払いを完成できません。問題はアキさんのウォレットに5,000satがないことではなく、途中の特定方向の余力が足りないことです。

別のノードを経由する経路があって、その区間で十分な余力があれば、別経路で成立する可能性があります。ただし経路探しの結果は利用時点のネットワーク状態や実装に依存します。自分が直接つながるチャネルの容量だけを見ても、途中すべての余力を知ることはできません。支払いが失敗したとき、同じインボイスへ繰り返し操作する前に、ウォレットの処理状態や再試行の仕様を確認する理由がここにあります。

よくある質問

Lightningで送るBTCは別の仮想通貨ですか？

通常のLightning NetworkはBTCの支払いをチャネル経由で扱う仕組みです。新しいBTC銘柄に自動交換するという意味ではありません。ただしアプリ独自の商品や他チェーンの類似名サービスは別途確認します。

Lightningなら受取手数料も送金手数料もゼロですか？

いいえ。中継やサービスの費用、チャネル開設・閉鎖のオンチェーン費用などが発生し得ます。金額と条件は利用する方式で異なります。

送金に失敗したら必ず取り戻せますか？

一律には言えません。チャネルの状態、アプリの管理方式、実際に何が失敗したかで対応が変わります。追加送金せず、公式の履歴やサポート案内を確認してください。

受け取れないのは自分の残高不足ですか？

必ずしもそうではありません。チャネルの受信余力や中継経路、請求条件などが原因になり得ます。送信用の残高と受信用の余力を区別することが重要です。

まとめ：チャネルの「合計額」と「向き」を理解する

Lightningでは、チャネルを使ってBTCの支払いに伴う残高配分を更新します。オンチェーンは開閉などで重要な役割を持ち続け、通常のBTC送金と送付先の形式や確認方法が異なります。10万satの例のように、チャネルの合計容量だけでなく、誰の側にいくらあるかを見れば、送れる・受け取れるの違いを説明できます。高速さや費用の利点があっても、経路・管理主体・復旧条件を確認することが欠かせません。