接触通知の発生状況に関する利用者調査で送信するデータの期間と形式

[daisuke-nogami]

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

前提（ #1138 ）

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

このデータ提供の依頼をするときの仕様の論点に関するIssueである。

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

提供いただくexposure_data.jsonの期間を全期間とするか、直近14日間とするかを決める必要がある。
本Issueでは全期間を提案したい。

COCOAは利用者のプライバシー保護のため、プライバシーポリシーにおいて、厚生労働省が取得する情報と、本人以外の利用者の端末に記録される情報は、14日間に限って利用することと定めている。
そして、15日以上経過した日次鍵・接触符号は無効化し、動作情報等は端末内からは削除することとし、そのようにアプリも実装されている（なお、動作情報等は、障害調査が終了するまではサーバ上で保持される）。

一方、exposure_data.jsonの出力機能は、もともとは利用者本人がCOCOAの動作状況や接触の詳細な状態を確認できるようにするために実装したものであり、厚生労働省や本人以外の利用者がexposure_data.jsonを取得しない前提であったため、v2.0.1（と予定していたv2.1.0の時点の）プライバシーポリシーに定義がされておらず※、現時点では一定期間が経過したデータを自動的に削除する処理も実装されていない。

調査を行う立場からは、exposure_data.json（と提出者の属性）だけでは、提出者や提出者が接触した陽性者を特定可能な情報は含まれてはいないこと、機能停止直前の14日間では陽性登録者が大きく減少していることが見込まれることから、可能であれば端末内に記録されている全期間（最長で2022年4月以降）の提供を受けられることが望ましい。

一方、他の情報が14日間で揃えられていること、exposure_data.jsonが、プライバシーポリシーに定める「動作情報」の定義の文言（ ''本アプリで実施した処理の内容、処理が行われた時刻、処理の成功/失敗、処理の実施にあたり参照した情報、処理の結果として出力した情報、実施時の状態等'' ）にも含まれると読めてしまうことを勘案すると、これも14日に絞るべきでは？という意見がでることも想定される。

※「動作情報」を取得する目的は「アプリ利用者から寄せられる本アプリの障害の可能性等に関する情報を元に、本アプリの改善のために必要な対処を速やかに行うため」と定義されており、アプリ内ではお問い合わせの際に送信する「動作情報」のことを示していることから、プライバシーポリシーの意図としてはexposure_data.jsonは「動作情報等」には含まれないと記載した。

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

提供期間を14日分に絞る。

その他 / Additional context

[kvaluation]

第1　参考になるかも知れないデータです。

1. 全期間の開始日
   遠距離信号のご報告の原データでは、
   遠距離の信号を接触判定および表示から除外することを検討する #1121
   2022年3月25日（DateMillisSinceEpoch が 1648166400000）
   が最も古い接触日でした。

2. アンケート開始時点との関係
   アンケート開始時点では、直近14日間ですと、診断キーが少なく、接触通知もほぼない可能性も想定されます。機能停止してアンケートを開始してから15日後に回答すると0件となりそうです。

3. 診断キー数の推移

・グラフの原データ
https://docs.google.com/spreadsheets/d/1CAAKjXHdeAQfPYngGA04mYq6x-E5wfBANTmvEH808yA/edit?usp=sharing

3.1 例えば、6/30までの3ヶ月と、配信の多い7/1から9/30の3ヶ月を比較したい、という分析を行うのであれば、4/1から直近までのExposureWindowのデータを送信して欲しい、という根拠になるかと思います。全件として3/25からでも誤差の範囲かと思われます。

3.2 ExposureWindowの実例を多数知りたい、ということであれば、7/1以後とすることも考えられます。

[kvaluation]

第2　意見です。

意見1　情報収集に際して、「データに基づく他者による決定（情報的他律）」がされず、その決定に従わなくて良い自由へのご配慮を、お願いします。

参考「情報的他律」
https://roppongi-kaigi.org/wp-content/uploads/2022/08/PERSONALDATA_GRK_20220809_DRAFT.pdf

情報提供者の個々人を特定して、どのような行動をすべきであった、等の決定をしないことはもちろん、プロファイリングによる評価が行政庁から公表されないように、ご配慮をお願いします。

例1　exposure.jsonを分析すると、同居者に陽性者があったか高い確率で推定できると思われます。そのような同居陽性者のあるのデータを集めて、「こうすべきであった」「公的な支援を減らす」などの自動的な決定をしないで欲しいです。

例2　特定の日に接触があり、他の日の接触は少ない、というデータを集めると、特定のイベントに参加したかどうか推定できる可能性があります。そのようなプロファイリングについて、浅い分析に基づいて、感染拡大をしたとか、注意不足だったなどという評判の流通に繋がる決定や情報発信は避けてください。メディアではスポーツイベントに比較して音楽イベントが悪玉にされやすい傾向があります。

例3　ExposureWindowsをデータの時系列で分析しすぎると、判定単位を1日としたGoogle | Appleの要件を超えた洞察を得てしまう可能性があります。ENを採用した経緯に応じて、また倫理的に、すべきでない分析をしないように、お願いします。

例4　14日間を超える期間を対象として、同一人（同一端末）であることを前提とする分析は、ENの14日間で接触履歴を削除する、という理念と整合しない可能性があるため、そのような分析や公表は避けることが望ましいです。
　統計的に、6月30日までに接触が記録されなかった端末で、7月から9月に接触が通知された比率は○%等、統計的で思慮深い分析と公表であれば、許容範囲はありえるとは思います。ただ、収集自体のバイアスが強く、ランダムサンプリングになり得ないため、何らかの指針の根拠とできるデータにはならないです。

例5　感染というセンシティブ情報であるため、2022年の技術や法制度を鑑みると、今回は、AIの教師データにしない、という規約での収集が望ましいと考えます。

意見２　収集期間について、選択肢をユーザーに提供する可能性もあるかと思います。アプリ終了日の直近14日間と、全期間の2種類など。

意見3　収集したデータの取り扱いについて、学識経験者、特に統計学の講義をしていらっしゃるような大学教授のレビューを頂くことが望ましいと思われます。
省庁の都合の良い公表をするためにデータを任意に抜き取っているかのような、疑いを生じさせない体制やプロセスの構築をお願いします。

意見4　収集するデータ原本は、公開しないことが望まれます。一方、研究者による研究目的で、機械学習ではない場合には、その学識経験者に利用頂けるようにすることが望ましいと考えます。

[keiji]

意見1について

情報収集に際して、「データに基づく他者による決定（情報的他律）」がされず、その決定に従わなくて良い自由へのご配慮を、お願いします。

例1　exposure.jsonを分析すると、同居者に陽性者があったか高い確率で推定できると思われます。そのような同居陽性者のあるのデータを集めて、「こうすべきであった」「公的な支援を減らす」などの自動的な決定をしないで欲しいです。

推定できないという理解です。
exposure_data.jsonには「そのデータが誰のものか」「接触した陽性者は誰か」という情報が含まれません（接触通知APIレベルで推定不可能という認識です）。

例2　特定の日に接触があり、他の日の接触は少ない、というデータを集めると、特定のイベントに参加したかどうか推定できる可能性があります。そのようなプロファイリングについて、浅い分析に基づいて、感染拡大をしたとか、注意不足だったなどという評判の流通に繋がる決定や情報発信は避けてください。メディアではスポーツイベントに比較して音楽イベントが悪玉にされやすい傾向があります。

exposure_data.jsonには、その人が誰かの情報はないので、そのデータが誰のものか、わからない状態です。
一方、イベントA, イベントB, イベントCなどのように複数の大型イベントがあり、その日に接触の記録があるデータがあった場合、その3つのイベントに参加した人が1人しか居ない場合は、推定が可能になる可能性はないとは言えないよね。と、思います。

例3　ExposureWindowsをデータの時系列で分析しすぎると、判定単位を1日としたGoogle | Appleの要件を超えた洞察を得てしまう可能性があります。ENを採用した経緯に応じて、また倫理的に、すべきでない分析をしないように、お願いします。

要件を超えた洞察とは、たとえばどんなものが考えられるでしょうか。倫理的にすべきでない分析とはどのようなものでしょうか。「倫理的にすべきでない分析をすべきでない」というのは合意するところなのですが、いまいち捉えどころが無い意見だなと思います。exposure_data.jsonに含まれている範囲で、もう少し具体的に例を挙げていただけるとありがたいです。

例4　14日間を超える期間を対象として、同一人（同一端末）であることを前提とする分析は、ENの14日間で接触履歴を削除する、という理念と整合しない可能性があるため、そのような分析や公表は避けることが望ましいです。
　統計的に、6月30日までに接触が記録されなかった端末で、7月から9月に接触が通知された比率は○%等、統計的で思慮深い分析と公表であれば、許容範囲はありえるとは思います。ただ、収集自体のバイアスが強く、ランダムサンプリングになり得ないため、何らかの指針の根拠とできるデータにはならないです。

承りました。ENの理念はCOOCAの理念でもあります。データの送信自体を行わない選択肢は常にあります。

例5　感染というセンシティブ情報であるため、2022年の技術や法制度を鑑みると、今回は、AIの教師データにしない、という規約での収集が望ましいと考えます。

機械学習の教師データにするという話は出てきていません。多分それをする人は機械学習のことを知らない人だと思うので、あかんで（使い物にならないよ）って言いますね。

意見2

意見２　収集期間について、選択肢をユーザーに提供する可能性もあるかと思います。アプリ終了日の直近14日間と、全期間の2種類など。

これは技術的な側面ですが、14日間に限定して送信する場合はデータとしての実効性がないので、そうであるならば「送信しない」という選択が良いと思います。

意見3

意見3　収集したデータの取り扱いについて、学識経験者、特に統計学の講義をしていらっしゃるような大学教授のレビューを頂くことが望ましいと思われます。
省庁の都合の良い公表をするためにデータを任意に抜き取っているかのような、疑いを生じさせない体制やプロセスの構築をお願いします。

承りました。むしろ取り扱い方法や過程についてもきちんと公開しなさいよと。
それくらいやらないと駄目ですね。

意見4

意見4　収集するデータ原本は、公開しないことが望まれます。一方、研究者による研究目的で、機械学習ではない場合には、その学識経験者に利用頂けるようにすることが望ましいと考えます。

これは前段の「公開しないことが望まれます」について、なにか理由とか有るのでしょうか。

元データがあると誰かが「倫理的にすべきでない分析」ができる可能性があるから……ということでしょうか。@kvaluation さんのご指摘、ここがすごくふんわりしていて意図が掴みきれないでいます。

[kvaluation]

ありがとうございます。

例えば、こちらの06Aさんと13Gさんは同居の方が陽性登録なさっています。
#1121
遠距離を含む接触時間が16時間を超える日が連続しているかどうかは、exposure_data.jsonから判りますし、その場合、同居の方の陽性登録の確率がとても高いです。壁越しの住まいの近隣者の可能性もありますが。
EN1のときは、同居者の陽性登録では、一致したキーの数が毎日1件でていました。

イベントは、フジロックとかコミケなどです。意図的に特定のイベントの状況を調べるようなことをしないでいただきたいという意見です。

時系列は、すみません、TwitterでDMします。心配しすぎなだけだと思います。ご放念いただけたら。

非公開は、14日以上のデータは削除されることになっているので、全期間で公開するのはENの理念に反する結果をもたらしかねない、という懸念です。

全期間でデータを集めて分析していただくのは、賛成しています。

[daisuke-nogami]

意見1の例2、特定の種類のイベントを特定できないようにすべき、という点ですが、日本全体では年に1000件以上のコンサート、2000件以上のスポーツ興行が行われていること（source: 2020年イベント産業規模推計）、イベント時間の長さ（e.g. 120分など）に相当する濃厚接触も決して稀ではない（私も、つい昨日、150分の濃厚接触通知を受けましたが、イベント等に参加していない日の通知でした）ことから、真面目に考えれば、長時間の接触がある日の組み合わせで行動を特定しようとは考えないとは思います。

ただ、そのようなミスリーディングな邪推をされないように、という観点で生データの公開範囲を絞りたい、ということで意見4が出たのかと思いましたが…

意見1の例4のような懸念が出る点については、意見3と組み合わせて、
「当初はこのような統計的数値を算出するのみに用いる。それ以上の分析は有識者のレビューを踏まえて行う」
というような見せ方も1つあるのかなと思いました。

ちなみに、Issueを作った時点で自分が想定していた統計は、発言力のある層で「自分の端末には通知が来たことがないので動作していない」と思われる方が少なくないこと、国外事例との比較で「通知が出すぎているのではないか」という意見がでる可能性が高いことを踏まえ、イメージだけで語られないようにするために、

• 「濃厚接触の可能性通知」が出た台数（日次）
• データを送信いただけて集計対象となった台数（日次）
• 通知には至らなかったが陽性登録者の信号を受信した台数（日次）
• 上記データを、「通勤通学をしていない」「通勤通学を公共交通機関を利用せずしている」「通勤通学を公共交通機関を利用している」別に分解したもの

というものを想定していました（最後の分解は、サンプルの性質に対する指摘があるだろう、という想定）。

[daisuke-nogami]

なお、

遠距離信号のご報告の原データでは、
#1121
2022年3月25日（DateMillisSinceEpoch が 1648166400000）
が最も古い接触日でした。

この共有で気づきましたが、v2.0.0のβ版を利用している場合には、より古い時期のデータも送信できてしまうので、時期によってはβ版を使用していたのが数名などに限られて、個人を特定できてしまう可能性がありますね…（私の端末の片方では1月末からデータがあります）

その点で、データを受信したあとに、v2.0.0のリリース日以前のデータは削除する必要がありそうです。

[kvaluation]

「意見4　収集するデータ原本は、公開しないことが望まれます」について、DMの対話により「下記のような加工データなら公開に反対しない」と、考えを改めましたので、ご報告します。

ExposureWindowは1名に1つ30分までと定義にあります。このアンケートで収集される全データが公開されることで、自分や家族のデータを分析しているだけでは判らない陽性者さんの行動が、「日単位」よりも詳細に判ってしまう可能性を懸念しています。

せっかく守られている陽性者さんの人数やプライバシーが「日単位」以上に暴かれてしまい、犯人捜しにexposure_data.jsonが使われる風潮となることは、私は、避けたいです。

データ原本の公開については、ExposureWindowsの情報を削除し、つまり、ScanInstancesがどのExposureWindowに属していたか判らないようにして、かつ、ランダムに並べ替えるか、TypicalAttenuationDbで並べ替えるような加工をしていただけたら、公開に問題がないと、考えます。

接触通知があった場合、ScanInstancesのSecondsSinceLastScanを合計すれば通知した接触時間と等しくなるので、日単位の接触の内訳として良質で、それ以上の陽性者さんの人数や行動に関する情報は提示しない粒度と思います。

特に、ScanInstancesのランダムな羅列から接触した陽性者さんの人数を推定することはおそらくできない（接触時間が24時間を超えたら2人以上のはず、程度）ので、私としては、この加工をしたデータを公開しても、陽性者さんのプライバシーをENの当初から想定している範囲にとどめることができると考えます。

[daisuke-nogami]

いったん、ここまでの議論を踏まえて、どういう案が俎上に残っているかの整理をさせてください。
特に問題提起・代替案が出ていないところは案を分けていないですが、一方、並行しているIssueも踏まえて案が幾つかあるところは、本Issueのコメントになかった部分も追記しています。

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

[keiji]

連休中考えて、やはり「14日前の接触データは取得しない方が良い」に傾いています。
そうなると、機能停止版が配信されるのは全数把握が終了して14日以上経過してからでしょうから「接触データの取得そのものをしない方が良い」が現時点のぼくの考えです。

「14日前の接触データは取得しない方が良い」と思う理由は、14日より前のデータが端末内に存在することは本来、利用者の期待する動作とは異なるものだからです。

利用者目線で考えたとき、期待するCOCOAの挙動は14日前の接触データは消えていくこと。です。
初期設計時にCOCOA内の接触データは14日を超えても消えないようになっていて、それを「表示しないようにする」ことで手当てしました。現在のバージョンでは14日より前の接触データは削除される。と、外形上はそういう動きになっていると考えます。

接触データをエクスポートして解析してみた人なら、データがすべて残っていることは知っているでしょうが、それも自分の端末内のみにあって、どこにも送信されていないから許容されているだけという認識です。

端末内に留めておくだけならまだしも、それを送信することは、ぼくが何も知らない利用者であれば、やはりいい気持ちにはならないだろうなと思います。「消えているはずなのに消えていなかった！」という不満につながる可能性があります。

さらに一度送ってしまうと仕組み上、申請による消去ができません（誰から送られたデータなのかを記録しないため）。
リカバーの手段がないのも、利用者にとって大きな不満になると考えます（「間違って送ってしまったので、自分の分を消してください」と問い合わせが来る）。

運用期間中、どのような接触が発生していたのかデータが欲しいという気持ちは依然としてぼくの中にもあります。
一方、COCOAの作られた経緯や、利用者が期待する挙動を考えるとやはり現状では接触データの送信は難しく、今後の課題として総括に含めると言う取り扱いにするのが良いと考えていますが、いかがでしょうか。

[kvaluation]

機能停止版の配信時期と分離して、早めに、exposure_data.jsonを送信できるサイトなどご用意頂いて、手順をご案内できれば、数千件から数万件は集まるような気がします。
exposure_data.jsonは全期間で送ってもらって、ゆっくりと14日以内のみ残す（読み出す）コードを作って頂いて、解析いただくなどが考えられます。他の質問と関連させての送信は日程的に難しくなりそうですが。

[daisuke-nogami]

有山さん、丁寧にありがとうございます。

おっしゃる通り、最初の「ざっくりとした説明から受けるユーザのデータ保持期間に関する理解」と齟齬があることは当初より理解しており、その点では当初から調査自体の課題が多いことは承知の上での提案でしたが、改めて、この調査をするとしたら、当初の認識と異なる扱いを受けうることに対して「行政としての明確な意思であることを強く明示すること」が必要条件であることは、改めて強く認識しました。

一方、背景にあるプライバシーの保護／ユーザの取り扱いの観点からは、必ずしも「全てのデータを14日経過したら "削除" する」ことを必要とせず（「無効化」で済ませているものもあるとおり）、また、そもそもの当初からCOCOAを（処理件数が伸びず通知も出ず状況もクローズドで分からない中で）使い続けた方々というのは、その取り組みから何かを得ることを期待しているので、取り組みの実績を得る努力をしないで「意味のない取り組みだった」と総括することが、その気持ちに添う意思決定なのかというと、私個人としては思えません。

いずれにせよ、（取り下げるならここで取り下げると言えば済むだけですので）実行するとしたらGithubだけで意思決定できるものではなく、

• 行政としてのCOCOAの活用状況の検証に対する強い意志（説明を果たした上で、当初の説明にないことをすることの説明）
• 個人情報保護委員会ないし相当する組織で、この取り扱いに問題がないかどうかの確認
• ENを利用するアプリの配信を許諾するGoogle/Apple両社による、この取り扱いに対する問題がないかどうかの確認

は踏まえねばなりません。これらに対して順次諮ることは進めねばならないと考えます（特に1点目の行政としての検証の意思）。

[keiji]

「総括にあたって必要なデータを集める」と言う観点で接触データを収集したい。と考えている動機が行政にある点はぼくも理解しています。ぼくの作成した停止計画の素案でも「可能であれば利用者の合意を得た上で接触データを集める」というプランであった事も事実です。

その上で、開発に携わっている者として、またCOCOAの利用者として「ユーザーのプライバシーに配慮して、一切のデータを取らない」と言う触れ込みでインストールをお願いしている事実はとても大きいと感じています（これが翻意した主要な理由の1つです）。

• 利用者に明示的な合意を得ればOK？（利用者は自分が何をしようとしているのか理解できる？
• 利用者の明示的な合意があれば、利用者が想定していなかった期間のデータを収集するのはOK？（利用者は自分が何をしようとしているのか理解できる？

特に14日より前のデータを送信することについて利用者に理解を求めるのは、利用者の認識を180度とまでは言いませんが、90度くらいは変えていただく必要がありますし「COCOAにだまされた！」という声が出るリスクを行政として取りますか。と言う話なのです。

「行政としての明確な意思であることを強く明示すること」

多分ここがもっとも重要な点で、このGitHubだけ見ると、野上さんがこのプランを推しているように見えてしまっている現状があると考えています。冒頭に「動機が行政にある」と書いたとおり、野上さんが一人でやっていることではない。

その上で、実行にあたっては野上さん自身のリスクヘッジは重要で「行政としての判断」であることを明示する。そのために「行政内できちんと話を通して、意思決定したことを明示する」をポイントとしておいた方が良いと考えています。

---

もう一つ、アプリエンジニアとしての総括という意味では「取るべきデータはきちんと取らないと、まともにアプリやサービスの分析や改善ができませんよ」が1つの重要な反省点になると考えています。

「初期の段階で、どのようなデータを集めて何に活かすのかを計画し、利用者に合意を得ておかなかったために、後からのデータ収集が難しく、データ分析的な側面では何もできなかった」
「今後、アプリをリリースするときには、初期段階でデータ収集と利用についても検討して、利用者にきちんと説明をして合意を得る必要がある」

その視点で見ると、
「プライバシーに配慮するために一切のデータを取得していなかったが、最後に利用者の明確な合意を得てデータを収集した」
「14日前のデータも保存されていたので収集できた。利用者の明確な合意を得れば問題ない整理になった」
の流れは、誤った成功体験として受け取られないように十分な配慮が必要と考えています。

[keiji]

@kvaluation

機能停止版の配信時期と分離して、早めに、exposure_data.jsonを送信できるサイトなどご用意頂いて、手順をご案内できれば、数千件から数万件は集まるような気がします。

これについては、COCOAから取り出した（ENが記録した） exposure_data.json であることをどうやって確認するかという話があります。
（COCOAから送信すれば、Attestation APIやDeviceCheck APIでサーバー側で検証できます）

もちろん、気にしないという選択も有りと言えば有りなのですが…

[daisuke-nogami]

このGitHubだけ見ると、野上さんがこのプランを推しているように見えてしまっている
（略）
「行政内できちんと話を通して、意思決定したことを明示する」をポイントとしておいた方が良いと考えています。

はい。おっしゃるとおりです。

先のpostでは意図的に「個人の考え」という部分を強く出したのは、行政側で、データ取得に関する課題を解像度高く理解しているかどうかを常勤の行政職員ではない私が述べることはできませんので、私個人が理解をしたという発言が、行政側の発言でないことを明示することにありました。

「14日前のデータも保存されていたので収集できた。利用者の明確な合意を得れば問題ない整理になった」
の流れは、誤った成功体験として受け取られないように十分な配慮が必要

こちらも十分に理解して判断をサポートして参ります。

====

なお、集めるとしたときに、そのデータの真正性に疑念を抱かれたり、あるいは、偽のアンケートサイト等が立ち上がってexposure_data.jsonが収集されることを避けるためには、データ収集はアプリから直接送信することは、調査の前提として考えております。

[daisuke-nogami]

他のpull-requestについて、
#1170 (comment)

送信データの内容について、手前のコメントであげた3案のうち
#1141 (comment)
少なくとも案③にはするべきではないだろうと判断をしています、という補足をします。

[kvaluation]

送信データの内容について、手前のコメントであげた3案のうち
#1141 (comment)
少なくとも案③にはするべきではないだろうと判断をしています、という補足をします。

ありがとうございます。

送信期間：2022/03/24～送信日まで　案① 日次で、日付, 閾値を超えたか否か

等となる際に、

1. 14日以前のデータが残っていること。
2. 日付としきい値を超えたか否かのデータを送信することで何らかの協力ができること。
3. 任意であること。
4. 送信又は送信しないことによる不利益がないこと。
5. 個人を識別できる情報が含まれないこと。
6. 取得したデータが公開される範囲や公開のイメージ図

など、アプリで表示して同意を得る部分と、Webページなどで案内する部分など、可能であれば、事前に公表いただいて、意見を求めていただけたらと考えます。

[daisuke-nogami]

ありがとうございます。

1. ～ 5.に関してはアプリ内でも提示すべきと考え、たたき台を作っている段階です。
   （ただし、長文になってしまっているので、そのまま貼るべきかどうか少し検討中です、が、利用者目線でのコメントは、是非いただきたいとは考えています、表現に対するご意見を全て取りこめるとは限りませんが…）

6 は作業段階では考慮できていませんでしたが、Webページで案内するイメージを持ちました。
確かに図示がある方が分かりやすいですから、こちらも検討進めてまいります。

[daisuke-nogami]

↑のコメント、6.と書いた部分が順序箇条書きで2.と表示されていたのを直しました…

たたき台、まだ長文なのですが（有識者の方にご相談のメールをしているあいだ寝かせていた）、自分でもどこをどう変更したか差分を分かるようにせねばとgist化したのでこちらにも共有します。
https://gist.github.com/daisuke-nogami/44bb347f9f5bd8c8ad7b4d4efd44f000
伝えるべき内容を「自分がしゃべるとしたら」という前提で書き下したので、全然アプリ向きじゃないボリュームです。
まだ文言で直すべきところがある状態ですが、そもそもの抜けがあると困るので貼り付けてみます。

[kvaluation]

こちらに直接コメントしてみました。
https://gist.github.com/daisuke-nogami/44bb347f9f5bd8c8ad7b4d4efd44f000?permalink_comment_id=4340551#gistcomment-4340551

[daisuke-nogami]

直接のコメントありがとうございます。更新しました！

[daisuke-nogami]

現状を親Issueに貼りました。

#1138 (comment)

[daisuke-nogami]

調査が終了して、総括報告書で発生回数推計も公開することができましたが、もう少し詳細な集計を公開できるよう調整いただいているので、その集計が公開できたらCloseします。

[daisuke-nogami]

発生回数に関する細かめの集計を含んだExcelの公開が出来たのでCloseします。
https://www.digital.go.jp/policies/cocoa/