ワクチン大規模接種の予約システムで盛り上がっていますが、ニュースに踊らされないことが大切です。
さっき友だち同士のLINEグループで、ワクチン大規模接種東京センターの予約システムについて盛り上がりました。上記のLINEのやりとりはその時のキャプチャーです。（ちょっとだけ加工してます。）
そのやり取りの中で、本件の関係者でもないですし完全に外部からみた意見なので間違っていることもあるかと思いますが、あえてシステムをつくった中の人目線で考察をしてみたのでその内容をまとめてみました。
大昔につくったnote.comのアカウントで初投稿です。ところでnote.muからnote.comにドメイン変わってたんですね。（今更）
ことの始まり
もともとワクチン大規模接種東京センターの予約システムに重大欠陥があると話題になった元の記事はこれです。これを受けて各種マスコミでも取り上げられています。
「架空番号でも予約可能」とあったので、まずは自分で試してみました。下記のデタラメな接種券番号を入れると問題なく次の画面に進みます。
市区町村コード：000000
接種券番号：0000000000
生年月日：1970年01月01日
これ以上先に進むのは迷惑をかけるかもしれないので、一旦検証はこの画面まで。試しに「予約確認・変更・キャンセルはこちら」を押してみると、
すでにキャンセル済みの予約が30件くらいありました。みんな同じこと試してるんだ。そして、「市区町村コード」「接種券番号」「生年月日」の3点が一致すると同一人物だと認証されるんですね。
さて、それぞれのページのソースコードなどを確認した上で、いくつかの観点で思ったことを書いていきます。
このシステムは突貫なのか？
突貫で作ったからこんな欠陥になるんだ、という意見を見かけました。本当かなと思いながらサービス利用規約を確認すると、規約の初版が2021年2月1日となっています。
通常、規約を作成するときは、サービスで保持する個人情報、サービスの責任範囲を明記するため、ある程度のサービス設計が固まっているはずです。この予約システムの設計自体は規約ができるおそらく1月からすでに進んでいたはずです。
ただ、実際に読んでみると、「当センターは、氏名・メールアドレス・電話番号等の個人を識別できる情報を第三者に開示しないものとします」という記載があり、実際には収集していないメールアドレス・電話番号が書かれているので、この時点では予約時の収集情報は決まっていなかったのかもしれません。おそらくシステムの想定としては個人への予約完了通知や、SMSを用いた認証などが想定されていたのかもしれません。
しかし、実際の予約システムでは、入力項目が「市区町村コード」「接種券番号」「生年月日」の3点のみになっています。この2月時点の規約時に想定していた内容と差ができた理由としては、予約のハードルを下げるため、運用を簡素化するためというのが考えられます。
つまり、準備不足で今のシステムになったのではなく、検討の中で、今のシステムに落ち着いたのでは？という空気を感じます。今回は、予約のハードルを下げるために、UIを簡単にするために、そして、運用のトラブルを軽減するために、あえてこの仕様にしたのでしょう。もしかすると、一度メールアドレスや電話番号を入力する前提でシステムを作っていたかもしれません。しかし、プロトタイプやユーザーテストの中で、もしくはその後の実運用を想定したシミュレーションの中で、これでは運用に乗らないという判断をしたのでしょう。
これらのことから、この予約システムは、そもそもの大目的として、とにかくシンプルに予約を取れることを第一優先しており、それ以外のことは優先度を下げていることが考えられます。そのため、後述する色々なものを犠牲にしています。
不正は起きうるのか？
先ほど試した下記の情報。
市区町村コード：000000
接種券番号：0000000000
生年月日：1970年01月01日この入力内容で進んだらマイページにキャンセル済みレコードがたくさん出てきました。この3点の情報で認証をしていること、そしてデタラメな情報でも予約ができること。この状態で考えうる不正は、下記2点です。
1. 接種券番号と生年月日の組み合わせが第三者に漏れたら、勝手に人の予約を変更・キャンセルできてしまう
2. 存在しない予約を大量にされてしまう
ところで、フォーム画面のhtmlを見てみるとちゃんとreCAPTCHA v3が入っていました。安心しました。reCAPTCHAというのはGoogle が提供するCAPTCHA認証システムで、ボットによる不正アクセスを制限する仕組みです。v3でチェックボックスがなくなったので一見すると入ってないようにみえたので少し不安になったのですが、これでボットによる不正操作ははじけそうです。
ということで、それぞれの不正について考えてみます。
1. については、接種券番号と生年月日が一致する必要がありますが、ボットでの総当たり攻撃はしづらくなります。そもそも生年月日だけというのがとても脆弱なので、認証の仕組みを作る上ではパスワードを設定するのが一般的ですが、パスワードの入力負荷やパスワード忘れの対応をするよりも、使いやすさのシンプルさを優先したのでしょう。万が一、接種券番号と生年月日が一致する可能性は起こり得ますが、このシステム上に個人情報があるわけでもないので、リスクはかなり最小化されます。
2. についてもボットでダミー予約を大量にするのが困難ではあるものの手動で頑張ればいくらでもできますが、IPアドレスやブラウザごとに認証情報を保持してるので、同一ブラウザの特定はできそうです。なので、ある程度のダミー予約は予約後でも判別つけられそうです。そしてその怪しいダミーかもしれない予約はわざわざ削除しなくても、怪しい予約枠数分だけ予約枠数を増やしておけば運用上困ることはないでしょう。場合によってはここにすごい頑張って攻撃してくる人がいるかもしれませんが、重要な個人情報が盗みとれるわけでもなく単なる嫌がらせしかできないので、そこまでするモチベーションが起きづらいです。
ちなみに、利用者が間違って情報入力したまま予約を完了してしまうリスクはありますが、これに関してはおそらく現地の運用でうまいこと対応しているのではないでしょうか。一般的にシステムと運用は常にセットであるべきなので、情報入力間違いによる不利益は起きないように柔軟にしているかと思われます。希望的観測です。
誰でも何度でも予約可能、なことは問題か？
この運用の場合「市区町村コード」「接種券番号」の存在チェックや、重複チェックはどこまで厳密に運用をするべきなのでしょうか。この観点がニュースでも話題になった箇所でもあります。
まず、「市区町村コード」「接種券番号」の組み合わせの存在チェックをしようとすると、そのマスターを各自治体から入手してシステムに反映しないといけません。もちろん、その流れが自動化できていれば簡単かもしれませんが、おそらく実際にやろうとするとかなりの運用コストになりそうです。
また、その情報をシステムが保持してしまった時に、仮にゼロデイ攻撃されてしまった場合、不用意にシステムに情報を持たせているのはリスクになります。もちろん、それに耐えれるシステムの設計にするという選択肢もありますが、それをするにはセキュリティ対策に膨大なコストをかけないといけません。
そのため、今回はあえて何もチェックしないという思想にしたのではないでしょうか。ただし、市区町村コードは、オープンになっているしチェックしてもよかったかもしれません。
次に、重複予約のチェックの厳密さですが、確かに下記のデタラメ情報で認証した時に、複数のキャンセル済みレコードが出てきました。
市区町村コード：000000
接種券番号：0000000000
生年月日：1970年01月01日これはおそらくワクチン2回接種の仕様を入れたからじゃないかと推測されます。1回目と2回目をシステムで厳密に分けるより、予約制限をなくして対応して簡素化したんじゃないかと。
これはこれで雑な気もしますが、最終的な本人確認や接種回数は紙ベースで行うので、そのマスター情報と完全に同期を取るよりも、このサービスでは正しい予約情報を管理をしないという選択をしたのでしょう。
複雑な制御をサービスで行なってしまうと、柔軟な運用ができなくなってしまいます。ワクチン接種の場合、例えば、自治体によるワクチン接種とワクチン大規模接種センターとの併用での運用や、電話予約を新たに導入するなどのユースケースが追加されることが考えられます。その時に、こういった運用も含めてシステムで担保しようとすると、複雑性が増して現場も利用者も結果的にわかりにくくなってしまいます。仮に対応したとして、利用者のみなさんから「わかりにくい」「使いにくい」と言われるのは目に見えています。
ニュースでは、「防衛省は『サイバー攻撃による個人情報流出のリスクが高まる』として住民情報との接続には慎重だ。当面は対象外の市町村コードでは予約できなくするなど、簡易な対策を検討する。」とありますが、むしろこの対応で十分なように思えます。
ネットのみの予約は何が問題か？
同じく話題になったのが、予約ができない高齢者の方の記事。
このワクチン大規模接種の予約だけを切り出せば、確かにこの課題はありますが、いくら平等とはいえ、これだけ大量の人に対して接種しようと思うと、何かしらの優先順位をつけなければいつまで経っても接種率が上がりません。これに関しては、常に何事も平等という考えが足枷になってしまいます。
今回はその順番をつける手段として、ネットリテラシーを優先した、ということではないでしょうか。日本全体を俯瞰して考えると、今一番大切なのはいかに効率的に国民の接種率を上げられるかです。そのためには、効率的な運用が求められます。電話でコールセンターを立ち上げるより、圧倒的にネット予約の方がスピーディーに進められる。だからこそのネット予約。
もちろん、アクセス手段にって不平等が生まれてはいけません。しかし、順番を決める上で、ネットから予約というのはとりうる選択肢の中で最善だったのではないでしょうか。まずは高齢者から接種と言っているので、自治体でのワクチン接種では、いずれ遠くないうちにネット予約以外の手段で電話や対面の予約なども今後出てくるでしょう。（すでにあるのかも？）
結局、何が問題だったのか？
この大規模接種のプロジェクトの目的は一体何だったのか。おそらくそれは、完璧な予約サービスではなく、大規模な予約センターをいかに効率的に回して短期での接種者を増やすか、だったのかと思われます。行列を作らず、ここにかける人材とコストを最小限にして、その上で多くの人にワクチン接種をしてもらう。そう考えると、今回の件は最善を尽くした結果だと思えてきます。むしろ、グッジョブと言いたい。
その上で、何が問題だったかと思うと、この運用とシステムの要件を作る人と広報の連携と、これはこういったものだと強く主張する強さが見えなかったのが問題を大きくしてしまった点でしょうか。
揚げ足を取るマスコミやメディアにあまり踊らされたくないニュースだなと改めて思いました。
これらの考察を終えて
あくまでもこれは内部を知らない部外者の考察なので、実際のところはどうだったのかはわかりません。ネット上での画面キャプチャーは確認しましたが、実際の予約画面や完了画面は見ていないので、実装上のセキュリティリスクなどは全ては未確認です。あと、なぜこの会社が受託を受けたのかとか、そういった政治的なことには触れません。
もちろん、完璧を求めればいくらでも対応できます。しかし現実にはQCDの中でベストを尽くさないといけない。という前提で予約システムをフラットに第三者としてみると、むしろこの複雑な要件や仕組みの中で、今回は素晴らしい運用とシステムのバランスに仕上げた（であろう）ことに感心をしました。
きっと中の人は、このニュース騒動を受けて、システムの改修を頑張っているのかと思いますが、批判ばかりするのではなく、批判を消費するだけでなく、接種率が上がるよう何か協力できることがあれば協力しつつ、応援していきたいものです。
※記載内容に嘘やアップデートあれば修正をします。
この記事が気に入ったらサポートをしてみませんか？