はじめに
本記事は AI を使いながら制作を進めたものです。何か誤りなどあればご指摘いただけると幸いです。
Bitcoin は、銀行のような中央管理者がいないにもかかわらず、世界中の参加者が同じ「お金の台帳」を共有できる仕組みです。
一見すると不思議です。
- 誰が「この送金は正しい」と決めるのか
- 同じコインを 2 回使うズルはどう防ぐのか
- ただのデータに、なぜ資産としての価値が生まれるのか
この疑問に答えるのが、Satoshi Nakamoto が 2008 年に公開した論文
Bitcoin: A Peer-to-Peer Electronic Cash System
です。
この記事では、前提知識をできるだけ置かずに、Bitcoin の仕組みを体系的に整理します。
細かい実装差分や歴史的経緯よりも、まず「何がどうつながっているのか」が見えることを重視します。
まず全体像
Bitcoin をひとことで言うと、
中央管理者なしで、世界中の参加者が 1 つの取引履歴に合意する仕組み
です。
そのために必要な要素は大きく 5 つあります。
-
公開鍵暗号
誰がどのコインを使う権利を持つかを証明する -
トランザクション
どのコインを誰に渡したかを表す -
ノード
取引やブロックを検証し、ネットワークに広める -
ブロック
取引をまとめて順番に並べる単位 -
Proof of Work
どの履歴を正しい履歴とみなすかを決める仕組み
この 5 つがつながることで、Bitcoin は動いています。
1. Bitcoin が解決したかった問題
ネット上の普通のデータは、簡単にコピーできます。
たとえば画像ファイルなら、まったく同じものを何枚でも複製できます。
しかし、お金がそれと同じだと困ります。
もしデジタルなお金を簡単にコピーできたら、
- 1 BTC を A さんに送る
- 同じ 1 BTC を B さんにも送る
という不正ができてしまいます。
これを 二重支払い といいます。
銀行のような中央管理者がいる世界では、中央サーバが
「先に届いた送金だけを有効にする」
ことでこの問題を防ぎます。
しかし Bitcoin は、中央管理者なしでそれを実現しようとしました。
そこで必要になったのが、
- 全員が同じ取引履歴を見ること
- その履歴を簡単には書き換えられないこと
- もし意見が割れても、どの履歴が正しいかを決められること
です。
2. Bitcoin に登場する基本概念
ここが一番大事です。
この節の用語が頭に入ると、その後の話がかなり楽になります。
2-1. コインとは何か
Bitcoin の「コイン」は、現実の硬貨のように独立した物体ではありません。
Bitcoin における資産は、
あるトランザクションの出力を使う権利
として表現されます。
つまり「1 枚の BTC コイン」がどこかにあるわけではなく、
ブロックチェーン上に記録された
「この出力はまだ使われていない」
という状態の集合が、あなたの資産になります。
2-2. 鍵とアドレス
Bitcoin では、コインを動かす権利を 秘密鍵 で証明します。
-
秘密鍵
本人だけが持つ、絶対に漏らしてはいけない鍵 -
公開鍵
秘密鍵に対応する公開情報 -
アドレス
公開鍵やその派生情報から作られる受け取り先の表現
送金するときは、秘密鍵で署名します。
受け取る側やノードは、その署名を公開鍵情報から検証します。
重要なのは、
Bitcoin は「名前」ではなく「鍵」で所有権を管理している
という点です。
2-3. トランザクション
トランザクション は、送金の記録です。
ざっくり言えば、
- どのコインを使うか
- 誰に送るか
- いくら送るか
を書いたデータです。
Bitcoin のトランザクションは、主に 入力 と 出力 から成ります。
-
入力
過去の未使用出力を参照して「これを使います」と宣言する部分 -
出力
新しい受け取り先と金額を書く部分
たとえば、
- 自分が 1.2 BTC の未使用出力を持っている
- そのうち 0.8 BTC を相手に送る
なら、出力は普通こうなります。
- 0.8 BTC を相手へ
- 残り 0.399 BTC を自分へ
- 0.001 BTC は手数料
という形です。
2-4. UTXO
Bitcoin を理解するうえで避けて通れないのが UTXO です。
UTXO は Unspent Transaction Output の略で、
「まだ使われていないトランザクション出力」
を意味します。
Bitcoin の残高は、口座残高のように 1 行で管理されているのではなく、
自分が使える UTXO の合計
として表現されます。
つまり Bitcoin の送金とは、
- 既存の UTXO を消費し
- 新しい UTXO を作る
処理だと考えると分かりやすいです。
2-5. ノード
ノード は、Bitcoin のソフトウェアを動かしてネットワークに参加しているコンピュータです。
ノードの役割は主に次の通りです。
- トランザクションを受け取る
- その内容がルールに合っているか検証する
- 正しいものを他のノードへ中継する
- ブロックを受け取る
- ブロックが正しいか検証する
- どのチェーンを正史とみなすか判断する
つまりノードは、
Bitcoin ネットワークの参加者であり、検証者であり、台帳の共有者
です。
2-6. full node
full node は、Bitcoin のルールを自分で全部検証するノードです。
具体的には、
- ブロックをダウンロードする
- 各トランザクションの署名や形式を確認する
- 二重支払いがないか確認する
- ブロック報酬がルールを超えていないか確認する
- 最も累積 work が大きいチェーンを採用する
といったことを行います。
Bitcoin の安全性を本当に自分で確かめたいなら、full node が最も強い立場です。
2-7. miner
miner は、ブロックを作って Proof of Work を計算する参加者です。
ただし、ここは誤解されやすい点です。
miner はネットワークの特別な支配者ではなく、ルールの範囲内で次のブロックを提案する人
です。
miner がどんなブロックでも自由に通せるわけではありません。
最終的にそのブロックを受け入れるかは full node が決めます。
2-8. mempool
mempool は、まだブロックに入っていない未承認トランザクションの置き場です。
誰かが送金を作ると、そのトランザクションはまずネットワークへ流れ、
各ノードの mempool に一時的に保存されます。
miner はその中から候補を選んで、次のブロックに入れます。
ここで大事なのは、
mempool はネットワーク全体で 1 個だけ存在するわけではなく、各ノードがそれぞれ持っている
という点です。
そのため、ある瞬間にどのトランザクションを持っているかはノードごとに少しずれることがあります。
2-9. ブロック
ブロック は、複数のトランザクションをまとめたデータのかたまりです。
ブロックには大きく 2 つの部分があります。
-
ブロックヘッダ
ブロックの要約情報 -
ブロック本体
実際のトランザクション一覧
Proof of Work の対象になるのは主にブロックヘッダです。
2-10. ブロックチェーン
ブロックチェーン は、
ブロックが前のブロックのハッシュを参照しながら連なっている構造です。
Block 1 -> Block 2 -> Block 3 -> Block 4 -> ...
各ブロックは前のブロックに依存しているため、
途中のブロックを書き換えると、それ以降のブロックも全部作り直さなければなりません。
これが改ざん耐性の土台です。
3. Bitcoin の送金はどう進むのか
概念だけでなく、実際に何が起きるのかを流れで見た方が分かりやすいです。
3-1. 送金を作る
まずユーザーがウォレットを使って送金トランザクションを作ります。
このときウォレットは、
- 使える UTXO を選ぶ
- 送り先のアドレスを指定する
- 金額を決める
- 手数料を決める
- 秘密鍵で署名する
という処理を行います。
3-2. ネットワークに流す
作られたトランザクションは、ノードからノードへ中継されて広がっていきます。
各ノードは受け取ったトランザクションに対して、
- 形式が正しいか
- 署名が正しいか
- 参照している UTXO が本当に未使用か
を確認します。
問題がなければそのノード自身の mempool に入れ、他のノードへ転送します。
3-3. miner が次のブロック候補を作る
miner は mempool のトランザクションを見ながら、
次のブロック候補を作ります。
このとき miner は通常、
- 手数料が高いトランザクション
- サイズ効率のよいトランザクション
を優先して選びます。
また、ブロックの先頭には coinbase transaction という特別なトランザクションが入ります。
これはブロック報酬と手数料を miner が受け取るためのものです。
3-4. Proof of Work を計算する
ブロック候補ができたら、miner はそのブロックヘッダに対して Proof of Work を行います。
ここで使うのが SHA-256 です。
Bitcoin では、ブロックヘッダに対して
SHA256(SHA256(block_header))
を計算します。
これを double SHA-256 と呼びます。
miner は nonce などの値を変えながら、
結果のハッシュが難易度条件を満たすまでひたすら試します。
3-5. 条件を満たすブロックが見つかったら配布する
ある miner が条件を満たすブロックを見つけたら、
そのブロックをネットワークへ流します。
他のノードはそれを受け取って検証します。
検証内容は主に次の通りです。
- ブロック構造が正しいか
- Proof of Work が本当に成立しているか
- トランザクションがルール通りか
- 二重支払いがないか
- 報酬がルールを超えていないか
正しければ、そのブロックをチェーンに追加します。
3-6. 承認と confirmations
ある取引がブロックに入ると、その取引は 1 confirmation を得たと言います。
さらにその後ろにブロックが 1 個積まれるごとに、
confirmation 数が増えます。
取引が入ったブロック -> 1 confirmation
その次のブロックが追加 -> 2 confirmations
さらに次が追加 -> 3 confirmations
confirmation が増えるほど、その取引を含む履歴を書き換えるコストが大きくなるため、
一般に安全性は高まります。
4. ハッシュとは何か
Bitcoin を理解するには ハッシュ関数 が重要です。
ハッシュ関数とは、
任意の長さの入力を、固定長の出力に変換する関数
です。
Bitcoin で重要なのは SHA-256 です。
4-1. ハッシュ関数のイメージ
たとえば入力が文字列でも、画像でも、バイナリでも、
SHA-256 は最終的に 256 bit の値を返します。
"hello" -> 2cf24dba5fb0a30e...
"hellp" -> fdd7585e08c4e2af...
入力がほんの少し変わるだけで、出力は大きく変わります。
4-2. ハッシュ関数に期待される性質
Bitcoin 文脈では、次の性質が重要です。
- 同じ入力なら常に同じ出力になる
- 出力から元の入力を見つけるのが難しい
- 少しの変更で出力が大きく変わる
- 計算自体は速い
ハッシュは「暗号化」とは違います。
暗号化は復号が前提ですが、ハッシュは基本的に一方向です。
4-3. なぜ SHA-256 が PoW に向いているのか
Proof of Work では、
- 有効な解を見つけるのは大変
- 見つかった解を検証するのは簡単
であることが重要です。
SHA-256 は、1 回 1 回の試行は速いですが、
「条件を満たすハッシュ」を狙って見つける近道がほぼありません。
だから nonce を変えて総当たりするしかなく、その総当たりの大きさがそのまま PoW のコストになります。
5. ブロックをもう少し詳しく見る
Bitcoin のブロックは、単なる「取引の袋」ではありません。
構造がかなり重要です。
5-1. ブロックヘッダ
ブロックヘッダには、代表的に次のような情報が入っています。
versionprevious block hashmerkle roottimestampbitsnonce
このヘッダは 80 byte です。
Proof of Work は、この 80 byte に対して行われます。
5-2. previous block hash
これは「1 つ前のブロックのハッシュ」です。
これが入ることで、
各ブロックは前のブロックに結びつきます。
その結果、過去のブロックを変えると、その後ろも全部つじつまが崩れます。
5-3. Merkle root
ブロックには大量のトランザクションが入ります。
それらを 1 つ 1 つ全部ヘッダに入れるのは無理なので、
トランザクション全体をまとめた要約値として Merkle root を使います。
Merkle tree は、ざっくり言えば
- トランザクションをハッシュする
- それを 2 つずつまとめてまたハッシュする
- 最後に 1 個の根の値を得る
という木構造です。
こうすると、ヘッダには root だけ入れればよくなります。
5-4. nonce
nonce はハッシュ結果を変えるための調整値です。
block header の他の部分がほぼ同じでも、
nonce を変えればハッシュ結果は変わります。
miner はこれを 0, 1, 2, 3... と変えながら何度も試します。
5-5. bits と difficulty
bits は、そのブロックが満たすべき難易度情報を圧縮して持つフィールドです。
難易度が高いほど、
条件を満たすハッシュは見つかりにくくなります。
Bitcoin では、この難易度は固定ではなく、一定間隔で調整されます。
目的は、ブロック生成間隔をおおむね 10 分に保つことです。
6. Proof of Work を丁寧に見る
ここは Bitcoin の安全性の中心なので、少し丁寧に見ます。
6-1. miner が実際にやっていること
miner がやっていることは、かなり単純化するとこうです。
- 取引を集めてブロック候補を作る
- ブロックヘッダを作る
- nonce を変える
- double SHA-256 を計算する
- 結果が target 以下なら成功
- 失敗なら別の nonce で再試行
つまり本質は、
条件を満たすハッシュが出るまで大量に試す
ことです。
6-2. なぜ逆算ではなく総当たりになるのか
ここでよく出る疑問が、
「ハッシュの条件を満たす値を逆算できないのか」
です。
現状の理解では、SHA-256 について
そのような実用的な逆算アルゴリズムは知られていません。
したがって miner は、
- 数学的な近道を使う
のではなく、
- とにかく試行回数を増やす
しかありません。
この「近道がほぼない」という性質が、PoW の成立条件になっています。
6-3. なぜ PoW が安全性につながるのか
PoW が安全なのは、
その計算が役に立つからではありません。
安全性の本質は、
- ブロックを 1 個作るのにコストがかかる
- 過去を書き換えるにはそのコストを積み直さないといけない
- 正直な参加者全体の積み上げを追い越すのが難しい
という点にあります。
つまり Bitcoin は、
履歴の改ざんを「禁止」しているのではなく、「割に合わないほど高コスト」にしている
のです。
6-4. longest chain とは何か
Satoshi の論文では longest chain と書かれています。
ただし実際には、単にブロック数が多いというより、
最も累積 Proof of Work が大きい chain
を採用します。
そのため、ノードは
- 自分が気に入った履歴
ではなく、
- 最も多くの work が積まれた履歴
を正史とみなします。
6-5. 実際に 1 つの PoW を通すのにどれくらいの計算資源が必要か
ここでいう「1 つの PoW」には、実は 2 つの意味があります。
1 回のハッシュ試行実際にブロックを 1 個成立させるまでの期待計算量
この 2 つはまったく違います。
1 回のハッシュ試行そのものは軽い
SHA-256 を 1 回計算すること自体は、現代のコンピュータから見るとそれほど重くありません。
問題は、
条件を満たすハッシュが出るまで、天文学的な回数それを繰り返さないといけない
ことです。
ブロック 1 個ぶんの期待試行回数は非常に大きい
Bitcoin の難易度を D とすると、平均的にはおよそ
D × 2^32
回のハッシュ試行が必要になります。
2026 年 4 月 5 日時点で、Blockchain.com の Stats API が返している Bitcoin の難易度は
138,966,872,071,213
です。
これをそのまま入れると、ブロック 1 個あたりの期待試行回数はおよそ
138,966,872,071,213 × 2^32
= 596,858,170,773,275,618,050,048
≈ 5.97 × 10^23 回
になります。
これは、
1 回あたりの計算は単純でも、成功するまでの総試行回数がとてつもなく大きい
ことを意味しています。
ネットワーク全体ではどれくらいか
同じく 2026 年 4 月 5 日時点で、Blockchain.com の Stats API による推定ハッシュレートは
9.187747304727507 × 10^11 GH/s
≈ 9.19 × 10^20 hashes/s
≈ 918 EH/s
です。
これだけの計算資源がネットワーク全体で同時に動いているため、
期待試行回数は巨大でも、平均すると約 10 分に 1 ブロックのペースで新しいブロックが見つかります。
単純計算すると、
5.97 × 10^23 ÷ 9.19 × 10^20 ≈ 650 秒
つまり約 10.8 分 です。
これは Bitcoin が目標としている「だいたい 10 分に 1 ブロック」という感覚とほぼ一致します。
ASIC 1 台だけでやるとどれくらいか
たとえば BITMAIN の Antminer S21 XP の公式スペックは、
270 TH/s3645 W13.5 J/TH
です。
この 1 台だけで、上の期待計算量
5.97 × 10^23 hashes
をこなすとすると、単純計算では
5.97 × 10^23 ÷ 2.70 × 10^14 ≈ 2.21 × 10^9 秒
となり、約 70 年 かかります。
消費電力も、理想化した単純計算では
3.645 kW × 約 613,915 時間
≈ 2,238,000 kWh
≈ 2.24 GWh
になります。
もちろん現実には、
- 難易度は固定ではない
- ネットワークハッシュレートも変わる
- 個人が solo で掘ることはほぼ現実的ではない
ので、この数字は「2026 年 4 月 5 日時点の難易度が固定だと仮定した期待値」にすぎません。
それでも、
Bitcoin の PoW が、個人の PC どころか現行 ASIC ですら 1 台では厳しいほど巨大な計算競争
であることは十分伝わると思います。
7. なぜ PoW が必要なのか
ここが Bitcoin の思想の核心です。
7-1. もし PoW がなかったら
PoW がないと、同じコインを 2 回使う不正が起きたときに、
「どちらの履歴を正しいとするか」を決める共通基準がありません。
ネットワーク上では、
- B さんへ送った履歴
- C さんへ送った履歴
のように複数の候補が並びうるからです。
中央管理者がいない以上、
誰かが「これが正しい」と宣言するだけでは不十分です。
7-2. 多数決ではだめなのか
素朴には「ノード数の多数決」でよさそうに見えます。
しかし、それだと攻撃者が大量の偽ノードを立てるだけで勝ててしまいます。
これを Sybil attack といいます。
PoW はこの問題を避けるために、
発言権をノード数ではなく、実際に払った計算コストで重みづけする
仕組みになっています。
7-3. Bitcoin における PoW の役割
PoW の役割は主に次の 3 つです。
- 次のブロック提案者を競争で決める
- 二重支払いを高コスト化する
- どのチェーンを正史とみなすかの基準を与える
つまり Bitcoin における PoW は、
分散合意のためのコスト装置
です。
8. ノードの種類と役割
node という言葉は広いので、ここで整理しておきます。
8-1. full node
full node は、ルールを自分で検証します。
特徴:
- 自分でブロックを検証する
- 自分でトランザクションを検証する
- どのチェーンが正しいか自分で判断する
強み:
- 他人を信用しなくてよい
- 一番強い検証モデル
8-2. mining node
mining を行うノードです。
実務上は、full node 機能を持つものと連携して動くことが多いです。
特徴:
- トランザクションを集める
- ブロック候補を作る
- PoW を計算する
強み:
- ブロック生成に参加できる
- 報酬を得る可能性がある
8-3. SPV client
Satoshi の論文で出てくる軽量な確認方式です。
特徴:
- 全ブロックを完全には持たない
- 主にブロックヘッダを保持する
- Merkle proof を使って取引の包含を確認する
強み:
- 軽い
- モバイル端末などでも動きやすい
弱み:
- full node より信頼モデルが弱い
9. confirmations はなぜ大事なのか
ある取引がブロックに入った直後は、まだ比較的浅い位置にあります。
その後ろにブロックが積まれるほど、
その取引を覆すにはより多くの PoW を積み直さなければならなくなります。
したがって、
- 1 confirmation より 2 confirmations
- 2 confirmations より 6 confirmations
の方が一般に安全です。
これは「何回確認したから魔法のように安全になる」という話ではなく、
履歴を書き換えるために必要なコストが、後ろに積まれた work の分だけ増える
からです。
10. 51% 攻撃とは何ができる攻撃なのか
攻撃者が十分大きな計算力を持つと、
正直なネットワークより速く別チェーンを育てられる可能性があります。
これが 51% 攻撃 と呼ばれるものです。
10-1. できること
- 自分の支払いを後から取り消す方向の二重支払い
- 特定の取引をブロックに入れにくくする
10-2. できないこと
- 他人の秘密鍵なしで他人のコインを使う
- Bitcoin のルールを無視して好きなだけ新規発行する
これらは full node の検証ルールで拒否されます。
つまり 51% 攻撃は「万能破壊」ではなく、
履歴競争で優位に立つ攻撃
です。
11. miner はなぜ働き続けるのか
Bitcoin にはインセンティブ設計があります。
miner はブロックを作ると、
- 新規発行される BTC
- そのブロックに含めた取引の手数料
を受け取れます。
Satoshi の論文でも、
この報酬が参加者に正直な行動を促す重要な要素として説明されています。
要するに miner は、
- ネットワークの維持に貢献し
- その対価として報酬を得る
という立場です。
12. もし誰も mining しなくなったらどうなるか
もし誰も mining をしなくなったら、新しいブロックがほとんど作られなくなります。
その結果、
- 送金トランザクションは mempool にたまる
- 取引は承認されない
- 新しい送金は実質的に成立しない
という状態になります。
台帳上の「この人が持っている」という記録は残っても、
ネットワークが更新されないので、決済システムとしてはほぼ機能停止です。
したがって PoW は、
- 安全性の土台
- 稼働の土台
の両方を担っています。
13. なぜ Bitcoin に価値があるのか
ここは技術だけではなく経済の話も入りますが、技術的な観点から整理すると、
Bitcoin には次の特徴があります。
- 二重支払いを防げる
- 中央管理者なしで動く
- 世界中で同じルールの台帳を共有できる
- 供給量のルールが公開されている
- 誰でも検証できる
つまり Bitcoin は、
改ざんしにくい公開台帳の上で、所有権が管理されるデジタル資産
だと考えると分かりやすいです。
そのうえで市場参加者が価値を認めるから、価格が付きます。
14. よくある誤解
14-1. Bitcoin はただのデータだから価値がない
確かに Bitcoin はデータです。
しかし、価値があるのは「データそのもの」ではなく、
そのデータが表現している
改ざんしにくい公開台帳上の所有権
です。
14-2. miner が全部決めている
miner はブロック提案者ですが、最終的なルールの執行者ではありません。
ルールを検証し、受け入れるか拒否するのは full node です。
14-3. 51% 攻撃が起きたら何でもできる
そうではありません。
主に問題になるのは履歴競争と二重支払いであり、
署名ルールそのものを無視して他人の資産を奪えるわけではありません。
14-4. PoW は無意味な計算だから価値がない
PoW の計算結果そのものには外部用途がなくても、
その「大きなコストが必要」という性質自体が、履歴改ざんを高コスト化する役割を持っています。
15. まとめ
Bitcoin は、
- 鍵で所有権を表し
- トランザクションで移転を記録し
- ノードがそれを検証し
- ブロックにまとめ
- Proof of Work で時系列と正史を決める
ことで、中央管理者なしに動く電子的な価値移転システムを実現しています。
重要なのは、Bitcoin が
「特殊な暗号 1 つで動いている」
わけではないことです。
実際には、
- 公開鍵暗号
- ハッシュ関数
- 分散ネットワーク
- 経済インセンティブ
- 現実の計算コスト
が組み合わさって成り立っています。
だから Bitcoin は、単なる通貨の話というより、
中央管理者なしでどうやって 1 つの正しい履歴に合意するか
というコンピュータサイエンスの課題に対する 1 つの実装例でもあります。
16. 感想
ここまで調べてみて一番印象に残ったのは、Bitcoin の安全性がかなり PoW に支えられている、という点でした。
正直、「この前提っていつまで同じように通用するんだろう」とは思いました。
もちろん、単純にマシンスペックが上がるだけですぐ危なくなるわけではありません。実際には、計算資源の増加はネットワーク全体にも広く効きますし、難易度調整もあります。
ただ、それでも
- 計算資源の偏りが極端に進む
-
SHA-256に対する効率的な近道が見つかる - ネットワークを支える経済合理性が崩れる
といったことが起きれば、今の前提は揺らぎ得ます。
2008 年に提案された仕組みが、いまも世界規模で動いていること自体はかなりすごいです。ただ、その持続性は数学だけで成り立っているわけではなく、技術・電力・経済インセンティブ・参加者の行動のバランスに支えられているのだと実感しました。
何が言いたかったかというと、Bitcoinで一攫千金を夢見ていた私は大人しく明日からも会社で働きます。
参考資料
-
Satoshi Nakamoto,
Bitcoin: A Peer-to-Peer Electronic Cash System
https://bitcoin.org/bitcoin.pdf -
Bitcoin Developer Guide: Operating Modes
https://developer.bitcoin.org/devguide/operating_modes.html -
Blockchain.com Stats API
https://api.blockchain.info/stats -
BITMAIN Support: S21 XP Specifications
https://support.bitmain.com/hc/en-us/articles/35383015643673-S21-XP-Specifications