Tech-on MeetUp#09 hitachi資料

© Hitachi, Ltd. 2019. All rights reserved.
不動産×企業間情報連携プロジェクト(後編)
～ブロックチェーン七転八倒～

1. 自己紹介
1
IoT
Cloud
AI
Block Chain
製造現場系のIoTソリューション立ち上げ
SaaS型のIoTメンテナンス・リペアソリューションの開発
AWS、Azureを中心とした各種システム開発・適用
製造業を中心とした分析案件を多数。日立が認定する
データサイエンティストのプロフェッショナル資格あり。
企業間情報連携プロジェクト開発取り纏め。
蒲生弘郷 (Gamou Hirosato)Name
大学院にて機械工学系の修士課程を卒業後、
2014年に日立製作所入社
いわゆるSIerのSEという立場でありつつ、
産業系のデジタルソリューション事業を中心に
コンサルティング、プロジェクトマネジメント、
システムアーキテクチャ設計、実証実験、データ分析など
幅広く活動。

2. 企業間情報連携基盤での日立の立ち位置
2
内覧サービスの提供
スマートロックキーの発行
IDを活用した
本人確認情報の提供
本人確認情報の連携機能を提供
ブロックチェーン基盤提供により個人情報取引の管理
申し込み～内覧の手続きのスマート化で業務効率向上
迅速な本人確認とセキュアな情報取引管理を実現協創価値
賃貸物件内覧の各社連携の概要
情報提供
手数料
本人確認情報
KDDI様積水ハウス様
スマートロック
賃貸物件
auユーザ
賃貸内覧予約システム
手続きのスマート化を多方面に拡大
他業種データの価値創造を支援将来像

～ちょっと寄り道(1/3)～日立製作所とIT
3
IT SI、ソフトウェアなど OT 鉄道などの運行管理
プロダクト昇降機、鉄道、建設機械、産業機械、家電、ITプロダクトなど
ITが
1/5を占める
「デジタル時代のイノベーションパートナー」
「社会イノベーション」
日立の事業部門別売上高構成 (２０１８年度)

～ちょっと寄り道(2/3) ～ SIer企業のパラダイムシフト
4
IT部門
SIビジネスデジタルビジネス
顧客
大規模システムの
要件定義からスタート規模
 PM力
 安定稼働を実現する
レガシー設計技術
 RDB設計
 オンプレミスサーバ構築
 Javaアプリケーション
 要件定義
スキル
主に業務部門顧客
小・中規模の技術検証や
課題定義からスタート規模
 コンサルティング
(ビジネス・新技術知識)
 データサイエンス・AI
 クラウド
 新規技術への対応力
 OT技術との連携
 大量データ処理技術
…
スキル
求められるスキルが変化し、最新技術を追う必要性が増加
内部プロセス効率化目的ビジネス競争力強化目的

～ちょっと寄り道(3/3) ～デジタルソリューションの組織へ変化
5
従来のSIerスキル＋新領域の技術
習得を推進する方向に。
TopCoderやKaggleなど競技実績を
挙げるSEが増加。
新技術を活用したシステム構築を
積極的に提供中
(ブロックチェーンもその1つ)
出典日経 xTECH 2019年10月10日掲載『AI道場「Kaggle」の金メダリストも参加、日立が渾身のDX専門組織』
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/01006/100900004/

3. ブロックチェーンのバズワード化
6
すごい。
ブロックチェーン使ってなんかやれ
電子署名
分散台帳
改ざん耐性
経済圏創造
P2P
取引透明性
話を戻して…
ブロックチェーンの「いい部分」だけが1人歩き
魔法の箱のような扱いが継続中

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

5. 企業間情報連携基盤の特性とブロックチェーン
8
企業A 企業B
data ①譲渡
取引履歴
書込照合
②手数料
ポイント①
ポイント②
ポイント③
データの改ざんがあってはいけない
手数料が発生する以上、取引の透明性が必要
提供主の確かな証明が必要
ブロックチェーンのメリットは活かせそうな当初の印象
企業C
…

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

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

【参考】ピアの範囲にもご用心
11
全企業(または業界)で全データを持つ自社が取引に関わるデータのみ持つ
 改ざんに対する承認について第三者も
含む監視という位置づけとなる
 容量の肥大化(各企業コスト増)
 ブロックチェーンの性能問題が懸念
 保守や障害の影響範囲が大きい
メリット
デメリット
 各企業が余計なデータを持たない
 比較的軽量で利用可能
 改ざん耐性(コンセンサスアルゴリズム)の
選定、運用を慎重に実施する必要あり
メリット
デメリット
企業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
コンソーシアム
取引に関係する企業と
コンソーシアムにのみピア配置

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

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

【参考】結局一本化の道へ？
14
HyperLedger Besu
Pantheon ConsenSys社製のJava実装の
Ethereumクライアント
改称＆HyperLedgerプロジェクトに参画
HyperLedger Besu
PegaSys Plus
コンセンサスアルゴリズムにIBFT2.0など
インターフェースにJSON-RPC APIのほか、GraphQLを採用。
無償版
商用版

7-3. 業務結合度という視点
15
ミッションクリティカルをブロックチェーンに任せる場合
速度性能
負荷許容
ブロックチェーン処理の遅延時間は許容できるのかどうか。
(FabricはOrderer導入など速度をある程度担保し対処可能。
PBFTだと10秒程度だったが)
例えば先の例など特定相性でクライアントが落ちるなどの要因を事前
に考慮できるか。耐久テストで3日後に落ちたという報告もあり。
ノード、データ、関連業務が増えれば負荷も変化する。
障害時
対応
バグ発生の際の対応速度。サービス提供側が保証できるのかどうか。
修正がコミュニティ頼りになるケースも。
バックアップの考え方は通常DBと変化する。
技術者
確保
上記を吸収しながら対応できる技術者を保守運用として囲う必要あ
り。 Solidityはじめ、固有の技術が多い一方、需要が高
まる可能性があり、人材枯渇やコストが懸念点。
上記リスク吸収できるサービス、例えばBaaSなどの活用も選択肢

7-4. ブロックチェーンの運用課題
16
保持期間の問題
バージョンアップ対応の問題
「〇年を越えたデータは破棄したい」「少なくとも〇年前のデータは持ちたい」
といった場合、部分的にチェーンを切ることは困難。
クライアントなど、ブロックチェーン要素の脆弱性などが
発生した場合のバージョンアップ対応など移行方針を
あらかじめ考慮しておく必要あり。
2020 2021 2022 2023 2024 …
チェーン①
チェーン②
例えば平行稼働期間を作る？破棄
クライアントなど
ブロックチェーン技術
スマートコントラクトはバージョンアップが困難。
コントラクトをインターフェースとしての利用に抑え、
アプリケーションは環境を変えるなど工夫が必要。
スマートコントラクト

8. ブロックチェーン活用のまとめ
17
1
2
3
未解決問題は回避しながら
金融分野の実績が多いため、高品質のイメージがあるが、
実際は多少品質を割り切って従来技術で回避のケースも。
長所を全取りしようとすると進まない
「ブロックチェーンはこうあるべき」が強いが
すべてを満足しようとするとプロジェクトが進まない。
まだ進化が見込まれる
理論自体も、支えるソフトウェアも進化の段階。
世間の理解も浅く、スモールスタートから進化させたい。
良く知り、試し、失敗しながら活用方法を見出す段階。
その経験が、いつかブレークスルーを呼ぶ可能性もある
オフチェーン機能の
DB外部実装
アプリレイヤの分離
下記の確保に活用
証跡の改ざん耐性
取引の透明性
耐障害性
不必要な部分では
BCは疎結合
要素技術は
代替可能な設計へ
ポイント企業間情報連携基盤

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

Tech-on MeetUp#09 hitachi資料

Tech-on MeetUp#09 hitachi資料

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Tech-on MeetUp#09 hitachi資料

Similar a Tech-on MeetUp#09 hitachi資料 (20)

Más de Techon Organization

Más de Techon Organization (20)

Tech-on MeetUp#09 hitachi資料