中央銀行デジタル通貨（CBDC）：デジタルマネーを支えるインフラストラクチャの実践ガイド

中央銀行デジタル通貨（CBDC）は、しばしば「スマートフォンで使える現金」のように語られることがありますが、実際のところ、技術的な側面はより複雑です。実用的なCBDCには、発行・決済レイヤー、アクセス権限に関するルール、銀行や決済プロバイダーとのインターフェース、ユーザーウォレットやその他の決済手段、プライバシー管理、不正対策、運用上の安定性、そして設計によってはオフライン機能も必要となります。したがって、CBDCは単一のアプリや台帳としてではなく、決済エコシステムとして理解する方が適切です。

CBDCに関する取り組みは依然として広く行われている。国際決済銀行（BIS）が2024年を対象に実施し、2025年8月に発表した調査によると、調査対象となった93の中央銀行のうち85行（91%）が、リテールCBDC、ホールセールCBDC、またはその両方を検討していると回答した。ホールセールCBDCの取り組みは概してより進んでいる。BISの2024年CBDC調査結果を参照のこと。

CBDCの基礎知識：実際にデジタル化されるのは何か？

CBDCとは、中央銀行が発行する通貨をデジタル形式で表現したものです。最も重要な違いは、ブロックチェーン技術を使用しているかどうかではなく、その通貨が誰のためのものであり、請求、記録、アクセスがどのように管理されているかという点です。

実用的な教訓は単純明快だ。「デジタル」は必ずしも「ブロックチェーン」を意味するものではない。国際決済銀行（BIS）は以前から、中央銀行デジタル通貨（CBDC）のインフラストラクチャには、従来型の中央集権型データベースまたは分散型台帳技術（DLT）のどちらでも使用できると指摘してきた。適切な選択は、特定の流行語への好みではなく、政策目標、運用モデル、耐障害性要件、処理能力、ガバナンスによって決まる。

CBDCインフラストラクチャスタック

1. 発行、償還、およびコア台帳

中核システムは、CBDCの発行量、CBDCを移動させる権限を持つ者または主体、そして送金が確定する時期を明確に示す必要がある。民間仲介機関が顧客対応サービスを担う場合でも、中央銀行は発行と償還の責任を負う。

BIS（国際決済銀行）のイノベーション・デジタル経済諮問グループによる有用な参照モデルでは、利用者の登録、CBDCの「入金」による生成、CBDCの「出金」による消滅、台帳内での価値移転という4つの主要な小売プロセスが説明されています。このモデルで提案されているアーキテクチャは、中央銀行と民間仲介機関の間で責任を分担するハイブリッドモデルを採用しています。BISの小売CBDCアーキテクチャ提案を参照してください。

台帳の設計においては、取引順序、二重支払いの防止、決済の確定性、障害発生後の復旧、照合、監査可能性といった運用上の疑問に答える必要があります。これらの要件は、実装に従来型のデータベース、許可型分散型台帳技術（DLT）、あるいはその他のアーキテクチャのいずれを使用する場合でも重要です。

2. 仲介業者と二層構造モデル

多くの小売向けCBDC設計では、中央銀行が何百万ものユーザーにとって日常的なサービス窓口となることは想定されていません。その代わりに、銀行や決済サービスプロバイダーが顧客のオンボーディング、ウォレットの配布、不正監視、口座復旧、および最前線のサポートを行い、中央銀行は金融の中核を運営または管理します。

この二層構造は、民間部門の競争の余地を残しつつ、基となる通貨を中央銀行の負債として維持する。また、中央銀行が顧客情報を全て収集する必要性を軽減する。しかしながら、インターフェースとガバナンスに関する作業が発生する。仲介業者は、本人確認、制裁対象者スクリーニング、取引メッセージ、エラー処理、紛争解決プロセス、サービス提供状況に関して、一貫したルールを策定する必要がある。

3. 本人確認、アクセス管理、およびコンプライアンスサービス

CBDC（中央銀行デジタル通貨）のインフラストラクチャは、個人または機関がウォレットやアカウントを開設、資金投入、使用、回収、または閉鎖する権利をどのように証明するかを定める必要があります。小売システムでは、これは通常、顧客確認（KYC）、マネーロンダリング対策（AML）、制裁、詐欺、および消費者保護の要件と関連しています。

アイデンティティとは、中央銀行がすべてのユーザーの現実世界の身元を把握することを意味するものではありません。アーキテクチャによっては、決済プロバイダーが保有するアイデンティティデータと、決済システムで使用される取引識別子を分離することができます。具体的なプライバシーモデルは、暗号化の問題であると同時に、政策や法律上の問題でもあります。

4. APIとサービスレイヤー

アプリケーションプログラミングインターフェース（API）は、金融の中核とユーザーが実際に利用するサービスをつなぐ役割を果たします。適切に設計されたAPIレイヤーがあれば、複数の銀行、ウォレット、加盟店、フィンテックプロバイダーが、それぞれ中央銀行の台帳に個別に統合することなく接続できます。

BISイノベーションハブのプロジェクト・ロザリンドは、2層構造の小売向けCBDCモデルを用いてこのアイデアを検証しました。プロトタイプは6つの機能カテゴリにわたる33のAPIエンドポイントを公開し、30以上のユースケースをテストしました。このプロジェクトは、APIレイヤーは基盤となる台帳設計の違いを抽象化できるものの、CBDCのプライバシーと運用モデルと整合性が取れていなければならないと結論付けました。プロジェクト・ロザリンドのレポートをご覧ください。

5. ウォレット、カード、加盟店決済、その他のエンドポイント

小売向けCBDCの場合、エンドポイントは銀行アプリ、専用ウォレット、スマートカード、フィーチャーフォンのフロー、POS端末、QRコード、またはその他のフォームファクターとなる可能性があります。エンドポイントは通貨そのものではなく、CBDCシステムへのアクセスメカニズムです。

設計者は、アクセシビリティ、紛失端末の復旧、認証、加盟店の受け入れ、取引明細、利用限度額、障がい者への対応、最新のスマートフォンを所有していないユーザーへのサポートなどを考慮する必要があります。技術的に優れた台帳であっても、これらのエンドポイントが使いにくい場合、公共決済システムとしては機能しない可能性があります。

6. オフライン決済

オフラインCBDCは、インフラストラクチャ上の最も困難な問題の一つです。なぜなら、どちらのデバイスもオンライン台帳にアクセスできない場合でも、システムが価値を移転する必要が生じる可能性があるからです。これは、二重支払い、デバイスの侵害、残高の不整合、および状態の不整合のリスクを高めます。

BISのProject Polarisハンドブックでは、オフライン設計に万能な方法はないことを強調しています。ソリューションには、セキュアなハードウェア、プリペイドバリュー、デバイス間転送プロトコル、リスク制限、および後からのオンラインシステムとの同期などが含まれます。Project PolarisオフラインCBDCハンドブックを参照してください。IMFの2025年限定接続ソリューションレビューでも同様に、プリペイドバリューカードとデバイス間アプローチが取り上げられており、フォームファクタ、サイバーセキュリティ、プライバシー、ユーザビリティ間のトレードオフが強調されています。IMF限定接続CBDCレビューを参照してください。

7. サイバーセキュリティ、レジリエンス、および運用管理

CBDCは国家の重要な決済インフラとなる可能性があるため、後から耐障害性を追加するだけでは不十分です。システムには多層防御が必要です。具体的には、強力な鍵管理、ネットワークのセグメンテーション、安全なソフトウェア開発、脆弱性管理、特権アクセス制御、トランザクション監視、バックアップと復旧、災害復旧サイト、インシデント対応、そして定期的なテストが求められます。

可用性目標は、中央台帳以外の依存関係、すなわち通信ネットワーク、IDサービス、クラウドまたはデータセンターのインフラストラクチャ、仲介システム、加盟店の決済処理、ハードウェアセキュリティモジュールなども考慮に入れる必要があります。脆弱な外部コンポーネントに依存するCBDCは、台帳が複製されているというだけで回復力があるとは言えません。

8. データアーキテクチャとプライバシー

プライバシーは単なる方針声明ではなく、インフラストラクチャの特性です。設計者は、どのようなデータを作成するか、どこに保存するか、どのくらいの期間保持するか、どの関係者が取引記録を個人に紐付けることができるか、そして法律に基づいて何を開示できるかを決定しなければなりません。

有効な手法としては、データ最小化、匿名識別子、IDデータとトランザクションデータの分離、暗号化、アクセスログ記録、役割に基づくデータ可視化などが挙げられます。より高度なプライバシー強化技術は、設計によっては適切な場合もありますが、不正対策、法的義務、パフォーマンス、および運用復旧をサポートする必要もあります。

9. 相互運用性と国境を越えた連携

中央銀行デジタル通貨（CBDC）は単独で存在することは稀です。国内インフラは、商業銀行の資金、即時決済システム、カードネットワーク、証券プラットフォーム、あるいは他のCBDCと接続する必要があるかもしれません。したがって、相互運用性にはメッセージフォーマットの互換性だけでなく、互換性のある本人確認規則、営業時間、流動性確保のための取り決め、為替メカニズム、法的枠組み、決済モデルなども必要となる場合があります。

卸売および国境を越えた利用に関しては、BISプロジェクトmBridgeやプロジェクトIcebreakerなどの実験で、共有プラットフォームや相互接続された国内システムが検討されてきた。これらは普遍的な設計図ではなく実験段階の取り組みだが、国境を越えた設計上の選択は、国家システムが既に確立された後に後付けで修正するよりも、早期に検討する方が容易であることを示している。

中央集権型データベースか、それとも分散型台帳技術（DLT）か？

重要な点は、どちらのアーキテクチャも自動的に「デジタル化」が進むわけではないということだ。中央銀行デジタル通貨（CBDC）はブロックチェーンを使用しなくても技術的に高度なものになり得るし、分散型台帳技術（DLT）ベースのシステムも、本人確認、API、監視、デバイス、サポート、ガバナンスといった従来のインフラストラクチャを必要とする。

小売業におけるCBDC決済の流れ

1. 登録：銀行または承認された決済プロバイダーがユーザーを確認し、必要なウォレット、アカウント、エイリアス、または認証情報を作成します。
2. 資金調達：利用者は商業銀行の資金または現金をCBDCに変換し、システムのルールに従って対応するCBDC残高または価値表現が作成または割り当てられます。
3. 支払い：ユーザーが送金を承認します。仲介機関とコアインフラストラクチャがリクエストを検証し、制限と制御を適用し、送金を最終的に決済します。
4. 通知と記録：支払者と受取人はステータス情報を受け取り、システムは選択されたアーキテクチャと法的枠組みで必要とされるデータのみを記録します。
5. 償還：ユーザーはCBDCを別の形態の通貨に変換することができ、必要に応じて対応するCBDCの表現を減額または消滅させることができます。

オフライン決済では、送金時に最終的なオンライン認証が利用できない可能性があるため、ステップ3が大幅に変更されます。そのため、オフライン機能を実現するには、単なる「オフラインモード」切り替えではなく、専用のリスク管理、ハードウェア、同期、および復旧設計が必要となります。

CBDCインフラストラクチャを評価するための実践的なチェックリスト

• 責任とガバナンス： CBDCは誰が発行するのか、各構成要素は誰が運用するのか、そして何らかの不具合が発生した場合、誰が責任を負うのか？
• 帳簿と決済：最終的な処理とは何か、また重複、取消、および回復はどのように処理されるのか？
• 分配モデル：中央銀行、銀行、決済プロバイダーのそれぞれにどのような責任があるのか​​？
• 本人確認とコンプライアンス： KYC/AMLチェックは誰が実施し、どのような情報が中央銀行に送られるのか？
• プライバシー：データは最小限に抑えられ、役割ごとに分離されていますか？取引と個人情報を関連付けることは可能ですか？また、誰が関連付けることができますか？
• パフォーマンス：システムは、想定されるピーク時のトランザクション量とレイテンシ要件を満たすことができるか？
• 回復力：複数の障害領域、災害復旧体制、およびテスト済みの事業継続手順は整備されているか？
• オフライン機能：必須ですか？必要な場合、どのようなセキュリティハードウェア、値制限、同期機能、不正対策が必要ですか？
• 相互運用性： CBDCは既存の決済システム、銀行、加盟店、そして場合によっては海外のシステムと連携できるのか？
• アクセスチャネル：対象ユーザー層向けに、スマートフォン、カード、フィーチャーフォン、または補助チャネルはサポートされていますか？
• ベンダー戦略：中央銀行を特定のサプライヤーに縛り付けることなく、部品の交換やアップグレードは可能か？
• 運用上の可観測性：監視、監査ログ、インシデント検出、照合、およびサポートプロセスは、最初から適切に設計されていますか？

現在のプロジェクトがCBDCインフラの方向性について明らかにするもの

現在のプロジェクトは、単一の普遍的なCBDCスタックではなく、モジュール式のエコシステムを目指しています。BISの技術要件に関する作業では、相互運用性、拡張性、ユーザー中心設計、セキュリティ、データプライバシーを高レベルの要件として強調しています（BISの高レベル技術要件を参照）。2025年11月に更新されたIMFのCBDC仮想ハンドブックも同様に、CBDCを政策、運用、技術、プライバシー、サイバーレジリエンス、および導入に関する複合的な課題として扱っています。

デジタルユーロプロジェクトは、このモジュール思考がどのように適用されているかを示す最新の例です。2025年10月に準備段階が終了した後、ユーロシステムはさらなる技術作業に着手しました。公開されているアーキテクチャ作業は、オフライン機能、安全な決済情報の交換、不正行為とリスク管理、アプリとソフトウェア開発キット、レジリエンス、プライバシー保護処理などの分野を網羅しています。2026年8月、ECBは、オフライン機能に関する作業として、2027年後半に予定されているパイロットテストに先立ち、組み込みセキュアエレメントやeSIMなどのスマートフォンのセキュアハードウェアを検討していると発表しました。ECBのデジタルユーロ進捗状況ページと、2026年8月18日のECBのオフライン標準更新情報を参照してください。これらの計画は欧州の立法および決定プロセスに従う必要があるため、最終的な発行システムの証明ではなく、プロジェクトの設計作業として読むべきです。

主な教訓：CBDCインフラはシステム群の集合体である

台帳は重要ですが、それはあくまでも一つの層に過ぎません。実用的なCBDCは、通貨発行、決済、仲介者、本人確認、プライバシー保護、API、ユーザーデバイス、加盟店による決済、サイバーセキュリティ、オフラインリスク、復旧、そして法的ガバナンスといった要素を調整する必要があります。したがって、最も信頼性の高い設計は、まず要件と運用上の役割を明確にし、次にそれらの要件に適合する技術を選択するという、逆の順序で行うべきではありません。

CBDCの提案を比較検討する読者にとって、最も役立つ質問は具体的なものです。台帳を誰が運用するのか？ユーザーの身元は誰が確認するのか？銀行やネットワークが利用できなくなった場合はどうなるのか？デバイスを紛失した後、ユーザーは資金を回復できるのか？システムはオフラインでの二重支払いをどのように防止するのか？複数のプロバイダーが共通のインターフェースを介して接続できるのか？そして、中央銀行の通貨の信頼性を損なうことなく、アーキテクチャを進化させることができるのか？これらの質問は、プロジェクトが「ブロックチェーン」という言葉を使っているかどうかよりも、CBDC設計の質について遥かに多くのことを明らかにします。