1. 概要
1.1 SwiftとSwift ledger
Swiftは、世界の銀行が送金の指図（電文）を安全に送り合うためのネットワークだ。Swiftが届けるのは「誰に、いくら払ってほしいか」という指図であり、資金そのものはコルレス口座やRTGSを通って別の経路で動く。
Swiftはこれまでも、送金の指図を届け、その進み具合を追跡する機能を提供してきた。そこに銀行間の支払い義務を記録し、確かめるための台帳を加える。それがSwift ledgerだ。
| Swiftの機能 | 共有・処理する情報 | 銀行間債務との関係 |
|---|---|---|
| Swift gpi | 送金経路、処理状況、着金確認 | 送金の進捗を追跡する |
| Transaction Manager | 関係銀行が参照する共通の取引データ | 取引情報の整合性を維持する |
| Swift ledger | 銀行間の支払コミットメント・債務の状態 | 資金手当てに関するコミットメントを検証し、債務の記録・照合・相殺・決済調整を行う |
Swift ledgerの価値は、受取銀行が、送金元の銀行の支払い義務と、その支払いに必要な資金が確保されていることを、共通の台帳で確かめられる点にある。そのため受取銀行は、銀行間の最終決済を待たずに顧客へ入金しやすくなり、銀行が閉じている夜間や週末でも送金を進められる。
1.2 トークン化預金とSwift ledger
トークン化預金（Tokenised Deposit、以下TD）は、銀行の預金債務をブロックチェーン上で表現し、記録・移転する仕組みだ。預金の発行主体が銀行であること、顧客がその銀行に対する請求権を持つことは変わらない。変わるのは、預金を記録し、動かすための技術である。
銀行間のTD送金のルールは一意に定まっていない。口座関係、顧客確認、台帳、参加ルールが銀行ごとに異なるため、銀行間の決済をして良いか判別する必要がある。
この銀行間決済の問題の解決を目指すのが、Swift ledgerだ。ただし、Swiftが運営する台帳に「A銀行はB銀行へ100ドル支払う義務がある」と記録しても、それだけでB銀行に100ドルの決済資金が移ったわけではない。「銀行間債務の記録」と「銀行間債務を実際に支払って消すこと」は、別の処理だからだ。
まず、3つの異なる「記録」を区別する
A銀行の顧客XからB銀行の顧客Yへ100ドルを送るケースで考える。ここには、少なくとも3種類の異なる記録が関係する。
| 記録するもの | 何を表すか | 誰の管理・権限か |
|---|---|---|
| 顧客の預金・TD | XがA銀行に持つ預金債権、YがB銀行に持つ預金債権 | 各銀行：自行の口座・TD台帳を管理 |
| 銀行間債務 | 顧客間送金の結果、A銀行がB銀行へいくら支払う必要があるか | Swift ledger：参加行間で共通の記録を維持・検証 |
| 銀行の決済用預金残高 | 中央銀行当座預金やコルレス口座で、銀行同士の支払いを実行する資金 | 銀行・決済システム：銀行が決済を指図し、RTGS運営者やコルレス銀行が該当口座を更新 |
記録の流れは以下のようになる。
1.3 解消する課題：24時間の銀行間送金と、既存のレールを置き換えない設計
国際送金には、営業時間と時差、RTGSの稼働時間、コルレス口座の流動性管理、銀行ごとの照合作業などの制約がある。各行のTDが24時間動いても、銀行間で支払いの状態と資金手当て（銀行間の支払いに必要な資金の確保）を確認できなければ、顧客への送金を常時提供しにくい。
従来の国際送金の一つであるカバー方式では、送金指図と決済資金が別の経路で動く。そのため受取銀行は、資金の到着を待つか、未決済のリスクを負って先に顧客へ入金するかを選ぶ必要があった（2.1で詳しく扱う）。
TDに置き換えても、この銀行間債務の問題は残る。 A銀行のTD台帳で送金処理が進んでも、それだけではB銀行への最終決済が済んだことにならない。
これまでも、銀行自身がコルレス口座の残高や与信枠、決済資金を管理し、コルレス銀行や決済システムが資金を動かしてきた。Swift ledgerが加えるのは、資金手当ての管理そのものではない。TDを使う銀行間送金について「どの債務が発生し、どの支払いについて資金が手当てされたと確認でき、どこまで処理が進んだか」を、参加銀行が共通のルールで検証・調整する層である。Swiftはこの層を、自社の基盤の新しい層として追加する。銀行にとっては、資金の可視性、照合負荷、流動性の効率の改善が期待される。
2. Swift ledgerを用いた国際送金フローの図示
2.1 Swift ledger以前の国際送金：コルレスのカバー方式
従来方式の一例としてカバー方式を考える。送金銀行A、受取銀行B、カバー資金を扱うコルレス銀行を想定する。
カバー方式では、顧客送金の電文が受取銀行へ届く一方、銀行間の決済資金はコルレス銀行などを通る別の経路で動く。受取銀行は電文を受信しても、まだ資金を受け取っていないことがある。
B銀行が資金到着を待てば、その分だけ顧客は入金を待つ。B銀行が先に入金すれば、カバー資金を受け取るまでのリスクをB銀行が負う。先行入金自体はSwift ledgerが登場する前から可能だった。ただし、リスクが伴っていた。これはSwiftが公開するPMPG（Payments Market Practice Group）の市場実務ガイドラインでも、受取銀行が資金到着を待つ場合と先に入金する場合に分けて説明されている。
2.2 Swift ledger以後の国際送金：顧客間送金を先にするための工夫
Swift ledgerでは、TDによる支払いで生じた銀行間債務を共通台帳に記録・検証し、資金手当てに関するコミットメントを確認する。検証が終わると受取銀行に通知し、受取銀行は銀行間の最終決済に先立って顧客へ入金できる。
従来との違いは、受取銀行が先行入金できるようになったこと自体ではない。 従来、B銀行は送金指図を受け取っても、A銀行から決済資金が届くかどうかを確認できず、相手銀行との取り決めや与信判断に基づいて先に顧客へ入金していた。Swift ledgerでは、相手銀行の支払い義務と資金手当てのコミットメントが共通台帳で検証されるため、B銀行はその結果を確認したうえで入金を進められる。
3. Swift ledgerと既存システムとの接続
TDを扱う銀行のサービスからSwift ledgerを利用するには、台帳が何を記録するのか、何を検証してから受取銀行へ通知するのか、銀行側はどのタイミングで読み書きするのかを理解する必要がある。
Swiftはスマートコントラクトで取引を記録・検証する方針を公表している。ただし、2026年11月時点で、Swift ledgerに接続するための具体的な仕様は一般公開を確認できない。以下ではSwift・参加行・RBAが公表した動作と、接続ベンダーが説明する実装方式を分けて扱う。
3.1 Swift ledgerが保存・管理するデータ
Swiftは、銀行同士が何を支払う義務を負っているか、資金手当てされた支払いがどのような状態にあるかを、関係する銀行が確認できる仕組みだと説明している。
| 対象 | Swift ledgerでの役割 |
|---|---|
| 銀行間の支払コミットメント・債務 | ある銀行が別の銀行へ支払う義務を記録・検証する |
| 資金手当てされた支払コミットメント | 支払いに資金の裏付けがあることを検証し、関係者が確認できるようにする |
| 支払いの状態（payment state） | 銀行間で取引の進捗について共通の状態を参照できるようにする |
3.2 コミットメントとは何か、何を検証するのか
ここでいう支払コミットメント（payment commitment）とは、銀行間送金に伴って、送金銀行が受取銀行へ支払うという約束を指すと整理できる。
何を検証するのか
検証の具体的な条件は明らかになっていない。 例えば、銀行のTDをロックするのか、通常預金の残高を拘束するのか、決済口座の資金を確認するのか、与信枠や署名をどう使うのかは分からない。
3.3 既存のTDサービスからSwift ledgerをどう読み書きするのか
RBAが示したSwiftの処理モデル（2.2の図）とSwift自身の説明を「銀行からの書き込み・読み取り」という観点で整理すると、次のようになる。
| タイミング | 銀行側操作 | Swift ledger側操作 |
|---|---|---|
| 送金の実行時 | 書き込み：銀行間債務・支払コミットメントを記録する | 送金に伴う銀行間債務が共有台帳に記録される |
| 検証完了後 | 読み取り・受信：検証結果を受け取る | Swift ledgerが受取銀行へ通知し、受取銀行が入金処理を進める |
| 処理の途中 | 状態参照：支払コミットメントと取引状態を確認する | 関係する銀行間で共通の状態を参照できる |
| 後続の最終決済時・決済後 | 決済指示の受信・状態更新 | Swiftが銀行へ純額決済の指示を調整。決済確認後、債務が解消される |
接続方式：EVMのJSON-RPCを使う場合
確認できていることは、Swift ledgerがHyperledger Besuを基盤とするEVM互換の共有台帳であり、スマートコントラクトによって取引を記録・検証すること、そして銀行が自行の鍵を管理することだ。
この構成から考えると、銀行がアクセスできるBesuノードのEthereum JSON-RPCを通じて、Swift ledger上のスマートコントラクトを操作する方式が自然な候補になる。一般的なEVMの操作であれば、銀行が署名したトランザクションをeth_sendRawTransactionで送信し、eth_callで状態を読み取り、eth_getLogsでイベントを取得できる。
ただし、これはEVMの一般的な操作例であり、Swift ledgerの接続仕様として確認されたものではない。銀行に提供されるRPCエンドポイント、アクセス権限、対象コントラクトのアドレス・ABI、呼び出す関数と引数は公表されていない。銀行側のTD環境にSwift用のコミットメント・コントラクトを配置し、イベントで状態を同期する方式はOracleが説明しているが、銀行側コントラクトとSwift ledger側コントラクトの具体的な呼び出し関係は未確認だ。
4. 今後の展望
4.1 日本の銀行・企業にとってのメリット
日本の銀行・企業にとっての効果は、送金してから受取人が資金を使えるまでの日数が縮むことだと筆者は考える。
国際送金では、送金を指図した日（T）から受取人が資金を使えるまでにN日かかる（T+N）。従来は、送金元や受取側の銀行、間に入るコルレス銀行の営業時間外、時差、週末・祝日をまたぐと、このNが伸びていた。たとえば金曜の夕方に日本から送金すると、相手国の銀行が週明けに処理するまで、受取人が資金を使えないことがある。
Swift ledgerでは、受取銀行が夜間や週末でも先に顧客へ入金しやすくなるため、このNが縮む。日本の企業にとっては、送った資金や受け取る資金が使えるようになるまでの日数が短くなり、その間に使えないまま置いておく資金を減らせる。資金をより短い周期で回せるようになり、資金効率が上がる点が大きなメリットになる。
4.2 今後のマイルストーン
Swiftのイノベーション責任者Nick Kerigan氏は、2026年11月6日に公開されたインタビュー記事で、Sibos 2026時点では13行が5通貨・8市場でSwift ledgerを利用しており、2026年末までにさらに6行が稼働する予定だと説明している。計画どおり進めば19行となる。
その後もSwiftは、台帳の機能と利用範囲の段階的な拡張を計画している。TD以外のオンチェーン決済資産やプログラマブルな支払いへの展開も検討しているが、これらの具体的な提供時期は公表されていない。
4.3 普及に向けた論点
この仕組みが多くの銀行で使われるまでには、次の3つの論点が残る。
① 各銀行がTD基盤を準備する必要がある
Swift ledgerは、銀行に代わって顧客のTDを発行・管理する基盤ではない。接続製品を提供するTaurusの共同創業者Lamine Brahimi氏は2026年10月、参加銀行が自行の許可型台帳、ウォレット、トークン化・スマートコントラクト機能を用意する必要があると説明している。既にTDを扱う銀行と、まだ扱っていない銀行では参加までの負担が異なる。
② 顧客への入金と銀行間の最終決済が分離している
Swift ledgerで銀行間債務を記録・検証できても、その時点で銀行間の最終決済が完了するわけではない。受取銀行が顧客へ先に入金し、RTGSやコルレスなど既存の経路で最終決済を後から行う設計である。この違いはDecryptもSwift ledgerの制約として取り上げている。
したがって、送金を24時間処理できても、銀行間の決済資金を24時間、同じタイミングで移動できることまでは保証されない。受取銀行にとっては、最終決済までの未決済債権の管理が残る。
③ 資金手当ての検証で、どこまで信用リスクを抑えられるか
Swiftは、台帳が支払コミットメントと資金手当てを検証すると説明している。一方、資金をどのように拘束・保証するか、決済不能になった場合に誰が損失を負担するかについて、一般公開された共通仕様だけでは確定できない。
これは「Swift ledgerに信用リスク低減効果がない」という意味ではない。受取銀行のリスクがどの条件で解消されるかを、参加条件や契約で確認する必要がある、という論点だ。