Project Agorá（プロジェクト・アゴラ）は、銀行や企業が行う国際決済の改善を検証するプロジェクトです。トークン化した商業銀行預金と中央銀行マネーを、共通のプログラム可能な基盤で扱います。
たとえば日本の企業が海外の取引先へ代金を送るとき、送金は複数の銀行を経由することがあります。銀行ごとの確認や営業時間の違いが重なると、相手の口座に反映されるまで数日かかる場合もあります。その間、企業からは「今どの銀行で止まっているのか」「相手はいつ資金を使えるのか」が見えにくいこともあります。Agoráが改善しようとしているのは、こうした一件の送金の遅さと見通しの悪さです。
このプロジェクトを主導するBIS（国際決済銀行）は、63の中央銀行が出資し、中央銀行同士の協力を支える「中央銀行のための銀行」です。Agoráには日本銀行を含む8つの中央銀行と40超の金融機関が参加し、顧客が使う銀行預金だけでなく、銀行同士の決済に使う中央銀行マネーまで組み合わせて検証しています。この参加範囲と検証対象の広さから、本記事ではAgoráを本命級のプロジェクトとして取り上げます。これは筆者の評価であり、商用化や普及を保証するものではありません。
2026年7月には、実際の資金を使うテストまで進みました。現在は追加検証の段階です。この記事では、円で払いドルで受け取る一件の送金を通して、Agoráが何を変えようとしているのか、どう動くのか、日本の取組みとどこでつながるのかを見ていきます。
目次
- 国際送金の資金構造｜顧客預金と銀行間決済の対応
- Agoráの送金処理｜確認・資金ロック・決済の5段階
- 預金のトークン化｜複数行の残高と支払条件の一体化
- Agoráの台帳構成｜共通台帳と法域別台帳の連携
- 実用化までの距離｜実価値テストの成果と残る接続作業
- 日本の取組み｜日銀のDLT連携サンドボックス構成案
- 実運用の条件｜決済完了・運営責任・費用対効果
- アナリストコメント
- 付録｜Besu・Paladin・Kaleidoの役割
1. 国際送金の資金構造｜顧客預金と銀行間決済の対応
まず、顧客が銀行に持つ預金と、銀行が銀行間の決済に使う資金の違いを説明します。
支払企業が銀行Aに持つ預金は、支払企業から見ればAに支払いを求められる権利で、Aから見れば支払企業に対する債務です。預金をトークンとして記録しても変わりません。
支払企業が同じ銀行Aの顧客へ払うなら、Aは二人の預金残高を振り替えられます。相手が銀行Bを使う受取企業なら、受取企業が受け取るのはBの預金です。Bが新しく負う預金債務に対応させて、銀行同士でも資金を受け渡す必要があります。
まず、同一通貨の支払いを単純化すると、次の関係になります。
支払企業の預金を減少させ、受取企業の預金を増加させる処理に、銀行間の決済を対応させます。この決済のために、銀行が中央銀行に持つ資金を使う構成です。以下では、その資金を「中央銀行マネー」と呼びます。
商業銀行は顧客の預金を扱い、中央銀行は銀行間の決済資金を提供します。Agoráは、この二層構造を保ちながら、両方の処理をプログラムで結び付けようとしています。預金の発行者は各銀行、中央銀行マネーの発行者は各中央銀行です。民間側の取りまとめにはIIF（国際金融協会）が参加しています。
円で払い、ドルで受け取る場合
ここからは、海外送金の場合を考えます。日本の支払企業が、米国の受取企業へ1万ドルを支払うとします。支払企業は銀行Aの円預金、受取企業は銀行Dのドル預金を使います。
間に入るのは一つの為替事業者です。この事業者が、銀行Bに円預金、銀行Cにドル預金を持っています。説明を簡単にするため、1ドル＝150円、手数料なしとします。円とドルの支払いを結び付ける仕組みを示す仮例であり、この通貨の組み合わせをAgoráで実際に試したという意味ではありません。
円側では、支払企業の銀行A預金が150万円減少し、為替事業者の銀行B預金が同額増加します。それに対応して、銀行Aから銀行Bへ円の決済資金を渡します。銀行Aでは、銀行間決済に使う資金と、支払企業に払い戻すべき預金額の両方が減少します。銀行Bでは、受け取る決済資金と、為替事業者に払い戻すべき預金額の両方が増加します。
ドル側でも同じ関係が生まれます。為替事業者の銀行C預金を減少させ、受取企業の銀行D預金を増加させ、CからDへドルの決済資金を渡します。
Bに入った円がCのドルに変わるわけではありません。 この仮例では、同じ為替事業者がBで円を受け取り、Cに用意していたドル預金から支払います。この一件の送金中に、銀行Bから銀行Cへ資金を移す処理はありません。
ただし、為替事業者が円を受け取ったのに、ドルを支払う処理だけが止まると困ります。そこで、円側とドル側の支払いを条件付きで結び付け、片側だけの決済を避けます。
支払企業から受取企業への一件の送金を成立させるには、この為替の受渡しに加えて、各顧客の預金と銀行間資金の変化も対応させます。Agoráがつなごうとしているのは、この一連の処理です。
2. Agoráの送金処理｜確認・資金ロック・決済の5段階
Agoráのプロトタイプは、以下の5段階で送金を処理します。
受取銀行が受取人情報を照合し、送金に関わる各銀行が決済に必要な残高などを確認したら、決済に使う資金をロックし、ほかの支払いに使われないようにします。
条件がそろうと決済に進み、関係する支払いをすべて成立させるか、一つも成立させないようにします。この性質を、原子性（atomicity）と呼びます。
3. 預金のトークン化｜複数行の残高と支払条件の一体化
普通の銀行預金でも、API（注1）などの接続口を通じて振込を自動化したり、資金を確保して条件付きで動かしたりできます。片側だけの決済を避ける仕組みも、トークン化に固有ではありません。
Agoráで預金をトークン化する理由は、複数行の預金の記録と、それを動かす条件を、共通のプログラムから扱えるようにするためです。トークン化預金は「どの銀行に対する、誰の、いくらの請求権か」という記録を、権限の確認、資金のロック、残高の更新といった処理に結び付けます。銀行が認めたルールの範囲で、プログラムがその状態を変えられる形です。
各行の別々のシステムをAPIでつなぐ場合も、自動処理はできます。ただし、接続先ごとに更新を依頼し、応答を受け取り、途中で止まった処理に対応する必要があります。
共通基盤に預金を載せると、送金を次の一連の処理として扱えます。
- 各銀行の必要な確認と準備を済ませ、支払企業の円預金と、為替事業者が支払うドル預金をロックする
- 決済に必要な資金のロックと実行権限がそろったことを確認する
- 銀行間決済とともに、支払側の預金の減少と受取側の預金の増加を確定する
ロックした資金と、その資金を動かせる条件をプログラム上で対応させます。これにより、残高確認後に資金が別の支払いへ使われることを防ぎながら、複数の預金の増減を組み合わせられます。
送金に関わる銀行が、支払いの条件や進み具合を同じ台帳で確認できるため、銀行同士で結果を突き合わせる手間を減らせます。共通の処理を使い回せれば、新しい送金先の銀行を追加するときの開発負担も抑えられます。
4. Agoráの台帳構成｜共通台帳と法域別台帳の連携
今回のプロトタイプでは、商業銀行預金を扱う共通台帳と、中央銀行マネーを扱う法域別の台帳を連携させています。
共通台帳はUL（Unifying Ledger）、法域別台帳はJL（Jurisdictional Ledger）と呼ばれます。法域は、法律や規制が適用される国・地域の単位です。2026年5月の設計報告書は、この二種類を連携させる構成を示しています。
図2の送金をAgoráの構成に置き直すと、トークン化預金の残高と、銀行間の決済資金が次のように変わります。円とドルの預金は同じULで扱い、中央銀行マネーは通貨ごとのJLで扱います。
まず円側です。UL上で、支払企業が持つ銀行A発行のトークン化預金を150万円減少させ、為替事業者が持つ銀行B発行のトークン化預金を150万円増加させます。支払う人と受け取る人が使う銀行に合わせ、それぞれの銀行に対する預金債権の残高を更新します。
この増減に対応して、円のJLでは中央銀行マネー150万円をAからBへ移転します。Aの決済資金と預金債務が減少し、Bの決済資金と預金債務が増加する関係です。
ドル側も同じです。UL上で為替事業者の銀行C発行預金を1万ドル減少させ、受取企業の銀行D発行預金を1万ドル増加させます。それに対応して、ドルのJLで中央銀行マネー1万ドルをCからDへ移転します。円を受け取る側とドルを支払う側は同じ為替事業者で、二つの通貨の支払いを一件の取引として結び付けます。
台帳が分かれるため、ある台帳の結果をほかへ伝え、一件の支払いの結果として整合させる必要があります。
共有台帳では、誰にどこまで情報を見せるのか
複数の銀行が同じ台帳を使うとき、各銀行はどの情報を見られるのでしょうか。
銀行Aは、支払企業の本人確認書類や取引目的などの情報を持っています。こうした情報を、ほかの参加行すべてへ配る必要はありません。
各銀行が、制裁対象との照合など、送金に必要な確認を自社のシステムで行います。その確認結果を送金に関わる銀行と共有し、必要な確認がそろってから決済へ進みます。
本人確認書類や取引情報を誰に見せるか、承認・決済の結果を誰と共有するかを個別に設定することが、機密性を守るうえで重要になります。
Agoráのプロトタイプに使われたのが、BesuとPaladinです。BesuはEthereum互換の台帳・実行環境を提供し、Paladinは関係者を限定した資産の管理や処理を支えます。
たとえば、銀行Aと銀行Bの取引の詳細を、取引に関わらない他の銀行まで、取引の詳細を見られるようにする必要はありません。取引の詳細を見る権限を持つ銀行を限定しながら、共有する台帳では、承認を示す署名などを使って処理の正当性を検証できるようにします。
また、通常時の閲覧を絞ることに加えて、監査や調査では権限のある相手へ必要な証跡を示せなければなりません。どの情報を誰に開示するかは、銀行の審査責任や各法域の制度と合わせて設計します。
5. 実用化までの距離｜実価値テストの成果と残る接続作業
Agoráは、2024年4月に始まり、2026年5月にプロトタイプの成果を公表しました。同年7月には実価値テストを行い、9月29日には民間の追加参加7行と、その先の検証に向けた作業が発表されています。
7月テストでBISが報告した結果は、次のとおりです。
| 項目 | 報告された内容 |
|---|---|
| 参加 | 中央銀行を含む28機関 |
| 取引 | 17のシナリオで30件 |
| 通貨 | CHF、EUR、GBP、JPY、KRW、USDの6通貨 |
| 総額 | 約80万スイスフラン相当 |
| 所要時間 | 取引開始から決済まで平均約80秒 |
| 確認した流れ | Agorá上でトークンを発行して送金・決済。その後、受取側が償還を申請し、発行者の承認を経て、既存の銀行システムで対応する資金を受け渡した |
| 既存システムとの関係 | 既存システムを使った資金の受渡しまで実施したが、Agoráと既存システムの自動接続は行っていない。決済指示・残高報告には共通のISO 20022（注2）形式を使った |
プロジェクトには誰が参加しているのか
当初の中央銀行参加者は、日本銀行、フランス銀行、韓国銀行、メキシコ銀行、スイス国民銀行、イングランド銀行、ニューヨーク連邦準備銀行でした。フランス銀行はユーロシステムを代表し、2026年5月にカナダ銀行が加わっています。
日本からは、みずほ銀行、三菱UFJ銀行、三井住友銀行が参加しています。銀行以外にも、Swift、Visa、SIXなどが参加しています。
6. 日本の取組み｜日銀のDLT連携サンドボックス構成案
日本銀行は、日銀当座預金と分散型台帳技術（DLT）の連携を検証する「DLT連携サンドボックス」を進めています。日銀当座預金は、銀行などの金融機関が日銀に持つ口座の預金で、銀行同士の支払いに使われます。
2026年7月付で9月4日に掲載された資料には、サンドボックスがAgoráの日本側のJLを兼ね、ULと連携できる構成案が示されています。
日銀が検討中の構成案では、サンドボックスにBesuを利用する想定です。ノード運営と鍵管理は日銀が担います。日銀に当座預金口座を持つ金融機関は、APIゲートウェイ（注3）を通じて中央銀行マネートークンの発行・移転・償還を依頼します。
7. 実運用の条件｜決済完了・運営責任・費用対効果
Agoráの構想から期待できるのは、送金の速さに加え、送金がどこまで進んでいるか、受取人がいつ資金を使えるようになるかを把握しやすくすることです。
企業や銀行が送金の進み具合を確認しやすくなり、照会や照合の手間を減らせると期待されます。納品や証券の引渡しを条件に支払う用途も考えられます。
実用化には、次の課題が残ります。
決済完了の判断基準
送金の完了は、次の3つの観点で確認します。
- 記録：台帳上の残高の変更が確定しているか
- 法律：支払いが法的に確定し、取り消せなくなっているか
- 実務：受取人が資金を使える状態になり、銀行の会計や通知にも反映されているか
障害対応とルール変更の責任主体
送金プログラムに不具合が見つかった場合に備え、修正の承認者と、進行中の送金を扱う手順を定めます。台帳が停止した場合には、状態の確認と再開判断を担う責任者を明確にします。参加行の退出時には、未決済取引と監査記録の引継ぎ先・手続きを決めておく必要があります。
台帳の合意形成、銀行の業務判断、監督上の承認は、それぞれ担当と手続きが必要です。ソフトウェアの更新や緊急停止を含め、運営主体と参加者の権限・責任を決めることが、ネットワークを実運用するための条件になります。
導入・運用コストに見合う効果があるか
銀行がAgoráを導入するには、既存の口座管理システムにつなぐ開発費がかかります。稼働後も、処理の監視や障害対応を続けるための運用費が必要です。
これに対して、残高や取引結果を照合する作業、送金状況の問い合わせ対応がどれだけ減るかを、現在の業務と比べることになります。
業務負担が減る効果と、導入・運用にかかる費用を比べ、各銀行が継続して使う価値があるかを確かめる必要があります。