コラム

トークン化預金は、銀行預金という既存の金融商品を、分散型台帳技術（DLT）などのプログラマブルな台帳上で表現・移転できるようにする仕組みです。単に「預金をコインにする」ことではなく、誰に対するどのような権利なのか、銀行の正式な預金台帳とどう整合させるのか、銀行をまたぐ場合に何で最終決済するのかを一体で理解することが重要です。

本記事では、トークン化預金を「新しい資産」ではなく「既存の預金債権を別の形式で扱う仕組み」として捉え、その仕組み・法的性質・銀行間決済・リスク・システム要件を実務目線で解説します。

1. トークン化預金の基本的な定義

トークン化預金とは、銀行に対する預金者の請求権、すなわち預金債権を、DLTやその他のプログラマブルな台帳上でデジタルに表現したものです。実務上は、銀行台帳との関係性に応じて複数の実装方式がありますが、狭義には預金債権をDLT上で記録・管理する仕組みを指します。

このため、トークン化預金の本質は「暗号資産のような新しい資産を発行すること」ではありません。基本的には、預金者が銀行に対して持つ既存の債権を、別の技術的な形式で記録し、移転や条件付処理を可能にするものです。欧州銀行監督機構（EBA）は、預金債権をDLTに記録すること自体は直ちに規制上の分類変更を意味しないとの考え方を示しています。

2. トークン化で変わるもの、変わらないもの

 DLTは、記録の共有に加え、あらかじめ定めた条件に基づいて処理を実行できる「プログラマビリティ」や、複数当事者による同時参照といった機能を提供します。
 しかし、預金契約、本人確認、銀行の信用供与、会計処理、監査、法的な債務消滅といった金融実務が不要になるわけではありません。技術は既存の責任を消すのではなく、その実現方法や統制手段を新しい処理方式へ移行するものと捉える必要があります。

3. 実装方式は一つではない

「トークン化預金」は国際的にも統一された単一の技術方式を意味しません。実務上は、次のような類型で整理すると理解しやすくなります。以下は法令上の分類ではなく、システム設計を比較するための分析上の類型です。

4. 発行・移転・償還の基本フロー

トークン化預金のライフサイクルは、一般に発行（Mint）、移転（Transfer）、償還または消却（Burn）、照合（Reconciliation）で構成されます。ただし、各処理の法的効果や銀行台帳の更新タイミングは設計により異なります。

①対象額の確保
　預金者の既存口座から対象額を確保する。確保方法は、専用口座への振替、残高拘束、管理勘定への計上など設計により異なる。

②発行（Mint）
　銀行または権限を付与された基盤が、確保額を超えない範囲でデジタル表象を発行する。

③移転（Transfer）
　利用者間の移転では、本人確認、権限、残高、利用上限、制裁・不正利用リスク等を確認する。

④償還・消却（Burn）
　デジタル表象を消却または利用不能にし、対応する預金残高を通常の銀行取引で利用できる状態に戻す。

⑤照合（Reconciliation）
　銀行台帳、DLT上の残高記録、ウォレット残高、管理勘定、会計記録を定期またはリアルタイムで照合し、不一致を例外管理する。

5. 預金創造との関係

銀行預金は、現金を預け入れた場合だけでなく、銀行が貸出を実行する際にも生まれます。銀行が借り手の口座に貸出金を記帳すると、銀行の資産側には貸出債権、負債側には預金が計上されます。これが一般に預金創造と呼ばれる仕組みです。

既存預金の一部をトークン化対象として振り替えるだけであれば、それは預金の表示・利用形態を変更する処理であり、トークン化そのものによって銀行全体の預金総額が増えるわけではありません。一方、仕組み上は、銀行が貸出実行と同時にトークン化預金を発行する設計も想定されます。その場合でも、与信判断、自己資本規制、流動性規制、会計・監査等の銀行業務上の要件が消えるわけではありません。

6. 同一銀行内と銀行間では何が違うか

同じ銀行の顧客間でトークン化預金を移転する場合、銀行の負債の帰属先が顧客Aから顧客Bへ変わります。銀行全体として見れば債務者は同じ銀行であり、通常は他行との中央銀行マネー決済を伴いません。

これに対し、銀行Aの顧客から銀行Bの顧客へ価値を移す場合、銀行Aの負債を減らし、銀行Bの負債を増やすだけでは銀行間の債権債務が残ります。そのため、中央銀行当座預金、銀行間決済資産、既存決済システム、またはあらかじめ合意した決済メカニズムによって、銀行間の最終的な資金決済を行う必要があります。

7. 中央銀行マネーと通貨の一体性

現行の銀行制度では、異なる銀行の預金が同じ通貨単位で額面どおり交換できることが重要です。

これを通貨の一体性（singleness of money）と呼びます。中央銀行マネーによる銀行間決済、健全性規制、預金保険制度等が組み合わさることで、一般利用者は銀行ごとに円の価値が違うと意識せずに利用できます。

トークン化預金でも、この一体性を維持する必要があります。銀行ごとのトークンが別々のネットワークで発行され、相互に額面交換できない、または流動性や償還条件が異なる場合、同じ「1円」建てであっても、交換可能性や流動性、利用可能な場面に差が生じる可能性があります。このため、相互運用性、額面償還、銀行間決済、共通ルール、障害時対応が制度設計の中心になります。

8. スマートコントラクトとプログラマビリティ

スマートコントラクトは、あらかじめ定めた条件に基づいて台帳上の処理を実行するプログラムです。トークン化預金と組み合わせることで、商品の引渡しと支払を同時に行うDvP（Delivery versus Payment）、異なる通貨を同時交換するPvP（Payment versus Payment）、承認条件付支払、利用目的制限、期限管理などを実装しやすくなります。

ただし、プログラムが実行されたことと、現実の契約上の義務が適切に履行されたことは同じではありません。外部データの誤り、権限設定、契約変更、取消し、裁判所や当局の命令、障害時の手作業などを含め、コード外のガバナンスが必要です。

9. 技術的確定と法的ファイナリティ

ブロックチェーン上で取引が一定数の承認を得て覆りにくくなった状態は、技術的な確定性を示します。一方、法的ファイナリティとは、支払債務がいつ消滅し、誰がどの権利を確定的に取得したかが法令・契約・参加者ルール上明確になることです。

両者は一致するとは限りません。たとえば、DLT上の移転が完了しても銀行台帳の更新が未了である場合、外部決済資産の受渡しが完了していない場合、権限外取引や不正アクセスが判明した場合など、法的効果の判断が別途必要になります。システム設計では、受付、検証、ロック、台帳記録、銀行勘定更新、通知、取消不能となる時点を分解して定義します。

10. 他のデジタルマネーとの比較

11. 期待されるメリットとユースケース

これらは自動的に実現する効果ではありません。既存システムとの二重運用、参加者の少なさ、外部データ連携、24時間運用、規制対応などにより、初期段階では従来方式より高コストになる場合もあります。ユースケースごとに、削減できる摩擦と新たに増える統制コストを比較する必要があります。

12. 日本の法制度上の見方

日本では、トークン化預金を一律に定義する専用の法令上の分類が確立しているわけではありません。銀行が預金契約に基づく債務として発行し、保有者が銀行に対して預金の払戻し等を請求できる構造であれば、基本的には銀行預金としての法的性質を起点に検討することになります。

ただし、第三者への自由譲渡、匿名性、外部ウォレットへの移転、預金者とトークン保有者の不一致、信託や別主体の介在、破綻時の権利、預金保険、利息、相殺、差押え、本人確認等によって評価は変わり得ます。預金保険の適用についても、「トークン化預金」という名称のみで判断せず、対象預金の種類、預金者の特定、名寄せ、払戻し請求権、帳簿記録等を個別に確認する必要があります。

13. システム・業務要件

14. 主なリスク

・台帳不一致リスク
　銀行台帳とDLT残高が一致せず、払戻し可能額や保有者の権利が不明確になる。

・鍵・ウォレットリスク
　秘密鍵の漏えい、紛失、誤送付、内部不正により不正移転が発生する。

・スマートコントラクトリスク
　コード不具合、権限奪取、アップグレード失敗等が広範囲の取引に影響する。

・決済・流動性リスク
　銀行間決済資産や為替流動性が不足し、トークン移転と最終決済がずれる。

・法的リスク
　台帳記録の効力、取消し、破綻時の権利、準拠法、差押え等が不明確になる。

・AML/CFT・制裁リスク
　外部ウォレットや越境利用によって、顧客・取引相手・資金源の確認が難しくなる。

・運用リスク
　24時間稼働する台帳に対し、銀行の審査・照会・障害対応が営業時間内に限定される。

・集中・外部委託リスク
　特定クラウド、チェーン、ウォレット、オラクル等への依存が単一障害点になる。

・デジタルバンクラン（オンライン環境で預金が急速に流出する現象）
　移転の即時性が高まることで、危機時の預金流出が速くなる可能性がある。