「2038年問題」が2000年問題と比べ桁違いにヤバい…社会インフラで障害も

　一部システムが2038年1月19日3時14分8秒以降の時刻になると誤作動を起こす可能性があるとされる「西暦2038年問題」。新たな論文が発表され、一般的に想定されているより広い範囲で大きな影響が出るのではないかという声が広まっている。どのような規模の影響の発生が想定されるのか。また、システム運用者はどのような対策をすべきなのか。9月に論文「32bitを超えるtime_t型を持つ環境における2038年問題とその検出」を発表した立命館情報理工学部教授の上原哲太郎氏に聞いた。

　2038年問題とは、LinuxなどのUNIX環境、C言語プログラムのUNIX timeで表現されたタイムスタンプ値が32bit符号付き整数型で定義されている場合、2038年1月19日3時14分8秒以降の時刻で整数オーバーフローが生じ、それを参照したシステムが不具合・障害を起こすというもの。対策としては、時刻を取得する「time_t」変数の整数型を64bitなどの32bitを超えるデータ型に再定義することが有効だとされているが、上原教授の研究室がGitHub上のC言語レポジトリの上位874プロジェクトを調査したところ、うち294に64bit化しただけでは落とし穴にはまりそうな部分が確認されたという。

「組み込み系・制御系システムに使われるC言語プログラムは、鉄道・航空・エネルギー・工場など大規模な社会インフラで広く使用されており、不具合が生じた際の影響も大きくなります。また、家電製品など販売後はメーカーと所有者の接点が失われる傾向があるモノの場合、何も対策がなされないまま時を迎え、不具合が生じても原因が特定されないというケースも多発する可能性があります」（上原教授）

世界同時に一斉に不具合が発生する可能性

　2038年問題は過去の2000年問題と比較して、桁違いに影響範囲が広く、かつ人々が被る被害は深刻だとという。

「2000年問題は特定の日付を扱うシステムだけが対象であり、大きく影響を受けるのは金融機関の事務システムなど、ある程度限定されており、確かに改修は大変でお金と手間がかかりりましたが、2000年を迎える段階では世の中的には『おそらく大丈夫だろう』というところまでたどりつきました。また対象の多くはCOBOLシステムだったため、調査・改修すべきシステムの数がある程度、絞られたという面もありました。

　一方、2038年問題を起こすC言語は広いシステムで使われる上、『処理Aの●秒後に処理Bを行う』といった経過時間を扱うシステムが対象であり、ありとあらゆるシステムが対象となります。2000年問題で対象となった事務システムは日々の業務の変更に伴って改修が行われるものも少なくなく、それをきっかけに中身を知っている人も多くなりますが、組込み系や制御系のシステムはいったん使用が開始されると改修されず長期間そのまま稼働しているというケースも珍しくなく、気が付くと中身をわかっている人間がいないという状況になりやすい点も対応を難しくさせます。

　また、2000年問題は2000年に年号が変わるタイミングで不具合が生じるため、世界全体で見ると時差1時間ごとに24のタイムゾーンが順番に2000年を迎えることで、先に2000年を迎えたエリアで生じた現象を見て他のエリアが対応を行うということが可能でしたが、2038年問題は世界共通の協定世界時（UTC）の1970年1月1日0時0分0秒からの経過秒数がベースとなるため、世界同時に一斉に不具合が発生します」（上原氏）

　すでに2038年問題に起因する障害は起きている。2004年、KDDIの一部システムは0.5秒単位で時刻を認識していたため、1秒単位で時刻を認識するのに比べて半分しか経過秒数を保持できず、1970年と2038年の真ん中に当たる2004年1月10日にオーバーフローが発生。通話料金の課金システムで不具合が生じ、一部ユーザへの誤請求が生じた。このほか、同年には日本IBM製ソフトウェアで不具合が生じてシステムが正常な日時を取得できなくなり、複数の銀行のATMで障害が発生した。

あと2～3年以内に対策に着手しないと間に合わない

　2038年は今から14年後だが、あと2～3年以内に対策に着手しないと間に合わない可能性があるという。

「まず、何をどうすればよいのかが誰もわかっていない状況から始まるので、正式にプロジェクトを立ち上げて現行システムを調査するのに5年ほどみておく必要があるでしょう。time_t型が64bit型ではないシステムは現在も数多く残っており、それを洗い出し、32bit型から64bit型への改修や、日付の起点の見直しという非常に難しく重い作業をしなければなりません。日付の起点を見直す手法には標準的な手法はないため個別の作業になり、その後のメンテナンス計画も含めた慎重な作業が必要です。幸運にも64bit型へ移行できたとしても、安易な手法では不十分な穴が生じる可能性があるため、改修の計画を立てるのに、さらに5年はかかるかもしれません。残り数年で改修して、なんとか間に合うというイメージではないでしょうか」

（文＝Business Journal編集部、協力＝上原哲太郎／立命館大学情報理工学部教授）