コラム

企業のグローバル資金管理では、オンチェーンを使った資金移動が一部で商用化され、日本企業や日本の口座へも対象が広がっています。ただし、利用できる銀行、通貨、地域には条件があり、企業グループの全資金を自由に動かせる段階ではありません。

導入の価値は、資金が必要になるタイミングに合わせて移動を実行し、その結果を貸借管理や会計までつなげられるかで決まります。本稿では、オンチェーン、すなわちブロックチェーン上で残高や取引を記録・処理する仕組みが、既存の資金管理と何が違うのかを整理します。

1. グローバル資金管理は何をしているのか

企業財務のグローバル資金管理は、各国の法人・口座に分散する資金を把握し、支払、投資、借入、外国為替取引（FX）を含めてグループ全体の流動性を管理する業務です。銀行は、こうした業務を支えるCMS（キャッシュ・マネジメント・サービス）を提供しています。

代表的な手法には、資金を集約するキャッシュ・プーリング、口座間で余剰資金を移すスイープ、債権・債務を相殺するネッティング、社内銀行機能、支払集約があります。企業側ではTMS（財務管理システム）やERP（会計などを統合する基幹システム）を使い、残高・資金予測を集約して銀行へ指図します。

2. 現在の仕組みにはどこに課題があるのか

国際的な資金移動には、銀行や通貨ごとのカットオフ（受付締切）、休日、送金を中継するコルレス銀行、法人ごとの口座構造が関係します。資金需要が見えていても、必要なタイミングに移動できるとは限りません。

また、送金、必要に応じた為替取引、残高報告、会計処理を別々に扱うと、到着待ちの資金や予備資金が増え、照合も必要になります。ただし、既存サービスでも即時送金や日中スイープは進んでいます。まずは、現在利用している銀行サービスの機能と制約を把握し、オンチェーンを活用した場合との違いを比較する必要があります。

3. オンチェーン化すると何が変わるのか

オンチェーン化によって期待される主な変化は、3つあります。

第1に、対応する口座間で資金移動の時間帯が広がります。第2に、残高の変化や支払予定など、あらかじめ設定した条件に応じて資金移動を実行できるようになります。これが、プログラマビリティと呼ばれる機能です。第3に、対応するサービスでは、取引に関係する金融機関や企業が同じ取引状態を参照し、為替取引や資産移転と決済を連動させることが可能になります。

これらの機能は、すべてのオンチェーンサービスに備わるわけではありません。既存のAPI（システム連携の窓口）でも実現できる自動化と、共通の実行環境によって照合や処理待ちを減らせる部分を分けて考える必要があります。

■既存サービスとオンチェーン活用時の比較

4. 条件に応じたスイープを業務に組み込む

例えば、子会社の残高から当日・翌日の支払必要額を控除し、余剰分を資金統括会社へ移す運用が考えられます。資金不足が見込まれるときは資金統括会社から補填します。こうした条件付きスイープでは、予測データの更新時刻、最低残高、移動上限も条件に含めます。

J.P. MorganとMIT Digital Currency Initiativeの共同論文は、企業側で判定して銀行に指図する方式と、銀行側の環境に企業の実行ルールを配置する方式を区別しています。既存の銀行商品にも残高調整機能があるとしたうえで、条件や動作の柔軟性を広げる意義を論じています。

出典： J.P. Morgan と MIT DCI  プログラマビリティの銀行業務への適用  2024年7月

重要なのは、条件判定から残高確認・移動実行までの間に状態が変わる場合への対処です。古い予測での送金や二重実行を防ぎ、ルール変更時の承認手続きや緊急停止の仕組みを設けます。予測にAIを利用する場合も、AIの予測結果で送金を実行するのではなく、送金権限や上限を別途設定・管理します。

5. 同一通貨の移動と為替取引を伴う移動を分ける

米ドルを米ドルのまま、日本と海外拠点の間で動かす場合、送金経路上の外国為替取引は必須ではありません。まず同一通貨の移動と資金集中を実装し、必要な場合に通貨交換を追加する進め方が可能です。

円をドルに換える場合などは、価格提示、取引可能な通貨ペア、夜間・休日の流動性、決済時間を確認します。オンチェーンFXでPvP（両通貨の受渡しを相互に条件付ける決済）を実現できれば、一方の通貨だけを引き渡す元本リスクを抑えることができます。ただし、為替変動や資金調達のリスクまでなくなるわけではありません。

さらに、ネットワーク内の24時間送金と、従来口座からの入出金は別に確認すべきです。Kinexysの公開説明では、従来型の預金口座とBlockchain Deposit Accountとの間の資金移動について、毎週土曜日の米国東部時間15時から18時まで、3時間の停止時間があると注記されています。通貨対応の拡大だけで、あらゆる経路が常時利用できるとは判断できません。

出典： J.P. Morgan On-chain FX 入出金停止時間の注記を含む

6. 企業財務で利用・検討されるマネー

銀行との預金関係を維持する場合、トークン化預金や銀行のブロックチェーン預金口座が選択肢になります。ただし、口座型の商品と移転可能な預金トークンでは、保有・移転できる相手やネットワークが異なります。そのため、商品ごとに預金契約、口座の所在国、利用条件を確認する必要があります。

公開型のブロックチェーン上の取引先やトークン資産と決済する場合には、ステーブルコインが候補になります。ただし、相手の受入れ、保有・利用できる地域、銀行預金への換金、手数料、会計処理まで含めた評価が必要です。複数銀行への接続が自動的に解決するわけではありません。

中央銀行マネーは、通常、企業が直接保有・利用する手段ではなく、金融機関間の最終決済を支える基盤として位置付けられます。具体例として、ホールセールCBDCやトークン化中央銀行準備があります。一般利用者向けのリテールCBDCとは利用対象を分けて考えます。

7. 既存システムと貸借管理をつなぐ

TMS・ERPは、資金予測、支払予定、法人別のルールや会計情報を管理します。オンチェーン基盤とは、APIなどで指図と結果を連携し、どの記録をどの業務の基準にするかを明確にします。

親子会社など別法人間の資金集中では、契約に応じて貸付・借入などの関係が生じます。ウォレットや口座の残高移転だけでは、貸借の記録、利息計算、会計仕訳は完成しません。取引識別子、送金元・先法人、通貨、金額、資金使途を関連付け、貸借管理と会計へ反映する設計が必要です。

送金指図の受付、送金資金の引当て、資金移動の完了、会計反映は、それぞれ別の処理状態として管理します。送金は完了したが会計連携だけ失敗した場合には、資金を再送せず、結果の再通知・再照合で復旧できる仕組みが必要です。既存の金融システムとオンチェーンを接続するうえでは、こうした処理状況の整合性を保つことが実務上の重要なポイントになります。

8. 商用利用と複数銀行での実証が並行して進む

J.P. Morganは2026年3月31日、三菱商事がシンガポール、ロンドン、ニューヨーク間のグループ内米ドル資金管理にKinexys Digital Paymentsを採用したと発表しました。同年6月29日には日本円を含むアジア太平洋の5通貨への対応を発表し、JERA Global Marketsが円建てのBlockchain Deposit Accountをグループ内資金管理に利用している事例を紹介しています。

出典： J.P. Morgan 三菱商事のグループ内資金管理での採用 2026年3月31日
 J.P. Morgan アジア太平洋の5通貨追加とJERA Global Marketsの利用 2026年6月29日

Citiは2026年9月28日、Citi Token Servicesの対象を日本とUAEへ広げ、計7市場で稼働していると発表しました。日本で対応する取引通貨は米ドルです。日本の口座が対象になることと、日本円を扱えることは区別する必要があります。

出典： Citi Citi Token Servicesの日本とUAEへの拡大 2026年9月28日

これらは銀行が提供するネットワーク内の利用拡大です。一方、Citiは9月2日、Swiftの共有台帳上でファースト・アブダビ銀行（FAB）、OCBC銀行と実取引を実施したと発表しました。こちらは2026年7～12月の管理された概念実証の一環であり、一般企業が自由に利用できるマルチバンクCMSの完成を意味しません。

出典： Citi Swiftの台帳上でFABとOCBCとの実取引を実施 2026年9月2日

BIS（国際決済銀行）のProject Agoráでは、2026年7月に中央銀行準備と銀行預金のトークンを用いた実価値取引の検証が行われました。この検証では、アジア、欧州、北米の金融機関・中央銀行計28機関が取引を実施し、取引総額は約80万スイスフラン相当でした。単一銀行内の商用化と、複数銀行・通貨をつなぐ基盤の検証が並行して進んでいます。

出典： BIS Project Agorá Real-Value Testingの公表内容

9. オンチェーン化しても残る課題

法人間貸借の契約、移転価格（グループ会社間取引に適用する価格や金利などの条件）、税務、各国の資本規制、会計、社内権限は引き続き検討が必要です。同じ企業グループ内であっても、こうした制約により、資金を自由に集約できるとは限りません。

複数銀行へ広げる場合は、参加資格、顧客確認、異なる預金債務の決済方法、銀行間最終決済、障害時の責任を確認します。共通の画面や台帳を利用していても、資金移動が確定するタイミングまで一致するとは限りません。

24時間利用には、時間外の監視、制裁・不正取引の確認、資金不足時の扱い、手動承認への切替えが必要です。また、即時の資金移動を増やすと資金予約が増える場合もあり、待機資金が必ず減るとは限りません。ネッティングなどの既存方式と資金効率を比較します。

10. 業務にオンチェーンが必要か見極める

定時スイープや既存APIで目的を達成できる場合には、それを比較対象に置きます。複数タイムゾーン、高頻度の資金需要、トークン化資産との決済連携は検討の契機になりますが、それだけでオンチェーン採用が決まるわけではありません。

追加価値を評価する際には、関係者が同じ取引状態を参照できるか、条件判定と資金移動の間の不整合を減らせるか、照合や例外対応の負担を減らせるかを確認します。そのうえで、効果が接続・運用コストを上回る業務に適用します。

11. 検討を始めるならどこからか

まず、1通貨、2～3拠点、グループ内資金移動に対象を絞り、現行手順と比較します。残高確認、移動条件、法人間貸借、会計反映を一連の流れとして検証し、資金不足、重複指図、通信断、承認待ちも確認します。

効果は送金時間に加え、待機資金、手作業・照合の件数、貸借・会計への反映時間、例外処理と復旧の所要時間で測定します。外国為替取引や複数銀行への接続は、その業務上の必要性と対応サービスが確認できた段階で追加します。

12. 企業財務の業務全体で導入価値を測る

オンチェーン資金管理は、対象を絞った銀行サービスとして実用化が進み、複数銀行へ接続する検証も始まっています。導入を判断する際には、利用できる地域・通貨・時間帯に加え、どこまでの業務を完了できるのかを具体的に確認することが重要です。

資金を移す機能を、資金予測、承認、貸借、会計までつなげて初めて、企業財務における効果を測ることができます。既存のCMSと組み合わせながら、必要な場所に必要なタイミングで資金を配置する能力を高めることが、実装の目標になります。

金融トークナイゼーションの構想整理・既存のCMS・TMS・ERPとの接続、業務・システム両面からの実装検討に課題をお持ちの方は、TISIまでご相談ください。

＞金融トークナイゼーションについて相談する