仕様書 第1編を見た「接触確認アプリ」の仕様書について （1)のに続いて、第2編 仕様(要件定義)です。
第２編 仕様（要件定義）
要件定義は、機能要件と非機能要件に分かれています。
第１章 機能要件の定義
１． 機能に関する事項
これは、さらに基本機能(インストール)、認証機能、あと、アップル・グーグル枠組(Apple Google Frameworkですね、AGF)で実現する機能にわけて論じられています。アップル・グーグル枠組は、私のブログだと、既に見ているし、あと、本で、触れています。
インストールで興味深いところは、オプトインで、利用規約、ブルートゥース利用の案内、通知機能利用の確認がなされることが確認されているところです。また、同意の撤回についても、確認がなされています。
陽性利用者の接触履歴のアップロードが、「認証機能」という名称のもとで論じられています。これが、「認証機能」たるゆえんは、「いたずらの陽性者の通知を防止する」ための陽性者の端末の認証という趣旨ですね。
これは、世界でも共通の問題意識で、シンガポールは、保健所の職員がワンタイムパスワードでいれる仕組みですね。イギリスのNHSXは、自己申告の症状でもOKとしているので、ちょっと問題という記事を読みました。
この部分のフローと画面遷移の記載があります。
あと、近接接触した人数の総計の画面表示については、AGと調整中のようです。家族との間を近接接触といわれてもなんで、ホワイトリスト機能も要件になりますね。
利用中の機能は、AGFで提供なのでパス。
そのあと、フェーズ的には、近接接触者への通知ですね。AGF風には「ばく露通知」です。(ただ、理論的には、変動する近接識別子(Rolling Proximity Identifier@接触符号と訳されていますね)が送信されて、端末で、照合されるので、通知でもないでしょ、という人もいます。そのとおりです。正しく、理解することはとても大切です。) これは、図を貼っておきます(仕様書16頁より)。
この場合に、接触確認がなされると、接触確認フラグが、通知サーバーにいくのですが、保健所はスルーです。でもって、わが国だと、利用者が、保健所には、そのアプリでガイダンスを得て、「必要に応じて連絡」ということになっています。
なので、意図的にと思われますが、本来の「コンタクトトレーシング」という趣旨からは離れて、近接接触者の行動変容を促す、というのに重点がおかれた仕組みになっています。公式には、接触「確認」アプリといっています。
通知サーバー統計機能が記載されています。これは、上の図でいうと、接触確認フラグから統計をとるということですね。(調整中だそうです)
２． ファイルに関する事項
これについては、については、特に注意する事項はありませんでした。
３． 外部インタフェースに関する事項
これについては、日次キーと時刻による診断キーが送出されて、それを各自が手元で照合する仕組みが記載されています。(ここは、DP-3TとAGFの違いになっていたのかな、ここも本の修正が必要なりそうです。すみません。)
第２章 非機能要件の定義
１． ユーザビリティ及びアクセシビリティに関する事項
同意事項が多いこと、直感的操作、適切なガイダンス、視覚的な理解、英語の準備、未成年のための代理登録が触れられています。
２． システム方式に関する事項
システム(中央サーバの仕組みだと思います)は、クラウドサービスを利用することがうたわれています。あとは、OSは、両方、AGF準拠と。
３． 規模に関する事項
スマートフォンの国民の個人保有率が64.7％（令和元年版情報通信白
書）であるので、最大で国民の６割以上が導入することを目指す想定で
基盤等の拡張性を確保する。
だそうです。100％のインストール率を目指しているのかもしれません。個人的には、オプトインは、「スマッジ」ですね。でも、日本人だと奇跡はありうるのかも。ノーベル経済学をもふっとばすアマビエの御札効果ですね。
14日分の接触データ、日次キーの提供でもって、4月6日週レベルで押さえ込むからねという見込みがでています。
４． 性能に関する事項
応答時間(3秒以内)、通信回線の輻輳防止等、ブルートゥースの較正ですね。ブルートゥースの較正は、他の国でも論点になっているという認識です。
５． 信頼性に関する事項
稼働率ですね。
６． 拡張性に関する事項
処理能力の拡張が可能性、モジュール設計、接触カウント機能等の拡張、相互運用性にも対応が触れられています。
国際的な相互互換性について留意すべきことが触れられています。本のなかでは、これも重要な原則の一つとしています。
７． 上位互換性に関する事項
APIによる接続を原則とすることです。
８． 中立性に関する事項
ベンダーロックインの解消等、オープンな標準的技術または製品を用いること、開発ドキュメントの透明性の確保への配慮です。
９． 継続性に関する事項
一時的な停止で大きな社会的混乱を引き起こすものではないこと、端末の機種変更時のデータ引き継ぎは考慮しないことです。
１０． 個人情報保護に関すること/１１． 情報セキュリティに関する事項
別途の留意事項によります。
１２． 情報システム稼働環境に関する事項
国内リージョンのクラウドサービスであることが、明らかにされています。これは、プライバシーやセキュリティの評価の際に問題がでてきます。
１３． テストに関する事項
ベータ版のテストも検討することだそうです。
１４． 運用に関する事項
通知サーバーの運用の自動化、異常発生時の工夫、FAQの整備、ユーザーとのコミュニケーションなどが記載されています。
１５． 保守に関する事項
信頼性、継続性に配慮、サーバーの停止時間ができるだけ短期になるよう配慮、とのことです。
１６． 関連ドキュメントの整備
整備されるべきドキュメントとして、利用規約等、設計書及び関連ドキュメント（ソースコード、通知サーバーの運用マニ ュアル含む）、簡易説明およびFAQ があげられています。
ということで、仕様書の分析は、終了。基本的には、このようにオープンな形で検討できるのは、すごくいいですね。
でもって、「接触確認アプリに関する有識者検討会合」で定める個人情報保護・セキュリティに関する留意事項をみていくことになります。
が、この検討は、アマゾンKindle出版で販売されている「新型コロナウイルス対プライバシー－コンタクトトレーシングと法」を6月1日のアップデートを行うなかでしようと思います。
