20191212に実施された、BlockchainGIG#6 における日立様講演 「エンタープライズ領域におけるブロックチェーン活用 ～ビジネスの視点から見た社会実装に向けた課題とアプローチ～」 の資料（後編）です。 サイトはこちら https://oracle-code-tokyo-dev.connpass.com/event/156475/

1. © Hitachi, Ltd. 2019. All rights reserved.
エンタープライズ領域におけるブロックチェーン活用
～ビジネスの視点から見た社会実装に向けた課題とアプローチ～
(後編)

2. © Hitachi, Ltd. 2019. All rights reserved.
1. 自己紹介
1
IoT
Cloud
AI
Block Chain
製造現場系のIoTソリューション立ち上げ
SaaS型のIoTメンテナンス・リペアソリューションの開発
AWS、Azureを中心とした各種システム開発・適用
製造業を中心とした分析案件を多数。日立が認定する
データサイエンティストのプロフェッショナル資格を持つ。
企業間情報連携プロジェクト開発取り纏め。
蒲生 弘郷 (Gamou Hirosato)Name
2014年に日立製作所 入社
産業系のデジタルソリューション事業を中心に
コンサルティング、プロジェクトマネジメント、
システム設計、実証実験、データ分析など幅広く活動。

3. © Hitachi, Ltd. 2019. All rights reserved.
【参考】SI→デジタルへ ～日立のデジタル推進組織～
2
TopCoderやKaggleなど競技実績を
挙げるSEが増加。
新技術のエンタープライズ適用を
積極的に推進中
(ブロックチェーンもその1つ)
出典 日経 xTECH 2019年10月10日掲載『AI道場「Kaggle」の金メダリストも参加、日立が渾身のDX専門組織』
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/01006/100900004/

4. © Hitachi, Ltd. 2019. All rights reserved.
2. 企業間情報連携基盤での日立の立ち位置
3
➢内覧サービス提供
➢スマートロックキー発行
➢本人情報
(auID)の提供
➢ データ連携による新しい内覧サービス創出を支援
➢ セルフ内覧の実現で営業効率向上を加速協創価値
「賃貸物件内覧」での検証概要
KDDI様積水ハウス様
auユーザ
Web予約と
本人確認による
「セルフ内覧」の実現
セキュアなデータ連携
確かな本人確認
透明性の高い取引 ブロックチェーンによる
証跡管理
KYC情報
手数料

5. © Hitachi, Ltd. 2019. All rights reserved.
3. バズワード化するブロックチェーン
4
電子署名
分散台帳
改ざん耐性
経済圏創造
P2P
取引透明性
ブロックチェーンの「いい部分」だけが1人歩き
魔法の箱のような扱いが継続中
ところで…

6. © Hitachi, Ltd. 2019. All rights reserved.
3. バズワード化するブロックチェーン
5
すごい。
ブロックチェーン使ってなんかやれ
電子署名
分散台帳
改ざん耐性
経済圏創造
P2P
取引透明性
ところで…

7. © Hitachi, Ltd. 2019. All rights reserved.
4. ブロックチェーンの陰と陽
6
実運用を見据えると、クセがすごい…
改ざん耐性
分散化
電子署名
コンセンサス
データを正しい形で保持
変更があっても消せない
or 修正できない
データの共有が容易
透明性の高い取引を実現
電子署名による本人確認
機微な情報の扱いが難しい
データの書き込みが遅れる
秘密鍵管理の難しさ
IoT Cloud AI Block Chain
5G時代の4種の神器
特徴 メリット でも…

8. © Hitachi, Ltd. 2019. All rights reserved.
5. 企業間情報連携基盤の特性とブロックチェーン
7
企業A 企業B
data ①譲渡
取引履歴
書込 照合
②手数料
ポイント①
ポイント②
ポイント③
データの改ざんがあってはいけない
手数料が発生し、取引の透明性が必要
1対多の取引となる
ブロックチェーンのメリットは活かせそうな当初の印象
企業C
…

9. © Hitachi, Ltd. 2019. All rights reserved.
6. 実運用までに乗り越えるべき「カベ」は多数
8
データ項目精査
ブロックチェーン
技術選定
業務との結合度
運用保守
個人情報は書ける？書けない？どこまで書ける？
暗号化してもダメなのか…？
そもそもEthereum? Hyperledger Fabric?
有名クライアントが落ちるなど課題あり
ブロックチェーンをミッションクリティカルにする場合の影響
データ肥大化による入れ替えやアップデートの対応
セキュリティ
ブロックチェーンにありがちなセキュリティ神話。
導入するからこそ周辺ミドルにも注意。
ミドルウェア 自前で建てる場合には準備するミドルウェアの多さは注意。
インターフェース より多くの企業に使ってもらうためのインターフェース提供。
この辺りをメインに

10. © Hitachi, Ltd. 2019. All rights reserved.
7-1. データ項目の精査
9
GDPR「忘れられる権利」
個人が自身の全個人データを不当な遅滞なく消去するよう
データ管理担当者に要求できる権利。単なる暗号化でも×。
理
想
は
…
個人情報
書き込み
伝播
削除困難性によるデータ肥大化
書き込むデータ項目、保持期間、頻度、容量、変更・削除要件
については必ず事前確認が必要。
トランザクションA
取引ID:………
物件ID:………
契約種別:A
容量コスト
性能劣化
運用負担増
削除
容量増加の弊害
一部データ

11. © Hitachi, Ltd. 2019. All rights reserved.
【参考】ピアの範囲にもご用心
10
全企業(または業界)で全データを持つ 自社が取引に関わるデータのみ持つ
➢ 改ざんに対する承認について第三者も
含む監視という位置づけとなる
➢ 容量の肥大化(各企業コスト増)
➢ ブロックチェーンの性能問題が懸念
➢ 保守や障害の影響範囲が大きい
メリット
デメリット
➢ 各企業が余計なデータを持たない
➢ 比較的軽量で利用可能
➢ 改ざん耐性(コンセンサスアルゴリズム)の
選定、運用を慎重に実施する必要あり
メリット
デメリット
企業A
企業B 企業C 企業D
企業F
企業E
企業G
node node
取引してるのはA,B,Cだけでも
取引履歴を全社で共有
node
node
node
node
node
node
node node
企業A 企業B
企業C
node node node node
コンソーシアム
取引に関係する企業と
コンソーシアムにのみピア配置

12. © Hitachi, Ltd. 2019. All rights reserved.
7-2. ブロックチェーン技術の選定(1)
11
Hyperledger Fabric or Ethereum
価値交換
オフチェーン
ノード追加
Fabricはデジタルアセット管理を作りこむ必要あり。
例：データ連携手数料の取引など
Ethereumは標準でオフチェーン機能は無し
(拡張OSSやSaaS連携など必要)
Fabricのプライベートは参加者の合意、
再起動が必要など
速度性能
即時性があるのはFabric
(Ordererには批判もあるけれど…実用的ではある)
観
点
保守サポート
詳しくは後述。
エンタープライズの国内実績はFabricがリード？
サーバレス対応
管理数が多くなるほどサーバ管理工数が肥大化して
しまう。とあるBaaSは東京リージョン非対応だったり。
「ブロックチェーンらしさ」よりも実用重視なのはFabricの印象。
が、すべてに対応するわけではない。

13. © Hitachi, Ltd. 2019. All rights reserved.
7-2. ブロックチェーン技術の選定(2)
12
クライアント選定(Ethereum系)
Quorum
Geth
Parity
コンソーシアム型に合致。
実績が豊富。
リファレンスが少ない。
環境との相性で中断
実績、リファレンス十分。
落ちることもなかった。
実績、リファレンス十分。
CPU問題は解決。
CPU消費の激しさ
ブロック生成の速度が気になる
2017年の不具合報告
クライアント メリット でも…
教訓①
教訓②
実績十分でも何が起こるかわからない。
商用利用はこれで耐えられるのか？という視点は重要。
全体的に参照できるものや書籍が少ない。
検証に時間を要し、未解決問題の発生は前提とすべき。

14. © Hitachi, Ltd. 2019. All rights reserved.
7-3. 業務結合度という視点
13
ミッションクリティカルをブロックチェーンに任せる場合
速度性能
負荷許容
ブロックチェーン処理の遅延時間の許容可否。
(FabricはOrdererでやや早く対処可能。PBFTでも10秒程度)
特定相性でクライアントが落ちるなどの要因を事前に考慮できるか。
耐久テストで3日後に落ちたという報告あり。
ノード、データ、関連業務が増えれば負荷も変化する。
障害運用
バグ発生の際の対応速度。サービス提供側が保証できるのかどうか。
修正がコミュニティ頼りになるケースも。
技術者
確保
Solidityはじめ固有の技術が多く、
人材需要が高まる可能性あり。
全てをクリアできるか検討必須。SaaSなどの活用も選択肢。

15. © Hitachi, Ltd. 2019. All rights reserved.
7-4. ブロックチェーンの運用課題
14
保持期間の問題
バージョンアップ対応の問題
「〇年を越えたデータは破棄したい」「少なくとも〇年前のデータは持ちたい」
といった場合、部分的にチェーンを切ることが困難。
ブロックチェーンの脆弱性などが発生した場合の
バージョンアップ運用など慎重な検討が必要。
2020 2021 2022 2023 2024 …
チェーン①
チェーン②
例えば平行稼働
期間を作る？破棄
クライアントなど
ブロックチェーン技術
スマートコントラクト修正も運用検討が必要。
どこまでの複雑性を持たせるか総合的に判断。
スマートコントラクト

16. © Hitachi, Ltd. 2019. All rights reserved.
8. ブロックチェーン活用のまとめ
15
1
2
3
未解決問題は既存技術で回避
金融分野の実績が多く、高品質のイメージがあり。
実際は未解決問題が多数。
長所を全取りしようとすると進まない
「ブロックチェーンはこうあるべき」が強いが
すべてを満足しようとするとプロジェクトが進まない。
まだ進化が見込まれる
理論自体も、支えるソフトウェアも進化の段階。
世間の理解も浅く、スモールスタートから進化させたい。
✓オフチェーン機能の
DB外部実装
✓アプリレイヤの分離
必要な長所に特化
✓証跡の改ざん耐性
✓取引の透明性
✓耐障害性
✓不必要な部分では
BCは疎結合
✓要素技術は
代替可能な設計へ
ポイント 企業間情報連携基盤

17. © Hitachi, Ltd. 2019. All rights reserved.
商標について
16
Amazon Web Servicesは、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です。
Azureは、米国 Microsoft Corporation の、米国およびその他の国における商標または登録商標です。
KDDI、auは、KDDI株式会社の登録商標または商標です。
積水ハウスは、積水ハウス株式会社の登録商標または商標です。
Topcoderは、Appirio Inc.の登録商標または商標です。
Kaggleは、Google Inc.の登録商標または商標です。
Ethereumは、Stiftung Ethereum (Foundation Ethereum)の登録商標または商標です。
Hyperledgerは、Linux Foundationの登録商標または商標です。
Javaは、米国およびその他の国における米国Sun Microsystems,Inc.の商標または登録商標です。
その他記載されている製品名などの固有名詞は、各社の商標または登録商標です。