【分かりやすく解説】コロナ接触確認アプリ “COCOA” のポイント

政府の「新型コロナウイルス感染症対策テックチーム」は、2020年5月26日、デジタル技術を使ったコロナ対策である接触確認アプリの「仕様書」を公開しました。これによって、6月中旬にリリース予定の、日本版接触確認アプリの仕組みの詳細が明らかになりました。
◆接触確認アプリ及び関連システム仕様書

あわせて、このアプリがプライバシーやセキュリティの観点から安全なものであるか、ユーザーの信頼獲得のためにどのような点に留意すべきかといった事項をまとめた、有識者検討会による「評価書」も公開されています。
◆「接触確認アプリ及び関連システム仕様書」に対するプライバシー及びセキュリティ上の評価及びシステム運用上の留意事項

本稿では、これらの文書で明らかにされた、日本版接触確認アプリの全体像とポイントをご紹介していきます。

※　本稿は筆者個人の見解であり、所属する組織や団体の見解を代表するものではありません。また、アプリに関する個人の意見を述べるものではなく、あくまで「仕様書」と「評価書」（2020年5月26日付）の内容とその背景を説明するものです。詳細を簡略化して説明していることから、正確な情報については仕様書と評価書の原文をご確認下さい。

１．接触確認アプリとは何か？

接触確認アプリとは、スマホ端末間のデータ通信技術（Bluetooth）を活用して、人と人との接触距離や接触時間を測定し、コロナウイルス陽性者と濃厚接触した可能性があるユーザーに通知を行うものです。

もともとは、シンガポール政府が"Trace Together"という名前のアプリを導入したのが始まりです。4月には、スマホOSの大手二社であるApple社とGoogle社が共同で、接触確認アプリ用のAPIを開発することを発表し、5月21日にそのAPIが公開されました。現在、世界各国の政府が、接触確認アプリの開発・導入に乗り出しています。

そもそも、この「接触確認」という用語ですが、当初シンガポールのアプリが開発された際には、"Contact Tracing"すなわち「接触"追跡"」アプリという呼び方が一般的でした。ただ、接触確認アプリは、必ずしもユーザーの行動を追跡するものではありません。後述のように、少なくとも日本のアプリは一切「追跡」を行うことはできないことから、接触追跡という単語はミスリーディングであり、日本版では「接触"確認"」という表現が使用されています。

※ なお、Apple及びGoogleが開発しているAPIについても、"Exposure Notification"（「曝露通知」）という用語が使われ、「追跡」という概念は出てきません（事実、両社は、本アプリをユーザーの行動追跡目的に利用することを禁止しています）。

２．接触確認アプリの類型

一口に接触確認アプリといっても、様々な類型があります。ここでは、2つの視点をご紹介します。

その視点とは、
（１）アプリが位置情報を取得するか？
（２）陽性者と接触者のマッチングを、サーバーで行うか端末で行うか？
というものです。

結論を先取りすると、日本版のアプリは、「位置情報を取得しない、端末マッチング型」です。

（１）位置情報

まず一つ目の論点は、「位置情報を取得するかどうか」。
上述のとおり、接触確認アプリは、基本的にはBluetoothのような端末間の通信を使います。ただこれだけだと、端末同士が"どこで"接触ししたのかはわかりません。そこで、スマホに搭載されたGPSなどによって、ユーザーの位置情報を取得することが考えられます。誰がいつどこにいたかという位置情報を、保健当局が取得できれば、陽性者の感染経路をかなり正確に特定ことができると考えられます。また、陽性者の行動履歴から、その近くにいた人を探し出し、アラートを出すこともできます。これは、感染経路の特定や感染リスクのある人の特定という観点からは、とても効果的だと思われます。

他方、国がユーザーの位置情報を取得することについては、プライバシーの観点から、大きな懸念が生じます。ユーザーがいつどこで誰と会っていたか、どういう場所に行ったかという情報を、国が把握してしまうこと、しかもそれが「コロナ感染症対策」という公益目的の名の下で行われることについては、多くのユーザーが抵抗をもつものと思われます。そのため、日本をはじめとする多くの国のアプリでは、こうした位置情報を取得しないこととしています。他方、インドやイスラエルでは、位置情報を活用したアプリの導入・開発が進められているようです。

（２） サーバーマッチング or 端末マッチング

二つ目の論点は、「陽性者と濃厚接触者とのマッチングをサーバーで行うか、端末で行うか」。これは(1)の点よりやや複雑です。

まず前提として、いずれの場合であっても、ユーザーは端末内で、「自分のユーザーID」と「自分が過去一定期間内（日本の場合14日以内）に濃厚接触したユーザーのIDのリスト（濃厚接触リスト）」をもっています。

※ なお、実際のアプリでは、これらのIDはランダムな文字列です。自分のIDは24時間に一度、他のユーザーとの接触時に交換されるIDは10分に一度、端末内で自動生成されることで、高度な匿名性を確保しています。

その上で、両者には、大まかに以下のような違いがあります。

①サーバーマッチング型
ユーザーが陽性判定を受けた場合、陽性者は、通知サーバーに対して、任意で「自分のユーザーID」と「濃厚接触リスト」を送信します。これらを受け取った通知サーバーは、その濃厚接触リストに含まれているIDの端末に対して、濃厚接触した旨の通知を送ります。

②端末マッチング型
ユーザーが陽性判定を受けた場合、陽性者は、通知サーバーに対して、任意で「自分のユーザーID」のみを送信します。通知サーバーは、その陽性者のIDを、全ユーザーのスマホに送信します。これによって、各ユーザのスマホ端末内で、「自分が陽性者と接触があったか」が確認されます。接触が確認された人（濃厚接触者）には、予め用意されていた通知メッセージが表示されます。

このように、単に陽性者との接触の有無をユーザーが把握するだけであれば、②のように各端末でマッチングを行うことで十分です。他方、①のように、通知サーバーでマッチングを行う場合には、どのIDとどのIDがマッチしたかを、アプリ運営者（通常は保健当局）が把握することができます。さらに、それぞれのIDに電話番号が紐づけられる場合には、保健当局が、どの電話番号とどの電話番号の人が接触したかを特定することができます。

実は、接触確認アプリの先駆けであるシンガポールでは、この「サーバーマッチング型＋電話番号取得」というモデルを採用しています。ここまでくると、保健当局は、濃厚接触者を電話番号レベルで特定して、直接電話をかけることもできます。シンガポールアプリが"Contact Tracing"（接触"追跡"）と表現されている背景には、このように実際に濃厚接触者を追跡可能という事情があるのです。

他方、日本では、このようなプライバシーリスクのある「サーバーマッチング型」ではなく、よりプライバシーリスクの少ない「端末マッチング」のモデルを採用しています。このモデルでは、アプリを運営する保健当局（厚生労働省）は、誰と誰が接触したかが"匿名IDレベルでも"わかりません。

３．日本版接触確認アプリの目的

それでは、このような日本版接触確認アプリは、何を目的としているのでしょうか。

仕様書の冒頭には、本アプリの目的として、以下のように記載されています。

利用者は、スマートフォンを活用して、①日常において自らの行動変容を意識できると共に、②互いに誰とどこで接触があったのかは分からないよう、プライバシー保護と本人同意を前提に、自らが陽性者と接触した情報について、通知を受けることが可能になる。
（利用者におけるメリット）
・利用について本人の同意のもと、自分が感染者と接触が確認された者かどうかを知ることができる
（公衆衛生当局、保健所等におけるメリット）
・個人が自らの行動変容を意識するとともに、接触確認後の適切な行動等を実施できることにより、感染拡大の防止につながる

このように、本アプリの目的は、あくまでも「ユーザーに陽性者との接触リスクを通知すること」であり、これによってユーザー自身の行動の変容を促すこととされています。

このほかに、接触確認アプリの目的としては、「保健当局が陽性者の感染経路を特定すること」や「濃厚接触者の疑いのある人を特定すること」といった要素も考えられます。しかし、これは、保健当局がユーザーの位置情報や電話番号を取得することによって実現されるものです。日本では、こうした個人を直接特定できるような情報をアプリで取得しないことから、濃厚接触者の追跡・特定といった目的は仕様書に記載されていないものと考えられます。

このように、濃厚接触者の行動変容を目的にするとするという方針は、Apple社とGoogle社が表明しているポリシーにも沿っています。両社のポリシーに沿った仕組みを導入することで、両社が開発する専用のAPIを利用することができ、バックグラウンドでも稼働する、消費電力を抑えられるというメリットを得ることができます。

5月20日現在、日本を含む22か国が、こうしたApple社とGoogle社の提供するAPIを利用したアプリを導入することを表明しています。

４．日本版接触確認アプリの仕組み

日本版アプリの仕組みの詳細は、「仕様書」のP.3以降に記載されています。以下では、仕様書P.5の図に基づいてご説明します。（※ この先、技術的な話が続きますので、プライバシーや安全性についてのみ知りたい方は、5.に飛んでいただければと思います。）

技術的な点も多く書かれていますが、ポイントは、すでに記載したような端末マッチングを行うシステムであるということです。

まず、上の＜通常時＞の図において、端末の中にある「日次キー」というのが、24時間に一度更新される「自分のユーザーID」です（TEK: Temporary Exposure Key）。次に、図の赤い矢印で示されているのが、交換用のIDである「接触符号」（RPI: Rolling Proximity Identifier）です。これは10分に一度更新され、接触符号から日次キーを計算することはできません。

あるユーザーが陽性だと判明し、その旨を任意でシステムに登録する場合には、下の＜陽性発覚時＞のフローのようになります。青字で書かれている「3.感染者報告」では、上述の日次キーと時刻の情報をもとに作成される「診断キー（Diagnosis Key）」が通知サーバーに送信されます。その後、その診断キーが、「4.感染者情報の取得」の矢印ように、通知サーバーから全ユーザーの端末に発信されます。通知を受けたユーザーの端末では、送られてきた診断キーと、端末に保管されている接触符号を照らし合わせ、一致があるかどうかを確認します。一致した場合には、濃厚接触のリスクありということですので、その旨のメッセージや、その後どのような行動をとるべきか、帰国者・接触者相談センターへの相談方法等が表示されます。

※　なお、ここで示されている「日次キー」「接触符号」「診断キー」といった識別子は、アプリのバックグラウンドで作成・交換・送信・照合されるものであり、ユーザーが直接確認することはできません。

さて、下の＜陽性発覚時＞の図の中で、これまでの説明に出てこなかったものとして、緑の字で記載された「処理番号」というものがあります。これは、「虚偽の陽性登録」を防ぐための仕組みです（誰もが勝手に「自分は陽性だ！」と登録できてしまうとすると、本アプリのシステムが機能しなくなってしまいます）。処理番号とは、PCR検査等によって陽性判定を受けた人に対し、厚労省のシステムが振り出す登録用の番号です。陽性者は、本アプリの感染者登録（＜陽性発覚時＞図の3.の矢印）を行うに先立ち、アプリ上でこの処理番号を入力する必要があります（図の2.の矢印）。これによって、真に陽性判定を受けた人だけが、アプリのシステムに登録できるようになっているのです。

５．プライバシー・セキュリティ上の評価

以上、日本版接触確認アプリの概要をご説明しましたが、結局のところプライバシーやセキュリティといった観点から問題はないのでしょうか。

この点については、プライバシー、セキュリティ、公衆衛生等の専門家等による「接触確認アプリに関する有識者検討会合」が、冒頭に紹介した「評価書」において、詳細な検討を加えています。

（１）プライバシー

評価書では、まず、本アプリに関して、個人情報保護に関する法律が適用されるかを検討しています。具体的には、①本アプリは国の機関である厚労省が運営するものなので、「行政機関の保有する個人情報の保護に関する法律」（以下、「行個法」）が適用されるか、また、②本アプリ開発の委託を受ける民間事業者に個人情報保護法が適用されるか、という観点から分析を行っています。ここでは詳細な議論は省きますが、結論として、少なくとも「処理番号」は行個法の「個人情報」に該当すること、システムの設計次第では「診断キー」も同法の個人情報となる場合があること、また、これらの情報について委託先事業者が個人情報保護法上の義務を負う場合があること等が示されました。

こうした検討を経た上で、「評価書」は、以下のように述べています。

本アプリは、ユーザーが陽性者や接触者であるかどうかという機微な情報を取り扱うものであり、その上で広くユーザーに信頼されるものである必要があることから、行個法及び個情法の適用関係にかかわらず、サービスの利用開始及び陽性者登録等の重要な局面において、ユーザーの同意を取得することを原則とすると共に、情報のライフサイクル（取得、保管、利用、移転、削除）の各過程において、プライバシーに対する十分な配慮がなされる必要がある。

すなわち、法令上の義務の有無にかかわらず、プライバシーに対して十分な配慮をすべきである、ということです。

その上で、評価書は、次のような理由で、仕様書を積極的に評価しています。

①アプリ利用開始時、及び陽性者が感染者システムへ登録する時という２つの重要局面で、ユーザーの同意の取得を求めていること。
②本アプリを通じて運営者やユーザーが取得する情報が、目的達成のために必要最小限といえること。
③通知サーバー及び端末の双方について、本アプリの運営上に必要と考えられるセキュリティ基準を満たすことが求められていること。
④不要となったプライバシー情報は速やかに削除するものとされていること。

さらに、運用に際しては、ユーザーに対してあらかじめ、プライバシー情報の利用目的や取扱方法等について十分な説明を尽くすべきことや、システム導入時の脆弱性検査を行うこと等を求めています。

（２）セキュリティ

本仕様書では、セキュリティ対策として、①「政府機関等の情報セキュリティ対策のための統一基準」に基づきセキュリティ対策を行うこと、及び②スマホのOSのセキュリティ機能を利活用することを要求しています。評価書は、これらが信頼のあるセキュリティ基準・機能であり、セキュリティ対策方針としては妥当であると評価する一方、実際に本アプリがこれらの基準を満たすかどうかについては、運用段階で適切に検証する必要があると指摘しています。

６．運用上の留意事項

続いて、評価書では、アプリの運用上特に留意すべき点として、(1) 透明性、(2) インクルーシブネス（包摂性）、(3) 使用目的の限定、(4) 検証、(5)調整事項に関する留意事項、という観点から検討を行っています。

（１）透明性については、本アプリに対する信頼を確保するために、①仕様書等を公開すること、及び②感染症対策全体の仕組みの中でのアプリの位置づけ、本アプリの仕組み及びプライバシー情報の取扱い等の事項についてユーザーにわかりやすく明示することが求められています。

（２）インクルーシブネス（包摂性）については、より多くのユーザーが本アプリを利用できるよう、①分かりやすいユーザーインターフェースとすること、②少なくとも英語など、多言語対応を行うこと、③16歳未満の者や成年被後見人など、自ら同意の判断を行うことが困難なユーザーについては、代理人が同意を与えることができるようにすること、④陽性者、接触者、その家族等が差別を受けないよう、本アプリのシステム全体の設計運用上、十分に配慮すること、⑤本アプリに関する苦情・相談のための窓口を設置すること、等が求められています。

（３）使用目的の限定については、①本アプリの運用で得られたデータを、本アプリの目的以外の一切の目的で使用しないこと、②コロナウィルス本感染症が終息した場合には、速やかに本アプリのサービス提供を停止すること、等が求められています。

（４）検証については、アプリ運営者が、仕様書や留意事項を遵守していることを自ら継続的に内部検証するとともに、中立かつ専門の有識者による検討会に報告し、その評価を受けること等が求められています。

最後に（５）調整事項に関する留意事項では、仕様書において今後の調整事項と記載された、「各端末内で全接触回数を記録し表示することを可能にする」という機能について、こうした機能はプライバシー上は問題がないが、具体的な仕様は現時点で不透明であることから、今後適時評価を行っていくことが必要であるとしています。

７．まとめ

このように、日本版の接触確認アプリは、「位置情報を取得しない、端末マッチング型」というプライバシーを重視した設計で、国家によるコントロールではなく、各ユーザーによる自主的な行動変容によって効果を発揮しようとするものといえます。

こうしたシステム設計について、有識者検討会は、プライバシー・セキュリティ上十分な配慮がなされていると評価した上で、透明性・インクルーシブネス（包摂性）・目的外利用の禁止・継続的な検証といった留意事項を守って運用することを求めています。こうした留意事項については、6月中旬のリリースに向けたシステム構築の中で、適切に達成されることが期待されます。

以上が仕様書及び評価書のポイントです。あくまで概説ですので、接触確認アプリに興味を持たれた方は、ぜひ仕様書と評価書の原文にあたってみていただければ幸いです。

接触確認アプリがコロナ感染症対策として有効に機能するかどうかは、どれだけ多くの方に本アプリをインストールしていただけるかにかかっています。本稿が、読者の皆様の接触確認アプリに対するご理解の参考となり、一人でも多くの方が、アプリの利用について前向きに考えていただけることを切に願っています。

【参考資料】
本アプリについては、以下のサイトにこれまでの議論の概要や関連資料が掲載されています。
◆第1回 接触確認アプリに関する有識者検討会合
◆第2回 接触確認アプリに関する有識者検討会合
◆仕様書・評価書