2026年9月、タイムズカーのWebシステムが不正アクセスを受け、約660万件のアカウント情報が第三者に取得されたことが公表されました。そのうち約160万件では、運転免許証画像などの本人確認書類情報も漏えいしています。
本稿は、2026年10月2日時点の公式発表および一般公開されたWebページをもとに整理したものです。調査の進展や公式発表の更新により、内容が変わる可能性があります。
このニュースを見て、「うちのWebサイトは大丈夫だろうか」と気になった方も多いのではないでしょうか。私たちも公開情報を追うなかで、現在の技術構成や、長く運用されてきたシステムをどう保守していくべきか議論するきっかけになりました。
公開HTML上では、Teedaに由来すると考えられる文字列やパスを確認できます。ただし、これらは現在のサーバー内部の構成、利用バージョン、稼働状況を示すものではありません。また、公式発表では侵入原因が明らかにされておらず、本件との関連を示す証拠もありません。特定の技術を原因と決めつけず、確認できた事実と一般的な考察を明確に分けながら、古いWeb基盤を抱える企業が見直すべきポイントを整理します。
この記事でわかること
- タイムズカー不正アクセス事案について、公式発表で確認できる事実
- 公開HTMLから読み取れる技術的な手掛かりと、断定してはいけないこと
- 古いWeb基盤を抱える企業が、集客と安全性を両立しながら刷新する進め方
何が起きたのか—公式発表の時系列
タイムズカーは2026年9月25日9時07分、Webシステムへの不正アクセスを検知しました。第三者がシステムへアクセスした形跡を確認し、翌26日7時25分までに侵入経路と攻撃元からの通信を遮断しています。第1報の時点では、氏名、住所、生年月日、電話番号、メールアドレス、会員番号、免許情報、本人確認書類、法人会員情報、連携サービスIDなどが漏えいした可能性があるとされました。
9月28日の第2報では、約660万件のアカウント情報が第三者に取得されたことを公表。対象には現会員だけでなく、退会済みの利用者や、入会手続きが完了しなかった人も含まれます。クレジットカード情報の漏えいは確認されておらず、パスワードは復元できない形式で保存されていたと説明されています。サービス提供への影響も確認されていません。
翌29日の第3報では、運転免許証画像などの本人確認書類情報が漏えいしたアカウントが約160万件にのぼることが明らかになりました。10月1日時点でも外部専門機関による調査が続いており、個別の漏えい内容は調査結果を踏まえて案内するとしています。
約660万件という規模に加え、退会済みの利用者や入会未完了者の情報も対象に含まれていました。ただし、公表情報だけでは、各情報の保有目的や保存期間、その妥当性までは判断できません。今回の保存が不適切だったと断定するものではなく、一般論として、企業が保有する個人情報の範囲・保存期間・削除ルールを定期的に確認する重要性を示す事例といえます。
日付
公表内容
2026年9月25日
不正アクセスを検知。個人情報漏えいの可能性を公表
2026年9月26日
侵入経路と攻撃元からの通信を遮断
2026年9月28日
約660万件のアカウント情報の取得を確認
2026年9月29日
約160万件の本人確認書類情報の漏えいを確認
※ ここは重要なので改めて触れておきます。本稿執筆時点で、公式発表には具体的な侵入手法や脆弱性、原因となった製品名は記載されていません。技術構成とインシデント原因は分けて考える必要があります。
公開HTMLから分かるのは、あくまで「手掛かり」
タイムズカーの一般公開ページを確認すると、HTML上に「Teeda」と呼ばれるWeb開発技術に由来すると考えられる記述が残っています。Teedaは以前、日本のWebシステム開発で使われていた技術の一つで、公式なメンテナンスはすでに終了しています。
ただし、外から見える記述だけでは、現在もその技術が使われているのか、どの範囲で動いているのかまでは分かりません。過去のファイルや記述だけが残っている可能性もあります。もちろん、今回の不正アクセスとの関係も確認されていません。
ここで伝えたいのは、「古い技術が見つかったから危険」という話ではありません。長く運用しているWebシステムでは、担当者の交代や改修の積み重ねによって、全体像が見えにくくなりがちです。
自社サイトについて、どの技術が動いているのか、サポートは続いているのか、問題が起きたときに誰が更新できるのか。まず、この3点を説明できる状態にしておくことが大切です。
レガシーWebシステムでリスクが積み上がる5つの理由
1. 修正プログラムが提供されない
サポート終了後は、新しい脆弱性が見つかっても公式の修正版が提供されない可能性があります。アプリケーション本体だけでなく、OS、Java、ライブラリ、ミドルウェア、外部APIまで含めて考える必要があります。
2. 「誰も全体を知らない」状態になりやすい
長年の機能追加や担当者交代によって、設計書と実装が乖離します。使われていないように見える機能が重要な業務とつながっていることもあり、更新を避ける判断が続きがちです。
3. 個人情報の保有範囲・保存期間が見直されにくい
今回の対象には退会済みの利用者や入会未完了者も含まれました。ただし、各情報が保存されていた理由や保存期間の妥当性は、公表情報だけでは判断できません。一般論として、収集時には必要だったデータでも、法令や契約上の保存義務を踏まえながら、保有目的、保存期間、削除ルール、保管場所、アクセス権限を定期的に見直すことが重要です。
4. 売上に直結するため止められない
予約、会員、問い合わせなどを担うWebシステムは、全面停止して作り直すことが困難です。その結果、短期的な改修が優先され、基盤の更新が後回しになります。
5. 制作と保守が分断される
公開をゴールにすると、監視、パッチ適用、バックアップ復元確認、変更履歴、緊急連絡網が曖昧になります。セキュリティは制作時のチェック項目ではなく、公開後も続く業務です。
AIの発展も、攻撃の増加に影響している
最近、個人情報漏えいのニュースが増えたように感じる背景には、AIの発展も無関係ではありません。ただし、AIが自動的にシステムへ侵入しているというより、攻撃の準備や試行を、以前より速く・安く・大量に行えるようになったと考えるのが近いでしょう。
たとえば、自然な日本語のフィッシングメールを作る、相手に合わせて内容を変える、公開されているシステムの弱点を探す、といった作業にAIを利用できます。攻撃者の「手数」が一気に増えた、と考えるとイメージしやすいかもしれません。
VerizonやIBMの最新レポートでも、AIが攻撃を効率化している一方、実際に狙われるのは、更新されていないシステムや弱い認証といった従来からある隙だと指摘されています。[1] [2]
つまり、AIは新しい原因というより、攻撃の加速装置です。だからこそ、派手な最新対策を追う前に、システムの更新、認証、監視、不要なデータの整理といった基本を続けられる状態にしておく必要があります。
もちろん、防御側もAIを活用できます。大量のログから異常を見つけたり、対応の優先順位を整理したりすることは、AIが得意な領域です。攻撃側だけでなく、防御側もAIを使う前提で運用を考える時代になっています。
集客を止めずに刷新するための現実的な進め方
では、古いシステムが見つかったら、すぐに全面リニューアルすべきなのでしょうか。実際には、費用や業務への影響を考えると、一度にすべてを入れ替えるのは現実的ではないケースも多くあります。
まずは事業への影響とリスクを整理し、優先順位をつけて段階的に進めるのが現実的です。
Step 1｜現状を棚卸しする
まず、ドメイン、サーバー、OS、CMS・フレームワーク、ライブラリ、データベース、外部連携、管理アカウント、保守期限を一覧化します。公開HTMLだけではなく、サーバーとソースコードの実態まで確認することが必要です。
Step 2｜守るデータと機能を分類する
氏名やメールアドレスだけでなく、本人確認書類、行動履歴、退会者情報などを洗い出します。「収集する」「保存する」「利用する」「削除する」の各段階で、必要性と権限を見直します。
Step 3｜緊急対策と刷新計画を分ける
WAFやアクセス制御、不要アカウントの停止、パッチ適用、ログ監視など、すぐに実施する対策と、CMS・フレームワーク移行のような中長期施策を分けます。緊急対策だけで刷新を先送りせず、刷新だけを待って現在のリスクを放置しないことが重要です。
Step 4｜売上・問い合わせ導線から段階移行する
集客サイトでは、SEO評価、広告の遷移先、フォーム、計測タグ、CRM・MA連携を維持する必要があります。リダイレクト、構造化データ、GA4イベント、フォーム計測を移行計画に含め、機能単位・ページ群単位で切り替えます。
Step 5｜公開後の保守を設計する
担当者、更新頻度、承認フロー、監視項目、バックアップと復元手順、障害時の連絡先、変更履歴の管理方法まで決めます。運用できない対策は、時間とともに形骸化します。
YOAKEの対応事例 — 放置されていたCMSからの侵入
あるWebサイトの運営企業から、「サーバー事業者から不正ファイルが設置されていると通知が届き、サイトが表示できなくなった」と緊急のご相談をいただきました。制作当時の担当会社とは関係が切れており、サイトの構成を把握している人がいない状態でした。
調査の結果、長く更新されていなかったCMS拡張機能の脆弱性から侵入され、約1週間にわたって攻撃者の活動が続いていたことが分かりました。
YOAKEでは、データベースのバックアップでコンテンツを保全したうえで、バックドアが残る可能性を考慮して公開領域をいったん全削除。安全な簡易ページで公開を継続し、各種パスワードの変更を依頼しました。感染したCMSを部分的に修復するのではなく、「一度空にして、安全な状態から立て直す」判断がポイントです。
原因は高度な攻撃ではなく、誰にも把握されないまま古いCMSが動き続けていたことでした。本稿で触れた「誰も全体を知らない」「制作と保守の分断」が、そのまま表れた例といえます。
※ 本事例は、YOAKEが実際に対応したケースを企業名を伏せて掲載しています。
こうした経験を踏まえ、YOAKEでは契約範囲や対象システムに応じて、CMS・OSの更新、外部監視、バックアップ取得確認、実施ログの記録などを組み合わせたWebインフラ保守を設計しています。インシデントを完全にゼロにする保証はできませんが、異常の早期発見と、更新忘れ・属人化を減らす運用体制づくりを支援できます。ホームページ保守の作業内容や外注時のポイントもあわせてご覧ください。
まず確認したいチェックリスト
- 利用中のCMS・フレームワーク・OSのサポート期限を把握している
- サーバー、ドメイン、外部サービスの管理者と契約主体が分かる
- 保存している個人情報と保存期間を説明できる
- 退会者・離脱者・テストデータの削除ルールがある
- 不要な管理者アカウントを定期的に停止している
- セキュリティ更新を定期的に実施し、履歴を残している
- 異常検知の通知先と一次対応者が決まっている
- バックアップから実際に復元できることを確認している
- リニューアル時にSEO・広告・計測・フォーム移行を考慮している
- 制作会社・開発会社との保守範囲と責任分界が明確になっている
答えられない項目が複数ある場合は、全面刷新の前に「現状調査と優先順位づけ」から始めることをおすすめします。
まとめ — 古いかどうかより、把握して改善し続けられるか
今回の事案について、現時点で特定の製品名を「原因」と決めつけることはできません。原因が明らかになる前に断定してしまうと、本当に必要な対策から目をそらすことにもなります。
一方で、「まだ動いているから大丈夫」と古い仕組みを使い続けるのも不安が残ります。サポートが終了した技術、担当者にしか分からない構成、削除ルールが曖昧な個人情報。思い当たるものがあれば、いきなり作り直すのではなく、まず棚卸しから始めてみてください。
Webサイトが集客や顧客接点を担うほど、セキュリティとマーケティングは切り離せません。守るための運用と、成果を伸ばすための改善を、同じ計画の中で考えることが大切です。
FAQ
Q. Teedaを使っていると危険なのでしょうか？
Teedaを使っているという情報だけで、直ちに危険とは判断できません。ただし、公式メンテナンスが終了した製品を利用している場合、依存ライブラリや実行環境も含めて、脆弱性への対応方法と移行計画を確認する必要があります。
Q. WAFを導入すればリニューアルは不要ですか？
WAFは有効な防御策の一つですが、アプリケーションの脆弱性、不要な権限、データ保持、運用不備をすべて解消するものではありません。短期対策として活用しながら、基盤更新や運用改善を進める必要があります。
Q. 古いサイトを止めずに移行できますか？
多くの場合、段階移行が可能です。機能・データ・URLを棚卸しし、検証環境、リダイレクト、データ同期、切り戻し手順を準備したうえで、優先度の高い領域から切り替えます。
Q. 最初に依頼すべきことは何ですか？
現状調査です。技術構成、データ、権限、外部連携、保守期限、集客導線を可視化すると、緊急対策と中長期の刷新計画を分けて判断できます。
