---
title: "ブロックチェーンとデータベースの違い｜RDB・台帳DBとの比較と選び方【2026年】"
url: "https://www.issoh.co.jp/column/details/1491/"
published: 2023-09-29
updated: 2026-10-11
categories: ["ブロックチェーン"]
publisher: "株式会社一創"
---

# ブロックチェーンとデータベースの違い｜RDB・台帳DBとの比較と選び方【2026年】

ブロックチェーンとRDBは、どちらもデータを記録する技術ですが、記録を共有する相手と信頼の置き方が異なります。RDBは信頼できる管理者のもとで速く読み書きするための仕組み、ブロックチェーンは複数の参加者が合意したルールに従って記録を共有・確定する仕組みです。ただし、ブロックチェーンが保証するのは記録の整合性で、入力された現実世界の情報が正しいかまでは保証しません。この記事では両者の違いを構造・改ざん耐性・処理速度で比べ、2026年10月に実測した処理件数と、両者の中間にあたる「台帳データベース」まで含めて選び方を整理します。

## まとめ：ブロックチェーンとデータベースの違いと選び方の要点

- **違いの核心**：RDBは権限と制約に従って更新・削除でき、ブロックチェーンは合意形成の安全性が維持される条件で、確定した履歴の変更を困難にします。
- **処理件数**：2026年10月11日の実測で、ビットコインは約9.8件/秒、イーサリアムは約21件/秒でした。Visaは公称で毎秒65,000件超の処理能力を持ちます（取引の単位や確定条件が違うため、単純な性能比較にはなりません）。
- **中間解**：「改ざんを検知できれば十分」で管理者が1社なら、SQL Server・Azure SQLのLedgerやOracleのブロックチェーン表が候補になります。Amazon QLDBは2025年7月31日にサポートを終えています。
- **選び方**：データを管理する信頼できる主体が1つあるならRDB。互いに信頼しきれない複数の組織が同じ記録を持ち合う場合にだけブロックチェーンを検討します。

## RDB・台帳DB・ブロックチェーンの比較

RDB・台帳データベース・ブロックチェーンの3つを並べると、違いは「誰が正しさを保証するか」に集約されます。

| 観点     | RDB              | 台帳データベース          | ブロックチェーン         |
| ------ | ---------------- | ----------------- | ---------------- |
| 管理主体   | 1組織              | 1組織               | 複数の参加者           |
| 正しさの担保 | 管理者への信頼          | 管理者＋ハッシュ検証        | 合意形成             |
| 更新・削除  | 権限の範囲で可能         | 履歴が残る／追記のみ        | 追記のみ             |
| 改ざん    | 権限があれば可能         | 検知できる             | 合意形成の安全性に依存      |
| 処理速度   | 構成次第で高速          | RDBに近い            | チェーン・取引内容・構成による  |
| 代表例    | PostgreSQL・MySQL | SQL Server Ledger | Bitcoin・Ethereum |

表の「台帳データベース」は、中央管理のまま履歴の改ざんを検証できるRDBの台帳機能を指します。この列を挟むと、ブロックチェーンが本当に必要な場面がかなり狭いことが見えてきます。

## ブロックチェーンと分散データベースの関係

### 台帳（ledger）という呼び名の意味

ブロックチェーンが「分散台帳」と呼ばれるのは、記録の性質が会計の帳簿と同じだからです。帳簿は誤りを消しゴムで消さず、訂正の仕訳を追加して直します。ブロックチェーンも確定した記録を書き換えず、訂正は新しい取引として追記します。台帳は取引や履歴を記録するもので、RDBでも実装できます。例えばSQL Server Ledgerには、挿入のみを許す追記専用テーブルがあります。

### 一般的な分散データベースとの違い

RDBにも、複数のサーバーへデータを複製する[データベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計を実装者目線で解説【2026年版】](/tech/details/16276/)のような分散の仕組みがあります。ただしその目的は可用性と読み取り性能で、どのサーバーも同じ管理者の配下にあります。プライマリが書いた内容をレプリカは疑わずに受け取ります。ブロックチェーンのノードは互いに相手を信用せず、受け取ったブロックを自分で検証してから台帳に加えます。広い意味では分散データベースの一種ですが、「参加者同士が信頼していない」ことを前提にしている点が決定的に違います。

## ハッシュ連鎖による改ざん検知と限界

### Pythonによるハッシュ参照の検証

各ブロックは直前のブロックのハッシュ値を持ちます。過去のブロックを1文字でも書き換えるとハッシュが変わり、次のブロックが持つ値と一致しなくなります。次のPythonコードは3件の取引をつないだ台帳を作り、1件目の金額を書き換えて検証します（Python 3.9.6で実行）。

```
import hashlib, json

def block_hash(block):
    body = json.dumps(block, sort_keys=True, ensure_ascii=False).encode()
    return hashlib.sha256(body).hexdigest()

def append(chain, data):
    prev = block_hash(chain[-1]) if chain else "0" * 64
    chain.append({"index": len(chain), "prev_hash": prev, "data": data})

def verify(chain):
    for i in range(1, len(chain)):
        if chain[i]["prev_hash"] != block_hash(chain[i - 1]):
            return f"NG: ブロック{i - 1}が改ざんされています"
    return "OK"

chain = []
append(chain, {"from": "A社", "to": "B社", "amount": 100})
append(chain, {"from": "B社", "to": "C社", "amount": 40})
append(chain, {"from": "C社", "to": "A社", "amount": 10})
print(verify(chain))

chain[0]["data"]["amount"] = 1000   # 過去の記録を書き換える
print(verify(chain))

# 台帳を1人で持っていれば、後続のprev_hashを全部計算し直せる
for i in range(1, len(chain)):
    chain[i]["prev_hash"] = block_hash(chain[i - 1])
print(verify(chain))
```

出力は `OK`、`NG: ブロック0が改ざんされています`、`OK` の順です。最後の結果が重要で、台帳を1人で持っている限り、書き換えた後に後続のハッシュをすべて計算し直せば検証を通ってしまいます。このコードは隣接ブロック間のハッシュ参照だけを検査します。末尾ブロックの改変や末尾の削除は検知できず、連鎖の再計算にも対抗できません。履歴全体を検証するには、信頼できる場所に保存した末尾ハッシュや長さなどとの照合が必要です。

### 複製と合意形成による履歴改変への耐性

ブロックチェーンでは同じ台帳を多数のノードが持っているため、1人が手元で計算し直しても、他のノードの台帳と食い違って受け入れられません。どのブロックを正しい台帳に加えるかは合意形成（コンセンサス）で決めます。ビットコインは計算競争で記録する権利を決めるProof of Work（PoW）で、プロトコルが目標とするブロック間隔は[ソースコード上で600秒（10分）](https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp)です。イーサリアムは[2022年9月15日のThe Merge](https://ethereum.org/roadmap/merge/)でProof of Stake（PoS）へ移り、保有するETHを担保に預けた検証者がブロックを提案・承認します。履歴の変更に必要な条件は合意方式と確定状態によって異なります。攻撃に必要な計算資源やステーク、罰則が変更を困難にしますが、あらゆるチェーンで不可能と保証されるわけではありません。

## 処理件数・確定条件・手数料の比較

### ビットコインとイーサリアムの実効処理件数

2026年10月11日に公開データから処理件数を測りました。処理件数は取引の大きさや観測期間で変わるため、ある時点の目安として見てください。ビットコインは[blockchain.comの統計API](https://api.blockchain.info/stats)で直近24時間の取引数が849,038件、平均ブロック間隔は約8.2分で、1秒あたり約9.8件です。イーサリアムは公開RPCから直近300ブロック（約1時間）を取得し、取引75,551件・平均ブロック間隔12.08秒で、1秒あたり約21件でした。ブロック間隔がほぼ12秒なのは、イーサリアムが[時間を12秒のスロットに区切って1スロット1ブロックを作る](https://ethereum.org/developers/docs/blocks)設計だからです。

ビットコインの1ブロックに入る量は[最大400万ウェイトユニット](https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h)と合意ルールで決まっており、ブロック間隔と合わせて処理件数の上限を縛っています。速度を上げたいアプリケーションは、L1の外で取引をまとめて処理する[ブロックチェーンのレイヤー2とは？ロールアップの仕組みと手数料の内訳・成熟度の見分け方【2026年版】](/tech/details/8797/)を使うのが現在の主流です。

### Visaとの桁の違いとトリレンマ

Visaは自社記事で[毎秒65,000件超の処理能力](https://www.visa.com/en-us/thought-leadership/innovation/deep-dive-on-solana)を公称しています。実際の量も、[2025年度の年次報告書（Form 10-K）](https://www.sec.gov/Archives/edgar/data/1403161/000140316125000089/v-20250930.htm)にVisaが処理した取引が2,580億件とあり、365日で割ると平均で毎秒約8,200件です。ただし、Visaの決済処理とBitcoinのオンチェーン取引では処理の単位・観測期間・確定条件が異なるため、件数比をそのまま性能差とはみなせません。

処理件数の差には、処理の意味や実装、合意方式の違いが影響します。取引の検証や合意形成には通信・計算の負荷がかかりますが、全ノードの合意を待つ方式ばかりではなく、Hyperledger Fabricのように一部のピアが実行を分担する設計もあります。「分散性・安全性・スケーラビリティを同時に高い水準で満たすのは難しい」というブロックチェーン・トリレンマの言い方をすれば、RDBは分散性（管理者を置かないこと）を最初から捨てることで速さを得ています。公開チェーンでは書き込みのたびに手数料（ガス代）もかかります。

## ブロックチェーンノードの保存方式とデータベース

ブロックチェーンとデータベースは対立する技術のように語られがちですが、層が違います。ノードはブロックや現在の状態をローカルに保存しますが、保存方式は実装で異なります。Hyperledger Fabricではブロック履歴をファイルに、現在の状態をステートデータベースに保存します。

- **Ethereumのクライアント Geth**：新規に台帳を作るときの既定のストレージエンジンは[キー・バリュー型のPebble](https://github.com/ethereum/go-ethereum/blob/master/node/defaults.go)です（既存の台帳がLevelDBならそれを使い続けます）。
- **Hyperledger Fabric**：各ピアが現在の状態を持つステートデータベースは、[既定がピアに組み込まれたLevelDB、選択式で外部のCouchDB](https://hyperledger-fabric.readthedocs.io/en/latest/couchdb%5Fas%5Fstate%5Fdatabase.html)です。

つまりブロックチェーンは「データベースの代わり」ではなく、「参加者が共通のルールで取引の順序や状態を検証・共有する仕組み」と捉えられます。許可型では運営組織が権限を管理し、共有範囲を限定することもあります。現在状態などの保存には、[KVS（キーバリューストア）とは：Redisで動かして分かる仕組みとRDBとの使い分け【2026年版】](/tech/details/18062/)で扱うようなキー・バリュー型のストアが使われます。ブロックエクスプローラーのように過去の取引を検索・集計する用途では、チェーンのデータをRDBへ取り込んでから問い合わせる構成が一般的です。

## 中間の選択肢：台帳データベース（改ざん検知付きRDB）

「後から書き換えられていないことを監査で示したい。ただし管理者は自社1社」という要件なら、ブロックチェーンを立てる必要はありません。主要なRDBが、表の中にハッシュ連鎖を持たせる機能を備えています。

### SQL Server・Azure SQLのLedger

[Ledger](https://learn.microsoft.com/en-us/sql/relational-databases/security/ledger/ledger-overview?view=sql-server-ver16)はSQL Server 2022で入った改ざん検知機能で、Azure SQL DatabaseとAzure SQL Managed Instanceでも使えます。表は2種類で、更新可能台帳テーブルは更新・削除を許しつつ旧版を履歴表に残し、追記専用台帳テーブルは挿入だけを許します。データベース全体のハッシュ（ダイジェスト）を外部に保存しておけば、後から検証して改ざんの有無を確かめられます。[ダイジェストの自動保存先](https://learn.microsoft.com/en-us/sql/relational-databases/security/ledger/ledger-digest-management?view=sql-server-ver17)は、Azure SQLではAzure StorageかAzure Confidential Ledger、SQL ServerではAzure Storageだけです。

先ほどのコードで見たとおり、管理者が全部を計算し直せば連鎖は作り直せます。ダイジェストを管理者が書き換えられない外部の場所に置くことが、この機能の要点です。

### Oracle Databaseのブロックチェーン表

Oracleのブロックチェーン表はOracle Database 21cで登場し、[19cでもRelease Update 19.10から使えます](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/DBA%5FBLOCKCHAIN%5FTABLES.html)。[先頭以外の各行を前の行へ暗号学的ハッシュでつなぎ](https://docs.oracle.com/en/database/oracle/oracle-database/21/admin/managing-tables.html)、NO DELETE句で行を永久に、または挿入後一定日数まで削除できなくします。日数を指定するときの最小値は16日です。行同士を連鎖させない「不変表（Immutable Tables）」もあり、[19cではRelease Update 19.11から](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/DBA%5FIMMUTABLE%5FTABLES.html)使えます。

### Amazon QLDBのサポート終了と移行先

台帳データベースの代表例だったAmazon QLDBは、[2025年7月31日でサポートを終了](https://aws.amazon.com/jp/blogs/news/migration-from-amazon-qldb/)し、AWSはAurora PostgreSQLへの移行を案内しています。QLDBの開発者ガイドはすでに公開を終えており、製品ページ（aws.amazon.com/qldb/）もAuroraのページへ転送されます。台帳データベースを比較した記事でQLDBが候補に挙がっていたら、記事の日付を確かめてください。仕組みと移行の詳細は[Amazon QLDBとは？台帳データベースの仕組みとサービス終了・移行先を実装者目線で解説](/tech/details/15451/)にまとめています。PostgreSQLで追記型の履歴を設計するなら、変更をイベントとして積み上げる[イベントソーシングとは？状態再生とイベントストア設計を実装視点で解説【2026年版】](/tech/details/16144/)の考え方が近くなります。

## クラウドでブロックチェーンを使うときの現状

クラウド事業者のマネージドサービスも、RDBほど選択肢はありません。AWSの[Amazon Managed Blockchain](https://aws.amazon.com/managed-blockchain/)は、Hyperledger Fabricのネットワーク管理に加え、Ethereum・Bitcoin・Polygonへのアクセス機能を持ちます。使える機能はAMB AccessとAMB Queryというサービス区分ごとに異なります。一方、Microsoftは[Azure Blockchain Serviceを2021年9月10日で終了](https://github.com/Azure-Samples/blockchain/blob/master/abs/migration-guide.md)し、ConsenSysのQuorum Blockchain Serviceか、仮想マシン上での自前運用へ移るよう案内しました。

台帳DBのQLDBとAzure Blockchain Serviceは、どちらもすでに終了しています。新しく作るなら、サービスの存続も含めて検討し、RDB側の台帳機能で済むかを先に確かめるのが安全です。

## 使い分けの判断基準：ブロックチェーンを選ぶべき条件と失敗パターン

最初に問うべきは「このデータを管理する、全員が信頼できる主体はいるか」です。いるならRDBか台帳データベースで足ります。

| 要件                   | 向く技術                  |
| -------------------- | --------------------- |
| 1組織が管理し、高速に更新・削除する   | RDB                   |
| 1組織が管理し、改ざんの有無を監査で示す | 台帳データベース              |
| 互いに信頼しない複数組織が同じ記録を持つ | ブロックチェーン              |
| 単独管理者による履歴改変を困難にしたい  | 独立した組織で運営するブロックチェーン   |
| 個人情報など削除義務のあるデータを扱う  | 削除可能な保管先＋法的・再識別リスクの評価 |

失敗しやすいのは、社内システムや自社サービスの会員データのように管理者が1社しかいない用途へブロックチェーンを持ち込むケースです。合意形成や複数ノードの運用が必要になり、記録の訂正・削除にも制約があるのに、「管理者がいなくても正しさを保証できる」という唯一の利点は活きません。改ざん検知が目的なら、Ledgerやブロックチェーン表を候補にできます。必要な保存期間、検証証跡、権限分離などが監査要件を満たすかを確認します。

逆に、複数の企業が流通履歴や取引記録を持ち合い、どの1社にも台帳を任せられない場面では、ブロックチェーンがRDBで代えられない価値を出します。その場合も、業務データ本体はRDBに置き、改ざんされては困る記録のハッシュだけをチェーンへ書く構成が現実的です。チェーンに載せる範囲の決め方は[オンチェーンとは？オフチェーンとの違い・仕組み・使い分けをわかりやすく解説](/column/details/4534/)、大きなファイルをチェーン外に置く設計は[IPFSとブロックチェーンの違い｜役割分担・暗号化・CID連携](/tech/details/8567/)で扱っています。既存のRDBに台帳機能を足すか、チェーンと組み合わせるかの設計・移行は、一創の[データベース設計・移行支援](/service/system/database/)でも相談を受けています。

## よくある質問

### ブロックチェーンとデータベースの違いは何ですか？

最大の違いは、正しさを誰が保証するかです。データベースは管理者がデータを一元管理し、権限があれば更新・削除できます。ブロックチェーンは、複数の参加者が共通のルールに従って記録を共有・確定する仕組みです。許可型では運営組織が参加者や権限を管理します。確定した記録は追記で訂正する代わりに、処理件数は少なく、2026年10月の実測でビットコインは毎秒約10件でした。

### ブロックチェーンのデータはどこに保存されますか？

台帳データはネットワーク上の複数のノードに保存されますが、保存範囲はノードの種類や設定によって異なります。例えばEthereumのライトノードは全履歴を保存しません。ノードの中ではキー・バリュー型のデータベースが使われており、EthereumのGethは新規作成時にPebble、Hyperledger FabricはLevelDB（選択でCouchDB）が既定です。複数ノードへの複製はデータ消失への耐性を高めます。ただし、サービスの継続には合意形成に必要なノードの稼働や、接続先・運用基盤の冗長化も必要です。

### ブロックチェーンはデータベースの代わりになりますか？

多くの業務システムでは代わりになりません。1つの組織が管理し、高速な更新・削除が要る用途ではRDBのほうが速く安価です。改ざんの検知だけが目的なら、SQL ServerのLedgerやOracleのブロックチェーン表のような台帳データベースが候補になります。ブロックチェーンが必要なのは、互いに信頼しきれない複数の組織が同じ記録を持ち合う場面です。

### ブロックチェーンのデータは削除や修正ができますか？

できません。各ブロックが直前のブロックのハッシュを持つため、過去を書き換えると連鎖が崩れ、他のノードに受け入れられません。誤りは訂正の取引を追記して直し、元の記録も残ります。削除への対応が必要なデータ本体は、削除可能な保管先に置きます。ハッシュをチェーンに残す場合も、元データとの照合や個人の再識別が可能かを評価し、削除要求への対応を別途設計します。

### ブロックチェーンをクラウドで使うサービスはありますか？

AWSのAmazon Managed Blockchainには、Hyperledger Fabricのネットワーク管理に加え、Ethereum・Bitcoin・Polygonなどへのアクセス機能があります。利用できる機能はサービス区分ごとに異なります。MicrosoftのAzure Blockchain Serviceは2021年9月10日に終了しており、台帳データベースのAmazon QLDBも2025年7月31日にサポートを終えました。採用前に、サービスが続いているかを公式ドキュメントで確認してください。

## 関連記事

- [Amazon QLDBとは？台帳データベースの仕組みとサービス終了・移行先を実装者目線で解説](/tech/details/15451/)
- [オンチェーンとは？オフチェーンとの違い・仕組み・使い分けをわかりやすく解説](/column/details/4534/)
- [ブロックチェーンのレイヤー2とは？ロールアップの仕組みと手数料の内訳・成熟度の見分け方【2026年版】](/tech/details/8797/)
- [Solidity入門｜開発環境の選び方・基本構文・Sepoliaデプロイまで【2026年版】](/tech/details/8629/)
- [IPFSとブロックチェーンの違い｜役割分担・暗号化・CID連携](/tech/details/8567/)

---

出典: [ブロックチェーンとデータベースの違い｜RDB・台帳DBとの比較と選び方【2026年】](<https://www.issoh.co.jp/column/details/1491/>)（株式会社一創）