# トランザクションの深層 Publisher: ビットコイン図書館 (KK siiiiiixth) — https://bitcoin.ne.jp ## トランザクションの深層 URL: https://bitcoin.ne.jp/learn/transactions URL role: Self-canonical for this Japanese representation English counterpart URL: https://bitcoin.ne.jp/en/learn/transactions Slug: transactions Language: ja First published: 2025-12-01 Last updated: 2026-10-10 Last verified: 2026-10-09 Description: UTXOモデル、トランザクション構造、署名検証、手数料（RBF・CPFP）、確認と最終性、SegWitの影響まで——口座残高を持たないビットコイン送金の全メカニズムを技術的に解説する。 ビットコインには銀行口座のような残高の概念がなく、未使用トランザクション出力（UTXO）の集合として管理される。本稿はトランザクションの構造・検証プロセス・手数料の仕組み（RBF・CPFP）・確認の考え方・SegWitの影響までを技術的に解説する。 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秒でつかむ ビットコインに「口座残高」はありません。ウォレットが見せる残高の裏に並んでいるのは、まだ使われていない出力の小片です。 たとえ: 財布から何枚かの硬貨を選び、支払先とお釣りに分ける。その姿を思い浮かべると、入力・出力・UTXOの流れがつかめます。 事実との境界: UTXOは物理的なコインではなく、条件を満たせば使える台帳上の出力です。手数料は送る金額ではなく、取引のデータの大きさと市場の需要で決まります。 読み進める道: [UTXOを選ぶ](https://bitcoin.ne.jp/learn/transactions#utxo-model) → [Scriptと署名で鍵を開ける](https://bitcoin.ne.jp/learn/transactions#tx-structure) → [mempool・手数料・承認](https://bitcoin.ne.jp/learn/transactions#fees) 読後にわかること: ブロックエクスプローラーの一行を、入力・お釣り・手数料・承認という物語として読めるようになります。 ### UTXOモデル：口座残高ではない Section URL: https://bitcoin.ne.jp/learn/transactions#utxo-model ビットコインには「口座残高」という概念がありません。代わりにUTXO（Unspent Transaction Output＝未使用トランザクション出力）モデルを使います。 「残高」とは、自分のアドレスに紐づくすべての未使用出力の合計です。100円玉3枚と500円玉1枚を持っているようなもので、「残高800円」という抽象的な数字ではなく、具体的な「コイン」の集まりです。 送金時は、一つ以上のUTXOを「入力」として消費し、新しい「出力」（受取人への送金 + お釣り）を生成します。消費されたUTXOは使用済みとなり、二度と使用できません。 このモデルには利点があります。二重支払いを検出しやすく、並列に処理でき、プライバシーも管理しやすい（コインコントロール）という点です。銀行口座モデルとは根本的に異なる考え方に立っています。 [Figure: utxo-flow — ビットコインの送金は口座残高を書き換えるのではなく、手持ちの UTXO を丸ごと使い切って新しい UTXO（送金分とお釣り）を作り直す操作で、入力と出力の差額がそのまま手数料になる。] ### トランザクション構造 Section URL: https://bitcoin.ne.jp/learn/transactions#tx-structure バージョン番号（4バイト）：現在は2が主流です。OP_CHECKSEQUENCEVERIFY（相対タイムロック）を使う場合はバージョン2以上が必要になります。2024年10月のBitcoin Core 28.0以降は、未確認トランザクションの連鎖の形を制限するバージョン3（TRUC、BIP-431）も標準的な中継対象に加わりました。 入力（TxIn）：前のトランザクションの出力への参照。「前のトランザクションハッシュ」（32バイト）、「出力インデックス」（4バイト）、「scriptSig」（署名と公開鍵を含む解錠スクリプト）、「シーケンス番号」（4バイト）で構成されます。 出力（TxOut）：送金先と金額の指定。「金額」（8バイト、satoshi単位）と「scriptPubKey」（施錠スクリプト）で構成されます。 ロックタイム（4バイト）：指定したブロック高またはタイムスタンプまで、トランザクションが有効にならないという条件を設定できます。 代表的な出力の型：P2PKH（1で始まるレガシー）、P2SH（3で始まる。マルチシグやネストSegWitを含む）、P2WPKH／P2WSH（bc1qで始まるネイティブSegWit）、P2TR（bc1pで始まるTaproot）。SegWit以降、署名が何を対象に計算されるかはBIP-143で再定義されています。 SegWitトランザクションの場合、署名データ（witness）がトランザクション本体から分離されます。トランザクションID（txid）の計算からwitnessが外れ、witnessを含む全体のハッシュはwtxidとして別に扱われるため、第三者が署名の書き方を変えてもtxidは変わりません。これがトランザクション展性（malleability）解決の中身であり、同時にブロック容量も実質的に拡大しました。 ### トランザクション検証プロセス Section URL: https://bitcoin.ne.jp/learn/transactions#tx-validation レガシー（P2PKHなど）の検証は2段階で行われます：①入力のscriptSigを実行 → ②参照される出力のscriptPubKeyをscriptSigの結果を使って実行。最終的にスタックの先頭がtrue（非ゼロ）であれば有効です。ネイティブSegWit（bc1q／bc1p）ではscriptSigは空で、署名の検証はwitness側に置かれたデータに対して行われます。 標準的なP2PKH検証の流れ：署名と公開鍵がscriptSigに含まれる → 公開鍵がハッシュ化され、scriptPubKey内のハッシュと一致するか確認 → 署名が有効か検証 → すべて満たされれば取引は有効です。 マイナーはメモリプール（mempool）内の未確認トランザクションから、手数料の高いものを優先してブロックに含めます。 重要：入力の合計値から出力の合計値を引いた差額は、すべて取引手数料としてマイナーに渡ります。消えてなくなるわけではありませんが、送信者が取り戻すことはできません。お釣り用の出力を作り忘れると、入力の残り全額をそのまま手数料として支払ってしまうことになります。 ### 手数料の仕組み Section URL: https://bitcoin.ne.jp/learn/transactions#fees 前提として、本節で扱うRBF・CPFP・手数料の優先順位は、いずれも各ノードが個別に選べる中継とメモリプールのポリシーであり、ブロックの有効性を決める合意ルール（コンセンサスルール）ではありません。ソフトフォークを経ずに既定の挙動が変わることがあるのは、このためです。 ビットコインの取引手数料は送金額ではなく、トランザクションのデータサイズ（バイト数）に基づきます。1 BTC の送金も0.001 BTCの送金も、同じサイズなら同じ手数料です。 手数料率は「sat/vB」（satoshi per virtual byte）で表されます。SegWitトランザクションはwitnessデータが割引されるため、同じ機能でも手数料が安くなります。 RBF（Replace-By-Fee）：手数料が低すぎて確認されないトランザクションを、同じ入力を使うより高い手数料の取引で置き換える仕組みです。歴史的にはBIP-125のオプトイン方式が使われ、入力のいずれかのシーケンス番号が0xFFFFFFFE未満のときだけ置き換えの対象になっていました（0xFFFFFFFEはロックタイムを有効にしつつ置き換えを拒む値として、多くのウォレットが標準的に使います）。 その後、2024年10月のBitcoin Core 28.0でfull-RBFが既定となり（-mempoolfullrbfの既定値が0から1へ変更）、2025年4月の29.0ではオプション自体が削除されました。2026年8月時点の既定構成のノードでは、シグナリングの有無にかかわらず未確認トランザクションは原則すべて置き換えの対象になります。「RBFをシグナリングしていないから0確認でも安全」とは言えません。 CPFP（Child-Pays-For-Parent）：低手数料の未確認トランザクションの出力を使って、高手数料の子トランザクションを作成。マイナーは親子セットを一緒にマイニングするインセンティブが生まれます。Bitcoin Core 28.0以降は「1親1子（1P1C）」のパッケージリレーが加わり、親単体ではメモリプールの最低手数料率に届かない場合でも、子と組で評価されて伝播できるようになりました。2026年4月の31.0では、中継の最低手数料（-minrelaytxfee）を下回る親（手数料0を含む）もこの対象に広がりました。 ### 確認と最終性 Section URL: https://bitcoin.ne.jp/learn/transactions#confirmations 0確認：トランザクションは送信されたがまだブロックに含まれていない状態。二重支払いのリスクがあります（レース攻撃、フィニー攻撃）。前節のとおり2025年以降のBitcoin Coreではfull-RBFが無条件なので、未確認の取引はいつでも別の取引で置き換えられうる前提で扱うべきです。 1確認：最初のブロックに含まれた状態。少額取引にはほぼ十分ですが、ベクター76攻撃のリスクが残ります。 6確認：慣例的に「最終確定」とみなされる基準です。ホワイトペーパー§11の計算では、ネットワークハッシュレートの10%を持つ攻撃者が6確認を覆せる確率は約0.024%とされています（同じ表で0.1%を下回るのは5確認からです）。ただしこれは攻撃者のハッシュパワーが一定で外部から調達もできないというモデル上の前提での数値であり、ハッシュパワーを借りられる現実の攻撃者にそのまま当てはまるわけではありません。 高額取引でより多くの確認を待つ運用もありますが、「100確認」という統一規格があるわけではなく、各事業者の内規によります。合意ルールとして100ブロックの待機が定められているのは、マイニング報酬（coinbase出力）が使えるようになるまでの期間（coinbase maturity）であり、通常の送金の確認数とは別の話です。確認数の選択は、取引金額と相手の信頼度に応じたリスク管理です。 平均確認時間は約10分（1ブロック）ですが、実際にはブロック生成間隔にはばらつきがあり、数秒〜1時間以上になることもあります。 ### SegWitとその影響 Section URL: https://bitcoin.ne.jp/learn/transactions#segwit Segregated Witness（SegWit、BIP-141）は2017年8月24日（ブロック481,824）に有効化されたソフトフォークで、ビットコインの最も重要なプロトコルアップグレードの一つです。 署名データ（witness）をトランザクション本体から分離し、従来の「1MB」というサイズ上限に代えて「ブロックウェイト400万WU（ウェイトユニット）以下」という別軸の上限を導入しました。witness以外のデータは1バイト＝4WU、witnessデータは1バイト＝1WUと数えるため、witnessの多いブロックほど多くの取引が入ります。実際のブロックはおおむね1.5〜2.5MB程度で、4MBに達することはまれです。手数料計算に使うvsize（仮想サイズ）は、ウェイトを4で割った値です。 トランザクション展性（malleability）の問題も解決しました。その結果、Lightning Networkなどの支払いチャネル技術を安全に構築できるようになりました。 ネイティブSegWitのアドレスは「bc1q」で始まるBech32形式です。3で始まるP2SHの中にSegWitを埋め込む「ネストSegWit」も同じ手数料割引を受けられます。Taprootで導入された「bc1p」はwitness version 1のアドレスで、Bech32を改良したBech32m（BIP-350）が使われます。 普及率は集計の定義によって変わります。「SegWitの入力を1つ以上使うトランザクションの割合」を基準とする集計では、mainnet.observer の日次データによる2026年前半の月平均が約94〜97%、Glassnodeの「SegWit Adoption」指標が2026年3月23日時点で96.1%でした。一方、トランザクションではなく使われた入力の数を基準とするGlassnodeの「SegWit Utilization」指標は、同日時点で91.5%と数ポイント低くなります。単一の数字を覚えるより、どの定義に基づく数字かを確かめて読むことが重要です。 ### 主な参照元 - Bitcoin Developer Reference — Transactions: https://developer.bitcoin.org/reference/transactions.html - BIP-141 — Segregated Witness (SegWit): https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki - BIP-125 — Opt-in Full Replace-by-Fee (RBF): https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki - BIP-350 — Bech32m（witness version 1 以降のbc1pアドレス）: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki - Bitcoin Core 29.0 リリースノート（-mempoolfullrbf の削除＝full-RBF の標準化、2025年4月）: https://bitcoincore.org/en/releases/29.0/ - mainnet.observer — SegWit入力を使うトランザクションの割合: https://mainnet.observer/charts/transactions-spending-segwit/ - Glassnode Studio — SegWit Adoption / Utilization（BTC）: https://studio.glassnode.com/charts/transactions.SegwitAdoption?a=BTC - Bitcoin Core 31.0 リリースノート（1親1子パッケージリレーの最低中継手数料未満への拡張、2026年4月）: https://bitcoincore.org/en/releases/31.0/ - Bitcoin Whitepaper（2008年）: https://bitcoin.org/bitcoin.pdf ### 改訂履歴 - 2026-10-09: 1親1子パッケージリレーの条件（28.0はメモリプール最低手数料率、31.0で最低中継手数料未満へ拡張）とSegWit普及率の値を是正。 - 2026-08-16: RBFの閾値をBIP-125（0xFFFFFFFE未満）に訂正しfull-RBF既定化（Bitcoin Core 28.0／29.0）を追記、6確認の確率をホワイトペーパー§11に一致させ、SegWit普及率・ウェイト上限・検証モデルの記述を定義付きに修正