見た目は最新でも、中身は20年前。AI時代になっても変われない日本企業
2026年9月、カーシェアリングサービス「タイムズカー」で大規模な個人情報漏えい事件が発生した。
運営元のパーク24が公表した情報によると、不正アクセスによって約660万件ものアカウント情報が第三者に取得されたという。
漏えいした情報には、氏名、住所、電話番号、メールアドレスだけでなく、運転免許証情報や本人確認書類の画像なども含まれていた。
クレジットカード情報の漏えいは確認されていないものの、非常に深刻な事件である。Park24
そして、この事件をきっかけに、IT技術者の間であることが話題になった。
タイムズカーのWebシステムに、約20年前の技術が使われている可能性が指摘されたのだ。
個人的には、この話を聞いて驚いたというよりも、「やはり日本の大規模システムには、こういう問題が残っているのか」と感じた。
もちろん、古い技術が使われていることと、今回の不正アクセスの原因は別問題だ。
しかし、これだけAIが進化した時代になっても、古いシステムを刷新できない日本企業の体質については、考える必要があると思う。
Webサイトには、利用者から見える部分と見えない部分がある
そもそもWebシステムは、大きく「フロントエンド」と「バックエンド」に分かれている。
フロントエンドとは、私たちが普段ブラウザで見ている画面のことだ。
例えば、ログイン画面、予約画面、ボタン、メニュー、画像などが該当する。
HTML、CSS、JavaScriptといった技術で構成されており、ブラウザに配信されたソースコードは誰でも確認できる。
一方、バックエンドは、その裏側で動作しているプログラムだ。
会員情報の管理、ログイン認証、予約処理、データベースへのアクセスなど、サービスの中核となる処理を担当している。
こちらは通常、利用者からソースコードを見ることができない。
普段からWebサイトの内部構造を気にしている人など、IT技術者でもなければほとんどいないだろう。
大半の人は、画面のデザインや操作性を見る程度だ。
だからこそ、仮にバックエンドが20年前に開発されたものであっても、フロントエンドだけを新しくすれば、利用者には最新のWebシステムに見えてしまう。
見た目が新しいことと、システムの中身が新しいことは、まったく別の話なのである。
タイムズカーで見つかった古いJavaフレームワークの痕跡
今回、タイムズカーのWebサイトについて、技術者から興味深い指摘があった。
公開されているHTMLの中に、次のようなJavaScriptの読み込み記述が残っていたという。
<script src="/view/teedaExtension/org/seasar/teeda/ajax/js/ajax.js?20201217"></script>ここに登場する「Seasar」と「Teeda」は、かつて日本の業務システム開発で利用されていたJavaのフレームワークだ。
Seasar2は2000年代に普及した国産のオープンソースフレームワークで、2016年にサポートが終了している。
Teedaは、そのSeasar2を利用したWebアプリケーションフレームワークである。System Design Works
つまり、少なくとも公開されているWebページには、現在ではサポートされていない古い技術の痕跡が残っていたことになる。
ただし、この記述だけでバックエンド全体がSeasar2で動いていると断定することはできない。
また、今回の不正アクセスがSeasar2やTeedaの脆弱性によって発生したという証拠もない。
それでも、もし現在もサポート終了済みのフレームワークが本番システムの中核で使われているとしたら、セキュリティ面で大きな懸念がある。
なぜなら、サポートが終了したソフトウェアでは、新たな脆弱性が発見されても、公式の修正プログラムが提供されない可能性が高いからだ。
JavaのStrutsやSpringでも重大な脆弱性が発見されてきた
JavaによるWebシステム開発では、Seasar2以外にもさまざまなフレームワークが利用されてきた。
代表的なものが「Apache Struts」と「Spring Framework」だ。
これらは、Webシステムを効率的に開発するための仕組みを提供している。
ただし、どれほど広く使われているフレームワークであっても、セキュリティ上の問題が発見されることはある。
例えば、Apache Struts 2では2017年に「CVE-2017-5638」という重大な脆弱性が発見された。
特定の条件下で、外部から不正なリクエストを送ることにより、サーバー上で任意のコードを実行できてしまうというものだ。
また、Spring Frameworkでも2022年に「Spring4Shell」と呼ばれる脆弱性（CVE-2022-22965）が公表された。
こちらも特定の環境や構成において、リモートからコードを実行される危険性があった。
いずれも、攻撃者に悪用されれば、サーバーの乗っ取りや情報漏えいにつながりかねない重大な問題である。
もちろん、StrutsやSpringを使っているだけで危険というわけではない。
重要なのは、使用しているバージョンと、適切なセキュリティ対策が行われているかどうかだ。
新しい脆弱性が発見されれば、開発元から修正版が提供される。
しかし、古いシステムでは、その修正版を適用すること自体が難しい場合がある。
例えば、フレームワークを更新すると既存のプログラムが動かなくなる。
Javaのバージョンを上げる必要がある。
Javaを更新すると、今度は別のライブラリが対応していない。
このように、古いシステムほど依存関係が複雑になり、簡単には更新できなくなってしまう。
結果として、脆弱性が存在する可能性を認識しながらも、システムを変更できないという状況が生まれる。
セキュリティ上の問題が見つかっても、修正できない。これこそが古いシステムを維持し続ける大きなリスクなのだ。
なぜ古いシステムを使い続けるのか
では、なぜ企業は古いシステムを使い続けるのだろうか。
理由の一つは、システムを刷新するためのコストだ。
大規模なWebシステムでは、何十万行、場合によっては何百万行ものプログラムが存在する。
それらをすべて解析し、新しい環境に移行するには、膨大な費用と時間が必要になる。
さらに厄介なのが、長年の改修によって複雑化したプログラムだ。
当初の開発者はすでに退職し、設計資料も十分に残っていない。
なぜその処理が必要なのか、どの機能と関連しているのか、誰も正確に把握していない。
いわゆる「ブラックボックス化」である。
こうなると、システムを変更すること自体が大きなリスクになる。
結果として、企業は既存システムを延命させるという選択を取りやすくなる。
しかし、ここで考えてほしい。
その判断は、AIが登場する前の常識に基づいていないだろうか。
AIの登場によって、古いシステムの刷新は現実的になった
以前であれば、古いプログラムを解析するには、技術者が一つずつソースコードを読み解く必要があった。
しかし、現在は状況が大きく変わっている。
生成AIの進化によって、ソフトウェア開発の効率は飛躍的に向上した。
例えば、AIを使えば、次のような作業を支援できる。
- 古いJavaプログラムの構造解析
- StrutsやSeasar2から新しいフレームワークへの移行
- 複雑なプログラムの処理内容の説明
- 既存コードからの設計書の生成
- セキュリティ上の問題点の洗い出し
- 自動テストの作成
- 新旧システムの動作比較
これらは、従来であれば多くの技術者が膨大な時間をかけて実施していた作業だ。
もちろん、AIがすべてを完璧に処理できるわけではない。
業務上の細かなルールや、特殊な例外処理などは、人間による確認が必要になる。
それでも、AIを使うことで、これまで費用や時間の問題から手を付けられなかったシステムの刷新が、現実的な選択肢になりつつある。
特に、古いプログラムの解析や、新しい言語・フレームワークへの移植といった作業は、AIの能力を活用しやすい分野だ。
ただし、セキュリティが重要なシステムでは、AIによるコード生成だけでなく、テストや第三者による検証も欠かせない。
重要なのは、AIにすべてを任せることではなく、AIによって人間の開発能力を大きく拡張することなのである。
日本はAI活用でも世界に遅れを取るのか
個人的に最も気になるのは、日本企業のAIに対する姿勢だ。
AIが登場しても、情報漏えいが心配、生成したコードが正しいか分からない、社内ルールが整っていないといった理由で、導入に慎重な企業は少なくない。
もちろん、企業がセキュリティや品質を重視するのは当然だ。
しかし、それを理由にAIの活用そのものを避けていては、何も変わらない。
例えば、機密性の高いプログラムであれば、外部にソースコードを送信しないローカル環境でAIを動かすという選択肢もある。
AIが生成したコードの品質が心配なら、人間がレビューし、自動テストで検証すればよい。
実際、従来のソフトウェア開発でも、人間が書いたコードが必ず正しいわけではない。
人間が作ったプログラムにもバグは存在するし、セキュリティ上の問題も発生する。
AIだけに完璧さを求めるのは、少し違うのではないだろうか。
むしろ重要なのは、AIをどのように使い、どのように品質を保証するかという仕組みを作ることだ。
世界中でAIを活用したソフトウェア開発が進む中、日本企業が従来の開発手法に固執していれば、開発速度やコスト面で競争力を失っていく可能性がある。
日本は平和ボケしているのだろうか
少し厳しい言い方になるが、こうした状況を見ると、日本は平和ボケしているのではないかと感じる。
今のシステムが動いているから問題ない。
大きな障害が発生していないから、わざわざ作り直す必要はない。
システム刷新にはお金がかかるから、もう少し先送りしよう。
そうした判断を繰り返しているうちに、技術はどんどん古くなっていく。
そして、いざ問題が発生したときには、システムの構造を理解できる技術者もいなければ、簡単に修正する方法もない。
今回のタイムズカーの事件について、古いフレームワークが直接の原因だったかどうかは、現時点では分からない。
しかし、もしサポートが終了した技術を使い続けていたのであれば、そのリスクをどのように管理していたのかは気になるところだ。
特に、数百万人もの個人情報を扱うシステムであれば、なおさらである。
企業にとって、システムを変更しないことは、一見すると安全な選択に見えるかもしれない。
しかし、変更しないことによって、セキュリティ上のリスクが積み重なっていく場合もある。
これまでの日本企業は、安定性や品質を重視することで、高い信頼を築いてきた。
それ自体は素晴らしいことだと思う。
ただ、その慎重さが、新しい技術を取り入れない理由になってしまっては本末転倒だ。
AIの進化によって、ソフトウェア開発の常識は大きく変わろうとしている。
今までのやり方が正しかったからといって、これからも正しいとは限らない。
最後に
タイムズカーの約660万件の個人情報漏えい事件は、単なる一企業のセキュリティ問題として片付けるべきではないと思う。
日本には、長年にわたって使われ続けているWebシステムが数多く存在する。
その中には、すでにサポートが終了したフレームワークやライブラリを使用しているものもあるだろう。
もちろん、古いシステムだからといって、必ずしも危険とは限らない。
適切な保守やセキュリティ対策が行われていれば、長期間にわたって安全に運用できる場合もある。
しかし、問題は、そうした対策が十分に行われているかどうかだ。
そして、今はAIという強力な技術がある。
これまで難しかった古いプログラムの解析やシステムの刷新も、AIを活用することで、以前より効率的に進められる可能性がある。
それなのに、従来のやり方を変えようとしないのであれば、非常にもったいない話だ。
20年前のプログラムを使っていることが問題なのではない。20年前の考え方のまま、システムを運用し続けることが問題なのだ。
そして、AIがこれだけ進化した今、その考え方を変える絶好の機会が訪れているのではないだろうか。
参考資料
- パーク24：タイムズカーWebシステムへの不正アクセスに関する調査結果（2026年9月28日）
- タイムズカー漏えいに学ぶ：古いフレームワークを使い続けるリスク — 公開HTMLに残るSeasar2／Teedaの痕跡についての技術的考察
- IPA：Apache Struts 2の脆弱性を悪用した攻撃 — 国内でも実際に情報漏えい被害が発生したことを解説 IPA 独立行政法人 情報処理推進機構
- Spring公式：Spring4Shell（CVE-2022-22965） — Spring開発元による脆弱性の技術解説
