JR東日本の新幹線システム障害

　雪の影響かと思われていた東北新幹線のシステム障害の原因が、システムの制限値を認識していなかったという、ある意味人為的ミスによるものと明らかになった。安全性を最大の売りにしている日本の新幹線だけに、この事実はやや複雑な問題をはらんでいるといえそうだ。

JR東の新幹線システム障害、原因は処理限度値のオーバー(ITmedia)

　列車の運行のスケジューリングは結構難しい問題であることは明らかである。現在は当然ながらコンピュータシステムで運用管理されているから安全なはずだが、何かトラブルが起きたときの対応が最終的には人間がダイアグラム表をにらめっこしながら経験と勘で決めるということになっていそうだ。

　運行当初よりも列車数が増えたために、運行に遅れが生じたときなどの影響が多くの場所や時間に影響を及ぼす。すべてがうまく切り抜けられるように各駅で入線番線や停車時間を各列車を調整する。あちらを立てればこちらが立たずのような、迷路を抜けるような試行錯誤が必要になるだろう。実はこれは「巡回セールスマン問題」と同様のことになる。影響を受ける列車数が増えると、あっというまにその場合の数が増加して適切な解を見出すのが困難になってくる。

　コンピュータは基本的にしらみ潰しでその可能性をチェックするから、場合の数が増えればそれだけ処理時間も急激に伸びる。システム導入当初に「1分間に600件まで」の上限値が設けられていたのは、処理数が増えると処理時間がかかり過ぎることになって、リアルタイムでの処理が難しくなると判断されていたからではないのか。現在はCPUやメモリなどのリソースは増えているはずだから、以前の上限値よりはもっと大きく設定はできたかもしれない。しかし無制限（上限なし）にすると、いつまでも応答が返ってこなくなるかもしれない。だからこれはソフトウェアのバグという問題ではなくて、やはり上限値が存在することを運用側が認識していなかったか、結果オーライで昔の設定のままで通用すると思っていたところが問題だろう。何やらかつての2000年問題を連想させる。2000年問題は2000年になると日付が上限に達してリセットされることが早くから認識されていて、それに対する修正も行われてきたために大きな混乱は発生しなかった。しかし新幹線の方は上限値が認識されていなかったために、今回のトラブルに繋がったということになる。上限値はむしろ、かつては安全策として設定されたいたはずだからである。