blog.s.kbachaun.com

試験公開中です。雑記帳のようになってしまっています。更新頻度は低いです。

記事表示

名古屋市からのエリアメールでnullが表示された問題

インターネット上に掲載されたニュース記事によると、担当者は件名と本文の情報をきちんと入力して送信したとしている。しかし、実際にはnull nullに置き換わって送信されている。なぜnullが複数あるのか、なぜnullになったのか。

そもそもnullが2つある理由

おそらく、件名と本文にパートが分かれていて、それが両方ともnullとなっていたと考えられる。実際のメールではすべて本文であるように見えるが、実際は1行目は件名として機能している。

また、末尾の'(名古屋市)'の表示はnullに置き換わっていないが、これはキャリア側で付与される文面であるため、配信システムの影響を受けない。そのため、nullに置き換わらないと考えられる。

 

なぜnullになったか

おそらくエリアメール(緊急速報メール)は以下の仕組みになっていると考えられる。

[発信用端末]-[各キャリアへのゲートウェイ]-[各キャリアのサーバー]-[各キャリアの基地局・制御装置])[端末]

ここで、発信用端末・各キャリアへのゲートウェイは、名古屋市(あるいは市の委託を受けた業者)の管理で、それ以降のサーバー等は各キャリアごとに管理(キャリアごとに準備)されているものとする。

今回のnull騒動は、特定キャリアのみで発生したわけではなく、すべてのキャリア(docomo,au,Softbank)で発生している問題である(Twiiterなどの画像を参考)。また、調べた限りにおいては、配信システムは各キャリアごとに用意されている。つまり、各キャリアで発生した問題ではないと考えるのが自然である。

次に、件名や本文が空白の状態で送信した場合についてを考える。本来は、本文などが空白で送信しようとした場合、送信前のチェック処理でエラーとして認識し、送信処理は実行されないようにするのが自然である。このようなチェックはコードにしてわずか1-3行程度で実現できる。すなわち、件名や本文を入力せずに送信できる仕様になっている仕様は考えづらく、仮にそのような仕様の場合はシステムに問題があると結論付けるべきであると考えられる。

また、仮に空白で送信できたとしても、それがnullに置き換わる理由が見当たらない。空白であっても文字列として認識できれば、nullとはならずに空白として送信されるはずである。ただし、この点については暗黙の型変換や、送信フォーマットなどの仕様(空文字列とnullが区別できないフォーマットなど)もあるので、一概には言えない。

担当者が意図的に'null'を送信した可能性もあるが、先述の記事では2つの情報をきちんと手で入力して送信したとしている。また、その後の訂正においても'配信エラー'と記してある。したがって、そのような可能性は非常に低い。仮に、これが原因であった場合、担当者は不正な電文を送信したとして、懲戒処分を受けることになり、またその旨が公になると考えられる。

つまり、件名や本文に誤った内容が入力されたとは考えづらく、原因はゲートウェイのサーバー、あるいは発信用端末とゲートウェイとの間の通信路、あるいは端末のソフトウェアの障害であると考えられる。例えば、端末からゲートウェイに電文を送信する際、件名と本文のデータが完全に欠落した(欠落の原因はここでは問わないが、例えばソフトウェアの問題や、通信路の問題などが考えられる)と考える。その場合、ゲートウェイは件名と本文のデータがないことから、データがない=nullと解釈し、各キャリアへ'null'と文字列に変換した電文を送信したと考えることができる。また、ゲートウェイの問題であった場合、例えばデータを処理する段階で何らかの不具合があり、結果としてnullが送出されてしまったとも考えられる。件名は選択式で、本文は件名の選択によって手入力の場合と定型フォーマットがある仕様の場合、件名の選択が定義されていない値となったため、件名がnullとなり、本文についても動作が定義されていないことから値が設定されず、結果的にnullとなったと考えることもできる。しかし、件名が未定義であることにより発生した問題の場合、通常は端末、あるいはゲートウェイサーバー側でチェックされ、送信処理を行わずにエラーとすると考えられることから、データの欠落の問題である、あるいはデータの欠落の問題と件名が未定義であることにより発生した問題が合わさった(件名が未定義値だが、異常な範囲ではないのでチェックを通してしまった)と考えるのが自然である。

ここで、なぜnullのチェックを抜けてしまったのかの疑問がある。この疑問への回答は非常に容易である。単純に''(空文字列)とは比較していたが、null値との比較はされていなかった点(多くの場合、''==nullはfalseとなる)、および、文字列に変換する処理で'null'とされてしまったことにより、キャリア側でのチェックもすり抜けてしまった(多くの場合キャリア側でも本文が空白かのチェックがあると考えられるが、このチェックは空白文字などであった場合にのみ機能し、何らかの文字列が入っている場合は(たとえ'null'であっても)チェックは通ってしまう)と考えることができる。あるいは、文字列に変換した後に空白チェックを行う仕様だった(この場合、文字列に変換した時点で'null'となるため、'null'==''はfalseとなり、またempty('null')などnull値も確認できる空白チェック法であってもfalseとなる)と考えることもできる。つまり、いずれの場合もシステムに欠陥があったため、最後のチェックもすり抜けてしまい、nullとだけ記されたエリアメールが送信されてしまったと考えることができる。

では、なぜ処理の時点で電文がnullとなってしまったのか、また、なぜこのメールだけnullが送出されてしまったのか。この問題のヒントとなるのが、朝日新聞の記事(http://www.asahi.com/national/update/0905/NGY201309050003.html)に記載されている、"約20分後に別のパソコンで送信すると、本来の内容で配信された。"の文面である。このことから、nullが送出されたときに使用していたPC(あるいはそのPCとゲートウェイ間の伝送路)に障害があるか、あるいは、nullが送出されたときに限り、伝送路もしくはゲートウェイに障害が発生したかのいずれかであると考えられる。ここで、今回のnull送出の前に送信された緊急速報メールは正常に送信されていることから、もし、PC(あるいはそのPCに搭載されたソフトウェア)に障害があった場合、そのPCは今回のnull送出の前には使用しておらず、今回のnull送出時に初めて使用した(あるいはnull送出時に初めて不具合が発生する条件(例えば、市内全域を指定した場合に限り不具合が発生するなど)を満たした)と考えないとPCの障害は想定しづらい。そのことから、nullが送出されたときに限りゲートウェイ等に障害が発生したか、あるいはnullを送出するときに障害発生条件を満たしてしまったかのいずれかであると考えられえる。

いずれにせよ、送出システムに問題があることは明らかなので、今後はこのような事態のないよう、早急にシステムの修正を行ってほしい。

参考まで、docomoのエリアメール送信ツールはWebインターフェースを利用しているようだ(参考: http://t.co/Pr3IzNF7 )。しかし、各キャリアに同時に配信する必要があることから、現在は専用のツールを使用している可能性が高い。

参考文献

緊急速報「エリアメール」で誤表示 名古屋市

http://www.chunichi.co.jp/s/article/2013090490225832.html

名古屋市、豪雨情報メール誤配信 意味不明の文面

http://www.asahi.com/national/update/0905/NGY201309050003.html

 

コメント

コメント投稿