トークン化預金の検討では、送金手段を置き換えることだけでなく、請求、承認、納品確認、支払い、消込、会計処理といった企業間の商流をどこまで連動できるかが重要です。国内で43社が参加する銀行間決済実証は、その実現に必要な資金移転、システム接続、運用統制の条件を具体的に検証する動きとして捉えられます。
トークン化預金は、銀行預金をプログラム可能な台帳上で扱い、商流やデジタルアセット取引と決済を連動させるための仕組みとして検討されています。ステーブルコインとの制度上・仕組み上の違いは、「トークン化預金とステーブルコイン――何が違う？」で整理しています。
トークン化預金の社会実装において重要なのは、複数の銀行をまたいで企業間決済を完結できるようになることです。
取引企業が異なる銀行を利用している場合、利用者間でトークン化預金を移転するだけでなく、銀行間でどのように資金を決済するかを設計する必要があります。ここには、資金移転の確定方法、既存決済基盤との接続、夜間や休日の運用、障害時の対応など、実務上の課題が含まれます。
こうした現在地を示す国内事例が、金融庁「FinTech実証実験ハブ」の支援案件である「トークン化預金の銀行間決済」です。DCP、GMOあおぞらネット銀行、アビームコンサルティングの公表によると、同案件は2026年4月3日に採択され、43社が参加しています。2026年8月20日には、参加企業と関係者による本格的な検証が始まったとされています。
公表資料では、民間銀行1行を幹事行として利用者間送金と銀行間決済を処理する方式、利用者間送金に伴う銀行間決済にステーブルコインを活用する方式、既存の決済システムと連携する方式が検討対象として示されています。目指しているのは、オンチェーンで行われた利用者間取引に対応する銀行間決済を、24時間365日の即時グロス決済として扱えるかを、適法性、有用性、実現性の観点から検証することです。
これは特定方式の採用や実用化が決まったことを意味するものではありません。一方で、トークン化預金の議論が、単一銀行内の送金から、複数銀行が関わる決済設計へ進みつつあることを示す事例といえます。
企業間決済の世界では、請求書の発行、発注内容との照合、納品・検収、支払承認、振込、入金消込、会計記帳を扱うシステムが、それぞれ別の部署や環境で処理されているケースが見られます。仮に送金だけを即時化しても、前後の手続きが分断されたままであれば、業務全体の処理時間や確認作業が大きく変わらないことも少なくありません。
そのため、トークン化預金の導入可能性は、「既存の振込より速いか」だけで評価するのではなく、商流上のイベントと資金移転をどこまで接続できるかで考える必要があります。例えば、所定の承認や納品確認が完了した場合に支払いへ進む仕組みや、請求情報、取引ID、支払情報を関連付けて消込を支援する仕組みが検討対象になります。
あらゆる業務が条件付き執行や自動化に適しているとは限りません。数量や品質について人の判断が必要な取引、契約変更が多い取引、部分納品や相殺が発生する取引では、例外処理を前提とした設計が欠かせないからです。
そこで出発点となるのは、技術方式の選定ではなく、自社の商流を可視化することです。どの情報が支払いの条件になっているのか、誰がその条件を確認しているのか、訂正や取消が必要になった場合に誰が判断するのかを整理することで、トークン化預金を検討すべき業務が見えやすくなります。
国内では銀行間決済に加え、企業間取引の自動化やセキュリティトークンの決済など、トークン化預金の検討対象が広がっています。個別の仕組みや進捗は異なりますが、それぞれの検討や取り組みを見渡すと、金融機関と事業会社が確認すべき論点が、次の5つに整理できます。
24時間365日の処理は、営業時間外にも資金移転を実行できる可能性を示します。しかし、支払受付、社内承認、銀行間決済、会計反映、取引先への通知まで、すべての業務が即時化されるとは限りません。
どの時点で資金移転を確定と扱うのか、確定後に訂正や返金が必要になった場合はどう処理するのかを定義する必要があります。夜間・休日の障害監視や問い合わせ対応、資金不足時の扱いも含め、システムの稼働時間と業務の運用時間を分けて設計することが重要です。
プログラマビリティを活用すると、発注、納品、検収、承認などのイベントと支払いを関連付ける設計が可能になります。共通の取引IDを請求情報と支払情報に付与できれば、入金消込や照合作業を支援できる余地もあります。
一方で、条件をシステムへ実装するには、条件の充足を誰が判定するのか、判定に使うデータを誰が提供するのかを決めなければなりません。請求金額の変更、部分納品、返品、相殺、取引先との認識相違などを想定し、手動処理へ切り替える条件と操作権限を定義する必要があります。
銀行間決済は、同じ基盤上のトークン化預金だけで完結させる設計に限られません。既存の銀行システムや決済基盤を利用する方法、別の決済手段を接続する方法も検証対象になります。
企業の取引先や利用金融機関が、すべて同じ方式を同時に採用するとは限りません。当面は、トークン化預金を利用する取引と従来の振込を利用する取引が併存する可能性を踏まえ、残高管理、会計処理、照合方法を設計することが現実的です。
相互運用性は、異なる銀行や台帳の間でトークンを移転できるかという技術的な問題だけではありません。企業のERP、会計システム、資金管理システム、受発注システムとの間で、必要なデータを正確に受け渡せるかという業務上の問題でもあります。
例えば、台帳上の取引IDと請求書番号、発注番号、会計伝票番号を関連付けられなければ、決済が完了しても消込や監査の作業が残ります。データ形式、照合ルール、処理状況の通知方法、エラー発生時の責任分界を関係者間で定義することが必要です。
トークン化預金を企業業務へ組み込む場合、台帳や利用者向け画面だけでなく、ERP、会計、資金管理、承認ワークフローとの接続まで設計する必要があります。仕訳を計上する時点、残高を確定する時点、銀行側と企業側の記録を照合する方法も明確にしなければなりません。
内部統制では、支払いの起案者、承認者、実行者の権限分離、操作履歴の保存、監査証跡の取得、秘密鍵や認証情報の管理が重要です。障害、不正利用、誤送信が発生した場合の停止・復旧手順も必要になります。決済をプログラム可能にしても、企業に求められる統制そのものが不要になるわけではありません。
国内では、銀行間決済以外にも商流と決済を接続する取り組みが公表されています。日立製作所は、トークン化預金を活用した企業間取引の自動化に関する実証結果を公表しています。また、SBIグループは、セキュリティトークンの受渡しにトークン化預金を利用する検証を2025年12月に発表した協業のもとで進め、2026年4月に実発行での検証完了を公表しています。
これらは、トークン化預金の検討対象が単純な企業間送金に限られず、商流情報との連動やデジタルアセット取引の決済にも広がっていることを示します。ただし、公表された実証の存在だけで、業務効率化やコスト削減の効果を一律に判断することはできません。
海外でも、J.P. MorganのKinexys Digital Paymentsや、DBSとKinexysによる複数基盤間のトークン化預金移転に関する取り組みが公表例として挙げられます。ここでも注目すべきなのは個別サービスの規模ではなく、企業向け決済を営業時間外にも扱うことや、異なる台帳・銀行間で資金移転を接続することが検討テーマになっている点です。
中央銀行の側でも、日本銀行を含む7つの中央銀行が参加するBISの「Project Agorá」が、トークン化した商業銀行預金を中央銀行マネーと同じ基盤で扱う試作の結果を2026年5月に公表しています。
国内外の事例を自社に引き寄せて評価するときは、対象通貨、利用可能な企業、取引の種類、資金移転の確定方法、既存システムとの接続条件を確認する必要があります。名称が同じ「トークン化預金」であっても、発行、移転、償還、銀行間決済の設計は一様ではありません。
第一に、対象業務を選定します。請求から入金消込までの処理量が多い業務、取引条件が比較的定型化されている業務、支払いまでに複数の確認が必要な業務を洗い出します。通常処理だけでなく、訂正、返品、分割払いなどの例外件数も確認することが重要です。
第二に、取引先との連携条件を整理します。支払条件、納品確認の方法、共有するデータ項目、取引ID、訂正時の手順は、一社だけでは決められません。まずは対象となる取引先や金融機関を限定し、共通化できる業務ルールを確認すると検討を進めやすくなります。
第三に、既存システムとの接続点を特定します。ERP、会計、資金管理、受発注、承認ワークフローのうち、どのシステムが正となるデータを保持し、どの時点で仕訳や残高を確定させるかを整理します。APIの有無だけでなく、更新頻度や照合方法も確認対象です。
第四に、統制と運用を設計します。承認権限、操作ログ、証跡保存、認証情報の管理、障害時の連絡体制、訂正・取消の手順を、通常時と例外時に分けて定義します。金融機関側では銀行間決済と顧客管理の責任分界、事業会社側では支払承認と会計処理の整合性が主要な論点になります。
トークン化預金を検討する最初の成果物は、技術構成図ではなく、対象業務、関係者、データ、資金移転、例外処理を一つの流れとして整理した業務フローであるべきです。その上で、トークン化預金がどの部分に適用可能かを評価することで、実証の目的と検証項目を具体化できます。
43社が参加する国内実証は、トークン化預金の論点が単一銀行内の送金から、複数銀行をまたぐ決済へ広がっていることを示しています。一方、企業にとって重要なのは新しい決済方式そのものではなく、請求、承認、納品確認、支払い、消込、会計処理をどこまで連動できるかです。24時間365日処理、条件付き執行、銀行間決済、相互運用性、内部統制を自社業務に照らして整理することで、検討すべきユースケースと準備事項が見えやすくなります。
Gincoは、金融機関や事業会社におけるデジタルアセット活用とオンチェーン金融の検討において、商流・決済業務の整理から、システム接続、ウォレット運用、権限管理、監査対応までを横断的に支援しています。
構想整理、ユースケース選定、PoC設計、システム要件定義、ウォレット基盤の設計、既存システム連携、運用・内部統制設計などが可能です。
皆さんのデジタルアセット活用やオンチェーン金融事業実現を専門家チームが支えます。事業全体の構想からシステム要件定義、開発、保守運用まで、あらゆるフェーズからプロジェクトに伴走しますので、ぜひお気軽にご相談ください。
.png)
