「交通局からの報告により、免許センターなどで機器の障害が発生したことが分かった、岡山と神奈川、新潟、愛媛の4県警で免許証の発行の遅れが発生した。新潟県の一部遠隔地の警察署を除いて2月29日の16時時点で復旧した」

　ただし、原因については調査中だ。うるう年によるものなのか、そうでないのかは2月29日の午後16時時点では明言できないという。

　神奈川県警の警察運転免許本部の担当者によれば「2月29日午前8時20分に免許センターの作成機が動かないことが分かり、その後、神奈川県内で免許証を交付する6つの警察署でも同じ障害があることが分かった。午前11時30分には全て復旧したものの、障害があった時間帯に新しい免許を受け取れなかったり、受け取らずに免許センターを離れたりした方が数百人おり、後日免許証を郵送することとなった」という。

　障害の原因については「障害の原因がうるう年だと複数報じられているが、まだ調査中だ」とした。「古い免許証を受け取った後、新しい免許証を作るコピー機のような形状の『免許証作成機』が動作しなくなった。作成機に障害が生じた事例は過去にもあるが、今回の障害とは内容が異なる」と状況をまとめた。

スギ薬局では処方薬の会計が不能に

　ドラッグストアのスギ薬局を全国で1700店舗以上展開するスギホールディングスでも2月29日に障害が起きた。

　広報担当者によれば原因はうるう年だという。「薬局では顧客から処方箋を受け取り、その内容に従って調剤し、会計するという流れで進むが、会計用のレセプトコンピュータ（PC）のソフトウェアに障害が発生した。処方箋の読み取りや調剤には問題がなく、料金の会計処理だけができなくなった。支払いができなかった顧客には後日料金を支払っていただくようお願いした」という。なお、13時時点で全店が復旧済みだ。

ニュージーランドではガソスタが閉鎖

　海外ではさらに大規模な障害も起こった。原因はやはりうるう年だ。ニュージーランドでは全国でセルフサービスのガソリンスタンドが閉鎖された。

　Allied PetroleumやGull、Zといった大手の決済システムに不具合が生じたためだ。ガソリンスタンドでは「Nationwide Payment Outage」（全国的な支払い停止）という看板を掲げて対応したという。

なぜうるう年で障害が起きるのか

　ソフトウェアが原因でうるう年などに不具合が生じる場合、原因は5つ考えられる。

・日付の計算方法の誤り　年や時刻を正しく計算できないOSやアプリケーションプログラムがある場合、日付の処理を誤ってしまい、システムが不整合を起こして停止する可能性がある

・時刻のオーバーフロー　日付や時刻を表すOSやアプリケーションプログラム内の変数の値がオーバーフローする場合がある。この場合もシステムが正しく動作しなくなる

・データベースの設計ミス　データベースに日付情報を格納する際、設計時にうるう年などに対応していないとデータの整合性が失われてシステムが停止する可能性がある

・外部ライブラリやフレームワークの不具合　ITシステムが使用している外部ライブラリやフレームワークに原因がある場合だ

・セキュリティ証明書の期限切れ　うるう年にはセキュリティ証明書の有効期限が誤って計算されてしまう場合がある。証明書の期限切れにより、セキュリティ関連の機能が停止することがある

2000年問題は解決　2025年問題は大丈夫か

　うるう年を含む時刻の問題が起きたのは今回が初めてではない。過去、最も対応にコストを要したのが2000年問題だ。2000年問題では、（1）年号を2桁で扱っていた場合と、(2）2000年がうるう年だという判定に失敗していた場合があった。

　（1）はデータベースやメモリの容量を抑えるために4桁の年号の下2桁だけを扱っていた場合に起きる。2000年を迎えると「1900年」との区別が付かなくなって処理が異常になる。（2）は400年に1回しか起きない不具合だ。うるう年を4で割り切れる年だと処理していると（2）の問題が起きる。実際には4で割り切れ、100で割り切れず、400で割り切れる年がうるう年だからだ。

　2000年問題が次に起こるのは2400年だ。あと376年も猶予がある。だが、「時間」が原因で問題が生じそうな年が迫っている。2025年と2036年、2038年だ。

　2025年は元号に換算すると昭和100年に相当する。プログラムやデータベース内部で年を昭和で表しており、2000年問題と同様に2桁の数値を想定していた場合、2025年が昭和00年になってしまい、不具合の原因になる。

　2036年問題はコンピュータシステム同士の時刻を同期させるプロトコルNTP（Network Time Protocol）が桁あふれを起こすという問題だ。NTPは64bitで1900年1月1日の0時0分0秒からの経過秒数を表している。2036年2月7日にこれが0に戻ってしまうため、NTPが誤動作する可能性がある。

　似たような問題が2038年問題だ。UNIXやUNIXと互換性があるシステムでは1970年1月1日0時0分0秒からの経過時間を32bitで表すと2038年1月19日に桁あふれが生じてしまい、やはり誤動作する可能性がある。

　以上とは多少性格が異なり、不規則に生じる問題もある。うるう秒だ。地球の自転速度は内部や表面の質量分布の変化によって、常に変化している。長い目で見ると次第に自転速度が遅くなるため、極めて正確な原子時計と自転の差が0.9秒を超えたとき、うるう秒を挿入して対応してきた。主に国際標準時（世界時）で6月か12月の月末の23時59分59秒の後に同60秒を挿入するという全世界的な操作だ。これまで1972年から27回挿入されている。

　だが、24時間365日動作するITシステムに悪影響があるため、国際電気通信連合（ITU）は2023年12月11日にうるう秒を2035年までに原則廃止すると決定した。それまではうるう秒による障害を警戒しなければならない。

20XX年問題を起こさないためにどうすればよいか

　うるう年も含め、時間が原因になるシステム障害を予防するにはどうすればよいのだろうか。

　幸いにも予測されている日までは時間がある。まずは自社が利用しているOSやアプリケーションプログラム、データベースなどについて時間問題を検証、改修するための予算を確保することだ。自社と密接に関連する外部の企業のITシステムについても調査が必要だ。ベンダーはもちろん、専門家やコンサルタントに助言を求めて作業の流れを確認するとよい。

　最初に取り組むべきなのはレガシーシステムの更新だ。時間に関連する問題が残っている可能性が最新のシステムよりも高い。システムやプログラムに問題がないかどうかを確認するために、テストと検証が必要だ。

　新しいシステムでも油断はできない。広く使われているOSやアプリケーションでも時間関係の問題が隠れていることがある。定期的にパッチやアップデートを適用しなければならない。

　自社向けにスクラッチ開発されたアプリケーションではアップデートが期待できないことがある。時間に関連するテストケースを含む自動化されたテストスイートを作成し、定期的に実行しなければならない。

　システムを更新し、テストを実施していても問題が起きる可能性はある。そのため、システムの稼働状況や異常をリアルタイムで監視し、早期に問題を検出して対処するモニタリングシステムが必要になる場合もあるだろう。

　最後はバックアップと復旧計画だ。システム障害が発生した場合に備えて、適切なバックアップと復旧計画を策定しておく。障害が発生した場合でも、迅速にシステムを復旧できれば、問題は大きくならない。