中央銀行デジタル通貨（CBDC）とブロックチェーンの関係を整理する

Posted at 2026-07-03

検証日: 2026-07-03
本記事では、CBDCを投資判断や政策提言として扱うのではなく、中央銀行マネー・決済インフラ・台帳設計・情報セキュリティをつなぐ技術テーマとして整理します。
なお、CBDCに関する制度・実証実験・各国方針は変化が大きいため、実務利用や研究で参照する場合は必ず最新の一次情報を確認してください。

概要

コンビニで現金を使うと、財布の中のお札や硬貨が減ります。
スマホ決済を使うと、アプリに利用履歴が残ります。
銀行振込をすると、通帳や銀行アプリに「いつ、誰に、いくら送ったか」という記録が残ります。

普段はあまり意識しませんが、私たちが使っている「お金」は、どこかにある記録と深く結びついています。

現金は、手元にある物理的なお金として扱えます。
銀行預金は、銀行が管理する口座残高として記録されています。
スマホ決済や電子マネーは、アプリや事業者のシステム上に残高や利用履歴が記録されています。

では、中央銀行が発行するお金そのものを、デジタルな形で使えるようにしたらどうなるのでしょうか。

この問いと関係するのが、CBDC（Central Bank Digital Currency）、日本語では中央銀行デジタル通貨と呼ばれるものです。

日本銀行は、CBDCについて一般に次の3つを満たすものと説明しています。

デジタル化されていること
円などの法定通貨建てであること
中央銀行の債務として発行されること

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

「中央銀行の債務」と聞くと少し難しく感じますが、まずは 中央銀行が責任を持って発行するお金 と考えると分かりやすいです。
つまり、CBDCは単なる決済アプリの残高ではなく、中央銀行マネーをデジタルな形で使えるようにする構想として整理できます。

ここで注意したいのは、CBDCを 「ブロックチェーン版の日本円」 と単純に考えないことです。

CBDCは、中央銀行が発行するデジタルなお金に関する制度・決済インフラの話です。
一方、ブロックチェーンや分散型台帳技術（DLT）は、そのCBDCをどのように記録・管理するかを考えるときの技術候補の一つです。

たとえば、スマホ決済は「アプリでお金を便利に使う仕組み」として見ることができます。
一方、CBDCは「中央銀行が発行するお金を、デジタル社会の中でどのように安全に使えるようにするか」という、もう少し土台に近い話です。

この違いは、次のように整理できます。

種類	主な発行・管理主体	デジタルか	中央銀行マネーか	イメージ
現金	中央銀行	いいえ	はい	手元にあるお札や硬貨
銀行預金	民間銀行	はい	いいえ	銀行口座に記録された残高
スマホ決済・電子マネー	民間事業者など	はい	多くはいいえ	アプリやカードで使える残高・履歴
ステーブルコイン	民間発行者など	はい	いいえ	価値の安定を目指すデジタルトークン
CBDC	中央銀行	はい	はい	デジタルな中央銀行マネー

もちろん、CBDCを導入すれば必ず便利になる、という単純な話でもありません。

CBDCを考えるときには、利用者のプライバシー、本人確認、マネー・ローンダリング対策、オフライン決済、災害時の利用、金融機関への影響、サイバーセキュリティなど、さまざまな論点があります。

日本銀行も、CBDCを日本で導入するかどうかは決まっておらず、内外の情勢を踏まえた国民的な議論の中で決まっていくものと説明しています。
また、CBDCに関する実証実験やCBDCフォーラムでの議論を継続的に公表しています。

参考: 日本銀行「中央銀行デジタル通貨」

世界的に見ても、CBDCは多くの中央銀行で検討されています。
BISの2024年調査では、調査対象となった93の中央銀行のうち、91%がリテールCBDC、ホールセールCBDC、またはその両方を検討しているとされています。

参考: BIS “Results of the 2024 BIS survey on central bank digital currencies and crypto”

本記事では、いきなり制度や技術の細かい話に入るのではなく、まずは現金、銀行預金、スマホ決済、電子マネー、ステーブルコインといった身近な例から出発します。
そのうえで、CBDCとブロックチェーンの関係を次の3つの視点から整理していきます。

CBDCは、どのようなお金として考えられているのか
現金・銀行預金・電子マネー・ステーブルコインと何が違うのか
ブロックチェーンやDLTは、CBDCのどこに関係するのか

CBDCは、単なる新しい決済アプリではありません。
また、ブロックチェーンを使えば自動的に完成するものでもありません。

「お金の記録を誰が持つのか」「その記録を誰が検証するのか」「利用者が安心して使える仕組みにするには何が必要か」を考えるうえで、CBDCはとてもよい題材になります。

この記事の立ち位置

本記事は、以前作成した 「身近な記録から理解するブロックチェーンの全体像」 の派生記事です。

派生元の記事では、ブロックチェーンを「複数の参加者が同じ記録を共有し、その記録があとからこっそり書き換えられていないかを確認しやすくする仕組み」として整理しました。
そこでは、ブロック、チェーン、台帳、分散、ハッシュ、デジタル署名、コンセンサス、スマートコントラクト、情報セキュリティ上の強みと限界を広く扱いました。

本記事では、その中でも CBDC に絞って深掘りします。

ただし、この記事は「CBDCの導入を主張する記事」ではありません。
また、金融政策や中央銀行会計を専門的に論じる記事でもありません。

この記事の目的は、CBDCを学び始めた人が、まず次のような全体像を持てるようにすることです。

派生元記事	本記事
ブロックチェーン全体の地図を整理する	CBDCとブロックチェーン/DLTの関係に絞って整理する
身近な記録からブロックチェーンを説明する	身近なお金の記録からCBDCを説明する
改ざん検知や検証可能性を広く扱う	お金の台帳を誰が管理し、どう信頼するのかを見る
強みと限界を広く整理する	CBDC特有のプライバシー、AML/CFT、金融安定、セキュリティ論点まで整理する

CBDCは、「中央銀行が発行するデジタル通貨」と短く説明されることが多いです。
もちろん、その説明は入口として分かりやすいです。

しかし、ブロックチェーンとの関係まで理解するなら、もう一歩進んで、何を中央銀行マネーとして発行し、どの台帳で記録し、誰がどこまで検証・管理するのか を見る必要があります。

この記事では、その見方を初学者向けに整理します。

関連記事: 身近な記録から理解するブロックチェーンの全体像

Qiitaに投稿する際は、上記の ここに派生元記事のURLを挿入 の部分を、実際に投稿済みの派生元記事URLへ置き換えてください。

この記事で分かること

この記事では、CBDCを「なんとなく新しいデジタル通貨」としてではなく、中央銀行が発行するお金を、デジタルな記録としてどう扱うのかという視点から整理します。

ブロックチェーンの細かい実装や金融政策の専門的な議論にいきなり入るのではなく、まずは「普段のお金は、どこにどのように記録されているのか」というところから見ていきます。

この記事で分かることは以下です。

CBDCを身近なお金の記録から理解する考え方
現金、銀行預金、電子マネー、スマホ決済、ステーブルコインとの違い
CBDCが「中央銀行マネーのデジタル化」と言われる理由
リテールCBDCとホールセールCBDCの違い
CBDCとブロックチェーン/DLTの関係
CBDCが必ずしもブロックチェーンで実装されるわけではない理由
プライバシー、AML/CFT、オフライン決済、金融安定などの設計論点
情報セキュリティの観点で見るCBDCの注意点
日本銀行や海外中央銀行における検討状況の概要

対象読者

この記事は、次のような人を想定しています。

CBDCという言葉を聞いたことはあるが、具体的な意味はまだ曖昧な人
ブロックチェーンとCBDCの関係を整理したい人
暗号資産、ステーブルコイン、電子マネー、CBDCの違いを知りたい人
情報セキュリティや金融システムの観点からCBDCを理解したい人
詳細な制度設計や金融政策論に入る前に、まず全体像をつかみたい人

前提知識としては、ブロックチェーンについて「取引や状態を記録する分散台帳のようなもの」というイメージがあれば十分です。

ただし、DLT、スマートコントラクト、AML/CFT、KYC、FAPI、オフライン決済などの用語は出てきます。
これらは初出時にできるだけ具体例を挟みながら説明し、いきなり専門用語だけで話を進めないようにします。

なお、本記事は筆者自身がブロックチェーンや情報セキュリティを学ぶ中で、CBDCの全体像を整理するための学習記事です。
政策提言、投資判断、特定の国・通貨・プロジェクトの推奨を目的とするものではありません。

本記事で扱わないこと

CBDCは、中央銀行、民間銀行、決済事業者、利用者、規制当局、技術ベンダーなどが関わる大きなテーマです。
そのため、この記事ですべてを細かく扱うことはできません。

本記事では、初学者が全体像をつかむことを優先し、以下の内容は深掘りしません。

扱わないこと	理由
各国CBDCプロジェクトの網羅的な比較	国や地域によって制度・目的・進捗が大きく異なり、個別調査が必要なため
金融政策への詳細な影響分析	金利、信用創造、銀行預金への影響などは専門的な金融論の整理が必要なため
中央銀行会計や銀行規制の専門的な議論	初学者向け記事の入口から外れやすいため
個別CBDCシステムの本格的な実装コード	実際のCBDCは高い安全性・可用性・法制度対応が必要であり、短いコードでは再現できないため
暗号プロトコルや合意形成アルゴリズムの数学的詳細	まずはCBDCとブロックチェーンの関係を理解することを優先するため
投資判断や特定通貨の将来予測	本記事は技術・制度・セキュリティ観点の整理であり、投資助言ではないため
CBDC導入の是非に関する政策的主張	公的資料に基づいて論点を整理することを目的とするため

また、CBDCに関する制度や実証実験は、2026年時点でも変化が続いています。
そのため、記事内では日本銀行、BIS、IMF、ECB、FRBなどの一次情報を優先して参照しますが、実務利用や研究で使う場合は、必ず最新の公式情報を確認してください。

この記事では、CBDCを「便利そうなデジタル通貨」としてだけではなく、何を技術で支え、何を制度や運用で支える必要があるのかという視点で整理します。

コードを試す場合の前提

本記事では、考え方を確認するためにPythonの短いコードをいくつか使います。
コードを手元で試す場合は、次の前提で読んでください。

項目	内容
目的	CBDCにおける台帳、二重利用防止、分類、リスク判定、監査ログ、原子的決済などの考え方を理解するための学習用
想定環境	Python 3.x系
主に使う機能	辞書、リスト、条件分岐、ループ、簡単な関数、ハッシュ計算
外部ライブラリ	原則なし。標準ライブラリの `hashlib` を使う例があります
注意点	実際のCBDCシステム、金融取引、法的判断、政策判断には使わない

本記事のコードでは、利用者、残高、取引ID、本人確認状態、リスク判定、監査ログなどをかなり単純化して扱います。
これは、CBDCやデジタルなお金の仕組みを追いやすくするための模型です。

実際のCBDCでは、中央銀行、民間銀行、決済事業者、利用者端末、認証基盤、API、監査、障害対応、法制度など、この記事のコードよりはるかに多くの要素が関係します。
そのため、本記事のコードは 「考え方を理解するための模型」 として扱ってください。

全体の流れ

この記事では、次の順番で話を進めます。

ここからは、まず身近なお金の記録を確認し、その後にCBDCの定義やブロックチェーンとの関係へ進みます。

1. まず「お金の記録」はどこにあるのか

この章では、CBDCの定義に入る前に、現金・銀行預金・スマホ決済などの身近なお金がどこに記録されているのかを整理します。
ポイントは、デジタルなお金では残高や取引を正しく記録し、二重利用を防ぐ台帳が重要になるという点です。

前の章では、CBDCを考える前に、現金・銀行預金・スマホ決済などの身近なお金を並べて見ました。

ここで少し立ち止まって考えたいのは、そもそも私たちが普段使っているお金は、どこに「記録」されているのか、という点です。

コンビニで現金を使うと、財布の中のお札や硬貨が減ります。
銀行振込をすると、銀行アプリや通帳に入出金の履歴が残ります。
スマホ決済を使うと、アプリ上に「いつ、どのお店で、いくら使ったか」が表示されます。

どれも同じように「支払う」という行為ですが、裏側で見ている記録の場所は少しずつ違います。

支払いの例	記録がある場所のイメージ	信じているもの
現金で支払う	手元のお札や硬貨そのもの	その紙幣・硬貨が本物であること
銀行振込をする	銀行が管理する口座残高・入出金履歴	銀行の台帳が正しく更新されること
スマホ決済を使う	決済事業者や連携先のシステム上の履歴	アプリや事業者の残高・取引記録が正しいこと
交通系ICカードを使う	カードや事業者側のシステム上の残高・利用履歴	チャージ残高や利用履歴が正しく扱われること

ここでいう「台帳」は、会計帳簿のような紙のノートだけを指しているわけではありません。
この記事では、誰がいくら持っているか、いつ誰にいくら移動したかを管理する記録くらいの意味で使います。

銀行口座の残高も、スマホ決済の利用履歴も、広い意味では「お金に関する台帳」と見ることができます。

1.1 現金は「物そのもの」が記録に近い

現金は少し特別です。

1,000円札を友人に渡すと、自分の手元からそのお札はなくなります。
同じ1,000円札を、同時に別の友人にも渡すことはできません。

もちろん、偽造や盗難といった別の問題はあります。
しかし、少なくとも普通に使う範囲では、現金は「手元にあるかどうか」がかなり分かりやすいお金です。

一方で、デジタルな記録はそう簡単ではありません。

画像ファイルやPDFをコピーできるように、デジタルデータは複製がとても得意です。
もし「1,000円分のデジタル商品券」をただの画像ファイルのようにコピーできてしまうと、A店でもB店でも同じ商品券を使えてしまうかもしれません。

このように、同じデジタル上の価値を複数回使えてしまう問題は、一般に二重支払い問題と呼ばれます。

ブロックチェーンを学ぶときにもよく出てくる話ですが、これはCBDCを考えるうえでも重要です。
なぜなら、CBDCも「デジタルなお金」として設計される以上、同じ残高を二重に使わせない仕組みが必要になるからです。

💡 豆知識
二重支払い問題は、暗号資産だけの話ではありません。
デジタルなお金やポイント、電子チケットのように「コピーできてしまいそうな価値」を扱うときには、どの記録を正しいものとして扱うのかが必ず重要になります。

1.2 いちばん分かりやすい対策は「管理者の台帳」を見ること

二重支払いを防ぐ分かりやすい方法は、中央にいる管理者が台帳を持つことです。

たとえば銀行振込では、利用者が「AさんからBさんへ1,000円送る」と操作したとき、銀行側のシステムで残高が確認され、問題なければAさんの残高を減らし、Bさんの残高を増やします。

スマホ決済でも、細かい仕組みはサービスによって異なりますが、基本的にはどこかのシステムで「支払える残高があるか」「すでに使われた取引ではないか」を確認しています。

この流れをとても単純化すると、次のようになります。

ここで大切なのは、支払いのたびに「本当に使える残高があるか」を台帳で確認していることです。
台帳が正しく更新されていれば、同じ残高を何度も使うことはできません。

1.3 小さなPython例で「台帳」を見てみる

ここでは、実際の銀行システムやCBDCの実装ではなく、考え方をつかむための小さなPython例を見てみます。

以下のコードでは、利用者ごとの残高を辞書で管理し、送金処理のたびに次の3点を確認します。

同じ取引IDがすでに処理されていないか
送金元の口座が存在するか
送金元に十分な残高があるか

class SimpleLedger:
    def __init__(self):
        # 利用者ごとの残高を管理する簡易的な台帳です。
        # 実際の金融システムでは、データベースや監査ログなどを組み合わせて管理します。
        self.balances = {
            "Alice": 1000,
            "StoreA": 0,
            "StoreB": 0,
        }

        # すでに処理した取引IDを保存します。
        # 同じ取引をもう一度送ってしまう「再送」や「リプレイ」を検知するための簡易的な仕組みです。
        self.processed_tx_ids = set()

    def transfer(self, tx_id, sender, receiver, amount):
        # 取引IDがすでに使われている場合、同じ取引を二重に処理しないように拒否します。
        if tx_id in self.processed_tx_ids:
            return False, "この取引IDはすでに処理済みです"

        # 送金元または送金先が台帳に存在しない場合は拒否します。
        if sender not in self.balances or receiver not in self.balances:
            return False, "送金元または送金先が存在しません"

        # 送金額が0以下の場合は拒否します。
        if amount <= 0:
            return False, "送金額が不正です"

        # 残高が不足している場合は拒否します。
        if self.balances[sender] < amount:
            return False, "残高が不足しています"

        # ここまで確認できたら、送金元の残高を減らし、送金先の残高を増やします。
        self.balances[sender] -= amount
        self.balances[receiver] += amount

        # 処理済みの取引IDとして記録します。
        self.processed_tx_ids.add(tx_id)

        return True, "送金が完了しました"


ledger = SimpleLedger()

# AliceがStoreAに700円支払います。
print(ledger.transfer("tx-001", "Alice", "StoreA", 700))
print(ledger.balances)

# 同じ取引IDをもう一度送ってみます。
# これは再送やリプレイのような扱いになり、拒否されます。
print(ledger.transfer("tx-001", "Alice", "StoreA", 700))
print(ledger.balances)

# 別の取引IDでStoreBにも700円支払おうとします。
# Aliceの残高は300円しか残っていないため、拒否されます。
print(ledger.transfer("tx-002", "Alice", "StoreB", 700))
print(ledger.balances)

実行すると、イメージとしては次のようになります。

(True, '送金が完了しました')
{'Alice': 300, 'StoreA': 700, 'StoreB': 0}
(False, 'この取引IDはすでに処理済みです')
{'Alice': 300, 'StoreA': 700, 'StoreB': 0}
(False, '残高が不足しています')
{'Alice': 300, 'StoreA': 700, 'StoreB': 0}

この例では、Aliceが最初に700円を支払った時点で、残高は300円になります。
そのため、同じ取引をもう一度処理しようとしても拒否されますし、別のお店にさらに700円支払おうとしても残高不足で拒否されます。

もちろん、これはかなり単純化した例です。

実際の金融システムでは、同時に大量の取引が来ても矛盾しないようにする処理、データベースのトランザクション、認証、アクセス制御、監査ログ、障害復旧、不正検知などが必要になります。
また、CBDCであれば中央銀行、民間銀行、決済事業者、利用者端末など、どの主体がどこまで責任を持つのかも重要になります。

そのため、このコードは「金融システムの実装例」ではなく、お金をデジタルに扱うには、残高や取引を正しく記録し、二重利用を防ぐ台帳が必要になるという考え方をつかむための小さな模型です。

1.4 では、誰の台帳を信じるのか

ここまで見ると、デジタルなお金では台帳がとても重要だと分かります。

ただし、台帳があるだけでは十分ではありません。
次に問題になるのは、その台帳を誰が管理し、誰が責任を持つのかです。

銀行預金であれば、基本的には民間銀行が口座残高を管理します。
スマホ決済であれば、決済事業者や連携する金融機関のシステムが関わります。
暗号資産であれば、ブロックチェーン上で複数の参加者が取引履歴を検証する仕組みが使われます。

では、中央銀行が発行するお金そのものをデジタル化する場合はどうでしょうか。

この問いが、CBDCにつながります。

日本銀行は、CBDCについて一般に「デジタル化されていること」「円などの法定通貨建てであること」「中央銀行の債務として発行されること」の3つを満たすものと説明しています。
つまり、CBDCを理解するには、単に「デジタルなお金」と見るだけでなく、中央銀行が発行するお金の記録を、どのような仕組みで安全に扱うのかという視点が必要になります。

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

1.5 この章のまとめ

この章では、CBDCの定義に入る前に、身近なお金の記録を整理しました。

ポイントは、次のとおりです。

現金は、手元にあるお札や硬貨そのものが分かりやすい記録に近い
銀行預金やスマホ決済では、残高や取引履歴を管理する台帳が重要になる
デジタルなお金では、同じ残高を二重に使わせない仕組みが必要になる
台帳があるだけではなく、誰がその台帳を管理し、責任を持つのかが重要になる
中央銀行が発行するお金をデジタル化する場合、この「誰の台帳を信じるのか」という問いがCBDCにつながる

つまり、CBDCを理解する入口は、難しい制度論ではなく、普段のお金がどこでどのように記録されているのかを考えることにあります。

次の章では、この流れを受けて、CBDCを一言でいうと何なのかを整理します。

2. CBDCを一言でいうと

この章では、CBDCを一言で捉えたうえで、日本銀行の定義に沿って基本的な性質を整理します。
ポイントは、CBDCを単なる決済アプリではなく、中央銀行が発行するデジタルな中央銀行マネーとして見ることです。

前の章では、デジタルなお金を扱うには、残高や取引を正しく記録する「台帳」が重要になることを見ました。

では、その台帳に記録されるお金が、民間企業のポイントや銀行預金ではなく、中央銀行が発行するお金そのものだったらどうなるのでしょうか。

ここで登場するのが、**CBDC（Central Bank Digital Currency）**です。
日本語では、中央銀行デジタル通貨と呼ばれます。

一言でいうと、CBDCは次のように整理できます。

CBDCは、中央銀行が発行するお金を、デジタルな形で使えるようにする構想です。

もう少し正確にいうと、日本銀行はCBDCについて、一般に次の3つを満たすものと説明しています。

条件	意味	身近な例で考えると
デジタル化されていること	紙幣や硬貨のような物理的なお金ではなく、電子的な記録として扱われる	スマホアプリやカードの残高のように、画面上で確認できるイメージ
円などの法定通貨建てであること	「1ポイント」や「1トークン」ではなく、「1円」のように国の通貨単位で表される	日本なら円、ユーロ圏ならユーロ、米国ならドルのような単位
中央銀行の債務として発行されること	中央銀行が責任を持って発行するお金である	民間企業の残高ではなく、中央銀行マネーとして扱われる

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

ここで一番つまずきやすいのが、中央銀行の債務という言葉です。

「債務」と聞くと借金のように感じるかもしれませんが、ここではまず 中央銀行が責任を持って発行しているお金 と考えると分かりやすいです。
たとえば、私たちが普段使っている日本銀行券、つまりお札も、中央銀行である日本銀行が発行するお金です。

一方で、銀行口座に入っている預金は、中央銀行ではなく民間銀行が管理するお金です。
スマホ決済アプリの残高も、多くの場合は民間事業者や金融機関の仕組みを通じて管理されています。

つまり、CBDCを理解するときは、単に「デジタルなお金かどうか」だけでなく、誰が発行していて、誰の信用で成り立っているのかを見ることが大切です。

2.1 「デジタルなお金」なら、すべてCBDCなのか

ここで、少し引っかかる点があります。

私たちはすでに、銀行アプリ、クレジットカード、交通系ICカード、スマホ決済など、デジタルな支払い手段を日常的に使っています。
そのため、「もうデジタルなお金はあるのに、なぜCBDCという言葉が出てくるのか」と感じるかもしれません。

この疑問に対する答えは、デジタルであることと、中央銀行マネーであることは別の話だからです。

たとえば、銀行アプリに表示される10,000円はデジタルに見えます。
しかし、それは基本的には銀行預金、つまり民間銀行のシステムに記録された残高です。

スマホ決済の残高も、アプリ上では数字として表示されます。
しかし、それも多くの場合、民間事業者や連携する金融機関の仕組みによって管理されています。

CBDCがこれらと違うのは、中央銀行が発行するお金を、デジタルな形で一般の支払いに使えるようにするという点です。

日本銀行も、CBDCについて「誰でも24時間365日使える現金をデジタル化したような支払決済手段」が主に想定されると説明しています。
ただし、日本でCBDCを導入するかどうかは決まっておらず、今後の国民的な議論の中で決まっていくものとされています。

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

2.2 ざっくり判定する小さなアルゴリズム

CBDCの条件は文章だけで読むと少し抽象的です。
そこで、考え方をつかむために、非常に単純化した判定ロジックを書いてみます。

もちろん、実際にCBDCかどうかは法律・制度・発行主体・技術仕様を総合して判断する必要があります。
以下のコードは、あくまで CBDCを見分ける観点を整理するための模型です。

from dataclasses import dataclass


@dataclass
class MoneyLikeRecord:
    # お金に似た記録を、とても単純化して表現するためのデータクラスです。
    name: str
    is_digital: bool
    unit: str
    issuer: str
    liability_of: str
    widely_available: bool


def is_cbdc_like(record: MoneyLikeRecord):
    """
    CBDCらしさを、次の4つの観点で簡易的に確認します。
    1. デジタル化されているか
    2. 法定通貨建てか
    3. 中央銀行の債務として発行されているか
    4. 一般の利用者に広く使える想定か

    実際の制度判断ではなく、概念整理のためのサンプルです。
    """

    reasons = []

    # CBDCは、紙幣や硬貨そのものではなく、デジタルな形で扱われる必要があります。
    if not record.is_digital:
        reasons.append("デジタル化されていない")

    # ここでは単純化のため、円・ドル・ユーロを法定通貨の例として扱います。
    # 実際には、各国・地域の通貨制度に基づいて判断する必要があります。
    if record.unit not in {"JPY", "USD", "EUR"}:
        reasons.append("法定通貨建てとして扱っていない")

    # CBDCの重要な特徴は、中央銀行の債務として発行されることです。
    if record.liability_of != "central_bank":
        reasons.append("中央銀行の債務ではない")

    # 一般向けCBDCを想定する場合、幅広い利用者が使えることも重要になります。
    # ただし、ホールセールCBDCのように金融機関向けの設計もあるため、ここでは簡略化しています。
    if not record.widely_available:
        reasons.append("一般利用者に広く使える設計ではない")

    # 理由が空なら、今回の単純化した条件ではCBDCらしいと判断します。
    return len(reasons) == 0, reasons


examples = [
    MoneyLikeRecord(
        name="現金",
        is_digital=False,
        unit="JPY",
        issuer="central_bank",
        liability_of="central_bank",
        widely_available=True,
    ),
    MoneyLikeRecord(
        name="銀行預金",
        is_digital=True,
        unit="JPY",
        issuer="commercial_bank",
        liability_of="commercial_bank",
        widely_available=True,
    ),
    MoneyLikeRecord(
        name="スマホ決済残高",
        is_digital=True,
        unit="JPY",
        issuer="payment_service_provider",
        liability_of="private_sector",
        widely_available=True,
    ),
    MoneyLikeRecord(
        name="CBDCの候補",
        is_digital=True,
        unit="JPY",
        issuer="central_bank",
        liability_of="central_bank",
        widely_available=True,
    ),
]


for example in examples:
    result, reasons = is_cbdc_like(example)

    if result:
        print(f"{example.name}: CBDCの条件を満たすイメージです")
    else:
        print(f"{example.name}: CBDCとは言いにくいです -> {', '.join(reasons)}")

実行すると、イメージとしては次のようになります。

現金: CBDCとは言いにくいです -> デジタル化されていない
銀行預金: CBDCとは言いにくいです -> 中央銀行の債務ではない
スマホ決済残高: CBDCとは言いにくいです -> 中央銀行の債務ではない
CBDCの候補: CBDCの条件を満たすイメージです

この例から分かるように、CBDCを見分けるときは、単に「アプリで使えるか」「デジタルな残高か」だけでは不十分です。

現金は中央銀行マネーですが、デジタルではありません。
銀行預金やスマホ決済残高はデジタルですが、中央銀行の債務ではありません。
CBDCは、デジタルであり、法定通貨建てであり、中央銀行の債務として発行される点が特徴です。

このように、CBDCは 現金の性質 と デジタル決済の性質 の両方にまたがる存在として考えると理解しやすくなります。

💡 豆知識
CBDCという言葉を聞くと、「お金がこれから初めてデジタル化される」と感じるかもしれません。
しかし、銀行預金、カード決済、インターネットバンキング、スマホ決済など、私たちの生活ではすでに多くのお金の動きがデジタルな記録として処理されています。
CBDCの新しさは、「お金が初めてデジタルになること」ではなく、中央銀行マネーを一般の人がデジタルに使える可能性があるという点にあります。

ただし、ここで注意したいのは、CBDCが導入されれば必ず現金がなくなる、という話ではないことです。

日本銀行の説明でも、CBDCは主に「現金をデジタル化したような支払決済手段」として想定される一方、日本で導入するかどうかはまだ決まっていません。
また、日本銀行のCBDC関連ページでは、概念実証、パイロット実験、CBDCフォーラム、連絡協議会などの資料が公開されており、検討が段階的に進められていることが分かります。

参考: 日本銀行「中央銀行デジタル通貨」

また、海外でもCBDCは「すでに完成した一つの答え」ではなく、各国の決済事情や制度に応じて検討されています。
たとえば米国のFRBも、CBDCを一般に「広く一般に利用可能な中央銀行のデジタル負債」と説明しつつ、追求・実装するかどうかは未決定であるとしています。

参考: Federal Reserve “Central Bank Digital Currency (CBDC)”

2.3 この章のまとめ

ここまでをまとめると、CBDCは次のように整理できます。

CBDCは、単なるスマホ決済アプリではありません。
また、暗号資産やステーブルコインと同じものでもありません。

重要なのは、中央銀行が発行するお金を、デジタルな社会の中でどのように安全・便利に使えるようにするのかという点です。

ただ、ここまでの説明だけでは、現金、銀行預金、電子マネー、ステーブルコインとの違いがまだ少し曖昧に感じるかもしれません。

次の章では、それぞれを比較しながら、CBDCがどこに位置づけられるのかをもう少し具体的に整理します。

3. 現金・銀行預金・電子マネー・ステーブルコインとの違い

この章では、現金、銀行預金、電子マネー、スマホ決済、ステーブルコイン、CBDCを横並びで比較します。
ポイントは、デジタルかどうかだけでなく、誰が発行し、誰の信用で成り立つのかを見ることです。

前の章では、CBDCを 「中央銀行が発行するお金を、デジタルな形で使えるようにする構想」 と整理しました。

ただ、ここで少し混乱しやすい点があります。

私たちはすでに、銀行アプリで残高を確認できます。
交通系ICカードやスマホ決済で支払いもできます。
暗号資産やステーブルコインのように、ブロックチェーン上で移転できるデジタルな価値もあります。

そう考えると、次のように感じるかもしれません。

すでにデジタルなお金はたくさんあるのに、CBDCは何が違うの？

この章では、現金、銀行預金、電子マネー・スマホ決済残高、ステーブルコイン、CBDCを横並びで比較しながら、違いを整理します。

ポイントは、デジタルかどうかだけで判断しないことです。
より大切なのは、誰が発行しているのか、誰の信用で成り立っているのか、どの台帳に記録されているのかです。

3.1 見分けるための4つの軸

CBDCと既存の決済手段を比べるときは、次の4つの軸で見ると分かりやすいです。

軸	見るポイント	例
形	物理的なお金か、デジタルな記録か	お札・硬貨、アプリ残高、トークン
発行主体	誰が発行・管理しているか	中央銀行、民間銀行、決済事業者、民間発行者
信用の置き場所	最終的に誰を信じて使っているか	中央銀行、銀行、サービス事業者、裏付け資産
台帳の場所	残高や取引履歴がどこに記録されるか	手元の現物、銀行台帳、事業者システム、DLTなど

たとえば、銀行アプリに表示される10,000円はデジタルです。
しかし、それは中央銀行が直接発行したデジタルなお金ではなく、基本的には銀行預金として、民間銀行の台帳に記録されている残高です。

一方、CBDCは、デジタルであり、法定通貨建てであり、中央銀行の債務として発行される点に特徴があります。

参考: BIS “Central bank digital currencies – Executive Summary”
参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

3.2 まずは全体像を比較する

それぞれの違いを表にすると、次のようになります。

種類	デジタルか	主な発行・管理主体	利用者から見たイメージ	CBDCとの違い
現金	いいえ	お札は日本銀行、硬貨は政府	手元にあるお札や硬貨を直接渡す	公的なお金として使えるが、物理的なお金である
銀行預金	はい	民間銀行	銀行口座に記録された残高	デジタルだが、中央銀行の債務ではない
電子マネー・スマホ決済残高	はい	決済事業者、電子マネー発行者、連携する金融機関など	アプリやカードで使える残高	便利な決済手段だが、多くは民間側の仕組みで管理される
ステーブルコイン	はい	民間発行者など	価値の安定を目指すデジタルトークン	法定通貨に連動する設計でも、中央銀行の債務ではない
CBDC	はい	中央銀行	デジタルな中央銀行マネー	中央銀行が発行するデジタルな法定通貨建てのお金

この表を見ると、CBDCは現金とデジタル決済の中間にあるようにも見えます。

現金は、お札を中心に見ると中央銀行が発行する公的なお金としての安心感があります。
銀行預金やスマホ決済は、デジタルで便利です。
CBDCは、その両方にまたがるような存在として議論されています。

ただし、これは「CBDCが現金や銀行預金をすぐに置き換える」という意味ではありません。
日本銀行も、CBDCを日本で導入するかどうかは決まっておらず、国民的な議論の中で決まっていくものと説明しています。

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

3.3 現金：手元にある「物理的なお金」

現金は、もっとも直感的に分かりやすいお金です。

1,000円札をお店に渡せば、自分の手元からそのお札はなくなります。
同じ1,000円札を、同時に別のお店で使うことはできません。

この分かりやすさは、現金の大きな特徴です。
お札や硬貨という「物」そのものを移動させるため、デジタルデータのように簡単にコピーできません。

なお、お札については、日本銀行が日本銀行法に基づいて発行しています。日本銀行の説明では、日本銀行は銀行券を発行することになっており、銀行券は小口資金の受払いの手段として広く利用されているとされています。

参考: 日本銀行「銀行券・貨幣の発行・管理の概要」
参考: 日本銀行「お札は誰が発行しているのですか？」

CBDCと比べると、現金は 公的なお金として広く使える性質 を持つ一方で、デジタルではありません。

そのため、ネットショッピングや遠くにいる相手への送金には、そのままでは使いにくいです。
また、紛失した場合に取り戻しにくい、保管や輸送にコストがかかる、といった面もあります。

3.4 銀行預金：デジタルだが「民間銀行の台帳」にあるお金

銀行預金は、私たちにとってかなり身近なデジタルなお金です。

銀行アプリを開けば、残高が数字で表示されます。
振込をすれば、相手の口座にお金を送れます。
クレジットカードや口座振替の支払いも、最終的には銀行口座と関係していることが多いです。

ただし、銀行預金はCBDCではありません。

理由は、銀行預金が 民間銀行の台帳に記録された残高 であり、中央銀行が一般利用者に直接発行するお金ではないからです。

BISは、現在のお金を大きく「中央銀行が発行する公的なお金」と「民間銀行などが発行する民間のお金」に分けて説明しています。その中で、商業銀行の預金は民間のお金として位置づけられ、CBDCは中央銀行の直接の負債として整理されています。

参考: BIS “Central bank digital currencies – Executive Summary”

銀行預金を使うときは、利用者が銀行に対して「この口座からこの口座へ振り込んでください」と指示し、銀行のシステムが残高を更新します。
日本銀行の解説でも、預金を決済手段として使うには、預金者が銀行に指図する必要があると説明されています。

参考: 日本銀行「第5章決済と銀行 2．預金と銀行」

つまり、銀行預金はデジタルで便利ですが、CBDCと比べると 信用の置き場所が民間銀行側にある という違いがあります。

3.5 電子マネー・スマホ決済：便利な「決済の窓口」

交通系ICカードやプリペイド型の電子マネーは、日常生活ではとても現金に近い感覚で使えます。

改札でタッチする。
コンビニでかざす。
スマホアプリで支払う。

このような支払いはとてもスムーズなので、「これもCBDCに近いのでは？」と思うかもしれません。

しかし、電子マネーやスマホ決済も、多くの場合はCBDCではありません。

日本銀行は、電子マネーについて、一般に利用前にチャージを行うプリペイド方式の電子的な決済手段を指すと説明しています。利用者は、現金等を提供して電子マネーを受け取り、その電子的なデータを使って買い物などを行う、という流れです。

参考: 日本銀行「電子マネーとは何ですか？」

スマホ決済についても、サービスによって仕組みはさまざまです。
残高を事前にチャージするものもあれば、銀行口座やクレジットカードと連携するものもあります。

ここで大切なのは、スマホ決済アプリは お金そのものというより、お金を使いやすくする窓口 として働く場合が多いことです。

たとえば、アプリ画面では「残高1,000円」と見えていても、その裏側では、決済事業者のシステム、銀行口座、カード会社のネットワークなどが関わっている可能性があります。

CBDCとの違いは、中央銀行の債務として発行されたデジタルなお金かどうかです。
電子マネーやスマホ決済は便利ですが、それだけでCBDCになるわけではありません。

3.6 ステーブルコイン：価値の安定を目指す民間のデジタルトークン

ステーブルコインは、CBDCと特に混同されやすい存在です。

どちらもデジタルで、円やドルなどの法定通貨と関係しているように見えるためです。
さらに、ステーブルコインはブロックチェーン上で発行・移転されることも多く、CBDCとブロックチェーンの話をしていると、同じもののように見えてしまうことがあります。

しかし、CBDCとステーブルコインは発行主体が違います。

CBDCは中央銀行が発行するデジタルな中央銀行マネーです。
一方、ステーブルコインは、一般に民間発行者などが、特定の資産や法定通貨との連動を目指して発行するデジタルな価値として整理されます。

日本では、法定通貨の価値と連動するいわゆるステーブルコインについて、資金決済法上の「電子決済手段」として扱う制度が整備されています。金融庁は、法定通貨の価値と連動するいわゆるステーブルコインの仲介・管理等を行うために必要な登録制度について説明しています。

参考: 金融庁「電子決済手段・暗号資産サービス仲介業を行うみなさまへ」

CBDCとステーブルコインの違いを、もう少し短くまとめると次のようになります。

観点	CBDC	ステーブルコイン
発行主体	中央銀行	民間発行者など
価値の単位	円・ドル・ユーロなどの法定通貨建て	法定通貨や資産との連動を目指す設計が多い
信用の置き場所	中央銀行	発行者、裏付け資産、償還の仕組み、規制など
ブロックチェーンとの関係	必須ではない	DLTやブロックチェーン上で流通する設計が多い
位置づけ	デジタルな中央銀行マネー	民間が発行するデジタルな価値・決済手段の一種

ここで注意したいのは、ステーブルコインと一口にいっても、設計や法的位置づけは国・地域・発行形態によって異なることです。
そのため、記事内では「ステーブルコインは必ずこうである」と断定しすぎず、必要に応じて公式資料に基づいて整理する必要があります。

3.7 コードで見る：同じ「1,000円っぽい表示」でも中身は違う

ここまでの説明を、簡単なコードで整理してみます。

次のコードは、現金、銀行預金、電子マネー、ステーブルコイン、CBDCを、次の観点で分類する小さなサンプルです。

デジタルかどうか
主な発行主体は誰か
利用者から見た信用の置き場所はどこか
中央銀行マネーといえるか

実際の金融制度を判定するコードではなく、比較の軸を整理するための模型として見てください。

from dataclasses import dataclass


@dataclass
class MoneyRecord:
    # お金や決済手段を比較するための簡易的なデータ構造です。
    # 実際の制度や法律上の分類を完全に表すものではありません。
    name: str
    is_digital: bool
    issuer: str
    trust_anchor: str
    ledger_location: str
    is_central_bank_money: bool


def describe(record: MoneyRecord) -> str:
    """
    お金・決済手段の性質を、比較しやすい短い文章に変換します。
    CBDCかどうかを厳密に判定するのではなく、
    どの軸で違いを見るべきかを整理するための関数です。
    """

    # 物理的なお金か、デジタルな記録かを整理します。
    form = "デジタルな記録" if record.is_digital else "物理的な現物"

    # 中央銀行マネーか、民間側の仕組みによるお金・決済手段かを整理します。
    money_type = "中央銀行マネー" if record.is_central_bank_money else "民間側の仕組みによるお金・決済手段"

    return (
        f"{record.name}: {form} / {money_type}\n"
        f"  発行・管理の中心: {record.issuer}\n"
        f"  信用の置き場所: {record.trust_anchor}\n"
        f"  主な台帳・記録: {record.ledger_location}"
    )


records = [
    MoneyRecord(
        name="現金（お札を中心に考える）",
        is_digital=False,
        issuer="お札は中央銀行、硬貨は政府",
        trust_anchor="公的な通貨制度",
        ledger_location="手元にあるお札・硬貨そのもの",
        is_central_bank_money=True,  # ここでは説明を単純化し、お札を中心に中央銀行マネーとして扱います。
    ),
    MoneyRecord(
        name="銀行預金",
        is_digital=True,
        issuer="民間銀行",
        trust_anchor="預金を管理する銀行",
        ledger_location="銀行の口座台帳",
        is_central_bank_money=False,
    ),
    MoneyRecord(
        name="電子マネー・スマホ決済残高",
        is_digital=True,
        issuer="決済事業者や連携先の金融機関など",
        trust_anchor="サービス提供者や連携する金融機関",
        ledger_location="事業者のシステムやカード・アプリ上の記録",
        is_central_bank_money=False,
    ),
    MoneyRecord(
        name="ステーブルコイン",
        is_digital=True,
        issuer="民間発行者など",
        trust_anchor="発行者・裏付け資産・償還の仕組みなど",
        ledger_location="ブロックチェーンや発行者側の台帳など",
        is_central_bank_money=False,
    ),
    MoneyRecord(
        name="CBDC",
        is_digital=True,
        issuer="中央銀行",
        trust_anchor="中央銀行",
        ledger_location="CBDC用の台帳・ウォレット基盤など",
        is_central_bank_money=True,
    ),
]


for record in records:
    print(describe(record))
    print("-" * 60)

出力イメージは次のようになります。

現金（お札を中心に考える）: 物理的な現物 / 中央銀行マネー
  発行・管理の中心: お札は中央銀行、硬貨は政府
  信用の置き場所: 公的な通貨制度
  主な台帳・記録: 手元にあるお札・硬貨そのもの
------------------------------------------------------------
銀行預金: デジタルな記録 / 民間側の仕組みによるお金・決済手段
  発行・管理の中心: 民間銀行
  信用の置き場所: 預金を管理する銀行
  主な台帳・記録: 銀行の口座台帳
------------------------------------------------------------
電子マネー・スマホ決済残高: デジタルな記録 / 民間側の仕組みによるお金・決済手段
  発行・管理の中心: 決済事業者や連携先の金融機関など
  信用の置き場所: サービス提供者や連携する金融機関
  主な台帳・記録: 事業者のシステムやカード・アプリ上の記録
------------------------------------------------------------
ステーブルコイン: デジタルな記録 / 民間側の仕組みによるお金・決済手段
  発行・管理の中心: 民間発行者など
  信用の置き場所: 発行者・裏付け資産・償還の仕組みなど
  主な台帳・記録: ブロックチェーンや発行者側の台帳など
------------------------------------------------------------
CBDC: デジタルな記録 / 中央銀行マネー
  発行・管理の中心: 中央銀行
  信用の置き場所: 中央銀行
  主な台帳・記録: CBDC用の台帳・ウォレット基盤など
------------------------------------------------------------

このコードで見たいのは、is_digital が True だからといってCBDCになるわけではない、という点です。

銀行預金、電子マネー、ステーブルコインはいずれもデジタルに扱えます。
しかし、中央銀行マネーかどうかという軸で見ると、CBDCとは別物です。

つまり、CBDCを理解するときは、次のように考えると整理しやすくなります。

💡 豆知識
普段の会話では、お札も硬貨もまとめて「現金」と呼びます。
ただし、制度上は少し違いがあります。お札は「日本銀行券」として日本銀行が発行し、硬貨は「貨幣」として扱われます。
CBDCのように「誰が発行するお金なのか」を考えるときには、この発行主体の違いも手がかりになります。

参考: 日本銀行「お札は誰が発行しているのですか？」
参考: 財務省「通貨（貨幣・紙幣）」

3.8 この章のまとめ

ここまでをまとめると、CBDCと似て見えるものはたくさんあります。

銀行預金はデジタルです。
電子マネーやスマホ決済は便利です。
ステーブルコインは、ブロックチェーンや法定通貨との連動という文脈でCBDCと近く見えることがあります。

しかし、CBDCを見分けるうえで一番重要なのは、中央銀行が発行するデジタルな中央銀行マネーかどうかです。

次の章では、CBDCの中にも種類があることを整理します。
特に、日常の買い物で使うイメージの リテールCBDC と、金融機関同士の決済で使うイメージの ホールセールCBDC の違いを見ていきます。

4. CBDCにはどのような種類があるのか

この章では、CBDCの代表的な種類であるリテールCBDCとホールセールCBDCを整理します。
ポイントは、一般利用者向けの日常決済と、金融機関向けの大口決済では、目的も設計論点も変わるという点です。

前の章では、現金、銀行預金、電子マネー、ステーブルコイン、CBDCを並べて比較しました。

そこで見えてきた大事なポイントは、CBDCを理解するときには、単に「デジタルなお金かどうか」だけではなく、誰が発行しているのか、誰が使うのか、どの場面で使うのかを見る必要がある、ということでした。

実は、CBDCにもいくつかの種類があります。

代表的なのは、次の2つです。

リテールCBDC
ホールセールCBDC

名前だけを見ると少し難しそうですが、ざっくり言うと、個人やお店も使うものか、金融機関向けのものかという違いです。

BISの解説では、リテールCBDCは一般の人々を対象にした日常取引向けのデジタルな支払手段、ホールセールCBDCは金融仲介機関の間で使われるものとして整理されています。

参考: BIS “Central bank digital currencies – Executive Summary”

4.1 リテールCBDC：日常の支払いで使うイメージ

リテールCBDCは、個人、店舗、一般企業などが使うことを想定したCBDCです。

たとえば、次のような場面を考えると分かりやすいです。

コンビニで飲み物を買う
友人に立て替え分を送る
ネットショップで支払う
行政から給付金を受け取る
災害時にも使えるデジタルな支払手段を用意する

このような日常的な支払いで使うイメージのCBDCが、リテールCBDCです。

「リテール」は、小売や一般消費者向けという意味で使われます。
そのため、リテールCBDCは 一般利用型CBDC と呼ばれることもあります。

現金に近いイメージで考えるなら、リテールCBDCは 「デジタルなお札」 に近い感覚で説明できます。

ただし、ここで注意したいのは、リテールCBDCが本当に現金とまったく同じになるわけではないことです。

現金は、相手に直接渡せば支払いが完了します。
一方、リテールCBDCはデジタルな記録として扱われるため、ウォレット、本人確認、取引記録、プライバシー、不正利用対策などをどう設計するかが重要になります。

たとえば、スマホをなくしたときに残高をどう守るのか。
通信が使えない場所でも支払えるようにするのか。
利用者の取引情報を誰がどこまで見られるのか。

このような論点は、リテールCBDCでは特に重要になります。

4.2 ホールセールCBDC：金融機関同士の決済で使うイメージ

ホールセールCBDCは、銀行や金融機関、市場参加者などが使うことを想定したCBDCです。

「ホールセール」は、もともと卸売という意味です。
日常の買い物ではなく、金融機関同士の大きな取引や、証券決済、国境を越える決済などをイメージすると分かりやすいです。

たとえば、次のような場面です。

銀行同士で大きなお金を決済する
証券取引の代金決済に使う
国境を越える銀行間決済を効率化する
トークン化された資産の受け渡しとお金の支払いを同時に行う

ホールセールCBDCは、一般利用者がコンビニで使うものというより、金融システムの裏側で使われる決済基盤に近いです。

ここで、ブロックチェーンやDLTとの接点が強くなりやすいのが、ホールセールCBDCの特徴です。

たとえばBISの Project Agorá では、トークン化された中央銀行準備預金と商業銀行預金を共有プラットフォーム上で扱い、ホールセールのクロスボーダー決済をより速く、安全に、透明性高く処理できるかを検証しています。BISは、同プロジェクトについて、トークン化によって複数通貨のホールセール国際決済を原子的に決済できる可能性を示すプロトタイプだと説明しています。

参考: BIS “Project Agorá: exploring tokenisation of wholesale cross-border payments”

ここで出てくる 原子的決済（atomic settlement） は、少し専門的な言葉です。

簡単に言うと、複数の処理を「全部成功するか、全部失敗するか」のどちらかにそろえる考え方です。

たとえば、A銀行がB銀行にお金を払い、同時にB銀行がA銀行に証券を渡す取引を考えます。
このとき、お金だけ移動して証券が渡されない、または証券だけ渡されてお金が移動しない、という状態になると困ります。

そこで、次のように考えます。

このような仕組みは、トークン化資産やスマートコントラクトと関係が深くなりやすいため、ホールセールCBDCではブロックチェーンやDLTの文脈とつながりやすくなります。

4.3 リテールCBDCとホールセールCBDCの比較

リテールCBDCとホールセールCBDCを表で整理すると、次のようになります。

観点	リテールCBDC	ホールセールCBDC
主な利用者	個人、店舗、一般企業	銀行、金融機関、市場参加者
主な用途	日常の支払い、個人間送金、給付金など	銀行間決済、証券決済、国際決済など
身近な例え	デジタルなお札	金融機関向けの決済基盤
重要な論点	利便性、プライバシー、本人確認、オフライン利用、不正対策	決済効率、即時性、相互運用性、トークン化資産との連携
ブロックチェーン/DLTとの関係	必須ではない。設計候補の一つ	トークン化資産や国際決済の文脈で接点が強くなりやすい

ここで大切なのは、リテールCBDCとホールセールCBDCは、どちらが上位・下位という関係ではないことです。

目的が違います。
使う人も違います。
求められる性能や安全性の考え方も違います。

日常の買い物に使うリテールCBDCでは、使いやすさやプライバシー、災害時の利用などが大きな論点になります。
一方、ホールセールCBDCでは、大口決済の確実性、既存の金融市場インフラとの接続、複数通貨やトークン化資産との連携などが重要になります。

BISの2024年調査では、93の中央銀行のうち91%がリテールCBDC、ホールセールCBDC、またはその両方を検討しているとされています。また、集計上はホールセールCBDCの検討の方が、リテールCBDCより進んだ段階にあると整理されています。

参考: BIS “Advancing in tandem - results of the 2024 BIS survey on central bank digital currencies and crypto”

4.4 種類は「利用者」だけで決まるわけではない

ここまで、リテールCBDCとホールセールCBDCを、主に利用者の違いで整理しました。

ただし、実際の設計では、それ以外にも多くの切り口があります。

たとえば、次のような観点です。

切り口	例	ざっくりした意味
利用者	リテール / ホールセール	誰が使うのか
台帳管理	中央管理型 / 分担管理型 / DLT	取引記録をどのように管理するのか
仲介機関	直接型 / 間接型 / 二層型	中央銀行と利用者の間に民間銀行などが入るのか
アクセス方式	口座型 / トークン型	本人の口座を中心に見るのか、デジタルな価値そのものを中心に見るのか
利用環境	オンライン / オフライン	通信があるときだけ使うのか、通信がない場面も想定するのか
利用範囲	国内 / クロスボーダー	国内決済中心か、国境を越える決済まで見るのか

この表を見ると、CBDCは単に「リテールかホールセールか」だけで決まるものではないことが分かります。

たとえば、リテールCBDCであっても、台帳は中央管理型にするのか、分担管理型にするのか、オフライン決済をどこまで認めるのか、といった設計の違いがあります。
ホールセールCBDCであっても、既存の中央銀行当座預金に近い形で考えるのか、トークン化された金融資産と接続しやすい形で考えるのかで、技術的な論点は変わります。

日本銀行のCBDC関連ページでも、実証実験、CBDCフォーラム、連絡協議会などの資料が継続的に公開されており、性能、相互運用性、可用性、セキュリティ、KYC、AML/CFT、外部システムとの接続など、さまざまな観点から検討が進められていることが分かります。

参考: 日本銀行「中央銀行デジタル通貨」

4.5 コードで見る：用途からCBDCの種類をざっくり分類する

ここまでの内容を、簡単なコードで整理してみます。

次のコードは、取引の参加者や用途をもとに、リテールCBDC向きか、ホールセールCBDC向きかをざっくり分類するサンプルです。

実際の制度設計やシステム仕様を判定するものではありません。
あくまで、CBDCの種類を考えるときに、どの情報を見るとよいかを理解するための模型です。

from dataclasses import dataclass
from typing import Literal


ActorType = Literal["individual", "merchant", "company", "bank", "market_infrastructure"]
Purpose = Literal[
    "daily_payment",
    "person_to_person",
    "government_payment",
    "interbank_settlement",
    "securities_settlement",
    "cross_border_wholesale",
]


@dataclass
class PaymentUseCase:
    # CBDCの利用場面を整理するための簡易データ構造です。
    # 実際の制度分類を完全に表すものではありません。
    sender: ActorType
    receiver: ActorType
    purpose: Purpose
    amount: int
    involves_tokenized_asset: bool = False


def classify_cbdc_type(use_case: PaymentUseCase) -> str:
    """
    参加者と用途から、CBDCの種類をざっくり分類します。

    重要なのは、金額だけでリテール/ホールセールを決めないことです。
    誰が使うのか、何のための決済なのか、
    トークン化資産との受け渡しがあるのかを合わせて見ます。
    """

    financial_actors = {"bank", "market_infrastructure"}
    wholesale_purposes = {
        "interbank_settlement",
        "securities_settlement",
        "cross_border_wholesale",
    }

    # 金融機関同士の決済や、証券・国際決済に関わる場合は、
    # ホールセールCBDCの文脈で考えるのが自然です。
    if (
        use_case.sender in financial_actors
        and use_case.receiver in financial_actors
        and use_case.purpose in wholesale_purposes
    ):
        return "ホールセールCBDC向き"

    # トークン化資産の受け渡しを伴う場合は、
    # 金融市場インフラやDLTとの接続が論点になりやすいため、
    # ホールセールCBDC寄りとして扱います。
    if use_case.involves_tokenized_asset:
        return "ホールセールCBDC寄り（トークン化資産との連携が論点）"

    # 個人・店舗・一般企業のあいだの日常決済や個人間送金は、
    # リテールCBDCの文脈で考えるのが自然です。
    if use_case.purpose in {"daily_payment", "person_to_person", "government_payment"}:
        return "リテールCBDC向き"

    # ここに来るケースは、追加の制度設計や利用者条件を確認する必要があります。
    return "追加確認が必要"


examples = [
    PaymentUseCase(
        sender="individual",
        receiver="merchant",
        purpose="daily_payment",
        amount=800,
    ),
    PaymentUseCase(
        sender="individual",
        receiver="individual",
        purpose="person_to_person",
        amount=3000,
    ),
    PaymentUseCase(
        sender="bank",
        receiver="bank",
        purpose="interbank_settlement",
        amount=5_000_000_000,
    ),
    PaymentUseCase(
        sender="bank",
        receiver="market_infrastructure",
        purpose="securities_settlement",
        amount=100_000_000,
        involves_tokenized_asset=True,
    ),
]


for example in examples:
    print(example)
    print("分類:", classify_cbdc_type(example))
    print("-" * 60)

出力イメージは次のようになります。

PaymentUseCase(sender='individual', receiver='merchant', purpose='daily_payment', amount=800, involves_tokenized_asset=False)
分類: リテールCBDC向き
------------------------------------------------------------
PaymentUseCase(sender='individual', receiver='individual', purpose='person_to_person', amount=3000, involves_tokenized_asset=False)
分類: リテールCBDC向き
------------------------------------------------------------
PaymentUseCase(sender='bank', receiver='bank', purpose='interbank_settlement', amount=5000000000, involves_tokenized_asset=False)
分類: ホールセールCBDC向き
------------------------------------------------------------
PaymentUseCase(sender='bank', receiver='market_infrastructure', purpose='securities_settlement', amount=100000000, involves_tokenized_asset=True)
分類: ホールセールCBDC寄り（トークン化資産との連携が論点）
------------------------------------------------------------

このコードで伝えたいのは、CBDCの種類を考えるときに、金額だけで判断しないという点です。

たとえば、個人が高額な買い物をする場合でも、それだけでホールセールCBDCになるわけではありません。
逆に、金融機関同士の決済では、少額であっても金融市場インフラや銀行間決済の文脈で考える必要があります。

つまり、CBDCの種類を見分けるときは、次の順番で考えると分かりやすいです。

💡 豆知識
CBDCという言葉を聞くと、多くの人はスマホアプリで使うデジタル円のようなものを想像するかもしれません。
しかし、世界の中央銀行や国際機関の資料では、ホールセールCBDCも重要なテーマとして扱われています。
コンビニのレジで直接見るものではないかもしれませんが、銀行間決済や国際決済の土台を変える可能性があるため、ブロックチェーンやトークン化の文脈では重要な論点になります。

4.6 この章のまとめ

ここまでをまとめると、CBDCには大きく リテールCBDC と ホールセールCBDC があります。

リテールCBDCは、個人や店舗が日常的に使うデジタルな中央銀行マネーをイメージすると分かりやすいです。
一方、ホールセールCBDCは、銀行や金融機関同士の決済、証券決済、国際決済など、金融システムの裏側で使われるものとして整理できます。

そして、この記事のテーマであるブロックチェーンとの関係を考えるうえでは、特に次の整理が重要です。

リテールCBDCは、ブロックチェーンを使わずに設計される可能性もある
ホールセールCBDCは、トークン化資産、スマートコントラクト、国際決済の文脈でDLTとの接点が強くなりやすい
ただし、どちらの場合も CBDC = ブロックチェーン と決めつけるのは正確ではない

次の章では、いよいよこの記事の中心である 「CBDCとブロックチェーンはどう関係するのか」 を整理します。

CBDCの種類によって、ブロックチェーンやDLTが関係しやすい場面も変わるため、今回のリテール/ホールセールの区別を土台にして読み進めると理解しやすくなります。

5. CBDCとブロックチェーンはどう関係するのか

この章では、記事タイトルの中心であるCBDCとブロックチェーンの関係を整理します。
ポイントは、CBDCはブロックチェーンそのものではなく、ブロックチェーンやDLTは台帳設計の候補の一つだという点です。

前の章では、CBDCには大きく リテールCBDC と ホールセールCBDC があることを見ました。

リテールCBDCは、個人や店舗が日常の支払いに使うイメージです。
ホールセールCBDCは、銀行や金融機関同士の決済、証券決済、国境を越える大口決済などで使うイメージです。

ここまで来ると、この記事のタイトルでもある次の疑問が出てきます。

CBDCは、ブロックチェーンで作るものなの？

結論からいうと、CBDCは必ずしもブロックチェーンで実装されるものではありません。

CBDCは、中央銀行が発行するデジタルな中央銀行マネーに関する制度・決済インフラの話です。
一方、ブロックチェーンやDLTは、そのCBDCをどのような台帳で記録し、どのように検証するかを考えるときの技術候補の一つです。

つまり、まず分けて考えると分かりやすいです。

観点	問い	例
CBDCの話	何を発行するのか	中央銀行が発行するデジタルな円のようなものを考える
台帳設計の話	どこに記録するのか	中央管理型台帳、分担管理型台帳、DLTなど
ブロックチェーンの話	記録をどうつなぎ、どう検証するのか	ハッシュで取引履歴をつなぐ、複数参加者で検証する

日本銀行のCBDCフォーラム総括資料でも、CBDCシステムの台帳管理について、集中管理型や分担管理型などの設計パターンが議論されています。集中管理型は効率的な仕組みになりやすい一方で耐障害性やレジリエンスが重要になり、分担管理型はプライバシー配慮や単一障害点の回避につながる可能性がある一方で、複数台帳間の整合性確保が大きな論点になると整理されています。

参考: 日本銀行「中央銀行デジタル通貨に関する実証実験『パイロット実験』の進捗報告書（2026年6月）CBDCフォーラムにおけるこれまでの議論の総括【別冊】」

5.1 CBDCとブロックチェーンを分けて見る

CBDCとブロックチェーンの関係を図にすると、次のようになります。

この図で大切なのは、CBDCの下に 複数の台帳設計が並んでいる ことです。

ブロックチェーンは、その中の一つの候補です。
「CBDCを考える = すぐブロックチェーンを選ぶ」ではありません。

たとえるなら、CBDCは「新しい公共交通サービスを設計する話」に近いです。
バスで運ぶのか、電車で運ぶのか、専用レーンを作るのか、既存の道路を使うのかは、目的や制約によって変わります。

CBDCでも同じです。

日常の買い物に使うのか。
銀行間の大口決済に使うのか。
災害時のオフライン利用まで考えるのか。
プライバシーをどのように守るのか。
既存の金融機関や決済事業者がどう関わるのか。

こうした条件によって、向いている技術構成は変わります。

BISのリテールCBDCに関する技術整理でも、CBDCの設計では、中央管理型のインフラにするのか、DLTを使うのかといった選択肢があり、それぞれ効率性や単一障害点への強さなどのトレードオフがあると説明されています。

参考: BIS “The technology of retail central bank digital currency”

5.2 そもそもDLTとブロックチェーンは同じなのか

ここで、DLT という言葉も整理しておきます。

DLTは Distributed Ledger Technology の略で、日本語では 分散型台帳技術 と呼ばれます。
ざっくり言うと、1つの管理者だけが台帳を持つのではなく、複数の参加者やシステムで台帳を共有・検証する技術の総称です。

ブロックチェーンは、このDLTの代表的な形の一つとして説明されることが多いです。

用語	ざっくりした意味	関係
DLT	複数の参加者やシステムで台帳を共有・検証する技術の総称	広い概念
ブロックチェーン	取引をブロックにまとめ、ハッシュで前後につないでいく台帳構造	DLTの代表例の一つ
パーミッションドブロックチェーン	参加者を限定したブロックチェーン	金融機関向けの検討で出やすい
パブリックブロックチェーン	誰でも参加しやすい公開型のブロックチェーン	責任分界や規制対応が難しくなりやすい

「DLT = ブロックチェーン」と完全に同じ意味で使うと、少し雑になります。
記事では、DLTは広い概念、ブロックチェーンはその中の代表的な構成の一つとして扱うと安全です。

5.3 CBDCで考えられる台帳設計

CBDCの台帳設計を、かなり単純化して比較すると次のようになります。

設計	イメージ	良い点	注意点
集中管理型台帳	中央のシステムが残高や取引を管理する	構成がシンプルで効率的にしやすい	中央システムの障害に強くする設計が重要
分担管理型台帳	中央銀行と仲介機関などで台帳管理を分担する	単一障害点の回避やプライバシー配慮につながる可能性がある	複数台帳間の整合性を保つ必要がある
パーミッションドDLT	参加者を限定し、複数主体で台帳を共有・検証する	金融機関など、参加者が特定される場面と相性がある	ガバナンス、性能、運用ルールの設計が必要
パブリックブロックチェーン	誰でも参加できる公開ネットワークを使う	高い公開性や検証可能性を持つ場合がある	責任主体、性能、プライバシー、規制対応が難しくなりやすい

日本銀行の資料では、参加者を特定したパーミッションドブロックチェーンは、分散性を一部犠牲にしながらスケーラビリティやセキュリティを高める例として説明されています。一方で、パブリックブロックチェーンでは、運営主体やノード、スマートコントラクトの提供・責任主体が不明確になりやすい点が、パーミッションド型との違いとして指摘されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（ブロックチェーン関連技術）

この整理から分かるように、CBDCでブロックチェーンを使うかどうかは、単なる流行では決められません。

「誰が台帳を持つのか」
「誰が取引を検証するのか」
「障害が起きたら誰が復旧するのか」
「利用者の取引情報を誰がどこまで見られるのか」
「法的な責任を誰が負うのか」

こうした問いに答えられる設計でなければ、実際の決済インフラとしては使いにくいからです。

5.4 ブロックチェーンが得意なこと、苦手なこと

ブロックチェーンの特徴は、過去の記事でも整理したように、記録をあとから検証しやすくする点にあります。

代表的な特徴を、CBDCの文脈に寄せて見ると次のようになります。

特徴	CBDCで期待されること	注意点
改ざん検知	取引履歴が勝手に変えられていないか確認しやすい	改ざん検知と不正防止は別。運用や権限管理も必要
複数主体での共有	金融機関など複数主体で同じ状態を共有しやすい	参加者が増えるほど合意形成や責任分界が難しくなる
スマートコントラクト	条件付き支払いや処理自動化と相性がある	バグや仕様ミスがそのまま損失につながる可能性がある
トークン化資産との接続	証券やRWAなどのトークン化資産との同時決済を考えやすい	決済手段・資産・法制度・市場インフラの整理が必要

ここで注意したいのは、ブロックチェーンの特徴は CBDCのすべての課題を自動的に解決する魔法ではない ということです。

たとえば、ブロックチェーンで取引履歴をつないでも、ウォレットを乗っ取られたら不正送金は起こり得ます。
スマートコントラクトで処理を自動化しても、プログラムにバグがあれば誤った処理が実行される可能性があります。
取引を広く検証できるようにすると、今度はプライバシーとのバランスが難しくなります。

CBDCでは、台帳技術だけでなく、認証、認可、本人確認、AML/CFT、監査ログ、障害対応、利用者保護まで含めて考える必要があります。

5.5 小さなPython例：ハッシュで記録をつなぐと何が嬉しいのか

ブロックチェーンの雰囲気をつかむために、ここでは ハッシュで記録をつなぐ という考え方を小さなPythonコードで見てみます。

実際のCBDCやブロックチェーンの実装ではありません。
あくまで、過去の記録をこっそり変えると検知しやすくなる という考え方を理解するための模型です。

from dataclasses import dataclass, asdict
import hashlib
import json
import time


@dataclass
class Block:
    index: int
    tx_id: str
    sender: str
    receiver: str
    amount: int
    previous_hash: str
    timestamp: float
    block_hash: str = ""

    def calc_hash(self) -> str:
        # ハッシュ値の計算対象に block_hash 自身を含めると、
        # 計算のたびに値が変わってしまいます。
        # そのため、block_hash を除いた内容だけをJSON文字列にしてハッシュ化します。
        payload = asdict(self)
        payload.pop("block_hash")

        # sort_keys=True にすることで、辞書のキー順序に左右されず同じ文字列を作ります。
        encoded = json.dumps(payload, sort_keys=True, ensure_ascii=False).encode("utf-8")
        return hashlib.sha256(encoded).hexdigest()


class HashChainLedger:
    def __init__(self):
        # 利用者ごとの残高を管理します。
        # 実際のCBDCや金融システムでは、より複雑な残高管理・認証・監査が必要です。
        self.balances = {"Alice": 1000, "Bob": 0}

        # 同じ取引IDを二重に処理しないために、処理済みIDを保存します。
        self.processed_tx_ids = set()

        # 最初のブロックです。
        # 実際のブロックチェーンでは genesis block と呼ばれることがあります。
        genesis = Block(
            index=0,
            tx_id="genesis",
            sender="system",
            receiver="system",
            amount=0,
            previous_hash="0",
            timestamp=0.0,
        )
        genesis.block_hash = genesis.calc_hash()
        self.chain = [genesis]

    def add_transaction(self, tx_id: str, sender: str, receiver: str, amount: int) -> bool:
        # 取引IDの再利用を防ぎます。
        if tx_id in self.processed_tx_ids:
            print("拒否: 同じ取引IDは処理済みです")
            return False

        # 送金元・送金先が存在するかを確認します。
        if sender not in self.balances or receiver not in self.balances:
            print("拒否: 送金元または送金先が存在しません")
            return False

        # 残高不足を防ぎます。
        if self.balances[sender] < amount:
            print("拒否: 残高不足です")
            return False

        # ここまで確認できたら残高を更新します。
        self.balances[sender] -= amount
        self.balances[receiver] += amount
        self.processed_tx_ids.add(tx_id)

        # 直前のブロックのハッシュ値を、新しいブロックに埋め込みます。
        # これにより、過去のブロックを改ざんすると後続ブロックとのつながりが壊れます。
        previous_hash = self.chain[-1].block_hash
        block = Block(
            index=len(self.chain),
            tx_id=tx_id,
            sender=sender,
            receiver=receiver,
            amount=amount,
            previous_hash=previous_hash,
            timestamp=time.time(),
        )
        block.block_hash = block.calc_hash()
        self.chain.append(block)
        return True

    def verify_chain(self) -> bool:
        # すべてのブロックについて、保存されているハッシュ値が内容と一致するかを確認します。
        for i, block in enumerate(self.chain):
            if block.block_hash != block.calc_hash():
                print(f"検知: block {i} の内容が変更されています")
                return False

            # 2番目以降のブロックでは、前のブロックのハッシュ値とつながっているかも確認します。
            if i > 0 and block.previous_hash != self.chain[i - 1].block_hash:
                print(f"検知: block {i} の previous_hash が前のブロックと一致しません")
                return False

        return True


ledger = HashChainLedger()

# AliceからBobへ300円送ります。
ledger.add_transaction("tx-001", "Alice", "Bob", 300)
print("残高:", ledger.balances)
print("チェーンは正しいか:", ledger.verify_chain())

# 過去の取引額をこっそり変更した場合を試します。
ledger.chain[1].amount = 900
print("改ざん後のチェーンは正しいか:", ledger.verify_chain())

出力イメージは次のようになります。

残高: {'Alice': 700, 'Bob': 300}
チェーンは正しいか: True
検知: block 1 の内容が変更されています
改ざん後のチェーンは正しいか: False

このコードでは、1つ前の記録のハッシュ値を、次の記録に埋め込んでいます。

そのため、過去の取引額をこっそり変更すると、保存されているハッシュ値と、現在の内容から再計算したハッシュ値が一致しなくなります。
これにより、記録が変わったことを検知しやすくなるわけです。

ただし、この例だけでは本物のブロックチェーンとは呼べません。

本格的なブロックチェーンでは、ネットワーク上の複数ノード、合意形成、署名、ブロック生成ルール、フォークへの対応、手数料設計、スマートコントラクト実行環境など、さらに多くの要素が関わります。

ここで見てほしいのは、ブロックチェーンの全部ではなく、履歴をハッシュでつなぐと、過去の記録の改ざんに気づきやすくなるという基本の考え方です。

5.6 では、CBDCにブロックチェーンを使えばよいのか

ここまで見ると、ブロックチェーンはCBDCに向いているようにも感じます。

確かに、複数の金融機関が同じ台帳を共有したり、トークン化された証券や資産と決済を同時に行ったりする場面では、ブロックチェーンやDLTが候補になりやすいです。

一方で、リテールCBDCのように、多くの一般利用者が日常的に使う決済手段では、別の観点も重要になります。

たとえば、次のような点です。

決済が混雑時にも止まらないか
災害や障害に強いか
スマホを持たない人も使えるか
取引情報が必要以上に見えすぎないか
不正利用やマネー・ローンダリングを検知できるか
障害時に誰が責任を持って復旧するか
法制度や既存の銀行システムと整合するか

BISの情報セキュリティ・運用リスクに関する報告書では、CBDCでDLTのような新しい技術を用いる場合、固有のサイバーリスクがあり、DLTに広く受け入れられたサイバーセキュリティフレームワークが存在しないことも課題として挙げられています。

参考: BIS “Central bank digital currency information security and operational risks to central banks”

そのため、CBDCでは ブロックチェーンを使うかどうか だけではなく、次のように考える必要があります。

つまり、ブロックチェーンは有力な選択肢になる場面があります。
しかし、CBDC全体を説明する言葉として 「ブロックチェーンで作るお金」 とだけ言ってしまうと、かなり大事な部分を落としてしまいます。

💡 豆知識
ブロックチェーンの話をすると、よく スマートコントラクト という言葉が出てきます。
スマートコントラクトは、ざっくりいうと、条件に応じて処理を自動実行するプログラムです。
ただし、処理の自動化 = 必ずブロックチェーンが必要 というわけではありません。既存のデータベース、API、ワークフローエンジン、認証基盤などで実現できる場合もあります。

日本銀行の資料でも、トークン化はブロックチェーンやスマートコントラクトの活用が前提となるケースが多い一方で、既存技術でも必要なプログラマビリティや処理の自動化を達成できる可能性があると整理されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（ブロックチェーン関連技術）

この点は、CBDCを考えるうえでかなり重要です。
ブロックチェーンは便利な道具になり得ますが、技術選定では、まず「何を自動化したいのか」「複数主体で同じ台帳を検証したいのか」を分けて考える必要があります。

5.7 この章のまとめ

ここまでをまとめると、CBDCとブロックチェーンの関係は次のように整理できます。

CBDCは、中央銀行が発行するデジタルな中央銀行マネーに関する制度・決済インフラの話
ブロックチェーンやDLTは、CBDCの台帳を設計するときの技術候補の一つ
集中管理型台帳、分担管理型台帳、パーミッションドDLTなど、複数の選択肢がある
ブロックチェーンは、記録の検証、複数主体での共有、トークン化資産との接続などで役立つ可能性がある
ただし、性能、プライバシー、責任分界、法制度、運用、セキュリティの論点を無視して選べるものではない

CBDCを理解するときは、「ブロックチェーンを使うか」より先に、「どのようなお金の記録を、誰が、どの責任で管理するのか」 を考えることが大切です。

次の章では、今回の内容を一歩進めて、なぜCBDCの文脈でDLTやブロックチェーンが検討されるのかを整理します。
特に、ホールセールCBDC、トークン化資産、国際決済のように、ブロックチェーンとの接点が強くなりやすい場面を見ていきます。

6. なぜCBDCにDLTやブロックチェーンが検討されるのか

この章では、CBDCにブロックチェーンが必須ではないにもかかわらず、なぜDLTが検討されるのかを整理します。
ポイントは、複数の主体が関わる決済やトークン化資産との接続では、同じ記録を共有しながら処理したい場面があるという点です。

前の章では、CBDCとブロックチェーンは同じものではない、という点を整理しました。

CBDCは、中央銀行が発行するデジタルな中央銀行マネーに関する構想です。
一方、DLTやブロックチェーンは、そのお金の記録をどのように管理するかを考えるときの技術候補の一つです。

では、ブロックチェーンが必須ではないにもかかわらず、なぜCBDCの文脈でDLTやブロックチェーンがたびたび話題になるのでしょうか。

理由を一言でまとめると、複数の主体が関わるお金の移動を、同じ記録の上で、より確実に処理したい場面があるからです。

日常の買い物だけを見ると、中央のシステムが高速に処理するだけでも十分に見えるかもしれません。
しかし、銀行間決済、証券決済、国際送金、トークン化資産の取引まで視野を広げると、「複数の金融機関が同じ状態を確認しながら処理したい」という場面が増えてきます。

ここからは、特に重要な理由を順番に見ていきます。

6.1 理由1：複数の主体で同じ台帳を見たいから

普段のスマホ決済では、利用者はアプリの残高や履歴を見ています。
その裏側では、決済事業者、銀行、加盟店、カード会社など、複数のシステムが関わっていることがあります。

取引が単純であれば、それぞれのシステムが自分の台帳を持ち、あとから照合する方法でも運用できます。

しかし、関係者が増えるほど、次のような手間が出てきます。

A社の記録とB社の記録が一致しているか確認する
どの時点で取引が確定したのかをそろえる
途中で失敗した取引を取り消す
監査やトラブル対応のために履歴を確認する

このような場面では、最初から関係者が同じ台帳を共有できると、記録のズレや照合作業を減らせる可能性があります。

もちろん、共有台帳にしたからといって、すべてが自動的に楽になるわけではありません。
誰が台帳を更新できるのか、障害時に誰が責任を持つのか、個人情報や取引情報をどこまで共有してよいのか、といった設計が必要です。

日本銀行のCBDCフォーラム総括資料でも、CBDCシステムの台帳設計として、集中管理型と分担管理型の特徴が整理されています。集中管理型は効率性がある一方で耐障害性やレジリエンスが重要になり、分担管理型はプライバシー配慮や単一障害点回避の利点を得やすい可能性がある一方で、台帳間の整合性確保が論点になるとされています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（CBDCシステムのアーキテクチャー）

6.2 理由2：トークン化資産との同時決済を考えやすいから

ブロックチェーンやDLTが特に関係しやすいのが、トークン化資産との接続です。

トークン化資産とは、株式、債券、不動産の持分、預金、ポイントなどの権利を、デジタルなトークンとして表す考え方です。
たとえば、将来的に「デジタル化された債券」と「デジタルなお金」を同じ仕組みの上で扱えるようになると、証券の受け渡しと代金支払いを一体で処理しやすくなる可能性があります。

ここで重要になるのが、同時決済です。

たとえば、債券を買う場面を考えます。

買い手は、代金を支払う
売り手は、債券を渡す

このとき、代金だけ支払われて債券が届かない、または債券だけ渡されて代金が届かない、という状態は避けたいです。

日本銀行は、DVP（Delivery-versus-Payment）を、証券の受け渡しが行われる場合に限って資金支払いも行われるようにする仕組みとして説明しています。これは、証券だけ届く、またはお金だけ支払われる、といったリスクを防ぐための考え方です。

参考: 日本銀行「What is DVP?」

DLT上で資産トークンと決済用のお金を扱える場合、このような同時決済の仕組みをプログラムとして表現しやすくなる可能性があります。
ただし、ここでも「ブロックチェーンを使えば必ず安全」というわけではありません。法的にいつ取引が確定したとみなされるのか、障害時にどう戻すのか、本人確認や不正対策をどう組み込むのかが必要になります。

6.3 理由3：国境を越える決済を効率化したいから

CBDCとDLTの接点として、近年特に注目されているのがホールセールのクロスボーダー決済です。

海外送金や企業間の国際決済では、複数の銀行、国、通貨、法制度が関わります。
そのため、処理に時間がかかったり、手数料が高くなったり、どの段階まで処理が進んでいるか見えにくくなったりすることがあります。

BISのProject Agoráは、この課題に対して、トークン化された中央銀行準備預金と商業銀行預金を共有プラットフォーム上に記録し、ホールセールのクロスボーダー決済をより速く、安全に、透明性高く処理できるかを検証しているプロジェクトです。BISは、Project Agoráについて、共有プラットフォーム上で中央銀行準備預金と商業銀行預金をトークン化することで、既存の銀行システムの安全性や信頼性を保ちながら、ホールセールのクロスボーダー取引の原子的決済を可能にすることを目指していると説明しています。

参考: BIS Innovation Hub “Project Agorá”

ここで出てくる原子的決済という言葉は、少し技術っぽく聞こえます。
これは、かなりざっくり言えば 全部成功するか、全部失敗するかのどちらかにする処理 です。

💡 豆知識
「原子的」という言葉は、ここでは「小さい」という意味よりも、処理を途中で分割して中途半端な状態にしない、という意味で使われます。
データベースのトランザクションで出てくる atomicity と近い感覚で、「片方だけ成功して片方だけ失敗する」状態を避けるための考え方です。

たとえば、円とドルを交換する取引で、円だけ送金されてドルが届かないと困ります。
そこで、両方の支払いがそろった場合だけ確定し、どちらかが不足していれば全体を失敗にする、という考え方を使います。

Project Agoráのページでは、スマートコントラクトを活用することで、金融機関が取引の中にワークフローのロジック、コンプライアンス要件、条件付き支払いのトリガーを組み込める可能性にも触れられています。これにより、照合作業や手作業など、現在のクロスボーダー決済における遅延・コスト・失敗の要因を減らせる可能性があります。

参考: BIS Innovation Hub “Project Agorá”

6.4 コードで見る：原子的決済のイメージ

ここでは、原子的決済の雰囲気をつかむために、かなり単純化したPythonコードを見てみます。

実際のCBDCや銀行間決済システムは、このような短いコードで動くものではありません。
ここではあくまで、複数の移転をまとめて確認し、全部成功できる場合だけ残高を更新する という考え方を理解するためのサンプルです。

from copy import deepcopy

# 口座残高を、通貨ごとに分けて管理する簡易的な台帳です。
# 実際の金融システムでは、認証、署名、監査ログ、障害対応など、
# さらに多くの仕組みが必要になります。
ledger = {
    "BankA_JPY": {"currency": "JPY", "balance": 1_000_000},
    "BankB_JPY": {"currency": "JPY", "balance": 200_000},
    "BankA_USD": {"currency": "USD", "balance": 1_000},
    "BankB_USD": {"currency": "USD", "balance": 10_000},
}


def atomic_transfer(ledger, transfers):
    """
    複数の送金をまとめて処理する関数です。

    すべての送金が実行できる場合だけ台帳を更新します。
    1つでも残高不足や通貨不一致があれば、台帳を一切更新せずに失敗させます。
    """

    # 途中で失敗しても元の台帳を壊さないように、作業用コピーを作ります。
    working_ledger = deepcopy(ledger)

    # まず、すべての送金が実行可能かを確認します。
    for transfer in transfers:
        sender = transfer["from"]
        receiver = transfer["to"]
        amount = transfer["amount"]
        currency = transfer["currency"]

        # 送金元・送金先の口座が存在するかを確認します。
        if sender not in working_ledger or receiver not in working_ledger:
            return False, "存在しない口座が含まれています", ledger

        # 指定された通貨と、口座の通貨が一致しているかを確認します。
        if working_ledger[sender]["currency"] != currency:
            return False, "送金元口座の通貨が一致しません", ledger
        if working_ledger[receiver]["currency"] != currency:
            return False, "送金先口座の通貨が一致しません", ledger

        # 送金元に十分な残高があるかを確認します。
        if working_ledger[sender]["balance"] < amount:
            return False, "残高不足のため取引全体を取り消します", ledger

        # 確認が通った送金だけ、作業用台帳に反映します。
        # まだ元の台帳は更新していません。
        working_ledger[sender]["balance"] -= amount
        working_ledger[receiver]["balance"] += amount

    # すべての送金が問題なく確認できた場合だけ、更新後の台帳を返します。
    return True, "すべての送金が同時に確定しました", working_ledger


# 例: BankAが円を支払い、BankBがドルを支払う取引をまとめて処理します。
fx_payment = [
    {"from": "BankA_JPY", "to": "BankB_JPY", "amount": 100_000, "currency": "JPY"},
    {"from": "BankB_USD", "to": "BankA_USD", "amount": 700, "currency": "USD"},
]

success, message, updated_ledger = atomic_transfer(ledger, fx_payment)
print(success)       # True
print(message)       # すべての送金が同時に確定しました
print(updated_ledger)

# 例: BankAのドル残高が足りない取引を混ぜると、全体が失敗します。
failed_payment = [
    {"from": "BankA_JPY", "to": "BankB_JPY", "amount": 100_000, "currency": "JPY"},
    {"from": "BankA_USD", "to": "BankB_USD", "amount": 9_999, "currency": "USD"},
]

success, message, updated_ledger = atomic_transfer(ledger, failed_payment)
print(success)       # False
print(message)       # 残高不足のため取引全体を取り消します
print(updated_ledger == ledger)  # True: 元の台帳は変わっていない

このコードで重要なのは、送金を1件ずつその場で確定していない点です。

一度、作業用の台帳に反映しながら全体を検証し、最後にすべて問題なければ確定します。
途中で1つでも問題があれば、元の台帳は変わりません。

このような「全部成功するか、全部失敗するか」という考え方は、データベースのトランザクション処理でも重要です。
DLTやブロックチェーンの文脈では、これを複数の金融機関や複数通貨の取引にまたがってどのように実現するかが大きな論点になります。

6.5 理由4：条件付き支払いを組み込みやすいから

もう一つの理由は、条件付き支払いです。

たとえば、次のような支払いを考えます。

商品が届いたら支払いを実行する
証券トークンが移転できる場合だけ代金を支払う
必要な本人確認や制裁リスト確認が済んだ場合だけ送金を進める
指定された期日になったら自動で支払いを行う

このような処理は、スマートコントラクトやワークフローエンジンのような仕組みと相性があります。

BISのProject Agoráでは、スマートコントラクトを使うことで、ワークフローのロジック、コンプライアンス要件、条件付き支払いのトリガーを取引に直接組み込める可能性が示されています。

参考: BIS Innovation Hub “Project Agorá”

ただし、条件付き支払いも、ブロックチェーンだけの専売特許ではありません。

既存の銀行システムや決済システムでも、条件に応じて処理を進める仕組みはあります。
そのため、CBDCでDLTを検討するときは、「条件付き支払いをしたいからブロックチェーン」ではなく、次のように目的を分解して考える必要があります。

目的	DLTが候補になりやすい理由	既存システムでも検討できる点
複数機関で同じ状態を見たい	共有台帳で状態をそろえやすい	API連携や中央管理DBでも実現可能な場合がある
資産とお金を同時に移転したい	トークン化資産と決済を同じ基盤で扱いやすい	既存のDVPシステムでも同時決済は実現されている
条件付き支払いをしたい	スマートコントラクトで処理を表現しやすい	ワークフローエンジンやルールエンジンでも実装可能
監査しやすい履歴を残したい	改ざん検知しやすい履歴を作りやすい	監査ログ、電子署名、ハッシュチェーンでも実現可能

つまり、DLTは「唯一の答え」ではなく、複数の選択肢の中の一つです。

6.6 理由5：決済インフラの将来像を試す実験台になるから

CBDCやDLTの議論は、単に「今ある決済を少し速くする」だけではありません。

将来的には、次のようなものが同じデジタル基盤の上で接続される可能性があります。

中央銀行マネー
商業銀行預金
証券や債券などの金融資産
ステーブルコイン
RWAトークン
本人確認や資格情報
取引ルールやコンプライアンス処理

このような世界では、「お金だけを動かす」のではなく、「お金・資産・条件・本人確認・監査ログ」をまとめて扱う設計が重要になります。

このような構想では、DLTやブロックチェーンが選択肢に入りやすくなります。
複数の主体が参加し、同じ記録を確認し、条件付きで資産やお金を移転するという性質があるからです。

日本銀行のCBDCフォーラム総括資料でも、ブロックチェーン関連技術としてアセットトークナイゼーションやインターオペラビリティが取り上げられています。また、トークン化はブロックチェーンを利用するケースが多いものの、必ずしもブロックチェーンを利用しなくても必要なプログラマビリティを達成できる可能性があると整理されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（ブロックチェーン関連技術）

6.7 ただし、DLTを使えばすべて解決するわけではない

ここまで見ると、DLTやブロックチェーンはとても便利に見えます。
しかし、CBDCの設計では、便利そうだから採用する、という単純な判断はできません。

特にリテールCBDCでは、日常の支払いに使われる可能性があるため、次のような条件が求められます。

多数の利用者が同時に使っても遅くならないこと
小額決済でも手数料や処理負荷が重くなりすぎないこと
利用者のプライバシーを守れること
不正利用やマネー・ローンダリング対策を組み込めること
災害や通信障害にも耐えられること
障害発生時の責任分界が明確であること

BISと主要中央銀行によるCBDCシステム設計の報告書では、リテールCBDCの設計において、集中型と分散型の選択肢は必ずしも相互排他的ではなく、要件に応じて複数のモジュールを組み合わせる可能性があると整理されています。また、プライバシー、サイバーセキュリティ、オフライン機能、店頭決済などが相互に関係する重要論点として扱われています。

参考: BIS “Central bank digital currencies: system design”

つまり、CBDCの技術選定では、次のようなバランスを考える必要があります。

観点	DLT・ブロックチェーンに期待されること	注意点
共有台帳	関係者が同じ状態を確認しやすい	共有してよい情報の範囲を慎重に決める必要がある
改ざん検知	履歴の検証性を高めやすい	誤ったデータを入れた場合の訂正手順が必要
同時決済	資産とお金をまとめて移転しやすい	法的な決済確定性との整合が必要
自動化	条件付き支払いを表現しやすい	スマートコントラクトのバグや責任分界が問題になる
分散性	単一障害点を減らせる可能性	性能・運用・ガバナンスが複雑になる

6.8 この章のまとめ

この章では、CBDCにDLTやブロックチェーンが検討される理由を整理しました。

ポイントは、次のとおりです。

CBDCにブロックチェーンが必須なわけではない
それでも、複数主体で同じ台帳を共有したい場面ではDLTが候補になる
トークン化資産との同時決済では、ブロックチェーンやスマートコントラクトとの接点が強くなる
ホールセールの国際決済では、トークン化された中央銀行マネーや商業銀行預金を使う実験が進んでいる
原子的決済は、「全部成功するか、全部失敗するか」を実現するための重要な考え方
ただし、性能、プライバシー、法的責任、運用、セキュリティを考えずにDLTを採用することはできない

DLTやブロックチェーンは、CBDCを考えるうえで魅力的な選択肢になる場面があります。
しかし、CBDCはお金そのものに関わる仕組みであるため、技術だけで決められるものではありません。

次の章では、CBDCを実際に設計するうえで重要になる論点を整理します。
プライバシー、本人確認、AML/CFT、オフライン決済、金融安定など、技術と制度が交わる部分を見ていきます。

7. CBDCで重要になる設計論点

この章では、CBDCを実際に設計するうえで重要になる論点を整理します。
ポイントは、台帳技術だけでなく、本人確認、AML/CFT、プライバシー、オフライン決済、金融安定を同時に考える必要があるという点です。

ここまでで、CBDCは「中央銀行が発行するデジタルな中央銀行マネー」であり、ブロックチェーンやDLTはその実装候補の一つであることを整理しました。

では、実際にCBDCを作るとしたら、何を決める必要があるのでしょうか。

ここで大切なのは、CBDCは単なるアプリ開発ではないという点です。
スマホ決済アプリであれば、画面の使いやすさや決済速度が大きな論点になります。もちろんCBDCでもそれらは重要ですが、それだけでは足りません。

CBDCは「お金の基盤」に近い仕組みなので、次のような問いを同時に考える必要があります。

誰が残高や取引を記録するのか
誰が本人確認を行うのか
不正な送金をどう防ぐのか
どこまで利用者のプライバシーを守るのか
通信障害や災害時にも使えるようにするのか
銀行預金や既存の決済サービスとどう共存するのか

日本銀行のCBDCフォーラム総括資料でも、台帳設計、KYC、AML/CFT、認証・認可、標準化、API、現金・銀行預金・民間デジタルマネーとの関係、オフライン決済など、非常に幅広い論点が整理されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（CBDCフォーラムにおけるこれまでの議論の総括）

この章では、細かい制度論に入りすぎず、初学者が全体像をつかみやすいように、主な設計論点を順番に見ていきます。

7.1 台帳設計：誰が「お金の記録」を持つのか

CBDCの設計で最初に大きな論点になるのが、台帳を誰が持つのかです。

ここでいう台帳は、前の章までで何度も出てきたように、誰がいくら持っていて、いつ誰にいくら移動したかを管理する記録です。

CBDCの台帳設計には、ざっくり次のような考え方があります。

設計の方向性	イメージ	利点	注意点
集中管理型	中央システムが台帳を一元管理する	仕組みを比較的シンプルにしやすい	障害時の影響集中、負荷集中、レジリエンスが論点
分担管理型	中央銀行と仲介機関などが役割を分けて管理する	単一障害点を減らしやすい可能性がある	台帳間の整合性、責任分界、システム連携が論点
DLT型	複数の参加者が共有台帳を使う	共有記録や同時決済と相性がよい	性能、プライバシー、ガバナンス、運用が論点

日本銀行のCBDCフォーラム総括資料では、集中管理型は効率的な仕組みになり得る一方で、耐障害性やレジリエンス確保が重要になると整理されています。
また、分担管理型はプライバシー配慮や単一障害点の回避といった利点を得やすい可能性がある一方で、複数の台帳管理システムが存在する場合には、台帳間の整合性をどう確保するかが大きな論点になるとされています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（CBDC台帳と顧客管理システムの構成）

たとえば、AさんがBさんに1,000円を送ったとします。
Aさん側の台帳では残高が減っているのに、Bさん側の台帳では増えていない、という状態が起きると困ります。

この流れの途中で通信障害や処理エラーが起きた場合に、どこまでを「完了」と見るのか。
失敗したときに元に戻すのか、再試行するのか、後から整合性を合わせるのか。

こうした設計は、アプリの見た目よりも地味ですが、CBDCの信頼性を支えるとても重要な部分です。

7.2 仲介機関：中央銀行だけで全部やるのか

CBDCという名前だけを見ると、中央銀行が利用者一人ひとりのウォレットを直接管理するように感じるかもしれません。

しかし、実際の議論では、民間銀行や決済事業者などの仲介機関が関わる設計が重要な論点になります。

仲介機関とは、利用者との接点を持ち、口座開設、本人確認、アプリ提供、問い合わせ対応、トラブル対応などを担う主体です。

イメージとしては、次のようになります。

役割	主体の例	担う可能性があること
中央銀行	日本銀行など	CBDCの発行、基幹台帳、全体ルールの設計
仲介機関	銀行、決済事業者など	ウォレット提供、本人確認、顧客対応、不正検知
追加サービス事業者	家計簿アプリ、EC、地域サービスなど	API連携、付加価値サービス、利用体験の改善
利用者	個人、店舗、企業	支払い、受け取り、残高確認

このように役割を分けると、中央銀行がすべての利用者対応を直接行わなくてもよくなります。
一方で、責任分界は難しくなります。

たとえば、不正送金が起きた場合、原因がウォレットアプリにあるのか、仲介機関の本人確認にあるのか、API連携先にあるのか、利用者端末のマルウェアにあるのかを切り分ける必要があります。

日本銀行の資料でも、KYCやAML/CFT対応を共同化する場合には、効率化の利点がある一方で、責任の所在、運営主体、情報共有に伴うプライバシーリスクなど、整理すべき課題が多いと指摘されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（KYCとAML/CFT対応の共同化）

7.3 KYC・AML/CFT：便利さと不正対策のバランス

CBDCでは、本人確認と不正対策も重要です。

ここで出てくる代表的な用語が、KYC と AML/CFT です。

用語	読み方	ざっくりした意味	身近な例
KYC	Know Your Customer	利用者が誰なのか確認すること	銀行口座開設時の本人確認、スマホでのeKYC
AML	Anti-Money Laundering	マネー・ローンダリング対策	犯罪収益を普通のお金に見せかける行為を防ぐ
CFT	Countering the Financing of Terrorism	テロ資金供与対策	不正な資金移動がテロ活動に使われることを防ぐ

現金に近い使いやすさを目指すなら、少額の支払いまで毎回重い本人確認を求めるのは使いにくくなります。
一方で、誰でも高額送金できるようにしてしまうと、不正送金やマネー・ローンダリングに悪用されるおそれがあります。

そのため、CBDCでは「何でも同じ強度で確認する」のではなく、取引のリスクに応じて確認レベルを変えるという考え方が重要になります。

日本銀行のCBDCフォーラム総括資料でも、KYCやAML/CFTの水準はCBDCが提供する機能に応じて変わり得ること、身元確認の実施状況に応じて機能の提供範囲を変えることで一定のユニバーサルアクセスを確保できる可能性があることが議論されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（KYCやAML/CFTの水準）

7.4 リスクに応じた制御のイメージ

以下は、CBDCの実際の仕様ではありません。
あくまで、リスクに応じて利用できる機能を変えるという考え方を理解するための簡単な例です。

from dataclasses import dataclass


@dataclass
class TransferRequest:
    """CBDC送金リクエストの簡易モデル。実際のCBDC仕様ではありません。"""
    amount: int                    # 送金額
    sender_kyc_level: str          # 送金者の本人確認レベル: none / basic / full
    recipient_verified: bool       # 受取人が確認済みかどうか
    is_offline: bool               # オフライン決済かどうか
    daily_total: int               # その日の累計送金額


def evaluate_transfer(request: TransferRequest) -> tuple[bool, str]:
    """送金を許可するかどうかを、簡単なルールで判定する。"""

    # 例1: 本人確認なしの場合は、少額・低リスクの利用だけに制限する
    if request.sender_kyc_level == "none":
        if request.amount > 10_000:
            return False, "本人確認なしでは高額送金はできません"

    # 例2: 高額送金の場合は、より強い本人確認を求める
    if request.amount > 100_000 and request.sender_kyc_level != "full":
        return False, "高額送金にはフルKYCが必要です"

    # 例3: オフライン決済では、台帳にすぐ確認できないため金額を小さく制限する
    if request.is_offline and request.amount > 5_000:
        return False, "オフライン決済では送金額の上限を超えています"

    # 例4: 1日の累計額が大きい場合は、不正対策として追加確認に回す
    if request.daily_total + request.amount > 200_000:
        return False, "1日の累計送金額が大きいため追加確認が必要です"

    # 例5: 受取人情報が未確認の場合は、送金を止める設計も考えられる
    if not request.recipient_verified:
        return False, "受取人情報が未確認です"

    # すべてのチェックを通過した場合のみ許可する
    return True, "送金可能です"


request = TransferRequest(
    amount=3_000,
    sender_kyc_level="basic",
    recipient_verified=True,
    is_offline=True,
    daily_total=12_000,
)

allowed, reason = evaluate_transfer(request)
print(allowed, reason)

このコードはとても単純ですが、設計上の考え方は伝わりやすいと思います。

少額なら使いやすくする
高額なら強い本人確認を求める
オフラインなら上限を低くする
急に利用額が増えたら追加確認する
受取人情報が怪しい場合は止める

実際のCBDCでは、これに加えて法律、本人確認制度、金融機関の業務、利用者保護、障害時対応、プライバシー保護などが関わります。
そのため、単純なif文だけで設計できるものではありませんが、利便性とリスク管理のバランスを取るという考え方は重要です。

7.5 プライバシー：誰がどこまで取引情報を見られるのか

CBDCでよく議論されるのが、プライバシーです。

現金でコンビニに行って飲み物を買う場合、銀行アプリのような明細は残りません。
一方で、スマホ決済やクレジットカードを使うと、いつ、どこで、いくら使ったかという情報がサービス側に残ります。

CBDCはデジタルなお金なので、設計によっては取引情報を細かく記録できます。
しかし、記録できるからといって、すべての関係者がすべての情報を見られる設計にするとは限りません。

ここで重要になるのは、誰に、どの情報を、どの目的で見せるのかという設計です。

関係者	見える可能性がある情報	注意点
利用者本人	自分の残高、利用履歴	分かりやすいUIが必要
仲介機関	本人確認情報、取引情報の一部	不正対策と個人情報保護の両立が必要
中央銀行	CBDC全体の発行・流通状況など	個人単位の情報をどこまで扱うかが論点
追加サービス事業者	家計簿連携などに必要な範囲の情報	同意、目的外利用、API権限管理が重要
規制・捜査機関	法令に基づき必要な情報	ルールと手続きの明確化が必要

たとえば、家計簿アプリとCBDCウォレットを連携する場合、家計簿アプリには「利用履歴を読む権限」が必要かもしれません。
しかし、そのアプリが送金までできる必要はありません。

このように、必要な情報・必要な権限だけを渡す設計にすると、便利さと安全性のバランスを取りやすくなります。

日本銀行の資料でも、追加サービスとAPIに関して、CBDCエコシステム全体への信頼を確保する観点から、品質保証やAPIの開発容易性が重要であることが議論されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（追加サービスとAPI）

また、IMFのCBDC Virtual Handbookでは、CBDCに関する論点としてデータ利用とプライバシー保護、金融安定、金融包摂、クロスボーダー決済、サイバーレジリエンスなどが章立てで整理されています。

参考: IMF “Central Bank Digital Currency (CBDC) - Virtual Handbook”

7.6 オフライン決済：通信がないときにも使えるのか

現金の強いところは、インターネットにつながっていなくても使えることです。

災害時に通信が不安定になった場合でも、手元に現金があれば支払いに使える可能性があります。
CBDCを「現金に近いデジタルなお金」として考えるなら、オフライン決済は避けて通れない論点になります。

ただし、デジタルなお金をオフラインで使うのは簡単ではありません。

オンライン決済では、台帳に問い合わせて「この人は本当に残高を持っているか」「同じ残高を別の場所で使っていないか」を確認できます。
しかし、オフラインでは台帳にすぐ確認できません。

BIS Innovation HubのProject Polarisでは、オフラインCBDC決済を「台帳システムへの接続を必要とせず、端末間でCBDCの価値を移転するもの」と定義しています。
同ハンドブックでは、オフライン決済は金融包摂や決済システムのレジリエンスに役立つ可能性がある一方、技術、セキュリティ、運用面の考慮を初期段階から設計する必要があるとされています。

参考: BIS Innovation Hub “Project Polaris: Handbook for offline payments with CBDC”

💡 豆知識
オフライン決済は、単に「スマホを機内モードにしても使える」というだけの話ではありません。
端末が本当に正しいCBDC残高を持っているか、同じ残高を別の相手にも使っていないか、端末が改造されていないか、紛失・盗難時にどう扱うか、オンライン復帰後に台帳とどう同期するかまで含めて設計する必要があります。

このため、オフラインCBDCでは、利用上限、端末の耐タンパ性、暗号技術、同期処理、紛失時の扱いなどを組み合わせて考える必要があります。

7.7 金融安定：便利すぎるお金は銀行預金に影響するかもしれない

CBDCは、中央銀行が発行するデジタルなお金です。
もし安全で便利で、誰でも簡単に持てるCBDCができた場合、利用者が銀行預金からCBDCへ資金を移す可能性があります。

普段の少額決済であれば大きな問題にならなくても、金融不安が起きたときに「銀行預金よりCBDCに移しておこう」と多くの人が一斉に動くと、銀行の資金繰りや金融システムに影響する可能性があります。

そのため、CBDCの設計では、次のような工夫が検討対象になります。

設計上の工夫	目的	注意点
保有上限	銀行預金からCBDCへの急激な資金移動を抑える	上限が低すぎると利便性が下がる
取引上限	高額・不自然な送金を抑える	正当な利用まで妨げないようにする必要がある
無利子設計	預金との競合を抑える	金利環境によって影響が変わる
仲介機関の関与	既存金融システムとの接続を保つ	役割分担と責任分界が必要
段階的な導入	影響を見ながら進める	実証実験や利用状況の観察が重要

BISと複数の中央銀行による共同報告書では、CBDCを検討するうえで、金融・通貨の安定を損なわず、既存のお金と共存・補完し、イノベーションと効率性を促すことが重要な条件として整理されています。

参考: BIS “Central bank digital currencies: foundational principles and core features”

また、IMFのCBDC Virtual Handbookでも、CBDCが金融安定や決済競争、金融包摂、クロスボーダー決済などに与える影響が論点として整理されています。

参考: IMF “Central Bank Digital Currency (CBDC) - Virtual Handbook”

7.8 相互運用性：既存の決済サービスとどうつなぐのか

CBDCは、仮に導入されるとしても、いきなり世の中の決済をすべて置き換えるものとして考えられているわけではありません。

現金、銀行預金、クレジットカード、電子マネー、QRコード決済、地域通貨、ポイントなど、すでに多くの支払い手段があります。
CBDCを考えるなら、これらとどう共存するかが重要です。

たとえば、利用者から見ると、次のような疑問が出てきます。

銀行預金からCBDCにチャージできるのか
CBDCを現金に戻せるのか
既存のスマホ決済アプリからCBDCを使えるのか
店舗側は今の決済端末を使えるのか
家計簿アプリや会計ソフトと連携できるのか

日本銀行のCBDCフォーラム総括資料では、CBDCと現金、銀行預金、民間デジタルマネーとの関係や、既存の決済ネットワーク・インフラを活用する可能性と課題が議論されています。既存インフラの活用は利用促進に役立つ可能性がある一方、既存ネットワークが複雑であるため、活用範囲や新規ネットワーク構築との比較を慎重に考える必要があるとされています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（相互運用性と水平的共存）

ここで大事なのは、CBDCを「新しい決済手段を一つ増やす話」だけで見ないことです。
むしろ、既存の決済サービスや金融機関、店舗、利用者アプリとどう接続し、どこを共通化し、どこを民間の工夫に任せるのかという、エコシステム全体の設計が重要になります。

この図のように、CBDCは単独で存在するというより、さまざまなシステムとつながる可能性があります。
だからこそ、標準化、API、認証・認可、責任分界、品質保証が重要になります。

日本銀行の資料でも、CBDCエコシステムを担う仲介機関や追加サービス事業者の技術レベル・セキュリティレベルを一定水準に保つためには、仕様書やガイドライン等による標準化が重要であると議論されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（仕様の標準化）

7.9 この章のまとめ

この章では、CBDCで重要になる設計論点を整理しました。

ポイントは、次のとおりです。

CBDCは、技術だけでなく制度・運用・金融システム全体の設計が必要
台帳設計では、集中管理型、分担管理型、DLT型それぞれに利点と注意点がある
仲介機関をどう関与させるかによって、利用者対応や責任分界が変わる
KYCやAML/CFTでは、利便性と不正対策のバランスが重要になる
プライバシーでは、誰がどの情報をどの目的で見られるかを明確にする必要がある
オフライン決済は現金に近い使いやすさにつながる一方で、二重支払いや端末改ざんへの対策が必要
金融安定の観点では、銀行預金からCBDCへの急激な資金移動をどう抑えるかが論点になる
既存の銀行、決済サービス、店舗端末、アプリとどう接続するかも重要

CBDCは、便利なデジタル通貨を作ればよい、という単純なものではありません。
便利さを高めるほど、不正対策やプライバシー保護、金融安定との調整が必要になります。

次の章では、これらの設計論点の中でも、情報セキュリティの観点に絞って整理します。
ウォレット、認証、API、監査ログ、改ざん検知、不正検知など、セキュリティを学ぶ人にとって特に重要な部分を見ていきます。

8. 情報セキュリティの観点で見るCBDC

この章では、CBDCを情報セキュリティの観点から整理します。
ポイントは、台帳だけでなく、ウォレット、認証、API、監査ログ、オフライン決済、運用体制まで守る必要があるという点です。

ここまで、CBDCの種類や設計論点を見てきました。
この章では、その中でも 情報セキュリティ に焦点を当てます。

CBDCは「デジタルなお金」なので、便利さだけでなく、次のような問いを避けて通れません。

本人以外が勝手に送金できないか
取引記録や残高が改ざんされないか
障害や災害時にも使えるか
不正利用を検知できるか
その一方で、利用者の取引情報を必要以上に見せない設計にできるか

たとえば、スマホ決済アプリを思い浮かべると分かりやすいです。
スマホをなくしたとき、第三者が勝手に支払える状態だと困ります。アプリの残高が勝手に増減しても困ります。通信障害でレジ前に人が詰まってしまうのも困ります。

CBDCでは、こうした身近な問題が、より公共性の高い決済インフラとして扱われます。
そのため、単に「台帳を安全に作る」だけではなく、ウォレット、本人確認、認証、API、監査ログ、オフライン決済、運用体制まで含めて考える必要があります。

IMFのCBDCサイバーレジリエンスに関するノートでも、CBDCは広く複雑なエコシステムを作り、既存のリスクを増幅したり新しいリスクを生んだりする可能性があると整理されています。

参考: IMF “Cyber Resilience of the Central Bank Digital Currency Ecosystem”

8.1 CBDCで守る対象は「台帳」だけではない

ブロックチェーンの記事では、台帳の改ざん検知や複数ノードでの検証に注目しがちです。
しかし、CBDCのセキュリティを考えるときは、もっと広い範囲を見る必要があります。

たとえば、台帳そのものが安全でも、利用者のスマホが乗っ取られて送金されれば被害は発生します。
逆に、ウォレットの認証が強くても、仲介機関のAPI設計が弱ければ、外部連携部分から不正操作される可能性があります。

つまりCBDCのセキュリティでは、一つの強い技術だけで守るというより、複数の層で守る考え方が重要になります。

8.2 セキュリティの基本観点で整理する

まずは、情報セキュリティでよく使われる観点に当てはめてみます。

観点	CBDCでの意味	身近な例
機密性	取引情報や本人情報が必要以上に見えないこと	自分の支払い履歴が誰にでも見えると困る
完全性	残高や取引記録が勝手に変わらないこと	送っていないのに残高が減ると困る
可用性	必要なときに支払えること	レジ前で決済システムが止まると困る
認証	本人であることを確認すること	スマホのロック解除、パスキー、生体認証など
認可	何をしてよいかを制御すること	残高照会はよいが、送金は追加確認が必要など
監査可能性	何が起きたか後から確認できること	不正送金が起きたときに経路を追えること

CBDCで難しいのは、これらの観点が互いに引っ張り合うことです。

たとえば、不正検知を強くするために取引情報を細かく集めれば、プライバシーへの配慮が難しくなります。
逆に、プライバシーを重視しすぎて取引情報をほとんど見えなくすると、マネー・ローンダリング対策や詐欺対策が難しくなる可能性があります。

そのため、CBDCでは「セキュリティを強くする」だけでなく、どの情報を、誰が、どの目的で、どの範囲まで扱うのかを設計する必要があります。

IMFのCBDC Virtual Handbookでも、リテールCBDCにおけるAML/CFTの適用や、CBDCの設計機能が金融犯罪対策に与える影響が論点として整理されています。

参考: IMF “Central Bank Digital Currency (CBDC) - Virtual Handbook”

8.3 ウォレットをどう守るか

CBDCを利用者が使う場合、多くの場面ではスマホアプリやカード型デバイスのような ウォレット が登場すると考えられます。

ウォレットは、単なる画面ではありません。
利用者が「自分のCBDCを使うための入口」です。

そのため、ウォレットでは次のような対策が必要になります。

リスク	例	必要になる対策の方向性
端末紛失	スマホを落とした	端末ロック、遠隔停止、再発行手続き
なりすまし	他人がログインする	多要素認証、生体認証、パスキー等
マルウェア	端末内の不正アプリが操作する	OS保護、アプリ署名、改ざん検知
フィッシング	偽アプリや偽サイトに誘導される	公式配布、利用者教育、認証画面の工夫
秘密情報の漏えい	鍵やトークンが盗まれる	セキュア領域での保存、短命トークン、再認証

ここでいう「鍵」や「トークン」は、家の鍵に近いイメージです。
鍵を持っている人だけがドアを開けられるように、デジタル決済でも、正しい権限を持つ人だけが操作できるようにします。

ただし、CBDCのウォレット設計が必ず暗号資産ウォレットと同じになるとは限りません。
暗号資産では、秘密鍵を利用者が直接管理する形が多く見られます。一方で、CBDCでは中央銀行、仲介機関、ウォレット提供者、利用者の役割分担によって、鍵管理や復旧手続きの設計が変わります。

たとえば、スマホをなくしたときに「二度と残高を取り戻せない」設計では、日常決済としては使いにくいかもしれません。
一方で、簡単に復旧できすぎると、本人確認をすり抜けた不正復旧のリスクが高まります。

このように、ウォレットでは 安全性 と 使いやすさ のバランスが重要になります。

💡 豆知識
CBDCのウォレットを考えるときは、「スマホアプリを守る」だけでなく、お金を動かす権限を守る と考えると分かりやすいです。
ログインできること、残高を見られること、高額送金できることは同じではないため、操作ごとに必要な確認の強さを変える設計が重要になります。

8.4 認証と認可：ログインできることと、送金できることは別

CBDCのセキュリティでは、認証と認可を分けて考えることが大切です。

認証は「あなたは誰ですか？」を確認することです。
認可は「あなたは何をしてよいですか？」を判断することです。

たとえば、スマホ決済アプリにログインできたとしても、すぐに高額送金まで許可してよいとは限りません。

操作	必要な確認の例
残高を見る	通常ログインでよいかもしれない
少額の支払い	端末ロック解除でよいかもしれない
高額送金	追加認証が必要かもしれない
新しい端末への移行	本人確認や復旧手続きが必要かもしれない
API連携サービスに権限を渡す	どの範囲まで許可するか明示する必要がある

日本銀行のCBDCフォーラム総括資料でも、CBDCでは標準化された認証・認可の方式を採用すべきこと、ユースケースとリスクを整理したうえで国内外の標準規格やガイドラインを活用することが望ましいことが議論されています。
また、FIDO2、OpenID Connect、NIST SP 800-63等への言及や、高いセキュリティ要件を満たすFAPIへの準拠が検討事項として示されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（認証・認可）

NIST SP 800-63-4は、デジタルIDに関するガイドラインとして、身元確認、認証、フェデレーションに関する技術要件や推奨事項を整理しています。CBDC専用の文書ではありませんが、デジタルIDや認証強度を考えるうえで参考になります。

参考: NIST SP 800-63-4 Digital Identity Guidelines

FAPI（Financial-grade API）は、OAuth 2.0を基にした高セキュリティ用途向けのAPIセキュリティプロファイルです。金融取引や重要なデータ連携のように、通常のAPIより高い安全性が求められる場面で参考にされます。

参考: OpenID Foundation “FAPI 2.0 Security Profile”

次のコードは、取引の金額や送金先の状態に応じて、追加認証を求めるかどうかを簡単に判定する例です。
本格的な不正検知ではありませんが、「リスクに応じて認証強度を変える」という考え方をつかむためのサンプルです。

from dataclasses import dataclass

@dataclass
class PaymentRequest:
    sender: str
    receiver: str
    amount: int
    is_new_receiver: bool
    device_trusted: bool


def required_auth_level(request: PaymentRequest) -> str:
    """
    取引のリスクに応じて、必要な認証レベルを返す簡易例。
    実際のCBDCシステムでは、法令・制度設計・不正検知結果・利用者保護などを含めて判断する。
    """

    # 低額かつ既知の端末・送金先であれば、通常の認証で足りると仮定する
    if request.amount <= 3_000 and not request.is_new_receiver and request.device_trusted:
        return "通常認証"

    # 新しい送金先や信頼済みでない端末の場合は、追加確認を求める
    if request.is_new_receiver or not request.device_trusted:
        return "追加認証"

    # 高額取引では、より強い本人確認や取引確認を求める
    if request.amount >= 100_000:
        return "強い追加認証"

    # それ以外は中程度のリスクとして追加認証を求める
    return "追加認証"


requests = [
    PaymentRequest("alice", "shop", 1200, False, True),
    PaymentRequest("alice", "new_user", 5000, True, True),
    PaymentRequest("alice", "bob", 150000, False, True),
    PaymentRequest("alice", "mall", 2000, False, False),
]

for request in requests:
    print(request, "=>", required_auth_level(request))

この例で大事なのは、すべての取引に一律で重い認証を求めるわけではない点です。
毎回複雑な確認が必要だと、利用者は使いにくく感じます。逆に、すべてを簡単にしすぎると、不正送金のリスクが高まります。

CBDCでは、利用者体験と安全性のバランスを取りながら、取引の種類に応じた認証設計を考える必要があります。

8.5 API連携では「過剰な権限」を避ける

CBDCが社会の決済インフラとして使われる場合、銀行、決済事業者、家計簿アプリ、店舗システム、行政サービスなど、さまざまなシステムと連携する可能性があります。

このときに重要になるのがAPIです。
APIは、ざっくり言えば「システム同士が安全にやり取りするための窓口」です。

たとえば、家計簿アプリがCBDCウォレットと連携する場合を考えます。
家計簿アプリに必要なのは、利用履歴の読み取りかもしれません。送金権限までは不要です。

連携サービス	必要そうな権限	不要な権限の例
家計簿アプリ	利用履歴の読み取り	送金実行
店舗決済端末	決済要求の作成	利用者の全履歴閲覧
税公金支払い	指定先への支払い	任意の第三者への送金
見守りサービス	利用通知の受信	残高移動

このように、API連携では 最小権限の原則 が重要になります。
これは「必要な操作だけを許可し、余計な権限は渡さない」という考え方です。

この図では、外部アプリに「利用履歴の読み取り」だけを許可しています。
もし外部アプリやアクセストークンが悪用されても、送金まではできない設計にしておけば、被害を小さくできます。

日本銀行の資料でも、追加サービス提供事業者にとって標準化されたAPIと認可の実装が必要である一方、どの範囲をどの程度共通化するか、仲介機関側の負担をどう考えるかが論点として示されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（追加サービスとAPI）

8.6 取引記録と監査ログを改ざんから守る

CBDCでは、残高や取引履歴が勝手に変わらないことがとても重要です。
これは情報セキュリティでいう 完全性 に関係します。

ここで、ブロックチェーンの記事で出てきたハッシュチェーンの考え方が役に立ちます。
ハッシュチェーンとは、前の記録のハッシュ値を次の記録に含めることで、途中の記録が改ざんされたときに後続のハッシュがずれる仕組みです。

ただし、CBDCの監査ログが必ずブロックチェーンになるという意味ではありません。
集中管理型のシステムでも、監査ログ、電子署名、HSM、アクセス制御、バックアップ、改ざん検知などを組み合わせて完全性を高めることはできます。

次のコードは、取引ログをハッシュチェーンでつなぎ、途中で改ざんされていないか確認する簡単な例です。

import hashlib
import json
from dataclasses import dataclass, asdict

@dataclass
class AuditRecord:
    index: int
    transaction_id: str
    action: str
    amount: int
    previous_hash: str
    record_hash: str = ""


def calc_hash(record: AuditRecord) -> str:
    """
    監査ログ1件分のハッシュ値を計算する。
    record_hash 自体は計算対象から外し、その他の内容が変わるとハッシュが変わるようにする。
    """
    data = asdict(record)
    data.pop("record_hash")

    # JSON文字列にしてからハッシュ化する。
    # sort_keys=True にすることで、キーの順番による差を避ける。
    serialized = json.dumps(data, sort_keys=True, ensure_ascii=False)
    return hashlib.sha256(serialized.encode("utf-8")).hexdigest()


def append_record(chain: list[AuditRecord], transaction_id: str, action: str, amount: int) -> None:
    """
    監査ログを1件追加する。
    直前のログのハッシュ値を previous_hash として保持することで、ログ同士をつなげる。
    """
    previous_hash = chain[-1].record_hash if chain else "GENESIS"
    record = AuditRecord(
        index=len(chain),
        transaction_id=transaction_id,
        action=action,
        amount=amount,
        previous_hash=previous_hash,
    )
    record.record_hash = calc_hash(record)
    chain.append(record)


def verify_chain(chain: list[AuditRecord]) -> bool:
    """
    監査ログ全体が改ざんされていないか確認する。
    1. 各ログのハッシュ値が内容と一致するか
    2. previous_hash が直前ログの record_hash と一致するか
    を確認する。
    """
    for i, record in enumerate(chain):
        if record.record_hash != calc_hash(record):
            return False

        expected_previous = "GENESIS" if i == 0 else chain[i - 1].record_hash
        if record.previous_hash != expected_previous:
            return False

    return True


# 監査ログを作成する
chain: list[AuditRecord] = []
append_record(chain, "tx001", "PAYMENT", 1200)
append_record(chain, "tx002", "PAYMENT", 3000)
append_record(chain, "tx003", "REFUND", 500)

print("改ざん前:", verify_chain(chain))

# 途中のログを不正に書き換える例
chain[1].amount = 1

print("改ざん後:", verify_chain(chain))

このコードを実行すると、改ざん前は検証に成功し、途中のログを書き換えた後は検証に失敗します。

もちろん、実際のCBDCシステムでは、これだけでは不十分です。
誰がログを書き込めるのか、ログをどこに保存するのか、秘密鍵をどう守るのか、障害時にどう復旧するのか、証跡をどの期間保存するのかなど、多くの設計が必要です。

それでも、この小さな例から、あとから検証できる記録を残すという考え方はつかめます。

8.7 不正検知とプライバシーのバランス

CBDCでは、不正送金やマネー・ローンダリングを検知する仕組みも重要になります。
一方で、すべての利用履歴を誰でも細かく見られるようにすると、利用者のプライバシーに大きな不安が生まれます。

そのため、CBDCでは次のようなバランスが必要になります。

目的	必要になる情報の例	注意点
不正送金の検知	取引金額、頻度、送金先、端末情報など	必要以上の監視にならないようにする
AML/CFT	本人確認情報、取引パターン、制裁対象確認など	法令・制度に沿った権限管理が必要
利用者保護	不審なログイン、端末変更、異常な送金	誤検知時の説明や解除手続きが必要
障害調査	取引ID、処理時刻、エラー内容	個人情報を含めすぎないようにする

日本銀行のCBDCフォーラム総括資料でも、不正検知や取引モニタリングを共同化する場合の課題として、責任の所在、説明責任、共同システムで扱う情報、金融機関ごとの事情などが議論されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（KYCとAML/CFT）

次のコードは、非常に単純なルールで不審な取引を検知する例です。
実際の金融犯罪対策では、このような単純ルールだけで判断することはできませんが、「検知した理由を説明できること」の大切さを理解するための例として見てください。

from dataclasses import dataclass

@dataclass
class Transaction:
    tx_id: str
    user_id: str
    amount: int
    receiver: str
    minutes_since_previous_tx: int
    is_new_receiver: bool


def detect_suspicious_transaction(tx: Transaction) -> list[str]:
    """
    不審な取引かどうかを、説明可能なルールで判定する簡易例。
    実運用では、法令、リスク評価、利用者保護、誤検知対応などを含めた慎重な設計が必要になる。
    """
    reasons = []

    # 高額取引は追加確認の対象になりやすい
    if tx.amount >= 100_000:
        reasons.append("高額取引")

    # 短時間に続けて送金している場合は確認対象にする
    if tx.minutes_since_previous_tx <= 1:
        reasons.append("短時間での連続取引")

    # 新しい送金先への高額送金はリスクが高いと仮定する
    if tx.is_new_receiver and tx.amount >= 30_000:
        reasons.append("新規送金先への比較的大きな送金")

    return reasons


transactions = [
    Transaction("tx001", "alice", 1200, "shop", 60, False),
    Transaction("tx002", "alice", 150000, "bob", 10, False),
    Transaction("tx003", "alice", 50000, "unknown", 1, True),
]

for tx in transactions:
    reasons = detect_suspicious_transaction(tx)
    if reasons:
        print(tx.tx_id, "確認対象:", reasons)
    else:
        print(tx.tx_id, "通常処理")

この例では、「なぜ確認対象になったのか」を理由として返しています。
不正検知では、検知精度だけでなく、利用者や関係機関に対して説明できることも大切です。

特にCBDCのような公共性の高い仕組みでは、AIや機械学習で不正検知を行う場合でも、誤検知、説明責任、異議申し立て、データの取り扱いを慎重に考える必要があります。

8.8 オフライン決済では二重支払いへの対策が難しい

オフライン決済は、CBDCのセキュリティで特に面白く、難しいテーマです。

通常のオンライン決済では、台帳システムに接続して「この人の残高は足りているか」「この取引はすでに使われていないか」を確認できます。
しかし、オフライン決済では、通信がない状態で支払いを行うため、すぐに中央の台帳へ確認できません。

ここで問題になるのが、二重支払い です。

同じ残高を使って、通信できない間に複数の相手へ支払おうとする攻撃が考えられます。
オンラインなら台帳がすぐに拒否できますが、オフラインではその場で全体の整合性を確認しにくくなります。

BISのProject Polarisでは、オフラインCBDC決済はレジリエンス、包摂、プライバシー、現金らしさの観点から重要である一方、技術・セキュリティ・運用面の考慮を早い段階から計画・設計する必要があると説明されています。また、各国の要件により適した方式が異なるため、万能の解決策はないと整理されています。

参考: BIS “Project Polaris: handbook for offline payments with CBDC”

オフライン決済で考えられる対策の方向性は、たとえば次のようなものです。

対策	ねらい	注意点
少額・回数制限	被害額を抑える	利便性とのバランスが必要
セキュアエレメント	端末内の価値や鍵を守る	端末コストや供給体制が課題
後同期時の検証	オンライン復帰後に不正を検知	その場で完全に防げるとは限らない
リスクに応じた利用制限	高リスク取引をオンライン必須にする	災害時の使いやすさとの調整が必要
監査ログ	後から調査できるようにする	プライバシー保護との両立が必要

オフライン決済は、現金に近い使いやすさを実現する可能性があります。
しかし、デジタルである以上、端末改ざん、秘密情報の抽出、二重支払い、後同期時の不整合などを考慮する必要があります。

8.9 運用とレジリエンスもセキュリティの一部

セキュリティというと、暗号技術や認証方式を思い浮かべがちです。
しかし、CBDCのような決済インフラでは、止まらないこと、壊れても戻せること、攻撃を受けても被害を抑えられることも重要です。

観点	内容
冗長化	片方のシステムが止まっても別系統で動かす
バックアップ	データ破損や障害時に復旧できるようにする
監視	異常なアクセスや取引増加を検知する
インシデント対応	攻撃や障害時の連絡・封じ込め・復旧手順を決める
サプライチェーン管理	ウォレット、端末、クラウド、外部APIなどの依存先を管理する
権限管理	運用担当者やシステムの権限を最小化する

日本銀行のCBDCフォーラム総括資料でも、CBDCシステムの基本特性として強靭性や即時決済性、台帳システム間の整合性確保、エラー対応、仲介機関間のネットワーク整備などが論点として整理されています。

参考: 日本銀行「パイロット実験」進捗報告書別冊（CBDCシステムのアーキテクチャー）

ここでのポイントは、CBDCのセキュリティを「攻撃されないこと」だけで考えないことです。
現実のシステムでは、障害や設定ミス、連携先の問題、利用者の端末紛失なども起こりえます。

そのため、CBDCでは予防、検知、対応、復旧をまとめて考える必要があります。

この流れは、一般的なインシデントレスポンスにも通じます。
攻撃や障害を完全にゼロにすることは難しいため、起きたときに素早く気づき、被害を限定し、再発防止につなげる設計が重要になります。

8.10 この章のまとめ

この章では、CBDCを情報セキュリティの観点から整理しました。

ポイントは、次のとおりです。

CBDCでは、台帳だけでなく、ウォレット、認証、API、監査ログ、オフライン決済、運用まで守る必要がある
セキュリティの基本観点として、機密性、完全性、可用性、認証、認可、監査可能性が重要になる
ウォレットでは、端末紛失、なりすまし、マルウェア、フィッシング、秘密情報の漏えいへの対策が必要
認証と認可は別物であり、ログインできることと送金できることは分けて考える必要がある
API連携では、必要最小限の権限だけを渡す設計が重要
監査ログや取引記録では、あとから検証できる完全性の確保が重要
不正検知では、検知精度だけでなく、説明責任やプライバシーへの配慮も必要
オフライン決済では、二重支払い、端末改ざん、後同期時の不整合が大きな論点になる
CBDCのセキュリティは、技術だけでなく運用・責任分界・復旧体制まで含めて考える必要がある

CBDCは、ブロックチェーンや暗号技術だけで成立するものではありません。
利用者が毎日の支払いに使う可能性がある以上、セキュリティは「裏側の専門的な話」ではなく、使いやすさや安心感に直結するテーマです。

次の章では、ここまで整理した技術・制度・セキュリティの観点を踏まえて、日本銀行や海外中央銀行でどのような検討が進んでいるのかを見ていきます。

9. 最近の動向：日本銀行と海外の検討状況

この章では、日本銀行と海外中央銀行におけるCBDCの検討状況を整理します。
ポイントは、導入済み・実証中・未決定を混同せず、一次情報をもとに現在の位置づけを見ることです。

ここまで、CBDCを「お金の記録」「台帳設計」「ブロックチェーン/DLT」「セキュリティ」という観点から見てきました。

この章では、少し視点を外に広げて、日本銀行や海外中央銀行では実際にどのような検討が進んでいるのかを整理します。

ただし、CBDCの状況は国や地域によってかなり違います。
すでに一般利用が始まっている国もあれば、実証実験の段階にある国、制度設計を議論している国、導入に慎重な国もあります。

そのため、この記事では「どの国が進んでいるか」を競争のように見るのではなく、それぞれの国・地域が、どの課題を解こうとしてCBDCを検討しているのか に注目して整理します。

検証日: 2026-07-03
CBDCの検討状況は変化しやすいため、最新情報を確認する場合は各中央銀行・公的機関の一次情報を参照してください。

💡 豆知識
CBDCのニュースでは、「導入」「実証実験」「パイロット」「検討」「準備段階」といった言葉が並びます。
これらは同じ意味ではありません。資料を読むときは、本当に一般利用が始まったのか、技術実験なのか、制度設計の検討なのかを分けて見ると誤解を避けやすくなります。

9.1 まず全体像を表で整理する

最初に、この記事で扱う主な国・地域・国際機関の状況をざっくり並べます。

国・地域・機関	状況の大まかな整理	読むときのポイント
日本	導入は未決定。日本銀行が実証実験やCBDCフォーラムを通じて検討中	「検討中」と「導入決定済み」を混同しない
BIS	各国中央銀行の調査・実証を横断的に整理	世界全体の傾向を見るときに有用
ユーロ圏	デジタルユーロの準備を継続。発行判断に向けた技術・制度面の準備段階	発行そのものは、法制度や最終判断に左右される
米国	FRBはCBDCの基本説明を公表。一方、2025年の大統領令では連邦機関によるCBDC推進を禁止する方向	技術論だけでなく、政策判断・政治的論点が大きい
バハマ	Sand Dollarを全国展開	金融包摂や島しょ国の決済アクセスが背景にある
ナイジェリア	eNairaを導入済み	法定通貨としてのCBDCと普及課題を考える例になる
ジャマイカ	JAM-DEXを展開	「CBDCは暗号資産ではない」という説明が分かりやすい

ここで見えてくるのは、CBDCは単に「新しい決済技術」ではなく、各国の金融制度、決済習慣、現金利用、プライバシー観、金融包摂、国際決済の課題と結びついているという点です。

9.2 日本：導入決定ではなく、実証実験と制度設計の検討段階

日本についてまず押さえておきたいのは、CBDCの導入は決定していない という点です。

日本銀行は、CBDCについて「誰でも24時間365日使える現金をデジタル化したような支払決済手段」が主に想定されると説明しています。
ただし、日本でCBDCを導入するかどうかは、内外の情勢も踏まえ、今後の国民的な議論の中で決まっていくものとされています。

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

日本銀行は、CBDCに関する実証実験を段階的に進めてきました。
公表資料を見ると、概念実証、パイロット実験、CBDCフォーラム、関係府省庁・日本銀行連絡会議など、技術面だけでなく制度面・実務面も含めて検討していることが分かります。

参考: 日本銀行「中央銀行デジタル通貨」

2026年6月に公表された日本銀行のCBDCフォーラム総括資料では、台帳設計、端末、UI/UX、KYC、AML/CFT、認証・認可、標準化、API、現金・銀行預金・民間デジタルマネーとの共存、オフライン決済、ブロックチェーン関連技術など、かなり幅広い論点が扱われています。

また、財務省のページでは、CBDCについて政府・日本銀行として制度設計の大枠を整理するため、関係府省庁・日本銀行連絡会議が設置されていることが示されています。
2024年の中間整理、2025年の第2次中間整理、2026年の進捗報告も公表されています。

参考: 財務省「CBDC（中央銀行デジタル通貨）に関する関係府省庁・日本銀行連絡会議」

この流れを見ると、日本では「すぐにデジタル円が始まる」というより、将来必要になったときに備えて、技術・制度・実務の論点を丁寧に洗い出している段階だと考えるのが自然です。

9.3 日本の動向を見るときの注意点

日本のCBDCについて調べるときは、次のような表現に注意が必要です。

表現	注意点
デジタル円が始まる	導入決定済みのように聞こえるが、日本銀行は導入未決定としている
実証実験をしている	実験していることと、導入が決まったことは別
ブロックチェーンで作る	日本銀行の議論では、集中管理型・分担管理型など複数の設計が検討されている
現金がなくなる	CBDCは現金や既存決済との共存も重要な論点として扱われている

特にQiita記事として書く場合、「導入される」ではなく「検討されている」「実証実験が行われている」 と表現する方が正確です。

9.4 BIS：多くの中央銀行がCBDCを検討している

CBDCの世界的な傾向を見るときに参考になるのが、BIS（Bank for International Settlements、国際決済銀行）の調査です。

BISの2024年調査では、調査対象となった93の中央銀行のうち、91%にあたる85の中央銀行が、リテールCBDC、ホールセールCBDC、またはその両方を検討しているとされています。
また、全体としてはホールセールCBDCの検討の方が、リテールCBDCより進んだ段階にあるとも整理されています。

参考: BIS “Advancing in tandem - results of the 2024 BIS survey on central bank digital currencies and crypto”

ここで大事なのは、「多くの中央銀行が検討している」ことと、「多くの国で実際に一般利用が始まっている」ことは違う、という点です。

CBDCには、少なくとも次のような段階があります。

段階	内容のイメージ
調査	CBDCが必要か、どのような影響があるかを調べる
概念実証	小さな範囲で技術的に実現できるかを試す
パイロット	実際の利用に近い環境で運用・制度面も含めて検証する
導入	一般利用者や金融機関が実際に使える状態にする
改善・普及	利用状況を見ながら制度・UI・加盟店・連携先を広げる

CBDCは社会インフラに近い仕組みなので、実験で動いたからといって、すぐに全国導入できるわけではありません。
技術だけでなく、法律、金融機関との役割分担、利用者保護、プライバシー、災害時対応、コスト負担などを合わせて考える必要があります。

9.5 ユーロ圏：デジタルユーロの準備が進む

ユーロ圏では、ECB（欧州中央銀行）が digital euro（デジタルユーロ） の準備を進めています。

ECBは2025年10月、デジタルユーロプロジェクトを次の段階に進めることを決定したと説明しています。
この段階では、発行判断の前に必要な技術的能力を構築し、法制度の進展と整合する形で準備を進めるとされています。

参考: ECB “Preparation phase of a digital euro - Closing report”

ECBは、必要なEU法制が2026年中に採択されるという作業上の前提のもと、2029年中の潜在的な初回発行に備えることを目指しています。
また、準備のためのパイロットや初期取引が、早ければ2027年半ばから始まる可能性にも触れています。

参考: ECB “Digital euro”

ここでも注意したいのは、「2029年に必ず発行される」と断定しないことです。
ECBの説明は、法制度の成立などを前提とした「潜在的な発行に備える」という表現になっています。

9.6 デジタルユーロの見方

デジタルユーロは、単に「ユーロをスマホで使えるようにする」だけではありません。

ユーロ圏には多くの国があり、決済サービス、銀行、利用者、加盟店、法制度も複雑に関係します。
そのため、デジタルユーロでは、オンライン・オフライン利用、仲介機関の役割、保有上限、プライバシー、既存決済との共存などが重要な論点になります。

前章までに見てきた設計論点が、実際の地域プロジェクトではどのように扱われるのかを見るうえで、デジタルユーロは参考になる事例です。

9.7 米国：CBDCをめぐる政策判断が大きい

米国では、FRB（Federal Reserve、連邦準備制度理事会）がCBDCに関する情報ページを公開しています。

FRBは、CBDCを一般に「広く一般に利用可能な中央銀行のデジタル負債」と説明し、FRBの負債として発行されるCBDCであれば、一般利用者にとって信用リスクや流動性リスクを伴わない安全なデジタル資産になり得ると説明しています。

参考: Federal Reserve “Central Bank Digital Currency (CBDC)”

一方で、米国では政策上の制約も強く示されています。
2025年1月の大統領令では、法律で求められる場合を除き、連邦機関が米国内外でCBDCを設立・発行・促進する行為を禁止する内容が示されました。

参考: The White House “Strengthening American Leadership in Digital Financial Technology”

米国の例から分かるのは、CBDCは技術的に可能かどうかだけで決まるものではない、ということです。

CBDCは中央銀行マネーをデジタル化する仕組みなので、プライバシー、政府の関与、民間決済との競合、ステーブルコイン政策、金融機関への影響など、政治・制度面の判断が非常に大きくなります。

9.8 導入済みの例：バハマ、ナイジェリア、ジャマイカ

CBDCは、多くの国ではまだ検討・実証段階ですが、すでに導入済みの例もあります。
ここでは、代表的な例としてバハマ、ナイジェリア、ジャマイカを見ます。

9.9 バハマ：Sand Dollar

バハマの Sand Dollar は、バハマ・ドルのデジタル版として説明されています。
公式サイトでは、Sand Dollarは現金と同じく、バハマ中央銀行によって発行され、認可金融機関を通じて提供されるとされています。

参考: Sand Dollar “Digital Bahamian Dollar”

バハマのような島しょ国では、島ごとに銀行支店やATMを整備するコスト、現金輸送、災害時の決済アクセスなどが課題になりやすいと考えられます。
そのため、CBDCは単に「新しい技術を使う」というより、金融サービスへのアクセス改善や決済インフラの近代化と結びつきやすいテーマです。

9.10 ナイジェリア：eNaira

ナイジェリア中央銀行は、eNaira を法定通貨として発行されるCBDCと説明しています。
公式ページでは、eNairaはナイラのデジタル形態であり、現金のように使われるものとされています。

参考: Central Bank of Nigeria “eNaira”

eNairaは、金融包摂、送金、決済効率化などの文脈で語られることが多いCBDCです。
一方で、導入済みだからといって自然に広く使われるとは限りません。利用者にとって既存の決済手段より明確なメリットがあるか、加盟店が受け入れるか、ウォレットを使いやすいか、といった普及面の課題も重要になります。

9.11 ジャマイカ：JAM-DEX

ジャマイカの JAM-DEX は、Bank of Jamaicaが発行するCBDCです。
Bank of JamaicaのFAQでは、CBDCはBOJがデジタル形式で発行するお金であり、銀行口座ではなく、銀行や認可決済サービス提供者が発行するCBDCウォレットに保有されると説明されています。

参考: Bank of Jamaica “CBDC FAQs”

また、同FAQでは、CBDCは暗号資産ではなく、国の通貨のデジタル版であり、法定通貨として中央銀行が発行・規制するものだと説明されています。
これは、本記事で繰り返し整理してきた 「CBDCと暗号資産は同じではない」 という点を理解するうえで分かりやすい説明です。

9.12 導入済みだから成功、未導入だから遅れている、ではない

ここまで見ると、国や地域ごとに状況がかなり違うことが分かります。

ただし、CBDCについては、単純に「導入済みの国が進んでいる」「導入していない国が遅れている」とは言い切れません。

CBDCを導入するかどうかは、その国の状況によって意味が変わります。

観点	CBDCが強く検討されやすい背景の例
現金アクセス	現金の流通・輸送・管理コストが高い
金融包摂	銀行口座を持たない人にも決済手段を届けたい
決済効率	送金や小口決済をより速く安くしたい
国際決済	クロスボーダー決済の遅さやコストを改善したい
民間デジタルマネー	ステーブルコインなど民間マネーとの関係を整理したい
金融安定	中央銀行マネーをデジタル社会でも信頼のアンカーにしたい

逆に、既存の決済インフラが十分に便利で、現金や銀行預金、スマホ決済が広く使われている国では、CBDCを導入するメリットとコストを慎重に比較する必要があります。

たとえば、日本ではキャッシュレス決済が普及しつつある一方で、現金の信頼性も高く、銀行預金や民間決済サービスも広く利用されています。
そのため、CBDCを考えるときには「技術的に作れるか」だけでなく、「利用者にとって何が改善されるのか」「既存の決済とどう共存するのか」を丁寧に検討する必要があります。

9.13 調査メモを整理するための簡単なコード例

CBDCの動向を調べると、国・地域ごとに「調査中」「実証中」「準備中」「導入済み」など、表現がばらばらになりがちです。

そこで、記事作成や調査メモでは、次のように状態をそろえて管理すると見通しがよくなります。

# CBDCの検討状況を整理するための簡単なデータ例です。
# 実際の記事作成では、必ず各中央銀行・公的機関の一次情報で確認します。

projects = [
    {
        "area": "日本",
        "project": "日本銀行のCBDC実証実験",
        "status": "pilot_research",
        "note": "導入は未決定。実証実験・CBDCフォーラム・関係府省庁との議論を継続。",
    },
    {
        "area": "ユーロ圏",
        "project": "digital euro",
        "status": "preparation",
        "note": "潜在的な発行に備えて技術・制度面の準備を継続。",
    },
    {
        "area": "米国",
        "project": "U.S. CBDC",
        "status": "policy_restricted",
        "note": "FRBは情報を公表しているが、政策上の制約が大きい。",
    },
    {
        "area": "バハマ",
        "project": "Sand Dollar",
        "status": "launched",
        "note": "バハマ・ドルのデジタル版として全国展開。",
    },
    {
        "area": "ナイジェリア",
        "project": "eNaira",
        "status": "launched",
        "note": "中央銀行が発行するナイラのデジタル版。",
    },
    {
        "area": "ジャマイカ",
        "project": "JAM-DEX",
        "status": "launched",
        "note": "Bank of Jamaicaが発行するCBDC。",
    },
]


def label_status(status: str) -> str:
    """内部用の状態名を、記事で読みやすい表現に変換する。"""
    labels = {
        "research": "調査段階",
        "pilot_research": "実証・検討段階",
        "preparation": "準備段階",
        "policy_restricted": "政策上の制約あり",
        "launched": "導入済み",
    }

    # 未知の状態が来た場合でも、記事作成時に見落とさないようにする
    return labels.get(status, "要確認")


for item in projects:
    # 国・地域、プロジェクト名、整理した状態、補足メモを表示する
    print(f"{item['area']} / {item['project']} : {label_status(item['status'])} - {item['note']}")

このコードは、CBDCの仕組みそのものを実装しているわけではありません。
あくまで、調査結果を整理するときに 「導入済み」「実証中」「未決定」などの状態を混同しないためのメモ管理例 です。

CBDCのように制度・技術・政策が絡むテーマでは、こうした小さな整理でも、記事の誤表現を減らす助けになります。

9.14 この章のまとめ

この章では、日本銀行と海外のCBDC検討状況を整理しました。

ポイントは、次のとおりです。

日本では、CBDCの導入は決定しておらず、日本銀行の実証実験、CBDCフォーラム、関係府省庁・日本銀行連絡会議などを通じて検討が進められている
BISの2024年調査では、多くの中央銀行がリテールCBDC、ホールセールCBDC、またはその両方を検討している
ユーロ圏では、デジタルユーロの潜在的な発行に備えた準備が進められているが、法制度や最終判断が前提になる
米国では、FRBがCBDCの基本説明を公表している一方、2025年の大統領令により連邦機関によるCBDC推進が禁止される方向が示されている
バハマ、ナイジェリア、ジャマイカなど、CBDCを導入済みの例もある
ただし、導入済みだから成功、未導入だから遅れている、とは単純に言えない
CBDCの必要性は、各国の決済インフラ、現金利用、金融包摂、プライバシー観、制度設計によって変わる

CBDCは世界的に検討されているテーマですが、その中身は国や地域によって大きく異なります。
だからこそ、ニュースやSNSで見かける短い表現だけで判断するのではなく、一次情報を確認しながら、「何が決まっていて、何がまだ検討中なのか」を分けて読むことが大切です。

次の章では、ここまでの内容を踏まえて、CBDCに関して特に誤解されやすい点を整理します。

10. よくある誤解

この章では、CBDCに関してよくある誤解を整理します。
ポイントは、CBDCをブロックチェーン、暗号資産、ステーブルコイン、現金廃止といった言葉と単純に結びつけないことです。

ここまで、CBDCの基本的な考え方、既存のお金との違い、ブロックチェーンとの関係、設計論点、セキュリティ、国内外の検討状況を見てきました。

ただ、CBDCは「中央銀行」「デジタル通貨」「ブロックチェーン」「ステーブルコイン」「監視社会」のような強い言葉と一緒に語られやすいため、短いニュースやSNSの見出しだけを見ると、少し誤解しやすいテーマでもあります。

この章では、CBDCに関してよくある誤解を整理します。

最初に結論をまとめると、次のようになります。

よくある誤解	本記事での整理
CBDCはブロックチェーンで作るもの	ブロックチェーンやDLTは実装候補の一つであり、CBDCに必須ではない
CBDCは暗号資産と同じ	中央銀行が発行する法定通貨建ての中央銀行マネーであり、暗号資産とは性質が異なる
CBDCはステーブルコインと同じ	ステーブルコインは民間発行が中心で、CBDCとは発行主体と信用の置き場所が異なる
CBDCが出ると現金が必ずなくなる	少なくとも日本銀行は、現金需要がある限り現金供給を続ける方針を示している
日本ではCBDC導入が決定済み	日本銀行は検討を進めているが、導入判断は今後の国民的な議論の中で決まると説明している
CBDCはすべての取引を中央銀行が直接見る仕組み	取引情報を誰がどこまで扱うかは、制度設計・システム設計・仲介機関の役割によって変わる
デジタルなので完全に安全	ウォレット、認証、端末、API、台帳、運用など、多くのセキュリティ論点がある

💡 豆知識
「デジタル円」という言い方は入口として分かりやすい一方で、CBDCの制度設計を説明するには少し短すぎます。
CBDCを読むときは、「円建てなのか」「誰の債務なのか」「誰が記録を持つのか」「どのような本人確認や不正対策があるのか」まで分けて見ると理解しやすくなります。

10.1 誤解1：CBDCはブロックチェーンで作るもの

CBDCという言葉を聞くと、ブロックチェーンや暗号資産を連想する人も多いと思います。

しかし、ここはかなり重要なポイントです。

CBDCは、必ずしもブロックチェーンで作られるものではありません。

日本銀行はCBDCについて、一般に次の3つを満たすものと説明しています。

デジタル化されていること
円などの法定通貨建てであること
中央銀行の債務として発行されること

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

ここに「ブロックチェーンであること」は含まれていません。

少し身近な例で考えると、家計簿を紙でつけても、Excelでつけても、スマホアプリでつけても、「家計の記録」であることは変わりません。違うのは、記録の管理方法です。

CBDCも同じように、

何を発行するのか
誰の責任で発行するのか
誰が使えるのか
どのように決済するのか

という制度・決済インフラの話が中心です。

一方で、ブロックチェーンやDLTは、

台帳をどのように管理するか
複数の参加者でどう整合性を保つか
改ざんをどう検知するか
条件付きの処理をどう自動化するか

といった、記録を扱うための技術候補として登場します。

日本銀行のCBDCフォーラム総括資料でも、CBDCの台帳システムについて、NoSQL/NewSQLなどの分散データベース技術やブロックチェーン技術の活用可能性が議論されています。つまり、ブロックチェーンは選択肢の一つとして検討されるものであり、CBDCの定義そのものではありません。

10.2 誤解2：CBDCは暗号資産と同じ

CBDCは「デジタル通貨」と呼ばれるため、ビットコインなどの暗号資産と同じようなものだと思われることがあります。

ただし、CBDCと暗号資産は、かなり性質が異なります。

観点	CBDC	暗号資産の例
発行主体	中央銀行	プロトコルやネットワークによるものなど、設計によって異なる
通貨単位	円、ユーロ、ドルなどの法定通貨建て	BTC、ETHなど独自単位の場合が多い
価値の安定性	法定通貨としての安定性を前提に設計される	市場価格が大きく変動し得る
主な目的	支払決済インフラ、中央銀行マネーのデジタル化	価値移転、ネットワーク利用、投資対象など多様
信用の置き場所	中央銀行	ネットワーク、プロトコル、市場参加者など

たとえば、ビットコインは特定の中央銀行が発行するものではありません。価格も市場で変動します。

一方、CBDCは「円建てのCBDC」であれば、基本的には1円は1円として扱われることを前提に考えます。ここが、価格変動のある暗号資産との大きな違いです。

もちろん、どちらもデジタル技術を使う点では共通しています。ですが、発行主体・価値の安定性・制度上の位置づけが違うため、同じものとして扱うと混乱します。

10.3 誤解3：CBDCはステーブルコインと同じ

暗号資産との違いに続いて、ステーブルコインとの違いもよく混同されます。

ステーブルコインは、一般に法定通貨などの価値と連動するように設計されたデジタル資産です。金融庁の資料でも、法定通貨の価値と連動するいわゆるステーブルコインについて説明されています。

参考: 金融庁「電子決済手段・暗号資産サービス仲介業を行うみなさまへ」

CBDCとステーブルコインは、どちらも「円やドルなどに近い価値を持つデジタルなお金」と見えることがあります。

しかし、重要なのは 誰が発行しているか です。

観点	CBDC	ステーブルコイン
主な発行主体	中央銀行	民間事業者など
信用の置き場所	中央銀行	発行者、裏付け資産、規制、監査など
法定通貨建てか	法定通貨建て	法定通貨などに連動する設計が多い
中央銀行マネーか	はい	通常はいいえ
主な論点	公的決済インフラ、金融安定、プライバシー、制度設計	裏付け資産、償還可能性、発行者リスク、規制対応

たとえるなら、CBDCは「中央銀行が直接発行するデジタルなお金」です。ステーブルコインは「民間の仕組みによって、円やドルなどに価値を近づけるデジタルな資産」と整理できます。

見た目はどちらもデジタルな残高に見えるかもしれません。ですが、中身の信用構造は異なります。

10.4 誤解4：CBDCが出ると現金が必ずなくなる

CBDCが話題になると、

将来は現金が全部なくなるのでは？

と不安に感じる人もいるかもしれません。

ただし、少なくとも日本銀行は、現金需要がある限り現金供給を続ける方針を示しています。日本銀行の「中央銀行デジタル通貨に関する日本銀行の取り組み方針」では、現金に対する需要がある限り、日本銀行は現金の供給についても責任を持って続けていくと説明されています。

参考: 日本銀行「中央銀行デジタル通貨に関する日本銀行の取り組み方針」

また、BISと複数の中央銀行による報告書でも、CBDCは現金や他の種類のお金と共存し、補完することが基本原則の一つとして整理されています。

参考: BIS “Central bank digital currencies: foundational principles and core features”

現金には、現金ならではの強みがあります。

スマホや電池がなくても使える
通信環境に依存しにくい
小額の対面決済で使いやすい
デジタル機器に不慣れな人でも扱いやすい

もちろん、現金管理にはコストもあります。偽造対策、輸送、保管、ATM運用など、現金ならではの負担もあります。

そのため、CBDCの議論では「現金をすぐに置き換える」というより、現金・銀行預金・民間デジタルマネーとどう共存させるか が重要な論点になります。

10.5 誤解5：日本ではCBDC導入がすでに決まっている

日本銀行はCBDCの実証実験やCBDCフォーラムを進めています。

ただし、これは「日本でCBDCを導入することが決定した」という意味ではありません。

日本銀行は、わが国でCBDCを導入するかどうかは、内外の情勢も踏まえ、今後の国民的な議論の中で決まっていくものと説明しています。

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

ここは、記事を書くときにも特に注意したい部分です。

たとえば、次のような表現は避けた方が安全です。

日本でもCBDCが導入される予定です。

より正確には、次のように書くのがよいです。

日本ではCBDCの導入は決定していませんが、日本銀行は実証実験やCBDCフォーラムを通じて検討を進めています。

CBDCは技術だけでなく、法律、金融システム、利用者保護、プライバシー、民間決済事業者との関係など、多くの論点を含むテーマです。だからこそ、検討していることと導入が決まっていることは分けて書く必要があります。

10.6 誤解6：CBDCは中央銀行がすべての取引を直接見る仕組み

CBDCについて、プライバシーの観点から不安を持つ人もいます。

CBDCになると、すべての支払いを中央銀行が直接見るのでは？

という疑問です。

この点については、単純に「必ずそうなる」とも「絶対にそうならない」とも言い切れません。

なぜなら、取引情報を誰がどこまで扱うかは、CBDCの制度設計やシステム設計によって変わるからです。

たとえば、次のような設計上の選択肢があります。

設計論点	考え方の例
仲介機関を置くか	民間銀行や決済事業者が利用者対応を担う設計にするか
本人確認をどうするか	少額利用と高額利用で確認水準を変えるか
取引情報を誰が持つか	中央銀行、仲介機関、利用者端末などの役割をどう分けるか
不正対策をどう行うか	AML/CFTや不正検知をどの主体が担うか
プライバシーをどう守るか	利便性、不正対策、利用者保護とのバランスをどう取るか

日本銀行のCBDCフォーラム総括資料でも、KYC、AML/CFT、認証・認可、プライバシー、仲介機関の役割などが論点として整理されています。

ここで大事なのは、CBDCは「便利な決済手段」だけを目指せばよいわけではないという点です。

犯罪収益の移転を防ぐ必要がある
利用者のプライバシーも守る必要がある
システム障害や災害時にも使える設計が求められる
誰がどの情報にアクセスできるかを明確にする必要がある

このように、CBDCでは プライバシーと不正対策のバランス が非常に重要になります。

10.7 誤解7：デジタルなので完全に安全

「中央銀行が発行するデジタル通貨」と聞くと、とても安全な仕組みに見えるかもしれません。

もちろん、CBDCは高い安全性が求められる仕組みです。しかし、デジタルである以上、考えなければならないリスクは多くあります。

守る対象	例
ウォレット	端末紛失、マルウェア、フィッシング、なりすまし
認証情報	パスワード、秘密鍵、生体認証、端末認証
API	過剰権限、不正アクセス、リプレイ攻撃、認可ミス
台帳	改ざん、不整合、二重支払い、障害時復旧
監査ログ	ログ改ざん、証跡不足、責任分界の不明確さ
オフライン決済	二重支払い、端末改ざん、後続同期時の不整合

第8章で見たように、CBDCは「台帳だけ守ればよい」システムではありません。利用者のスマホ、ウォレットアプリ、仲介機関のシステム、API、監査ログ、運用体制まで含めて考える必要があります。

ブロックチェーンを使った場合でも同じです。

ブロックチェーンは、取引履歴の改ざん検知や複数主体での記録共有に役立つ可能性があります。しかし、ウォレットの秘密情報が盗まれたり、APIの認可設計が甘かったり、運用上の権限管理が不十分だったりすれば、システム全体としては安全とは言えません。

つまり、

ブロックチェーンを使う = すべて安全

ではありません。

より正確には、次のように考える必要があります。

ブロックチェーンやDLTは、CBDCの一部の課題に役立つ可能性がある。
ただし、CBDC全体の安全性は、ウォレット、認証、認可、API、台帳、監査、運用を含む総合設計で決まる。

10.8 小さなコード例：CBDCに関する説明をチェックしてみる

最後に、ここまでの誤解を整理するために、CBDCに関する短い説明文を簡単にチェックするコードを書いてみます。

もちろん、これは本格的なファクトチェックシステムではありません。記事を書くときに、危ない断定表現を見つけるための簡単なメモ用ツール くらいのイメージです。

# CBDCに関する説明文に、誤解を招きやすい表現が含まれていないかを確認する簡易ツール
# 本格的な自然言語処理ではなく、キーワードに基づくルールベースのチェックです。

statements = [
    "CBDCはブロックチェーンで作られる日本円です。",
    "CBDCは中央銀行が発行するデジタルな中央銀行マネーです。",
    "CBDCが導入されると現金は必ず廃止されます。",
    "日本ではCBDCの導入は決定していないが、検討が進められています。",
    "ブロックチェーンを使えばCBDCは完全に安全になります。",
]

# 誤解を招きやすい表現と、その理由を定義します。
# 実際の記事執筆では、こうした表現を見つけたら一次情報で確認します。
risky_patterns = {
    "ブロックチェーンで作られる": "CBDCにブロックチェーンは必須ではありません。実装候補の一つです。",
    "現金は必ず廃止": "CBDCと現金の共存が議論されており、必ず廃止とは言えません。",
    "完全に安全": "デジタル通貨にはウォレット、認証、API、運用などのセキュリティ論点があります。",
    "導入される予定": "日本ではCBDCの導入は決定していません。検討段階として表現する必要があります。",
}

for statement in statements:
    warnings = []

    # 各説明文に、誤解を招きやすいキーワードが含まれているか確認します。
    for pattern, message in risky_patterns.items():
        if pattern in statement:
            warnings.append(message)

    print("説明文:", statement)

    if warnings:
        print("注意:")
        for warning in warnings:
            print(" -", warning)
    else:
        print("判定: 大きな危険表現は見つかりませんでした。")

    print("---")

実行すると、たとえば次のような出力になります。

説明文: CBDCはブロックチェーンで作られる日本円です。
注意:
 - CBDCにブロックチェーンは必須ではありません。実装候補の一つです。
---
説明文: CBDCは中央銀行が発行するデジタルな中央銀行マネーです。
判定: 大きな危険表現は見つかりませんでした。
---
説明文: CBDCが導入されると現金は必ず廃止されます。
注意:
 - CBDCと現金の共存が議論されており、必ず廃止とは言えません。
---
説明文: 日本ではCBDCの導入は決定していないが、検討が進められています。
判定: 大きな危険表現は見つかりませんでした。
---
説明文: ブロックチェーンを使えばCBDCは完全に安全になります。
注意:
 - デジタル通貨にはウォレット、認証、API、運用などのセキュリティ論点があります。
---

このコードで重要なのは、正誤判定そのものではありません。

大切なのは、記事を書くときに、

「必ず」
「完全に」
「もう決まっている」
「同じ」
「ブロックチェーンで作るもの」

のような強い表現を見つけたら、一度立ち止まって一次情報を確認することです。

CBDCは制度・技術・金融・プライバシーが重なるテーマなので、少しの表現の違いで印象が大きく変わります。Qiita記事として公開する場合も、断定しすぎず、根拠を示しながら書くことが大切です。

10.9 この章のまとめ

この章では、CBDCに関してよくある誤解を整理しました。

ポイントは、次のとおりです。

CBDCはブロックチェーンそのものではなく、中央銀行が発行するデジタルな中央銀行マネーである
ブロックチェーンやDLTは、CBDCを実現するための技術候補の一つであり、必須条件ではない
CBDCは暗号資産やステーブルコインと同じものではなく、発行主体と信用の置き場所が異なる
CBDCが出ると現金が必ずなくなる、とは言えない
日本ではCBDC導入は決定しておらず、実証実験や議論を通じて検討が進められている
取引情報を誰がどこまで扱うかは、制度設計やシステム設計によって変わる
デジタル化すれば完全に安全になるわけではなく、ウォレット、認証、API、台帳、監査、運用を含む総合的なセキュリティ設計が必要になる

ここまでで、CBDCそのものの基本的な整理はかなり進みました。

次の章では、記事全体を振り返りながら、CBDCをブロックチェーン全体の学習の中でどのように位置づけられるかをまとめます。

11. まとめ

この章では、記事全体を振り返り、CBDCとブロックチェーンの関係を整理し直します。
ポイントは、CBDCを「ブロックチェーン上の通貨」としてではなく、中央銀行マネーをデジタル社会でどう扱うかというテーマとして見ることです。

ここまで、CBDCとブロックチェーンの関係を、現金・銀行預金・スマホ決済・電子マネー・ステーブルコインなどの身近なお金の記録から整理してきました。

CBDCは、単なる新しいスマホ決済アプリではありません。
また、「ブロックチェーン上で動く日本円」のように、ブロックチェーンと一体のものとして決まっているわけでもありません。

日本銀行は、CBDCを一般に次の3つを満たすものとして説明しています。

デジタル化されていること
円などの法定通貨建てであること
中央銀行の債務として発行されること

参考: 日本銀行「中央銀行デジタル通貨とは何ですか？」

少しやわらかく言い換えると、CBDCは 中央銀行が発行するお金を、デジタル社会の中でも安全に使えるようにする構想 と考えると分かりやすいです。

11.1 本記事で整理したこと

本記事で整理した大きなポイントは、次の3つです。

ポイント	内容	具体例
CBDCは中央銀行マネーである	発行主体は中央銀行であり、単なる民間サービスの残高ではない	現金は中央銀行マネー、銀行預金や多くのスマホ決済残高は民間マネー
CBDCはブロックチェーンそのものではない	ブロックチェーンやDLTは、CBDCを実装する場合の技術候補の一つ	集中管理型台帳、分担管理型台帳、パーミッションドDLTなど複数の選択肢がある
CBDCは技術だけでは決まらない	利便性、プライバシー、AML/CFT、オフライン決済、金融安定、セキュリティなどを総合的に設計する必要がある	高額送金時の追加認証、取引モニタリング、災害時のオフライン利用など

CBDCを理解するときは、まず 「デジタルかどうか」だけで見ないこと が大切です。

銀行預金もスマホ決済も、すでにかなりデジタルです。
しかし、それらがすべてCBDCになるわけではありません。

重要なのは、次のような問いです。

そのお金は、誰が発行しているのか
その残高は、誰の台帳に記録されているのか
その記録を、誰が検証できるのか
不正利用や改ざんが起きたとき、誰がどのように対応するのか
利便性とプライバシーを、どのように両立するのか

このように見ると、CBDCは単なる「デジタルなお金」ではなく、お金の記録と信頼をどう設計するか というテーマだと分かります。

11.2 CBDCを学ぶときに意識したいこと

CBDCを学ぶときは、最初から各国の制度比較や専門的な金融政策論に入ると、少し迷いやすくなります。

そのため、まずは次の順番で理解すると進めやすいです。

現金、銀行預金、スマホ決済など、身近なお金の記録を考える
CBDCを「中央銀行マネーのデジタル化」として整理する
現金・銀行預金・電子マネー・ステーブルコインとの違いを見る
リテールCBDCとホールセールCBDCの違いを理解する
CBDCとブロックチェーン/DLTを同じものとして扱わない
DLTが検討される場面を、台帳共有や原子的決済の観点から見る
プライバシー、AML/CFT、オフライン決済、金融安定を設計論点として確認する
ウォレット、認証、API、監査ログなど、情報セキュリティの観点から見る
日本銀行や海外中央銀行の動向は、必ず一次情報で確認する

特に大切なのは、制度としてのCBDC と 技術候補としてのブロックチェーン/DLT を分けて考えることです。

CBDCは、中央銀行が発行するデジタルな中央銀行マネーに関する構想です。
一方、ブロックチェーンやDLTは、その記録や決済を支えるための技術候補の一つです。

この2つを分けて見ると、「CBDCは必ずブロックチェーンで作られる」「ブロックチェーンを使えばCBDCは安全になる」といった誤解を避けやすくなります。

11.3 CBDCは便利そうだが、魔法ではない

CBDCは、ぱっと見ると「現金がスマホで使えるようになったら便利そう」という話に見えるかもしれません。

もちろん、うまく設計されれば、決済の効率化、金融包摂、オフライン利用、国境を越える決済の改善などにつながる可能性があります。

一方で、CBDCはお金の土台に近い仕組みです。
そのため、便利さだけでなく、次のような論点を同時に考える必要があります。

論点	なぜ重要か
プライバシー	利用者の取引情報を誰がどこまで見られるのかが信頼に関わるため
AML/CFT	マネー・ローンダリングやテロ資金供与を防ぐ必要があるため
オフライン決済	災害時や通信障害時にも使える可能性を考えるため
金融安定	銀行預金からCBDCへ急激に資金が移ると、金融システムに影響する可能性があるため
サイバーセキュリティ	ウォレット、API、認証、台帳、監査ログなど守る場所が多いため
相互運用性	既存の銀行システムや民間決済サービスとつながる必要があるため

日本銀行も、CBDCを導入するかどうかは決まっておらず、実証実験やCBDCフォーラムなどを通じて、技術面・制度面の検討を進めている段階です。

参考: 日本銀行「中央銀行デジタル通貨」

また、BISの2024年調査では、多くの中央銀行がCBDCを検討している一方で、検討の段階や目的は国・地域によって異なるとされています。

参考: BIS “Results of the 2024 BIS survey on central bank digital currencies and crypto”

この点からも、CBDCは「世界で流行っているから導入する」というものではなく、それぞれの国の決済環境、金融システム、法制度、利用者ニーズに合わせて慎重に考える必要があるテーマだと分かります。

11.4 今後深掘りしたいテーマ

この記事では、CBDCとブロックチェーン/DLTの関係を中心に整理しました。
ここからさらに理解を広げるなら、次のようなテーマを順番に深掘りするとつながりが見えやすくなります。

テーマ	CBDC記事とのつながり
ステーブルコイン	CBDCと混同されやすい民間発行のデジタルマネーを整理できる
RWAトークン化	ホールセールCBDC、トークン化資産、DVP、原子的決済との接点を理解しやすくなる
Layer 2とRollup	パブリックブロックチェーンの性能・拡張性・データ可用性の課題を理解できる
暗号技術の全体像	ハッシュ、デジタル署名、認証、鍵管理など、CBDCのセキュリティを支える基礎を整理できる
暗号資産AML・取引解析	CBDCやステーブルコインに関係する不正利用対策、KYC、AML/CFTの理解につながる

CBDCは、単独で理解するよりも、現金・銀行預金・ステーブルコイン・トークン化資産・ブロックチェーン基盤・暗号技術と並べて見ると整理しやすくなります。

特に、本記事の出発点である 「身近な記録から理解するブロックチェーンの全体像」 では、記録、台帳、改ざん検知、分散、セキュリティ上の強みと限界を広く整理しています。
CBDCを「お金の記録設計」として見るための土台になるため、投稿時には本文中の関連記事リンクから自然に戻れるようにしておくと読みやすくなります。

11.5 最後に

CBDCは、単なる新しい決済アプリではありません。
また、ブロックチェーンを使えば自動的に完成するものでもありません。

CBDCを考えることは、次のような問いを一つずつ整理することでもあります。

お金の記録を、誰が持つのか
その記録を、誰が検証するのか
利用者は、どの範囲までプライバシーを守れるのか
不正利用を、どのように防ぐのか
現金、銀行預金、民間決済サービスと、どう共存するのか
ブロックチェーンやDLTを使うなら、どの部分に使うのが適切なのか

そのため、CBDCとブロックチェーンの関係は、次のように整理できます。

CBDCは、中央銀行マネーをデジタル社会でどう扱うかという構想である。
ブロックチェーンやDLTは、その記録や決済を支えるための技術候補の一つである。

この記事が、CBDCを「なんとなく難しい言葉」ではなく、身近なお金の記録から考えられるテーマとして捉えるきっかけになれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up