ExposureNotification APIに追加された変異株対応を導入するか検討する

[keiji]

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

ExposureNotification 1.9から変異株への対応 variantOfConcern が導入された。
（マジか。ようやくENv2になったって喜んだばかりだぞ…

v1.9, December 2021
Version 1.9 of the Exposure Notifications API introduces variantOfConcern, which provides the option of labeling TEKs associated with variants of concern.

https://developers.google.com/android/exposure-notifications/release-notes

Optional variant of concern.
VARIANT_TYPE_UNKNOWN: Default unset.
VARIANT_TYPE_1: Variant Type #1 (suggested meaning: Vaccine is effective)
VARIANT_TYPE_2: Variant Type #2 (suggested meaning: Highly transmissive)
VARIANT_TYPE_3: Variant Type #3 (suggested meaning: High severity)
VARIANT_TYPE_4: Variant Type #4 (suggested meaning: Vaccine breakthrough)
This field is present in v1.9 and higher.

https://developers.google.com/android/exposure-notifications/exposure-notifications-api#variantofconncern

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

変異株に対応する。

• 陽性登録時に変異株の種類も分かっていれば登録してもらう。
  • 陽性情報登録画面の変更（項目追加）
  • 陽性情報登録処理（アプリ・サーバー側双方）の変更
• 診断キーの生成処理を変異株の情報を含めるように調整する

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

変異株に対応しない。

その他 / Additional context

接触確認時のExposureWindowにvariantOfConcernが入ってくるので、例えば利用者のワクチン接種回数に応じて通知を出す出さないを分岐したりできそう。どうやらDailySummaryConfigでのリスクスコア計算にvariantOfConcernに重みのようなものは追加されていない様子。

[daisuke-nogami]

今後のワクチン周りの研究の進展によりますが、当面は使いにくそうな印象ですね…

• どの変異株か判定して対応を分解する必要がある時期は、どの変異株かの判定が難しいシーンが多そう
  • 迅速に結果がでるPCR検査で変異株を判定するには、変異株の特徴に合わせた試薬が必要だが、その組み合わせは流行の初期にはわからず、加えて「何であるか」を特定できる保証はない
    • e.g. オミクロン株の判定は、日本では「デルタ株の特徴がない」で判定している
  • 特徴に合わせた試薬がない時期にはPCRでウイルスのゲノムを読む必要があるが、この結果が出るまでのタイムラグがある
• ワクチン接種の効果をどのように判定するかがよりなやましい
  • 接種からの経過時間で中和抗体の量が変わるので、接種日情報は必須
  • 加えて、ワクチンの中和抗体の量は個人差が大きすぎるため、一律に中和抗体の量の推定もできない
  • そもそも中和抗体の量と、感染のしにくさが綺麗に比例しない

ただ、このような機能があると「なぜ使わないのか」という疑問は出てくると思いますので、
適切に理由を説明するとともに、 主流の変異株等に合わせた通常の判定条件（1m以内を見直す、等）の見直しのアップデートの頻度はあげていきたい ですし、ユーザによって判定条件を変える
（ワクチン接種ができていない人の感度を上げる、など）というような対応をより考えたい感じです。

メモ：想定している変異株のタイプ

• VARIANT_TYPE_1: ワクチンが有効)
• VARIANT_TYPE_2: 感染性が高い
• VARIANT_TYPE_3: 重症化リスクが高い
• VARIANT_TYPE_4: ワクチン接種していたが感染した

[b-wind]

（この時期にこのレベルの機能追加があり得るんだ……）
まずは感想レベルになりますが、陽性登録時の入力・選択項目が増えてしまうのは嬉しくないなと言う印象が。

また、検討するにしても以下の２点の確認が必要そうには思います。

• 検査結果を伝える段階で変異株の種類を確実に伝えるフローが出来ているか
• iOS にも同様の機能が実装されているのか

どのような使い方をすると有効に利用出来るかの検討は（他の要素とも併せて）続けて行くべき内容だとは思います。

[keiji]

どの変異株かは時期によって検査したり検査しなかったりするようですね。
変異株が出たての時は識別のために検査しますが、置き換わりが進むとほとんどが優位な変異株になるので識別自体をしなくなるとか。

そういう意味では、今はどんな変異株が優勢なのかでサーバー側で設定する。と言うのも技術的にはできそうです。確定に基づかずにえいやで決めてしまうようなやり方が果たして許されるのかはわかりませんが。

同様のパラメーターはiOSでも追加されているので問題はないのですが、ただ現在のCOCOAに変異株対応（接触に変異株の情報を持つという意味）のプライオリティが最高かと言われると、もっといろいろやることはあるよなと思います。

野上さんが言うように「そもそもの接触の定義をちゃんと考え直そうぜ」とか、あとは感染拡大期にはHER-SYSへの登録が遅れることで結果として通知が遅れることの方が問題でしょうとかがありますね（通知の遅れについては、すべてが登録遅れによって発生しているわけではなく、オミクロン株の特性などいろいろな事情があると推察しますが）。

[daisuke-nogami]

ちょうどタイミングよく、西浦先生の分析の話がでてきたのですが、これを踏まえると、陽性者側になにかの情報を入れるよりは、接触者側が受けているワクチンの情報を踏まえた通知条件の切り替えができた方がよさそうです。
これ、現在のENでもパラメータを無理矢理いじればできなくもないですが、EN側のこれらのパラメータを使って切り替えできる方がよさそうだなと思いました。

※本論に入る前に、「オミクロン様イベント」の補足説明が必要ですが、ちょうどよい説明があったのが会員限定記事なので限定的に引用します

オミクロン様イベント「1年に1回以上の確率35％」と推定
西浦京大教授、「オミクロンワクチン生産で1年以上は有用」
https://www.m3.com/news/iryoishin/1035009

とても離れた分岐が生じるような変異株の発生」と説明。系統が離れていれば、抗原性の変化も起こりやすいという。人口レベルの免疫保有度合などが大幅に変わるリスクと言い換えることもでき

第80回新型コロナウイルス感染症対策アドバイザリーボード（令和4年4月13日）
西浦先生資料
https://www.mhlw.go.jp/content/10900000/000928857.pdf

参考にしたのは、こちらの西浦先生資料のp.125以降です。

結論
・オミクロン様イベントは平均して数年以内に1回のペースで起こる。
・1年間を通じてオミクロン様イベントが1回以上起こる確率は35％程度である。
・人口レベルの免疫保有度合などが大幅に変わるリスクがその程度である。
・オミクロンワクチンを生産するか否かなどの参考となる（1年以上有用と思われる）

逆に考えると、オミクロン様イベントが起きたときには、既存のワクチン接種者も感染リスクが高まるため、警戒を高める必要がある、と言える。

たとえば運用イメージ

• VARIANT_TYPEは、Googleが想定している株の特性ではなく、大きな系統が同じかどうかで順次利用していく（1=オリジナル・α～δ株、2=オミクロン株、…というイメージ）
• VARIANT_TYPEは、サーバ側で「現在の流行の主流の株」に合わせて全部上書きしておく
  • 主流かどうかは、少し悪い方の判断に基づいて行う（オミクロン株の場合で例えると、市中感染が始まった2022年1月前半には切り替えてしまうイメージ）
  • もちろん将来的に株がすぐに分かる状況になるならば陽性者側に入力してもらい、それをそのまま取り込む
• COCOA側では、接種証明アプリ等(QRコード取り込みで海外での接種記録も取りこめるとよい)で、利用者がどの株に対するワクチンを接種済みかを保持する
• 接触通知の判断をする時点では、利用者の対応しているVARIANT_TYPEと送られてくる鍵のVARIANT_TYPEを比較して、対応できていないときは感度をあげる