2038年1月19日以降、情報システムが正常に動作しなくなるリスクのこと。システムの設定によっては、それより早く問題が発生する可能性がある。
「2000年になると情報システムが止まる」——。システムが日付を正しく認識できなくなるという、いわゆる「2000年問題」が世間を騒がせました。結果的に大きな影響は出ませんでしたが、多くの企業は対応に大わらわだったことでしょう。
ほっとしたのもつかの間、またしてもシステムにかかわる新たな問題が指摘されています。「2038年問題」がそれです。
コンピュータは、OS（基本ソフト）が内部で時刻情報を保持しています。UNIXの場合、2038年1月19日3時14分8秒を過ぎると、この時刻が狂う可能性があるのです。システムが正常に動作しなくなり、ビジネスに支障を来すことも考えられます。
◆事例
1346万円を誤請求
2038年と聞くとずいぶん先のように思えますが、安心してはいられません。すでにKDDIは、2038年問題が原因でトラブルに見舞われました。
今年1月10日から2月25日の期間に国内電話やネットワーク接続サービスなどを利用した顧客に対して、通話料金を誤って請求してしまったのです。4万5866件の通話で誤請求が発生し、正しい請求額との差は合計で1346万円に上ります。
このトラブルは、課金システムで時刻を正しく認識できなかったことが原因です。通話料は利用した日時によって変わります。顧客がサービスを利用した時刻とシステムが管理する時刻情報にズレが生じ、土日祝日の通話に割高な平日料金を適用したり、逆に平日に割安な休日料金を課金していたのです。
◆対策
OS変更で手を打つ
UNIXは、経過秒数を2進数で保持しており、UTC（協定世界時）と呼ばれる1970年1月1日0時0分0秒に経過秒数を加算して現在の時刻を特定します。
しかし、保持できる秒数が2の31乗（約21億）秒までという制限があるのです。この制限を超えると、1901年12月13日20時45分52秒と誤認識してしまい、正しい時刻を把握できなくなります。
では、なぜKDDIでは2038年よりも早く誤作動を起こしたのでしょうか。それは、トラブルを起こした課金システムが時刻を0.5秒単位で処理していたためです。つまり、通常の2倍の速さで秒数を加算していくため、中間地点に当たる2004年1月10日に保持できる秒数の限界を迎えたというわけです。
2038年問題を回避するには、例えば、OSを変えて保持できる秒数を増やすという方法があります。時刻を基に顧客サービスを提供するシステムを活用している企業は、早めの対応が求められます。
