機能停止版アプリへの、接触通知の発生状況に関する利用者調査の実装をすべきか

[daisuke-nogami]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

• COCOAの出した結果を定量的に把握するために必要な指標のうち「どの程度の利用者に接触通知という形で注意喚起を出来たのか」の測定は現在に至るまで行えていない
• v2.0.1以降で実装されたexposure_data.jsonを用いることで、当該ユーザのCOCOAが最大で何回接触通知を出したかを推定することができる
• 任意で協力いただける方に、COCOAの利用終了前にexposure_data.jsonを提供いただき、分析することで、接触通知がでた範囲・頻度を推定したい

関連Issue #1132

解決策についてお書きください / Describe the solution you'd like

機能停止版COCOAを用いて調査を実施する。

具体的には、機能停止版COCOAの停止処理の直後に、調査への任意での協力依頼を表示する。協力いただける方には、可能な範囲で提出者の属性もお答えいただき、exposure_data.jsonとともにサーバに送信する形式を取りたい。

本Issueでは、そもそもの是非や手段の選択肢（「代替案」の項で言及））について検討したい。

なお、これを実現するとすると、大きな課題が3点ほどあるため、別Issueで議論する。

1. 提供いただくexposure_data.jsonの期間（全期間 or 直近14日間）とその形式 接触通知の発生状況に関する利用者調査で送信するデータの期間と形式 #1141
2. 質問する「提出者の属性」（exposure_data.jsonと紐付けるか否かを含めて） 接触通知の発生状況に関する利用者調査で、利用者の属性を接触通知の発生情報と紐付けて取得するか・その属性はなにとするか #1143
3. exposure_data.jsonを提供いただくときの同意の流れ（プライバシーポリシー等に同意頂く範囲） 接触通知の発生状況に関する利用者調査時に用いるプライバシーポリシー #1142

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

• exposure_data.jsonをWebフォーム等の別の手段で提出する
  • 提出者の操作の負担が増え回収率が落ちること、重複回答や偽装データの提出がされうることから、提供いただくときにはCOCOAアプリから直接提供する形を取りたい
• exposure_data.jsonの収集を諦める

その他 / Additional context

• COCOAの振り返りで、利用者に対する調査を用いて調査すべき事項と、適切な手段は以下のように整理しているため、利用者に対するアンケート・意見の収集については、基本的には本Issueでは議論の対象外としたい

-	Process	Output	Outcome
意味	政策の進め方/過程	直接生み出される結果	社会に対する成果/効果
指標/測定内容	アプリ品質（ご意見・改善案、利用を止めた理由）、開発プロセス（Github活用も含む）	ダウンロード数、陽性登録件数、稼働台数（推計）、 通知発生回数 など	注意喚起効果（通知カバー率、行動変容率、喚起した行動の内容）、利用者のメリット
測定手法	アプリ利用者向けアンケートorヒアリング、関係者によるKPT	実績値の集計、 exposure_data.jsonの収集	調査パネルによるアンケート調査、報道内容・件数整理、SNS発言内容分析
メディア	メール and/or Webフォーム、行政内総括	システム運用業務、 機能停止版アプリ	外部調査会社パネル

[keiji]

「接触通知の発生状況（exposure_data.json）」と「提出者の属性」についてはIssueを分けるといいかなと思います。

とくに「接触通知の発生状況（exposure_data.json）」と「提出者の属性」をそれぞれ別個に（リンクせずに）収集するか。リンクして収集するのかでプライバシーへの影響度が変わってくると考えますので、この点も分けて検討していくのが良いと考えています。

「今後のために可能な限りデータをもらいたい」という気持ちはぼくも同じという前提で、利用者にお願いするに当たってクリアすべきポイントは、

• 利用者の負担にならないこと
• 提出に応じない選択がある（提出しなくても不利益がない）ことを明確に示すこと
• 利用者が、自分がどのような情報を提出しようとしているか具体的に知ることができること

くらいでしょうか（他にもあればご指摘ください）。

「こんな情報をとりたい！」「この情報があればこんなことが分析できる！」という合理的に必要性を伝えていくことも大切ですが「この内容だったら協力してもいいかな」と利用者に思ってもらえるような形を探していけるといいですね。

[daisuke-nogami]

今回のIssueでは、「接触通知の発生状況（exposure_data.json）」を取得する際に、「提出者の属性」をリンクさせて収集するかを問うIssueですので同じIssueで語っています。

一方、リンクさせずに「提出者の属性」だけを収集するのは、ユーザ全体に占める属性別のユーザ数の割合を知るのが目的になり、Additional Textに書いたOutcomeの調査の話になると自分は整理しています。
自分の中ではアプリ内でOutcomeを調査しない前提だったのでIssueを立てていませんでしたが、言われてみれば、Outcomeに相当する事項をアプリ内で聞くべきか、は、確かにIssueですので、その点のIssueを別に立てますね！

[keiji]

今回のIssueでは、「接触通知の発生状況（exposure_data.json）」を取得する際に、「提出者の属性」をリンクさせて収集するかを問うIssueですので同じIssueで語っています。

だとすると、「提出者の属性と接触データの関連付けの可否を検討」というタイトルにした方がよりわかりやすいと思いますがいかがですか。

いまのIssueだとタイトルが「実装」で終わっているので、見る人に実装することが決まっているような印象を与える可能性があります。

実装してもリリースしない。という可能性もあるのですが、どちらにせよ当該機能をリリースするかどうかも含めて「検討」段階にあることはタイトルで明示するのが良いと考えます。

[daisuke-nogami]

そうすると、解決策の中で語っている3つの課題を別々にIssueにした方がよかったですね（というか課題=Issueじゃん…）。接触通知の発生状況の把握自体の是非をこのIssueに残しつつ、把握を前提としたときに直面する論点を扱うIssueを分割しました！

[keiji]

調査検討（実装）にあたっての参考資料をこちらにも共有します。

Indicator framework to evaluate the public health effectiveness of digital proximity tracing solutions
https://www.ecdc.europa.eu/en/publications-data/indicator-framework-evaluate-public-health-effectiveness-digital-proximity

ECDC(European Centre for Disease Prevention and Control: 欧州疾病予防管理センター)と、WHO（World Health Organization: 世界保健機関）の本部・欧州地域事務局が共同開発したデジタル接触追跡の評価フレームワークです。

This indicator framework, developed by ECDC together with the World Health Organization (WHO) through its Headquarters and Regional Office for Europe (WHO/Europe), is intended for use by relevant national health authorities, public health and related institutions and their partners involved in the planning, implementation, monitoring and evaluation of contact tracing activities. It will be of most relevance to those with responsibility and oversight for the development and deployment of national digital proximity tracing solutions.

"4. Options for data collection" の冒頭にあるとおり、収集できるデータは各国の事情によって異なるという前提があります。
COCOAというコンテキストで、どのような形で情報を収集、分析していくか（どのような形であれば情報を収集、分析できるか）を決めることは独立して行うことになると考えます。

The capacity to collect data for each of the indicators in this framework may vary across countries due to differences in design architecture, integration of the overall surveillance and response strategy, and the local legal, privacy and governance context.
There is therefore variation in the type of data that can be collected and the sources they can be collected from (app controller, public health authorities, surveys, etc.).
Different options for data collection in the context of digital proximity tracing are listed below.

その上で、次世代の接触追跡（Contact Tracing）のデジタル化（計画は現時点で存在しない）を検討するにあたっては、効果指標の設定や必要な情報の検討をする上での参考にできると考えています。

[daisuke-nogami]

手前のコメントでの指摘（Issueのタイトルが調査を前提としている）への対応がもれていました。子Issueも含めて議論されている内容に合わせたタイトル修正をしました。

子Issueも踏まえて、調査を行うとしたときの調査概要を（子Issueでの整理も転記して）まとめました。

• 調査目的
  • どの程度の利用者に対して「接触通知」という注意喚起を行えたのかを回数として把握する
    • 集計・算出される回数の偏りをなくすため、COCOAの利用期間・（接触機会となる）通勤通学の有無によって収集したデータを区分して集計する
• 調査方式
  • 機能停止版アプリにおいて、機能が停止したことの告知の直後に、調査目的と協力の呼びかけを提示する
  • 協力いただける方に、回答者の属性と接触通知の発生状況データの送信可否を質問し、送信する画面を提示。送信処理が終わればアプリのデータを削除して機能停止とする
  • 協力いただけない方も、アプリのデータを削除して機能停止とする

接触通知の発生状況データの期間・内容
#1141 (comment)

• 送信期間：2022/03/24～送信日まで
• 送信データ形式
  • 案① 日次で、閾値を超えたか否かのみを取得
    • 日付, 閾値を超えたか否か, (属性を紐付ける場合は回答者属性)
  • 案② 日次で、閾値を超えたか否か・陽性登録者の信号を受信したか否かのみを取得
    • 日付, 閾値を超えたか否か, 陽性登録者の信号を受信したか否か, (属性を紐付ける場合は回答者属性)
  • 案③ 日次で、ENのスコア・総受信時間と、電波強度毎の接触時間の内容を取得　※exposure_data.jsonそのままに近い
    • 日付, ENスコア, 総受信時間, (属性を紐付ける場合は回答者属性), Exposure_Windowの内容{ CalibrationConfidence, MinAttenuationDb, SecondsSinceLastScan, TypicalAttenuationDb }
• 収集したデータを研究者等に開示するときには、一連のデータから、個別の端末ごとの接触した陽性者の人数などを特定できないような処理を加える（詳細はデータ形式による）

回答者の属性
#1143 (comment)
※目的に沿うためには案①ないし案②とすべき

• 利用者調査の項目
  • 案①：COCOAインストール日、定期的な通勤通学の有無、年代を、接触通知の発生情報と紐付けて取得する
  • 案②：COCOAインストール日、定期的な通勤通学の有無を、接触通知の発生情報と紐付けて取得する
  • 案③：定期的な通勤通学の有無、年代を、接触通知の発生情報と紐付けずに取得する
• 項目毎の詳細
  • COCOAインストール日
    • （アプリが内蔵している日付を初期値とし、修正することを許容する。無回答も可能にするのが望ましい）
  • 定期的な通勤通学の有無（定期的とは、週に1回以上の頻度のことを指します）
    • 通勤・通学をしていない / 公共交通機関（鉄道・電車・乗り合いバス）を利用せず通勤・通学をしている / 公共交通機関（鉄道・電車・乗り合いバス）を利用して通勤・通学をしている / 回答しない
  • 年代
    • 14歳以下 / 15-19歳 / 20-24歳 / 25-29歳 / 30-34歳 / 35-39歳 / 40-44歳 / 45-49歳 / 50-54歳 / 55-59歳 / 60-64歳 / 65-69歳 / 70歳以上 / 回答しない

[daisuke-nogami]

こちら、Github含めていろいろなところでの議論を踏まえて、

• 送信データ形式
  • 案② 日次で、閾値を超えたか否か・陽性登録者の信号を受信したか否かのみを取得
    • 日付, 閾値を超えたか否か, 陽性登録者の信号を受信したか否か, (属性を紐付ける場合は回答者属性)
• 利用者調査の項目
  • 案①：COCOAインストール日、定期的な通勤通学の有無、年代を、接触通知の発生情報と紐付けて取得する

という流れで、以下の様な画面設計でコードをフリーズさせてテストを進めております。

[daisuke-nogami]

調査が終了して、総括報告書で発生回数推計も公開することができましたのでCloseします。