【世界のオンチェーンプロジェクト File.003】Swift Ledger
預金は各銀行、状態同期は共有台帳、最終決済は既存レール
最終更新：2026年8月
Swiftと聞いて、多くの人が思い浮かべるのは、銀行間で送金メッセージを交換するためのネットワークです。
Swift自身がお金を発行するわけでも、顧客の口座を管理するわけでもありません。銀行から銀行へ、標準化された金融メッセージを安全に伝えることが、これまでの中心的な役割でした。
そのSwiftが、ブロックチェーン型の共有台帳を自らのインフラへ追加しました。
2026年7月、Swiftは新しい台帳が初期利用可能な状態になり、世界6大陸の17銀行が、トークン化預金を使った実取引パイロットの準備に入ったと発表しました。日本からはMUFG銀行が参加しています。
「あのSwiftがブロックチェーンを採用した」というニュースだけを見ると、既存の国際送金網をブロックチェーンへ置き換える計画のようにも見えます。
しかし、実際の構造は違います。
Swift Ledgerが目指しているのは、
預金は各銀行が管理し、銀行間の支払状態は共有台帳で同期し、最終決済は既存システムで行う
という、既存金融とオンチェーン金融の接続モデルです。
Project Card
プロジェクト名
Swift blockchain-based shared ledger
本稿では「Swift Ledger」と表記
運営主体
Swift
発表時期
2025年9月に構想を発表
2026年7月に初期利用可能な状態へ移行
初期ユースケース
トークン化預金を使った24時間365日のクロスボーダー銀行間決済
対象顧客
法人・機関顧客を中心とする資金管理、クロスボーダー決済
台帳技術
Hyperledger Besuを基礎とするEVM互換アーキテクチャ
Swiftの役割
銀行間支払コミットメントの記録・検証・同期、取引ワークフローのオーケストレーション
銀行の役割
自行の預金、台帳、鍵、資金、コンプライアンス、最終決済を管理
現在の段階
17銀行による管理された実取引パイロットの準備段階
Swiftは2025年9月、30を超える金融機関と共同で、ブロックチェーン型共有台帳をインフラへ追加すると発表しました。その後、設計、MVP（実用最小限の製品）の構築を進め、約9か月で初期利用可能な状態へ移行しています。
Swiftは、なぜ共有台帳を必要としたのか
現在のクロスボーダー決済では、送金銀行、中継銀行、受取銀行が、それぞれ自分の帳簿とシステムを管理しています。
送金指図はSwiftなどを通じて伝えられますが、各銀行が見ている取引状態は必ずしも同じではありません。
例えば、一つの送金でも、
顧客から資金を受け付けた
コンプライアンス確認が終わった
中継銀行へ指図を送った
必要な資金を確保した
受取銀行が指図を受け付けた
銀行間で最終決済された
受取人が資金を利用可能になった
という複数の状態があります。
各銀行がそれぞれのシステムで状態を管理すると、確認、照会、再送、照合が必要になります。
また、夜間や休日に顧客間の送金指図を処理できても、銀行間決済システムが動いていなければ、すべてをその場で完了できるとは限りません。
Swift Ledgerが解こうとしているのは、この銀行間の状態共有と処理の同期です。
参加銀行が同じ銀行間支払コミットメントを確認できれば、
どの銀行が支払いを約束したか
必要な資金が確保されているか
取引がどの段階にあるか
相手銀行が処理を受け入れたか
最終決済が未了か完了済みか
を共通の状態として扱えます。
Swiftは、この共有台帳を「銀行間コミットメントについて、信頼できる共通ビューを提供する仕組み」と説明しています。
Swift Ledgerの構造
Swift Ledgerは、すべての銀行預金を一つの台帳へ集約する仕組みではありません。
構造は、大きく三つの層に分かれます。
第1層｜各銀行の預金台帳
顧客の預金とトークン化預金は、各銀行が自らの環境で管理します。
A銀行のトークン化預金は、A銀行に対する預金債権です。B銀行のトークン化預金は、B銀行に対する預金債権です。
どちらも同じ通貨建てであっても、法的な債務者は異なります。
Swiftが共通の預金トークンを発行するわけではありません。
Swiftの公式説明でも、トークン化預金は各参加銀行自身の台帳上にあり、銀行は鍵、資産、資金、決済に対する権限を維持するとされています。
第2層｜Swiftの共有台帳
Swift Ledgerが記録する中心的な対象は、銀行間の支払コミットメントです。
コミットメントとは、簡単に言えば、
A銀行がB銀行に対して、一定額を支払うための資金と処理条件を確保した
という銀行間の約束です。
Swiftは共有台帳上で、
支払コミットメントの記録
必要資金の確認
取引状態の検証
参加銀行間の状態同期
ワークフローの調整
を行います。
したがって、Swift Ledgerは預金そのものの正本というより、銀行別に管理される預金を銀行間取引として同期するオーケストレーション層です。
オーケストレーションとは、複数システムの処理順序と状態を調整することです。
第3層｜既存の銀行間決済
銀行間の最終決済は、既存の仕組みを利用します。
Swiftは、最終決済の選択肢として、
RTGS（即時グロス決済システム）
コルレス銀行関係
参加銀行間で合意したその他の決済方式
を挙げています。
つまり、共有台帳があるからといって、中央銀行当座預金やコルレス口座が直ちに不要になるわけではありません。
むしろSwift Ledgerは、
既存の銀行間決済が動く前後の処理を、24時間共有・同期できるようにする
仕組みです。
一つの取引は、どのように流れるのか
Swiftが公表している情報から概念的な取引フローを組み立てると、次のようになります。
Step 1｜送金銀行が顧客の支払いを受け付ける
A銀行の顧客Xが、B銀行の顧客Yへ送金を依頼します。
A銀行は、
顧客本人
受取人
送金目的
制裁・AML情報
残高
取引限度額
などを確認します。
Step 2｜A銀行が資金を確保する
A銀行は、自行の台帳で顧客Xの資金をロック、予約、または利用不能な状態にします。
これにより、同じ資金が別の取引へ二重に利用されることを防ぎます。
Step 3｜銀行間コミットメントを共有台帳へ記録する
A銀行は、B銀行に対する支払コミットメントをSwift Ledgerへ記録します。
Swift Ledgerは、そのコミットメントが必要な条件を満たしているかを検証し、参加銀行へ共通の取引状態を提供します。
Step 4｜B銀行が取引を受け入れる
B銀行は、受取人情報、コンプライアンス条件、取引内容を確認し、受入可能であることを共有台帳へ反映します。
これにより、A銀行とB銀行は同じ取引状態を確認できます。
Step 5｜顧客向けの資金移動を実行する
条件が満たされれば、A銀行側のトークン化預金を減額し、B銀行側で顧客Yの預金またはトークン化預金を増額する処理が行われます。
Swiftは、この仕組みにより、夜間や休日を含め、顧客向け資金移動を24時間365日実行できると説明しています。
Step 6｜銀行間で最終決済する
A銀行とB銀行の間に生じた銀行間債権・債務は、RTGS、コルレス口座、その他の合意された仕組みを使って最終決済されます。
ただし、公表資料だけでは、
顧客Yが資金を利用可能になる正確な時点
銀行間決済までの最大時間
グロス決済かネッティングか
決済未了時の与信枠
参加銀行破綻時の損失分担
顧客向け記帳の法的ファイナリティ
までは明らかになっていません。
以上の取引フローは、Swiftが公表した構造に基づく概念整理であり、実際のパイロットの詳細な業務規約ではありません。
トークン化預金は、銀行をまたいでそのまま動くのか
ここは、Swift Ledgerを理解するうえで重要なポイントです。
A銀行の顧客が持つA銀行のトークン化預金を、そのままB銀行の顧客へ渡す構造であれば、B銀行の顧客はA銀行に対する預金債権を持つことになります。
一方、A銀行のトークン化預金を減額し、B銀行のトークン化預金を新たに発生させる構造であれば、受取人はB銀行に対する預金債権を持ちます。
Swiftの公表資料は「銀行発行のトークン化預金を各銀行自身の台帳上で扱う」と説明しています。
このため、本稿では後者、すなわち、
各銀行の預金債権を維持したまま、銀行間コミットメントによって減額と増額を同期する構造
が中心になると推察します。
ただし、法的な債権移転、顧客約款、銀行間決済義務の成立時点を含む完全な法律構成は、現時点の公開資料だけでは確定できません。
なぜブロックチェーンを使うのか
銀行間の状態共有だけであれば、従来型の中央データベースでも実装できるように見えます。
Swift Ledgerがブロックチェーンを採用した理由として考えられるのは、次の点です。
複数銀行による状態共有
一つの銀行が他行の台帳を管理するのではなく、参加銀行が共通ルールの下で同じ状態を検証できます。
改ざん耐性と監査証跡
銀行間コミットメントと状態変更の履歴を、連続した検証可能な記録として残せます。
プログラマビリティ
将来的には、
条件付き企業間決済
FXのPvP
証券取引に伴う資金移動
プログラマブルマネー
AIエージェントによる支払い
などへ処理を拡張できます。Swiftも、企業決済、FX PvP、証券取引の資金レッグ、エージェンティックコマースを将来の応用候補として挙げています。
既存・新規ネットワークとの相互運用
EVM互換のHyperledger Besuを使うことで、外部のデジタル資産基盤やスマートコントラクトとの接続可能性を確保しています。
ただし、EVMを採用したこと自体が、このプロジェクトの本質ではありません。
重要なのは、Swiftがブロックチェーンを金融機関間の共通状態管理へ組み込み、既存の世界的ネットワークと接続したことです。
17銀行が参加する意味
初期の実取引パイロットには、次の17銀行が参加します。
ANZ、BNP Paribas、BNY、Citi、DBS、First Abu Dhabi Bank、FirstRand Bank、HSBC、Itaú Unibanco、Lloyds Bank、Mashreq、MUFG銀行、OCBC、Standard Chartered、UBS、UOB、Wells Fargoです。
この参加銀行には、
自行のトークン化預金サービスを持つ銀行
グローバルなコルレス銀行網を持つ銀行
アジア・中東・アフリカ・欧米の地域銀行
カストディや証券決済に強い銀行
が含まれています。
特にHSBCは、自行のTokenised Deposit ServiceをSwift Ledgerへ接続すると明言しています。MUFG銀行も、トークン化預金とDLTを既存金融エコシステムへ安全かつ拡張可能な形で統合するユースケースを評価するとしています。
ただし、2026年8月時点で17銀行が本格商用稼働しているわけではありません。
現在は、初期利用可能な台帳を使い、管理された環境で実取引を開始する準備段階です。
「17銀行による商用サービスが開始された」ではなく、
17銀行がライブ取引パイロットへ進む段階に入った
という表現が正確です。
Swift Ledgerの独自性
Swift Ledgerの特徴は、すべてを新しい共通基盤へ移そうとしないことです。
顧客関係は各銀行に残す
預金債権は各銀行に残す
鍵と資産管理は各銀行に残す
コンプライアンスも各銀行が担う
最終決済には既存システムも使う
銀行間のコミットメントと状態だけを共有する
この構造は、銀行の既存システムや法的役割を維持しながら、24時間365日の処理を実現しようとするものです。
言い換えると、Swift Ledgerは銀行預金を一つの共通マネーへ統合するのではなく、
異なる銀行預金を、共通の状態管理によって交換可能にする
構想です。
Swift Ledgerが解かなければならない問題
1．顧客向け完了と銀行間最終決済の時間差
顧客Yが資金を利用できるようになった後で銀行間決済が行われるなら、B銀行は一時的にA銀行に対する信用リスクを負います。
必要になるのは、
参加銀行別の与信枠
プレファンディング
担保
ネッティング
決済期限
自動停止条件
です。
「資金確保済みコミットメント」が、どの程度このリスクを抑えるのかが重要になります。
2．24時間365日の流動性
顧客向け取引が休日も動くなら、銀行の流動性管理も休日対応が必要です。
一方、中央銀行のRTGSやコルレス口座が同じ時間帯に動いていなければ、未決済ポジションが蓄積する可能性があります。
24時間決済の本当の難所は、台帳の稼働時間ではなく、銀行間流動性です。
3．法的ファイナリティ
共有台帳上で「完了」と表示された時点と、法律上の銀行間決済完了時点が一致するとは限りません。
コミットメントが取消不能になる時点
受取人の預金債権が成立する時点
銀行破綻時にも取引が保護される時点
を参加国・参加銀行間で揃える必要があります。
4．銀行ごとに異なるトークン化預金
トークン化預金のデータ形式、状態、発行・償還方法、凍結・取消し機能が銀行ごとに異なれば、共有台帳だけでは相互運用できません。
銀行側台帳とSwift Ledgerを接続する共通API、状態モデル、取引識別子、例外処理が必要です。
5．既存システムとの二重管理
銀行は当面、
勘定系
トークン化預金台帳
Swift Ledger
RTGS・コルレス口座
会計・AMLシステム
を並行して管理します。
オンチェーン化によって照合が減る一方、新旧システム間の整合管理が増える可能性もあります。
日本から見るべき三つのポイント
1．銀行側の制御基盤が必要になる
Swift Ledgerへ接続するだけでは、自行の預金をトークン化できません。
銀行側には、
預金の資金確保
トークン化預金の発行・償還
顧客・ウォレット管理
取引状態管理
Swift Ledgerとの同期
勘定系との照合
障害時の補償処理
を担う制御基盤が必要です。
Swift Ledgerは銀行側システムを不要にするのではなく、銀行側に標準化された接続点を求めます。
2．全銀行が同じトークン基盤を使う必要はない
各銀行が自行の台帳と預金管理を維持したまま、共通のネットワーク層で銀行間状態を同期できます。
これは、各銀行が異なるトークン化基盤を採用する可能性がある日本にとって、現実的な構成です。
3．新しい決済網は、既存インフラとの接続が前提になる
Swiftは、既存レールを廃止して新しい台帳へ全面移行するのではなく、両者を接続しています。
日本でも、トークン化預金、次世代決済システム、日銀当座預金、既存勘定系を、一度に一つの基盤へ統合する必要はありません。
どの処理をオンチェーン化し、どの最終決済を既存インフラへ残すかを分けて設計できます。
Project Agoráとの違い
Swift Ledgerの次にProject Agoráを見ると、二つの設計思想の違いが明確になります。
Swift Ledgerでは、
預金は各銀行の台帳に置く
銀行間コミットメントを共有台帳で同期する
最終決済には既存システムを使う
という構成です。
一方、Project Agoráは、
トークン化商業銀行預金
トークン化中央銀行準備
多通貨取引
コンプライアンス処理
を共有プログラマブル基盤上で組み合わせ、取引全体をアトミックに決済するプロトタイプです。アトミック決済とは、関連するすべての処理を「全部成立するか、全部成立しないか」で実行する方式です。
整理すると、
Swiftは、現在の銀行システムを共有台帳でつなぐ。
Agoráは、銀行預金と中央銀行マネーを共通のプログラマブル取引へ組み直す。
という違いがあります。
どちらか一方だけが正解なのではありません。
Swift型は既存システムを活用しながら早く拡張しやすい一方、銀行間最終決済との時間差が残ります。
Agorá型はアトミックな多通貨決済を実現できますが、中央銀行を含む制度・運用・基盤の変更範囲が大きくなります。
Swift Ledgerが示したこと
Swift Ledgerの最大の意味は、Swiftがブロックチェーンを採用したことではありません。
重要なのは、
グローバルな銀行間ネットワークにおけるブロックチェーンの役割を、資産の発行ではなく、銀行間コミットメントの共有と状態同期に置いたこと
です。
この構造では、銀行は預金、顧客、鍵、資金、コンプライアンスに対する主権を維持します。
Swiftは、その銀行同士をつなぐ共通のオーケストレーション層になります。
これは、オンチェーン金融が既存金融を全面的に置き換えるのではなく、
既存金融の境界部分に、共有状態とプログラマビリティを追加する
方向へ進んでいることを示しています。
次回のProject Fileでは、もう一つの銀行間決済モデルであるProject Agoráを取り上げます。
なぜ商業銀行預金だけでなく、中央銀行準備までトークン化するのか。
Swift型では残る銀行間最終決済の時間差を、Agoráはどのようにアトミック決済へ変えたのか。
両者の違いから、オンチェーン金融における銀行間決済の二つの到達点を読み解きます。
