「2038年問題」が桁違いにヤバい
一部システムが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年は今から14年後だが、あと2～3年以内に対策に着手しないと間に合わない可能性があるという。
「まず、何をどうすればよいのかが誰もわかっていない状況から始まるので、正式にプロジェクトを立ち上げて現行システムを調査するのに5年ほどみておく必要があるでしょう。time_t型が64bit型ではないシステムは現在も数多く残っており、それを洗い出し、32bit型から64bit型への改修や、日付の起点の見直しという非常に難しく重い作業をしなければなりません。日付の起点を見直す手法には標準的な手法はないため個別の作業になり、その後のメンテナンス計画も含めた慎重な作業が必要です。幸運にも64bit型へ移行できたとしても、安易な手法では不十分な穴が生じる可能性があるため、改修の計画を立てるのに、さらに5年はかかるかもしれません。残り数年で改修して、なんとか間に合うというイメージではないでしょうか」
詳しくはビジネスジャーナルをご覧ください。
編集者：いまトピ編集部
