仕様書 第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日のアップデートを行うなかでしようと思います。

5月17日に、第２回 接触確認アプリに関する有識者検討会合 が開催されて、そこで、「接触確認アプリ及び関連システム仕様書（案）［概要］ 」と「「接触確認アプリ及び関連システム仕様書（案）」に対するプライバシー及びセキュリティ上の評価及びシステム運用上の留意事項（案）の概要 」が公表されています。

また、５月26日に、「接触確認アプリ及び関連システム仕様書」が公表されています。あと、「「接触確認アプリ及び関連システム仕様書」に対するプライバシー及びセキュリティ上の評価及びシステム運用上の留意事項 」も公表されています。

でもって、詳細なコメントが公開されています。

まずは、仕様書からみます。

仕様書は、第１編　総論、第２編　仕様（要件定義）からなります。

第１編 総論
１． 目的

ここでは、接触が確認された者に対して通知をおこなうことが目的であることが記載されています。

２． 前提条件

前提条件として、陽性者との間で、１ｍ以内で、15分以上の近接状態が続いたもの、確認できるのを14日間としています。

アップルとグーグルの枠組を利用すること、個人情報保護についての記載があり、また、仕様書中に調整中の事項があることが留意されています。

３． システムの基本的な考え方

これについては、AGFを利用して構築すること、識別子は周期的に変更されるものであり、個人や端末を特定できないこと、陽性者との接触の照合も各自の端末内で行うこと、 通知サーバーでは、本人同意のもと、陽性者の識別子のみが管理されること、 アプリと通知サーバーは、情報漏洩や侵入を防ぐために十分なセキュリティ上の措置を講じること、がうたわれています。

４． 概要

これは、関係者が「日本国内居住者・滞在者」であること、アプリの概要が記載されています。アプリの概要については、他の分散型の仕組みとだいたい同様です。陽性者の確認を処理番号の通知とその確認で行うのが特徴のように思えます。

５． アーキテクチャと本仕様の範囲／６． アプリケーション詳細

アーキテクチュアは、

 

あと、照合プロセスは、下の図ですね。

 

 

 

 

 

７． 本アプリで定義、使用する識別子、８． スケジュール、９． 体制、
１０． 用語集　は、省略。

なるほどです。これらの図は、わかりやすい。こういう形で、情報が詳細にわかるのは、非常にいいことですね。

---

アマゾン・キンドル出版で、「新型コロナウイルス対プライバシー－コンタクトトレーシングと法」を発売しています。

5月19日にコード・フォー・ジャパンの開発してきた接触確認アプリのソースコードがオープンソースになっています。プレスリリースは、こちらです。

Githubは、管理パネル、api、アンドロイド、iOSの四つのディレクトリから出来ています。

管理パネルをみていきますが、READMEで、データフローをみることができます。概観の大きなファイルは、こちら。

とか、データフローは、こちら（大きくはこっち）。

データの流れは、わかりますね。

この図で、近接接触者に流れる「陽性者交換用デバイスID」を個人情報だろうといっている人がいるのですが、どうなのでしょうね。この接触者が、受信した段階で、あとは、接触者からしか、扱わないですし、その人は、そのデバイスIDしか受信しないので、陽性ユーザが、このIDの人とは、識別できないですよね。

ある人にとって「個人情報」だったら、誰がいつ取り扱おうが、みんな「個人情報」という解釈に毒されているのでしょうか。よくわからないです。

ロゴとかもあります。

細かいところは、json読みきれないので、パスします。ごめんなさい。

今後は、厚生労働省さんが引き継ぐということで、仕様書とかもでています。

基本的な設計で、コンタクトトレーシングのデジタル化というところから、離れてしまったのは、個人的には、反対なのですが、リソースをかけて、きちんと対応しようとしているということで、更に注目していきたいと思います。

 

 

「第１回 接触確認アプリに関する有識者検討会合 開催」が、先週の5月9日に開催されて、その資料が、公表されています。

また、この有識者会合については、「第３回 新型コロナウイルス感染症対策 テックチーム Anti-Covid-19 Tech Team 開催」にいて、正式にテックチームの下に設置が求められたもののようです。(資料 の 8ページ)

有識者会合で提供されている資料で確認しておきしたいのは、以下のとおりです。。

資料４：接触確認アプリの導入に向けた取組について
資料５：接触確認アプリの導入に係る各国の動向について
資料６：接触確認アプリの詳細について（非公開）
資料７：新型コロナウイルス感染症対策としてコンタクトトレーシング
アプリを活用するための個人情報保護委員会の考え方

うち、資料4は、テックチーム資料1-1と同じですね。資料5は、同1-2と同じです。資料7は、個人情報保護委員会の資料です。

資料4をみていきます。

---

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

 

コンタクトトレーシング・アプリケーションについて、欧州・英国・オーストラリアの動向についての注目すべきリンクをまとめて報告した際のスライドをスライドシェアにあげました。

「コンタクトトレーシングとは何か－法律問題と議論」のリンクはこちらです。

なと、スライドでも、書いていますが、現在の予定では、ブログについては整理して、kindle出版等をする予定ですので、コンタクトトレーシング関係の部分については、ブログから近いうちに撤回いたします。

ご了承ください。

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

４月30日　情報コミッショナーは、「コンタクトトレーシング　アプリ開発におけるデータ保護の期待（COVID-19 Contact tracing: data protection　expectations on app development）」という書類を公表します。

—

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。

恐縮ですが、本エントリは、アマゾン社キンドル出版による「新型コロナ出版対プライバシー」出版のために、撤回させていただきます。

出版された際には、是非とも、購入をお願いいたします。