「接触確認アプリ」の仕様書について (2)

仕様書 第1編を見た「接触確認アプリ」の仕様書について (1)のに続いて、第2編 仕様(要件定義)です。

第2編 仕様(要件定義)

要件定義は、機能要件と非機能要件に分かれています。

第1章 機能要件の定義

1. 機能に関する事項

これは、さらに基本機能(インストール)、認証機能、あと、アップル・グーグル枠組(Apple Google Frameworkですね、AGF)で実現する機能にわけて論じられています。アップル・グーグル枠組は、私のブログだと、既に見ているし、あと、本で、触れています。

インストールで興味深いところは、オプトインで、利用規約、ブルートゥース利用の案内、通知機能利用の確認がなされることが確認されているところです。また、同意の撤回についても、確認がなされています。

陽性利用者の接触履歴のアップロードが、「認証機能」という名称のもとで論じられています。これが、「認証機能」たるゆえんは、「いたずらの陽性者の通知を防止する」ための陽性者の端末の認証という趣旨ですね。

これは、世界でも共通の問題意識で、シンガポールは、保健所の職員がワンタイムパスワードでいれる仕組みですね。イギリスのNHSXは、自己申告の症状でもOKとしているので、ちょっと問題という記事を読みました。

この部分のフローと画面遷移の記載があります。

あと、近接接触した人数の総計の画面表示については、AGと調整中のようです。家族との間を近接接触といわれてもなんで、ホワイトリスト機能も要件になりますね。

利用中の機能は、AGFで提供なのでパス。

そのあと、フェーズ的には、近接接触者への通知ですね。AGF風には「ばく露通知」です。(ただ、理論的には、変動する近接識別子(Rolling Proximity Identifier@接触符号と訳されていますね)が送信されて、端末で、照合されるので、通知でもないでしょ、という人もいます。そのとおりです。正しく、理解することはとても大切です。) これは、図を貼っておきます(仕様書16頁より)。

この場合に、接触確認がなされると、接触確認フラグが、通知サーバーにいくのですが、保健所はスルーです。でもって、わが国だと、利用者が、保健所には、そのアプリでガイダンスを得て、「必要に応じて連絡」ということになっています。

なので、意図的にと思われますが、本来の「コンタクトトレーシング」という趣旨からは離れて、近接接触者の行動変容を促す、というのに重点がおかれた仕組みになっています。公式には、接触「確認」アプリといっています。

通知サーバー統計機能が記載されています。これは、上の図でいうと、接触確認フラグから統計をとるということですね。(調整中だそうです)

2. ファイルに関する事項

これについては、については、特に注意する事項はありませんでした。

3. 外部インタフェースに関する事項

これについては、日次キーと時刻による診断キーが送出されて、それを各自が手元で照合する仕組みが記載されています。(ここは、DP-3TとAGFの違いになっていたのかな、ここも本の修正が必要なりそうです。すみません。)

第2章 非機能要件の定義

1. ユーザビリティ及びアクセシビリティに関する事項

同意事項が多いこと、直感的操作、適切なガイダンス、視覚的な理解、英語の準備、未成年のための代理登録が触れられています。

2. システム方式に関する事項

システム(中央サーバの仕組みだと思います)は、クラウドサービスを利用することがうたわれています。あとは、OSは、両方、AGF準拠と。

3. 規模に関する事項

スマートフォンの国民の個人保有率が64.7%(令和元年版情報通信白
書)であるので、最大で国民の6割以上が導入することを目指す想定で
基盤等の拡張性を確保する。

だそうです。100%のインストール率を目指しているのかもしれません。個人的には、オプトインは、「スマッジ」ですね。でも、日本人だと奇跡はありうるのかも。ノーベル経済学をもふっとばすアマビエの御札効果ですね。

14日分の接触データ、日次キーの提供でもって、4月6日週レベルで押さえ込むからねという見込みがでています。

4. 性能に関する事項

応答時間(3秒以内)、通信回線の輻輳防止等、ブルートゥースの較正ですね。ブルートゥースの較正は、他の国でも論点になっているという認識です。

5. 信頼性に関する事項

稼働率ですね。

6. 拡張性に関する事項

処理能力の拡張が可能性、モジュール設計、接触カウント機能等の拡張、相互運用性にも対応が触れられています。

国際的な相互互換性について留意すべきことが触れられています。本のなかでは、これも重要な原則の一つとしています。

7. 上位互換性に関する事項

APIによる接続を原則とすることです。

8. 中立性に関する事項

ベンダーロックインの解消等、オープンな標準的技術または製品を用いること、開発ドキュメントの透明性の確保への配慮です。

9. 継続性に関する事項

一時的な停止で大きな社会的混乱を引き起こすものではないこと、端末の機種変更時のデータ引き継ぎは考慮しないことです。

10. 個人情報保護に関すること/11. 情報セキュリティに関する事項

別途の留意事項によります。

12. 情報システム稼働環境に関する事項

国内リージョンのクラウドサービスであることが、明らかにされています。これは、プライバシーやセキュリティの評価の際に問題がでてきます。

13. テストに関する事項

ベータ版のテストも検討することだそうです。

14. 運用に関する事項

通知サーバーの運用の自動化、異常発生時の工夫、FAQの整備、ユーザーとのコミュニケーションなどが記載されています。

15. 保守に関する事項

信頼性、継続性に配慮、サーバーの停止時間ができるだけ短期になるよう配慮、とのことです。

16. 関連ドキュメントの整備

整備されるべきドキュメントとして、利用規約等、設計書及び関連ドキュメント(ソースコード、通知サーバーの運用マニ ュアル含む)、簡易説明およびFAQ があげられています。

ということで、仕様書の分析は、終了。基本的には、このようにオープンな形で検討できるのは、すごくいいですね。


でもって、「接触確認アプリに関する有識者検討会合」で定める個人情報保護・セキュリティに関する留意事項をみていくことになります。

が、この検討は、アマゾンKindle出版で販売されている「新型コロナウイルス対プライバシー-コンタクトトレーシングと法」を6月1日のアップデートを行うなかでしようと思います。