接触確認アプリ「まもりあいJapan」の全体設計について
はじめまして。河津と申します。
普段はFintech企業のCTOとして金融システムのデザイン(企画/方式設計/技術採択)を生業としております。縁あって「まもりあいJapan」プロジェクトに参画させていただき、こちらでも企画/方式設計を担当しています。
この記事について
この記事では接触確認アプリとはどのようなもので、「まもりあいJapan」がどのような設計なのかをお伝えできればと思います。5月13日に開催させていただいた勉強会のアーカイブと合わせてご覧いただけますと幸いです。
接触確認 / コンタクトトレーシングとは何でしょうか
ウイルスは目に見えず、人知れず感染を広げます。感染拡大を食い止めるには早期に感染の可能性がある人物を特定する疫学調査と、そのプロセスの中で定義される一人ひとりの適切な行動が必要です。現在も多くの人が調査に奮闘し、また調査対象として調査に協力されています。
しかしながら、自分が陽性になった時、いつどこで誰と出会っていたのかをあますことなく回答できるでしょうか。調査の重要性は理解しつつも、記憶の曖昧さやプライバシー面の心理的なハードルが正確な回答を阻む可能性があります。
このハードルをクリアするひとつの方法として、IT技術で人と人との接触を検知/記録する仕組みが考案されました。スマートフォンのBluetooth機能を使った端末間のID交換を主体とした仕組みです。シンガポール政府が主導するアプリなどがモデルケースとして注目を集めています。
ID交換によって得られた接触記録と、利用者を特定する情報(位置情報や電話番号など)を組み合わせて疫学調査の有効性を高めるものがコンタクトトレーシングです。誰がリスクに晒されているのか、どこがクラスター源になっているのか、などを公衆衛生当局が把握し対策に繋げることを目的とします。
集権的にデータを管理し、公衆衛生当局から利用者へアプローチするケースが多く中央型などと表現されることもあります。
一方、集権的に管理するのではなく、データを基に利用者自身に自分の行動を判断してもらうアプローチもあります。接触記録はあくまで匿名で処理され、個人は特定できず、リスクの有無のみを利用者に伝え利用者が適切な行動を取れるように促す方法です。これを接触確認と呼びます。
あくまで利用者自身に判断を委ね、利用者が自分の意志で公衆衛生当局にアプローチするケースが多く分散型などと表現されることもあります。
どちらが正解、ということはありません。ウイルスとの戦いに必要なものを見定めて、国や地域の状況や特性に合わせて機能をデザインすることが必要です。
基本要素
基本的な要素としては上図の①-⑤の5要件です。
① スマートフォンを用いて人と人の接触を検知し、記録する機能
② 利用者から何らかのデータの提供を求める機能
③ 医療に関わる機関によりデータの妥当性/正当性が検証される機能
④ システムから利用者に何らかのデータを伝達する機能
⑤ データによって利用者が適切な行動を行える機能
どれだけの情報をどのように用いるのかによってその機能 (コンタクトトレーシング or 接触通知) もシステムデザインも異なり、バリエーションが生まれます。
ここでよく考えなければならない点が2つあります。
ひとつは導入障壁となる不安や疑問にわかりやすく丁寧かつ合理的な答えを出す必要があること。これは効果を最大化するためには多くの人に利用者となってもらう必要があり、利用者心理もさることながら社会全体としてこの取組に賛同してもらうことが必要です。安心できないデータの利用や、不透明な仕組みでそのような支援を得ることは困難です。
もうひとつはこのシステムを運用する側の負担を新たに増やさないこと。この取組はどのようなパターンであっても感染症に対応している公衆衛生当局 (医療機関/保健所/都道府県/厚生労働省)の参画なしに運用できるものではありません。非常に有用なシステムだったとしても、運用負荷が大きな新しいシステムを構築したのでは、日夜感染症対策に取り組んでいる公衆衛生の現場に新たな負荷が増えることになります。
「まもりあいJapan」のデザイン
「まもりあいJapan」でも様々なパターンを検討してきました。その結果、このプロジェクトでは匿名IDのみを使用する非常にプライバシーに配慮した設計をリファレンスモデルとして公開することと致しました。
① 人と人との接触検知は、アプリ内で一定時間ごとに再生成する匿名のIDを、端末間のBluetooth通信で交換することで実現します。一定時間ごとに変化する匿名のIDを、インターネットを介さない近接通信で交換し、交換した匿名IDは端末内のセキュアな区画にのみ保存します。どの匿名IDといつ出会っていたのかはスマートフォンアプリの外には出ない仕組みです。
②/③ データの提供と検証は、検査結果で陽性だと判定されたあとに、その方から同意を取得の上ご自身の匿名IDのみを提供いただきます。あくまで自分自身が生成した匿名IDのみのため、どのIDといつ接触していたのかというデータは一切開示されません。また医療機関から検査結果を通知する仕組みと連動することで、データの妥当性検証も合わせて実現する想定です。
④/⑤ 陽性になられた方の匿名IDを配信し、受信したスマートフォンアプリの中で照合処理を行います。もし自分のアプリが保存している匿名IDのなかに、受信した陽性の方の匿名IDが存在していたとすれば、それは陽性の方との濃厚接触の可能性があったことを示します。もしマッチしていたら「濃厚接触の可能性がある」とアプリの画面を通してお知らせします。照合の仕組はあくまでアプリの中で行われるため、その画面をみた本人が誰かに伝えない限り、誰にも知られることはありません。
全体の設計はこのような機能配置です。
この設計は個人情報を取得しないという選択をしたため、公衆衛生への貢献が、利用者へ届ける情報の内容やそれによる利用者自身による自発的な行動変容に依存することとなります。つまり、UIやUX、情報設計が非常に重要かつ難しいものになりました。どのように配慮して形にしていったのかはプロフェッショナルの言葉で感じていただきたいと思います。
この記事のおわりに
本記事は長くなりましたので、詳細はまた別の機会にさせていただきますが、設計を大きく左右する因子に以下のポイントがありました。
・日本全体の感染症対策に立ち向かう様々なシステムの中で、
接触確認/コンタクトトレーシングが果たすべき機能とは何か
・そのデータは誰のものか、どのような同意設計が必要か
・インターオペラビリティ (相互運用性) の考慮
・プラットフォーム(Apple/Google)の技術採択の是非
いずれも技術だけで解決できるものではなく、明確な答えがあるものでもなく、本プロジェクトチーム内での検討はもとより、自治体/医療機関/プライバシーやセキュリティ専門家の皆様/プラットフォーム開発者の皆様、など多くの方々にディスカッションに時間を割いていただき上記の設計にたどり着いたものです。この場を借りて深く御礼申し上げたいと思います。
日本における今後の取り組みは厚生労働省主幹で進められますので、最短でのリリースに向けてシビックテックの力で貢献させていただきたいと思います💪
この記事が気に入ったらサポートをしてみませんか？