# Lightning Network入門
Publisher: ビットコイン図書館 (KK siiiiiixth) — https://bitcoin.ne.jp

## Lightning Network入門

URL: https://bitcoin.ne.jp/learn/lightning
URL role: Self-canonical for this Japanese representation
English counterpart URL: https://bitcoin.ne.jp/en/learn/lightning
Slug: lightning
Language: ja
First published: 2025-12-01
Last updated: 2026-10-10
Last verified: 2026-10-09
Description: ビットコインの「第2層」Lightning Networkとは？支払いチャネル、HTLC、マルチホップルーティングによる即時・低手数料の送金の仕組みと、誰を信頼することになるのか、現状と課題を解説する。

Lightning Networkは、支払いチャネルとHTLCを用いてオフチェーンで即時・低手数料の取引を行うビットコインのレイヤー2ソリューションであり、その仕組みとルーティング、そして実際に誰を信頼することになるのかを解説する。mempool.spaceの公開統計では2026年8月16日時点の公開チャネル容量は約3,786 BTC、公開チャネル数は33,131、ノード数は16,421で（プライベートチャネルは含まれない）、2025年12月に記録した過去最高（5,800 BTC超）からは3割以上減少している。利用面では、Tether社が2025年1月に発表したTaproot AssetsによるUSDTのLightning対応計画など、ステーブルコイン決済への応用も模索されている。

Reuse terms: https://bitcoin.ne.jp/licenses#content-reuse
Third-party sources retain their own rights. Cite the canonical HTML URL or its section fragment.
Sources below are article-level references; they do not establish support for every sentence. Check the original source and its date before quoting time-sensitive claims.
This is educational material, not investment or legal advice. Dates describe the editorial text; this representation excludes browser tools and live market/network values.

### 30秒でつかむ

二人が何百回支払い合っても、ベースチェーンに残るのは入口と出口だけ。Lightningは、ビットコインの上に支払いの小道を張り巡らせます。

たとえ: バーで最初に預け入れて伝票を開き、途中は伝票を書き換え、最後にまとめて精算する。支払いチャネルはその姿に近く、伝票どうしをつなげば経路になります。
事実との境界: 実際には署名済みのコミットメントとHTLCが使われ、十分な流動性とオンラインでの監視が必要です。オンチェーンと同じ決済条件・信頼条件ではなく、いつも安く必ず届くとも限りません。
読み進める道: [チャネルを開く](https://bitcoin.ne.jp/learn/lightning#payment-channels) → [経路と流動性](https://bitcoin.ne.jp/learn/lightning#routing) → [失敗と信頼、使いどころ](https://bitcoin.ne.jp/learn/lightning#wallet-types)
読後にわかること: コーヒー一杯の支払いがどのチャネルを通り、どこで失敗しうるのかを追えるようになります。

### Lightning Networkとは

Section URL: https://bitcoin.ne.jp/learn/lightning#what-is-lightning

Lightning Network（LN）は、ビットコインのレイヤー2スケーリングソリューションです。ブロックチェーンの「上に」構築された決済ネットワークで、ほぼ即時かつ極めて低手数料の取引を可能にします。

Joseph PoonとThaddeus Dryjaが「The Bitcoin Lightning Network」というホワイトペーパーで提案しました。初稿は2015年、現在公開されている改訂版は2016年1月付です。

基本的な仕組み：2者間で「支払いチャネル」を開設（オンチェーン取引）→ チャネル内で何度でもオフチェーン取引 → チャネル閉鎖時にのみ最終残高をブロックチェーンに記録。

この仕組みによって、ブロックチェーンの負荷を大幅に減らせます。ただし「ビットコインと同じセキュリティがそのまま得られる」とまでは言えません。Lightningの安全性は、相手が古い残高状態をブロードキャストしていないかを一定時間内に監視できること、そして必要なときにオンチェーン取引を送れること（＝手数料が高騰しすぎていないこと）を前提にしています。この前提が崩れる条件は「取り消し機構とペナルティ」「課題と限界」で扱います。

### 支払いチャネルの仕組み

Section URL: https://bitcoin.ne.jp/learn/lightning#payment-channels

[Figure: lightning-channel — Lightningチャネルはオンチェーン取引で開き、参加者間の署名済み残高を何度も更新し、最後に必要な場合だけオンチェーンへ決済する。]

支払いチャネルは、2者がビットコインをマルチシグアドレスにロックすることで開設されます。この「ファンディングトランザクション」がブロックチェーンに記録されます。

チャネル開設後、両者は「コミットメントトランザクション」を交換することで残高を更新します。これらはオフチェーン（ブロックチェーンに記録しない）で行われます。

例：アリスがボブに1万satoshi送りたい場合、新しいコミットメントトランザクション（アリスの残高-1万、ボブの残高+1万）を作成し、両者が署名します。これは瞬時に行われます。

チャネルを閉じる際、最新のコミットメントトランザクションがブロックチェーンにブロードキャストされ、各自の残高が確定します。

### マルチホップルーティング

Section URL: https://bitcoin.ne.jp/learn/lightning#routing

Lightning Networkの真の力は、直接チャネルを持たない相手にも支払えることです。支払いは複数のチャネルを経由してルーティングされます。

HTLC（Hash Time-Locked Contract）という技術により、中間ノードを信頼する必要がありません。支払いは「ハッシュロック」で暗号的に保護され、経路全体で同時に成功するか、すべて失敗するかのどちらかです。

オニオンルーティング：Torネットワークと同様に、各中間ノードは自分の直前と直後のノードしか知りません。ただしプライバシーは無条件ではありません。経路の最終ホップは受取人が誰かを知り、送金者は経路の全体を知ります。チャネルグラフは公開されているため、少額の試行送金（probing）でチャネル残高を推定する手法も知られています。カストディ型のウォレットを使う場合は、そもそもプロバイダが送受金の全体を把握します。

ルーティング手数料は一般に少額ですが、「常に1 satoshi未満」ではありません。広く使われる実装の既定値は1ホップあたり基本手数料1 satoshi＋送金額に比例する分であり、複数ホップを経由すれば合計は数satoshi以上になります。それでもオンチェーン手数料とは桁が違い、マイクロペイメント（少額決済）が経済的に成立する水準です。

### HTLCの仕組み

Section URL: https://bitcoin.ne.jp/learn/lightning#htlc

HTLC（Hash Time-Locked Contract）は、Lightning Networkの安全性を保証する核心技術です。

ハッシュロック：受取人は秘密の値（プリイメージ）を知っている場合のみ資金を請求できます。この値のハッシュが事前に共有され、支払いの条件として使用されます。

タイムロック：一定時間内にプリイメージが提示されない場合、資金は送金者に返還されます。この仕組みがあるため、経路のどこかで支払いが失敗しても、資金が永久にロックされたままになるのを防げます。

HTLCが保証するのは「経路上での資金の受け渡し」です。チャネル内部で古い残高状態が使われることを防ぐのは、これとは別の機構（次節）が担っています。

### 取り消し機構とペナルティ

Section URL: https://bitcoin.ne.jp/learn/lightning#revocation

チャネル内の残高を更新するたびに、両者は一つ前のコミットメントトランザクションを「取り消し（revoke）」ます。具体的には、古い状態を無効化するための鍵を相手に渡します。これはHTLCとは独立した機構です。

相手が古い（自分に有利な）コミットメントトランザクションをブロードキャストした場合、受け取っておいた鍵を使って「ペナルティトランザクション」を作り、チャネル内の全資金を没収できます。不正が経済的に割に合わないようにする設計です。

ただしこの防御は自動では働きません。ペナルティを行使するには、不正なブロードキャストを相対タイムロックの猶予内に検知する必要があります。自分のノードがオフラインのまま猶予が過ぎれば、不正はそのまま確定します。

この監視を代行するのがウォッチタワーです。ノードを常時稼働させない利用者は、ウォッチタワーを使うか、監視を担うプロバイダに任せることになります。後者は次節の「カストディ型」に該当します。

### ウォレットの2類型 — 誰が鍵を持つか

Section URL: https://bitcoin.ne.jp/learn/lightning#wallet-types

Lightningを使う方法は大きく二つに分かれます。この違いは操作性の差ではなく、「何かが壊れたときに何を失うか」の差です。

| 類型 | 鍵とチャネルの管理 | 利用者が信頼する相手 | 主な留意点 |
| --- | --- | --- | --- |
| 非カストディ型（セルフホスト） | 利用者自身、または利用者の鍵で動くウォレット | チャネルの相手方（＋自分または委託先の監視体制） | 不正監視・バックアップ・流動性管理の責任を自分で負う |
| カストディ型 | プロバイダ | プロバイダ | 残高はプロバイダに対する債権。破綻・凍結・本人確認要求・送受金の可視化というリスクを負う |

「中間ノードを信頼する必要がない」というLightningの性質は、非カストディ型に当てはまる説明です。カストディ型のウォレットでは、画面に表示されている残高はプロトコル上のチャネル残高ではなく、プロバイダに対する請求権にすぎません。プロバイダが破綻・凍結・撤退すれば、資金が戻らない可能性があります。この構造は取引所に預けたビットコインと同じで、「主要事件と教訓」で扱う破綻事例と同じ類型に属します。

中間的な形態もあります。LSP（Lightning Service Provider）が流動性やチャネル管理だけを担い、鍵は利用者が持つ設計です。この場合でも、LSPが撤退したときに自分でチャネルを閉じてオンチェーンへ退出できるかどうかが、信頼前提の分かれ目になります。

本サイトは特定のウォレットを推奨しません。判断の起点は「秘密鍵とチャネル状態のバックアップを自分が持っているか」の一点です。ウォレット全般の考え方は「ウォレットと安全管理」で扱っています。

### ユースケースと現状

Section URL: https://bitcoin.ne.jp/learn/lightning#use-cases

マイクロペイメント：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）の普及を反映したものと説明されます。これらの数値は週単位で増減するため、単一時点の値を趨勢と読まないでください。

### 課題と限界

Section URL: https://bitcoin.ne.jp/learn/lightning#limitations

流動性：チャネルの容量には上限があり、高額の支払いでは分割ルーティングが必要になる場合があります。受信流動性（インバウンドキャパシティ）の確保も課題です。

オンライン要件：支払いを受け取るにはノードがオンラインである必要があります。モバイルウォレットではバックグラウンド監視の課題があります。

チャネル管理：開設と閉鎖にはオンチェーン手数料がかかります。手数料が高騰する時期には、少額チャネルの採算が悪くなります。

不正監視：相手が古い状態をブロードキャストする不正行為を検出するには、定期的な監視が必要です。ウォッチタワーサービスがこの問題を軽減しますが、監視を他者に委ねること自体が新しい信頼前提になります。

経路の集中：公開チャネル数はピーク時の約8万から3万台へ半減し、容量も少数の大規模ノードとLSPに集まっています。送金の成功率という点では大きなハブを経由するほうが有利ですが、その分、特定の事業者の稼働・方針・規制対応がネットワーク全体の使い勝手を左右する構造になります。分散性を数えるとき、ノードの総数と「実際に経路として使われるノードの数」は別物です。

カストディへの回帰：上記の課題（流動性・オンライン要件・監視）を回避する最も簡単な方法はカストディ型ウォレットを使うことであり、実際に多くの利用者がそこへ流れています。技術的な難しさが、設計上排除したはずの仲介者を呼び戻すという構造は、「ビットコインのパラドックス」で扱う論点の一つです。

これらの課題は活発に研究・開発が進んでおり、年々改善されています。一方で、上に挙げたもののうち経路の集中とカストディへの回帰は、技術の改善だけでは解消しない性質のものです。

### Taproot Assetsとステーブルコイン

Section URL: https://bitcoin.ne.jp/learn/lightning#taproot-assets

Taproot Assets（旧Taro）は Lightning Labs が開発したプロトコルで、ビットコインのブロックチェーン上でステーブルコインなどのデジタル資産を発行し、送受信できるようにするものです。

2025年1月、Tether社はTaproot Assetsを使ってLightning Network上でUSDTを提供する計画を発表しました。実現すれば、USDTをLightningの支払いとして、即座に低い手数料で送れるようになります。

Taproot Assetsは継続的に更新されており、再利用可能なアドレスや監査可能な供給量といった機能が段階的に加わっています。バージョン番号は短期間で変わるため、現行の機能範囲は開発元のリリース情報で確認してください。

Lightning上のステーブルコインは、国際送金や自国通貨が不安定な地域での決済手段として注目されています。ただし支払われているのはビットコインではなく、発行体の信用リスク・償還の可否・規制上の位置づけはビットコインとは別に評価する必要があります。

2025年12月にはLightning Networkの公開チャネル容量が過去最高の5,800 BTC超に達しました。その後は減少に転じ、2026年8月16日時点では約3,786 BTCです。容量は一方向に伸び続けているわけではありません。なお「Lightningの年間処理量」として流通する推計値がありますが、オフチェーンの送金量は外部から直接観測できず、推定の主体と手法をたどれる一次資料が確認できないため、本サイトでは採用しません。

### 主な参照元

- Lightning Network ホワイトペーパー（Poon & Dryja、2015年初稿・2016年改訂）: https://lightning.network/lightning-network-paper.pdf
- mempool.space — Lightning Networkネットワーク統計: https://mempool.space/lightning
- Lightning Labs — Taproot Assets リリース一覧（バージョンごとの機能追加）: https://github.com/lightninglabs/taproot-assets/releases
- Tether — Lightning Network統合発表: https://tether.io/news/tether-brings-usdt-to-bitcoins-lightning-network-ushering-in-a-new-era-of-unstoppable-technology/

### 改訂履歴

- 2026-10-09: 公開チャネル容量の過去最高を出典（mempool.space）に合わせて是正。一次資料で確認できない「2026年3月のUSDT稼働」を、2025年1月の計画発表に改めた。
- 2026-08-18: チャネルの資金投入、署名済み残高更新、複数のオフチェーン支払い、最終決済を示す日英図解を追加。
- 2026-08-16: ネットワーク統計を実測値に更新（ATH後の減少を併記）、ウォレットの2類型（カストディ／非カストディ）節を新設、取り消し機構をHTLCから分離、プライバシー・手数料・セキュリティ保証の記述を条件付き化、出典不明の年間処理量を削除