この記事で学べること

インターオペラビリティ、その必要性と実装について

目次

• はじめに
• DvP決済で考える
• サプライチェーン・マネジメント（SCM）で考える
• インターオペラビリティーで繋げるインセンティブ
• 選ばれるアプリ・ベンダーになる

はじめに

例えばポスト・トレードの分野における証券決済と資金決済を同時に行うDvP決済だとインターオペラビリティーはどのように効いてくるでしょうか。

DvP決済で考える

①何を繋げたいか？なぜ繋げたいか？

DvP決済の目的は、取りっぱぐれるリスクを失くしたいからです。証券決済において証券の受け渡しが終わったにも関わらず、それに伴う資金が移動されないと渡し損になってしまいます。これを防止するために、証券のデータと資金のデータを渡し合いたいのですのですが、この渡し方を”同時に”、事後的な書き換えがおこならないよう、また証券や資金のデータが二重に存在することがないよう、かつ出来るだけお金をかけずに実現したいのです。

②どう繋げるか？

ここで取り扱いデータは債券とキャッシュであり、それぞれ”価値”ある資産になります。そのため、債券の受け渡しとキャッシュの受け渡しには、厳密な不可分性（アトミック性）が求められます。この要件を基に実装を考えると、同じブロックチェーン間でインターオペラビリティーを実現するのが理想的でしょう。

債券の所有権移転とキャッシュの所有権移転を一つの取引として同時に実行すれば良いです。

もしくは、異なるブロックチェーン間であれば、技術的にシームレスかつダイレクトな接続は困難ですので、信頼できる第三者を活用する方法が考えられます。

③標準化は？

日本でもブロックチェーン上での債券発行とその流通について標準化を目指す動きが出てきています。STO分野では日本STO協会が、目的の一つであるルール整備の一環としてデータモデルについても主導していくことが期待されます。

サプライチェーン・マネジメント（SCM）で考える

もう一つ事例で考えます。SCMは様々なプレイヤー、グループ企業が登場しますので、何となく繋ぎたくなってしまいます。整理して考えましょう。

①何を繋げたいか？なぜ繋げたいか？

SCMの壮大なテーマですので、目的は様々です。一旦ここでは「リードタイムの削減によるキャッシュ・コンバージョン・サイクル（CCC）の短縮」を目的に設定しましょう。難しい言葉を使ってしまいましたが、要はモノを売ったら早く現金化したいんだ！を実現したいのです。このために、”モノが納品された”という事実を表すデータと、”請求書を発行した”というデータを、異なるネットワーク間で受け渡したいのです。ディープ・ダイブします。

ここでは目的の異なる3つのネットワークが存在すると想定します。

一つ目は、トレーサビリティー(追跡性)に主眼を置いたネットワークです。モノの移動履歴等の物流に関するデータがやり取りされています。

二つ目は、サプライチェーン内の受発注プロセスの効率化を目的としたネットワークです。発注書や請求書といった商取引に関するデータが飛び交っています。

３つ目は、インボイス・ファイナンスを目的にしたネットワークで、売掛債権の早期現金化を提供します。これは銀行のサービスです。

サプライヤーであるAはこの全てのネットワークに参加しています。

この状況において、どのようにCCCを短縮すれば良いか考えてみましょう。まずはトレーサビリティーと受発注のネットワークに注目します。

最初に、A（サプライヤー）-C（バイヤー）間で受発注取引が行われます。すると、Cは受発注アプリを通じて、発注書データをAに送信します。Aは早く入金して欲しいからと言って、受注直後にいきなり請求書を発行する訳にはいきません。基本的には商品を出荷し、無事バイヤーであるCにモノが納品されたら、Aは請求書を発行できます。だから、Aにはいち早く納品の事実を受け取りたいというモチベーションがあります。トレーサビリティー・アプリを通じて、納品済データを受け取ると、Aは請求書を発行できます。受発注アプリとトレーサビリティー・アプリが繋がっていれば、この納品から請求書発行の流れをスムーズに行えます。だからインターオペラビリティーが必要なのです。しかし問題は請求の時期です。支払は月末締め翌月末払いとなっていますので、入金は少し先になりそうです。いくらブロックチェーンで受発注プロセスがスムーズになったとはいえ、入金タイミングまで早めることはできません。しかし、Aは運転資金が不足気味で何かあったらアウトです。だから次に、受発注アプリとファイナンス・アプリを繋げたいのです。

Aは請求書発行後、請求書データを受発注アプリを通じてCに送らず、ファイナンス・アプリを通じて、銀行Yに送信します。インターオペラビリティーがあれば、ボタン一つで送信できるでしょう。銀行Yは、受信した請求書データを事前に設定しておいた基準に照らし合わせ、適度な手数料を設定し、審査結果データをAに返信します。この一連の流れは自動でできてしまうでしょう。以上が実現されると、Aは請求書の期日を待たずとも、銀行から早期現金化のサービスを受けられるようになります（ここで決済の議論はスコープ外としておきます）。

②どう繋げるか？

まず納品済データの連携を考えます。納品済データは、データそのものに”価値”がある訳ではありません（もちろん価値はありますが、ブロックチェーンでいうところのデータそのものを資産として扱えるという意味の”価値”です…）。ここでは、あくまで次のアクションを起こすためのトリガーとして使っています。そう考えると、ブロックチェーンの厳密な技術的要件が必要かというと、ある程度割り切りも可能かもしれません。つまり、AからCへの納品から、Aによる請求書発行までのプロセスをスムーズに行うことを目的とすれば、トレーサビリティー・アプリと受発注アプリが別々のブロックチェーンで実装されていたとしても、”頑張って繋げる”ことで、目的は達成出来ます。

では請求書データのファイナンス・アプリへの連携はどうでしょうか。ここはブロックチェーンの良さが必要となります。なぜなら、売掛債権の二重譲渡による不正が発生し得るためです。請求書データも所詮データなので、A社はY銀行だけでなく、X銀行にもZノンバンクにも同じ請求書データをコピーして送信できてしまいます。つまり、この場面において、請求書データにはデータの原本性（一度そのデータを使ったら二度と使用できないようにする特性）が必要となってきます。ですので、同じブロックチェーンを使い、シームレスかつダイレクトに接続しましょう。

③標準化は？

国際貿易の世界では、ICC (International Chamber of Commerce, 国際商工会議所)が音頭を取り、DSI (Digital Standards Initiative)と呼ばれる電子的貿易取引に係る標準化の取り組みを既に始めています。

インターオペラビリティーで繋げるインセンティブ

どのような形であれば、インターオペラビリティーが実現することによって、エンドユーザーは業務上のメリットが受けられるイメージがついてきたかと思います。ブロックチェーン上で動くアプリケーションの提供者側（以下、アプリ・ベンダー）は、出来るだけ早い未来にこの世界観を実現しなくてはなりません。ただ、現状としてインターオペラビリティーの実装事例は一部に留まっています。なぜでしょうか。そもそも”繋ぐ”を実装する前に、ブロックチェーン技術自体の機能向上、成熟化が優先であるという理由が一つ。もう一つは、アプリ・ベンダーにとってインターオペラビリティーを実装するインセンティブは何か、という議論があります。

ソフトウェアを開発するベンダーの基本戦略は囲い込みであり、自社で構築したネットワーク”内”で、出来るだけ多くのエンドユーザーに留まって頂くことが、ベンダーの収益に繋がります。仮にインターオペラビリティーが実現してしまうと、エンドユーザーは同じ目的で作られたより安いネットワークへ乗り換えてしまう可能性があります（逆に顧客が流入する可能性もあります）。

アプリ・ベンダーは自社の囲い込み戦略とエンドユーザーにとってのデメリットの狭間で悩まされます。囲い込みを強化するのであれば、自社ネットワーク内にあらゆる機能を用意し、エンド・ツー・エンドで取引を完結させることによって、エンドユーザーにそもそもインターオペラビリティーの必要性を感じさせないことも出来ます。一方、エンドユーザーにとっては”一択”となるため、気付いたときには言い値でそのサービスを使わざるを得ないかもしれません。かといってインターオペラビリティーを強化して、ブロックチェーン間を繋ぎ始めると、ロックインの度合いが弱まるため、エンドユーザーにとっては嬉しいですが、アプリ・ベンダーにメリットは薄いかもしれません。もちろん逆に顧客流入はあるかもしれませんが、諸刃の剣です。ブロックチェーンと社内システム、社外システムを連携させて、エンドユーザーの利便性を向上させることは、ベンダーにとっても特にデメリットはないため、有効な戦略となるでしょう。

選ばれるアプリ・ベンダーになる

ここまで色々と議論を整理してきましたが、結論としてインターオペラビリティーの実装は、どのような形であれば、エンドユーザーにとって業務上のメリットがあります。ですので、インターオペラビリティーをエンドユーザーに訴求しながら、協働できる、時には競合するネットワーク間を”繋ぐ”ハブを目指すのが、アプリ・ベンダーにとって賢い戦略と言えるでしょう。例えば、貿易金融のContourはコモディティ取引のマーケットプレイスTradeCloudとパートナーシップを組み、TradeCloudで発行されるPO（発注書）をContourで取り込めるようにしています。これにより、エンドユーザーによりシームレスな取引体験をお届けできます。”転記”は不要です。と同時に、ContourはTradeCloudの既存顧客の流入も副作用として期待出来ます。

これまでシステムインテグレーターやソフトウェア・ベンダーは、どれだけエンドユーザーを囲い込むかが、決してそのような言い方はしませんが、公然の戦略でした。ブロックチェーンの社会実装そしてインターオペラビリティーの実現が、システムの提供側の戦略すら変えていってしまいそうです。意外にみんな気付いています。