1

経済産業省商務情報政策局 情報経済課 御中

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

報告書

2018 年 3 月 16 日

株式会社日本総合研究所

2

目次

1． 本調査研究の背景および目的 .............................................................................. 3

2． 分散型システムを活用したユースケースの作成・具体化および評価 ...................... 4

2.1． 分散型システムを活用したユースケースの作成および具体化 ......................... 4

システム評価の対象となるユースケースの選定 .......................................... 4 2.1.1．

システム評価の対象となるユースケースの具体化 ...................................... 22 2.1.2．

2.2． 分散型システムを活用したユースケースのシステム評価 ............................... 25

評価項目と評価方法 ................................................................................ 25 2.2.1．

システム評価結果 ................................................................................... 25 2.2.2．

3． 法制度面での課題調査....................................................................................... 36

3.1． 分野横断的な論点 ...................................................................................... 36

3.2． 個別分野における論点 ............................................................................... 46

医療・ヘルスケア分野における論点 .............................................................. 46 3.2.1．

物流・サプライチェーン、モビリティ等分野における論点 .................................... 50 3.2.2．

4． システム構築に必要となる要素技術 ................................................................... 58

4.1． ブロックチェーンの課題と解決技術 ................................................................. 58

4.2． 性能効率性 ............................................................................................... 58

4.3． 保守・運用性 .............................................................................................. 60

4.4． セキュリティ ................................................................................................ 61

4.5． スマートコントラクト ....................................................................................... 66

4.6． 用語集 ...................................................................................................... 69

5． まとめと今後の検討課題 ................................................................................... 73

5.1． システム評価軸の運用方法、ビジネス面での検討課題 ....................................... 73

5.2． 法制度面の検討課題 ................................................................................... 73

5.3． 技術面の検討課題 ...................................................................................... 74

6． （参考資料）ブロックチェーン法制度検討会について ................................................ 75

3

本調査研究の背景および目的 1．

IoT、ビッグデータ、人工知能といった破壊的イノベーションによる「第４次産業革命」とも呼ぶべ

き大変革が世界的に進みつつある状況にあって、これら技術等の発展がどのような経済・社会的イ

ンパクトをもたらすかを迅速に把握し、これに向けて国としてどのような対応を取っていくべきかを早

期に検討することが重要である。このような状況の中、ビットコイン等の仮想通貨に使用されている

ブロックチェーン技術は、その構造上、従来の集中管理型のシステムに比べ、①『改ざんが極めて

困難』であり、②『実質ゼロ・ダウンタイム』なシステムを③『安価』に構築可能という特性を持つこと

から、IoT を含む非常に幅広い分野への応用が期待されている。

上記背景を踏まえ、平成 27 年度に実施した「ブロックチェーン技術を利用したサービスに関する

国内外動向調査」（以下、「平成 27 年度調査」という。）」においては、社会に与える可能性のあるイ

ンパクトを整理するとともに、当該技術が影響を与え得る市場規模を算出し、およそ 67 兆円と見積

もっている。また、平成 28 年度には、ブロックチェーン技術の特性を正しく評価し、既存の技術・シ

ステムとの比較を可能とする評価軸の整備に関する調査を実施し、「ブロックチェーンを活用したシ

ステムの評価軸 ver1.0」（以下、「システム評価軸」という。）を策定したところである。

一方、非金融領域を含む幅広い分野でのブロックチェーンを活用したシステムの社会実装を

進めるためには、さらなる検討が必要である。まず、システム評価軸を策定したところではあるが、

評価軸に加え、ユースケースごとに変わりうる評価方法（測定方法等）を例示することで、当該評価

軸の活用を促進していくことが必要である。また、利活用が期待されているスマートコントラクトの民

事訴訟上の証拠能力の明確化など法制度面の検討の必要性が指摘されてきたところである。さら

に、我が国の強みである暗号技術等を有する大学・研究所等の学術界の活動支援の必要性が指

摘されている。

そこで、本調査研究は、以下の事項を調査・検討し、ブロックチェーンを活用したシステムの社会

実装を後押しすることを目的とする。

① 分散型システムを活用したユースケースの抽出および評価

② 法解釈の明確化、規制緩和・制度化のあり方等の法制度面での課題調査

③ システムを構築する際に必要となる要素技術の整理

4

分散型システムを活用したユースケースの作成・具体化および評価 2．

本章では、平成 28 年度にブロックチェーン技術の特性を正しく評価するための指標として策定

したシステム評価軸の利用方法を例示するために、今後社会実装が進むと考えられるユースケー

スを作成し、システム評価軸を用いて評価を行った。ユースケースの作成に際しては、ブロックチェ

ーン技術の利活用が進む分野やテーマを整理・選定した上で、当該分野において実際に運用や

検討が進んでいる事例を広範に調査し、既存事例を参考にブロックチェーンの特徴が活用された

３件のユースケースを作成し、ユースケースに必要な要件を満たすシステム構成を具体的に想定し

た。

2.1． 分散型システムを活用したユースケースの作成および具体化

システム評価の対象とする３件のユースケースの作成・具体化にあたって、ブロックチェーンの利

活用がなされている分野やテーマを整理し、システム評価の対象とするユースケースの分野を選

定した。その後、それぞれの分野に関して、海外のユースケースを含めて調査を行い、ユースケー

スを３件選定し、システム評価のための具体化を行った。

システム評価の対象となるユースケースの選定 2.1.1．

システム評価の対象となるユースケースの分野の選定 （1）

「平成 27 年度調査」では、活用が期待される有望な事例として「価値の流通・ポイント化、プラット

フォーム」、「権利証明行為の非中央集権化の実現」、「遊休資産ゼロ・高効率シェアリングの実現」、

「オープン・高効率・高信頼なサプライチェーンの実現」および「プロセス・取引の全自動化・効率化

の実現」が掲げられている。一方で、ブロックチェーンの利活用は日進月歩で進められていること

から、平成 27 年度調査を踏まえつつ、国内のユースケースを調査した。また、今後ブロックチェー

ン技術の社会実装が進むと考えられる分野を特定するため、海外のユースケースについても調査

を実施した。なお、海外のブロックチェーン技術の活用事例は、その数が多いため、海外の調査レ

ポート等を活用して、活用が多い分野を調査することとした。

5

主に活用が進められている分野（産業セクター）として、「物流・サプライチェーン」、「エネルギ

ー」、「医療・健康」、「公共」が掲げられる。また、横断的な分野（テーマ）としては、「IoT」や権利証

明等の「スマートプロパティ」などがある。

ブロックチェーン技術を用いた実証実験支援や開発研修などを行っている NTT テクノクロス社は、

ブロックチェーン技術を活用したユースケースとして、仮想通貨以外に医療や保険、サプライチェ

ーン、IoT、民泊やカーシェアといったシェアリングエコノミーなどの分野を挙げている。1

図 1 NTT テクノクロス社によるブロックチェーン技術の活用分野

ブロックチェーンに関する調査・研究を進めている三菱総合研究所は、ブロックチェーン技術のも

たらす社会インパクトと導入ステータスについて分析を行っている。2その中で社会的インパクトの

大きい分野として、公共サービスや政府、証券取引所の他に、IoT や医療・教育、サプライチェーン

などの分野を挙げている。公共サービスや政府、証券取引所、サプライチェーンの分野に関しては、

日本においても海外においても取り組まれているが、その他の医療・教育、IoT といった分野では

海外で取り組みが進むものの、国内では取り組みが進んでいないとしている。

1 出所：NTT テクノクロス”NTT TechnoCross Fair 2017 ミニセミナー講演資料ブロックチェーン活用事例”（2017 年 9

月）

<https://www.slideshare.net/ssuser70f2c8/ss-80047422> 2 出所：三菱総合研究所” MRI マンスリーレビュー2016 年 4 月号「ブロックチェーン技術の真の実力―金融分野に

とどまらないイノベーションの可能性”

<http://www.mri.co.jp/opinion/mreview/pdf/mr201604.pdf>

6

図 2 ブロックチェーンの社会インパクトと導入ステータス

bolten-consulting 社が独自に構築するブロックチェーンの活用事例のデータベースを基に調査

した結果3によれば、2017 年 10 月時点で活用が多かったのは金融分野で、25%程度であった。次

に多かったのがサプライチェーン関連の活用で、公共・エネルギーなどの分野でも活用が多い。4

図 3 bolten-consultin による海外も含めたブロックチェーン活用業種

医療・健康・介護分野については、治験データ、診療録、医薬品情報などデータが改ざんされた

3 出所： bolten-consulting” BLOCKCHAIN ASA GAME CHANGERFORSUPPLYCHAIN MANAGEMENT

ANDTRANSPORT LOGISTICS”

<https://www.decentralized.com/wp-content/uploads/2017/12/Frank-Bolten-Blockchain-in-Use_the-Most-imp

ortant-projects.pdf> 4 3 番目に多い「Enterprise」は、電子契約書や会計システムなど業務システムへのブロックチェーンの活用事例を

包含する。なお、本調査の基になっているデータベースは、同社が重要なプロジェクトと判断したものを掲載してお

り、実際にブロックチェーンが活用されている事例は、更に多いものと考えられる。

7

場合、人体や生命に危害が発生するため、ブロックチェーンの改ざん不可能という特徴が生きる分

野である。

また、物流・サプライチェーンの分野については、安全に取引がなされるためには取引にかかる

物・情報の真正性が求められ、また問題が発生した際のトレーサビリティが必要な分野であり、ブロ

ックチェーンのトレーサビリティの確保が可能という特徴が生きる分野である。

エネルギーについては、スマートメーターやスマートグリッドなど電力の情報通信化が進んでおり、

消費者間での余剰電力の直接取引などにおけるスマートコントラクトによる自動化など、オンチェー

ン上で処理できることが多く、実装が進められている分野である。

仮想通貨に代表されるようにブロックチェーンは、非中央集権であり、究極的には国家の裏づけ

を排除する可能性があるが、官民で、公的な証明サービスや政府調達等に活用しようという取組が

海外では進みつつある。

一方で、分野横断的な実装も進みつつある。IoT については、今後通信端末・トランザクションの

増大が想定されるなかで、機器間で直接通信することが求められており、そのためのアプリケーショ

ンとしてスマートコントラクトを用いることが期待されている。

また、トークンに権利や価値を記録し、権利等の所在を対外的に証明しつつ、当該トークンを

転々流通させるスマートプロパティに関する取組が進みつつある。ブロックチェーンにより、権利等

の所在の記録それ自体については改ざん不可能であることはもとより、仲介者を排除するため低コ

ストで権利等を流通させることができるためである。

なお、シェアリングエコノミーについては、上述の海外調査では、分野として掲げられていないが、

ブロックチェーンの非中央集権性が生きる分野として、諸外国においては活用がなされ始めている。

例えば、ライドシェアやカーシェア等の労働力や物のシェアリング（共有）に活用されている。ただし、

シェアリングサービスについては、ブロックチェーンの活用に向けて業法上の適法性が問題となる

ことから、我が国ではブロックチェーンの利活用が進んでいないため、その数は多くない。

以上を踏まえて、本調査研究では、システム評価の対象として、個別の産業分野として、非金融

分野で最も活用が進みつつある物流・サプライチェーン分野、データの改ざん不可能性が強く求

められる医療・健康分野を取上げる。なお、エネルギー分野に関しては、社会実装に向けて電気

事業法上等の規制緩和の必要性が指摘されていることから、後述法制度の検討において取上げ

ることとする。産業横断的なテーマとして、スマートプロパティを取上げる。IoT に関しては、今後の

活用が非常に期待されているが、システム要件は個別分野におけるユースケースに応じて異なる

ため、システム評価の対象から除外した。

8

表 1 ブロックチェーン技術の社会実装が期待される分野・テーマ

分類（注） 分野・テーマの特徴 ブロックチェーン

活用の意義 活用検討事例（一部）

活 用

が 期

待 さ

れる

分野

医療・健康

センシティブデータでありか

つ改ざんされた場合の影響

が多大

データが改ざん不

可能

治験データ管理プラットフォーム

医療機関カルテ共有システム

物流・サプライ

チェーン

多様なステークホルダーが関

与しているため、トレーサビリ

ティの確保が困難

トレーサビリティを確

保可能

食品トレーサビリティ

製造業におけるトレーサビリティ

エネルギー

固定価格買取制度の廃止等

に伴い、分散型の電力取引

の実現が期待

スマートコントラクト

による

自動執行

電力融通取引

電力チャージスタンドでの課金

公共 公証力を有する前提としてデ

ータの完全性が必要

データが改ざん不

可能

単一障害点の排除

公的 ID、登記、政府調達等のシ

ステムに活用

分野

横 断

的

テ ー

マ

IoT

通信端末・トランザクションの

増大が想定

セキュリティの確保

デバイス間での直

接取引可能

アクセス権限が改ざ

ん不可能

M to M 少額取引

IoT デバイス管理・アクセス制

御

スマートプロパ

ティ 権利やモノの流通の促進

権利のトークン化

低コストな権利管理

の実現

コンテンツの利益分配・利用許

諾管理

不動産の権利処理

データ流通プラットフォーム

シェアリングエ

コノミー

透明性の高いシェアリングの

実現

プロシューマーによ

る非中央集権的な

サービスの実現

民泊、ライドシェア、カーシェア

9

大分類 小分類 概要

医療

治験データ管理シ

ステム

治験データの登録・閲覧をネットワーク上で行うプラットフォームをブロックチェー

ンで実装する。新薬認可機関（厚生労働省）もネットワークに接続させ、薬の承認

までをブロックチェーン上で実施する想定。

医療機関カルテ共

有システム

病院の電子カルテや薬局の処方箋データなど、医療機関ごとに分散されていた

情報を、患者ユ―ザー本人が権限を与えた医療機関内で共有閲覧・書き込み可

能とすることで、適切な治療を目指すもの。

物 流 ・ サ

プライチェ

ーン

BtoC 小売のトレー

サビリティ

製品が消費者の手に渡った後も偽物製品の検知、生産者や認証の有無を確認

する。

◇ダイヤモンドや高級ワインなど、高価な商品のトレーサビリティにおいてニー

ズが高い

食の安全関連トレ

ーサビリティ

食品の安全を担保するために、小売業者や食品メーカーが食品の流通経路の

記録をつける。短時間で汚染された製品を追跡して発生源を突き止め、店頭か

ら確実に除去することを保証。

CtoC サービスのト

レーサビリティ

チケット転売のプラットフォームをブロックチェーンを用いて実装し、チケット売買

履歴をトレース可能にしたり、チケット販売時にその後の転売を禁じるシステム。

スマート宅配ボック

ス

ブロックチェーンと IoT 技術を使った宅配ボックスに荷物を納入する際に、ブロッ

クチェーン上に納入記録および施錠要求が行われる。荷物を受け取る利用者

は、個人のスマートフォンからブロックチェーン上に解錠を要求することで、宅配

ボックスが解錠され、荷物の受領が記録される。

サプライチェーン

物流需給プラットフ

ォーム

発注・出荷予定、物流では輸送実績を、事業者間で共有するプラットフォーム。

需要に基づいた物流計画、物流状況に応じた SCM 計画を実現するもの。ダイナ

ミックプライシングなどを導入し、物流発注量の計画性向上を図る工夫も検討。

携帯電話の修理に

おける契約情報処

理

携帯電話の店頭修理申し込みから完了までの工程における、リアルタイムな情

報共有およびオペレーション効率化をブロックチェーンを用いて実装する。異な

るシステム間の情報をプログラムが自動判別し最適な契約が行えるかを判定する

仕組みとする。

エ ネ ル ギ

ー 電力需給調整

電力の消費者とプロシューマー（太陽光発電など、自身で発電した電気を消費

し、余剰分は売電する生産消費者）に対し、電力を直接取引するプラットフォー

ムをブロックチェーンで実装する。

10

大分類 小分類 概要

◇類似の取り組みとして、アグリゲーターを介した節電要請と各家庭の家電を

制御する実証実験の事例もあり。

保険 保 険 金 支 払 い 査

定情報流通

傷害保険金請求書に記載の医療機関に対し、ブロックチェーンを通じて入通院

期間などの医療情報の提供を要求・受領するなど、保険会社が公的機関に情報

提供を依頼する仕組み。

IoT IoT デバイス管理・

制御

世界中の IoT 機器をセキュアに監視・管理・制御するブロックチェーンの利用を

促進する取り組みが一部で見られる M2M で 1 円未満の超小額決済（マイクロペ

イメント）などの実装も見込まれる

スマートプ

ロパティ

コンテンツの利益

分配・利用許諾管

理

著作隣接権の利益分配システムをブロックチェーン上で実現することにより、放

送やレンタルの実績に基づいて正しく利益分配されていることを、使用料の支払

者が確認する。また利用者が権利者に利用許諾を行い、これに応じて権利者は

直接ライセンス発行を行うプラットフォームも一部で研究されている（NTT 研究

所）

議決権行使システ

ム

賛否いずれかのアカウントにトークンを送付することにより株主総会の議決権等と

して投票を実施。

不 動 産 の 権 利 処

理

物件情報の一元管理に加え、閲覧権限の設定や所有権の移転情報などを、ブ

ロックチェーン技術を用いて記録する。民泊物件利用権についても権利管理を

実施。

データ流通プラット

フォーム

蓄積したデータの信頼性を維持したまま、特定の相手とだけデータ取引を可能

にするデータ共有システム。

◇損害保険会社と鑑定間で手配や鑑定の進捗状況等における情報共有をブ

ロックチェーン上で行う事例もあり。

デジタル・

ア イ デ ン

ティティ

KYC プラットフォー

ム

本人確認システム。口座開設や契約者の本人確認、ビザ、公的身分証等に関す

る本人確認をブロックチェーンを使用して行う。

転職活動における

証明書管理

証明内容を公的証明書の認定・発行機関にブロックチェーン上に書き込むよう依

頼し、ユーザーが書き込まれたデータの参照権限・期間をコントロール可能とす

る。

シェアリングサービ

ス向け本人確認サ

ービス

CtoC のマッチングや取引を行うシェアリングサービスにおいて、本人確認サービ

スを行う。

11

大分類 小分類 概要

ポ イ ン ト ・

地域通過 ポイント管理

ポイントの発行・管理を行うプラットフォームをブロックチェーンを用いて実装す

る。

◇株主優待としてポイントを発行し、これをブロックチェーン上で管理する事例

もあり。

その他 ゲーム向けクラウド

サービスの冗長化

ゲームバックエンドシステムをブロックチェーン技術を利用して実現したもの。複

数のコンピュータ（ノード）にデータを分散して稼働させるので、キャパシティを超

えても機能が停止することなく自動で遅延処理し、トランザクションの整合性も保

証される。

12

選定した個別の分野・テーマにおけるユースケース調査 （2）

将来性のあるユースケースを選定する観点から、国内の活用事例に加えて、上記において選定

した分野・テーマに関連する海外におけるユースケースを調査し、システム評価の対象となるユー

スケースを抽出した。BC 活用目的、社会的価値、将来性などを評価し、将来的に現実の実装につ

ながっていくものとなるか評価し、抽出にあたっての参考とした。なお、ユースケースの抽出にあた

っては、システム評価の際に具体的な要求要件等が必要となることから、協力が得られやすい日

本の民間事業者等が取り組んでいる、または取り組む予定のユースケースを中心に抽出する。

13

医療・健康分野におけるユースケース 1）

医療・健康情報は、改ざんされた場合に影響が甚大であるため、ブロックチェーンの活用が国

内外で進められている。主な活用分野としては、臨床データ、診療情報、ヘルスケア情報の共有を

ステークホルダー間で行っている。特に、臨床データに関しては、法規制がない場合、承認を得る

ため、治験依頼者や医療機関が改ざんを働く可能性があるインセンティブがあることから、ブロック

チェーンの活用が期待される。その他、医薬品の情報など個人情報以外の情報の共有も行われて

いる。国内外におけるユースケースの概要は、次の表の通りである。

表 2 医療・健康分野におけるブロックチェーンの社会実装が期待される分野・テーマ

ユースケース 事業者 取り組み概要

臨床データ流通

サスメド

（治験マネジメントシス

テム）

【構想段階】

- 治験データの登録・閲覧をネットワーク上で行うプラット

フォームをブロックチェーンで実装することを目指してお

り、特許を申請済み。

- 将来的にはモバイルデバイスや認可機関などもチェーンに加え、

各プロセスを革新することを想定している。5

OKEIOS

（eios.BC）

【検討・実証段階】

- 治験や医薬品の開発・製造支援を行うアイロムグループと提携

し、医療データを一元管理できるプラットフォーム「eios.BC」を開

発している。

- 「eios.BC」はブロックチェーン技術を用いて構築されており、患者

側への仮想通貨発行によるインセンティブ付与、改竄や不正アク

セスに対する高い堅牢性を特長とする。6

米 IBM

米 FDA

（FDA-IBM project）

【検討・実証段階】

- IBM は米国食品医薬品局（FDA）との研究イニシアチブを締結、

ブロックチェーン技術を使用して、安全で効率的でスケーラブル

な健康データの交換を行う。

- 臨床試験情報の他、電子医療記録、ゲノムデータ、モバイル機

5 Astabision「医学的エビデンスに基づき、スマートフォンアプリで不眠症治療を実現-サスメド株式会社 上野太郎」

（2017 年 11 月）

<http://astavision.com/contents/interview/4085>、およびサスメド株式会社へのヒアリング 6 オウケイウェイヴ「当社子会社・株式会社 OKEIOS と株式会社アイロムグループの資本・業務提携契約締結のお

知らせ」（2017 年 10 月）

<http://www.nse.or.jp/listing/search/files/140120171017492072.pdf>

14

ユースケース 事業者 取り組み概要

器、ウェアラブル、IoT 機器からの健康データなどのデータ交換を

検討する予定である。7

米 Pfizer

米 Amgen

仏 Sanofi

【構想段階】

- 製薬大手 3 社が、ブロックチェーンを利用して新薬の治験のスピ

ードアップに共同で取り組むと報じられた。

- ブロックチェーン技術を用いたシステムを用いることで、データの

断片化や、匿名性を確保した上で治験に適した患者の選定が可

能になるとしている。8

英 Greg Irving

【検討・実証段階】

- 臨床試験データの管理にブロックチェーンを活用し、安全な臨床

情報の管理に有効とする研究を実施している。9

濠 Global Cannab

【検討・実証段階】

- 医療用大麻の解禁に向け、ブロックチェーン技術を利用した臨床

試験データプラットフォーム構築に取り組んでいる。

- また関連産業へのより良い情報提供を行う仕組みを構築中であ

る。

健康記録保管と個

人管理

米 Medicalchain

【検討・実証段階】

- ブロックチェーン技術により、健康記録を安全に保管、医師、病

院、研究所、薬剤師、健康保険会社が、患者の許可を得た上で

レコードにアクセスする。

- 現在、資金調達のために ICO が開始されている。10

米

openPDS/SafeAnswers

【検討・実証段階】

- 患者がヘルスケアのメタデータ（口座番号、患者の姓名、入院日

など）を、研究機関に提供し利益を得る。

- SafeAnswers システムでは、患者は PDS の URL を使用してヘルス

7 IBM”IBM Watson Health Announces Collaboration to Study the Use of Blockchain Technology for Secure

Exchange of Healthcare Data”（2017 年 1 月）

<http://www-03.ibm.com/press/us/en/pressrelease/51394.wss> 8 Coindesk” Big Pharma Seeks DLT Solution for Drug Costs”

<https://www.coindesk.com/blockchain-day-big-pharma-seeks-dlt-solution-drug-costs/> 9 The Economist”Better with bitcoin Blockchain technology could improve the reliability of medical trials”（2016

年 5 月）

<https://www.economist.com/news/science-and-technology/21699099-blockchain-technology-could-improve-r

eliability-medical-trials-better> 10 <https://medicalchain.com/ja/>

15

ユースケース 事業者 取り組み概要

アプリへのアクセス、メタデータはすべて追跡され、記録され、患

者がその状況を確認出来る。

- アクセス制限を行うことも可能。

瑞 healthbank

【検討・実証段階】

- Healthbank は、患者のみアクセスできる安全な領域にデータを保

存可能なプラットフォームとして開発されている。

- インテリジェントな同意管理機能を使用することで、ユーザーはプ

ラットフォームを介して医療研究プロジェクト、オンライン処方箋サ

ービス、および他の商業ベンチャーに接続、データから収益を上

げることが可能。

精密医 療向けデ

ータ流通基盤

米 Health Linkages

【検討・実証段階】

- 精密医療におけるデータ分析に寄与する、データの収集・履歴

管理・暗号化に寄与するプラットフォームを提供する。

- データを効果的に構造化することで、データの質を損なわれずに

すぐ分析に利用できるようになり、最小限のデータ・キュレーショ

ンと優れた結果が得られる。

- 機関は、当事者に対する機密性を担保しつつ、分析のためにデ

ータを共有が可能に。

米 Health Wizz

（2017 年 1 月

kreateloT が買収）

【検討・実証段階】

- 個人がデジタル健康データのポートフォリオを構築、データマー

ケット内で医療研究者、健康データ科学者、製薬会社、 精密医

学に選択にデータを提供し、精密医療を進歩させるため研究に

利用させることができる。

- Ethereum のスマートコントラクトにより、暗号通貨と健康データを

交換するプラットフォームとなる。

薬品トレーサビリテ

ィ

米 Innvatemedtec

（IMT デジタル健康ア

カデミー）

【検討・実証段階】

- 医薬品製造業者、卸売業者、薬剤師、患者の間の各取引を追跡

し、模倣薬などの問題に取り組むために医薬品情報を検証する

仕組み

仏 Blockpharma

【検討・実証段階】

- ブロックチェーン技術を使い、薬物トレーサビリティと偽造薬の検

出を行う

16

ユースケース 事業者 取り組み概要

マイクロソフト、IBM、

SAP、オラクルなど

【検討・実証段階】

- 高価値医薬品などの消耗品のサプライチェーンパートナー間の

取引をすべて正確に記録し、容易に共有。

- 医薬品およびライフサイエンスのリーダーの 68％が、ブロックチェ

ーンが医薬品のサプライチェーン管理を大幅に改善し、患者の

安全性を向上させる可能性があると述べている。

物流・サプライチェーン分野 2）

前述の通り、物流・サプライチェーン分野における国内外における物流・サプライチェーン分野

のユースケースは、次の表の通りである。

表 3 物流・サプライチェーン分野におけるブロックチェーンの

社会実装が期待される分野・テーマ

ユースケースｊ 事業者 概要

物流システム効率化

セイノーホールディ

ングス

【検討段階】

- 「セイノー アクセラレーター 2017」において、総エントリー

74 社の中からテックビューロの「mijin ブロックチェーン」を採

択、実証実験の検討を開始。

- mijin ブロックチェーンは、非改ざん性とユーザー認証・暗

号化に優れたプライベート型ブロックチェーンであり、物流

システムのバックエンドとして活用されると考えられる。

- 。

セゾン情報システム

ズ

パルコ

- ブロックチェーンテクノロジーを活用した宅配ボックスと、パ

ルコが運営する WEB 通販サービス「カエルパルコ」とを連

携した実証実験を実施。

- ブロックチェーン上に納入記録および施錠要求を管理、利

用者は、個人のスマートフォンからブロックチェーン上に解

錠を要求、荷物の受領が記録される

物流シェアリング 濠 Yojee

- 中小企業あるいは個人事業主の物流事業者の荷台空きス

ペースに荷物を積み、比較的高額の報酬を提供する。

- 荷物の集荷から、途中の倉庫に荷物が到着したとき、次の

17

ユースケースｊ 事業者 概要

車両に荷物を引き渡したときなど、荷物の動きをとらえるの

にポイントごとにデータをブロックチェーンに記録し、配送を

行う。

米 OAKEN

INNOVETION

- 乗り物、貨物スペース、または車両そのものの使用を売るこ

とによって、車両所有者が資産を収益化。

- 走行経路、距離および時間、車両所有者、運転手、乗客に

関する情報を使用して、取引を確認するスマートコントラクト

を作成する。

食品トレーサビリティ

米ウォルマート、米

IBM

- ウォルマート、IBM、清華大学は、サプライチェーンに沿っ

て IoT センサーを使用して中国の豚肉を追跡したブロック

チェーンパイロットの協力を開始。

- Dole、Driscoll‘s、Golden State Foods、Kroger、McCormick

and Company、Nestlé、Tyson Foods、Walmart ともグローバ

ルサプライチェーンにて協力。

英 Provenance

- ブロックチェーン技術を使い食品の信頼性を確立する。

- 例えばインドネシアで捕獲されたマグロを認証し、日本のレ

ストランに提供することを目指している。

電通国際情報サー

ビス、Guardtime、

シビラ、宮崎県 東諸

県郡 綾町

- ブロックチェーン技術を活用して、地方創生を支援する新

たなプロジェクト「IoVB」をスタート。

- 生産管理情報をブロックチェーンで実装

NEC、AGSA、福岡

県朝倉市（生産者）

- 地域通貨を利用すること自治体のふるさと納税返礼品の生

産ボランティアへのインセンティブを用意。

- 生産・加工情報などへの適用も考えられる。

製造業サプラチェーン管

理・製品利用状況管理

KAULA

- 中国政府のバッテリー3 法（EV バッテリーの高品質化、違

法改造・放棄の防止を目的に利用者情報の記録、メーカー

の技術情報公開などを課す）を背景に、所有権・使用権の

移転の記録にブロックチェーン技術を活用する。

- さらにはバッテリーの残存価値・利用予測のブロックチェー

ン上での管理を構想。

独 Innogy - フォルクスワーゲン・ファイナンシャル・サービシズと

18

ユースケースｊ 事業者 概要

BigchainDB と協力して、車両の利用履歴管理するプラット

フォームを構築。

- サービスセンターは摩耗する前に部品を交換することがで

きるため、自動車はより安全になる。

- 自動車がどこでどのように使われたかを追跡するテレマティ

クスデータが組み込まれており、消費者は、その履歴に基

づいて、いつでも車の再販価値を予測。

日立製作所

- サプライチェーン分野でのブロックチェーン技術の活用促

進に向けて、トレーサビリティ管理システムのプロトタイプを

開発。自動車メーカーと部品メーカーを結ぶサプライチェ

ーンで、製品販売、部品や材料調達などの情報をブロック

チェーン技術で管理する。

米 Wipro

（SIer）

- ブロックチェーンを用いたサプライチェーンの可視化、追跡

に関するソリューションを提供している。

- 特に航空分野における部品サプライヤーの品質証明取得

（耐空性証明書類）を対象としたソリューションでは、部品の

ライフサイクルを追跡、スマートコントラクトによって、不良部

品の保守と修理を容易にする。

- バーコード/ QR コードの出荷トランザクションを用いる。

- 他に偽造防止、3D プリンター向けのソリューション等。

スマートプロパティ 3）

スマートプロパティに関する国内外のユースケースは、知的財産などの無形資産、動産や不動

産などの有体物に関する権利の証明などがある。公開情報ベースでは、国内におけるトークンによ

る権利・価値証明や移転に関するユースケースは少ないが、ヒアリングを行うなかで、トークンの活

用を検討していると回答する事業者は多かった。以下では、スマートプロパティに関するユースケ

ースを示す。

表 4 スマートプロバティ分野におけるブロックチェーンの社会実装が期待される分野・テーマ

ユースケース 事業者 概要

知財管理 米 Binded - 著作権・知財の恒久的な記録作成を実現するためブロックチ

ェーンを使う公開データベース上に著作権の恒久的な記録を

19

ユースケース 事業者 概要

作るサービスを開発している。

- 例えば写真家等が自分の知財を容易に保護できるようにす

る。

- 朝日新聞などから資金調達

独 Bernstein

- 発明、デザイン、使用証明はすぐに登録することができ、ブロ

ックチェーン証明書はあらゆる IP資産の所有権、存在、および

完全性を証明する。

西 Stampery

- Bitcoin のブロックチェーンを使用して、機密文書等に対して

法的証明（公証）を生成する検証および認証プラットフォー

ム。 （機密文書の場合はトークンのみを保持）

- ファイルや通信の完全性、存在、所有権、および領収書を証

明し、デジタルトランザクションを認証して監査証跡を生成し、

知的財産を保護し、デジタル資産の所有権を証明するために

使用可能。

（学術雑誌） Ledger

- 学術ジャーナルの Ledger では、内部の編集者が投稿論文

のレビュー進捗状況や公開日時などをブロックチェーンに記

録している、

筑波大学システム情

報工学研究科

- 存在証明ツール「Proof of Existence」を利用し、折り紙の折り

図の著作権保護を行う研究を行っている。

動産の権利処理 英 Everledger

- 価値のある商品を追跡および保護するためのデジタル、グロ

ーバル元帳を目指す。生涯にわたり高価値品の出所を不変

的に追跡し、顧客やこれらの資産を追跡したい他のステーク

ホルダーに情報を提供する。

- ダイヤモンド鑑定・所有者・保険情報の管理などを行うサービ

スを提供している。

濠 Bitcar

- Lamborghinis、Ferraris、Bugattis などの高級車の分数所有を

可能にし、ユーザーは暗号化を「BITCAR トークン」に格納す

ることができ、分散型ブロックチェーンプラットフォームで取引

スマートコントラクトによ

る不動産投資市場構米 Propy

- グローバルでの分散不動産市場をブロックチェーン上に構

築。バイヤー、売り手、ブローカー、エスクロー、所有者、公証

20

ユースケース 事業者 概要

築 人間の契約をスマートコントラクトにて実現。

- 海外不動産への投資は事務作業が膨大であった。

- 2020 年 7 月から Propy のプラットフォームを利用して、個人間

の国際不動産取引を可能にすることを目指す。

独 BrickBlock

- ブロックチェーン上に取引プラットフォームを構築、不動産や

ETF などの資産管理を検討。（ICO 実施）

- スマートコントラクトを使用し、資産担保型トークン（ POA

Token）による仮想通貨の換金を行うことで、法定通貨為替手

数料を排除する仕組み。

- 投資対象は専門家によって入念に審査され、またリスクに応じ

てランク付けされる。

米 ALANT

- 個々の不動産シェアを示すトークンをリスト化し、流動性のある

市場取引、仲介者不要の P2P 賃貸サービス（民泊サービスの

代替）の実現を検討。（ICO 実施）

- レビューと物件リストの真正性の担保も行う。

不動産情報管理（所有

権、利用履歴など）

カイカ

AMBITION

LIFULL

テックビューロ

- 空き家情報、修繕・リフォーム履歴、住宅評価情報、広告履歴

など、官民のデータベースに散在する不動産情報をブロック

チェーンに集約する実証実験を実施。

- 実証実験で、不動産賃貸権利の発行・流通・譲渡がブロック

チェーン上で管理できることを確認。

- 電子化された契約手続きおよび情報の保持、契約金および

- 家賃の仮想通貨決済が有用であると判断。

積水ハウス

bitFlyer

- プライベートブロックチェーン技術「miyabi」による賃貸住宅の

入居契約等の情報管理システムを検討

シノケン

チェーントープ

- 民泊物件におけるブロックチェーンを活用したサービス開発を

開始している。独自通貨も発行。

システム評価の対象とするユースケース 4）

医療等の分野においては、治験における不正改ざん防止、治験マネジメントシステム（サスメド

株式会社）および物流・サプライチェーンの分野に関しては、モビリティ業界や太陽光発電業界に

おける新市場の立ち上げにも寄与する EV バッテリーライフサイクル管理プラットフォームを取上げ

ることとする。また、スマートプロパティに関しては、汎用的なプラットフォームとして様々な権利・価

21

値を記録・流通させうる可能性を有することに鑑み、諸外国や国内でのユースケースを参考に、当

社にてユースケースの作成を行った。

22

システム評価の対象となるユースケースの具体化 2.1.2．

選定したユースケースに関してヒアリングおよび追加調査等により、具体化を行った。以下では、

各ユースケース11の詳細を説明する。

治験データ管理プラットフォームの具体化 （1）

治験は、製薬企業が医療機関に対して依頼が行われ、医療機関が治験を実施する。治験の進

捗管理は、書類の整備や実地でのモニタリングなど非常に労働集約的になされるため、近年、製

薬企業側は、CRO（Contract Research Organization：医薬品開発受託機関）と呼ばれる企業に治

験のマネジメントを委託している。一方で、医療機関側においても、SMO（Site Management

Organization：治験施設支援機関）と呼ばれる治験の実施を支援する企業に委託すること多くなっ

てきた。治験は、長期間にわたり実施され、書類の整備や実地でのモニタリングなど医療機関側、

製薬企業側双方にとって時間・コストがかかる構造となっており、治験の実施結果に対して結果を

改ざんする誘因が存在する12。

そこで、ブロックチェーンに治験の実施結果やモニタリングの内容を記録し、医療機関、SMO、

CRO が共有することで監視が働くとともに、データの改ざんが防げることが期待される。

図 2 治験データ管理プラットフォームのサービスモデル

11 「治験データ管理プラットフォーム」はサスメド株式会社に、「EV バッテリーライフサイクル管理プラットフォーム」は、

カウラ株式会社にユースケースをご提供いただいた。ユースケースの作成、システム評価の段階で、ヒアリングやデ

ィスカッションを幾度もさせていただいたことを、この場を借りて御礼申し上げる。 12 加えて日本においては、SMO 及び CRO が同一の企業グループとなっている場合があり、実質的な利益相反構

造が存在するとの指摘がある。

製薬会社 CRO（医薬品開発受託機関）

医療機関・臨床試験センター

認証機関（PMDA）

⑧承認申請

①業務委託

⑦治験実施結果の報告

SMO（治験施設支援機関）

各種業務支援

IRB（施設内審査委員会）

⑨認可

②治験の依頼、④実地モニタリング

⑤臨床データの提供

利益相反者が多数介在する構造⇒不正防止、信頼性確保のための業務履行にコストがかかる

⇒コストは薬価に転嫁され医療費が増大する

倫理的・科学的妥当性の評価

現状の治験データ流通プロセス

医療機関・SMO

製薬会社

認証機関（PMDA）

製薬会社

CRO（医薬品開発受託機関）

ブロックチェーンを活用した治験データ流通システム

ステークホルダー間で記録を確認することで抑止機能が働く治験データの改ざんが技術的に防止可能となる

③治験の実施

ブロックチェーンによる治験データの共有

23

EV バッテリー管理プラットフォームの具体化 （2）

2020年～2025年にかけて使用済み自動車（ELV） が増加すると予測されている。日本自動車

工業会の推計13によれば、2025年には約50万台の使用済み自動車が出回ると予測している。また、

年間の約 30 万台（2016 年）14と日本の 15 倍程度の中国においては、更に多くの廃バッテリーが出

回ることになる。

一方で、電池容量の保証期限を迎えた EV やメーカー保証による電池交換等で発生する電池

をリユースするビジネスモデルが検討されている。EV のバッテリーは通常、残存価値15が 6 割から 7

割程度になると交換される。一般に、EV のバッテリーは、モジュールと呼ばれる電池が数十個組み

合わされたものになる。太陽光発電システムの蓄電池など他の用途であれば、残存価値が少なく

ても十分に機能するため、モジュールを取り出し、組み替えることで再利用が可能となる。

ただし、再利用にあたっては、バッテリーの残存価値が同程度となるモジュールを組み合わせる

ことが必要である。また、現在は EV メーカーが自主回収しているが、今後大量に廃電池が出回る

ため、回収事業者等が回収を行うことも考えられる。その際に、回収事業者側で、あらかじめバッテ

リーの残存価値が分かっていれば、自動車の保有者、回収事業者ともに、効率的にバッテリーを

回収することができる。このとき、バッテリーの残存価値が正確に把握され、かつ改ざん不可能な形

で伝達できれば、廃バッテリーの流通市場は、円滑になるだろう。

ブロックチェーンを活用し、バッテリーの残存価値、所有者、日時、環境データ等を記録し、共有

することで、バッテリーの二次利用市場を立ち上げることが可能となるとともに、太陽光発電の蓄電

システムなど様々な市場にインパクトを与えると考えられる。

なお、EV が急激に普及している中国では、法令によりトレーサビリティの確保としての特徴も活

かすことが可能である。

13 一般社団法人日本自動車工業会「次世代車の適正処理・再資源化及び新冷媒の取組み状況」産構審・中環審

第 45 回合同会議資料 14 International Energy Agency「Global EV Outlook 2017」 15 残存価値とは、バッテリーの劣化状態を表す値をいい、以下の数値で表される。：

SoC（State of Charge）= 初期満充電容量（Ah） / 残容量

SoH（State of Health）= 劣化時満充電容量（Ah）/初期満充電容量（Ah）

24

図 3 EV バッテリー管理プラットフォームのサービスモデル

スマートトークンプラットフォームの具体化 （3）

大都市圏や政府の補助を受けた地域において、リアルデータを活用したスマートシティ開発が

進められている。例えば、高松市では水位センサーや潮位センサー等を河川や護岸に設置し、デ

ータを IoT プラットフォーム上に収集・解析することで、早期の災害対策を実現するという実証実験

を実施している。その他の先進的な自治体、地域においても IoT を活用した街づくりが進められて

いる。

一方で、日本全国に普及させようとした場合、自治体および民間事業者側の財政面への課題が

存在する。スマートシティ開発や IoT の地域での実装にあたって、自治体等による初期コストの負

担が問題となり、新たな資金調達のスキームを検討する必要がある。

そこで、ブロックチェーンを活用することで、プロジェクトオーナーは各デバイス設置の初期投資

（=初期トークン総額）を迅速に調達可能となり、補助金等に頼らないスマートシティ開発の実現が

期待される。16

16 EV チャージステーションを地域住民で設置し、トークンの保有割合に応じて、EV チャージステーションの利用権

や利用料収入を得るといった活用の仕方も想定される。

EV完成車メーカー

EVの販売

EV所有者・利用者

回収・解体事業者中古車販売事業者

バッテリー回収

EVの普及に伴い使用済みバッテリーが大量に発生再利用に必要なバッテリーの残存価値データを適正に

把握・共有する仕組みが存在しない

あらかじめ適正な残存価値が把握できるため、バッテリーの回収・買取プロセスが効率化

現状のEVのバッテリー二次利用市場

個人

バッテリー残存価値共有システム

加工・再販事業者

EV完成車メーカー EV所有者・利用者

回収・解体事業者中古車販売事業者 加工・再販事業者

①バッテリーの残存価値を測定

ブロックチェーンで共有

②残存価値データに基づき、バッテリーを選別・回収

③残存価値データに基づき、バッテリーを買取

残存価値が同等なバッテリーを組み替えて、販売

太陽光発電システム等向け蓄電池の販売バッテリー組替え

EVの販売

25

図 4 スマートトークンプラットフォームのサービスモデル

2.2． 分散型システムを活用したユースケースのシステム評価

評価項目と評価方法 2.2.1．

本評価では、2.4の３つのユースケースを対象にして、平成２８年度「ブロックチェーン

技術を活用したシステムの評価軸 ver1.0」から作成したシステム評価項目で机上評価を行

った。具体的には、各ユースケースのシステム構成を検討し、システム評価軸の項目をも

とに各ユースケースのシステム実装における要件を想定し、システム評価項目として策定

した。策定した評価項目をもとに机上で評価を実施した。

システム評価結果 2.2.2．

治験データ管理プラットフォームの評価 （1）

治験データ管理のユースケースをブロックチェーンで実装する場合のシステム構成例を以下に

示す。

プロジェクト提案者

④デバイス購入・設置

個人投資家

①プロジェクト提案＋

トークン発行

②仮想通貨による支払

・プロジェクト目的・設置デバイス一覧（種類、設置場所、生成データ）・データ購入予定者・潜在データ購入顧客・プロジェクト予算（=初期トークン総額）（プランナーが値付け）

センサーデバイスA

データ購入者デバイス利用者

Aトークン：30

③予算確保

Aトークン：20 Aトークン：50

トークン2次流通

共同所有

⑥データ対価支払い・分配

⑤データ収集

Aトークン：100

スマートシティ開発を予定している自治体や企業住民など個人

アプリケーション事業者、データ解析事業者等

トークンを発行することで資金調達が容易になる。

トークンの発行による資金調達

26

図 5 治験データ管理プラットフォームのシステム構成例

本システムは、治験実機計画に沿って各種治験データを登録・参照・管理するブロックチェーン

システムである。治験に関わる各社で台帳を管理するコンソーシアム型のブロックチェーン構成とし、

機密性の高い臨床データを扱うため、閉域網を使用する IP-VPN で各社のネットワークを繋ぐ構成

とする。

システム構成をもとに机上評価した結果を以下に示す。

表 2 治験データ管理プラットフォームのシステム評価結果

評価項目 （机上）評価結果

品質 性能効率性

処理性能 年平均 600 件の治験に関する臨床 データの登録が可能であること

Hyperledger Fabric のベンチマーク結果(参考資料 3-1)から秒間千件以上のスループットの実現は可能。

ネットワーク性能

BC サーバ間のネットワーク性能がボトルネックとならない十分な帯域を確保すること

性能評価を行い、十分な帯域が確保できるIP-VPN サービスを使用する。

ブロック確定性能

30 秒以内に確定した登録データが参照可能であること

Hyperledger Fabric ではブロック生成期間（トランザクション発生後の何秒以内に新規ブロックを生成するのか）の設定が可能であるため、実現は 可能。（生成期間のデフォルト値は 2 秒）

参照性能 従来の Web システムと同程度の応答時間であること

BC ノードを DB と捉えることで従来の Web・AP・DB システムと同じ参照性能があると想定することが可能。 ただし、データ参照時には複数の BC ノードか

27

評価項目 （机上）評価結果

らデータを読み取り検証する必要がるため、その分参照性能が落ちることを考慮する必要がある。

相互運用性

相互運用性 (既存システム)

HPKI 等の電子証明書基盤との連携が可能であること

公開鍵証明書をサーバに配ることで連携可能。

相互運用性 (他ブロックチェ

ーン)

本システムでは他のブロックチェーンシステムとの連携は必要ではない

―

拡張性 処理性能向上性

ノード追加が可能であること 製薬会社毎にブロックチェーンネットワークを形成することで、拡張可能。１つのネットワーク内の最大ノード数は性能評価で確定させる必要がある。 （複数ネットワークに参加する PDMA、医療機関のノードの処理性能がボトルネックになる可能性があるため、サーバのスペックについて考慮が必要）

ネットワーク性能

向上性

容量拡張性

ノード数拡張性

信頼性 成熟性 ブロックチェーン基盤ソフトウェアで使用されている暗号技術が実績のある技術であること

Hyperledger Fabric でサポートされている鍵暗号アルゴリズムは、ESDCA（楕円曲線暗号、Bit数 256/384）であり、電子政府推奨暗号の 1 つである。

可用性 参加会社のシステム障害でサービス停止しないこと

Hyperledger Fabric では、事前設定する承認ポリシーを満たすことが可能なノードが稼動している限りはサービス停止しない。 本システムにおける例として PDMA、製薬会社もしくは CRO、医療機関もしくは SMO の 3 つから承認を得ることを承認ポリシーと設定した場合には PDMA のノードを二重化することで、単一ノード障害でサービス停止することはない。

障害許容性 サービス停止となる障害ノード数に単一障害で達することがないこと

Hyperledger Fabric の承認ポリシー設定に依存するが、PDMA、製薬会社もしくは CRO、医療機関もしくは SMO の 3 つから承認を得ることを承認ポリシーと設定した場合には PDMA のノードを二重化することで、単一ノード障害でサービス停止することはない。

回復性 BC ノード障害後にサービス停止せずに 復旧可能であること

Hyperledger Fabric では、障害ノードを再起動することで 復旧可能。障害時のデータも同期が取られる。

セキュリティ

機密性 データの秘匿化が可能であること （本システムの要件ではない）

データのハッシュ化、および、暗号化することで秘匿可能。 ただし、ハッシュ化の場合は、別途、関係者間で元データの共有が必要。 暗号化の場合は、別途、関係者間で復号鍵の共有が必要。

インテグリティ メンバーシップ管理機能を有していること

Hyperledger Fabric では、コントラクト管理者と利用者を分けて管理可能。

否認防止性 事象又は行為が後になって否認されることがないよう、事象又は行為が引き起こされたことが証明できること

本システムでは、信頼のおける医師により自らの電子署名とともに登録される臨床データを改ざん困難なブロックチェーンに格納することで否認防止性・真正性を確保する。 Hyperledger Fabric では、承認者の署名が付いたデータを全ノードで共有するため改ざんが困難。 （改ざんするには、全承認者の署名を取る必要がある）

真正性 データの正しさを証明できること

移植性 適応性 標準的な OS を用いたシステムとすること

一般的な Linux OS を用いたシステムであるため、適応性あり。

置換性 他のブロックチェーン基盤ソフトウェアに置換可能であること

現時点ではブロックチェーン基盤の標準が存在しないため、置換性を担保することは不可である。

保守・運用

保守・運用性

モジュール性 システムの構成要素がモジュール化されていること

Hyperledger Fabric では、コンセンサス方式はモジュール化されており、変更可能である。

28

評価項目 （机上）評価結果

性 再利用性 システムの構成要素が他のシステムで再利用可能であること

ブロックチェーン基盤ソフトウェア以外の UI 等は再利用の可能性がある。

解析性 障害発生時にどのノードで何があったのかが分かること

各ノードのブロックチェーン基盤ソフトウェアのログ、および、コントラクトコードのログで解析可能。

修正性 サービスを止めずにシステムの修正が可能であること

Hyperledger Fabric では、サービス稼動中にコントラクトコードの修正が可能。 ただし、コントラクトコードの修正の際には参加者の合意・了承を得る必要がある。

試験性 サービス開始前にテスト可能であること

サービス開始前にシステムテストだけではなく、十分な試行を実施する必要がある。

コスト 研究開発 ブロックチェーン基盤

コストが明確になること 既存のブロックチェーン基盤ソフトウェアを使用することで新規研究開発費を極小化。

サブシステム

実装 ハードウェア 各参加組織で BC サーバ、BC 呼出システムの構築費を負担。 ソフトウェア

システム実装

保守・運用 運用 各参加組織で IP-VPNサービス利用料を負担。

保守 各参加組織で自社の BC サーバの保守費を負担。

[参考資料 3-1] IBM「Hyperledger Fabric: A Distributed Operating System for Permissioned

Blockchains」 (https://arxiv.org/pdf/1801.10228v1.pdf)

品質 1）

性能においては、年間 600 件の治験を管理するためには、1件の治験あたり 100名の治験参

加者が 3 ヶ月に 1 回臨床データを採取・登録することを仮定した場合には、約 670 件/日のデ

ータ登録処理性能が必要となる。この場合は、秒間数千件以上のベンチマーク結果を持つ

Hyperledger Fabric で十分に満たすことが可能である。

拡張性においては、本システムでは製薬会社毎にブロックチェーンネットワークを形成するこ

とで拡張していくことが可能である。その際には、1 つのネットワーク内の最大ノード数や複数ネ

ットワークに参加する PDMA、医療機関のノードの処理性能を、性能評価をもとに検討する必

要がある。

信頼性の可用性を向上させるためには、Hyperledger Fabric の承認ポリシー設定を適切に設

定し、必要なノードを冗長化することが必要である。本システムにおいては、PDMA、製薬会社

もしくは CRO、医療機関もしくは SMO の 3 つから承認を得ることを承認ポリシーと設定すると、

PDMA のノードを二重化することで、単一ノード障害でサービスが停止することをなくすことが

可能である。

セキュリティのデータ秘匿化については、本システムでは必須要件ではないが、必要に応じ

てアプリケーションの実装にてデータのハッシュ化、暗号化することにより対応可能である。た

だし、ハッシュ化の場合は別途、関係者間で元データの共有が必要である。また、暗号化の場

29

合は別途、関係者間で復号鍵の共有が必要となる。

保守・運用性 2）

ブロックチェーンシステムの保守・運用性においてはサービスを止めないで運用を続けること

が重要である。従来のシステムにおいては、サービス利用の少ない時間帯に閉塞を行い、ア

プリケーションの修正を行うことが一般的であるが、ブロックチェーンシステムにおいては各組

織が分散して運用しているノードを一斉に閉塞かけることは非常に困難なためである。この点

を考慮した場合、ブロックチェーンシステムにおいてはサービスを停止せずにアプリケーション

となるコントラクトコードの修正が可能であることが望ましい。Hyperledger Fabric では、サービス

稼動中にコントラクトコードの修正が可能であるため、コード修正に伴うサービス停止は無い。

ただし、コントラクトコードの修正の際には、ブロックチェーン参加者の合意・了承を得ることも

検討が必要である。

コスト 3）

ブロックチェーンシステムにおいては、分散してシステム運用を行うため、各社のサーバ構築、

運用、保守のコストを各社が負担する必要がある。また、本システムにおいては IP-VPN サービ

スの利用料も各社で負担する必要がある。

30

EV バッテリー管理プラットフォームの評価 （2）

EV バッテリー管理のユースケースをブロックチェーンで実装する場合のシステム構成例を以下に

示す。

図 6 EV バッテリー管理プラットフォームのシステム構成例

本システムは、各 EV からのデータを収集する IoT エッジサーバから各車のバッテリー残存価値デ

ータを登録し、関係各社でリアルタイムにデータ参照が可能なブロックチェーンシステムである。

IoT エッジサーバ側とデータを参照する各社で台帳を管理するコンソーシアム型のブロックチェー

ン構成とし、比較的安価に構築可能なインターネット VPN で各社のネットワークを繋ぐ構成とする。

システム構成をもとに机上評価した結果を以下に示す。

表 3 EV バッテリー管理プラットフォームのシステム評価結果

評価項目 （机上）評価結果

品質 性能効率性

処理性能 10 万台の電気自動車から 1 日1KB の残存価値データの登録が可能であること （1.16 件/秒）

Hyperledger Fabric のベンチマーク結果(参考資料 3-1)から秒間千件以上のスループットの実現は可能。

ネットワーク性能

BC サーバ間のネットワーク性能がボトルネックとならない十分な帯域を確保すること

性能評価を行い、十分な帯域が確保できるインターネット VPN サービスを使用する。

ブロック確定性能

30 秒以内に確定した登録データが参照可能であること

Hyperledger Fabric ではブロック生成期間（トランザクション発生後の何秒以内に新規ブロックを生成するのか）の設定が可能であるため、実現は 可能。（生成期間のデフォルト値は 2 秒）

31

評価項目 （机上）評価結果

参照性能 従来の Web システムと同程度の応答時間であること

BC ノードを DB と捉えることで従来の Web・AP・DB システムと同じ参照性能があると想定することが可能。 ただし、データ参照時には複数の BC ノードからデータを読み取り検証する必要がるため、その分参照性能が落ちることを考慮する必要がある。

相互運用性

相互運用性 (既存システム)

IoT エッジサーバとの連携が可能であること

エッジサーバがブロックチェーンのクライアントとなり、データを登録することで連携可能。

相互運用性 (他ブロックチェ

ーン)

本システムでは他のブロックチェーンシステムとの連携は必要ではない

―

拡張性 処理性能向上性

ノード追加が可能であること EV メーカー毎にブロックチェーンネットワークを形成することで、拡張可能。１つのネットワーク内の最大ノード数は性能評価で確定させる必要がある。 （複数ネットワークに参加するノードの処理性能がボトルネックになる可能性があるため、サーバのスペックについて考慮が必要）

ネットワーク性能

向上性

容量拡張性

ノード数拡張性

信頼性 成熟性 ブロックチェーン基盤ソフトウェアで使用されている暗号技術が実績のある技術であること

Hyperledger Fabric でサポートされている鍵暗号アルゴリズムは、ESDCA（楕円曲線暗号、Bit数 256/384）であり、電子政府推奨暗号の 1 つである。

可用性 参加会社のシステム障害でサービス停止しないこと

Hyperledger Fabric では、事前設定する承認ポリシーを満たすことが可能なノードが稼動している限りはサービス停止しない。 本システムにおける例として 3 社以上の承認を得ることを承認ポリシーと設定した場合には単一ノード障害でサービス停止することはない。

障害許容性 サービス停止となる障害ノード数に単一障害で達することがないこと

Hyperledger Fabric の承認ポリシー設定に依存するが、3 社以上の承認を得ることを承認ポリシーと設定した場合には単一ノード障害でサービス停止することはない。

回復性 BC ノード障害後にサービス停止せずに 復旧可能であること

Hyperledger Fabric では、障害ノードを再起動することで 復旧可能。障害時のデータも同期が取られる。

セキュリティ

機密性 データの秘匿化が可能であること （本システムの要件ではない）

データのハッシュ化、および、暗号化することで秘匿可能。 ただし、ハッシュ化の場合は、別途、関係者間で元データの共有が必要。 暗号化の場合は、別途、関係者間で復号鍵の共有が必要。

インテグリティ メンバーシップ管理機能を有していること

Hyperledger Fabric では、コントラクト管理者と利用者を分けて管理可能。

否認防止性 事象又は行為が後になって否認されることがないよう、事象又は行為が引き起こされたことが証明できること

本システムでは、各車の電子署名とともに IoTエッジサーバを経由して登録される残存価値データを改ざん困難なブロックチェーンに格納することで否認防止性・真正性を確保する。 Hyperledger Fabric では、承認者の署名が付いたデータを全ノードで共有するため改ざんが困難。 （改ざんするには、全承認者の署名を取る必要がある）

真正性 データの正しさを証明できること

移植性 適応性 標準的な OS を用いたシステムとすること

一般的な Linux OS を用いたシステムであるため、適応性あり。

置換性 他のブロックチェーン基盤ソフトウェアに置換可能であること

現時点ではブロックチェーン基盤の標準が存在しないため、置換性を担保することは不可である。

保守・運用

保守・運用性

モジュール性 システムの構成要素がモジュール化されていること

Hyperledger Fabric では、コンセンサス方式はモジュール化されており、変更可能である。

32

評価項目 （机上）評価結果

性 再利用性 システムの構成要素が他のシステムで再利用可能であること

ブロックチェーン基盤ソフトウェア以外の UI 等は再利用の可能性がある。

解析性 障害発生時にどのノードで何があったのかが分かること

各ノードのブロックチェーン基盤ソフトウェアのログ、および、コントラクトコードのログで解析可能。

修正性 サービスを止めずにシステムの修正が可能であること

Hyperledger Fabric では、サービス稼動中にコントラクトコードの修正が可能。 ただし、コントラクトコードの修正の際には参加者の合意・了承を得る必要がある。

試験性 サービス開始前にテスト可能であること

サービス開始前にシステムテストだけではなく、十分な試行を実施する必要がある。

コスト 研究開発 ブロックチェーン基盤

コストが明確になること 既存のブロックチェーン基盤ソフトウェアを使用することで新規研究開発費を極小化。

サブシステム

実装 ハードウェア 各参加組織で BC サーバ、BC 呼出システムの構築費を負担。 ソフトウェア

システム実装

保守・運用 運用 各参加組織でインターネット VPN サービス利用料を負担。

保守 各参加組織で自社の BC サーバの保守費を負担。

品質 1）

性能においては、10 万台の電気自動車から 1 日 1 回(1KB)の残存価値データの登録が可能

な処理性能を必要とする。この場合、秒間数千件以上のベンチマーク結果を持つ

Hyperledger Fabric で十分に満たすことが可能である。

拡張性においては、本システムでは EV メーカー毎にブロックチェーンネットワークを形成す

ることで拡張していくことが可能である。その際には、1 つのネットワーク内の最大ノード数や複

数ネットワークに参加するノードの処理性能を、性能評価をもとに検討する必要がある。

信頼性の可用性を向上させるためには、Hyperledger Fabric の承認ポリシー設定を適切に設

定し、必要なノードを冗長化することが必要である。本システムにおいては、3 社以上の承認を

得ることを承認ポリシーと設定すると、単一ノード障害でサービスが停止することをなくすことが

可能である。

保守・運用性 2）

3.1 と同様にサービスを止めないアプリケーション修正が必要であり、Hyperledger Fabric で

は実現可能である。

コスト 3）

ブロックチェーンシステムにおいては、分散してシステム運用を行うため、各社のサーバ構築、

運用、保守のコストを各社が負担する必要がある。また、本システムにおいてはインターネット

VPN サービスの利用料も各社で負担する必要がある。

33

スマートトークンプラットフォームの評価 （3）

スマートトークンのユースケースをブロックチェーンで実装する場合のシステム構成例を以下に示

す。

図 7 スマートトークンプラットフォームのシステム構成例

本システムは、プロジェクト提案者が個人投資家から資金調達を行うためのトークン管理ブロック

チェーンシステムである。運用中のパブリック型ブロックチェーン上にコントラクトコードとなるアプリ

ケーションを配置する構成とする。

システム構成をもとに机上評価した結果を以下に示す。

表 4 スマートトークンプラットフォームのシステム評価結果

評価項目 （机上）評価結果

品質 性能効率性

処理性能 bitcoin の最大スループットである秒間 7 件の処理性能があること

Ethereum の本番ネットワークでは bitcoin 以上のトランザクション数を処理できているため、実現は可能。

ネットワーク性能

BC サーバ間のネットワーク性能がボトルネックとならない十分な帯域を確保すること

既存の Ethereum 本番ネットワークに依存する。

ブロック確定性能

30 秒以内に確定した登録データが参照可能であること

Ethereum のコンセンサス方式は bitcoin と同じPoW(Proof of Work)であるため、同程度の確定性能は実現可能。（ただし、ブロック生成間隔は平均 15 秒であり、bitcoin の 10 分と比較して短いが、何ブロックをもって確定とみなすかは取引者間で決める必要がある）

参照性能 従来の Web システムと同程度の応答時間であること

BC ノードを DB と捉えることで従来の Web・AP・DB システムと同じ参照性能があると想定するこ

34

評価項目 （机上）評価結果

とが可能。 ただし、データ参照時には複数の BC ノードからデータを読み取り検証する必要がるため、その分参照性能が落ちることを考慮する必要がある。

相互運用性

相互運用性 (既存システム)

IoT との連携が可能であること IoT 基盤が Ethereum のクライアントとなり、データを登録することで連携可能。

相互運用性 (他ブロックチェ

ーン)

本システムでは他のブロックチェーンシステムとの連携は必要ではない

―

拡張性 処理性能向上性

ノード追加が可能であること 仮想通貨として運用されている Ethereum 本番ネットワークを利用するため、Ethereum の拡張性に依存。 ネットワーク性

能 向上性

容量拡張性

ノード数拡張性

信頼性 成熟性 ブロックチェーン基盤の実績があること

Ethereum 本番ネットワークは仮想通貨基盤として 2015 年 から運用されている。

可用性 単一障害においてサービス停止しないこと

仮想通貨として運用されている Ethereum 本番ネットワークを利用するため、Ethereum の可用性/障害許容性/回復性に依存。 (Ethereum がサービス停止しない限り、本システムもサービス停止しない)

障害許容性 サービス停止となる障害ノード数に単一障害で達することがないこと

回復性 BC ノード障害後にサービス停止せずに 復旧可能であること

セキュリティ

機密性 データの秘匿化が可能であること （本システムの要件ではない）

データのハッシュ化、および、暗号化することで秘匿可能。 ただし、ハッシュ化の場合は、別途、関係者間で元データの共有が必要。 暗号化の場合は、別途、関係者間で復号鍵の共有が必要。

インテグリティ メンバーシップ管理機能を有していること

Ethereum の機能でコントラクト管理者と利用者を分けることはできないため、別途、作り込みが必要。

否認防止性 事象又は行為が後になって否認されることがないよう、事象又は行為が引き起こされたことが証明できること

本システムでは、既存の仮想通貨基盤を用い、仮想通貨と同等のトークン管理を行うことで否認防止性・真正性を確保する。

真正性 データの正しさを証明できること

移植性 適応性 標準的な OS を用いたシステムとすること

一般的な Windows、Linux OS を用いたシステムであるため、適応性あり。

置換性 他のブロックチェーン基盤ソフトウェアに置換可能であること

現時点ではブロックチェーン基盤の標準が存在しないため、置換性を担保することは不可である。

保守・運用性

保守・運用性

モジュール性 システムの構成要素がモジュール化されていること

モジュール性は特にない。

再利用性 システムの構成要素が他のシステムで再利用可能であること

ブロックチェーン基盤ソフトウェア以外の UI 等は再利用の可能性がある。

解析性 障害発生時にどのノードで何があったのかが分かること

各ノードのブロックチェーン基盤ソフトウェアのログ、および、コントラクトコードのログで解析可能。

修正性 サービスを止めずにシステムの修正が可能であること

Ethereum では、サービス稼動中にコントラクトコードの修正が 可能。 ただし、コントラクトコードの修正の際には参加

35

評価項目 （机上）評価結果

者の合意・了承を得る必要がある。

試験性 サービス開始前にテスト可能であること

サービス開始前に Ethereum テストネットワークで十分な試行を実施する必要がある。

コスト 研究開発 ブロックチェーン基盤

コストが明確になること 既存のブロックチェーン基盤ソフトウェアを使用することで新規研究開発費を極小化。

サブシステム

実装 ハードウェア 運用済みのパブリックブロックチェーンを利用することで極小化。 ただし、AP の開発は必要。

ソフトウェア

システム実装

保守・運用 運用 各利用者でインターネット接続費を負担。

保守 全体統括者が AP 保守費を負担。

品質 1）

トークン管理システムとしての性能要件を仮想通貨 bitcoin と同等と想定した場合、本システ

ムで使用する Ethereum 本番ネットワークは 2017 年 7 月時点で bitcoin 以上のトランザクション

数(50 万件/日以上)を処理できているため、十分に実現可能と考えられる。

その他の拡張性、信頼性、セキュリティについては、利用する Ethereum に依存する。そのた

め、Ethereum 本番ネットワーク自体がサービス停止すると、本システムもサービス停止すること

は考慮が必要である。

保守・運用性 2）

利用するEthereum では、コントラクトコード管理者と利用者を区別してアクセスコントロールす

る機能は有していないため、別途アプリケーション開発で作り込みが必要である。また、

Ethereum においてもサービスを止めずにアプリケーションの修正が可能であるが、他のユース

ケースと同様に利用者の合意・了承を得ることについては検討が必要である。

コスト 3）

既に運用中のパブリック・ブロックチェーンを利用することで台帳管理を行う必要がないため、

初期導入コストを非常に抑えることが可能である。実際には、全体を統括する組織・運用体に

てアプリケーション開発、分配、および保守を行うコストが発生する。

36

法制度面での課題調査 3．

本章においては、ブロックチェーンを活用したシステムの社会実装を促進することを目的として、

法解釈の明確化のみならず、規制緩和・制度化のあり方や推奨される実務的な取組について検討

を行った結果について述べる。法制度上の課題については、システム評価の対象となったユース

ケースに関する法制度上の課題の検討に加えて、社会実装にあたって障害となりうる法制度上の

課題として、事業者や有識者へのヒアリング等の結果、指摘された事項についても検討を行ってい

る。なお、検討にあたっては、弁護士、学識経験者、ブロックチェーンに係わる民間団体、民間企

業等からなる検討会を開催し、議論を行った（検討会の詳細は、第 6 章参考資料を確認された

い）。

以下では、まず、分野横断的な論点に関する検討結果を示す。また、個別のユースケースによ

って、業法規制など法制度上の課題が異なる可能性があることから、システム評価の対象となった

ユースケースに関連する分野に関するユースケースについて検討を行った。

3.1． 分野横断的な論点

ブロックチェーンのような新技術については、既存の法制度が想定しない可能性がある。その際、

ブロックチェーンによる法律行為の有効性や適法性に関して、その解釈が不明確となり得る。まず、

書面交付義務等がある書面に関して、ブロックチェーンを用いた電磁的記録の授受で代替するこ

との適法性に関する基本的な考え方について、検討を行った。また、スマートコントラクトおよびトー

クンに関しては、分野を問わず広く活用が期待されていることから、法的な効力について検討を行

った。

また、分散型システムであるブロックチェーンの開発において、開発者コミュニティーの貢献は大

きい一方で、各人の法的責任の所在が不明確であり、萎縮効果が働くことが懸念される。そこで、

システムの瑕疵による損害の発生に関する開発者コミュニティーの民事的責任について、検討を

行う。

最後に、ブロックチェーンの開発や利用は、国境を越えてなされている。そのため、国内法に関

する検討に加えて、国際私法の観点から準拠法に関する検討を行った。

書面の交付等に係わる論点 （1）

平成 13 年「書面の交付等に関する情報通信の技術の利用のための関係法律の整備に関する

法律」（以下、「IT 一括化法」という。）が制定され、５０本もの個別法を改正する形で、書面の電磁

的方式による交付等が認められた。平成 16 年には、 「民間事業者等が行う書面の保存等におけ

る情報通信の技術の利用に関する法律」（以下、「e-文書法」という。）が制定された。e-文書法によ

り同法の別表に掲げられた場合、IT 一括化法同様、紙媒体としてのみ作成、保存、交付（以下、作

成、保存、交付を「保存等」という。）することが可能となっていた書面を、電磁的な方式を用いて保

存等することができるようになり、IT 化の対象が広がった。

37

具体的な技術的要件は、e-文書法ではなく主務省令に委任されているが、政府全体の整合性

を保つため、内閣府により「主務省令の作成要領」17が作成され、次に掲げる方法によることを主務

省令に規定することが望ましいとされている。

「イ」「民間事業者等の使用に係る電子計算機と交付等の相手方の使用に係る電子計算機とを

接続する電気通信回線を通じて送信し、受信者の使用に係る電子計算機に備えられたファイ

ルに記録する方法

「ロ」：「民間事業者等の使用に係る電子計算機に備えられたファイルに記録された書面に記載

すべき事項を電気通信回線を通じて交付等の相手方の閲覧に供し、当該相手方の使用に係

る電子計算機に備えられたファイルに当該事項を記録する方法

「主務省令の作成要領」や個別法令のガイドライン等では、イに掲げる方法としてメール等を想

定しているとの記述がある。またロに掲げる方法としてWebページの閲覧等のクライアントサーバー

型のシステム用いた提出を想定している旨記載がある。そのため、ブロックチェーンを用いて電子

データや電子化された文書を交付等することは適法か、という問題が生じる。

e-文書法においては、具体的な技術的要件を、主務省令に委任している。そのため、具体的

な技術的要件および当該要件を踏まえたブロックチェーンによる交付等の適法性は、主務省令お

よび個別の法令、並びに個別の法令のガイドライン等の検討を要することとなる。一方で、政府全

体としての整合性の確保の観点から、「主務省令の作成要領」が定められており、多くの e-文書法

の主務省令が当該要領に基づき制定されている。そこで、e-文書法および「主務省令の作成要領」

に規定された技術的要件に関して、ブロックチェーンによる交付等の適法性に関する基本的な考

え方を検討することとする。

e-文書法が交付等の技術的要件を主務省令に委任した理由は、民民間の取引に関して具体

的な技術的要件についてまで政府が権利義務関係を創設・変更すべきでないこと、技術進歩が早

く、取引の実態に応じて情報通信技術の普及等が異なるため、主務大臣が責任を持って判断す

べきこと等が理由である18。そのため、少なくとも内閣官房 IT 室が作成した「主務省令の作成要領」

に関しては、特定の技術を規定したものではなく、ブロックチェーンのような新しい技術を用いること

を排除する意図はないと考えられる。そこで、「主務省令の作成要領」に定められた技術的要件に

関して、ブロックチェーンを文理解釈上認めることができるかが問題となる。

e-文書法逐条解説では、第 1 項第 1 号イとして「電子メールなどで、相手のパソコンのフォルダ

に電磁的記録を送る方法」を定め、第 1 項第 1 号ロとして「自分のホームページに電磁的記録を掲

載し、それを交付等の相手方がダウンロードできる状態に置く方法」を定めていると解説している。

ここで、「民間事業者の使用に係る電子計算機」については、必ずしも当該民間事業者等が保有

している必要はなく、使用していればよいと解される。例えば、ホームページを構築する際、レンタ

17 内閣官房情報通信技術（IT）担当室（2005）『逐条解説 e-文書法』株式会社ぎょうせい 18 内閣官房情報通信技術（IT）担当室（2005）『逐条解説 e-文書法』株式会社ぎょうせい 38 頁

38

ルサーバーを使用することは広く行われているためである。また、「顧客等の使用に係る電子計算

機」と「民間事業者等の使用に係わる電子計算機」は、同一であっても構わないと解される。例えば、

クラウドストレージサービスを使用している民間事業者が、クラウドに交付等の対象となる電子的な

書面をアップロードし、当該ストレージを使用している交付等の相手方が当該書面をダウンロード

する場合がある。

ブロックチェーンについては、分散型システムとして各ノードの記憶領域を共有していると考える

ことができ、「顧客等の使用に係る電子計算機」と「民間事業者等の使用に係わる電子計算機」が

同一であるようなクラウドストレージサービスと同様と考えることができる。

以上を踏まえると、ブロックチェーンによる電磁的な書面の交付等は、クラウド型のシステムとか

わらず、e-文書法及び主務省令の範囲内では適法と考えられる。なお、個別法の施行令において

は、異なる規定を置いているものがあるため、ブロックチェーンの実装にあたっては、個別の法令を

確認するとともに、必要に応じて適法性について所管省庁に確認することが必要である。

スマートコントラクトに関する論点 （2）

スマートコントラクトとは、ブロックチェーン上で動作するコンピュータプログラムである。スマートコ

ントラクトのプログラムコード(コントラクトコード)は、それ自体がブロックチェーンに書き込まれ、入力

されたデータに基づき、処理が実行される。スマートコントラクトは、プログラム化された契約として、

1990 年代後半に、法学者・暗号学者の Nick Szabo 氏により提唱された概念であり、概念自体は、

ブロックチェーン以前から存在していた。ブロックチェーンの開発により、技術的に実装可能となり、

契約以外に関しても幅広く活用が期待されているが、本項では、主として、契約をブログラムコード

としてブロックチェーンに書き込み、自動的に履行がなされるものとして検討を行う。

契約の成立 1）

契約の成立については、一般に当事者の意思の合致があるかが問題となる。当事者の意思表

示がなされ、かつそれが一致したものと見做されるには、あらかじめ、機械語で記述されたコントラ

クトが、当事者の一定の指示に基づいて、動作を行うことにより自動的に契約がなされることを、契

約当事者が認識し、合意している必要がある。動作の結果について改めて明示的な承諾を行うこ

とは必要ないが、サービスの説明やシステム利用にあたっての約款・契約、社会的な共通理解など

により、合意成立の基礎となる社会的な共通理解がなされることが求められる。

特に、事業者が消費者と契約を行う場合、「電子消費者契約及び電子承諾通知に関する法律」

3 条により、錯誤の主張がなされる場合がある。送信ボタンが存在する同じ画面上に意思表示の内

容を明示する等の対処を行った場合には、同法に基づく錯誤の主張が許されなくなるので、どこか

らが契約成立なのかを明らかにしておく必要性がある。その意味では、スマートコントラクトを実装

する事業者が、リスクを事前に認識した上で、インターフェイスを設計する必要がある。消費者との

インターフェイスは、自然言語で容易に契約内容等を理解可能なものにする必要がある。なお、錯

誤主張との関係では、そもそも各別かつ明示の方法により、消費者側の主体的意思が形成され、

39

確認措置を不要とする意思の表明がされるように、スマートコントラクト利用者に対する説明とともに、

仕組みへの理解を促進するという対策により、錯誤の主張が頻発しないよう、対応することも考えら

れる。

証拠力 2）

民事的な紛争が発生した際、提出されたコントラクトコードが事実の証明に役に立つか（実質的

証拠能力）を判断する前提として、当該コードが真正に成立したものであるか（形式的証拠力）が

問題となる。 そこで、形式的証拠力および実質的証拠力それぞれについて検討を行う。

■ 形式的証拠力

私文書に関しては、「本人又はその代理人の署名又は押印があるときは、真正に成立したものと

推定」される（民事訴訟法第 229 条第 1 項）。一方で、電磁的記録に関しては、本人による電子署

名が行われているときに、真正に成立したものと推定される（電子署名法第 3 条）。認定認証事業

者が提供する証明を受けた場合は、本人による電子署名がなされたことが証明される。それ以外

の場合には、電子署名を「行うに必要な符号および物件を適正に管理することにより、本人だけが

行うことができることとなるものであること」を立証しなければ、真正に成立したものと推定されない。

ただし、裁判実務上、例えば電子メールに電子署名が付いていないことをもって、成立の真正が争

われることは少ないとの指摘がある（なお、「故意又は重大な過失により真実に反して文書の成立

の真正を争ったときは」過料に処せられる（民事訴訟法第 230 条第 1 項））が19、電子署名法の要件

を満たす電子署名の利用が少なく、いわゆる二段の推定が働かないことからすると、ブロックチェ

ーンの利用者に若干のリスクが残ることとなる）。

■ 実質的証拠力

実質的証拠力の判断は、裁判官の自由な心証に委ねられる（自由心証主義）。機械語で記述さ

れたコードについて、実際に裁判所に証拠として提出したとしても、可読性がないため証拠として

認められないのではないかといった指摘がある。

消費者と事業者間での契約については、実務上の取組として、自然言語で記述されたインター

フェイスを通じて契約を成立させたことの記録に関して、消費者および裁判官が見て分かる形態で

あることが、証拠として認められるために最低限必要となる。

また、ブロックチェーンの基盤（いわゆる非決定論的な基盤20）の中には、記述されたコードを裁

判所に証拠として提出した際に、契約成立時点と異なった実行結果となりうるものがあり、証拠書

19 増島 雅和「ブロックチェーン技術を用いたスマートコントラクトの検討」NBL 2017 年 3 月号 No.1093 20 異なった実行結果になり得る非決定的なコードとは、サーバの時間やサーバで生成した乱数などの実行環境に

依存する情報をもとに計算するコードのことである。また、決定的なコードとは、固定値の入力パラメータのみで計算

され、どの実行環境でも結果が同じになるコードのことである。

40

類として認められないことがあるのではないかとの指摘がある。そのため、非決定論的な基盤を採

用する場合には、契約がなされた時点での実行結果の証跡を保存しておくことが重要との指摘が

あった。具体的には、ソースコードの断面をそれぞれ保管しておき、かつソースコードをコンパイル

して合意した内容を実行し、保存する。さらに、当該結果とコードがブロックチェーンに記録されて

いれば、証拠として利用できる状況であることが明確になる。なお、少額取引でブロックチェーンを

使用する場合などについては、厳密な証跡の取得は、コストとして見合わなくなる可能性がある。こ

のような場合に保存を行わないことで、コストは削減されるが、訴訟が発生した際に一定のリスクが

存在するため、費用対効果を検討の上、判断することが望ましいとの指摘があった。

トークンに係わる論点 （3）

Initial Coin Offering（ICO）として、新たな資金調達手段が注目を集めている。一方で、トークン

の用途はこれに留まらず、様々なトークンが発行され始めている。本項では、トークンの法的性質を

整理するとともに、ICO 以外の活用を促進する観点から、トークンの法的課題を検討することとす

る。

トークンの類型と権利性・法令の適用関係 1）

ヒアリング行った民間事業者から、トークンの法的位置付けが不明確であり、実装にあたって活

用を躊躇しているとの指摘があった。そこで、以下ではトークンの類型化を行い、法令の適用関係

やトークンの権利性について、検討を行った。

一般的に定まった定義はないが、本項では、ブロックチェーンにおけるトークンを、何かしらの価

値を有する台帳上の記録であり、保有者から第三者へ移転可能なもの、として検討する。トークン

には、様々な形態があるが、主なものとして、ビットコインなどの送金および決済手段として使用さ

れる仮想通貨型トークン、Ethereum などのブロックチェーンプラットフォームを利用する際に支払う

プラットフォーム利用型トークン、権利や財産的価値を台帳として記録したものやトークンの保有量

に応じて配当を受けることができるアセット型のトークンがある。

表 1 トークンの機能による分類

類型 機能 具体例

通貨型 決済手段 ビットコイン

プラットフォーム利用型 ブロックチェーンプラットフォームの利

用料

Gas（Ethereum の使用料）

アセット型 台帳型 権利・財産的価値を記録したもの 共同所有、登記 等

配当型 トークンの保有量に応じて、配当を受

けることができるもの

ICO（Initial Coin Offering）

41

通貨型は、送金および決済手段として利用するものであり、台帳には、送金先や送金額が記録

されている。資金決済法では、仮想通貨には、物品の購入・サービスの利用等の対価の弁済のた

めに、不特定の者に対して使用することができ、かつ不特定の者を相手方として購入及び売却を

行うことができる財産的価値であり、情報通信技術を用いて移転することができる「1 号仮想通貨」、

不特定の者を相手方として１号仮想通貨と交換できる「２号仮想通貨」がある。トークンがこれらの

仮想通貨に該当することを企図して発行される場合、①仮想通貨の売買または他の仮想通貨との

交換、②それらの行為の媒介等、③前記①・②の行為に関して行う利用者の金銭または仮想通貨

の管理を業として行う事業者は仮想通貨交換業の登録を要する。また、私法的な性質を見ると、仮

想通貨自体は、所有権、債権、知的財産権として認められないと考えられる。所有権とは、有体物

をいうため、デジタルデータであるトークンは対象とならない。

一方で、プラットフォーム利用型は、基本的には、該当する規制はないと考えられる。ただし、決

済または送金手段として使用される場合は、資金決済法の仮想通貨に該当する可能性がある。権

利性については、通貨型同様である。また、発行されるトークンについて対価が支払われており、

発行者または発行者以外の第三者から物品を購入し、サービスの提供を受ける際の代価の弁済

に使用できる場合、前払式支払手段に該当する可能性がある。この場合、発行者は資金決済法に

従い届出または登録を要し、発行保証金の供託義務等が課せられる。なお、前払式支払手段に

該当する場合は、資金決済法上の仮想通貨には該当しないものとされている21。

アセット型トークンのうち主に台帳として利用するものについては、決済または送金手段として使

用される場合は、資金決済法の仮想通貨に該当する可能性がある。私法的な性質については、記

録する権利または価値の内容により多岐に渡るが、トークンそれ自体については、基本的に債権

的性質を有するものが多いと考えられる。なお、慣習などソフトローにより、一般に権利として認識さ

れているものがある。例えば、商法における有価証券の電子化が進められている一方で、船荷証

券などを電子化して良いのかわからないという議論がある。船荷証券は、現在ではほとんど使用さ

れていないが、商慣習に形成されたものであるとの指摘がある。

アセット型トークンのうち配当を行うものは、金融商品取引法第２条 2 項 5 号の集団スキーム持分

に該当する可能性がある。この場合は、第二種金融商品取引業の登録が必要となる。また、送金

および決済手段として使用する場合は、資金決済法上の仮想通貨に該当する可能性がある。ただ

し、有価証券に該当する場合は、兼業規制などとの関係があること、二重に規制を課す必要性が

低いことなどから、仮想通貨に該当しないと整理することが望ましいとの指摘があった。

21 金融庁 2017 年 3 月 24 日付パブリックコメント回答「資金決済に関する法律（仮想通貨）関係 No.37」

42

表 2 各類型の法的性質

類型 関連する権利、法令等

私法的性質 公法

通貨型 原則、権利として認められない 資金決済法上の仮想通貨

プラットフォーム利用型 決済または送金手段として使用される

場合は、資金決済法の仮想通貨に該

当する可能性あり。

アセット型 台帳型 債権的性質を有する場合あり 金融商品取引法 2 項有価証券に該当

する可能性あり

配当型 債権的性質を有する場合あり

金融商品取引法集団投資スキーム持

分に該当する可能性あり

以下では、今後、様々な活用が期待されるアセット型トークンに関して、トークンが移転した際の

権利の移転について、検討する。

アセット型トークンの移転と権利移転 2）

適切に仕組まれたブロックチェーンでは、①改ざん不可能、②ネットワーク上において転々と流

通されることができる、③二重に使用することが困難、④トークン保有者が権限又は権利の正当な

保有者であることを明らかにする、という性質を持たせることが可能である。

例えば、ビットコインのような仮想通貨では、プライベートキーを有するものが権利者であって、

二重譲渡の問題は生じにくい(なお、プライベートキー自体を 2 人以上に譲渡した場合や、ブロック

が分岐する場合の問題もあり、二重譲渡が一切起こらない訳ではない)。一方で、このようなトーク

ンに、債権・動産・不動産などの権利を紐づけるアセット型トークンの場合、そもそもトークンにアセ

ット上の権利をどのように紐付けられるかという問題に加え、トークンを移転したことにより真に権利

が移転するのか、また対抗要件が具備されるのか、という問題が生じる。以下、各権利に関して、個

別に検討を行う。

■ 債権

まず債権については、当事者がトークンを有するものが債権者である、という合意をなすこと自体

は有効であり、また、トークンの移転により債権が移転する、という予めの合意もそれ自体は有効と

思われる。

他方、トークンホルダーが権利を移転するにはトークンの移転が必須であってトークンと切り離し

ては権利を移転できないという｢権利とトークンの一体化の合意｣や、権利の二重譲渡があった場合

に、トークンのプライベートキーを有する者が正当な権利者であるという｢対抗要件の合意｣が有効

かについては疑義がある。

43

前者は通常の債権とは異なる新たな権利の組成ではないかとも考えられ、また後者については、

日本法上、債権の対抗要件が債務者に対する通知・承諾(第三者対抗要件は確定日付ある通知・

承諾)(民法 467 条)、または、金銭を目的とする指名債権については動産及び債権譲渡特例法上

の登記による第三者対抗要件（同法第 3 条、4 条) が認められているのに対し、新たな対抗要件制

度を当事者が合意により創出するものではないか、という疑義が生じる。

この点、仮にこれら二つのような合意が認められないとすると、例えばトークンホルダーがトークン

とは別個に権利を譲渡した場合にどうなるのか、トークンホルダーによるトークン譲渡後に旧トーク

ンホルダーが権利の差し押さえを受けた場合にどうなるのか、旧トークンホルダーが破産をした場

合に破産管財人との関係がどうなるのか、等の問題が生じ、場合によりトークンの譲渡を受けてい

た者が権利を第三者に対抗しえない、ということになり、取引の安全を害することになる。

■ 動産

動産については、目的物を引渡す（占有を移転する）ことが対抗要件となる（民法第 178 条）。こ

の引渡しには、現実の引渡し、占有改定による引渡し、指図による引渡し、簡易の引渡しの方法が

認められている。また、「動産及び債権の譲渡の対抗要件に関する民法の特例等に関する法律

（以下、「動産及び債権譲渡特例法」」という。）により登記を受けた動産については、引渡しがあっ

たものと見做され、対抗要件を具備する。

動産のトークン化を考えた場合、例えば SPC22を設立し、SPC が動産を保有し、トークンを発行す

る、その上でトークンホルダーが動産の所有権を有し、かつトークンの譲渡があった場合には指図

による占有移転による引渡しがあったものとする、などの合意をすることが考えられる。但し、このよ

うな指図による占有移転の合意が擬制的にすぎないか、トークンホルダーにより他の方法により動

産譲渡がなされた場合、やはりトークンと権利の分離が起きてしまうのではないか、などの問題が生

じる。

また、そのほか実際の動産を管理する SPC が当該動産を第三者に譲渡した場合、即時取得を

した第三者には対抗できない点も課題である。

■ 不動産

不動産のトークン化についても、例えば SPC を設立し、SPC が不動産を保有し、トークンホルダ

ーが所有者である、とする仕組みを組成することが考えられる。

しかしながら、日本法上、不動産の移転の対抗要件は不動産登記によってのみ行われるところ

(民法 177 条)、トークンの移転によって不動産所有権が移転する、ということを対抗要件にすること

はできないと考えられる。

以上のように、権利のトークン化を考えた場合、日本法上、トークンの移転では対抗要件が具備

されず、トークンホルダーと実際の権利者が異なることが生じうる、という問題が指摘された。この点

22 SPC（special purpose company, 特定目的会社）とは、限定された目的のために設立される会社である。

44

に関しては、そもそも民法上、トークンのようにプライベートキーの占有によってのみ権利者が明ら

かになる、という仕組みは想定されておらず、日本がブロックチェーン大国となるためには、新しい

権利移転要件、対抗要件として適切に蔬菜されたブロックチェーン上の｢トークン｣の移転を認める

民法改正、または何らかの特例法の制定を議論すべきである、と指摘があった。

また、特例法を制定しないまでも、不動産の登記所のシステムから API で登記の情報とトークン

の記録を相互に更新していくことで、登記とトークンの記録を一致させ、結果として第三者への対

抗要件が具備される、という方法も検討の方向性として考えられる。なお、合意した形跡があり、特

殊な場合を除いてスマートコントラクトが実行されると権利移転する、ということが言えればよいとい

った指摘もあった。

トークンの差押 3）

ブロックチェーンに権利を載せたトークンをどう差し押さえるのかというトークン自体の執行可能

性の問題がある。これについては、東京地判平成 28 年 10 月 14 日をもとにした返還請求権の差押

の事件が参考になる23。このもととなる事件は、高齢者に対して「転売すれば、利益を得ることがで

きる」などと次々に勧誘し、実勢価格の約 30 倍の単価で売却し、1500 万円ほどをだまし取ったとい

う事件である。被害者が、詐欺を行ったものに対して請求訴訟を行い確定した。その判決をもとに

差押を行ったという事案である。

この案件において、被害者は債権者として、第三債務者たる仮想通貨の交換所に対して、債務

者の有する仮想通貨の返還請求権を差し押さえることにしている。さらに、「第三債務者への送達

以後も債務者がネットワーク上のアカウントやウォレット等のサービスを自由に利用できるとなれば、

債務者の処分禁止効や第三債務者の弁済禁止効がない(ダダ洩れ)状態になる。そこで、第三債

務者となった仮想通貨交換業者としては、民事執行法 145 条 I 項違反や執行妨害などの無用な争

いに巻き込まれないためには(略)、民事執行北條の弁済禁止義務の付随義務として、提供してい

るアカウントやウォレット、サービスを中断、停止、あるいは削除することが必須である。」として、そ

れらに対する配慮をなした上で、差押をしている。

トークンに対する差押といっても、交換所等の何らかの中間的な事業者を経由する場合につい

ては、その事業者等に対する返還請求権を差し押さえるということで対処しうる場合も相当あるよう

に考えられる。

では、債務者の唯一の資産が、ブロックチェーン上で保管されていたらどうするのか。結局、司

法権の行使から免れる財産を認容することになるのではないか、仮想通貨がその意味で治外法権

となってしまうのではないか、という疑問がある。この場合は、いわゆる執行不能となってしまい、結

局は間接強制しか方法がないということになってしまうものと考えられる。

23 藤井裕子「仮想通貨等に関する返還請求権の債権差押え」(金融法務事情 2079 号、2017)6 頁

45

分散型システムにおける法的責任に関する論点 （4）

分散型のアプリケーションである DApps（Decentralized Applications）24に関しては、特定の運営

主体が存在せず、開発はコミュニティーによって行われる。このとき、スマートコントラクトに関してバ

グなど、不正確なプログラムによって誤った取引がなされて損害が発生した場合など、ブロックチェ

ーンを活用したサービスに関して、売主の行動により金銭的または物理的な被害が買主に生じた

場合、ブロックチェーンの構築やサービスの提供に貢献した個人は、民事的な責任（不法行為責

任等）を負いうるか、という問題がある。

この点について、一般的には、不正確なプログラムによって、誤った取引がなされて発生

した損害とブロックチェーンの構築者の行為の因果関係が問題になる。因果関係が肯定され

た場合に、コミュニティーへの貢献などを総合的に考慮して、賠償額が決定される。

準拠法に係わる論点 （5）

ノードが分散しており、人々が世界中に点在している状況下で、国際的な観点で、何を準拠法と

し、意思の合致はどの法律で考えるべきかという問題がある。

まず、上記のように世界的に参加者がいるブロックチェーン上の法律問題を考えるにあたって

は、厳密に見る場合には、（１）どこの誰が（どの国の裁判所か、行政機関か）（２）どのような法律問

題（刑事法であるのか、民事法であるのか、行政に関する法律なのか）を、検討するのかということ

によって、左右されることになる25。

その意味で、厳密な分析は極めて難しいが、むしろブロックチェーン上の法律問題については、

基本的に当事者の合意で解決をなそうという性質が合致するといえる。

例えば、我が国において、契約の成立や効力が議論されている場合においては、当事者が契

約締結時において、適用地を選択した場合には、当該土地の法律が準拠法とされる（法の適用に

関する通則法－以下、法適用通則法という－７条）。これに対し、準拠法の選択がない場合には、

法律行為の当時において、法律行為の成立および効力は、法律行為に最も密接な関係がある地

の法によることとなる（同法８条１項）。この密接関連性に関しては、同法同条２項において、法律行

為において特徴的な給付を当事者の一方のみが行うものであるときは、給付を行う当事者の常居

所地法を最も密接な関係がある地の法と推定するとの定めがある。

もっとも、このような説明は、我が国において、契約の成立や効力が議論されている場合の処

理ということになる。しかしながら、契約をめぐって紛争が起きた場合に、我が国のような国際私法

に関するアプローチがすべての国で同一であるという保障はない。実際には、ブロックチェーン上

のアプリケーションの提供者（以下、プロバイダーという）の常居所地法が適用され、また、執行等

24 DApps とは、開発者コミュニティーなど非中央集権的な主体により構築されたアプリケーションであり、トークンを

報酬として、中央の管理主体なく、アプリケーションの構築が行われる。 25 この点について「電子商取引及び情報財取引等に関する準則 改訂案」（平成 22 年 8 月）は、我が国での考え

方を述べたあとに、これは「当該紛争について我が国の裁判所に訴えが提起された場合についての我が国の立場

からの判断であることに注意する必要がある。すなわち、当該紛争について外国の裁判所に訴えが提起された場

合には、当該外国の法に従って、国際裁判管轄が認められるかどうかや、どの国の民法や商法が適用されるかに

ついて判断されるのであり、その結論が我が国のそれとは異なる可能性もあるのである。」と論じている（同 10 頁）。

46

の関連からプロバイダーの常居所を管轄する裁判所において裁判が行われるものと考えられるが、

理論的には紛争の解決が図られる裁判所と適用される法は全く別の問題ということになる。

その意味で、どの国で一定の法律関係の解決が図られるのかというのが、実際としては先に来る

のであり、その場合、特にプラットフォームをなしている上記プロバイダーの指定する裁判所が紛争

の解決を図ることになろう。その場合、その国の国際私法の考え方で法律問題の性質決定および

準拠法が指定されるのであるが、そのこと自体は、一般の取引と変わることはないといえる。

基本的には、当事者間の合意を尊重する方向性は、どの国においても採用されている手法であ

るといえる。準拠法を指定しない者は、それが上記の枠組みにおいて、みずからの利益になるとい

うことであろう。

上記のように、実際に法の適用されるルールは明確であったとしても、実際にわが国の司法制

度が利用されるのか、というのは全く別の問題である。アジアの各国との間で、判決の執行の可能

性が乏しいこと、判決例の公開があまり進展していないこと、証拠の開示制度がないことなどが、わ

が国の司法制度の問題として指摘されることがあり、これらの問題点を克服していくことによって、

事業者が紛争解決のプラットフォームとして日本の裁判所を利用するようにならなければならないと

いえるだろう。

3.2． 個別分野における論点

個別分野のユースケースについて、社会実装にあたっての法制度上の課題に関する検討を行

った。

医療・ヘルスケア分野における論点 3.2.1．

医療に係わる情報については、生命または人体に影響を及ぼすことが多いため、真正性や完

全性が求められる。そのため、情報の取扱いや情報システムの構築・利用に関して、他の分野と異

なる扱いが法令等において求められているところである。そこで、医療・ヘルスケア分野固有の法

制度上の課題について、医療・治験データプラットフォームおよび医療カルテの共有システムを取

上げ検討を行った。

治験データ管理プラットフォーム （1）

システム評価を行った治験データ管理プラットフォームを社会実装する上で法制度上の課題に

関して検討を実施した。

書面の保存、交付等に係わる論点 1）

医療機関、治験依頼者等による治験の実施基準等を定めた「医薬品の臨床試験の実施の基準

に関する省令」（平成９年厚生省令第 28 号。以下「GCP 省令」という。）では、原則として治験依頼

者（製薬企業）が「モニタリングを実施する場合には、実施医療機関において実地に行わなければ

47

ならない」とされている（GCP 省令第 21 条第 2 項）。ただし、「他の方法により十分にモニタリングを

実施することができる場合には、この限りではない」（GCP 省令第 21 条第 2 項）とされており、例外

的に実地以外の方法によることが認められている。

実地以外の方法によりモニタリングが行える場合として、中央モニタリングが認められている。中

央モニタリングは、「治験の方法（評価項目等を含む。）が簡単であり、参加実施医療機関の数およ

び地域的分布が大規模であるなどのために、実施医療機関等への訪問によるモニタリングが困難

である治験」において行われる例外的な方法であり、「治験責任医師等又は治験協力者等の会合

およびそれらの人々に対する訓練や詳細な手順書の提供」、「統計学的にコントロールされた方法

でのデータの抽出と検証」、「治験責任医師等との電話、ファックス等による交信等の手段」を併用

し、治験の実施状況を調査し、把握する方法である（厚生労働省通知「医薬品の臨床試験の実施

の基準に関する省令」）。

統計学的にコントロールされた方法でのデータの抽出と検証は、サンプル SDV（Source

Document Verification）と呼ばれており、治験の効率化の観点から導入が期待されている。特に、

サンプル SDV の実施にあたっては、電子的に治験関連データを登録・閲覧できる EDC（Electronic

Data Capture）システムの導入が、欧米の製薬企業において進められているところである26。なお、

本ユースケースも、EDC に位置付けられるものであるが、ブロックチェーンを用いることで、効率的

なモニタリングの実施のみならず、治験データの不正な改ざんの防止が期待できる。

治験依頼者から指名されるモニターは、モニタリング報告書27を治験依頼者に提出しなればなら

ないとされており（GCP 省令第 22 条第 2 項）、当該規定においては書面による提出が想定されて

いる。しかし、e-文書法を受けて制定された「厚生労働省の所管する法令の規定に基づく民間事

業者等が行う書面の保存等における情報通信の技術の利用に関する省令」（平成 17 年 3 月 25 日

厚生労働省令第 44 号。以下、「省令 44 号」という。）において、GCP 省令第 22 条 2 項について、

書面による提出に代えて、電磁的記録により提出することが認められている。そのため、EDC により、

モニターや医療機関が治験関連データを登録・閲覧することが可能となっている。このとき、メール

等の手法が想定されている省令 44 号第 11 条第 1 項第 1 号イ、又はクラウド・ウェブページの閲覧

等が想定されている同号ロ28に掲げられた方法により行わなければならないとされており、ブロック

26 リモートSDVについて、日本国内において導入が進まない理由として、治験依頼者側での導入コストおよび医療

機関側のオペレーションコストの高さである。ブロックチェーン技術を用いて容易に使えるようになることをポイントと

してビジネスを始める場合、利活用者がコストを感じずに着手できるような分かりやすさがあれば、医療機関側も導

入に踏み切りやすいとの指摘がある。 27 モニタリング報告書には、モニタリングを行った日時、モニタリングの対象となった実施医療機関、モニターの氏

名、モニタリングの際に説明等を聴取した治験責任医師等の氏名、モニタリングの結果の概要、前項の規定により

治験責任医師に告げた事項、並びに実施医療機関における治験がこの省令又は治験実施計画書に従って行わ

れていないことを確認した場合講じられるべき措置及び当該措置に関するモニターの所見を記載しなればならない。

（GCP 省令第 22 条第 2 項） 28 省令 44 号 第 11 条

民間事業者等が、法第 6 条第 1 項の規定に基づき、別表第 4 の 1 及び 2 の表の上欄に掲げる法令のこれらの

表の下欄に掲げる書面の交付等に代えて当該書面に係る電磁的記録に記録されている事項の交付等を行う場合

は、次に掲げる方法により行わなければならない。

一 電子情報処理組織を使用する方法のうちイ又はロに掲げるもの

イ 民間事業者等の使用に係る電子計算機と交付等の相手方の使用に係る電子計算機とを接続する電気通信回

48

チェーンによるモニタリング報告書の提出が認められるかが問題となる。

GCP 省令に基づき治験関連文書の交付および保存の方法、留意事項等を定めた厚生労働省

事務連絡「治験関連文書における電磁的記録の活用」に関する基本的考え方」では、具体的な交

付の方法として、「e-メールに添付し交付」、「ＤＶＤ－Ｒ等を交付」、「クラウド等システムに対して、

アップロードし、受領者がダウンロードする方法により交付」を例示している。ただし、これは例示で

あり、これに限るものではないと解される。そこで、ブロックチェーンが該当しうると解釈できるかが問

題となる。省令 44 号第 11 条を見ると、「主務省令の作成要領」と同じ規定となっている。ブロックチ

ェーンについては、第 3 章「書面の交付等に係わる論点」で論じたとおり、クラウド等のシステムと変

わるところなく同様の論理で解釈可能であろう。

その他の論点 2）

以上の検討のように、ブロックチェーン固有の法制度上の論点は、多くないと考えられる。実際

にブロックチェーンを実装する場合には、クラウドコンピューティング、その他 IT に関する既存の法

令、ガイドライン等を遵守していくことが望ましい。

医療情報の共有システム （2）

ユースケース概要 1）

医療情報の有効活用等に向けて診療録や処方箋等の医療情報の電子化が進められている。

一方で、改ざん等がなされた場合に生命・人体に影響を及ぼすリスクがある医療情報については、

法令等において、データの真正性等の情報セキュリティの確保が強く求められているところである。

そのようななかで、診療情報や処方箋を、医療機関、薬局、保険会社等の間でブロックチェーンを

用いて共有することで、クライアントサーバーシステムでの実装に比べて、より安価に、かつ改ざん

不可能な形で医療情報を関係者間で共有することが可能になると考えられる29。

個人情報保護法上の論点 2）

医療情報の共有システムは、医療機関、薬局等、複数のステークホルダーで医療情報が共有さ

れるため、各ステークホルダーは、個人情報取扱事業者として義務を課されられることとなるが、新

たにノードが加わった場合、個人情報の共有に関して、第三者提供となるのか等の論点が存在す

る。このとき、ブロックチェーン上で診療録等の情報を共有する場合、ブロックチェーン上では、診

線を通じて送信し、受信者の使用に係る電子計算機に備えられたファイルに記録する方法

ロ 民間事業者等の使用に係る電子計算機に備えられたファイルに記録された書面に記載すべき事項を電気通信

回線を通じて交付等の相手方の閲覧に供し、当該相手方の使用に係る電子計算機に備えられたファイルに当該

事項を記録する方法（法第六条第一項に規定する方法による交付等を受ける旨の承諾又は受けない旨の申出を

する場合にあっては、民間事業者等の使用に係る電子計算機に備えられたファイルにその旨を記録する方法）

49

療録等の医療情報のハッシュ値のみを共有し、分散型のサーバ等により個別に医療情報を送信

する場合が考えられる。それぞれ、共有される情報、医療情報の共有範囲が異なることから、以下

では分けて検討する。

■オンチェーンで医療情報を送受信する場合

患者、医療機関、薬局、保険会社等の間で、医療情報を共有するにあたって、医療情報そのも

のをブロックチェーン上の記録する方法が考えられる。この場合、パブリック型のブロックチェーン

で実装した場合、医療情報が不必要に不特定多数の者に共有されるため、プライバシーに対する

リスクが高く、適当ではない。そこで、コンソーシアム型のブロックチェーンで実装した場合について、

個人情報保護法上の問題を検討する。

当初、ブロックチェーンに参加している医療機関等による個人情報の取得に関しては、クライア

ントサーバー型システムによって実装したものと相違なく、取得時における本人同意の取得等が求

められる。一方で、新たにノードが追加される場合に、当該ノードへの医療情報の送信に関して、

既存のノードに第三者提供に関する義務が課されるのか、または第三者提供とはならないのか、と

いう論点が存在する。

ノードが後から追加される場合としては、例えば地域医療連携のように、かかりつけの医院から

他の医院の紹介があり、当該他の医院に診療録を共有し、診療後、当該他の医院、薬局、かかり

つけの医院で、電子処方箋が共有されるような場面が想定される。このとき、既存のノードから第三

者提供となる場合には、既存の全てのノードに対する記録義務、新規のノードに対する確認・記録

義務が課されうることから、問題となる。

図 8 ノードが追加された場合の個人情報保護法上の義務

一方で、最初に医療機関を受診した時点等で黙示の同意があったとみなし、本人から委託を受

医療機関A 医療機関B

薬局

・本人同意の取得・第三者提供時の記録義務

・本人同意の取得・第三者提供時の記録義務

第三者提供を受ける際の確認記録義務

既存のノード 新規のノード

④医療情報の送信

④医療情報の送信

①医療情報の送信

例：診療録を共有

例：診察他の医院を紹介

アクセス権限管理サーバー

②権限付与依頼 ③権限付与

50

けているとみなすことも考えられるとの指摘があった。この場合、第三者への提供とはみなされず、

個人情報保護法第２５条および第２６条における確認・記録義務が適用されない。なお、各ノード

が「本人からの委託等に基づいて個人データを提供しているものと評価し得るか否かは、主に委託

等の内容、提供の客体である個人データの内容、提供するときおよび提供先の個人情報取扱事

業者等の要素を総合的に考慮して、本人が当該提供を具体的に特定できているか否かの観点か

ら判断」30される。

なお、既存のノードからの第三者提供となる場合は、既存のノードに対する、本人同意の取得お

よび第三者提供に際しての記録義務、追加されたノードに対する第三者提供を受ける際の確認・

記録義務が課されることとなるが、後述するパーソナルデータストア（ＰＤＳ）等の仕組みや個人情

報保護法２５条に定められた事項をブロックチェーンに記録することにより、ノードの参加者に対す

る義務を履行する上でのコストを減らしつつ、適法に医療情報を共有することが可能となるとの指

摘がある。

■オフチェーンで医療情報を送受信する場合

ハッシュ値は、記号・数値のランダムな組み合わせであり、当該情報のみでは、特定の個人を識

別することはできない。そのため、ハッシュ値を全ノードで共有しておき、求めに応じて、診療録等

を分散型サーバで、医療機関と薬局等の特定の関係者間で共有（オフチェーン処理）する場合に

は、ハッシュ値の共有に関して第三者提供に係わる本人同意は不要となる。医療情報の共有にあ

たって、サイドチェーン等のオフチェーン上で個人情報を共有した場合に、オンチェーン上のノー

ドである当事者以外との関係で個人情報の移転となるかといった論点がある。 この点については、

個人情報は第三者のノードには移転しておらず、アクセス不可能なため、当該第三者との関係で

は第三者提供とはならないと解される。

物流・サプライチェーン、モビリティ等分野における論点 3.2.2．

本項においては、物流・サプライチェーン・モビリティ等（エネルギーを含む）分野における法制

度上の課題等について検討する。 物流・サプライチェーン、モビリティ等分野の法制度検討会で

は、ユースケースとして、システム評価の対象となった「EV バッテリーライフサイクル管理」および電

力融通取引を取上げる。

EV バッテリーライフサイクル管理 （1）

システム評価の対象となった EV バッテリーライフサイクル管理に関する法制度上の論点につい

て検討した。

30 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（第三者提供時の確認・記録義務

編）」

51

計量法に係わる論点 1）

EV バッテリーの安全性の確保のため、製造、販売、流通、利用までのライフサイクル全体にわた

って、所有者の情報をブロックチェーンに記録し、管理する。 また、残存価値、利用予測をAIで解

析し、当該データをブロックチェーンに書き込み、活用する手法を検討した。

残存価値の活用にあたっては、ブロックチェーン上の書き込まれたデータの耐改ざん性のみな

らず、残存価値データの予測自体が正しいことが求められる。 適正な計量の実施の確保を目的と

した法令として計量法が存在するが、バッテリーの残存価値データの計測は、適用外と考えられる。

計量法施行令を改正してバッテリー残存価値予測エンジンを「特定計量器」に加えるべきか。加え

るとして、どのような規律（有効期間、検査受信義務等）を設けるべきか。あるいは、加えなくともよい

かという論点が存在する。

計量法は、計量の基準を定め、適正な計量の実施を確保する法律である（同法１条）。このため

に、取引もしくは証明における計量に使用され、又は主として一般消費者の生活の用に供される

計量器のうち、適正な計量の実施を確保するためにその構造又は器差に係る基準を定める必要

があるものとして政令で定めるものを「特定計量器」としている。この特定計量器は、国や自治体等

が精度を確認した計量器を使用すること等を義務づけることで、正確な計量を確保している。特定

計量器は、検定・検査の技術基準に合格し、証印が付されたものでなければ、原則、取引・証明に

使用できない。

特定計量器は、前述のように、その構造又は器差に係る基準を定める必要があるかどうかによっ

て判断される。その判断基準としては、「不特定多数の者における取引において当該計量器の値

をもとに取引がなされるもとにあるものかどうか（確認必要）」ということになる。このような観点からす

るときに、バッテリー残存価値自体については、基本的にこれをもとにした当該関係者が、みずか

ら判断をなせば、実際の利用については十分であり、不特定多数の者の取引のもとにされるという

要素は、非常に少ないことになるものと考えられる。

製造物責任に関する論点 2）

我が国において、スモン事件、カネミ油症事件などの深刻な危害が発生する事件が相次いだこ

と、また、国民生活重視、消費者重視の考え方が従来以上に強調されるようになったこと、製造業

者、消費者双方の自己責任原則の強化を求める声が強まったこと、ＥＣ指令により欧州諸国にお

いて製造物責任立法が進展したこと等を背景として、我が国においても製造物責任法の立法化を

もとめる声が強まったことから、平成６年に製造物責任法が成立した（施行は、平成７年７月）。同法

は、「製造物の欠陥により人の生命、身体又は財産に係る被害が生じた場合における製造業者等

の損害賠償の責任について定めることにより、被害者の保護を図」ものとしている（同法１条）。同法

において「製造物」とは、製造又は加工された動産をいい（２条１項）、「欠陥」とは、「当該製造物の

特性、その通常予見される使用形態、その製造業者等が当該製造物を引き渡した時期その他の

当該製造物に係る事情を考慮して、当該製造物が通常有すべき安全性を欠いていることをいう」と

定義されている（同２項）。開発時において「科学又は技術に関する知見によっては、当該製造物

52

にその欠陥があることを認識することができなかった」場合には、責任を負わないという開発危険の

抗弁が定められており、また、他の製造物の部品等として使用された場合においては、その「欠陥

が専ら当該他の製造物の製造業者が行った設計に関する指示に従ったことにより生じ、かつ、そ

の欠陥が生じたことにつき過失がない」場合には、責任を負わないという部品・原材料製造業者の

抗弁も認められている（同４条）。

中古品または再生品 については、それぞれ、「製造または加工された動産」にあたる以上は、製

造物であって製造物責任法の対象となる。ただし、中古品として売買されたものについては、①以

前の使用者の使用状況や改造・修理の状況が確認しにくいこと、②中古品販売者による点検、修

理屋整備などが介在することも多く、製造業者の責任の有無については、このような事情を踏まえ

て判断されることとなる。また、再生品については、再生品を「製造または加工」したものが製造物

責任を負うとされる。

中古車販売業者が、当該バッテリーを買い取り、他の中古 EV に組み込んで EV を販売したところ、

当該中古 EV との相性が悪かったがゆえに、あるいは中古車販売業者の組み込み作業が拙かった

がゆえに、その後に発火して損害が生じた場合、製造物責任の関係は、どうなるのか、という問題

がある 。

このような改造がなされた場合の責任問題は、どのようになるのか、という問題が存在する。「改

造」「改良」は、新しい属性がくわえられており、それ自体が、「製造または加工」に該当すると考え

られる。製造物責任法と改造が問題になった案件としては、東京地裁平成 24 年 12 月 21 日判決、

札幌高裁平成 14 年 2 月 7 日があるが、一般論としては、因果関係の問題として処理されている。

バッテリーが再販事業者に転売され、太陽光発電システムの蓄電池に組み替えられた場合にお

いては、その太陽光発電システムを製造したものが、同法における製造者となるのが原則と考えら

れる。ブロックチェーンを利用して移転先や利用方法等が記録されるシステムを構築した場合にお

いて、上記の解釈が影響を受けることは、実質的には、考えにくいものと考えられる。

電力融通取引 （2）

需要家（消費者）間で、スマートコントラクトを活用し、余剰電力を融通するシステムの実証実験

が進められようとしている。一方で、直接需要家間で電力を取引する場合、余剰電力を販売する消

費者（以下、「プロシューマー」という。）が電気事業法における小売電気事業者に該当し、現行法

では、直接取引することができないのではない、との意見が事業者から聞かれた。そこで、プロシュ

ーマーの小売電気事業者への該当性を検討するとともに、法の趣旨を踏まえつつ、電力融通取引

を実現するための制度の在り方について検討を行った。

ユースケース概要 1）

電力融通取引は、直接需要家間で太陽光発電等により発生した余剰電力、売買する仕組みで

53

ある。電力融通は、IT により電力潮流を制御するスマートグリッドなどの技術を用いて行われる。埼

玉県浦和美園地区において、東京大学等が実証実験を進められようとしており31、プロシューマー

と消費者間で電力を売買する市場を構築しようとしている。スマートコントラクトを活用することで、

自動的に電力を売買するができるようになることが期待されている。

図 9 電力融通決済取引の概念図32

プロシューマーの小売電気事業者への該当性 2）

電気事業法は、電気事業の運営を適正かつ合理的ならしめることによって、電気の使用者の利

益を保護し、および電気事業の健全な発達を図るとともに、電気工作物の工事、維持および運用

を規制するための法律である（同法１条）。そこでは、一般の需要に応じ電気を供給することを小売

供給といい、小売供給を行う事業（一般送配電事業、特定送配電事業および発電事業に該当する

部分に該当する部分を除く。）は、小売電気事業となる。そして、小売電気事業を営もうとする者は、

経済産業大臣の登録を受けなければならない（同法２条の２）。この登録を受けようとする者は、氏

名または名称および住所ならびに法人にあっては、その代表者の氏名、主たる営業所その他の営

業所の名称および所在地、小売供給の相手方の電気の需要に応ずるために必要と見込まれる供

給能力の確保に関する事項、事業開始の予定年月日、その他経済産業省令で定める事項を経済

産業大臣に提出すると共に、小売電気事業を適正かつ確実に遂行する体制の整備に関する事項

を記載した書類その他の経済産業省令で定める書類を添付しなければならない（同法２条の３）。

ブロックチェーンを用いて P2P 型マッチングおよび電力制御を実現することによって、市場原理

に基づく分散型対応の電力融通を実現する電力流通システムを構築するというプロジェクトを考え

た場合に、上記電気事業法の規定は適用されるのか、という問題がある。具体的な法律の解釈とし

ては、一般の家庭が、このシステムによって、電力を売る場合に、「一般の需要に応じ電気を供給

すること」に該当するのではないか 、ということである。

31 環境省「再エネ導入を加速するデジタルグリッドルータ（DGR）及び電力融通決済システムの開発・実証」 32 内閣府「環境エネルギー分野における Society 5.0 の実現に向けた各省庁の取組」

54

「電気事業者による再生可能エネルギー電気の調達に関する特別措置法」でもあきらかなように、

一般の家庭であっても、再生可能エネルギー発電設備を用いて再生可能エネルギー源を変換し

て得られる電気を供給する場合には、その供給先が、一般送配電事業者等であり、特定されてい

ることから、一般の需要に応じ電気を供給することには、該当しない。

その一方で、「一般の需要に応じ」電気を供給することとは、何かという問題がある。「一般」とは、

「不特定多数」をいうとされており、「不特定」、「多数」の基準は、社会通念上決せられるべきと解さ

れている33。本件では、最終需要家が一般消費者となるため、一般の需要に応じていると考えられ

る。特定の供給地点において電気を供給する登録特定送配電事業者は、「一般の需要に応じ」供

給していると整理されている。特定の場所で、任意の者が電力の供給を受ける可能性があるため

「不特定多数」つまり「一般の需要に応じ」ていると解されるのである。以上から、一般の需要に応じ

ておらず、小売供給にはならないとすることは、難しい。

次に、このような行為が、小売供給を行う「事業」といえるのかが問題となる。一般に、業とは、営

利目的をもって反復継続の意思を持って行うことをいい、電気事業法においても、「営利の意思を

持って反復継続して電気を供給することをい」い、「営利の意思の有無は、具体的事例に応じて総

合的に判断」34すると解されている。例えば、「自己の発生電力を供給する場合であって、供給の相

手方から、供給電気に対して何らかの対価を受け取ることを前提としている場合は、営利の意思が

あると解釈される」。一方、「電気の供給者が慈善事業として無料で電気を供給する場合、ビル・ア

パート等において、管理人が一括受電した電気をビル・アパート等の内に個別に取り付けたメータ

ーを通じて供給し、その対価が一括受電により支払った料金と同等の場合等は、『営む』ものでは

ないと解する」とされている。仮に当該ユースケースにおいて金銭的価値が低く、営利性がないと

整理した場合、当該ユースケースは社会実装を進めるためのインセンティブ設計が出来ていない

ことになる。

以上のように、現行の法の解釈を前提とする限りでは、小売電気事業とせざるをえないものと考

えられる。

電力融通取引の社会実装に向けた規制緩和の在り方 3）

上述の通り電力融通取引を行う場合、現行法の枠組では、プロシューマーが行う電力融通は小

売電気事業に該当すると考えるほかなく、各プロシューマーによる小売電気事業者としての登録が

必要となる。社会実装を進めるためには、法改正する必要がある。その際、法改正を行う意義があ

る事業となっていなければならない。そのためには、自営線により小規模な範囲で実証実験を実施

することは可能ではあるが、範囲を拡張して実証実験を行う必要があると考える。実証実験を行わ

なければ電力の安定供給といった技術的な問題の検証ができず、不特定多数の需要家への電力

融通サービスの普及に向けた法制改正の議論や事業性の評価ができないためである。そこで、閣

議決定された「規制のサンドボックス」の活用を念頭におきつつ、実証実験を行うために必要な制

33 資源エネルギー庁電力ガス事業部、原子力安全・保安院編 『2005 年版電気事業法の解説』35 頁 34 資源エネルギー庁電力ガス事業部、原子力安全・保安院編 『2005 年版電気事業法の解説』139 頁

55

度の在り方を検討した。

■基本的な考え方

プロシューマーを小売電気事業者としない場合、電力の安定供給や需要家保護など、小売電

気事業を登録制とした法の趣旨に反する事態が生じる可能性がある。一方で、現行法の下では、

個人であるプロシューマーに、事業者と同程度の義務を課すこととなり、電力融通取引を利用する

インセンティブが発生しない。そのため、法の趣旨に反しない範囲において、電力融通取引を実現

する方策を考える必要がある。そこで、本調査研究では、小売電気事業者の基本的な枠組は維持

しつつ、プロシューマーの義務を緩和するための方法の検討を試みた。なお、次の図表に掲げる

「準分散型」のサービス形態を想定し、プロシューマーと準分散型の運営主体との役割分担につい

て検討する。

表 3 運営主体によるブロックチェーンのシステムの分類

■プロシューマーと運営主体の役割分担

現行法の枠組の中で、消費者保護という法の趣旨を踏まえつつ、プロシューマーに対する義務

を緩和し、実証実験を実施するための、制度の在り方について検討した。

① 小売電気事業の登録

プロシューマーが登録を個人で行うとした場合、手続が煩雑なため、サービスを利用しなくなる。

そのため、特定の運営主体が取りまとめて、登録の手続を行うのが望ましい指摘がある。

② 供給能力の確保

（ご参考）プラットフォーマー

準分散型分散型（Dapps）

物理的な取引あり 仮想世界に閉じた取引

シェアリングの対象 全般 モノ モノ、労働力 モノ、カネ

運営主体 特定の主体 特定の主体 オープンなコミュニティ オープンなコミュニティ

具体例 Uber（ライドシェア）、Airbnb（民泊）

電力融通取引（うらわ美園実証実験） 等

Lazooz（ライドシェア） 等 計算資源のシェアリング※仮想通貨（ビットコイン）

特徴 ルール形成 運営規約等によりルール形成

特定の運営主体が決定（コミュニティによることも可能）

コミュニティにより合意形成 コミュニティにより合意形成

参加 個別の契約 個別の契約 オープン オープン

マッチング・執行 参加者が意思によりマッチング

スマートコントラクトによる自動的なマッチング・執行

スマートコントラクトによる自動的なマッチング・執行

スマートコントラクトによる自動的なマッチング・執行

役務、物、価値等の移転

システム外で移転 システム外で移転 システム外で移転 システム内で移転

取引後の対応（苦情への対応、モニタリング等）

対応可 対応可 対応不可 対応不可（ただし、ルールが強制されるため、対応する必要性があまりない）

運営者のマネタイズ 取引手数料、登録料等 取引手数料、登録料等（中央集権的なプラットフォーマーに比べて安価）

トークンの価値上昇によるリターン

トークンの価値上昇によるリターン

56

基本的には、供給能力確保の義務は小売電気事業者（プロシュマー）が負うものである。小売電

気事業者（プロシュマー）が供給できない場合、系統運用者である一般送配電事業者が補充する

こととなる。そのためには、一般送配電事業者が調整電源を複数抱えていなくてはいけない。この

際発生するコストは、最終的には、託送料という形で電気料金に計上される。このため、安定供給

を担う一翼として、小売電気事業者（プロシュマー）としても自らの需要家に応じるだけの供給能力

が求められている。

一方で、太陽光等の余剰電力が生じた場合には、プロシューマーとして融通するが、自身の電

力が不足した場合で他のプロシューマーから融通を受けることが出来ないときは、消費者として既

存の小売電気事業者から供給を受けるという方法がありうるのではないか。

③ 供給条件の説明等

基本的には、供給条件の説明は、プロシューマーの負担にならない。アプリケーション上で説

明を行うのであれば、負担にならないと考えられる。説明事項には、定型化できるものが含まれて

おり、あらかじめ、雛形を作成し、実装することが有用ではないか。

④ 苦情等の処理

他のシェアリングサービスについて、法令等で苦情対応を義務付けているものがあり、本件につ

いてもプロシューマーが苦情を受け付けるべきである。また、特定の運営主体が、消費者団体から

の苦情受付窓口を設置しておくことが望ましいのではないか。

⑤ 広域的運営推進機関への加入義務

当該機関への加盟費は、現行水準では取引量に見合わない額である可能性が高い。多頻度小

額取引を想定している参加者について、新たな価格設定を設けることを検討するがよいのではな

いか。支払いは、個々のプロシューマーが行うのではなく、運営主体がまとめて行うのが望ましいの

ではないか。

⑥ 事業を休廃止する際の需要家に対する周知義務

消費者がサービスを辞める場合に、休廃止したことについて、周知することは通常期待できない。

一定期間取引がない場合には、休廃止したものと見做し、特定の運営主体が取りまとめて周知す

るのが有用ではないか。（スマートコントラクトにルールを記述し、条件が満たされた場合に、自動

的に周知するという方法も存在する。）

その他、託送料金の負担については、実証実験の結果を踏まえ、必要に応じて、見直しを行う。

57

58

システム構築に必要となる要素技術 4．

4.1． ブロックチェーンの課題と解決技術

今日、ブロックチェーンは主に仮想通貨分野で広く実用的に使用されているが、ニュースで連日

取上げられるように、解決されるべき課題は多い。また、仮想通貨以外でも、金融、流通、IoT、パ

ーソナルデータ管理などの分野で活用できる技術であると言われているが、従来の中央集権的な

信頼を前提としたシステムとの考え方の違いなどから、実用化にはさらに多くの課題が存在する。

本章では、これらの課題を挙げ、解決のための技術とあわせて示す。課題の提示順序は、「平成

28 年度我が国におけるデータ駆動型社会に係る基盤整理(ブロックチェーン技術を活用したシス

テムの評価軸整備等に係る調査)調査報告書」で挙げられているブロックチェーンシステム評価項

目を参考に、次の 3 種類に分類する。

(1) 性能効率性

(2) 保守・運用性

(3) セキュリティ

なお、スマートコントラクト関連の課題と解決技術については、上記の評価項目に分類するよりも、

まとめた方が理解しやすいため、「スマートコントラクト」として別に分類する。

また、以降で説明する解決技術の成熟度はさまざまである。そこで、それぞれについて成熟度

に応じて次のように 3 種類のラベル付けを行った。

ラベル 説明

[実用] 製品化あるいはサービス化が行われ、実用段階にある技術

[研究] 論文発表が行われているが、製品化およびサービス化が行われていない、研究段階の技術

[構想] 査読付きの論文発表は行われていないが、ホワイトペーパーは発行されている等の、構想段階

の技術

4.2． 性能効率性

● 高速化

ブロックチェーンは従来の中央集権的システムに比べ、処理速度が低い。例えば、もともとのビッ

トコインのブロックチェーンのスループットは最大毎秒 7 トランザクションである。性能改善のために、

さまざまなアプローチが試みられている。

・ 台帳外取引

ビットコインやイーサリアムに代表されるパブリック型ブロックチェーンでは、主に仮想通貨の投

資目的とみられる取引の増加に伴い、トランザクション量が増大している。これにより、トランザクショ

59

ンの遅延や破棄、手数料の増大などが問題になっている。そのため、台帳に書き込むトランザクシ

ョン量を抑制する方法の 1 つとして、取引当事者間で台帳に記載しない複数回の取引を行い、そ

の結果をまとめて台帳に記載する方式が検討されてきた。この考え方に基づいて、ビットコイン向け

にはライトニングネットワーク[35,36] [実用]、イーサリアム向けにライデン[3]37 [実用]の開発が行われて

おり、これらを用いた実サービスもはじまった。

・ アルゴリズムの改善

台帳外取引はブロックチェーンの使い方の改善だったが、ブロックチェーンのアルゴリズム自体

を改善する方法も提案されている。シャーディングと呼ばれる方法では、ノードをグループ分けし、

複数のグループで同時並行にトランザクションを処理し、最後に担当グループがそれらをまとめて

台帳に記録する[38]この方式を用いて、ZILLIQA は 3600 ノードで 6 つのグループを形成し、毎秒

2488 取引処理を実現した[39] [研究]。

・ トラステッドハードウェアの活用

ソフトウェアの工夫だけでなく、新しいハードウェアを利用したアルゴリズムの改善策も提案され

ている。近年の汎用プロセッサが備えるトラステッドハードウェアを活用することによって、より高速

で頑強な合意形成アルゴリズムを構成できる。コンソーシアム型ブロックチェーンで利用できる以前

から知られた合意形成アルゴリズムとして、PBFT[1]がある。これを踏まえた MinBFT と呼ばれる方式

は、トラステッドハードウェアを活用して、PBFT よりも高速な合意形成を実現する。合意形成に参加

するノードが、理由が悪意か故障かによらず、合意形成を妨げるメッセージを発信した場合（ビザン

チン障害）に、そのことを受信者が容易に検知できる仕組みを、トラステッドハードウェアを用いて構

成する。これにより、合意形成に必要な通信回数を減らしている。加えて、MinBFT では PBFT に比

べ、頑強性が向上している。PBFTでは参加ノードの 1/3未満までのノードがビザンチン障害を起こ

しても合意形成が可能だが、MinBFT ではさらに多い 1/2 未満までのノードのビザンチン障害にも

対処できる[2] [研究]。

・ 台帳データサイズ

ブロックチェーンでは新しいブロックが漸増的に追加され、台帳のデータサイズが増えていく性

質がある。参加者(ノード)は仕様上、すべての台帳を保持することが必須ではないことが多いが、

すべてを保持した方が台帳データの必要な部分を逐次ダウンロードする方式に比べ性能面で有

35 Poon and T. Dryja, “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, available

electronically at https://lightning.network/lightning-network-paper.pdf

36 “ ラ イ ト ニ ン グ ネ ッ ト ワ ー ク 始 動 Blockstream が オ ン ラ イ ン ス ト ア を オ ー プ ン ” (2018),

https://btcnews.jp/196kpru614701/ (accessed: 2018.03)

37 https://raiden.network/ (accessed: 2018.03)

38 Lui et al., “A Secure Sharding Protocol For Open Blockchains”, ACM CCS’16 (2016).

39 https://www.zilliqa.com/keynote.html (accessed: 2018.02)

60

利になる。そのためブロックチェーン技術の誕生初期のころから台帳データの増大に伴い、ストレ

ージを圧迫することが懸念されてきた。そしてこれが現実となりつつある。

例えば、ビットコインのデータサイズは 2017 年に前年比で約 1.6 倍増え、149GB になっている[40]。

イーサリアムの場合は 2017 年 9 月 2 日から 2018 年 2 月 5 日までの間にデータサイズが約 2.3 倍

に増加している[41]。将来的にストレージコストの増加によりノードの維持を辞退する参加者が続出

すれば、ブロックチェーンそのものの改ざん耐性などが脅かされる可能性がある。

今後、スマートコントラクトや人工知能技術の普及に伴い、IoT デバイス間の自動取引などにより

トランザクションが多数発生することが予想される中、ブロックチェーンに記載するデータを最小限

にとどめ、記載しないデータは外部のクラウドなどにデータベースを持つなど新しい枠組みの設計

が必要である。現在、この考え方にもとづいたブロックチェーン技術の開発が行われている。[42]

[研究]

4.3． 保守・運用性

● ランタイム展開の容易性とデータ秘匿性のトレードオフ

ブロックチェーンは新しい技術であり、頻繁にソフトウェアのバージョンアップが行われる。そのた

め、運用者は頻繁に新たな実行ファイルを展開する必要がある。ランタイム(実行ファイルおよびデ

ータファイル)の展開を容易に行うためには、仮想マシン技術や Docker などのコンテナ技術が有効

である。

これら仮想化技術を活用する際の利便性は、データ秘匿性とトレードオフの関係にあることに注

意が必要である。仮想マシンおよびコンテナ内のデータはホストから秘匿されない。特にこれら仮

想化技術をクラウド上で動作させる場合は、クラウド事業者にも仮想マシンおよびコンテナ内のデ

ータが見えてしまう。ブロックチェーンに記録するデータの開示範囲を限定したい場合には、暗号

技術など、ホストからデータを秘匿する手段について考慮が必要である。[構想]

● ブロックチェーンが脆弱化した際の運用継続性

ブロックチェーンは、信頼できる中央の管理者がなくても信頼性や可用性を維持する仕組みを

備えているが、それでも信頼性や可用性が急激に低下する可能性も考えられる。

例えば、マイニング報酬の下落などにより、ノード管理者のモチベーションが低下すると、参加ノー

ド数が大幅に減り、その結果、合意形成が特定の勢力に支配されやすくなる恐れがある。

また、ブロックチェーンが使用しているハッシュ関数や暗号方式の脆弱性が発見されたり、量子コ

ンピュータの発達に伴い公開鍵暗号アルゴリズムが危殆化したりすると、ブロックチェーンの安全性

40 https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/ (accessed: 2018.03)

41 https://etherscan.io/chart2/chaindatasizefast (accessed: 2018.03)

42 https://blockstack.org/whitepaper.pdf (accessed: 2018.03)

61

が一挙に損なわれることが懸念されている。[43, 44]

そこで、ブロックチェーンを使ったサービスを安定的に運用するために、ある方式のブロックチェ

ーンを利用中のアプリケーションが、異なる方式の別のブロックチェーンに無停止で移転できるよう

にする仕組みが提唱されている[45,46] [構想]。これが実現すれば、あるサービスが利用中のブロック

チェーンが脆弱化した際には、そのサービスを、世の中に複数あるパブリック型ブロックチェーンの

うち、まだ脆弱化していないものに移転させることで、運用継続性を維持できる。[図 9]

図 10 ミドルウェア導入によるブロックチェーン脆弱化対策

4.4． セキュリティ

● プライバシー保護

ビットコインのブロックチェーンでは、台帳のデータを誰でも読めるため、台帳のデータが正しく

導出されていることを誰でも確認できる。一方で、台帳のデータを秘匿することは難しい。ブロック

チェーンのユースケースによっては、台帳のデータに個人情報や企業秘密が含まれることがある。

そこで、コンソーシアム型ブロックチェーンの実装例である Hyperledger Fabric v1.0 においては、デ

ータの正しさを確認するノードと、データの順番を保証するノードに役割分担をし、データの順番を

保証するノードには必ずしもデータを見せないようにすることもできる[47] [実用]。あるいは、サテライ

43 D. Aggarwal et al., “Quantum attacks on Bitcoin, and how to protect against them” (2017), arXiv:1710.10377v1

44 M. Sato and S. Matsuo, “Long-term public blockchain: Resilience against Compromise of Underlying

Cryptography” EuroS&PW (2017).

45 https://blockstack.org/whitepaper.pdf (accessed: 2018.03)

46 https://beyond-blockchain.org/public/bbc1-design-paper.pdf (accessed: 2018.03)

47 http://hyperledger-fabric.readthedocs.io/en/release/Fabric-FAQ.html (accessed: 2018.03)

62

トチェーンと呼ばれる方式で、チェーンを 1 つにするのではなく、取引の関係者だけがそれぞれチ

ェーンを構成する方式も提案されている[48] [研究]。

その他、既存の暗号プロトコル技術を使って、ブロックチェーンには暗号データと、その暗号データ

を正しく処理したことを示すゼロ知識証明を記載して、データの正当性を担保する方式も存在する

[49] [実用]

● ノード管理者の ID 管理、アクセス制御

あるノードがブロックチェーンへ参加する際には、別の信頼できるノードを発見する手段が必要

である。これは非中央集権なブロックチェーンネットワークにおいては難しい問題である。

パブリック型の場合には、参加者をすべて把握する必要はないが、最初のノードを自力で見つける

ブートストラッピングが必要である。例えばビットコインでは、ノード実装プログラムのコードに DNS

Seed と呼ばれる文字列がハードコードされており、DNS サーバに問い合わせることで最初のノード

の IP アドレスを取得することができる。[実用]

コンソーシアム型の場合には、あらかじめ誰がブロックチェーンに参加しているかというノード情報

を、PKI 基盤などを用いて管理する必要がある。例えば、Hyperledger Fabric v1.0 では、ID 管理を

行うメンバーシップサービス[50]として、参加ノードの管理や証明書の発行を行う Hyperledger Fabric

CA サーバが想定されている。一方で、この CA サーバにノードを参加させたり、脱退させたりする

権限が集中してしまうという懸念がある。

● 鍵管理

ブロックチェーンの台帳のデータは、正当性を保証するために電子署名が付与される。

ブロックチェーンの台帳にデータを書き込む際には、書き込みを行う参加者の電子署名の秘密鍵

が必要となる。暗号通貨の場合、その秘密鍵を管理・保管するアプリケーションや、デバイスを総称

し、ウォレットと呼んでいる。

ウォレットには大きく 2 種類があり、「秘密鍵を保持するアプリケーションやデバイスが常にインタ

ーネットに接続されているホットウォレット」と「インターネットから隔離されているコールドウォレット」

がある。[実用]

ホットウォレットでは、秘密鍵へのアクセスが容易で、ユーザにとってはトランザクション作成など

が迅速にでき、利便性が高い。しかし、ネットワークにつながっていることによって、サイバー攻撃で

秘密鍵が盗まれてしまう可能性がある。秘密鍵が他人にわたると勝手になりすまされ、トランザクシ

48 W. Li et al., “Towards Scalable and Private Industrial Blockchains”, ACM BCC’17 (2017).

49 E. Ben-Sasson et al., “Zerocash: Decentralized Anonymous Payments from Bitcoin”, IEEE, 459-474 (2014). 50 Membership Service Providers (MSP) http://hyperledger-fabric.readthedocs.io/en/release/msp.html (accessed:

2018.03)

63

ョンを作成できてしまう。それにより、もともとの秘密鍵保持者が不利益を被ることになる。例えば、

仮想通貨の場合には資産が流出する[51]。

コールドウォレットでは、秘密鍵を紙に記載するペーパーウォレット[52]や、デバイス上に鍵を保存し、

デバイスを接続したときのみ使用可能なハードウォレット[53,54]などがある。オフラインのため、ネット

からのハッキングなどの脅威から、自分の秘密鍵を守ることができる。しかし、トランザクション作成

時などには、秘密鍵を保存したペーパーウォレットやデバイスなどが必要となり、手動操作を挟むこ

とから利便性に課題が残る。印刷した紙やデバイスをなくしてしまうと秘密鍵を復元できず、資産が

使えなくなる可能性がある。

重大な取引を行う秘密鍵はコールドウォレットで管理を行うなど、アプリケーションによって秘密

鍵の管理方法は考えていく必要がある。例えば、1 つの秘密鍵を複数に分散し、その中のいくつか

を集めることで秘密鍵を使用できる秘密分散法[55]などを用いて、鍵の紛失やハッキングなどへの

対策が考えられる。暗号通貨では、トランザクションへの電子署名の付与数を決める機能として、マ

ルチシグという仕組みがあり[56]、2 つ以上の秘密鍵を用いた電子署名を付与することを選択し、必

要な秘密鍵がすべて漏えいしない限り、資産の流出を防ぐような対策も考えられる。[実用]

● パーソナルデータ管理

欧州の一般データ保護規則(GDPR)策定などにみられるように、世界的に個人情報保護の意識

が高まっており、さらに、個人情報は本人主導でデータ管理するパーソナルデータストア(PDS)の

構想が広がっている[57] [研究]。その際、誰のデータを誰に見せてよいか、という「誰」を表現するた

めに、集中管理ではない ID 管理が必要になり、その実現にブロックチェーンを活用する試みがは

じまっている。現在、Sovrin Foundation では、個人の ID と個人の PDS の場所をブロックチェーン上

で管理することが議論されている[58]。これにより、個人が管理している自身に関する情報を、必要

に応じて他者にアクセス権限を付与してデータ共有することができる。個人情報を保管するパーソ

51 「コインチェック 580 億円分流出 顧客資産返せぬ恐れ」日本経済新聞 2018/1/27 付

https://www.nikkei.com/article/DGKKZO26234720X20C18A1MM0000/ (accessed: 2018.03)

52 BitcoinWalletPaper.com https://bitcoinwalletpaper.com/ (accessed: 2018.03)

53 トレザー https://zaif.jp/trezor (accessed: 2018.03)

54 Ledger Nano S

https://hardwarewallet-japan.com/a/?a8=o5a7254SMX8GEu_8IW6DuXacZWTtAIgBdS88XuBKkDAgftaRFXa

BhXTR65a7ds00000015669002 (accessed: 2018.03)

55 Adi Shamir:How to Share a Secret. Commun. ACM 22(11): 612-613 (1979)

56 アンドレアス・M・アントノプロス 著 今井崇也/鳩貝淳一郎 訳 「ビットコインとブロックチェーン 暗号通貨を支え

る技術」 第 4 章

57http://www.glocom.ac.jp/wp-content/uploads/2016/12/20170125mydata1_hashida.pdf (accessed: 2018.03)

58 “Sovrin: A Protocol and Token for Self-Sovereign Identity and Decentralized Trust” (2018)

64

ナルデータストア(PDS)の安全性やデータへのアクセス制御を向上させる技術の開発が必要であ

る。

図 10 は自身の健康データを Sovrin の考えにもとづいたパーソナルデータストアで管理した場合を

表している。

図 11 健康データのブロックチェーンへの保存

図 12 ブロックチェーンに保存された健康データの開示先を特定して開示

65

● 実世界との紐づけ

ブロックチェーンは、データがいったん台帳へ書き込まれたら、改ざんが困難であることが大きな

特徴である。しかし、間違って誤ったデータが入力されることや、意図的に改ざんされたデータがブ

ロックチェーンに入力された場合、ブロックチェーン上のデータといえども信頼ができなくなる。ビッ

トコインやイーサリアムのように、バーチャルの世界でのデータのやり取りの場合、入力データには

デジタル署名が付与されるため、その署名者が意図した入力データだとみなされる。署名用の秘

密鍵が漏えいして悪用された場合には、その署名鍵の所有者になりすましてデータ入力が行われ

てしまう。あるいは、入力ミスや入力デバイスのバグにより、意図しないデータが署名付きでブロック

チェーンに記載されてしまう場合がある。これらについては、鍵管理の項で述べたように、ウォレット

をはじめとした入力デバイスを堅牢に開発する必要がある。

一方、物理世界の人や物に関するデータをブロックチェーン上で管理する場合は、そのデータが

実社会の何に紐づいているデータであるのかを明確にし、適切に保護された状態で入力される必

要がある。ユースケースによっては、どのような状況でこのデータが入力されたのかを管理すること

も必要である。

例えば、センサーなどの IoT デバイスが人間を介さずに直接ブロックチェーンにデータを記録す

る場合を考える。上述のように、ブロックチェーンにいったん記載されたデータは改ざんが極めて困

難であるが、適切なデータが入力になるようデバイスを管理する必要がある。具体的には、デバイ

スが故障したり、デバイスの出力結果がハッキングにより不正に操作されたり、あるいは関係のない

デバイスの出力を取り込まないようにする必要がある。対策としては、センサーなどの IoT デバイス

に IDと署名鍵と検証鍵を付与し、デバイスからの出力データにデジタル署名を付与することが考え

られる。これにより、デバイスのなりすましやデータ改ざんを防止することができる。この場合も、IoT

デバイスから秘密鍵が漏えいしないよう、デバイスの物理的なタンパーレジスタンスを担保する技

術が必要である[59] [実用]。ハッキング対策としては Intel SGX[60]、ARM TrustZone[61]など、プログラ

ムを安全に実行するトラステッドハードウェアが実用化されている[実用]。

サプライチェーン管理のように、物の移動をデータとして管理する場合には、どの物品のデータ

であるかを紐づける必要がある。実用的には、その物品を一意に識別できるように、バーコードや

RFID などの IC タグ[62]を付与し、リーダーでその値を読み取ってブロックチェーンに記載することが

考えられる。例えば、商品の作成工程や流通情報の管理などを行うことで、真偽判定などをブロッ

クチェーン上で管理するサービスが提供されている[63] [実用]。

59 https://www.intel.co.jp/content/www/jp/ja/support/articles/000007452/mini-pcs.html (accessed: 2018.03) 60 Anati et al., “Innovative Technology for CPU Based Attestation and Sealing” (2013) 61 https://www.amd.com/ja/technologies/security (accessed: 2018.03) 62 DENSO RFID とは https://www.denso-wave.com/ja/adcd/fundamental/rfid/ (accessed: 2018.03)

63 MANICA ブランドプロテクション|RFID とブロックチェーンのあなたの商品を守ります。

http://www.hayato.info/brandprotection/index.htm (accessed: 2018.03)

66

必要に応じて、読み取り時にリーダーのデジタル署名を付与すれば、より確実にデータを保護でき

る。物品を識別する方法には、バーコードや IC タグなど、外から ID を与える方法以外にも、物質そ

のものの個体差を画像によって識別する物体指紋認証など[64]を使うことも考えられる。この方式は、

バーコードやRFIDがはがれてしまったり、悪意を持ってはがしたり、付け替えられたりする不正にも

耐えうる方式になる。

パーソナルデータをブロックチェーンで管理する場合には注意が必要である。ブロックチェーン

に記録したデータは書き換えることも削除することも困難なため、GDPR などで求められているパー

ソナルデータの消去手段をすぐには提供できないからである。このような場合には、パーソナルデ

ータそのものをブロックチェーンに書くのではなく、そのハッシュ値のみをブロックチェーンに記載し、

パーソナルデータが改ざんされたかどうかの判定にのみ使うことが考えられる。

一方で、ブロックチェーン上のトランザクションデータが、本当にそのユーザ本人の意図でなされた

トランザクションなのかどうかを確認することが必要になる場合が出てくるであろう。その場合、ビット

コインやイーサリアムのように、単にデジタル署名の有無のみならず、その署名鍵の持ち主が、実

社会の具体的な人物と紐づくことを保証する必要がある。

具体的には、その秘密鍵を格納しているデバイスがユーザ認証をしないと稼働しない、といった仕

組みを設けることができる。ユーザ認証の手段としては、パスワード認証や生体認証が考えられる。

現在、顔、指紋などの生体情報[65]を利用した認証方法で本人を識別することができる。生体認証

を用いて秘密鍵を格納しているデバイスのユーザを認証するのではなく、生体情報から電子署名

を作成する基盤を用いたブロックチェーン基盤の開発が行われている[66] [実用]。

4.5． スマートコントラクト

スマートコントラクトとはブロックチェーン上で動作するコンピュータプログラムである。スマートコント

ラクトのプログラムコード(コントラクトコード)は、それ自体がブロックチェーンに書き込まれ、ブロック

チェーン外からの入力を契機として起動し、ブロックチェーンの値を読み書きすることができる。

利用者はそのコントラクトコードを読んで中身を理解し、行われる処理について合意したうえで実行

することが前提となっている。

64 模造品を 1 秒で鑑定！「物体指紋認証」

http://jpn.nec.com/info-square/solution-report/industrial_iot/06.html (accessed: 2018.03)

65 NEC の顔認証技術 http://jpn.nec.com/biometrics/face/index.html (accessed: 2018.03)

66 ブロックチェーンにおけるセキュアな取引を実現する生体認証技術を開発

http://www.hitachi.co.jp/New/cnews/month/2017/10/1005.html (accessed: 2018.03)

67

● 理解が容易なスマートコントラクト

例えば企業間で取引する際、現在は自然言語による契約書を交わしているが、これをスマートコン

トラクト化することにより、ブロックチェーンの特性(透明性、耐改ざん性)を活かした確実な契約の執

行が行えるようになることなどが期待されている。

しかしながら現在、一般にコントラクトコードは、自由度は高いが、学習コストが高いプログラミング

言語で作成される。ある契約書が妥当かどうかを判断するには、自然言語で書かれていれば契約

分野の業務知識があればよかったが、スマートコントラクトではそれに加え、情報科学の知識とプロ

グラミング言語の知識が必要になる。そのような知識を備えた人材は少なく、雇用や育成に多大な

コストが発生する。そのことが、スマートコントラクト活用の妨げになる、あるいは、知識の差を利用し

て詐欺的なスマートコントラクトに合意させ、不正に利益を得るものが現れることが予想される。

よって、「スマートコントラクトで記述する典型的な処理」を、プログラミング知識が少なくてもより直感

的に分かりやすく記述できるフレームワークやドメイン特化言語(DSL)が必要になってくると考えら

れる。典型的な処理には、例えば所有権の移転や所有権の交換などがある。そのような DSL の例

として Hyperledger Composer[67]がある。[実用]

● 高品質なスマートコントラクト開発

The DAO 事件では、ブロックチェーンプログラミングに精通した多数の関係者がテストおよびレビュ

ーしたにも関わらず、脆弱性を発見できず、大きな影響を及ぼした[68]。スマートコントラクトは直接

財産を扱うことが多く、稼働すると停止できない性質を持つものが多い(止めるだけなら技術的には

容易だが、契約を一方的に破棄することになる)ため、品質についてより考慮する必要がある。

未知の脆弱性に対処するのは容易ではないが、形式検証などの手法の導入によってある程度発

見することが可能だと考えられる。既知の脆弱性に対しては静的コード検査や典型的な脆弱性を

まとめたドキュメント(Ethereum Smart Contract Security Best Practices[69]など)を活用することにより

対処することができる。[構想]

「理解が容易なスマートコントラクト」の項で述べたフレームワークや DSL の導入、あるいは

OpenZeppelin[70]のような高い安全性を目指して開発されたオープンソースライブラリの活用により、

難易度および自製コード量を減らし脆弱性を減らすことも重要である。また、開発環境・テスト手法

67 https://hyperledger.github.io/composer/ (accessed: 2018.03)

68 http://tech.nikkeibp.co.jp/it/atcl/column/14/377135/062000008/ (accessed: 2018.03) 69 https://consensys.github.io/smart-contract-best-practices/ (accessed: 2018.03)

70 https://openzeppelin.org/ (accessed: 2018.03)

68

などを充実させることにより開発効率を上げることも対策になる。[構想]

● スマートコントラクトの配備・更新

パブリック・ブロックチェーンでスマートコントラクトを運用する際には、スマートコントラクトを更新す

る方法について考慮が必要である。利用者はスマートコントラクトのコードを読み、そのロジックによ

って引き起こされる内容に合意したうえで実行しているという前提がある。そのため、利用者に気付

かれず勝手にロジックを変更することが可能な構造であると、前提が崩れてしまう。

パブリック型ブロックチェーンの実装の 1 つであるイーサリアムでは、スマートコントラクトを更新する

仕組みが基盤として存在しない。スマートコントラクトのコードに不具合があり、修正したコードを反

映させるには、インストールし直すしか方法がない。これは利用者に気付かれずにロジックを更新

することを不可能にしている[実用]。しかし、再インストールした場合、スマートコントラクトを一意に

表すアドレスが変更されるため、新しいアドレスを利用者すべてに通知する必要がある。これは一

般的に現実的ではない。

そのため、スマートコントラクトの構造を工夫し、トランザクションを直接受け付けるアドレスが不変な

コントラクト(メインコントラクト)と、再インストールによりアドレスが変更しうるコントラクト(ロジックコント

ラクト)に分離し、メインコントラクトはロジックコントラクトのアドレスを変数として保持して、トランザク

ションをロジックコントラクトにディスパッチする手法[図 12]が提案されている[71]。コントラクト管理者

はメインコントラクトの持つロジックコントラクトのアドレスを変更することでディスパッチ先を変更でき

る。

71 https://blog.zeppelin.solutions/proxy-libraries-in-solidity-79fbe4b970fd (accessed: 2018.03)

69

図 13 メインコントラクトとロジックコントラクトを分けて、スマートコントラクトを更新する

しかし、この仕組みだけだと、コントラクト管理者は利用者に気付かれずにロジックを変更できてしま

う。なんらかの方法で、ロジックが変更された際に、利用者が気づかずに有効なトランザクションをコ

ントラクトに送信してしまわないような仕組みが必要である。 [構想]

4.6． 用語集

「3.3.システム構築に必要となる要素技術」での用語説明を以下に示す。

用語 説明 参照情報

DNS サーバ 主にインターネットで名前解決を行うサーバ。入力としてホスト

名と呼ばれる文字列を受け取り、それに対応する IP アドレスを

出力する機能を持つ。

-

Docker コンテナ技術の 1 つ。オープンソースソフトウェアの多くは

Docker 用のイメージファイル(実行ファイル、ライブラリ、データ

ファイル、環境設定などがまとめられたファイル)が提供されて

いる。これらイメージファイルをそのまま、あるいはプロジェクト

に応じたカスタマイズを行って使用することにより、オープンソ

ースソフトウェアの評価・開発・実行環境を簡単に作成できる。

[1]

[1]

https://www.docker.com/

Ethereum スマートコントラクト機能を持つオープンソースのブロックチェ

ーン技術の 1 つ。インターネット上に誰でも参加できるネットワ

ークが存在し、その意味ではパブリック型に分類できるが、限

られたメンバーしか参加できないコンソーシアム型の標準[2]お

よび実装[3]も存在する。

[1]

https://www.ethereum.org/

[2]

https://entethalliance.org/

[3]

https://www.jpmorgan.com/

global/Quorum"

70

用語 説明 参照情報

Hyperledger

Fabric

IBM が提案したスマートコントラクト機能を持つオープンソース

のコンソーシアム型ブロックチェーン技術の 1 つ。[1]

[1]

https://www.hyperledger.org

/projects/fabric

PBFT 最初の実用的なビザンチン障害耐性のある合意形成アルゴリ

ズム[1]。参加者が固定されていることを前提にしているため、ノ

ードが自由に出入りできないコンソーシアム型ブロックチェー

ンに用いられる。

[1] Castro and Liskov,

“Practical Byzantine Fault

Tolerance”, ACM Trans.

Computer Systems, vol. 20,

no. 4, 398-461 (2002).

PKI 基盤 PKI 基盤とは、使用する公開鍵暗号や署名鍵の公開鍵の持ち

主が誰であるかを保証する仕組みである。

インターネット上で公開鍵暗号技術などを用いる際に、通信先

が本当に本人かを確認することは難しく、なりすましなどが考

えられる。そのため、認証局(CA、Certification Authority)とい

う第三者機関が公開鍵の持ち主を保証する仕組みが必要と

なる。既存の PKI 基盤では、認証局は悪意のある改ざんなど

を行わない信頼できるものと想定している。

-

アドレス ブロックチェーン技術においてアドレスとは、なんらかの主体を

一意に指し示す識別子のことである。多くのパブリック型ブロッ

クチェーンにおいて、公開鍵から変換されるアドレスは、公開

鍵に対応する秘密鍵を知っているユーザを指し示している。

加えて、イーサリアムではアドレスによりスマートコントラクトも指

し示す。

-

形式検証 数学や論理学にもとづいてソフトウェアなどの仕様記述、開

発、検証を行う技術のことを形式手法と呼ぶ。形式検証とは、

形式手法によって、ソフトウェアなどが正しいか、あるいは正し

くないかを検証することである。

-

合意形成アル

ゴリズム

P2P ネットワーク上で暗号化技術などを駆使し、通信のみで安

全に合意を形成するためのアルゴリズムを合意形成アルゴリ

ズムと呼ぶ。ブロックチェーンでは各ノードが同じ状態を持つ

ために合意形成アルゴリズムが用いられる。

-

公開鍵、秘密

鍵

電子情報に対して暗号化する公開鍵とそれを復号する秘密

鍵が非対称な暗号方式のことを指す。

複数の暗号方式が存在するが、どの公開鍵暗号も、一方向か

らの計算は求められるが、逆からの計算が非常に難しいとされ

る数学的に難しい問題を応用して作られている。この難問の

計算時間は、現在のスーパーコンピュータなどを使用しても何

万年も必要とするとされており、その難しさによって安全性が

担保されている。

-

コンソーシア

ム 型 ブ ロ ッ ク

チェーン

ブロックチェーン技術のうち、ノードとして参加するために特定

の人や団体などからの承認が必要なものを指す。承認が必要

なことにより、ノード数がある程度限定されるため、PBFT のよう

な合意形成アルゴリズムを使用できる。

-

71

用語 説明 参照情報

コンテナ技術 ファイルシステムやプロセス、ネットワークなどを隔離することに

よってアプリケーション単位の仮想環境を実現する技術。基本

的にホストと同じ OS しか使えないが、従来の仮想化技術に比

べて起動が速く、ハードウェア資源のオーバーヘッドが小さ

く、非仮想化環境に比べた性能劣化もほぼない、というメリット

がある。

-

静的コード検

査

あるプログラムコードを、そのプログラムコード自体を実行せず

に、ツールなどを用いて検査する技術。

-

ゼロ知識証明 ゼロ知識証明とはある命題が真であることを、真という情報以

外を開示せずに証明する手法である[1]。これを使うと、ある公

開鍵に対して、秘密鍵を知っていることを、秘密鍵に関する情

報を一切もらさずに証明できる。1985 年に Goldwasser らにより

定式化され[2]、重要な暗号技術の 1 つになっている。

一般的に、検証者側は、秘密情報を知らないと答えられない

質問を証明者へ投げかけ、証明者は返答を行う。

検証側は質問の回答のみを受け取り、秘密情報に関する知

識を一切得ることはできない。

[1] 光成滋生「クラウドを支え

るこれからの暗号技術」第 14

章ゼロ知識証明

[2] Shafi Goldwasser, Silvio

Micali, Charles Rackoff:

The Knowledge Complexity

of Interactive Proof-Systems

(Extended Abstract). STOC

1985: 291-304

電子署名 電子署名とは、電子情報の作成者を証明する暗号技術であ

る。

文書作成者は、ある文書に対し、秘密鍵を用いて署名を作成

し、元の文書と一緒に送信する。検証者は、署名者の公開鍵

を用いて、署名を復号することにより、文章が改ざんされてい

ないことと、作成者が署名者であることを検証できる。

-

ド メ イ ン 特 化

言語

ある特定の領域の問題に特化したコンピュータ言語。特化領

域については C++、Java、Go のような汎用コンピュータ言語に

比べ、簡単に記述することができる。

-

トラステッドハ

ードウェア

悪意のあるコードからソフトウェアを保護する機能を提供する

ハードウェア。その 1 つである Intel SGX は OS からもアプリケ

ーションを保護することができる。[1]

[1] Aumasson and Merino,

"SGX Secure Enclaves in

Practice: Security and

Crypto Review ",

Blackhat'16 (2016)

ハッシュ関数 ハッシュ関数とは、任意の入力値からハッシュ値と呼ばれる出

力を生成する演算手法。同じ入力値に対して、必ず同じハッ

シュ値が生成されるという性質を持つ。ハッシュ値から入力値

を求めるのが困難な性質を一方向性と呼び、同じハッシュ値

になる 2 つの入力値を求めるのが困難な性質を衝突困難性と

呼ぶ。暗号分野ではこの 2 つの性質を持つハッシュ関数が多

く用いられる。主に文書など電子データの改ざん検知などに

応用されている。

-

72

用語 説明 参照情報

パ ブ リ ッ ク 型

ブ ロ ッ ク チ ェ

ーン

ブロックチェーン技術のうち、ノードとして参加するための条件

が存在せず、誰でも参加可能なものを指す。悪意を持ったも

のを含む不特定多数のノードがいつでも参加および離脱が可

能である。

-

ビザンチン障

害耐性

複数のノードが協調して動作する分散システムにおいて、ノー

ドに障害が起きた際、そのノードが単に停止して無反応になる

場合は、これをクラッシュ障害と呼ぶ。一方、それ以外の任意

の振舞いをする場合には、ビザンチン障害と呼ぶ。ビザンチン

障害が起きても、そのようなノードの数がアルゴリズムに設定さ

れた一定数を超えなければ合意形成を行える性質を持つア

ルゴリズムをビザンチン障害耐性のある合意形成アルゴリズム

と呼ぶ。

-

ビットコイン 2008 年に Satoshi Nakamoto によって提案された初めてのブロ

ックチェーンによる非中央集権的仮想通貨。

-

量子コンピュ

ータ

粒子の量子力学的な振る舞いである状態の重ね合わせや量

子もつれ現象を用いる計算機。従来の計算機の 1 ビットは 0

か 1 のどちらか 1 つの状態しか取れないが、量子ビットはその

両方の重ね合わせ状態を取り得る。これによって、複数の状

態の処理を一度に行うことができる[1]。まだ、実用段階に至っ

ていないが、ショアアルゴリズム [2]により素因数分解を高速に

行うことが理論的に示されている。これは、素因数分解問題の

困難さに安全性の根拠を置く公開鍵暗号基盤の危殆化につ

ながるとされ、代替方式が盛んに研究されている。上記の量子

ゲート方式とは別に組み合わせ最適化問題の解探索などに

特化した量子アニーリング方式の計算機も量子コンピュータと

呼ばれており、両者が混同されがちである [3] 。カナダの

D-Wave 社などが実現しているのはこの量子アニーリング方式

の量子コンピュータである。この方式を用いた計算機ではショ

アアルゴリズムに対応するアルゴリズムは見つかっていない。

[1] 宮野健次郎、古澤明 著

「量子コンピュータ入門」

[2] P. W. Shor,

"Polynomial-Time

Algorithms for Prime

Factorization and Discrete

Logarithms on a Quantum

Computer", SIAM J.

Comput. 26(5), 1484-1509

(1997).

[3]

http://ascii.jp/elem/000/00

1/451/1451932/

73

まとめと今後の検討課題 5．

以下では、第 2 章から第 4 章までのまとめおよび今後の検討課題を記す。

5.1． システム評価軸の運用方法、ビジネス面での検討課題

システム評価軸の運用方法 1）

今回のシステム評価において各ユースケースのシステム要件を網羅的に洗い出すためにシステ

ム評価軸を用いた。他のユースケースにおいても同様にシステム実装の際の要件定義にシステム

評価軸は活用できるものと考える。

多様なステークホルダーが関与する場合の社会実装の推進 2）

平成２８年度我が国におけるデータ駆動型社会に係る基盤整備においても指摘されているが、

社会課題解決の取組みを行うためには、産官学による連携の拡大やコンソーシアムによる異業種

連携を推進していく必要がある。ユースケースとして取上げた、治験管理システムなど公的機関が

係わる利活用に関しては、公的機関の積極的な参加が求められるとことである。また、EV バッテリ

ーライフルサイクル管理のユースケースのように、IoT デバイス等の機器からデータを取得する場合、

国際標準化に向けた官民連携が必要となるだろう。

5.2． 法制度面の検討課題

「分散型システム」の導入を阻害する規制の緩和に向けた検討 1）

電力融通取引について、現行法の解釈を明らかにするとともに、実証実験の実施に向けた法精

度の在り方を検討した。「規制のサンドボックス」等を活用した実証実験を推進することが望ましい

のではないか。また、実証実験等の結果を踏まえた法改正等に向けた検討を実施していき、ブロッ

クチェーンの社会実装を後押ししていく必要がある。

法解釈や実運用上の指針の策定 2）

本調査研究では、スマートコントラクトの証拠能力等の法解釈、実運用するうえでの法制度上の

留意点等について、検討を行った。明示的な承諾を必要としないが、サービスやシステムの約款、

利用にあたっての契約、社会的な共通理解などにより、合意がなされることが契約成立にあたって

重要であるとの検討がなされた。スマートコントラクトに関する社会的な共通理解等を高めるために

も、政府又は民間団体等が指針を策定することが有用だと考える。

74

トークンを用いた権利移転の対抗要件 3）

トークンに記録された所有権と実態として占有が乖離するという問題について、更なる検討が必

要と考えられる。今後の借地借家法、動産及び債権譲渡特例法等の特例法の制定等に向けた検

討が必要との指摘があった。また、特例法を制定しないまでも、登記所のシステムから API で登記

の情報とトークンの記録を相互に更新していくことで、登記とトークンの記録を一致させ、結果として

第三者への対抗要件が具備されるという方法も検討の方向性として考えられる。登記所ではない

が、電子記録債権機関において、ブロックチェーンの導入に向けた実証実験が進められており、

最終的に API を提供することが検討されており、今後の取組として参考になると考えられる72。なお、

合意した形跡があり、特殊な場合を除いてスマートコントラクトが実行されると権利移転する、という

ことが言えればよいといった指摘もある。このように、法改正のみならず、オープンデータ等の取組

を推進してくことで、ブロックチェーンの社会実装を後押することも重要であると考える。

ユースケースの蓄積に合わせた継続的な法制度の検討 4）

責任主体が存在しない Dapps について、十分に普及しているユースケースが少なく、法制度上

の検討が十分に出来ているとはいえない。ユースケースの動向を踏まえつつ、法解釈や実運用上

の取り組みについて更なる議論が必要である。

なお、上記全ての検討課題に共通するが、国際的な契約が容易になっている現状に鑑み、法

制度の枠組みの議論に日本としてどのように参加していくのが課題となる。

5.3． 技術面の検討課題

ブロックチェーンは、金融、流通、IoT、パーソナルデータ管理などの分野で活用できる技術であ

ると言われているが、従来の中央集権的な信頼を前提としたシステムとの考え方の違いなどから、

実用化にはさらに多くの課題が存在している。本章では、これら課題を挙げ、解決のための技術と

あわせて示した。

72 株式会社 NTT データ「「～「でんさいネットシステム」におけるブロックチェーン技術の利用可能性を検証～」

< http://www.nttdata.com/jp/ja/news/release/2017/103100.html >

75

（参考資料）ブロックチェーン法制度検討会について 6．

経済産業省 委託調査

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

ブロックチェーン法制度検討会（医療・介護・ヘルスケア分野）

（第 1回）

議事録

日時 2015 年 11 月 28 日（火） 15:00-17:00

場所 経済産業省別館 3 階 310 各省庁共用会議室

構成員

株式会社日本医療機器開発機構

取締役 CBO

委員 A

渥美坂井法律事務所・外国法共同事業

弁護士

委員 B

特定非営利活動法人ヘルスケアクラウド

研究会 理事 医薬学博士

委員 C

駒澤綜合法律事務所 弁護士 委員 D

国立研究開発法人国立国際医療研究センター

国際医療協力局 グローバルヘルス政策研究センター

（iGHP） 特任研究員

委員 E

オブザーバー サスメド株式会社 代表取締役 委員 F

経済産業省 商務情報政策局 情報経済課 委員 G

委員 H

日本電気株式会社 事業イノベーション

戦略本部 FinTech 事業開発室

委員 I

事務局

株式会社日本総合研究所

委員 J

委員 K

委員 L

委員 M

敬称略

76

1. 議事

(1) 議題

(1)ブロックチェーン法制度検討会について

(2)医療・介護・ヘルスケア分野における国内のブロックチェーン活用事例

(2)-1 諸外国におけるブロックチェーンの活用事例

(2)-2 国内におけるブロックチェーンの活用事例

(2)-3 ブロックチェーンを活用した治験データの共有（サスメド様）

(3)ブロックチェーンの社会実装に向けた法制度上の論点

(4)質疑応答

(2) 配布資料

資料 1 議事次第

資料 2 出席者一覧

資料 3 ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 1 回

事務局資料

資料 4 サスメド様ご発表資料「ブロックチェーン技術を用いた臨床開発システム」

2. 議事要旨

(1) 議題

(ア) ブロックチェーン法制度検討会について

株式会社日本総合研究所（以下日本総研）より、資料 3「ブロックチェーン法制度検討会 （医療・

介護・ヘルスケア分野）第 1 回 事務局資料」を用いて、経済産業省「平成２９年度我が国における

データ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」の背景・目的、法制度検討会（医療・介護・

ヘルスケア分野）の開催要綱、スケジュールについてご説明した。

(イ) 医療・介護・ヘルスケア分野における国内のブロックチェーン活用事例

日本総研より、資料 3「ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 1 回 事

務局資料」を用いて、「諸外国における医療・介護・ヘルスケア分野のブロックチェーン活用事例」

としてアメリカ、オーストラリア、フランス、台湾の事例等をご説明した。

日本総研より、資料 3「ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 1 回 事

務局資料」を用いて、「国内におけるブロックチェーンの活用事例」として治験管理、診療情報共有、

保険金支払いに関する事例等をご説明した。

(ウ) ブロックチェーン技術を用いた臨床開発システム

サスメド株式会社（以下サスメド）より、資料 4「ブロックチェーン技術を用いた臨床開発システム」を用

77

いて、取組事例、医薬品・医療機器開発における課題、現在認識している法制度上の課題につい

て説明された。

(エ) ブロックチェーンの社会実装に向けた法制度上の論点

日本総研より、資料 3「ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 1 回 事

務局資料」を用いて、医療・ヘルスケア分野におけるブロックチェーンの活用に係わる法令及び論

点についてご説明した。

■質疑応答

資料 4（P.8）で「モバイル医療」とあるように、“医療”という言葉を用いているが、“ヘルスケア”では

なく、“医療”という言葉を使用したのは意図があるのか、逆に問題提起なのか、お聞かせいただき

たい。（委員 D）

本件は医療機器として開発している。厚生労働省にも、今回サービスを行うのは治療行為にあたる

ことを確認した。薬機法の規制対象である。我々としては、PMDAの規定に基づき、治療機器として

認めてもらうようにしている。そのため、今回は医療データを扱っているという表現としている。（委

員 F）

プログラム医療機器のなかで、医療従事者同士での情報共有等のサービスが広がっている。これ

は、院内のみで利用可能な、イントラネットを活用しているサービスが主である。医療機器メーカー

はこのような ICT メーカーを買収している状況だが、これを横展開する際、彼らが動きやすいような

環境を作れるとよいと考えている。（委員 A）

医療分野のなかでも、ブロックチェーン導入の障壁が低い領域・高い領域があると考える。ベストプ

ラクティスが作りやすい部分から着手するのがよいのではないかと考える。（委員 C）

我々も医薬品等はハードルが高いと考え、単独で出来るデジタル医療から着手した。今後、医薬

品評価等に横展開していければと考えている。（委員 F）

トランザクション量が多い場合に、ブロックチェーン導入にあたってのニーズが多いという見方があ

り、そのような観点で言えば、MRI 等の画像を機械学習に用いるケースなどはニーズが高いと考え

られる。ただし、画像の内容によっては単体で個人情報とならず、これも踏まえると相対的にニーズ

が低いと考えられる。一方で遺伝情報であれば、発生するトランザクションの量としては少ないが、

情報がセンシティブであるため、ブロックチェーン技術を活用するニーズは高いように思われる。ま

た、議論にあたっては実証実験等の具体的な事例があれば、よりイメージがわきやすいと考える。

（委員 A）

資料 4（P.10）の図があるが、データを入力する部分に関しては、ブロックチェーン技術はどのよう

に係わっているのか。（委員 A）

今回検討しているシステムは、例えば血液データを分析し、それが電子カルテに登録されるような

78

ものは扱っていない。今回扱っているのは、患者自身が入力する医療情報である。不眠症の重症

度は国際的な基準があり、患者自身が入力することで取得できる情報である。（委員 F）

今回のサービスでは全ての治験が適用できるものではなく、主観的な評価で出来る、一部のもの

のみである。将来的には IoT 機器などからデータを吸い上げて統括することで、客観的なデータも

取れるだろうと考えているが、現在検討しているシステムは主観的なデータになる。（委員 F）

今回はあくまで治験で使うということだが、病院のカルテシステムとの連携は考えていないのか。

（委員 E）

カルテ分野には参入しないと決めている。これには以下の２点の理由がある。

・現状の日本国内のカルテに統一性が無いため

・ブロックチェーン技術自体が未成熟だと考えているため

現在のブロックチェーンを用いたシステムにおいて、トランザクションの捌き具合は全国の電子カル

テデータを扱えるレベルではないと思っている。またデータ量に関しても、現状の技術は CT など

の画像データはおそらくそのままではブロックチェーンに書き込めず、ハッシュ化してサイズダウン

したデータを格納することが必要となる。このような様々複雑な問題があるので、今回はｎ数が限ら

れ、かつ、電子カルテとの関連性が無いという観点で対象を選定した。（委員 F）

今回のシステムは重要情報インフラとなり、サイバーセキュリティという部分は必ず入ってくる。事業

者、医療機関等、色々なステークホルダーが入ってくる。このようななかで、誰が調整役を担うのか、

という部分の議論は避けられない。イノベーションを支援するためには、枠組みを作らないと進まな

い。（委員 C）

サイバーセキュリティの部分は、委員 C 先生にご相談したいと感じていたところである。海外の事情

を見ると、米国 HIPAA 法への対応が必要になると感じている。その際、小さい日本のベンチャー

の場合は、まず AWS を用いることとなってしまう。そうなると海外のサーバーとなるので、日本国内

の医師会はかなり反発するだろう。内部でサーバーを立てて HIPAA 法対応となると大変な問題に

なってしまう。その部分について、本当は整備する必要があるとは思っている。（委員 F）

セキュリティの人材育成についても大変ではないかと思っている。サービス提供分野の人材育成と、

医療分野の人材育成をどうリンクさせるかということが、おそらくは結構大変な課題ではないか。実

臨床の方々はほとんど分からない方が多いだろう。（委員 C）

物理的に遮断するようなものが、おそらくは実臨床側の考え方になっている。（委員 F）

具体的なセキュリティという部分で、今回のケースで、ブロックチェーンをこういった臨床データの共

有に使っていこうとした時に、具体的にどういったセキュリティ上の問題が発生するものなのか。（事

務局・委員 K）

実際は、ブロックチェーンの中身よりは、そこに紐付けられているデータのセキュリティ基準と、ブロ

ックチェーン側の基準にかなりギャップが出てくると思われる。その差をどう埋めていくのかという点

79

がかなり困難である。特に、関わる事業者が、金融・医療・通信のどの事業者なのかにより、それぞ

れの規制が関わることとなる。本来業務のプラスαでブロックチェーンを取り扱うと、本来業務固有

の規制が掛かることがある。（委員 C）

金融業界は社会的信頼があることから、セキュリティのインフラをどうにか活用できないかと考える。

但し踏み込みすぎると、銀行法の外の話になってしまう。金融の係わりが入ると、金融庁と調整を要

することとなる。（事務局・委員 J）

おそらく、保険会社が医療分野のブロックチェーン技術に最も関心を寄せるのではないか。（委員

C）

医療との関わり方という点でいうと、保険、信託系、銀行が関心を寄せているようである。（事務局・

委員 J）

リモートでモニタリングを行おうという潮流は 10 年前からある。医療機関の入力が正しいかを確認

することをリモート SDV（ソース・データ・ベリフィケーション）というが、10 年ほど整備の取り組みが

あるものの、実用化に至っていない。最大の理由は、医療従事者がそれに対応できる専門家がい

ないことにある。グローバルでは、医療機関側にもそのような対応が整っているが、日本では難しい

ため、技術はあっても諦めざるを得ない状況。（委員 A）

医療の現場に現業プラスαの対応を求めると、セキュリティ以上に、非常に反発を受けるという実

感がある。（委員 F）

サービスのなかで、メッセンジャーや LINE などのプラットフォームを用いる場合、API 連携等が生じ

ることとなる。そのなかで、どこからどこまでが医療機器の部分で、ツールの部分としての責任分解

はどこになっているか等の法的な論点が生じる。クライアント側に脆弱性があったらどうなるか、API

を呼び出す部分が脆弱ならどうなるか等が、セキュリティ分野で現実的に課題となるだろう。IoT 機

器のセキュリティの問題と同じことがブロックチェーンにおいても問題となるのではないか。（委員

D）

ブロックチェーンで担保されるものと、ブロックチェーンの外側にあり担保できないものがある。認証

の部分は外側なので、そこは別途セキュリティ面の対応が必要になってくると考える。（委員 F）

アクセス管理の部分が肝になってくると考えている。そこを乗っ取られてしまうと、何でもできてしまう。

（委員 C）

クライアントサーバーモデルも、アクセス権限をしっかりしないといけない。病院内は閉域網で構成

されているだろう。この治験データをブロックチェーンで行うとなった場合、アクセス権限の管理をよ

り一層、しっかり行わないと、リスクが大きくなる。いろいろなステークホルダーに情報がどんどん漏

れてしまうことが起きるということか。（事務局・委員 K）

医療機関やベンチャーが自前でやるのは無理なので、レグテックのサービス業者が入り、提供とい

った形になると思う。サービス事業者をどうチェックするか。そういったところで、医療機関やベンチ

80

ャーに負荷をかけないようにすること、サービス事業者をどう育てるかということが、ポイントとなると

考える。この点については経済産業省の担当領域かと考える。（委員 C）

最終的には誰がこのブロックチェーンのシステムを管理するべきと考えるか。（事務局・委員 K）

ベストな形態は、最終的には、政府機関が 1 個のノードとして入ることではないか。例えば、PMDA

がノードを 1 個持っていて、そのブロックチェーンのネットワークに他の製薬企業が入る等を想定す

る。政府機関が閲覧できる形にしておき、少なくとも認証が済んだノードについては、信頼性が担

保されている状態にできるとよいが、認証の部分は課題があるだろう。（委員 F）

そうした場合、PMDA としても管理が必要になり、仕様変更がある時にも、ノードへチェック機能を

入れるということか。（委員 B）

PMDA と IBM は、そういった部分を目指して行っているのではないか。（委員 F）

ガバナンスの構造は課題になると考える。ビットコインなどでも、パワーがある者が特定な場所に固

まっていると、恣意的なハードフォークが起き得るように、恐らく管理する存在をどのような形で組み

込むかが課題と考える。（委員 B）

ノードの１つとして政府機関を入れるという話が挙がったが、製薬会社の業界団体等、纏めている

組織がガバナンスを効かせる主体となっていくということか。（事務局・委員 K）

それも考えられる。ブロックチェーンの場合は、ゲーム理論により、利益関係がある組織がお互い

に牽制する構図を作ることで、信頼性を担保することができると考えられている面がある。（委員 B）

最終的に政府機関が 1 個のノードとして入った場合、費用負担はどのように考えられるか。（委員

B）

CRO を労働集約的に行う場合との差分で、利益が浮くと想定して、製薬会社に負担してもらうこと

などを考えている。（委員 F）

事業者が実際にサイバー攻撃にあった時に、インシデント対応をどうするのかという体制は作って

おく必要がある。その時に、誰に連絡して、同時に患者に通知するのか。ルールの設定は必要に

なってくる。医療だけは事例がないので、他の業界を見て設定する必要があると思っている。（委員

C）

このような問題を考える際は、基本的にどういうドメインごとに、法的な問題点があるのかを分析する

手法がよいと思われる。今回については３つあり、第一には、医行為独占の観点である。ソフトウェ

アとして扱ったときに、医行為の医師の独占という観点があるため、どこが医療行為の部分なのか、

そこの部分にブロックチェーンが関わることで限界が生じるかということを考える必要がある。第二に、

安全の観点。安全の観点は 2 つあり、1 つ目は、サイバーセキュリティ関係で、通信が絡むというこ

とによって、安全が犯されるという問題。2 つ目には、医療機器に該当した場合には、人の生命、身

体その他に対しての危害が加わる可能性があるため、そのレベルをどうするかという点が挙げられ

る。更に、それを医療機器としての安全基準で事前にどう定めるか、ブロックチェーン技術がそれ

になじむのか、といった問題が出てくる。第三が、一般社会との関係。個人情報保護関係、保険が

81

どのように係わるのか、他の分野はどうか。このように分野ごとに分けて整理していくと、漏れなく問

題点が意識されて、きちんと適切に分析できるのではないかと思っている。（委員 D）

他の業種と共通化して出来ることと、出来ないことと分けて考えること。（委員 C）

他の業種となると、金融関連分野は関わりが強いと考える。将来的には街づくりに広げようとされて

いる、保険分野の実証実験の事例があり、これは委員 D 構成員が前述したのその他一般社会との

関係という論点となる。このような場合には社会的信頼をおけるような組織を、ある程度チェーンの

なかに組み込めるかどうかが肝要となる。（事務局・委員 J）

医療情報について、登録制度等があった方が信頼性が向上するという可能性もある。民間事業者

がこのようなデータを持っていることについて、消費者のなかには不安を覚える層もいると思われる。

銀行法をとってみても、政府の承認があるという意義がある。規制を重くする・軽くするかは別として、

何らかの法規制を設けることで、より社会実装が促進されるという見方もある。（委員 B）

銀行が信頼される背景には、銀行法の厳しい規制が挙げられる。（事務局・委員 J）

個人的にあまり賛成ではないが、次世代医療基盤法を用いて、認定された事業者であれば、匿名

化された医療情報を利用可能であるため、これを活用するという方法もある。また、臨床研究法・薬

機法との兼ね合いで、ブロックチェーン技術を利用するシステムが問題ないかを考える必要がある。

（委員 E）

医療専門職は無限責任で守秘義務を負っているため、そうでない方の責任をどうするかといったと

いう問題がある。チーム医療で行ったときに、職種により責任の違いをどのように扱うかが課題にな

る。（委員 D）

ブロックチェーン技術を用いる場合、ノードをあとから追加する場面が想定されるため、情報の

受け渡しは共同利用でなく第三者提供という整理になると考える。また、規制は 1 つの主体がコント

ロールすることを前提としている一方で、ブロックチェーン技術を用いたシステムではなじまないよう

に思われる。従来の規制を参加者全員に課してしまうということもあるかもしれないが、このような部

分が課題になると考える。（委員 B）

要配慮個人情報はオプトアウトによる第三者提供ができないなかで、同意をあらかじめ取得する必

要があるが、ブロックチェーンにノードが都度追加されるなかで適切に遂行できるかは難しいように

思われる。（事務局・委員 K）

第三者提供ではなく、委託として整理可能であるように思われる。（委員 E）

医療機関を主体とした場合、委託としてみる可能性も検討できるが、その場合は委託先管理を行う

必要がある。その場合は情報の共有先がブロックチェーン上に追加された場合についても検討が

必要となる。（委員 B）

この点について、自主的な監督が出来るのかという観点で判断することが必要であるように思われ

る。（事務局・委員 K）

82

ノードとしてどの組織が想定され、初期から加入している組織、主体となる組織がどこかを整理して

議論することが必要であるように思われる。（事務局・委員 J）

分散管理にあたっては、最終的に誰が責任を持つかという点が大きな課題になるように思われる。

民間事業者の実証実験の事例を見ると、どの組織が主体となるか明示しているケースは少ないが、

これは民間事業者としても、どの組織を主体とすべきか判断がつかないのではないかと想定する。

そのようななかで、法制度上としては、どのような組織が担うべきかを示すことが好ましいと思われる。

（事務局・委員 K）

医療機器というよりは、プログラム医療機器となると思うが、目的によって変わると考える。診療に利

用するかどうかで変わる。また、アプリ側で課金を行い、保険適用になっていないと、混合診療の禁

止が適用されると思われる。この部分は慎重に進める必要がある。（委員 B）

ブロックチェーンのシステムと一口と言っても、それぞれ大きく差異があるため、サービスモデル毎

に前提を整理して法制度について議論していきたい。（委員 D）

サスメドの事例では、医療機器等法、プログラム医療機器への該当性等に照らして特段の問題が

生じないのではないとお考えか。（事務局・委員 K）

省令等について、そこまで記載されていないのが実態であり、そのように考えるほかないように思わ

れる。（委員 E）

過去エンタープライズ系のサービスを検討した際に、ガイドラインにはどの程度遵守していると宣言

すべきかが難しいと感じた。医療機関からは、関連法規を遵守するという旨を伝える以上は求めら

れないようにも思われた。（委員 A）

国内でスタートする分には、問題ないように考える。情報漏えい等、有事の際に、ガイドラインを守

っていたかどうか議論となるように思われる。（委員 E）

実際の開発イメージにあたって、現状ではマイクロソフトや IBM がブロックチェーンの OSS を出し

ているがこれを活用するのか。（委員 D）

OSSの開発自体は社として現在着手しても、どこかに淘汰されると考え、既存の OSS を活用してい

る。今回は、基本的にオープンにする必要性がないため、プライベートなブロックチェーンネットワ

ークを用いている。これにより、個人情報の保護などにおいても、配慮ができるかと考えている。（委

員 F）

OSS は、かなり乱立しているが、開発者の活動等を見ると桁違いの差異が見られる。IBM の開発

数は国内の OSS 開発者と比べると桁違いに多いため、ブラッシュアップされるのだろう。（委員 F）

ベンチャー育成の観点から言うと、ベンチャーは、今までに無かったことをやることになり、メリットも

リスクもある。その責任が全部ベンチャーにかかるとなるとイノベーションは起きないため、ベンチャ

83

ーのリスクをどう減らすかが課題となる。（委員 C）

ベンチャーにのみ責任を負わせるべきでないという問題がさまざまな分野で出てきている。そのよう

な場合に、そこを担保できるような産業界側の枠組みがどうであるかは、ひとつの問題提起になると

考えている。また、最初の資金調達にも関わってくる。（委員 C）

ロボット手術のデータ、患者のデータはどのように活用されるかという点も関心を集めている。手術

支援ロボット「ダヴィンチ」が話題になっているが、手術情報は、皆で共有されるべき情報ではない

かと考えている。（委員 D）

資料 3（p.7）にも事例を掲載しているが、医療機器は 2018 年以降活用されると予想している。諸外

国でも活用が期待されている。（事務局・委員 K）

経済産業省として、ブロックチェーン技術を用いたサービスの事業主体に対して、支援を行う予定

であるか。（事務局・委員 K）

民間事業者で検討が進んでいるという印象を受けており、規制改革等、制度面について、必要が

あれば支援を行っていくべきと考えている。（委員 G）

サスメドのサービスでは、社会実装にあたり、さまざまなステークホルダーとの調整が必要となるもの

であり、その調整を政府機関に実施いただきたいといった話も受けているが、いかがか。（事務局・

委員 K）

特に医療の場合には、国の認証がボトルネックとなるものであり、ご協力いただきたい。（委員 F）

関連する機関へ話をするような場を作ることは出来ると考えている。（委員 H）

以上

84

経済産業省 委託調査

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

ブロックチェーン法制度検討会（医療・分野）

（第 2回）

議事録

日時 2018 年 1 月 17 日（水） 15:00-17:00

場所 経済産業省本館 17 階委員 O5 第 4 共用会議室

構成員

株式会社日本医療機器開発機構 取締役 CBO 委員 A

渥美坂井法律事務所・外国法共同事業 弁護士 委員 B

特定非営利活動法人ヘルスケアクラウド研究会 理事 委員 C

国際大学グローバル・コミュニケーション・センター 研究部長 委員 D

駒澤綜合法律事務所 弁護士 委員 E

森・濱田松本法律事務所 弁護士 委員 F

国立研究開発法人国立国際医療研究センター

国際医療協力局 グローバルヘルス政策研究センター（iGHP）

特任研究員

委員 G

一般社団法人ブロックチェーン協会 委員 H

オブザーバー サスメド株式会社 代表取締役 委員 I

経済産業省 商務情報政策局 情報経済課 課長 委員 J

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 K

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 L

経済産業省 商務情報政策局 情報経済課 係長 委員 M

日本電気株式会社 事業イノベーション戦略本部

FinTech 事業開発室 委員 N

事務局 株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ 主席研究員 委員 O

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 P

株式会社日本総合研究所 リサーチ・コンサルティング部門

戦略コンサルティンググループ 通信・メディア・ハイテク戦略クラ

スター

委員 Q

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 R

敬称略

85

3. 議事

(3) 議題

(1)ブロックチェーン法制度検討会 第１回の振り返り

(2)治験マネジメントにおけるブロックチェーンの活用

(2-1)ユースケースの概要

(2-2)企業治験に関わる論点

(2-3)質疑応答

(2-4)医師主導型臨床研究に関わる論点

(2-5)質疑応答

(3)電子カルテの共有におけるブロックチェーンの活用

(4)質疑応答

(4) 配布資料

資料 0 議事次第

資料 0 出席者一覧

資料 1 ブロックチェーン法制度検討会（医療・介護・ヘルスケア分野）第２回事務局資料

参考資料１．厚生労働省「医薬品等の承認又は許可等に係る申請等における電磁的記録及び電

子署名の利用について（ＥＲ／ＥＳ指針）」

参考資料２．厚生労働省「『治験関連文書における電磁的記録の活用に関する基本的考え方』の

一部改正について」

参考資料３．厚生労働省「『医薬品の臨床試験の実施の基準に関する省令』のガイダンス」

参考資料４．臨床研究法施行規則（案）

4. 議事要旨

(2) 議題

(ア) ブロックチェーン法制度検討会 第 1 回の振り返り

株式会社日本総合研究所（以下日本総研）より、資料 1「ブロックチェーン法制度検討会 （医

療・介護・ヘルスケア分野）第 2 回 事務局資料」を用いて、前回の議論内容について、振り返

りを行った。

(イ) 治験マネジメントにおけるブロックチェーンの活用（企業治験に関する論点）

日本総研より、資料 1「ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 2 回

事務局資料」を用いて、治験マネジメントにおけるブロックチェーンユースケースの説明、およ

び、企業治験に関する論点をご説明した。

■論点 1 「プログラム医療機器等の適用関係」について

86

今回サスメド株式会社が取り組まれているシステムについては、個人情報についてはブロックチェ

ーンに書き込まない、ということで間違いないか。（委員 P）

今回は、個人が特定できない情報のみをブロックチェーンに記録することになっている。個人を特

定できる情報は、病院のカルテで臨床試験の ID を振って紐づく形としている。（委員 I）

治験参加者の居住地、年齢、性別等についても書き込まないのか。（委員 E）

そのような項目についても、ブロックチェーン上には書き込みを行わず、病院のカルテのみに記録

している。（委員 I）

治験参加者本人は、治験データへのアクセスや、データによって対価を得ることはできないのか。

（委員 D）

治験参加者個人のスマートフォン端末からブロックチェーンへアクセスすることは出来ず、中継サ

ーバーを経由する仕組みとするため、インセンティブ設計については検討していない。治験に参加

すること自体について、研究協力費という形で金銭的な対価は支払っている。（委員 I）

データ共有と個人情報の問題については、これまで証券業界において、ブロックチェーンでデータ

を管理するときに、どういった点に注意すべきか、議論がなされている。解釈の方向性についてこ

の議論を医療分野に適用することで、多くの課題が解決できるのではないかと考える。誰かのデー

タと紐づく時点で個人データと扱われる中で、提供に当たっての留意点等が議論されている。（委

員 F）

■論点 2 治験関連文書の「交付」について

過去に、クラウド、特にパブリッククラウドを社会実装していく際に、同様の論点について「このように

解釈することが可能」と既に整理されているため、参考になることが多いと思われる。論点 2 につい

ては、医療・介護・ヘルスケア分野に限った話ではないため、ブロックチェーン法制度検討会の横

断的分野の回で取り上げると良いのではないか。（委員 F）

GCP 省令第一号イに関して、P2P システムにより治験関連文書を同時送信的に共有する場合で

あっても、誰が受信者で、誰が送信者かは実態としては明らかなのではないかと考える。治験のマ

ネジメントであれば書き込むのが SMO であり、読み取るのが CRO であるため、SMO が CRO に

送信したように見え、GCP 省令第一号イには該当するように解釈できるかと思われるが、いかがか。

（事務局・委員 P）

IT 書面一括法（書面の交付等に関する情報通信の技術の利用のための関係法律の整備に関す

る法律）にも似たような記載がされている。ブロックチェーン上でシェアをすることは、ある場所に格

納されているデータを参照しにいくことと同義だということを確認できればよい。（委員 F）

ブロックチェーン上のデータ共有に当たってのルールを整備するとなると、業界共通のルールを設

け、その上で個別の業種に関するルールを設けるという設計がよいと考える。（委員 C）

87

医療分野以外の分野、金融分野等でも検討されているか。（事務局・委員 P）

例えば、中央管理者がアカウントという名の下でデータを管理し、データを共有している状況で、ア

カウントがデータを持っていると言えるのかという問いが立つ。フランスは金融分野、有価証券のペ

ーパレス化でこの点について議論がなされ、立法で対応したが、本質的には他の分野の問題でも

同じ問題が生じうる。一定の要件を満たせば個別に列挙されていなくとも構わないのではないかと

いう議論ができるのではないか。本論点についても同様で、ガバナンスの問題、リスクの問題は整

理されており、こういった条件であれば既存のものと同様に考える、ということが言えればよいと考え

られる。（委員 F）

ブロックチェーン固有のリスクを洗い出し、それぞれについて制度的な対応をすべきか、リスクはあ

るけれども既存のクライアント･サーバーシステムと大きく変わらないと考えるか、他の要素で補完で

きるか等を考えられると良いと理解した。（事務局・委員 P）

ブロックチェーンと電子分散台帳技術に関する国際標準化について、検討状況はどのようになっ

ているか。（委員 F）

金融分野での国際標準化の検討についてはあまり進んでいないと聞いている。（委員 B）

情報経済課で検討しているが、現時点で具体的な動きとはなっていない状況73。（委員 L）

どのようにすれば実務の方が先行しているという状況を作れるか、という点がポイントであるように思

われる。クラウドの場合、規格が整備され、その規格に適している製品が広まっていったという経緯

を辿っていたが、規格整備を待っていても時間が掛かるため、進め方には検討が必要。（委員 F）

「治験関連文書における電磁的記録の活用に関する基本的考え方」にも記載があるが、クラウドと

いう文言が明示的に使われている。他分野の法令・ガイドラインではクラウドについて明言されてい

ないことも多々あるが、当該ガイドラインにはクラウドを意識している分、検討しやすいのではないか。

ブロックチェーンによる共有も、GCP 省令に挙げられている、メール等による送信、ダウンロード方

式いずれかで判断できるように思われる。それ以外の部分で、サスメド社のユースケースが厚生労

働省から反発を受けるとすると、ガイドライン等に記載の無い部分での指摘となるのではないかと思

われる。（委員 B）

医療情報のガイドラインにおいて、クラウドを意識した記載を追加すべきではないか。FISC（金融

情報システムセンター）でも検討されている点を参照し、最終的には規制業種間でブロックチェー

ンに関する整理があまりに外れていないように見直しが行えればよい。これにより、医療機関分野

でブロックチェーン利用に関するセキュリティ上の問題が解釈しやすくなるのではないかと考える。

（委員 B）

ブロックチェーンに関して、ノードの使用者が誰であるか、あるいは、もう少し下のレイヤーで、イン

フラを管理する事業者が誰であるかは、曖昧なところがあると思うが、ブロックチェーンとクラウド全

73 経済産業省「ISO でブロックチェーンの国際標準化についての議論が始まります」2016 年 10 月 7 日

http://www.meti.go.jp/press/2016/10/20161007002/20161007002.html

88

般は等しいものと整理されるのかどうか。（委員 H）

レイヤーの問題はあるが、ブロックチェーン全体について議論すると煩雑なものになる。論点 4 に

関連するが、ブロックチェーンとリスク管理という文脈のなかで、リスク管理フレームワークというもの

がある。リスク管理については切り分けて議論しようということになっている。リスク管理の部分で纏

めてはならないのが、パブリックか否かという点である。パーミッションレスなのか、パーミッションドな

のかで分けて議論をすることが必要だ。パブリック型ブロックチェーンを想定すると、社会実装が進

みづらくなるため、コンソーシアム型で進めるのを前提に議論するのがよいと思われる。そうした場

合に、レイヤーで議論が進めていけると思われる。（委員 F）

データを預け、その後管理を委ねるとなると、管理を求める権利が生じると思う。その場合、管理の

義務を誰が負うのかという議論になると思われる。このサービスで責任主体をどのように位置づける

か、について前回議論が行われていたら教えて頂きたい。（委員 D）

誰がガバナンスを行うかは現状定まっていない。PMDA のような公的な機関がノードの 1 つとなり、

イニシアチブを握ることが最終的には望ましいという議論となった。（事務局・委員 P）

国がデータの安全性を保障するのであれば、従来型の仕組みでも良いのではないかと思われる。

（委員 D）

台帳がシェアされていれば、責任やリスクについてもシェアされているということであり、リスクシェア

の仕組みを作ることが先決である。リスクエンジニアリングという捉え方が恐らく正しい。コンソーシア

ム型を組めば明らかになることであるし、パブリックであっても本質的には同じ。（委員 F）

現状、今回のサービスの導入にあたっては、製薬メーカー側が医療機関に伝えるのが一般的だと

考えている。それとも、国が導入を提案するものか。（事務局・委員 P）

基本的には前者かと思われるが、既存の治験自体、治験実施の責任者とデータの管理者は存在

するので、コンソーシアムを組むのであれば、１つの治験の責任をお互いにシェアすることを合意

できるのかどうかが鍵となる。（委員 I）

製薬メーカー同士で治験情報を情報共有することはない。唯一あるとすれば、国家プロジェクト等

である。そういったものも１つのテストケースに成りうると考える。（委員 A）

■論点 3 組織、設備等に関わる規定の内容について

大手の製薬メーカーが治験を行う場合に議論となるが、クラウドを使って治験を行う場合のバリデ

ーションをどこまでやるべきか、という問題がある。クラウド事業者に有る程度の、認証制度に基づく

信頼性があればよいが、それがない場合にどの程度までバリデーションをすべきか、という問題が

生じる。クラウドの環境で、ここを使った際には担保できるという基準があれば参考になるが、現在

はそうではない。海外に比べ、日本ではまだ認証制度が整っておらず、また、外部委託先としての

クラウド事業者という点の整合性についてもこれから検討が必要な状況ではないか。（委員 C）

基本的に、申請者がデータについて責任を持ってコントロールをするということは既存の情報シス

89

テムと変わらないと考えてよい。クラウドを利用する際にも、クラウドプロバイダを選定するときにどの

程度リスクがあり、なにか起きたときにどのようなコントロールが出来るのかということを検討すると思

うが、その点は、他の情報システムであっても、ブロックチェーンであっても同様であると思われる。

その点より問題となるのは、ブロックチェーンを用いるときにどこの部分にどういったリスクが生じるか

という点だと思う。（委員 E）

リモート SDV について、スタートアップにとって活用が進まない理由は、コストの高さと、医療機関

側のオペレーションコストの高さである。ブロックチェーン技術を用いて容易に使えるようになること

をポイントとしてビジネスを始める場合、利活用者がコストを感じずに着手できるような分かりやすさ

が規定に補足としてついていれば、医療機関側も導入に踏み切りやすいと考える。（委員 A）

ブロックチェーンに限った話ではなく、新しい技術は今後も発生するため、新たな技術が出てきた

際にどのように対応するかというフローを考えたほうが現場としても対応が楽になるのではないかと

考える。（委員 C）

ブロックチェーンの固有の問題が権限管理だけなのであれば、逆に明記したほうがよいのではない

か。唯一発生するリスクの違いはどの部分なのか、そのリスクはどのように対応できるのかを明記で

きれば有用なのではないかと考える。（委員 B）

■論点 4 治験のモニタリングについて

モニタリングの趣旨について確認したい。「Chain of Custody」という考え方があり、事件発生から

裁判所に来るまで証拠がどのように繋がっているか、というものである。治験に関しても、すべての

証拠が繋がっており、すべてについて改ざんされていないことが明らかになっていることが言える

必要性があるが、ここでのモニタリングの趣旨とは、そういった連続性についても明らかにしようとす

るものか。（委員 E）

医療機器等法におけるモニタリングの第一の趣旨については、治験実施中に副作用が生じた等、

人体に危害が及ぶなんらかの事象が発生した時に適切な対応が取れるようにしようとしたものだと

思われる。加えて、最終的に承認を目的としているという点もあるため、証拠の正しさを担保するこ

とについても、目的として挙げられると思われる。臨床研究法におけるモニタリングについては、後

者が一番の趣旨になると考える。（事務局・委員 P）

その場合、ブロックチェーン固有の議論ではないと思われる。（委員 E）

モニタリングの趣旨としては、治験を受ける者の安全性の確保、治験データの正確性いずれもにつ

いて、検証・監視できるようにするためにどうするか、という議論である。そもそも情報システムをどの

ように使うかという点についてどのように考えるかという点の整理が基本となる。それに加えて、ブロ

ックチェーン、特にコンソーシアム型として権限管理ができている前提で何か追加ですべきことがあ

るかという点を議論できれば十分ではないかと考える。資料 1（p.24）に「ブロックチェーン固有のリ

スクマネジメントの在り方」として、ハードフォーク問題等という事例が挙がっているが、コンソーシア

90

ム型で管理主体が存在する場合に、勝手にフォークを起こすのはどういう場合かが分からない。

（委員 B）

リスク管理について、safety と security の違いに関する議論がある。ブロックチェーンに限らず、情

報システムを導入すると、security のリスクが生じるという議論が出てくる。これについては、解釈が

示しきれていないのが現状である。リスクマネジメント委員会が検討すればよいというものかと思わ

れるが、彼らは safety については検討してきたが、security については分からない人も多いという

印象もある。safety と security についてどう整合性を取るか、ベストプラクティスをどう早く作るかとい

う点が重要だと思われる。（委員 C）

パーミッションドのブロックチェーンについてはこれまでクラウドに関して議論が整理されているため、

それを参考にできるとなると、固有の問題としては、ノードの権限を誰に与えるかという部分と、ブロ

ックチェーンの規定という、人によるガバナンスの部分が残る。また、すべてオン・チェーンでやるこ

とは現実的ではなく、特に例外事象への対応などで、ブロックチェーン上で対処不可能なケースが

挙げられる。（委員 F）

今回のケースで、改ざん防止というのは 1 つの目的だと思うが、データを入れるときの真正性が懸

念となる。医療関係者に改善したいというモチベーションが生まれうるなかで、インプットデータの正

しさについての検証が論点として挙がるのではないか。ブロックチェーンに書かれているデータは

正しいという前提となるため、ブロックチェーンに書かれているものこそが正しいという判断になって

しまう懸念がある。（委員 D）

ブロックチェーン固有の課題にならないのではないか。（委員 A）

ブロックチェーンに書き込まれているものが正しいという判断になりやすい点が懸念である。（委員

A）

ブロックチェーンを活用したとして、データの入り口での真正性が解決されているものではなく、既

存のシステムと変わりは無い。（委員 H）

P2P で一斉に送信することで、ブロックチェーンならではの課題は発生するか。実際に情報が相手

に届いたか等の懸念はないか。（事務局・委員 P）

アプリケーションによって対応可能なものであり、ブロックチェーン固有の問題ではない。（委員 H）

通信が到着したことが分かればよく、その点はアプリケーションによって実現できるような対応が可

能ではないか。（委員 B）

医療機関がリモート SDV を行う場合、物理的に作業用に個室を設け、書き込み者や閲覧者の制

限を管理しているが、ブロックチェーンではこれと同等のシステムを作成できると思われる。実際に

はどのように取り組まれるのか。（委員 A）

91

スマートフォンが中継サーバー経由して書き込むもので、個別に治験参加者が行う。現状、製薬会

社のように、利益相反が生じる人間による書き込みは発生しないという前提によるものである。将来

的に製薬メーカー側が閲覧することになった場合には、現状のリモート SDVのような仕組みを検討

したい。（委員 I）

治験マネジメントにおけるブロックチェーンの活用（医師主導型臨床研究に関する論点）

日本総研より、資料 1「ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 2 回 事

務局資料」を用いて、医師主導型臨床研究に関する論点をご説明した。

■論点 5 特定臨床研究に治験データプラットフォームを活用した場合の実施状況の確認

そもそもモニタリング担当者が利益相反関係者を選んではならないのではないか。特段の問題が

発生しないように思われる。（委員 G）

■論点 6 特定臨床研究に治験データ管理プラットフォームを活用した場合の利益相反管理

他の業法等でも、同じ会社の中で利益相反関係が発生し、取り扱いルールが定められているもの

かと思われるが、例えば弁護士法においてはどうか。弁護士事務所内でも、利益相反関係があるク

ライアント同士が存在する場合があると思われるが、どのように対処しているか。（事務局・委員 P）

弁護士法の場合は、ファイアウォールを敷いてという場合は、情報自体を隔離するという方法をとっ

ている。特定の利益管理の行為を禁ずるという場合もあれば、証券会社のように部門間で情報に

接すること自体を禁止するものもある。ここでの利益相反管理とは、どういった意味合いなのか、あ

くまで臨床研究への不正な関与さえ防ぐことができれば良いということであれば、権限管理の問題

に帰着するのではないか。（委員 B）

個人的に類似する事例と思われるのは、自分が破産管財人であり、破産債権者に自分の顧問会

社がいたらどうか、というものだ。形式的に見るのであれば、証拠を集め単なる大勢の債権者のうち

の一人ということを主張すればいいというものである。本ケースでは、形式的なケースのように見え

る。（委員 E）

臨床研究法や臨床研究法施行規則（案）について、情報隔離ということについては明記されていな

いようであれば、情報を見ること事態には問題がなさそうに思える。（委員 B）

臨床研究法において特に示されていない上、そもそも実際上、臨床研究が行える必要があるので、

特に課題視していない。（委員 G）

治験データ管理プラットフォームを導入するのであれば、アカウントの種類を何種類か分けて、例

えばモニタリングは読み取り専用にすべき、等の基準が挙げられるのであれば、記述したほうがい

いとは思う。それが無いのであれば、全般論の話と言える。（委員 H）

特に国家プロジェクト等で製薬企業が複数参加し、製薬企業同士が利益相反関係にある。アクセ

92

ス権限がうまくコントロールできるのか。（委員 G）

ブロックチェーンを用いる際の製品の選定次第でアクセス権限は設定可能。（委員 H）

国家プロジェクトの場合には、前提となるチェーンの選定の段階で解決すると思われる。（事務局・

委員 O）

当社の場合でも、アクセス権限が可能な仕様の OSS を用いている。（委員 I）

電子カルテの共有におけるブロックチェーンの活用

日本総研より、資料 1「ブロックチェーン法制度検討会 （医療・介護・ヘルスケア分野）第 2 回 事

務局資料」を用いて、電子カルテの共有におけるブロックチェーンのユースケースおよび論点をご

説明した。

■論点 7 個人情報の第三者提供に関わる責任分解

個人情報の第三者提供に関わる責任分解について、PDSやAPIについての議論がそのまま適用

でき、ブロックチェーン固有の問題ではない。証券業界に関する議論のなかでは、見せる必要の無

いデータを見せない状態で情報共有した場合に、個人情報の共有となるか、といった議論もあった

と記憶している。（委員 F）

第三者提供・委託のいずれも整理可能である。第三者提供であると対応が煩雑であるため、責任

主体が医療機関から委託を受けて管理していると言える実態があるのであれば、委託が望ましいと

は思われる。PDS についても鑑みると、委託の際に、本人同意を取ることになるのではないかと思

う。逐次同意を取ることが機能する仕組みとできるかどうかは検討する必要がある。（委員 B）

コンソーシアムとして同意を取った後、メンバーが追加となったケースも論点となると考えられるが、

この点は既に論じられている観点かと思うので参照するとよい。（委員 D）

地域医療連携の場合は、最初に医療機関を受診した時点で黙示の同意があったとみなし、医療

介護ガイダンスの整理としては本人に代わって委託を受けているということとなっている。こちらと同

様に考えても良いのではないかと考える。地域医療連携の場合に、どこまでが委託先と認められる

かは明らかでない部分もある。（委員 G）

ICT サプライチェーンという考え方が強くなっており、インシデント・レスポンスとしてどのように対応

すべきかを事前に確認しておくことが求められる。第三者提供・委託のいずれであっても、ビジネ

ス・レスポンスがあった場合に個人にどう通知するか等、詰めていく必要がある。（委員 C）

ヨーロッパを拠点とした主要な製薬企業が多くある。GDPR 等、医療業界について、ヨーロッパに

関連する論点は多くあるように思われる。（委員 E）

医療・介護・ヘルスケア等分野のブロックチェーン法制度検討会は今回を持って終了となるが、改

93

めて議論を取りまとめ、展開する。また、今回の議論を元に関係機関についてヒアリングを行い、報

告書として結果を整理させて頂く。（事務局・委員 P）

以上

94

経済産業省 委託調査

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

ブロックチェーン法制度検討会（物流、サプライチェーン、モビリティ分野）

（第 1回）

議事要旨（案）

日時 2018 年 1 月 12 日（金） 10:00-12:00

場所 経済産業省本館 2 階委員 P6 共用会議室

構成員

株式会社ブロックチェーンハブ 委員 A

渥美坂井法律事務所・外国法共同事業

弁護士

委員 B

シティユーワ法律事務所 弁護士 委員 C

国際大学グローバル・コミュニケーション・センター

研究部長

委員 D

森・濱田松本法律事務所 弁護士 委員 E

オブザーバー 委員 P 京大学大学院工学系研究科

技術経営戦略学専攻 システム創成学専攻（兼担）

インターネット・オブ・エナジー社会連携講座

特任准教授

委員 F

カウラ株式会社 CEO 委員 G

カウラ株式会社 CIO 委員 H

委員 P 京電力ホールディングス株式会社

新成長タスクフォース事務局

グリーン＆イノベーション第二グループ

委員 I

委員 P 京電力ホールディングス株式会社

新成長タスクフォース事務局 グリーン＆イノベーション第二グル

ープ

委員 J

経済産業省 商務情報政策局 情報経済課 課長 委員 K

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 L

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 M

経済産業省 商務情報政策局 情報経済課 係長 委員 N

日本電気株式会社 事業イノベーション戦略本部

FinTech 事業開発室 委員 O

事務局 株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ 主席研究員 委員 P

95

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 Q

株式会社日本総合研究所 リサーチ・コンサルティング部門

戦略コンサルティンググループ 通信・メディア・ハイテク戦略クラ

スター

委員 R

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 S

敬称略

96

議事

(5) 議題

(1)ブロックチェーン法制度検討会について

(2)EV リチウムイオン電池に係わる情報の共有に関するブロックチェーンの活用（カウラ株式会

社様）

(3) ブロックチェーンを活用したリコール、二次電池の再利用に関する法制度上の課題につい

て

(4)質疑応答

(5)電力融通取引におけるブロックチェーンの活用について（委員 P 京大学委員 F 様）

(6)電力融通取引に関する法制度上の課題について

(7)質疑応答

(6) 配布資料

資料 0 議事次第

資料 0 出席者一覧

資料 1 「ブロックチェーン法制度検討会（物流・SC・モビリティ分野）

第 1 回事務局資料

資料 2 カウラ様ご発表資料「EV へのブロックチェーン活用概要」

資料 3 委員 F 様ご発表資料「ブロックチェーンを用いた P2P 電力流通システムの研究」

参考資料 1 電気通信マニュアル[追補版]

参考資料 2 国土交通省「道路運送法における登録又は許可を要しない運送の態様について」

議事要旨

(3) 議題

(ア) ブロックチェーン法制度検討会について

株式会社日本総合研究所（以下日本総研）より、資料 1「ブロックチェーン法制度検討会 （物流・

SC・モビリティ分野）第 1 回 事務局資料」を用いて、経済産業省「平成２９年度我が国におけるデ

ータ駆動型社会に係る基盤整備（分散型システムに対応した技術・制度等に係る調査）」の背景・

目的、法制度検討会（物流・SC・モビリティ分野）の開催要綱、スケジュールについてご説明した。

(イ) EV リチウムイオン電池に係わる情報の共有に関するブロックチェーンの活用

カウラ株式会社様より、資料 2「EV へのブロックチェーンの活用概要」を用いてご説明された。

(ウ) 株式会社日本総合研究所より、資料 1「トレーサビリティの確保に関するユースケース EV

バッテリー管理に法制度上の課題」を用いて、「EVバッテリーライフサイクル管理にかかるプラットフ

ォームを活用するにあたっての法制度上の課題」についてご説明した。

97

■質疑応答

自動車メーカーも電気自動車（EV）を本格的に売ろうとすると、電池の二次利用は避けられないと

いう考え方に変わってきている。日産自動車株式会社のように、電池の二次利用を目的とした会社

を立ち上げた事例もある。事務局から論点が挙がっている SOC（State Of Charge=残容量）、SOH

（State Of Health=劣化状態）は、メーカー側の自称的な要素が強いので正しい情報かを見極める

仕組みが必要である。例えば SOH については、テスラ株式会社は恐らくスペック以上の電池を載

せ、何年経ってもスペック通りの容量を保っているように見せていると思われるが、SOH を開示する

と衝撃的なものになるので出したくないだろう。何を取得して何を開示するかはメーカーとの話し合

いが必要である。製造物責任をどう緩やかにしてあげるかがメーカーとの論点になるだろう。（委員

F）

バッテリーの残存価値をメーカーのデータに頼らず入手でき、特定することが出来れば大きな価値

を生むと思う。（委員 A）

計量法のもとで規制を行うのか、このデータは計量法にオーソライズされたデータであるため、信

用できますという付加的な方向で進めるのか、いずれも考えられる。計量法は規制でなく、オーソラ

イズされる方向で進めると面白いと思われる。残存性を評価する場合、データを大量に集め、劣化

試験をする必要があるが、試験に多額の経費がかかるので電池メーカーが SOC を開示できないの

ではないかと思われる。このためカウラ社には是非開発を進め、日本のクオリティで残存価値デー

タを出す仕組みを作って頂きたい。

（委員 F）

資料 1（P.16）に EV バッテリー管理プラットフォームのサービスモデルイメージとして、「完成車メー

カー／バッテリーメーカー」が参加するとの記載があるがこれらのメーカーは競合企業も同一チェ

ーン内に組み込まれるということか。コンソーシアム型を利用する際に、一番難しいのはインセンテ

ィブの問題だと考えている。対競合について公開したくない情報もあると思われるが、参照権限の

コントロールを行う予定か。（委員 E）

本ケースの目的は行政機関側でクレーム状況を把握したいという課題を解決することである。競合

のクレーム情報を全て公開するということではなく、各メーカーそれぞれに対して行政機関がチェ

ーンを結ぶ想定である。資料 1 （P.17）に記載しているが、企業機密に関るものは当該メーカー以

外には秘匿することを検討している。（事務局・委員 R）

資料 1（P.16）にプラットフォームの参加者として、自動車メーカーとバッテリーメーカーが挙げられ

ているが、これらのメーカー同士の組み合わせはかなり多いものであり、それによって秘匿したい内

容は異なる、複雑な状況となる。

秘密分散の仕組みを使えばチェーンが何本も必要という話ではないが、このプラットフォームの主

98

眼としては行政機関のために作っていると考えてよいか。（委員 E）

行政機関がクレーム情報を吸い上げることを目的としたものである。（事務局・委員 R）

このサービスモデルを実現しようとする場合、ひとつの仕組みの作り方として、オープンデータの形

で、API をたたけば役所がそのデータが見える仕組みを実装すれば、吸い上げたデータから別の

データに有効に活用するモデルが作れる。従って、論じるべきは計量法の問題というより行政法の

話になってくる。まず、一定のデータを提出させる制度を作る。メーカー側は実施せざるを得ず、そ

れを実行するに当たりブロックチェーンを活用、実装するということとし、行政側は API を張って利

用者が見える状態にするスキームなどが考えられる。消費者がこれを利用する場合、自分の電池

の残存価値が見えるようにする。消費者が自分からは見に行かないと思うので、API を活用したア

プリを作る事業者が出てくるなど、こういう絵を作るのが法制度の検討なのではないか。自発的に

事業者が何かを行おうとしたときに今の法制度が邪魔になることも一部あると思うが、どちらかという

とこのプラットフォームの趣旨は全体の効率化を上げるため国全体の戦略として実施するというもの

だと思われる。制度デザインの話をしていく必要があるのではないか。（委員 E）

今回の対象は EV であったが、EV のように台数は多くなく、所有権を移転することも多くはないが、

このシステムは蓄電池システムの仕組みでも価値はあると思われる。

事例を挙げると、あるエネルギー関連の事業会社では米国・英国等で電力系統に蓄電池を繋ぎ、

周波数調整を行うというビジネスを展開していたが、そのうち、米国オハイオ州のプラントの一部を

委員 P 京電力ホールディングスが購入した経緯がある。そのような所有権移転の際、買い手企業

がデューデリジェンスを安心して行うためには、こういった客観的なデータが判断するのに役に立

つのではないか。

最後に、資料 1 （P.35）論点 1 である、「バッテリー残存価値予測可能エンジンが計量法に適応す

るかどうか」の論点は有効。仮に適応するとして、予測エンジンだけでなくハッキングされないように、

信号を取るところからはじめなければならない。この時点からブロックチェーンを使うとしたら信号機、

計測器の出力に秘密鍵をかけることも必要なので、個人的にはかなり大変な印象を受ける。総合

的な付加価値を向上させるためにはそのような作業が必要かと思われる。（委員 A）

SOH が残存を示す重要なデータだと思うが、時系列でどんな使われ方をしたかは関係なくスナッ

プショットで一度取ればいいという理解でもいいか？（委員 D）

SOH 自体は、現時点での値となる。残存価値を計る上では、時系列データが必要になってくる。

（委員 G）

例えば製造されたときから 3 年経った今、この程度だから将来的にはこの位という想定はできない

か。（委員 D）

その間にどういう使われ方をしてきたかで判断が変わる。例えば SOH の結果が「1」だった場合、そ

の「1」は減少していくのか、維持できるものかという判断が多少出来る。

（委員 G）

99

車を構成するさまざまなパーツの中で、タイヤのゴム等、残存価値のあるパーツがほかにも多くある

なかで、バッテリーをどの位特別扱いするかという点が疑問に思われる。ユーザー側も自らバッテリ

ーを交換するよりは、例えば車検等に出したときにバッテリー交換を勧められて交換することになり

メーカー側が新しいバッテリーに交換する、というモデルが考えられる。その場合回収した側がセカ

ンドマーケットに売れるかを判断して売れるなら売る。その際、買い手はどのくらいの情報で満足で

きるかという問題になってくる。これに関しては現状のモデルと大差なく進められる気がする。（髙

木）

また一方で、ユーザーが自分でバッテリーを自由に入れ替え、チャージしていくということになった

場合、ユーザーが自分で残存価値を証明する必要が生じる可能性がある。ユーザーが業者に依

存しない形で証明しなければならない時、ブロックチェーンの意味が出てくるようにも思われる。例

えばブロックチェーン上で過去の履歴、SOH も記録・開示した上で販売した後、爆発した場合、免

責されるかどうかの判断をする際、ブロックチェーンを使う意味がでてくるのでは？（委員 D）

バッテリーの形状について、メーカー側がバッテリーをインプリメントした状態で出荷されているケー

スと、乾電池のようにステーションへ行ったら新しい電池を入れるカセットタイプの両方が考えられる。

（委員 G）

現在ガソリンスタンドを経営している会社がそこの品質で装着したらその会社の責任のうえ、一定の

品質のものを提供してもらうという方法もある。（委員 D）

フィリピンではバイクのバッテリーは交換式があるが、あのようなタイプを自動車に転用する事も出

来るかと思う。（委員 G）

ベタープレイスという車のバッテリー交換をする会社があったが、2013 年に事業を撤退したと聞い

ている。（委員 A）

バッテリーの性能を証明する必要があるのは誰か、買うときにその証明を必要としているのは誰か、

によって法制度の課題が変わってくる。（委員 D）

法制度となると広い意味になるが、カーシェアリング会社、国内で言えばレンタリース会社は 1 社で

多いところでは、70万台の車を所有している。そのうち、数％をEVに変え、現在の状態、残存価値

を見て交換するというモデルは具体的なテーマとして挙げられるのではないか。（委員 G）

(エ) EV リチウムイオン電池に係わる情報の共有に関するブロックチェーンの活用

委員 P 京大学 委員 F 様より、資料 3「ブロックチェーンを用いた P2P 電力流通システム

の研究」を用いてご説明された。

■質疑応答

分散型のシステムでサービスを提供するときに、初めてブロックチェーンをつかっていることにより

業規制の考え方が変わってくると思われる。個々の事業者というよりは、プラットフォームを誰が管

100

理するかという、ガバナンスの部分が重要となってくる。それがカウラ社の例で言えば計量法であっ

たし、本件では電気事業法になる。計量法は分散型の規制に近い部分があると考えられるが、電

気事業法に関してはそうではない。分散化していくのであれば、どのように要件を考えていくのか、

将来を見据えて考える必要がある。ガバナンスとして何を抑えておけば、本質的に守ろうとしていた

どのような保護法益を守りうるか、という議論を次回法制度検討会までにできればよいと考える。（委

員 B）

小売電気事業に関する議論について、条文の定義からすると、「一般の需要に応じ電気を供給す

る事業を営む者」ということになるが、事業の遂行の程度という論点に関して言えば、「一般の需要

に応じているか」という点がポイントとなると考えられる。本件では最終需要家が一般消費者となる

ため、一般の需要に応じていると考えられるのではないか。現行法の解釈を前提とすると、「登録特

定送配線事業」という制度があり、自営線に基づいて特定の供給地点に配電する場合では 1 箇所

だけ供給することもあるが、中の人が変わりうる、つまり、誰にでも供給する可能性があるということ

から、一般の需要に応じて供給していると整理されている。これを鑑みると、「一般の需要に応じて

いるか」については世帯数によって、決まるという議論にはならないのではないかと考える。（委員

C）

反復継続性の議論について、電気事業法の改正前のコンメンタールを参照するに、一定の目的を

持ってされる同種の反復継続行為であり、営利の目的は問わないといった内容が現状の解釈とし

て示されている。小売電気事業者を「営もう」としている者ということで、ここから営利性の要件が出

てくるものとなる。本件のような場合では、電気を売買するとなると、営利性が無いと判断するのは

難しいと思われる。そうなった場合、小売電気事業者ではないと整理するためには、法改正が必要

と考えるのが素直な考え方となる。他の手段で小売電気事業にあたらないようにする場合、法の解

釈にて回避するという方法があるが、解釈を変更することによって、小売電気事業者の適用の有無

が変わってしまうことになり、他の事業者への影響も大きいと見られるため、解釈で整理するのは難

しいと考える。（委員 C）

電力の小売に際しライセンスが求められるという制度の意図としては、安定的な電気の供給を遂行

するために、供給の確保義務や需給バランスの確保が必要となるという背景がある。これを鑑みる

に、電力融通にあたり小売電気事業者という扱いをやめ、さまざまな義務を課さないことで実害が

生じる可能性がある。とはいえ、プロシューマーに従来の小売電気事業者に与えるような義務を課

すのも難しいため、場を提供するプラットフォーマーの方に義務付けするのが現実的だと思ってい

る。（委員 J）

仮に小売電気事業を営むことではない場合での問題として、どうやって電気を届けるかという点が

問題になる。自営線を使うという方法もあるが、全国規模では自営線では回らず、一般配送電磁業

者の配送網が必要となる。一般送配電事業では託送が義務付けられており、小売電気事業のた

101

めの供給は義務付けられている。小売電気事業にあたらなければ一般送配電事業者に託送義務

がなくなり、現状の法制度では送電義務がないことになる。このため、小売電気事業にあたらないと

する場合には託送制度も検討しなければいけない。（委員 C）

一般配送電事業者の送配電網を利用するのであれば料金を払わなくてもよいという理由はなく、

自己託送でも託送料金は支払う必要があるため、本件であっても必要と考える。

（委員 C）

電気事業者からみても、プロシューマーが託送料金を支払わなくても良いというのは著しい不公平

感がある。現状では託送料金制度の中で、遠い場所でも近い場所からでも一定の託送料金を払う

制度になっているため、それよりも、形態にあわせた料金制度にしたほうが、P2P の電力融通も進

むし、公平間も調整できると思われる。（委員 J）

制度の傾向でいうと、民泊のような場合はミッションクリティカルではないため、真ん中で管理する

人が責任を負わないことも法制度としても許されている。一方で、金融等の業界だと、ミッションクリ

ティカルであることから、責任の所在について厳しい検討が求められる。ただし、金融機関の事例

を参考にしても、プラットフォーマーの監督さえできていれば、末端の人に重い義務を課す必要は

ないのではないかと考える。（委員 E）

小規模の事業者、個人は適用除外というものを明確に記載しておいた方がよい。

他方で代わりにプラットフォーマーに対して、適用除外としたことで生じる弊害を防止させるための

比較的重い責任を課する形で整理するとよいのではないか。（委員 B）

現在の制度に基づき、本件を実施する最も簡単な整理としては、小売電気事業者をプラットフォー

マーとして扱い、発電設備を持っている個人から電力を買い集める、プラットフォーマーは小売電

気事業者として説明義務等の法的義務を負い、電気の調達先として消費者を捉えるということが考

えられる。（委員 C）

一方で、民泊の事例等を鑑みるに、町内、隣人といった単位のコミュニティで電力を融通する場合

には、責任を問うといった問題も生じない可能性がある。そのように、ある程度制度を緩和すること

も考えてもよいのではないか。（委員 E）

以上

102

経済産業省 委託調査

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

ブロックチェーン法制度検討会（物流、サプライチェーン、モビリティ分野）

（第 2 回）

議事録（案）

日時 2018 年 1 月 30 日（火） 10:00-12:00

場所 経済産業省本館 17 階委員 M5 共用会議室

構成員

株式会社ブロックチェーンハブ 委員 A

渥美坂井法律事務所・外国法共同事業 弁護士 委員 B

シティユーワ法律事務所 弁護士 委員 C

森・濱田松本法律事務所 弁護士 委員 D

駒澤綜合法律事務所 弁護士 委員 E

オブザーバー カウラ株式会社 CEO 委員 F

カウラ株式会社 Executive Adviser 委員 G

委員 M 京電力ホールディングス株式会社

新成長タスクフォース事務局

委員 H

委員 M 京電力ホールディングス株式会社

新成長タスクフォース事務局 委員 I

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 J

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 K

経済産業省 商務情報政策局 情報経済課 係長 委員 L

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ 主席研究員 委員 M

事務局 株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 N

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 O

敬称略

103

議事

(7) 議題

・電力直接取引に関する法制度上の課題

・質疑応答

・EV バッテリー管理に関する法制度上の課題

・質疑応答

(8) 配布資料

資料 0 座席表

資料 0 議事次第

資料 0 出席者一覧

資料 1 「ブロックチェーン法制度検討会（物流・SC・モビリティ分野）」

第 2 回事務局資料

議事要旨

議題

電力直接取引に関する法制度上の課題

株式会社日本総合研究所（以下日本総研）より、資料 1「ブロックチェーン法制度検討会 （物流・

SC・モビリティ分野）第 2 回 事務局資料」を用いて、電力直接取引に関するユースケースの概要、

論点１「小売電気事業者への該当性」、要件１「事業の遂行の程度に関する検討」、前回検討会の

検討内容等をご説明した。

■質疑応答

資料１「要件１『事業の遂行の程度』に関する検討」に関して、「少数」で「不特定」の者に電気を供

給する場合に、該当する電力融通取引のケースとして「特定地点における供給（いわゆる特定供

給）」が挙げられる旨記載されているが、「特定供給」の概念はそもそも「特定の人に対して供給す

る」ということであり、少数で不特定の者へ電気を供給するケースを「特定供給」として扱うのはやや

不適切ではないか。（委員 C）

また、「少数」で「不特定」の者に電気を供給する場合には「特定送配電事業者として規律される」と

あるが、特定送配電事業者の該当性については一般送配電事業者の送配電を使うか、特定の送

配電事業者としての送配電を使うかという違いが大きく、必ずしも少数か多数かという差異にはよら

ないと考える。

いずれにせよ、プロシューマーが小売電気事業者に該当するか否かという議論のなかで、一定の

場合は該当しないというケースが存在する。そのケースにはほぼ間違いなく「特定供給」が入ってき

てしまう。電気事業法上、需要家ごとに許可を受ける必要が生じ、より面倒な手続を踏まなければ

ならず、今回考察しているスキームからすると離れたものになると思われる。現行の解釈のもとで電

104

気事業法の規制が及ばない形で実施することはハードルが高いように思う（委員 C）

電気を供給する対象が「少数」である場合、「多数」である場合、と分けて検討されているが、線引き

される人数の目安はあるか。（委員 A）

現行の解釈では特定性、対象者数について、具体的な数は定まっていない。ガイドラインについ

ても、明記がなく、不明瞭な部分である。（事務局・委員 N）

事務局資料の整理では、対象が「不特定」の場合、対象者数が「少数」であれば「小売電気事業者」

に該当せず、「多数」であれば該当することとなるため、20 名が少数なのか多数なのか、という議論

になるのではないか。 （委員 A）

「少数」が何を指すかについて、「特定されている人達」ということでないと説明がつきづらいと理解

している。供給地点という概念で考えると、供給地点には誰でも入りうることから、現実的には「多数」

と考えることができる。特定の供給地点だけに供給する特定送配電事業では、「一般の需要に応じ

て供給している」と整理されているが、任意の場所に誰かが入ってくる可能性があることをもって「不

特定多数」、つまり一般の需要に応じているという考え方である。また、逆に「特定の人」に供給され

ているということになれば「特定供給」という概念になるのではないか。そうであるとすると、仮に特定

の 20 人に供給するといった場合、特定の 20 人以外に供給しないと言えるのであれば、当該 20 人

に「特定供給」していると言えるであろう。人数の多寡では判別しづらい。（委員 C）

今回取り上げている、一般消費者間での電力融通システムのユースケースは、1 人のプロシューマ

ーから供給する対象地域が限定されたとしても、対象者の数はその際の需要によって増減すると

いった状況が生じるものと思われる。（委員 A）

当該ケースを事業として成り立たせる場合、ある程度不特定多数に供給する必要がある。一方で、

今後社会実装のためには、実証実験を行うなかで、電力を融通することが技術的に安全か、需要

があるのか等をデータに基づいて議論する必要がある。その際には、「特定少数」に対する供給で

あっても、取引を行う意義はあると思うが、ある程度エリアを区切り、例えば 10 人レベルのとある地

域の家庭で電力を融通するのであれば「特定少数」への供給として、解釈することは可能か。（事

務局・委員 N）

資源エネルギー庁「2005 年版 電気事業法の解説」において、「『事業』とは、一定の目的をもって

される同種の行為の反復継続的遂行」をいい、「試験的又は一時的に供給する場合を含まない」

旨の解説がある74。実証実験をどのようを捉えるか次第であるが、試験的又は一次的に該当するた

め事業に該当しないと主張する道もあるかもしれない。なお、現状、組合等の密接な関係を有する

人たちの間で電気を融通する形であっても、それは「特定供給」という事になるので、小売電気事

業者でなく特定供給にも当たらないという整理は難しいと思われる。（委員 C）

株式会社日本総合研究所より、資料 1「ブロックチェーン法制度検討会 （物流・SC・モビリティ分野）

第 2 回 事務局資料」を用いて、要件３「『営利性』の該当性」、論点２「託送料金制度」、前回検討

74 資源エネルギー庁「2005 年版 電気事業法の解説」37 頁

105

会の検討内容等についてご説明した。

■質疑応答

営利性の概念について、「特定供給の概念」に関しても「電気事業法の解説」の中で解説がある。

「電気事業法の解説」では、「『事業を営もうとする』とは、営利の意思を持って反復継続して電気を

供給することをいう。営利の意思の有無は、具体的事例に応じて総合的に判断しなければならな

いが、例えば、自己の発生電力を供給する場合であって、供給の相手方から、供給電気に対して

何らかの対価を受け取ることを前提としている場合は、営利の意思があると解釈される」との説明が

ある75。一方、「電気の供給者が慈善事業として無料で電気を供給する場合、ビル・アパート等にお

いて、管理人が一括受電した電気をビル・アパート等の内に個別に取り付けたメーターを通じて供

給し、その対価が一括受電により支払った料金と同等の場合等は、『営む』ものではないと解する」

とされており76、電気通信事業法の内容に近い。営利性についてそれ以上のことは書いていない

ので、営利性の議論というのはあまりうまい議論ではないと思われる。「営利性」は今回取り組もうと

している事以外にも関わってくる。例えば電力取引で仮想通貨を用いて行う場合に、仮想通過は

営利性が無いと整理した場合、他の小売電気事業者も同様の考え方を適用する必要がある。「営

利性の概念」の解釈だけでは整理がつきづらい。（委員 C）

仮に当該ユースケースにおいて金銭的価値が低く、営利性がないと整理した場合、当該ユースケ

ースは社会実装を進めるためのインセンティブ設計が出来ていないという懸念がある。 （委員 E）

「電気事業者による再生可能エネルギー電気の調達に関する特別措置法」（以降、「再エネ特別措

置法」という。）があるが、電気事業法とのバランスを見ながら、再エネ特別措置法を拡張していくと

いうアプローチも考えられるのではないか。基本的には再エネ特別措置法では一般送配電事業者

が調達する先がプロシューマーという整理になっている。プロシューマーが調達先として認められ

ていることを鑑みれば、一般送配電事業者という特定者に対しての調達先というだけでなく、一般

送配電事業者以外に対しても一定の条件を満たせば調達先として扱うことができるとするアプロー

チも考えられる。（委員 E）

小売段階、発電段階、送配電段階といった段階のなかで、再エネ特別措置法の目的は発電段階

の再生エネルギーの促進と考えられる。プロシューマーはある意味、発電所的な位置づけとなり、

ある発電所から直接需要家が電気を買い取り、その電気を売る者へ送る、というものと考える。再エ

ネ特別措置法においては調達について定めており、小売段階に対する供給については特段範疇

にない認識である。再エネ特別措置法の目的のもとでは、少なくとも現状の理解の中で解釈するこ

とは不可能ではないか。再エネの促進、再エネ特別措置法の観点から直接電力融通を制度の中

で整理するのが望ましいということであれば、電気事業法との調整を行い、法制度を変えるという手

法を取ることになろう。（委員 C）

75 資源エネルギー庁「2005 年版 電気事業法の解説」139 頁 76 資源エネルギー庁「2005 年版 電気事業法の解説」140 頁

106

これまではシステム構成で例えると、サーバー・クライアント形式で、調達した電力がサーバーに常

に集まり、各家庭に配信するといったものだった。配信内容の品質はサーバーに集めた人が管理

していたというものだが、今回のユースケースでは P2P 形式で電気を融通することが可能となると

いうことである。一般ユーザーの視点からすれば、技術的に品質を保証できるならば従来のサーバ

ー・クライアント形式でなく、P2P 形式に移っても異論はないだろう。そうすると電気通信事業法のよ

うな枠組みよりも、再エネ特別措置法の部分的な発展という形で、時代に合わせてアレンジすると

いう考え方もできるのではないか。（委員 E）

P2P 形式で電力を取引しても品質に影響はでないか。（委員 A）

電気自体の質は差がないが、需給バランスを取るという意味での品質は保つ必要がある。現在は

小売電気事業者が需給バランスを担保しているが、需給バランスを保つ仕組みは引き続き必要と

なる。（委員 I）

P2P 形式で電力融通を行う際にあたって、消費者への説明等、小売電気事業者が現状負ってい

る義務を誰が担うのかという点で議論が必要となる。（委員 C）

電力直接取引に関する法制度上の課題

株式会社日本総合研究所より、資料 1「ブロックチェーン法制度検討会 （物流・SC・モビリティ分野）

第 2 回 事務局資料」を用いて、法改正や将来的な制度設計の在り方に関する前回検討会の検

討内容、諸外国の動向、小売電気事業者に対する義務等についてご説明した。

■質疑応答

小売電気事業者の枠組みを取り除くのはドラスティックであり、相当なリスクだと考える。将来的に

小売電気事業がなくなるのではないかという議論もよく耳にするが、現時点で必ずしも必然性があ

るものではない。小売電気事業者をプラットフォーマーとしてそれぞれ中間の方から電気を調達し、

調達した電気を需要家に供給する。電気事業法上の需要家保護の義務についてはこのプラットフ

ォーマーが負って需要家保護にも適う形で対応していくのが現実的な方法ではないか。ただ、余

剰電力の供給を受けた需要家が、あるプロシューマーからの電力供給のみでは不足するという場

合が生じうる。現状の制度なら不足分は小売電気事業者が一般送配電事業者から調達する形で

供給することとなる。「低圧部分供給」のようなイメージで、不足分の電力は別の他のプロシューマ

ーから購入する方法が考えられる。法制度上は不可能な事ではないと思うが、その辺りの考え方も

整理する必要がある。いずれにしても小売電気事業者の枠内で何が出来るのか、どこまで出来る

かを考える事はあるにせよ、小売電気事業者の枠組みを外さなければ絶対に達成出来ないことは

あまり無いのではないか。（委員 C）

資料 1（p.12）にて、「要件１『事業の遂行の程度』に関する検討」にて自己の社宅に対する供給等

の事例が挙げられているように、物理的に特定された少数への供給であれば例外として小売電気

事業者に該当しないと整理されている。情報技術が発展していくなかで、電力融通に当たりサイバ

ー上のネットワークを駆使したとしても、同様に特定少数への供給であれば小売電気事業者に該

107

当しないと取り扱うことについて何ら実害は起きないのではないか。それならば、再生エネルギーを

使う、という目的が加わる中で、「これを満たせば広げられる」といった部分を模索するようなアプロ

ーチが現実的ではないか。供給のみについて定めている再エネ特別措置法を拡張する等の手法

が考えられる。（委員 E）

「レギュラトリー・サンドボックス」という話もあり、現時点では、法改正までは求めない場合でも、法改

正を行う意義がある事業になっているか、を検証することも重要だろう。「レギュラトリー・サンドボック

ス」自体が法規制に抵触する実証実験を許容するという話ならば、最低限、実験を許容する条件と

して、何が実質的に満たされていればいいのかを議論するべきと考える。その中で実際に問題が

生じないということをもって、法改正を検討するということも考えられるのではないか。一方、実験す

るにしても、現時点で法令により確保されるべきと整理している点は継続して守らなければならない。

恐らく供給能力に関しては既に話題に挙がっているように、少なくともプラットフォーマーに対し、電

力の安定供給に向け調整できる能力を持たせ、最低限の監督をして頂くことは必要だろう。加えて、

更に実質的に確保すべきものは何かを議論できればいいと考える。

（委員 B）

ブロックチェーン技術の特徴として、中央集権的な仲介者が不要という点が挙げられているなかで、

プラットフォーマーがいる前提の枠組みが結論となると、ブロックチェーン法制度検討会の結論とし

ていかがなものか。

安定供給を達成する必要があるという話は理解できるが、現行の安定供給のための取り組みはや

や針小棒大でもあると思われるため、どの程度の規模で実施する分には問題がない、という議論も

できるはずだと考えている。また、P2P 技術を用いる時点で現行システムより不安定となるのは当

然のことである。現時点と同等の品質を担保するという前提が正しいのかは懸念がある。全体として、

ブロックチェーンの特徴を踏まえて前提を検討する必要があるように思われる。（委員 D）

シェアリングビジネスでブロックチェーンを活用する場合、最終的にはプラットフォーマーが不在と

なる状態を目指していると思うが、事業性と安全性の問題が生じる。最終的にはプラットフォーマー

がいない世界を前提として議論することも必要であるが、一方で、目の前の普及を考えたときに、

規律する何らかの存在も必要だと考える。今後、プラットフォーマーはこれまでの役割とは変わって

くると考えている。例えばライドシェアの場合で言えば、Uber のような事業主体がいて、ドライバー

と乗客に対して制約を課しているが、今後、プラットフォーマーはブロックチェーンの提供者として

は存在するものの、ブロックチェーンを用いることで手数料が下がるという点もあり、これまでとは異

なるビジネスモデルを有するようになる。目先のプラットフォーマーが必要ということを念頭におきつ

つ、最終的にプラットフォーマーがいなくなった場合、どのような問題が起きるかを示せればと考え

ている。（事務局・委員 N）

例えばスマートメーターがあり、需要家とプロシューマー間で契約を結ぶ場合に、実際に社会的に

許容しえない不都合として何があるのか、もしくは無いのかという議論が生まれる。不都合が無いと

なった場合、プラットフォーマーによる規制ではなく個別の契約で対応できることとなる。（委員 E）

108

これまでのプラットフォーマーとは違い、情報を一箇所に集めて、マッチングすることから手数料得

るのではなくて、プラットフォームのシステムを利用し、電力融通を促進するような立場だと想定する。

実際のシステムを稼動させるにあたっては、現状、誰かが管理しないと消費者が使用できる状態に

ならない。将来的には管理者がいない状態に近くなるかと思われるものの、短期的には、完全中央

集権型と完全分散型の中間となるのではないかと考えている。（委員 A）

プラットフォーマーという表現が適切であるかは別として、サービスの運営に関わってくる人たちは

ブロックチェーンを用いたサービスであっても、存在していくと思われる。何らかの仕組みでブロック

チェーンを動かす努力をする主体は必要であり、仕組みの変更を行うときについても最低限のル

ールを決めておく必要がある。また、ブロックチェーン上で実装することにより、電力の安定供給が

難しくなる面があるとしても、最低限ここまで不安定になってしまうと実用に耐えられないという線引

きというのは、既存の日本のインフラと同等にまではせず、最低限このくらいという基準を策定する

こともできるのではないかと思う。現在の日本のインフラでは海外での実用レベルプラスαの可用

性があると考えるので、実際には可用性を少し落としてでも実用に耐えうるラインを検討する意義は

あるだろう。（委員 B）

基本的に需要家が可用性の高さを選べるようになればよいと思われる。今回の議論で、プラットフ

ォーマーについての言及があったが、今後はコーディネーターと呼ぶに近い存在になると考えて

いる。コーディネーションを行うコミュニティがあり、そこで最低限のルールを決める存在となるので

はないだろうか。業種・業態・業容によって、運営者のインセンティブをどこにおくかは選択の余地

があるという設計をしないと誤解を与えるため、ブロックチェーンのシステムを検討するなかで明確

にしておいたほうがよい。サービスが段階的に中央集権型から分散型と進んでいくなかで、中間段

階で何が必要になってくるか、という議論もあると思われる。（事務局・委員 M）

先ほど安定供給の必要性について挙げて頂いたが、他に事業を行っていくに当たり、利用者保護

として重要なものについて伺いたい。（委員 B）

基本的に小売電気事業者にとっては供給量の確保が挙げられる。時間ごとの需給バランスの調整

は送配電事業者が担っているが、送配電事業者をサポートするにあたり、小売電気事業者は日々

どの程度需要があるかを送配電事業者に出しているため、そのような作業は挙げられる。（委員 I）

電気はライフラインであるため、リライアビリティが重要となってくる。それを参加者が共通認識として

持てる環境が必要になると思われる。利用者保護の観点で、具体的に必要になるものは現時点で

は精査できていないが、決済が適切に行われるか等が挙げられると考える。（委員 H）

事務局説明のなかで、今回のユースケースに関してレギュラトリー・サンドボックスの活用に関する

話題が挙がったが、ユースケースの最終的な目的はどういったところか。

（委員 D）

目先の部分では、電力融通取引の実証実験を行うことが挙げられる。自営線などで小規模なところ

109

はできるが、もう少し広げて実証実験を行う必要があると感じている。実証実験を行わなければ電

力の安定供給の問題といった技術的な問題の検証ができないため、不特定多数の需要家への電

力融通サービスの普及に向けた法制改正の議論や事業性の評価もできない。そのため、実証実

験のデータをもとに今後の事業化をどうしていくかを検討したいと考えている。（事務局・委員 N）

弊社では P2P には関心を高く持っており、関連するベンチャーにも投資している。事業を進めるう

えで問題と思っているのは、ひとつは安定供給であるが、もうひとつは、事業として成り立つのかと

いう点である。参加する方にとって経済的にメリットがある仕組みができるのか、という点に関心をも

って検討している。（委員 I）

運営主体に関して、貴社としては、「電力市場プラットフォーム提供者」の位置づけか、「サービスプ

ロバイダー」のような立場として事業を行っていくのか。今後の事業性も含めてどのような検討をな

さっているか。（事務局・委員 N）

可能であればプラットフォームのような部分も、新しい価値として提供できればいいと思っている。

（委員 I）

各社電力事業の実証実験を行っているが、プラットフォーマーがいない仕組みをつくるというのは、

感触的に難しいと考えるか。（事務局・委員 N）

現状ではプラットフォーマー・コーディネーターを介さない仕組みは難しいと考える。分散型システ

ムの構築が最終目的ではなく P2P 形式を作って、再生エネルギーの普及や、これまで再生エネル

ギーにアクセスできないような方が、再生エネルギーにアクセスできるようにすることが目的のため、

その目的のもとではコーディネーターやプラットフォーマーなどが必要になってくる。（委員 I）

電力会社各社で、電力融通取引でこのようなプラットフォームを共同で運営していくというのは考え

られるか。（事務局・委員 N）

恐らく難しいと考える。取り掛かりとして１社が始めて、広まることは考えらえる。電力会社が横並び

となってコンソーシアムを組んで運営するという発想は現状持っていない。（委員 H）

運営主体が誰となるか、運営主体に課すべき義務は何か、という２つの検討の方向性があると考え

ている。後者については、供給能力の確保、電力取引量の調整、リライアビリティ等が条件として求

められてくるというご意見を頂いた。また、これまでの議論で、電力融通の実証実験を行うに当たっ

て、プロシューマーは小売電気事業者の枠内で考えるのが現実的ということであったが、小売電気

事業者には実際に色々な義務が課せられている。実証実験を行う上で、すべての義務をプロシュ

ーマーに課す必要があるのか、不要な義務もあるのかについて、議論したい。（事務局・委員 N）

供給能力の確保の義務はおそらく必要だが、個人にどこまでの供給能力を求めるかについては、

程度の問題だと考えている。他に誰かが電力を供給しうるような状態、具体的には小売電気事業

者が他にも存在する場合にプロシューマーが供給能力を確保しておく必要があるのか。（事務局・

委員 N）

110

基本的には、供給能力確保の義務は小売電気事業者が負うものである。小売電気事業者が供給

できない場合、系統運用者である一般送配電事業者が補充することとなる。そのためには、一般送

配電事業者が調整できるような電源をいくつか抱えていなくてはいけない。この際発生するコストは、

最終的には、託送料という形で電気料金に計上される。このため、安定供給を担う一翼として、小

売電気事業者としても自らの需要家に応じるだけの供給能力が求められている。現状のシステムも

一般送配電事業者が安定供給に必要な電力を抱えており、すべての電気事業者が供給量の確

保がしているというが、仮に全ての電源が脱落するような場合も可能性としては考えられる。（委員

C）

そのようななかで、小規模だからといって、小売電気事業者が供給能力確保について全く義務を

負わないとすると、一般送配電事業者が抱えるリスクも高くなる。仮に、分散型の電源供給が主要

なものとなった世界で、供給能力確保義務が課されなくなった場合の社会に与える影響として、す

べての電源のバックアップを誰が用意しなくてはいけないかという議論となる。極めて少ない、全体

の 0.001％程度が対象である場合、必ずしもプロシューマーが供給量を確保しなくても、一般送配

電事業者が対応可能ということがあるかもしれないが、その対象者のために国民全体の電気料金

の負担の中で支えるとして本当に良いのか、という議論はあるだろう。（委員 C）

まず実証実験を始めるという場面で、どの範囲を議論する必要があるのか。現在の議論は針小棒

大なものとなっている印象を受ける。（委員 D）

全体の供給の話になるが、最初の段階では、太陽光等の余剰電力が生じた場合には地域に融通

するが、その他の時間は従来通り小売電気事業者から供給をうけるというパターンが現実的だろう。

近未来の姿としては、従来の小売電力事業との契約は継続して、電気の供給システムが２本立てと

なることを想定している。（委員 A）

ブロックチェーンのシステムを作っている者や、運営をしている事業者に供給条件の説明義務や、

苦情・問い合わせに適切に対応する義務を課すことによって、プロシューマーにそれらの義務を課

さないと整理することについてはどうか。（事務局・委員 N）

何かあった際に苦情を受け付けるのは当然であり、苦情対応については他のシェアリングサービス

で義務付けていることとの兼ね合いもあるため、全く苦情対応の義務を課さないというわけにはなら

ないだろう。また供給条件の説明については、Web 上で行うのであれば、それほど負担とならない

のではないか。消費者団体からの苦情窓口を設けておくという点も事業を行う上で必要だと思われ

る。（委員 D）

実際のオペレーションとしては、スマートフォン上で操作可能なものだろうと考える。（委員 E）

条件の説明義務等については、プロシューマ―ごとに大きく変更することがないようであれば、雛

形の活用が可能ではないか。また、周知義務についてはプラットフォーマー等が取り纏めて実施

すればソリューションになるのではないかとも思われる。例えば、小売電気事業者に対する義務の

111

１つとして「事業を休廃止する際の需要家に対する周知義務」に関して、３ヶ月程度何も実施してい

なかった場合、サービス停止したものとして周知するといったルールを決めておくことで機械的に

行えるのではないか。また、義務の１つに「需給計画等の情報提供義務」があるが、実際はどういっ

たものを作っているか。

（委員 B）

どの程度の需要家層を見込んでいるか、というものであり、プラットフォーマー等の統括者が支援で

きるものである。（委員 I）

小売電気事業者に対する義務の１つとして「広域的運営推進機関への加入義務」があるが、当該

機関の会費は高額であるか。（委員 B）

高額ではないが、現行水準ではプロシューマーにとっては取引量に見合わない額である可能性が

高いため、多頻度小額取引をイメージした参加者の場合には、新たな価格設定を設けることも可能

ではないか。支払いに当たっては、個々のプロシューマーが各々行うよりは、プラットフォーマーの

ような存在がまとめて行うのがよいのではないか。（委員 I）

レギュラトリー・サンドボックスのなかで、必要な手続きを段階的に検討するのがよいと思われる。

（事務局・委員 M）

レギュラトリー･サンドボックスの内容や、進め方については、どのようになっているか。ルールを新

たに設けられるような方向性か、既存の法令に該当させない方向性なのかが知りたい。（委員 D）

具体的な内容については、確認する77。（経産省・委員 K）

プロシューマーについて、個人といえども悪質な事業者に行政指導は必要だと考えるか。（事務

局・委員 N）

プロシューマーがどれだけの役割を担っていくかにもよると思われる。（委員 C）

前回での議論にて、プロシューマーに関しては小売電気事業者に該当するよう整理することとし、

託送料金は負担すべきであるという結論となったと認識している。実際に、どの程度託送料金を負

担すべきかについては、電力融通取引の仕組みの普及の程度にもよるかと考える。将来的な観点

で、電力融通取引が行われている区域・人数等によって、柔軟に託送料金を変えることは可能か。

（事務局・委員 N）

社会制度の変化に応じて当然変化があってよいものと考える。（委員 H）

事業性の観点から、託送料金制度の論点については非常に重要なものと捉えている。P2P 形式で

の電力融通について普及を促進するような制度設計にして頂きたい。（委員 I）

77 平成 30 年 2 月 9 日、プロジェクト型「規制のサンドボックス」制度の創設を含む「生産性向上特別措置法案」が閣

議決定された。新技術等実証に関して、法令違反しないことの確認に加えて、必要に応じて、規制の特例を措置す

る。なお、本法案では、規制当局からの規制の適用に関して遅滞なく回答するものとされ、社会実験等の早期実現

が期待される。

経済産業省報道発表< http://www.meti.go.jp/press/2017/02/20180209001/20180209001.html >

（平成 30 年 2 月 9 日）

112

株式会社日本総合研究所より、資料 1「ブロックチェーン法制度検討会 （物流・SC・モビリティ分野）

第 2 回 事務局資料」を用いて EV バッテリー管理に関するユースケース、法制度上の課題、前回

検討会の検討内容等をご説明した。

■ 質疑応答

資料１（p.46）の「論点 2：電池を二次利用した場合の製造物責任」に関して、バッテリーメーカー側

の懸念として、バッテリーが当初予定していた用途以外に使用されることが挙がっている。何か問

題が起こった際、誰が責任を取るかという懸念の中で、バッテリーメーカー側の反対もあり当該シス

テムの実装が進まないという声も聞く。その中で、EV の蓄電池が別の用途に使用されることを知ら

なかったバッテリーメーカーが、ブロックチェーンの一ノードとなることで、回収事業者や蓄電池を

組み替えて回収事業者や再販事業者が他の用途に使用することを知り、当該他の用途に使用し

た蓄電池により事故が発生した場合に、責任を負うかが、問題となるのではないか。これについて

は先ほどのバッテリーメーカーの懸念と合わせて、かかる責任について議論したい。基本的にバッ

テリーを組み替えた時点で組み替えた側が製造物責任を負うということでよいか。（事務局・委員

N）

パロマ湯沸器死亡事故にて、事故が当然に予測できたならば製造側の責任、とする裁判例78が出

ていたと認識している。この事例が参考になるのではないか。（委員 E）

パロマ湯沸器死亡事故は、過去にパロマ製品の湯沸器で複数回改造による事故が発生し、経営

者もこれを認識しており、かつ容易に改造可能な状況であるにもかかわらず、湯沸器メーカーが対

応しなかったことが問われたものであった。（委員 B）

国を跨る場合、具体的には、海外で生産された電池を日本に持ってきて再利用した場合、どの国

の法律が適用されるのか。また残存価値自体を 1 つのブロックチェーン上にデータとして保存する

が、その担保の方法を我々側は考えなければならない。国を跨ってデータを保全する場合、どのよ

うな規制が課せられるのか。自動事故通報システムの搭載がヨーロッパと日本で義務化されたが、

そういった枠組みが必要になってくるのではないかと考えている。（委員 F）

当初の想定ではスマートシティ構想の中で、国内のレギュレーションに拘らず実施してみたらどうか、

という考えからスタートしているが、実際に日本と海外とで取引するモデルはかなり敷居が高いと思

われる。（委員 F）

製造物責任法の観点では、損害の発生場所、関係者の所在等について個別の司法がどこまで及

ぶかを見ていくこととなる。（委員 E）

以上

78 東京地裁平成 22 年 5 月 11 日判決。本件は、パロマ工業が製造してパロマが販売した強制排気式ガス湯沸器

が、不正な改造がなされた結果、強制排気装置の作動なしに本件湯沸器が使用され、強制排気式ガス湯沸器が

不完全燃焼を起こし多量の一酸化炭素が排出され、居住者が一酸化炭素中毒により死傷した事故について、同湯

沸器を製造・販売した会社に、点検・回収等の措置を講じなかった過失があるとして、業務上過失致死傷罪の成立

が認められた事例。

113

経済産業省 委託調査

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

ブロックチェーン法制度検討会（横断分野）

（第 1 回）

議事録（案）

日時 2018 年 2 月 7 日（火） 13:00-15:00

場所 経済産業省別館 3 階 310 共用会議室

構成員

渥美坂井法律事務所 弁護士 委員 A

一般社団法人日本ブロックチェーン協会 委員 B

駒澤綜合法律事務所 弁護士 委員 C

森・濱田松本法律事務所 弁護士 委員 D

アンダーソン・毛利・友常法律事務所 弁護士 委員 E

特定非営利活動法人ヘルスケアクラウド研究会 理事 委員 F

創法律事務所 弁護士 委員 G

オブザーバー 経済産業省 商務情報政策局 情報経済課 課長補佐 委員 H

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 I

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 J

経済産業省 商務情報政策局 情報経済課 係長 委員 K

日本電気株式会社 事業イノベーション戦略本部 FinTech 事

業開発室 委員 L

事務局

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ 主席研究員 委員 M

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 N

株式会社日本総合研究所 リサーチ・コンサルティング部門

融合戦略コンサルティンググループ コンサルタント 委員 O

随行者 創法律事務所 委員 P

創法律事務所 委員 Q

アンダーソン・毛利・友常法律事務所 弁護士 委員 R

敬称略

114

議事

(9) 議題

1. スマートコントラクトに関する法制度上の課題の検討

2. 分散型取引に関する責任問題

(10) 配布資料

資料 0 座席表

資料 0 議事次第

資料 0 出席者一覧

資料 1 「ブロックチェーン法制度検討会（横断分野） 第 1 回事務局資料」

議事要旨

(4) 議題

・実装する機能に起因する法制度上の課題

１．スマートコントラクトに関する法制度上の課題の検討

株式会社日本総合研究所（以下日本総研）より、資料 1「ブロックチェーン法制度検討会

（横断分野）第１回 事務局資料」を用いて、検討会の開催概要、ブロックチェーン技術を

活用した事業について業界横断的に検討が必要とされる法制度の概観、および、スマー

トコントラクトに関する法制度上の課題点をご説明した。

質疑応答

ブロックチェーンやスマートコントラクトについて法制度を横断的に議論するとき、権利をトークン等

にどう載せるのかという論点と、トークンの権利を移転するときの対抗要件の論点、加えてファイナリ

ティ・取り戻し・差し押さえの可能性の議論があると思っている。権利移転の話は次回ということなの

で、今回の検討事項に関して言えば、「ブロックチェーン法制度検討会（横断分野） 第 1 回事務

局資料」P.15 の執行可能性について、その他にも、ブロックチェーンに権利を載せたトークンをどう

差し押さえるのかというトークン自体の執行可能性の問題があるのではないか。民事法上も刑事法

上も間接強制以外ではブロックチェーンに記録されているトークンの権利を差し押さえることができ

ない。そういった点も議論に上げるとよい。（委員 G）

契約の成立や証拠能力については基本的に問題がないのではと考える。同資料 p.15「契約の成

立」に関して想定されるシーンとして挙げているケース 1 については、契約の成立を当事者が認識

しているし、ケース 2 も、当事者が AI によって何等かの条件で最適化することをあらかじめ合意し

たうえで、AI に任せるとしており、原則としては問題がない。ブロックチェーン上に書き込んだ証拠

能力についても、日本の民事訴訟法上は何にでも証拠能力があるが、刑事訴訟法上は問題があ

るので議論となる。（委員 G）

スマートコントラクトの中身について、委員 G 先生が仰っている形は契約書の内容を電子化した物

115

というイメージである。一方で多くの場合、スマートコントラクトはプログラムされていて、自然言語で

は記述されていない。よって、この二つは分けた方がよい。お互いが電子署名のようにサインをす

る事で契約が締結されるのはわかりやすい一方で、スマートコントラクトのプロバイダーのようなもの

に対してお金を払って契約を執行するような場合、どの時点で契約が成立されているのか非常に

不透明で、通常プログラムは最小単位で実行されているにすぎないので、この２つは分けて議論

するのが良い。（委員 B）

米国では、裁判所が契約と認めてくれるのか、社会通念上、通常契約と呼べるものなのかという議

論がされているのが、日本においても、スマートコントラクトに関する法的な意味について、認識を

醸成するということが重要ではないか。例えば、スマートコントラクトの法的な証拠能力等に関して、

政府において検討がなされていると主張していくことである程度補えていくのではないか。（委員

D）

各国でブロックチェーンに対応する法制度はデラウェア州やフランスなどで議論されているが、日

本だと電子的に交付する・提供することができるものに関して、基本的にクライアントサーバー型を

想定しているものがあり、それを分散台帳型でもいいのか、それとも電子トークンに入れるかが社会

実装という世界になるのではないか。（委員 D）

本検討会のアウトプットとして、法律を変えるという視点に加えて、レポートを出す事によって事実上

のお墨付きを与える事も視野にあっても良いのではないか。例えば、商法における有価証券の電

子化の文脈の中でとらえられるものは色々あるが、このうち船荷証券などは勝手に電子化して良い

のかわからないという議論がある。現在、倉荷証券はほとんど使われていないが、商慣習によるも

のであるという事が文献に書いてある。商慣習とは人々の認識の醸成である。倉荷証券のブロック

チェーンによる電子化というのはこういう事であるとレポート等で言っていただけるとそれをベースに

実際に開始・使用され、それが商慣習になっていくという経緯を辿るかもしれない。（委員 D）

医療の契約の成立に必ず出てくるのがインフォームドコンセントの問題である。医療の場合は最終

的には医療訴訟になるのでブロックチェーンの中に入っているインフォームドコンセントの情報を二

次利用し、安全性と医療費の問題が出ててきても、フローができているため、それを共通して使え

ると助かる。

ケースデータの２次利用というところで資産として価値がある。（委員 F）

マウントゴックス事件ではっきりしたのが、国の裁判権や裁判所の決定というのが効力として出てこ

ない点である。ブロックチェーン上で当事者の合意だけで行うと従来ながらの当事者と国の権利の

形でやる仕組みが現れない。破産法の取戻し権に関して、例えば物の所有権が実際にブロックチ

ェーン上のアカウントへの権限として本人にもあるという手続きでやるのか、国の制度上とブロック

チェーン上での真の権利者や破産者について整理する必要がある。（委員 C）

契約の成立については基本的に意思の合致があるか、その中で機械語が消費者・利用者にとっ

116

てわかるものか、社会的な認知やサービス内容が分かるのかが必要であり、これはこういうものだと

報告書に記載することに意味がある。（ISO でスマートコントラクトのワーキンググループで議論して

いる中で）各国では日本法については問題が少ないと思われているが、諸外国の法律では（契約

の成立要件等としての）書面性を満たさない場合があるので、どう歩調を合わせていくのか、国際

的な契約も容易になってくるため、枠組みの議論に日本として参加していくのが課題となる。

AI で自動的に契約する場合、AI 自身が自分で改善し、元々想定したものとは違ってい

たときは、意思表示の合致が存在しないのでないか。その場合はどのように考えるのか。

AI に関しての一般論として、そういう視点がありうる。

証拠能力としては、一般的には電子証拠と同じだが、二段の推定が働く証拠に関しては、

現実の訴訟では電子メールでも十分役割を果たしている場合が多いが、課題としてはあ

りうる。（委員 A）

契約に関する資料として、紙の契約書を電子化したものと、プログラミング言語がそのまま読めるソ

ースコードと中間言語があるが、マシン語は全く読めない。これを裁判所に持って行っても裁判官

が読めずに、意味を成すか疑問である。

再現性という観点では、一般の契約は再現性が高いが、プログラムは同じ状況が再現で

きないことが多々ある。同じスマートコントラクトを違った時間に違った環境で実行した場

合、異なった結果になるということも考えられる。例えばノードが沢山ある中で JPX のレポ

ートでは、外部データを取り込んで、各ノードが外部の株価を分散したとき、どちらのノー

ドが取り込んだデータが正しいのかわからないといったことが指摘されている。

ブロックチェーンには２つのタイプがあり、決定論的に決まるもの、非決定論的に確定し

ないものがある。非決定論的に確定しないものは、契約が成立したように見えても、裁判

所で証拠として出したときに違うデータが出てきて、契約成立と認められないことがあり得

る。プログラムは実行しないと分からないランタイムエラーが多々あるので、再現するには

全く同じ環境を整える必要がある。（委員 B）

プログラムを動かしている人達はどう予測し、信頼しているのか。スマートコントラクトを実装していて、

実行結果が分からないということはないと思うが。（委員 G）

恐らくこのように動くと想定してプログラムしている。例えば、１コインを送ると１回音楽が聞けるシス

テムを作成した場合、再生する曲につき外部参照とする場合、ユーザーはアーティスト A の曲を購

入したのに、外部参照先が変わってしまうと購入した（とされる）曲がアーティスト B の曲に変わって

しまう。プログラムを実行しないとわからない世界と紙に全部書かれていて固定されているものの概

念が違いすぎる。（委員 B）

再現性がないところで、事業者がソリューションとして考えるものとしては、今はどういうものがあるか。

（委員 A）

当社は、過去にロールバックした時に同じような環境にした時に必ず同じように決まる決定論的な

仕様を採用している。よくある仕様として、トランザクションをブロードキャストした時にたまたまそのノ

117

ードが近くにいた人が拾ったなど、メモリープールに入った状態は各ノードによって違うといったこと

がある。一方で、当社では基本的にメモリープールに入っていて序列をつけて、中でソートアウトし

て必ず一様に決まるシーケンサーのようなものをつけている。ただし、ランタイムエラーは絶対に生

じるので、プログラムを走らせないと絶対に結果が分からない。そのときに、ハードディスクがいっぱ

いだと動かないといったことも起こりうる。（委員 B）

イメージしたのは、プログラムを当事者間で合意して走らせると、アーティスト A かアーティスト B い

ずれかの楽曲が出てきて、その時出てきたものがアーティスト A か B かはブロックチェーン上で完

全に記憶されていて、改ざんされないというものである。当事者間でプログラムを作ったという結果

自体は変わらないのではないか。（委員 R）

外部参照先は変わっていないが、外部参照先の内容が変わることによって、結果としての値が変

わっているか分からないという場合が考えられる。（委員 B）

同様の問題はブロックチェーン以外でも発生していて、海外ではリンク先が貼ってあるが、参照先

がおかしいことがある。ブロックチェーンの中と外で両方存在をしていて、ブロックチェーンだけで、

スマートコントラクトの議論をどこまでできるのかわからないことが非常に多い。スマートコントラクトは

魅力的ではあるが、若干何の議論をしているのかわからなくなる。当事者の認識かといわれると、ど

こかに書いてある説明書かもしれないという話があって、普通の意思の合致というプリミティブな気

持ちでいくとよくわからない事がある。

学者によっては、準拠法の方かと言われサーバーにあるわけではなく世界中に散っている国際私

法の中では、準拠法がないことがいいと考えられており、裁判所に行ったらどうするかというと裁判

所は一体どこで合意しているのかという話がある。（委員 D）

鍵の問題もある。一人のひとが鍵を持っていてサインして契約をしたあと、それを誰かにあげた場

合やコピーした場合、契約の当事者が誰なのか、ビットコインでいえば、所有権や債権はどちらが

有しているか、マルチシグの場合はどうか、といった議論がある。

（委員 B）

執行可能性について、動産か不動産かで異なる。不動産の場合は、登記制度があり、裁判では通

用する。動産の場合、動産を集中管理して、管理者がいるのであればトークン上で持っている人に

渡すというやり方はあるかと思う。動産なのか不動産なのか、オフィシャルなのかアンオフィシャルな

のか分けて考える観点は重要だと考える。閉じたプラットフォーム内であれば執行可能性があるか

議論しやすい。拡散している場合は、裁判所に対してどう立証していくのか課題である。（委員 R）

契約成立の有効性に関して、基本的には当事者の意思が合致していれば契約は認められる。恐

らく問題となるのは、意思の合致という点について、契約内容について認識しているか、説明につ

いてもブロックチェーンのシステムのみを伝えるか、ブロックチェーンの外のシステムについても説

明するのかという点と考える。契約内容の説明をするとは思うものの、実務上の問題としてその他当

事者が認識していない問題があるか。（委員 N）

118

ソースコードが存在しないと、（契約内容について）分からないと思われる。例えば１億円相当の不

動産を仮想通貨で購入したところ、なんらかの権利の証明がどこかに行ってしまったといった状況

で、返金を迫る場合に、ソースコードの存在は議論になるだろう。（委員 B）

意思の合致はあるが、ソースコードがなくなっているので、意思の合致が本当にあったのか、後か

ら意思の合致の有無やその内容を追跡のしようがないという状況かと思われる。（委員 G）

私法における、契約の成立といえる程度の意志の合致、という議論があり、それは、単に抽象的に

こうだと思っていただけだと契約は成立していない、というものである。バインディングできるに相応

しい程度の意思の合致という概念を法律家は共有して持っており、そういった意味での契約の成

立までの確保は難しい。裁判の場でも、あるケースについて、契約が成立したとはいえず、単なる

期待にすぎないと結論付けられる場合もある。契約成立有無については安易に判断できない。（委

員 D）

何をやっているか、スマートコントラクトがどういう仕組みのときに契約が成立し、拘束力がある状態

になっているのか知らせた上で、何かしらの行為をさせる必要がある。恐らく対消費者の場合、「電

子消費者契約及び電子承諾通知に関する法律」の趣旨79通り、錯誤の主張がなされる場合がある

から、どこからが契約成立なのかを明らかにしておく必要性がある。その意味では、実際にスマート

コントラクトを作る事業者が、そういった懸念を事前に認識した上で設計する必要がある。証拠をど

のように残すかという点に関して、ソースコードのようなものまで追えるようにするのかも含め、実際

に何を証拠に残すかについては議論の余地がある。（委員 A）

消費者とのインターフェイスは自然言語で分かるものである必要がある。そのインターフェイスを使

って契約を成立させたことの記録について、最終的に専門家がみれば分かる状態にしておけば、

証拠としての価値はあると思われる。契約成立の時点では、消費者・裁判官が見て分かる形態で

あることが絶対条件ではないか。このような説明を受けて同意をして契約を締結した、ということまで

も、裁判で証拠として残せる形でブロックチェーン上に書き込めるかどうかが、最初の段階で検討

する必要がある。（委員 R）

国際私法的な観点で、サーバーが分散しており、人々が世界中に点在している状況下で、何を準

拠法とし、意思の合致はどの法律で考えるべきかは悩ましい問題である。（委員 G）

基本的には合意ベースで作られているので、合意ベースで進むことも多いと思われる。国が関与

する仕組み、準拠法のレベルで見ても、消費者保護のための法は属地的なものであるから、スマ

ートコントラクトの枠組みとどのように組み合わせるか、検討が必要だ。破産手続きのケースでは、

裁判所が破産したから処分できないと判断した場合でも、ブロックチェーン上は処分できないという

表示ができない、といったことも考えられる。

（委員 C）

79 「電子消費者契約及び電子承諾通知に関する法律」第一条 この法律は、消費者が行う電子消費者契約の要

素に特定の錯誤があった場合及び隔地者間の契約において電子承諾通知を発する場合に関し民法（明治二十九

年法律第八十九号）の特例を定めるものとする。

119

法律の解釈でのアプローチでは議論が詰まってしまうため、日本の実務ではこのように行う、という

のを共有するといいのではないか。スマートコントラクトに関しても、約款のようなものを示しておき、

トークンの振舞についても規定すれば足りると考える。その程度まで示すことができれば、日本の

プラクティスとして実務を進めることができる。法律上の扱いが完璧に分からないと何も進められな

いということではなく、実務的にこうやれば対処できるというものが決められていればよいと思われる。

（委員 D）

国際法の観点については、プラクティスとしては準拠法を分かるように記載しておくことで対処でき

ると思われる。紛争解決手段という点で見れば、アジアでやろうとしたとき、日本の裁判の判決はア

ジアでは殆ど執行できないため、仲裁か、現地の裁判所で裁判するほかない。プラクティスを書く

場合には、仲裁という形で記載するしかない。（委員 A）

“Code is Law”の思想を掲げている者が準拠法を指定しない理由は、準拠法を指定しないことが

その者について有利だからである。ここでの議論は、日本法を準拠法にしてよりクリアで保護される、

とするためには、どういうプラクティスにしたらよいか、どういう法律改正をすれば様々な事業者が日

本法を使ってくれるか、という点を議論するのがよい。（委員 G）

エンジニアとしては、証拠能力として認められるか分からない状態でサービスをローンチした場合、

消費者からクレームがくるのではないかという懸念があるのではないか。実務上、安定的・確定的

に契約のプログラムの実行内容が決まってこないことに対し、どのように対処するかという点につい

て、ご意見頂きたい。（事務局・委員 N）

法律家としての枠組みとしては、契約の成立は、当事者がいて合意があり内容が確定いていること

が分かればいいと考える。内容が確定しているからこそ契約が成立しているのであって、後は立証

の問題、というような論点のきり方をする。お互いにそれぞれの意思が合致していることが分かれば

評価としては契約が成立していなかったと認識されるだけの話である。むしろどこで意識が一致し

ていないのか、という点を確認することとなる。（委員 C）

意思の合致というのは、契約の成立の論点よりも、裁判になったときの実務上の論点ということか。

（委員 N）

証拠能力は無制限なので、契約が成立したことによって利益を得たいのであれば、後からトレース

できるよう証跡を取っておくことが、法律家からのアプローチとしてのアドバイスである。（委員 C）

ブロックチェーン上で、契約についての実行結果を毎回記録することは現実的であるか。（委員 N）

技術的には可能。データが膨大になるが、どの状態でも実行結果をブロックチェーンに書き込むな

ら消すことはできない。ソースコードもその断面のものを保管しておき、そこで合意した内容につい

て再現した時には、ソースコードをコンパイルして実行してみることで結果を確認できる。ステートト

ランディションといってすべてのステートが記録されており、それがブロックチェーンに入っていると

なれば、非常に堅牢な証跡と言えよう。（委員 B）

実務上、事業者としてはそのように対応せざるを得ないのか。（事務局・委員 N）

個別具体的な事例に応じて、判断したい。（委員 G）

120

特に少額取引でブロックチェーンを使う場合について、厳密な証跡の取得はコストとして見合わな

くなる場合がある。取引によって、証拠として十分ではないかもしれないという点を消費者に注意喚

起し、後は自己判断とするケースもあるだろう。（委員 A）

（事務局の問について）スマートコントラクトについて、契約のプログラムの詳細な実行内容が決まら

ないという場合を想定するとしていたが、仮に売買の目的物について認識が異なる場合には、契

約自体が成立していないのではないかと思われる。（委員 R）

契約にあたっては、目的物は外部参照によって設定する、というケースも考えられる。（委員 G）

売買の目的物について認識が異なるケースは、スマートコントラクトでなくとも起こり得る。CDジャケ

ットとは異なるアーティストの曲が収録された CD が販売されていた場合、すり変えたかどうかはわ

からない、販売元が分からず、お互い証明できない。（委員 B）

○月○日○時現在、○商店の○階の棚の上から○段目の右から○つ目の CD を取って購入する

という契約を行った場合に、契約は成立しているが、実際にその棚に何が入っていたかが後から追

跡できないといったパターンが想定できる。（委員 G）

少額商品であれば、クレーム対応のコストを鑑み事業者が厳密に事実関係を追跡せずに補償する

ことが考えられるが、高額商品の取引を行う場合、事実関係が証明出来ないときはどのように対処

するか。（委員 B）

高額商品の取引は、紛争となる可能性がある契約はしないか、写真等の証跡を取る、第三者によ

って証明させるといった手法が想定できる。（委員 G）

スマートコントラクトでの取引の場合、対象が少額の場合は厳格に決める必要はないが、不動産売

買等では、いろいろな防御策が必要、という考えか。（委員 B）

そのように考える。（委員 G）

・実装する機能に起因する法制度上の課題

2.分散型取引（シェアリングエコノミー）に関する責任問題

株式会社日本総合研究所（以下日本総研）より、資料 1「ブロックチェーン法制度検討会 （横断分

野）第１回 事務局資料」を用いて、シェアリングエコノミーに関する法制度上の課題点をご説明し

た。

サービス主体が存在するものについては、ブロックチェーン技術を用いたとしても利用規約を整備

するなど、サーバー･クライアント形式で実装する他のサービスと大差はないが、問題は、DApps80

である。DApps では定義できないため、検討が必要となる。（委員 B）

「分散型」システムの場合、業規制の問題と民事上の問題がある。一般に、規制の目的として、社

会全体における利益の保護と複雑な事故が発生した場合の消費者保護の 2 つがある。DApps に

おける基本的な考え方は、消費者保護については自己責任であるというのが原則であることを強

80 非中央集権・分散型のアプリケーション、Decentralized Applications の略

121

調した方がよい。（委員 G）

分散型の取引所もネット上にあるが、規制対象になるかという議論がある。多くの場合は管理主体

がいるので、「準分散型」が多いが、その場合は、管理主体として登録やライセンスを求めたうえで、

プロシューマーを利用してサービスを提供する主体に関しては、基本的に管理者が消費者保護に

関する取組を行うが、一部はプロシューマーに対応してもらうように整理するイメージであろう。（委

員 R）

「準分散型」か「分散型」なのかが問題ではなく、サービス内容が不十分だった場合に何がおきる

かを特定しないと議論にならない。例えば、スマートコントラクトでプログラムのミスがあった場合、ミ

スによって何が問題となるかによって具体的に違ってくる。

（委員 C）

バグでよくある無限ループで、コードの文法上は問題ないが、プログラムを実行させた結果ループ

してしまう事がある。実際に Uber で事故を起こしたことがあるので実行してみないとわからない。普

通の契約書で無限ループのような状況はないか。プログラムの場合は上から実行するというルール

があるが、紙に書いてある契約書は同列とみるのか、両方が無効なのか全体が無効になるのか、

矛盾が生じた契約書はどう処理するのかという事に似ている。（委員 B）

一般に全体の中で矛盾が生じることはあるが、裁判所が意思の解釈をして総合考慮し最終的に裁

判官が判決を下す。DApps の場合、それを人が介入して行うのは難しいかもしれない。（委員 R）

有体物質として一体化しているプログラムは製造物責任法で規制は厳しい。

製造物責任法の考え方として、フラグ上のプログラムが不都合になったとき、どこまで及ぶかという

考え方は出てくる。逆に言うと普通のプログラムがプログラミングの中であって情報処理の問題であ

る場合に関しては、現状～提供するもので責任は一切負いません。という枠組みがあって、どの枠

組みでいくのか。シェアリングブロックチェーンが、どれだけ影響するかというと枠組みの中でブロッ

クチェーンであるという事が占める割合は低いという意識がある。（委員 C）

プログラムをダウンロードするときに規約に同意する際に「責任を負いません」と表記すれば故意ま

たは重過失がなければ責任がないのでいいと思う。（委員 G）

民事的責任で、「準分散型」で誰が責任を負うか特定できる場合はあまり考える必要はないが、「分

散型」の場合、スマートコントラクトによる自動的施行で非中央集権性のため特定の運営主体が存

在せず、物の取引であればそれで問題ないが、規制が厳しい分野においては保険などの責任が

取れる主体を設置する必要があるか考えなければいけない。

（委員 A）

ただし、既存の業法よりも厳しくならないようにした方がよい。運営主体がある場合、参加者（プロシ

ューマー）に対しては、義務を軽くするのが一般論として言える。完全分散型の場合もどのようにし

ていくのかがあると思うが、実質的な保護が満たされる場合、その部分については規制がなくてもよ

い。ブロックチェーン以外のもので担保できるのであれば、軽くする考え方である。（委員 A）

122

仮想通貨取引所を運営する合同会社リップルトレードジャパンの元代表が詐欺容疑で逮捕された

事件があったが、リップル社は分散型環境のソフトウェアを提供し、ゲートウェイが代理店として整

理するか否かという話と似ていて、ゲートウェイで何かが発生した際に、責任はリップルが負うのか

どうかという議論がある。（委員 B）

P2P の議論で分散型について責任を負わなくてよい場合があるのではないか。オープンソースの

開発者コミュニティーに関して、社会的には問題ないといった議論である。

（委員 E）

開発者コミュニティーが完全分散型でシステムを構築して、当該システムで誰かが被害を被ったと

きに誰が責任を問われるかに関して、ウィニーの話が分かりやすいのではないか。（委員 N）

ウィニーの事件81は評価がわかれる。ソースコードだけをみると書いた人がダークサイドに落ちる意

思を持っていたのではないかというのは情報セキュリティ業界の多数説なので、逆に言うとソースコ

ードから作者の意図が判明しなかったという裁判所の判断が問題だと情報セキュリティ関係者は指

摘している。この点に関しては、「デュアルユース」のような両用ツールに関する刑事的規制、サイ

バー犯罪に関する条約第６条「装置の濫用」に対応するための国内法化に関して議論が進んでい

る。（委員 C）

技術の中立性というキーワードに集約されるのではないか。（委員 E）

結局、利益を得ているのではないか。最近分散型取引所（DEX）が注目されており、DEX であるた

め法律に触れないと主張されることがあるが、少なくとも管理者や利益を得る主体がいるように思え

る。（委員 B）

DApps だと問題にならないと思う。委員 B 氏のおっしゃる DEX はおそらく実際に管理者がいるこ

こでいう準分散型だと思う。本当に分散していて単にプログラムを提供しているだけで、プログラム

が技術中立的であれば、プログラム開発者は責任を負わない。ただ、本当に分散型がなかなかな

81  最三 平成 23 年 12 月 19 日 刑集 第 65 巻 9 号 1380 頁。P2P 型ファイル共有ソフトＷｉｎｎｙ（以下、「本件ソフト」

という。）の開発者が、当該ソフトをインターネットを通じて不特定多数の者に公開、提供し、正犯者がこれを利用し

て著作物の公衆送信権を侵害することを幇助したとして、本件ソフトの開発者が著作権法違反幇助に問われた事

案。判決では、本件ソフトは、「適法な用途にも、著作権侵害という違法な用途にも利用できる」価値中立的ソフトで

あるとしつつ、本件ソフトを用いて著作権侵害を行うかは利用者の判断に委ねられていること、不特定多数の者に

対して無償で公開，提供し，利用者の意見を聴取しながら当該ソフトの開発を進めるという方法は合理的なものとし

て一般に受け取られていること、さらにソフトの開発を萎縮させてはならないことを踏まえて、「単に他人の著作権侵

害に利用される一般的可能性があり，それを提供者において認識、認容しつつ当該ソフトの公開、提供をし、それ

を用いて著作権侵害が行われたというだけで、直ちに著作権侵害の幇助行為に当たると解すべきではない」ことが

示された。

具体的には、「ソフトの提供者において，当該ソフトを利用して現に行われようとしている具体的な著作権侵害を

認識、認容しながら、その公開，提供を行い，実際に当該著作権侵害が行われた場合や、当該ソフトの性質、その

客観的利用状況，提供方法などに照らし、同ソフトを入手する者のうち例外的とはいえない範囲の者が同ソフトを著

作権侵害に利用する蓋然性が高いと認められる場合で、提供者もそのことを認識、認容しながら同ソフトの公開，

提供を行い，実際にそれを用いて著作権侵害（正犯行為）が行われたときに限り、当該ソフトの公開、提供行為が

それらの著作権侵害の幇助行為に当たると解するのが相当である」ことが示された。上記に関して、本件において

は、利用者に対して著作権侵害に利用しないよう告知していることや P2P 型の大規模ファイル共有システムの大規

模な社会実験を目的としていたことなどから、「例外的とはいえない範囲の者がそれを著作権侵害に利用する蓋然

性が高いことを認識、認容していたとまで認め」られず、著作権法違反罪の幇助犯の故意を欠くため、請求が棄却

された。

123

いというのはおっしゃる通り。（委員 G）

例えば、仮想通貨で最初に参加した人が新規コインを取得して利益を得られる。そこにプログラム

を開発した人が入って利益を得るといったことがある。（委員 B）

プログラムを開発して、例えば１つ１つプログラムを売るたびに、いくらもらえるか、そのあとはプログ

ラムを走らせてくださいというのは、プログラムを管理していない。どの仮想通貨をリスティングする

などを決めるのは管理しているといえる。（委員 G）

どの仮想通貨を使うか選ぶか決めていないが、アルゴリズムで自動的にきまる。そのアルゴリズムを

決定する。（委員 B）

アルゴリズムを作ったあとに変更したいといったら純粋な分散型だが、適宜変更できるものなら分散

型ではないということになる。ハードフォークの仕方が分散していて、マイナーの 50％で取り決める

のであれば分散型だが、誰かが決めるのであれば準分散型になる。そこは事実による。（委員 G）

完全に分散化していて、ソフトウェアだけを提供しているとき、意思決定が 100 人で分散されていた

ら、責任はこの 100 人に及ぶのか。ビットコインのように 100 万人が意思決定に参加していたら、

100 万人が責任者になるということでよいか。（委員 B）

そのような考え方でも問題ないと思う。ただ、分散していればしているほど、最終的には多数決にな

る。（委員 G）

会社の株主が議決権の行使によって責任を負う場合がどこまであるかというと、ケースによってでは

あるが、基本的にはないことが多い。（委員 G）

業規制の責任を負うのか、民事責任を負うのかという事は別だが、継続的な管理をして利益を得て

いるなら営業していることになるため業規制の対象になる。悪意のあるプログラムを流していれば、

継続的に管理していなくても、それによってどこかに被害が出れば民事的な責任を負うことになる

ことがある。（委員 R）

例えば分散型のシステムで保険を提供するサービスを考えたとき、リスク移転のところを引き受けま

すとなると、そこから出てくる保険料を管理することで保険業をすることになる。例えば、支払いの判

断だけや損害の認定の判断だけだと、それが保険業といえないというのが起こりえる。分散型アプ

リだと、これができてしまう。中央集権型のものだと引き受けてお金を扱いますということになるので、

スマートコントラクトで実行できるといっても、通常管理者がいるという事になる。しかし、保険料相当

をトークンで受け取るとなったとき、トークンの受け取り先がどこにあるのかというと、業法で想定して

いる管理者がいないという状態をつくることができる。ただし、そのような分散型のシステムを作って

放置しても誰も利用しない。そのため、特定の主体がマーケティング活動を行っているため、マー

ケティング活動する事が勧誘にあたるのか、募集にあたるのかといった問題となることはある。（委

員 D）

DApps といっても全部自分のところでやっているわけではなく、実際にはデータベースを使ってそ

の上にのっかっているとかが実際は多いと思う。なので、自分達には責任がないというケースが多

い。そこにのっかっている所はどうするか。SLA（Service Level Agreement）はどうするのか、責任

分界点をどうするかという話がこれから出てくるのではないか。（委員 F）

124

以上

125

経済産業省 委託調査

「平成２９年度我が国におけるデータ駆動型社会に係る基盤整備

（分散型システムに対応した技術・制度等に係る調査）」

ブロックチェーン法制度検討会（横断分野）

（第 2 回）

議事録（案）

区分 ご所属・役職等 氏 名

構成員

渥美坂井法律事務所 弁護士 委員 A

一般社団法人日本ブロックチェーン協会 委員 B

アンダーソン・毛利・友常法律事務所 弁護士 委員 C

アンダーソン・毛利・友常法律事務所 弁護士 委員 D

森・濱田松本法律事務所 弁護士 委員 E

特定非営利活動法人ヘルスケアクラウド研究会 理事 委員 F

創法律事務所 弁護士 委員 G

国際大学グローバル・コミュニケーション・センター 研

究部長 委員 H

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 I

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 J

経済産業省 商務情報政策局 情報経済課 課長補佐 委員 K

経済産業省 商務情報政策局 情報経済課 係長 委員 L

事務局

株式会社日本総合研究所 リサーチ・コンサルティング

部門

融合戦略コンサルティンググループ 主席研究員

委員 M

株式会社日本総合研究所 リサーチ・コンサルティング

部門

融合戦略コンサルティンググループ コンサルタント

委員 N

株式会社日本総合研究所 リサーチ・コンサルティング

部門

戦略コンサルティンググループ 通信・メディア・ハイ

テク戦略クラスター

委員 O

株式会社日本総合研究所 リサーチ・コンサルティング

部門

融合戦略コンサルティンググループ コンサルタント

委員 P

株式会社日本総合研究所 リサーチ・コンサルティング 委員 U

126

区分 ご所属・役職等 氏 名

部門

オブザーバ

ー・

随行

日本電気株式会社 金融システム開発本部 委員 Q

日本電気株式会社 事業イノベーション戦略本部

FinTech 事業開発室

委員 R

創法律事務所 委員 S

アンダーソン・毛利・友常法律事務所 弁護士 委員 T

敬称略

127

議事

(11) 議題

第 1 回の検討内容

情報通信技術の利用に係わる論点

アセット管理（権利移転、価値記録等）（トークンの法的位置づけ）

(12) 配布資料

資料 0 座席表

資料 0 議事次第

資料 0 出席者一覧

資料 1 「ブロックチェーン法制度検討会（横断分野） 第 2 回事務局資料」

議事要旨

議題

第 1 回の検討内容

株式会社日本総合研究所（以下日本総研）より、資料 1「ブロックチェーン法制度検討会 （横断分

野）第 2 回 事務局資料」を用いて、前回検討会の検討内容をご説明した。

質疑応答

事務局資料 P.12 の「約款等において準拠法を日本法に指定することが有用である」旨の記載に

ついて違和感がある。事業者にとっては、“Code is Law”の考え方を主張して、準拠法を指定せず

に、訴訟になった場合に解釈のつまみ食いをする方が都合がいい。実際に準拠法を指定しない事

業者が多いように思われる。日本法を準拠法として指定した方が有利であると主張するのであれば、

何故有利なのかを整理する必要がある。また、日本法ではトークンに権利を記録するという考え方

がこれまで無かったために、権利の記録の仕方、トークンの移転に伴う権利移転の実現可否、実

現にあたっての法改正の要否等を検討する必要がある。このような検討を行わないと、現状約款等

で準拠法として日本法を指定することが有用だとは主張できないだろう。（委員 G）

準拠法を明記していない場合、法律上どのように取り扱われるか。紛争解決にあたり、複数の国の

法律が準拠法とされることはないか。（委員 B）

国際私法上は、契約主体の所在地や契約が成立した場所など、当該契約に関して最も密接に関

連している「最密接関係地」に基づくと整理されている。また、複数の国がそれぞれ、管轄が及ぶと

主張することはあるが、最終的には１国に定まる。（委員 C）

そもそも、どの国際私法を選択するか、という話もある。一般的には訴えのあった裁判所を包含す

る国際私法が選択される。先ほど最密接関連地の概念について挙がったが、これは我が国の裁判

所に管轄権が与えられた場合に適用される国際私法「法の適用に関する通則法」のなかでも規定

されているものである。ただ実際には、特則もあるために、準拠法が直ちに決まらない場合も多い。

128

（委員 A）

それでは実際には、準拠法を定めず“Code is Law”を謳えば、事業者が有利な状態になることは

なく、日本においては最密接関連地の概念により準拠法が一意に定まるということか。（委員 B）

準拠法を明記することで法的問題が発生することが明らかに分かってしまう場合には、曖昧にして

おくことで訴えられづらいということはあろう。（委員 G）

国際的な取引を行うにあたり、準拠法を何とするかが争点となることが多い。（委員 B）

金融取引においては、イングリッシュ・ローが選択されることが多い。（委員 C）

The DAO のような非中央集権投資ファンドを作るとなった場合、日本法を準拠法にするとトークン

ホルダーが有する権利が何か、説明がつかないと考える。イングリッシュ・ローであっても恐らく法律

的な解釈が難しいため、ひとまず準拠法は定めないという判断になるのではないか。（委員 G）

国際的に広く行われているデリバティブ取引等も準拠法のベースがあり、イングリッシュ・ロー、ニュ

ーヨーク・ローがよく用いられている。デリバティブのような金融取引では、一番柔軟な法はイングリ

ッシュ・ローである。そのため、これをもとに、ISDA マスター契約と呼ばれる雛形が作成されており、

各国の法律に照らして執行可能性があるか、見解を示すこととなっている。広く世の中で使われる

ものはこの事例のように、細かに執行可能性を確認し、その契約が有効な国を見つけるという活動

が行われている。ただし、これはＩＳＤＡだからできるのであって、さまざまな取引が有り得るスマート

コントラクト全体で検討することは難しい。ただ、現実的には、最もよく使われて柔軟に解釈しうる法

律をとりあえずは選択するという方向性になるだろう。（委員 C）

日本法においては、権利の成立要件と対抗要件は民法で定められており、新しく権利を作りにくい

ことを鑑みると、コモン・ローの方が解釈しやすい。（委員 G）

準拠法を定めない場合、最密接関連地に自動的に定まるために、事業を営む上で使いやすい準

拠法を予め定めた方がよく、もしくは ISDA のような取組みを行い逐一確認するという理解でいる。

なお準拠法を決めたくない、という場合は啓蒙するしかないのだろう。（委員 B）

準拠法が決まっていても、契約に記載のある内容は基本的に優先される。ただ、契約内容の効力

が否定される強行規定を把握しておくことが肝要だ。典型的な例で言えば倒産時であり、基本的

には契約の内容によらず、各国の倒産法が優先する。契約がスムーズに進んでいる場合は、準拠

法の記載がなくとも大きな問題にはならないだろうが、債務不履行や倒産した際に手当てをどこま

で考えるか問題となる。事業を進めるにあたり最も障壁の低い法律を採用したとしても、一部整合

性がとれない箇所も出てくるだろう。

（委員 C）

倒産以外に検討すべきパターンとして、トークン移転に伴う権利移転の場合が考えられる。この旨

の記載が契約で書かれていたとしても、日本法の債権譲渡の考え方に基づくと、トークンの移転に

伴い権利が移転するとは考えづらい。差し押さえ、二重譲渡の場合などは不都合が起きるだろう。

（委員 G）

EU では消費者保護の思想が強く、事業者にとっては不利のように思われる。株式会社 bitflyer で

129

は、利用規約において、「損害の事由が生じた時点から遡って過去 １ヶ月の期間に登録ユーザー

から現実に受領した本サービスの利用料金の総額を上限」とする82旨の記載をしている。日本法で

はこの記載内容が適用されるものの、EU ではこういった記載の有無によらず、事業者が無限責任

を負うスキームになっていると聞いている。（委員 B）

利用規約にて、基本的な部分はある国の法律を準拠法とし、その他は各国の法律に基づくとする

事例があるように思われるが、部分的に事業を進めるに有利な法律を規定することはできないのか。

（委員 B）

出来る部分、出来ない部分があるだろう。仮にアメリカ法を準拠法として採用した場合に、ある部分

だけはアメリカ法が非常に厳しいため、アメリカ以外の国ではこれを適用しない等の判断は合理性

があるだろうが、強行法規の適用などもあり、これにより全てが解決できるとは言えない。（委員 A）

検討にあたっては、法律との整合性をどの程度まで目指すかという前提を置く必要があろう。単純

に利用規約に合意した形跡があり、特殊な場合を除いてスマートコントラクトが実行されると権利移

転する、ということが言えればよいのか、それとも法体系全体にスマートコントラクトの仕組みを適す

るまで求めるのか。厳密に法律との整合性を追求するのであれば、対抗要件についての論点は、

民法を改正しないまでも、借地借家法や債権譲渡の特例法のようなものを立法しなければならな

いだろう。（委員 A）

スマートコントラクトで、債権が問題なく移転するとことまでは確保したい。不動産、有価証券等につ

いては現時点では難しいと思うが、将来的には、ブロックチェーンにあらゆる権利を乗せたい。（委

員 G）

第 1 回の検討内容

日本総研より、資料 1「ブロックチェーン法制度検討会 （横断分野）第 2 回 事務局資料」を用い

て、

情報通信技術の利用に係わる論点をご説明した。

質疑応答

スマートコントラクトになると議論が必要だが、法律的には PDF の電子書類をブロックチェーンに載

せるには、既存の Oracle 等のデータベースに載せるのと何ら変わらないように思われる。事務局

資料 1（p.28）の整理で、ブロックチェーンを用いた交付はブロードキャストしている点でメール等と

類似する旨の記載があるが、メールはブロードキャストしておらず、技術的に異なると考える。メー

82 株式会社 bitflyer 「ご利用規約」https://bitflyer.jp/ja-jp/usepolicy（2018 年 3 月 2 日閲覧）「第 14 条 紛争処

理および損害賠償 2.当社は、本サービスに関連して登録ユーザーが被った損害について、一切賠償の責任を負

いません。なお、消費者契約法の適用その他の理由により、本項その他当社の損害賠償責任を免責する規定にか

かわらず当社が登録ユーザーに対して損害賠償責任を負う場合においても、当社の賠償責任は、損害の事由が

生じた時点から遡って過去 １ヶ月の期間に登録ユーザーから現実に受領した本サービスの利用料金の総額を上

限とします。」

130

ルの法的な定義はあるか。（委員 B）

「厚生労働省の所管する法令の規定に基づく民間事業者等が行う書面の保存等における情報通

信の技術の利用に関する省令」および「経済産業省の所管する法令に係る民間事業者等が行う書

面の保存等における情報通信の技術の利用に関する法律施行規則」において、「民間事業者等

の使用に係る電子計算機に備えられたファイルに記録された書面に記載すべき事項を電気通信

回線を通じて交付等の相手方の閲覧に供し、当該相手方の使用に係る電子計算機に備えられた

ファイルに当該事項を記録する方法」と示されている。閲覧要件があるが、ブロックチェーンも「電

子計算機」として包括できよう。（委員 G）

ブロックチェーンはミドルウェアなので、ブロックチェーン技術を用いたシステムとして、閲覧が可能

である状態になっていれば問題ないだろう。（委員 B）

金融取引の電子化を進めたときにも、実質的にどうか問わず、文言的には読めれば良い、と判断し

た。今回も文言的には読めるということで問題ないだろう。（委員 E）

スマートコントラクトについては、自然言語でかかれている限り既存の枠組みに当てはめられるだろ

う。そもそもメールでの交付を義務付けるといった文言については、法律を変えればよい。（委員

B）

どういったブロックチェーンの利用を想定するのかを、前提として明確にした方がよい。例えば考え

られる 3 つのパターンのうち、1 つ目は、通常の事業者が存在しているなかで、色々な業務を行う

手段があるなかの 1 つのコンポーネントとしてブロックチェーンを使うというパターンだ。その場合は、

事業主体と消費者との関係は恐らく今まで変わらず、既存の法体系で整理できよう。2 つ目として、

業務のほとんど、または全てをスマートコントラクト・ブロックチェーンで行うが、運営主体は明確で

あるパターン。3 つ目として、事業主体が無い、もしくはコミュニティがあるだけの、DAO 等のパター

ンだ。今回のように、政府という責任主体が明確になっている場合には、既存の仕組みに当てはめ

て検討できるだろうが、ブロックチェーンが政府が何かを交付するという業務関係を変えていくとこ

ろまで想定するのであれば、他の論点が出てくると思われる。（委員 H）

ノードを持っているという技術面での話と、責任主体の話は分けて考えるべきであろう。最終的には

事業者がノードを持っていたとしても、そのサービスを提供している者は明確に決まっているだろう。

（委員 B）

3 番目の例では、ファイルポイントのような仕組みがあり、どこかに格納したことをもって交付とする

か、というような場合が考えられよう。（委員 E）

コインでアクセス可能な分散型ストレージがあり、資料 1（p22）の「ロ」をあてはめて解釈できるかを

検討するとどうか。（委員 E）

Dropbox の事例が「ロ」でも読めれば同じだろう。Dropbox と分散型ストレージネットワーク「ファイ

ルコイン」は差異が無いと思われる。（委員 B）

レンタルサーバーを「使用」してホームページを作成することと同様に考えればいいのではないか。

（委員 G）

131

「使用」に係わる電子計算機でよく、「保有」までは求めていないということであろう。（委員 E）

何をもって交付したかに関して、国がタイムスタンプを付けて送信し、既読管理を行えるという仕組

みは作れるため、あまり問題はないように思える。（委員 B）

資料 1（p22）にて前述の「ロ」に関して、「閲覧」をどう解するかが問題となるのでは。両方同じサー

バーを使用していると読めればいいのでは、クラウドでも適用できると判断されているのであればブ

ロックチェーンであっても同様ではないか。（委員 G）

情報を永続化させる機構、SSD やハードディスク化等の永続化ユニットの位置は、法律で規定され

ていないはず。現在でも DB やファイルシステムは、その所在が点在している場合もあり、厳密な所

在地は分からないだろう。概念として記憶領域に保存されていると分かっていれば良いとする現状

を鑑みれば、ユーザーからみたときにここにものがあるとしたときに、クライアント･サーバー形式で

あれ分散型データベースであろうが、同様に考えられるではないか。（委員 B）

資料 1（p22）「ロ」に該当するということでよいのではないか。（委員 G）

資料 1（p22）「ロ」に該当するとなった場合、スマートコントラクトの場合はどうなるか。閲覧要件に関

して、可読性のないコントラクトの内容があるのではないかと考える。（事務局・委員 N）

電子的記録が交付を限定的に認めているのは、交付の相手方が分かるようにするという趣旨なの

で、可読性は必要だろう。（委員 G）

日本準拠法で日本の裁判所へ証拠を提出する際、日本語以外でも有効であり、立証時にも問題

はない。そうであれば、自然言語である必要性はあるが、図形などで表記されていても、スマートコ

ントラクトとバイナリが合っていればいいと思われる。（委員 B）

双方で合意できており、裁判官が読めるように翻訳がついているのならいいと思う。また、正しい翻

訳ができるのであれば、暗号化された状態でもいい。ただし、保険約款などの契約者に提示しなけ

ればならない書類でのスマートコントラクトの使用はできないだろう。（委員 E）

法的にはいままでの約款や契約時と同じような方法で履行する。（委員 H）

これまで通り、資料 1（p22）「ロ」と同じでよいのではないか。（委員 G）

アセット管理に関する法制度上の課題の検討

日本総研より、資料１事務局資料を用いてアセット管理（権利移転、価値記録等）、トークンの法的

位置づけ、スマートトークンプラットフォームのサービスモデルイメージ、利用形態・イメージと法的

な論点についてご説明した。

質疑応答

資料 1（p32）スマートトークンプラットフォームについて、法律を守れば進められるだろう。トークンに

ついての分類に関して、整理を見直す必要があろう。「会員権型」についてはライセンス型とも言わ

れるが、いわゆる契約上の地位を指している。「プリペイドカード型」トークンは通常の前払い式支

132

払い手段。「ファンド持分型」トークンとしては日本有価証券に拘ることはなく、金融商品取引法上

の有価証券を指す。「権利証明」型トークンとしているものは曖昧で、商法上の有価証券も入って

いるだろうし、それ以外のものも入っているように見える。それぞれ法的な性質は明らかなので、そ

れぞれの法律を守ればいいだけのように思える。（委員 E）

日本の有価証券はエクイティが無い前提で作るが、ブロックチェーンでは、投信の持分というもので

はないかという話があがり、法的な性質をどう考えるか、という問題に直面する。日本法では金融商

品取引法上の 1項有価証券・2項有価証券83を区分しているが、ブロックチェーンに載せると、区別

が分からなくなる。この課題については具体的な解が出ていないが、ここを明らかにすれば、エクイ

ティ・トークンの健全な普及が進むのではないか。（委員 E）

もともとの 1 項有価証券、2 項有価証券の概念に、ファンド持分だが流通するもの、というものが存

在しない。現在の金融証券取引法の考え方で見れば、カテゴリー上は 2 項有価証券だが、2 項有

価証券を流通させる場が想定されていない。トークンであるがマーケットを作って流通させることは

できないことになる。立法的整理を行う必要があろう。（委員 C）

発行体が行政機関の地域通貨の場合、行政機関は両方守らなくてもいいのか。（委員 B）

金融証券取引法において、国が発行する国債等は既に書かれているので、例外規定がない限り

守らなくてもよい。地域通貨は前払式支払手段でも可能。記載されている場合にのみ守らなくても

よい。資料 1（p.38）は前払式支払手段でも集団投資スキームでもできる。機構体であれば、前払

式支払手段であれば可能である。（委員 G）

機構体が業務登録するというのは有り得るのか。（委員 B）

株式会社でないと仮想通貨の発行はできない。株式会社を設立し、そこが Hub となれば発行可能

となる。道の駅等がその事例である。（委員 C）

論点としては、実態と法律的があっていないということであろう。（委員 C）

金融規制法の論点と私法の分類とは異なるだろう。金融規制法は、規制を守って遂行できるかどう

か、という点だが、私法の分類は何に該当するかというものである。「権利証明」型トークンは異なる。

（委員 C）

物の所有権をトークンに書き込んだとしても、宣言しているだけであって、所有権の設定はされない

と考えられるか。（事務局・委員 N）

トークンは二重譲渡がほぼ困難だが、物の二重譲渡は出来てしまう。手形等の法律が設けられて

いるものであれば二重譲渡させない仕組みが実現できるだろうが、そうでなければ難しい。（委員

83 金融商品取引法において、有価証券には、第 2 条 1 項で定められる「1 項有価証券」と第 2 条 2 項で定められる

「2 項有価証券」の 2 種類が存在する。1 項有価証券は国債証券や株券又は新株予約権証券があたり、2 項有価証

券は証券又は証書に表示される権利以外の権利を指し、具体的には信託の受益権等が該当する。2 項有価証券

は「みなし有価証券」とも呼ばれ、証券や証書に表示されるようなものではないものの、投資者保護の必要性がある

ことから、有価証券とみなして、金融商品取引法の適用を受けている。

133

E）

トークンの分類を行うに当たっては、行政が何かしたいのか、ICO の文脈を意識しているのか。（委

員 B）

ICO の文脈を意識しているが、民間事業者がトークンを用いて事業を行うにあたり、曖昧な点が事

業の実施を妨げる。（事務局・委員 N）

スイス金融監督当局（FINMA）が ICO ガイドラインを発表した84。当該資料により一般の人々には

分かりやすくなるだろう。（委員 E）

スイスでは、「プリペイド型」との整理がなかったように思われる。また、ファンド、ではなく、アセットと

して整理していたように思われる。（委員 A）

分類については様々な議論がなされているが、確定版があるとよいだろう。（委員 B）

モノの実態から考えるパターンと規制から考えるパターンとではズレが生じるため、複数の法的性

質を持っているときは複数の観点で、場合により両方当たりうるというのがスイスの書き方であり、そ

の日本語版のようなものがあればいいのではないか。（委員 A）

仮想通貨にも有価証券にもあたるカテゴリーについて、オーバーラップする意味があるのかというも

のも含めて議論すべき。（委員 C）

前払い式支払手段だけは、絶対に重複しないということは言える。（委員 B）

国会答弁85から鑑みるに、どの類型にも該当しない場合、仮想通貨に該当するものと推測するが、

その点を明確にしたい。（委員 E）

アメリカでもクリアになっていない。（委員 B）

有価証券にあたらなかったら仮想通貨であると断言できればわかりやすい。（委員 E）

アメリカとは異なり、日本では金融行政として金融庁が一括で管理している点は素晴らしいことなの

で、その中で線引きをしてくれると、事業者からするととてもやりやすくなる。（委員 B）

兼業規制の問題もあるため、証券と仮想通貨と両方に該当させるというのは避けたい。（委員 C）

株式を細分化し、その株式で支払いが出来るとした場合、それを仮想通貨として整理すると難し

い。

（委員 E）

株式が仮想通貨で運営され、株と仮想通貨が交換可能になれば、株の決済手段として仮想通貨

を使っただけとなる。（委員 G）

84 スイス金融監督当局（FINMA）は 2018 年 2 月 16 日、資金調達法を監視し、マネーロンダリング防止法や有価

証券のいずれかで規制することを明らかにする ICO ガイドラインを発表した。

Swiss Financial Market Supervisory Authority FINMA「FINMA publishes ICO guidelines」

https://www.finma.ch/en/news/2018/02/20180216-mm-ico-wegleitung/ 85 第 186 回通常国会にて、ビットコインの法的な整理について答弁がなされ、貨幣・有価証券に該当しないことが

示された。

参議院「第 186 回国会（常会）質問主意書」

http://www.sangiin.go.jp/japanese/joho1/kousei/syuisyo/186/touh/t186028.htm

134

証券保管振替機構の名義立替権を持っているのは証券会社だけなので、閉じられた世界であれ

ば株も仮想通貨にはあたらないと思う。 （委員 B）

証券保管振替機構の参加証券会社間だけで取引を行う場合であれば閉じられた世界になるかも

しれないが、その後ろに交換する主体がいるとなると違う。（委員 G）

ほかのものに該当する際には、仮想通貨に該当しないと定義して欲しい。（委員 E）

医療分野・物流分野・横断分野と計 6 回の検討会全体を通じての質問・意見等

経済産業省的にはブロックチェーンの基本的な法律をつくるのが本丸だと思う。（委員 G）

振興法を作るという話が以前挙がっていたが、行政機関がブロックチェーンを利用して相互に情報

交換する基本法があるといいと思う。官民データ活用推進基本法を活用すればいい。（委員 B）

権利移転は法務省だが債権譲渡特例法は経済産業省所管だから経済産業省で定めればよい。

（委員 G）

公的機関の持っている帳簿をブロックチェーン上に書き込む仕組みにすると便利になると思う。（委

員 E）

今回は責任主体があり、広域的なものを前提として議論を進めるという事であったと思うが、ブロッ

クチェーンを利用するなら、責任主体が確定できない場合や、約款等通常の契約のツールに頼れ

ない場合について、ブロックチェーンに書かれている情報をどう解釈するか、どこに位置づければ

よいのかゆくゆくは議論した方がいい。（委員 H）

ハードル高いが民法契約法の特則等の形がいいと思う。（委員 C）

株式会社が販売する際に用いる特則として使えるようにすれば、経済産業省の特則という扱いも出

来るだろう。（委員 G）

分散型のシステムやサービスが多く出てきていない状況で、議論しづらかった。そういったところは、

今後の積み残しという形にしたい。（事務局・委員 N）

政府として取り組むべき議論について、まずは報告書の中で提言をするという形で残し、できるとこ

ろから着手したい。電子商取引法に関するところになるが、準則という形でルールを明文化する取

り組みを行っており、今回議論した内容について取り上げ、更に深い議論をしていきたい。 （委員

K）

以上

135

（様式２）

二次利用未承諾リスト

報告書の題名

「平成２９年度我が国におけるデータ駆動型社会に

係る基盤整備（分散型システムに対応した技術・制度

等に係る調査）」

委託事業名

「平成２９年度我が国におけるデータ駆動型社会に

係る基盤整備（分散型システムに対応した技術・制度

等に係る調査）」 報告書

受注事業者名 株式会社日本総合研究所

頁 図表番号 タイトル

海外における主要なブロックチェーン活用業種