複数組織間のデータ持ち寄り、共有とエンタープライズブロックチェーン
なんの話
- 単に「複数組織間でデータを持ち寄って共有」をやりたい、ってだけでもエンタープライズブロックチェーンはメリットあるかも
- 「ブロックチェーンでないとできない」でなくても「ブロックチェーンのほうがやりやすい」ことで結果として実現可能になるユースケースはたくさんある
イントロ
エンタープライズブロックチェーンって何がうれしいの？という話はこれまでに地道に整理、啓蒙されてきており、また徐々に浸透し理解が進みつつあると思うんですが、これまで多く語られてきたのはどちらかというと「耐改ざん性で信頼の問題を解決する～～」とか「二重支払いの防止で価値の移転ができるようになる～～」とかそういった結構派手めな話だったように思います。そういう派手めなポイントももちろん重要なんですが、エンタープライズブロックチェーンを適応できる射程は本来それらが課題になっている領域よりももっと広いのではないか、地味ではあるがそれでもなお重要で、かつ広大な裾野が存在しているのではないか、と感じています。そのへんを一発整理しておきたいというのがこのエントリを書くにあたっての動機です。
実は昨年10月末のこちらの記事（個人的に2019年のブロックチェーン関連記事 of the Year） note.com
と、昨年11月のこちらの記事 medium.com
がすごくよかったので、これらと併せて読んでもらうことでWhy (Enterprise) Blockchain?の理解の一助となるエントリを書くぞ～～～という気持ちになったもののそのままモンハンをやっていて日々の仕事の忙しさにかまけて3ヶ月くらい経っていました。
というわけで、とてもgeneralなテーマである「複数組織間でデータを持ち寄って共有」におけるWhy Blockchain?の話をしていきたいと思います。ちなみにこのエントリでは「ブロックチェーン」という用語を「分散台帳技術／DLT」と同じ意味で使います。また、「データ」は単に電子化された情報を指していると思って読んでください。
データを持ち寄って共有することのメリット、課題、解決方法
企業はその業務をしていくなかでさまざま情報を扱うわけですが、少なくない場合においてその情報の発生源とは別の企業に情報を渡す、つまり複数組織で情報を共有する必要が生じます。情報の共有は例えば対面や電話口での口頭であったり、紙の書類の原本、写しやFAXであったり、あるいは電子メールやPDFファイル、EDI、APIなどの電子化されたかたちで行われてきました。
こうした情報の共有において特にブロックチェーンを用いることの意義（Why Blockchain?）について、暗号通貨や証券、不動産の所有権など、それそのものが直接価値を表している／価値そのものである情報や、ブランド、産地、来歴、品質などの価値に結びついた情報を扱うユースケースが、ブロックチェーンの耐改ざん性という性質と結びつけて説明されることが多いです。が、必ずしもそういったものでなくても、つまり改ざん等の不正をする動機が通常見いだされないようなところにもブロックチェーンを使う意義はあるはず、という話をしていきます。
サイロ化状態における課題
複数組織が関係することになるある業務に関して、各企業がデータをバラバラにもったうえで都度局所的かつ基本的には1対1での情報共有を行っていく、という至極一般的な状況です。ここではこの状態を便宜的にサイロ化状態と呼ぶことにします。この状態の一般的な課題を以下の「Single Source of Truthがない」「標準化されていない」「データを断片でしか扱えない」という観点で説明します。
Single Source of Truth（SSoT）不在によるリコンサイルのコスト
「その組織内ローカルのみでの正」な情報がバラバラに存在しているというのがこの状態です。他の組織から共有された情報は受け取った組織内で保管されることになりますが、特に相手を欺こうとする悪意がなくても、相手に情報を渡すときに、また、受け取った情報を解釈する際や社内に保管する際に、ミスが生じてその時点で同一であるべき情報に食い違いが生じることがふつうにありえます。同一の事柄を表現しているはずのデータが各組織内で独立して（一致を保証する仕組みのないまま）保持されているのがこの状態と言い換えることもできるでしょう。
だからこそ、やり取りをするたびにお互いの持っている情報の照合や突合、いわゆるリコンサイルに時間と手間、つまりコストが多大にかかることになります。このことは例えば見積もり、契約、検収、請求、支払いといった一連のプロセスを思い浮かべるとわかりやすいと思います。見積もり時に提出された金額は（通常）支払いまで不変のはずですが、契約書を交わす時には見積もり書と金額が変わらないことを、検収時、請求時、支払い時はそれぞれその前のプロセスで交わした情報と変更、齟齬がないことをいちいちお互いに確かめたうえで処理をしているはずです。
これは必ずしも相手の悪意を疑っているわけではなく、同一であることを保証する仕組みがない*1以上は食い違いが有り得ることを想定しなければならない、また、食い違いが有った場合に少なくない損失が生じる（係争になった場合に相手と共通で正とできる情報がないので言った言わない問題、水掛け論になる）ために、手間をかけて確認をしなければならないわけです。
ちなみに以下のついーとをしたところまあまあのｲｲﾈをもらいました。この言い換えは結構わかりやすくなっていると思うので、ぜひ使ってみてください。
ブロックチェーンでよく言う「互 いに信頼しあっていない複数組織が」というのは「互いの情報の照合にコストをかけている、また食い違いが生じたときの解決に多大なコストが生じる組織が」と言い換えたほうが伝わりやすいのではないか、という気がしてきた。
— ガクムラ氏 (@gakumura) January 22, 2020
3者以上の複数組織が絡む業務プロセスの場合には情報共有が一気に複雑化し、かかる時間、手間も増えていきます。例えばGreen社とBlue社の間にある契約が結ばれていることを前提にGreen社とYellow社の間に別の契約を結ぶ、といったケースでは、重大性の高い業務ではYellow社はGreen社から提供された情報をそのまま受け入れるのではなく、Yellow社から直接Blue社に前提契約の締結を確認する必要があるかもしれません。また、ある業務を共同、協力して行うために複数社がそれぞれリソースを提供する条件（日時、場所、コスト負担、利益配分）を協議、合意する、といったケースを考えた場合にも、伝言ゲームをやっているとミスや思い込みによる認識齟齬が生じる可能性があり、それを防ぐためには時には一堂に会するなど相当の手間がかかることも想像しやすいと思います。
こうしたリコンサイルの時間、手間のコストは、複数組織それぞれが「組織内ローカルな正」の情報を保持しており、その写し（であるはずのもの）をお互いにやり取りしたうえでそれらに基づき行動するしかないために生じています。そうではなく、必要な情報を一元的に管理する「場」をつくり、そこに各組織が情報を提出し、以降はその「場」にある情報を「共通の正」として参照し、それのみに基づいて行動するようにすればリコンサイルのコストを少なく、あるいはゼロに、することができるはずです。そのような複数組織の間で一元化された（唯一化された）「正である／正とする情報」（あるいはそれが保持される「場」）をSingle Source of Truth（SSoT）と呼びます。
標準化されていないため情報共有のコスト、遅延が高い
ほとんどの場合、それぞれの企業がそれぞれ独自のフォーマットでデータを持っています。また、相手と情報を共有する、やり取りするうえでもどちらかの都合に応じた独自のフォーマットでのやり取りになります。データの保持方法および共有方法における標準がない、という話です。このうち特に後者、共有方法における標準がないことにより、情報を共有するのにかかる手間が増大し、余計な時間がかかり、また、伝達の正確性にも悪影響が生じます。
同じ種類の情報を送付するにあたりGreen社には紙で、Yellow社にはメール添付のPDFファイルで、Blue社にはEDIで、Orange社にはWebサイト上のフォーム入力で、と各社バラバラな媒体、フォーマットでしか受け入れていないといった状況は頻繁に見かけます。紙に出力して、、、といったやり方はもちろん人手による作業につきもののミスを招き、ミスが少なくないとなればお互いの確認作業にもなおのこと手間をかけることになります。APIやEDIのようにシステム化されてれば機械的なチェックを実装することができる分まだマシとも考えられますが、しかし結局相手先都合に合わせてこちらのシステムを対応させなければならない（あるいはそれができないので手入力でデータを作る）などコストが生じます。
そして、基本的には2者間でのなんらかのメッセージ（紙、PDF、メール、API、EDI…）送受信をベースに行われており、その送受信ごとに人手による確認などの遅延が入るため、特に3者以上の間でのリアルタイムに準じた情報共有には対応しづらいです。
このように、情報共有における標準がない状況は、タイムリーかつ正確なデータ共有を妨げており、ひいてはやはりリコンサイルのコストを押し上げています。
データを断片でしか扱えない
世の中には個々の企業が持っている分だけではそれほどの価値を生まないが、他の企業の持っている分と合わせることで大きな価値を持ち寄ることで（より）大きな価値を生みだすことができるようなデータが多々あります（というかほとんどのデータってそのようなものですよね）。そのうち、個人情報などの機微情報であったり、競争力にダイレクトに関わる情報なので絶対外に出せない、といったデータも多くあるでしょう。が、共有しても特に損失を生じない（非競争領域の情報）、あるいは一定のメリットが得られるのであれば共有することも考えられる（インセンティブ次第で共有できる）といったデータも数多く存在するはずです。
そうした共有が可能なデータを複数組織で持ち寄って扱う（統合する、分析する）ことではじめて可能になる新たなビジネスの創出や、既存ビジネスの効率化というシナリオはさまざまに考えられます。
データ共有を通じて局所最適による限定的な効率化から全体最適でのより高度な効率化へ、というシナリオの典型として言われるのがサプライチェーンです。生産～小売までに必要になる多くの役割を企業が分担していますが、それぞれの企業は（よくて）自分から見て前後くらいの情報までしか把握できておらず、データが分断されています。もしデータを横串でタイムリーに共有、つまり持ち寄ったうえでその全体を対象に分析できれば、サプライチェーンを通して生産、保管、輸送を全体最適となるようにリアルタイムで計画を更新していくことで、それぞれの企業にとって効率化のメリットが生じるはずだと言われています。
また、金融領域におけるKYC（Know Your Customer）共有やAMLの文脈でのフィルタリングリストなどは、規制という外圧から生じる必要性に対処するために各金融機関がコストをかけてそれぞれ実施している、つまり業界全体から見れば重複して行っているなどして非効率な業務を、非競争領域情報のデータ共有することで全体としてのコストを削減し、かつ、より実効性を増すことができるというケースです。
こうしたデータを持ち寄ることで可能になるメリットを享受できていない、というのはサイロ化状態の課題として意識されることは少ないと思いますが、それだけに多くのチャンスが失われているだろうとも言えます。
解1：中央集権的にデータを集中させたうえで共有
前述のサイロ化状態での課題を解決するにはどうしたらいいか？と考えるとすぐに「どこか一箇所にデータを持ち寄り、それを皆が正として扱う」という答えに思い当たると思います。前述の課題、SSoT実現も標準化もデータ持ち寄りもぜんぶ解決です。しかしその答え自体は正しいように思われますが、ではそれをどうやったら実現できるのか？どうやって実現すべきか？という別の問いが生じます。この問いについては基本的にはブロックチェーンの登場以前には、「誰か（1者）にデータを集める」というやり方、つまり中央集権的なやり方しかなかったと考えています。
以下に中央集権的なやり方でのデータ持ち寄りについて、強いプレイヤーに集める vs 中立機関に集めるというふたつのサブカテゴリに分けて説明していきます。
解1A：代表プレイヤーに集める
シンプルに、業務に関わる複数組織（＝プレイヤー）のうちどこかが代表してデータを集めればいいじゃん、という方式です。わかりやすいですね。この方式で代表してデータを集めるプレイヤー（代表プレイヤー）の手元にあるデータストアに提出されたデータが一元的に集まり、これがSSoTになります。そのうえで他のプレイヤー（＝参加者）は自身や他の参加者が提出したデータそのものや、それらの分析結果などの二次データをAPIなどを通じて参照することになります。なおこのとき参加者、および代表プレイヤーが参照可能な範囲の制御（パーミッション）はプラットフォームの機能として備えることが想定されます。
ところで、サイロ化状態について述べた課題の解決には、また、その解決による効果を増大させるには、その取り組みに如何に多くの参加者を巻き込めるか、言い換えるとネットワークを拡大するかが鍵になります（→ネットワーク効果）。ネットワークが拡大せず限定的な範囲にとどまると、やはりその効果も限定的なものになります。さらには、他のプレイヤーが同様の取り組みを立ち上げ、結局プラットフォームが乱立することによりそもそもの課題が解決されていない、といった事態も現実的に想定できると思います。
直観的にわかると思いますが、代表プレイヤーは非常に強い立場に置かれることになります。というのは、結局のところデータが集まっているのは代表プレイヤーの管理下のプラットフォームであり、であればそのプラットフォームへのアクセスを与えるも奪うも代表プレイヤー次第なわけです。とすると、このようなことを実現する場合、ある領域において規模が大きいなど、あるいは資本関係の上位にあるなど、もともと有利な立ち位置にあるプレイヤーがこの役割を担うことが多くなるとも思われます（単純にシステム開発能力、運用体力があるかという問題もある）。この方式には、そうした強い／弱いあるいは有利／不利という関係から必然的に生じる、ネットワーク拡大に対して障害となる以下のような課題があります。
これらにより、この方式を適用できる領域はかなり限られた領域、ユースケースになると考えられます。
公平性の疑念と参加者利便性の置き去りの懸念
代表プレイヤーは最初は参加者を集めるために公平に振る舞うかもしれません。しかし、いったんプラットフォームが動き出し、ネットワークが十分に拡大し、かつ参加者がそれに依存して業務を行うようになると（ロックインされてくると）、代表プレイヤーにとってもはや公平に振る舞うことのインセンティブよりも、自己中心的に振る舞うことのインセンティブのほうが大きくなることがあるかもしれません。すると、代表プレイヤーは自分だけ有利なようにプラットフォームの仕様や規約の変更を行うようになる懸念があります。
また、代表プレイヤーのみが特権的にすべてのデータを分析しやすいかたちで手元に持っています。例えばプラットフォーム開始時には思いもよらなかった（したがって利益配分について取り決めがなかった）価値が分析によって生まれることが後に明らかになったとして、この新たな利用価値による利益は参加者にも公平に配分されるのか、といったことを考えると、多くの場合そうではない（代表プレイヤーが利益の分配を拒み独占する、あるいはそもそも利益の発生を隠蔽する）のでは、とも思われます。
こうした自己中心的な振る舞いにより参加者との間に軋轢が生じ、関係性が悪化することで後述の信用の問題、プラットフォーム利用遮断のリスクが増大することにもなります。
また、プラットフォームの改善に関する決定は代表プレイヤーのみに託されています。最大限公平な代表プレイヤーを想定したとしても、やはり手元にデータがあり自身は利便性高くデータを扱える代表プレイヤーにとって、参加者からの参照アクセスに関しての改善要望の対応の優先度は高くなく、そのため参加者にとっては使いづらいプラットフォームになってしまう可能性が高まります。
信用の問題（透明性、検証可能性の問題）
代表プレイヤーはプレイヤーであるという定義上、プラットフォームで扱っているデータの内容、およびその共有に対して利害関係（ステーク）があります。したがって以下のような不正のインセンティブがあります。
- 覗き見：代表プレイヤーは内容を参照できない、というパーミッションを前提に提供されたデータを実際には参照してしまう
- 改ざん：収集したデータ自体を自身に都合の良いように修正する、あるいは参加者が参照する際に修正したものを引き渡す
- 隠蔽：自身に都合の悪いデータを参加者が参照できないようにする
プラットフォームに透明性がないため、参加者は代表プレイヤーが公正であるかどうかを検証できません。実際にこうした不正をするかどうか、その可能性がどの程度かの問題ではなく、不正のインセンティブがある中で、代表プレイヤーを信じるか信じないか、という根拠の乏しい（あるいは全くない）決断になってしまうこと自体が参加者、あるいは参加を検討しているプレイヤーにとっての問題になります。
参加者の手元にデータがない（アクセス遮断リスク）
代表プレイヤーとの関係悪化により、プラットフォームの利用を差し止められてしまう可能性があります。また、代表プレイヤーが破綻する、あるいは運用コストにメリットが見合わなくなるなどして、そもそもプラットフォームの運用が停止してしまうという可能性も無視できません。こうした事態になると、参加者は自分が提出したものも含め、貯まっていたデータを参照する手段が失われることになります。
とすると、業務継続上の観点から、参加者はほとんど必ず中央集権プラットフォームにあるものと同じデータを自身の手元にも保持する必要を感じるでしょう。また、コンプライアンス上の観点からも、ある種のデータ（例えば契約、会計などに係る情報）はそもそも外部ではなく自身の手元にも保持しておく必要があります。
このようにして参加者は結局手元にもデータを保持することになります。とすると、中央集権プラットフォームにあるデータ vs 自身の手元にあるデータのリコンサイルが必要になってしまうこともあるでしょう。また、手元にあるデータのほうが常に使いやすいため、少なくない場合においてそれが「ローカルな正」として運用されてしまうことでサイロ化における課題の一部が再発することも考えられるでしょう。
競合関係がネットワーク拡大を阻害
ある領域での競争関係において競争相手を（より一層）強い、有利な立場にさせてしまうとなると、参加すれば自身にもメリットがあるとしても競合の関係にある企業はこの取り組みには乗ってこれない、拒否されてしまうというのが常でしょう。
ここまで述べてきた懸念やリスクもあり、こうした競合関係によるネットワーク拡大可能性の制限が問題にならない領域、ユースケースでしかこの強いプレイヤーによる中央集権的データ集中のやり方は機能しづらいと考えられます。
解1B：中立機関に集める
というわけで、プレイヤーのひとりが代表して集める、という方式にはいろいろと大きな課題があり、適用領域が限定されるということを説明してきました。説明してきた課題はいずれも、代表プレイヤーには集めるデータの内容やその利用、共有について営利上のステークがあるため中立ではない、したがって公平性、公正性を（少なくとも合理的には）期待することが難しいことによるものだと言えます。であればプレイヤーではない中立の機関を設けてそこに集めればいいのでは、という解がすぐに浮かぶでしょう。
この「中立の機関」については、大きく以下ふたつのサブカテゴリに分けられます。
- 公的機関：政府系法人、独立行政法人、特殊法人などの政府関係機関や地方公共団体などの行政機関
- 業界団体：ある領域における共通の目的（課題解決、業務効率化など）を達成するために業界内で設立された機関（法人、非法人は問わない）
このうち業界団体については一部のプレーヤー（のグループ）のステークから独立していると言い難く、そのため中立性が（やや～だいぶ）怪しい場合もあると思いますが、そうしたケース（中立機関として扱えないケース）は除くものとします。中立機関はプラットフォーム利用者／ネットワーク参加者に対して個別の利害関係がなく中立に振る舞い、基本的には全体の利得が最大化するように動く、という想定で話を進めます。そうであれば中立機関には不正をするインセンティブもなければ、競合関係もなく、また、参加者を独善的に締め出すようなことをする可能性も低いでしょう。したがって代表プレイヤーに集める方式に関して挙げた課題はおおよそ対処できていることになります。
中立機関が適用できる領域は限定的
一方で、こうした中立機関を利用できるケースというのはかなり限られた領域にしかならないのではないかとも思われます。
公的機関がこうしたことを担当できる領域はもちろん公共的な意義があり、かつ市場的、営利的なメカニズムでの対応、解決が難しいごく基礎的なエリアに限られます（例えば土地登記簿、戸籍、住民基本台帳ネットワークなど）。
そして業界団体についても、上記の通りの振る舞いを期待できる、かつ、システム開発や保守を担うことができる業界団体は、金融などの特に外圧が強い業界くらいにしか存在していないのではないかと思います。データ持ち寄りの取り組みのために新規に団体を立ち上げるというのも、システム開発＋運用費用の他に業界団体の法人としての運営費用がオーバーヘッドとして生じるなど、一気にハードルが高くなってしまい、やや機能しづらいのではないかと思われます。
参加者の手元にデータがない
代表プレイヤー方式について述べたのと同様に、中立機関方式においてもやはり参加者の手元に持ち寄ったデータそのものはありません。一方的、独裁的な決定によりアクセスを遮断されるリスクは代表プレイヤー方式と比較したときにずいぶん小さいと考えられますが、やはりコンプライアンス上の要請があれば手元に重複してデータを抱えておく必要も生じます。以下に述べる使い勝手の問題もあり、中央集権プラットフォームにあるデータ vs 自身の手元にあるデータのリコンサイルが必要になってしまうこともあるでしょう。
利便性の改善が進みづらい
この中立機関に集中させる方式においても、データを集めるデータストアは中立機関の手元にのみ存在しています。したがって、参加者のデータ入力、データ閲覧の利便性は中立機関の提供するプラットフォームのAPIなどのインターフェースに依存することになります。また、集まったデータに対してのどのような分析を行うのか、そこから如何に価値を汲み出せるのかも、やはり中立機関の判断、また、能力に依存するでしょう。
初期の仕様決定、また、その後の改善について、中立機関が参加者からのニーズを汲み上げたうえで、限られたリソースの中で対応の優先順序を判断し、参加者と合議のうえでプラットフォームの向かう方向を決めていくことになるでしょう。ここで中立機関の判断は、参加者全てに対して中立性、公平性を保つという前提があるため、一部の参加者だけを利するものや、あるいは逆に一部の参加者から反対意見が出るような仕様の取り入れ、変更は難しくなります。こうした条件下では、最大公約数的な、誰にとっても使いづらいものができあがり、以降の改善も迅速には進みづらいという問題が生じやすいでしょう（公的機関によって提供されているシステム一般が、あまり使いやすいものとは言いづらく、改善要望も対応されづらいことを思い出してください）。
解2：ブロックチェーンにより水平にデータを持ち寄って共有
ここまで中央集権的なデータを集中させるやり方の課題について長々説明してきました。というわけでようやくブロックチェーンのお話です。
ご存知の通り、ブロックチェーンでは同一の内容の台帳を複数の組織が分散して所有／運用／管理する複数のノードで保持します（分散台帳）。台帳の内容が同一であることがシステム的に保証されているため、SSoTを複数組織で分散して実現できるということになります。また、参加者がネットワークにデータを持ち寄ることは、即ち他の参加者とデータを共有することと同義になっています。これらがブロックチェーンが可能にすることです。
エンタープライズブロックチェーンと呼ばれる分野では、現在のところ特にこの台帳を持つノードから成るネットワークを決められた組織内で閉じたかたちで運用すること（Permissioned／コンソーシアム型ネットワーク）が多いです。エンタープライズブロックチェーンで用いられるブロックチェーン基盤には代表的なものとしてはHyperledger Fabric、Corda、Enterprise Ethereum（Quorum／Hyperledger Besu）があり、いずれも「複数組織がノードを所有／運用／管理しつつネットワーク内でデータを持ち寄り、共有する」ことを前提とした、また、それを実現するための機能が備わっています。言い換えると、ネットワーク内のいずれか単一の組織の意向のみでネットワーク全体にとって重要な判断が為されてしまう中央集権的なガバナンスではなく、合議やコンセンサスによりそうした判断が為されるような非ー中央集権的なガバナンスを実現する仕組みが備わっています。
ここでは複数組織＝プレーヤーがノードをそれぞれ所有／運用／管理してブロックチェーンネットワークを形成し、そこでデータの持ち寄りと共有を中立機関を介在させずに行うことにどのようなメリットがあるか、また、独特の課題があるかについて説明します。
Pros
データの持ち寄りと共有を（エンタープライズ）ブロックチェーンを用いて行った場合には、以下の性質により、前述の中央集権的なやり方で問題、懸念、リスクとして挙げたポイントを以下のように解決、あるいは回避できます。
手元にデータがあることによるアクセス遮断リスク回避、利便性向上
台帳を保持するノードを自前で所有／運用／管理することは、つまり参加者の手元にデータがあるということです。これにより、例えあるネットワーク内での合議によってある参加者のネットワーク利用が差し止められたり、あるいはネットワークの運用そのものが停止されたとしても、そこまでに台帳に記録されたデータは利用可能なかたちでその参加者の手元に残ることになります（一方でその参加者は新たなトランザクションは発行できない、つまり台帳に追記を行うことができないことになります）。
これにより参加者は、中央集権的なやり方（代表プレイヤー方式、中立機関方式いずれも）でほとんどの場合必要になるであろう、皆がデータを持ち寄っているプラットフォームにあるものと同内容（であるはず）のデータを手元に重複して保持しておくことが不要になります。したがって、「持ち寄ったプラットフォームにあるデータ vs 自身の手元にあるデータのリコンサイル」といった副次的な手間が生じる心配も小さいでしょう。
アクセス遮断リスクについて懸念がなくても、コンプライアンス上の要請によりデータを自身で保持しなければならないケースについても対応できています。この要件は扱う機微データを扱う場合や、データ共有のネットワークが国をまたぐ（法令、監督機関が複数種類ある）場合に多く存在し、そうしたユースケースを実現しやすいことにつながります。
また、手元にデータがあるということは、中央集権的なやり方で想定されるAPIによる参照に比べ、集計、分析、データ統合などのデータ利用が格段にやりやすくなります。ただしこうした高度な参照操作を台帳上／オンチェーンで行うのは多くのブロックチェーン基盤が苦手としているところなので、（直前の段落で述べたこととやや矛盾するようではありますが）台帳の内容をRDBに複製したうえで、それらを大得意とするRDBで行うことが多いです*2。このようなデータ利用については参加者それぞれが自身の都合で改善していけるので、中央集権的なやり方に比べて参加者それぞれにとっての利便性を追求しやすいと考えられます。
透明性と検証可能性
しばしば「ブロックチェーンは信用／信頼の問題を解決する」というようなことが言われますが、これはブロックチェーンは信用／信頼、つまり検証できないため信じるしかないという事態、が問題にならないよう、システムが参加者にとって透明性を持ち、検証可能であることを実現できるように周到にデザインされているからです。従って、「解決する」というよりは「回避する」というほうがより実態に近いと考えています。
ブロックチェーンを用いていても代表プレイヤー方式についてで述べた不正＝一部のプレイヤーにとってだけ有利になる仕様を作り込む余地は存在します。しかし、重要なのはそうした不正が発見可能であり、また、責任追求が可能であるという点です。であれば、ネットワーク参加者がお互いの法的、また社会的なアイデンティティが明らかになっているエンタープライズブロックチェーンの分野では、不正を作り込むインセンティブよりも責任追及のリスク、デメリットのほうが大きく、したがって参加者が十分に合理的であるという前提を置けば不正をするという判断は為されないと考えてよいでしょう。このようにして覗き見、改ざん、隠蔽といった不正が起きるリスクを排除あるいは極小化できます。
公平性、水平性によるネットワーク効果増大容易性
前述の通り、エンタープライズブロックチェーンで多く用いられるブロックチェーン基盤がシステム的に備える機能や特性により、非ー中央集権的なガバナンスのもとで、上下関係や特権関係がなく、水平かそれに近いかたちでデータの持ち寄り、共有を行うことができます（そうしないこともできます）。これにより競合関係にあっても、また、互いに完全には信頼し合っていない企業同士であっても、同一のネットワークに参加してメリットを享受することが実現しやすいです。ネットワーク拡大＝データ共有、持ち寄りによる効果、価値の増大を阻害する要因が少ないと言えます。
運用コスト、責任の分担
「参加者全員の要望、要請などの要件を単独の責任で実現する中央集権的なプラットフォーム」を構築、運用する場合に比べて、「参加者それぞれがそれぞれの要件に合わせて運用するノード」は単品で見れば基盤としての構築、運用コストが低くなりやすいです。前者では将来的なネットワーク拡大時に必要となるであろう可用性やパフォーマンス、スケーラビリティ要件をプラットフォーム開始時にある程度織り込んでスタートしなければならないため、初期から運用コストが大きくなりやすいかもしれません。
他方、後者ではネットワーク拡大につれてノードが増えるにつれ全体の運用コストは増えていきますが、初期での運用コストは比較的小さく済むという利点があります。ネットワークが拡大する＝プラットフォームの重要性が上がっていくことと、ノード増加により可用性が高まることがリニアに結びついているというのも運用コスト構造として受け入れやすいと思われます*3。
Cons
一方で、以下のような課題あるいは限界があります。
まだ技術的にこなれていない
少なくとも現状では、いわゆる「データベース」を使って中央集権的なソリューションを実現するよりも、非ー中央集権的なソリューションの実現は「技術的に」少々、あるいは大いに、難しいでしょう。こうした「技術的に」と書いた現状のソリューション実現の難しさは、以下に分解することができます：
- プロダクト側の問題：各ブロックチェーン基盤の製品機能としての成熟性。また、公式／非公式問わず公開され入手可能な情報の量と質。
- ユーザー（プロダクトの周辺環境）側の問題：各ブロックチェーン基盤、およびブロックチェーン一般の特性についての市場側の理解。また、各企業内、および市場を通じてアクセス可能なエンジニア総体として持っている構築、運用、管理などのノウハウ、経験値の量と質。
このうちプロダクト側の問題については、依然として代表的なブロックチェーン基盤では速いスピードで開発や情報公開が進んでいるため、すでに解消されている、あるいはそれほど遠くなく解消されるでしょう。また、BaaS（Blockchain as a Service）と呼ばれるマネージド・サービスも提供が増えてきており、ブロックチェーン基盤の構築、運用およびブロックチェーン利用アプリケーションの開発容易性が高まっています。
一方でユーザー（プロダクトの周辺環境）側の問題については、各企業でキャッチアップのために動く、オープンな勉強会*4などを通じてエンジニア間でノウハウを共有していくなどの動きが必要です。
また、ここまでProsに書いてきたようなメリットのほとんどは、ネットワークの参加者がノードを分散して所有／運用／管理していることが前提で実現されます。翻って現在行われているPoC、技術検証や、すでに商用／本番稼働を迎えているプロジェクトを見てみると、いずれか単一のITベンダーやプレイヤー、あるいは専用の合弁会社などの組織がノードの所有／運用／管理を一手に引き受けているケースが多いように見えます。こうした状況も、前述の通りノウハウを蓄積、共有することで自前でノードの世話をできる企業を増やしていき、本来の姿であるより分散したかたちに近づけていく必要があるでしょう。
全体でのシステム運用コスト
Prosのところで述べたように、「参加者全員の要望、要請などの要件を単独の責任で実現する中央集権的なプラットフォーム」を構築、運用する場合に比べて、「参加者それぞれがそれぞれの要件に合わせて運用するノード」は単品で見れば基盤としての構築、運用コストが低くなりやすいでしょう。一方で、ネットワーク全体での総計を見たときには（特にネットワークが一定程度拡大してきたのちは）、機能という面では同一である複数ノードが各参加者に冗長に運用されるため、中央集権的に実装するよりシステムの運用コストがかかっているということもあり得ます。
この点については、①そのプラットフォームから参加者が享受するメリット ②そのプラットフォームを構築、運用するための（現在および将来の）システム的なコスト ③中央集権的に実現する場合に比較しての非ー中央集権的に実現することのビジネス的な容易性、優位性 を総合的に比較したうえで受け入れる／受け入れないを判断することになるはずです。
書き込みパフォーマンスの限界と読み取り整合性
ブロックチェーンには複数の（必ずしも互いに信頼し合っていない）組織がノードを所有／運用／管理し、そのノードの保持する台帳に書き込みを行うトランザクションについて、コンセンサスを取りながら書き込みの可否を検証していくという性質があります。この点から、単一の組織が所有／運用／管理するデータストアにデータを集中させたうえで共有する中央集権的なソリューションに比べ、どうしても書き込みのパフォーマンスの限界が低くなります。大いにノード間のネットワーク距離、また、トランザクションの内容にも依りますが、代表的なエンタープライズブロックチェーン基盤では概ね数百～数千TPSといったところが限界とされています。
また、ブロックチェーンは一般に各ノードの台帳間のトランザクション特性はBASE特性となっており、読み込み整合性については結果整合性しか担保されていません。つまり、トランザクションが発行されて台帳上での更新が起きた場合、その更新がすべてのノードに伝播するまでの間に、古い（最新のトランザクションが反映されていない）状態の台帳を読み取ってしまう事態は排除されていません。読み取りについてシビアな整合性（常にどのデータストアレプリカから読み取っても値が同じであること）を要求するユースケースでは、なんらかの工夫が必要になります。
まとめ、あるいはWhy Enterprise Blockchain?
ここまで、「データの持ち寄りと共有」というテーマに対して①サイロ化状態における問題、課題 を整理したうえで、②その中央集権的なソリューションにおける課題 と、③ブロックチェーンによる非ー中央集権的なソリューションにおけるメリットおよび課題 について長々と書いてきました。このエントリは③について、特にそのメリットを説明するために書かれているわけですが、ここまで読んできて「データの持ち寄りと共有」というテーマに関して、（エンタープライズ）ブロックチェーンのメリット、優位性により、「ブロックチェーンでないとそもそも実現できない」わけではないが、「ブロックチェーンのほうがやりやすい（領域がある）」ことがあるとなんとなく理解いただけたのではないでしょうか。
最初のほうに書いた「耐改ざん性で信頼の問題を解決する～～」とか「二重支払いの防止で価値の移転ができるようになる～～」とかのブロックチェーンならではな特性を活かしたユースケース（例えば金融領域のCBDC、RTGS、証券プラットフォームなど）はこれからもエンタープライズブロックチェーンの適用領域の王道であり続けるでしょうし、そのリファレンスとしての重要性、存在感はなお増していくことはあっても衰えることはないでしょう。しかしそうしたユースケースは、「数」としてはそれほど多くないと考えています。
それに対して、「複数組織間でのデータの持ち寄りと共有」というのは至極ありふれた、どこにでもあるテーマです。エンタープライズブロックチェーンは、あるパターンにおけるデータの持ち寄りと共有をやりやすくします。このテーマでエンタープライズブロックチェーンを適用することについてよくある批判が、「データベースでもできるよね」というものですが、そのとおり、技術的には実現できるでしょう。しかし、ではなぜ既にデータベースで、つまり中央集権的なやり方でとっくにできていないのでしょうか？ビジネス的な要素、つまり競合関係や参加者それぞれのコストとリスクについての考え、まで含めて考えたときに、中央集権的なやり方では実現が困難だったからではないでしょうか。ブロックチェーンの登場により非ー中央集権的なやり方という選択肢が増えたことによって、中央集権的なやり方しか取れなかった時代に比して、ソリューション実現によって得られるメリットとソリューション実現の難しさおよびコストのバランスが変わり、「これなら実現を試みたほうがいい」側に傾くケースがあると考えられます*5。
過去に発見され検討されてきた（そして断念された）もの、また、現在まだ発見されていないものも含めて、複数組織間でのデータの持ち寄りと共有よって解ける課題は無数にあるでしょう。そのうちこの「バランスの変更」によってトライが可能になる、トライするべきとなるものは、現時点でもかなりの数存在しており、今後ブロックチェーン技術およびその周辺環境が成熟していくにつれてますます増えていくと考えています。このような「単に複数組織間でのデータの持ち寄りと共有をやる、ただし非ー中央集権的に」というものが、地味ではあってもエンタープライズブロックチェーンのユースケースの「数」としては圧倒的多数になると想定しています。
というわけでみなさんも「複数組織間でのデータの持ち寄りと共有」によって解ける課題がないか、果たせる効率化がないか、実現できる新たなビジネスがないかをちょっと自分の身の回りの業務を見回して探してみてください。ひょっとすると、エンタープライズブロックチェーンがその実現を地味に助けてくれるかもしれませんよ。
*1:自身内部でのプロセスについてはワークフローシステムなどで対応可能かもしれませんが、相手の業務プロセスについては確認しようがありません
*2:Ethereumを利用している場合、台帳の更新イベントを拾って更新内容をRDBにも伝播させていくIndexingと呼ばれるやり方を取ることが多いようです。Hyperledger FabricをベースとするOracle Blockchain Platformでは、台帳の内容をOracle DBに複製する機能が備わっています。Cordaについてはよく知らないですが、もともと台帳のバックエンドにRDBを使っているので特に不要なのかと想像しています。
*3:参加者が自分のノードの可用性を確保するインセンティブがなかった結果、ネットワークとしての可用性が低下してしまうというコモンズの悲劇問題が生じる可能性もあるのでそのへんの規約の整備は必要です
*4:東京ではBlockchain GIGやBlockchain Engineer Night、blockchain.tokyoなどのエンジニア向け勉強会が運営されています
*5:最近の新型コロナウィルス関連で中国でブロックチェーンを使って実現されているソリューションを眺めていると別にブロックチェーンじゃなくてよくない（政府が中央集権的にやればよくない）？と思うものが多いんですが、中国では既にブロックチェーンをいわゆるデータベースと同程度にカジュアルに使える程度にノウハウが蓄積されており、「どっちでもいいならブロックチェーンでやっとくか」みたいな状況になってるのかも
