神奈川県の緊急速報メール誤送信の原因とテストで防げたのか対策を考察

2022年1月16日にトンガ大規模噴火により、日本の太平洋沿岸などにも津波が到達しました。

https://www3.nhk.or.jp/news/html/20220117/k10013434251000.html
引用：NHKニュースより

この津波を検知して、緊急速報メールが各地に配信されました。
緊急速報メールとは、地震、津波、災害が来たときに、気象庁や、国・地方公共団体からエリアメールを配信するシステムのことです。

https://www.au.com/mobile/anti-disaster/kinkyu-sokuho/
引用：auより

この緊急速報メールは、通常であれば、数回通知を送りますが、神奈川県にいたっては、夜中の0時から朝方にかけて、同じ内容のメールを20回以上送信されました。
20回以上送信してしまったことは、神奈川県の黒岩知事も、誤送信だったと発言されております。

度重なる深夜の津波注意報の誤送信により、多くの県民の皆さんが眠れない夜を過ごされたと思います。また、受験生の皆さんにはたいへんなご迷惑をおかけしました。ホントに申し訳ございませんでした。

— 黒岩祐治 (@kuroiwayuji) January 16, 2022

https://twitter.com/kuroiwayuji/status/1482581758185197572
引用：黒岩知事のTweetより

誤送信の原因

誤送信の原因は、神奈川県の公式発表によりますと、アプリケーションの設定不備が、下記の通りあったとのことです。

本来の設定	今回不備があった設定
津波警報発表時は気象庁から緊急速報メールを配信	津波注意報が発表された段階で緊急速報メールを県が配信
津波警報から注意報に切り替わった段階で緊急速報メールを県が配信	本県以外の津波情報が更新される毎に緊急速報メールを県が配信

https://www.pref.kanagawa.jp/docs/bu4/prs/r1141087.html
引用：津波注意報に伴う緊急速報メールの配信について

本来、県からの緊急速報メールは、津波警報から注意報に切り替わった段階で配信を行います。
しかし、津波注意報が発表されると緊急速報メールを県が配信し、さらに神奈川県以外の津波情報が更新されるごとに緊急速報メールを県が配信していたとのことです。

実にひどい設定のミスです。

アプリケーション考察

なぜこのような事が起こってしまったのか、ここからは私なりの考察です。
システムとして、緊急速報メールは全国で使えるシステムを、神奈川県（エリアごと）に配信できるように設定することができ、下記のような設定値があったのでは無いかと予想しています。

• 情報取得元
• 配信エリア
• 配信条件

こちらの誤った設定を、下記の通り、正しい設定に変更をしたのではないかと考えています。

誤った設定

• 情報取得元 : 全ての通知
• 配信エリア : 神奈川県
• 配信条件 : 注意報以上の情報が更新されるたび

正しく修正した設定

• 情報取得元 : 神奈川県向けの通知
• 配信エリア : 神奈川県
• 配信条件 : 警報から注意報に情報が更新されるたび

今回の誤送信は防げたのか

上記の仕様だったとして、当記事の本題である、誤送信は防げたのでしょうか。

個人的見解は、しっかりとアプリケーションのテストを行えば防げたと思うが、設定差による誤送信を防ぐには念入りな運用テストが必要だと考えています。

念入りなテストと上記で書きましたが、どの程度テストを行えば良いかの基準は、IPAの「高信頼化ソフトウェアのための開発手法ガイドブック」にサンプルが記載されています。

当書のモデル・グレードを参照すると「社会的影響が極めて大きい」に該当し、「社会的影響が極めて大きい」には高信頼性を求められることが分かります。そのためしっかりとテストを行いリリースをする必要があります。

https://www.ipa.go.jp/sec/publish/tn10-005.html
引用：IPA 高信頼化ソフトウェアのための開発手法ガイドブックより

テストについて

高信頼を求められるアプリケーションだから、このテストを必ずやらないと行けないという基準はありません。
しかし大手SIerなど、テスト手法や呼び名は各社ごと違いはありますが、必ずしっかりとしたテストを行っております。

ソフトウェア作成及び、ソフトウェア結合時のテスト

ソフトウェアコード作成時には単体テストや、画面遷移テストを実施し、作成したソフトウェアに不具合が無いか確認をおこないます。

テスト項目は下記の通りです。

• 単体テスト
• 画面遷移テスト
• 脆弱性診断

「単体テスト」は、部品テストや、機能テスト、性能テストなどと呼ばれることもあります。
また、単体テストは、自動でチェックすることも可能で、ウェブアプリケーションの場合は、PHPUnit や、Jenkins などが使われることが多いです。

今回の誤送信は、アプリケーションの不具合ではなく、設定変更をしたことにより、解消したとのことです。そのため、こちらのテスト範囲では防ぐことができなかったと考えることができます。

システム結合時のテスト

ソフトウェアの単体テストに合格すると、システム全体を結合（他システムとのIF連携など）し、実際の運用に沿った形でテストを行います。負荷テストや単純なアクセス権限確認のテストでは、JMeter が使われることが多いです。

テスト項目は下記の通りです。

• 負荷テスト
• 運用テスト
• 障害テスト/障害回復テスト
• 総合テスト

今回の誤送信では、システム結合時に行う、運用テストがしっかりと実施されていれば防げたのでは無いかと考えています。

運用テストとは

運用テストとは、要件仕様に書かれていることが満たされているかの確認と、実際のデータを用いて、商用環境と類似した環境で、実際の操作、手順でアプリケーションが正しく動作するかを確認します。

今回の誤送信を防ぐためには、下記のテスト環境を準備し、具体的に特定の地域障害発生時に、特定の地域に通知されるかのシナリオを実施することで今回の誤送信を防げたのでは無いかと考えています。

• 各エリアの通知を受け取るための環境
• 実際の本番で利用する設定値
• 各エリアごとに擬似的に障害を発生させる

シナリオテストでは、下記サンプルの通り、各都道府県のエリアごとに障害を発生させ、想定通りの通知となるかを試験します。

シナリオテストサンプル

シナリオサンプル：scenario-sample.xlsx

ただ、各エリアごとに障害を発生させ、各エリアごとに通知を確認するためには、膨大なテスト工数がかかってしまいますので、もし私が担当したら、このテストは自動化できるように設計をしたと思います。

また、実際の本番で利用する設定値を使い運用テストを行いますが、この運用テストで使った設定と、商用環境（本番環境）とで、差がでると、商用環境で思った動作になりません。ですので、設定値（環境値は除く）は、Git等のバージョン管理に含めるようにし、運用テスト環境と、商用環境とで差が出ないようにする設計も必要です。

最後に

運用テストを実施した後は、発注側が「受け入れテスト」を行います。受け入れを行いますと、このシステムは要件通りにできていて、問題が無いと判断されたということになりますので、そこからは発注側の責任になります。

神奈川県公式の発表によると下記の通り原因が書かれています。

緊急速報メールを配信するシステムである災害情報管理システムの委託業者によるプログラム設定ミス

これは設定変更を行った後や、何かシステムに改変が入った場合は、運用中のテストがしっかりと実施されていなかったことにも原因があります。テストをしっかりと実施することにより、業者が誤った設定をしてしまったとしても、商用環境へ適用前に気がついたのではないかなと考えています、

また、テストをしっかりやろうとすると膨大な、工数（お金）がかかってしまいますので、テストを縮小されてしまうことも多いです。
しかし今回のような緊急速報メールは、人の生死に関わる重大なシステムと言え「社会的影響が極めて大きい」システムです。このようなシステムを構築する場合は、高信頼性を担保するためにテストをしっかりと実施する必要があります。今回の事態を重く受け止めて、神奈川県はしっかりとしたテスト計画を行ってほしいです。

皆さんも、どれくらいのテストを実施したら良いかが分からない場合などは、IPAのモデル・グレードを参照し、他社の実施状況などを参考にしてみては如何でしょうか。どんなに影響度が小さいアプリケーションだとしても、最低限、単体テスト、結合テスト、運用テスト、受け入れテストは品質担保のためにもしたいところではあります。