...

集中型 分散型

by user

on
Category: Documents
9

views

Report

Comments

Transcript

集中型 分散型
セマンティックコンピューティングと
PLR (個人生活録)
2014-07-09 橋田浩一
自律分散協調のトレンド
集中→分散
汎用大型コンピュータ
 一部の大組織だけがコンピュータを所有
PC
 分散: 個人のエンパワメント
インターネット
 核戦争にも耐える分散システム
グリッド
 分散した計算資源の相互連携
クラウドとスマートフォン
 一見集中みたいだが分散でもある?
フォグ
3
 やっぱり分散
自律分散協調型社会システム
個人や小組織の
エンパワメント
経営・企画・研究
単純な間接業務
(機械的なデータ変換)
意味的
構造化
中抜き
(自動化・コモディティ化)
フィールドでの業務
物理的な作業やサービスの現場
4
支援サービス市場の拡大
概要
セマンティックコンピューティング
人間と機械が共有する意味構造に基づくICT
データの一次利用と二次利用
間接業務の消去
ITによる中抜きの徹底
大きな組織や官僚機構は不要
個人のエンパワメント
個人データの保護と活用
データの一次利用と二次利用
5
セマンティックコンピューティング
6
オントロジー
= 概念階層 + 属性定義
クラス(概念)
非勤労者
ニート
市民
「勤労者」クラス
は「市民」クラス
に含まれる。
属性
勤労者
扶養者
主婦 ・・・ 学生
教師
会社員 ・・・ 個人業主
指導教官
小学生
中学生 ・・・ 大学生
「大学生」クラスのインス
タンスの「指導教官」属
性の値は「教師」クラス
のインスタンスである。
7
セマンティックオーサリング
オントロジーに基づくコンテンツ作成
オントロジーで定義されたクラスと関係(属性)のイ
ンスタンスとしてのノードとリンクからグラフを作
る作業
グラフをそのまま表示して編集するような直接的・
図的なユーザインタフェースが典型的
8
グラフに基づく発想支援システム
リンク
ノード
9
グラフはわかりやすい
風が吹く
桶屋が儲かる
→
風が吹くと土ぼこりが立つ。そ
の土ぼこりが目に入る。それで
盲人が増える。その盲人が三味
線を買う。ゆえにその三味線を
作るため猫が殺される。だから
鼠が増える。増えた鼠が桶をか
じるので、桶の需要が増える。
それで桶屋が儲かる。
論
理
的
構
造
が
す
ぐ
わ
か
る
加
工
が
容
易
要約
風が吹く
土ぼこりが立つ
土ぼこりが目に入る
盲人が増える
その盲人が三味線を買う
その三味線を作るため猫が殺される
鼠が増える
増えた鼠が桶をかじる
桶の需要が増える
桶屋が儲かる
1
グラフは作りやすい(1/2)
対照
頭が痛い
胃の調子が良い
因果
因果
頭痛薬を飲む
因果
頭痛 が治る
11
グラフは作りやすい(2/2)
前頁のグラフと同じ内容のテキスト:
胃の調子が良かった。でも頭が痛かった
*
ので頭痛薬を飲んだら治った。
前頁の原因に相当する関係*を反映するように
書き換えるのは大変:
胃の調子が良かったが頭が痛かった。
そこで頭痛薬を飲んだら頭痛が治った。
12
グラフは質が高い
八木下ら (1998)の実験
文章の内容を表わ
すグラフを作成
グラフに基づい
て文章を作成
見落としが少ない
含まれる論点が多い
考えが深まる
推論の連鎖が長い
13
談話グラフ
ノード(マイクロコンテンツ)
 タイプは文(対話行為)に相当するクラス
 叙述、命令、疑問など
 1単文程度のテキスト、映像、音声、イラスト、表など
 各ノードの中味をオントロジーに基づいて構造化する
ことは、通常のユースケースでは想定しない。
 ハイパーノード(グラフを含むノード)でも良い
ノードの間のリンク
 タイプは談話関係(因果、逆接、例、対照など)や後向き
対話行為(応答や確認)
 20~40個程度の属性(関係)で各自然言語の通常の文章に
1
おける文間の関係を十分に区別できる
15
文書データの木構造形式
個人が組織に依存せずに本人のデータを活用する
ため、データの検索や分析の精度と効率を高める。
意味構造の明示
→ 人間にもコンピュータにも扱いやすい
 人間による理解と作成が容易
 自動解析の精度が高い
データの一次利用
 記録作業(文書作成)のコストを低減
 文書の読解を容易にし誤読を防止
データの二次利用
 標準規格に従って正確に構造化したデータの蓄積
 検索、要約、分析、翻訳など
16
病理診断報告書(従来形式)
胃全摘検体。小弯長15.7cm、大弯長23cm。
口側周径3cm、肛門側周径4.5cm。1.2cm長の
食道が付いている。
胃の上部後壁に6.5x5cm大の2型腫瘍があ
る。腫瘍表面は褐色調で、3x2cm大の潰瘍を
有している。肛門側断端からは11cm、口側
断端からは2cm離れている。腫瘍は各断端に
及んでいない。腫瘍の漿膜側は硬くなってい
るが、腫瘍の露出は見られない。腫瘍は割面
では白色充実性で、出血や壊死は僅かである。
以上の主病変とは別に、下部大弯に3mm大
の亜有茎性ポリープがある。肛門側断端から
は6cm離れている。
そのほかの粘膜面に著変はみられない。
人間にとってもコンピュータにとっても扱いにくい。
17
病理診断報告書
(木構造形式)
凡例:
主題
主題への参照
最左の行は検体
検体の大弯
 胃全摘検体
 小弯長16cm、大弯長23cm
検体に付
 口側周径3cm、肛門側周径4.5cm いている
 1.2cm長の食道が付いている
 上部後壁に6.5x5cm大の2型腫瘍がある
腫瘍の表面  表面は褐色調
 3x2cm大の潰瘍を有する
腫瘍の漿膜側  肛門側断端からは11cm、口側断端からは
2cm離れている
腫瘍が露出
 各断端に及んでいない
上の腫瘍とここのポリープは
検体の割面  漿膜側は硬くなっているが、露出は見ら
別々のものであることが木構造
れない
からわかるので、「以上の主病
 割面では白色充実性で、出血や壊死は僅
変と別」である旨は記述不要
か
 下部大弯に3mm大の亜有茎性ポリープ
検体の肛門側断端
 肛門側断端から6cm
 他の粘膜面に著変なし
18
病理診断報告書(画像と木構造形式の統合)
大弯長23cm
胃全摘検体
口側周径3cm
小弯長16cm
肛門側周径4.5cm
食道1.2cm長
2型腫瘍
亜有茎性ポリープ
 下部大弯
 3mm大
 肛門側断端から6cm
19








上部後壁
6.5x5cm大
表面は褐色調
3x2cm大の潰瘍を有する
肛門側断端から11cm、口側断端から2cm
各断端に及んでいない
漿膜側は硬くなっているが、露出は見られない
割面で
 白色充実性
 出血や壊死は僅か
19
特許の請求項 (従来形式)
メール受信サーバから受信した電子メールのヘッ
ダーにより指定された配信日時が到来しているか
否かを判断する通知タイミング判断部と、
前記通知タイミング判断部において配信日時が到
来していないと判断された電子メールについて、
受信メモリに保持するか或いは前記メール受信
サーバへ返却するかを判断する返却要否判断部と、
前記返却要否判断部において前記メール受信サー
バへ返却すると判断された電子メールについて、
ヘッダーを変更するヘッダー変更部と、
前記ヘッダー変更部においてヘッダーが変更され
20
た電子メールをメール送信サーバへ送信する送信
部と、
を備える通信端末。
特許の請求項 (グラフ形式)
メール受信サーバから受信した電子
通知タイミング判断部
メールのヘッダーにより指定された配
機能 信日時が到来しているか否かを判断
次
構成要素
返却要否判断部
通信端末
前記通知タイミング判断部において配
信日時が到来していないと判断された
電子メールについて、受信メモリに保
機能 持するか或いは前記メール受信サーバ
へ返却するかを判断
次
ヘッダー変更部
機能
前記返却要否判断部において前記メー
ル受信サーバへ返却すると判断された
電子メールについて、ヘッダーを変更
21
送信部
機能
次
前記ヘッダー変更部においてヘッダー
が変更された電子メールをメール送信
サーバへ送信
グラフ(木)形式の有効性の検証
実験
10人の病理医の各々が10個の症例(依頼書と写真)の
うち5個を従来形式、残り5個をグラフ形式で記述。
わずか5分程度の教示により、グラフ形式を用いて、
従来形式の場合と同等以上の品質と効率で病理診断
報告を記述することができた。
考察
習熟によってグラフ形式の方が従来形式よりも品質
と効率が有意に高まる可能性がある。
グラフ形式に基づく精度の高い入力支援を提供する
ことにより、従来よりはるかに高い品質と効率で文
22 書を作成できると期待される。
グラフ形式の効能
一次利用
専門家
(病理医、
弁理士、他)
非専門家
(患者、
発明者、他)
23
二次利用
(著作、読解)
(検索、分析
、翻訳、他)
△
○
○
○
専門家の業務をオープン化
するモデルの創造が必要
PLR (個人生活録)
個人データの流通と活用
事業者が集中管理 → 個人が自律分散管理
自分の許可なしにデー
タが使われているかも
自分のデータが
活用できない
自分のデータの使わ
れ方を把握できる
自分のデータを自ら指定
した他者に自由に開示し
てサービスを享受できる
利用者
データの流れ
事業者
大量の個人データを蓄
積・管理せねばならない
顧客のニーズがよくわからない
大量データが一挙に漏洩するリスク
自らが提供するサービス以
外のデータが得られない
 市場の参入障壁が高い
 既存の事業者によるロックイン
25
大量の個人データを蓄
積・管理する必要なし
大量データが一挙に漏洩しない
顧客のニーズがよくわかる
自らが提供するサービス
以外のデータも得られる
 市場の参入障壁が低い
 サービスの質に関する自由競争
PDS: Personal Data Store
個人が本人のデータを自ら蓄積・管理し、他者と
自由に共有して活用する仕組み
星新一(1970) 声の網.
情報銀行…東大・慶大・JIPDEC
2,000年ごろに提案された?
Alan Mitchell (2001) Right Side Up: Building Brands
in the Age of the Organized Consumer. Harper
Collins Business.
2
集中型PDS
分散型PDS
物理的集中・分散ではなく管理権限の集中・分散
事業者が多数の個人のデー
各個人(または代理人)が本
タを管理
人のデータを管理
 データ利用に本人の許可も
必要
 事業者グループ内での流通
 データ利用を本人が許可
 事業者グループ間での流通
あらゆる種類のデータを相
個人の判断であらゆる種類
互運用するには全データの
のデータを相互運用
集中管理が必要だが、それ
 複数の集中型PDS等を統合
は明らかに不可能
EHR、従来のPHR、ID連
携、Respect Network、
情報銀行等
PLR (東大・アセンブロー
グ)、OpenPDS (MIT)
PLR: Personal Life Repository
 分散PDS: 個人が特定の事業者に依存せず本人のデータを管理し他者
と自由に共有して活用
 多数の集中型サービスを個人が連携させる
 事業者が各IDの範囲で個人データを名寄せして集中管理
 すべてのIDを事業者側で相互連携させるのは不可能
センサデータの収集
各事業者(グループ)
は内部で顧客の個人
データを集中管理
Maps Picasa
Drive
Google+
Gmail
YouTube
個人
Google Drive等の無
料クラウドの組合せに
より安価で高可用性
常時携帯している端末に
お薬手帳や母子手帳や医
療記録が入っている
PLRクラウド
税金
Google
社会保障
家族や友人
預貯金
日本政府
Cookpad
トラベル
クラウド
ヤフオク
docomo
マイナンバー
VISA
Yahoo!
OneDrive
Bing
28
暗号化によりクラウド運営
事業者に内容がわからない
Store
Microsoft
無印良品
Apple
HealthKit
iTunes
iCloud
TSUTAYA
ファミリー
Excelsior マート
Cafe
CCC
全個人データの集中管理による連携?
Maps Picasa
Drive
Google+
Gmail
YouTube
Cookpad
税金
トラベル
クラウド
預貯金
docomo
ヤフオク
VISA
無印良品
OneDrive
Bing
Store
TSUTAYA
HealthKit
iTunes
iCloud
29
社会保障
Excelsior
Cafe
ファミリー
マート
PLRクラウドの仕組み
PLRクラウド
Dropbox
Onedrive
Respect
Google Drive Network
端末とクラウドの間
でのデータの変換
暗号化と秘密分散
ス
マ
ー
ト サ
デ ー
バ バ
イ
ス
PLR
暗号化や通信の詳
細を気にせず開発
30
…
ストレージハンドラ
コンテンツハンドラ
URIで指定される
ファイルの交換
ファイルとRDFデー
タの間での変換
RDFデータの交換
PLRアプリ
領域オントロジーに
依存するサービス
30
データ管理の責任分界
個人は本人のデータを自らの権限と責任で管理
 他の個人や事業者とのデータ共有を自由に設定・解除
 PLRによってデータを自ら作成・利用
事業者は個人が管理するデータに責任を負わない
 顧客の連絡先や契約書やその他法律等で定められたデー
タだけを保管すれば良いので低コストかつ低リスク
個人データに関する法令等を満たす
 個人情報保護法、医療情報システムの安全管理に関する
ガイドライン(厚労省)、EUのデータ保護指令、他
31
個人データの流通と活用
事業者が集中管理 → 個人が自律分散管理
自分の許可なしにデー
タが使われているかも
自分のデータが
活用できない
自分のデータの使わ
れ方を把握できる
自分のデータを自ら指定
した他者に自由に開示し
てサービスを享受できる
利用者
データの流れ
事業者
大量の個人データを蓄
積・管理せねばならない
顧客のニーズがよくわからない
大量データが一挙に漏洩するリスク
自らが提供するサービス以
外のデータが得られない
 市場の参入障壁が高い
 既存の事業者によるロックイン
32
大量の個人データを蓄
積・管理する必要なし
大量データが一挙に漏洩しない
顧客のニーズがよくわかる
自らが提供するサービス
以外のデータも得られる
 市場の参入障壁が低い
 サービスの質に関する自由競争
PLRによる個人データの利活用
自律分散協調エネルギー管理
 太陽光発電システム等の保守
 スマートグリッド ・・・ 配電系統の安定化
自律分散協調ヘルスケア
 医療・健康データの自己管理
 医療機関や介護施設が個人を介してデータ連携
自律分散協調学習
 学習者の興味や進度に応じたアドバイスと協調学習
自律分散協調資産管理
 金融資産や不動産の管理・相続等
 データに基づく住宅・建物保守
自律分散協調マーケティング
33
 購買等のデータを顧客が蓄積・管理 → 収集・分析
 事業者が売り方を最適化(CRM)
 顧客が買い方を最適化(VRM)
本人を介する個人データの共有
 福島県相馬郡新地町の地域医療連携
 個人が自分のデータをパブリッククラウドで管理
 相手と情報の種類を自由に選んでデータを共有
 スマホ等は不要
 クラウドのデータを暗号化しておけば本人からのデータ漏洩はない
 医療機関等はデータを作成・利用するのにPLRを使う
 データを暗号化して患者のクラウドに格納
 患者のクラウドからデータを取得して復号
 導入コストは数万円で運用コストはほぼゼロ
 法律やガイドラインを満たす
個人
データを暗号化して格納
個人が管理
するクラウド
病院
PLR
3
データを取得して復号
診療所
暗号化したデータ
データを取得して復号
PLR
データを暗号化して格納
老人ホームと入居者家族とのデータ共有
 山梨県甲府市の医療・介護事業者グループ
 被介護者の家族に対する新有料サービス
 介護記録のデータを家族が管理
 自宅や外出先からタブレットPCやスマートフォンで閲覧
 介護日誌レベルの要約も容易
 老人ホームと家族との通信にも活用
 映像等の共有や遠隔見守りも
 PLRアプリ運用費 < 新サービスの収益(5,000円/月?)
老人ホーム
介護記録等
新たな収益
自宅
被介護者
サービス向上
負担軽減
介護者
35
問合せ
お知らせ
被介護者
の家族
ヘルスケアデータの個人分散管理
今後5~10年で普及
医療制度改革(~2025年)
異業種間でのデータ共有が必須
 ヘルスケア事業者の間の水平分業
病院を急性期、回復期、療養期等に分類
診療所間のデータ共有も必須
 24時間365日の在宅医療対応
集中管理型データ共有による囲い込みは不可能
分散管理型の方が圧倒的に安くて便利で安全
36
データ共有
の方法
集中型
分散型
ID-Link
HumanBridge
(SaaS型)
PLR
6~180百万円
各電子カルテシ
ステムへの接続
に10百万円以上
端末購入費等
< 集中型の1/10
運用コスト
2~8万円/月
+ サーバ運用費
10万円/月
(富士通のデー
タセンタ利用)
端末償却費等
< 集中型の1/10
データ共有
公開機関のデー
タを他機関が参
照
医療機関同士が
データを相互参
照
患者の同意で任
意の者が共有
連携サーバ
@拠点病院
@データセンタ
か拠点病院
パブリッククラ
ウド
累計導入実績
2,407機関
(2013年10月)
2,000機関
(2014年末?)
3機関
(2014年前半?)
導入コスト
自律分散協調ヘルスケア
 急性期病院: (逆)紹介率を高め、患者の手離れを良くしたい。
 診療所: 病院のデータを参照し、また互いにデータを共有したい。
健康管理
本人
家族
見守り
薬局
訪問看護ステーション
医薬連携
PLRクラウド
老人ホーム
病院
 現場の負担軽減
 サービス向上
 収益増大
38
 診診連携
 病診連携
 治療指導
診療所




 退院サマリ
患者の確保
 看護サマリ
再入院の抑止  薬剤サマリ
病診連携
地域医療連携計画策定
VRM: 業者関係管理
Vender Relationship Management
CRM (顧客関係管理; customer relationship
management)の逆
顧客が自らの意思とデータに基づいて業者(サービ
スや商品)の組み合わせ(買い方)を最適化
 広告や推薦よりはるかに高精度で安価
Berkman Center for Internet and Society, Harvard
Univ.の研究プロジェクト … Media Lab., MITと連携
顧客がPLRデータを事業者に開示し、それに基
づいて事業者がサービスや商品を提案
顧客のPLRデータを託されたソフトウェアエー
ジェントがサービスや商品を検索
39
ヘルスケアにおけるVRMの例
利用者A
データに基づく評価
私みたいな人があの病院に
かかると5年生存率は60%
私に似た人達にはこの薬
が効いているみたい
私みたいな病状の人は
世の中に2%ぐらい
生データの
分析結果
40
診療明細、検査結果、
処方、満足度、バイタ
ルデータ、主観的体調、
etc.
個人を特定で
きないデータ
情報取得
検索要求
知識ベース
利用者Aの
認証は不要
個人データのアドホックな集約と分析
 データ開示の手続きがオンラインで簡単に
 本人の目の届く範囲で個人データが流通
→ 安心してデータを開示
個人データ
元データを
取得しない
41
分析者
与信
分析結果
データブローカ
開示の条件を形式的に表
現することにより、PLR
が可否を半自動的に判断
多くの個人のPLR
IDを知っている
データブローカ+サーベイ事業
 アンケート代行事業によるPLRデータの蓄積
 アンケートへの回答を回答者のPLRに格納
 他のサービス(WellnessLINK、Amazon、
Expedia、楽天など)のデータを自動的に取得
してPLRに蓄積するアプリ
 アカウント管理 ~ 1Password
 単なるデータブローキング(後向き調査)では
なく目的に応じたアンケート(前向き調査)
個人
 アンケートが中心
 過去のアンケートへの回答を含む個人データ
のニ次利用
センサデータ
センサ
サービス
データ
元データを
取得しない
サービス事業者
アンケート発注者
42
与信
分析結果
アンケート結果
個人データの開示
アンケートへの回答
データブローカ
(TEPCO, etc.)
多くの個人のPLR
IDを知っている
PLRで得をするのは誰か?
もちろん個人のメリットは大きい。
それは産業全体のパイの拡大をもたらす。
しかし、PLRの最大の受益者は、多数の顧客に
個別に(PLR IDで)連絡できる事業者:
Google、Amazon、Facebook、Dropbox、Apple、
通信事業者、電力会社、政府・自治体、etc.
Amazon主導のVRM
 Amazonは、PLRに基づくVRMにより、個人データ
管理や推薦のコストを激減させ、売り上げを増や
せる。
43
まとめ
概要
セマンティックコンピューティング
人間と機械が共有する意味構造に基づくICT
データの一次利用と二次利用
間接業務の消去
ITによる中抜きの徹底
大きな組織や官僚機構は不要
個人のエンパワメント
個人データの保護と活用
データの一次利用と二次利用
4
Fly UP