v2.0.0-beta01/beta02について気づいたことがあれば

[keiji]

タイトルの通りです。現在オープンベータに向けてクローズドベータを実施中です。
Contributorsに名前を連ねている方などで個人的に連絡が付く方にお願いして回っています（ #599 (reply in thread) ）。

何か気づいたことがあって、Issueにするほどでもないと言うものについては、こちらにお願いします。

[Murayu0225]

本日、陽性者との基準値を下回った接触を確認しました。スコアの確認をしたところスコアが1.2となっていました。(下記画像参照)

正直、このスコア値を見た際に思ったのは1.2とはなに？という感じです。1170以上が通知対象と書いてありますが、程遠い値でよくわかりませんでした。

スコアの計算方法の例が書いてあっても良いと思います。

• バージョン：v2.0.0-beta01
• OS：Android
• 端末：Galaxy S10

[Murayu0225]

すみません。API関連で気になったことがあるので聞かせてください。

GoogleのAPIドキュメント上で言われているlegacy v1の接触は、COCOAだとkvaluationさんによると"2m50cm以上の記録は5分以上の接触でExposureSummaryに記録される"とのことですがそうであれば、私がベータ版に移行する前(1/23以前)の接触において3m以上2分というのはどのようにして計算をしているのでしょうか。(3m以上において5分に満たない記録が何故確認できるのでしょうか)

ドキュメント上には、v1 legacyからExposureWindow modeへの移行の際には

The API is backward compatible with all versions: it activates non-breaking changes when a new version is available on the device, even when using the legacy v1 mode. Such changes would include, for example, the same-day release of keys and the ability to provide keys from multiple files with different signatures in one call.

と書いてありますがこれがどのような処理をしているのか書いていないので計算方法が気になりました。ここらへんのコードを見て調べたりしましたがよくわかりませんでした…

[kvaluation]

RPI自体は、v1もv2もどちらでも併存できるのかなと思いました。14日経過まで削除されないので、v1でもv2でも非破壊に動作するようにしたのかと思われます。

2m50cmは、v1のパラメーターでCOCOAが
"DurationAtAttenuationThresholds": [ 50, 70 ]
と決めていることによります。

3mというのはv2 COCOA2のパラメーター設定によるものと思われます。

何分間かは、通知サーバーからダウンロードしたTEKによる符号の照合時に計算していると思います。

[daisuke-nogami]

私が出した3mという数字は、ENが返した値ではなく、「3mだとこのような電波強度になるであろう」と推定した閾値を下回ったことで3mという言葉を出しています。
（なお、こちらで推定に用いたロジックでは、70dBは「3mを越える可能性が高い」となりますが）

ENv1時点で突合したTEKはENv2に移行したあとでは再突合はされない（手元の端末でそのような挙動を確認）ため、β版を入れてくださった1/23以降にサーバにアップロードされた1/23以前のTEKとの照合で、閾値以下の接触が表示されたものだと思います。

※その点でいうと、kvaluationさんのGoogle Data Studioから、「登録は発症日/検査日から何日おくれていたのか」が読めると思うので、そういうViewがあるとありがたいな…と思ったりしながら見ていました

※さらに余談ですが、v2ではTEKをサーバに全部送信するようになる（日数判定は端末側が行う）ので、サーバ上のデータの傾向は大きく変わるはずです…

[keiji]

この画面、分かりづらいという意見をいただいているのでbeta03ではこうなりそうです。

#823 (comment)

[parasite2006]

@daisuke-nogami

kvaluationさんのGoogle Data Studioから、「登録は発症日/検査日から何日おくれていたのか」が読めると思うので、そういうViewがあるとありがたい

初めまして。こちらにグラフを説明とともにアップしましたのでご参考になれば。
#831

[kvaluation]

実際の動作例と、動作例による対話、とてもわかりやすいです。ありがとうございます。

EN1のキーの一致は、cocoa-logをみると、距離2m50cm以上も時間5分以上の接触から記録されており、4分とか3分とかは見かけないです。
こちらのCOCOA2のスコア表示の方が、現状のキーの一致の通知範囲（4分以下は表示していないっぽい）より幅広く陽性者さんとのすれ違いをお知らせすることになりそうと感じました。

そうすると、処理負荷が高まったり、記憶容量を圧迫したりしないかなと心配になったりもしますが、

• すれちがいで記録するRPI自体が増えるわけではない。
• 比較をする計算量も増えない。
• 通知のテキストは合計値なので通知のテキスト自体はRPI数やTEK数に比例せず上限がある。
• 計算中のスコアを一時的に記憶しておくメモリ量は、RPI数とTEK数の掛け算で増えそう。

など、理論的なアプローチで計算しておけたらと感じております。

5分未満を切り捨てると、途中のメモリ量が現状より増えることはないかな、などの心証ですが、色々不確定で分からないです。

[daisuke-nogami]

そのあたりはEN内部の話になるので利用者サイドとしては分からないところがありますが、直近で都心部で活動があるチームのメンバーでも2分以上の接触が拾えているので、ENv2として動作するときには、これまでよりも細かく処理・記録をしていても動作に問題がないように作られているのではないかと思います。

勝手に内部の動作を推測するのであれば、

• RPIを受信するたびに毎分（ないし最大5分単位）電波強度を記録しminとaveを取る
• TEKとの突合は、TEKを下ろす⇒RPIに変換する⇒内部で記録したRPIと照合する⇒突合できたらExposure_windowに書き出す
  という感じで、メモリ量はかけ算では増えないのではないかな…

[zaruudon]

現行のAndroid版の話ですが、ビーコンの受信は(状況によって大きく変わりますが基本として)約5分ごとに行われます。
相手が15分近くにいたとすると接近してから3分後、8分後、13分後に受信するというようなことになるので、
最後の時刻から最初の時刻を引くと10分となって実際より5分短くなります。
ということで一律に5分加算されてから5分単位に丸められるようです。
https://github.com/google/exposure-notifications-internals/blob/aaada6ce5cad0ea1493930591557f8053ef4f113/exposurenotification/src/main/java/com/google/samples/exposurenotification/matching/KeyExposureEvaluator.java#L434

なのでビーコンを1回受信しただけの場合でも5分として報告されているのではないかと思います。

[tmurakami]

β版未導入ですが、意見を言わせて下さい。

スコアについてですが、「EN が正常動作していることを証明する」以外に、細かい数字を出す理由が何かありますか？

個人的には「高リスク」「低リスク」さえわかれば良いのではないかと思っています。
細かい数字を見て、ユーザーはどう受け止めれば良いのでしょうか？

[daisuke-nogami]

ただ、正直な所、「まずはβ版を入れて、ご自身の行動とスコアを見比べてみてくれ」と申し上げたいところです。

このアプリの性質上、具体的なアクションに繋がる見解を出すには、かなりユーザの状況を深く拝察したメッセージを出さないといけないですが、そのためには、自分自身が、どのような状況でどのようなスコアになってどのような感情をもってどのように言われて欲しいか、を受け止める必要があります。

現在、チームのメンバーはみな入れてスコアをだして行動と見比べることで、どのようなメッセージを出しうるか必死にかんがえているところです。
都内在住もいれば都外在住もいる、外出が多い人もいれば少ないひともいる、その状況で、「同じスコアであってもこんなに受け止め方が違うのか」ということを日々確認しています。

感染者数が多いこと自体は不幸なことですが、様々なスコアがでる状況であることも間違いないので、その点ではいまでないと分からないことが多いと考えながら日々画面をみています。

[tmurakami]

ご返答ありがとうございます。
様々ご検討なされているのですね。
配慮が足りず、大変失礼致しました。

[daisuke-nogami]

いえいえ、こちらこそ言い方がきつくなってしまってすいません。

今日も、閾値を100としたときの数字のイメージについて関係者で話す場があったのですが、質疑の中で説明しつつ気づいたのは、

• 二桁のスコアだと、近接した時間が短時間ある可能性がある（特に65以上の場合）
• 5から10くらいだと、近接した時間がある可能性は低いが、ごくごく短時間なら近接した場合もある
• 5以下なら近接していない

というイメージだな、と説明していました。

これをそのまま見せるのはどんなイメージでしょうか？

[tmurakami]

これをそのまま見せるのはどんなイメージでしょうか？

スコア以外に三種類のメッセージを出し分け表示する感じでしょうか？
個人的には賛成です。
数字だけ表示するよりもわかりやすいと思います。

[daisuke-nogami]

コメントいただきありがとうございます。
これをそのまま出すのか、もう少し違う表現をするのかは要精査ですが、イメージとして、この粒度での3区分くらいのイメージが良さそうだ、ということは参考にさせて頂きます。