ブロックチェーンを活用し ... - blockchain-jp.com · Ver.1.0 ブロック ......

ブロックチェーンを活用した医薬品の

デッドストック販売プラットフォーム

PoC [Phase１ ] 報告書

Ver.1.0

ブロックチェーン北海道イノベーションプログラム（ BHIP）

BHIP 事務局：株式会社 INDETAIL・株式会社北海道銀行

スペシャルサポート：株式会社ファーストブレス

2 BHIP ブロックチェーン北海道イノベーションプログラム

ブロックチェーンを活用した医薬品のデッドストック販売プラットフォーム POC （ PH1）報告書

目次

1.はじめに............................................................................................................................................................ 4

1.1BHIP のご紹介............................................................................................................................................ 4

2.実証実験実施の背景と目的 ............................................................................................................................. 5

2.1 ブロックチェーン技術の活用の可能性 .................................................................................................. 5

ブロックチェーン技術の特徴....................................................................................................................................5 ブロックチェーンの機能特性....................................................................................................................................5

2.2「医薬品のデッドストック解消」をテーマとした背景 ......................................................................... 6

調剤薬局の市場環境....................................................................................................................................................6 医薬品のデッドストック販売に関するグレーゾーンの解消とユーザーニーズ................................................6 本プラットフォームが解決可能な課題....................................................................................................................7

3.実証実験概要 .................................................................................................................................................... 8

3.1 全体構想 ..................................................................................................................................................... 8

3.2 今回の PoC の検証範囲 ............................................................................................................................ 9

3.3 連携スキーム ............................................................................................................................................. 9

4.結論 ................................................................................................................................................................. 10

5.実証実験詳細 .................................................................................................................................................. 11

5.1 期間 .......................................................................................................................................................... 11

システムの設計・開発・環境構築......................................................................................................................... 11 検証期間..................................................................................................................................................................... 11

5.2 システム構成 ........................................................................................................................................... 11

5.2 検証環境 ................................................................................................................................................... 11

5.3 機能一覧 ................................................................................................................................................... 12

5.3.1 管理系機能一覧 ............................................................................................................................................... 12 5.3.2 ユーザー向け（薬局向け）機能一覧 ........................................................................................................... 13 5.3.3 画面遷移図 ....................................................................................................................................................... 14

5.4 検証・調査項目の概要 ............................................................................................................................ 15

5.4.1 検証項目サマリー ........................................................................................................................................... 15 5.4.2 調査項目サマリー ........................................................................................................................................... 15 5.4.3 検証環境補足 .................................................................................................................................................. 16

6. 検証項目別の実験結果詳細 ......................................................................................................................... 18

6.1 トレーサビリティの実現性 ................................................................................................................... 18

No.1 薬の履歴の取得に関する検証 ...................................................................................................................... 18 No.2 薬の売買履歴の取得に関する検証 .............................................................................................................. 19 No.3 自分以外の売買履歴の取得に関する検証 .................................................................................................. 21

6.2 エスクロー決済の実現性 ....................................................................................................................... 25

No.4 エスクロー決済の実現性 .............................................................................................................................. 25

6.3 整合性の確認 .......................................................................................................................................... 27



No.5 同時購入に関する検証 .................................................................................................................................. 27 No.6 安定運用に関する検証 .................................................................................................................................. 28

6.4 仮想通貨の実用可能性 ........................................................................................................................... 30

No.7 仮想通貨の実現方法に関する検証 ............................................................................................................ 30 No.8 仮想通貨による正常な取引と一括決済の検証 ........................................................................................ 31

6.5 性能検証 .................................................................................................................................................. 34

No.9 レスポンスタイムの検証 ............................................................................................................................ 34 No.10 レスポンスタイムの変化の検証 .............................................................................................................. 35 No.11 Peer 数の変化によるレスポンスタイムの変化検証 ............................................................................ 37 No.12 同時アクセス時のパフォーマンス検証 .................................................................................................. 38

7. 調査項目別の調査/考察結果詳細................................................................................................................ 41

7.1 耐改ざん性に関する調査と考察 ........................................................................................................... 41

No.13 内部データの改ざん可能性の調査 .......................................................................................................... 41 No.14 ユーザーによるデータ改ざん可能性の検証 ............................................................................................ 42

7.2 コスト削減に関する調査と考察 ........................................................................................................... 43

No.15 開発コストへの影響度を検証 .................................................................................................................. 43 No.16 運用コストへの影響度を検証 .................................................................................................................. 45

8.検証過程で生じた課題と対処 ....................................................................................................................... 46

8.1 Chaincode のデバッグ方法........................................................................................................................... 46 8.2 Chaincode のログ出力方法........................................................................................................................... 46 8.4 Chaincode で条件指定してのデータ取得が可能か................................................................................... 47 8.5 Chaincode で複雑なクエリでデータを取得可能か................................................................................... 47

9.ブロックチェーン技術と技術習得に関する考察 ......................................................................................... 48

9.1 既存技術（DB）との併用について ............................................................................................................. 48 9.2 データ設計に必要な前提知識について ....................................................................................................... 48 9.3 Fabric の質問や相談先について ................................................................................................................... 49 9.4 SDK の使い方について .................................................................................................................................. 49 9.5 SDK を使用する際の注意点 .......................................................................................................................... 50 9.6 ブロックチェーンの開発チーム体制について ........................................................................................... 50 9.7 ブロックチェーンにおけるデータの設計思想について ........................................................................... 51

10.本報告に関するお問い合わせ先 ................................................................................................................. 52



1.はじめに

1.1BHIP のご紹介

『ブロックチェーン北海道イノベーションプログラム（以下 BHIP）』は、『北海道を「ブロックチェ

ーン技術の集積地」として北海道に新たな技術基盤を創造する』をビジョンに活動する任意団体です

事務局である「株式会社 INDETAIL」「株式会社北海道銀行」をはじめ、北海道、札幌市など、主旨に

ご賛同いただいた、北海道内の団体および法人の皆様と連携しながら、ブロックチェーン技術者の育成

やビジネス活用の検討に必要なナレッジ取得に役立つ学習機会・情報共有・プロモーション・コミュニ

ケーションの効率的な機会を作る取り組みを行っており、ブロックチェーン技術者の育成と啓発活動を

通じて、北海道の IT 産業振興を目指しております

本 PoC は、BHIP による「ブロックチェーンエンジニア育成」の一環として、また「ブロックチェーン

技術をビジネスへ活用する可能性を探る」ことを目的として取り組んだ、北海道での初の実証実験です

(※1)

※1. 2017 年 10 月 1 日時点 BHIP 事務局 INDETAIL 調べ



2.実証実験実施の背景と目的

2.1 ブロックチェーン技術の活用の可能性

日本政府が「第 5 期科学技術基本計画」(※1)にて打ち出した「Society5.0」、この実現にあたり「これ

からの主戦場は『リアルデータのプラットフォーム』を創出・発展させていくこと」とも明示されてお

り、データをどう活用するかが今後の産業発展におけるテーマになると予測しております

日本国内では既に IoT をはじめとするインターネット機器によって収集された膨大なデータをクラウド

に集め、膨大な情報を人口知能（AI）が自動分析を行い、その解析結果を様々な産業へ適用し革新させ

る時代へと突入しています

それらのデータ利活用に必要不可欠な手段として注目されているデータの管理方法が「ブロックチェー

ン」です

ブロックチェーン技術の特徴

「ブロックチェーン」は、サトシ・ナカモトという開発者が 2008 年に「ビットコイン」について書い

た「Bitcoin: A Peer-to-Peer Electronic Cash System（ビットコイン： P2P 電子通貨システム）」と

いう論文によって発明されたと言われています

暗号技術と P2P（ピア・ツー・ピア）ネットワーク技術を応用し、中央管理者を必要とせずにデータの

改ざんがほぼ不可能な仕組みを実現した技術のことです

「ブロックチェーン」は、取引履歴（帳簿）を参加者全員で持ち合う仕組みであり、分散型台帳技術と

も呼ばれます各取引履歴は、順番にブロックに格納され、各ブロックが直前のブロックと繋がりデータ

を相互に承認します

ブロックチェーンの機能特性

ブロックチェーンは以下のような機能特性を持ち、あらゆる価値の交換に活用可能です

仮想通貨や契約、著作権管理、芸術作品の真贋性担保、決済、IoT など様々な分野で活用できる可能性

があります

※1:出展 2016 年 1 月 22 日内閣府発表



１）優れた堅牢性とゼロ・ダウンタイムの実現

分散管理により単一障害点がないため外部からの攻撃に強く、システムがダウンしない

２）改ざんが極めて困難

記録されたデータの非可逆性が保証されており、高い改ざん耐性を持つ

３）開発や運用コストの低減

同程度の堅牢性/耐改ざん性を持つ中央管理型の台帳システムと比較し開発コストが抑えられる、障害

に強いため運用コストも低減できる

2.2「医薬品のデッドストック解消」をテーマとした背景

調剤薬局の市場環境

全国の調剤薬局数は 2015 年末時点で 58,000 店舗（※１）国内人口の高齢化による影響で市場は拡大し

ており、その数は全国のコンビニエンスストア店舗数（約 54,000 店舗）よりも多い状況です

しかし、医療費削減の流れから、調剤報酬の引き下げによって薬価差益が縮小し、利益率は恒常的に下

落しています。また後発品（ジェネリック）の普及により常備する在庫品が増加しているため、デッド

ストック医薬品が在庫を圧迫し、これまで以上に効率的な薬局経営が必要となっています

医薬品のデッドストック販売に関するグレーゾーンの解消とユーザー

ニーズ

そのような背景の中、2016 年 12 月に経済産業省からの発表で、薬局間の医療用医薬品の売買に係る、

医薬品医療機器法の適用範囲がより明確となりました（※２）

このことにより、これまで仲介業者が支援してきたデッドストック解消サービスが医薬品医療機器法の

適用外となり、改めてコスト削減のために慣例的に行われてきたデッドストック医薬品の譲受・譲渡サ

ービスの拡大が、新市場として期待されています



一方で、すでに信頼関係のある調剤薬局間「以外の事業者間で」取引を行う際の信頼性を、どのように

担保するかという点が課題となっております現在の買取サービスやオークション形式の取引では「手数

料の高さ」や「取引先・システムに対する不安」「流通商品が真性品であるかどうか」など、ユーザー

はさまざまな不安や不満を抱えており、「手頃な料金で安心/安定した取引を行いたい」というニーズ

が存在します

また系列店舗を多く抱える大手企業では店舗間の在庫移動などでデッドストックの解消を図ることが可

能ですが、調剤薬局市場は寡占化が進んでおらず、売上上位 10 社の占める市場シェアはわずか 15%

残り 75%にあたる約 43,500 店舗の多くは個人経営薬局と言われており、見ず知らずの事業者間でのデ

ッドストック医薬品の取引に不安を感じている可能性が高いと考えています

（※１）厚生労働省平成 27 年度衛生行政報告例より

（※２）経済産業省 2016 年 12 月 14 日

薬局間における在庫流通システムの提供サービスの実施に係る医薬品医療機器法の取り扱いが明確にな

りました～産業競争力強化法の「グレーゾーン解消制度」の活用～

http://www.meti.go.jp/press/2016/12/20161214003/20161214003.pdf

本プラットフォームが解決可能な課題

そのような背景をふまえ、ブロックチェーンの技術的な特長である「履歴の改ざんがされにくく、高い

透明性や信頼性をインターネット上で確保できる」という点を活かして「在庫データの正確な追跡と保

存性/取引に関する信頼性を担保した売買システム」を実現することで、デッドストック医薬品に関す

る不安を解消し、ニーズにお応えするサービスを提供できる可能性があると考え、本企画の立案に至り

ました



3.実証実験概要

3.1 全体構想

業界の課題を真に解決するプラットフォームとしては、将来的に医薬品に関わるさまざまな業界やシス

テムとの連携の可能性を検討する必要があると想定しておりますが、今回はその構想の中でも「販売」

に関する一部機能を切り出し、ブロックチェーン技術を用いてシステム構築し検証を行うことで、本構

想の実現の可能性を探りました



3.2 今回の PoC の検証範囲

PoC の[Phase1]として、「仮想の薬局間でデッドストック医薬品の売買を行う」という取引を想定した

システムを構築し、検証を行いました

3.3 連携スキーム

BHIP 事務局である「株式会社 INDETAIL」「株式会社北海道銀行」、そして「株式会社ファーストブ

レス」の３社共同で PoC を進めて参りました



4.結論

今回の実証実験により、検証範囲の機能を満たすには十分な成果が出ており、デッドストック医薬品の

売買の実運用が可能であると考えます

また、性能については、同時アクセス 100 トランザクションが実行されるレベルの小・中規模のシステ

ムであれば実運用として耐えられるスペックであることが確認できました

それ以上の大規模システムを構築するには、検証で使用したシステム構成より見直す必要がある

課題としては、ブロックチェーン技術の発展の速さにより仕様変更が多い状況であり、周辺開発が追い

ついていないことである

これに伴い SDK の仕様説明などのドキュメントが整備不足である等、新規開発の参入障壁が非常に高

いものとなっている

今後の PoC Phase2 にて向けて学習を続け、解決を図る予定です



5.実証実験詳細

5.1 期間

システムの設計・開発・環境構築

2017 年 7 月 3 日～9 月 7 日

検証期間

2017 年 9 月 7 日～10 月 6 日

5.2 システム構成

5.2 検証環境

＃項目内容

1 実行環境 IBM Bluemix の仮想サーバ上に Docker で展開

※詳細は 5-4-3 参照

2 Blockchain

プラットフォーム

Hyperledger-fabric Version1.0.0

- 認証：Fabric CA x 1

- 制御：Orderer x 1

- 端末：Peer x 5



3 SDK fabric-sdk-go

- Hyperledger-fabric の go 言語用 SDK

- https://github.com/hyperledger/fabric-sdk-go

4 サーバ側 golang-restful-starter-kit

- go 言語フレームワーク

- https://github.com/qiangxue/golang-restful-starter-kit

5 画面側 React

- フロントエンドライブラリ

- https://facebook.github.io/react/

5.3 機能一覧

5.3.1 管理系機能一覧

＃機能実装 Phase サーバ画面備考

1 ログイン Phase1 済済

2 薬局一覧 Phase1 済済

3 薬局追加 Phase1 済済

4 薬局編集 Phase1 済なし画面は次 Phase にて実装予定

5 薬局削除 Phase1 済なし画面は次 Phase にて実装予定

6 ポイント付与 Phase1 済済

7 締め処理 Phase2 で予定

検証のため一部機能を実装

8 医薬品マスタ追加 Phase2 で予定

Ph1 は手動実行

9 医薬品マスタ編集 Phase2 で予定

Ph1 は手動実行

10 医薬品マスタ削除 Phase2 で予定

Ph1 は手動実行



5.3.2 ユーザー向け（薬局向け）機能一覧

# 機能実装 Phase サーバ画面備考

1 ログイン Phase1 済済

2 販売機能

3

医薬品一覧 Phase1 済済

4

医薬品登録 Phase1 済済

5

医薬品編集 Phase1 済なし画面は次 Phase にて実装予定

6

医薬品削除 Phase1 済なし画面は次 Phase にて実装予定

7

着荷処理 Phase1 済済

8

取引履歴表示 Phase1 済済

9 購入機能

10

医薬品一覧 Phase1 済済

11

医薬品詳細 Phase1 済済

12

医薬品購入 Phase1 済済

13 医薬品履歴表示 Phase1 済済



5.3.3 画面遷移図



5.4 検証・調査項目の概要

5.4.1 検証項目サマリー

検証の観点 No 検証内容

トレーサビリティの実現性 1 ブロックチェーンが保存している薬の履歴を、容易に取得可能なこと

を検証する

2 ブロックチェーンが保存している、自分の売買履歴を取得可能なこと

を検証する

3 ブロックチェーンが保存している、自分以外の売買履歴は取得できな

いよう実装することが可能かを検証する

エスクロー決済の実現性 4 ブロックチェーンにおいて、信頼のおける取引（エスクロー決済）を

実現可能か検証する

整合性の確認 5 複数の薬局が薬を同時に購入した際、先行した薬局が薬を購入し、他

の薬局が購入できないよう実装することが可能か検証する

6 Peer が停止、または Peer を追加した際に継続して運用されることを

検証する

仮想通貨の実用可能性 7 仮想通貨を Hyperledger Fabric 上でどのようにして実現できるか検証

する

8 薬の売買を仮想通貨で行ない、月末にまとめて決済することが可能か

検証する

性能検証 9 1 件アクセス時のブロックチェーンのレスポンスタイムを検証する

10 データの係数によるブロックチェーンのレスポンスタイムの変化を検

証する

11 Peer 数によるレスポンスタイムの変化を検証する

12 同時アクセス時のパフォーマンスを検証する

5.4.2 調査項目サマリー

調査の観点 No 調査内容

耐改ざん性の確認 13 ブロックチェーンの内部データを直接改ざんすることは可能か調査す

る

14 CA（認証局）に登録されているユーザがデータを改ざんすることが可

能か調査する

コスト削減の可能性 15 開発コストへの影響度を調査する

16 運用におけるコストが削減可能か調査する（スケーラビリティの容易

性など）



5.4.3 検証環境補足

No.1 - No.8、No.13-No.14 の検証環境

■実行場所

ローカル環境で Web サーバ、ブロックチェーンを起動して検証

No.9 - No.11 の検証環境

■クラウド

Bluemix( https://www.ibm.com/cloud-computing/jp/ja/bluemix/ )

サーバロケーション CPU

(※1) メモリ

ネット

ワークディスク OS 用途

仮想サーバ 1 Tokyo 2 2 Cores 8GB 速度

100Mbps SAN

Ubuntu16.04-

64 Minimal for

VSI

・Web サーバ


100Mbps

LOCAL

(SSD)

(※２)

Ubuntu16.04-

64 Minimal for

VSI

・CA

・Orderer

・Peer#0(※３)

・Peer#1

（※１）8 Core にしても速度への影響がないことを事前に確認

（※２）SAN にした場合、倍近く時間を要すことを事前に確認（更新系：SAN＝5 秒前後、LOCAL＝3

秒前後）

（※３）Chaincode は Peer#0 にインストール

※Chaincode：ブロックチェーン内でトランザクション処理をするためのプログラム

■実行場所

仮想サーバ 1@Tokyo <----> 仮想サーバ 2@Tokyo

↑

仮想サーバ 1 から Golang で提供されているベンチマーク機能にて検証



No.12 の検証環境

■クラウド

Bluemix( https://www.ibm.com/cloud-computing/jp/ja/bluemix/ )

サーバロケーション CPU メモリネット

ワークディスク OS 用途


100Mbps SAN

Ubuntu16.04-

64 Minimal

for VSI

・Web サーバ


100Mbps

LOCAL

(SSD)

Ubuntu16.04-

64 Minimal

for VSI

・CA

・Orderer

・Peer#0(※1)

・Peer#1

（※1）Chaincode は Peer#0 にインストール

■実行場所

ローカル <----> 仮想サーバ 1@Tokyo <----> 仮想サーバ 2@Tokyo

↑

ローカルから JMeter を使用して検証



6. 検証項目別の実験結果詳細

6.1 トレーサビリティの実現性

No.1 薬の履歴の取得に関する検証

■概要

ブロックチェーンに保存したデータは、ブロックチェーン上に改変できない履歴として保存され続けて

いるこのブロックチェーンが保存している薬の履歴を、容易に取得可能かを検証する

■検証目的

ブロックチェーンに保存されている履歴が、薬のトレーサビリティ情報としての有用性を確認すること

を目的とする

■検証方法

Web API 経由で薬の購入を繰り返し行い、薬の所有者を変更して薬の履歴を取得する

■処理内容

ブロックチェーン内の薬データは所有者や薬価等の情報を保存しており、売買が繰り返されることでそ

れらの情報が更新され続ける

（fabric-sdk-go 経由で）Chaincode のインターフェースとして用意されている「GetHistoryForKey」

を呼び出すことで履歴が取得できる

■検証の対象外

なし

■検証結果想定

[前提]

1. 薬局 A が薬 X を販売登録

2. 薬局 B が薬 X を購入



3. 薬局 B が薬 X を 10 錠在庫にし、残りの 40 錠の薬価を下げて販売登録

3. 薬局 C が薬 X を購入

[結果]

薬 X

所有者薬価数量変更日（購入日）

薬局 A 80.5 50 2017/8/1

薬局 B 80.5 50 2017/8/5

薬局 B 80 40 2017/8/6

薬局 C 80 40 2017/8/10

■検証結果

薬データの履歴が取得可能なことを確認

薬の購入は、注文と着荷の２つの処理に別れるため、６履歴作成されていることを確認

No.2 薬の売買履歴の取得に関する検証

■概要

ブロックチェーンに保存したデータは、ブロックチェーン上に改変できない履歴として保存され続けて

いる

このブロックチェーンに保存されている履歴を取得し、自分の売買履歴として取得可能かを検証する

■検証目的

ブロックチェーンで自動的に取得される履歴情報が、システムの履歴情報取得のデータソースとして容

易に使用でき、実装コストが軽減可能かを確認することを目的とする

■検証方法

Web API 経由で薬を売買し、売買した履歴を取得する



■処理内容

売買履歴は以下のようにオーダー情報としてブロックチェーンに保存している

売買履歴は、このオーダー情報を履歴として取得する

1. 薬局 A が薬局 B から薬 X を購入した

ID ステータス販売日販売側の薬局購入側の薬局合計金額着荷確認日購入した薬販売薬価数量

1 着荷未確認 2017/8/1 薬局 B 薬局 A 4,025 - 薬 X 80.5 50

2. 薬局 A が着荷処理を行なった


1 着荷確認 2017/8/1 薬局 B 薬局 A 4,025 2017/8/5 薬 X 80.5 50


なし


[前提]

1. 薬局 A が薬局 B から薬 X を購入 [着荷確認済み]


1 着荷確認 2017/9/11 薬局 B 薬局 A 4,025 2017/9/11 薬 X 80.5 50

2. 薬局 B が薬局 A から薬 Y を購入 [着荷確認済み]


2 着荷確認 2017/9/11 薬局 A 薬局 B 3,015 2017/9/11 薬 Y 100.5 30

3. 薬局 A が薬局 C から薬 Z を購入 [着荷未確認]


3 着荷未確認 2017/9/11 薬局 C 薬局 A 9,500 - 薬 Z 95 100

4. 薬局 D が薬局 A から薬 W を購入した [着荷未確認]


4 着荷未確認 2017/9/11 薬局 A 薬局 D 2,328 - 薬 W 38.8 60



[結果]

●薬局 A の販売履歴

ID ステータス販売日

販売側の薬

局

購入側の薬

局

合計金

額

着荷確認

日

購入した

薬

販売薬

価

数

量

2 着荷確認 2017/9/11 薬局 A 薬局 B 3,015 2017/9/11 薬 Y 100.5 30

4 着荷未確認 2017/9/11 薬局 A 薬局 D 2,328 - 薬 W 38.8 60

●薬局 A の購入履歴

ID ステータス販売日

販売側の薬

局

購入側の薬

局

合計金

額

着荷確認

日

購入した

薬

販売薬

価

数

量

1 着荷確認 2017/9/11 薬局 B 薬局 A 4,025 2017/9/11 薬 X 80.5 50

3 着荷未確認 2017/9/11 薬局 C 薬局 A 9,500 - 薬 Z 95 100

■検証結果

売買履歴は薬情報のように Asset（ブロックチェーンでの管理対象資産）で管理しておらず、

Transaction（Transaction 管理）としている

Chaincode のインターフェースで用意されている、「GetHistoryForKey」を呼び出すことで履歴を取得

することは可能だが、「GetHistoryForKey」のデータを元に他のデータを取得して売買履歴を作成する

必要があり、レスポンスタイムが遅くなる可能性が高くなる

そのため、Web API で指定された薬局の売買履歴を取得して返却する（RDBMS でいうところの Where

を使用）という方法で、自分の売買履歴を取得する処理を実装することで、実用的な速度での動作を実

現できることを確認した

No.3 自分以外の売買履歴の取得に関する検証

■概要

ブロックチェーンに保存されている売買履歴を、ブロックチェーンでアクセス制限し、閲覧可能なデー

タのみ取得することができるかを検証する



■検証目的

ブロックチェーンが保存している、自分以外の売買履歴を他のユーザが参照出来ないような実装が可能

か確認することを目的とする

■検証方法

Web API 経由で薬を売買し、売買した履歴を取得する

■処理内容

No.2 同様


なし


1. 薬局 A が薬局 B から薬 X を購入した [着荷確認済み]


1 着荷確認 2017/9/11 薬局 B 薬局 A 4,025 2017/9/11 薬 X 80.5 50

2. 薬局 B が薬局 A から薬 Y を購入した [着荷確認済み]


2 着荷確認 2017/9/11 薬局 A 薬局 B 3,015 2017/9/11 薬 Y 100.5 30

3. 薬局 A が薬局 C から薬 Z を購入した [着荷確認済み]


3 着荷確認 2017/9/11 薬局 C 薬局 A 9,500 2017/9/11 薬 Z 95 100

4. 薬局 D が薬局 A から薬 W を購入した [着荷未確認]


4 着荷確認 2017/9/11 薬局 A 薬局 D 2,328 2017/9/11 薬 W 38.8 60



5. 薬局 A が薬局 D から薬 W を購入した [着荷確認済み]


5 着荷確認 2017/9/11 薬局 D 薬局 A 2,328 2017/9/11 薬 W 38.8 60

6. 薬局 B が薬局 A から薬 X を購入した [着荷確認済み]


6 着荷確認 2017/9/11 薬局 A 薬局 B 4,025 2017/9/11 薬 X 80.5 50

7. 薬局 C が薬局 B から薬 Y を購入した [着荷確認済み]


7 着荷確認 2017/9/11 薬局 B 薬局 C 3,015 2017/9/11 薬 Y 100.5 30

8. 薬局 D が薬局 A から薬 Z を購入した [着荷未確認]


8 着荷未確認 2017/9/11 薬局 A 薬局 D 9,500 - 薬 Z 95 100

[結果]

薬局 A の履歴を取得

●薬局 A の販売履歴


2 着荷確認 2017/9/11 薬局 A 薬局 B 3,015 2017/9/11 薬 Y 100.5 30

4 着荷確認 2017/9/11 薬局 A 薬局 D 2,328 2017/9/11 薬 W 38.8 60

6 着荷確認 2017/9/11 薬局 A 薬局 B 3,015 2017/9/11 薬 X 100.5 30

8 着荷未確認 2017/9/11 薬局 A 薬局 D 2,328 - 薬 Z 38.8 60

※薬局 A 以外の販売履歴は取得できない

●薬局 A の購入履歴


1 着荷確認 2017/9/11 薬局 B 薬局 A 4,025 2017/9/11 薬 X 80.5 50

3 着荷確認 2017/9/11 薬局 C 薬局 A 9,500 2017/9/11 薬 Z 95 100

5 着荷確認 2017/9/11 薬局 D 薬局 A 4,025 2017/9/11 薬 W 80.5 50

※薬局 A 以外の購入履歴は取得できない



■検証結果

ブロックチェーンでデータのアクセス制限をするという機能はないため、該当データのみを取得すると

いう処理を実装する必要がある

今回のケースでは、売買時に薬局 ID と OrderID の Index を作成し、履歴取得時に指定薬局の Order 情

報のみ取得するように実装することで、指定した薬局の履歴のみを取得する処理を実現した



6.2 エスクロー決済の実現性

No.4 エスクロー決済の実現性

■概要

ブロックチェーンに保存したデータで、薬が手元に届いてから仮想通貨が移動するような信頼のおける

取引（エスクロー決済）が実現可能か検証する

■検証目的

従来のエスクローでは一般的に、エスクローサービスを提供する第三者が売り手と買い手との間に入

り、商品と代金の交換を保障する

ブロックチェーン上で、このエスクローと同等の信頼のおける取引を実装することで、売買当事者同士

で実現することが可能となり、エスクローサービス提供者への手数料コストの削減などが期待できる

■検証方法

Web API 経由で購入～着荷処理を行う

Hyperledger Fabric ではやエスクロー決済のような仕組みはあらかじめ備えられていないため、今回は

以下の機能を実装した

・購入時点では仮想通貨を一時的に凍結（使用できない状態）し、薬の所有者は変更せず発送中のステ

ータスに変更

・購入者が着荷処理を行なった際（購入者の手元に購入品が届いたという状況を想定）に、仮想通貨の

移動および薬の所有者の変更を実施

■処理内容

[前提]

・薬局 A の保有仮想通貨： 100,000

・薬局 B の保有仮想通貨： 100,000

・薬 X：所有者 = 薬局 B



1. 薬局 A が薬局 B の薬 X を購入

価格は 4,218 円（140.6 * 30)

・薬局 A の保有仮想通貨： 95,782 ★この時点で購入した価格分をブロックチェーンで凍結

・薬局 B の保有仮想通貨： 100,000 ★この時点では増減なし

・薬局 A の凍結中仮想通貨： 4,218 ★この仮想通貨は凍結中のため使用不可

・薬 X：所有者 = 薬局 B ★この時点では所有者変更なし、薬のステータスを「購入手続中」に変更

2. 薬局 B が薬 X を薬局 A へ発送する

※本 PoC では実際の薬は移動しない（実運用時は、発送が完了したら薬のステータスが「発送中」

になる想定）

3. 薬局 A に薬 X が届いたタイミングで、薬局 A が着荷処理を実施

・薬局 A の保有仮想通貨： 95,782

・薬局 B の保有仮想通貨： 104,218 ★この時点で凍結分の通貨が薬局 B へ移動

・薬局 A の凍結中仮想通貨： 0 ★薬局 B へ移動済のため凍結分なし

・薬 X：所有者 = 薬局 A ★この時点で所有者が薬局 A に変更


キャンセルや未達（着荷処理が行われない）の場合、凍結している仮想通貨を元に戻す処理が必要とな

るが、本 Phase では実装対象外としている


「■処理内容」の通りのデータとなる

■検証結果

「■処理内容」の通りのデータとなることを確認した



6.3 整合性の確認

No.5 同時購入に関する検証

■概要

複数の薬局が薬を同時に購入した際、先行した薬局が薬を購入し、他の薬局が購入できないかどうかを

検証する

■検証目的

ブロックチェーンにおいて、同時に処理要求がきた場合のデータ整合性担保の確認を目的とする

■検証方法

Web API 経由で同時に購入処理を行う

■処理内容

「Apache-JMeter」を使用し、3 つの薬局で同時に同じ薬を購入する行為を 10 回繰り返す

最初に接続できた薬局が薬を購入し、他の薬局が購入不可になっている事を確認する


なし


先行した要求の処理が行われ、正常に購入が完了する

後行した要求の処理はエラーとなり、購入に失敗する

■検証結果

全てのパターンにおいて、最初に接続した薬局が購入に成功し、他の薬局には購入エラーが発生してい

る事を確認した



No.6 安定運用に関する検証

■概要

Peer が停止、または Peer を追加した際に継続して運用可能か検証する

■検証目的

ブロックチェーンの実行中に環境が変化した場合の稼働状況を確認することを目的とする

■検証方法

1. Web API 実行中に任意の Chaincode を持たない Peer を 1端末停止後、Web API を実行

2. Web API 実行中に Peer を 1端末追加後、Web API を実行

■処理内容

なし


なし


1. Chaincode を持たない Peer を 1 つ停止した場合、Web API の実行結果が正常に返却される

停止後も、Web API の実行結果が正常に返却される

2. Peer を 1 つ追加した場合、Web API の実行結果が正常に返却される

追加後も、Web API の実行結果が正常に返却される

3. Chaincode を持つ Peer を停止した場合、Web API の実行結果が正常に返却されない

■検証結果

想定通りの結果が得られた



Chaincode を持つ Peer を停止した場合、単一障害点となるリスクがあるため、実運用時は Chaincode

を持つ Peer を複数用意し、Chaincode を持つ Peer が停止していた場合は別の Peer にリクエストする

という処理を実装する必要がある



6.4 仮想通貨の実用可能性

No.7 仮想通貨の実現方法に関する検証

■概要

Hyperledger Fabric で仮想通貨をどのようにして実現できるか検証する

■検証目的

Hyperledger Fabric では Bitcoin や Ethereum のように、仮想通貨だけを想定した思想ではないため、

仮想通貨をどのようにブロックチェーンに保存、運用するかを設計、実装する必要がある

Hyperledger Fabric で容易に仮想通貨を実現する方法を検証することで、活用の可能性を探る

■検証方法

Web API 経由で仮想通貨を使用して薬の売買を行う

■処理内容

・仮想通貨を「ポイント」という概念で管理する

・1 ポイント = 1 円と想定する

・管理画面から薬局に対しポイントを追加できる機能を持つ（ポイントを減らすことはできない)

・薬局はポイントで薬を購入することができる

・購入する薬の価格よりポイントが少ない場合は、薬を購入できない


PoC では実際の現金と仮想通貨を紐付けない

■検証結果

今回は、以下のように仮想通貨を実現した



▼Pharmacy（薬局)

ID Name Points（※1）

1 薬局

A 10,000

2 薬局

B 50,000

（※１）薬局が管理しているポイント Account の Balance と同値仮想通貨の増減は、このポイントの

値を変更せず、Account の Balance に対して行う

理由は、ポイント以外の値を変更した場合（名前など）でも履歴として残ってしまうため、純粋にポイ

ントの増減履歴だけを保存しておけないためこれを解決するため、以下の Account の Balance を使用

することとした

▼Account（口座)

PharmacyId Balance（※2）

1 10,000

2 50,000

（※２）購入した場合は、この値がマイナスされる販売した場合はこの値がプラスされ、プラス/マイ

ナスの履歴が保存される

No.8 仮想通貨による正常な取引と一括決済の検証

■概要

薬の売買を仮想通貨でやり取りし、月末にまとめて決済をすることができるか検証する

■検証目的

ブロックチェーンに保存したデータで、月末に薬局ごとに決済をまとめて行うため、日付を指定しての

データ一括取得が可能かの確認を目的とする

■検証方法

Web API 経由で実行し、薬局毎に仮想通貨の集計値が返却されることを確認する



尚、今回は現実的な性能を担保しつつ日付を指定してデータを取得するため、以下のような実装を行な

った

1. 着荷処理の際に、以下のインデックスを保存

index = order_confirmdate_index#<着荷処理実行年月>#<OrderId>

2. 決済年月を指定してインデックスを取得

order_confirmdate_index#2017/8#1



...

3. 末尾の OrderId を使用し、該当のオーダー情報を決済対象データとして仮想通貨を集計

■処理内容

実行年月の 1 日～末日までの仮想通貨を薬局ごとにまとめ、レスポンスで返却する

（例）

薬局完了日仮想通貨の使用状況

A 7/01 1,000

8/01 -5,000

8/10 1,500

B 6/10 4,000

8/10 3,800

8/31 -1,000

9/01 5,000

★8 月に処理を実行（8/1～8/31 で売買が完了しているデータを対象としてまとめる）

レスポンス

薬局 8 月の仮想通貨備考

A -3,500 = -5,000(8/1) + 1,500(8/10)

B 2,800 = 3,800(8/1) + -1,000(8/31)




8/1～8/31 の締め処理を実施

▼オーダー情報

薬局購入先完了日薬（製品 ID) 販売薬価数量販売価格締め処理対象

A 薬局 B 7/01 1 82.4 10 824 ×

薬局 B -（未完了) 2 140.0 10 1,400 ×

薬局 B 8/01 173 25.6 50 1,280 ◯

薬局 C 8/02 32 15.3 60 918 ◯

薬局 B 8/21 188 200.1 75 15,008 ◯

薬局 B -（未完了) 3 6.0 10 60 ×

薬局 B 9/01 4 70.0 10 700 ×

薬局 B -（未完了) 5 90.2 10 902 ×

B 薬局 A 7/31 6 200.0 10 2,000 ×

薬局 A -（未完了) 7 20.0 10 200 ×

薬局 C 8/06 94 30.7 90 2,763 ◯

薬局 A 8/15 107 9.8 100 980 ◯

薬局 A 8/31 200 170.4 120 20,448 ◯

薬局 A -（未完了) 8 1,500.0 10 15,000 ×

薬局 A 9/05 9 1,200.0 10 12,000 ×

薬局 A -（未完了) 10 1,100.0 10 11000 ×

▼結果

薬局仮想通貨詳細

A 4,222 購入：-1,280+-918+-15,008、販売：980+20,448

B -7,903 購入：-2,763+-980+-20,448、販売：1,280+15,008

C 3,681 販売：918+3,213

■検証結果

検証結果想定通りの結果が得られることを確認した



6.5 性能検証

No.9 レスポンスタイムの検証

■概要

ブロックチェーンの取得、更新、削除時のパフォーマンスを確認する

■検証目的

ブロックチェーンを用いたシステムの性能を把握するため

■検証方法

Web サーバ経由でブロックチェーンを実行し、レスポンスが返却されるまでの時間を計測する

以下で計測する

・Golang 付属の Benchmark を使用し、各機能について 1 秒間に処理可能な件数を 20 セット測定

■対象機能

計測する対象の機能は以下とする

No. 機能 Web API

1 薬局向け機能（販売) ログイン

2 薬局登録

3 薬局一覧

4 医薬品登録

5 医薬品編集

6 医薬品削除

7 取引履歴表示

8 薬局向け機能（購入) 医薬品一覧

9 医薬品詳細

10 医薬品購入

11 着荷処理

12 その他締め処理




画面操作からの計測は行わない

画面操作からの時間は、Web API のレスポンスタイム + 数ミリ秒～数秒と想定される


Get（取得）は 1Peer から取得するため高速だが、Update（更新）は全 Peer に対して更新するため低

速

※追加、削除については、削除した状態の履歴を作成する形になるため、追加、更新、削除は内部では

同じ処理となる

また、WebAPI 経由での計測を行なっているため、内部の LevelDB へのアクセス

（ http://www.lmdb.tech/bench/microbench/benchmark.html )以外に、Chaincode で JSON を

Entity に変換するためのコストを考慮する必要がある

■検証結果

想定の通り、取得は比較的高速で、更新は一般的なレスポンス指標よりは低速という結果となった

取得：約 30～500ms

追加、更新、削除：約 2,000ms

参考）画面表示レスポンスの指標

Google 推奨は、200ms 以下（ https://developers.google.com/speed/docs/insights/Server ）

No.10 レスポンスタイムの変化の検証

■概要

ブロックチェーンの取得、更新時のパフォーマンス、データ件数の増加による処理時間の変化などの、

ブロックチェーンのレスポンスタイムを検証する



■検証目的

ブロックチェーンを用いたシステムの既存データ件数に伴う性能の変動を把握することを目的とする

■検証方法

Web API 経由でブロックチェーンを実行し、レスポンスが返却されるまでの時間を計測する

データの件数を、10、50, 100...のように変化させて計測する

以下で計測する

・Golang 付属の Benchmark を使用し、各機能について 1 秒間に処理可能な件数を 5 セット測定

※更新については、同時に N 件ではなく、既に N 件入っている状態で 1 件登録した場合の数値

■対象機能


No. 機能 Web API

1

薬局向け機能（販

売）医薬品登録

2

薬局向け機能（購

入）医薬品一覧



画面操作からの時間は、Web API のレスポンスタイム + 数ミリ秒～数秒と想定される

■検証結果

取得は、取得件数が増えるほどレスポンスタイムが比例して増加する結果となった



そのため、ページング等の実装により一度に取得するデータ件数を抑えることが必要だと思われる

更新については、登録されているデータ件数に関わらずレスポンスタイムは一定である

No.11 Peer 数の変化によるレスポンスタイムの変化検証

■概要

Peer の数の増減によりレスポンスタイムに変化が生じるのかを検証する

■検証目的

Peer の数がデータの取得、更新に与える影響の確認を目的とする

■検証方法

Web API 経由でブロックチェーンを実行し、Peer の数を２～５に変化させた場合のレスポンスが返却

されるまでの時間を計測する

■対象機能


No. 機能 Web API データ

1 薬局向け機能薬局登録 10

2 薬局一覧 10



（画面操作からの時間は、Web API のレスポンスタイム + 数ミリ秒～数秒と想定される）

また、Peer を別サーバに配置した場合の計測については環境構築に時間を要するため、今回は対象外

とする



■検証結果

取得も更新も Peer 数によるレスポンスタイムの変化は見られない

更新については、Peer 数の増加に伴い速度が低下する想定だったが、Peer 数 5 程度ではそれほどの変

動は無い結果となった

No.12 同時アクセス時のパフォーマンス検証

■概要

同時アクセスが生じた際のパフォーマンスを検証する

■検証目的

ブロックチェーンの取得、更新時のパフォーマンスはどれくらいなのか確認する

同時アクセス時のレスポンスタイムを確認する

■検証方法

JMeter にて Web API 経由でブロックチェーンを実行し計測する

一般的な Web システム(ページング使用を想定)して、取得件数を 100 件、5 秒間隔で 10 回計測

また、開始時の同時アクセスの負荷による影響を避けるため、Ramp-Up による分散を行なう



■対象機能


No. 機能 Web API

1 薬局向け機能（販売）医薬品登録

2 薬局向け機能（購入）医薬品一覧



■検証結果

・GetDrugs(8Core / データ 100 件)

スレッド数-RampUp-ループ回数-WaitTime

Avg

(Latency- Connect の

中央値)：秒

Avg


平均値)：秒

Avg


MAX 値)：秒

2-1-10-2s 0.0445 0.05 0.07

10-5-10-2s 0.044 0.05 0.07

50-25-10-2s 0.044 0.046 0.09

100-25-10-2s 0.043 0.045 0.07

1000-25-10-2s 24.887 21.709 95.96

※Web サーバへの接続時間の影響を省くため、レスポンスタイムから接続時間を引いた値で計測

・PostDrug(8Core)

スレッド数-RampUp-ループ回数-WaitTime

Avg


中央値)：秒

Avg


平均値)：秒

Avg


MAX 値)：秒

2-1-10-5s 2.127 2.09 2.18

10-5-10-5s 2.1045 1.54 2.20

50-10-10-5s 0.186 0.281 1.91

100-10-10-5s 0.185 0.251 1.99

1000-10-10-5s 8.1475 7.018 12.79

・ MAX 値の変動については、処理タイミングの影響と思われる

・ある程度の同時アクセス数があっても、ファイナリティの速度は担保されている

・取得、更新共に同時 1,000 アクセスは極端に性能が劣化しており、同時処理の限界に到達している

よう見受けられる



・現在のサーバ構成は、Hyperledger Fabric の最小要件に近い形となっているため、より高い性能要

件を満たすにはサーバスペックや構成の強化が必要となる



7. 調査項目別の調査/考察結果詳細

7.1 耐改ざん性に関する調査と考察

No.13 内部データの改ざん可能性の調査

■概要

ブロックチェーンの内部データを改ざんすることは可能か調査する

■調査目的

データが保存されている内部のデータベースにアクセスし、データを取得、改ざんの難易度、実現困難

であることを確認し、実用の有益性検証を目的とする

■調査結果想定

1. データはバイトで格納されているため、データの改ざんは困難 = 改ざん不可

2. 特定の Peer のデータを改ざんしようとしても、他の Peer に保存されているデータと不整合となる

ため改ざんデータは無効となる

3. LevelDB アクセス時に証明書が必要となるため、データの取得、改ざんは困難

■調査結果

1. Fabric-peer の Docker イメージは LevelDB を使用しており、Hyperledger Fabric ソースコードから

ローカルアクセスを行っているため、エクスターナルアクセスは困難

Docker イメージ内に自分の LevelDB クライントをインストールすればアクセス可能だが、多くのセキ

ュリティレイヤーをバイパスする必要がある

2. LevelDB にダイレクトアクセスすれば、データを更新は可能だが、どれか１つの Peer のデータを更

新すると、他の Peer は不正データを検知しトランザクションをブロックする仕様のため、全ての Peer

を正しく更新することは極めて困難



No.14 ユーザーによるデータ改ざん可能性の検証

■概要

CA（認証局）に登録されているユーザーがデータを改ざんする方法について調査する

■調査目的

証明書を所有している正式なユーザーが悪意を持った場合、ブロックチェーンのデータを改ざんや、内

部からの不正処理を行うことが可能かの確認を目的とする

■調査結果想定

特定の Peer のデータを改ざんしようとしても、他の Peer に保存されているデータと不整合となるため

改ざんデータは無効となる

そのため、証明書を所有している正式なユーザーでもデータの改ざんは不可

■調査結果と課題について

現在はブロックチェーン外でアクセス制限を行っているが、ブロックチェーンへのアクセスは管理者権

限を使用しているため、証明書が漏洩すると全ての操作が可能となる

ブロックチェーン側で正しくアクセス制限を行なうには以下の２つの実装が必要となる

1. ユーザー証明書のロール設定行ない、ユーザが可能な操作を制限する

一般的な RDBMS と同様、フルアクセス権限のユーザーが改ざんしようと思えば可能なため、ユーザー

ごとにロールを設定し、実行できる範囲を限定するなどの対策が必要となる

2.Chaincode 内で下記のステップで証明書のチェックを行ない、アクセスしてきたユーザを特定する

- トランザクションを行う際、正しいユーザの証明書を送る

- チェインコードの中で変更するアセットのオーナーの証明書を確認する

トランザクションの証明書とアセットオーナーの証明書をコンペア（比較)する



7.2 コスト削減に関する調査と考察

No.15 開発コストへの影響度を検証

■概要

今回検証に用いたシステムについて、ブロックチェーンを使用した場合と、従来型のデータベースを使

用したシステム開発を行った場合の開発コストを比較する

■調査目的

ブロックチェーンを使用することによる開発コストの削減効果を見込むことができれば、既存システム

からブロックチェーンへと置き換えるメリットになるため

■調査結果

1. 教育コストについて

▼全体

- Hyperledger Fabric の日本語ドキュメントはほぼ皆無

-ドキュメントが追いついていない場合もあるため、その場合はインターネットでの調査や、ソースコ

ードを直接参照する必要がある（インターネットで得られる記事やコードに関するコメントは基本的に

すべて英語)

- SDK の使い方もドキュメントが少ないため、サンプルコードをベースにする必要がある

▼インフラ

- 証明書や Docker の知識が必要

- 証明書を様々な箇所で使用しているため、証明書特有の問題が発生することが多く、扱いが難しい

▼バックエンド

- SDK は Go（golang）、Node.js、Java、Python で書かれているので取り組みやすい

- DB に対しての Get/Update と同様の感覚で実装を行うことが可能

▼フロントエンド

- Rest API 経由でブロックチェーンを実行すれば、フロントエンド担当者にはブロックチェーンの知

識は不要



2. ブロックチェーンの内部管理は KVS を使用しているため、KVS の設計思想で設計すれば、特に設計

コストは高くならないと思われる

3. 履歴はブロックチェーンで保存されるため、実装は不要

通常のデータベースでは、データの変更履歴を保存しておく場合、「履歴を保存する処理」を実装する

必要があるが、ブロックチェーンでは変更履歴は常に保存され続ける仕組みのため、別途実装する必要

がないため、この分はコストが削減できる

履歴も改ざんされない仕組みがあるので、データの改ざんについて考慮する必要が無い

4. Hyperledger Fabric や SDK のバージョンアップに対応するコストは高い

Hyperledger Fabric は現在進行形でスピード感のある開発が行なわれているため、しばらくはバージョ

ンアップが頻繁に発生する可能性が高い

そのため、SDK もアップデートが頻繁に行われており、開発中にアップデートする回数が増えることに

よる対応コストの増加が懸念となる

5. SDK はインフラに関わる部分もある

インフラに関わる処理を SDK 経由でアクセスする箇所については、ブロックチェーンのインフラにつ

いてより深い知識が必要となる

6. 工数サマリー（単位：人日)

▼インフラ

予定実績学習コストなし

22 16.7 10

▼バックエンド


40.75 43.9 36.5

▼フロントエンド


30 27.8 -



No.16 運用コストへの影響度を検証

■概要

今回検証に用いたシステムについて、ブロックチェーンを使用した場合と、従来型のデータベースを使

用したシステム開発を行った場合の運用コストを比較する

■検証目的

ブロックチェーンを使用することによる運用コストの削減効果を検証するため

■調査結果

1. Peer を増やすと自動的にデータの同期がかかるので、データの分散に関する運用コストは下がる

2. 提供されている Docker ファイルをベースにある程度の自動化が可能なため、通常のデータベース

を設定するよりは設定工数が抑えられる

3. 上記に伴い、スケーラビリティに関する運用コストは削減される可能性がある

4. バージョンアップ作業については、Peer の数を多くした場合、通常のデータベースと同様 Peer 毎

にアップデートをかける必要があるため、コストは下がらない



8.検証過程で生じた課題と対処

8.1 Chaincode のデバッグ方法

■課題

Chaincode のデバッグ方法が確立されていない

■対処

IDE でブレークポイントを張る方法はあるようだが（※）、今回は Eclipse を使用していないため以下

の方法で問題を回避した

1. Chaincode の UnitTest を行う

2. ログに出力する

（※ https://jira.hyperledger.org/browse/FAB-3736?page=com.atlassian.streams.streams-jira-

plugin%3Aactivity-stream-issue-tab ）

8.2 Chaincode のログ出力方法

■課題

Chaincode でログを出力する方法が確立されていない

■対処

【Docker】

Peer の環境変数に「CORE_VM_DOCKER_ATTACHSTDOUT=true」を追加して、Peer を起動すると出

力可能

【Chaincode】

logger := shim.NewLogger("xxx")

logger.Warningf("%s ", hoge)



8.4 Chaincode で条件指定してのデータ取得が可能か

■課題

Chaincode で条件指定してデータを取得する場合、全件取得後にループして抽出以外の方法があるかど

うか

■対処

複合キー（Composite Key）を利用して、条件指定でデータを取得することが可能

また、検索用の Index を作成することも可能

例えば、薬のステータスを条件にデータ取得することがある場合、以下のような Index を作成する

ステータスが販売中（Status=0）の薬（ID=5） → Index を「drug - 0 - 5」のように作成する

このような設計を行なうと、「販売中の薬のみを取得」のようなデータ取得方法が可能となる

8.5 Chaincode で複雑なクエリでデータを取得可能か

■課題

Chaincode で複雑なクエリでデータを取得可能か

■対処

LevelDB の代わりに CouchDB を使うことで、複雑なクエリを使用できる可能性があるところまでは判

明している

ただし、以下の問題があるため今回は使用を見送った

・LevelDB と比べ、docker のサイズが大きい（1.4GB）

・JOIN は可能なようだが実装が難しい

・別途 UnitTest が実行出来ない問題が発生



9.ブロックチェーン技術と技術習得に関する考察

検証の過程で得られたブロックチェーン技術および技術習得に関する考察や注意点を以下にまとめる

9.1 既存技術（DB）との併用について

■テーマ

全データをブロックチェーン保存してよいのかブロックチェーンと DB を併用すべきかを、どのように

判断すべきか

■考察結果

ブロックチェーンの特性を生かすデータはブロックチェーンへ保存すべきだが、更新頻度が高くデータ

も多い場合、ブロックチェーンへの保存は時間を要するため、ブロックチェーンへの保存は検討する必

要がある

参照頻度の高いデータについては、ブロックチェーンのデータを DB にキャッシュしておく、なども検

討の余地がある

9.2 データ設計に必要な前提知識について

■テーマ

ブロックチェーン技術を用いた開発を行うにあたり、データ設計時に必要な前提知識があるか

■考察結果

Hyperledger Fabric の内部で使用するデータベースのデフォルトは LevelDB のため、KVS（キーバリ

ューストア）の知識が必要となる

CouchDB を使用する場合も同様それぞれ使用する DB の知識が必要



9.3 Fabric の質問や相談先について

■テーマ

Fabric を用いた開発過程で生じた質問や相談をどのように行なえば良いか

■考察結果

Hyperledger のコミュニティチャットを活用すると問題解決が早い

（ https://chat.hyperledger.org/channel/fabric ）

しかし、コミュニティ内でのコミュニケーションはすべて英語のため、実用レベルでの英語スキルが必

要となる

9.4 SDK の使い方について

■テーマ

SDK の使い方を知るのにどのような方法があるか

■考察結果

SDK に関しては情報を得られるドキュメントが少ないため、SDK の UnitTest からどのように使用する

べきかを解析する必要がある

また、function のドキュメントも存在しないため、SDK のコードを解析してどのような処理を行なって

いるか把握する必要がある



9.5 SDK を使用する際の注意点

■テーマ

SDK を使う場合の注意点について

■考察結果

今回使用している fabric-sdk-go も TODO が残っている状態で、実装されていない機能もあるため、

SDK 選定の際には未実装機能がないかを確認する必要がある

9.6 ブロックチェーンの開発チーム体制について

■テーマ

ブロックチェーンを用いた開発のチーム体制をどのようにすると良いか

■考察結果

以下の特性を持つエンジニアがそれぞれ必要となる

それぞれの人数は、開発規模による

・Hyperledger Fabric のインフラを理解し、活用できるエンジニア

・Chaincode を理解し活用できるエンジニア（バックエンドエンジニアと兼任でも可）

・バックエンドエンジニア

・フロントエンドエンジニア

チームメンバー内に、Hyperledger Fabric 全体を理解している高スキル（英語が実用レベルで使用可能

+ 高技術力）のエンジニアがいると発生時の対処方法の調査等がスムーズとなる



9.7 ブロックチェーンにおけるデータの設計思想について

■テーマ

ブロックチェーンにおけるデータの設計思想は確立されているか

■考察結果

Hyperledger を前提としたアプリケーション・フレームワークと開発運用ツール群として、

Hyperledger Composer がある

Hyperledger Composer (https://hyperledger.github.io/composer/)

本フレームワークのモデル定義に従って構築すると効率が良い

今回は以下のように設計を行っている

・Asset：薬情報、アカウント（仮想通貨口座）情報

・Participant：薬局情報

・Transaction：オーダー情報



10.本報告に関するお問い合わせ先

本報告書に関するご質問や取材などのお問い合わせは下記までご連絡ください

株式会社 INDETAIL 内

ブロックチェーン北海道イノベーションプログラム事務局

E-mail：[email protected]

TEL ：011-206-9235

URL ：https://blockchain-jp.com/bhip

住所：〒060-0042 北海道札幌市中央区大通西 9 丁目 3 番地 33 キタコーセンタービルディング

ブロックチェーンを活用した医薬品の

デッドストック販売プラットフォーム

PoC [Phase1] 報告書

発行日：2017 年 10 月 12 日第 1 版

発行人：ブロックチェーン北海道イノベーションプログラム（BHIP）

mailto:E-mail：[email protected]

mailto:E-mail：[email protected]

ブロックチェーンを活用し ... - blockchain-jp.com · Ver.1.0 ブロック ......

Documents

Transcript of ブロックチェーンを活用し ... - blockchain-jp.com · Ver.1.0 ブロック ......