【世界のオンチェーンプロジェクト File.021】 SWIFT Ledger Update
銀行ごとのトークン化預金は、本当につながり始めたのか
17行の「準備」から、HSBCとStandard Charteredによる最初のライブ銀行間取引へ
最終更新：2026年8月
2026年7月、SWIFTは大きな発表をしました。
ブロックチェーンベースの共有台帳、SWIFT Ledgerが初期利用可能な状態となり、MUFG、HSBC、Standard Chartered、Citi、BNP Paribas、DBS、UBSなど、世界6大陸の17行がトークン化預金を使ったライブ取引の準備に入ったのです。
このシリーズでは以前、SWIFT Ledgerについて、
預金は各銀行、状態同期は共有台帳、最終決済は既存レール
という構造で整理しました。
そして約6週間後。
2026年8月19日、次の段階へ進みました。
HSBCとStandard Charteredが、SWIFTのブロックチェーンベースの共有台帳を使い、銀行間で初となるライブのクロスボーダー・トークン化預金取引を実施しました。
これは一見すると、
「SWIFTのブロックチェーン上でトークン化預金が銀行間送金された」
というニュースに見えます。
しかし、実際の構造はもう少し興味深いものです。
HSBCの預金トークンが、そのままStandard Charteredへ移動したわけではありません。
SWIFTが銀行預金を発行したわけでもありません。
中央銀行マネーによる最終決済をSWIFT Ledger上で行ったわけでもありません。
今回実現したのは、
異なる銀行がそれぞれ管理するトークン化預金を、SWIFTが銀行間取引として同期した
ことです。
この違いに、SWIFTがオンチェーン金融で狙っているポジションが見えてきます。
Project Card
プロジェクト名
SWIFT Blockchain-based Ledger
今回のアップデート
初のライブ・クロスボーダー銀行間トークン化預金取引
実施銀行
HSBC
Standard Chartered
2026年7月時点のパイロット参加予定行
ANZ、BNP Paribas、BNY、Citi、DBS、First Abu Dhabi Bank、FirstRand Bank、HSBC、Itaú Unibanco、Lloyds Bank、Mashreq、MUFG Bank、OCBC、Standard Chartered、UBS、UOB、Wells Fargoの17行。
台帳技術
EVM互換、Hyperledger Besuベース
SWIFTの役割
銀行間の共通オーケストレーション、取引状態・支払義務の調整
預金の管理
各銀行
銀行間最終決済
既存決済システム
現在地
Initial controlled go-liveから、最初のライブ銀行間取引へ
7月のニュースは「利用可能になった」だった
まず7月9日の発表を振り返ります。
SWIFTは2025年9月、ブロックチェーンベースの共有台帳を自らの技術スタックへ追加すると発表しました。
その後、世界の金融機関と設計を進め、2026年3月にはDesign PhaseからMVP実装へ移行。
そして7月には、わずか約9か月でLedgerをinitial use readyの状態まで進めました。
日本からもMUFGが17行の一つとして参加しています。
ただし、7月時点では重要な留保がありました。
17行が「取引した」のではありません。
17行がライブ取引の準備に入った
という段階でした。
そして8月19日、初めて実際の銀行間取引が行われました。
HSBCとStandard Charteredは何をしたのか
今回の取引では、
HSBCのTokenised Deposit Service
と、
Standard Charteredのトークン化預金インフラ
という、別々の銀行が管理する二つのシステムが使われました。
概念的には、次のように整理できます。
Step 1｜銀行間で支払いメッセージを交換する
HSBCとStandard CharteredがSWIFT Ledgerを通じて支払いに必要なメッセージを交換します。
Step 2｜それぞれの銀行で預金債務を記録する
取引から生じる義務は、
HSBC Tokenised Deposit Service
Standard Charteredのトークン化預金基盤
それぞれに、トークン化預金の義務として記録されます。
Step 3｜SWIFT Ledgerが銀行間義務を同期する
SWIFT Ledgerは共通のオーケストレーション層として、
支払義務
相手銀行
金額
資金状態
取引状態
を調整します。
今回の取引では、SWIFTが銀行間の義務をmatch and netしたと説明されています。
Step 4｜最終決済は既存システムで行う
そして最後に、銀行間の最終決済を既存システムで行います。
ここが重要です。
SWIFT Ledger上の取引確定＝銀行間最終決済
ではありません。
7月のSWIFT自身の説明でも、Ledgerは銀行発行トークン化預金のオーケストレーション層であり、最終決済は既存システムを通じて完了すると明記されています。
「HSBCの預金トークンをStandard Charteredへ送った」のではない
トークン化預金を考えるとき、この区別は非常に重要です。
HSBCが発行する預金は、HSBCに対する預金債権です。
Standard Charteredが発行する預金は、Standard Charteredに対する預金債権です。
同じ通貨建てであっても、発行銀行が違えば法的な債務者が違います。
そのため、
HSBC Token → Standard Charteredの顧客
と、単純にトークンを送れば銀行振込が完成するわけではありません。
銀行間取引では、
HSBC側の預金状態
↓
HSBCとStandard Charteredの銀行間義務
↓
銀行間最終決済
↓
Standard Chartered側の預金状態
をつなぐ必要があります。
今回SWIFTが担ったのは、この真ん中の調整部分です。
これは、単なるBlockchain Bridgeとはかなり違います。
SWIFTは「トークン発行基盤」になろうとしていない
SWIFT Ledgerの設計は、既存の多くの金融DLT構想と少し違います。
SWIFT自身が、
預金を発行する
顧客残高を管理する
顧客ウォレットを提供する
銀行の鍵を保有する
銀行間決済資産を発行する
わけではありません。
2026年3月の設計説明では、銀行が自らの環境、鍵、資産、資金、決済を管理し、SWIFTがLedgerを運営して取引ワークフロー、Funding Commitment、銀行間プロセスを調整するとしています。
つまり、
Moneyは銀行に残す。
Controlも銀行に残す。
Shared StateだけをSWIFTが提供する。
という設計です。
これがSWIFT Ledgerの本質です。
なぜ「一つの共通トークン」にしないのか
複数銀行のトークン化預金を相互運用するなら、
全銀行が同じ共同トークンを使えばよい
とも考えられます。
しかし、それでは銀行預金の構造そのものを変える必要があります。
共同発行体を作るのか。
誰の負債になるのか。
預金保険はどうするのか。
利息は誰が払うのか。
顧客関係は誰が持つのか。
AML/CFT責任を誰が負うのか。
こうした問題が発生します。
SWIFT型では、その必要がありません。
HSBCの預金はHSBCに残す。
Standard Charteredの預金はStandard Charteredに残す。
CitiもMUFGもDBSも、自行の預金を自行で管理する。
そして、
銀行間で必要な支払状態だけを共有する。
これは、現在の二層型銀行制度を大きく変えずに、トークン化預金へ相互運用性を加える方法です。
Shared Ledgerだが、すべての「正本」を共有しているわけではない
「Shared Ledger」という名称から、
17行の預金残高が一つのブロックチェーンに集約される
と想像すると、実態から離れます。
SWIFT Ledgerが共有する中心は、銀行間取引の状態と義務です。
顧客預金の正本は銀行側。
トークン化預金も銀行側。
銀行間最終決済も既存システム側。
SWIFT Ledgerはその間に入り、
誰が誰にいくら支払うのか
資金は確保されたのか
両銀行は処理可能なのか
どの状態まで進んだのか
を同期します。
したがって、SWIFTのShared Ledgerは、
Shared Balance Sheet
ではなく、
Shared Transaction State
に近いと考えると分かりやすいでしょう。
なぜブロックチェーンを使うのか
ここで当然の疑問が出ます。
「SWIFTが中央DBを作ればよいのではないか」
今回の構造だけを見ると、そう考えることもできます。
しかし、参加銀行がそれぞれ、
自行のトークン化預金基盤
自行の鍵
自行の顧客残高
自行のコンプライアンス
自行の取引権限
を維持しながら、複数銀行で同じ取引状態を検証する場合、分散台帳の特徴が生きてきます。
特に、
複数主体による状態確認
スマートコントラクトによる処理ルール
取引順序の共有
改変困難な監査証跡
複数銀行システムとの非同期連携
との親和性があります。
SWIFTはMVPを、オープンソースのHyperledger Besuを基礎としたEVM互換アーキテクチャで構築しています。
ただし、
「ブロックチェーンだから今回の取引が実現した」
とまで言うのは早計です。
今後、中央DB型オーケストレーションに対してどれだけ運用・拡張性・ガバナンス上の優位を示せるかは、商用化の評価ポイントになります。
今回のニュースで何が「証明された」のか
今回のライブ取引は重要です。
しかし、証明されたことと、まだ証明されていないことを分ける必要があります。
今回示されたこと
異なる二つの銀行のトークン化預金基盤をSWIFT Ledgerで接続できる。
銀行間の支払義務を共通レイヤーで同期できる。
銀行自身が資産・鍵・顧客管理を維持できる。
最終決済を既存インフラへ残したまま、オンチェーン・オーケストレーションを追加できる。
これはかなり重要な成果です。
まだ証明されていないこと
一方で、公表情報では今回の、
金額
通貨
送金元・送金先の国
法人顧客の有無
End-to-End処理時間
流動性削減効果
手数料
ネッティング効果
大量取引時の性能
などは明らかになっていません。複数報道も、この点を未公表事項として指摘しています。
したがって、
「SWIFTがトークン化預金によるグローバル24/7決済を商用化した」
と表現するのは、まだ正確ではありません。
現時点では、
Controlled Go-live環境で、最初の銀行間ライブ取引が成立した
という段階です。
次に重要なのは17行の「多角形化」
今回の取引はHSBCとStandard Charteredの2行です。
二行間の相互運用が確認できたことは重要です。
しかし、ネットワークとして本当に価値が出るのは参加関係が増えたときです。
例えば、
HSBC ↔ Standard Chartered
だけではなく、
MUFG ↔ HSBC
DBS ↔ Citi
BNP Paribas ↔ MUFG
UOB ↔ Wells Fargo
という形で、銀行ごとのトークン化預金基盤が同じSWIFT Ledgerを介して接続されれば、二者間接続を個別構築する必要がなくなります。
17行なら、すべてを二者間接続する場合の組み合わせは136通りです。
SWIFTが共通レイヤーになれば、
N × Nの接続問題を、N × 1へ近づけられる。
これこそSWIFTが持つ最大の強みです。
ブロックチェーンそのものより、
11,500超の金融・証券機関へ接続する既存ネットワーク
の方が、参入障壁としてははるかに大きいかもしれません。SWIFTは200超の国・地域で11,500以上の金融・証券機関等を接続しています。
しかし最終決済問題は残っている
SWIFT Ledgerの構造で、最も重要な未解決問題がここです。
銀行間の最終決済は既存システムに残っています。
つまり、
Ledgerは24時間動く。
トークン化預金も24時間動く。
では中央銀行マネーによる銀行間決済は24時間動くのか。
という問題があります。
RTGSの営業時間外なら、
銀行間信用を一時的に認める
プレファンディングする
コルレス残高を利用する
別の決済資産を使う
決済開始までPendingにする
などの設計が必要になります。
SWIFTはLedgerが複数のSettlement Optionを支援できると説明しており、銀行はRTGS、コルレス関係、参加者間で合意した他の方法を利用できます。
つまり、SWIFT LedgerはSettlement Engineそのものではない。
ここが、AgoráやmBridgeとの大きな違いです。
Project Agoráとの違いが、さらに明確になった
Project Agoráでは、
商業銀行預金
中央銀行準備
多通貨
Payment Coordinator
を組み合わせ、中央銀行マネーを含めてアトミックに決済するモデルを検証しています。
一方、SWIFTは、
預金と決済資産を新しい共通基盤へ集約しない。
各銀行の預金は各銀行。
中央銀行マネーは既存RTGS。
その間の取引状態をSWIFTが同期する。
したがって両者は、
Agorá
Moneyを共通取引基盤へ近づける。
SWIFT
Moneyは今の場所に残し、Transaction Stateを共通化する。
という、異なるアーキテクチャです。
どちらが優れているかではなく、移行コストと統合度のトレードオフです。
Meridianとの共通点も見えてくる
Project File 20で扱ったProject Meridianは、
台帳を統合せず、取引を同期する
という発想でした。
SWIFT Ledgerも、それに近い思想を持っています。
ただしMeridianがSynchronisation Operatorという技術中立的な概念を検証したのに対し、SWIFTは、
世界的な金融機関ネットワーク
ISO 20022
BIC
コンプライアンス
既存銀行接続
実際のトークン化預金
を背景に、グローバルな銀行間オーケストレーションサービスとして実装し始めている。
ここに大きな違いがあります。
SWIFTは何になろうとしているのか
従来のSWIFTを一言で説明すると、
銀行間メッセージングネットワーク
でした。
SWIFT自身は資金を持たない。
口座を持たない。
決済もしない。
金融機関同士が安全に標準化されたメッセージを交換できるようにする。
この基本モデルは変わりません。
しかしLedgerが加わると、役割が一段深くなります。
これが今回のアップデートで最も重要な変化です。
それでもSWIFTは「巨大なUnified Ledger」を作らない
ここが今回のニュースから見える、さらに大きな示唆です。
オンチェーン金融では、
すべての資産とマネーを一つのUnified Ledgerへ載せる
構想があります。
しかしSWIFTは違います。
既存銀行台帳を残す。
既存RTGSを残す。
銀行ごとのトークン化預金基盤も残す。
それぞれの銀行が自分のペースでトークン化預金を実装し、SWIFTとの接続を加えればよい。
これは「最も美しいオンチェーン・アーキテクチャ」ではないかもしれません。
しかし、
既存の世界金融システムを実際に移行させるアーキテクチャ
としては、非常に現実的です。
Project File 03から何が変わったのか
Project File 03で整理した時点では、
預金は各銀行。
状態同期はSWIFT Ledger。
最終決済は既存レール。
という「設計」でした。
今回、その基本構造は変わっていません。
変わったのは、成熟度です。
2025年9月
構想発表。30超の金融機関と設計開始。
↓
2026年3月
Design Phase完了。Hyperledger BesuベースでMVP実装へ。
↓
2026年7月9日
LedgerがInitial Use Ready。17行がライブ取引準備へ。
↓
2026年8月19日
HSBCとStandard Charteredが初のライブ銀行間トークン化預金取引を実施。
約1年で、
Concept → Design → MVP → Controlled Go-live → First Live Transaction
まで進みました。
このスピードは注目に値します。
次に見るべき5つのポイント
ここから先、SWIFT Ledgerの評価で見るべきなのは次の5点です。
第一に、17行のうち何行が本当にライブ接続するか。
第二に、複数通貨・複数法域へ広がるか。
第三に、銀行間最終決済を24時間どう成立させるか。
第四に、二行間取引からマルチバンク・ネッティングへ進めるか。
第五に、トークン化預金以外へ広がるか。
SWIFT自身は今後、Programmable Corporate Payments、FX PvP、証券取引のCash MovementなどへLedgerを拡張できるとしています。
7月の発表では、Programmable MoneyやAgentic Commerceも将来的な方向として挙げています。
そうなればSWIFT Ledgerは、単なるトークン化預金送金ネットワークではありません。
銀行、企業、証券、FX、AIエージェントの取引状態を同期するグローバル金融オーケストレーション層
へ発展する可能性があります。
SWIFT Ledger Updateが示したこと
今回のニュースの価値は、
「ブロックチェーンで銀行送金ができた」
ことではありません。
銀行間送金自体は、既存システムですでにできます。
重要なのは、
異なる銀行が、それぞれ別々に発行・管理するトークン化預金を、一つの共通トークンへ統合せずに相互運用できることをライブ取引で示し始めた
ことです。
しかもSWIFTは、
預金の正本を取りにいかない。
顧客を取りにいかない。
中央銀行マネーを発行しない。
銀行の鍵を管理しない。
既存RTGSを捨てない。
SWIFTが取りにいくのは、
銀行と銀行の間にある「取引状態」
です。
Project File 03で見えていた構想が、Project File 21で最初の実取引になりました。
タイトルの問いへの答えは、現時点ではこうなります。
銀行ごとのトークン化預金は、つながり始めた。
ただし、つながったのは預金残高そのものではない。
SWIFTが共有したのは、銀行間の支払義務と取引状態である。
そして、この設計が17行、数十行、数百行へ拡大したとき、
SWIFTは「メッセージを運ぶネットワーク」から、
世界の銀行マネーを同期するShared State Network
へ変わる可能性があります。
ここが、今回のアップデートの本当の意味だと考えます。
主な参照資料
SWIFT, Swift’s blockchain ledger ready for use as 17 banks set to pioneer tokenised cross-border payments on trusted global infrastructure, 9 July 2026.
SWIFT, Swift’s blockchain-based shared ledger progresses to MVP implementation, 30 March 2026.
Standard Chartered / HSBC, First live tokenised deposit transaction on SWIFT’s blockchain-based ledger, 19 August 2026.
いいなと思ったら応援しよう！
この記事が参加している募集
この記事は noteマネー にピックアップされました
