ビットコインを送る — 受け取りから着金確認までの実務
アドレスの受け取りと検証、sat/vB での手数料選択、送信前チェック、承認待ちと着金確認、止まったときのRBF・CPFP、テスト送金まで。取り消せない送金を手順で安全にするための実務を一次情報で整理します。記述は2026年8月時点。
約18分
要点
ビットコインの送金は「受け取る側が宛先を示し、送る側が自分のウォレットからそこへ送る」という向きで成立し、いったんネットワークに流れると原則として取り消せません。本ページはアドレスの受け取りと検証、sat/vBによる手数料の選び方、送信前の最終確認、承認と着金の見方、止まったときのRBF・CPFP、テスト送金までを、特定の製品を推奨せずに手順として整理します。
送金の全体像 — 5つのステップ
- ビットコインの送金は、カード決済とは成立の順序が逆です。受け取る側が宛先——オンチェーンならアドレス、Lightningならインボイス——を示し、送る側が自分のウォレットからそこへ送ります。カード番号のように、支払う側が相手に渡す情報はありません。
- 手順は5つに分けられます。
| ステップ | 何をするか | 取り返しがつくか |
|---|---|---|
| 1. 宛先を受け取る | 相手からアドレスまたはQRコードを受け取る | やり直せる |
| 2. 金額と手数料を決める | 送る額と手数料率(sat/vB)を選ぶ | やり直せる |
| 3. 内容を確認して署名する | 宛先・金額・手数料をウォレットの画面で確かめる | ここが最後の分岐点 |
| 4. ネットワークへ送信する | 署名済みの取引をブロードキャストする | 未承認のうちは限定的に置き換えられる場合がある |
| 5. 承認と着金を確認する | ブロックに取り込まれるのを待ち、相手側で受領を確認する | 原則として取り消せない |
- 重要なのは、実質的な安全確認がステップ3までで終わるという点です。bitcoin.orgが明記しているとおり、送られた取引は取り消せず、受け取った人が送り返す以外に戻す方法はありません。ステップ4以降にできることは、手数料を上げて急がせるか、待つかだけです。
- この非対称性は欠陥ではなく、中間者を置かない設計から必然的に導かれる帰結です。背景は「なぜ失うと取り戻せないのか」で扱っています。以下では、ステップごとに実際の確認手順を見ていきます。
宛先を受け取る — アドレスの形式とQRコード
- ビットコインアドレスは、公開鍵を一方向のハッシュで短くまとめた文字列です。受け取りのために公開してよい値で、これ自体を他人に知られても資産は動きません。鍵の3層構造は「ウォレットと安全管理」で扱っています。
- 実際に目にする形式は主に4種類です。用途は同じで、違いは手数料の計算に効くサイズと、対応しているウォレットの範囲です。
| 先頭 | 形式 | 補足 |
|---|---|---|
| 1 | P2PKH(レガシー) | 最初期からの形式。同じ送金内容でもサイズが大きくなりやすい |
| 3 | P2SH | マルチシグやネストSegWitを含む。ネストSegWitはSegWitの手数料割引を受けられる |
| bc1q | ネイティブSegWit(P2WPKH/P2WSH) | Bech32形式。witnessデータが割引されるため同じ内容なら手数料が軽い |
| bc1p | Taproot(P2TR) | witness version 1。Bech32を改良したBech32m(BIP-350)が使われる |
- 受け取る側が守るべき原則が1つあります——アドレスを使い回さないことです。現代のウォレットはHD(階層的決定性)構造を採っており、受け取りのたびに新しいアドレスを自動生成します。使い回すと支払い履歴が1つの識別子に紐づくうえ、公開鍵の露出も増えます。理由は「ビットコインのプライバシー」で扱っています。
- QRコードの中身は、多くの場合BIP-21で定義された `bitcoin:` から始まるURIです。アドレスに加えて金額(amount)、宛名(label)、メッセージ(message)を含められる形式で、金額まで含まれていれば手入力の機会がその分減ります。ただしURIの金額も相手が作った値である以上、ウォレットの画面に表示された金額を自分で読むという手順は省けません。
- なお、Bech32とBech32mは大文字と小文字の混在を認めていません。QRコードの効率のためにアドレスがすべて大文字で表示されることがありますが、小文字の同じ文字列と同一のアドレスです。
宛先を検証する — 何が自動で弾かれ、何が弾かれないか
- アドレス形式には誤りを検出する仕組みが組み込まれていますが、守備範囲には限界があります。どこまでが自動で、どこからが人間の目視なのかを知っておくことが重要です。
- bc1qで始まるBech32形式はBIP-173で定義され、4文字以内の置換誤りは検出され、それ以上の誤りを見逃す確率も10億分の1未満とされています(ただしBIP-173自身が後に、5文字未満の連続した挿入・削除に対しては必ずしも堅牢でないと開示しています)。Taprootのbc1pで始まるアドレスは、この弱点を修正した後継規格BIP-350のBech32m形式が同じ役割を担います。
- 一方、チェックサムが決して弾かないものがあります——正しく入力された他人のアドレスです。単純なタイプミスは止まりますが、そもそも別人の有効なアドレスを渡された場合、形式上は何の問題もありません。誤送金が「知識ではなく手順で防ぐ種類の失敗」と言われるのはこのためです。
- 実務上の確認は3段階です。第一に、アドレスは手入力せずコピー&ペーストかQRコードを使う。第二に、貼り付けた文字列の先頭と末尾の数文字を目視で照合する。クリップボードの内容を書き換えて送金先をすり替えるマルウェアが実在するため、「コピーしたのだから正しい」とは言い切れません。第三に、ハードウェアウォレットを使う場合は必ず機器側の画面で宛先を確認します。パソコンやスマートフォンの画面はマルウェアに書き換えられる可能性がありますが、機器の画面は独立しているためです。
- もう1つ、形式の検証ではまったく捉えられない層があります——その宛先を送ってきたのが誰かという問題です。SNSのメッセージや「サポート」を名乗るアカウントから送られてきたアドレスは、形式が正しくても宛先として正しいとは限りません。この層の見分け方は「ビットコイン詐欺の手口と自衛」で扱っています。
金額と手数料を決める — sat/vB とお釣り
- ビットコインの取引手数料は送金額ではなく、トランザクションのデータサイズに基づきます。1 BTCの送金も0.001 BTCの送金も、同じサイズなら同じ手数料です。単位は「sat/vB」(satoshi per virtual byte)で表され、vsize(仮想サイズ)はブロックウェイトを4で割った値です。
- 手数料が「引かれる」仕組みも押さえておく価値があります。入力の合計値から出力の合計値を引いた差額が、そのまま手数料としてマイナーに渡ります。手数料という独立した項目があるのではなく、余りがそれになるという形です。通常のウォレットは残額を自動的にお釣りとして自分の別のアドレスへ戻しますが、手動で取引を組み立てる場面ではお釣り出力の作り忘れがそのまま全額の支払いになります。構造は「トランザクションの深層」で扱っています。
- 相場は固定ではありません。2026年8月15日時点でmempool.spaceが示す推奨手数料は最速帯でも1 sat/vB(実質的な下限)でしたが、ブロックスペースが混み合う局面ではこれが何十倍にも跳ね上がります。現在の水準は、本サイトの「いまのビットコイン」でも週次で確認できます。
- 選び方は目的次第です。急がないなら低めの手数料で待つ、期限があるなら推奨帯かそれ以上を選ぶ。後述のとおり、置き換え送信に対応したウォレットであれば、低く設定して様子を見てから上げるという運用も可能です。逆に、極端に低い手数料は中継そのものが行われない場合があります。
- 出力の大きさにも下限の感覚が要ります。極端に小さい額の出力は、標準的な中継の対象から外れることがあります。少額を何度も送る用途は、そもそもオンチェーンではなくLightningの側が適しています。
送信前の最終確認 — 取り消せない一線
- 署名の直前が、やり直せる最後の瞬間です。以下は、見落とすと何が起きるかを対応させたチェックリストです。1つでも確認できないものがあれば、そこで止めてください。
| 確認すること | 見落とすと起きること |
|---|---|
| 宛先の先頭と末尾の数文字 | 他人に届く。取り戻せるかは相手の善意次第 |
| ネットワーク(チェーン)の選択 | 取り出せる人が誰もいない状態になることがある |
| 金額の桁と単位(BTC か sat か) | 意図しない額がそのまま確定する |
| 手数料率(sat/vB) | 滞留して届かない、または過大な支払いになる |
| 相手が本当に相手か(連絡経路) | 詐欺の被害になる。形式の検証では防げない |
- ネットワークの選択は特に事故が多い箇所です。同じ「BTC」という表記でも、ビットコインのネットワークと、他のチェーン上で発行された別のトークンは、まったく別の宛先です。取引所から出金するときは通貨名だけでなくネットワーク名も確認してください。
- 返金についても、期待の水準を合わせておく必要があります。カード決済のチャージバックにあたる仕組みは、プロトコルの側には存在しません。返金は、受け取った側が別の取引として送り返すという形でしか実現しません。
- そして、急かされているときは止まるのが最も効きます。相手が急がせるのは、第三者に相談される前に決着させたいからです。送金の前に一度誰かに話すという約束を1つ決めておくだけで、段階を踏んで相手を孤立させるタイプの手口は成立しにくくなります。
送信後 — 承認と着金の見方
- 署名した取引をネットワークへ送信すると、まず各ノードのメモリプール(mempool)に入り、マイナーが手数料の高いものから選んでブロックに取り込みます。ブロックは平均して約10分に1つ生成されますが、間隔にはばらつきがあり、数秒から1時間以上になることもあります。
- 0確認の段階は、まだ確定ではありません。2024年10月のBitcoin Core 28.0でfull-RBFが既定となり、2025年4月の29.0ではこれを無効にするオプション自体が削除されました。2026年8月時点の既定構成のノードでは、シグナリングの有無にかかわらず未承認取引は原則すべて置き換えの対象になります。「RBFをシグナリングしていないから0確認でも安全」とは言えません。
- 確認が積み上がるほど巻き戻しは難しくなります。ホワイトペーパー§11の計算では、ハッシュパワーの10%を持つ攻撃者が追いつく確率は1確認で約20%、6確認では約0.024%まで下がります(同じ表で0.1%を下回るのは5確認からです)。慣習的に6確認が「最終確定」の目安とされるのはこの計算に由来しますが、これは攻撃者のハッシュパワーが一定で外部から調達もできないというモデル上の前提での数値です。
- 着金の確認方法は2つあります。自分のウォレットの残高表示と、トランザクションID(txid)をブロックエクスプローラで照会する方法です。後者は第三者のサービスに依存するため、依存を減らしたい場合は自分のフルノードに問い合わせる形になります。運用方法は「ビットコインのノードを動かす」で扱っています。
- 相手側での反映条件は、プロトコルではなく相手の内規です。取引所への入金であれば必要な確認数は事業者ごとに異なり、店舗での決済では0確認で受け入れる運用も存在します。「何確認で確定か」は、金額と相手に応じたリスク管理の選択であって、統一規格ではありません。
届かない・遅いとき — RBF と CPFP
- 送ったのに届かないとき、原因は3つに切り分けられます。そもそもブロードキャストされていないのか、mempoolにはあるが手数料が低くて順番が来ないのか、ブロックには入っているが相手側の反映を待っているのかです。txidをブロックエクスプローラで引けば、どの段階かはすぐ分かります。
- 手数料が低くて止まっている場合、対処は2つあります。RBF(Replace-By-Fee)は、同じ入力を使うより高い手数料の取引で置き換える方法です。歴史的にはBIP-125のオプトイン方式が使われ、入力のいずれかのシーケンス番号が0xFFFFFFFE未満のときだけ置き換えの対象になっていましたが、前述のとおり現在の既定構成ではシグナリングに関係なく置き換えが可能です。実際に使えるかどうかは、自分のウォレットが置き換え送信に対応しているかによります。
- CPFP(Child-Pays-For-Parent)は、止まっている取引の出力を使って高い手数料の子取引を作り、親子をまとめて取り込ませる方法です。マイナーには親子セットを一緒にマイニングするインセンティブが生まれます。受け取る側からも実行でき(受け取った未承認の出力を使う)、送る側からはお釣りの出力を使います。Bitcoin Core 28.0以降は「1親1子(1P1C)」のパッケージリレーが加わり、親単体では中継の最低手数料に届かない場合でも、子と組で評価されて伝播できるようになりました。
- 前提として、RBF・CPFP・手数料の優先順位は、いずれも各ノードが個別に選べる中継・mempoolのポリシーであり、ブロックの有効性を決める合意ルールではありません。ソフトフォークを経ずに既定の挙動が変わることがあるのはこのためで、相手のノードが自分と同じ設定とは限らない点も含めて理解しておく必要があります。
- 何もせずに放置した場合、ノードは未承認のまま一定期間を過ぎた取引をmempoolから落とします(期間はノードの設定によります)。このとき資金は失われません。使われるはずだった入力は未使用のUTXOのまま残り、あらためて送り直せます。届かないことと失うことは別です。
テスト送金と、つまずきやすい場面
- 高額を送る前には、必ず少額のテスト送金を行い、着金を確認してから本番の送金をします。手数料は余分にかかりますが、取り返しのつかない事故に対する保険料と考えれば安いものです。新しい相手、新しいウォレット、久しぶりの操作——このいずれかに当てはまるときは、金額の大小にかかわらずテスト送金の対象と考えてよいでしょう。
- 取引所からの出金には、オンチェーンの手数料とは別の層があります。出金手数料は事業者が定める固定額であることが多く、ネットワークの混雑と連動しない場合があります。出金の上限、保留の条件、対応するアドレス形式も事業者ごとの内規です。うまくいかないときは、プロトコルの問題ではなく相手の規約の問題である可能性を先に疑ってください。
- Lightningを使う送金は、手順そのものが変わります。受け取る側がBOLT11形式のインボイスやQRコードを提示し、支払いは秒単位で完了します。承認を待つ概念がない代わりに、受け取る側に受信容量(インバウンドキャパシティ)が必要で、経路が見つからなければ失敗します。少額・高頻度に向く一方、まとまった金額や相手が対応していない場合はオンチェーンを使います。仕組みは「Lightning Network入門」、使い分けは「ビットコインで支払う」で扱っています。
- 自分の別のウォレットへ移す場合も、手順はまったく同じです。宛先が自分であっても、アドレスの検証もテスト送金も省略できません。新しいハードウェアウォレットへ移すときは、先にバックアップからの復元を試し、実際に戻せることを確認してから残高を移すのが安全な順序です。
- 日本の税務上の扱いは、送金という操作そのものではなく何をしたかで決まります。国税庁の整理では、課税のタイミングは売却・商品の購入・暗号資産同士の交換・マイニング等による取得時であり、保有しているだけでは課税されません。したがって、支払いに使えば課税上の事象になり得ます。本サイトは個別の税務助言を行いません。詳細は「ビットコインの税金」を、判断は税理士または所轄の税務署に確認してください。
まとめ — 手順で下げられるもの、下げられないもの
- 本ページで扱った内容を、手順で対処できるものとできないものに分けて整理します。
| 論点 | 手順で下げられるリスク | 手順では下げられないもの |
|---|---|---|
| 宛先 | タイプミス、クリップボードのすり替え | 正しく入力された他人のアドレス |
| 金額と手数料 | 桁の誤り、滞留、過払い | 送信後の相場変動 |
| 承認 | 確認数を金額に応じて選ぶ | ブロック生成間隔のばらつき |
| 相手 | 連絡経路の検証、送金前に一度止まる | 相手が約束を守るかどうか |
| 取り消し | 未承認のうちの置き換え(保証なし) | 承認後の取り消し |
- 構造として押さえるべき点は三つです。第一に、送金は取り消せず、返金は受け取った側の任意の送り返しとしてしか実現しないこと。第二に、手数料は送金額ではなくデータサイズに基づくため、少額ほど手数料の比率が重くなること。第三に、何確認を待つかは統一規格ではなく、金額と相手に応じたリスク管理の選択であることです。
- 逆に、本サイトが答えを持たない問いも明確です。どのウォレット製品や取引所を使うべきか、いくら送るべきか、いつ送るべきか。これらは個別の推奨か価値判断であり、教育的な解説の外にあります。
- 本ページは教育目的の解説であり、投資助言でも税務の個別助言でもありません。記述は2026年8月時点のもので、手数料水準やソフトウェアの既定値は変わります。実際に送る時点では、本ページの出典元とウォレットの公式ドキュメントで確認してください。
主な参照元
- ビットコイン白書(§11 — 確認数と巻き戻し確率)
- bitcoin.org — 知っておくべきこと(取引は取り消せない)
- BIP-21 — bitcoin: URI スキーム(QRコードに埋め込まれる形式)
- BIP-173 — Bech32アドレス形式(bc1q/チェックサムの検出能力と、挿入・削除に関する後日の開示)
- BIP-350 — Bech32m(Taprootを含むwitness version 1以降のbc1pアドレス)
- BIP-125 — Opt-in Full Replace-by-Fee(RBF のシグナリング)
- Bitcoin Core 28.0 リリースノート(full-RBF の既定化、1親1子のパッケージリレー、2024年10月)
- Bitcoin Core 29.0 リリースノート(-mempoolfullrbf の削除=full-RBF の標準化、2025年4月)
- Bitcoin Developer Reference — Transactions(入力・出力・手数料の構造)
- mempool.space — 推奨手数料とブロックの公開統計
- 国税庁 — 暗号資産等に関する税務上の取扱い及び計算書について
次に読む
トランザクションの深層約10分前に読む
関連トピック
さらに深める
共有
引用情報 / Citation
- Title
- ビットコインを送る — 受け取りから着金確認までの実務
- Source
- ビットコイン図書館 (bitcoin.ne.jp)
- Canonical URL
- https://bitcoin.ne.jp/learn/sending
- Author
- KK siiiiiixth
- Topic
- sending
- Published / Updated
- 最終検証 / Last verified
- Editorial policy
- https://bitcoin.ne.jp/editorial-policy
- About
- https://bitcoin.ne.jp/about
- License
- 教育目的の引用・要約・索引・AI 学習 すべて許諾
この記事は引用・要約・索引・AI 学習・回答エンジンでの参照を歓迎します。引用時は上記 canonical URL をご利用ください。