トークン化預金とは？開発に必要なシステム設計と企業導入の進め方を解説

トークン化預金の開発では、ブロックチェーンの導入自体が目的ではありません。まず、「従来のデータベースやAPIでは解決できない課題があるか」を見極める必要があります。

DLT（Distributed Ledger Technology：分散型台帳技術）は有力な選択肢ですが、すべての決済システムに適するわけではありません。預金とトークンの関係、既存システムとの役割分担、非同期処理、セキュリティまで含めた全体設計が重要です。

本記事では、トークン化預金の基本構造から、開発に必要なシステム設計、企業導入の進め方までを開発会社の視点で解説します。

トークン化預金とは？開発前に整理すべき基本構造

トークン化預金の開発では、預金とトークンをどのように対応させるかを最初に整理します。この関係が曖昧なままでは、残高の不整合や二重利用につながるためです。

なぜいま開発検討が増えているのか

トークン化預金が注目される理由は、決済と業務処理を連携し、企業間決済を効率化できるためです。

従来の銀行振込では、支払い、承認、入金確認、消込が別々に行われます。トークン化預金では、あらかじめ設定した条件に応じて決済できるため、次のような活用が想定されています。

• 商品の検収完了を条件に自動で支払う
• 24時間365日決済する
• デジタル証券やNFTと同時に決済する
• 請求から入金消込、会計処理まで自動化する

国内でも、デジタル資産決済、銀行間決済、企業間決済を想定した実証が進んでいます。

出典：

ゆうちょ銀行におけるトークン化預金の取扱に向けた検討について

金融庁「FinTech実証実験ハブ・決済高度化プロジェクト」

ディーカレットDCP「流通BMS×トークン化預金、受発注から債権管理システムまでのデータ連携に基づく決済/消込自動化に向けた実証実験が成功」

トークン化預金は単なる送金手段ではなく、決済と業務処理、デジタル資産をつなぐ基盤として検討されています。

トークン化預金の仕組みと預金残高との関係

トークン化預金は、銀行預金をそのままブロックチェーンへコピーする仕組みではありません。銀行預金とトークンは別々に存在するため、両者を適切に管理しなければ、同じ資金を二重利用できてしまいます。

例えば、銀行口座の1,000万円を拘束せずに同額のトークンを発行すると、預金とトークンを合わせて2,000万円分使える状態になります。そのため、預金残高とトークン残高は原則として1対1で対応させます。

一般的な処理は次のとおりです。

• 発行：対応する預金を拘束または専用口座へ振り替え、同額のトークンを発行する
• 移転：利用者間でトークンを移転し、総発行量は変えない
• 償還：トークンを消却した後、対応する預金を利用可能な状態へ戻す

あわせて、どのシステムを正式な残高である「正本」とするかも決めます。勘定系を正本にする場合は勘定系との整合性維持、DLTを正本にする場合はDLTの可用性や障害復旧が重要です。

不一致が生じた場合の検知、照合、復旧方法まで含め、預金とトークンを一つのライフサイクルとして管理する設計が必要です。

ステーブルコインとの違い

トークン化預金とステーブルコインは、いずれもブロックチェーン上で利用できるデジタルマネーですが、発行主体や法的な位置付けが異なります。

開発上の違いは、価値をどのシステムが保証するかです。

トークン化預金では勘定系が預金残高を管理するため、発行・償還のたびに勘定系との整合性を維持します。一方、ステーブルコインでは、発行方式に応じた裏付け資産や償還基盤の管理が必要です。

トークン化預金システムの全体アーキテクチャ

実用的なシステムを構築するには、DLTだけでなく、勘定系、ERP、API連携基盤、KYC・AML、監視・監査まで含めて役割を分担します。

DLTを採用する目的と適用範囲を決める

DLTを採用するかどうかは、製品ではなく業務課題から判断します。

同行内の送金や預金残高管理であれば、既存データベースとAPIで足りる場合があります。一方、複数の企業や金融機関が取引記録を共有し、共通ルールで決済や資産移転を行う場合は、DLTの特徴を生かしやすくなります。

導入前には、次の点を確認します。

• 取引記録を複数組織で共有する必要があるか
• 共通ルールで処理を実行する必要があるか
• 条件付き決済や異種資産との同時決済が必要か
• 既存システムだけでは解決できない課題があるか

DLTは目的ではなく、課題を解決するための手段です。適用範囲を見極めることが、システム設計の第一歩となります。

オンチェーン・オフチェーンを含む主要コンポーネント

一般的なトークン化預金システムは、次の要素で構成されます。

例えば、預金残高は勘定系、トークンの発行・移転・償還はDLT、KYC・AMLや法人承認は既存システムで管理する構成が考えられます。

金融機関ごとに異なるレガシーシステムを全面的に置き換えるのではなく、DLTを共通連携基盤として使い、システム間の違いを吸収する設計も有力です。オンチェーンとオフチェーンを対立させず、処理特性に応じて分担します。

同行内・銀行間・異種資産決済でシステム構成が変わる

必要なシステム構成は、決済の範囲によって変わります。

取引の原子性とは、証券と代金などを必ず同時に移転し、片方だけ成立する状態を防ぐ性質です。

対象範囲が広がるほど、システム構成や運用は複雑になります。そのため、同行内や限定した企業間取引からPoCを始め、段階的に適用範囲を広げる進め方が現実的です。

トークン化預金の開発に必要な5つのシステム設計

トークン化預金を安全に運用するには、トークンモデル、DLT基盤、スマートコントラクト、既存システム連携、セキュリティを一体で設計します。

①発行・移転・償還を管理するトークンモデルを設計する

トークンモデルでは、発行・移転・償還のルールを定めます。主な検討項目は次のとおりです。

• 利用者の範囲：誰がトークンを保有・送金できるか
• 発行・移転・償還の条件：各処理を実行する条件
• 管理者権限：凍結や返還を実行できる主体
• 残高管理：預金残高とトークン残高を照合する方法
• 障害対応：異常終了時の復旧方法

特に重要なのは、預金残高とトークン総発行量の整合性です。発行から償還、障害復旧までを通じて不整合を防ぐ必要があります。

②参加者とデータ共有範囲を管理するDLT基盤を設計する

DLT基盤では、参加者、データ共有、取引承認のルールを定めます。

• 参加者の識別方法
• データの閲覧・更新権限
• 取引承認のルール
• ノードの運営主体
• 処理確定までの時間
• 可用性や障害発生時の継続性

銀行だけが取引を閲覧するのか、企業や監査機関にも権限を与えるのかによって、アクセス制御やネットワーク構成は変わります。

金融分野では、参加者を限定できる許可型DLTが採用されるケースが多く、代表例にHyperledger Fabricがあります。ただし、製品名から選ぶのではなく、参加者数、処理性能、プライバシー、運用体制などの要件に合う基盤を選定します。

③業務ルールを実行するスマートコントラクトを設計する

スマートコントラクトは、発行・償還や条件付き決済などの業務ルールを自動実行します。

主な実装対象は次のとおりです。

• トークンの発行・移転・償還
• 利用者や送金先の制限
• 送金金額の上限設定
• トークンの凍結・解除
• 条件付き決済
• 緊急停止（Emergency Stop）

一方、ERPや勘定系との連携、外部データの真正性確認、プログラム更新の承認、運用・監査は、オフチェーンを含めて設計します。

スマートコントラクトの不具合はシステム全体へ影響するため、コードレビュー、第三者監査、十分なテスト、権限分離、緊急停止機能が欠かせません。

④勘定系・ERPと連携する非同期処理とAPIを設計する

DLTと勘定系、ERPを連携する場合、処理要求を受け付けた時点と、DLT上で取引が確定する時点は一致しないことがあります。そのため、取引ごとに状態を管理します。

API連携では、一意の取引ID、冪等性、状態照会、再実行・補償処理、残高照合も設計します。冪等性とは、同じ要求を繰り返しても二重送金などが起きず、結果が変わらない性質です。

応答が返らないことと取引失敗は同じではありません。タイムアウト後に状態を照会し、確定済みなら後続処理だけを進めるなど、状態に応じた復旧が必要です。

⑤セキュリティ水準と鍵・権限・KYC・AMLを設計する

セキュリティ設計では、鍵管理、権限管理、本人確認、監査を含む運用ルールを定義します。

• 秘密鍵の保管・更新方法
• 利用者・管理者の権限管理
• 多段階承認のルール
• KYC・AMLとの連携
• 操作ログ・監査証跡の保存
• テスト項目と受入基準

金融システムでは、「誰が、どの権限で、いつ、何を行ったか」を追跡できることが不可欠です。安全性だけを高めて業務が停止しないよう、必要な保証水準と受入基準を要件定義で明確にし、運用性とのバランスを取ります。

関連記事：秘密鍵の管理方式については、「MPCウォレットの秘密鍵管理と設計」で詳しく解説しています。

製造業の企業間決済で見るトークン化預金の実装例

トークン化預金を実務で使うには、決済が正常に完了する流れだけでなく、処理結果が返らない場合の対応までを設計に含める必要があります。こちらでは製造業の買い手企業と納入企業の支払いを例に、前章までの設計要素が業務の中でどう機能するかを確認します。 

検収完了からトークン化預金を移転するまでの流れ

ERPの検収完了を支払いの起点とし、次の条件を確認します。

条件を満たすと、スマートコントラクトがトークンを移転します。取引確定後、ERPへ結果を返し、会計データや債務情報を更新します。

このように、トークン化預金は送金だけでなく、検収、承認、決済、会計処理をつなぐ仕組みです。

処理結果が返らない場合の確認・再実行・残高照合

APIの応答が返らなくても、DLT上では取引が成立している場合があります。復旧時は、まず取引状態を確認します。

例えば、DLTでは送金が完了し、ERPだけ未更新なら、送金を再実行せずERPのみ更新します。重要なのは、一定時間後に機械的に再送することではなく、取引状態に応じた復旧手順を決めることです。

導入前後で業務がどう変わるか

トークン化預金の導入で変わるのは、決済と業務システムの連携方法です。

期待できる効果は、営業時間に左右されにくい決済、振込登録や消込の省力化、決済待ち期間の短縮です。ただし、DLTを導入するだけでは実現できません。業務フローと既存システムを含めた設計が必要です。

企業がトークン化預金を導入する手順

導入時は、業務要件とセキュリティ要件を整理し、PoC（概念実証）で成立性を検証したうえで本番運用へ移行します。

STEP0｜社内の推進体制と関係部門を確定する

トークン化預金は、決済、会計、法令、セキュリティに関わるため、システム部門だけでは要件を整理できません。

法務や情報セキュリティを終盤で加えると、大幅な仕様変更につながることがあります。要件定義から関係部門が参加し、役割と判断基準を共有します。

STEP1｜ユースケースとセキュリティ要件を整理する

発注前に、改善したい業務、支払者と受取者、決済条件、既存システムとの連携、DLTを利用する必要性を具体化します。

あわせて、次のセキュリティ要件も定義します。

要件が曖昧なままでは、開発会社は適切な設計や見積もりを提示できず、発注側も成果物を評価できません。

STEP2｜PoCで業務・技術・運用の成立性を検証する

PoCでは、技術的に動くかだけでなく、実業務で継続運用できるかを確認します。

セキュリティ対策によって業務が過度に複雑にならないかも確認し、安全性と導入効果の両立を評価します。

STEP3｜本番開発・運用・ガバナンス体制を構築する

PoC後は、変更管理、監査、障害対応を継続できる体制を整えます。

発注側と開発会社で、本番移行の判断基準や変更手続きを共有しておくことも重要です。開発後の運用まで設計して初めて、継続的に利用できる決済基盤になります。

また、技術的に実装できることと、金融機関や企業が継続運用できることは別問題です。責任分界、監査方法、障害時の判断権限まで明文化し、通常時だけでなく異常時にも迷わず対応できる状態を整えることが、本番導入の条件になります。

まとめ

トークン化預金の開発で重要なのは、DLTの採用そのものではなく、業務課題を起点にシステム全体を設計することです。

預金とトークンの整合性、オンチェーンとオフチェーンの役割分担、既存システムとの非同期連携、鍵・権限管理までを一体で検討する必要があります。

導入時は、限定したユースケースでPoCを行い、業務効果だけでなく、異常系や復旧手順、運用体制も検証します。既存のレガシーシステムを生かしながら共通連携基盤を構築し、段階的に対象範囲を広げる進め方が現実的です。

関連記事：ブロックチェーン開発の費用や進め方の全体像は、「ブロックチェーン開発にかかるコストと進め方」をご覧ください。