COVID-19に対する日本の水際対策における法的問題と技術的課題（後編）
水際対策の沿革、実態及び法的問題については前編にまとめました。ここを読んでいただける方は法的な解釈よりも技術について興味がある人が多いと思いますが、こちらを後編に持ってきました。後編では技術的課題に絞って議論したいと思います。
2022年3月から水際対策が緩和されているため、以下の情報は古い可能性がありますので、あくまでも過去の水際対策の課題であることにご留意ください。
水際対策における技術的課題
「紙が多すぎる！」
まずは、この一言は言っておかないといけないですね。ユニバーサルアクセスには紙が最も優れていることはわかりますが、感染症予防には物を介した接触も極力控えるべきだと思います。紙を不特定多数とやりとりするスタッフにもリスクはありますが、抗原検査等のスタッフを除き紙のやりとりをするスタッフが1人対応するごとに消毒をするわけではないので、入国者にもリスクが生じます。また、どうしても片手に書類の束を持った状態ではアルコール消毒がしづらいので、やはり適切なデジタル化が必要だと感じました。
一方で、現状の運用においても技術的課題が数多くあります。例えば、MySOSの利用規約やプライバシーポリシーなどは行政手続きのデジタル化を進める上で最もやってはいけないことであるとも感じたので、このような技術的な課題をここでは議論します。
紙中心の入国手続きのデジタルトランスフォーメーションにおける課題
米国（本土）入国では、事前にアプリ（VeriFLYなど）により、eKYC（本人確認）と検査証明書の確認を第三者によりオンラインで行うということで紙のやりとりを減らしています。日本でも最近になりWebでの事前手続きによるファストトラック制度が開始され、デジタル化が進んできました。
一方で、このファストトラックは、MySOSを使うことになっています。前編でも述べたとおり、MySOSの利用規約・プライバシーポリシーは、データ削除に関する規定がなかったり、データがMySOSを提供する会社に帰属することが規定されていたり、日本エマージェンシーアシスタンス株式会社という第三者に個人情報が提供されることになっています。この利用規約・プライバシーポリシーは厚生労働省の発表している検疫業務及び入国者健康確認フォローアップ業務に関するプライバシーポリシーと大きく矛盾します。
行政手続きのデジタル化は重要である一方で、このような行政側のプライバシーポリシーと大きく矛盾するアプリの使用を事実上必須のものとしたり、このようなアプリの使用を拒否することで著しい不利益（例えば、待機施設での停留を余儀なくされること。）を被る状況は、健全なデジタル化を阻害するものとなりうると考えます。
行政手続きにおいて特定のアプリやプラットフォームに依存することは、このような個人情報の取り扱いの問題やそのアプリ・プラットフォームへのアクセスの問題を生じるため、慎重に行う必要があります。基本的には、行政自身の管理・運用の元に、特定のプラットフォームに依存せずに、標準化された技術またはデファクトスタンダードな技術で相互運用性の高い技術を使う（例えば、アプリではなくWebを使用するなど。）ことが好ましいと考えます。
もし、行政自身が管理・運用できず、民間企業等の第三者のアプリ・プラットフォームを使用する場合は、利用規約やプライバシーポリシーに留意し、個人情報等の目的外利用をできないように規定することが必要不可欠であると考えます。また、標準化された技術により実現が困難な場合は、その第三者のアプリ・プラットフォームを使用しないこと（使用できないこと）で著しい不利益を生じないようにするなど、配慮が必要であると考えます。なお、米国入国のための手続きで使用できるVeriFLYのプライバシーポリシーは、そもそも民間航空会社の確認作業の簡略化に用いるものなので行政サービスではないですが、渡航と検疫のために必要な情報のみをその目的のみで使用することが定められており、また、このアプリを使用しなくても搭乗手続きに書類の提示が必要なくらいで大きな不利益はありません。
ファストトラックとVisit Japan Webサービス（デジタル庁）
上記のとおり、入国手続きのデジタル化はMySOSを拡張するという最悪の形で進んでいるようです。
一方で、2021年12月20日以降は、デジタル庁がVisit Japan Webサービスという、検疫や税関手続き等の入国手続きをオンラインで事前に行い、QRコードによりその情報を提示するサービスを提供しているようです（私は2022年1月の入国の際には気づいていなかったので、今度機会があったらこちらを使おうと思います。）。厚生労働省の「検疫業務及び入国者健康確認フォローアップ業務に関するプライバシーポリシー」と大きく矛盾する利用規約・プライバシー ポリシーのMySOSに質問票および誓約書の個人情報ならびにワクチン接種証明書および検査証明書に記載された個人情報を提供するのは、不安でしかありませんので、このようにデジタル庁が行政としてWebサービスを広く普及したWebにより提供してくれることは大変好ましいことです。
しかしながら、上述のファストトラックについては、厚生労働省のファストトラックに関するFAQで、
Visit Japan Webサービスと、MySOSアプリを利用したファストトラックは、どちらも任意でご利用が可能であり、併用いただいても問題ありません。 データの連携はないため、ご利用にあたっては、Visit Japan WebサービスとMySOSアプリでの事前申請をそれぞれに行う必要があります。同じ情報や証明書をそれぞれにご登録いただく必要があります。
（ファストトラックについてよくある質問から引用）
と回答されており、Visit Japan Webサービスだけではファストトラックは利用できず、MySOSとVisit Japan Webサービスに情報を冗長に入力する必要があるとのことです。デジタル庁がこのようなサービスを提供しているのに、ファストトラックにMySOSを採用した理由はまったく理解できません。
ただし、2022年2月8日付けで「検疫ファストトラック対応」という更新履歴が残っているので、もしかしたらMySOSを使わずにファストトラックに対応しているのかもしれません。
健康管理・位置情報の報告・ビデオ通話について
（待機施設における待機期間中健康管理は、富士通のシステムのようでしたが、今回は「厚生労働省の指定するアプリ」であるMySOSを対象とします。）
入国後の健康管理、位置情報の報告、ビデオ通話はMySOSを通じて行うことになっています。MySOSの利用規約・プライバシーポリシーが論外なのは何度も説明してきたとおりです。MySOSを採用した背景として、COCOAの失敗(?)を受けて、厚生労働省が主導して（外注で）アプリを作成し、運用することを躊躇ったのかな、とも邪推しますが、そもそも目的の違う既存のアプリを拡張し、それを必須アプリとして指定するのは、行政としては取ってはいけない策であったと思います。
仮に、MySOSを提供する企業が水際対策に適した技術やアプリを有しており、その既存技術やアプリを水際対策に利用するために厚生労働省から業務委託契約の申し出をするとしても、水際対策とは無関係の機能を取り除いた上で、利用規約・プライバシーポリシーも水際対策のために必要不可欠な厚生労働省の「検疫業務及び入国者健康確認フォローアップ業務に関するプライバシーポリシー」に準ずるもので別アプリとして登録し、指定すべきであったと考えます。
COVID-19の水際対策としては、迅速性のために既存のアプリの機能を利用したり、第三者に委託するなどは仕方がない面はあります。一方で、今回の水際対策のうち、入国後の健康管理、位置情報の報告、ビデオ通話を正しく設計するとしたらどうすればよいのかを考えてみました。
データの所有者と取得・送信
個人情報の持ち主はもちろん個人にあるべきです。水際対策のために、それを「行政」に提供するのであれば、そのデータの送信は「個人」の意思に基づいて、「行政」に対して行うものであるべきです。しかし、MySOSを使うことで、個人情報を行政に提供するわけではなく、MySOSの運営会社である第三者に対して直接提供するような形態となっています。もちろん、厚生労働省からの業務委託として第三者に情報を提供することは、他の行政サービスでも行われていることであります。しかし、その場合は、行政に対して情報を提供することになり、行政機関の保有する個人情報の保護に関する法律（平成十五年法律第五十八号）や行政機関の保有する個人情報の適切な管理のための措置に関する指針についてが適用されるものであると考えられます。一方で、現在の運用方法では、個人情報を行政に直接提供せずにMySOSの運営会社に提供することになり、その会社のプライバシーポリシーにより厚生労働省や法務局に情報が提供されることとなっています。これは、個人情報の持ち主である個人が、感染症の拡大防止のために行政にその情報を提供することに協力したい場合においても、情報の送信先をMySOSの運営会社とせざるを得なくなり、不適切です。
技術的には、MySOSを個人情報（位置情報を含む。）の入力および取得インターフェイスを持った通信アプリとし、その情報をMySOSの運営会社が閲覧・保存することなく「入国者」から「厚生労働省」に対して送信する機能を提供するように作ることは、アプリの設計を大きく変えることなく実現可能であると思います。また、MySOSの運営会社は電気通信事業法の届出をしている事業者であるため、電気通信事業として、この電気通信役務を提供することも問題ないと考えられます。
このようにすることで、個人情報は「入国者」から「厚生労働省」となり、もしMySOSの運営会社や第三者によりそのデータの検証が必要であれば、厚生労働省から行政機関の保有する個人情報の保護に関する法律等に基づき、業務委託先に情報を提供すれば良いと思います。
プラットフォームの多様性とデータの検証
上記において、MySOSからシステム設計を大きく変えない場合は、個人情報を受け取る側もMySOSのシステム内でそのデータへのアクセス権を厚生労働省とすることで実現できると考えられます。もちろん、アプリ内の他の機能との関係で、データベースを分ける等は必要になるかもしれませんが、アプリのUIも入国者専用になっていることからそこは既に（論理的に）分離されているのではないかと推察します。
理想としては、これらのデータを受け取る厚生労働省側のインターフェイスをAPIとして公開し、MySOS以外のアプリからも健康管理情報や位置情報、ビデオ通話（録画）を受け取れるようにすべきであると考えます。この際に、他のアプリからのデータを受け取るために必要なこととしては、データ（特に位置情報）の信頼性の担保（検証）と他のアプリからAPI通信を許可するための認証・認可等が必要となります。
今回の水際対策は迅速性が求められるため、このような第三者アプリやそれ経由で入力・取得されたデータの信頼性を検証する仕組みが困難であることから、データの入力・取得と通信アプリを同一のアプリで実現することは必要であったかとも思います。一方で、行政サービスのデジタル化とその発展には、このような第三者からのAPIを受け付けることが重要であると考えられるため、データの信頼性を担保する仕組みを今後検討する必要があると思います。
もちろん、MySOSのようにデータの送信先までアプリ運営会社にする必要はなく、厚生労働省にすべきです。
誓約書に記入したメールアドレスの確認における課題
入国手続きの中に、誓約書に記載したメールアドレスが有効であることを確認するプロセスがあります。基本的にはこのメールアドレスに対して連絡が来ることはない（濃厚接触者の通知はMySOSで届くらしいです。）ので、まずはこのメールアドレスを誓約書に記入し、厚生労働省および法務省に提供し、それを確認する意味を考えます。
私の知る限り、このメールアドレスにメールが届くのは、入国者健康確認センターへの報告やビデオ通話への応答をしない場合のみです。もちろん私はそのメールを受け取ったことはないのですが、入国者健康確認センターに電話をかけると自動音声でそのような案内があります。なので、氏名公表等の措置をとった際に、「事前に連絡がつくことを確認したメールアドレスに対して氏名公表前に連絡をした。」と主張できるくらいのものであると思います。MySOSの有効化は翌日になることもあり、2日経っても通知が来ない場合は連絡する旨を伝えられますが、入国手続きで連絡が取れることの確認をするのはメールアドレスだけです（電話も確認はありません）。
このメールアドレスの確認方法は単純で、タブレットを持ったスタッフがメールクライアントに誓約書に記載したメールアドレスを入力してメールを送り、入国者のスマートフォン等で受信したことを確認するというものです。ただ、こちらのメールアドレスの確認手法の最大の問題点は、スタッフのタブレットからメールを送信する際の送信元が @gmail.com のメールアドレスであり、Gmail経由で送られてくることです。この方式の問題は、
- 入国者の同意なくGmail（Google）に入国者のメールアドレス情報を提供している。
- その場でメールを受信確認をできるように設定したスマートフォン等が必要であるが、事前にそのような指示はない。
- 事前に
@gmail.comからのメールを許可していないと受信できないが、そのような指示はない。 - 厚生労働省等からの連絡がこれ以外のアドレス（例えば、
go.jpドメインのアドレス）から送られる場合は、そちらのアドレスから受信できる設定になっていることを保証するものではない。また、（ないとは思うが）仮にもし厚生労働省等からの送信元だとすると、@gmail.comから公的なメールを送ることになり、問題である。 - 送信専用であるメールである旨は記載されているが、
@gmail.comからのメールを一度でも公的な確認として使うことで、フィッシングの温床となりうる。
メールアドレスの確認は、通常のECサイト等のWebシステムでも行っているように、システム化すべきであると思いますが、そうでないとしても、タブレットのメールクライアントを使わずに、簡易フォームを使うなど go.jp ドメインからメールを送信するような仕組みを用意すべきだと思います。
国・地域の番号に一貫性がない問題
2021年11月に入国した際には、まだワクチン接種証明書の提出（実際には提示）とワクチンに関する質問がありました。その質問の中に、ワクチン接種国・地域を番号で記入する欄があったのですが、その国・地域の番号が私の持っていた書類と入国時で変わったらしく、「日本」の番号が変わっていました。
その際のフォーマットも検索しても見つからなかったので、国・地域番号の表は見つからなかったですが、私が記入した質問票の写真があったので掲載します。
こちらでは「日本、90」と記載していますが、この90が「日本」ではなく別の国・地域になっていて、日本は（記憶が正しければ）100番以降の番号になっており、訂正を求められました。
こちらの質問票は検疫法第12条に基づく質問であり、虚偽の回答をした場合には罰則も定められているものなので、番号を途中で変えてしまうのはどうかと思います。日本が一番大きい番号になるような謎の配慮があったようにも感じましたが、日本入国に認められる種類のワクチン接種を行っている国・地域が変わり（増加し）、リストが変更されることは想定されるため、日本を分かりやすく1番にしてしまうか、技術者としては、ISOコードを使うとか、そういうユニーク性を担保できる番号体系を使うべきだと思います。
特に、識別子に一貫性がない場合、名寄せが発生するなど、デジタル化の敵でしかないので、この点は最初の設計できちんと検討して欲しいと感じました。
Web質問票のQRコードの改善点
Web質問票の回答結果を保存するQRコードは、入力したデータを形成した生データが入っています。
これ自体はよくある設計ではありますが、航空券等でもよく問題になるように、バーコードやQRコードに個人情報が含まれることに気づかずにSNS等にアップロードしてしまう事例があります。また、QRコードの誤り訂正は強力なので、不用意に表示していると周りの人に読み取られてストーカー被害等の犯罪につながるおそれなども考えられなくはないです。そのため、1) QRコードに個人情報が含まれていることを表示するか、2) 暗号化して保存する（樹里側で復号する）ことが必要ではないかと思います。
暗号化する代わりにシステム側にデータを保存し、識別トークンをQRコードとして表示する方法も考えられますが、システム側のネットワークエラーで入国手続き（検疫）ができないことを考えると、スタンドアロンで動くシステムも一定の意味はあるのかとは思います。また、暗号化も鍵の管理問題はあるので、どちらを採用するかは、設計ポリシーに依ると考えます。（なので、QRコードに個人情報が含まれて居ることを表示するに留めても良いかとは思います．）
MySOSのバグ問題
MySOSのインストールは搭乗前までに済ませていた，というか1度目の入国の際にインストールしたままにしていたのですが、どうやら2度目には対応していないらしく、2022年1月の入国の際に入国者用の画面に遷移せずに、再インストールを余儀なくされました。2度入国する人は珍しいのか、バグで10分くらい悩まされました。
まとめ
後編では水際対策の技術的課題をまとめました。
デジタル庁のVisit Japan Webサービスを知らずに、最初は紙が多すぎだし、MySOSを入国手続きに使うとはけしからん！という気持ちで書き始めたのですが、Visit Japan Webサービスの存在を知って、「デジ庁仕事してる！頑張ってMySOSのような誤った行政サービスのデジタル化を是正して！」という気持ちになりました。