EN v2を搭載するCOCOAで実現したい機能について

[daisuke-nogami]

#334 では、EN v2対応の技術要件について議論いただいておりましたが、EN v2に差し替えただけではEN v2の新機能が活用できず勿体ないことになります。
ということで、EN v2を搭載したCOCOAで実現したい機能についても考えているのですが、以下5点ほどについて、コミュニティ上でもご意見をいただけるとありがたいと思っている次第です。
（これは公式なパブリックコメントに類するものではなく、純粋に私がコミュニティのみなさまの知恵をお借りしたいと思って投稿するものです）

• 「積極的疫学調査実施要領」に示されている濃厚接触の条件をより広くカバー出来るようなパラメータ設計と、それに応じた接触発生時の通知内容のカスタマイズ EN v2を搭載するCOCOAで実現したい機能について #532 (comment)
• 接触通知が出なかった場合も含めた、接触状況を知らせる定期的な通知の追加 EN v2を搭載するCOCOAで実現したい機能について #532 (comment)
• 接触通知の発生状況を把握するための、ログ自動送信による接触通知が出た回数の集計（プライバシーポリシー等で同意取得をすることは前提） EN v2を搭載するCOCOAで実現したい機能について #532 (comment)
• 接触通知の改善や、感染拡大防止に資する調査研究のための、接触通知が出たときのExposureWindowの収集（オプトイン形式） EN v2を搭載するCOCOAで実現したい機能について #532 (comment)
• 接触通知の改善や、感染拡大防止に資する調査研究のための、接触通知の発生状況に対するフラグ付け（地域等） EN v2を搭載するCOCOAで実現したい機能について #532 (comment)

※ちなみに、単純にEN v2に置き換えるだけのCOCOAでも、接触判定をするときの時間は、連続◯分から合計◯分になるので、それだけでも接触を拾いやすくなるという利点はあると思いますが…

[daisuke-nogami]

「積極的疫学調査実施要領」に示されている濃厚接触の条件をより広くカバー出来るようなパラメータ設計と、それに応じた接触発生時の通知内容のカスタマイズ

EN v2ではパラメータ設計を工夫することで、3種類程度の濃厚接触の条件を判定できるようになる。

現在、COCOAでは「1m以内・15分以上」という濃厚接触の可能性を判断する条件の中で最も有名なものだけを対象としているが、他にも以下のような条件があり、COCOAの判定条件に追加しうる条件が2種類ある。

条件	COCOA判定条件への読み替え
① 同居家族【感染予防策の有無を問わない】	同じ室内・2時間以上 ... (c)
② 長時間の接触（車内、航空機内等を含む）【感染予防策の有無を問わない】	同じ室内・2時間以上 ... (c)
③ 診察、看護もしくは介護【感染予防策を取っていない場合のみ】	1m以内・15分以上 ... (a)
④ 1m以内で15分以上の接触【感染予防策を取っていない場合のみ】	1m以内・15分以上 ... (a)
④' 国内線機内で2m以内に搭乗【感染予防策を取っていない場合のみ】	2m以内・30分以上 ... (b)

※実際に実装するときには、条件の読み替えについては、公衆衛生の専門家のレビューを受ける必要があるので、読み替えの正しさについては議論の対象外

読み替えた条件だけを抽出すると以下の3つ。

a. 1m以内・15分以上【既存】
b. 2m以内・30分以上【新規】…国内線機内には、どんなに短くても30分程度は着席していると考えて時間を設定
c. 同じ室内・2時間以上【新規】…壁を挟んだ接触は流石にリスクはないと考える。2時間は暫定的なものだが、長時間という意味合い。壁とは、一般的な木造建物を前提とする。

この3条件のいずれかの条件に合致する接触があった場合には通知を出すようにしよう、というもの。

加えて、このうち、a., b.と、c.では接触通知のメッセージを変えてはどうかと考えている。

理由は、

• c. については「マスクをしていたり非常に広い部屋にいるからリスクが低いのではないか、やり過ぎではないか」という意見がでることも考え得ること
• 壁の種類（e.g. 隙間がないビニールなど）によっては、設定する閾値より強い電波強度となって、実際に「壁を挟んでいるが通知される（≒誤報）」こともあり得ること
  の2点。

※b.については、a.と同様にリスクが高いことは理解しやすいので問題はないだろうと考える

具体的には、a., b.の場合は現状と同じような、PCR検査等を促すメッセージを出し、c.の場合には、飲食等のリスクの高い行動を避けるという注意喚起に止める、というイメージ。
こちらのメッセージ内容についても、最終的には公衆衛生の専門家のレビューにより意思決定をしていくが、一利用者としてどう感じるかを知りたいと考えている。

[daisuke-nogami]

通知メッセージを変えることについて、Github外でも議論を行ったところ、

• COCOAが通知を出すことは、リスクが大きいという強いメッセージと受け止められうるため、c.のような濃厚接触の可能性が低くなりうるものは通知を出さないのが望ましいのではないか
• 結果として、通知を出す接触が濃厚接触の可能性が高い接触（a., b.）に限られるのであれば、いずれの通知でも検査を促すべきではないか
• もし、いずれの種類の通知でも検査を促すのだとしたら、促す行動が同じならメッセージの出し分けの必要性は低いのではないか
  という意見があり、この機能は優先順位が低いのではないかと考えていた。

一方、直近のオミクロン株への対応では、「濃厚接触者にあたる可能性は低いが検査を促す」対象が時限的に追加された（後述1）。この区分は、COCOAの通知が出た方に対して行政検査を行う根拠である 「③当該感染症の疑似症患者」又は「④当該感染症にかかっていると疑うに足りる正当な理由のある者」 という区分（後述2）と同じような区分と考えられるが、これまでCOCOAは「濃厚接触にあたる可能性があるため」という理由で通知をだしていたため、オミクロン株への対応のような理由でc.の接触にも通知を出すときには、その理由を出し分けできる方が望ましい。

そのような背景においては、 #646 "接触通知を発生させるリスクスコアの閾値を変更しやすくする" において複数の閾値を設定できるようにし、メッセージの出し分けを迅速に可能にする準備を進めておくことも検討する。

※後述1
令和3年12月27日事務連絡
「B.1.1.529 系統（オミクロン株）が確定又は L452R 変異株 PCR 検査陰性が確認された患者に係る濃厚接触者等の取扱いについて」
https://www.mhlw.go.jp/content/000874549.pdf

以下の①から④までに該当する者であって、３の濃厚接触者に該当しない者について、更なる科学的知見が得られるまでの間の当面の対応として、検査を行うとともに、14 日間の不特定多数との接触自粛を呼びかけていただくよう、お願いします。

①B.1.1.529 系統（オミクロン株）であることが確定した検査陽性者（②～④において「感染者」という。）からの物理的な距離が近い（日常的に滞在する部屋が同一、座席が近いなど）者
②物理的な距離が離れていても感染者と接触頻度が高い者
③寮などで感染者と食事の場や洗面浴室等の場を共有する生活を送っている者
④換気が不十分、三つの密、共用設備（食堂、休憩室、更衣室、喫煙室など）の感染対策が不十分などの環境で感染者と接触した者
※ 法第 15 条に基づく調査として、SARS-CoV-2 に対する核酸増幅法等の検査を行うことを想定しています。

※後述2
令和3年3月8日事務連絡
「新型コロナウイルス感染症に係る行政検査に関するＱ＆Ａについて（その４）」
https://www.mhlw.go.jp/content/000750111.pdf

９ 新型コロナウイルス接触確認アプリ（COCOA）の利用者のうち、新型コロナウイルス感染症の陽性者と接触した可能性があると通知を受けた者については、行政検査の対象者となるのか。

（答）
○ 新型コロナウイルス接触確認アプリ（COCOA）の利用者のうち、新型コロナウイルス感染症の陽性者と接触した可能性があると通知を受けた者に検査を行う場合は、問１で記載されている「③当該感染症の疑似症患者」又は「④当該感染症にかかっていると疑うに足りる正当な理由のある者」として、行政検査の対象者とし、当該検査費用の負担を本人に求めないものとしております。
○ なお、疑似症患者又は無症状の濃厚接触者に当たると保健所長が判断した者を除き、新型コロナウイルス接触確認アプリ（COCOA）で通知を受けた者に対する行政検査は、濃厚接触者に対する検査とは別のものとして行うのであり、検査対象者は濃厚接触者として取り扱うことはしないこと（14 日間の健康観察の対象とはしない）としております。

[kvaluation]

GitHub内外の対話をつないでいただき、ありがとうございます。

もう一つの視点として、感染拡大期、まん延期と収束期で、PCR検査のニーズが異なってくることが想定されます。

COCOAは人手によらないテクノロジーで接触を自動追跡できますので、感染の収束期に幅広く接触者の感染をPCR検査で確認したいときには、cやさらに低リスクの接触者についても、PCR検査を促したい都道府県もあるかと思います。

まん延期には、正直、PCR検査体制や保護隔離のキャパシティーも超過した自宅待機の発生により、自宅死もありました。その状態では、保健所のリソースを自宅待機者のケアにまわし、aなどは、PCR検査をせずに、一定期間の自宅待機や会食等の自粛をうながして欲しいと私個人としては考えます。都道府県ごとに、陽性確認者の追跡を断念せざるを得ない時期に、COCOAのaの接触者へのPCR検査なしの自粛をうながすようなイメージです。

感染拡大期には、クラスターの有無、変異株の浸透、人流、市中感染の有無、感染者の年代層などで、都道府県の保健所等の体制に応じて最適な対策が異なってくることが想定でき、一律のルールを予め定めておくことは才気と指導力あふれる厚生労働省殿をもってしても不確実性が大きいのではないでしょうか。オブジェクト指向のカプセル化やポリモーフィズム、API化のような発想で、接触の意味（リスク毎の接触通知を受信した人に推奨する行動）を柔軟に変更できるようにしておけたら理想かと思われます。

[kvaluation]

国内線機内で2m以内に搭乗
機内モードにするとBluetoothがオフになるので、30分の着席をとらえられない可能性があります。新幹線ですと検出できますが。

音楽系、映画その他映像系のイベントでCOCOAを推奨しつつ、「携帯電話の電源をお切りください」としていたところもありました。どう使ってもらいたいか、引き続きの情報発信やコミュニケーションも必要と思います。

c飲食等のリスクの高い行動を避けるという注意喚起
イベント主催者や飲食店が、来店者のスマホのこの注意喚起を入店・受入時に確認すべきか、という議論になるかと思われます。原則、主催者等に確認義務はない、と公式発表しつつ、それぞれ感染防止のお取り組みを別途全体的に評価していくことをおすすめします。

[daisuke-nogami]

そうですね、

接触の意味（リスク毎の接触通知を受信した人に推奨する行動）を柔軟に変更できるようにしておけたら理想かと思われます

ここは、IT企業などで「システムでなにか動的な対応をする」という経験がないと、なかなかイメージしにくいところもあるようで、今回の更新に合わせたデータ取得でイメージを持たせながら進めていきたいとおもっていました。

ところで、現時点ではCOCOAを通じた検査は、そもそも医療機関に直行してもらう方向に進めています。
（保健所を通すと、COCOAのアプリのサポートとしての問い合わせまで保健所に回ってしまうため）
その前提であれば COCOAのaの接触者へのPCR検査なしの自粛をうながす までしなくてもよい
（加えて、検査でクロとでないと普通の人は自粛をしないのでは）のかとは考えていました。

[kvaluation]

医療機関直行はとても良いと思います。

検査でクロとでないと普通の人は自粛をしないのでは

確かに、イングランドの自主隔離は迷走な感じします。
https://gigazine.net/news/20210713-nhs-covid-app-reduce-pings/

COCOAの接触通知で自主隔離は、まん延し、都市のロックダウンの一歩手前に行うようなイメージでした。ロックダウン実施の諸国では、未検査で全員自粛なので。

[daisuke-nogami]

接触通知が出なかった場合も含めた、接触状況を知らせる定期的な通知の追加

現在のCOCOAは、接触が発生しないと一切通知を出さない「沈黙のアプリ」となっている。
これはコンセプトとして必ずしも否定されるものではない（e.g. キャリアの標準機能の災害対策）が、あまりにも通知がないことで、COCOA自体の挙動を疑われる状態となっている。
加えて、最近のAndroidでは、長期間起動していないアプリの権限削除やアプリの削除を促すようになってきており、（COCOAはその対象ではないものの）動いていないアプリを消すという動作が促されやすい状況にもあるのではないか、とも考えられる。

「通知が出たことがない！」という声を多数聞くがそれは当たり前で、第5波のピークで満員電車に乗っていたとしても同じ車両に5,6人しかいない計算になり、距離的に濃厚接触にならない（OSの画面上では閾値以下の接触あり、と表示されうるが）。
そして、感染者の分布に偏りがあることを考えると、接触がある可能性はより低くなる。
試算の根拠：
人口当たり新規感染者数が最も多かった沖縄県でも人口10万人あたり7日間合計3,000人、東京都は7日間合計2,500人
一般的な通勤列車は長さ20m、6人で割っても5m。最も長い駅間でも20分程度か。

そこで、濃厚接触の可能性がなかった場合でも、1週間に1回程度通知をだすことで、動作を伝えてはどうか、というのが
この機能の趣旨である。

また、関心が高いユーザで普及している「OSの設定画面から閾値以下の接触も探す」という行動は、自分の行動圏内に陽性登録者がいたかどうかを探るという意味でリスク情報の提供にもなっていると言える。
※個人的にも、8月は渋谷へ週3-4の出社が必要な時期があり、閾値以下の接触件数は念のため気にしていた（それでも8月に2日だけだったが）

そのため、通知の内容は3種類とするのがよいと考えている。

• （その週に濃厚接触の可能性を通知した場合）通知への対応をリマインドする内容
• （閾値以下の接触があった場合）行動圏内に陽性登録者がいたので少しだけ注意を促す内容
• （閾値以下の接触も無かった場合）行動圏内にも陽性登録者がいなかったのでリスクが非常に少ないことを伝える内容

[keiji]

COCOAログチェッカーの使われ方を見ていると、やはり閾値を超えない場合でも陽性判定された人が近くにいたことを知りたいという層は確実に存在してますよね。

ENv1の時点では接触情報をシステムから取得すると「接触の可能性があります」みたいな通知がシステムから出て、それを見た利用者が過剰に反応する可能性があったので厳しかったですが、ENv2になるとシステムからの通知は出ないので、閾値低めに接触確認しておいて、後段で分類するというのは現実的だなとぼくは思います。

[b-wind]

「沈黙のアプリ」本来目指す方向としては正しいけれど、ユーザーの期待とはズレてしまっていることは否めません。
内容詳細はぱっと思いつかないですが、 Weekly Report の様な物が出れば動作していることが認識しやすいかも知れませんね。

ENS で扱うデータの範囲外で有るだろう事を承知の上で言うと、身の回りの人がCOCOAを利用しているかどうかも知りたい需要があると感じます。（実数だと問題ありそうなので曖昧な表現に置き換えた方が良い様には思います）

[daisuke-nogami]

具体的な実装に関するp-r
#605
閾値以下で接触通知の対象にならなかった接触を確認出来る画面を作る #605

[daisuke-nogami]

接触通知の発生状況を把握するための、ログ自動送信による接触通知が出た回数の集計（プライバシーポリシー等で同意取得をすることは前提）

#532 (comment) にも記したが、COCOA自体の挙動の正しさを疑われる1つの要因が、接触通知が発生した件数が一切分からないことにある。
また、疫学・公衆衛生上の観点からは、接触通知の発生件数は、感染拡大状況を把握する上で1つの参考になる可能性がある。

件数が分かると、接触通知発生件数÷陽性登録件数＝1人の陽性者が接触した人数が分かる
1人の陽性者が接触した人数から、接触が感染に繋がる割合も大ざっぱに把握しうるのではないか
1人の陽性者が接触した人数の増減で、社会的な高リスク行動の有無を把握できるのではないか（例えば人流が増えていても接触人数が増えていなければ、人との接触を避けた通勤が増えているだけである、等）

そこで、接触通知が発生したことをログ自動送信し、回数を集計する機能があると良いのではないかと考えた。
通知が出たときに都度送信許可を求めると、許可率が分からないために正確な回数がつかめないことから、プライバシーポリシーを改訂した上で、通知発生時に自動的にログ送信をできると良いと考えている。

そのログ送信内容は、ここでは以下を想定している。

• 通知が発生したこと
• 重み付けスコアの合計値（どのような接触が把握したかの推定のため）
• Exposure Windowの個数（Exposure Windowを送信するとしたときのデータ量推定のため）
• 冪等キー（重複送信を避けるため、個人・端末を特定出来ないように端末側で生成する前提）

なお、 #532 (comment) に示した、週次の通知機能を実装するとした場合には、週次の通知機能が機能したときにも、

• 通知が発生した件数（0以上）
• 重み付けスコアの総合計
• Exposure Windowの合計個数
• 冪等キー（週次の通知送信ごとにリセットされ、通知発生時にも利用する）

を送信するようにすることで、Google/Appleのストア情報より分かる稼働端末数と合わせることでログの欠落率を把握し、通知の発生状況をより正確に把握出来るようにしたい。

[daisuke-nogami]

ダミーリクエストが完全にランダムなタイミングだと、むしろダミーと分かりやすいとも思うので、
TEKをダウンロードして接触通知を出すタイミングで発生するのが良いようには思いました。
（ダミーリクエストは記録しないが数はカウントする、とすればheartbeatとして稼働台数把握にもなる）

[b-wind]

陽性者情報の登録は有効な「処理番号」が必要であるので偽のデータを送信することは相対的に難しいだろうと認識しています。
（処理番号の発行ルーチン等は分からないので推測混じりですが）

逆に偽のログデータについては攻撃者のPC等から送信されることを想定していて、送信元がCOCOAで有るという保証は無いものとして考えています。
データの送信元がCOCOAアプリケーションである事を保証する仕組みが有る方が良いのですが、どういった方法があり得るかも含めて思案中ではあります。

もっとも、おかしなデータを混入させるイタズラぐらいしか思いつかないので最初は特別な対策はしないと言うのもあり得るのかなと。

[daisuke-nogami]

はい、今のところは何らかの政策判断などに用いるわけではないので、偽のログを送信してもイタズラかDoS攻撃くらいだと想定しています。最初の段階で出てきたデータをリファレンスに、異常値を検知していくような対応なのかなと考えています。

[daisuke-nogami]

一点追加の議論です。

ここではログを飛ばすのは通知発生時に限っていましたが、"閾値以下での接触"でも、同様にオプトアウト形式でログ送信が
できないかなと考えています。

これは、

• もともと 「積極的疫学調査実施要領」に示されている濃厚接触の条件をより広くカバー出来るようなパラメータ設計 とセットでのリリースを考えていたところ、「1m以内15分以上」以外への拡張が少し検討に時間がかかりそうであること。
• その結果、"閾値以下で接触通知の対象にならなかった接触を確認出来る画面を作る" 閾値以下で接触通知の対象にならなかった接触を確認出来る画面を作る #605 の表示対象になる接触が、当初想定していた「数m以上でリスクが非常に小さい接触」以外も含まれること
  から、通知が発生していない接触も実態を把握する必要性が高まるためです。

用途としては、「1m以内15分以上」以外への拡張をしたときの影響範囲をあきらかにして、変更の意思決定を
しやすくするところにあります。

この、通知が発生しない接触でもログを取ることについて、懸念等があればお教え頂けますと幸いです。

[kvaluation]

@keiji > 個人情報には疎いのであくまでアイデアレベル、個人的な意見なのですが、接触時にシステムから得られる情報を全部送ってもらって、オープンデータにしたら良いのではと考えることはあります。

「接触時にシステムから得られる情報全部［Exposure Window modeから得られる情報, ここでの仮名cocoa-log］」は、接触した相手の陽性登録者さんの個人情報が残っていないので、cocoa-logが生成された端末の所有者の個人情報とcocoa-logが紐付かなければ、オープンデータにしていくことができると思います。

cocoa-logに閾値以下の接触情報を含めても、接触がないという情報を含めても同様と考えます。

EN自体、過剰に個人情報に配慮しているシステムで、それが一定数以上利用者を得ている背景でもあることを考えると、ある程度まで過剰に個人情報に配慮するのが良いと、考えます。

国によって管理されるcocoa-log格納サーバーに、cocoa-logが格納された段階で、送信者（cocoa-logが生成された端末の所有者）と一切紐付かないと良いです。

案としては、例えば２段階として、cocoa-log生成端末→一時格納サーバーは、端末検証等をしつつcocoa-logを（できれば暗号化して）吸い上げます（TEK配信時にcocoa-log暗号化用のテンポラリな公開鍵を送るなど）。
別途、一時格納サーバー→cocoa-log格納サーバーのcocoa-logデータの移動を、バッチ処理とするなどとし、送信元端末との紐付けが完全に外れるようにでき、オープンソースのプログラム以外一時格納サーバーにアクセスできないようにすると、安心感あります。

避けて欲しいことは、指摘いただいておりますように、送信者とcocoa-log中の接触情報が紐付けられた状態で第三者に漏洩し、第三者が、ある個人（送信者）が陽性登録者と何分間接触したのかというセンシティブ情報を知ることができる状態です。cocoa-logを国が解析して解析結果からそのcocoa-logの個人に連絡できるようにするのも、避けていただけたらという前提です。

英国で郵便番号と紐付けられていますが、都道府県とcocoa-logの紐付けは私としては許容範囲と思います。ただ、代表地点１カ所としないと、都道府県の組み合わせで個人の属性を特定可能なシグナルになる可能性もあり、そこは議論や対話が必要と思います。例えば、米軍基地がある都道府県のみの場合など。　以上です。

[daisuke-nogami]

接触通知の改善や、感染拡大防止に資する調査研究のための、接触通知が出たときのExposureWindowの収集（オプトイン形式）

前述の、接触通知発生時のログ送信機能 #532 (comment) を実装したときに、単純に通知の件数だけ分かっても、日本全国の数字が分かったところで活用しにくい、という声が上がることも当然考えられるため、なんらか付加的な情報を収集できないか、と検討するのがこの項である。

ここでは、Exposure Windowを収集することを提案とする。
Exposure Windowは、接触を30分単位で区切ったものであり、以下の情報が含まれる。

• 接触が発生した日付
• 端末の電波強度の精度（Calibration Confidence）
• 陽性者の報告タイプ（症状の有無）
• ScanInstance（Exposure Windowの中での個別の接触。1～5分程度）の長さ
• Scaninstanceの間の電波強度の平均値・最小値

この情報がわかると、重み付けスコアの合計値と合わせた計算などにより、近距離の接触が長かったのかなどの、接触の内容がより具体的に分かり、社会で発生している陽性者との接触のイメージを掴みやすくなる。
一方、Exposure WindowとScanInstanceは、時系列が失われた状態で返されるため、これを元に個人を特定することは難しい。匿名性が担保された統計情報として扱えるとも考えている（要：専門家レビュー）。

ただ、より詳細な情報を取るときには、その説明をする必要はあるので、こちらもプライバシーポリシー等に同意いただいてから送信するようオプトイン形式で実装すると共に、必要に応じてオプトアウト可能にする必要はあるかもしれないと考える。

（なお、オプトアウトしても、過去の送信データの削除までは行えないが…）

[daisuke-nogami]

接触通知の改善や、感染拡大防止に資する調査研究のための、接触通知の発生状況に対するフラグ付け（地域等）

前述の、接触通知発生時のログ送信機能 #532 (comment) を実装したときに、単純に通知の件数だけ分かっても、日本全国の数字が分かったところで活用しにくい、という声が上がることも当然考えられるため、なんらか付加的な情報を収集できないか、と検討するのがこの項である。

ここでは、アプリ上に事前に何らかのフラグを設定しておいていただき、そのフラグもセットで送信することを提案とする。

私が個人的に検討してもよいと考えるフラグは以下の通り。

• 普段の行動範囲（県単位で設定、複数選択）⇒県単位での感染拡大状況の把握
• 大規模イベントや飲食店等、参加記録を残す・ワクチン接種証明が求められる（ワクチン・検査パッケージの対象となるような）場への参加の有無（あるいは具体的なイベント・飲食店名を把握できるID）⇒大規模イベント等での集団感染を防ぐための参考情報とする

※フラグの種類が少ないのは、個人的にこれ以外の属性（年齢・性別・職業など）は、活用目的がイメージできなかったため

これらの情報を任意で送信できるようにしうるかどうか、送信されたデータの悪用が出来ないような工夫は何が考えられるか、また、これ以外も含めた送信できると望ましい属性はなにか、を議論できるとありがたいと考えている。

[b-wind]

• 普段の行動範囲（県単位で設定、複数選択）⇒県単位での感染拡大状況の把握

ログとして提出する以前に設定するUIが煩雑になってしまいそうな気がしています。
また、「普段の行動範囲」という面から見ると、COVID-19に直接関連が無い内容も含むことになり
個人的にはこの情報を政府・官公庁に提供するのは抵抗がありますね。
情報提供によほどの（直接的な）メリットが無い限り、許諾するモチベーションは低い様に感じます。

[b-wind]

大規模イベントや飲食店等、参加記録を残す・ワクチン接種証明が求められる（ワクチン・検査パッケージの対象となるような）場への参加の有無（あるいは具体的なイベント・飲食店名を把握できるID）⇒大規模イベント等での集団感染を防ぐための参考情報とする

大阪コロナ追跡システムやドイツのCorona-Warn-Appの様にイベント毎にQRコードを発行し、利用者が読み込んで登録するシステムを想像しました。
https://www.pref.osaka.lg.jp/smart_somu/osaka_covid19/index.html
https://www.coronawarn.app/en/eventregistration/

あくまで利用者が登録する事は任意である条件であれば悪くないのかなと。
（結果として同調圧力によって登録を事実上強制されそうな懸念はあります）

[daisuke-nogami]

反応が遅れて失礼いたしました。

また、「普段の行動範囲」という面から見ると、COVID-19に直接関連が無い内容も含むことになり
個人的にはこの情報を政府・官公庁に提供するのは抵抗がありますね。
情報提供によほどの（直接的な）メリットが無い限り、許諾するモチベーションは低い様に感じます。

そうですね、個人的にも、いきなり行動圏を送信したいとは思わないと考えています。
ただ、いまの日本のコロナ対策の考え方が県単位でチューニングされることを考えると、
全国の数値だけでは、なかなか活用されにくいのではないかと考えていました。

利用者目線では、別項目でもあげているとおり、閾値以下の接触件数（現在、OSの設定画面で見れる
「キーの一致」のことです）をCOCOA上でも表示することを考えていますが、それが果たして
行動圏内の陽性者を正しく示すものなのか？という疑問はでると思っていて、その部分が、例えば
県単位で集計された新規感染者数/陽性登録者数/接触発生件数として出てくるとすれば、より
使い勝手がよい、と感じるのではないか、などとも考えております。

いずれにせよ、属性情報を取得するのは、EN v2の搭載直後ではなく、その次のバージョンアップなど、
理解とステップを踏んでから、というイメージでした。

大阪コロナ追跡システムやドイツのCorona-Warn-Appの様にイベント毎にQRコードを発行し、利用者が読み込んで登録するシステムを想像しました。

はい、神奈川など各県で作られている飲食店やイベントごとのQRコードによるチェックインとの
連動を想定した機能案です。この点については、ワクチン・検査パッケージ側が求めると、より強制力が
ある見え方になるとは思いますので、メリットの提示・デメリットの抑制など対策はいろいろ考えるべき
とは考えておりまして、こちらもEN v2搭載直後には間に合わない機能のイメージです。
（そもそもXamarinで端末のカメラを扱うところから苦労しそうです）

[b-wind]

ただ、いまの日本のコロナ対策の考え方が県単位でチューニングされることを考えると、
全国の数値だけでは、なかなか活用されにくいのではないかと考えていました。

こちらについては私自身も気になっております。各自治体としても地域内の事と捉えにくい状況だと思います。
手始めに考えられるとすれば、陽性者登録の際に任意でユーザー自身の行動範囲（自治体単位）を申告して戴くぐらいでしょうか。
これが良い方法かどうかはまだ自分でも考慮し切れていませんが……

[daisuke-nogami]

このあたりは、別のIssue #605 でも話題にしていますが、

• 全国の感染者数・接触通知の発生数を出すような画面があり
• 設定した都道府県（≒行動圏）に絞って感染者数を出すような機能があって
• 設定している人に対して、「接触通知が発生したときに設定した都道府県を送信してよいか、設定して貰えれば県単位の接触通知の件数が計測可能になる」と聞いて協力を促す

ようなイメージを持っていました（陽性者登録のときに県情報を送るのは抵抗感があるかと思い）。
事前に県単位の情報を提供していくことでメリットを見せてから、協力を促すようなアプローチだったら協力は得られますかね…？

[kvaluation]

多様なご議論をありがとうございます。追い切れていないところが多いのですが、検討頂きたい項目を報告させてください。

１．何日前の接触まで通知するか

現状、発症日又は検査日から約2日前までの接触に通知されております。
#305 (reply in thread)

しかし、例えば和歌山県では独自の追跡調査の科学的知見から、３日前で接触者を追跡してます。
https://www3.nhk.or.jp/news/html/20211020/k10013307181000.html

４日前の感染例も和歌山県で確認されていましたので、発症日１日前と比べればより低リスクとはいえ、知りたいニーズはあるかと思います。
COCOAは14日間分の接触を記録しておける点で、人手ではできない追跡ができるので、発症日から4日前、検査日から8日前ぐらいまで通知（低リスクとしての通知でも良い）できると良いと考えます。特に感染者数の減少期に有効と思います。

２．COCOA通知の意味と、アプリのユーザー体験
イングランドでは、濃厚接触の通知があると、医師の診断を経ずに自己隔離をうながすようでした。
#305 (comment)
自己隔離をうながす利点は、感染拡大期に保健所の負荷を高めないことと考えます。

ドイツでは、当初から、高リスク、低リスクの二段階表示となっていました。
日本では、OS側の（提供）キーの一致から、事実上の二段階表示として使える限られたユーザー層もおりした。
私は個人として100人以上、一致が出た方とTwitterのダイレクトメールで対話してきましたが、COCOAで接触が通知されず、キーの一致がでた（1m以上15分以内の接触）方たちは、ハイリスクな方との面談を回避したり、結婚式等の出席前に自費でPCR検査したり、保健所に連絡したら公費PCRを受けることができたなど、感染抑止の行動をしてくださっていました。
低リスクの通知には社会的有用性があると確信しています。

COCOAから接触が通知された際に、どのような行動をすべきなのか、そこまで「デザイン」していただけると、アプリの表示もより適切なものへと工夫されていくと考えます。

一つの理想としては、
　自主隔離となるハイリスク通知（PCR検査と診断で陽性でなければ通常の行動が可能）、
　陽性者とすれちがったことを示す低リスク通知
の二段階で、両者とも公費PCR検査に誘導（可能ならPCR検査予約アプリの起動）などできたら良いと思います。

低リスク通知でのPCR検査への誘導については、感染拡大期の地域のキャパシティーによっては、難しくなるため、PCR検査に誘導できない地域の場合、弱い自主隔離（接触日から３日間の外出自粛要請など。通常、接触通知日には経過している）をうながすのが良いと考えます。
アプリ側では、PCR検査誘導か、弱い自主隔離をうながすかのオン・オフを保健所ごとにできればよさそうです。

３．COCOAの証明書機能
イベントなどで、COCOAインストールと接触画面の表示をうながしてくださっている主催者様があります。しかし、実効性については色々と疑問も生じるところです。
どうしたら良さそうか以前考えたメモです。
#121 (comment)

以上です。整理できてなくてすみません。

[daisuke-nogami]

反応いただきありがとうございます。

１．何日前の接触まで通知するか

こちらについては、和歌山県の取り組みは報道でも聞いておりますし、例えば発症5日前に接触が
あるひとは、感染リスクがある同じ場にいあわせることで、登録した陽性者からの感染ではなく、
共通の感染源に曝露していることもあるのでは？というようなことを含めて幾つか専門家と議論を
しております。

ただ、現時点では、現状のまま48時間前までを対象にして変更しない、という考え方で検討していました。
これは、広く日本にいる人全般に対して動くものであるので、細かい例外を拾いにいくよりは、
まずは一般的な基準に沿って、確実に通知を出していくことが優先であろう、というものでした。
（そのためこのdiscussionのテーマにはあげておりませんでした）。

ただ、ご提案いただいて気づいたのは、2点目のご提案へのお答えでも示す、低リスク接触と同じような
枠組みでの伝え方もあるかもとも考えました。
論点として検討に加えるようにいたします。

２．COCOA通知の意味と、アプリのユーザー体験
COCOAから接触が通知された際に、どのような行動をすべきなのか、そこまで「デザイン」していただけると、アプリの表示もより適切なものへと工夫されていくと考えます。

こちらについて、ユーザにどのような行動を促すか考えて、今回のdiscussionでも2つの論点をあげています。

ドイツでは、当初から、高リスク、低リスクの二段階表示となっていました。

こちらに近い考えで、同じ接触でも通知をだしわけよう、としているのが、
「積極的疫学調査実施要領」に示されている濃厚接触の条件をより広くカバー出来るようなパラメータ設計と、それに応じた接触発生時の通知内容のカスタマイズ #532 (comment)
にあたります。そして、

日本では、OS側の（提供）キーの一致から、事実上の二段階表示として使える限られたユーザー層もおりした。
低リスクの通知には社会的有用性があると確信しています。

こちらの低リスクについて通知して意味を持たせようというのが、 接触通知が出なかった場合も含めた、接触状況を知らせる定期的な通知の追加 #532 (comment) で示している「定期的な通知」です。

まず、提供キーの一致を「週次」で通知している理由ですが、

• キーの一致の場合は、現状の設定値の閾値-63dBを踏まえると、10m以上離れたような接触を拾っていると考えられ、これと他の接触を同等に伝えるのはミスリードであるので見せ方を変える必要がある
  • 横浜スタジアムでCOCOA導入台数を計測する準備をしていたときに、球場から数車線の道路を挟んだ京浜東北線の電車のBLEを拾って計測に苦労したこともあるので…
• とはいえ、普段生活している行動圏内に陽性登録者がいるのは、少しは警戒感を持っていただきたいので、なんらかの形で伝えたい
• また、提供キーすらゼロで、ある程度緊張を解いてもよい地域（たとえば、直近1週間程度新規感染者が確認されていないような県など）は、それはそれで比較的安全であることも伝えたい

これらを組み合わせつつ、変化がない通知でもアテンションを持って貰える頻度として週次、というもので一旦置いています。

続いて、利用者に促すメッセージですが、

自己隔離をうながす利点は、感染拡大期に保健所の負荷を高めないことと考えます。

本来であれば自己隔離が望ましいですが、普通の人がいきなり2週間社会との接触を断て、と言われても
困るだろうと考えます。少なくとも、かなり強い証跡を求めたり、否定する主張をしたくなる（例：ずっと
マスクをしていた！）と思います。そうなるとアプリが得られる情報では打ち消しができません。
事実、感染拡大期のイギリスでは自己隔離をルールとしたことで、むしろアプリを止めたり消したりする
事例も多く見られたと聞きました。

これらを踏まえると、次善の策ではありますが、リスクがあったときにPCR検査をして白黒をつけてくれ、
というのが共通のメッセージになるかと考えております。

すでに、COCOAの通知は公費検査対象となると、2021年3月8日の厚生労働省の事務連絡
「新型コロナウイルス感染症に係る行政検査に関するＱ＆Ａについて（その４）」
https://www.mhlw.go.jp/content/000750111.pdf
の問9でも示されておりますので、COCOAから通知を出してとにかく公費検査につなげる、
というのが、いま考えている流れになります。

※この場合の検査対象となる通知には、閾値以下の「診断キーの一致」は含めない前提です

低リスク通知でのPCR検査への誘導については、感染拡大期の地域のキャパシティーによっては、難しくなるため、PCR検査に誘導できない地域の場合、弱い自主隔離（接触日から３日間の外出自粛要請など。通常、接触通知日には経過している）をうながすのが良いと考えます。
アプリ側では、PCR検査誘導か、弱い自主隔離をうながすかのオン・オフを保健所ごとにできればよさそうです。

COCOAが地域情報を持たないため地域別の出し分けできないこと、（PCR検査誘導のキャパシティー問題はどちらかといえば保健所の公費検査をアサインするところにあるので）医療機関を直接訪問して行政検査としてもらえればキャパシティー問題もおこらないという点からも、直接検査への誘導を強めるような考え方を取っております。
（直近でも、COCOAから開く医療機関等の一覧の中で、「医療機関で行政検査としてもらえる」ことをより明示していく予定です）

３．COCOAの証明書機能

こちらは、v2への改修など踏まえて、信頼度があがり、画面の偽造などが起こってきたときに考える
テーマかとは思いますが、こちらもアイデアとして頭に入れておくようにいたします。

[kvaluation]

@daisuke-nogami ありがとうございます。学ばせていただきます。

全体像やありたい未来を私なりに少し考えさせてください。自分のボランティア枠は、いま中小企業の過剰債務と大企業のサステナビリティー関連開示の在り方に時間使ってまして、反応が遅れます。

COCOAですが、対話の前提として、特にエンジニアから厚労省や医療関係者に伝えて欲しい、技術の限界と現状があります。

■技術の限界はBluetoothの距離測定の雑さです。精度でません。特に2m以上。

・Measurement-based evaluation of Google/Apple Exposure Notification API for proximity detection in a commuter bus
https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0250826

・Inferring distance from Bluetooth signal strength: a deep dive
https://medium.com/personaldata-io/inferring-distance-from-bluetooth-signal-strength-a-deep-dive-fe7badc2bb6d
　引用されているこちらの動画からわかることは、幅広く共有していけたらと希望します。
https://youtu.be/SAi24ctpyZQ

■現状というのは、COCOAのためのキャリブレーションはGoogleで100台、Appleは自社端末を実行したという情報はありますが、COCOA動作中で、規定の距離で濃厚接触が通知されるのかされないかの大規模検査を見かけない、という現状です。
（keijiさん個人とDeNA殿のはありました）
特に、Bluetoothの直進性を前提とした日本家屋ならではの現状や、逆に、航空機内や見通しの良い道路、トンネルや鞄の影響などは、科学的に誤差を測定しつつのデータは見かけたことがありません。医療機器であればするであろう製品性能検査がされていなさそうだ、ということです。
しかし、航空機や宗教施設など海外事例もみると、見通しが良くBluetoothが届きそうな場所での時間共有は、感染をもたらす可能性もあります。
特に、COCOA | ENの距離は平均値であるため、例えば、居酒屋の接客係さんとお客さんなど距離が変動するが近接で数十秒滞在する可能性のある状況で、キーの一致がでた事例などもありました。
COCOAの距離は、統計的根拠のある科学的判断になれた医師に、距離としてお伝えできる数字ではないと感じてます。
単に、Bluetoothが届く状況で、陽性者さんの近くにいた、というぐらいです。

■私個人としては、そういった距離測定の不安定性を把握しつつ、EN1のcocoa-logからわかる距離の３区分ごとの接触平均時間をユーザーやその診断をなさる医師に伝えることができて、医師の診断や、本人の行動判断に広く使ってもらえたらなと考えていました。
https://datastudio.google.com/reporting/069598a2-3f01-4b51-b023-cdb478992182/page/2pXIC
（Appleはキー一致レベルの際には隠蔽していますが、COCOAで接触が表示された際には３区分ごとの滞在時間がでます。）
EN2のすべて時間に換算していく発想より、この３区分の距離の方が診断に役立ちそうな気がしています。
EN2の時間は複雑すぎて何を言っている時間なのか、理解がとても難しいので。

色々とありがとうございます。お取り組みに感謝申し上げます。

[daisuke-nogami]

反応ありがとうございます。そして返信が遅れて失礼いたしました。

厚生労働省や医療関係者は、Bluetoothによる距離計測はそこまで信用しているわけではなく、
どちらかと言えば接触したときの環境を把握できないことを気にしています。
特に、実際の陽性者と接触する人になればなるほど、隔離等を指示する観点で
マスクや換気などの状況が推測出来て「リスクが高い接触だったでしょう」と言えることを
望んでおり、精密な距離や時間は気にしていないです。

その点では、ご提案されちる距離の区分毎の平均時間も診断や判定には使いにくい、
それらを丸めてスコアにするENv2のスコアリングの仕組みの方が使いやすかろう、という感触です。

ただ、一部には、Bluetoothの距離測定の精度を過剰に信用している言説があるのも
確かにそうなので、その点は留意しながらコミュニケーションを進めたいと思います。

なお、

特に、COCOA | ENの距離は平均値であるため、例えば、居酒屋の接客係さんとお客さんなど距離が変動するが近接で数十秒滞在する可能性のある状況で、キーの一致がでた事例などもありました。

キーの一致自体は、リスクがある接触があるという通知には適さないけれど、行動圏内に
陽性者がいたという点では早期の注意喚起には使えるものかと思います。
そして、ENv2のExposure_dataでは、最小値と平均値がでますので、一瞬近づいたので
スコアが高かった、というものも除外しうるかと思います。
（内部的には、1～5分で生成されるScanInstanceごとの平均値で計算しているようですので、
　跳ねた異常値に基づく反応はされていないようです）