見出し画像

GoogleとAppleが始めるコロナ対策アプリの課題と対応策とは?

コロナ対策アプリに関する取り組みは国単位だけでなく、民間でも積極的に開発が進められています。

GoogleとAppleは協力し5月には第一弾として公衆衛生当局向けに技術を提供すると発表しています。

この技術は個人のデータプライバシーに配慮した上で、感染者と濃厚接触の可能性がある人たちに通知を行い、感染拡大を防ぐ意図で開発されています。

しかし、発表された内容に関していくつかプライバシー保護に関する懸念材料(個人を特定できる要素があるのではないか)が上がっており、今回の記事では具体的なポイントを紹介したいと思います。

コロナ対策で開発されているアプリの種類

感染拡大を防ぐために各地域でアプリ開発が積極的に進んでおり、多くのアプリは利用者のプライバシーに最大限配慮した設計に取り組んでいます。

特徴としては以下の4つの種類に分けられます。

ユースケースイメージ.002

左に行くほど個人のデータプライバシーに関する権利は第三者(政府や民間企業など)が握る事になり、右に行けば行くほど個人でデータを管理する事ができる設計になっています。

当初は韓国、中国を除くとイスラエルとシンガポールの二カ国だけで展開されていましたが、5月に入り多くの国でアプリの提供、及び具体的な検討が始まっています。

ユースケースイメージ.002

これまではシンガポールのような接触感知型のアプリ(Bluetooth対応)が最もプライバシーに配慮した設計として検討が行われてきましたが、ここにきてデータを取得しない設計モデルも検討が始まっています。

※シンガポールでは5月2日の政府記事で先月から開始したSafeEntryと呼ばれるアプリの活用促進を5月12日以降店舗や企業に義務付け、これまでユーザー同意の下に設計されていたTracetogetherとは別にクラスター対策を進める計画です。

欧州全域ではGDPR(EU一般データ保護規則)の下、各国のDPA(データ保護当局)とデータプライバシー保護に関する厳格な議論を行い、各国は取り組みを決定しています。

フランスでは当初ドイツ同様にROBERTと呼ばれる感染者コードと接触可能性があるコードリストを紐づけて中央でデータを管理するモデル技術を導入して開発を進めて行く計画でしたが、ドイツが取り下げた事に加えて、国内の暗号学者やセキュリティ専門家からの要望もあり見直しが行われています。

一方でイギリスではNHS(国民保健サービス)が中心にアプリの提供を進めており、ドイツなどデータを取得しない方法で検討している他国と比較するとデータ取得での議論を中心に取りまとめています。

GoogleとAppleが進めるコロナ対策サービス

各国で様々なアプリや関連技術の導入が進んでいますが、中でも特に注目が高い取り組みとしてGoogleとAppleが共同で進めているコロナ対策の新しい機能です。

接触感知型のモデルで4月10日に両社の取り組みに関する具体的なロードマップが発表され、5月から本格的に始動すると明記されています。

第一ステップとしては公衆衛生局など国の機関がアプリを開発ができるように技術提供を行い、第二ステップは今年の後半にかけてインフラ技術として幅広く機能を利用できるようなステップで進めています。

ユースケースイメージ.003

GoogleとAppleの取り組みには普段利用しているサービスで、幅広く普及しやすいだろうという視点から期待が集まっています。

GoogleとAppleの対策とプライバシー保護の仕組み

GoogleやAppleが提供する上で個人のデータプライバシーに関する問題はアメリカ国内だけでなく、欧州各国でも議論が巻き起こっています。

イギリスでは両社のモデルではなく、独自の取り組みを促進するように検討が進むなど一部懸念するような動きも見られます。

両社の取り組みはシンガポールなどと同様にBluetooth機能を活用してスマホデバイス同士がお互いに感知し、特定のデバイス保有者の感染が確認された際にはデバイスで感知した過去二週間の接触感染者の人たちに通知が行くという設計になっています。

実際にGoogleとAppleの提供する仕組みがどのように機能するのかを紹介します。

ユースケースイメージ.004

①ランダムに発行される識別コードはBluetooth設定をオン(オプトイン)にした状態で10〜20分以内で新しく更新されます。毎回新しい識別コードが発行されるため、第三者が発行者を特定して位置情報を把握するリスクを減らすことができます。(プライバシー配慮)同じ範囲に数分以内デバイスが止まると双方をBluetoothを通じて感知します。

ユースケースイメージ.005

②Aさんの感染が発覚した場合はアプリを通じて公衆衛生局へ感染確認の通知を行います。衛生局はAさんに情報公開の同意を求め、同意が確認できた場合に毎回発行されていたAさんの識別コードは感染者コードとしてクラウドデータベースに記録されます。

ユースケースイメージ.006

③感染者コードはアプリ利用者向けに公開で保存され、Bさんのスマホデバイスは定期的に感染者コードを取得し続けます。BさんとBluetoothを通じて接触可能性が確認されたAさんの感染者コードを取得した際には、Bさんに対して濃厚接触可能性通知が行われます。

Bluetoothを活用した接触感知型の取り組みは各国でも採用が増えてきてはいますが、一方でデータプライバシーに関する課題もいくつか残っています。

GoogleとAppleが進めるプライバシー設計の課題

GoogleとAppleに限らずBluetoothを通じた接触感知型を採用するにあたって、データプライバシーリスクに関しては検討が必要になります。

今回は電子フロンティア財団が言及しているいくつかのポイントからデータプライバシーリスクの可能性を整理したいと思います。

1、友人など行動を想定しうる識別コードから個人を特定するケース

感染者に関する情報は匿名化された状態(感染者コード)でデータベースに記録しておく設計になっています。

しかし、ランダムに発行される識別コードと顔認識技術などを通じて得た付帯情報を組み合わせて、感染者を特定したデータベースを第三者が作成できてしまう可能性があります。

ユースケースイメージ.007

お互いに知り得る人(友人など)などは接触経路が想定しやすいため、感染通知を行うコードは匿名化されていても誰が感染しているかという事実は推定しやすい情報です。

感染通知コードとその他の情報を組み合わせる事で、感染した個人を特定した独自のデータベースの作成が可能になるケースも想定できます。

2、個人の識別コードを複数集める事で個人の行動を特定するケース

識別コードはランダムに10〜20分間の間隔で発行されますが、GoogleとAppleの取り組みに関しては感染者コードに関しては1日(24時間)の有効期限で発行が行われます。

そして、感染者コードが発行されると濃厚接触可能性のあるデバイスには通知が行われます。この機能を上手く活用する事でランダムに発行される識別コードから個人を特定される可能性があります。

実際に想定されるケースを考えてみたいと思います。

画像8

(画像:Apple and Google’s COVID-19 Exposure Notification API: Questions and Answers

上の図の赤い点がAさん(仮名)が誰か(スマホデバイスで機能をオンにしている人)と接触したポイントです。Bluetoothを通じて10〜20分ごとに発行された識別コードを点にして地図上でアップしています。

事前に複数の協力者(Aさんとスマホデバイスで接触する人)を募りAさんに接触してもらう事で、Aさんの接触(デバイスを通じてAさんとどこで出会ったかを見える化している)状況が上記のように見える化するようになります。

画像9

(画像:Apple and Google’s COVID-19 Exposure Notification API: Questions and Answers

その後、Aさんが感染した場合は、Aさんと接触があった可能性がある人(事前に募った協力者)たちに通知が行われます。

仮に協力者が100人いたとして、10分ごとに別々の人がAさんに接触していたと表示される場合は10分ごとのAさんの動きを地図上で予測することができます。(協力してくれた100人の濃厚接触可能性通知を辿っていくと一つの一つの点が地図上でAさんが辿った一つの線になる)

協力者に関しては必ずしも人である必要はなく、街中にBluetoothビーコン設置し活用することによっても実現できます。

(動画例:Indoor Localization Using Bluetooth Low Energy (BLE) Beacons)

これによってAさんの住所や職場、実際に訪れた場所などを特定することができるようになります。

GoogleとAppleが開発する感染者コードに関しては24時間有効な設計になっているため、感染者コードの有効期間を短くすることで個人の行動が特定される時間を短縮できるようになります。(MITが進めるPactと呼ばれるプロジェクトは1時間の有効期限

3、公権力によってデータ開示を求められるケース

スマートフォンなどのデバイスに識別コードが記録されているため、警察などの公権力によって個人デバイスからコードを開示するケースが出てくる可能性も考えられます。

※プライバシー以外の問題 「スマホの所有者はあなたは本人ですか問題」

識別コードをスマホデバイスから発行した際に、本当にそのスマホデバイスを所有者が持って活動しているかどうかは非常に重要なポイントです。

所有者であることを証明するためには識別コードが本当にスマホの所有者である事(第三者が勝手に操作していない)を確認する必要があります。

ユースケースイメージ.005

GoogleとAppleが発表している仕様では識別コードを発行する際にスマホデバイス保有者が本人であるか証明するための個人認証を行うと記載がないため、現時点では第三者によるスマホデバイスの利用可能性課題が存在しています。

GoogleとAppleの取り組みに追加で必要な視点

国内でもGoogleとAppleの取り組みに対しては注目が集まっており、シンガポールとは別に普及という視点で支持する動きも集まってきていると思います。

安心して全ての人たちが利用する環境を設計するためにはデータプライバシーの観点から以下の点に留意する必要ではないかと考えられます。

匿名データの課題
データを取得する必要性を再度考える
データの管理権限と使用期限

匿名データの課題

識別コードが匿名データであったとしても、匿名データを取得した人によっては別の情報(例えば頻繁に会う近しい友人やお店のスタッフの人など)を組み合わせることによって特定できてしまうケースがあります。

そのため匿名データであるからデータプライバシーが100%担保できているとは限らないという視点での設計が必要になります。

データを取得する必要性を再度考える

公衆衛生局が感染者コードを取得する(匿名)場合においては、ハッキングによる情報漏洩、他の政府機関などへの情報提供を含めてデータ取得者に対する信頼が十分に担保できた上での設計が必要になります。

そのため、データを取得する主体(アプリを開発する公衆衛生局及び開発委託先)はデータの取り扱いに対して適切に説明が求められることに加えて、データを管理するリスクに対処する必要があります。

GoogleやAppleがデータを取得しない場合でも、誰かが代わりにデータ取得者になる場合は説明責任の問題が発生すると考えられます。

データの管理権限と使用期限

スマホデバイスにデータが保有される設計となる場合、データ自体の管理権限の範囲がどこまで設計されるのかは大きなポイントになります。

例えば、"識別コードを個人で削除できるのかどうか" や "事前に同意を取得できていないケースでデータに関する請求が適切に行われるのか" などデータを提供する個人への権限とデータ取得者への義務に関しては大きな争点になると考えられます。

第三者的なプライバシーチェックの必要性

データプライバシーを重要視し過ぎる事でダウンロード数が想定より伸びず、本来目的とした感染拡大の防止に影響があってはならないと考えます。

一方で、有事の際は個人のデータを守ることよりもデータを活用していかに目的を達成するかに重きが置かれる事が多く(悪いというよりは過度に情報を要求される)有事が落ち着いてから問題になる事例もあります。

アメリカでも過去の教訓からデータプライバシーに関する議論はより高まってきており、第三者機関やメディアやソーシャルなどによるプライバシーチェックの機能が徐々に誕生してきています。

Zoomのプライバシー問題もこのような背景から発見に至り、セキュリティ含めた課題に対しての取組が始まるきっかけになっています。

ユースケースイメージ.007

GoogleとAppleの取り組みはこれからも改善されていくと考えられますが、適切にチェック機能が働いた上で取り組みを注力できると良いのではないかと考えます。

※一部法的な解釈を紹介していますが、個人の意見として書いているため法的なアドバイス、助言ではありません。

引き続きCOMEMO記事を読んで頂けると嬉しいです。

↓↓↓

記事の内容やブロックチェーン×データビジネスに関するご質問はこちらまで!!


ブロックチェーン技術は世界中の人たちが注目している新しいビジネスのタネの一つです!気になったら気軽にメッセージください!