【世界のオンチェーンプロジェクト】シリーズをはじめます

海外プロジェクトはどこを見ればよいのか

オンチェーン金融を比較する10の視点

Project Agorá、Project Guardian、Project Ensemble、Pontes、Appia、GBTD――。

オンチェーン金融を調べていると、世界各地のプロジェクト名が次々に現れます。

参加する中央銀行や金融機関の数、使われているブロックチェーン、実証された取引件数などが注目されますが、それだけでは、プロジェクトの意味は分かりません。

同じ「トークン化金融の実証」と呼ばれていても、実際には、

• 国際送金を改善するプロジェクト

• 証券と資金を同時に決済するプロジェクト

• 銀行預金をトークン化するプロジェクト

• 市場DLTと既存の中央銀行決済を接続するプロジェクト

• 将来の金融市場全体を設計するプロジェクト

が混在しています。

本シリーズ「世界のオンチェーン金融・プロジェクト解剖」では、ニュースの見出しではなく、その内側にある金融構造を読み解きます。

第0回では、今後すべてのProject Fileで使用する10の分析視点を整理します。

実証から実装へ進み始めたオンチェーン金融

オンチェーン金融のプロジェクトは、概念だけを議論する段階から、具体的なアーキテクチャや実取引を検証する段階へ進みつつあります。

Project Agoráは、トークン化された商業銀行預金と中央銀行準備を組み合わせ、多通貨のホールセール・クロスボーダー決済をアトミックに、つまり「すべて成立するか、すべて成立しないか」という形で処理できることをプロトタイプで示しました。次の段階では、対象通貨と参加者を限定した実価値取引の検証が予定されています。

欧州では、Pontesが市場のDLT基盤とTARGET Servicesを接続し、DLT上の取引を中央銀行マネーで決済する短期的な仕組みを提供します。一方のAppiaは、単一の共通基盤か、複数の相互接続基盤かという選択肢も含め、欧州の長期的なトークン化金融市場の設計図を2028年までに作る構想です。

ここで注意したいのは、プロトタイプの完成、実価値を用いた試験、限定的な商用提供、本格的な市場インフラ化は、それぞれ異なる段階だということです。

「実証に成功した」という表現だけでは、どこまで確認されたのかは分かりません。

プロジェクト名だけでは理解できない

オンチェーン金融のプロジェクトには、少なくとも三つの読み間違いが起こります。

第一は、技術を中心に読んでしまうことです。

どのブロックチェーンを使ったかは重要ですが、それ以上に、

• 何を資産として移したのか

• 何を支払いに使ったのか

• 誰が最終決済を行ったのか

を見る必要があります。

第二は、トークン化された資産と決済資産を混同することです。

例えば、証券をトークン化しても、その代金を既存の銀行送金で支払うなら、証券側と資金側は別々に動きます。証券のトークン化だけでは、DvP、すなわち証券と資金の同時決済は完成しません。

第三は、実証できたことと、商用化できることを混同することです。

技術的に取引を成立させられても、

• 法的ファイナリティ

• 参加資格

• 流動性

• 障害時の責任

• 収益モデル

• 既存システムとの共存

が決まらなければ、市場インフラにはなりません。

視点1｜何を解決しようとしているのか

最初に見るべきなのは、技術ではなく業務課題です。

プロジェクトが対象としている問題は、例えば次のように異なります。

• クロスボーダー決済に時間と費用がかかる

• 証券と資金が別々のシステムで動いている

• 担保の所在や利用可能性をリアルタイムで把握できない

• 複数の金融機関が同じデータを個別に照合している

• 市場のDLT基盤に中央銀行マネーが存在しない

• トークン化資産を決済する共通の銀行マネーがない

ここを曖昧にしたまま読むと、すべてのプロジェクトが「ブロックチェーンで金融を効率化する取組」に見えてしまいます。

本シリーズでは、各Project Fileの冒頭で、現在の業務フローと、そのどこに問題があるのかを確認します。

視点2｜誰が参加し、何の役割を担っているのか

参加企業の名前を並べるだけでは不十分です。

確認すべきなのは、各参加者の機能です。

• 中央銀行：中央銀行マネーの提供、制度・監督、通貨ごとの運用

• 商業銀行：預金の発行、顧客管理、決済指図、流動性供給

• 証券会社・運用会社：資産の発行、売買、運用

• FMI：清算、決済、証券保管などを担う金融市場インフラ

• 技術事業者：台帳、スマートコントラクト、接続基盤、鍵管理

• オラクル提供者：外部データをオンチェーンへ伝達

• プラットフォーム運営者：参加認定、仕様変更、障害対応

特に重要なのは、誰が台帳を運営するかではなく、誰が金融上の責任を負っているかです。

トークンを発行する主体、裏付け資産を管理する主体、本人確認を行う主体、最終決済を行う主体は、同じとは限りません。

視点3｜何をトークン化しているのか

「資産をトークン化した」という説明だけでは、対象が分かりません。

トークンが表しているものは、次のように異なります。

• 銀行に対する預金債権

• 中央銀行に対する準備預金

• 国債や社債

• ファンドの受益権

• 株式

• 担保として利用する資産

• 売掛債権

• 商品や動産の所有権

• 利用権・収益権

• 資産そのものではなく、既存台帳上の資産を動かす指図

トークン化は、必ずしも新しい金融商品を作ることではありません。

Project Agoráでも、トークン化によって商業銀行預金や中央銀行準備の法的性質が変わるわけではないと整理されています。

見るべきなのは、トークンの外観ではなく、

です。

視点4｜何を決済資産として使っているのか

金融取引には、取引する資産と、その代金を支払うマネーがあります。

オンチェーン金融では、決済資産として次のものが使われます。

• 中央銀行マネー

• 商業銀行預金

• トークン化預金

• ステーブルコイン

• 銀行間で開設した預金口座

• 既存の銀行送金

• プラットフォーム内の一時的な決済トークン

この違いは、信用リスク、流動性、法的ファイナリティ、24時間365日稼働の可否に直結します。

「証券をオンチェーン化した」という記事を読んだときには、必ず、

を確認する必要があります。

決済資産が明示されていない場合、そのプロジェクトは資産側だけを検証している可能性があります。

視点5｜台帳はどう構成されているのか

オンチェーン金融のアーキテクチャは、一つではありません。

主な構成には次のようなものがあります。

• すべての参加者が同じ台帳を利用する共通基盤型

• 銀行、法域、市場ごとの台帳を相互接続する方式

• 市場DLTと既存の決済システムをゲートウェイで接続する方式

• 資産はDLT、資金は既存口座で管理するハイブリッド方式

• 資産と資金の両方を同じプログラマブル基盤へ載せる方式

「共有台帳」という言葉にも注意が必要です。

すべてのデータを一つの台帳に置く設計もあれば、共通の取引処理層と、各国・各銀行が管理する台帳を階層的に組み合わせる設計もあります。

Project Agoráでは、相互運用可能な共有基盤を使いながら、各中央銀行が自国通貨と国内運用に対する自律性を維持できる階層型アーキテクチャが採用されました。

視点6｜一つの取引はどう流れるのか

アーキテクチャ図だけでは、取引がどのように成立するかは分かりません。

一つの取引を、次の順番で分解します。

1. 誰が取引を開始するのか

2. 誰が本人・参加資格を確認するのか

3. 資産や資金を誰がロックするのか

4. コンプライアンス確認はいつ行うのか

5. 為替レートや価格を誰が提供するのか

6. 資産と資金をどの条件で移転するのか

7. 失敗した場合にどこまで戻すのか

8. 最終的な記帳をどの台帳へ反映するのか

9. 既存勘定系や会計システムへどう連携するのか

「スマートコントラクトによって自動化した」という説明も、どの処理を自動化したのかまで確認します。

取引条件の確認だけなのか、資産移転なのか、資金決済なのか、帳簿への記録まで含むのかで、実装の意味は大きく異なります。

視点7｜どこにプログラマビリティがあるのか

プログラマビリティとは、あらかじめ定めた条件に応じて処理を実行する機能です。

例えば、

• 証券が移転した場合だけ資金を支払う

• 両通貨の資金が確保された場合だけFXを成立させる

• 制裁・AML確認が完了した場合だけ決済へ進む

• 担保価値が一定水準を下回った場合に追加担保を要求する

• 商品到着が確認された場合に売り手へ支払う

• 満期日に利払いと元本返済を実行する

といった処理が考えられます。

ただし、プログラマビリティはDLTだけの機能ではありません。従来型システムでも条件分岐や自動処理は実装できます。DLTとトークン化の意味が大きくなるのは、複数の組織が同じ状態を共有し、資産やマネーの移転までを一体的に実行する場面です。

したがって本シリーズでは、

ではなく、

を確認します。

視点8｜法制度とファイナリティはどう設計されているのか

技術的に取引が確定したことと、法律上の決済が最終的に確定したことは同じではありません。

確認すべき論点には、

• トークンが表す権利の法的性質

• 台帳記録と既存帳簿のどちらが正本か

• 決済完了の法的な成立時点

• 参加者が破綻した場合の取引の扱い

• 誤送金・不正取引の取消し

• 顧客資産の分別管理

• AML/CFTと制裁対応

• 個人情報と取引データの共有

• 国境を越える場合の準拠法

があります。

実証では技術的処理に成功していても、これらが未解決の場合があります。

逆に、既存の銀行預金や中央銀行マネーの法的性質を維持し、既存制度の延長として構成することで、制度的な不確実性を抑えるプロジェクトもあります。

視点9｜実証はどの段階まで進んだのか

本シリーズでは、プロジェクトの進展を次のように区別します。

段階1　構想・調査

課題、参加者、アーキテクチャ候補を検討している段階です。

段階2　技術検証

限定された環境で、スマートコントラクト、台帳接続、取引処理などを確認します。

段階3　模擬取引

実際の参加者や業務データを模した環境で、エンド・ツー・エンドの処理を確認します。実際の価値は移転しません。

段階4　実価値パイロット

限定された参加者、資産、金額、通貨を使い、実際の法的・経済的価値を移転します。

段階5　限定的商用化

対象顧客やユースケースを限定し、継続的なサービスとして提供します。

段階6　市場インフラ化

多数の参加者が接続し、標準化されたルールと運用体制の下で利用します。

Project Agoráはプロトタイプを完成させ、実価値を用いる次段階へ進む方針です。Pontesは、DLT取引を中央銀行マネーで決済する実用的な提供を2026年第3四半期に開始する計画です。

「実証済み」という一語ではなく、このどの段階にあるのかを明記します。

視点10｜何が証明され、何が残っているのか

最後に、プロジェクトの成果を三つに分けます。

証明されたこと

実際の検証によって確認された機能や性能です。

示唆されたこと

プロトタイプの結果から、将来的に実現できる可能性が示されたものです。

未確認のこと

商用化、法制度、運用、流動性、費用、参加者拡大など、実証では確認されていない事項です。

例えば、アトミック決済を技術的に実行できても、

• 市場全体の流動性が改善するか

• 現行方式より費用が安くなるか

• 障害時にも安定運用できるか

• 多数の金融機関が参加するか

• 利用企業が費用を払うか

までは証明されていない場合があります。

プロジェクトの成果を過小評価しないことと、過大評価しないことの両方が必要です。

プロジェクトカード

各Project Fileの冒頭には、次のプロジェクトカードを掲載します。

プロジェクト名
正式名称と略称

主催者
中央銀行、政府機関、業界団体、民間企業など

対象地域・通貨
法域、対象通貨、クロスボーダーの範囲

参加者
中央銀行、銀行、証券会社、運用会社、技術企業など

解決する課題
現在の業務上の問題

対象資産
預金、中央銀行マネー、証券、担保、ファンドなど

決済資産
取引の支払いに使うマネー

台帳構成
共通基盤、複数台帳、ゲートウェイ、既存システム連携

実証段階
構想、技術検証、模擬取引、実価値、商用化

最終更新日
Project Fileを最後に更新した日

このカードを見れば、異なるプロジェクトを同じ基準で比較できます。

オンチェーン金融のプロジェクトを読むとき、重要なのはプロジェクト名でも、参加企業の数でも、採用したブロックチェーンでもありません。

見るべきなのは、

です。

そして、プロジェクトが実証したことと、まだ実証していないことを分けて読む必要があります。

本シリーズでは、世界のプロジェクトを同じ10の視点で解剖し、個別事例の背後にある共通の設計原則を探します。

次回のProject File 01では、Project Guardianを取り上げます。

単なる「トークン化預金による国際決済プロジェクト」としてではなく、

• なぜ中央銀行準備と商業銀行預金を組み合わせたのか

• 共通プラットフォームと法域別台帳はどう共存するのか

• 多通貨のアトミック決済はどう成立するのか

• 何が証明され、実価値検証に何が残されたのか

を、取引フローとアーキテクチャから読み解きます。

本記事は公開情報に基づく一般的な分析であり、特定サービスの推奨や法的意見ではありません。各社の数値は定義が異なり、更新されるため、利用時は一次情報を確認してください。