DEIM Forum 2013 F5-6

緊急時判断に基づく状況に応じた個人情報へのアクセス制御
長谷川友香†

小口 正人†† お茶の水女子大学 〒 112–8610 東京都文京区大塚 2-1-1
E-mail: †yuka@ogl.is.ocha.ac.jp, ††oguchi@computer.org
あらまし 緊急災害時に家族間で個人情報を共有できれば，安否の確認や捜索などの面で大いに助けになる．しかし，平常時から当人の許可なしに個人情報を閲覧できるのは，プライバシの観点から問題である．本研究では実世界の状況に合わせて情報へのアクセス権を変化させることのできるアクセス制御手法を提案する．提案手法では，実世界において平常時か緊急時かの判断を行うためにシステム外部から情報を取り入れ，さらにユーザの判断をシステムに反映させる．そのようなアクセス制御手法を取り入れたシステムの例として，家族間情報共有システム FISS(FamilyInformation Sharing System) を構築したため，これを紹介する．
キーワード

情報共有，災害，階層型認証，クラウド，Android，ライフログ

An Access Control Method which depends on the Situation
based on a Judgement of Emergency
Yuka HASEGAWA† and Masato OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyo, Tokyo, 112–8610 Japan
E-mail: †yuka@ogl.is.ocha.ac.jp, ††oguchi@computer.org

1. は じ め に
東日本大震災のような災害発生時には，多数のユーザが同時の回線が混雑していてつながりにくい場合でも，全く別の場所にあるサーバからデータを取得し，家族の状況を把握する手掛かりが得られる．にネットワークを利用するため，回線が輻輳を起こし，急激にしかし，このシステムにおいて考慮すべき点として，緊急時電話やメールがつながりにくくなるという事態が発生する．こにのみ個人情報へアクセスできるようにしなければいけない．のような場合には，電話やメールなどを用いた家族の安否確認

そのためには，実世界の状況に応じた情報へのアクセス制御手は非常に困難である．被災地住民に対する調査 [2] によると，東法が必要である．本論文ではそのような制御手法を取り入れた

日本大震災の被災地で電話が使えず困った人は調査対象全体のシステムの一例として，複数の情報を用いて緊急時判断を行い，8 割ほど存在し，そのうちで家族・親戚・友人の安否確認がとその結果に応じてアクセス制御を行うシステムを提案する．

れず不安に感じた人の割合が 8 割以上であった．このことから

本論文では，まずシステムの概要について紹介し，システム電話通信がほぼ不可能な状況において安否の手掛かりになるよの持つ機能について説明したのち，それらの機能がどのようにうな情報が入手できれば，不安が軽減されることが予想される．

アクセス制御に用いられるかを示す．そののち各機能の実装方

さらに精神面だけでなく，行方不明となった人の捜索の面でも法についてそれぞれ説明していく．

役立つといえるであろう．
そこで，平常時から安否確認の手掛かりとなるような情報で

2. 家族間情報共有システム

あるライフログを貯めておき，緊急時にそれらの情報を見るこ

2. 1 概要とのできるシステムがあれば有用であると考えられる．そのよ

本研究では，家族間での緊急時における情報共有を目的としうな仕組みがあれば災害の発生した地域にいるユーザがメールたシステムである FISS(Family Information Sharing System)や電話などに反応できない場合であっても，また災害発生地域を構築した．そのシステム構成を図 1 に示す．

取り込むこととした．これらは公開されている API を用いて取得している．

2. 2. 3 内部情報の処理
第三の機能は，ユーザの Android アプリケーションの操作によって得られる，システム内部の情報を緊急時判断とアクセス制御に用いるために処理することである．ここでいう「ユーザの Android アプリケーションの操作」とは，自分の家族内のあるユーザの個人情報を見たいというリクエストを送ることである．このリクエストも緊急時判断の情報源となりうるが，リ
図1

システム構成図

クエストがあったら常に緊急時であると判断するように用いると個人の独断で情報を見ることのできるシステムになってしま

FISS はサーバ側とクライアント側に分かれており，サーバ側は汎用クラウドサービスである Amazon EC2 上に，クライアント側は Android 端末で動くアプリケーションとして構築している．ユーザは Android アプリケーションからシステムを利用する．

2. 2 システムの機能
システムの主な機能として以下の 4 つを取り上げ，それぞれの概要について説明する．

2. 2. 1 個人情報の蓄積
FISS の第一の機能は個人情報の蓄積である．この個人情報とは，家族と連絡が取れなくなった際に家族の居場所を特定したり，安否を確認したりするために有用な情報を指す．そのような情報としてさまざまなものが考えられるが，例として移動履歴，Android 端末の操作ログ，スケジュールの情報を用いることとした．各情報が，災害発生時にどこにいたか，いつまで携帯端末を操作できる状態にあったか，誰と何をしていたかの手掛かりになると考えられるためである．さらに，災害が起きたと判断された際にユーザに対して安否確認を行い，その際にユーザから送信される安否情報やメッセージを保存する．このう．そのような状況を避けるために，この情報は直接ではなく何らかの制御方式に従って用いるべきであると考えられる．本
論文ではその制御方式として「階層型相互認証」と「周辺ユーザへのリクエスト割合による判断」の二種類を提案する．FISS中ではそれらを併用することとした．

2. 2. 4 緊急時判断とアクセス制御
第四の機能は，第二の機能で取り上げた外部情報と第一，第三の機能で取り上げた内部情報を用いて緊急時判断を行い，アクセス制御を行うことである．ここでいうアクセス制御には，情報を見せるか見せないかという制御だけでなく，どの情報を見せるかという制御も含まれる．具体的には，外部情報である
緊急地震速報とニュース記事，また内部情報のうち「周辺ユーザへのリクエスト割合」，「安否情報の有無」を用いて緊急時判断を行い，「階層型相互認証」を用いてどの情報を見せるか決めるアクセス制御を行う．

3. 緊急時判断とアクセス制御
本章では緊急時判断とアクセス制御の詳細について説明する．
処理の流れを図 2 に示す．

安否確認にユーザが反応したかどうかも内部情報として緊急時判断に用いる．
移動履歴は Android 端末の GPS 機能を用いて定期的に取得し，サーバ側に送信して蓄積する．操作ログは Android 端末で操作が行われるとどのような操作がなされたかを取得し，定期的にサーバに送信して蓄積する．スケジュールは Google カレンダーの情報を，Google 社の提供する「Calendar API」[4] を用いて取得する．各ユーザは OAuth 認証を用いて Google カレンダーへのアクセス権をあらかじめシステムに委譲しておく．
そうすることによってユーザ ID とパスワードをシステム側で保存しておく必要なしに，システムがデータを取り出せるようになる．

2. 2. 2 外部情報の取得
第二の機能は，緊急時であるという判断材料となる外部からの情報を取得することである．詳細は後述するが，緊急時であるという判断には複数の情報を用い，より信頼性の高い情報のアクセス管理を実現する．緊急時判断の材料となる情報は，これも多く考えられるが，例として緊急時になりうる状況の一つである地震に着目し，緊急地震速報とニュースサイトの記事を

図 2 緊急時判断とアクセス制御の流れあるユーザの情報を見たいというリクエストがあったときにまずステップ 1 として緊急地震速報，ニュース記事あるいは周辺ユーザへ情報公開リクエストが送られた割合を用いて情報閲覧をリクエストされているユーザが危険地域にいるかを判断する．ここでいう危険地域とは災害の被害が及ぶと推定される地域のことである．ステップ 2 として，ユーザが危険地域に居た場合はそのユーザから安否情報が通知されているか調べる．
安否情報が通知されていない場合に，そのユーザは危険地域におり，かつ安否がわからないという可能性が高いので，家族はに保存してある各ユーザの現在地を用いてユーザ位置での大まそのユーザの情報を見ることができるものとする．しかし，あかな震度を予測する．予測のための計算式は [8] や [9] に紹介さくまでも可能性が高いというだけであり，実際には何の被害もれているものを用いた．

被っておらず，ただ携帯端末を見ていなかったということも十4. 2 ニュース記事分にあり得る．それゆえ，該当ユーザの個人情報を一気に全てさまざまなニュースサイトが存在するが，一例として Yahoo!

公開してしまうことは適切でないと考えられる．そこでステッニュースを取り上げ，その記事が発行される様子を監視するこプ 3 として階層型相互認証を用いる．この階層型相互認証を用ととした．Yahoo!社が提供する「トピックス見出しアーカイいることで先に述べたような状況で情報が見られることを防ぎ，ブ API」[6] を利用し，地震に関連するニュース記事が発行されさらに段階的な情報の公開が可能となる．

たかどうかを一定の間隔で確認する．発行された場合はニュー

4. 外部情報の利用
外部情報の取得からユーザへの安否確認の送信までの流れをス記事の見出しから，地震の発生地域と震度情報を取得する．
ユーザの現在地は緯度経度情報で保存されているので，発生地域を緯度経度に換算する必要がある．そこで Google 社の提供する「Geocoding API」[7] を利用する．この API は地名をパ図 3 に示す．

ラメタとして GET リクエストを送ると，該当する地域の範囲を緯度経度で返すものである．ただし，「関東」や「東北」などの地方名には対応していないため，それらの場合は FISS 内部で変換を行う．変換後の範囲内にいるユーザに対して緊急地震速報の場合と同様にユーザに安否確認を行う．
ここで注意すべきなのはニュース記事の取得はリアルタイムではないということである．こちら側からリクエストを送って定期的に記事発行の有無を確認するという方式であり，記事が発行された瞬間に緊急時判断を行うことは不可能である．

4. 3 外部情報による緊急時検知
前節までに述べた方法を用いて取得した約 4 週間分のデータ
図3

外部情報の取得とユーザの安否確認を図 4 に示す．このグラフは，Twitter を通して取得した緊急地震速報と Yahoo!ニュース記事の関係を示すものである．

緊急地震速報は揺れが感知された時点で発せられ，実際に地震の波が届く前に警告を与えることを目的としている．それに対し，ニュース記事は実際に観測された地震とその被害状況にᆅ㟈ᅇᩘ

108

基づいて発信される．FISS では災害の被害の及ぶ可能性にあ7るユーザに対して Android アプリケーション上で安否確認を6行うこととしており，できるだけ早く危険地域にいるユーザを5見つけたい．しかし，緊急地震速報の発表されない場合や，発䝬䜾䝙䝏䝳䞊䝗

99໭ᾏ㐨䛷㟈ᗘ5ᙉ䚸వ㟈ὀពᆅ㟈ᅇᩘⲈᇛ䛷㟈ᗘ5ᙅ䚸ὠἼᚰ㓄䛺䛧
2013-02-01 00:01:29

᭱኱䝬䜾䝙䝏䝳䞊䝗໭ᾏ㐨䛷㟈ᗘ5ᙉ䚸వ㟈ὀព
2013-02-02 23:20:30
2013-02-02 23:20:30

876
5

4
43

3

表されたものよりも実際の地震の方が規模が大きいことは十分2にあり得る．そこでニュース記事の情報も併せて用いることで，危険地域にいるユーザの検出漏れを極力減らす．

4. 1 緊急地震速報
気象庁から直接緊急地震速報を取得するには「予報業務許可」

2

1

1

0
1/10

0

1/13

1/16

1/19

1/22

1/25

1/28

1/31

2/3

2/6

図 4 緊急地震速報と Yahoo!ニュース記事の関係が必要であり，法人でなければならない．そのため Twitter 上で発表される緊急地震速報のツイートを取得することで間接的

ここで，「最大マグニチュード」とはその日に発生した地震のに緊急地震速報を利用した．Twitter 社の提供する「Streaming中で最もマグニチュードの大きかった地震のその値を指す．緊API」[5] を利用し，緊急地震速報を流しているアカウントのツ

急地震速報が発表された地震はデータ取得期間中に 76 回であっイートをリアルタイムで取得する．そのツイート内容から地震たのに対し，Yahoo!ニュースで地震の記事が発行されたのは 2の発生位置や規模を解析し，危険地域にいると判断したユーザ回であった．Yahoo!ニュース記事は 2 月 1 日と 2 日に一つずつに対して安否確認行う．

発行されている．2 月 2 日に発生した地震は Yahoo!ニュースに緊急地震速報を Twitter 上で流しているアカウントは多数あるが，今回は一例として「@eewbot」というアカウントのツよると北海道で震度 5 強という比較的大きなもので，緊急地震速報によるとマグニチュードは 6.5 であった．

イートを用いた．このアカウントは高度利用者向け地震速報を

2 月 1 日のニュース記事に注目すると，茨城県で震度 5 弱のcsv 形式で配信しており，ここから地震発生位置（緯度，経度，地震が発生したことが伝えられているが，この地震は日をまた深さ）と地震規模（マグニチュード）を取得する．FISS 内部

ぐ直前に発生したものであり，実際に発生した日付は 1 月 31

日である．緊急地震速報からサーバがこの地震を検知した時刻

緊急地震速報を用いたユーザ位置での震度予測では地震発生

は 1 月 31 日 23 時 53 分であり，ニュース記事が発行される 8場所に近いユーザほど大きな震度が算出されており，妥当な結分ほど前である．先ほど取り上げた北海道での地震における緊果であると言える．ニュース記事からも地震の発生地域にいる

急地震速報と記事発行の時間間隔は 2 分間程であった．ニューユーザを危険であると正しく判断できた．

ス記事は確認された事実が書かれているため正確な震度や被害ニュース記事に記載されている震度はその地域で最大のもの

状況を知ることが出来るが，その分即時性は下がり，地震発生であり，例えば北海道の地震ならば十勝での震度である．札幌

後どれくらいで記事が発行されるかは状況により異なるというで実際に観測された震度は 3 であり，この場合は緊急地震速報ことが分かる．

から得たデータで適切に予測が出来ている．茨城の地震の場合

ニュース記事が出ていない他の日でマグニチュードが大きい

は同じ県内でありながら震度 5 弱と 2 の地域が存在するもので地震が起こっている様子が見られるが，これらの地震は陸地かあったが，これは震源が 10km の深さと比較的浅いところで発ら離れたところで発生しており，人の住む地域に大きな影響が生した地震であるため，揺れが広範囲に広がらず，局所的に大なかったため記事にならなかったと言える．

きな揺れが発生したことによる．

次に，ユーザが日本の各地にいると仮定してそれらのユーザシステムを実運用する際には，算出した震度に対して閾値をが危険地域にいると判断されたかどうかを示す．仮想的なユー設けて，それより大きな震度が予測されたらユーザに安否確認

ザの配置場所を図 5 に示す．

をするべきであるが，算出した震度には幅があり，精度はあまり良くない．算出される値と実施の震度が大きく違う可能性もあるので，閾値は低めにとり，本当の緊急時を取りこぼさないようにすべきだと考えられる．
以上から，緊急地震速報を用いた震度推定と Yahoo!ニュース記事の解析はそれぞれ考慮すべき点はあるものの地震から起因する緊急時の判断に用いることのできる手法であると言える．
さらに，それぞれに利点と欠点が存在するため，単独ではなく組み合わせて用いることが有用であると推察される．

5. 内部情報の処理
2 章で述べたように，あるユーザの情報を見たいというリク
エストは「周辺ユーザへのリクエスト割合による判断」，「階層図 5 ユーザの配置型認証」の二つの方式で処理して緊急時判断・アクセス制御にユーザが札幌，茨城，東京の県庁所在地にいるものと仮定用いる．

5. 1 周辺ユーザへのリクエスト割合による判断

した．
図 4 で取り上げた北海道の地震の際の結果を表 1 に示す．ここの方式は，一人の判断では信用度が低いが，同一の場面でれは北緯 42.6 度，東経 143.3 度，深さ 120km の地点で発生し多くの人が同様の判断をしたら信頼度は高いものという考え方たマグニチュード 6.5 の地震である．気象庁が後日発表した各に基づいている．この概要図を図 6 に示す．情報を公開するよ

地の震度を比較のために表に加えた．

うリクエストが送られたユーザ A の周りにいるユーザを探索し，それらのユーザにも同様にリクエストが送られているか調

表 1 2 月 2 日に発生した北海道での地震によるユーザへの影響
緊急地震速報
気象庁発表
ユーザの場所 から算出の震度Yahoo!ニュースの震度

べる．
ユーザ A の周りのユーザにもリクエストが送られている場

札幌

3.3 ± 0.7

地域内（震度 5 強）

3合は，その地域は災害の被害を受ける可能性が高いとそれぞれ

水戸

0.5 ± 0.7

地域外

2のユーザの家族が判断しているということである．そこでユー

東京

0.1 ± 0.7

地域外

1

ザ A は危険地域にいると判断する．
この方式のメリットは，当事者の判断ではなく第三者の判断同様に茨城での地震の際の結果を表 2 に示す．これは北緯のみを参考にするため，客観的な基準で情報の公開・非公開が36.7 度，東経 140.6 度，深さ 10km の地点で発生したマグニ決まるということである．そのため，ユーザ個々の判断を情報

チュード 4.7 の地震である．

源として使用しているものの，一人のユーザが家族の情報を見

表 2 1 月 31 日に発生した茨城での地震によるユーザへの影響
緊急地震速報
気象庁発表
ユーザの場所 から算出の震度Yahoo!ニュースの震度
札幌-1.8 ± 0.7

地域外なし

水戸

2.5 ± 0.7

地域内（震度 5 弱）

2東京

1.3 ± 0.7

地域外なし

ようとした場合に簡単に見ることができるという状況は防ぐことができる．
この方式ではどのくらいの数のユーザを探索し，どのくらいの割合でリクエストが来ていたら危険地域にいるという判断をすべきか検討する必要がある．これらの値は人口密度などによって地域ごとに変化すると考えられる．

図 6 周辺ユーザへのリクエストを用いた判断の概要

5. 2 階層型相互認証
本論文では階層型相互認証とは，ユーザがそれぞれある階層にいるとし，同じ階層にいるユーザ同士が認証されたとして情報を互いに閲覧できる認証モデルである．その概要図を図 7 に示す．
(a) 自分のレベルを変更中(b) 自分のレベルを変更後(c) 相手のレベルを変更中(d) 相手のレベルを変更後

図 7 階層型相互認証の概要

各階層には個人情報が割り当てられており，同階層のユーザでその情報を互いに閲覧できる．通常ユーザはレベル 0 の非公開層にいると考える．緊急時のユーザの階層移動を，ユーザ Bがユーザ A の操作ログを見ようとすることを例にとって考える．ユーザ B はユーザ A をレベル 2 の層まで上げる．するとユーザ B も自動的にレベル 2 の層まで上がる．これによりレベル 2 で同じ層であるので相互に操作ログの情報を見られるようになる．

図8

レベル変更画面

ここで，相手のレベルを上位層に上げると自分も強制的に上位層に上がるので，これによりむやみに高い階層の情報を見ないよう抑止力として働くと考えられる．相手の情報を見るためには自分も同じレベルの情報を相手に公開しなければならないということである．

図 8(b) はユーザに対して安否確認を行う画面である．サー
バ側で危険地域にいると判断されたユーザに対して，PUSH通知によってサーバから Android 端末にその情報を通知する．

PUSH 通知とはサーバ側からクライアント側へデータを送信する仕組みのことである．通常ならばクライアントからのリクエ

6. Android アプリケーション
ここまで説明してきた制御方法等は全てサーバ側の実装である．本章では UI 部分である Android アプリケーションの実装を紹介する．
図 8(a) がアプリケーションのメイン画面である．ユーザはここから自分の各種情報を確認できる．

ストがあった時にサーバからデータを返すという流れになるが，この PUSH 通知を用いることで，サーバから任意のタイミングでクライアントにデータを送信することができる．Android
でこの仕組みを利用するために Google 社の提供する「GoogleCloud Messaging for Android」というサービスを利用した．
図 8(c) は安否確認済みのユーザの情報画面である．このユー
ザは安否確認を済ませているので，安否情報とメッセージが表示される．安否情報がわかるため，このユーザは緊急状態にはないと判断され，個人情報を見るために階層レベルの変更をすることは不可能である．
図??は安否確認が取れていないユーザの階層レベルを変更した画面である．このとき自分も同じレベルの階層に上がり，他の人から情報を見られる可能性のある状態になる．この画面の状態に至るのは，該当ユーザが危険地域にいると判断され，そのユーザから安否確認が取れず，さらにあるユーザが自分の情報を他の人に見せてでもそのユーザの情報を見なければいけないと判断した場合のみである．そのようなアクセス制御を行ったうえで，非常事態に巻き込まれた可能性の高いユーザの情報を，その家族が見ることのできる仕組みが提供されている．

7. まとめと今後の課題
実世界の状況に合わせてアクセス権の変化するアクセス制御手法を提案し，その手法に基づいて個人情報を管理する家族間情報共有システム (FISS) を構築した．これにより，平常時には個人情報は誰からも見られないが，緊急時のみ家族から情報を見られるシステムを実現した．
今後の課題としては，外部情報から実際に地震を検知し，ユーザを危険地域にいると判断する機能のテストを行う．その際，どのくらいの震度で危険地域にいると判断すべきかという点や，地震発生後どれくらいの時間で判断ができるかという点などを考察する．さらに，地震以外の災害を検知する方法を考察する．
また今後は周辺ユーザのリクエスト割合によって緊急時を検知する方法において，シミュレータを作成して，どのくらいの割合で緊急時とするのが最適かという点やどのくらいの周辺ユーザを探索するべきかという点などを考察する．人口密度の違いなどによって最適なパラメタがどのように変化するか調査する．また，周辺ユーザ探索において，速度を向上させる方法を検討する．
文献[1] Takeshi Sakaki，Makoto Ozaki，and Yutaka Matsuo: Earthquake Shakes Twitter Users: Real-time Event Detection by
Social Sensors ，Proc.of the 19th international conferenceon World Wide Web 2010[2] 千葉直子，山本太郎，関良明，高橋克己，小笠原盛浩，関谷直也，中村功，橋元良明: 被災地住民の情報通信利用の実態と心理―
東日本大震災の被災地住民への訪問留置調査― ， DICOMO
2012，1G-4，2012 年 7 月．
[3] 山本太郎，千葉直子，関良明，高橋克己，小笠原盛浩，関谷直也，中村功，橋元良明， 被災地住民のインターネット利用における安心と不安―東日本大震災の被災地住民への訪問留置調査― ，DICOMO 2012，1G-5，2012 年 7 月．
[4] Google Calenar API, http://developers.google.com/
google-apps/calendar/[5] Twitter Streaming API, http://dev.twitter.com/docs/streaming-apis[6] Yahoo! トピックス見出しアーカイブ API, http://developer.
yahoo.co.jp/webapi/news/news/v1/heading.html[7] Google Geocoding API, http://developers.google.com/maps/documentation/geocoding/[8] 気象庁地震火山部， 緊急地震速報の概要や処理手法に関する技術的参考資料 ，http://www.seisvol.kishou.go.jp/eq/
EEW/kaisetsu/Whats EEW/reference.pdf[9] 独 立 行 政 法 人 防 災 科 学 技 術 研 究 所 ， 地 震 動 の 評 価 モ

デル ，http://www.j-map.bosai.go.jp/j-map/result/tn
275/html/html/2-7.html