異なるブロックチェーンやシステムを繋げることの意義と課題、具体的な事例
はじめに
ブロックチェーン業界の伝統的キーワード、”インターオペラビリティー”について今回は議論しましょう。よくお客様から「CordaはFabricと繋がりますか？」と無邪気な質問を聞かれます。深い理由はなく、何となく「繋がると良いじゃないか？」と思っているだけが多いようです。ブロックチェーン業界の人もWhyとHowをさておき「インターオペラビリティーが重要だ！」と最もらしいことを高らかに宣言したりします。ですのでこちら側にも責任があります。今回は、少し踏み込んでインターオペラビリティーを目的からしっかりと理解した上で、なぜそんなに”繋ぎたいか？”を深堀してみたいと思います。
※ここではプライベート・ブロックチェーンの利用を前提にしており、パブリック・ブロックチェーン間のインターオペラビリティーは全く違う議論になりますのであしからず…
余談から…
インターオペラビリティーの議論は、私がブロックチェーン業界に入った当時（2016年7月）から存在しており、初めて聞いたのは忘れもしない日本橋で同業者とランチをしている時でした。
どのブロックチェーンも最終的には繋がると思ってるんですよ。
何となく「そうですよね～」と合わせにいったのを覚えています。なんと、ここから４年近くたった今でも、ブロックチェーンは繋がっていません。なぜでしょうか。これは後編の最後に振り返ってみます。
インターオペラビリティーの定義と目的
インターオペラビリティーは「何かと何かを”繋ぐ”」という意味で使われています（分類を後述）。インターオペラビリティーが必要とされる理由は、端的には「プライベート・ブロックチェーンのサイロ化を防止したいから」です。これはどういうことでしょう。
そもそもプライベート・ブロックチェーンの目的は、現状、企業毎にサイロ化された大差ない似たようなシステムを、企業間で繋げて、個別に台帳管理されている取引等のデータを同期させることにより、企業間の認識相違から生じる業務負荷を低減することです。
現在、世界中のプレイヤーが取り組んでいるブロックチェーンを使ったネットワークは、目的毎に開発されています。そのため、将来的には目的毎に複数のネットワークが誕生することが予想されます。企業間がブロックチェーンで繋がっても、複数誕生するであろうネットワーク間が繋がらなければ、結局、ブロックチェーン自体がサイロ化に陥ってしまいます（と考えられます）。
だから何となくインターオラビリティーが重要そうなのです。ただ、目的が異なるネットワークを闇雲に”繋げる”必要があるのか、この辺は議論しなければいけません。個別具体的にインターオペラビリティーの必要性を検討しないまま、「繋がるから良い」、「繋がらないから悪い」と技術的優位性を結論付けてしまうのは短絡的かと思います。重要なことは、エンドユーザーである企業が本当に望んでいる仕組みを構築できるか、です。ブロックチェーンだけでなく、他の技術も組み合わせた方が良いかもしれません。ブロックチェーンだけに囚われず、一段上位の目線でデジタル・トランスフォーメーションを考える必要があるでしょう。個別具体的なユースケースについては、後編にて議論したいと思います。
インターオペラビリティーの分類
インターオペラビリティーは文脈と勝手な前提に基づいて話されてしまうことが多いです。私が知っている限りでは、なんと7つの定義があります。
一つずつ見ていきましょう。
①異なるブロックチェーン間を繋げる
おそらく一番多くの人が考えるインターオペラビリティーはこれに該当します。エンタープライズ・ブロックチェーンの世界では３つの代表的なプラットフォーム（Hyperledger Fabric, R3 Corda, Quorum）があり（最近はHyperledger Besuも注目…）、それぞれを接続できるかがよく議論になります。
例えば、ドイツ取引所とスイスコム（スイスの通信大手）は、FabricとCordaを使い、証券トークンとキャッシュトークンのDvP決済を実証しています。シンガポールの規制当局MASとカナダの中央銀行BOCは、QuorumとCordaを使って、異なる通貨間の国際送金（PvP決済）を実証しています。他にもAccentureは密かにBlockchain Integration Frameworkと呼ばれる取組みを始め、Fabric, Corda, Quorum間のオンチェーン・データ交換を検証しています。日本のLayerX社は最近Cordageと呼ばれるプロジェクトを立ち上げ、Cordaと他のブロックチェーン（まずはEthereumとQuorum）との接続を実証します。
②同じブロックチェーン間を繋げる
例えば、CordaとCordaは繋がるか、といったインターオペラビリティーになります。もう少し厳密に言うと、「異なるアプリケーションが、同一のブロックチェーンを利用している場合、このネットワーク間は接続出来るか」が議論になります。
ちなみに前提はありますが、Cordaであれば繋がります。ただしこの場合においても、肝心な連携するデータの項目が、異なるアプリケーション間でズレていると、”項目のマッピング”作業が発生してしまいます。これを誰かがやらなければなりません。新しくネットワークを接続するたびにマッピングしていては、時間もコストもかかります。近しい目的をもったネットワークを構築しようとしている事業者は、競合の枠を超えて、データモデル標準化の議論を同時並行で進める必要があります（エンドユーザーのために）。
③オープンソース版とエンタープライズ版を繋げる
Cordaの場合、オープンソース版とエンタープライズ版のプロダクトがあります。一般に企業が本番利用を想定してノードを建てる場合は、Corda エンタープライズ版が必須となります（そうしないと非機能要件を満たせません）が、理論上は、オープンソース版のノードを混在させてネットワークを組むことも出来ます。この場面においてオープンソース版とエンタープライズ版が会話出来なければ、お話になりません。
④ブロックチェーンと社内システムを繋げる
例えばERPやCRMのような社内システムとブロックチェーンが接続出来るかが議論になります。これが実現可能になると、エンドユーザーはブロックチェーンを社内システムの”裏の仕組み”として活用することが出来ます。メリットとして、エンドユーザーはこれまで使い慣れた社内システムを継続して利用できますので、現行業務フローを変更する必要がありません。それでいながら、社外と認識を揃える必要のある業務まで、一つのアプリケーション内で完結できます。ブロックチェーン導入（新システム導入）に伴う二重入力もありません。さらに、この使い方は既存システムへのアドオンのような位置付けとなるため、「既存システムのリプレースによる投資対効果は？」という議論を回避できます（スイッチングコストの問題はコチラのブログが非常に分かりやすくお奨め）。
具体的な事例として、貿易金融のMarco Poloは、Oracle NetSuiteとのAPI連携を通じて、ERPデータをブロックチェーンでも活用出来るようにします。
⑤ブロックチェーンと外部システムを繋げる
これはブロックチェーンから既に存在する外部のネットワークに接続するという発想です。例えば、CordaにはCorda Settlerと呼ばれる実装例があり、SWIFT GPIとの接続が可能です。これは、ブロックチェーン・レイヤーにおける接続ではなく、あくまでAPIによる接続です。そのため、アプリケーション・レイヤーで、ステータスを監視するロジックを組み、不整合が起こらないように制御する必要があります。これではブロックチェーンの良さが失われてしまいます。
ではなぜブロックチェーンの良さを捨ててまで外部システムに接続したいかというと、SWIFTのように11,000社もの銀行を抱える”出来上がったネットワーク”をわざわざディスラプトする必要がないからです。技術の話ではありません。もちろん、送金データも含めてオンチェーンで扱える方がアーキテクチャーとしては美しいです。しかし、エンドユーザーの立場からすれば、これまで使ってきたSWIFTは安心感があり、「SWIFTとの接続」はmake senseするのです（稟議で揉めない…）。Corda Settlerを活用すれば、一つのアプリケーション内で取引の合意から決済までを完結できます。この利便性は「全てをブロックチェーン上でやらなくては！」という宗教観を上回ります。
同様の事例として、貿易金融のMarco Poloは、Mastercardとパートナーシップを組み、Mastercard Trackという既存の外部システムからKYCに関する情報を取得します。KYC情報は貿易金融の取引時に有用ですので、既存のネットワークで既に蓄積されたデータがあるならば、それを活用してしまおう、という発想です。
⑥異なるクラウド上のブロックチェーン間を繋げる？
ブロックチェーンはミドルウェアのレイヤーに該当しますが、その下支えとなるインフラは何でも良いかというと、そうではありません。現実には、特定のクラウド環境を想定し、それに依存する実装もされています。そのため、ブロックチェーンを実際にクラウド環境にデプロイして、本当に動くかの検証は必須です。最近ではOracleとIBMが異なるクラウド間での接続を実証しています。完全にクラウドの話ですが、これもインターオペラビリティーと呼ばれています（記事によると…）。
⑦ブロックチェーンと新技術を繋げる？
これはかなりレアパターンですが、事業会社でデジタル・トランスフォーメーション担当になった人がたまに疑問を持ったりします。「IoTからブロックチェーンに入力出来ますか？」、「ブロックチェーンのデータをAIで分析出来ますか？」、自由にして下さい（笑）。ただ一つ気付かされるのは、ブロックチェーンに蓄積したデータの”加工のし易さ”は、ブロックチェーン導入における一つ要件になるかもしれません。一般に、フロントユーザーが使用するシステムは、フロント仕様で最適化されているため、データ分析用には使いません。データ分析するのであれば、高速アクセスが可能はNon SQL DBにデータをオフロードします。これを実装できると、リアルタイムな企業業績管理（EPM）が可能となり、例えばSCMの分野で効いてきます。
これをインターオペラビリティーと呼ぶかは微妙ですが、「異なる技術が繋がって業務が最適化される世界」、エンドユーザーにとってはこっちの方が重要です。
”繋がる”の要件
さて、ここまで”繋げる”とか”接続”という言葉を使ってきましたが、これももう少し厳密に定義しておいた方が良いでしょう。あるブロックチェーン上で動くアプリケーションで取り扱っているデータを、別のブロックチェーン上で動くアプリケーションでも使える、と”繋がる”と言えそうです。が、ここには要件があります。
①シームレスと②ダイレクトは技術的要件で、③ローコストはビジネス的な要件（ペイするか）です。
例えば、アプリAで作成したデータをCSVで吐き出して、アプリBで取り込む、は”繋がる”とは言えません、なぜなら要件①のシームレスを満たしていないからです。CSVのデータはいくらでも書き換えが出来ますし、コピーして二重に利用することも出来ます。では、CSVのデータは信用出来ないからと言って、信頼できるXさんを間に置き、アプリAのデータを一旦Ｘさんに渡して、XさんがアプリBに責任をもってデータ送信する、も”繋がる”とは言えません。要件②ダイレクトを満たしていないからです。そして、そもそも「ブロックチェーンって第三者が要らなくなる仕組みじゃなかったっけ？」と振り出しに戻ります。加えて、第三者を置く方法では、それ相応の手数料を支払う必要も出てくるでしょう。第三者がインターオペラビリティーを提供するためのインセンティブ設計が必要です。要件③ローコストの充足は困難かもしれません。
さて、インターオペラビリティーの分類と”繋がる”要件が整理できて来ましたので、Howの部分も考えていきましょう。以降、ブロックチェーン間の接続（同種、異種）に絞って議論します。
中編へ続く
＜ご質問・ご要望の例＞
- Corda Portalの記事について質問したい
- ブロックチェーンを活用した新規事業を相談したい
- 企業でのブロックチェーン活用方法を教えて欲しい 等々