「まもりあいJapan」 開発試行錯誤の裏話 前編

はじめまして、モンスター・ラボ CTO の平田です。接触確認アプリ「まもりあいJapan」プロダクト開発チームで開発をしています。「まもりあいJapan」は5/18にコードを公開しました。今の形に収束するまでにたくさんの試行錯誤を重ねました。私からはテックサイドで議論されてきた課題や試行錯誤・紆余曲折について雑多に共有させてください。「まもりあいJapan」の開発経緯に関しては、以下をご参照ください。

開発初期の状況

開発キックオフがあった4月1日は世界各地でロックダウンが進み、日本もいよいよ緊急事態宣言が出されるかという状況でしたので、アプリのリリースは出来るだけ迅速にという思いでした。開発後の運営主体が誰になるのか、無事リリースできるのか、という先行きの不透明さはありながらも、開発チームのミッションはGW明けには1stリリースができるよう開発を進めることでした。最初期の開発メンバーには BLE の実装に詳しいメンバーがいませんでしたので（途中心強いメンバーもジョインしました！）、筋の良い OSS の BLE 実装をリファレンスとして、日本独自の仕様を取り込みプロダクト化しようという流れに自然といきつきました。GitHub を見るとシンガポールの TraceTogether インスパイアの OSS がいくつか公開され始めて盛り上がっていました。COVID Watch、CoEpi、WeTrace などは非常に参考になりました。他にヨーロッパの PEPP-PT や DP^3T も有力な選択肢となりそうでしたが OSS 化を待つ内に開発が始まりました。「まもりあいJapan」としては、シンガポールの TraceTogether の コア部分が OpenTrace として OSS 化されたこともあり、BLE 実装は OpenTrace を参考にしている部分があります。

課題となったバックグラウンドでの BLE 動作

さまざまな OSS が公開されていましたが、それらが抱える根本的な技術課題はバックグラウンドでの BLE の安定した動作でした。 Android, iOS はバッテリー消費を抑えるために、バックグラウンドのプロセスを抑制する仕組みを備えています。iOS のバックグラウンド動作は制限が多く、色々な工夫はできるものの完璧ではありません。Android でも Doze モードに入ると BLE を遮断するなどの課題もあります。
シンガポールの TraceTogether も安定した動作のためにフォアグラウンドを推奨しています。TraceTogether の普及率は20% という話しもありますが、フォアグラウンドで動作させるという不便さがアプリの普及を妨げる要因のひとつになっているのではないかと思います。（それはそうとして、TraceTogetherがバッテリー消費を抑えるために行っている実装はとても興味深いので見てください！）

「まもりあいJapan」でも、iOS のバックグラウンドでの通信を安定させるために様々な試みがなされ、面白いものとして CoreBluetooth と Beacon を併用して、デバイスがお互いを起こし合うというアイデアも試されました。しかし Beacon が位置情報取得のパーミッションを求めることが、位置情報を取らないとする「まもりあいJapan」のポリシーと合わないし、そもそもいずれのデバイスも起きていない状況からは起こしあいを始めることができない、Apple のレビューでリジェクトされる可能性もありそう、という課題もあり見送りました。

こうした課題を解決すべく 4月10日に Apple/Google が共同でクロスプラットフォーム対応の濃厚接触通知のためのフレームワークをリリースすると発表しました。現在、 Exposure Notification API と呼ばれているものです。この API を使えばバックグラウンドでの安定した動作が OS レベルでサポートされるため期待大です。「まもりあいJapan」も Exposure Notification API にマイグレートできるよう全体のアーキテクチャを作っています。なお、電子フロンティア財団が「Apple and Google’s COVID-19 Exposure Notification API: Questions and Answers(翻訳)」で、このAPIのセキュリティ課題について論じており、今後の展開も目が離せません。

濃厚接触の定義 1メートル15分

ところで、濃厚接触の定義である 1メートル15分以上の接触確認は BLE を使って達成可能なのでしょうか。これについては難しいというのが私の見解です。BLE の電波の受信信号強度情報 (RSSI:Recieved Signal Strength Indicator) による距離の推定が研究されていますが、この実験結果にあるようにデバイスによってRSSIと距離の関係は異なり一筋縄では行きません。

実際「まもりあいJAPAN」のQAで14台のデバイスを使用してテストした時にも安定した RSSI を得ることはできませんでした。以下、メジャーで距離を測ってテストしている図です。とても丁寧で感動しました。

なお、Exposure Notification API では「RiskScore = attenuationScore * daysSinceLastExposureScore * durationScore *
transmissionRiskScore」という計算で濃厚接触のリスクを計算するとあります。attenuationScore が BLE の信号強度に関係します 。

後編へ続く

開発チームの活動はフロントエンドだけではありません。後編はバックエンドへと続きます！