もともと、BLE による接触確認アプリに興味を持ったのは、アプリ自体が保持している近接データを駆使すれば、二世代前の接触者まで追跡できろうだろうと思ったわけですし、それをやると思ったんですよ。
コンタクト・トレーシング – Wikipedia https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%82%BF%E3%82%AF%E3%83%88%E3%83%BB%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0
2020年当時に日本の保健所が逼迫していたのが、感染者の聞き取り調査の部分です。聞き取り自体がアナログでしかできないし、その追跡自体も人海戦術のようでした。基本的な感染症数理モデルの SIR 型モデルを知ったのもこの頃ですが、統計学のそれも興味の範囲ではあったけど、直接 IT 技術者として手が付けられそうなのは、この接触確認アプリの近接データの扱いです。
結論から先に言うと、Goolge/Apple の Exposure Notification API を使った場合には二世代前の接触者などを追跡することはできません。サーバーに集められるのは、Temporary Exposure Keys (TEK) と呼ばれる感染者の端末が生成した一時的な鍵情報なだけで、接触自体はアプリ内で確認することになるからです。
これは個人情報保護としてはいいのですが、先にあるように保健所のトレーシング業務を支援することは不可能なわけです。ある意味 EN API の設計の失敗（実用度の失敗でもありますが）はここにあると思っています。
俺の考える最強のコンタクトレース…というか、日本の保健所のヒアリングがこんな感じになっていたと思うのです。いわゆる、新型コロナウィルスの場合もインフルエンザの場合も、感染者が居て集団で感染するクラスターのパターンが顕著に感染が広がります。接触感染じゃななくて空気感染（詳しい事は省略したうえで）なのがミソです。学校や老後施設での集団感染のことです。結局のところ、集団でいたときにマスクで防護するのが一番効率がよいのですが、じゃあ、まだマスクが主要でなかったときに、クラスター感染をどうやって見つけるのか、というのが当初の問題にありました。
そこで、保健所でヒアリングをして、感染源であるクラスターを探して、そのクラスターに居た人に注意喚起をしよう、というのが目的した。
ただし、そのヒアリングが人力であったし、保健所の職員自体も足りなかったので非常に負担であったという事実があります。いまだと、感染自体の報告義務がなくなったので、ヒアリング自体がどうなっているか不明ではありますが。
ただし、将来的に同じパターンで感染が広がったときに「ヒアリング」という手段でよいのか？ という問題があります。
IT 技術者としては、ここをなんとか自動化できるのではないか、と考えるわけです。
1. A で感染者が発覚する
2. A にヒアリングして、過去の B の集団が感染が疑われる
3. A にヒアリングして、最近の C の集団が感染が疑われる
4. B の感染疑いから、遡って C の感染疑いが発覚する
5. 過去の D の集団は、2 週間（感染期間）より前なので除外する
6. 未来の E の集団は、2 週間以内なので感染疑いとする
7. 未来の F の集団は、2 週間後なので除外する
基本的に感染者 A が発生したときは、その周辺の人達（家族や会社の同僚など）に注意喚起をするわけで、ちょっと前に合っていた B の集団に注意を喚起するわけです。
同時に、感染者 A がうろうろ歩き回ることを考えると、将来的に接触しそうな E に集団にも中期喚起が必要なわけです。まあ、新型コロナウィルスの場合は監禁ということになっていたので、うろうろ歩き回ってはいけないのですが。このあたりは、接触確認アプリの目的としてはどうなのでしょう、というところがあります。
で、実際のところ機能していたのは B の集団に対する注意喚起であって、感染者 A が感染登録をすると、B の集団の持っているスマホに「感染者に接触した可能性あります」という通知が送られるというのが EN API の基本的な仕組みです。
プライバシーの観点から、誰が感染したかどうかは分からないようになっています。が、「感染者に接触した可能性があります」という文言自体があまりにも曖昧なので、結果的にどう扱っていよいか分からなかったのが当時の実情です。結果的に「接触確認アプリが使えない」という批判を浴びたのもこういうところでしょう。
実際のところ、突き合わせは集団 B の人達が持っているスマホ内で照合が行われるので、集団 B の人達が感染者 A がその人であることを知ることはできません。この制限は、あったほうが良いかったのか、ないほうが良かったのかは不明ですが、EN API の設計としてはこうなっているわけです。
で、保健所でトレースをとっているのは、
1. 感染者 A が集団 B に感染させている可能性
2. 感染者 A が集団 B の誰かに感染させられた可能性
の二つがあります。新型コロナウィルスの場合、無症状状態があってその間に感染させている期間があるという前提となっているので（実はこれはインフルエンザでもあることが最近知られています）、感染者 A は自分が感染していることを知らずに、集団 B の誰かに感染させている可能性がある、という想定です。と、同時に、集団 B が既に感染をしていてその誰かからか感染させられたという可能性です。
これは、感染したという事実は、必ずしも保健所に報告されないことがあるためです。あるいは、無症状のまま感染している状態もあるので、集団 B には潜在的な感染者がいるという可能性を考えるわけです。
新型コロナウィルス自体は、人から人に伝播するわけですから、感染者 A が集団 B に感染させられたときには、その以前いた集団 C にも感染者がいる可能性があります。
こんな風に、感染の経路を保健所の職員がヒアリングして突き止めていたわけですが…果たして、接触確認アプリはどのくらい貢献できたでしょうか？
というか、EN API の設計上で、このトレースは取ることができたでしょうか？ という疑問があります。
先に書いた通り、EN API の設計上、個人のスマホ内でしか照合をしないので、感染通知が出せるのは集団 B の人達に対してだけです。しかも、どの時間に誰に接触したかを知らせることはしないので（サーバーとクライアントのデータを照合すれば特定可能ではありますが…機能上できません）、感染者 A がうろついた場所でしか注意喚起ができません。いや、むしろ、注意喚起ばかりが大きくて、迷惑だったという事実があります。まあ、端的に言えば、役に立たなかったのです。
これは、EN API の設計に引きずられてしまったという要因もあります。
先に書いた通り、EN API の設計上、感染者 A がすれ違った集団 B の人達というあいまいな特定の仕方しかできないので、アプリ自体がどう工夫してもこの制限を超えることができないのです。
では、もし、EN API の設計を変えたとして、保健所のようなトレース（集団 B や集団 C までの範囲の特定、そして 集団 D には通知しないなど）ができる程度まで、データの照合ができるとしたら、どのような仕組みを考えればよいでしょうか？ というのが FolkBears の課題であると私は思っています。
当然、EN API のようにプライバシーを守る必要があります。コンタクトトレースの場合を取る場合は、一番乱暴な方法としては GPS の位置情報をサーバーに送ってしまう、という方法があります。ですが、これはプライバシーの観点からは最悪です。感染者 A の行動履歴だけでなく、集団 B や C までが丸裸になってしまうからです。実際、GPS の位置情報を利用したアプリで、犯罪者の行動履歴を取ることもあります。
では、GPS の位置情報ではなく、単純に BLE を使って近接した（いわゆる iBeacon のように）だけを使って、どのくらいまで保健所のトレースと同じことができるでしょうか？
