サマリー
- 購買・サプライチェーン領域へのブロックチェーンの適用で、大きな効果が見込めるのは「企業間の文書/取引情報管理」です。(それ以外の領域への適用は、疑ってかかる必要があります)[第4章参照]
- 効果が上がる領域に導入する場合にも、確実にチェックしておくべき留意事項(後述)があります。[第5章参照]
1.はじめに～この記事の意図と狙い
2018年1月に東京、3月に大阪と購買ネットワーク会で「2018年“買えない”時代のサバイバル術～未曾有の時代にどう対応していったら良いのか？」というタイトルの講演機会をいただきました。現在、電子部品や機械部品などでモノ不足が発生し、”買えない”という購買部門にとってはゆゆしき状況が生じています。デフレ経済に慣れた身にとっては、未曾有の事態です。
しかしこの企画を提案した2017年秋の時点では、「本当にそんな深刻な事態が起きるのか、出席者が興味関心を持つテーマになるのか？」という疑心暗鬼の意見が多数ありました。にもかかわらず、敢えてこのテーマで押し切りましたが、現在の問題の重大化を見るに、ちょっとした未来予測として成功したかなと、少しばかり私自身が得意げになっていたところもありました。
すると「じゃあ次の話題が沸騰するトピックスは何？」と聞いてくださる方が何人か現れました。それには「たぶん半年後ぐらいにブロックチェーン」と私はお答えしてきました、そして3月の大阪での講演の際にはブロックチェーンに関するメモ資料を参考資料(お土産資料)としてご出席者にご提供もしました。
しかし今回は私の予想に反して、ブロックチェーンはもっとずっと早期に大きな盛り上がりとなりました。現在では一大ブームの熱狂の渦中といっても過言ではないと思われます。しかしブームの常として、購買担当者が具体的に社内導入を図る際の具体性がある説明材料の提供は非常に乏しい状況です。ブロックチェーンの話を振られた購買担当者の間では、「世間一般で導入が叫ばれているので、我が社も導入すべきです」などの苦しい言い訳をしなければならないような状況にも出てきています。
そこでこの記事では、購買実務担当者、特に仕組みの企画・導入を担当としている方が、①購買ブロックチェーンとはどのようなものであるのか、②購買ブロックチェーンではどのような導入メリットが期待できるのか、③購買ブロックチェーンを導入するときのチェックポイントは何かを、社内に説明し、さらには導入策を検討する際の基礎知識を提供するを目的として書いてみました。
2.ブロックチェーンとは何か
購買領域への適用に入る前に、ブロックチェーンとはどのようなものなのかから、話を進めていきたく考えます。そして一言で表現するならば、ブロックチェーンとはデータの格納・蓄積の仕組みです。例えば、「仮想通貨」はブロックチェーンというデータの格納・蓄積の仕組みを使って、実現されているものです(仮想通貨=ブロックチェーンではありません）。
主要な特徴として、以下の３つが挙げられます。
- 取引記録(トランザクション)を複数個取りまとめたものに、その取引記録が正しいものであることを証明するデータ（図1の青枠）をくっつけたものを「ブロック」という名前で取り扱います。
- ブロックが前のブロックのハッシュ値(ハッシュ計算結果)を持っている(図1の青枠参照)ことで、ブロック間の前後関係・関連付けがされています。この「ブロックの連なり」が鎖のように見えることから「ブロックチェーン」と呼ばれます。
- このブロックチェーン (連鎖したブロック)は、接続されている複数のコンピュータに保管されています。
このように、複数の取引記録がブロック内に保管されることから、ブロックを台帳(複数の取引記録が綴じられているもの)に見立て、かつ複数コンピュータでブロックを分散保管することから、ブロックチェーンを「分散台帳」と呼ぶことがあります。
先程、仮想通貨=ブロックチェーンではないと記述しました。しかしブロックチェーンは仮想通貨「ビットコイン」を起源として発達してきました。以降でブロックチェーンとはどのようなものかをまず整理したく考えます。しかしこのような経緯があるため、整理はビットコインでのブロックチェーンの適用方法を述べるところから始めようと思います。
その後、仮想通貨に留まらずに、購買・サプライチェーン業務などの他分野へ活用できるのではないかとの提起があり、今や仮想通貨以外での適用検討が大きなブームになっています。購買・サプライチェーン領域への適用もその一環です。
ただし非仮想通貨以外への適用の際には、仮想通貨での本来技術の不要部分の削ぎ落としと、必要部分の強化が行われました。そこでこの記事では、仮想通貨の部分に引き続いて、購買・サプライチェーン領域に適用するための、どのような機能変更が発生しているのかに、論を進めていく予定です。(ただし既に仮想通貨でのブロックチェーンに詳しい方はこの章の以降を読み飛ばしていただいても構いません)。
(1)仮想通貨でのブロックチェーン
ブロックチェーンは、仮想通貨ビットコインを実現するための技術として、2008年にSatoshi Nakamotoを名乗る人物が発表した論文「Bitcoin: A Peer-to-Peer Electronic Cash System」で提起された仕組みです。論文の題名にもあるように、この論文では電子通貨(Electronic Cash)の実現が検討されました。その結果、「誰から誰にいくら受け渡しが行われた」という記録が完全に把握できれば、実体通貨とは別の「電子通貨」の実現できることが提起されました。
(ここで貨幣論の深みに入るの本意ではありませんが、)仮想通貨とは「譲渡ができるポイントプログラム（例えばTポイント）」のようなものです。ご存知のように、Tポイントは譲渡ができず、1ポイント=1円といった固定レートで、円という実体通貨と結びついてます。しかし、Tポイントが保有者間で譲渡できるとなればどうでしょうか。
例えば「αさんだけが10ポイント持っている（システムからもらった）」という初期状態の記録があるとします。ここでαさんはβさんからキャンディを受け取り、その対価として「αさんはβさんに10ポイントを渡した」、βさんはγさんからガムを受け取り、その対価として「βさんはγさんに8ポイントを渡した」という所有の移転記録があるとします。するとこれらの記録を総合すると、「αさんには現在ポイントはないが、βさんは2ポイント、γさんは8ポイントの何かと交換できる、譲渡可能なポイントをもっている」ことが明確にできます。
このように関与者の皆が譲渡記録を参照でき、誰がどどのような経緯でポイントの授受を行い、現在どのくらいのポイントを所持しているかが共有化でき、その所持の正当性が理解できるのならば。そこで受け渡しされてる「譲渡可能なポイント」は”お金”と同等の働きができる、すなわち「仮想通貨」として通用させることができるのではないでしょうか。
しかしそのためには、改ざんも欠落も無い譲渡記録/取引記録が保持できる仕組みがなければなりません。そのために考案されたのが「ブロックチェーン」です。
(2)ビットコインでは、ブロックチェーンがどのように動作するのか
仮想通貨ビットコインでは、どのように取引が記録されるのでしょうか。
順を追って見ていきましょう。
ビットコインでは、「誰から誰にビットコインが受け渡された」という取引記録が発生すると、取引記録のブロックの作成・保管を担当する全てのコンピュータに伝送されます。この図では①～⑤の全てに送られます。そして全てのコンピュータがブロックを作成する処理に取りかかります。(なお図では、コンピュータ③を、コンピュータ①～⑤の代表例として、その動作を表示しています)
各コンピュータは、まず取引記録を複数個取りまとめます。そして取りまとめの結果できた取引記録群のハッシュ値の計算を行います。ここで「ハッシュ値」という言葉がでてきました。これはハッシュ関数という特別な関数を使って算出されるものです。特別というのは、この関数がインプットが少しでも異なると、異なるランダムな値を算出するもので、しかもアウトプットの値から、どのようなインプットがあったのかを逆計算することができない性質をもっているからです。すなわち、ハッシュ値(アウトプット値)から、インプットされた取引記録の値を推定することはできません。アウトプットのハッシュ値は、インプットの取引記録群をハッシュ関数に投入してみることでしかわかりません。
なお、計算に用いるハッシュ関数プログラムは、ビットコインシステムの一部として、①～⑤までの全てのコンピュータに同じものが備わっています。したがって計算対象(インプット)とする取引記録群が同一であれば、取引記録群のハッシュ値は同じになります。
そして次の段階から、各コンピュータの間で「当てずっぽうの競争」が始まります。
ビットコインでは、前述の取引記録群のハッシュ値(確定値：図では”5000a0f”)と前ブロックのハッシュ値（確定値：図では”1590a08″）と組み合わせてハッシュ関数に投入したときに、ハッシュ値がある値以下(先頭にゼロが規定数並ぶ値)になる値(ナンスと呼ばれます)を求めなさいという命題が、各コンピュータに課されています。例えば上図では、先頭に６個ゼロが並ぶハッシュ値が要求されています。
しかし前述のように、ハッシュ関数ではアウトプット値は計算を行ってみるまでわかりません。そこで各コンピュータは、当てずっぽうで適当なナンスを設定してハッシュ計算を行っていくのです。例えば、コンピュータ③は、１回目に”34fb78e0″というナンスを設定してハッシュ計算を実施してみました。しかしその結果算出されたハッシュ値は”bfd53050”となりました。先頭にゼロが１つも並んでいない、まったく的外れな結果です。これではどうにもなりません。
でも当てずっぽうにナンスの値を設定して、何回かハッシュ値の算出を行っていくうちに、条件に合致する結果が出ることがあります。図では、ｎ回目の算出で、コンピュータ③では条件を満たすハッシュ値が出ました。
もしここで他のコンピュータから見つけたという通知が着ていなければ、コンピュータ③にとってはシメたものです。コンピュータ③は、他のコンピュータに条件に合致する計算結果になったナンスを含むブロックを送って、確認を依頼します。ナンスの値が指定されていれば、ハッシュ値の計算は即座にできます。そこで各コンピュータは、コンピュータ③が送ってきた、ナンスを含めたブロックのハッシュ値の計算結果が条件を満たすものかの確認計算を行います。そしてその結果が条件を満たすと確認されると、確認した各コンピュータはそのブロックを自らに格納・蓄積し、次のブロックの作成作業に移っていきます。
そして(格納されたブロックに後続ブロックが付いていくと)、条件を満たすナンスを見つけたコンピュータ③には報酬のビットコインが与えられます(ビットコインシステムからコンピュータ③に報酬分のビットコインを渡したという取引記録が作られます)。
この作業がマイニング(採掘)と呼ばれています。2018年時点では、1ブロックを採掘すると12.5ビットコイン(BTC)が報酬として貰えます。現在１BTCは約100万円ですので、1,250万円分がもらえることになります。またビットコインでは、先頭に並ぶゼロの桁数の条件は適宜調整され、概ね10分間に１つの新ブロックが形成されるようになっています。
(3)ビットコインの耐改ざん性と自律性
もう一度、図１を見てみましょう。
ビットコインでは、このように当てずっぽうで偶然発見されるナンスに基づいたブロックのハッシュが連鎖したブロックチェーンが各コンピュータに蓄積され、重複保持されていきます。
ここで、ブロックAの取引記録を不正に書き換えようと企んだとしましょう。しかし取引記録を書き換えると、取引記録群のハッシュ値が変わってしまいます。すると書き換えを正当化するために先程の当てずっぽ処理を再度行って、新しいナンスAをみつけなければならなくなってしまいます。しかもその影響は書き換え対象のブロックだけに留まりません。前ブロックのハッシュ値を持つ後続のブロック(BやC)での訂正も必要になります。それらのナンス探索ももう一度やり直して、全部のコンピュータのブロックの書き換え(新しいチェーンの作成)が必要になるのです。ブロックチェーンの取引記録を改ざんすることが不可能と言われている理由がここにあります。
またビットコインでは、マイニングでナンスを見つけた場合に報酬が与えられる仕組みを導入したことで、仕組を自律的に動作できるようにしました。報酬を得ようとする参加者が新規ブロックをチェーンに追加する作業を自主的に実施し、誰かが運用資金を投入しなくても、運用が永続的に続いていく仕組みとなっているのです(採掘に成功すれば1250万円相当のビットコインの報酬が貰えますので、皆、頑張ります)。
これまでに見てきたように、ビットコインでは取引記録をそのまま格納するだけの仕組みでした。しかしその後開発されたイーサリアムでは取引データを処理するためのプログラムである「スマート・コントラクト」を設定し、取引記録をブロック格納前に処理を実行できるように仕組みの拡張が行われました(この機能は、以降で述べるブロックチェーンビジネス適用にも引き継がれています)。
※なお、仮想通貨および次のHyperledgerの部分では、内容が複雑過ぎないように簡略な記述とした部分が多々あります(個々の取引記録の暗号鍵での保護は省略、ハッシュ値の桁数の短縮化して表示など)。どうかご容赦ください。
3.ブロックチェーンの購買・サプライチェーン領域への展開
(1)ビジネス適用に際して、マイニング機能が削ぎ落とされた
2009年に可動したビットコインは、様々な攻撃にも耐え、稼働上の問題もなく、現在まで継続しています。するとビットコインで採用しているブロックチェーン(分散台帳)技術を、他の分野にも適用できないかという検討が始まりました。
その1つがこれから説明するHyperledger(ハイパーレジャー)になります。
しかしビジネス領域に適用する場合には、仮想通貨の仕組みから削ぎ落とされたものがあります。それがマイニング(採掘)です。仮想通貨では、自律的に仕組みを動かす上で重要だったマイニング(採掘)ですが、ビジネス領域で特定参加メンバーが相応の利用料を払って情報を共有する仕組みを考えた場合、やたらに処理時間とコンピュータパワーがかかるマイニング(採掘)が不要の長物となりました。
そこでこの不要分を削ぎ落としつつ、ブロックチェーンの改ざんも欠落もない確実な情報蓄積の仕組みは適用する方向で、ビジネス領域のブロックチェーンの仕組み(コンソーシアム型)は設えられました。
比較すると下表のようになります。
(2)Hyperledgerプロジェクトの概要
仮想通貨以外のビジネス領域で、ブロックチェーン技術を適用するために活動しているのがLinux財団が主催するハイパーレジャー(Hyperledger)プロジェクトです。とはいっても、このプロジェクトがスタートしたのは、2015年12月。実はまだ2年強しか経っていません。仮想通貨イーサリアムもβ版の稼働は2015年7月です。にもかかわらず、現在ブロックチェーンが流行り言葉のように異常な盛り上がりになっています。そしてそれに伴い、夢のような話など様々なノイズも出てきていますので、現状を整理し、十分な留意をもって、冷静な対処を心がける必要があると感じています。
ところでハイパーレジャープロジェクトですが、以下の４つをミッションとしています (ミッション・ステートメントを要約して箇条書きにしてみました)。
- その上で仕組み構築できる分散台帳の枠組みとオープン・プログラムコードの作成
- ソリューション提供業者やユーザが集う技術コミュニティの結成
- 関連技術領域(エコシステム)で主導的な役割を果たしている人々の参加促進
- ハイパーレジャープロジェクトの活動を行っていく際の拠り所やの作業基盤の提供
すなわち、ハイパーレジャープロジェクトは、ブロックチェーン技術を使って、その上に誰もが様々な業務システムを構築できるような、プログラム内容が公開された基盤を作り出そうとしているプロジェクトです。
そして現時点で実用化済、もしくは間もなく実用化が期待できる実行基盤(ハイパーレジャー・フレームワーク)として、以下の３つが存在しています。その中には、「Iroha」という言葉からわかるように、日本企業が積極関与している「Hyperledger Iroha」のようなものもあります。
(3)ビジネス領域用ブロックチェーンのHyperledgerはどう動作するのか
では、ハイパーレジャーでの取引はどのように実行されるのでしょうか。Hyperledger Fabricを例として見ていってみましょう。
要点は、前述したように、仮想通貨でのマイニング作業を削ぎ落としているところにあります。図に合わせて、動作を説明していきます。
①まず、ユーザが記録したい取引記録をアプリケーションから投入します。するとユーザ(アプリケーション)から投入された取引記録は、「Application SDK」で受け付けられます。
②次にApplication SDKが、取引記録に対する処理とハッシュ値の計算を行う、特定の「Endorsing peer」に、取引記録を渡します。
③Endorsing peerは、取引記録への処理を実行後、取引記録のハッシュ値を計算します。そしてその計算結果と、前の取引記録のハッシュ値を「RWset」という領域に設定し、取引記録と合わせて、Application SDKに返却します。
ここで重要なのは、以下の２点です。
- 仮想通貨のマイニング作業のような、ナンスを使った当てずっぽうのハッシュ値探索は行いません。ハッシュ値は１回のハッシュ計算で求められます。
- ハッシュ計算と取引記録の処理は、取引記録を保管する全peerで行われません。特定数の指定されたEndorsing peerが実施するのみです。
引き続いて行われるのが、ハッシュ値の正当性を確認して、取引記録を各peerに格納する処理です。
⑤Application SDKは格納する「取引データとRWsetの組み合わせ」を「Ordering Service」に送ります。
⑥Hyperledger FabricをVersion 1.0(実用段階)に上げるときに、並行して複数の取引記録の処理が行えるようにしました。その際に、取引記録の実行順序を指定しないと前後して矛盾した変更が行われる危惧が生じたため、実行順序の順に整列した送信ブロックを作成する目的で導入されました。ただし話が複雑になるため、ここでは取引記録をまとめて取引記録を確認・蓄積機能に送る役割としておいてください。
⑦取引記録を蓄積するPeerは、送られてきたRWsetの内容を確認し、正しければ取引記録を新たな連鎖として格納します。なお、③の処理を担当せずに、取引記録の確認と格納のみを行うpeerも「Committing peer」として存在させることができます。
⑧格納が正常にできたかのステータス情報は、各PeerからApplication SDKに送られます。
⑨そして処理結果は、Application SDKから業務アプリケーションに連絡されます。
（なお、エラーが通知された場合にどう扱うかは、アプリケーションに委ねられています）
このように、当てずっぽうナンスによるハッシュ値の探索などを省いてコンピュータパワーの使用量を節減し、かつ処理速度を上げながら、改ざんや脱落が起こらないデータ保持というブロックチェーンの長所は活かそうとしているのがHyperledgerの特色です。
(4)購買・サプライチェーン領域での適用事例（１）～ 原産地追跡
Hyperledgerは、購買・サプライチェーン領域でどのような適用事例があるのでしょうか。
1つ目は、農林水産物や鉱物の原産地や流通経路追跡です。
有名な事例としては、Hyperledger Sawtoothの名前の元にもなった、水産資源の追跡があります。以下はHyperleger Sawtoothの適用事例(ユースケース)紹介ビデオに出てくる水産資源の追跡の全体範囲図です。さらにビデオを見ると、詳細がよりわかります。
具体的には、Hyperledger Sawtoothの事例は、図10に示すように、ブロックチェーンをデータ蓄積・共有基盤として、漁師や卸業者に魚の情報を簡単に登録できる仕組みを構築し、それを監督官や消費者であるレストランが参照できるようにしようとするものです。
これにより、現在売られている魚の33%の産地表示が正しくなく、不法漁獲操業がもたらしていると想定される全世界で毎年1～2.3兆円の損失を回避することに役立てようとしています。
Hyperledger Sawtoothは1月30日に正式実用版のVersion1.0がリリースされたところで、上記の適用事例は試用段階で検討されていたものでした。しかし例えば、ウォールマートのスーパーマーケットで顧客が商品を購入する際に、スマホに原産地情報を表示できないかとか、紛争鉱物で問題がない原料であることの証明に使えないかといった、原産地証明・流通経路追跡へのブロックチェーンの利用検討が昨今報じられています。
(5)購買・サプライチェーン領域での適用事例（２）～ 貿易事務
もう１つの適用事例は、貿易取引の事務(書類の受け渡し)に関するもので、既に実用化されています。貿易取引では、輸出者から輸入者までの間に、港湾作業、保管倉庫、税関、海運、陸運、金融機関などの様々な機関が関わります。そして現在は信用状(L/C)、船荷証券(B/L）などの紙ベースの書類の受け渡しが発生しています。それらの書類の受け渡しを電子化すると共に、貨物の輸送進捗を可視化するといった狙いから、貿易取引の取引記録の蓄積・共有にブロックチェーン技術を適用しようとしています(解説ビデオ)。
この仕組は、Hyperledger Fabricを使った仕組みとして実用化され、マースクとIBMの合弁会社により、2018年1月より実用サービスが提供され始めました。その解説用には、ビデオ(英語)、および文書記述(日本語)が提供されています。その資料によると、マースク関連だけでも数十億ドルのコスト削減が見込まれるとのことです。さらにこの仕組を全世界で適用し、国際的なサプライ・チェーン内に存在する「障壁」を削減できれば、グローバル全体では貿易量を約15％増加し、世界のGDPを約5％増やす効果が期待できるとのWTO（世界貿易機関）試算があるとのことです。
購買・サプライチェーン領域での実際の適用事例の数は多くありませんが、いくつかの事例が出てきています。
4.ブロックチェーンの採用メリットと誤謬
ところで現在のブロックチェーン・ブームで、ブロックチェーンのメリットとして喧伝されている事項は本当に適正なのでしょうか。実は疑わしいものが2点あります。「価格面のメリット」と「機能面の万能性」です。それぞれを見ていきましょう。
(1)誤謬1: ブロックチェーンは安い
ブロックチェーンの大きなメリットとして語られるのが、従来型システムよりもコストが安くなるというものです。しかし本当にそうなのでしょうか。
a.金融システムでコストを掛けている実現しているセキュリティや常時稼働のレベルと同等なものまでを、購買・サプライチェーン領域では必要としない。
”カネ”のやり取りに関わる金融分野のシステムでは、取引内容の改ざんや取引記録の脱落は即座にキャッシュの盗難・損失に繋がります。さらに金融取引の仕組みは、一瞬の停止も許されない社会インフラになっています。そのためシステムを運用する金融機関では、徹底した堅固なセキュリティ対策や常時稼働の仕組みを整え、そこに膨大なコストが掛かっています。
しかし、購買・サプライチェーンの取引記録の取扱いに、そこまでの堅牢なセキュリティや常時可動性(可用性)が果たして必要でしょうか。改ざんが即座にキャッシュ盗難に繋がる金融取引に匹敵するような、例えば原産地証明記録を改ざんしようといった動機が存在するのでしょうか。存在は疑わしく思います。そして存在しないのであれば、セキュリティの強度を弱めて、その分のコストを節約することもできるのではないでしょうか。
常時可動性(可用性)についても、社会インフラとしてシステムダウンが極度に許されない金融取引システムに比べて、原産地証明や貿易取引事務の仕組みに要求されるレベルは低いと思われます。もちろん、システムがやたらと稼働停止しないことは重要です。しかし、クラウドサービスとして、それらのシステムの稼働環境を提供する仕組みは、むやみやたらに稼働停止したりするものではありません。
このように考えると、金融システムほどの要件水準が求められず、既存の仕組みでそれに費やすコストも少なかった購買・サプライチェーン領域システムでは、金融領域でブロックチェーン化がもたらとされるほどコストメリットが大きくならない可能性が大きいのです。
b.金融システムでも、仕組みのブロックチェーン化によるコストメリットはさほど大きく見込まれていない
加えて、金融システムであっても、ブロックチェーン化によるコストメリットはそれほど大きくはならないとの研究結果が出てきています。東京証券取引所は、2016年8月に「金融市場インフラに対する分散型台帳技術の適用可能性について」というワーキングペーパーを発行しました。その中で、コスト削減余地について、以下のように判断しています。
結果は表２のとおりであり、厳密な計算等は行っていないものの、ハードウェア・ソフトウェア関係の 費用や保守費用が低下する可能性がある。ただし、これらの単純な ITインフラの置き換えによるコ スト削減効果は限定的であり、分散台帳技術(DLT)の採用によるコストへの主要なインパクトは、本節(1)に述べたようなビジネスプロセスの改善によるオペレーションコストの削減によりもたらされるものと考えられる。
これらからみると、セキュリティや常時可動性(可用性)対策を施している既存システムの仕組みを、ブロックチェーンの仕組みに置き換えても、喧伝されているほどのコスト削減が出るとは言えないように思われます。
「ブロックチェーンの仕組みは安くなる」という売り文句には、十分に注意したほうが良さそうです。
(2)誤謬2: ブロックチェーンは万能薬だ
もう１つの誤謬は、ブロックチェーンがあたかも万能薬の対策であるように語られていることです。例えば、財務省での公文書改ざんが発生すると、ブロックチェーンを公文書保管に適用せよという強い論調が出てきました。しかし前述のようにコストメリットもさほど期待できない中、わざわざ新技術を本当に使う必要があるのでしょうか。
購買業務に携わっている方ならばご存知と思いますが、購買領域のシステムソリューションの「契約管理モジュール」では、契約文書の適正な管理(作成者・承認者の特定、改訂履歴の漏れない把握など)が適正に実現できるようになっています。
例えば、上図はAribaでの契約管理(Contract Management)の概要図にコメントを付加したものです。契約文書は、締結後も、現在作成・改訂中も、改訂履歴(どこを追加したり書き換えたりしたかの履歴）とともに、リポジトリに一元格納されています(①)。契約文書を作成する場合には、MS Wordのような文章入力画面が出てきますので、そこに入力して文面案を作成します。文面案が完成したら、必要とされる確認者(レビューア）に内容確認を依頼します(②)。その結果、誰がチェックをし、それを反映して誰がどこ修正したかの改訂履歴が記録されたデータがリボジトリに格納されていきます(契約プロセスフロー：③)。社内承認された文面案が完成すると、交渉締結相手との文面合意交渉を行うことになります。そこで改訂の履歴は同様にリポジトリに蓄積され、さらに契約の最終承認者までの承認記録もリポジトリ内に記録されます(④)。
日本企業では契約文面の改訂を紙ベースで行い、改訂理由が不明確になってしまっている場合が多々ありますが、訴訟リスクがより高い欧米では、契約プロセスの電子化と改訂・承認履歴の完全な記録化を行うために、このような契約管理システムがすでに実用化されいます。
もちろん契約は購買契約だけではありません。営業契約にもこのような仕組みは適用されます。さらには、日本のある製薬会社は医薬品開発の申請に必要なデータ類の管理に契約管理システムを適用しています。新薬申請データは、厚生労働省に提出する公的文書ですので、これなどは契約管理システムを使って、適切な公文書管理を行っている事例になります。すでにこのような実績が、日本企業でも発生しているのです。
そもそもがブロックチェーンは多くのコンピュータ間で確認のために多数のやり取りを行うなどの通信負荷が高いシステムです。加えて、台帳データを分散保有しますので、1代で集中管理するコンピュータに大容量・高性能のデータ蓄積機能を保有する必要、高コストがかかることはありません。しかし分散して重複保管するデータ総量で見たらどうなのでしょうか。ビットコインでは、台帳を保管するのに、各コンピュータごとに130GBのディスク容量が現在必要になります(これはどんどん時系列に増えていきます)。そうなるとコンピュータ全部で考えると、保管しているデータ総量は膨大なものになってしまいます。加えて、データの入力画面などの「アプリケーション」は別途しつらえる必要があり、その開発コストは既存の仕組みと大差ないことが、前述の東証のワーキングペーパーで示されています。さらに新規に仕組みを作る場合には、システムバグ(不具合)が発生することも考えなければなりません。
このように考えるとき、稼働実績があり、不具合も出尽くした、いわゆる”技術的に枯れた”仕組みがあるならば、その方がよほど安全かもしれません。
何にでもブロックチェーンを適用すればよいという安易な風潮には、十分に注意してかかる必要があります。
(3)本当のメリットは、企業間の不効率解消の”良い意味”での口実が提供されること
では、ブロックチェーンはどんなところでの適用を考えていくべきなのでしょうか。例えば、NTTデータのレポートでは、現在は未対応だが新たに効果が出る領域の存在が示されています。しかし技術的な観点から考察しているため、具体的どこの領域かを指定できずに終わっています。
では、果たしてそのような領域はあるのでしょうか。結論から言うと、「企業間の文書/取引情報交換」がその領域ではないかと考えます。例えば、先程の適用事例でも貿易取引事務が出てきました。この領域は昔から、紙・手作業ベースで大変な非効率があること、作業面で面倒くさい領域であるに、皆が気づいていました。しかしその領域の効率化やデジタル化は進みませんでした。なぜなのでしょうか。2つの理由があると思います。
すなわち
- 場合によっては利害関係も生じる様々な参加者がいる領域で、誰かが敢えて主導権を握って仕組み化を進める気にはなれなかった。自分だけが皆のために仕組みを作って運営しても、自分の獲得できるメリットはさほど大きくはならない。けれどうまくいかないと文句だけは来る。そんなところで、ある意味無償奉仕活動するには躊躇を覚えた。
- 加えて、もし主導者が現れた場合、そこに自分のデータを託すことの不安があった。本心での得体が知れない相手にデータを委ねた場合、不利な利用をされるのではないかとの不安があった。
そのため、多大な不効率があったとしても、誰も音頭を取って対応を進めること無く、現状が維持されてきた、それが「企業間の文書/取引情報交換」の領域ではないでしょうか。
例えば、かつてコンサルティングテーマとして、ある業務の委託先ベンダーの選定を請け負ったことがあります。コンサルティングチームは、網羅的に選定評価観点を拾い出し、候補ベンダーの全てをそれで評価した上に、評価観点間の重み付けをシュミレーションした上で、(お客様も含めた)プロジェクトメンバーとしては完璧な採点結果を算出し、役員会のトッププレゼンに臨みました。しかし、この決議案は社長の次の一言で見事に撃ち落とされたのです。「そこはダメ、なぜならライバル企業が使っているところだろう」。2番手とは点数でかなりの差がありましたし、選定したベンダーはライバル企業の業務とは「チャイニーズ・ウォール」で漏洩などしないなど、納得感のある方式が提示もされていたにもかかわらずです。得体の知れない相手、さらにはライバル企業が絡むとなると、経済合理性を越えて、さほどに心理的な壁が立ちはだかったという事例です。
購買ブロックチェーンの導入は、鹿狩りゲームが発生している「企業間の文書交換」が主戦場になる
この状況は、ゲーム理論の「鹿狩り(stag hunt)」に類似します。「鹿狩り(stag hunt)」とは、狩りに来ている2人の猟師がいて、2人が協力すれば鹿という大きな獲物を手にできる状況です。しかし個別に行う狩りを選択すれば、ウサギという小物しか得られません(でも確実にうさぎは手にできます)。さらに、相手が協力してくれるという見込みが外れて、相手の協力を得られずに1人だけで鹿を追ってしまうと、その猟師は何も獲物を得られなくなるというものです(個別の狩りを選択した相手は、ウサギを手にできます)。
これを「企業間の文書/取引情報交換」に当てはめてみましょう。
これまでは、自分だけで音頭をとって割を食うことがないように、業務の非効率を我慢しながらも、皆が紙・手作業に甘んじてきました。すなわち、協調行動を獲らずに、敢えてウサギで良しとしてきました。ところがここへ来て、「ブロックチェーン」が登場してきました。
話を聞くと、ブロックチェーンは集中管理するリーダーは不要の仕組みとのことです。特定参加者に限定されるコンソーシアム型は、参加者の許可付与を含め、実際には管理者が必要ですが、仮想通貨の幻想がそのあたりの現実は見えなくしてくれています。さらに、データは参加者全員が同様のものを分散保有し、誰かが独占活用できないとのことです。となれば、これまでの不安は解消です。乗り遅れないように、急いで時流)に飛び乗りましょう(鹿狩りに参加しましょう)…ではないでしょうか。
加えてこれは、デジタルサービスのベンダーとっても、サービスの空白地帯であった「企業間の文書/取引情報交換」領域で新たなサービスを提供して、儲けをあげるチャンスになります。算を乱して取り組んでくることが予想されます。
このように、購買・サプライチェーン領域でのブロックチェーンの活用は「企業間の文書/取引情報交換」が主戦場になるのではないでしょうか(現在の適用事例の原産地証明も貿易取引事務も、企業・組織間での情報交換が対象です)。一方で、組織内といった制御が効くメンバが対象の領域には、既にブロックチェーン以外の何らかの代替策が存在しており、ブロックチェーンに基づく仕組みの導入があまり報われないのではと思われます。
なおこのような状況では、ブロックチェーンの参加メンバーの一般企業にとって、仕組みを主導する動機は乏しくなります(様々な一般企業の代表に立っても、それに見合う報いは少ないと思われます)。従って、おそらくはNTTデータ、IBM、アクセンチュア、あるいはサービス提供機会を見出したスタートアップ企業などのサービスプロバイダーが仕組みを組み立て、主導して、それに参加する一般企業メンバーを募る形態になるのではないかと考えます。
5.ブロックチェーン適用上の留意点
このようにして、一般企業(の購買部門)は「企業間」領域の改善策の提案をサービースベンダーから受け、その採否を判断する場面に今後遭遇するとが予想されます。
ではその際の留意点としてチェックすべきポイントはどのようなものでしょうか。
実は興味深いことに、ビジネス領域へのブロックチェーン定義・適用をリードしているHyperledgerプロジェクト自体が、良心的にも留意事項を明示してます。そこでここでは、ＭＩＴ(マサチューセッツ工科大学)のオンライン講座edX(後述)にて、Hyperledgerプロジェクトが提している技術的な留意事項も加えてまとめてみます。
留意点1:適用領域が「企業間」以外の場合は、十分な吟味が必要
まずブロックチェーンの解決策(ソリューション)の適用領域ですが、前述のように、企業間の文書/取引情報以外の領域に適用する内容の場合は、より有効な他の代替案がないかを、十分に確認して見る必要があります。すでに稼働実績があり、技術的に”枯れた”ソリューションの方が、導入トラブルのリスクは遥かに小さくなります。
加えて(購買部門ですから当然認識されていると思いますが)、サービス提供業者本体が大丈夫なのかの確認(取引を行うにふさわしいことの適格性認定(Qualification))やデータの実質的所在地なども含めた各国のデータ保護ルールの遵守性の確認などは、当然行っていくことが必要になります。
留意点2:秘匿性の高いデータを対象とする場合には留意が必要
ブロックチェーンの取引記録は、基本的に参加者に内容が公開されています(Hyperledger Fabric v1.0だけは、ようやく参照者を限定するチャネル機能が追加されましたが)。ハッシュ値も秘密鍵暗号も内容の改ざんを防ぐための措置であり、内容の参照を制限するものではありません。
従って、公開したくない/秘匿性の高い情報を格納対象としている場合には、慎重にチェックする必要があります。例えば、マイナンバーなどの個人情報は、ブロックチェーンに格納して記録するには大きな懸念があるものです。
留意点3:サイズが大きい台帳データの取扱いには向かない
ブロックチェーンは、複数のサーバー間でデータを送受信して確認するとともに、分散して同様のデータを保持する仕組みです。従って、あまりにもサイズが大きいデータを取り扱うと、通信回線容量を圧迫しますし、各コンピュータで保持するデータ量も膨大になりかねません。
(大規模データを別の場所に置いておき、それとリンクする小さなデータで確認・格納を行う技術的な方式も考えられますが、例えばHyperledgerではその方法はまだ実現されていません）。
従って、データサイズがあまりにも大きいデータを、ブロックチェーンに乗せようとする提案があれば、実用性を十分に吟味してみる必要があります。
留意点4:高速な処理が要求される場面には向かない
加えて、複数のサーバー間でデータを送受信して確認するブロックチェーンの仕組みは、リアルタイムにデータ処理要求が発生する業務をこなすことができるかには大きな不安が残ります。
証券売買取引などミリ秒を争う場面への適用はもちろんのこと、例えば、多くの機器が都度発信するデータを扱うIoTのデータ処理などにも、本当に性能面で太刀打ちできるかは、今後の状況を見なければならないと思います。
留意点5:頻繁に処理要件が変わる業務には向かない
イーサリアムの「スマート・コントラクト」のように、取引記録を格納する前に行う処理プログラムを定義しておく仕組みは、Hyperledgerなどその他のブロックチェーンの仕組みでも概ね実現可能となっています。
ただしこの処理プログラムの設定や変更は、特別な取引情報として、他の取引情報と同様に、ブロックチェーンに参加している全てのコンピュータに送信され、分散共有されます。従って、その設定や変更が完了するまでには、取引情報が格納されるのと同様の時間がかかります。
従って、あまり煩雑に処理内容が変わる場面では、処理プログラムの設定・更新の完了が間に合わないなどの不具合が発生することが予想されます。
ブロックチェーン技術の適性確認フローチャート
前述しましたが、ビジネス領域へのブロックチェーン適用を進めているHyperledgerプロジェクト自体が、ブロックチェーンの適否を判断するためのチャートを公開してくれています。以下は、MITのオンライン講座(edX)で公開されていたチャートに若干加筆したものになります。ブロックチェーンの適否判断の優れた判断材料になると思われます。
6.情報の入手方法～ＭＩＴオンライン講座 edXの活用
ブロックチェーンのビジネス適用を目指すHyperledgerプロジェクトは、2015年12月とほんの2年と少し前に始まったものです。しかし技術革新などの急テンポな動きの下では、突然に様々な事態に取り組みことが要請されるようになってきています。
しかしそれとともに、主導団体が直に必要情報を発信してくれている事例も増えてきました(書籍化されるのを待つなどといった、ゆったりした対応なしで済むようになっています)。
今回にHyperledgerでは、ＭＩＴのオンライン講座(edX)が受講コース「Blockchain for Business – An Introduction to Hyperledger Technologies」が提供され、多くはこれを受講すれば把握できるようになっていました(最終確認では、HyperledgerのTechnical Documents)に当たったりもしましたが）。
今後も特に技術に関わる側面で、急激な変化への対応を迫られることが多くなると思います。そのような場合には、海外のものを含めて、いかに有効な情報源を使えるかは重要な差別化要因になっていくと思われます（なお、英文はGoogle翻訳にかければ、かなり対応できるように精度があがってきています）。
