電車が止まる可能性も？実は深刻な｢2038年問題｣ 社会インフラや家電など広範囲で影響大の恐れ

しかし、社会インフラをはじめ、10年どころか20年、30年と使われるシステムは存在します。実際、私の研究室（立命館大学情報理工学部）にて「GitHub」（プログラムのソースコードを共有できるプラットフォーム）を調べたところ、よく使われているソースコードの上位874プロジェクトの3割以上で、「たとえ64ビットに拡張をしても、コード記述が適切でないために2038年問題を起こす可能性のあるプログラム」が検出されました。これは想像以上の多さで、事態は思ったより深刻だと考えています。

ソフトウェアのブラックボックス化を解消する好機に

――GitHubは今や、ソフトウェア開発の標準的なプラットフォームです。そこにも未対応のコードがあるというのは危険ですね。

さらに危ういのは、ソフトウェアの中身を把握できていない場合です。とりわけ家電メーカーは、外国企業と合弁していたり、外部から購入したモジュールを取り付けているケースも多いです。自社製品にどんなソフトウェアが使われているのか、メーカー自身も理解できていないのです。こうした製品は、いざ2038年に不具合が起きた場合、リコールや保証の対応に迫られるかもしれません。

ただ、こうしたリスクを認識はしていても、対策を講じることによるメーカー側のメリットが少ないことが2038年問題の悩ましい点です。どれだけ徹底してもすべての不具合を防げるとは限らないうえ、コストをかけて問題を解決したところで、新しい付加価値がつくわけでもありません。

しかし万が一の場合、人の命に関わるかもしれない問題です。なんとかリソースを割き、「問題があるソフトウェア」を洗い出さなければなりません。私はこの作業に10年かかると踏んでいるため、2028年には動き出す必要があります。そろそろ本格的に周知を進めなくては、と各所で呼びかけているところです。

――ソフトウェアのブラックボックスを解消することは、企業にとって強みにもなりそうです。

はい。何かしらのムダも可視化されるはずなので、業務効率化など副次的な効果は期待できるでしょう。

近い話では、ソフトウェアの脆弱性の管理手法である「SBOM」（Software Bill of Materials）の活用が検討できます。SBOMは「ソフトウェア部品表」と訳されるように、ソフトウェアの構成要素をリスト化する手法で、経済産業省が導入を推奨しています。

2038年問題がどこまで大きな影響を及ぼすかはわかりませんが、何かが起きることは間違いありません。各業界は2028年までにぜひ、「2038年問題に取り組みます」と手を挙げてほしい。一連の作業は、品質向上や業務プロセス改善にもつながります。インシデント対策だけでなく、この機会を企業価値向上にもつなげてほしいです。

東洋経済Tech×サイバーセキュリティでは、サイバー攻撃、セキュリティーの最新動向、事業継続を可能にするために必要な情報をお届けしています。

著者フォローすると、高橋秀和さんの最新記事をメールでお知らせします。