Keysendとは？インボイスを発行せず送金する方法

三倉大司 • 2026年09月28日

一般的にライトニングネットワーク（以下、ライトニング）はプル型の送金です。

ビットコインの受取人側がインボイスを発行し、支払人に請求をすることで送金が行われる構造をしています。

プル型の送金とは対照的にライトニングにはマニアック機能としてプッシュ型の送金も存在します。その中で「Keysend」という機能はインボイスを必要とせず、支払人が自発的に相手の公開鍵を利用することで送金を行うことが可能です。

本稿ではライトニングの送金方法の一種としてKeysendの仕組みや使用方法ならびにユースケース、懸念事項などをまとめます。

Keysendの仕組みと送金の流れ

Keysendの仕組みはとてもシンプルです。通常のライトニングの送金では受取人がプリイメージを生成するのに対して、Keysendでは支払人がプリイメージを生成します。支払人はプリイメージを受取人宛ての送金データに埋め込むことで、送金を受け取った受取人のノードはプリイメージを使ってビットコインを獲得することができます。

図で説明すると以下の通りです。

アリスはプリイメージを作成し、ボブしか見ることができない送金データに埋め込んでおきます。送金はプリイメージを利用したロックシステム（HTLC：Hash-Time-Lock-Contract）により各チャネルでロックされます。最終的にボブは送金データからプリイメージを知ることができるため、そのプリイメージでロックを解除することで決済が完了するという仕組みです。

ライトニングの送金データはマトリョーシカのような入れ子構造をしています。中継ノードは玉ねぎの皮を剝くように外側のデータのみを取得してバケツリレーを行っているため、この仕組みを「オニオンルーティング」と呼んでいます。

中継ノードAはオニオンルーティングにより送金の前後を知ることはできますが、送金がどこから来てどこへ送られるのか、つまり図の場合はボブが最終的な受取人であることは分かりません。

Keysendの受信方法

ライトニングノードには複数の実装が存在し、実装間の設計思想などにより若干の違いが存在するので、本稿では代表的な実装の1つであるLND（Lightning-Network-Daemon）を例にKeysendの受信・送信方法を解説します。

LNDの場合はlnd.confファイルを以下のように編集することでKeysendを有効にするか、無効にするかを管理することができます。

accept-keysend=true

accept-amp=true

💡

AMPはAtomic-Multi-Path Paymentsの略です。1回の送金を複数の経路に分割することが可能で、各経路ごとに異なるプリイメージとペイメントハッシュを利用し、受取人が全パーツを揃えて初めて秘密値（ルートシード）が復元され一括で送金が完了します。

GUIで設定する場合は以下の通り。

Keysendの機能自体を有効にしたい場合はaccept-keysend=trueのみで足りますが、大きな金額などを複数に分割して受け取ることで送金の成功率を上げたい場合はAMPも有効にしておくといいでしょう。

Keysendの送金方法

LNDでは以下のコマンドよりKeysendを送金することができます。

lncli sendpayment --dest <destination public key> --amt <amount> --keysend

destination public keyには相手ノードの公開鍵、amountには金額をsats単位で書き込みます。

なおライトニングノードの公開鍵を知りたい場合はamboss.spaceというサイト内でノード情報を検索することができるのでぜひご活用ください。

またAMPを利用する場合は以下のコマンドとなります。

lncli sendpayment --dest <destination public key> --amt <amount> --amp

メッセージを添付したい場合は--data フラグを利用します。--data フラグは<record_id>=<hex_value>の形式となっており、メッセージのレコードIDは一般的に34349334が使われます。

仮に「bitcoin-research」というメッセージを添付したい場合はUTF-8でバイト列にしたのち、16進数にて626974636f696e2d7265736561726368と変換することで以下のコマンドを作成します。

lncli sendpayment --dest <destination public key> --amt <amount> \
--data 34349334=626974636f696e2d7265736561726368 --keysend

詳しいレコードIDについてはこちらをご覧ください。

Keysendのユースケース4例

Keysendのユースケースとしてはどのようなものがあるのでしょうか。本稿では4つの例をピックアップして紹介します。

チップや寄付

チップや寄付は一番わかりやすいユースケースだと思います。クリエイターやオープンソース開発者、配信者などがビットコインでチップを受け付ける際にインボイスを必要としないという特徴はとても有用です。

一方で公開鍵を扱う必要があるため誤入力などが起きる可能性もあり、UXの面ではライトニングアドレスの方が優位だと思います。

広告や宣伝

受取人やネットワークにとっては少し迷惑ですが広告や宣伝としてのユースケースも存在します。広告主にとって送金相手は不特定多数でも問題がないため、公開鍵のみで送金が行えるKeysendはうってつけの方法と言えます。

ネットワーク帯域が謎の広告に使われたり、受取人のインバウンドキャパシティが無断で使用されるというデメリットはあるものの、お金を使って広告を打っているという面では問題はないという考え方もあるのでしょう。

勝手に送金されたくない場合は受信設定をオフにすればいいだけなので、あくまでユーザーの自由というのが良いと思います。

ストリーミングSats（Podcasting 2.0）

筆者自身も記事を書く際に初めて知ったユースケースなのですが、リスナーが音声や動画を再生している間に一定間隔で自動的にビットコインを少額送り続けるという仕組みを利用したシステムがあるようです。

Podcasting 2.0というのはPodcast Indexが主導するオープン仕様で、その目的はポッドキャストのエコシステムにおいて番組に関するあらゆる情報を特定のアプリやホスティング会社に所有されることなく配信をすることのようです。

Keysendはカスタムレコードを使うことも可能なので、番組名や再生位置などをメタデータとして付与できるところが相性いいのだと思います。

NostrでログインすることができるFountainでも利用することができるそうなので気になる方はぜひ使ってみてください。

リバランス

バランスが偏っているチャネルを調整することをリバランスと言い、自分自身に送金を行い円環状に流動性を移動させてリバランスを行うことをCircular Rebalanceと言います。

ノードオペレーターはKeysendを利用することでCircular Rebalanceを行うことが可能です。なおKeysendを利用したリバランスは一般的な方法ではないため、ユースケースの1つとして紹介しました。

通常のCircular Rebalanceはlncliで手動で行う方法やBoSなどの専用ツールを使う方法があります。詳しくは以下の過去記事をご覧ください。

Keysendの制限事項とセキュリティに関する考慮事項

Keysend特有の懸念点がいくつか存在するので最後に簡潔にまとめます。

インボイスがないことによる制限

支払人が作成したプリイメージによる一方的な送金であるため、正式なインボイスは存在しません。そのため送金が問題なく完了したのかを第三者に証明する手立てがなく、またレシートも存在しません。

例としてECサイトで商品を購入した場合を考えます。

ECサイト運営者に「決済が完了していない」と言われた際、通常のインボイス送金であれば「サイト側の署名がついたインボイス」と「決済が完了した時に得たプリイメージ」を提示することができます。このときプリイメージは決済完了時にECサイト側により送られるためインボイスと組み合わせることで支払いの証明となります。

一方でKeysendの場合は送信者自信が作成したプリイメージであるため、支払いを行っていない場合もプリイメージを手元に持っていることになります。つまり送信者がプリイメージを提示しても支払いの証拠とは言えず、ECサイト側の署名がついたインボイスもないため、支払いを客観的に証明する手段がありません。

さらに、インボイスには入力ミスを検知する仕組みがありますが、Keysendでは宛先の公開鍵を直接扱うため、打ち間違いに気づく仕組みがありません。ただし、実在しない公開鍵やKeysendに対応していないノードが宛先の場合は送金自体が失敗するため、資金が失われることはありません。注意すべきは、別の実在するノードの公開鍵を誤ってコピーしてしまったケースで、この場合は送金が成立してしまい、取り戻すことはできません。

インバウンドキャパシティが消費される

ルーティングノードを運用する上でインバウンドキャパシティは非常に重要な役割を担います。しかしKeysendを有効にすることでインバウンドキャパシティが不特定多数の送金により消費されることは念頭に置くべき事項です。

プライベートチャネルのみのノードはKeysendを受け取りにくい

Keysendの支払人は、公開されているチャネル情報をもとに経路を探索します。そのため、公開チャネルを持たずプライベートチャネルのみで運用しているノードは、通常は第三者からKeysendを受け取ることができません。このようなノードに送金したい場合は、受取人がルートヒント（プライベートチャネルの情報）を含めたインボイスを発行するのが一般的です。

ただし、通常のインボイスは1回限りのため、支払いのたびに受取人が発行し直す必要があり、Keysendのように支払人が自由に送金することはできません。そこでLNDでは、ルートヒントを含めたAMPインボイス（lncli addinvoice --amp --private）を発行して公開しておくことで、有効期限内であれば同じインボイスに何度でも支払えるため、Keysendに近い使い方ができます（支払人側もAMPに対応している必要があります）。

スパムが増える可能性

許可を必要とせずに送金を行うことが可能であるためスパムとして利用されることもあります。望まない送金やメッセージによりノードのデータベースが増えることを懸念するのであれば、設定にて受信をオフにするのが賢明でしょう。

BOLTの仕様にはない点

実はKeysendという仕組みはLNDの実験的な機能から生まれた仕組みであるため、BOLTとして標準化はされておらず、実装間に若干の差が生じます。一方でCore LightningやLDKなど複数の実装で使われているため現在はBOLTを補完する枠組みであるbLIPにて仕様が文書化されています。

bLIP-3「Keysend」はステータスがActiveで、すでに広く使われている方式をドキュメント化し、新しい実装が既存の実装をリバースエンジニアリングしなくても済むようにすることが目的と明記されています。

まとめ

Keysendは、受取人のインボイスなしで、公開鍵だけを使ってライトニングネットワーク上で送金できるプッシュ型の機能です。通常とは逆に、支払人がプリイメージを生成して受取人宛ての送金データに埋め込み、受取人がそれを使ってロックを解除することで決済が完了します。

LNDではaccept-keysend=trueで受信を有効にでき、lncli sendpayment --keysendで送金できます。チップや寄付、広告や宣伝、ストリーミングSats（Podcasting 2.0）、Circular Rebalanceなど、インボイスなしで手軽に送れる点を活かしたユースケースがあります。

一方で、レシートがなく送金証明できないこと、インバウンドキャパシティが消費されること、プライベートチャネルのみのノードはKeysendを受け取りにくいこと、スパムに使われうること、BOLTで標準化されておらず実装間に差があることには注意が必要です。

三倉大司

大学では量子コンピュータのゲート方式を中心に、QAOAを用いた問題解決手法の研究を行っていました。また、GPT をはじめとする Transformer アーキテクチャにも関心を持ち、機械学習モデルの構造理解や応用に取り組んできました。現在は日本ビットコイン産業株式会社の R&D 部門に所属し、主に Lightning Network（LN）関連技術の調査・研究開発を担当しています。特に、LN におけるネットワークのデータ分析やルーティング効率改善に関するテーマに興味を持ち研究しています。