コラム

1. スマートコントラクトとは何か

スマートコントラクトとは、ブロックチェーンなどの実行環境上で、あらかじめ定めた条件に従って処理を実行するプログラムです。「コントラクト（契約）」という名称が付いていますが、必ずしも法的な契約そのものを指すわけではありません。

例えば「残高が一定額を上回っている」「承認済みの相手先である」「支払期日を迎えている」などの条件を設定し、その条件を満たした場合に送金を実行するといったルールをコード化できます。

金融トークナイゼーションにおけるスマートコントラクトの本質は、資産やマネーの記録だけでなく、その移転条件や処理のルールも同じデジタル環境上で扱えることにあります。

■比較表

2. 金融業務で自動化できること

スマートコントラクトが得意なのは、入力データと実行条件が明確で、同じルールを繰り返し適用できる処理です。

代表例として、条件付き支払や定期支払、残高に応じた資金移動、証券と資金を同時に動かすDvP、異なる通貨を同時交換するPvPが挙げられます。このほか、利息・配当・償還金の自動分配、担保条件の判定、参加資格やホワイトリストの確認などにも活用できます。

BISのProject Agoráでも、スマートコントラクトを用いて、ワークフローのロジック、コンプライアンス要件、条件付き支払のトリガーを取引に組み込める可能性が検証されています。

出典：BIS, Project Agorá: a shared programmable platform for wholesale cross-border payments, 27 May 2026

3. DvP・PvPでは何が変わるのか

従来の金融取引では、資産移転と資金決済、あるいは異なる通貨の決済が、別々のシステムで処理されます。このため、一方の処理が完了しても、もう一方の処理が失敗するリスクや、複数システム間で取引内容を照合する業務が生じます。

スマートコントラクトを用い、対象となる処理を同一または連携された実行基盤上で適切に設計することで、複数の処理について「双方が成立するか、双方とも成立しない」というアトミックな処理を実現できます。

これがDvPやPvPの基本的な考え方です。ただし、法的ファイナリティや外部システムを含む一連の処理まで自動的に保証されるわけではありません。

4. コンプライアンスはどこまで自動化できるか

参加者の本人確認が完了しているか、取引限度額を超えていないか、制裁リストとの照合が完了しているかといった明確な条件は、実行前チェックに組み込めます。これにより、あらかじめ定めた条件を満たす一定の取引だけを実行することが可能になります。

一方、疑わしい取引かどうか、取引目的が妥当か、例外承認を認めるべきかなど、文脈や総合判断を要する業務までスマートコントラクトだけで完結させることは困難です。

金融業務では、ルールに基づく自動判定と、人による審査・承認・モニタリングを組み合わせる設計が現実的です。

5. スマートコントラクトが「知らない」もの：オラクルの問題

スマートコントラクトは、ブロックチェーンの外部で起きた事実を自ら確認することはできません。商品の納品、為替レート、気象データ、本人確認の結果、ERP上の検収完了などを実行条件に用いるには、外部データを安全に取り込む仕組みが必要です。

外部の情報をスマートコントラクトに提供する機構は、一般に「オラクル」と呼ばれます。オラクルに誤った情報が入力された場合、スマートコントラクトがコードどおりに正しく動作しても、金融取引としては誤った結果になる可能性があります。

そのため、オラクルの提供者やデータソースを明確にするとともに、データの改ざん耐性、複数ソースによる検証、障害時の代替手段まで含めて設計する必要があります。

6. 改ざんされにくいコードが、正しいとは限らない

ブロックチェーン上に配置されたコードは、通常のアプリケーションと比べて、変更が制約される場合があります。しかし、コードが変更しにくいことが、その処理内容の正しさを意味するわけではありません。

仕様の誤り、権限設定の不備、想定外の入力、外部コントラクトとの連携不具合、秘密鍵の侵害などがあれば、誤った処理が自動実行される可能性があります。

日本銀行も2026年3月、スマートコントラクトの利便性に触れる一方、設計が不十分な場合には不正利用が金融市場やシステムの安定性を脅かす可能性があると指摘しています。

出典：日本銀行「新金融エコシステムにおける中央銀行の役割」2026年3月3日

7. 変更・停止・取消をどうするか

金融サービスでは、法改正、商品の条件変更、障害、誤送信、不正利用などに応じて、処理を止めたり変更したりする必要があります。そのため、一度配置したコードを変更できない設計が、常に望ましいとは限りません。

実務では、アップグレード権限（コードを更新する権限）、緊急停止や手動介入の方法、管理者の多重承認、変更履歴の記録、ロールバック（変更前の状態に戻すこと）の可否などを定めます。

重要なのは、誰が、どの条件でコードを変更・停止できるのかを明確にすることです。加えて、権限が濫用された場合に、どのように検知し、復旧するのかを、システム設計とガバナンスの両面から設計する必要があります。

8. 例外処理は自動化の外に残る

残高不足、通信断、データ遅延、二重送信、相手先システムの停止、オラクルからの誤った情報の入力、スマートコントラクトの不具合など、実際の金融業務では多数の異常系が発生します。

正常系だけをコード化しても商用サービスにはなりません。どの時点までなら取消可能か、保留状態をどう管理するか、再実行で二重払いにならないか、利用者への補償を誰が負担するかといった運用ルールが必要です。

自動化率を高めるほど、例外が発生したときの影響範囲も大きくなる可能性があります。そのため、監視やアラート、手動介入の手順、事業継続性までを含めて設計する必要があります。

9. 従来のワークフローエンジンと何が違うのか

条件分岐や自動処理だけであれば、従来の業務システムやワークフローエンジンでも実現できます。スマートコントラクトを活用する意義は、複数組織が共有する資産やマネーの状態と、実行ロジックを同じ基盤上で扱う場合に大きくなります。

例えば、複数銀行、証券会社、企業が同じ取引状態を参照し、資産移転と支払を不可分に処理する場合です。一方、単一企業内の承認フローだけであれば、既存技術の方が単純で安価なこともあります。

したがって、単に「業務を自動化したいからスマートコントラクトを使う」のではなく、「共有状態と価値移転を複数主体間で同期する必要があるか」を判断基準にすることが重要です。

10. 金融で実装する際の設計原則

第1に、自動化の対象を限定します。正常系と例外系を分け、コードが最終判断をしてよい範囲を明確にします。

第2に、入力データと責任主体を明確にします。オラクルや外部APIの情報を誰が保証するのかを定めます。

第3に、権限と変更管理を設計します。コードの配置、アップグレード、停止、再開を単独管理者に依存させないことが重要です。

第4に、監査可能性を確保します。どのバージョンのコードが、どの入力に基づき、誰の権限で実行されたかを追跡できるようにします。

第5に、既存システムとの境界を設計します。勘定系、会計、AML/CFT、顧客管理、決済システムとの整合が取れなければ、オンチェーン部分だけ正しくても金融業務は成立しません。