この記事で学べること

ブロックチェーンの必要性とその利点、特に取引の同期とデータの一貫性について

目次

• はじめに
• 中央集権型じゃダメなの？
• Why ブロックチェーン?のそもそもの課題は？
• Why ブロックチェーン? Why Corda?
• まとめ

はじめに

今日から始まるこのブログでは、R3が開発するブロックチェーン・プラットフォームCordaを活用したビジネスを始めるに当たって、最小限必要となる知識（Minimal Viable Knowledge）を紹介していきます。このブログがみなさんにとって、世界中の契約や取引、情報共有の仕組みを変えるアプリケーション開発に着手するきっかけとなれば幸いです。

第一回目の今回は、ブロックチェーン業界でいつも話題になるWhy ブロックチェーン？について、議論したいと思います。

中央集権型じゃダメなの？

Why ブロックチェーン?の質問を挙げる人の多くは、頭の中に、「中央集権型じゃダメなの？」といった疑問があります。特に、顧客先の社内システムを構築してきたベンダーの方々はこのような視点を持っています。社内の情報を一元的に集中管理するのであれば、確かに中央集権型の方が効率的に思えます。しかし、ブロックチェーンが想定しているのは、社内の情報共有といった閉ざされた信頼のある世界ではなく、顧客との取引、社外との情報共有といった、オープンかつガバナンスの効かない場面になります。会社を跨いで、時には業界をも跨いでもなお、中央集権型の仕組みをユーザー全員が望んでいるのであれば、それで良いかと思います。言い換えると、エンドユーザーであるお客さまが、機密情報を含むあらゆる取引データを、競合他社もみんなが使っているデータベースに喜んで預けたい、というニーズであれば、中央集権型データベースで全く問題ないでしょう。

しかし、2015年にR3で実証実験を開始した金融機関からは、自分たちの金融取引のデータを一か所には集めたくない、という逆の要望がありました。よく考えると当たり前のように感じます。なぜ世界中の金融機関が、社内の機密データを第三者が管理する中央集権型データベースに集めたいのでしょうか？色んな意味で危険です（情報漏洩したら？権限制御を誤ったら？そもそも誰が管理出来るの？etc,.）。また、本当に世界中の全員がその一つの中央集権型の仕組みに必ず乗るのでしょうか？おそらく、「うちは違うのを使う」と言い始める会社が、複数社出てくるでしょう。そうなると、現実的に中央集権型で一か所に集める、というコンセプトの実現は難しそうです。結果、現状がそうであるように、各企業が自社のデータベースを分散してバラバラに持つ状況となってしまうでしょう（これをサイロ化と呼びます）。

ただ、分散していながらも、あたかも中央集権型データベースのように、相手が見ているレコードを自分も見ているという状態を作れるとしたら、いかがでしょうか。つまり、各金融機関は、これまでと同じように自社のデータを自社で管理しつつ（これはクラウドでもオンプレでも構いません）、それでいてレコード単位で取引の相手方と情報を同期出来る仕組みにより、あたかも論理的には一つのデータベースを共有しているのと同じ効果が得られるとしたら？R3は、金融機関のコンソーシアムからこのような業務要件を受け、Cordaをスクラッチで設計・実装しました。

Why ブロックチェーン?のそもそもの課題は？

中央集権型の良し悪しはともかく、現在は各企業が分散して台帳を持っているという状況があります。社内システムを使って取引を記帳し、「自分たちにとっての事実」として自社内に保管します。しかし、その事実は取引の相手方にとっても、本当に事実なのでしょうか？取引台帳は各社が持っているので、相手方がどう記帳しているかは、確認の術がありません。そのため、その取引の当事者であるA社とB社のバックオフィスは、「自分たちにとっての事実」が相手にとっても同じなのか、確認する必要があります（コンフォメーション）。また認識相違があれば、調整して同期する必要があります（リコンサイル）。多くの場合、これらは手作業であり、業務負荷がかかります。また1日1件であれば何となく出来そうですが、もし数百件の確認が必要となったら、急に業務プロセスは止まってしまうでしょう。

こう考えるとまた、データを一か所に集めれば良い？という発想になりがちですが、今はブロックチェーン（分散台帳技術）があります。一か所に集めなくとも、この課題を解決出来るのです。

Why ブロックチェーン? Why Corda?

ブロックチェーン（もしくはCorda）は、対改ざん性があり、二重取引を防止する機能を備えた分散型データベースを実現する仕組みです。対改ざん性と言った場合、もちろん書き換えられないという意味ですが、そのデータの状態は相手方との合意を得ることで進化させることは出来ます（対改ざん性のあるデータの状態が進化する過程が履歴として記録出来ることを、追跡性がある（Traceability）と呼びます）。この場合でも、あくまで相手方との合意に基づいているという点がポイントです。一度Corda上に記録されたデータは、自分の手元にあるデータベースでありながら、自分で勝手に書き換えることが出来ず、更新するためには常に相手との合意形成が必要となります。これは相手方とのワークフローを通じて行われます。そして、このワークフローがあるおかげで、データベースの内容は相手方と確実に同期された状態を維持出来ます。

さらに、取引をする企業同士は、共通のアプリケーション（スマートコントラクト）を利用します。そして、ワークフローによって同期されたデータベースの内容をスマートコントラクトのインプットデータにすることで、それぞれの企業は、別々に計算しながらも、全く同じアウトプットが得られるようになります（このことをDeterministicと呼んでいます）。

ここまで来ると何が起こるでしょうか？取引における相手方との認識相違がなくなるということです。すなわち、バックオフィスで行っているようなコンファメーションやマッチング、リコンサイルといった業務はCordaによって改善されるという効果が得られます。

まとめ

さて、分散型でデータベースを共有したい理由が、何となく分かってきたでしょうか？ここで紹介した内容は私自身の回答であり、もちろん唯一の正解ではございません。Whyブロックチェーン？に対し、ブロックチェーンは必要ない、という結論に至る人もいるでしょう。様々なユースケースがありますので、おそらく、中央集権型の仕組みが最適な場面もあるでしょう。ただ、ブロックチェーンを実際に触らずに結論を出すのは早計です。目で見て手で動かして、初めてブロックチェーンの威力を感じることも多々あります（少なくともR3と協働してきた金融機関やパートナーの方々は皆そのような経験をしてきました）。まずは一つユースケースを選択し、実証実験（POC）を始めることが重要です。その際、適切なユースケースを選びが肝心となります。ユースケース選定のポイントは、次回以降のブログでまた紹介したいと思います。