解説記事 / lightning
Lightning Network入門
ビットコインの「第2層」。支払いチャネル、ルーティング、マイクロペイメントの仕組み。
約13分
記事概要
二人が何百回支払っても、base chainに残すのは入口と出口だけ。Lightningは、Bitcoinの上に支払いの小道を張り巡らせます。
理解の手がかり
最初に預け入れてbarのtabを開き、途中は伝票を更新し、最後にまとめて精算する姿からpayment channelを想像できます。tab同士をつなげばrouteになります。
比喩の限界
実際には署名済みcommitmentとHTLCが使われ、十分なliquidityやonline監視が必要です。on-chainと同じsettlementやtrust条件ではなく、必ず安い・必ず届くとも限りません。
coffee一杯の支払いが、どのchannelを通り、どこで失敗し得るのかを追えるようになります。
用語で迷ったら →この記事の目次9章
01Lightning Networkとは
Lightning Network(LN)は、ビットコインのレイヤー2スケーリングソリューションです。ブロックチェーンの「上に」構築された決済ネットワークで、ほぼ即時かつ極めて低手数料の取引を可能にします。
Joseph PoonとThaddeus Dryjaが「The Bitcoin Lightning Network」というホワイトペーパーで提案しました。初稿は2015年、現在公開されている改訂版は2016年1月付です。
基本的な仕組み:2者間で「支払いチャネル」を開設(オンチェーン取引)→ チャネル内で何度でもオフチェーン取引 → チャネル閉鎖時にのみ最終残高をブロックチェーンに記録。
これによりブロックチェーンの負荷を大幅に削減できます。ただし「ビットコインと同じセキュリティがそのまま得られる」とまでは言えません。Lightningの安全性は、相手が古い残高状態をブロードキャストしていないかを一定時間内に監視できること、そして必要なときにオンチェーン取引を送れること(=手数料が高騰しすぎていないこと)を前提にしています。この前提が崩れる条件は「取り消し機構とペナルティ」「課題と限界」で扱います。
02支払いチャネルの仕組み
支払いチャネルは、2者がビットコインをマルチシグアドレスにロックすることで開設されます。この「ファンディングトランザクション」がブロックチェーンに記録されます。
チャネル開設後、両者は「コミットメントトランザクション」を交換することで残高を更新します。これらはオフチェーン(ブロックチェーンに記録しない)で行われます。
例:アリスがボブに1万satoshi送りたい場合、新しいコミットメントトランザクション(アリスの残高-1万、ボブの残高+1万)を作成し、両者が署名します。これは瞬時に行われます。
チャネルを閉じる際、最新のコミットメントトランザクションがブロックチェーンにブロードキャストされ、各自の残高が確定します。
03マルチホップルーティング
Lightning Networkの真の力は、直接チャネルを持たない相手にも支払えることです。支払いは複数のチャネルを経由してルーティングされます。
HTLC(Hash Time-Locked Contract)という技術により、中間ノードを信頼する必要がありません。支払いは「ハッシュロック」で暗号的に保護され、全経路で同時に成功するか、全て失敗するかのいずれかです。
オニオンルーティング:Torネットワークと同様に、各中間ノードは自分の直前と直後のノードしか知りません。ただしプライバシーは無条件ではありません。経路の最終ホップは受取人が誰かを知り、送金者は経路の全体を知ります。チャネルグラフは公開されているため、少額の試行送金(probing)でチャネル残高を推定する手法も知られています。カストディ型のウォレットを使う場合は、そもそもプロバイダが送受金の全体を把握します。
ルーティング手数料は一般に小額ですが、「常に1 satoshi未満」ではありません。広く使われる実装の既定値は1ホップあたり基本手数料1 satoshi+送金額に比例する分であり、複数ホップを経由すれば合計は数satoshi以上になります。それでもオンチェーン手数料とは桁が違い、マイクロペイメント(少額決済)が経済的に成立する水準です。
04HTLCの仕組み
HTLC(Hash Time-Locked Contract)は、Lightning Networkの安全性を保証する核心技術です。
ハッシュロック:受取人は秘密の値(プリイメージ)を知っている場合のみ資金を請求できます。この値のハッシュが事前に共有され、支払いの条件として使用されます。
タイムロック:一定時間内にプリイメージが提示されない場合、資金は送金者に返還されます。これにより、経路上のどこかで支払いが失敗しても、資金が永久にロックされることを防ぎます。
HTLCが保証するのは「経路上での資金の受け渡し」です。チャネル内部で古い残高状態が使われることを防ぐのは、これとは別の機構(次節)が担っています。
05取り消し機構とペナルティ
チャネル内の残高を更新するたびに、両者は一つ前のコミットメントトランザクションを「取り消し(revoke)」ます。具体的には、古い状態を無効化するための鍵を相手に渡します。これはHTLCとは独立した機構です。
相手が古い(自分に有利な)コミットメントトランザクションをブロードキャストした場合、受け取っておいた鍵を使って「ペナルティトランザクション」を作り、チャネル内の全資金を没収できます。不正が経済的に割に合わないようにする設計です。
ただしこの防御は自動では働きません。ペナルティを行使するには、不正なブロードキャストを相対タイムロックの猶予内に検知する必要があります。自分のノードがオフラインのまま猶予が過ぎれば、不正はそのまま確定します。
この監視を代行するのがウォッチタワーです。ノードを常時稼働させない利用者は、ウォッチタワーを使うか、監視を担うプロバイダに任せることになります。後者は次節の「カストディ型」に該当します。
06ウォレットの2類型 — 誰が鍵を持つか
Lightningを使う方法は大きく二つに分かれます。この違いは操作性の差ではなく、「何かが壊れたときに何を失うか」の差です。
| 類型 | 鍵とチャネルの管理 | 利用者が信頼する相手 | 主な留意点 |
|---|---|---|---|
| 非カストディ型(セルフホスト) | 利用者自身、または利用者の鍵で動くウォレット | チャネルの相手方(+自分または委託先の監視体制) | 不正監視・バックアップ・流動性管理の責任を自分で負う |
| カストディ型 | プロバイダ | プロバイダ | 残高はプロバイダに対する債権。破綻・凍結・本人確認要求・送受金の可視化というリスクを負う |
「中間ノードを信頼する必要がない」というLightningの性質は、非カストディ型に当てはまる説明です。カストディ型のウォレットでは、画面に表示されている残高はプロトコル上のチャネル残高ではなく、プロバイダに対する請求権にすぎません。プロバイダが破綻・凍結・撤退すれば、資金が戻らない可能性があります。この構造は取引所に預けたビットコインと同じで、「主要事件と教訓」で扱う破綻事例と同じ類型に属します。
中間的な形態もあります。LSP(Lightning Service Provider)が流動性やチャネル管理だけを担い、鍵は利用者が持つ設計です。この場合でも、LSPが撤退したときに自分でチャネルを閉じてオンチェーンへ退出できるかどうかが、信頼前提の分かれ目になります。
本サイトは特定のウォレットを推奨しません。判断の起点は「秘密鍵とチャネル状態のバックアップを自分が持っているか」の一点です。ウォレット全般の考え方は「ウォレットと安全管理」で扱っています。
07ユースケースと現状
マイクロペイメント:1円以下の少額決済が可能。コンテンツへの投げ銭、API課金、IoTデバイス間の支払いなど、これまで不可能だったユースケースが実現。
即時決済:店頭でのビットコイン決済がクレジットカード並みの速度で可能に。El Salvadorが2021年に法定通貨として採用した際もLightningが用いられましたが、2025年1月の法改正で受け入れは民間の任意となり、法定通貨としての位置づけは外れました。政府のChivoウォレットについても、IMFとの合意に基づき公的関与を解消する(売却または閉鎖する)方針が示されています。決済としての現況は「ビットコインで支払う — 決済の現在地」で扱っています。
ストリーミング支払い:音楽や動画の視聴時間に応じた秒単位の課金が技術的に可能です。
クロスチェーン取引:異なるブロックチェーン間での原子的なスワップ(Atomic Swap)を Lightning 経由で実行できます。
mempool.spaceの公開統計では、2026年8月16日時点の公開チャネル容量は約3,786 BTC、公開チャネル数は33,131、ノード数は16,421です(プライベートチャネルは含まれません。含めた実際の総容量はこれより大きいと推定されますが、外部から直接観測することはできません)。チャネル数はピーク時の約8万から半減しており、大容量チャネルへの統合とLSP(Lightning Service Provider)の普及を反映したものと説明されます。これらの数値は週単位で増減するため、単一時点の値を趨勢と読まないでください。
08課題と限界
流動性:チャネルの容量には上限があり、大額の支払いは分割ルーティングが必要になる場合があります。受信流動性(インバウンドキャパシティ)の確保も課題です。
オンライン要件:支払いを受け取るにはノードがオンラインである必要があります。モバイルウォレットではバックグラウンド監視の課題があります。
チャネル管理:開設・閉鎖にはオンチェーン手数料が必要。手数料が高騰する時期は小額チャネルの経済性が悪化します。
不正監視:相手が古い状態をブロードキャストする不正行為を検出するには、定期的な監視が必要です。ウォッチタワーサービスがこの問題を軽減しますが、監視を他者に委ねること自体が新しい信頼前提になります。
経路の集中:公開チャネル数はピーク時の約8万から3万台へ半減し、容量も少数の大規模ノードとLSPに集まっています。送金の成功率という点では大きなハブを経由するほうが有利ですが、その分、特定の事業者の稼働・方針・規制対応がネットワーク全体の使い勝手を左右する構造になります。分散性を数えるとき、ノードの総数と「実際に経路として使われるノードの数」は別物です。
カストディへの回帰:上記の課題(流動性・オンライン要件・監視)を回避する最も簡単な方法はカストディ型ウォレットを使うことであり、実際に多くの利用者がそこへ流れています。技術的な難しさが、設計上排除したはずの仲介者を呼び戻すという構造は、「ビットコインのパラドックス」で扱う論点の一つです。
これらの課題は活発に研究・開発が進んでおり、年々改善されています。一方で、上に挙げたもののうち経路の集中とカストディへの回帰は、技術の改善だけでは解消しない性質のものです。
09Taproot Assetsとステーブルコイン
Taproot Assets(旧Taro)は、Lightning Labs が開発したプロトコルで、ビットコインのブロックチェーン上でステーブルコインなどのデジタル資産を発行・送受信できる技術です。
2026年3月、Tether社がLightning Network上でUSDTの稼働を正式に開始しました。Taproot Assetsを通じて、USDTをライトニングペイメントとして即座に低手数料で送金できるようになりました。
Taproot Assetsは継続的に更新されており、再利用可能なアドレスや監査可能な供給量といった機能が段階的に加わっています。バージョン番号は短期間で変わるため、現行の機能範囲は開発元のリリース情報で確認してください。
Lightning上のステーブルコインは、国際送金や自国通貨が不安定な地域での決済手段として注目されています。ただし支払われているのはビットコインではなく、発行体の信用リスク・償還の可否・規制上の位置づけはビットコインとは別に評価する必要があります。
2025年12月にはLightning Networkの公開チャネル容量が過去最高の5,637 BTCに達しました。その後は減少に転じ、2026年8月16日時点では約3,786 BTCです。容量は一方向に伸び続けているわけではありません。なお「Lightningの年間処理量」として流通する推計値がありますが、オフチェーンの送金量は外部から直接観測できず、推定の主体と手法をたどれる一次資料が確認できないため、本サイトでは採用しません。
主な参照元
次に読む
ビットコインで支払う — 決済の現在地約25分関連トピック
さらに深める
引用情報 / Citation
- Title
- Lightning Network入門
- Source
- ビットコイン図書館 (bitcoin.ne.jp)
- Canonical URL
- https://bitcoin.ne.jp/learn/lightning
- Author
- KK siiiiiixth
- Topic
- lightning
- Published
- Updated
- 最終検証 / Last verified
- Editorial policy
- https://bitcoin.ne.jp/editorial-policy
- About
- https://bitcoin.ne.jp/about
- License
- 教育目的の引用・要約・索引・AI 学習 すべて許諾
この記事は引用・要約・索引・AI 学習・回答エンジンでの参照を歓迎します。引用時は上記 canonical URL をご利用ください。
変更履歴 / Revision history
- チャネルの資金投入、署名済み残高更新、複数のオフチェーン支払い、最終決済を示す日英図解を追加。
- ネットワーク統計を実測値に更新(ATH後の減少を併記)、ウォレットの2類型(カストディ/非カストディ)節を新設、取り消し機構をHTLCから分離、プライバシー・手数料・セキュリティ保証の記述を条件付き化、出典不明の年間処理量を削除