平成２８年度我が国におけるデータ駆動型社会に係る基盤整備 （ブロックチェーン技術を活用したシステムの評価軸整備

等に係る調査）

調査報告書

2017 年 3 月 17 日

株式会社三菱総合研究所

ii

目次

1. 調査概要 ................................................................................................................................ 1

1.1 調査の背景と目的、検討範囲 ...................................................................................... 1

1.2 調査実施フロー ............................................................................................................ 2

1.3 有識者検討委員会の実施状況 ...................................................................................... 3

2. ブロックチェーン技術を活用したシステムの評価に関する国内外動向調査 ...................... 6

2.1 ブロックチェーン技術の特性に関する調査結果 ......................................................... 6

2.2 ブロックチェーンを活用したシステムの評価に関する文献調査結果 ...................... 13

2.3 国内外のユースケースにおける評価状況の調査結果................................................ 19 2.3.1 日本証券取引所グループによる証券取引における応用事例 .............................. 19 2.3.2 ブロックチェーン研究会による銀行間振込みへの応用事例 .............................. 21 2.3.3 リクルートテクノロジーズによる履歴書公証データベースへの応用事例 ........ 22 2.3.4 Everledger（英国）における動産管理への応用事例 .......................................... 24 2.3.5 欧州のエネルギー産業における応用事例 ........................................................... 25 2.3.6 原子力発電所などの重要インフラに対するブロックチェーン技術の応用例（英国）

............................................................................................................................ 26 2.3.7 ニューヨークにおけるマイクログリッドへの応用例（Brooklyn Microgrid） ... 27 2.3.8 エストニア政府による ID 管理への応用例 ......................................................... 29

2.4 関係者・有識者へのヒアリング調査結果 .................................................................. 31

2.5 国内外動向調査のまとめ ........................................................................................... 33

3. ブロックチェーン技術を活用したシステムの評価軸に関する検討結果 ........................... 34

3.1 評価軸検討に当たっての論点と各論点に関する検討結果 ........................................ 34 3.1.1 評価軸の目的について ........................................................................................ 37 3.1.2 評価の対象について ............................................................................................ 37 3.1.3 評価軸の構成要素（評価項目・評価指標・評価方法等）について ................... 40

3.2 評価軸の検討結果 ...................................................................................................... 43 3.2.1 「品質」に関する検討結果 ................................................................................. 43 3.2.2 「保守・運用」に関する検討結果 ...................................................................... 51 3.2.3 「コスト」に関する検討結果 ............................................................................. 54

4. まとめ .................................................................................................................................. 57

4.1 調査結果概要 .............................................................................................................. 57

4.2 本評価軸の活用方法について .................................................................................... 57

4.3 今後の検討課題について ........................................................................................... 58

4.4 ブロックチェーン技術の社会実装を推進するための考察 ........................................ 59

参考資料 1：ISO/IEC25010 の全ての項目とブロックチェーン技術との関連性 ................... 62

iii

参考資料 2：有識者検討委員会等議事録 ................................................................................ 68

iv

図目次

図 1-1 調査フロー ................................................................................................................... 3 図 2-1 ブロックチェーンプラットフォームの分類例：市場と許可の観点 .................... 9 図 2-2 Bitcoin Core のアーキテクチャ ................................................................................ 11 図 2-3 Ethereum のアーキテクチャ ..................................................................................... 12 図 2-4 Hyperledger Fabric のアーキテクチャ ..................................................................... 12 図 2-5 JPX における実証試験の環境概要 .......................................................................... 20 図 2-6 JPX における DLT 技術の適用可能性評価 ............................................................ 20 図 2-7 構築された実証環境イメージ ................................................................................. 21 図 2-8 技術観点の検証軸と検証結果概要 ......................................................................... 22 図 2-9 履歴書公証データベースの利用フロー ................................................................. 23 図 2-10 Everledger（英国）による動産管理の概念図 ...................................................... 25 図 2-11 RWE 社が開発した充電システムとアプリケーション ...................................... 26 図 2-12 ブルックリン地区にある President Street における小規模系統の状況............. 28 図 2-13 TransActive Grid のシステム概念図 ...................................................................... 29 図 2-14 「X-Road」の概念図 ............................................................................................... 30 図 3-1 ブロックチェーン（図中では BC と表記）技術を活用したシステムの評価軸の

検討に当たっての論点と方針 ......................................................................................... 36 図 3-2 評価対象の概念図 ..................................................................................................... 38 図 3-3 ユースケースによって異なる要件、機能 ............................................................. 40 図 3-4 評価軸の構成（図中では BC とも表記） .............................................................. 41

v

表目次

表 1-1 有識者検討委員会実施状況 ....................................................................................... 4 表 1-2 有識者検討委員会メンバー ....................................................................................... 4 表 2-1 JBA によるブロックチェーン技術の定義 ............................................................... 6 表 2-2 英国 GCSA による記載 ............................................................................................... 7 表 2-3 管理主体による一般的なブロックチェーンプラットフォームの分類 ................ 8 表 2-4 オーストラリアの ISO 提案における分類例 ........................................................... 9 表 2-5 調査対象文献リスト ................................................................................................. 13 表 2-6 文献調査結果概要 ..................................................................................................... 15 表 2-7 エストニアが e-state 構築に向けて掲げるビジョン ............................................. 30 表 2-8 関係者・有識者へのヒアリング調査結果 ............................................................. 31 表 3-1 評価軸：品質 ............................................................................................................. 47 表 3-2 評価軸：保守・運用 ................................................................................................. 52 表 3-3 評価軸：コスト ......................................................................................................... 56

1

1. 調査概要

1.1 調査の背景と目的、検討範囲

(1) 調査の背景

IoT、ビッグデータ、人工知能といった革新的イノベーションによる「第 4 次産業革命」

とも呼ぶべき大変革が世界的に進みつつある状況にあって、これら技術等の発展がどのよう

な経済・社会的インパクトをもたらすかを迅速に把握し、国としてどのような対応を取って

いくべきかを早期に検討することが重要である。 こうした中、産業構造審議会情報経済小委員会分散戦略ワーキンググループは、IoT の進

展による分散型のアーキテクチャ及び社会システム等について将来像が示した中間とりま

とめ（2016 年 11 月）を公表している。同中間とりまとめにおいて「信頼の仕組みを変える

新たな産業社会システム」を予見する新たな技術の潮流として示されたものが、Bitcoin 等

の仮想通貨に使用されているブロックチェーン技術 1である。Bitcoin に代表されるブロック

チェーン技術を活用したシステムは、その構造上、従来の集中管理型のシステムに比べ、『改

ざんが極めて困難』であり、『実質ゼロ・ダウンタイム』なシステムを、『安価』に構築可

能という特徴を持つことから、IoT による分散型のアーキテクチャに対して親和性が高く、

非常に幅広い分野への応用が期待されている。 経済産業省では、ブロックチェーン技術の可能性について、いち早く着目し、昨年度、調

査（平成 27 年度我が国経済社会の情報化・サービス化に係る基盤整備（ブロックチェーン

技術を利用したサービスに関する国内外動向調査））を実施している。同調査では、ブロッ

クチェーン技術が社会に与えるインパクトの可能性を整理するとともに、関連する市場規模

をおよそ 67 兆円と見積もるなど、当該技術の経済的・社会的ポテンシャルを明らかにして

いる。 一方、当該調査を通じて、ブロックチェーン技術の社会実装に向けての顕在化しつつある

課題も明らかになった。その中のひとつとして、「既存のシステム評価手法を単純にブロッ

クチェーン技術を活用したシステムの評価に用いると、ブロックチェーン技術の特性を効果

的に表現できず、結果として当該技術の活用を妨げる可能性もある」という課題が挙げられ

ている。現状、このような評価の基準となる軸（評価軸）が整備されていないことで、当該

技術やそのシステムに対する不安感だけでなく、過度な期待や誤解が生じており、結果的に

適切な導入が進まないという現象が生じつつある。

1 ブロックチェーンという単語は世の中において様々な領域を表す言葉として使われている。本報告書で

は、領域の範囲の順に「ブロックチェーン技術」「ブロックチェーンプラットフォーム」「ブロックチェ

ーン技術を活用したシステム」という単語を用いることとする。Bitcoin や Ethereum、Hyperledge Faburic（詳

細は後述）等を「ブロックチェーンプラットフォーム」と定義し、その構成技術要素を「ブロックチェー

ン技術」、プラットフォームを利用したシステムを「ブロックチェーン技術を活用したシステム」と定義

する。

2

(2) 調査の目的

本調査では、ブロックチェーン技術を活用したシステムの特性を適切に表現し、評価する

ことが可能な項目を洗い出し、これらを網羅的にまとめた評価軸を作成することを目的とし

た。特に、実際にシステムベンダーなどが、ブロックチェーン技術を活用したシステムを評

価する際に利用されることを意識した。 なお、ISO TC3072が 2017 年に立ち上がるという背景も踏まえ、標準化の議論も視野に入

れ、検討を行った。

(3) 調査の検討範囲

ブロックチェーン技術は世界中で多くの技術者が開発を進めており、日進月歩で進化して

いる技術である。本検討は半年弱かけて実施したが、その中でも新たな技術やブロックチェ

ーンプラットフォームの台頭が見られ、そのすべてに対応した評価軸の検討を行うことはで

きなかった。 原則として、2016 年 11 月時点で主要なブロックチェーンプラットフォームであった

Bitcoin、Ethereum、Hyperledger Fabric3等を念頭に置き、その時点で構想が公表されている、

もしくは実証試験が行われているユースケースを想定してシステムの評価軸を検討した。今

後様々な技術革新や社会変革を起こすようなユースケースの創出も想定されるが、それらに

ついては有識者検討委員会の委員の見識をベースに極力考慮とすることとしたが、技術の進

化を予想することは難しく、それらの将来像の検討への取込み度合いについては限界がある

点について、留意が必要である。 すなわち、今回の検討は急速な進化を見せている発展途上の技術を活用したシステムの評

価軸検討を、現時点のスナップショットとして実施したものであり、評価軸として将来にわ

たって普遍的なものを検討できたわけではない。技術の進化、ユースケースの蓄積と共に随

時見直していく性質のものである点についても理解の上、本検討結果を活用いただきたい。

1.2 調査実施フロー

本調査は図 1-1 に示すフローで実施した。まず、ブロックチェーン技術を活用したシス

テムの評価に関する国内外動向調査を行い、その結果を踏まえ、ブロックチェーン技術に関

する幅広い有識者からなる有識者検討委員会（詳細は 1.3 参照）を開催し、評価軸の検討を

行った。 「ブロックチェーン技術を活用したシステムの評価に関する国内外動向調査」では、まず、

2 「ブロックチェーンと電子分散台帳技術に係る専門委員会（Blockchain and electronic distributed ledger technologies）」。ブロックチェーン技術と電子分散台帳におけるシステム、アプリケーション、ユーザー

間の互換性やデータ交換をサポートする国際標準化活動が行われる予定。日本は、標準化活動に積極的に

関与する「P メンバー」として、当該 TC に参加しており、国内審議団体は一般財団法人日本情報経済社会

推進協会（JIPDEC）が務めている。 3 IBM が主導する Hyperledger Project ではアンブレラ・アプローチの名のもと、複数のプラットフォームが

並存するスキームとなっている。その中で、現時点で最もよく利用されているプラットフォームが

Hyperledger Fabric である。その他にも、Sawtoothlake、Iroha というプラットフォームも存在する。

3

文献等をベースに、ブロックチェーン技術の特性に関する整理を実施した。次に、こちらも

文献調査によりブロックチェーン技術を活用したシステムについての比較評価事例を調

査・分析した。その後、いくつかの個別ユースケースを調査し、主に、既存システムとの比

較においてどのような評価を行っているのかを整理した。さらに、有識者等へのヒアリング

を行い、有識者検討委員会で検討するための基礎的情報整理を行った。 有識者検討委員会は、国際大学グローバル・コミュニケーション・センターの高木聡一郎

研究部長を委員長に迎えて、2016 年 11 月～2017 年 3 月にかけて 5 回実施した。有識者検討

委員会メンバーとしては、学識経験者、ブロックチェーン関連事業者、国内システムベンダ

ー、国際的なコンソーシアム参画企業といった構成とした。有識者検討委員会での議論に加

え、委員への個別ヒアリングも複数回にわたって実施しながら検討を進めた。

図 1-1 調査フロー

1.3 有識者検討委員会の実施状況

有識者検討委員会は、表 1-1 の日時・議事内容で 5 回開催した。第 1 回～第 3 回は事例

のプレゼンテーションを踏まえた議論を行い、第 4 回・第 5 回において集中的に評価軸およ

び報告書の内容についての議論を行った。

(1) ブロックチェーン技術を活用したシステムの評価に関する国内外動向調査

(2) ブロックチェーン技術を活用したシステムの評価軸の検討

ブロックチェーン技術の特性に関する調査 ブロックチェーン技術を活用したシステムの評価に関す

る文献調査 国内外のユースケースにおける評価状況の調査 関係者・有識者へのヒアリングによる事前論点整理

5回の有識者検討委員会を通じた検討

4

表 1-1 有識者検討委員会実施状況

有識者検討委員会は表 1-2 のメンバーで実施した。表 1-1 に記載の通り、第 1 回には株

式会社日本証券取引所グループよりプレゼンテーションをしていただき、株式会社日本証券

取引所グループ総合企画部新規事業推進室・フィンテックラボ課長の山藤敦史様にも議論に

参加いただいた。また、第 3 回には、株式会社リクルートテクノロジーズよりプレゼンテー

ションをしていただき、同社の櫻井一貴様、中野猛様、蓜島大気様にも議論に参加いただい

た。 また、ISO TC307 との連携を取るために、国内委員会事務局である一般財団法人日本情報

経済社会推進協会（JIPDEC）と随時情報共有をしながら、検討を進めることとした。JIPDECには、第 4 回の有識者検討委員会にオブザーバーとして参加いただいた。

表 1-2 有識者検討委員会メンバー

氏名 所属・役職等

■委員長

高木 聡一郎 国際大学グローバル・コミュニケーション・センター 研究部長

■委員（50 音順）

エドムンド・ エドガー

株式会社ソーシャル・マインズ CEO

大岩 寛 国立研究開発法人産業技術総合研究所 情報技術研究部門 サイバーフィジカルウェア研究グループ長

加納 裕三 株式会社 bitFlyer 代表取締役

議事内容

第1回11月11日

15:00-17:00

本事業の説明1. 委員紹介2. 事業の目的、実施内容の確認3. 日本証券取引所グループ（JPX）の実証事例紹介4. ディスカッション

第2回12月16日

17:00-19:00

1. ブロックチェーン技術を活用したシステムの評価事例の紹介（JPX、ブロックチェーン研究会）2. 今回の評価軸に対する期待・要望（システムベンダー2社からプレゼン）3. 業務を変えない場合の評価軸についてディスカッション

第3回1月18日（水）16:00-18:00

1. 業務を変えたブロックチェーン技術を活用したシステム事例の紹介（リクルートテクノロジーズ）と評価軸に関するディスカッション

2. 今回の評価軸に対する期待・要望（システムベンダー1社からプレゼン）3. 利活用イメージの共有と業務を変えない場合の評価軸に関するディスカッション

第4回2月8日（水）16:00-18:00

1. 評価軸検討に当たっての論点と各論点に対する検討の方向性の確認2. 評価軸に関するディスカッション

第5回3月2日（木）15:00-17:00

1. 報告書内容に関するディスカッション① 評価軸について② 報告書構成について③ 今後の検討の方向性について

5

楠 正憲 ヤフー株式会社 CISO Board

柴田 巧一 株式会社 SKEED IoT 事業開発室室長

杉井 靖典 カレンシーポート株式会社 代表取締役/CEO

高城 勝信 日本 IBM 株式会社 ブロックチェーン・アーキテクト

長 稔也 株式会社日立製作所 金融システム営業統括本部 事業企画本部 金融イノベーション推進センタ センタ長

鳥山 慎一 日本電気株式会社 事業イノベーション戦略本部 Fintech 事業開発室 マネージャー

八田 真行 駿河台大学 専任講師

廣瀬 一海 日本マイクロソフト株式会社 クラウドソリューションアーキテクト

山崎 重一郎 近畿大学 産業理工学部 情報学科 教授

（敬称略）

6

2. ブロックチェーン技術を活用したシステムの評価に関する国内外動向調査

ここでは、有識者検討委員会による評価軸検討を行うための事前調査として実施した、図 1-1 に示した 4 つのアプローチによる調査の結果とそのまとめを示す。

2.1 ブロックチェーン技術の特性に関する調査結果

評価軸を検討するに当たってはブロックチェーン技術の特性を十分に把握する必要があ

るため、ブロックチェーン技術の定義、ブロックチェーン技術を活用したシステムの分類、

ブロックチェーンプラットフォームに含まれる技術レイヤについて調査した。

1) ブロックチェーン技術の定義について

現在、機関等において「ブロックチェーン技術の定義」を明確に示しているのは、日本ブ

ロックチェーン協会（JBA）であり、表 2-1 のように定義している。（2016 年 11 月 30 日

現在）

表 2-1 JBA によるブロックチェーン技術の定義

1). ビザンチン障害 4を含む不特定多数のノードを用い、時間の経過とともにその時点の合

意が覆る確率が 0 へ収束するプロトコル、またはその実装をブロックチェーンと呼ぶ。 A blockchain is defined as a protocol, or implementation of a protocol, used by an unspecified number of nodes containing Byzantine faults, and converges the probability of consensus reversion with the passage of time to zero.

2). 電子署名とハッシュポインタを使用し改竄検出が容易なデータ構造を持ち、且つ、当

該データをネットワーク上に分散する多数のノードに保持させることで、高可用性及

びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ。 In a broader sense, a blockchain is a technology with a data structure which can easily detect manipulation using digital signatures and hash pointers, and where the data has high availability and integrity due to distribution across multiple nodes on a network.

出所）JBA HP （http://jba-web.jp/）

4 ビザンチン障害とは、分散コンピューティングにおいて、アルゴリズムを実行中に発生する故障・障害

である。不作為障害 (omission failures) と作為障害 (commission failures) が含まれる。不作為障害とは、ク

ラッシュ、要求を受信しそこなうこと、応答を返しそこなうことなどを指す。一方、作為障害とは、要求

を不正に処理すること、局所状態が壊れること、要求に対して不正または一貫しない応答を返すことなど

を指す。ビザンチン障害が発生すると、障害耐性を備えていないシステムは、予期しない動作をすること

がある。 出所）Pease, M.; Shostak, R.; Lamport, L. (April 1980). “Reaching Agreement in the Presence of Faults”. Journal of the ACM 27 (2): 228–234 等から作成

7

この定義では Satoshi Nakamoto による論文 “Bitcoin: A Peer-to-Peer Electronic Cash System” の実装であるBitcoinシステムを反映した定義となっている。なお、Satoshi Nakamotoの論文で提案されているシステムは、「信用できる第 3 者機関を必要とせず、Peer-to-Peerでの電子マネー取引において、電子マネーの二重使用問題を解決するシステム」である。（こ

の論文中では、 “Blockchain” という用語は使われておらず、 “Proof-of-work chain” という

用語が用いられている。） また、機関として明確に定義しているものではないと思われるが、英国 GCSA（UK

Government Chief Scientific Adviser）によるレポート “Distributed Ledger Technology: beyond block chain” では、ブロックチェーン技術と分散台帳について、以下のように記している。

表 2-2 英国 GCSA による記載

A block chain is a type of database that takes a number of records and puts them in a block (rather like collating them on to a single sheet of paper). Each block is then ‘chained’ to the next block, using a cryptographic signature. This allows block chains to be used like a ledger, which can be shared and corroborated by anyone with the appropriate permissions. Distributed ledgers are a type of database that is spread across multiple sites, countries or institutions, and is typically public. Records are stored one after the other in a continuous ledger, rather than sorted into blocks, but they can only be added when the participants reach a quorum.

出所）“Distributed Ledger Technology: beyond block chain”, UK Government Chief Scientific Adviser, 2016

このレポートでは、ブロックチェーン技術とは、ブロック内に多くのレコードが記録され

るデータベースの 1 つであり、それぞれのブロックは、暗号学的な署名により次のブロック

に繋がっていくものであるとされている。また、ブロックチェーン技術は、台帳のように使

うことができ、適切なパーミッションを持つ者によって共有され、正しさが裏付けられるも

のであり、分散台帳では、レコードは連続する台帳に記載され、これらは参加者の投票によ

って追加することができるものとしている。 ブロックチェーン技術は新しく、発展途上の技術であるため、現時点で、国内外の関係者

間で合意の取れた定義というものは存在しない。ただし、現状のユースケースを見るとデー

タベースとして利用されているケースが多く、評価の際にはデータベース 5としての特性を

測ることが必要条件になると考えられる。また、特徴としては分散型で複数のノードを持つ、

各ノードがビザンチン故障耐性を有する、高可用性及びデータ同一性を実現する、などが挙

げられ、それらを評価できる軸の設定が不可欠と考えられる。 また、本検討ではブロックチェーン技術を評価の対象とし、より広義の概念である分散台

帳の全てを評価対象とはしない。分散台帳の中には、Corda6のようにブロックを生成せず、

Proof of Work（以下、PoW）を単一ノードで行うものもある。そのようなシステムは性能を

5 ここで言うデータベースは、一般的な RDB（Relational Database）ではなく、トランザクションも記録し

たデータストア的な、広義のデータベースを意味している。 6金融機関が参加するコンソーシアム（米国 R3 コンソーシアム）が開発した分散型台帳プラットフォーム

8

評価する項目が異なってくると考えられるが、本調査では検討の対象外とした。

2) ブロックチェーン技術を活用したシステムの分類について

ブロックチェーン技術を活用したシステムの一般的な類型としては、表 2-3 に示すよう

なパブリック型、コンソーシアム型、プライベート型の分類が存在する。この類型は、参加

者が不特定多数か許可された者かで分類し、許可された者で構成される場合についてさらに

複数組織に跨るか、単一組織で構成されるかで分類したものである。実際に採用するコンセ

ンサス方式やトランザクション処理時間については、ユースケースにより異なるため、表中

記載は一例である。

表 2-3 管理主体による一般的なブロックチェーンプラットフォームの分類

管理主体 なし 複数組織 単一組織

ネットワーク形

態 パブリック型 コンソーシアム型 プライベート型

参加者 自由 許可制

不特定、悪意のある参加

者を含む 参加者の身元が判明しており、信頼でき

る者で構成される

コンセンサス方

式 （合意形成方式）

PoW 型 PBFT 型 7 （プラクティカル・ビザンチン・フォールト・ト

レラント型）

ファイナリティがない 電力消費が多い

ファイナリティがある 軽量、高速、低消費電力

トランザクショ

ン 処理時間

長い（10 分など） 短い（数秒など）

ユースケース 仮想通貨 銀行間送金、証券取引等ビジネスネット

ワーク

実装例 Bitcoin、 Ethereum、etc…

Ripple、Hyperledger Fabric、etc…

出所）IBM 公開資料より MRI 作成

ISO TC307 はオーストラリアによる提案が設立の契機になったが、そのオーストラリアの

ISO TC 設立の提案書においても “Public Blockchains”, “Private Blockchains” の記述がある。

しかし、表 2-3 に示す分類とは異なり、”Public”とは「参加者は第 3 者機関による認証を必

要としない」ものであり、”Private”とは「産業界や企業グループ等の信頼できる者で構成さ

7コアノードにブロックの生成権限を集中させ、コアノードによる合議制において、トランザクションの承

認を行うコンセンサス方式

9

れる」もので、表 2-3 の分類におけるコンソーシアム型とプライベート型をまとめて “Private” としている。また、”Public” には 2 つの意味があり、「誰でも ledger に情報を書

けること」と「誰でも ledger の情報を読み出せること」としている。

表 2-4 オーストラリアの ISO 提案における分類例

Public vs Private Blockchains There is a big difference in what technologies you need, depending on whether you allow anyone to write to your blockchain, or known, vetted participants. As an example, Bitcoin allows anyone to write to its ledger. Public blockchains - Ledgers can be ‘public’ in two senses: 1.Anyone, without permission granted by another authority, can write data 2.Anyone, without permission granted by another authority, can read data Private blockchains - Conversely, a ‘private’ blockchain network is where the participants are known and trusted: for example, an industry group, or a group of companies owned by an umbrella company. Many of the mechanisms are not needed with the use of smart contracts.

出所）オーストラリア提案書(Ref#.ISO/TS/P 258), 2016/4/14

図 2-1 に示す分類は、市場と許可の観点からの分類である。許可の観点とは、参加する

ノードが信頼できる第 3 者による実在の認証を受けているか（許可型）、受けていないか（自

由参加型）であり、市場の観点とは、参加するノードが限定されているか（コンソーシアム

型）、限定されていないか（パブリック型）である。なお、この分類の考え方においては、

自由参加型かつ参加ノードが限定されるコンソーシアム型（自由参加型コンソーシアムチェ

イン）というものは考え難いものであり、出所においても論じられていない。

図 2-1 ブロックチェーンプラットフォームの分類例：市場と許可の観点

出所）’ブロックチェインの分類に関する一考察’, 岡田仁志(国立情報学研究所), ITU ジャーナル Vol46. No.9 2016/9

自由参加型パブリックチェイン 許可型パブリックチェイン 許可型コンソーシアムチェイン

10

このようにブロックチェーンプラットフォームの分類については様々な考え方が存在す

る。そこで、既存の分類例を受けて、分類する際の観点を以下に整理する。 ① 管理主体の有無 管理主体が存在しない

Bitcoinのように誰でもが自由にシステム上での取引やマイニング等への参加が

できる形式。参加許可等を行う管理主体が存在しないため、システムの信頼性

（データ正確性や可用性等）を確保するための工夫が必要であり、Bitcoinでは、

暗号アルゴリズムや PoW のようなコンセンサス方式等を組み合わせることで

実現している。管理主体による類型においては、「パブリック型」とされる。 管理主体が存在する

管理主体が存在するケースとしては、複数組織が管理主体となるケースと単一

組織が管理主体となるケースとに分類する考え方があり、前者を「コンソーシ

アム型」、後者を「プライベート型」とするのが一般的である。管理主体が複

数組織となる場合には、これら複数組織間での合意形成が必要となる。

② 参加における許可の有無 参加に許可は不要

管理主体が存在しない場合には、通常は参加に当たっての許可は不要であり、

参加者は匿名で参加することも可能である。また、管理主体が存在する場合に

おいてもそのサービス内容（リクワイアメント）によっては、許可が不要とな

るケースもある。 参加に許可が必要

管理主体が存在する場合には、その管理主体による参加の許可が必要となるケ

ースがある。また、その許可における必要条件も厳密な本人確認が必要となる

レベルからメールアドレスの着信確認のみといったレベルまで様々であり、こ

れらはそのサービス内容（リクワイアメント）によって決まる。

③ 参加者のパーミッションレベル 一般レベル

管理主体が存在せず、参加が自由である場合には、全参加者が同じパーミッシ

ョンレベルであり、一般レベルということになる。Bitcoin では、マイニングで

きないノードも存在するが、それは参加者によって選択されているだけであり、

参加者が誰でもマイニングノードとなることができる。 管理主体が存在し、参加に許可が必要である場合には、管理主体が参加者を一

般レベルと後述の許可レベルに分けることができる。 許可レベル

管理主体が存在し、参加に許可が必要である場合には、管理主体が参加者を一

般レベルと許可レベルに分けることができ、たとえば一般レベルは読み出しの

み、許可レベルは読み書き可能といったパーミッションレベルの制御が行われ

る。また、許可レベルを複数設定することも可能であり、これらはそのサービ

ス内容（リクワイアメント）によって決まる。 特権レベル

11

管理主体が存在する場合には、多くの場合管理主体が特権レベルとなり、参加

者許可の判断やシステムの監視・運用・保守といった役割を担う。 これらの類型化軸の組み合わせによって、各ブロックチェーン技術を活用したシステムが

実現できる機能とその機能レベルは大きく異なる。本調査で検討する評価軸においてはいず

れの類型も対応できるような設計とすることが求められる。

3) ブロックチェーンプラットフォームに含まれる技術レイヤについて

ブロックチェーンプラットフォームがどのような技術レイヤ（アーキテクチャ）で構成さ

れるのかを把握することで、何を評価すればよいかを考えることができるようになる。 まず、Bitcoin Core のアーキテクチャを図 2-2 に示す。Bitcoin Core に含まれる 4 つのレイ

ヤ（コンセンサス、Peer-to-Peer（P2P）プロトコル、分散台帳、台帳ストレージ）は、ブロ

ックチェーンプラットフォームを構成する基礎的要素となっており、図 2-3 に示した

Ethereum、図 2-4 に示した Hyperledger Fabric でも同様のコンポーネントが見られる。

図 2-2 Bitcoin Core のアーキテクチャ

出所）IBM 公開資料を参考に MRI 作成

Ethereum のアーキテクチャを図 2-3 に示す。Ethereum では、データ（ブロックチェーン、

トランザクション）とコントラクト・コードがより密に結合した Ethereum Virtual Machineというコンポーネントとなっているおり、スマートコントラクトなどのサービスを提供しや

すいプラットフォーム構造となっている。

Bitcoin CoreのAPI

Bitcoin Coreのサービス

ブロックチェーン

ブロックチェーン・サービス

コンセンサス（PoW）

P2Pプロトコル

トランザクション

分散台帳

台帳ストレージ

12

図 2-3 Ethereum のアーキテクチャ

出所）IBM 公開資料、Ethereum WhitePaper, Yellow Paper を参考に MRI 作成

次に、Linux Foundation による Hyperledger Project での Hyperledger Fabric アーキテクチャ

では、Bitcoin Core の基本構造に加えて、メンバーシップ・サービス、ブロックチェーン・

サービス、チェーン・コード・サービスがコンポーネント化されている構造となり、プラッ

トフォーム単体でかなりの機能を実現できる仕組みとなっている。

図 2-4 Hyperledger Fabric のアーキテクチャ

出所）IBM 公開資料より MRI 作成

EthereumのAPI等

Ethereumのサービス

Ethereum Virtual Machine (EVM)

ブロックチェーン

ブロックチェーン・サービス

コンセンサスマネージャ

P2Pプロトコル

トランザクション

分散台帳

台帳ストレージ

コントラクト・コード

コントラクト・サービス

Hyperledger FabricのAPI、SDK、CLI

Hyperledger Fabricのサービス

メンバーシップ

メンバーシップ・サービス

登録

アイデンティティ管理

監査可能性

ブロックチェーン

ブロックチェーン・サービス

コンセンサスマネージャ

P2Pプロトコル

トランザクション チェーン・コード

チェーン・コード・サービス

セキュア・コンテナ

セキュア・レジストリ

イベント・ハブ

分散台帳

台帳ストレージ

13

このようにブロックチェーンプラットフォームには様々なアーキテクチャを持つものが

存在しており、今後も進化・発展していくものと考えられるが、分散型のデータベースと捉

えた場合には、何らかのトランザクションがあり、そのトランザクションが認証され、デー

タベースに書き込まれるというのがコアな機能となると考えられる。 また、システムとしてみた場合には「データ構造」、「署名・暗号化」、ビジネス応用に

おいて必要となる「セキュリティ・プライバシー保護」などの技術のレイヤが考えられる。

ブロックチェーン技術を活用したシステムの評価を行う場合には、これらのレイヤが実現す

る機能をそれぞれ評価できる評価軸を用意する必要があると考えられる。

2.2 ブロックチェーンを活用したシステムの評価に関する文献調査結果

ブロックチェーン技術を活用したシステムの評価に関する現状を把握するために、まずは

複数のシステムを比較評価している文献の調査を実施した。調査対象文献を表 2-5に示す。

金融やスマートコントラクトなどのユースケースをベースに比較を行っている文献や、セキ

ュリティやスケーラビリティといった特定の性能について、Bitcoin Core と Ethereum などの

複数のプラットフォームの比較を行っている文献などを調査した。

表 2-5 調査対象文献リスト

特定のユースケースを想定した文献では、ユースケースから特定されるリクワイアメント

を満たすことができるかどうかについて評価していた。主として定性的な評価が多かった。

たとえば、”Evaluation of Logic-Based Smart Contracts for Blockchain Systems”では、スマート

コントラクトの有用性について定性的に評価し、契約の人間による可読性や、契約の正常履

行に対する安定性などを評価していた。 また、複数のブロックチェーンプラットフォームを比較している文献では、スケーラビリ

# 文献（タイトル、著者、年月等） 備考

1Evaluating Blockchain SystemsDr. Vincent Gramoli, Univ. of SYDNEYhttp://sydney.edu.au/research/opportunities/opportunities/2117

金融分野における既存のBlockchainシステムの評価。

2On the Security and Performance of Proof of Work BlockchainsArthur Gervais, et al.

PoWのセキュリティと性能の評価をいくつかのパラメータを用いて評価。Bitcoin CoreとEthereumの対比も実施。

3Evaluation of Logic-Based Smart Contracts for Blochchain SystemsFlorian Idelberger(European Univ. Institute, Italy), et al.

Logic-based スマートコントラクトの可能性について考察。

4On Scaling Decentralized BlockchainsKyle Croman, et al.

Bitcoin Coreを用いたシステムのスケーラビリティについて、ブロックサイズ、スループット、レイテンシ等を交えて考察。

5Bitcoin-NG(Next Generation): A Scalable BlockchainProtocolIttay yal(Cornell Univ.), et al., 2016/3

Bitcoin Coreを用いたシステムのスケーラビリティを向上させるためのプロトコルデザインについて考察。

6The Blockchain AnomalyChristopher Natoli(NICTA/Data61-CSIRO), et al., 2016/5

プライベート型ブロックチェーンにおける合意形成に関する考察。

14

ティについて比較評価している事例が多かった。その他、セキュリティと性能面（スループ

ット等）のトレードオフについての考察も見られた。 しかし、いずれの事例も一部の機能・性能評価に留まっており、本事業で検討対象として

いるような網羅的な指標検討事例は存在しなかった。一方、スケーラビリティ、セキュリテ

ィ、スループット、およびそれらの指標のトレードオフについては評価をする際に非常に重

要であることが示唆された。 文献調査結果の概要を表 2-6 に示す。

15

表 2-6 文献調査結果概要

文献タイトル 著者 要約 評価対象、評価項目（ブロックチェーンを活用したシステムの機能やアルゴリズム等の評価について、どのよ

うなものを評価対象として、何を評価項目としているか）

1 On the Security and

Performance of Proof of

Work Blockchains

Arthur Gervais

Ghassan O. Karame

Karl Wüst

Vasileios

Glykantzis

Hubert Ritzdorf

Srdjan Capkun

PoW によるブロックチェーン技術を活用したシステムは現在流通しているデジタル通貨

の時価総額の 90%以上を占めている。Bitcoin Core のセキュリティ対策は徹底的に検討さ

れてきているにも関わらず、変形した（フォークした）PoW チェーン（異なるパラメー

タによるインスタンス）のセキュリティ保証はあまり注目されていない。

本文献では、PoW チェーンの様々なコンセンサスおよびネットワークパラメータの、セ

キュリティおよび性能面への関連性を定量評価するための新たなフレームワークを提案

している。このフレームワークに基づき、著者は二重支払いや利己的なマイニングへの

最適な対策戦略を考案している。これらはネットワーク伝搬やブロックサイズ、ブロッ

ク生成間隔、情報伝播機構、エクリプス攻撃の影響などの、現実世界における制約を考

慮に入れたものとなっている。それゆえ本フレームワークは、異なるパラメータで生成

された PoW チェーンの変形型（インスタンス）と同様に、現在流通している PoW に基

づいて構築されたシステムを対象としており、性能面とセキュリティ対策とのトレード

オフを客観的に比較することが可能となっている。

※「変形した PoW チェーン」、「異なるパラメータで生成された PoW チェーンの変形

型」はオルトコインのようなブロックチェーンインスタンスを表現しているものと推測

される

【評価対象】

ブロックチェーン技術を活用したシステムのセキュリティと性能面（スケーラビリティ）のトレードオフ

【評価項目】

＜指標＞

・スループット：単位時間に処理可能なトランザクション数 [transactions/sec]

・Median block propagation time（ブロックの伝播時間の中央値）

・stale block rate：ブロックに対する、最長チェーンに含まれない（stale 状態）ブロックの割合

・double spending value：各種ブロックチェーンインスタンスのセキュリティ性能を測る指標

・relative revenue：利己的(selfish)なマイニングへの対応度を測る指標。全ネットワークノードがマイニングに

よって受ける報酬に対する、敵対する（一部の利己的な）ノードが受ける報酬の割合

＜変更パラメータ＞

・Block interval：ブロックを生成する間隔（時間）

・Block size：1 ブロックに格納できるデータ容量

上記、5 種類の指標と 2 種類の変更パラメータそれぞれとの関係を実験によって検証

2 Evaluation of Logic-Based

Smart Contracts for

Blockchain Systems

Florian Idelberger

Guido Governatori

Régis Riveret

Giovanni Sartor

ブロックチェーン技術を活用したシステムにおけるスマートコントラクトプログラムに

は一般的に手続き型言語が用いられているが、論理型言語はその代替となる可能性を持

った興味深い言語である。本文献では通常の契約を主とした一般的な活動の観点から、

論理ベースのスマートコントラクトの法的、技術的利点（および欠点）を検証し、この

ような論理ベースのスマートコントラクトをブロックチェーン技術を活用したシステム

といかに組み合わせるかについて洞察を与えている。これらの洞察は、”論理的なアプロ

ーチをとるアルゴリズムは効率的でなければならないが、経済的ルールに従いかつデプ

ロイされた環境内で容易に実行・評価されるものでなければならない”という根源的な課

題を強調するものである。以上のことを、解除条件付きの論理ベースフレームワークに

基づいた、異なるアルゴリズムを用いて説明している。

【評価対象】

論理型言語を用いたスマートコントラクトの有用性を評価（定性的観点）

【評価項目】

・Formation and Negotiation

－契約の（人間による）可読性

－契約内容確認にかかる時間的コストおよび確認時のエラー率

－人工知能による交渉および契約履行の代替可能性

・Contract Storage/Notarizing

－契約内容の（ブロック内への）保存が可能かどうか、および保存時に使用するデータ容量

（保存された情報は契約の存在および記載内容を認証するために使用される）

・Enforcement and Monitoring

－契約の正常履行に対する安定性（相互履行性）およびその監視 ・Modification：契約内容修正の安全性 ・Dispute resolution：契約の（人間による）可読性

（契約内容に関する論争時に、法律専門家が内容を理解し円滑に決議まで運ぶため）

16

3 On Scaling Decentralized

Blockchains

Kyle Croman

Christian Decker

Ittay Eyal

Adem Efe Gencer

Ari Juels

Ahmed Kosba

Andrew Miller

Prateek Saxena

Elaine Shi

Emin Gün Sirer

Dawn Song

Roger Wattenhofer

ブロックチェーン技術を活用した暗号通貨システムの人気の高まりによって、スケーラ

ビリティが最重要かつ緊急の懸案事項となってきている。本文献では Bitcoin Core の基本

的かつ状況的なボトルネックが、いかにして現在の Peer-to-Peer オーバーレイネットワー

クの安定した高スループットと低レイテンシ支持能力に制限をかけているかを分析して

いる。本文献の分析結果をみると、ブロックサイズとブロック生成頻度のリパラメタラ

イゼーションは、次世代の高負荷なブロックチェーン技術を活用したシステムのプロト

コルへ向けた第一の増強案とみなすべきであり、さらなる進展に向けては技術的アプロ

ーチの観点からの見直しが必要であると言える。その結果として、以上のようなアプロ

ーチ設計に対する構造的な見通しが提案されている。この見通しの中で近年提案された

多くのプロトコルアイデアを列挙、およびそれらに対する簡単な議論を行い、加えて新

たなアイデアとこれからの課題が述べられている。

【評価対象】

ブロックチェーン技術を活用したシステムのスケーラビリティ

（Position Paper のため、具体的な実験ではなくブロックチェーン技術を活用したシステムのスケーリングに関

する定量的評価指標をまとめている）

【評価項目】

・（最大）スループット：最大ブロックサイズ（1 ブロックに格納できるデータ容量）およびブロック生成間

隔（時間）に依存。2016 年時点（論文執筆時）で 3.3-7 transactions/sec

・レイテンシ：トランザクションが承認される（ブロックの一部となる）までの時間（＝新しいブロックが生

成されるまでの時間)。現在 10min/block。

・Bootstrap time：新たなネットワークノードの立ち上げ準備にかかる時間。ブロックチェーン技術を活用した

システム内の保持されている過去の履歴をダウンロードし、現在のシステム状態を検証するために必要な手

続きを行う必要があり、現在およそ 4 日間かかる。この値は履歴の蓄積に伴い線形に増加。

・Cost per Confirmed Transaction（CPCT）：1 トランザクションを承認する際に Bitcoin システム全体が消費す

るコスト（USD 換算）。以下の 4 項目において operational costs（主に消費電力）と capital equipment costs の

観点からコストが発生する。

- Mining：Proof of Work を解く際にマイナーによって消費されるコスト

- Transaction validation：トランザクションを承認するための計算資源

- Bandwidth：トランザクション送受信の頻度

- Storage：Blockchain 履歴を保存しておくためのストレージ

・Network Propagation Rate：ブロックのノード伝搬速度[kbps]。論文中にブロックサイズとの関係を評価した結

果を掲載

17

4 Bitcoin-NG(Next

Generation): A Scalable

Blockchain Protocol

Ittay Eyal

Adem Efe Gencer

Emin Gün Sirer

Robbert van

Renesse

Bitcoin を始めとする暗号通貨は、匿名のオンライン決済や安価な送金、ノードの信頼性

を問わないデジタルアセット交換、スマートコントラクトなど各種機能のインフラ基盤

としての可能性を持っている。しかしながら、Bitcoin に由来するブロックチェーン技術

を活用したシステムは、スループットとレイテンシのトレードオフ関係というスケーラ

ビリティにおける制限を持っており、これによって本来持っている潜在的な性能が抑制

されてしまっている。

本文献では、Bitcoin-NG（Next Generation）というスケールに適した設計がされた新たな

ブロックチェーン技術を活用したシステムのためのプロトコルを提案している。

Bitcoin-NG は Bitcoin と同様の信用モデルを採用した、ビザンチン障害耐性を有するブロ

ックチェーン技術であり、 極度の変化に対しても頑健なプロトコルとなっている。

Bitcoin-NG の提案に加え、Bitcoin ライクなプロトコルのセキュリティおよび効率を定量

評価するための新たな指標を導入している。Bitcoin-NG を実装し、実際の 15%スケール

の Bitcoin システムを用いて同一クライアントによる比較実験を行っている。これらの実

験において Bitcoin-NG は、帯域幅（トランザクション頻度）は個々のノードの処理能力

によってのみ制限され、レイテンシはネットワークの伝搬遅延時間のみによって制限さ

れるという結果が得られ、最適なスケーリングが可能であることが示されている。

【評価対象】

ブロックチェーン技術を活用したシステムのスケーラビリティについて、既存のプロトコルと提案プロトコル

「Bitcoin-NG」の比較実験を行っている

【評価項目】

＜指標＞

・Transaction Frequency（Bandwidth）：トランザクション送受信の頻度

・Consensus Delay(Latency)：システム全体が合意に達するまでの遅延時間

・Fairness：プール間でのマイニング競争の公平性を表す指標。全トランザクションの内、最大マイナー以外の

マイナーによって承認されたトランザクションの占める割合として算出される。

・Mining Power Utilization：コンセンサス遅延等によるマイニングパワーの損失抑制を表す指標。全ブロックに

対するマイニングパワーとメインチェーンブロックに対するマイニングパワーの割合として算出される。

・Time to Prune：（ブロック）フォークした枝の切り落としにかかる時間。フォークした枝のうち、切り落と

される枝の第一ブロックが生成された時間と、存続する枝の存続を確定させたブロックが生成された時間の

差として計算される。

・Time to Win：ブロックフォーク時に存続する枝が、切り落とされる枝の長さを超えるまでの時間。フォーク

した枝のうち、存続する枝の第一ブロックが生成された時間と、切り落とされる枝の末端ブロックが生成さ

れた時間の差として計算される。

＜変更パラメータ＞

・Block Frequency：ブロックの生成頻度

・Block Size：1 ブロックに格納できるデータ容量。

上記、2 種類の変更パラメータと 4 種類の指標との関係を実験によって検証。特に Block Frequency は Consensus

Delay との関係、Block Size は Bandwidth との関係を見て性能向上への検証を行っている。

18

5 The Blockchain Anomaly Christopher Natoli

Vincent Gramoli

Bitcoin に代表される、PoW に基づきコンセンサスによる保証された出力が得られるよう

な、多くの一般的なブロックチェーン技術を活用したシステムは多くの可能性が見込ま

れている。しかしその可能性は、メッセージ送受信や計算機パワーがネットワークノー

ドのプール間で十分に分配されているかに依存しており、クラウド以上に早くマイニン

グ可能なマイニングプールは今や存在しなくなっている。Ethereum のような新たなアプ

ローチは、個人に対し高いトランザクションスループットでプライベートな技術を活用

したシステムを構築させることで PoW によるアプローチを一般化している。企業もプラ

イベートチェーンのデプロイを開始してきており、これは小規模なコントロールされた

環境から提供されるブロックチェーン技術を活用したシステムの信頼性を検証・理解す

る上で非常に重要な動きであるといえる。

本文献では、NICTA/Data61 にプライベートチェーンを構築した際に経験した、ブロック

チェーン技術を活用したシステムの異常について紹介している。この異常はこれまで認

知されてこなかったが、ユーザーにとって劇的な結末を引き起こすものである。Paxos

anomaly にちなんで名付けたこのブロックチェーン異常は、”Bob が Alice からお金を受け

取った後に（その一部を）Carole に送金する”といったような従属的なトランザクション

を不可能にしてしまう。このブロックチェーン異常は、現存のブロックチェーン技術を

活用したシステムはコンセンサスの安全性を確実に保証できないという事実に基づいて

いる。その一例として、Bob にとって Alice が実際に送金を行ったかの確認は、そのお金

を引き出し可能な法定不換紙幣に変換するなどの外部機構を利用しなければ不可能であ

る。本文献では（上述のような）トランザクション以外にも資産を凍結させる可能性を

持つスマートコントラクトについても調査し、またこのようなブロックチェーン異常の

影響を受けてしまうスマートコントラクトの実装を紹介する。さらにそれらに対する対

応策についても述べている。

【評価対象】

ブロックチェーン技術を活用したシステムにおいて発生する、スワップ等の異常に対する検証（使用不能なト

ランザクションアウトプットの発生や、ダブルスペンド攻撃など各種脅威に対して脆弱な状態となる）

【評価項目】

以下、2 種類の実験において各種パラメータと指標の関係性を検証

１．時間経過とブロックチェーン異常の自動複製の関係検証

指標：レイテンシ（2 項目）

- 承認されたトランザクションがピア全体に伝わるまでの時間

- コンセンサス全体が終了するまでの時間

パラメータ：実験開始からの経過時間

2．マイニング difficulty とスワップ頻度の関係検証

※スワップ…ピア間のメッセージ遅延によって承認されるブロックの順番が入れ替わること

指標：レイテンシ（2 項目）

ブロックチェーン異常によって引き起こされるスワップの頻度

パラメータ：マイニングの difficulty

出所）各文献より MRI 作成

19

また、文献調査ではこれらのブロックチェーン技術関連の文献以外に、既存のシステム評

価に関する状況を把握するために、ISO/IEC25010（システム及びソフトウェア品質モデルに

関する国際規格）や独立行政法人情報処理推進機構（IPA）の各種報告書についてのレビュ

ーも実施した。これらの既存の枠組みは多くのシステムベンダーに活用されているものであ

り、今回の評価軸検討においても、これらとの整合性について留意しておくことが必要であ

ることが分かった。また、特に ISO/IEC25010 は評価項目としては網羅的に整理されている

ため、本検討において、非常に参考になることが分かった。

2.3 国内外のユースケースにおける評価状況の調査結果

国内外のユースケースとしては、以下 8 件の事例における評価状況を調査した。日本証券

取引所グループ（JPX）、ブロックチェーン研究会 8、リクルートテクノロジーズについて

は、有識者検討委員会でのプレゼンテーションも実施していただいた。

日本証券取引所グループ「証券取引における主要 7 機能の実現性およびシステム性

能・コストの検証」 ブロックチェーン研究会「国内の銀行間振込業務におけるブロックチェーン技術の実

証実験」 リクルートテクノロジーズ「ブロックチェーン技術による履歴書公証データベースの

利用」 Everledger（英国）「動産管理への応用」 欧州のエネルギー産業における応用事例 原子力発電所などの重要インフラに対するブロックチェーン技術の応用例（英国） ニューヨークにおけるマイクログリッドへの応用例（Brooklyn Microgrid） エストニア政府による ID 管理への応用例

2.3.1 日本証券取引所グループによる証券取引における応用事例

日本証券取引所グループでは、ブロックチェーン技術／分散型台帳技術（DLT：distributed ledger technology）の可能性に着目し、社内研究を進めており、2016 年には金融機関も参加

した実証試験を行い、結果の評価を行っている。 実証試験の概要を図 2-5 に示す。実証試験は、図中①～⑦の証券市場における主要 7 機

能の実現性及びシステム性能・コストの検証を行うことを目的として 2016 年 4 月～6 月と

いう短期間で実施された。比較的トランザクションの少ない市場における技術的な限界や可

能性について検討が行われた。 システムの構築は当初、現状の各証券業務（募集、発行／割当、コーポレートアクション、

権利配当など）をブロックチェーン技術の活用により置き換えるという発想であったが、そ

れでは一貫して業務を取扱うことができるブロックチェーン技術の特性が生かされないた

め、全過程を一貫して取り扱えるように業務を一部変更したシステム設計とした。

8株式会社みずほフィナンシャルグループ、株式会社三井住友銀行、株式会社三菱 UFJ フィナンシャル・グ

ループ、デロイトトーマツグループが参画し、ブロックチェーン技術の研究を推進している会。

20

図 2-5 JPX における実証試験の環境概要

出所）JPX ワーキングペーパー「金融市場インフラに対する分散型台帳技術の適用可能性について」2016年 8 月

同実証試験では、ブロックチェーン技術の適用可能性について、図 2-6 のような評価を

している。評価項目としては、スループット、セキュリティ、情報の秘匿性を上げ、その他

の技術的な要件としてスマートコントラクトの課題等、実装上の困難性を挙げている。

図 2-6 JPX における DLT 技術の適用可能性評価

出所）JPX ワーキングペーパー「金融市場インフラに対する分散型台帳技術の適用可能性について」2016年 8 月

21

2.3.2 ブロックチェーン研究会による銀行間振込みへの応用事例

ブロックチェーン研究会には、株式会社みずほフィナンシャルグループ、株式会社三井住

友銀行、株式会社三菱 UFJ フィナンシャル・グループ、デロイトトーマツグループが参画

し、ブロックチェーン技術の研究を推進している。同研究会では、ブロックチェーン技術を

適用し得る銀行業務を選定し、プロトタイプを作成した上で、動作確認／稼働検証、評価を

行っており、これにより、ブロックチェーン技術が有用であることが立証されれば、将来的

な実用化に向けた正式な仕様に発展させていくことも視野に入れている。 実証実験においては、仕向銀行・被仕向銀行がブロックチェーン技術を活用した環境に参

加し、本環境を介して振込指図の送受信を実施することで、資金決済の起動プロセスである

「ペイメント」をブロックチェーン技術を活用したシステムで実現するものとしている。 実験環境としては、図 2-7 に示す環境を整備している。コンセンサス方式の仕組みとし

ては PBFT に類する仕組みを採用し、本環境に参加するノードを、トランザクションを生成

するアプリノードと、トランザクションを承認してブロックを生成するコアノードの 2 つに

分類した上で、銀行はアプリノードとして参加する形式とした。

図 2-7 構築された実証環境イメージ

出所）ブロックチェーン研究会「国内の銀行間振込業務におけるブロックチェーン技術の実証実験に係る

報告書」2016

実証試験の検証としては、「機能観点」「技術観点」「コスト観点」の大きく 3 つの観点

から評価が行われた。 機能観点は、銀行間の送金のシステムとして必要な機能が実装できるかどうかを定性的に

22

評価している。技術観点については、銀行間振込業務として実運用に必要となる水準（リク

ワイアメント）に鑑み、可用性、性能、拡張性、保守性、セキュリティ、データ完全性とい

う 6 項目で、それぞれ評価指標（サービス稼働率、ディザスタリカバリータイム 9等）を設

定して評価を行っている。性能におけるスループットなど、定量的な評価が可能なものは定

量的に評価しているが、多くの項目は定性的な評価を行っている。

図 2-8 技術観点の検証軸と検証結果概要

出所）ブロックチェーン研究会「国内の銀行間振込業務におけるブロックチェーン技術の実証実験に係る

報告書」2016

コスト観点としては、イニシャルコストとランニングコストに分け、削減可能性のあるコ

スト項目としては、アプリケーション開発費、ソフトウェア（ミドルウェア・OS）購入費、

ハードウェア購入費、保守・運用費が挙げられている。

2.3.3 リクルートテクノロジーズによる履歴書公証データベースへの応用事例

リクルートテクノロジーズでは、「改ざんなく情報を記録していける」機能と「分散的に

データが保全される機能」にフォーカスし、ブロックチェーン技術をどのように活用できる

かを考え、様々な実践的検証を行っている。既存のノウハウを適用し検証可能なユースケー

スのひとつとして、転職活動者と企業の採用担当者における利用を想定した「履歴書公証デ

ータベース」を選択し、プロトタイプ開発に着手した。今まで紙を用いることが一般的だっ

た契約や公的証明書の確認を、ブロックチェーン技術を使ったデータベースを置き換えると

9災害等被害からの回復措置／被害を最小限に抑える予防措置

23

いうものである。運用イメージを図 2-9 に示す。

図 2-9 履歴書公証データベースの利用フロー

出所）リクルートテクノロジーズプレスリリース 2016 年 4 月 25 日 （http://recruit-tech.co.jp/news/images/20160425_PressRelease.pdf）

履歴書公証データベースの全体フローは以下、1)～4）の通りである。このフローを技術

的な観点から 3 つのステップを踏んで行っている 10。

1) 求職者が自身の経歴を登録し、企業に対して承認の要求を行う。 2) 求職者が所属していた学校および企業が受け取った要求を承認する。 3) 求職者が就職を希望する企業に対し、所属していた学校及び企業が承認した経歴

を公開する。 4) 就職を希望する企業側が求職者に公開してもらった経歴を閲覧する。

現在、転職活動者は、転職希望先の企業に、卒業証明書や過去在籍した企業の所属証明書

など、さまざまな公的書類を提出する必要がある。履歴書公証データベースが実現すれば、

一連の作業をブロックチェーン技術を活用したデータベースを通じて行うことが可能とな

る。これにより、転職活動者は複数の公的証明書を収集する労力が軽減でき、採用企業側に

とっても求職者の経歴詐称の心配がなくなることに加え、より安全に機密文書である公的証

明書を取り扱うことができるようになるなど、両者にとってのメリットは大きい。

10 技術検証ステップの詳細は次を参照のこと。http://www.atmarkit.co.jp/ait/series/3732/

24

このようなブロックチェーン技術を活用したシステムでは、入力されたデータが改ざんさ

れていないことと、たとえデータの発行主体（この場合は卒業証明書を発行する学校等）が

無くなったとしてもデータは消滅しないことが保証される。しかし、最初に入力されたデー

タがそもそも正しいかどうかということや、その利用者にとって必要十分なデータが揃って

いるかどうかなどはわからないため、何らかの管理者が必要になり、それがリクルート等の

事業者の役割になると考えられる。 本ユースケースは転職市場に関係する独立したプレーヤーがそれぞれ行う業務を、ブロッ

クチェーン技術を活用したデータベースに集約し、機能的に行おうというものである。既存

の仕組みとの比較評価を考えると、まず、転職活動に係る公的書類のデータベース化は、転

職活動者の機会損失リスクを大幅に低減すると考えられる 11。また、ひとつのプラットフォ

ームへ採用業務が集約されることで、重複業務の削減や採用プロセスの縮減、あるいは自動

化につながり、採用活動にかかる業務効率を大幅に改善させる可能性がある。 評価軸の検討という観点からは、業務効率化というブロックチェーン技術の特性を適切に

評価できる評価項目の検討が求められる。

2.3.4 Everledger（英国）における動産管理への応用事例

ロンドンに本拠を置く Everledger は、ダイヤモンドが鉱山から産出され消費者の手に渡る

までの過程を追跡し、ダイヤモンドの鑑定情報や取引履歴、移転証明などをブロックチェー

ン技術を活用したシステム上で管理する仕組みを実現した。 当該システムには、ダイヤモンドの所有権移転記録だけでなく、センサーで個々のダイヤ

モンドの形状を厳密に測定したデジタル指紋に加え、鑑定書情報も格納されているため、購

入者はダイヤモンドの真贋はもちろん、その来歴を確認することができる。 「データの改ざんは不可能」、「データを分散して安全に管理」、「スピーディな情報共

有が可能」というブロックチェーン技術の特徴は、動産管理につきものの鑑定書の偽造や保

険金の詐欺、また、マネーロンダリングによるテロ資金の温床といった問題を解決し、社会

課題解決型のエコシステムを作り上げることに成功した事例である。 現在 98 万個のダイヤモンドをブロックチェーン上で管理しており、API を公開すること

で警察、銀行や保険会社もデータの参照可能にしている。結果、盗品を取引市場から排除す

ることにも成功しており、ダイヤモンド自体の価値を引き上げることにもつながっている。

また、いわゆる「ブラッドダイヤモンド」12が取引市場を通じて紛争地域のテロ資金となる

ことを阻止することにより、社会課題の解決にも寄与する可能性があることから、社会的意

義も大きいと言える。

11 たとえば、転職活動における学位証明取得にはおおよそ 2~3 週間を要すると言われている。 12 ブラッドダイヤモンドと呼ばれる、紛争地域のダイヤモンドは、取引で得た外貨が武器の購入に充てら

れるため、内戦が長期化および深刻化する原因となっている。汚れたダイヤモンド（Dirty Diamond）、

戦争ダイヤモンド（War Diamond）とも言われる。したがって、ブラッドダイヤモンドの取引市場からの

排除は、テロ資金の根絶につながり、戦争の長期化や深刻化の回避にも寄与することが期待される。途上

国にとって紛争は経済成長の大きな阻害要因であり、その回避は結果として、途上国の経済伸長にも貢献

する可能性がある。

25

図 2-10 Everledger（英国）による動産管理の概念図

出所）Justin Ramos “Blockchain: Under the Hood”, 2016 年 8 月 （https://www.thoughtworks.com/insights/blog/blockchain-under-hood）

これは、ブロックチェーン技術を活用した新たな仕組み（新サービス）の導入と考えられ

る。ダイヤモンドの管理には多数の主体が分散的に関わるために、各主体の利害を調整し、

中央管理を行うことができなかったが、ブロックチェーン技術を活用することで、このよう

に多数のメリットを持つ仕組みを実現することができた。既存の仕組みの障害を技術の力で

取り払うことにより、新たな仕組み・サービスを創出できるということは、ブロックチェー

ン技術のひとつの特徴であるため、本検討においても、このような新たな仕組み・サービス

創出の評価をどうするかについて検討する必要があると考えられる。

2.3.5 欧州のエネルギー産業における応用事例

エネルギー分野では、再生可能エネルギーの普及に伴い発電設備の地理的な分散化が生じ

ている。家庭や事業所等、電力の利用者は分散していることに加え、電気自動車や家庭用蓄

電池の普及によりストレージ側の分散も始まっている。この動きが最も進展しているのが欧

州である。欧州の電力各社は分散された電力・データネットワークシステムを運用する技術

としてブロックチェーン技術に着目し、数多くの取組みが行われている。 ドイツの大手電力会社である RWE 社は、Ethereum を用いた認証・決済システムを搭載し

26

た電気自動車（EV）の充電システムを開発した。システムはドイツのブロックチェーン技

術関連のスタートアップ企業である Slock.it との共同開発を行った。

図 2-11 RWE 社が開発した充電システムとアプリケーション

出所）Slock.it 社プレゼンテーション資料（http://clicccar.com/2016/08/12/392194/）

従来の EV は充電中は車を使用できないという難点を持っていた。また、充電時間も長く、

その上、充電スタンドでは 30 分や 1 時間など、時間単位で料金が請求されるため、補充時

間の下限が設定されるといった不便さもあった。これらが EV 普及のネックとなっていた。 RWE と Slock.it はブロックチェーン技術によるスマートコントラクトを用いてその問題

を解決した。あらかじめ EV にデジタル・ウォレットをリンクさせておくことにより、充電

スタンドでは時間単位ではなく補給量単位で支払いを可能とした。スマートコントラクトに

より、支払いに関する時間が削減されたことで、信号待ち程度の時間でも、道路に設置され

た充電ポイントからこまめに充電することも現実的となった。車のデジタル・ウォレット化

である。 既存の仕組みとこのシステムを比較した場合の最大のメリットは、充電に関する利便性の

向上だが、決済手段も大幅に簡素化されるメリットも大きい。後者は特にブロックチェーン

技術の特性に関連するメリットであると考えられる。スマートコントラクトというユースケ

ースを想定した場合には、取引の自動化、所要時間の短縮化という効果が見込まれるため、

それらを適切に評価できる軸を検討する必要がある。

2.3.6 原子力発電所などの重要インフラに対するブロックチェーン技術の応用例（英国）

Guardtime 社（本社オランダ、米国・エストニアに拠点）は英国の the UK Future Cities Catapult と連携して、英国の重要なインフラ（治水のためのインフラや、原子力発電所、送

配電網など）のサイバーセキュリティ向上のためにブロックチェーン技術を活用したシステ

ムを開発している。 Guardtime 社は Keyless Signature Infrastructure（KSI）と呼ばれるブロックチェーン技術を

活用して、セキュリティ技術を開発しており、この技術をインフラ管理に適用しようとして

27

いる。Bitcoin がブロックチェーン技術活用した公共の台帳を仮想通貨の取引記録を行うた

めに用いているのと同様、KSI は公共の台帳をデータトランザクションのために使用し、認

証や承認のための管理者を不要としている。これにより、これまでの物理的なセキュリティ

を超えるサービス提供が可能になり、重要なシステムを保護するための役割を果たすことが

できるようになっている。 これまで、重要なインフラ技術についてシステムとプロセスそしてデータの整合性を継続

的に担保するためには、管理者を適切に配置し、慎重にデータの突合を行いながら対応する

ことが必要であった。しかし、ブロックチェーン技術を活用することにより、管理者が不要

になり、手続きも自動化できることとなる。これにより、以下のメリットが得られると評価

できる。

データの改ざん耐性が高くなることにより、データ突合の必要性が無くなり、手続き

の自動化（ネットワーク化）が可能になる。 手続きが自動化されることにより、オペレーションスピードが向上する 自動化により、人為的なミスが入り込む要素が無くなる 上記を通じて、結果として重要インフラのセキュリティが強化され、スマート化を促

進させることとなる。

既存の仕組みと比較して当該システムが優れている項目（評価すべき項目）としては、ま

ずデータの改ざん耐性が挙げられる。そして、自動化が行われた結果として、手続きのスピ

ード向上や、インフラ自身のセキュリティ強化が実現される。これを勘案すると、評価軸の

検討においてはブロックチェーン技術に直接紐づく特性の比較と、システムとして実現され

る特性の比較との両面を行うことができることが望ましいと考えられる。

2.3.7 ニューヨークにおけるマイクログリッドへの応用例（Brooklyn Microgrid）

ニューヨークのブルックリン地区にある President Street における小規模系統において、

TransActive Grid 社は Ethereum を用いた Peer-to-Peer の電力売買システムを開発し、実際に

取引が行われている。売電者は太陽光パネルの余剰電力を売り、買電力者は、TransActive Grid のスマートメーターを介して電力を購入することとなる。このとき、実際の取引・契

約は Ethereum によって自動実行される。 システムとしては、まず、ある家庭において、電力が生成されたことをスマートメーター

が検知すると、「エナジークレジット」と呼ばれるトークンが生成される。エナジークレジ

ットはマイクロエナジーマーケットでスマートコントラクトに基づいて取引され、電力の生

産者は収入を得て、電力の消費者はこのトークンを買い取り、電力を消費するとトークンが

消滅する。トランザクションはブロックチェーン上で自動的に処理・検証され、エナジーク

レジットの二重カウント、不正の発生などを防ぐことができる。ブロックチェーン技術を活

用したシステムによる取引の透明性の高さにより、外部監査は不要な仕組みとなっており、

このことも電力売買コスト削減に寄与している。

28

図 2-12 ブルックリン地区にある President Street における小規模系統の状況

出所）http://brooklynmicrogrid.com/

日本でも電力小売全面自由化により、消費者が電力会社を自由に選択できるようになった

が、電力の売買に関しては送配電を運用している電力会社を通じてしか取引できない仕組み

となっている。これに対し、TransActive Grid のシステムは、個人が電力を消費するだけで

なく、マイクログリッドに参加する近隣の参加者が直接発電した電力や余剰電力の売買を行

うことを可能にした。ブロックチェーン上に書き込んだ契約に即して、売買が自動実行され

るため、第三者が介在しなく、運用コストが削減されるだけでなく、価値観を同じくする近

隣住民が、透明性を容易に保ちながらマイクログリッドを運用し、クリーンエネルギーの電

力を売買できる点が特徴的で、CO2 の削減に寄与することのみならず、自律型エコシステ

ム実現により地域経済の活性化にも寄与することができる、画期的な電力シェアサービスの

ユースケースである。 既存の仕組みと比較すると、スマートコントラクトにより、契約のコストが低下し、消費

者間の直接売買が可能になっている。RWE の事例同様、スマートコントラクトによるコス

ト・手間の低減効果はブロックチェーン技術の一つの大きな特徴であり、適切に評価すべき

対象となると考えられる。

29

図 2-13 TransActive Grid のシステム概念図

出所）http://brooklynmicrogrid.com/

2.3.8 エストニア政府による ID 管理への応用例

エストニア共和国は、人口約 130 万人の国であり、現在は EU に加盟している。「e-State」として政府（統治）の再定義から始め、デジタル化によって人々の生活やビジネスをシンプ

ルにすることを推し進めてきた。 エストニア電子政府（e-Estonia）のシステムは分散型のアーキテクチャを採用しており、

その中核部には「X-Road」と呼ぶシステム間連携基盤がある。各種政府機関はそれぞれ「独

立に最適な技術を利用」しつつ、他のシステムと連携できる。X-Road のプロトコル仕様書

によれば、内部的には SOAP1.1、WSDL1.1 など XML Web サービスの技術を用いており、

汎用性が高い XML ベースのプロトコルを使い、政府機関が抱える多数のデータベースを連

携している。

30

図 2-14 「X-Road」の概念図

出所）エストニア電子政府の公式サイト（https://e-estonia.com/）

ブロックチェーン技術は、各種政府機関や民間企業が X-Road にぶら下がるシステムの一

つとして選択するもので、これまでに「ブロックチェーン技術を ID カードに導入」「医療

データの記録にブロックチェーン技術の利用へ」「ブロックチェーン技術で公共のサービス

を提供開始」などの取組みが公表されている。 エストニアは e-state 構築に向けたビジョンとして、表 2-7 に示す 7 つの「E」を打ち出し

ている。これらは、各種政府機関が技術を選択する際の評価軸としての役割を果たしている

（具体的な評価指標等があるわけではないが、ビジョンとの整合性という観点で評価軸的な

性質を有していると考えることができる）。ブロックチェーン技術に限らず、新技術を横断

的に評価できる枠組みとして参考になる考え方である。

表 2-7 エストニアが e-state 構築に向けて掲げるビジョン

7E 和訳 ビジョンの内容 Empowering エンパワー／権

限の付与 国民に多くの権限を与え、デジタル化によってほとん

どの申請やサービスをオンラインで提供する Easy 簡易性 すべてのサービスが 1 つの Web サイトからアクセス

でき、デジタル化したソリューションを簡単に使える Efficient 効率性 デジタル化によって時間やお金などの節約を図る Economical 経済性 仕組みをデジタル化することで、業務に要する時間や

人の増加を防ぎ、運用コストの節約を図る Everywhere どこでも 「社会的権利」であるコネクティビティとサービスへ

のアクセスを国内全土だけでなく、海外からのアクセ

31

スにも広げる Engaging 協業 e-states の構築を国民や関係団体との合意に基づく協

業によって実現する Egalitarianism 公平性・透明性 データは厳重なセキュリティ保護のもとに管理し、

NTK（Need-to-Know）に基づいた公平なアクセスを実

現する

出所）IT Leaders「ブロックチェーンも活用する“e 国家”エストニアにみる戦略としての IT」2016 年 9 月

19 日、大和 敏彦（ITi 代表取締役）より作成

ブロックチェーン技術は、オープン型の場合、多数のノードが取引等に自由に参加できる

ため、「Empowering（エンパワー／権限の付与）」に優れた技術だと考えることができる。

また、中央集権が不要となると、「Efficient（効率性）」や「Economical（経済性）」にも

優れた技術となる可能性がある。また、ブロックの中身を参加者が共有できるという仕組み

は「Egalitarianism（公平性・透明性）」に優れた技術と考えることができる。つまりブロッ

クチェーン技術はエストニア政府が推し進めたい電子政府の方向性と親和性の高い技術で

あるため、今後も導入は増加していくことが想定される。 エストニアは IT 先進国であり、また国土面積や人口規模も小さいためこのような先進的

な取組みができていると考えられるが、政府の効率化、国民の利便性など大きな効果が出て

いることは事実であり、EU またはその他の先進国・大国へも電子政府化の流れが進んでい

くとの意見も数多くみられる。

2.4 関係者・有識者へのヒアリング調査結果

有識者検討委員会での検討と並行して、関係者・有識者へのヒアリングを行い、評価軸検

討に当たっての示唆を得た。主要な論点を以下に示す。これらの論点については、有識者検

討委員会での議論にフィードバックし、議論を進める参考とした。また、システムベンダー

からの要望については、有識者検討委員会の中で各社から直接プレゼンテーションを実施し

ていただいた。

表 2-8 関係者・有識者へのヒアリング調査結果

提示された論点 ブロックチェーン

技術を活用したシ

ステム開発事業者

・ ブロックチェーン技術は発展途上の技術で、技術的に難しい面も

多い。実りのある議論のためには、技術をよく理解している委員

が入る必要がある。 ・ 評価軸の検討はブロックチェーン研究会で検討を行った。レポー

トも公開予定であるため、参考になると思われる。 ・ ブロックチェーンプラットフォームの比較を行うのであれば、ブ

ロックチェーン技術の定義が重要になる。ユースケースで考える

と、アプリケーションレイヤでの議論が多くなると考えられる。 ・ パブリックチェーンとプライベートチェーンでは評価軸を変え

る必要があるかもしれない。

32

・ コスト比較は難しい。性能とのトレードオフなどの側面が大き

く、単純に比較することができない。 システムベンダー ・ 評価軸を作成するためには、システムを理解している人が検討し

なければいけない。 ・ 評価軸の検討は有益だが、難しい議論になることが想定される。

ブロックチェーンプラットフォームのどのシステムを対象とす

るか、アウトプットの使い道など、議論の土台をあらかじめ設定

するべき。 ・ IPA のシステム評価軸（システム・リファレンス・マニュアル等）

は参考になると考えられる。 ・ パブリック型ブロックチェーン技術とコンソーシアム型ブロッ

クチェーン技術の適用用途をまとめたうえで、それぞれ評価軸を

整理した方が実用的と考えられる。 ・ すでに実装、もしくは White paper が出されているオープンソー

スのブロックチェーン・ソフトウェアを対象にいくつかをピック

アップし、その特徴とアーキテクチャを説明すると理解度が深ま

る。 ・ ブロックチェーン技術特有のリクワイアメントをリスト化し、評

価軸として整理することも有効。 ・ リクワイアメントは機能要件と非機能要件に分かれるが、汎用ユ

ースケース毎に、機能要件に関する評価項目を策定し、非機能要

件に関する評価項目はユースケース非依存として取りまとめる

ことも考えられる。 ・ 具体的なブロックチェーンプラットフォームに対して、何ができ

て／できないかをまとめるニーズは高い。 ・ できれば各ユースケースを実現するために必要なリクワイアメ

ントをまとめられるとよい。 ・ IT アーキテクチャ的にいうと非機能要件は品質要求と制約にわ

かれる。制約は、各ユースケースにおいて、関連する法制度（整

備が必要な法律）について整理することで把握できる。 学識経験者 ・ 評価軸の設計は重要である。結論として「ブロックチェーン技術

は平均点は下がるが、とびぬけて良い項目がある」ことがわかり、

良い応用先（金融以外で）が見つけられるとよいと考えている。 ・ 評価軸の設計は非常に難しい。分散型データベースの評価は各社

によって条件が異なる。極端に異なる条件下にあるシステム同士

の比較となってしまうと意味をなさないと考えられる。 ・ 日本証券取引所など実証実験を行った人にゲストとして来ても

らい、どんな視点で実証に取組んだのか、やろうと思ってできな

かったのがどこか、等を話してもらいたい。 ・ 最終的に定性要件の整理と定量要件の測定方法が決まればよい

のではないか。IPA の過去のシステム評価などが参考にできるの

33

ではないか。 ・ ブロックチェーン技術のメリットは共有性と考えているので、そ

れを評価できるとよく、また、そのメリットが生かされる分野を

中心に実用化が進むと考えている。 ・ ブロックチェーン技術はつまるところデータベースなので、デー

タベースの評価指標が原則そのまま使えると思っている。その適

用で不都合が生じる部分を中心に議論ができればよい。

2.5 国内外動向調査のまとめ

文献調査、ユースケース調査、関係者ヒアリングを通じた事前調査の結果得られた知見に

ついて以下の通りまとめる。 文献調査の結果、ブロックチェーン技術を活用したシステムの評価について、網羅的

に評価軸の設定を行った事例は国内外において存在しなく、本調査で新たな検討が必

要であることが分かった。さらに関係者からのヒアリングを通じて、検討に当たって

は、ISO/IEC25010 や IPA の整理（システム・リファレンス・マニュアル等）が参考

になることも示唆された。 ブロックチェーン技術を活用したシステムの評価について既存のユースケースの評

価事例を見ると、以下の 2 つの側面から評価が行われていた。前者については、実装

可否が定性的に評価されていることが多く、後者については、スループット、レイテ

ンシ、スケーラビリティ、セキュリティなどが注目される評価項目として挙げられて

いた。 ブロックチェーン技術を活用したシステムが必要な機能を実現できるのかどう

か 実現できた場合に既存システムや他のブロックチェーン技術を活用したシステ

ムと比較して性能がどうか 動産管理や政府による ID 管理など、比較対象となる既存システムが存在しない応用

事例も散見された。このような事例の場合、機能の実現性が定性的に評価されるのみ

で、性能の定量的な評価は問題視されていないようであった。 関係者・有識者ヒアリングでは、ユースケースをベースとした検討の重要性について

も示唆された。ユースケースによってリクワイアメントが異なるため、ブロックチェ

ーン技術がそれらの要件を充足できるかどうかを評価することの重要性が指摘され

た。また、パブリック型のブロックチェーン技術を利用する場合とプライベート型の

ブロックチェーン技術を利用する場合では、求められる機能・性能が異なるために、

評価軸・評価方法も変えなければいけない可能性も指摘された。 これらの知見は、有識者検討委員会での論点提示の根拠とするとともに、各論点の方向性

を定めるにあたっての参考情報として活用した。方向性検討に当たって、具体的にどのよう

に参考としたかは、3.1 の各論点の部分に記載をしている。

34

3. ブロックチェーン技術を活用したシステムの評価軸に関する検討結果

ここでは、評価軸の検討に当たっての事前検討内容とそれを踏まえた、評価軸の検討結果

を示す。

3.1 評価軸検討に当たっての論点と各論点に関する検討結果

事前の調査と有識者検討委員会での議論を通じて、具体的な評価軸を検討するためには、

評価の目的、評価の対象、評価軸の構成要素（評価項目・指標・方法等）について検討する

ことが必要であることが明らかとなった 13。まず重要な点が「評価軸の目的」である。目的

を定め、評価軸を誰が誰のために使うのかを明確化しなければ、具体的な軸を考えることは

できない。議論した目的については、1.1 調査の背景と目的、検討範囲に示している。 また、「評価の対象」を明確にすることも軸の設定のために不可欠である。ブロックチェ

ーン技術の場合、技術自身が発展途上であり、その定義も不確定な状況ではあるが、評価の

目的と照らし合わせて何を評価対象とすべきか、評価対象による違いをどのように評価軸に

反映させるかを検討した。 最後に目的と評価対象を踏まえた、評価軸の構成要素について検討を行った。なお、評価

軸とは複数の評価項目の総体として定義されるものである。評価指標は個別の評価項目につ

いて、実際に評価を行う際に取得するデータ項目を指し、評価方法はそのデータをどのよう

な条件の基でどのように取得するかを定めるものである。

評価軸の目的

誰が何のために評価を行う際に利用する評価軸なのか

評価の対象

既存システムとブロックチェーン技術を活用したシステムを比較するのか、ブロ

ックチェーン技術を活用したシステム同士を比較するのか ブロックチェーンプラットフォームを評価するのか、システム全体を評価するの

か これまで世の中にない新規サービスをどのように評価するのか パブリック型とコンソーシアム型／プライベート型では求められる機能が異な

るが、どのように評価軸に反映させるか ユースケースによりリクワイアメントが異なるが、どう評価軸に反映させるか

評価軸の構成要素（評価項目・評価指標・評価方法等）

何を評価項目とするか 評価指標は一律に定めるのか、自由度を持たせるのか 評価方法についてはどこまで定めるのか（標準的手法を検討するのか）

13 事前調査だけでこれらの論点を洗い出すことはできず、第 1 回・第 2 回での発散的な議論を経て、よう

やく論点の洗い出しを行うことができた。よって、本論点には 2.5 のまとめに記載されていない内容も含ま

れることとなっている。

35

それぞれの検討項目に関する主な議論の内容と、本調査における結論について、図 3-1に示す。

36

図 3-1 ブロックチェーン（図中では BC と表記）技術を活用したシステムの評価軸の検討に当たっての論点と方針

評価軸の目的

議論を踏まえての方針検討項目 議論内容

• BC技術の価値を社会・関係者にわかってもらえるような評価軸を考えたい• 標準化の議論も視野に入れながら検討をする必要がある• 定量評価をこの検討の中で行うのか、検討が必要

（行う場合、性能データをどう取得するかも検討が必要）

BC技術を活用したシステムの特性を適切に表現する 想定する利用シーンにおいて、必要十分な評価項目

を網羅する 本事業では実際の評価は行わない

（データ収集は実施しない）

評価の対象

比較の範囲

業務変革への対応

ユースケースの網羅

評価軸の構成要素

• BCプラットフォームを評価するのか、システム全体を評価するのか• BCプラットフォームによってできることが違うため、プラットフォーム同士を単純に機能

比較することはできない• ユーザーニーズはシステム全体の評価にあることが多い

BCプラットフォーム＋サブシステムを評価対象とする 個別BCプラットフォームの機能評価（○×表の作

成）は実施しない

• 業務要件を固定／業務変革を含めて評価する、という2つの観点がある• 社会・業務を変えることを考えないとBC技術の特性は生かされない• 本当に業務・仕組みを変える場合とシステムの在り方だけを変える場合がある• 新規の場合（特にスマートコントラクト等の新しい考え方、技術を活用する場合）、

法律・商慣習など超えるべきハードルが高い

業務の目的・要件が変わらないのであれば評価軸の対象とする

今までに全くなかったようなシステムについては比較対象が存在しないため、評価軸の対象外とする

• ユースケースから抽象的な要件を抽出して、整理すれば評価ができるかも• 何を秘匿とするか、第三者が必要か、などがユースケースにより異なる• ケースに応じてどのようなBCプラットフォームが適しているか知りたいニーズは高い

ユースケースによる違いは考慮する 多様なユースケースとリクワイアメントを想定した上で、

抜け漏れが無いことを担保する

• 評価をする上でコストは非常に重要 ・ 項目は網羅性が不可欠• コスト／性能、性能間のトレードオフの関係を捉えることが必要• 評価に当たっては前提条件を明確にすることが不可欠• データ秘匿、データの真正性、スループットなどは関心の高い評価項目

「品質」、「保守・運用」、「コスト」が評価大項目 一律の評価指標や評価方法は設定せず、実際評価

する際に留意すべき点などの記載を充実させる BC技術を活用したシステムの特性に関連性の高い評

価項目のみを抽出し整理

比較対象 • 既存システムと比較するのか、BC技術を活用したシステム同士を比較するのか• 現状は既存システムとの比較が多いが、将来的にはBC同士の比較も必要 両方を網羅的に扱うことのできる評価項目とする

プラットフォームの分類

• パブリック型BCとコンソーシアム型・プライベート型BCでは求められる（実装される）機能が大きく異なり、同一の評価軸設定は難しい可能性がある

• ブロックチェーンの類型化、定義にも数多くの意見があり、定まっていない 評価軸としては全てのパターンを網羅する軸を考える 型による違いは、備考欄等へ特性を記載

37

3.1.1 評価軸の目的について

評価軸は、ブロックチェーン技術を活用したシステムの特性を適切に表現し、想定する利

用シーンにおいて、必要十分な評価項目を極力網羅的に提示することを目的とした。 利用シーンとしては、「既存システムをブロックチェーン技術を活用したシステムに置き

換える場合の比較評価」や「ブロックチェーン技術を活用したシステムの実証試験結果の評

価」などを想定し、前者を特に重視した。また、評価を行う主体としては、システムベンダ

ーを想定した。 なお、有識者検討委員会の中では、実際の定量評価を試行的にでも本調査事業の中で行う

かどうかが大きな論点となったが、本調査事業の目的は、実際のブロックチェーンプラット

フォームの優劣を示すことではないため、定量評価は行わないこととした。

3.1.2 評価の対象について

評価の対象については、大きく「何と何を比較対象とするのか」という観点と、「比較対

象による違いをどう評価軸に反映させるか」という観点の 2 つについて検討を行った。

(1) 何と何を比較対象とするのか

何と何を比較対象とするかという点については、以下の 2 つの論点が存在する。

既存システムとブロックチェーン技術を活用したシステムを比較するのか、ブロック

チェーン技術を活用したシステム同士を比較するのか ブロックチェーンプラットフォームを評価するのか、システム全体を評価するのか

1 点目の「既存システムとブロックチェーン技術を活用したシステムを比較するのか、ブ

ロックチェーン技術を活用したシステム同士を比較するのか」という点については、いずれ

のケースもニーズとしては高いため、両方に対応できる評価軸を設定することとした。その

際に、既存のシステム評価の枠組みと対応させた方が利用者（システムベンダー等）は利用

しやすく、導入検討者も理解しやすいと考えられるため、評価軸は、ISO/IEC25010（システ

ム及びソフトウェア品質モデル）と IPA（システム・リファレンス・マニュアル 14、第 4 章

保守・運用、2005 年）が整理した既存のシステム評価の枠組みをベースとすることとした。 2 点目の「評価の対象をブロックチェーンプラットフォームのみとするか、ブロックチェ

ーン技術を活用したシステム全体とするか」については、有識者検討委員会においても大き

な論点となった。どのブロックチェーンプラットフォームを利用したらよいかを把握したい

ユーザーが多く存在すると推測される点や、ブロックチェーン技術を評価するという目的で

は、プラットフォームに特化した評価軸を検討すべきという意見もあったが、以下の理由に

より、システム全体を評価対象とすることとした。

ブロックチェーンプラットフォームによって実装している機能の範囲等が異なり、横

14 https://www.ipa.go.jp/about/jigyoseika/05fy-pro/chosa/2005-srm2.pdf

38

並びでの比較が難しい ブロックチェーンプラットフォームのシステムへの組み込み方、実装方法によって、

システムとしての機能・性能も違ってくるため、ブロックチェーンプラットフォーム

同士の単純な機能・性能比較はユーザーにとって有益な情報とならない プラットフォーム同士を比較する場合、ブロックチェーンプラットフォームが具備す

べき機能が定まっていれば、その部分だけを比較評価することも可能だが、何を具備

すべきかについての共通合意がない システムを利用するユーザーにとって重要な評価軸は、システムとしての機能や性能

であるため、周辺サブシステムを含めたシステム全体を評価対象にしたほうが有益で

あり、投資判断等に役立つ

評価対象検討のイメージを、図 3-2 に示す。上述のように、本調査では赤色の矢印で示

している 2 つの観点に対応できる評価軸を検討することとした。

図 3-2 評価対象の概念図

(2) 比較対象による違いをどう評価軸に反映させるか

比較対象による評価内容の違いとしては、以下の 3 点が論点となった。

これまで世の中にない新規サービスをどのように評価するのか プラットフォームの分類（パブリック型とコンソーシアム型／プライベート型

等）の違いにより求められる機能が異なるが、どのように評価軸に反映させるか ユースケースにより異なるリクワイアメントを、どのように評価軸に反映させる

プラットフォームの比較

既存システムとブロックチェーン技術を活用したシステムの比較

ブロックチェーンプラットフォームA

ＡＰＩ

サブシステム

データベース

利用者

集中管理型DB

ＡＰＩ

アプリケーション

既存システムブロックチェーン技術を活用したシステムA

利用者

ブロックチェーンプラットフォームB

ＡＰＩ

サブシステム

ブロックチェーンプラット

フォームの比較：本調査の検討対象

：本調査の検討対象外※

ブロックチェーン技術を

活用したシステム同士の比較ブロックチェーン技術を

活用したシステムB

利用者

《凡例》

※ 検討・作成した評価軸が結果としてプラットフォーム同士の比較にも一部使える可能性はある。

39

か

ブロックチェーン技術の特性を考えると、最もその特性が生かされるのは今までに社会に

無いようなサービス・仕組みを提供することができた場合であると考えられるが、このよう

なサービスが世に出た場合、比較対象となるサービス・仕組みは世の中に存在しないため、

評価軸を用いた比較評価を行うことはできない。しかし、有識者検討委員会ではこのような

新サービスをどうやったら社会実装できるのかという点を検討することの重要性が指摘さ

れた。この点に関する条件整理は今後の検討課題になると考えられる。 また、プラットフォームの分類（パブリック型とコンソーシアム型／プライベート型等の

分類）によっては求められる機能が異なるという点に関しては、たとえば、有識者検討委員

会にて「パブリック型で認証局について言及したり、コンソーシアム型で PoW でのインセ

ンティブを語ったりするのは適用用途が異なるため評価軸は分けたほうがいいのではない

か」という提案があった。それに対し、本検討では全てのパターンを網羅できる軸を考える

こととし、「型」による評価対象の違いは、「本評価軸を活用する際の留意点、備考等」に

参考情報を記載することとした。 ユースケースによる違いについては調査対象文献でもそれぞれ特徴的な評価項目を取り

上げて評価を行っていたり、有識者検討委員会でも多くの議論が行われたりするなど、注目

して検討すべきテーマと考えられる。具体的にはユースケースによっては、以下が異なって

くる。

当該システムを用いて達成しなければならない業務要件 業務要件のうち、システムとして求められる機能（リクワイアメント） リクワイアメントを達成するための具体的なシステムスペック 適応可能なブロックチェーンプラットフォームの種類

（プライベート型／コンソーシアム型／パブリック型） 上記に伴う、評価項目の重要度 評価項目ごとに利用する評価指標

図 3-3 に、金融分野を例にユースケースによって、業務要件とリクワイアメントがどの

ように異なるかを整理している。ユースケースとして、「パブリック型の（オープンな）価

値移転」と「企業間の（クローズドな）価値移転」を考えた場合、業務要件としては管理の

方法、取引をオープンにするか秘匿するか、参加を許可型にするか否か、それらを踏まえた

参加者数・トランザクション数などが変わってくる。その結果、リクワイアメントとしては、

管理方法やデータアクセス方法などが異なり、評価すべき項目が変化することとなる。 金融の中でも他に様々なユースケースが考えられ、評価軸検討の際には、金融以外に SCM

（サプライチェーンマネージメント）や証跡保存等、多数のユースケースを考慮する必要が

ある。

40

図 3-3 ユースケースによって異なる要件、機能

しかし、業務要件やリクワイアメントは変わるが、網羅的な評価項目を考えられればそれ

らの違いを包含できる軸設定ができると考えられる。ただし、網羅的な評価項目を考えるに

当たっては、多様なユースケースとリクワイアメントを想定した上で、抜け漏れが無いこと

を担保しておくことが必要であるため、本検討では複数のユースケースを調査するとともに、

多様なユースケースを把握している有識者委員の議論を経ることで、網羅性を担保すること

とした。 また、ユースケースにより、各評価項目の重要度が変化する点については、重要なものに

ついて「本評価軸を活用する際の留意点、備考等」に記載を行う方針とした。

3.1.3 評価軸の構成要素（評価項目・評価指標・評価方法等）について

「評価項目」に関して、ブロックチェーン技術を活用したシステムを評価する場合には、

「品質」「保守・運用」「コスト」の 3 項目が必要であり、既存システムを評価する場合に

も一般的であるため、図 3-4 に示すように、それら 3 つの項目を評価軸の大項目として設

定した。 品質については、ISO/IEC25010（システム及びソフトウェア品質モデル）のすべての項目

とブロックチェーン技術との関連性について、調査検討の結果に基づき、参考資料 1 に示す

通り整理を行った。この整理に基づき、ブロックチェーン技術を活用したシステムの特性に

関連性が強い項目を評価軸として抽出した。保守・運用については、IPA が整理したもの（シ

ステム・リファレンス・マニュアル、第 4 章保守・運用、2005 年）を参考とし、品質同様

にブロックチェーン技術を活用したシステムの特性と関連性が深い項目を評価軸として抽

出した。コストについては、研究開発、実装、保守・運用において、システムベンダーが企

業として費用認識するコストによって評価軸を構成することとした。

ユースケース（業務要件）

パブリック型の（オープンな）価値移転

システムに必要とされる機能

（リクワイアメント）

• 非中央管理における信頼性担保の仕組み

• 不正アクセス・取引対策• 取引履歴の改ざん耐性• アクセスの容易性• 可用性• 対応ノード数• トランザクション処理性能

• 対応可能なデータ量• 拡張性• ・・・

金融分野

企業間の（クローズドな）価値移転

・・・

• メンバー管理機能

• 不正アクセス・取引対策• 取引履歴の改ざん耐性• データ秘匿機能• 可用性• 対応ノード数• トランザクション処理性能

• 対応可能なデータ量• 拡張性• ・・・

ＳＣＭ 証跡保存

パブリック型の（オープンな）価値移転

企業間の（クローズドな）価値移転

・・・ ・・・• コンソーシアムによる管理• 取引は秘匿される• 参加は許可型• 参加者は少数に限られる• 取引量10,000件／分• ・・・

• 非中央管理• 取引はオープン• 参加は自由• 参加者は非常に多い• 取引量1,000件／分• ・・・

41

これらの評価軸を用いることで、ブロックチェーン技術を活用したシステム同士の比較が

できるとともに、ISO/IEC25010 や IPA のシステム・リファレンス・マニュアル等、システ

ム評価の現場で活用されている既存の評価軸（ガイドライン）をベースとしているため、既

存のシステムとの比較も容易にできるようになっている。 さらに、「本評価軸を活用する際の留意点、備考等」欄を設け、各評価項目を評価する際、

考慮しなければならないブロックチェーン技術を活用したシステムに特有な点（たとえば技

術間・評価項目間のトレードオフの関係）などを記載した。 「評価指標」及び「評価方法」については評価対象とする個別システムごとに大きく異な

るため、本評価軸においては一律の設定を行わないものとした。ただし、前述の「本評価軸

を活用する際の留意点、備考等」欄において、具体的な評価指標の例や、実際に評価を行う

際の記載イメージなどを付し、実際に評価をする際に留意すべき点などの記載を充実させる

こととした。

図 3-4 評価軸の構成（図中では BC とも表記）

なお、有識者検討委員会では、既存のブロックチェーンプラットフォームの比較評価を行

う場合、考え得るユースケースについてリクワイアメントを整理し、個別のブロックチェー

ンプラットフォームがそれらの要件を満たし得るかという○×表を作成するという評価方

法についても提案があった。そのような評価方法は、使用するブロックチェーンプラットフ

ォームを選定する場合の比較評価を行う場合においてはニーズがあると考えられるものの、

3.1.2 (1)に述べた通り、本調査においては評価の対象を、ブロックチェーンプラットフォー

ムではなく、ブロックチェーン技術を活用したシステムとし、リクワイアメントに対する○

処理性能（スループット）

・ブロックサイズ・トランザクションサイズ・コンセンサス方式・ブロック生成時間

・ノード構成、ネットワーク環境、コンセンサス・アルゴリズム等の前提条件を明確にする・何のスループットか明確にする（トランザクション処理、ブロック生成等）

応答性能（レイテンシ）

・ネットワーク環境・ノード分散

・ノード構成、ネットワーク環境、コンセンサス・アルゴリズム等の前提条件を明確にする・何のレイテンシか明確にする（トランザクション処理、ブロック生成等）

既存システムとの相互運用性

・データ構造・API仕様 ・相互運用のための前提条件を明確にする

他BCシステムとの相互運用性

・データ構造・コンセンサス方式・API仕様

・相互運用のための前提条件を明確にする

処理性能向上性（スループット向上

性）

・ブロックサイズ・トランザクションサイズ・コンセンサス方式・ブロック生成時間

・ブロックサイズを拡張するとトランザクション処理性能は上がるが、レイテンシが下がる。また処理性能を上げるということはデータ容量が増大することにつながり、ノードの負担（特に全データを保持するフルノードの負担）が大きくなり、フルノードを担えるサイトが減少し、信頼性が下がることにもつながる。・高速なコンセンサスアルゴリズムを適用するには、制約条件（承認ノードの管理やセキュリティレベルを下げる等）が生ずる

応答性能向上性（レイテンシ向上性）

・ノード分散・ネットワーク環境・P2Pプロトコル

・分散環境のためネットワーク環境に強く依存する・ノード間距離が近いとレイテンシは向上するが、地域災害による障害耐性が下がる

容量拡張性処理性能の向上や履歴の蓄積によって、保持すべきデータ容量が増大する。これらデータの増大に対する拡張性の度合い

・ブロックサイズ・トランザクションサイズ・コンセンサス方式・ブロック生成時間

処理性能向上やデータ蓄積によって、保持すべきデータ容量は増大するため、この対応が必要である

ノード数拡張性 分散システムのためどの程度のノード数に対応可能かの度合い

・データ容量・コンセンサス方式

・Proof of Workを適用しているBitcoinでは、ノード数に制限はないが、ファイナリティは得られない・ファイナリティを得られるPBFTを用いると承認ノード数は制限される・処理性能が上がるとフルノードへの負荷が高くなり、フルノードのための要件が高くなり、フルノードの減少につながる。フルノードが減少すれば、信頼性が低下する

・既存の実用技術（暗号技術等）・研究開発した新規の技術（コンセンサス・アルゴリズム等）

・ブロックチェーン技術を活用した実用システムとしての成熟性、稼動実績

・単一障害点の有無 ・障害点となるノードの有無

・コンセンサス・アルゴリズム ・コンセンサス・アルゴリズムに起因する不正状態（51%攻撃等）やコンセンサス不能状態（PBFTにおける1/3以上のノードとの不通等）

障害許容性（耐故障性）

ハードウェア又はソフトウェア障害にもかかわらず、システム、製品又は構成要素が意図したように運用操作できる度合い。

・ノード障害の許容性・ネットワーク障害、分断攻撃の許容性

・正常稼動の定義・正常稼動のためのノード条件、ネットワーク条件・ネットワーク分断等によるフォーク発生後の正しいチェーンの判断方法

回復性中断時又は故障時に製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い。

・ノード障害の回復性（回復方法、回復時間等） ・ネットワーク環境やデータ量などの前提条件を明確にする

・アクセス管理 ・データへのアクセス権限（読み、書き等）の管理

・データ秘匿化・データを秘匿する機能の有無・秘匿化の対象、範囲・第3者による検証方法

・トランザクション秘匿化・トランザクションを秘匿する機能の有無・秘匿化の対象、範囲・第3者による検証方法

・メンバー管理 ・メンバーシップ管理機能の有無等

・アクセス管理 ・データへのアクセス権限（読み、書き等）の管理

・データの改ざん耐性 ・コンセンサス・アルゴリズムによるファイナリティの有無、フォーク後の正しいチェーンの判断方法を明確にする

・ハードフォークポリシー ・ブロック巻き戻しに関するルール等

・分散ノード間の同期方法 ・分散したノード間でデータの同期が行われるか、または、正しいとされるデータの判断方法はどのようなものか

・データの改ざん耐性 ・コンセンサス・アルゴリズムによるファイナリティの有無、フォーク後の正しいチェーンの判断方法を明確にする

・ハードウェア適応性 ・ノードに関する要件を明確にする

・アプリケーション適応性 ・アプリケーションに関する要件を明確にする

・既存システムとの置換性 ・どのような既存システムと置換性があるのか明確にする

・他ブロックチェーンシステムとの置換性 ・どのような他BCシステムと置換性があるのか明確にする

・ブロックチェーンエンジンのモジュール性 ・コンセンサス・アルゴリズムのモジュール性・サブシステムのモジュール性

・コントラクトのモジュール性 ・コントラクトの仕様（記述言語等）を明確にする

・ブロックチェーンエンジンの再利用性（適用可能範囲等） ・コンセンサス・アルゴリズムのモジュール性とその再利用性・サブシステムのモジュール性とその再利用性

・コントラクトの再利用性（対応する記述言語やその仕様等） ・コントラクトの仕様（記述言語等）を明確にする

・障害検知・障害が発生しているかどうかの検知・障害がどこで発生しているかの特定（ノード障害、ネット障害等）・障害の影響範囲の特定

・パフォーマンス解析 ・スループット、レイテンシ、スケーラビリティ等のパフォーマンス・モニタリング方法

・バグ対応 ・バグの修正対応の方法、責任所在等

・コントラクト修正 ・ブロックチェーンでは、書き込まれたものは修正（改ざん）できないが、コントラクトにバグが発見された場合の対応はどうするのか。

・ハードフォーク ・ブロックチェーンでは、書き込まれたものは修正（改ざん）できないが、バグによる不正等が発見された場合にブロックの巻き戻し対応はどうするのか。

・ブロックチェーンエンジンの試験性・ノード構成、ネットワーク構成によって、試験結果は影響を受けるため、どのような環境でどのような機能、性能試験ができるのか、環境が変わったときにどのような影響を受けるのか明確にする

・ノード障害、ネットワーク障害の耐性に関する試験・スケーラビリティの試験・コンセンサス・アルゴリズムの試験

・分散環境では、ノードやネットワークの障害への耐性試験、容量やノードの拡張性試験、コンセンサス・アルゴリズムの試験が重要である

・コントラクトの試験性 ・ブロックチェーンでは、書き込まれたものは修正（改ざん）できないため、コントラクトは十分な試験が必要である

ブロックチェーンエンジン技術要素の研究開発

・新しいコンセンサス・アルゴリズム・高速なP2Pプロトコルの開発 ・処理性能向上等にためのコア技術の研究開発

サブシステムの研究開発

・アプリケーション開発・コントラクト開発環境 ・適用分野等を広げるための周辺システムの研究開発

ハードウェアコスト・ノード・ネットワーク・サブシステム

・製品のハードウェアコスト・コストに含まれる対象、範囲を明確にする

ソフトウェアコスト・OS・ミドルウェア・アプリケーション

・製品のソフトウェアコスト・コストに含まれる対象、範囲を明確にする

システム実装コスト ・組み立て、実装、試験 ・製品の設置等に関するコスト・コストに含まれる対象、範囲を明確にする

運用コスト

・ノード・ネットワーク・承認に係るコスト（コンセンサス・アルゴリズムの違いによるコストへの影響）・運用要員

・システム運用に関するコスト・コストに含まれる対象、範囲を明確にする

保守コスト ・バグ修正・保守要員

・システムの保守に関するコスト・コストに含まれる対象、範囲を明確にする

コスト

研修開発 研究開発に係るコスト（導入前コスト）

実装（製品化） システムの実装に係るコスト（導入時コスト）

保守・運用 システムの保守、運用にかかるコスト（導入後コスト）

欠陥の取込みも既存の製品品質の低下もなく、有効的にかつ効率的に製品又はシステムを修正することができる度合い。

試験性

システム、製品又は構成要素について試験基準を確立することができ、その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。

保守・運用 保守性

モジュール性

一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように、システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。

再利用性 一つ以上のシステムに、又は他の資産作りに資産を使用することができる度合い。

解析性

製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。

修正性

移植性

適応性異なる又は進化していくハードウェア、ソフトウェア又は他の運用環境若しくは利用環境に製品又はシステムが適応できる有効性及び効率性の度合い。

置換性 同じ環境において、製品が同じ目的の別の明示された製品と置き換えることができる度合い。

品質

製品又はシステムがアクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。

インテグリティコンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを、システム、製品又は構成要素が防止する度合い。

否認防止性事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明することができる度合い。

真正性 ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。

信頼性

成熟性 通常の運用操作の下で、システム、製品又は構成要素が信頼性に対するニーズに合致している度合い。

・ブロックチェーンシステムは、多くの既存技術を組み合わせて実現されているため個々の要素技術はある程度成熟していると考えられる・コンセンサス・アルゴリズム等は、BCシステムの性能向上のために新規アルゴリズムが研究開発されている・システムとしての実用実績は少ない・これらを個々および総合的に評価する

可用性 使用することを要求されたとき、システム、製品又は構成要素が運用操作可能及びアクセス可能な度合い。

セキュリティ

機密性

性能効率性製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間並びにスループット速度が要求事項を満足する度合い。

相互運用性二つ以上のシステム、製品又は構成要素が情報を交換し、既に交換された情報を使用することができる度合い。

拡張性（スケーラビリティ）

性能を向上させられる度合い

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン技術・特性 備考

ブロックチェーン技術を活用したシステムの評価軸

※指標を設定する際に留意すべき点を整理する

製品品質モデル

大項目

●重要・スループット・レイテンシ

●重要・利用時コスト（運用・保守コスト）※利用時品質モデルの効率性と合わせて検討

●重要・スケーラビリティ

ブロックチェーン技術・特性との関連性

×：低い機能の適合性は、システムとして評価すべきものであり、ブロックチェーン技術・特性とは直接関連するものではない。

×：低い機能の適合性は、システムとして評価すべきものであり、ブロックチェーン技術・特性とは直接関連するものではない。

×：低い機能の適合性は、システムとして評価すべきものであり、ブロックチェーン技術・特性とは直接関連するものではない。

備考中項目（品質特性）

小項目（副品質特性） 項目の概要

性能効率性明記された状態（条件）で使用する資源の量に関係する性能の度合い。

時間効率性製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間並びにスループット速度が要求事項を満足する度合い。

機能適合性明示された状況下で使用

するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を製品又はシステムが

提供する度合い。

機能完全性 機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。

機能正確性 正確さの必要な程度での正しい結果を製品又はシステムが提供する度合い。

機能適切性 明示された作業及び目的の達成を機能が促進する度合い。

容量満足性 製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。

資源効率性製品又はシステムの機能を実行するとき、製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い。

相談 即答率 即答件数 / 相談件数

引受率 引受件数 / 見積要請件数

保守グループ内作業完了率 保守組織内作業完了数 / 組織外への依頼数

保守時間達成率 実績時間 / 見積時間

納期内完了率 納期内完了件数 / 総案件件数

一度での修正完了率 一度で修正を完了した件数 / 着手件数

修正箇所検査、修正、確認にかけた作業時間の比率 修正箇所調査、修正、確認にかけた作業時間 / 全作業時間

自習 自習時間率 自習時間 / 全計画作業時間

改善提案作業時間率 改善提案のために要した実績時間 / 全計画作業時間

改善提案有効率 有効完全提案数

その他 ユーザ満足度 ユーザ満足度

保守作業価格 保守作業価格指標 保守金額 / 人月

付加価値作業率 付加価値作業時間 / 総作業時間

平均処理日時 案件別の処理に要した日数の平均値

指標大項目 中項目 小項目

システム保守

作業実施

総合指標

改善提案

引受検討

システム・ソフトウェアの品質モデル出所）ISO/IEC25010

システム保守・運用の評価指標出所）IPA

コストの観点• 研究開発コスト• 実装コスト• 保守・運用コスト

既存の評価軸をベースに 既存システムとの比較しやすさ 網羅性を担保

【特徴】① 既存評価軸をベースにしたことにより、

既存システムとの比較がしやすい② BC技術を活用したシステムの特性、

評価指標、評価方法等に関し、評価を行う際に留意するべき点等を明記

BC技術を活用したシステムの特性に着目した評価軸の抽出・追加 BC技術・特性の評価軸 備考・留意点を充実

「品質」にかかる評価軸

「保守・運用」にかかる評価軸

「コスト」にかかる評価軸

BC技術を活用したシステムの特性• 有識者検討委員会における意見・議論• 有識者ヒアリング調査• 文献調査

42

×では単純に表現できないような、ブロックチェーン技術を活用したシステムが伸ばせる利

点や超えられない壁（欠点）を評価の中で明らかにすることを重視することとした。しかし、

特定の活用シーンにおいては有効だと考えうる評価方法であることは事実であり、その実現

は今後の課題として認識しておくべきものと考えられる。

43

3.2 評価軸の検討結果

本調査で検討した評価軸について、「品質」「保守・運用」「コスト」の大項目ごとに検

討結果を示す

3.2.1 「品質」に関する検討結果

品質については、まず、ISO/IEC25010（システム及びソフトウェア品質モデル）のすべて

の項目について、各項目とブロックチェーン技術を用いたシステムの特性との関連度合いの

有無や強さについて、網羅的な整理を行った。整理の結果は、参考資料 1 の「ブロックチェ

ーン技術・特性との関連性」欄に示している。次に、抽出した評価軸の小項目ごとに、関連

するブロックチェーン技術・特性を整理した。さらに、「本評価軸を活用する際の留意点、

備考等」欄に、評価項目間やブロックチェーンの特性間のトレードオフ、指標設定や実際に

評価をする際に留意すべき点等を記載した。 品質に関する重要な評価項目と当該項目に関する主要な留意点、備考を以下に示す。

(1) 処理性能（スループット）

ブロックチェーン技術をビジネスに適用する場合に必要となる処理性能は、一般に

Bitcoin の処理性能 15より高くなるケースが多いと考えられており、リクワイアメントに対

応するための重要な評価項目である。スループットを向上させる方策には、「ブロックサイ

ズを大きくする」という方策と「ブロック生成にかかる時間を短くする」という方策の大き

く 2 つが考えられ、現在様々な研究開発が行われている。この 2 つの方策は、スループット

の向上に有効であるものの、他の評価項目やブロックチェーン技術の特性とのトレードオフ

も生じるため、実際の評価の際にはトレードオフの対象となる評価項目も同時に評価するな

どの留意が必要である。

1) ブロックサイズを大きくする

ブロックサイズを大きくすると、1 つのブロックに格納できるトランザクション数を増や

すことができる。たとえば、ブロックサイズを 2 倍とすると 2 倍近いトランザクションを処

理することができるようになる（ブロック内には、ヘッダーやチェーン管理情報等が含まれ、

すべてがトランザクションデータではないため処理性能は単純に 2 倍にはならない）。一方

でブロックサイズを大きくするとデータの転送にかかる時間が長くなるために応答性能は

15 Bitcoin においては、2017 年 3 月 13 日時点でのブロックサイズ（24 時間平均で 0.96MB）、トランザク

ション数（約 24 万件）をベースとし、ブロック生成にかかる時間を 10 分とすると、処理性能は 2.9 トラン

ザクション／1 秒程度となる。（https://blockchain.info/ja/charts/ ）同サイトでは、トランザクションサイズ

を確認することもでき、たとえば、1 つの Bitcoin アドレス・未使用残高情報（UTXO）から 1 つの他アド

レス（支払い送金）と自アドレス（残金を自宛送金）との 2 つの送金からなる実効的に最小となるトラン

ザクションの場合には、225 バイト前後のトランザクションサイズであることが確認できる。このような最

小トランザクションのみからブロックが構成される場合には、1 ブロック当たり 4,000 トランザクション程

度であり、7 トランザクション／1 秒程度の処理性能となる。この処理性能が Bitcoin の最大処理性能とさ

れている。

44

悪化する（ネットワーク遅延を引き起こす）。

2) ブロック生成にかかる時間を短くする

ブロック生成にかかる時間を短くすると、多くのブロックを生成することができる。たと

えば、ブロック生成にかかる時間を半分にすると 2 倍のトランザクションを処理できるよう

になる。一方で PoW におけるブロック生成時間を短くすることは、ブロック生成のための

Work が容易になることを意味し、データ改ざん耐性を下げることとなる。また、PBFT の

ように高速にコンセンサスを得る方式の研究開発が行われているが、このような方式におい

ては、何かしらのトレードオフを抱えている。たとえば、PBFT では、ブロック生成を承認

するノードは限られており、Bitcoin のように自由に多くのマイナーが存在できるようなシ

ステムには適用が困難である。

3) その他

上記に示したスループット向上では、トレードオフが生じるため、どのようなバランスが

適しているかの検討が難しくなるケースがある。そこで、このようなトレードオフを生じな

い新しい技術、たとえば、ライトニングネットワーク 16、その他様々な技術開発が進められ

ている。これら技術は開発途上であることから、現状ではどのような評価が適切かを議論す

ることも難しいため、今回の評価軸検討の段階では、対象外とした。 このように処理性能を向上させるために様々な検討や研究開発が行われているが、処理性

能が向上すると保持すべき履歴情報が多くなる。その結果、コンセンサスに参加するノード

（Bitcoin におけるマイニングを実行するノード）は、フルノードと呼ばれるすべての履歴

情報を保持したノードである必要があり、データ容量増大による負荷が高くなる。このため、

データ容量が増大するほどフルノードとして参加できるノードが減少し、コンセンサスの信

頼性が下がることも懸念される。

(2) ネットワーク性能

分散環境においてはネットワーク環境がシステム全体の性能に影響し、特に応答性能（ネ

ットワーク遅延）に大きな影響を与えるため重要な評価項目である。ノード間を高速な専用

線で接続すれば、応答性能を向上させることは可能であるが、非常に大きなコストがかかる

ことになる。また、ノード間の伝送距離を短くすることでも応答性能を向上させることが可

16 Bitcoin におけるオフチェーン技術（Bitcoin とは別のチェーンを使って Bitcoin の取引を行う技術。Bitcoinのチェーン利用は必要最低限のトランザクションだけにすることでBitcoin全体の取引をスケールさせなが

ら Bitcoin の負荷を軽減することができる）の 1 つ。小額支払い（マイクロペイメント）を実現し、Bitcoinでの取引手数料を削減し、Bitcoin をスケールすることができる。2 者間の小額、多数のトランザクション

を Bitcoin とは別の支払いネットワーク（ライトニングネットワーク）で行い、Bitcoin 上には、その開始と

終了時に必要情報を書き込むことで、Bitcoin でのトランザクションを減らすことのできる技術。詳細は、

ライトニングネットワークのリリースを参照のこと。

http://lightning.community/release/software/lnd/lightning/2017/01/10/lightning-network-daemon-alpha-release/

45

能であるが、各ノードが地理的に近くに設置されていると、その周辺におけるネットワーク

障害や災害等によって影響を受けるノードの数が増えることとなり、システム内で正常に作

動するノードが減ることにより、障害耐性が下がることとなる。このように他の評価項目と

のトレードオフも考えられるため、評価実施の際は留意が必要である。

(3) ブロック確定 17性能

ブロックチェーン技術を活用したシステムにおけるブロック生成には、コンセンサス方式

が大きな影響を及ぼす。また、ブロック確定の有無はリクワイアメントへの対応においても

重要な項目である。Bitcoin における PoW では、ブロックを確定することはできず、後続ブ

ロックが繋がっていくことで 100%の確定に漸近する方式となっている。一方、PBFT は、

ブロックを確定することができる方式である。また、前者はコンセンサスに参加するノード

数に特別な制限はないが、後者はコンセンサスに参加するノード数に実運用上の制限がある。

このように、コンセンサス方式によりブロック確定が得られるもの、得られないものがあり、

それぞれに異なる特徴を持っているため、評価の際には、性能だけではなく、コンセンサス

方式の特徴についての記載も必要である。

(4) 参照性能

ブロックチェーンに記録された取引履歴等の情報をどのように参照できるか、どの程度の

時間でどれだけの情報を参照できるかという参照にかかる性能も重要な評価項目である。

(5) 相互運用性

ブロックチェーン技術を活用したシステムは、単体システムではなく、全体システムの一

部機能・役割を担う部分システムとして活用されるケースも多いと考えられる。このため既

存システムとの連携や他ブロックチェーン技術を活用したシステムとの連携がどのように

実現できるかは重要な評価項目である。

(6) 拡張性（スケーラビリティ）

ブロックチェーン技術を活用したシステムにおける拡張性としては、スループット、ネッ

トワーク性能、ブロック確定性能、データ容量、ノード数の拡張性が重要と考えられる。ス

ループットとネットワーク性能については、前述のように向上させることができるが、トレ

ードオフ関係で低下する機能・性能もあるため、ユースケースによって、そのバランスを検

討することになる。ブロック確定性能については、確定を得られるアルゴリズムを適用する

と、ノード数が制限されるなどのノード数拡張性との間にトレードオフ関係が生ずる。デー

タ容量の増大についても、スループット性能で前述したようにフルノードの減少につながり、

改ざん耐性の低下を招く懸念がある。また、ノード数の増大により、トランザクション数が

処理性能を超えてしまい、処理されないトランザクションが出てくるようなことも懸念され

17 ブロック生成において分岐等が生じることで、生成されたブロックが後に否認される可能性がある状態

となることがあるが、ここでは、そのような可能性が無くなった状態を「ブロック確定」とする。

46

る。

(7) 信頼性

ブロックチェーン技術の改ざん耐性や可用性は、一般的に高いとされており、ブロックチ

ェーン技術らしさを表現できる評価項目である。改ざん耐性については、コンセンサス方式

に強く依存するため、改ざん耐性の評価だけではなく、その背景となるコンセンサス方式に

ついての詳説も必要である。また、システムとしての信頼性は、技術的に発展中のため様々

な課題が存在し、それら課題の解決のための研究開発が行われている状況であり、今後多く

のユースケースで実績を積むことで全体の信頼性を向上させていくことになる。

(8) セキュリティ

ブロックチェーン技術におけるデータの秘匿化、トランザクションの秘匿化については、

研究開発が行われている状況である。ビジネス適用においては、これらの秘匿化は重要な課

題と認識されており、秘匿化の実現方法やそのレベルはシステムの評価項目として重要なも

のと考えられる。また、アクセス管理等も含めてセキュリティは既存システムとの比較にお

いても重要な評価項目である。

(9) 移植性

ブロックチェーン技術は発展中であるため、よりよいシステムが開発された際に置き換え

が容易なシステムであるほうがよい。ブロックチェーンプラットフォームを新しい性能のよ

いものに入れ替えること、サブシステムの更改やハードウェアの更改の容易性は実用システ

ムとして必要な評価項目である。

47

表 3-1 評価軸：品質

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

品質

性能効率性

処理性能 （スループット）

製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間並びにスループット速度が要求事項を満足する度合い。

・ブロックサイズ ・トランザクションサイズ ・コンセンサス方式 ・ブロック生成時間

・ ノード構成、ネットワーク環境、コンセンサス方式等の前提条件を明確にする。 ・ スループットの定義を明確にする。たとえば、「対象とする処理は、トランザクション処理で理

論性能など。」。 ・ 他評価項目等とのトレードオフの関係に留意し、明確に示す。

※トレードオフの内容については、「処理性能向上性（スループット向上性）」の項目に詳述。

ネットワーク性能 ・ネットワーク環境 ・ノード分散

・ ノード構成、ネットワーク環境等の前提条件を明確にする。 ・ 処理時間の定義を明確にする。たとえば「ランダムに 2 つのノードを選択して、そのノード間

で●kB のデータ送信にかかる時間を測定する。これを〇回実施した平均値。」など。

ブロック確定性能 ・コンセンサス方式 ・ネットワーク環境 ・ノード分散

・ ブロックが確定するまでの時間。処理時間の定義を明確にする（たとえば「トランザクションを投げてからブロック確定まで」など）。

・ ブロックが確定する場合には、確定を得られるまでの時間、確定しない場合には、〇〇%の確定度合いを得られるまでの時間等、用いているコンセンサス方式の特徴・トレードオフ関係を明確にする。たとえば、「PoW を用いており、ブロック確定はできないが、後続に 6 ブロック生成されれば、確定度合いが〇%となる。また、ノード数に特別な制限はない。」など。

・ 他評価項目等とのトレードオフの関係に留意し、明確に示す。 ※トレードオフの内容については、「処理性能向上性（スループット向上性）」の項目に詳述。

参照性能 ・ノード分散 ・ネットワーク環境 ・ブロック構造

・ 特定のブロックおよびトランザクションを参照する際の性能。ノード構成、ネットワーク環境等の前提条件を明確にする。

相互運用性

既存システムとの 相互運用性 二つ以上のシステム、製品又は構成

要素が情報を交換し、既に交換された情報を使用することができる度合い。

・データ構造 ・API 仕様

・ 相互運用のための前提条件を明確にする。 ・ 連携実績のある既存システムおよびどのような連携なのか明示する。

他ブロックチェーン技術を活用したシステムとの

相互運用性

・データ構造 ・コンセンサス方式 ・API 仕様

・ 相互運用のための前提条件を明確にする。 ・ 連携実績のある他のブロックチェーン技術を活用したシステム、およびどのような連携なのか

明示する。

48

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

品質 拡張性

（スケーラビリティ）

処理性能向上性 （スループット向上

性） 性能を向上させられる度合い

・ブロックサイズ ・トランザクションサイズ ・コンセンサス方式 ・ブロック生成時間

・ スループット向上のために取りうる方法と、その方法により生じうるトレードオフにつき明確にする。

【明確にすべきトレードオフ関係】 ・ 信頼性にかかるトレードオフ関係：たとえば、「処理性能を上げることでデータ容量が増大

することにつながり、ノードの負担（特に全データを保持するフルノードの負担）が大きくなり、フルノードを担えるサイトが減少し、信頼性が下がる。フルノードが●ノード以下になるとリクワイアメントを満たすことが困難となる。」など。

・ 適用するコンセンサス方式により生じるトレードオフ関係：たとえば、「高速な●●コンセンサス方式を適用してスループットを向上させている。この方式では、特定の管理された承認ノードが必要になり、承認ノード数は実運用的に 30 台程度が上限である。これらのうち1/3 が不通となるとシステム機能を維持できなくなるため、可用性は低下し、▲となる。」など。

ネットワーク性能向上性

・ノード分散 ・ネットワーク環境 ・P2P プロトコル

・ 分散環境であることから、ネットワーク環境に強く依存するため、ネットワーク性能向上のボトルネックになっている部分を示し、性能向上のポイントの所在を明確にする。

容量拡張性

処理性能の向上や履歴の蓄積によって、保持すべきデータ容量が増大する。これらデータの増大に対する拡張性の度合い

・ブロックサイズ ・トランザクションサイズ ・コンセンサス方式 ・ブロック生成時間

・ データ蓄積によって、保持すべきデータ容量は増大する。ある一定期間後のデータ容量を見積り、取りうる対応につき明確にする。

ノード数拡張性 分散システムのためどの程度のノード数に対応可能かの度合い

・データ容量 ・コンセンサス方式

・ 各種別のノード（フルノードやライトノード等）について拡張の上限を明確にする。 ノード数が増大すると、処理性能を超過するトランザクションが発生する可能性がある。このため、処理性能に見合ったノード数の想定を明確にする。

・ 他評価項目等とのトレードオフの関係に留意し、明確に示す。 ※トレードオフの内容については、「処理性能向上性（スループット向上性）」の項目に詳述。

49

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

品質 信頼性

成熟性 通常の運用操作の下で、システム、製品又は構成要素が信頼性に対するニーズに合致している度合い。

・既存の実用技術（暗号技術等） ・研究開発した新規の技術（コンセンサス方式等）

・ システムの成熟性については、通常導入実績などで評価するが、ブロックチェーン技術の導入実績は、調査時点においてほとんどなく、端的に評価することが難しい。そこで、ブロックチェーン技術を活用したシステムは、暗号技術等の既存技術とコンセンサス方式やスループット等性能・機能向上のために研究開発された新しい技術を組み合わせて実現されていることから、個々の要素技術の実用実績、類似システムの稼動実績、テスト環境における稼動実績等によりシステムとしての成熟性を示す。

・ブロックチェーン技術を活用した実用システムとしての成熟性、稼動実績

可用性 使用することを要求されたとき、システム、製品又は構成要素が運用操作可能及びアクセス可能な度合い。

・単一障害点の有無 ・ 単一障害点となるノードの有無について明確にする。 ・ 単一障害点がない場合においては、どの程度のノードが不通等により機能しなくなるとシス

テムとしての信頼性が得られなくなるか明確にする。

・コンセンサス方式 ・ 正しいコンセンサスを得るための条件（ノード数等）を明確にする。 ・ コンセンサス方式に起因する不正状態（51%攻撃）、コンセンサス不能状態（PBFT に

おける 1/3 以上のノードとの不通）等のコンセンサスが機能しなくなる条件を明確にする。

障害許容性 （耐故障性）

ハードウェア又はソフトウェア障害にもかかわらず、システム、製品又は構成要素が意図したように運用操作できる度合い。

・ノード障害の許容性 ・ネットワーク障害、分断攻撃の許容性

・ 正常稼動の定義を明確にする。 ・ 正常稼動のためのノード条件、ネットワーク条件を明確にする。 ・ ネットワーク分断等によるフォーク発生後のメインチェーンの決定方法を明確にする。

回復性

中断時又は故障時に製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い。

・ノード障害の回復性（回復方法、回復時間等）

・ ネットワーク環境やデータ量などの前提条件を明確にする。

50

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

品質

セキュリティ

機密性 製品又はシステムがアクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。

・アクセス管理 ・ データへのアクセス権限（読み、書き等）の管理方法、設定レベル等を明確にする。

・データ秘匿化 ・ データを秘匿する機能の有無を明確にする。 ・ 秘匿化の対象、範囲を明確にする。 ・ 秘匿化されたデータの第 3 者による検証方法を明確にする。

・トランザクション秘匿化 ・ トランザクションを秘匿する機能の有無を明確にする。 ・ 秘匿化の対象、範囲を明確にする。 ・ 第 3 者による検証方法を明確にする。

インテグリティ

コンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを、システム、製品又は構成要素が防止する度合い。

・メンバー管理 ・ メンバーシップ管理機能の有無等を明確にする。

・アクセス管理 ・ データへのアクセス権限（読み、書き等）の管理方法、設定レベル等を明確にする。

否認防止性

事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明することができる度合い。

・コンセンサス方式 ・ コンセンサス方式によるブロック確定の有無を明確にする。フォーク後のメインチェーンの決定

方法を明確にする。

・ハードフォークポリシー ・ ブロック巻き戻しに関するルール、方法、影響範囲を明確にする。

真正性 ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。

・分散ノード間の同期方法

・ 分散したノード間でデータの同期が行われるかを明確にする。また、同期する際に正しいとするデータの決定方法を明確にする。

・コンセンサス方式 ・ コンセンサス方式によるブロック確定の有無を明確にする。また。フォーク後のメインチェーン

の決定方法を明確にする。

移植性

適応性

異なる又は進化していくハードウェア、ソフトウェア又は他の運用環境若しくは利用環境に製品又はシステムが適応できる有効性及び効率性の度合い。

・ハードウェア適応性 ・ ノードに関する要件を明確にする。

・アプリケーション適応性 ・ アプリケーションに関する要件を明確にする。

置換性 同じ環境において、製品が同じ目的の別の明示された製品と置き換えることができる度合い。

・既存システムとの置換性 ・ どのような既存システムと置換性があるのか明確にする。 ・他のブロックチェーン技術を活用したシステムとの置換性

・ どのような他のブロックチェーン技術を活用したシステムと置換性があるのか明確にする。

51

3.2.2 「保守・運用」に関する検討結果

保守・運用については、IPA が整理したもの（システム・リファレンス・マニュアル、第

4 章保守・運用、2005 年）を参考とし、ブロックチェーン技術を活用したシステムの特性に

関連性の深い項目を評価軸として抽出した。また、品質と同様に、小項目ごとに、「関連す

るブロックチェーン技術・特性」と「本評価軸を活用する際の留意点、備考等」を整理した。 保守・運用に関する評価項目と各項目における留意点、備考等について以下に示す。

(1) モジュール性、再利用性

ブロックチェーン技術を活用したシステムは、多くの場合プラットフォームとサブシステ

ムから構成されることが考えられる。プラットフォームは研究開発により今後も発展し、サ

ブシステムも要求要件の多様化・高度化などが想定される。したがって、モジュール性、再

利用性を高めておくことは、システムとしての高性能化、高機能化のために必要なことであ

り、どのようなユースケースや将来の技術進化を想定した上でモジュール性や再利用性を考

慮しているかは重要な評価項目となる。

(2) 解析性

システムとして正常に稼動しているかどうかのモニタリングは重要である。分散環境であ

るため、障害検知、その障害の原因解析、障害の影響範囲等の解析性は重要な評価項目とな

る。

(3) 修正性

ブロックチェーン技術は発展途上の技術であるため、新たな課題・不具合が発見され、そ

の修正が比較的頻繁に行われている。分散環境であるためノードに不具合が発見された場合

には、その不具合の影響範囲やこのような修正がどのように行われるかは重要な評価項目と

なる。また、コントラクト・コードの不具合や不正アクセスによる不正ブロック生成等が発

見された場合の対処方法も重要である。

(4) 試験性

ブロックチェーン技術を活用したシステムは分散システムであるためどのような分散環

境で試験が可能かは重要である。ネットワーク環境等のシミュレーションによる試験なども

考えられるため、どのような環境でどのような試験ができるかは重要な評価項目となる。ま

た、ブロックチェーン技術の動作に関する試験性に加えて、ブロックチェーン上の履歴は取

り消しができないため、コントラクト・コードの不具合は重大な事象を招くおそれがあり、

コントラクト・コードを十分に試験できるかどうかも重要な評価項目となる。

52

表 3-2 評価軸：保守・運用

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

保守・運用 保守・運用

性

モジュール性

一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように、システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。

・ブロックチェーンプラットフォーム

・ ブロックチェーンプラットフォームの構成要素、技術要素のモジュール性について明確にする。たとえば、「コンセンサス方式は、モジュール性の高い実装としているので、他アルゴリズムへの変更は容易である。」など。

・サブシステム ・ サブシステムの構成要素、技術要素のモジュール性について明確にする。

たとえば、「サブシステムの●●機能について、高機能化することを考慮したモジュール設計としているため、●●機能の高度化は容易である。」など。

・コントラクト・コード ・ コントラクト・コードの仕様（記述言語等）を明確にする。

再利用性 一つ以上のシステムに、又は他の資産作りに資産を使用することができる度合い。

・ブロックチェーンプラットフォーム

・ コンセンサス方式の再利用性を明確にする。 たとえば、「ブロックチェーンプラットフォーム●●に実装したコンセンサス方式は、ブロックチェーンプラットフォーム▲▲にも実装できるようになっている。」など。

・サブシステム ・ サブシステムの再利用性を明確にする。

たとえば、「サブシステム●●は、▲▲システムでも利用できるようになっている。」など。

・コントラクト・コード ・ コントラクト・コードの仕様（記述言語等）を明確にする。

解析性

製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部

・障害検知

・ 障害が発生しているかどうかの検知機能の有無を明確にする。 ・ 障害がどこで発生しているかの特定（ノード障害、ネット障害等）機能の有無を明確にす

る。 ・ 障害の影響範囲の特定機能の有無を明確にする。

53

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

分を識別することが可能であることについての有効性及び効率性の度合い。

・パフォーマンス解析 ・ スループット、ネットワーク性能、スケーラビリティ等のパフォーマンス・モニタリング機能の有無

を明確にする。

修正性

欠陥の取込みも既存の製品品質の低下もなく、有効的にかつ効率的に製品又はシステムを修正することができる度合い。

・バグ対応 ・ バグの修正対応の方法、責任所在等を明確にする。

・コントラクト・コード ・ ブロックチェーン技術を活用したシステムでは、書き込まれたものは修正（改ざん）できない

が、コントラクト・コードにバグが発見された場合の対応はどうするのか明確にする。

・ハードフォーク ・ ブロックチェーン技術を活用したシステムでは、書き込まれたものは修正（改ざん）できない

が、バグや不正アクセスによる不正データが発見された場合のブロックの巻き戻し対応について明確にする。

試験性

システム、製品又は構成要素について試験基準を確立することができ、その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。

・ブロックチェーンプラットフォーム

・ ノード構成、ネットワーク構成によって、試験結果は影響を受けるため、どのような環境でどのような機能、性能試験ができるのか、環境が変わったときにどのような影響を受けるのか明確にする。

・ノード障害、ネットワーク障害の耐性 ・スケーラビリティ ・コンセンサス方式

・ 分散環境では、ノードやネットワークの障害への耐性試験、容量やノードの拡張性試験、コンセンサス方式の試験が重要であるため、これらについてどのような試験ができるのか明確にする。

・コントラクト・コード ・ ブロックチェーンでは、書き込まれたものは修正（改ざん）できないため、コントラクト・コード

は十分な試験が必要であるため、どのような試験ができるのか明確にする。

54

3.2.3 「コスト」に関する検討結果

コストについては、研究開発コスト、製品化コスト、保守・運用コストを評価項目とした。

ブロックチェーン技術を活用したシステムの導入に関するコストとしては、これ以外にもユ

ーザー側でのシステム導入コスト、ブロックチェーン技術を適用するためのコンソーシアム

形成のための意思決定に係るコスト、インターネット等のインフラ利用に関するコストが考

えられるが、今回想定している評価軸の主たる利用者はシステムベンダーであるため、実際

にシステムベンダー企業として費用認識するコスト 18（≒顧客に請求する費用）のみを、今

回の評価軸に含めることとした。 また、コストについても、小項目ごとに、「関連するブロックチェーン技術・特性」と「本

評価軸を活用する際の留意点、備考等」を整理した。 コストに関する評価項目と各項目における留意点、備考等を以下に示す。

(1) 研究開発コスト

現在のブロックチェーン技術を活用したシステムは、分散環境において履歴等の情報をブ

ロック内に格納し、これらブロックを暗号技術によってつなげることで、極めて高い改ざん

耐性と可用性を実現したデータベースと考えることができる。このような技術を様々なアプ

リケーションに適用し、ビジネス応用を進めるためには、ブロックチェーンプラットフォー

ムの技術開発だけではなく、サブシステムの研究開発も必要である。ビジネスの要求・要件

を満たすために何をどのレベルで研究開発をする必要があるかを明確にして、そのコストを

見積もる必要がある。 また、現状ではブロックチェーン技術に関する技術者が少ないということも人材調達コス

トに関わってくる問題である。ただし、この問題はブロックチェーン技術の普及・成熟に伴

い解決されてくると考えられる。

(2) 製品化コスト

実装にかかるコストであり、ハードウェア（各ノードの費用、サブシステム用機器費用等）、

ソフトウェア（ブロックチェーンプラットフォーム、サブシステム、アプリケーション費用

等）、実装（機器設置、インストール費用等）の各費用を明確にする。システムの性能、希

望等によりコストは異なるため、性能とコストの関係を整理して示す必要がある。

(3) 保守・運用コスト

ブロックチェーンシステムはノードが分散したシステムであり、ネットワークやノードの

保守や運用費用を誰がどのように負担するかを明確にする必要がある。また、ブロックチェ

ーン技術を活用したシステムは、今後の発展が期待されるが、実績が少なく、保守・運用の

ノウハウ蓄積も今後の課題である。このため保守・運用コストは、このような状況を踏まえ

18 研究開発コストは、費用項目としては顧客に提示しないが、システムベンダーとしては重要なコスト項

目であり、結果として顧客から回収するコストであるため、評価軸の対象とした。

55

たものであることを認識して評価する必要がある。

56

表 3-3 評価軸：コスト

大項目 中項目 小項目 項目に関する概要等 関連するブロックチェーン

技術・特性 本評価軸を活用する際の留意点、備考等

コスト

研究開発

ブロックチェーンプラットフォームに関する技術要

素の研究開発 研究開発に係るコスト（導入前コスト）

・新しいコンセンサス方式 ・高速な P2P プロトコルの開発

・ 処理性能向上等にためのブロックチェーンプラットフォームの技術要素の研究開発コストを見積る。

・ 既存技術の機能・性能レベルを整理し、目指す機能・性能を明確にして見積る。 サブシステムの研究開

発 ・アプリケーション開発 ・コントラクト開発環境

・ 適用分野等を広げるためのサブシステムの研究開発コストを見積もる。 ・ 機能・性能を明確にして見積もる。

実装 （製品化）

ハードウェアコスト

システムの実装に係るコスト（導入時コスト）

・ノード ・ネットワーク ・サブシステム

・ コストに含まれる対象、範囲を明確にする。 ・ プラットフォームの分類の違い（パブリック型/プライベート型等）で見積り対象、範囲が異

なることを明確にする。たとえば、「パブリック型の場合は、不特定の参加者の資材をコストとして見積もらない（見積もることができない）。」、「プライベート型では、ノード数や参加者が明確であり、また、サーバ的役割を担う機器等も想定されるためこれらのコストを見積もる。」など。

ソフトウェアコスト ・OS ・ミドルウェア ・アプリケーション

・ コストに含まれる対象、範囲を明確にする。 ※明確化の例示については、「ハードウェアコスト」の項目に記述。

システム実装コスト ・組み立て、実装、試験 ・ コストに含まれる対象、範囲を明確にする。

※明確化の例示については、「ハードウェアコスト」の項目に記述。

保守・運用

運用コスト システムの保守、運用にかかるコスト（導入後コスト）

・ノード ・ネットワーク ・コンセンサスに係るコスト（コンセンサス方式の違いによるコストへの影響）

・ コストに含まれる対象、範囲を明確にする。

保守コスト ・バグ修正 ・ コストに含まれる対象、範囲を明確にする。 ・ 新技術のため、修正頻度の高さや対応に必要となる技術的レベルを明確にする。

57

4. まとめ

4.1 調査結果概要

本調査では、ブロックチェーン技術を活用したシステムの評価を行うために、国内外の動

向調査を行った上で、有識者検討委員会を通じた評価軸検討を行った。評価軸は以下の要件

を満たすものを作成した。

ブロックチェーン技術を活用したシステムの特性を適切に表現し、想定する利用シー

ンにおいて、必要十分な評価項目を網羅した評価軸 既存システムとブロックチェーン技術を活用したシステムの比較と、ブロックチェー

ン技術を活用したシステム同士の比較の両方を扱うことのできる評価軸 ブロックチェーンプラットフォームにサブシステム加えたシステム全体を評価対象

とする評価軸 パブリック型とコンソーシアム型・プライベート型等、ブロックチェーン技術の特徴

による機能の違いに対しても網羅的に対応できる評価軸 多様なユースケースとそのリクワイアメントに対応できる評価軸

結果として、ISO/IEC25010 や IPA のシステム保守・運用の考え方を参考に、「品質」「保

守・運用」「コスト」を大項目として、評価軸を定めた。各評価項目については、ブロック

チェーン技術を活用したシステムを評価する際に関連の深い技術・特性を明記し、ブロック

チェーン技術の違いやユースケースの違いによる評価の留意点、評価軸間のトレードオフの

関係性等についても記載を行った。具体的な評価軸については、3.2 に示した通りである。

4.2 本評価軸の活用方法について

本調査においては、3.1.1 に述べたように、主に「既存システムをブロックチェーン技術

を活用したシステムに置き換える場合の比較評価」を行う場面において活用されることを想

定し、評価軸を策定した。この場合、システムベンダーは、現在利用している既存のシステ

ム評価の枠組み（ISO/IEC25010 や IPA のシステム・リファレンス・マニュアル）によりシ

ステム全体を評価しつつ、ブロックチェーン技術に関連性が高い品質や保守・運用、コスト

の各評価項目については今回の評価軸に沿った評価を行うこととなる。そして、それらの結

果を併せてシステム導入検討者に対して提示することで、システム導入検討者の判断材料と

なる。 本評価軸は、ISO/IEC25010 と評価項目を合わせているため、既存システムとの比較を容

易に行うことができる。また、ブロックチェーン技術の特性に関する評価項目についても網

羅しているため、本評価軸を用いることで、評価項目間のトレードオフ関係なども含めた長

所・短所の両面を評価することができると考える。 なお、本評価軸は「ブロックチェーン技術を活用したシステムの実証試験結果の評価」を

行う場合も念頭に置いて検討したため、同目的にも利用することができると考える。その場

合には、今回の評価軸の中から、実証実験の実証目的やユースケースのリクワイアメントに

58

応じて、着目する評価項目に関して、「本評価軸を活用する際の留意点、備考等」に基づく

評価を行うこととなる。この場合、「既存システムをブロックチェーン技術を活用したシス

テムに置き換える場合の比較評価」における活用例のように、網羅的な評価とはならないも

のの、複数の実証試験結果において着目される評価項目を合わせて評価することで、それら

の結果を横並びに比較 19することが可能となるものと考える。 また、3.1.2 (1)に述べた通り、本調査においては評価の対象を、ブロックチェーンプラッ

トフォームではなく、ブロックチェーン技術を活用したシステムとして検討したが、結果と

して、システムに使用するブロックチェーンプラットフォームを比較評価する場合において

も参考となる可能性がある。その場合、ブロックチェーンプラットフォームに関連の強い項

目に関して、「本評価軸を活用する際の留意点、備考等」に基づく評価を行うことが考えら

れる。その場合、3.1.3 に述べた、「対応可能な機能の○×表」のようなものを合わせて作

成することの必要性についても検討が必要である。

4.3 今後の検討課題について

本調査では、評価軸の策定を行ったが、評価軸が実際に利用され、ブロックチェーン技術

を活用したシステムの実証・社会実装の進展に寄与していくためには、以下の取組みが今後

必要になる。

実際のシステムにおける評価の実施とその蓄積 ユースケースの蓄積に応じた評価軸の網羅性の検証 技術の進展に合わせた評価軸のメンテナンス 評価軸の国際標準化

まずは、4.2 に示したような数多くの評価が行われる必要がある。たとえば、3.1.3 に述べ

た通り、本評価軸の検討においては、「評価指標」及び「評価方法」については一律の設定

を行わず、「本評価軸を活用する際の留意点、備考等」欄において、実際に評価を行う際の

記載イメージなどを付すにとどまっている。本評価軸の活用が進むことで、評価を実施する

者の間において、評価指標や評価方法などの共有が進み、評価結果が蓄積された段階では、

評価指標・評価方法に関する指針・ガイドラインの整備も可能となる。ガイドラインによっ

て、評価方法が文書化（見える化）され、共有されることで評価の質の継続的な向上や、ブ

ロックチェーン技術の活用に対する新規参入者の増大などの効果が見込まれ、当該技術の活

用がさらに促進されることが期待できる。 しかし、実際のシステム評価を行うに当たっても課題が存在する。たとえば、実際に第三

者による評価において、対象をソースコードが開示されているブロックチェーンに限定せず、

各種データがクローズドになっているようなシステムについても含めようとする場合、後者

19たとえば、2.3.1 で紹介した JPX の事例では、「スループット」の項目について「秒間で数十～百件程度

のスループット性能が上限」と記載されている。この事例を本評価軸を用いて評価したと仮定すると、「ス

ループット」の項目における「本評価軸を活用する際の留意点、備考等」の記載に基づき、ノード構成、

ネットワーク環境、コンセンサス方式等の前提条件に関しても数値で明示されることになり、他の実証試

験においても同様に本評価軸の同項目に関して評価された場合に、これらと横断的に比較することが可能

になることを想定している。

59

においては性能データをどのように取得するかが課題となる。対応策としては、各プラット

フォーム提供者が発行しているホワイトペーパーを参照するという案や、提供者や実証試験

実施者自身に記載をしてもらう案などが考えられるが、実際にデータ収集を行う際には、実

現性・データの信憑性などを勘案する必要がある。 また、ブロックチェーン技術の活用は始まったばかりであり、今後様々なユースケースが

世界中で実証・実装されていくこととなると考えられる。評価軸についてはそれらすべての

ユースケースに対応することが求められ、ユースケースによっては今回ブロックチェーン技

術との関連性が薄いとした評価項目が重要になるかもしれない。よって、ユースケースの蓄

積に伴い、網羅性を主とした評価軸の見直しとメンテナンスが不可欠である。なお、ユース

ケースごとのリクワイアメントについては国内外のシステムベンダー、ブロックチェーン開

発事業者から標準化の要望が出ており、ISO TC307 等の場で今後リクワイアメントの標準化

が進められることが想定される。その場合、評価軸の検討もその標準化されたリクワイアメ

ント検討に対応できるよう見直しを進めなければならない。 さらに、ブロックチェーン技術は発展途上の技術であることから、今後の技術の進展に応

じても、評価軸の見直しやメンテナンスが必要になると考えられる。技術革新により、トレ

ードオフの問題が解消されることや留意する必要が無くなることが考えられる。その進展に

応じて、「本評価軸を活用する際の留意点、備考等」欄を適宜改定していく必要がある。 このように評価軸の見直しやメンテナンスを継続的に行うためには、評価軸の管理の主体

を明確にする必要がある。主体としては、公的機関が管理する他に、コンソーシアムを形成

し、オープンソース的にリアルタイムで更新を重ねていくといったやり方も考えられる。 ブロックチェーン技術を活用したシステムをどのように評価し、どのように普及させてい

くかということは世界各国でも共通の課題となっている。ブロックチェーン技術の標準化を

検討する ISO TC307 は立ち上がったばかりであるが、今後ブロックチェーン技術を活用し

たシステムに対する評価軸の標準化についても検討する可能性が十分に高いと考えられる。

今回の検討を通じ、我が国では他国に比べて進んだ議論がなされているものと推測されるが、

ブロックチェーン技術は発展途上であり、標準化によりイノベーションを阻害することにな

らないよう留意しつつ、我が国が国際標準化を主導することが期待される。

4.4 ブロックチェーン技術の社会実装を推進するための考察

評価対象の検討において、ブロックチェーン技術の特性が最も生かされるのは、今までに

社会に無いようなサービス・仕組みを生み出した場合であるとの議論があった。ブロックチ

ェーン技術を活用した新たなサービス・仕組みの社会実装を進める第一歩として、ブロック

チェーン技術が、どのような場合に、どのように使えるかについての理解を広め、その特性

が生かされる適用先を考える主体を増やすことが重要である。その意味で、今回作成した評

価軸は、理解を深めるためのツールとして非常に有効なものだと考えられる。 他方、ブロックチェーン技術の特性の理解が広がるだけで社会実装が進むという単純な構

図ではない。ブロックチェーン技術の特性が生かされるような革新的サービスを生み出すた

めには、コンソーシアム構築等の仲間作りが重要となる。既存の仕組みの改革には、業務・

システムの上流から下流のプレーヤーが協力し（仲間となり）、個別業務の部分最適化では

なく、当該業務の全プロセスを包括して最適化することが必要だからである。国内でのユー

スケースとして 2.3.1 で紹介した日本証券取引所グループの事例など、まさに既存のシステ

60

ム制約を超えて、全体最適のシステム設計が実現された事例と言える。 さらに、社会実装を加速していくためには、ブロックチェーン技術を活用したシステムを

構築する際の要素技術を整理することが必要である。現状においてどのような技術が不足し

ており、どのような技術開発が国内外で行われているかを把握することで、実装に向けた課

題と対策が明らかになるものと考えられる。 また、ユースケースに応じた規制や制度等の環境整備も不可欠である。既存の制度は、中

央集権型のシステムを前提として構築されていることから、ブロックチェーン技術を活用し

たシステムは想定されておらず、社会実装において、既存の規制や制度に阻まれてしまう可

能性がある。 以上、まとめると、ブロックチェーン技術の社会実装を推進するためには、以下の活動が

必要と考える。

ブロックチェーン技術の特性の把握と周知 課題解決に関するステイクホルダーによるコンソーシアムの構築 ブロックチェーン技術を活用したシステムを構築する際の要素技術の整理 社会実装のための環境整備（規制・制度の見直し等）

「ブロックチェーン技術の特性の把握と周知」に関しては、ブロックチェーン技術の進展

による新たな特性やこれまで想定していないユースケースなどが生まれる可能性があるこ

とから、今回の評価軸整備のような観点での議論を継続的に行うことが重要である。また、

ブロックチェーン技術の特性に対する理解を深めるためにはユースケースを増やしていく

ことが必要である。そのためには、「2.3.8 エストニア政府による ID 管理への応用例」の

ように、日本においても政府自らが政府システムにおいてブロックチェーン技術を活用する

ことも一つである。エストニアを始めとして欧州では、ブロックチェーン技術の政府による

活用事例も出現しており、それに応じて技術開発も進んでいるものと考えられる。 「課題に関するステイクホルダーによる課題解決コンソーシアムの構築」に関しては、ブ

ロックチェーン技術の特性を活用することで解決可能な社会課題を抽出する取組も重要だ

と考える。たとえば、「2.3.5 欧州のエネルギー産業における応用事例」で示した RWE と

Slock.it の事例では、EV 普及のネックとなっていた充電インフラの未整備（低い利便性）と

いう社会的課題に目を付け、電力会社とシステム開発会社が連携して解決を図った取組みで

ある。ブロックチェーン技術の特性を生かして、充電インフラの利便性を高めることに成功

している。この取組みはアプリケーション開発単独では社会実装を実現できず、インフラ企

業との連携があってこそ実装に成功した事例と考えられる。このような社会課題解決の取組

みを行うためには、産官学による連携の拡大やコンソーシアムの組織を行い、抽出された社

会課題とブロックチェーン技術とのマッチングを行い、解決を検討するなどの取組みが求め

られる。 「ブロックチェーン技術を活用したシステムを構築する際の要素技術の整理」については、

具体的には、多数のユースケースを分析することでリクワイアメントとブロックチェーン技

術を活用したシステムで実現されていることとのギャップを整理し、そのギャップを満たす

ことができる技術（開発中・概念段階の技術を含む）を抽出することとなる。特に処理性能、

信頼性、情報の秘匿化、セキュリティに関連する技術が必要とされていると考えられる。

61

最後に、「社会実装のための環境整備（規制・制度の見直し等）」は非常に重要だと考え

られる。たとえば、スマートコントラクトは、既存の契約書に代わる革命的技術として注目

されているが、現時点では「契約」としての法的拘束力が各国において確立されていない。

米国のアリゾナ州では、2017 年 2 月 7 日に、ブロックチェーン技術によるスマートコント

ラクトを合法化する法案が提出されており、米国の複数の州でも同様の動きがみられる。我

が国においても、たとえば監査・認証・証明制度等にブロックチェーン技術を活用するため

の見直しやブロックチェーン技術を活用したシステム上に記録されているデータの法的証

拠力の明確化などを検討する必要がある。 これらの活動が世界各地で行われ、革新的なサービスが次々と生み出されることが期待さ

れる。 本調査では、評価軸の検討に当たって、その周辺課題を含めた非常に多様なテーマの検討 を行うことができた。評価軸が活用されるとともに、それらの検討内容が関係者間で共有さ

れ、ブロックチェーン技術の普及拡大に寄与できれば幸いである。

62

参考資料 1：ISO/IEC25010 の全ての項目とブロックチェーン技術との関連性

製品品質モデル

●重要ブロックサイズやブロック生成にかかる時間が処理性能に大きな影響を与える。また、分散型システムであることからノード間通信におけるネットワーク遅延も生じることとなり、処理性能に影響を与える。

●重要分散型であるため、システム（製品）の資源やコストの対象を明確にして効率性を評価することは重要である。※利用時品質モデルの効率性と合わせて、コストとしての評価項目とする

●重要処理性能の向上やノード数の拡張性等は、ブロックサイズやコンセンサス・アルゴリズム等と強い関連性がある。

ブロックチェーン技術・特性との関連性の度合い

×：低い機能の適合性は、システムとして評価すべきものであり、ブロックチェーン技術・特性とは直接関連するものではない。

×：低い機能の適合性は、システムとして評価すべきものであり、ブロックチェーン技術・特性とは直接関連するものではない。

×：低い機能の適合性は、システムとして評価すべきものであり、ブロックチェーン技術・特性とは直接関連するものではない。

△：ケースによるユースケース（システム設計）に強く依存するものである。

●重要全体システムの一部機能を担うことも想定されるため、他システムとの連携性は重要である。

中項目（品質特性）

小項目（副品質特性） 項目の概要

性能効率性明記された状態（条件）で使用する資源の量に関係する性能の度合い。

互換性同じハードウェア環境又はソフトウェア環境を共有する間、製品、システム又は構成要素が他の製品、システム又は構成要素の情報を交換することができる度合い、及び／又はその要求された機能を実行することが

できる度合い。

時間効率性製品又はシステムの機能を実行するとき、製品又はシステムの応答時間及び処理時間並びにスループット速度が要求事項を満足する度合い。

機能適合性明示された状況下で使用

するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を製品又はシステムが

提供する度合い。

機能完全性 機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い。

機能正確性 正確さの必要な程度での正しい結果を製品又はシステムが提供する度合い。

機能適切性 明示された作業及び目的の達成を機能が促進する度合い。

相互運用性二つ以上のシステム、製品又は構成要素が情報を交換し、既に交換された情報を使用することができる度合い。

容量満足性 製品又はシステムのパラメータの最大限度が要求事項を満足させる度合い。

共存性その他の製品に有害な影響を与えずに、他の製品と共通の環境及び資源を共有する間、製品が要求された機能を効率的に実行することができる度合い。

資源効率性製品又はシステムの機能を実行するとき、製品又はシステムで使用される資源の量及び種類が要求事項を満足する度合い。

63

中項目（品質特性）

小項目（副品質特性） 項目の概要 ブロックチェーン技術・特性との

関連性の度合い

×：低いユーザインターフェイスは、ブロックチェーン技術とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術とは直接関連するものではない。

●重要新しい技術によるシステムのため実績が少なく、十分に成熟したものではないが、そのような中でもどのくらい安定しているかは重要であり、実績や試験の積み上げ等による評価は必要である。

●重要高い可用性は、大きな特性である。また、高い可用性を実現するためのシステムが満たすべき要件（ノード構成等）を明確にすることも重要である。

●重要システムの一部でノード故障やネットワーク障害が発生しても、全体として稼動を継続できることは大きな特性である。また、正常稼動を継続できる要件（ノードの2/3は正常稼動していること等）を明確にすることも重要である。

●重要多数のノードとネットワークから構成されているため、障害の発生確率は高く、そのような障害からの回復性は重要である。

使用性明示された利用状況において、有効性、効率性及び満足性をもって明示された目標を達成するために明示された利用者が製品又はシステムを利用することができ

る度合い。

回復性中断時又は故障時に製品又はシステムが直接的に影響を受けたデータを回復し、システムを希望する状態に復元することができる度合い。

成熟性 通常の運用操作の下で、システム、製品又は構成要素が信頼性に対するニーズに合致している度合い。

信頼性明示された時間帯で明示された条件下に、システム、製品又は構成要素が明示された機能を実行する度合

い。

可用性 使用することを要求されたとき、システム、製品又は構成要素が運用操作可能及びアクセス可能な度合い。

障害許容性（耐故障性）

ハードウェア又はソフトウェア障害にもかかわらず、システム、製品又は構成要素が意図したように運用操作できる度合い。

習得性

適切度認識性 製品又はシステムが利用者のニーズに適切であるかどうかを利用者が認識できる度合い。

ユーザインタフェース快美性

ユーザインタフェースが利用者にとって楽しく、満足のいく対話を可能にする度合い。

アクセシビリティ製品又はシステムが明示された利用状況において、明示された目標を達成するために、幅広い範囲の心身特性及び能力の人々によって使用できる度合い。

明示された利用状況において、有効性、効率性、リスク回避性及び満足性をもって製品又はシステムを使用するために明示された学習目標を達成するために、明示された利用者が製品又はシステムを利用できる度合い。

運用操作性 製品又はシステムが、それらを運用操作しやすく、制御しやすくする属性をもっている度合い。

ユーザエラー防止性 利用者が間違いを起こすことをシステムが防止する度合い。

64

中項目（品質特性）

小項目（副品質特性） 項目の概要 ブロックチェーン技術・特性との

関連性の度合い

●重要ノード構成やネットワーク環境の影響が大きいため、どのような試験ができるのかは重要である。また、ブロックに記録されたものは修正することが困難であり、コントラクト・コードを十分に試験できることは重要である。

●重要ビジネス応用においては、データへのアクセス管理やデータの秘匿化は重要な機能である。

●重要ビジネス応用においては、システムおよびデータへの不正アクセス防止は重要である。

●重要コンセンサス・アルゴリズムによって、ブロック確定の有無や確定度合いは異なるため、これらを明確にすることが必要である。

保守性意図した保守者によって、製品又はシステムが修正することができる有効性及び

効率性の度合い。

セキュリティ人間又は他の製品若しくはシステムが、認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように、製品又はシステムが情報及びデータを保護

する度合い。

●重要分散型であるため障害を検知するだけでなく、障害が発生しているノードやネットワークを特定できる解析性が必要となる。また、システムのパフォーマンスはノードやネットワーク環境に影響を受けるため、パフォーマンスをモニタリングする機能も重要である。

●重要新しい技術であるため、実装上の不具合修正は比較的頻繁に行われることが想定される。また、コントラクト・コードに不具合が発見された場合の修正方法やハードフォークを実施した場合の影響範囲等を明確にしておくことは重要である。

責任追跡性 実体の行為がその実体に一意的に追跡可能である度合い。

真正性 ある主体又は資源の同一性が主張したとおりであることを証明できる度合い。

機密性 製品又はシステムがアクセスすることを認められたデータだけにアクセスすることができることを確実にする度合い。

インテグリティコンピュータプログラム又はデータに権限をもたないでアクセスすること又は修正することを、システム、製品又は構成要素が防止する度合い。

否認防止性事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明することができる度合い。

×：低い不正アクセスの追跡等はブロックチェーン技術・特性とは直接関連しない。

●重要チェーンが分岐するコンセンサス・アルゴリズムを採用している場合には、分岐したものを同期する機能の有無やメインチェーンの選択方法を明確にする必要がある。

修正性欠陥の取込みも既存の製品品質の低下もなく、有効的にかつ効率的に製品又はシステムを修正することができる度合い。

試験性

システム、製品又は構成要素について試験基準を確立することができ、その基準が満たされているかどうかを決定するために試験を実行することができる有効性及び効率性の度合い。

モジュール性

一つの構成要素に対する変更が他の構成要素に与える影響が最小になるように、システム又はコンピュータプログラムが別々の構成要素から構成されている度合い。

再利用性 一つ以上のシステムに、又は他の資産作りに資産を使用することができる度合い。

解析性

製品若しくはシステムの一つ以上の部分への意図した変更が製品若しくはシステムに与える影響を総合評価すること、欠陥若しくは故障の原因を診断すること、又は修正しなければならない部分を識別することが可能であることについての有効性及び効率性の度合い。

●重要多くの技術の組み合わせで実現しているシステムであり、機能や性能の向上のために新たな技術・アルゴリズムに置き換える等も想定されるため、モジュール性の高い実装かどうかは重要である。

●重要新しい技術であり、今後様々な分野での適用が検討されている。再利用性の高さは、導入にかかる期間やコストに大きく影響する。

65

利用時の品質モデル

中項目（品質特性）

小項目（副品質特性） 項目の概要 ブロックチェーン技術・特性との

関連性の度合い

移植性一つのハードウェア、ソフト

ウェア又は他の運用環境若しくは利用環境からその他の環境に、システム、製品又は構成要素を移すことができる有効性及び効率性の

度合い。

適応性異なる又は進化していくハードウェア、ソフトウェア又は他の運用環境若しくは利用環境に製品又はシステムが適応できる有効性及び効率性の度合い。

設置性明示された環境において、製品又はシステムをうまく設置及び／又は削除できる有効性及び効率性の度合い。

置換性 同じ環境において、製品が同じ目的の別の明示された製品と置き換えることができる度合い。

●重要分散型であるため、ノードやネットワークにかかる要件（適応するための要件）を明確にすることは重要である。また、他システムと連携する場合には、連携するための要件を明確にすることも重要である。

×：低いハードウェアの設置性はブロックチェーン技術・特性とは直接関連しない。

●重要新しい技術であるため、より進歩したシステムに置き換えるということも想定されるため、置換にかかる要件は重要である。

×：低いユーザインターフェイスは、ブロックチェーン技術・特性とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術・特性とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術・特性とは直接関連するものではない。

×：低いユーザインターフェイスは、ブロックチェーン技術・特性とは直接関連するものではない。

満足性製品又はシステムが明示された利用状況において使用されるとき、利用者ニーズが

満足される度合い。

信用性利用者又は他の利害関係者がもつ、製品又はシステムが意図したとおりに動作するという確信の度合い。

快適性 利用者が（システム又はソフトウェアを利用する時の）快適さに満足する度合い。

実用性利用の結果及び利用の影響を含め、利用者が把握した目標の達成状況によって得られる利用者の満足の度合い。

ブロックチェーン技術・特性との関連性の度合い

有効性 有効性 明示された目標を利用者が達成する上での正確さ及び完全さの度合い。

●重要※製品品質モデルにおける信頼性に統合

効率性 ●重要※製品品質モデルにおける性能効率性に統合

中項目（品質特性）

小項目（副品質特性） 項目の概要

快感性 個人的なニーズを満たすことから利用者が感じる喜びの度合い。

効率性利用者が特定の目標を達成するための正確さ及び完全さに関連して、使用した資源の度合い。

66

データ品質モデル

中項目（品質特性）

小項目（副品質特性） 項目の概要 ブロックチェーン技術・特性との

関連性の度合い

×：低いシステムとして評価すべきものであり、ブロックチェーン技術・特性が直接関連するものではない。

×：低いシステムとして評価すべきものであり、ブロックチェーン技術・特性が直接関連するものではない。

×：低いシステムとしての影響は考慮すべきケースはあるが、ブロックチェーン技術・特性が直接関連するものではない。

×：低いシステムとしての影響は考慮すべきケースはあるが、ブロックチェーン技術・特性が直接関連するものではない。

×：低いシステムとしての影響は考慮すべきケースはあるが、ブロックチェーン技術・特性が直接関連するものではない。

利用状況網羅性明示された利用状況及び当初明確に識別されていた状況を超越した状況の両方の状況において、有効

性、効率性、リスク回避性及び満足性を伴って製品又はシステムが使用できる

度合い。

利用状況完全性

明示された全ての利用状況において、有効性、効率性、リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

健康・安全リスク緩和性意図した利用状況において、製品又はシステムが人々に対する潜在的なリスクを緩和する度合い。

柔軟性

要求事項の中で初めに明示された状況を逸脱した状況において、有効性、効率性、リスク回避性及び満足性を伴って製品又はシステムが使用できる度合い。

環境リスク緩和性意図した利用状況において、環境に対する潜在的なリスクを製品又はシステムが軽減する度合い。

リスク回避性製品又はシステムが経済状況、人間の生活又は環境に対する潜在的なリスクを

緩和する度合い。

経済リスク緩和性

意図した利用状況において、財政状況、効率的運用操作、商業資産、評判又は他の資源に対する潜在的なリスクを製品又はシステムが緩和する度合い。

固有 システム依存

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

データ品質項目の概要

－実体に関連する対象データが特定の利用状況において、全ての期待された属性及び関係する実体インスタンスに対する値をもつ度合い。

一貫性 ○ －特定の利用状況において、矛盾がないという属性及び他のデータと首尾一貫しているという属性をデータがもつ度合い。

信憑性 ○ －特定の利用状況において、利用者によって真（実）で信頼できるとみなされる属性をデータがもつ度合い。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

－特定の利用状況において、意図した概念又は事象の属性の真の値を正しく表現する属性をデータがもつ度合い。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

中項目（品質特性）

ブロックチェーン技術・特性との関連性の度合い

正確性 ○

完全性 ○

最新性 ○ －特定の利用状況において、データが最新の値である属性をもつ度合い。

67

固有 システム依存

中項目（品質特性）

項目の概要 ブロックチェーン技術・特性との関連性の度合い

データ品質

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

アクセシビリティ ○ ○特に、幾つかの障害が原因で、支援技術又は特別の機器構成を必要とする人々が特定の利用状況において、データにアクセスできる度合い。

標準適合性 ○ ○特定の利用状況において、データ品質に関係する規格、協定又は規範及び類似の規則を遵守する属性をデータがもつ度合い。

機密性 ○ ○特定の利用状況において、承認された利用者によってだけ利用でき、解釈できることを保証する属性をデータがもつ度合い。

効率性 ○ ○特定の利用状況において、適切な量及び種類の資源を使用することによって処理することができ、期待された水準の性能を提供できる属性をデータがもつ度合い。

精度 ○ ○正確な属性又は特定の利用状況において弁別を提供する属性をデータがもつ度合い。

可用性 － ○特定の利用状況において、承認された利用者及び／又はアプリケーションがデータを検索できる属性をデータがもつ度合い。

追跡可能性 ○ ○特定の利用状況において、データへのアクセス及びデータに実施された変更の監査証跡を提供する属性をデータがもつ度合い。

理解性 ○ ○利用者がデータを読み、説明することができる属性で、特定の利用状況において、適切な言語、シンボル及び単位で表現された属性をデータがもつ度合い。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

△：ケースによるデータ構造（属性）に関するものであり、ユースケースおよび設計に依存する。ブロックチェーン技術・特性に直接関連するものではない。

回復性 － ○特定の利用状況において、故障発生の場合でさえ、明示された水準の操作及び品質を継続し、維持することを可能にする属性をデータがもつ度合い。

移植性 － ○

特定の利用状況において、既存の品質を維持しながらデータを一つのシステムから他のシステムに実装したり、置き換えたり、移動したりできる属性をデータがもつ度合い。

68

参考資料 2：有識者検討委員会等議事録

第 1 回～第 5 回の有識者検討委員会議事録を参考資料 2 として示す。委員長以外の各委員

については、A 委員・B 委員等、匿名化している。第 1 回～第 5 回を通じて、A～L 委員は

同一の委員を表している。

第 1 回 ブロックチェーン技術を活用したシステム評価軸検討委員会 議事録

日時：2016 年 11 月 11 日（金） 15 時～17 時 場所：経済産業省別館 11 階 1111 会議室 ゲストスピーカー：株式会社日本証券取引所グループ

1). 開会挨拶

情報経済課：経済産業省では今年の 4 月末頃にブロックチェーン技術に関するレポートを

出し、この中で本検討会の趣旨であるシステムの評価軸をつくることを盛り込

んでいる。また、産業構造審議会 WG において、今後の自律分散協調社会

に向けて、ブロックチェーン技術はとても重要な位置づけを持つとしたレポー

トを作成している。ブロックチェーン技術を活用したシステムの評価軸の整理

は、チャレンジングなテーマであり、前例のないものだと思うが、専門家の皆

様の意見をいただきたい。11 月から開始と言うことで時間もあまりないが、

短い時間で精力的なご検討をお願いしたい。 委員長 ：ブロックチェーン技術を活用したシステムの評価軸整備検討委員会と言うこと

で誰に聞いても難しいと言われるが、委員長を務めさせていただく。是非充実

した議論ができればと思う。このテーマについてはブロックチェーン技術自体

が発展途上であるし、バリエーションもあると思うのでなかなか一口では言え

ないと思う。まっさらな目で見られればと思う。

2). 本事業の説明

事務局 ：（「資料 2 本事業の概要」の説明を行った）

3). 委員紹介

（略）

※報告書では非掲載とする

4). 本事業の説明

事務局 ：（「資料 3 ディスカッション用資料（本事業全体での検討事項をとりまとめた

資料）」の説明を行った） I 委員 ：どこまでを対象にするかと言うことではないか。コストは無視できないと思う。

コストを無視している限りビジネス利用の議論ができない。コストを固定して

69

性能を評価するのか、性能を固定してコストを評価するのか、そこはトレード

オフを考えて評価すべきである。最終軸はコストなのではないか、というくら

いに意識しないといけないのではないかと考えている。 G 委員代理：コストは最も重要な要因だと思う。ブロックチェーン技術の金融への利用を

考えたときには、機能として足りないものが多い。機能を高めること、機能開

発することを考えたときに、そのコストも見積もらないといけない。その場合、

将来作るシステムを評価することになり、難しい課題となる。 I 委員 ：将来作るシステムのコストを考えるのは難しい。今後の技術進化によって、伸

びる性能と伸びない性能があり、コストが読めない。場合によっては無限大の

可能性がある。ただし、明確な応用先があるものは、比較的予想しやすいかも

しれない C 委員 ：評価しなくてはいけないのは技術だけではなくて、世界を変えたときに何が変

わるかと言うことになる。中央管理が必要だったところで中央管理を必要なく

するということは、業務自体が変わるはずであるし、業務を変えることを考え

ないとブロックチェーン技術のよさがでない。 K 委員 ：コストを比べるところまでたどり着けないだろうと思っている。Bitcoin の場

合、マイニングのコストは競争しているものなので、無限大になりうるコスト

である。今のブロックチェーン技術を活用したシステムにどれくらいコストが

かかっていて、トランザクションのコストがどのくらいかかっているかは、パ

ブリックブロックチェーンについては把握できていると思うが、将来変わって

くるものでもある。プライベートブロックチェーンについては比べるにしても

要件がかなり違うので、機能の○×でも難しいと思う。ユースケースとか、リ

クワイアメントによってだいぶ変わってくるので、一律のコスト比較はハード

ルが高い。 B 委員 ：私も意見は似ている。私のところは何かのブロックチェーン技術に集中してや

っているわけではなくて、いろいろなブロックチェーン技術をチェックしてい

る。色々と評価している。もちろんコストも考える。ブロックチェーンプラッ

トフォームによって、パッケージとして実装されているものが異なるため、評

価対象も異なってしまうと思われる。評価の際に、Hyperledger ではできる、

Ethereum はできない、となってしまうのは、あまりよくないのでないか。 E 委員 ：数字が高い方が優れていると単純に言ってよいかどうかもわからない。実装さ

れているものは実装で評価できるが、実装がないものはどう評価するのか。ホ

ワイトペーパーの仕様で評価するのか。また、実装されているものであっても

技術の成熟によって評価も変わる。どの時点で何を評価するのか。 I 委員 ：定量的な数値を出すことはかなり難しいと思われる。軸は示せるかもしれない。 K 委員 ：それぞれの技術の発展が早く、ある時点での評価情報を揃えることに意味があ

るのか。ある時点で輪切りにしてしまうと、進歩が早い要素は、導入に当たっ

て、顧客をミスリードすることになるのではないか。

70

委員長 ：この委員会では、軸を整理するところまでで、数値までは難しいと思っている。 F 委員 ：その項目に対して、どこまでできるのか、があると良い。今のブロックチェー

ン技術を活用したシステムではどこまでできるのか。できないものは補わなく

てはいけない。 B 委員 ：ブロックチェーン技術とは何かについて、JBA のブロックチェーン技術の定

義だけだと何も出来ないシステムである。ブロックチェーン技術を支えるサブ

システムがあって、いろいろなことが出来るようになっている。どのような機

能が必要とされているかを出したほうがよいのではないか。ブロックチェーン

プラットフォーム＋周辺サブシステムを評価対象にしたほうがよいだろう。 委員長 ：リクワイアメントを固定して評価する、業務変革を含めて評価する、という 2

つの観点があるというのが共通認識だと思われる。

5). 株式会社日本証券取引所グループ（以下 JPX 社）実証事例紹介

JPX 社 ：（「資料 4 JPX 実証事例資料」を説明した）実証実験をやって、Hyperledgerと Ethereum 系の技術を使い、小さな証券系インフラを作り、検証をした。

この当時は珍しいコンソーシアム型の実証実験だった。小さな証券市場を作る

ことを想定し、現状のブロックチェーン技術の機能でどこまでできるかを確認

した。新たな機能の追加・開発を行っていない。既存システムとの接続をして

いないので、接続性については、確認できていない。期間が 3 ヶ月だったの

でできなかったこともあるが、“証券市場っぽいもの”が作れるというのは驚

異的ではあった。

6). ディスカッション

I 委員 ：取引内容の非公開性と中立的第三者の信頼性というときに、その第三者にはど

のくらい中立性が必要とされるのかを考える必要がある。ブロックチェーン技

術の改ざん耐性は必要条件ではあるが十分条件ではなく、本当に取引が改ざん

されていないことが重要である。取引内容を隠してしまうと、チェーンは改ざ

んされていないが、アプリで改ざんできないということは言えないのではない

か。 JPX 社 ：中立的第三者が誰なのかは感情的なものも関係してくる。この人には見られて

もかまわない、と言う人を想定しているので、ビジネス上のコンペティターで

あってはいけない。また第三者は情報を漏らすことによるメリットがないこと

が必要である。 I 委員 ：そういう前提では、既存システムが改ざん不可能というわけではない。取引の

中身を見ないでチェーンに暗号化して載せることを中立的第三者以外が実現

できるということでよいのではないか。中立的第三者が嘘をつくこともある。

中身を見られる人が、嘘をつくことができると、改ざんできる。 JPX 社 ：今のシステムでも改ざんはできる。その意味で、ある種の信頼性の元にシステ

71

ムは成り立っている。 I 委員 ：ブロックチェーン技術を適用する際には、今よりもよくなっているということ

が言える必要がある。 E 委員 ：スマートコントラクトとレッジャーを考えた場合、スマートコントラクトの内

容を変えたことをチェックするときは、レッジャー上の監査をチェックすると

よいのではないか。チェックできるという仕組みがあるということは、既存の

システムよりも良いと言えると思われる。 I 委員 ：取引の改ざん不可能性というのは、チェーンが改ざんされているかどうかとは

別問題で考えないといけないのではないか。チェーンの改ざんはチェックでき

るが、その中身を秘匿したままで取引の改ざんをチェックすることは難しい。 B 委員 ：コンフィデンシャルトランザクションをどうするかということであれば、いく

つかアイデアや実装が出てきている。現在は、アイデアや実装の研究は進んで

いるが、まだできていない段階である。それが組み込まれると、第三者によっ

て、取引の内容が正しい、内容の監査だけできる、ということが可能になる。 K 委員 ：パブリックチェーンはそうなってないような気がする。スプリットは日常に発

生している。Bitcoin が許されている理由は、書き込まれて生き残ったものが

唯一正しいということで通貨が増えないことは保証している。ただ悪意を持っ

てスプリットさせてチャレンジさせて生き残らせるのはやってできないこと

はない。一つのシステムに複数の状態があるということは、ある時点について

はあると思う。私が言いたいのは現実の情報システムにおいては、実際の債

権・債務関係をマスターに反映していることが要求されるのに対して、Bitcoinがやっているのはルーズということである。短期的には不整合な状態を設計と

して織り込んでいる。Bitcoin の世界の中ではスプリットしたものをあとから

バサッときれば良いのだが、実際の情報システムで同じようにできるのかどう

か疑問が残る。 委員長 ：JPX ではプライベートにすることで、スプリットを防いでいると言うことか。 C 委員 ：プライベートかどうかとは違う。パーミッションを公開して、みんなが見られ

るようにして、証明できるところを限られた人がやる。JPX の例では、過半

数がよいといえば、それでファイナル処理する。 E 委員 ：Bitcoin のスプリットの話と、改ざんをチェックする仕組みは違う話。どちら

の軸も必要である。 I 委員 ：改ざん不可能という言葉をしっかり定義しなければならない。データが改ざん

されないと言うだけでは改ざん不可能とは言えない。リアルシステムではチェ

ーンの内容が改ざんされていないことが担保される必要がある。 B 委員 ： JPX では改ざん困難と記載していたと思う。改ざん不可能を目標値 100 だと

したら、困難性がどこまであるのかというのを従来のシステムとの間で比べる

と良いのではないか。ブロックチェーン技術を活用したシステム上のデータは

改ざん不可能ではない。どうにかしてできる。ただ困難性は評価しても良いの

72

ではないか。 G 委員代理：データの改ざんと、取引の改ざんをわけるのは賛成である。 I 委員 ：Bitcoin は多少悪い人がいたとしても大丈夫である。参加者に悪い人がいても、

1 人悪いくらいは大丈夫。それが半分超えるとまずいというのはあるが。確認

は誰でもできるけど、隠したまま悪さはできない。 H 委員 ：改ざんができてしまう条件を定性的に整理するような比較はできると思われる。 A 委員 ：言葉の定義がずれていると思う。K 委員はファイナリティと分岐の話をして

いる。それに対して改ざんという話がされている。ブロックチェーン技術を活

用したシステム上でデータの改ざんが可能かといえば、可能であるが、十分に

時間が経ったときには、トランザクションをひっくり返すのはほぼ無理である。

JPX の言う取引を見えなくするということは、バリデーションをかけるとこ

ろとかけないところでわけるのではないか。秘匿しながらバリデーションする

のはまだまだ難しく、技術はそこまで進んでいない。 K 委員 ：リクワイアメントが何かは、Bitcoin と現実社会では違う。Bitcoin は総量が

増えなければ多少誰かの持ち分が落ちても良いということになる。現実の取引

所では、落ちたことについての補償等が生じることになる。Bitcoin は他の

entity がないので、落ちても本人があきらめるだけである。 委員長 ：3 点くらいに論点を絞りたい。1 つ目は、リクワイアメントの固定をどう考え

るか。ブロックチェーン技術の特性を生かすには業務を変える必要もある。こ

の辺についてどう考えているか議論をしたい。2 つ目は、何と何を評価するか

ということで、ブロックチェーン技術と既存のデータベースを使ったシステム

についてざっくりとどうわけられるか。3 つ目は、軸を考える中で、どういう

項目が考えられるか。ISO もみながらその辺の議論もできればと思う。まず

は、業務用件について考えたい。 I 委員 ：例えば、証券取引の場合に、取引の秘匿はどのくらい重要なのか。 JPX 社 ：現状を考えると、取引状況が全て公開だとすると、使いたい人は集まらないと

思われる。一般的に、いくらで何株の取引をしたということは隠したい情報で

ある。現状板に見えている情報は一部であり、裏にプロ投資家同士の動きもあ

る。 委員長 ：顧客からどの程度リクワイアメントを変えていいというオファーが来るのか。 G 委員代理：既存システムの入れ替えの場合、顧客はブロックチェーン技術を使うからと

言って、リクワイアメントを変えようとは思わない。しかし、ブロックチェー

ン技術を使うからには業務を変えようという顧客も多くいる。前者の場合ブロ

ックチェーン技術の優位性を出しにくいので、業務を変えることを前提にした

評価軸にしたい。 B 委員 ：JPX のプロジェクトでは、システムベンダーがだしてきた要件は、従来の業

務をそのまま踏襲するというものだった。その方法だと断片的なプログラムを

いくつもつくらなければならず、とても期間内に終わらなかったため、一気通

73

貫で作ることを提案し、何とか 3 か月で実装することができた。 A 委員 ：トレーダーは株取引で自分の取引の手口は隠したいだろう。昔は全部見えてい

たが、国際的な流れでプロのトレーダーは anonymous になってきた。見せた

くないというデマンドは変わらないだろう。ブロックチェーン技術を活用した

システムであればそのような秘匿性をもたせることができるはずである。 K 委員 ：Bitcoin、ブロックチェーン技術でもオーバーレイの分野で、匿名性を高める

ことはやられているので、技術的な可能性はあると思われる。 参考までに 2 つ文献を用意して事務局に配布してもらったので、見て欲しい。

カナダの homeland security の分野の評価表と、スループットの話を記載し

た日経の記事である。 また、あらゆるベンチマークを考えることは難しいので、データベースの世界

における TPC ベンチのような典型的なケースを考えるとうまくいくかもしれ

ない。 委員長 ：リクワイアメントについては変えるケースと変えないケースを両方見ることが

妥当であると考えられる。 I 委員 ：ビットコインではマイニングに時間が掛かるため、コーヒーを買って、決裁が

下りないうちにビットコインを売るというようなこともできなくはない。つま

り、ブロックチェーン技術を活用したシステムはリアルマネーにおける当たり

前の前提を取り払った上で成り立っているシステムである。 B 委員 ：今はペイメントプロセッサーがその決済リスクをとっている。今まではクレジ

ットカードなどでチャージバックの期間は 1 ヶ月とかそれ以上であった。ブ

ロックチェーン技術を活用したシステムはそれが 1 時間に短くなる。 A 委員 ：1 時間だと二重支払がわかったときにはコーヒーを飲み終わっちゃっている。

どれだけ短くしても、事業者か加盟店が負担するのは変わらない。 I 委員 ：クレジットカードの場合はそのリスクがあるため、手数料を取っている。ブロ

ックチェーン技術を活用したシステムはリスクが小さくなったからと言って、

手数料ゼロにはできないと思われる。 A 委員 ：リスクとして短くなるのはわかる。ただ Bitcoin は簡単に偽装できる。そのう

ち、トランザクションを偽装するための専用アプリができるのではないか。 委員長 ：要件がどうかわっていくのかをどう表現するのかは頑張って考えたい。次に、

何と何を比較するのかを考えたい。 B 委員 ：ブロックチェーン技術のコアの部分だけ見ると何もできない気がするため、非

常に難しい問題である。 I 委員 ：データベースだとコストが重要な指標なので、それを見るためには、ミラーリ

ングとバックアップまで含めて考える必要がある。 B 委員 ：可用性を担保するためにズーキーパーを入れるということまで考える必要があ

る。 K 委員 ：それは、持ち込む人にパッケージングさせて比較するしかない。持ち込む人が

74

何を担保仕様としているのかをベースにすれば○×表は作れると思われる。 B 委員 ：その○×だけだと、システムベンダーが業務にいかせるかどうか疑問が残る。 I 委員 ：本質的には、×表をつくるのだと思われる。ブロックチェーン技術を活用した

システムが延ばせる点、どうやっても越えられない壁を明らかにすることが必

要だと思われる。 A 委員 ：例えば、ガソリン自動車と電気自動車を考えた場合、エンジンとモーターを比

較することも必要だし、車全体としての燃費やパワーを比べることも必要であ

る。エンジンとモーターではトルクなどできることが異なり、ブロックチェー

ン技術を活用したシステムと他システムでも同様のことが言える。 委員長 ：エンジン（プラットフォーム）も比較するし、パッケージとしても比較するこ

とが必要という理解でよいか。 A 委員 ：その両面が必要である。エンジン（プラットフォーム）だけ見て大きく性能ア

ップできても全体でみるとそれほど大きな差は出ないというケースも多い。全

体を見ないわけにはいかない。 H 委員 ：やはりブロックチェーン技術の良さを適切に評価するのであれば、リクワイア

メントを変えることを前提に考えないといけないと思われる。 I 委員 ：難しい道だが、ユースケースから抽象的な要件を抽出して、整理すれば評価が

できるかもしれない。 事務局 ：誰に対してブロックチェーン技術を売り込むのかを想定して欲しい。経営者な

のか、システム担当者なのかで考えなければならない要件が変わる。ベンダー

の方中心に、次回まででいいので、ユーザーがどのような指標を求めているの

かを考えてきてほしい。 G 委員代理：バランスドスコアカードのように業務の視点からすべて比較できるのが理想

である。評価をする場合、まずは機能の所が見えるといいが、その上で業務の

話をするかどうかはチャレンジングである。 委員長 ：パッケージとして業務も見えると理想だが、どう軸に入れるかは宿題。今の議

論も含めて、ISO の項目と比較して追加／削除があればコメントをいただき

たい。 I 委員 ：ISO の項目を一段ブレークダウンすることになると思われる。ただし、信用

性がつらいところだが。人に分散するというのは、神様の目から見たら可用性

が上がっているが、これだけの人に任せなければならないのという。それが実

用性と信用性のトレードオフになっているのだと思われる。 L 委員 ：海外との似たような議論を見るべきか。ISITC などはベンチマーク的なもの

を作っている。それらとすり合わせるか、日本独自でやるかはどのように考え

ているのか。 委員長 ：まずは日本の考え方を整理することが必要だと思われる。 事務局 ：必要な情報があれば調査をするので、要望を出して欲しい。 B 委員 ：評価対象は、ブロックチェープラットフォーム毎に評価していくイメージか、

75

それとも何らかの一般的なブロックチェーン技術というものを定義して比較

するのか。 委員長 ：おそらく両方を評価することになると思われる。 B 委員 ：ブロックチェーンプラットフォームごとにやれることは異なるため、ブロック

チェーン技術ごとの評価をするためには、何かを追加すればできる／できない

という書き方をすればよいと思われる。 委員長 ：ISOの指標は議論のスタートとしては価値があるということだと思われる。

また、単純な○×ではなくて、各ブロックチェーン技術の特徴を記載したよう

なコメントが価値を持つ評価表が必要だと思われる。 B 委員 ：そのような記載をすれば、最終的には何ができないかも自明となる。 委員長 ：次回に向けて何を整理しなければいけないかも見えてきたので、事務局で再整

理をして次の検討につなげたい。 事務局 ：議論の内容は共有した上で、第 2 回～5 回の日程調整を行いたい。

以上

76

第 2 回 ブロックチェーン技術を活用したシステム評価軸検討委員会 議事録

日 時：2016 年 12 月 16 日（金） 17 時～19 時 場 所：経済産業省本館 17 階第 3 共用会議室

1). 前回議論の振り返り

事務局 ：（「資料 2 前回議論の振返り」の説明を行った）

2). ユースケースと評価事例の紹介について 事例 1：JPX ブロックチェーン実証実験に関する所見 ※「資料 3-1 JPX 事例における評価について」の説明を担当委員が行った。

I 委員 ：業務を変えるか変えないかということに 2 つの定義がある。サブシステムを

変えるかどうかということと、Bitcoin の資金移動がコインの取引のルールを

変える話とがある。今回の実証実験は、システムは変えたが、取引のルールは

変えていないということでよいか。 B 委員 ：業務は変えておらず、システムの在り方を変えている。 K 委員 ：大まかに分けましたということだと思う。この仕組みにしたことで動くという

ことはよくわかったが、メリット／デメリットについてはどうか。ソフトウェ

アはモジュール化されているのか、足並み揃えるのは大変だと思うが。 B 委員 ：2 回目の実証実験を JPX でやるが、広く募るといわれている。プロトコルを

決めるところから全員でやらないと難しい。コンソーシアムを作ることが第一

の仕事になるのではないか。 K 委員 ：セントラライズしないことがアーキテクチャ上のメリットだったはずだが、参

加しているエンティティが摺り合わせをすることになるのか。 B 委員 ：ネットワーク、ノードレベル以上では、プロトコルを統一しないと、ブロック

チェーン技術では何もできない。K 委員の言うアーキテクチャとは、何のブ

ロックチェーン技術を使うか、データの持ち方ということか。それがガラパゴ

ス化するということか。 K 委員 ：擦り合わせのところで話し合って 1 つにする必要があるということではない

か。 B 委員 ：予想がつかないが、標準化委員会みたいなものができるのではないか。もしく

はすでにある標準を使うのか。私よりも皆さんの方が、知見がありそう。 D 委員 ：アプリケーションのデータの持ち方については早急に考えないと行けない。製

造業系で、横一列で統一のルールをつくろうかという動きはある。 B 委員 ：ネットワークレベルやノードレベルよりもベースのところは、同じもので動か

ないといけないのがブロックチェーン技術。課題は組織化になる。 委員長 ：業務が変わりそうなところを堪えて変えなかったように見えるがどうか。 B 委員 ：敢えて変えなかったわけではない。募集発行割当などは証券取引として将来的

77

にも存続する業務だろう。ただし、登場人物は変わっていると思う。誰がいな

くなるかというと、当の JPX や、当の証券会社や、当の決済業者が消える。

残るのは人を認証する（電話、メール）等のアナログな部分だろう。最終的に

は、投資家と会社の P2P の取引ができるということをいっている。 I 委員 ：相対だとわかるのだが、板の場合はどうか。 B 委員 ：指値を掲示板としておいて、テイクする。 I 委員 ：同じ額の優先度はどうするのか。 B 委員 ：同じ額の優先度は、FIFO(First-In First-Out)になるようにしていたと記憶し

ている。部分約定をどうするかとか、残約定をどうするかなどいろいろなこと

があるが、今回は「乗っかっているものを取るだけ」とした。実際には残約定

やフィボがでてきたが。 I 委員 ：取引所の役割としてストップ高の場合等に決めることは残るのではないか。 A 委員 ：発行するというのは無から生み出す行為だと思うが、これはどうセキュリティ

を担保するのか。 B 委員 ：そこは課題としてワーキングペーパーに残っている。登記事項を誰が認証する

のか、証券会社なのか、新しい役割の人なのか、決済機関として一括管理する

のかについては決めなかった。とりあえず機能としてお金を入金し、それを資

金トークンと考えて、それをディールとするしかない、ということになってい

る。 A 委員 ：ゼロバリデーションみたいなものはどうか。スピードはどうか。 B 委員 ：報告書から抜粋すると、2 桁から 3 桁パーセカンド。バリデーションは、

Tendermint プロトコルを使っているので 2/3 の認証で、1 秒～3 秒程度。 A 委員 ：それはトランザクションの認証のことだろう。例えば、残高がない場合にはど

うか。 B 委員 ：その状況はなかった。 事例 2：ブロックチェーン研究会におけるブロックチェーン技術の実証実験 ※「資料 3-2 ブロックチェーン研究会事例における評価について」説明を担当委員が行った。

K 委員 ：コアノード、アプリノードの比率はどうか。 A 委員 ：アプリ 144、コア X～Y 個で可変。公開情報以外は回答を控えたい。 B 委員 ：性能評価に重要な数だろう。 A 委員 ：響きはするが、皆さんが思うほどのインパクトではない。トポロジー設計によ

る。背反の設計になっていて、ノード数が増えれば可用性は上がる。同時にパ

フォーマンスは落ちる。そのグラフもある。 B 委員 ：ネットワークは関係ないというのはどういう意図だったのか。我々がやってい

ると、ネットワークのレイテンシはパフォーマンスに影響が出ている。Azureも使っているが、パフォーマンスがいい数字は出やすいが、一方であまり某ク

ラウドだと全然パフォーマンスがでないことがある。影響が出ると思うがどう

78

か。 A 委員 ：ネットワークの影響は出るのだが、遠隔地でやった場合と同じデータセンター

ではパフォーマンスに違いが出る。Azure はいわゆるジャパンイーストだと

5Gbps は出る。 B 委員 ：同じ認識である。回線の帯域には依存しない。レイテンシはどうか。 A 委員 ：レイテンシは明確にヒットする。NY にあるだけで 80msec はかかる。 K 委員 ：純粋に BCP 目的であれば 4～500 キロ離れていればよい。どれくらいの拠点

を設けるかでコストが変わる B 委員 ：JPX の実証実験では、承認の速さに加え、順序性をどう担保するかが難しか

った。現状の仕組みでは難しい。ユーザーの PSA を置いてタイムスタンプを

正とし、順序性を担保してはどうかという話はあった。ただし、ブロックチェ

ーン技術の評価ではなくなるのでレポートに含んでないが、議論の余地がある

ところだと思う。 A 委員 ：皆さんが思っているほど帯域は圧迫しないので、100M の専用線でも十分であ

る。レイテンシは光の速さなので仕方が無い。レイテンシを気にするのは、証

券会社の取引が msec で発注しているからである。金融機関の人は、クリアリ

ングであればバッチ処理のため、何秒かかろうが気にしていない。 B 委員 ：同時のタイミングが生じたときに、どっちが正なのか。 A 委員 ：解決できているところもある。 J 委員 ：ブロックチェーン技術の定義からして違和感がある。ノードがデータセンター

に集中しているのか、地球上に分散した形にあるのかによっても使い方に違い

があるのではないか。光の速度では、1 秒間に地球 7 周半しかできない。毎秒

何千件やろうとすると、順番も変わってくる。分岐は地球上の 1 点で動いて

いることが前提な気がするが。 A 委員 ：分岐は生じない。順序を決めることも可能。 J 委員 ：分岐が生じないことは物理的に不可能ではないか。 E 委員 ：開発アルゴリズム上は特性として発生しないということか。 I 委員 ：ネットワーク上で時間を順序のセットとだけ見て、レイテンシをつぶしたとき

に、地球の反対側からの取引がぶつかった場合、順序関係というのは、ネット

ワーク上の順序は認められるとして、実際にはブロックチェーン技術を活用し

たシステム上の取引はそれよりも遅い。 J 委員 ：ロジカルなものとして、このトランザクションの次にこのトランザクションが

ある、というのでも無理ではないか。 B 委員 ：JPX の実証実験では、Tendermint プロトコルのプロポーザーで合意されるか

否かで決めることになった。 J 委員 ：順序の話ではなく、因果関係の順序のことを質問しているのだがどうか。 I 委員 ：距離が入ってくると、実世界の順序とは必ずしも一致しない。同じ場所から入

ったもの対して順序が保存されるが、ネットワークから見た場合に光の速度で

79

見たときの世界の順番を保存しているとは限らない。遠隔地でやりとりしない

と決まらない。それがビジネスと合うかどうか。 J 委員 ：前提を正したい。例えば、ロサンゼルスのノードが受け取る順序は、整合的な

歴史を作るし、北京で受け取るノードも整合的な歴史をつくる。各ブロックに

入っているトランザクションのセットはそれぞれ違ってくる。であれば分岐は

起きるのではないか。実装に依らないのではないか。 B 委員 ：コンセンサス・アルゴリズムによるのではないか I 委員 ：順番を決めなければならない場合には、光の速度の遅れの中でコミットされる

のが遅くなる。 A 委員 ：コンセンサスを 1 回と想定しており、PBFT は想定に上がっていないので食

い違っているのではないか。 J 委員 ：前提が異なるのであろう。 A 委員 ：一般的な PBFT 型は 1 回でコンセンサスはとらない、複数持つ。 J 委員 ：分岐が起こるから PBFT が必要。分岐が起きないことが理解できない。 I 委員 ：分岐の定義が異なるのではないか。ローカルに入ってきたものの順序が食い違

っていることについて、分岐のないコンセンサスを見ているのであれば分岐が

ないということになる。コンセンサスを「分岐を定義すること」と見なすのか、

「分岐のない列を作ること」と見なすのかの違いではないか。 J 委員 ：それであれば理解できる。

3). 評価指標の活用について

※「資料 4-1 システムベンダーが評価指標に求める要件（1）」の説明を担当委員が行った。

I 委員 ：制約については同意する。法律の議論で契約として認められるかは弁護士に頼

むが、こういう契約であればこういう性質が満たされなければならないという

観点は検討に入れても良いのではないか。技術屋が見ても明らかであることを

前提に。 A 委員 ：国税庁と話したのだが、スマートコントラクトは契約に当たるのではないかと

いう可能性を示唆している。事前登録が必要。スマートコントラクトは見た目

がプログラムで、自然言語で書いていないものを契約と呼べるのかとの議論に

なったが、そこで書いてあるものを元に執行されているのであれば、契約では

ないかということだった。 D 委員 ：資料について訂正をお願いしたい。Bletchley は特定のブロックチェーンプラ

ットフォームを指しているものではない。Bletchley は、様々なブロックチェ

ーン技術を使ってもらえるようにするプラットフォームを目指すプロジェク

トの名前である。 A 委員 ：Corda も違う。Iroha もアプリケーションと考えられる。プラットフォームと

その他のボーダーは議論したほうがよい。 K 委員 ：これから弁護士を入れるのはハードルが高いと思うが、要件として考えた方が

80

良いのではないか。民法の中では合意が成立していれば契約であるし、どれだ

けの証拠能力があるかだけでなくて、多様な要件が入ってくるだろう。ハード

フォークも含めて状態遷移がある中で、どれだけ証拠能力を持つかを掘り下げ

るべき。 B 委員 ：証拠能力の話はブロックチェーン技術のコアの話で、スマートコントラクトと

は違うのではないか。 I 委員 ：コアがはっきりしているのであれば、スマートコントラクトは投げ入れる。そ

のコアで承認されたのであれば、投げ込んだ条件に束縛されるという口約束と

解するのが良い。 B 委員 ：何を評価するのかという観点で言うと、Ethereum みたいなチューリング完全

の部分は捨ててもよく、ブロックチェーンコアとそこに何をもたらすかの方が

重要だろう。スマコンは多岐に渡りすぎている。 K 委員 ：ブロックチェーンコアにおける保持されたデータの証拠能力だとか、契約の要

件をのせるためのところ。 委員長 ：法的にどう扱われるかを検討する必要があるということか。 B 委員 ：書き込まれた情報の真正性はどれくらいの証拠能力を持ちうるのか。 D 委員 ：民法、刑法、医師法も絡むだろう。記録がブロックチェーン技術を活用したシ

ステム上にあり、それが記録を保持している証拠になるのか。ブロックチェー

ン技術を活用したシステム上に記録したデータが証拠能力を持つという主張

は、いずれ出てくるだろう。 A 委員 ：米国と日本でも違う。米国では証拠の範囲が限定的。日本は証拠提出の範囲が

広い。スクリプトで書かれたものは契約と見なされる。では IL、バイナリは

どうか。自然言語と何が違う。記述方式を議論する必要がある。 D 委員 ：DDF でも同じことが起きている。電子カルテを取組んだ際に、医師法上では

電子カルテにするために見読性の確保が求められた。 委員長 ：法的な問題についてこの研究会にどう位置づけるかも課題とする。 ※「資料 4-2 システムベンダーが評価指標に求める要件（2）」の説明を担当委員が行った。

I 委員 ：秘匿性が重要だと思う。秘匿だけど、中身を見ないとコントラクトがわからな

いものについては、取引高が見えないことには取引成立が見えない。うまく抽

象化して整理する必要がある。 B 委員 ：ビジネスロジックは透明でよい。トランザクションの中身の数字が秘匿できれ

ばよい。実装は検討されている。やり方もたくさんあって、この辺、日銀で秘

匿性の実現とかを話してきたことがある。進み始めていると思う。 I 委員 ：SCM ではスマコンの中身が契約そのものになる。スマコンのロジックの秘匿

性は、金融で不要でも SCM では必要になる。 D 委員 ：コンソーシアムで、同業者同士、子会社同士でブロックチェーン技術を使って

管理する方法など金融とは異なる業種の話が出てくる。業種業態によって求め

81

られるブロックチェーン技術を活用したシステムの仕組みは違う。5 分遅くて

もよいものもある。卒業証書の記録であれば、後日でもよい。短絡的に早さだ

けが良ければ良いというわけではない。秘匿性も同様だろう。その場合、異業

種間で使うブロックチェーン技術が異なる場合に、ある程度統一的なハブチェ

ーンが出てくるのではないか。各業種向け、目的で定めておく必要があるだろ

う。 I 委員 ：二つやり方があり、1 つは何でもできるパブリックチェーンで秘匿性はシステ

ムが確保。もう 1 つは、間をまたぐスマートコントラクトをブロックチェー

ン技術を活用したシステム間でつなぐような形。実際には金融ではこの要件が

強いので、こういう特性を持っていなくてはいけない、ということになって、

○×表の二次元を作ろうということではないか。 B 委員 ：複数の基盤がある中で、標準化して 1 つにするということか。 G 委員 ：Hyperledger は 1 つに絞る気持ちがない。私たちとしては、1 つに絞ってフォ

ーカスした方が良いということはある。ただ目的が違うので、それを併存させ

るのがポリシーだろう。 D 委員 ：Bletchley も同じ。当初から業種や目的によって求められる性能・機能が違う

だろう。できるだけ多くのテクノロジーが動くようにしようとしている。

4). ディスカッション

委員長 ：全体的な議論に移りたい。ここまでの話を整理すると、ブロックチェーン技術

の得意不得意は実装によっても異なる。E 委員からは、評価の対象は公開され

ているアルゴリズムを対象とすべき、パブリックとプライベートは分けるべき、

法的なコントラクトがどう受容されるのかについて提案・意見をいただいた。

G 委員からはブロックチェーン技術を活用したシステムによる異業種連携と

標準化について指摘いただいた。ファイナンスと SCM との統合については、

業務がどう変わるかの観点で重要になるだろう。議論をまとめる上での観点と

して、E 委員からの「PF について：実装によって違う中で、どこまでを対象

にするか。オープンなものを対象にすべきではないか」ということ。A 委員か

らの提案の「エンジン同士の比較も重要であり、エンジンを積んだ車全体の比

較も重要である。両面からやるべきだ」ということもある。ここについて議論

したい。業務、業種から見て、どう評価するか。エンジン同士、車同士の比較

が可能なのか。 A 委員 ：レイテンシどのくらいで、スループットがどのくらいで、ノードが同じ条件に

して比較するのがエンジン（プラットフォーム）の比較。そのときに可用性が

どうか、分岐するかどうかなどを見ていくのが良い。それを使った上で、アプ

リケーションとして、スマートコントラクトを解釈するくらいまで比較するの

が良いと思う。また、E 委員の言う、オープンソースのみを評価対象とする件

には反対である。ソースはオープンにしていないものでも、第三者が検証する

82

ことは可能である。客観的に観察できれば良いのではないか。 D 委員 ：私は E 委員に賛成である。業種の話ともつながってくるが、オープンソース

の方がよいとおもう。クローズドソースとしてあった場合、公共財性、社会性

という側面ができる。使う軸によってはオープンソースであることが求められ

るだろう。 I 委員 ：評価軸の整理なので、オープンソースで良いだろう。クローズドソースは各事

業者がそれに乗っ取ってやれば良い。ここでは表をかけるか否かを試すための

検証。表の中身は現時点では重要ではない。 B 委員 ：A 委員と同意見。プロプライエタリも評価すべきだと思う。性能はそっちの方

が良い。オープンソースだけではダメである。 I 委員 ：オープンソースでしか見なかった場合に抜け落ちるポイントがないか。オープ

ンソースで比較して、差が出れば問題ない。オープンソースだけ見た結果、性

能が抜けるのはまずい。 B 委員 ：性能は雲泥の差がある。何かの業務に特化している場合、オープンソースを見

ると性能がかなり落ちる。ブロックチェーン技術の性能評価をしているのかと

いうと足りていない。 委員長 ：軸を整理するという観点では、いろんなバージョンを念頭に置きつつ、軸を作

ればいいのではないか。 I 委員 ：オープンソースは中まで見えるので、評価軸を決めるときに深く見ることがで

きる。クローズドソースのものは中が見えないので、ホワイトペーパー等で主

張している軸を、オープンソースの軸と照合して、不足がないかという視点で

見ればよいだろう。 B 委員 ：実験であればそれでもよいが、実装ではどうだろうか。 A 委員 ：車のエンジンを評価するのなら、機械にかけて性能を評価すればよい。測定し

たいものが性能であれば、外形的に測れればよい。 B 委員 ：性能差が近ければよい。性能差がけた違いに違うならどうか。 D 委員 ：性能面だけでやるのは危険。車で言えば、F1 カーと畑のトラクターを比較す

るようなもの。性能と適正の軸と、プロプライエタリとオープンの軸の 2 軸

を持つべき。 B 委員 ：汎用性、一過性という軸もあるだろう。 D 委員 ：どのブロックチェーンプラットフォームがいいのかわからないという相談を顧

客企業から受けることがある。各ブロックチェーンプラットフォームの傾向か

ら、業界に応じて向き不向きが言える軸が要るのではないか。単純に性能評価

軸では成立しえない。 I 委員 ：セッティングが決まった後の性能を調べればよい。どう特化させたのか、なぜ

か、どういうビジネスロジックがあるのか、を明らかにした上で、評価すべき。

金融だから、物流だからではなく、その背景を明らかにすべき。例えば、クロ

ーズドなチェーンの場合は、Azure で 2 結合くらいでよいとか、リアルタイ

83

ムに世界中でコピーがないと困るチェーンの場合はこのような条件が必要、な

どが評価軸に書かれているとよい。ノード分散についても、東京と大阪だけで

良いのか、同時沈没を想定するのかでも変わるだろう。 K 委員 ：報告書の目的に立ち返る必要がある。ブロックチェーン技術が萌芽的な技術で

ある状況で、物差しを示すことでブロックチェーン技術の普及を図ることを目

的とするならば、利用検討している企業にとってどれだけ役に立つかを考える

必要がある。その場合に、オープン／クローズが両方ある中で、クローズによ

って評価が難しい項目があればそれは要件としてあぶりだすべきだろう。 I 委員 ：オープンソースであるメリットは自明ではない。ただ少なくともさっきの電子

カルテで言えば、法律あるいは国会レベルで問題になったときに、業者の協力

の有無に関係なく、パブリックに検証可能であることが大事だろう。 委員長 ：企業で使うときにはどうかというとどうか。 F 委員 ：ブロックチェーン技術をわかっている方は良いが、ブロックチェーン技術をわ

からない人に何を伝えるか。コンソーシアム型とパブリック型ではこれが違う、

プラットフォームによってはこういう特化型と汎用型がある、ということを見

せることが重要ではないか。時間が経てば評価軸が変わるだろうが、現時点で

評価軸を出すことが必要。数値は後で測れば良い。まずは項目軸とバリエーシ

ョンがあればよい。 I 委員 ：数字はシステムベンダーが出すだろう。システムベンダーに相談する上で、何

を考えるべきかのリストが必要。リストを元に、ブロックチェーン事業者やシ

ステムベンダーは検討ができる。 K 委員 ：持ち込める形ができればよい。性能なんて半年で変わる。必要な要件が業種ご

とにあぶりだせれば、今までなかった要件を R&D で伸ばせるといった貢献も

ある。普及にも研究開発にも資するのではないか D 委員 ：業種によってはトランザクションが不要なこともある。多角的に、二軸か三軸

かくらいは考えないといけない。 I 委員 ：ブロックチェーン研究会と JPX とで違う。 K 委員 ：業種ではなくて、業務でなお異なる。異後と約定では異なる。 委員長 ：ブロックチェーン技術が良いかどうかということではなくて、どう使えば良い

かも含めて、ユーザーの意見にも踏み込んで評価できると良い。今日の議論を

整理し、次回の議論に持っていければよい。 以上

84

第 3 回 ブロックチェーン技術を活用したシステム評価軸検討委員会 議事録

日 時：2017 年 1 月 18 日（水） 16 時～18 時 場 所：経済産業省本館 1 階西共用会議室 ゲストスピーカー：株式会社リクルートテクノロジーズ

1). 前回議論の振り返り

事務局 ：（「資料 2 前回議論の振返り」の説明を行った） K 委員 ：クローズドなブロックチェーン技術を活用したシステムを対象とするかどうか

は前回の有識者検討委員会で議論になったところなので、もう少し議論が必要

だと思われる。ホワイトペーパーも十分な情報が出ているわけではない。クロ

ーズドなブロックチェーンベンダーにも情報提供の機会を与えるような仕組

みにしてもいいと思われる。 委員長 ：評価軸検討の際に、実際にシステムを動かしている人に協力をしてもらうとい

うことか。 K 委員 ：事務局がデータを集める場合に、情報がオープンでないものについては、ベン

ダー側が作業をするような仕組みにしてもいいと思われる。 B 委員 ：そこで問題になるのは性能値だと思われる。機能については、ホワイトペーパ

ーで十分だと思われる。 K 委員 ：機能についても言葉の定義の問題があると思われる。 H 委員 ：同様の印象を持っている。性能についてホワイトペーパーで情報を取るのは難

しい。 委員長 ：今回の目的は軸を作るのが主目的で数字を集めるところまではいかないと思わ

れるが、軸を検討するのに必要な情報は事業者から提供してもらう方がいいと

思われる。 K 委員 ：機能も含めて、ベンダーに回答させるようなことをした方がいいと思われる。 C 委員 ：定義が合わない段階での数値を比較するのは難しい面もある。 B 委員 ：ホワイトペーパーには夢の部分も書いてあるため、純粋な比較は難しい面もあ

る。ただし、一次情報としては自己申告で記載してもらうことは有効だと考え

られる。 事務局 ：今回の検討の中では、機能についての評価の必要性について検討をしていきた

いと考えている。性能についても指標として必要かを考える予定であり、実際

の数値については、ブロックチェーンベンダーが利用する際に自分たちで数字

を集めることを考えている。また、各指標については、どのように使うか、同

データを取るかなどを備考欄に書いていくことを考えている。そこに何を書く

かということも意見をいただきたい。 J 委員 ：秒間のトランザクションといった評価と給与振込みたいなことを考えたときに、

ブロックサイズを勘案するか、場所の分散をどう考えるかどうかで値が大きく

85

変わってくると考えられる。前提条件を明確にしないで比較することは難しい

と考えられる。 D 委員 ：前提のスペックも非常に重要だと考えられる。 K 委員 ：前提条件を出さずに、マーケティング的に数値を出すことはフェアでないと考

えられる。 L 委員 ：ある程度のカテゴリ分けをして、その中で比較することが妥当と考えられる。 委員長 ：スループットはブロックチェーン技術の関心事項なので、前提条件をしっかり

決め、備考欄的なものを充実させていく必要があると思われる。この議論は有

識者検討委員会の後半で、重点的に行いたい。

2). ユースケースの紹介について （リクルートテクノロジーズ社（以下「R 社」）より、事例のご紹介をいただいた）

C 委員 ：リクルートの自社ビジネスとしての活用を考えていると思われるが、ブロック

チェーン技術の活用で誰がメリットを感じるかなどの考えがあれば教えて欲

しい。 R 社 ：履歴書データベース（DB）の事例で言えば、採用側の企業にとって応募者の

情報に信頼性を持てるということがメリットだということが分かった。また、

同じ考えで、企業の信頼性情報などもユーザーメリットが大きいと思われる。 D 委員 ：リボンモデルを保持しているとブロックチェーン技術を導入して業務を変える

必要性は少ないのかもしれない。第 3 フェーズみたいな形が最終的な姿で、

JPX もそのような姿となっている。 K 委員 ：ブロックチェーン技術によって情報が改ざんされないことが担保されたとして

も、最初に入力される情報の正確性については担保できないことは留意が必要

だと思われる。 もう 1 点、ブロックチェーン技術を活用した場合、エンジニアリングコスト

が掛かることが課題になると考えられる。同じことをやる場合、クライアント

サーバー型の方が開発コストは安くなると考えられる。 R 社 ：プライベートチェーンでできることはクライアントサーバー型で実現できると

考えられる。ブロックチェーン技術の価値はパブリックチェーンにあると考え

られる。 B 委員 ：ブロックチェーン技術でしかできないことは何かという質問を数多く受ける。

ウォレットを会員登録なしで実現できれば、ブロックチェーン技術でしかでき

ないことだと考えられる。アドレスを計算で生成して、そこに価値を送るとい

う仕組みである。クリプトウォレットと呼ぶべき様な世界だと考えられる。プ

ロビジョニングなどもいらなくなる。アプリをダウンロードした途端からウォ

レットを使えるようになる。 D 委員 ：第 2 フェーズのような形は研究をしている。実用化に当たっては、コンソー

シアムを作るなどして、全体を一気に変えないと進まない。ROI が出ないこ

86

とになる。卒業証書のようなものであれば、公的な ID との紐づけか、コンソ

ーシアム内での ID などが必要と考えられる。 委員長 ：職歴を登録する人は誰か。 R 社 ：当初の登録は自分が行い、それを元居た会社が承認するような仕組みとなる。 L 委員 ：卒業証書に大学が電子署名をするようなものと何が異なるのか教えていただき

たい。 R 社 ：パブリックな情報ソース上にデータが存在していて、第三者が見られるという

ことが重要だと思われる。 K 委員 ：元居た会社・大学がなくなったりする場合、保証する主体がなくなることにな

る。長期間必要なデータについては、ブロックチェーン技術を活用することで

担保されるかもしれない。 B 委員 ：ヒストリック署名のような技術的な解決策もある。 R 社 ：R&D 段階であり、指摘のような課題があることはもっともだが、ブロックチ

ェーン技術が使えるということは検証できたと考えている。 L 委員 ：リボンモデルという大きな範疇では業務が変わっていないと思うが、認識相違

はないか。 R 社 ：大きな概念では変わっていないと考えられる。 D 委員 ：ブロックチェーン技術の活用を考えると、システムがどんどん公共財化してい

ってしまう。つまり、既存のリボンモデルで活用するのは難しいと考えられる。 B 委員 ：インフルエンサーを中心としたリボンモデルはありうるかもしれない。どこに

いるかわからないが、リボンの結線に居るような人を活用するということはブ

ロックチェーン技術の特性を使うことで実現できると考えられる。それが実現

できれば業務を変えることになると考えられる。 K 委員 ：過去のデータを変えられないということが実装上課題にならないかということ

を教えて欲しい。通常はシステム更新の際に、以前のデータの構造を変えたり

することがあると考えられる。 R 社 ：スクラップ＆ビルドを繰り返しているが、作り替えることにデータスキーマの

作り直しが必要になっている。また、パブリックな場合仕様を変更した場合に

どんな作り替えをしたのかが分かってしまうため、営利企業としては課題があ

ると考えられる。 委員長 ：中央集権的ではないスキームが見えてくる中、Bitcoin のように、ワンタイム

でアドレスがわかればいいものと違い、長期的なデータ保存が必要になる場合、

誰かが管理しなければいけないことが新たな課題になると考えられる。求職者

と元の企業が結託して情報を改ざんすることも可能だと思われる。 K 委員 ：その 2 つは本来別の問題だと考えられる。

個人的にブロックチェーン技術の価値と考えているのは、サービス提供主体・

証明書発行主体が無くなってしまった場合にもデータが保全される点にある

と考ええている。

87

B 委員 ：電子署名においても同様の仕組みは担保されていると考えられる。ハッシュ値

は変わらないために、同様の機能を得ることができる。ある情報を、別の情報

と一緒にしていく、というのがブロックチェーン技術の仕組みであり、ある意

味でヒステリシス証明と同じと考えている。その役割を考えるうえでは、パブ

リック、プライベートの区別は不要と考えられる。 D 委員 ：同じ業種が集まってコンソーシアムを組む場合、ブロックチェーン技術のメリ

ットが出ると思われる。例えば、処方薬の履歴が残るというのはメリットだと

考えられる。そのためには、コンソーシアムをどうデザインするかがポイント

で、それにより業務が変わると思われる。 R 社 ：ブロックチェーン技術が普及するとデータが正しいことと無くならないことは

保証されると思われる。しかし、そのデータが利用者にとって適切なデータな

のかはわからない。その適切性を利用者に与えることがリクルート等の事業者

の役割になると考えられる。 B 委員 ：JPX の事例でも証券会社の役割としてそのような話をされていた。 K 委員 ：Bitcoin の場合も、元の仕組みがしっかりしているから事業者の役割が無いか

と言ったらそうではなくて、使い勝手の面などで存在感を発揮できる場面は多

くあると思われる。 G 委員 ：ステイクホルダーが増えると切り替えが難しくなるという問題は常に発生する。

SWIFT なども金融機関の不満は大きいが、切り替えることができない。切り

替えコストを賄うためにはブロックチェーン技術がフィットする業務を真剣

に考えないといけない。 K 委員 ：ブロックチェーン技術の価値が出ることは、公表することが義務付けられてい

るものだと考えている。公告などは各社の Web に出されていても正確には公

表されていると言いきれないので、一か所に集める意味があると考えられる。 D 委員 ：製造部品のトレーサビリティに関して、ブロックチェーン技術を使いたいとい

う話があった。製造業では多くのコンソーシアムが存在しているために、その

中でのブロックチェーン技術活用はやりやすいと考えられる。 G 委員 ：エアバスは SCM のためにブロックチェーン技術を活用しようとしている。そ

れができると企業にとっては非常に都合がよい。また、規制によってブロック

チェーン技術の普及が進むということも考えられる。 B 委員 ：コンソーシアムは必須ではないと考えられる。酒の真贋鑑定の需要があり、本

物の同定技術とブロックチェーン技術があれば、個社であってもメリットが出

ると思われる。 委員長 ：業務を変える場合のポイントが 4 点。1 点目は中央集権でないシステムを作る

場合であり、その場合は管理の役割をだれが担うか、情報の真正性をどう担保

するかが必要である。2 点目は情報を長期に保存できるというメリットがある

点である。取扱う情報としては、社会的意義がある情報や公表が義務付けられ

ているような情報になると考えられる。3 点目は、情報のキュレーターのよう

88

な役割が重要になると考えられる。情報を解釈し、エンドユーザーに伝える役

割が求められる。4 点目は多くのステイクホルダーが居る場合に、一気通貫に

情報を届ける点があると考えられる。 事務局 ：議論のたたき台として「資料 3 業務を変える場合の評価に関する論点」を用

意したが、説明が無くても十分な議論ができたと考えている。資料 3 につい

ても時間のある範囲で確認いただいて、ご意見等あれば連絡をいただきたい。

3). ディスカッション 1：業務を変える場合のブロックチェーン技術の特性について

※ 2.の内容と共にディスカッションを実施した

4). 評価指標の活用について

※「資料 4 システムベンダーが評価指標に求める要件（3）」の説明を担当委員が行った。 D 委員 ：ブロックチェーン技術でしかできないことというのは多くないと考えられる。

ただし、ブロックチェーン技術を活用することで利便性が変わるということは

あると考えられる。 A 委員 ：実証実験の中で、ブロックチェーンプラットフォーム同士を比べる場合と既存

システムと比べるという必要性があった。リレーショナル DB（RDB）でもよ

ければ、そこで出てくる課題はブロックチェーン技術の課題ではないと考えら

れる。ブロックチェーン技術の話をしているのか、既存システムの話、アプリ

ケーションの話をしているのかを分けて考えた方が良いと考えられる。 K 委員 ：RDB とブロックチェーン技術が並列で語られることに違和感がある。レイヤ

が異なるものである。 A 委員 ：レイヤは違うがブロックチェーン技術を使ったプロトコル全体と RDB を比較

するのはありだと考えられる。 K 委員 ：実務上、限界のスピードが問題になるケースは少ないと考えられる。本当に情

報システムを作る人が重要視している項目を考えていく必要があると考えら

れる。 5). ディスカッション 2：業務を変えない場合の評価指標について

事務局 ：（「資料 5 業務を変えない場合の評価指標案」の説明を行った） A 委員 ：コストについて比較をしないのかを確認したい。 K 委員 ：コストは構築と運用があり、そこをどう見積もるかという問題がある。項目と

しては、開発のしやすさみたいなものも必要だと思われる。 A 委員 ：一定の要件を示したうえでのコスト比較であれば可能ではないか。 D 委員 ：ROI を出すとしても既存システムの要件を満たすことが必要である。コスト

に関しては、資料 5 の評価項目の次の内容だと考えられる。 F 委員 ：全体のコストはわからないまでも、開発に関するコストだけでもわかるとよい

と考えられる。

89

H 委員 ：機能との見合いでコストを比較することは可能だと思われる。 A 委員 ：評価項目を考えるためには、顧客のニーズを踏まえることが重要だと考えられ

る。車のエンジンでも同様だと考えられる。 F 委員 ：性能のトレードオフを考えると指標の網羅性が重要になると考えられる。 委員長 ：数値はともかく、コストは何等か入れる必要があると考えられる。 B 委員 ：成熟性という指標があるが、発展途上の技術を評価しているということは留意

する必要がある。発展途上なために、開発コストが高くなるということもある。 K 委員 ：ブロックチェーン技術が適用しやすいユースケースというのは特定できると考

えられる。また、ユースケースとセットで、標準的なワークロードを設定する

こともできると考えられる。 B 委員 ：金融は必ず対象となるが、その他に何を対象とするかを考えたい。 K 委員 ：証跡保存はユースケースとして考えられる。書き込みが少なく、リファーが多

いような事例である。 A 委員 ：データーサイズを評価できるような指標が必要と考えられる。ブロックサイズ

に非常に弱いことが分かっている。 K 委員 ：ピュアなブロックチェーン技術というものは無く、機能の一部がブロックチェ

ーン技術で実装されることとなるため、そのシステム全体を評価することが必

要になると考えられる。 また、評価軸の最終的な出口としてはどうするかを考えたい。標準化の議論の

中でもこれだけの議論が行われていることは日本の大きなアドバンテージだ

と考えられる。 事務局 ：使い方は経産省として今後考えるが、経産省全体で標準化の議論ともマッチン

グさせて生かしていきたい。 D 委員 ：リファレンスとなるアーキテクチャの全体像が分かることが必要と考えられる。

トランザクションとマイニングを分けるような仕組みも必要だと考えられる。 F 委員 ：指標について、現場は顧客に比較表を見せる際に活用する。また、網羅的な指

標になっていれば、要件定義の時にも使えると考えられる。 K 委員 ：ISO/IEC2501x をリファーしていれば、一定の網羅性は担保されていると考え

られる。 F 委員 ：運用の観点の指標が盛り込まれていると望ましいと考えられる。 B 委員 ：ノードレベルだけでなく、コントラクトレベルでも必要である。ノウハウは、

やらないと身に付かない。インテグレーターの技術は、ノウハウそのものであ

る。 R 社 ：評価には、製品そのものだけでなく、担当者のノウハウ・スキルも関係してく

る。また、指標はプライベートな利用を想定したものでよいのか。 B 委員 ：要件によってはパブリックにしないといけないものだと考えられる。 委員長 ：指標については、網羅性があることが重要だと考えられる。そのために、コス

トの評価、データーサイズ、運用を追加で考えなければならないことが指摘さ

90

れた。もう一つは、ユースケースとそれに伴うアーキテクチャを想定してそれ

に応じた評価軸の使い方を検討する必要がある。 G 委員 ：ISO TC307 の国内委員会での議論が進んでいる。その中で、この委員会での

議論内容をどこまで出していいのかどうかなど決まりが欲しい。 K 委員 ：同じ経済産業省の事業の中なので、取り扱いを検討して欲しい。標準化の議論

の中で評価指標を考えるのはかなり先だと考えられるが、このような議論が国

内で進んでいることは日本としての大きなアドバンテージだと考えられる。 以上

91

第 4 回 ブロックチェーン技術を活用したシステム評価軸検討委員会 議事録

日 時：2017 年 2 月 8 日（水） 16 時～18 時 場 所：経済産業省本館 1 階西共用会議室

1). 前回議論の振り返り 事務局 ：（「資料 2 前回議論の振返りと本日の論点・進め方」の説明を行った）

2). 評価指標についてのディスカッション ２－１）論点 1：新サービス・価値を生みだす場合の検討事項

事務局 ：（「資料 3-1 評価軸の検討についての考え方」P.1～2 の説明を行った） 委員長 ：ブロックチェーン技術の特徴等を踏まえ、新サービス・価値の生みだし方とし

て、どのような類型化ができそうか。 I 委員 ：評価軸の対象外という意味はどういう意味か。JPX の例では、現状の制約に

合わせた場合に評価が困難な項目（自動化、時間短縮）が記載されていないよ

うに見受けられる。 E 委員 ：必ずしも対象外としなくとも、ユースケースの中で特殊な点を比較すればよい。

ブロックチェーン技術に適したユースケースについて、ブロックチェーン技術

の特徴を評価軸の項目にするとよい。また、ユースケース、リクワイアメント

でとらえる場合をそれぞれ分けて記載してはどうか。 I 委員 ：既存の評価軸でも十分に適用可能ではないか。ブロックチェーン技術ゆえに突

出した部分は、評価軸の中に追加すればよい。 C 委員 ：既存業務を改革する場合は評価軸による比較が可能だと考えられる。JPX の

場合は業務の一部は変わっているが、大きな意味では既存業務である。 I 委員 ：観点を示し各自で考えさせる、と切り離して示してはどうか。 事務局 ：JPX の事例にとらわれず、これまで世の中になかったような業務・システム

を生み出すユースケースも想定してもらいたい。 E 委員 ：世の中にあるものをユースケースとして取り上げ、評価軸を作成し、ブロック

チェーン技術ならではのユースケースはプラスアルファとして書けばよい。 H 委員 ：ユースケースは、ブロックチェーン技術の特性を挙げ、リファレンスブロック

を作ることで、0/1 の評価はできるだろう。 A 委員 ：ブロックチェーン技術のコアの部分とユースケースは分けるべき。miyabi の

ように外部システムの均整性を問うシステムをつくり内装できるようなシス

テムと比較することは不公平だろう。アプリケーションを対象にすべきではな

い。マイナンバー、音楽ファイルの所有権、登記簿など、これまで議論してき

たユースケースの 99%はアプリケーションの話である。 I 委員 ：サービス、ユースケースは適用可能性を探るために使えばよい。例えば、トラ

ンザクションによる保証（誰に対して守られているのか）とパフォーマンスは

92

トレードオフの関係にあるように、どの項目と項目とがトレードオフの関係に

あるかが示せるとよい。Bitcoin は速さが求められるが、ホテルの支払いであ

れば翌日にわかる程度の速さでよい。ブロックチェーン技術とアプリケーショ

ンとの切り分けは境界が不鮮明で難しいのではないか。 委員長 ：これまで世の中にないユースケースとは例えばどんなものがあるか。 A 委員 ：国家を作る場合（Bitnation）がある。また、高可用性（100%動けるシステム）

はブロックチェーン技術ならではであり、既存システムでは不可能である。 I 委員 ：ブロックチェーン技術でもネットワーク構造を破壊して認証システムを壊すこ

ともできる。ブロックチェーン技術の改ざん不要性は、100%できると言い切

ることはできないのではないか。 A 委員 ：何かを壊したら、という前提がおかしい。また、ノードが複数あることがブロ

ックチェーン技術であり、1 台しかない場合はブロックチェーン技術を活用し

たシステムとは呼ばない。 D 委員 ：ブロックチェーン技術の高可用性は、既存システムと同じくリスクを分散して

いるかに依るので、そのように組むことを評価軸に盛り込むべき。 委員長 ：高可用性については、論点 3 で議論する。Bitcoin 自体、世の中になかったユ

ースケースと捉えることができるのではないか。そのような新しいユースケー

ス以外は評価軸で評価できるだろうと考えられる。 事務局 ：B 委員がブロックチェーン技術ならではの例として前回、ウォレットを会員登

録せずに作れることを挙げている。 委員長 ：ブロックチェーン技術ならではの点として、ユーザーはいるが管理者がいない

ことも挙げられるだろう。別出しにするユースケースとして捉えたい。 ２－２）論点 2：ユースケースによる、評価軸変更の必要性について

事務局 ：（「資料 3-1 評価軸の検討についての考え方」P.3～4 の説明を行った） 委員長 ：ユースケースを軸の検討にどのように使っていくか、P.4 の 3 分野でよいだろ

うかについて検討したい。 H 委員 ：ユースケースとリクワイアメントはマトリックスの関係として書ける。 I 委員 ：「システムに必要とされる機能」を 1 列にし、トレードオフできるかどうかも

書けるとよいだろう。 D 委員 ：どの分野を抑えるか次第。それ以外は全体的に賛成である。 委員長 ：他にユースケースはあるか。 G 委員 ：スマコンを考えると何らかの加筆がいるだろう。具体的には難しいが、病院の

診療データと保険会社をつなげると保険金の給付がスムーズになるような業

種連動がある。 I 委員 ：属性の異なる業種間をつなげるか否かは管理者の判断が必要になる。 G 委員 ：難しい事例から入ると検討自体も汎用性も難しくなるので、シンプルなものの

方がよいだろう。モノの動きと支払いとを結びつける例はどうか。

93

D 委員 ：金融とほかの業界との連携は多い。例えば医療業界など。 A 委員 ：複数のチェーンをまたぐことは技術的に可能であり、ユースケースとして分け

て扱うべき。 Ethereum と別のブロックチェーンプラットフォームとが連携

することは将来的にありうること。しかもサイドチェーンではなく、プロトコ

ルに組み込まれており、それぞれのブロックに入る仕組みになる。両方のブロ

ックチェーン技術から参照し、サイドチェーンが間にないのが究極な形だろう。 委員長 ：視野として入れてもよいだろう。 F 委員 ：ユースケースごとに軸の種類が分かれるかが論点になるだろう。1 つの評価軸

でユースケースを当てはめ、網羅性チェックのために様々なユースケースを使

うという使い方をしてはどうか。 事務局 ：報告書での取り扱い方として確認したい。ユースケースを考えることで、軸の

過不足を見る。また、ユースケースの違いを勘案することで、評価軸間のトレ

ードオフを考える。という 2 つの観点でユースケースを分析した。 ２－３）論点 3：評価軸の構成概要

事務局 ：（「資料 3-1 評価軸の検討についての考え方」P.5～6 の説明を行った） 委員長 ：1 つ目が ISO/IEC2501X を、2 つ目は IPA の保守の項目を参照している。こ

こではコストについて意見をいただきたい。 I 委員 ：高可用性が高ければよいのではなく、高可用性を担保する必要がある場合、ネ

ットワークに専用線を必要とするのか、ノード数を増やすのかがコストの比較

要素になる。インターネットをコスト 0 とみなすことや、専用線のコストは

考えないとするのは問題である。ただし、ブロックチェーン技術自体の研究開

発費までは入れるべきではない。 A 委員 ：パブリック型は議論が発散しがちである。また、ネットワークの部分はブロッ

クチェーン技術そのものの話ではない。マイニングのコスト、手数料を含める

ところまで含めるべき。中央集権ではない Bitcoin は運用での人的コストはか

からない。例えば、送金システムを想定し、全てのコストを比較するのが妥当

である。 F 委員 ：使う側としては、アプリケーション開発費、基盤開発構築費、システム運用費、

業務運用費のような費目がわかるとよい。ブロックチェーン技術を使うことで

どの費目が下がるのか、ブロックチェーン技術ならではの費目があるのかがわ

かると、システムベンダーとしてわかりやすい。顧客と話す場合に、研究開発

費を入れることはない。 I 委員 ：インフラとしてパブリックなものに乗るビジネスをスコープに入れるのか。ネ

ットワークがパブリックまでは対象だが、あるパブリックに乗るという話では

ない。 B 委員 ：コンソーシアムを構築するコストは重要ではないか。中央の管理体を設定し、

加入するとシステムが使えるようになる場合、加入時にノードを何個か拠出す

94

るといった条件設定がされれば、それはコストとみなすべき。 A 委員 ：それは除くべき。既存ビジネスでも除いている。 委員長 ：コンソーシアム参加費については、軸に乗せるのではなく、補足的に扱いたい。 ２－４）業務を固定した場合の評価軸について

事務局 （「資料 3-2 評価軸案（業務を変えない場合）」の全体の説明を行った） I 委員 ：保守が、バグ修正なのか運用・マネジメントなのか。どこまでを運用・保守に

ついて整理しないか。 委員長 ：一般的なシステムとして見た場合に、ブロックチェーン技術を活用したシステ

ムゆえに注意すべきものがピックアップできないか。 E 委員 ：KPI は目標値か。 I 委員 ：最初の設計段階で高可用性・信頼性をどのレベルにし、分散ノードそれぞれに

対しコンポーネントサイズで保守運用するのか。何をどう売るのかが不明確で

ある。ブロックチェーンプラットフォームの選び方、運用体制は最初に議論す

べき。 E 委員 ：ブロックチェーン技術以外の項目もあり、違和感がある。ユーザー満足度とは

どういう意味か。 I 委員 ：システム全体の満足度であって、ブロックチェーン技術ゆえの満足度ではない。 委員長 ：前段の品質モデルと IPA とでは、レベル感が合わないということか。 委員長 ：事務局とも相談し、IPA フォーマットは一度忘れて、検討することとする。 事務局 ：（「資料 3-2 評価軸案（業務を変えない場合）」のうち、「製品品質モデル」につ

いて説明を行った） A 委員 ：スループットとレイテンシはトレードオフの関係にある。ファイナリティはセ

キュリティに入れるのではなく、別項目として入れるべき。ファイナリティが

なければスループットは早くなる。ノードの分散が多ければ、あるいは遠けれ

ば、遅くなり、両方を満たすのは難しいが、よいブロックチェーン技術を活用

したシステムであれば可能である。 I 委員 ：ユースケースで性質の対立するものを乗せた場合に、セキュリティはリクワイ

アメントとして整理することが多い。データ作るところに仕掛けがある。リク

ワイアメントを抽出するべき。一方でアクセス管理については、アカウントの

設計と守り方についても整理が必要。中項目の切り直しが必要。 A 委員 ：黄色で足りないのは、単一障害点に関する項目がない。 F 委員 ：IPA の可用性のところにある。何をリクワイアメントとするかはユースケース

にも依る。 D 委員 ：ブロックチェーン技術を活用したシステムの場合、ユーザーはすべて同じ条件

下にいる。セキュリティが、データに対してなのかユーザーに対してなのか、

分けるべき。

95

I 委員 ：アクセス権の設定、アクセスロールの設定、通信・盗聴を守る、を乗せるとセ

キュリティの話が混乱している。 A 委員 ：インターネットからアクセスするセキュリティは関係外である。アクセスコン

トロールがどうなされているか。ロールコントロールではないアクセスコント

ロールがブロックチェーン技術を活用したシステムにはある。 I 委員 ：ロールではなく、権限発行の管理など、別の言い方をすべき。 委員長 ：ISO のフレームワークをベースに評価をするのか、ブロックチェーン技術に

適したフレームワークを作るのか、議論の分かれ道である。 B 委員 ：ブロックチェーン技術とは部品であり、システム全体がブロックチェーン技術

ではない。ISO はシステム全体の評価だが、今回のスコープがブロックチェ

ーン技術の場合は当てはまらないだろう。 I 委員 ：部分的に当てはめるべきだろう。大項目レベルは合わせておくと説得力が増す。

中項目レベルでは、ブロックチェーン技術のどの要素技術で担保しているかを

アップデートすべき。 A 委員 ：ISO TC307 でブロックチェーン技術が対象とする規格が決まると考えられる。

既存の ISO の対象となっているような項目はブロックチェーン技術において

決める必要はない。 E 委員 ：パブリックベースではブロックチェーン技術を活用したシステムが満たすべき

機能の整理がある方が、ユーザー側も使いやすいはず。ISO に当てはめるか

否かは、ISO に慣れている人であればよい。 I 委員 ：この部品による最終的なシステムとはどの枠になるか。ブロックチェーン技術

を活用したシステムのリクワイアメントに関してはブロックチェーン技術ら

しい軸を出すべきだが、ブロックチェーン技術に合わせて既存の評価軸が変わ

るとは思えない。システム、情報セキュリティといったリクワイアメントは既

存の軸に合わせればよい。 F 委員 ：リクワイアメントは、ユースケースに対応するものであり、例えば、アクセス

管理を目的とするシステムであれば、アクセス制御はリクワイアメントになる。

ブロックチェーン技術とソフトウェア、ハードウェアを含めて軸があれば利用

側は使いやすい。IPA はリレーショナルデータベース（RDB）を意識して作

られていて、ファイナリティといった項目は目立たない。ファイナリティはブ

ロックチェーン技術で特徴的なので上の方に書くべき。 委員長 ：ブロックチェーン技術ならではの軸が並んだものに作り替えることにしたい。 事務局 ：当委員会では、どのプラットフォームを使うかを決めるための評価軸ではなく、

ブロックチェーン技術を使ったシステムとしての評価軸を作りたい。 F 委員 ：システムの切り方次第であり、使う側が取捨選択をすればよい。 B 委員 ：スループット、スケーラビリティに関係する。1 対 n の取引の記録を 1 個のト

ランザクションにすることもブロックチェーン技術では可能。N 対 n も、フ

ァイナリティで確定されれば N 個の取引としてカウントできる。これをスル

96

ープットということはできるのか。 A 委員 ：まとめるのはインチキになる。 F 委員 ：DB なら SQL 数だが、ブロックチェーン技術ではどうか。 A 委員 ：ブロックチェーン技術では、ファイナリティがないコンセンサス・アルゴリズ

ムは、データがくつがえるまでの時間で評価すべき。 委員長 ：いまの議論を注意書きとして書くことでも、利用者には参考になるだろう。 F 委員 ：必ずいれるべき。応答時間だけではない。 委員長 ：軸の組み方の見直しは事務局で案を再度作成してもらう。今後、メールベース

で確認いただく。あるいは個別に話を聞かせてもらいたい。注意事項等もメー

ルベースでいただきたい。 以上

97

第 5 回 ブロックチェーン技術を活用したシステム評価軸検討委員会 議事録

日 時：2017 年 3 月 2 日（水） 15 時～17 時 場 所：経済産業省本館 1 階西共用会議室

1). 前回議論の振り返り

事務局 ：（事務局より「資料 2 これまでの議論の振返りと本日の論点・進め方」の説明

を行った）

2). 報告書内容に関するディスカッション①：評価軸について

事務局 ：（「資料 3 当事業の報告書案」の 3 章の説明を行った） I 委員 ：処理について、普通のシステムは 100 万件/日といった処理能力だが、ブロッ

クチェーン技術を活用したシステムの場合は処理の範囲をどう捉えるか。ネッ

トワークとトランザクションのレイテンシは別項目で立ててはどうか。単一障

害点については、トラックナンバー（ミニマムのシステムがこけるのに最低の

数字）の比較ができるとよい。51%攻撃の問題もあり、両方記述がいる。保守

性の修正性に関する記述は、システムの不具合と運用の不具合で分けて書けば

よい。 J 委員 ：スループットとスケーラビリティの話はインターネットの黎明期も似た状況に

ある。Bitcoin ではトランザクションが多いところだけ部分的にスループット

を上げるような工夫もしている。オフチェーンの話は、長い方を正と判断させ

れば問題ない。修正可能性については、ビジネス上の取り消しとシステム上の

取り消しがある。修正可能なブロックチェーン技術は 1 つの研究対象分野で

ある。 I 委員 ：修正した記録を残すといった運用面で解決することが可能だろう。 B 委員 ：Corda はブロックを使わないブロックチェーンプラットフォームであり、む

しろ DLT である。トランザクションを投げることもないので、レイテンシや

スケーラビリティも関係ない。これらは対象になるのか。 A 委員 ：DLT も含めるのなら Corda も対象とすべき。レイテンシは、ファイナリティ

がある場合に関係がある。一方、ファイナリティがない場合は、6 シグマ

（99.9999%）以下にひっくりかえらないのであれば確定とみなす。スマート

コントラクトの Code is Law については、プログラムコードなど自然言語で

はなくても可読文字列で構成されたものであれば法的効力を持たせることは

可能と思われる。 委員長 ：技術革新が進む中で、チェーンの外側で処理するブロックチェーン技術、ブロ

ックを作らないブロックチェーン技術、投げもしないブロックチェーン技術も

出てきている中で、トレードオフの関係にないものもありうる。そこは付記し

たい。

98

J 委員 ：ファイナリティなど業界・業種特有の使い方をする用語や法律用語に絡む部分

は避けてもよいだろう。 B 委員 ：分散台帳は含むのか。 事務局 ：ブロックチェーン技術の定義を念のため確認したい。報告書の P.5（GCSA）

に当てはまるものを対象としたい。新しい技術（ブロックのないブロックチェ

ーン技術）は、今後の課題として、報告書の最後で取り上げたい。 委員長 ：海外の研究者の反応は、プライベートで使われるブロックチェーン技術を活用

したシステムを DLT と呼ぶ傾向がある。 A 委員 ：GCSA は DLT の定義があいまいである。DLT はイミュータビリティを持つこ

とが条件で、DLT にビザンチン障害耐性を持たせたものがブロックチェーン

技術を活用したシステムである。Corda は DLT だがブロックチェーン技術を

活用したシステムではない。また、ビジネス上の呼び方で DLT とブロックチ

ェーン技術を活用したシステムとを呼び分けている人もいて、明確な定義が普

及していない。 I 委員 ：ユーザー側は台帳がほしいので、台帳としてブロックチェーンを活用したシス

テムの性能が評価できればよい。広く技術を取り込みすぎると評価軸の作成の

難度があがるので、ブロックをつなげるブロックチェーン技術のみを対象とす

ればよいだろう。新しいものは現時点では対象としない。 委員長 ：新しい技術に対し影響のある項目には付記すればよい。 B 委員 ：スループット、レイテンシに影響が出てくるだろう。 委員長 ：保守運用、コストの評価項目についても意見があれば伺いたい。 C 委員 ：コストにノード数があるが、実際にシステムとやりとりするノードの範囲を明

確にすべき。 I 委員 ：既存のビジネスを変える場合はどう取り扱うのか。 事務局 ：業務を明らかに変える場合について今回は対象外としているが、業務フローが

変わる程度であれば対象とする。システムベンダーとしてのご意見を伺いたい。 G 委員 ：ブロックチェーン技術を活用したシステムは実運用されているシステムもほと

んど存在しないような黎明期の技術だと考えている。よって、まず暫定的な指

針が欲しい状況で、その目的としてはこの報告書の内容があることが非常に重

要だと考えている。まずは初版として公表し、今後随時更新していく仕組みを

持つことが重要である。 H 委員 ：検討が不十分な部分は、現段階では検討不十分と明記すればよい。 F 委員 ：使う側から見ると、今の評価軸だと一般のシステムの評価軸と違いが少ない。

それではもったいないので、ファイナリティなどブロックチェーン技術ならで

はの記載があると使いやすい。応答性能については、書き換えてほしい。 I 委員 ：一般のシステム評価軸と項目が同じでも、見方が違うことを強調するのがよい。

その上で付記の内容が変わらないようであれば、項目自体を落としても構わな

い。

99

委員長 ：表以外の記述部分で、報告書内に埋もれている箇所もあるので、表中にとりま

とめるようにしたい。 D 委員 ：確定の話を重点的にしているが、ブロックチェーン技術のもう一つの特徴とし

て、参照がある。参照に関する項目を取り込むべき。 事務局 ：ISO/IEC25010 の機能適合性の項目として、確定と参照に関する記載を行うこ

ととする。 A 委員 ：ブロックチェーン技術ならではについて、決定の時に決まるか、外部データを

取り込んだときにどうなるかは性能として整理が必要。P.18 について、PBFTは「PBFT に類するもの」修正してほしい。

3). 報告書内容に関するディスカッション②：報告書構成について

事務局 ：（「資料 3 当事業の報告書案」の構成について説明を行った） 委員長 ：2.1 1)（ブロックチェーン技術の定義について）の中でブロックチェーン

技術についてデータベース（DB）であると言い切っているが、この記載で問

題が無いかを議論したい。例えば、スマートコントラクトが対象から外れる可

能性がある。 J 委員 ：個人的にはブロックチェーン技術を DB とは捉えていない。少なくとも、RDB

（リレーショナル DB）ではなく、トランザクションのリプリゼンテーション

である。ブロックチェーン技術では口座 A から口座 B へのやりとりをパッケ

ージにして積み重ねている点が、DB とは異なる。 I 委員 ：現状では DB の置換でのブロックチェーン技術の利用を考えているので、DB

と捉えるのでよいのではないか。J 委員のいうことは、P.43 の後半に今回のフ

ォーカスで抜けた部分が記載されている欄で書くのがよい。 C 委員 ：事例を見ると、TDB（トランザクショナル DB）として捉えているものが主で

ある。 D 委員 ：分散性 DB とブロックチェーン技術の違いで、DB なのかデータストアなのか

悩む。顧客への説明では、Stored Procedure のようなデータストアと説明す

ると理解される。 H 委員 ：「基本的に DB」は言い過ぎ。いま想定している機能としては DB である、程

度に書き換えるのがよい。 A 委員 ：イミュータビリティを持っていて、どれが最新かわかる状態なので DB と捉え

ればいいと考えている。Bitcoin では、with spend というフラグがあり、必ず

ステータスがわかる。データを書き込み読める場合、書き込む場合に権限があ

り、プライベートキーさえあれば書き込み権限が持てる点に、ブロックチェー

ン技術の特徴がある。 B 委員 ：DB というと RDB を想起しがちなので、そうではないことを付記すべき。ブ

ロックチェーン技術は概念的なものであり、実装は自由。永続システム部分は

RDB 上に持たせてもよい。

100

I 委員 ：合意形成をつくるためのシステムがブロックチェーン技術上にあればよく、永

続化の部分は対象外。 委員長 ：前半の DB でありの部分に注釈をつけるか、文章そのものにデータストア等を

追記するかにしたい。

4). 報告書内容に関するディスカッション③：今後の検討の方向性について

事務局 ：（「資料 3 当事業の報告書」の 4 章（まとめ）について事務局より説明を行っ

た） I 委員 ：ビジネスルールを変える、社会のルールや国の制度を変えるなど、段階的に整

理する。Bitnation の話はさらに先の話なので唐突感がある。より近いビジネ

スの部分、社会のルールの部分を書くべき。 B 委員 ：ブロックチェーン技術を考えるにはエコシステムを俯瞰して組むことが必要で、

そうでないと活用できない。JPX はルールを変えず、ルール全体を見て一気

に作った。転記のチェックをしないで済む点に価値がある。 委員長 ：スマートコントラクトについては、どうか。 A 委員 ：スマートコントラクトはアプリケーションでありブロックチェーン技術そのも

のの話ではない。 B 委員 ：エンジニアの調達コストはシステムによって異なるので評価軸に入れる方がよ

い。Ethereum は独自技術者がいるが、Corda なら Java 取得者でも使える。 I 委員 ：見えてよいデータとそうでないデータがある。見せてはいけないデータの取り

扱い方については将来課題であり、暗号化の発展に時間がかかる。 A 委員 ：スマコンでは、テキストデータからバイナリまである。バイナリは判断する上

では読めるべきだが、読んではいけない部分でもある。その議論はだいぶ先に

なる。 D 委員 ：2～3 年はかかるだろう。暗号化以外にも、認証・認可の形はブロックチェー

ン技術に求められるだろう。

5). 今後の進め方

委員長 ：今後の展開について事務局から説明をお願いしたい。 事務局 ：今日の議論を踏まえた報告書、議事録を週明けに展開するので返信をいただき

たい。議論しきれていない内容については、その旨を明記する。またシステム

ベンダーの方には、すぐに使える書き方になっているか、書き方や使い方のイ

メージの追加要望などがあればご意見いただきたい。英語版も作成予定。 A 委員 ：委員会に出席していない読者の誤解を生じないよう、議論済みの箇所、まだ議

論しきれていない箇所とその付記について、委員間で報告書の確認を進めたい。 委員長 ：最後に経済産業省情報経済課からコメントをいただきたい。 情報経済課：この委員会ではブロックチェーン技術を PR するための材料をつくることを目

的においてきた。活発な議論をいただき、最終回を迎えて方向性が見え、安心

101

している。報告書だけでなく、概要版やリファレンスを作成するなどしたい。

評価軸は今後も改定していく予定である。国際標準の議論にも生かしたい。今

後も委員皆さまのご知見を伺いたい。 以上