Lightning Networkの「キャパシティ」は流動性ではない

1. ライトニングの「キャパシティ」という誤解を招く指標

Amboss、mempool.space、1MLといったLightning Network（以下、ライトニング）のエクスプローラーを開くと、いずれも「Network Capacity（ネットワークキャパシティ）」という見出し数値をビットコイン建てで表示します。アナリストは四半期レポートでこの数値を引用し、ジャーナリストはアダプション記事の冒頭でこの数値を使い、ビジネス上の意思決定者はこれをライトニングが成長しているかどうかを示す指標として扱います。しかもエクスプローラー同士でも数値は一致しません。2026年7月のある一日、mempool.spaceはネットワークキャパシティを4,494 BTCと報告した一方、1MLは2,785 BTCと報告しました。それぞれが自前のクローラーで観測できる範囲しか見ていないためです。

これは流動性の指標ではありません。公開登録されているすべてのチャネルにおける、コミットされた資本の合計、つまりノード運営者が公開チャネルにロックしたビットコインの総額です。この数値が教えてくれないのは、その資本のうちどれだけが特定の方向への支払いルーティングに使える状態にあるか、そしてそれが最後に動いたのがいつなのかということです。

この違いは些末な話ではありません。そろばんの珠を思い浮かべてください。キャパシティとは、その串が保持できる珠の総数です。流動性とは、支払いが必要になったときにスライドできる、自分側にある珠の数です。すべての珠を受取側のチャネル端にスライドさせても串自体は満杯のままですが、手元には使える珠が残っておらず、相手側から支払い（珠）を受け取ることしかできなくなります。

本稿は、ライトニングが一般に公開している情報と、公開していない情報を正確に対応づけるものです。フィールド単位の詳細な一覧は、その水準の情報を求める読者のために第6節「チャネルが実際に公開している情報」にまとめてあります。結論を先に述べると、支払いがルーティングできるかどうかを決定づける量であるチャネル残高は、決して公開されません。これは設計上意図的に隠されているものです。「公開データによるライトニング流動性分析」というカテゴリー自体が、丸ごと間違った対象を測っているのです。

2. 残高が隠されているのは仕様であってバグではない

残高をゴシップで共有するには、すべての支払いのたびにネットワーク全体へのブロードキャストが必要になります。1つのライトニングチャネルは1日に数千件の支払いを処理し得て、そのたびに残高の配分が変化します。もしノードが支払いのたびに残高をゴシップしていたら、ゴシップ層のトラフィックが決済層そのものを上回ってしまい、プロトコルは自らのアナウンスの重みで機能不全に陥るでしょう。

単なる工学的な制約ではなく、プライバシーも一つの理由です。ビットコインのベースレイヤーは完全に公開されており、すべてのオンチェーン取引、アドレス、金額は誰でも永続的に閲覧・追跡可能です。レイヤー2プロトコルであるライトニングは、その点を改善することも設計目的の一部としていました。ユーザーの支払い活動の大半はそもそもチェーン上に一切現れず、オニオンルーティングによって各ホップは経路全体を把握できません。ゴシップから残高を除外することは、この同じ設計目標をルーティング層自体にまで拡張するものです。誰が誰にいくら支払っているかを暴露しかねないただ一つの数値は、単に省略されているのではなく、意図的に非公開とされています。(Lightning Networkホワイトペーパー)

その代わり、ノードはポリシーを低頻度でブロードキャストし、支払いを試みて失敗から学ぶことで動的に流動性を発見します。中継ノードが送金に必要な残高を持たずに失敗を返すと、送信者はそのホップについて何かを学び、別の経路を試します。ネットワークは不完全な情報の上で動作し、試行錯誤を通じて機能する経路へと収束していきます。これはバグではなく、ライトニングのルーティングが本来そのように機能する仕組みなのです。

ビジネス側の読者にとって重要な補足が一つあります。ネットワークの実際の規模は、公開グラフが示すよりも大きいということです。かなりの割合のチャネルは、channel_announcementを一切行わずに開設される「プライベートチャネル」です。モバイルウォレット、Lightning Service Provider（LSP）のクライアント、多くの加盟店統合はすべてプライベートチャネルの上で完全に動いています。これらはキャパシティの数値には一切現れません。

2026年の業界推計の一つでは、プライベートチャネルのキャパシティは公開されている数値の2倍以上に達するとされています(Spark, State of the Lightning Network in 2026)。「ネットワーク総キャパシティ」が測っているのはアナウンスされたネットワークのみであり、それ自体が実際のネットワークの一部分に過ぎません。

3. キャパシティが生む4つの誤解

誤解1：キャパシティが大きいノード = 重要または活発なルーター

大きなチャネルを持つノードは多くの資本をコミットしています。しかしそれは、そのノードが1件でも支払いをルーティングしたことを意味しません。チャネルは50/50の残高バランスのまま、何も送金せずに何ヶ月も存在し続けることがあります。ルーティング活動と相関する唯一のシグナルである送金ボリュームは、どのノードにも共有義務のないプライベートデータです。

誤解2：総キャパシティ = アダプション、経済活動、またはTVL(Total Value Locked、預かり資産総額)

キャパシティが測っているのは公開チャネルにコミットされたビットコインであり、これはネットワーク全体で理論上同時に移動し得る価値の上限に過ぎません。取引量でも、決済件数でも、実際に取引された経済価値でもありません。

1 BTCのチャネルを開いて何も送金しないオペレーターは、この数値に1 BTCを加算します。0.1 BTCの、頻繁に使われていたチャネルをクローズするオペレーターは、この数値から0.1 BTCを減算します。この数値は資本コミットメントの判断に応じて動くのであって、経済活動に応じて動くのではありません。

誤解3：キャパシティがルーティング能力を示す

1,000,000satsのチャネルは、理論上はどちらの方向にも1,000,000satsをルーティングできます。しかし支払いが片方向に十分な量流れた後は、900,000が片端に偏り、逆方向のトラフィックに使えるのは100,000だけかもしれません。公開記録上は依然として1,000,000のままです。

channel_update内のhtlc_maximum_msatフィールドはポリシー上の上限を設定するものであり、流動性レポートではありません。これはウォレット、取引所、決済プロセッサーなど、ライトニングの上に何かを構築しようとするすべての人が直面するコストです。送信ノードは、候補経路が必要な方向に十分な残高を持っているかどうかを事前に知ることができません。だからこそライトニングのルーティングアルゴリズムは確率的であり、失敗した支払いがローカルの残高推定を更新し、マルチパス決済(支払いを複数のチャネルに分散させ、少なくとも1つの経路が機能する確率を上げる仕組み)が存在するのです。

誤解4：キャパシティ加重の中心性(centrality)が最も重要なルーターを特定する

キャパシティをエッジの重みとして計算する媒介中心性(betweenness)、近接中心性(closeness)、固有ベクトル中心性(eigenvector centrality)は、ルーティングのスループットではなく、コミットされた資本によって重み付けされた影響力を測っています。資本は大きいが活動の少ないノードは高いランクを得る一方、スループットは大きいが資本の少ないノードは実際の重要性よりも低くランクされます。キャパシティ加重の中心性ランキングは、ルーティングの重要性ではなく、資本コミットメントとトポロジーをランク付けしているのです。

この4つの中で、2つ目の誤解は最もデータで検証しやすいものです。2019年1月から2023年7月までのLightning Networkトポロジーのスナップショット(35,481ノード、336スナップショット)を対象とした2026年の実証研究は、この点を機械的に裏付けています。あるノードのキャパシティは、稼働期間との相関(相関係数0.03〜0.12)よりも、その接続性(ネットワーク次数、相関係数0.79〜0.86)とはるかに強く相関しており、キャパシティはその国のGDP(国内総生産)per capitaとも系統的に連動しています。キャパシティは利用実績や稼働年数ではなく、トポロジーと経済地理を通じて蓄積されるのです(Valko and Marx Gómez, "Shared Channel Capacity and Node Lifetime," arXiv:2606.20566)。

図1はこのコストを具体的に示しています。2018年3月のライトニング初の公開データから2026年6月までの両指標をプロットしたもので(mempool.space、日次観測2,366件)、両系列はまったく逆の物語を語っています。公開チャネル数は2022年3月に82,825でピークをつけた後、51%減少して40,971まで落ち込んでおり、これは一見すると崩壊のように見えます。一方、BTC建てのコミット資本は同じ期間を通じて上昇し、2025年12月に5,851 BTCという過去最高値をつけた後、19%減少して4,745 BTCとなっており、こちらは一見すると最近の急騰の後の反落のように見えます。どちらの解釈も、それぞれの元データとは矛盾しません。しかしどちらも、決済ボリュームについては何も教えてくれません。正確な説明は次のようなものです。「チャネル数は減っているが1件あたりは大型化しており、コミット資本は2025年後半に過去最高を更新した後、減少に転じている」。いずれかの系列をスループットやアダプションの指標として使うと、いかなるデータからも検証も反証もできない主張が生まれます。

これら4つの誤解はすべて同じ根本原因に行き着きます。キャパシティはライトニングのゴシップ層が公開する唯一の数値であるため、それを基に構築されるあらゆる下流の指標、アダプションのストーリー、ルーティングの推定、中心性のランキングは、すべて同じ盲点を受け継いでしまうのです。

そしてこの誤差は両方向に働きます。経済活動の指標として見ればこの数値は大きすぎ、ネットワークの真の規模の指標として見ればこの数値は小さすぎます。プライベートチャネルは決してこの数値に算入されないからです(第2節参照)。防御可能なライトニング分析への第一歩は、公開データが裏付けられる主張と、そうでない主張とを見分けることです。

4. 想定される回避策

技術に詳しい読者であれば、当然次のような反論を思いつくでしょう。チャネル残高は、対象チャネルに沿って支払いを送り、成功・失敗を二分探索することで、任意の精度まで能動的にプロービング(probing)して復元できるはずだ、と。学術文献はこれが実際に機能することを裏付けています。失敗した支払い試行はオンチェーンで決済されないため、資本コスト自体はほぼゼロです。

しかし、これによって公開データ分析が正当化されるわけではない理由が3つあります(Tikhomirov et al., "Probing Channel Balances in the Lightning Network," arXiv:2004.00333)。

第一に、プロービングは能動的かつ敵対的な行為です。人工的な支払いトラフィックを生み出し、ルーティングキャパシティを消費し、プロービング対象のノードに実際のレイテンシコストを課します。これは公開データの受動的な観測ではなく、意図的な侵入行為です。

第二に、スナップショットは瞬時に陳腐化します。プロービングで得られた残高は測定時点でのみ正確で、そのチャネルを次の支払いが通過した瞬間(トラフィックの多いノードでは数秒後もあり得ます)に古い情報になります。しかもこの陳腐化は連続的ではなく、1件の支払いによって残高がHTLC額分だけ一気にシフトします。

第三に、ネットワーク全体をカバーすることは事実上不可能です。数万件に及ぶ公開チャネルすべてを、個々の残高が変化するよりも速いペースで、一貫した時間枠内でプロービングするには、数百万回の試行が必要になります。これは現在の技術力の限界ではなく、組み合わせ論的な制約です。

能動的プロービングは、ノード運営者が自分の直近の隣接関係を把握するには有用です。しかしそれによって「公開データによるライトニング流動性分析」が一貫したカテゴリーになるわけではありません。データは依然として公開されていないのです。

より持続可能な代替案の研究も進んでいますが、まだ実現はしていません。2025年のある提案(arXiv:2512.12095)は、Trusted Execution Environmentとゼロ知識TLS(Transport Layer Security)アテステーションを用いて、数値自体をゴシップで共有することなく、ノードが自らの残高が正確であることを証明できるようにするというものです。これが実現すれば、プロービングなしで残高を検証可能にするアプローチになり得ます。ただし、これは信頼不要な解決策ではありません。「ノード運営者が正直に自己申告する」という信頼を、ハードウェアメーカー(Intel Software Guard Extensions、SGX、またはAMD Secure Encrypted Virtualization、SEV)とその基盤となる暗号学的な前提が成立し続けることへの信頼に置き換えているだけです。残高の可視性問題は構造的に困難な問題であって放置されているわけではなく、現時点ではプロービングだけが、上述のコストを払った上で残高を復元できる唯一の方法です。

5. まとめと次回予告

公開記録が実際に含んでいるものをそのまま捉えるべきです。それは動いている資本ではなく、コミットされた資本の指標です。

ここから3つの引用ルールが導かれます。

• この数値は「アナウンスされたキャパシティ」または「コミット資本」と呼び、決して「流動性」「取引量」「TVL」とは呼ばないこと
• スナップショットの日付とエクスプローラー名を明記すること。第1節で示した通り、同じ日でも2つのエクスプローラーの数値が1,700 BTCも食い違うことがあります
• そして、スループット、アダプション、成長に関する主張をこの数値の上に構築しないこと。公開記録はそうした主張を裏付けることも反証することもできません。

第4節で述べた「解決策」が実用段階に達し信頼を得るまでにはまだ何年もかかり、プロービングも1つのチャネルの瞬間の残高しか復元できません。それらの状況が変わるまで、キャパシティのデータが裏付けられるのはここまでです。キャパシティは串全体であって、自分側の珠ではないのです。

同じ混乱は、一段上のレベル、すなわち第3節の4つ目の誤解にもそのまま当てはまります。キャパシティ加重の中心性は、この誤りがAmbossの「Performance」タブや類似のリーダーボード上で「どのノードが重要か」の代理指標として現れたバージョンです。あらゆる指標で上位にランクされながら、実際には何ヶ月も何も転送していないノードがあり得ます。

本シリーズの次稿では、こうしたランキングを正面から分解します。媒介中心性、近接中心性、固有ベクトル中心性、次数中心性がそれぞれ数学的に何を捉えているのか。そのうちどれがあるとすれば、実際のルーティングボリュームや手数料収益と相関するのか。そして、手数料を最適化しようとするルーティングノード、確実な送金を最適化しようとするウォレット、プライバシーを最適化しようとするオペレーターといった、それぞれの用途にどの指標が適しているのか。キャパシティ加重ランキングが答えているのは資本についての問いであって、読者がこの手のランキングを見るときに実際に知りたいと思っている問い、「どのノードが役に立つのか」には一度も答えていないのです。

6. チャネルが実際に公開している情報

技術的な内訳を知りたい読者向けのセクションです。それ以外の方はここで読み終えて構いません。

ライトニングはゴシッププロトコル、すなわちノードがネットワークトポロジーを共有するためのピアツーピア・ブロードキャストシステムを採用しています。公開記録を構成するメッセージタイプは3種類です。

• channel_announcement: チャネル開設時にブロードキャストされます。short channel ID(SCID)、両ノードの公開鍵、署名を含みます。
• channel_update: ノードがルーティングポリシーを更新するたびにブロードキャストされます。手数料レート、支払い額の上限・下限、タイムスタンプを含みます。
• node_announcement: 接続可能なノードによってブロードキャストされます。公開鍵、エイリアス、IP(Internet Protocol)またはTorアドレス、プロトコル機能を含みます。

channel_announcementが検証されると、ノードはオンチェーン上の資金提供トランザクションを参照し、そのアウトプット値を読み取ります。この値がキャパシティであり、あらゆるダッシュボードが表示している数値です。

公開記録が開示しているすべての情報(BOLT 7: P2P Node and Channel Discovery):

公開記録が開示していない情報:

公開記録はポリシーデータについては豊富である一方、パフォーマンスについては何一つ含んでいません。トラフィックも、ボリュームも、方向別のフローも一切ありません。経済的に最も意味のある量である残高配分は、すべてのメッセージタイプから欠落しています。それは最初のライトニング仕様の時点から存在せず、現在に至るまでずっと存在しないままです。

これは見落としではありません。

出典: mempool.space Lightning Explorer(2026年6〜7月の数値);Tikhomirov et al., arXiv:2004.00333(残高プロービング);arXiv:2512.12095(TEE + zkTLS残高アテステーション);Valko and Marx Gómez, arXiv:2606.20566(キャパシティはノードの年齢や利用実績ではなく接続性によって決まる);Spark(プライベートチャネルのキャパシティ推計);BOLT 7(ゴシッププロトコル仕様)。