3月1日に起きた航空管制システムの障害は、直前のプログラム変更をきっかけに、NECが昨年9月に行ったシステム改修時のバグが顕在化したことが原因だった。NECはバグに気づいていたが、昨年9月以降、特に問題がなかったために対策をとらなかった。国土交通省のテストも不十分だった。

写真●3月1日の管制システム障害は、1日だけで約27万人の足に影響を及ぼした。 写真は当日の羽田空港 （写真提供＝日本経済新聞社）

　障害が発生したのは、国土交通省の東京航空交通管制部が運用する飛行計画情報処理システム（FDP）。すべての航空機の飛行計画を航空会社などから集約して一括処理し、各航空機の管制業務に必要な便名、行き先、飛行経路などの情報を、全国各地の管制部門に対して出力する重要なシステムだ。

　1995年9月に稼働した現行のFDPは、NECがシステム全体の構築を担当し、2台のメインフレーム（ACOS3600）とともに納入した。システム改修も、すべてNECが担当している。

　障害が起きた3月1日は、防衛庁と東京航空交通管制部が飛行計画をやり取りするための「防衛庁システム対応プログラム」をFDPに追加する日だった。3月1日午前1時、管制部の技術陣は予定通りNECが開発した同プログラムをインストール。FDPは問題なく始発便の運行データを出力し始めた。ところが午前7時、突然FDPがダウンする。

NEC社内で仕様が曖昧になりバグに

図●FDPがダウンするまでの動き

　障害が起きたのが午前7時だったことから、当初は「オンライン統計処理プログラム」と、追加した防衛庁システム対応プログラムの間で、何らかの不具合が生じたものとみられていた。オンライン統計処理プログラムは、毎日午前7時に前日分のFDPの処理をまとめた統計データを関係各所へ送信する。

　しかし、どちらのプログラムにも問題はなく、昨年9月にFDPに追加された「共通データ処理プログラム」にバグがあったことがダウンの原因だった。同プログラムは、FDP内の様々なプログラムに共通する処理を実行するもの。オンライン統計処理プログラムでも処理作業のなかで利用していた。

　ダウンを引き起こしたバグは二つある（図[拡大表示]）。一つは「メモリ空間において、共通データ処理プログラムの読み込み領域（参照範囲）が所定の範囲を超えると、システム全体がダウンする」というもの。これは、共通データ処理プログラムがオンライン統計処理プログラムに割り当てられたデータ領域を読み込む場合にのみに起きるバグだった。

　「FDPは、こうした事態を防ぐ『フェイルセーフ機能』を実装しているが、オンライン統計処理プログラムに関する処理には、同機能を適用していなかった」（NEC広報）ことも災いした。

　さらに本誌の取材で、「共通データ処理プログラムが読み込むデータ領域の範囲が、当初の仕様では『最大4Kバイト』だったのに対し、実装されたものは『常に4Kバイト』だった」というバグが存在したこともわかった。

　「割り当てられたデータ領域の範囲をチェックする機能があれば、所定の範囲を超える問題は発生しなかった」（国土交通省 航空局管制保安部保安企画課）。実際には、オンライン統計処理プログラムに割り当てられていたデータ領域の大きさは、わずか90バイト程度だった。

　なぜ仕様が「最大」から「常に」へ変わったのかについてNECは、「当社で設計している過程でプログラムの仕様が曖昧になってしまったため」（広報）と答えている。

　これらのバグが、3月1日のシステム改修を機に顕在化した。同日午前7時、いつものように共通データ処理プログラムは、オンライン統計処理プログラムに割り当てられたデータ領域を読み込み始めた。ところが処理の途中で所定の範囲を超えてしまった。これをFDPが「不正な処理」と見なし、システム全体のダウンに至った。

　防衛庁システム対応プログラムの追加を受けて、各プログラムに割り当てられたメモリ内のデータ領域が再配置され、「オンライン統計処理プログラムに割り当てられていたデータ領域が、所定の範囲ぎりぎりのところまで移動した」（保安企画課）ことが原因だった。

　NECは今年1月末の時点で、これらのバグに気づいていたが、改修作業などは行わず、国交省へも報告しなかった。「昨年9月の共通データ処理プログラムの追加時から、すでに8回もプログラム追加を行ってきたが、特にトラブルがなかった」（広報）ことが理由だ。

　この時点で何らかの対策をとっていれば、今回のトラブルは起きなかった。NEC幹部は3月11日、バグの存在を報告しなかったことについて国交省に謝罪。これを受けて国交省は、被害を受けた航空会社とともに、NECに対する損害賠償請求の検討に入った。