オンチェーン金融 ユースケースの地図 Use Case File 00： 概要
そのユースケースは、本当にオンチェーンである必要があるか
・海外への支払いを数秒で完了させる。
・企業グループ内の資金を、休日や夜間でも移動させる。
・外国為替取引と資金決済を同時に実行する。
・余剰資金を自動的にMMFへ投資し、支払いが必要になれば即座に償還する。
・商品が到着したことを確認してから、売り手へ代金を支払う。
こうした構想を説明するとき、しばしば「ブロックチェーン」「トークン化」「スマートコントラクト」「24時間365日」といった言葉が並ぶ。
しかし、本当に問うべきなのは、ブロックチェーンで実現できるかどうかではない。
その取引を、オンチェーンで実現する必然性があるか。
これが、本シリーズ「オンチェーン金融 ユースケースの地図」の中心的な問いである。
このシリーズでいう「オンチェーン金融」
本シリーズでは、オンチェーン金融を次のように捉える。
法定通貨建てのマネー、金融資産、商取引上の権利や取引状態を、プログラム可能なデジタル台帳上で記録・移転・決済し、複数の当事者が共有する金融の仕組み。
対象となるのは、暗号資産の売買や投機を中心とした世界ではない。
銀行預金、トークン化預金、ステーブルコイン、中央銀行マネー、証券、ファンド、債権、担保、船荷証券、商品所有権などを、実際の金融・商取引の中で利用する仕組みである。
また、オンチェーン金融は、必ずしも誰でも参加できるパブリックブロックチェーンを意味しない。金融機関や認可された事業者だけが参加する許可型台帳や、従来システムと分散型台帳を組み合わせた構成も含まれる。
イングランド銀行も、トークン化を、株式、債券、通貨などの金融資産を共有デジタル台帳上で表現し、所有状態を追跡・取引できるようにするものと説明している。
Use Case Card
項目内容分析対象実際の業務、取引、利用場面基本単位技術要素ではなく、取引の開始から完了まで比較対象現行方式、改善された従来型方式、オンチェーン方式中心的な問いオンチェーンでなければ解決しにくい問題があるか主な評価対象共有状態、資産と資金の同期、条件付き処理、正本性、監査性制約条件法律、流動性、ガバナンス、相互運用性、運用コスト最終評価AからDまでのオンチェーン適合性評価
なぜ「技術」ではなく「ユースケース」から考えるのか
オンチェーン金融の議論では、技術やプロジェクト名が先行しやすい。
「このブロックチェーンを使って何ができるか」
「トークン化預金をどこで使うか」
「スマートコントラクトを使ったサービスを作れないか」
この順番で考えると、本来は従来型システムで十分に解決できる問題まで、無理にオンチェーン化することになりかねない。
先に確認すべきなのは、現在の取引にどのような問題があるかである。
例えば、国際的な企業間取引が遅い理由は、送金システムの処理速度だけとは限らない。
請求内容の確認、外国為替取引、AML/CFT確認、貿易書類の不一致、受取人口座の確認、銀行の営業時間、着金後の入金消込など、複数の工程が連続している。
このうち送金部分だけを高速化しても、商取引全体が速く、確実になるとは限らない。
したがって、本シリーズでは常に次の三つを比較する。
現在の業務をそのまま続ける場合
APIや中央データベースなど、従来型システムを改善する場合
マネーや資産をオンチェーン化する場合
オンチェーン方式は、常に三番目の選択肢として評価する。
オンチェーン化によって解きやすくなる問題
オンチェーン金融の価値は、「ブロックチェーンを使うこと」そのものにはない。
重要なのは、既存の金融インフラでは分離されている処理を、同じ取引状態の中で結び付けられることである。
1．複数主体が同じ取引状態を共有する
現在の金融取引では、銀行、証券会社、決済機関、カストディアン、企業などが、それぞれ自社のシステムに取引を記録している。
各社が別々の記録を持つため、取引後に照合し、不一致があれば調査し、修正しなければならない。
オンチェーン化によって、複数の参加者が、権限に応じて同じ取引状態を参照できるようになれば、次のような照合作業を減らせる可能性がある。
誰が資産を保有しているか
支払いが予約されているか
担保が使用可能か
条件が成立したか
決済が完了したか
取引を取り消せる段階か
ただし、信頼できる単一の運営者が存在し、その運営者のデータベースを全員が正本として受け入れられる場合には、中央データベースでも同様の状態共有は実現できる。
重要なのは「共有台帳が使えるか」ではなく、複数の独立した主体が、誰の記録を正本として受け入れるのかという問題である。
2．資産と資金を同期して移転する
証券取引では、証券を渡したのに代金を受け取れないリスクがある。
外国為替取引では、一方の通貨を支払ったのに、反対側の通貨を受け取れないリスクがある。
こうした問題に対して使われるのが、次の仕組みである。
DvP（Delivery versus Payment）：証券などの資産引渡しと代金支払いを連動させる仕組み
PvP（Payment versus Payment）：二つの通貨の支払いを連動させる仕組み
アトミック決済（Atomic Settlement）：複数の処理を、すべて実行するか、すべて実行しないかのどちらかにする仕組み
CPMIは、トークン化の主要な目的の一つとして、DvPやPvPを含む複数の取引要素を一体的に決済することを挙げている。
資産と決済マネーを同じ台帳、または同期可能な台帳上に置くことで、従来は別々に処理されていた資産移転と資金決済を、一つの取引として制御しやすくなる。
BISが提唱する統合台帳（Unified Ledger）も、中央銀行マネー、商業銀行マネー、金融資産をプログラム可能な共通基盤上で取り扱い、取引の組合せと自動化を可能にする構想である。BISは、メッセージ送信、清算、決済が分離していることから生じる遅延、手作業、照合を減らせる可能性を指摘している。
3．条件付き取引を一つの流れとして実行する
スマートコントラクトとは、あらかじめ設定された条件に基づいて処理を実行するプログラムである。
例えば、次のような取引が考えられる。
商品が到着したら代金を支払う
担保が差し入れられたら融資を実行する
証券が移転可能になったら資金を引き渡す
口座残高が一定額を超えたらMMFを購入する
支払いが必要になったらMMFを償還する
為替レートが合意条件に達したら通貨を交換する
ここで重要なのは、単純な自動化ではない。
契約条件、資産状態、支払可能額、参加者の権限、コンプライアンス確認などを、一連の取引として制御できることである。
ただし、現実世界の出来事をスマートコントラクトが直接知ることはできない。
商品の到着、気象情報、資産価格、本人確認結果など、台帳の外にある情報を取り込むには、オラクルと呼ばれる外部データ連携の仕組みが必要になる。オラクルが誤った情報を提供すれば、スマートコントラクトは誤った処理を正確に実行してしまう。
4．権利と取引履歴を連続して記録する
高額商品の所有、証券の移転、担保設定、船荷証券の譲渡などでは、現在の保有者だけでなく、どのような経緯で権利が移転したかが重要になる。
オンチェーン台帳では、権限の付与、資産移転、担保設定、条件成立、決済完了などを、一続きの履歴として記録できる。
これにより、複数組織間の監査や取引後の検証を容易にできる可能性がある。
一方で、個人情報や営業秘密まで全参加者に見せることはできない。誰が、どの情報を、どの範囲で閲覧できるかというアクセス制御が不可欠である。
オンチェーン化しても、自動的には解決しない問題
オンチェーン金融を評価するうえでは、改善する点だけでなく、改善しない点を見る必要がある。
法律上の権利移転
台帳上でトークンが移転しても、それだけで現実の資産や法的権利が移転したことになるとは限らない。
トークン移転と、預金債権、証券、商品所有権、担保権などの法的移転を、契約や法制度によって結び付ける必要がある。
決済ファイナリティ
決済ファイナリティとは、支払いや資産移転が法的に取消不能となり、参加者の破綻後も覆されない状態をいう。
ブロックチェーン上で取引が確定したことと、法律上の決済が最終確定したことは、必ずしも同じではない。
CPMIも、トークンの技術的な移転時点と、法律上の最終決済時点が一致しない可能性を指摘している。
BISの2026年報告も、トークン化そのものが預金や中央銀行準備の法的性質を変えるわけではなく、決済ファイナリティを国内法制と整合させるには明確なルールが必要だとしている。
流動性
台帳を24時間稼働させても、24時間いつでも十分な資金や外貨が供給されるとは限らない。
夜間や休日に資金移動を可能にするためには、銀行、企業、マーケットメーカー、中央銀行などのいずれかが、その時間帯にも流動性を提供する必要がある。
「24時間動く台帳」と「24時間存在する市場」は別のものである。
また、決済を即時化すると、決済リスクを減らせる一方で、必要な時刻までに資金や担保を準備しなければならない。ネッティングによって決済額を圧縮していた取引では、即時グロス決済への変更が資金負担を増やす可能性もある。
外部データの正しさ
スマートコントラクトは、入力された情報に基づいて動く。
商品が本当に到着したか、担保が存在するか、保険事故が発生したか、価格が正しいかは、台帳の外側で確認しなければならない。
オンチェーン化は、現実世界の情報の真正性を自動的に保証しない。
AML/CFTと個人情報
取引履歴が追跡しやすくなっても、顧客確認、制裁対象者確認、疑わしい取引の検知、個人情報保護が不要になるわけではない。
むしろ、複数の国、金融機関、台帳をまたぐ場合には、情報共有範囲、保存場所、閲覧権限、データ移転規制を新たに設計する必要がある。
相互運用性
一つの台帳の中で取引が効率化されても、別の台帳や既存システムと接続できなければ、新しい孤立した市場が生まれるだけである。
IOSCOは、トークン化市場の拡大を妨げる要因として、ブロックチェーン間の相互運用性と、信頼できる決済資産の不足を挙げている。
イングランド銀行のDLT実証でも、決済ファイナリティ、拡張性、ネットワークと資産の制御、他のDLTや従来型RTGSとの相互運用性が主要論点として扱われた。
障害時の責任とガバナンス
プログラムが想定外の処理を実行した場合、誰が取引を停止するのか。
誤送信や不正取引を取り消せるのか。
スマートコントラクトに不具合があった場合、誰が損失を負担するのか。
ルール変更を誰が決定するのか。
オンチェーン化によって処理を自動化しても、運営主体や責任主体まで自動的に消えるわけではない。
FSBも、トークン化は従来金融に存在する流動性リスクやオペレーショナルリスクをなくすものではなく、技術や既存システムとの接続によって、それらの脆弱性が増幅される可能性を指摘している。
従来型データベースやAPIでは足りないのか
オンチェーン化を評価するとき、最も重要な比較対象は、現在の古いシステムではない。
十分に改善された従来型システムである。
取引の性質従来型DB・APIが適する場合オンチェーンが適する可能性がある場合運営主体信頼できる単一主体が存在する複数の独立主体が共同で運営する正本管理一社の記録を全員が受け入れる誰か一社の記録を正本にしにくい状態共有必要時にAPIで照会すればよい全参加者が継続的に同じ状態を見る必要がある資産と資金別々に処理しても支障が小さい同時移転しなければ決済リスクが生じる条件付き処理一社内のワークフローで完結する複数主体の義務を同じ条件で実行する変更・取消頻繁な修正や取消が必要取消不能性や履歴の連続性が重要データ大量の機密データを一社で管理する必要最小限の状態を参加者間で共有する取引規模参加者が少なく費用対効果が低い多数の参加者と反復取引が存在する
中央データベースの方が、性能、運用、変更、障害対応、機密情報管理の面で適している場合は少なくない。
反対に、複数組織が独立性を保ちながら、同じ取引状態とルールを共有し、資産と資金を同期させる必要がある場合には、オンチェーン化の意味が強くなる。
オンチェーン適合性の評価方法
本シリーズでは、各ユースケースをAからDの4段階で評価する。
A：適合性が高い
複数主体の共有状態、資産と資金の同期、条件付き移転、権利履歴など、オンチェーンでなければ解きにくい構造的な問題がある。
従来型DBやAPIでも理論上は実現可能だが、特定主体への依存、複雑な照合、取引分断などが大きく残る。
B：条件付きで有効
オンチェーン化による価値はあるが、参加者数、市場規模、法制度、決済マネー、流動性、標準化、相互運用性などの条件が整っていない。
技術的に実現できることと、商用サービスとして成立することの間に距離がある。
C：従来型でも実現可能
期待される便益の多くが、高速化、24時間化、自動化、データ連携にとどまり、API、中央データベース、既存決済インフラの改善でも相当部分を実現できる。
オンチェーン方式は選択肢になり得るが、必須ではない。
D：現時点では不向き
解決すべき問題が弱いか、法制度、運用、流動性、セキュリティ、コストなどの負担が便益を上回る。
将来の技術進歩や制度変更によって評価が変わる可能性はあるが、現時点で導入する合理性は低い。
評価は五つの順番で行う
各記事では、次の順序で判定する。
第1段階 問題は本当に存在するか
利用者が困っている問題なのか。
事業者が技術導入のために作った問題ではないか。
頻度、金額、損失、処理時間などから、解決する価値を確認する。
第2段階 従来型方式でどこまで改善できるか
API、クラウド、中央データベース、既存決済網の時間延長、ISO 20022などの標準化で解決できないかを確認する。
第3段階 オンチェーン固有の価値があるか
次のいずれかが必要かを確認する。
複数の独立主体による共有状態
資産と資金の同期
条件付き・複合的な取引
権利移転履歴の連続管理
特定の単一運営者に依存しない共同運営
第4段階 取引を法的・経済的に完了できるか
台帳上の移転だけでなく、次の点を確認する。
法律上の権利移転
決済ファイナリティ
銀行間最終決済
償還可能性
AML/CFT
個人情報保護
障害時の責任
第5段階 市場として成立するか
技術が動くだけでは、ユースケースは成立しない。
参加者、取引量、流動性、標準化、運営主体、収益モデル、既存システムとの接続費用を含めて評価する。
A評価は「すぐに商用化できる」という意味ではない。
D評価も「永久に実現しない」という意味ではない。
評価対象は、あくまで現在の制度、市場、技術、コストを前提とした適合性である。
各記事で確認する10項目
今後の各記事では、原則として次の10項目を共通の評価軸として使用する。
現在の業務と問題
取引当事者と役割
対象となる資産・権利
使用する決済マネー
オンチェーン化する処理
必要なシステム構成
プログラマビリティの具体的な意味
法律・規制・ガバナンス
実用化の成熟度
オンチェーン適合性と残課題
単に実証実験が行われたという理由で、実用化が進んでいるとは評価しない。
構想、技術実証、模擬取引、実価値パイロット、限定商用、本格商用を区別する。
これから描くユースケースの地図
本シリーズは、記事数を固定しないオープンエンド型の連載とする。
最初に取り上げるのは、次の五つのユースケースである。
Use Case File 01
クロスボーダーB2B決済
国際送金を速くするだけで、企業間取引は変わるのか。
請求書、商品、外国為替、AML/CFT、送金情報、着金確認を含め、企業間取引全体の確実性を検討する。
Use Case File 02
グローバル資金管理
企業グループの資金を24時間動かす意味はあるか。
キャッシュプーリング、海外子会社、通貨別残高、カットオフタイム、休日、プレファンディング、規制・税務を扱う。
Use Case File 03
24/7 FX and PvP
外国為替市場は、本当に24時間決済を必要としているか。
FX約定、PvP、CLS、非主要通貨、夜間・休日流動性、AMM、中央銀行マネーとの関係を分析する。
Use Case File 04
企業の余資運用とトークン化MMF
預金とMMFの境界をなくすと、企業財務はどう変わるか。
自動投資、自動償還、基準価額、流動性、担保利用、トークン化預金との交換を検討する。
Use Case File 05
電子船荷証券と条件付き貿易決済
商品・書類・資金を、一つの取引として動かせるか。
船荷証券、信用状、貿易書類、商品引渡し、オラクル、貿易金融、条件付き決済を扱う。
その後も、証券DvP、担保移動、イントラデイ・レポ、高額資産デジタルパスポート、サプライチェーン金融、不動産決済、保険金支払い、AIエージェント決済、機械間決済などを追加していく。
このシリーズで使わない近道
本シリーズでは、次の説明だけでオンチェーン化の価値を結論付けない。
「ブロックチェーンだから改ざんできない」
「スマートコントラクトだから自動化できる」
「24時間365日だから便利になる」
「仲介者をなくせる」
「即時決済だから流動性が改善する」
「トークン化すれば流通性が高まる」
これらは可能性を示す言葉ではあるが、ユースケースの成立を証明するものではない。
必ず、次の問いまで掘り下げる。
誰がデータを入力するのか。
誰が取引を停止できるのか。
誰が損失を負担するのか。
法的な権利はいつ移るのか。
銀行間の最終決済はどこで行われるのか。
24時間分の流動性を誰が供給するのか。
従来型データベースやAPIでは、なぜ足りないのか。
結論
オンチェーン金融の価値は、送金を速くすることだけにはない。
複数の主体が同じ取引状態を共有し、資産、資金、契約条件、権利移転を一つの取引として制御できるところに、本質的な可能性がある。
一方で、オンチェーン化しても、法律、流動性、外部データ、AML/CFT、個人情報、運用責任、参加者間の利害調整は残る。
新しい台帳を導入しただけでは、金融取引は完成しない。
だからこそ、技術からではなく、実際の取引から考える必要がある。
そのユースケースは、本当にオンチェーンである必要があるか。
この問いを起点として、オンチェーン金融が本当に価値を生む領域と、従来型システムで十分な領域を、一つずつ地図に描いていく。
次の記事
Use Case File 01
クロスボーダーB2B決済
「国際送金を速くするだけで、企業間取引は変わるのか」
（鋭意執筆中！ リクエストがあれば早めに書きます！）
主な参照資料
Bank for International Settlements, Annual Economic Report 2026: Anchoring trust in money – innovation beyond stablecoins
Bank for International Settlements, The next-generation monetary and financial system
CPMI, Tokenisation in the context of money and other assets
Financial Stability Board, The Financial Stability Implications of Tokenisation
IOSCO, Tokenization of Financial Assets
Bank of England, DLT Innovation Challenge 2025: Final Report
Monetary Authority of Singapore, Project Guardian: Open and Interoperable Networks
BIS, The oracle problem and the future of DeFi
本連載群は個人の見解であり、所属組織を代表するものではありません。
また直近の情報をもとに構成していますが、その正確性を保証するものでありません。ご利用の際には十分ご留意ください。
いいなと思ったら応援しよう！
この記事が参加している募集
この記事は noteマネー にピックアップされました
