タイムズカー漏えいに学ぶ:自社システムを点検する6つの質問

2026年10月2日
News

こんにちは!システムデザインワークスの渡辺です。

タイムズカー(パーク24)の約660万件の情報漏えいを題材にした連載の最終回です。第1回では、公式発表の事実と、公開HTMLに残っていたサポート終了フレームワーク Seasar2/Teeda の痕跡を事実と推測に分けて整理しました。第2回では、AIによって脆弱性発見と「狙う先探し」が自動化され、「小さい会社だから狙われない」が成立しなくなったこと、そしてフレームワークを新しくしても防げない「被害を大きくする設計要因」を見てきました。

最終回は「では、どうするか」です。

結論を先に書きます。弊社の方針は、守りを厚くする前に、攻撃面を構造的に小さくすることです。「完璧に守る」のではなく、「そもそも守るべき場所を減らす」。この考え方で弊社のコーポレートサイトをどう作っているかを例として公開し、最後に、自社のWebサービスを点検するための6つの質問をまとめます。経営者の方や情報システム担当の方は、開発ベンダーにそのまま聞いてみてください。

本連載は2026年10月2日時点の公開情報に基づいています。


タイムズカー漏えいに学ぶ(全3回)

  1. 第1回:古いフレームワークを使い続けるリスク

  2. 第2回:AIが変えた攻撃の常識

  3. 第3回:自社システムを点検する6つの質問(本記事)


弊社のコーポレートサイトはどう作っているか — 攻撃面を構造的に小さくする

弊社は「まず自社で試してからお客様に提案する」スタイルなので、自社サイトの構成を例に、どう考えて作っているかを共有します。

攻撃面(アタックサーフェス)とは、攻撃者が入り込める可能性のある入口の総量のことです。 弊社がサイトを設計するときの方針は、「守りを厚くする」より前に、この攻撃面を構造的に小さくすることです。

弊社のコーポレートサイトの構成は次のとおりです。

  • ホスティング: Cloudflare Workers(サーバーレス)。自社で管理するOSやミドルウェアを持ちません。OSのパッチ適用漏れ、放置されたポート、古いWebサーバーといった「よくある入口」が存在しません。DDoS 防御と WAF(Webアプリケーションファイアウォール)は Cloudflare のエッジで標準的に効いています。詳細はVercel から Cloudflare Workers へフル移行した記録で公開しています

  • CMS: Headless CMS(Payload CMS)。Headless CMS とは、記事などのコンテンツ管理機能だけを提供し、サイトの表示は別のフロントエンドが担う構成の CMS のことです。 公開ページは事前に生成された静的なページとして配信されるため、訪問者のリクエストが直接データベースに届く経路がほとんどありません。従来型の CMS で頻発する「プラグインの脆弱性からの侵入」という構造も持っていません

  • 持たないデータは漏れない。弊社サイトは会員制サービスではないので、そもそも免許証画像のような機微なデータを保持していません。お問い合わせフォームの内容は、Cloudflare Turnstile によるボット対策を通した上で受け付けています。「保持するデータを最小限にする」は、最も確実な漏えい対策です

  • 依存ライブラリの継続更新と定期点検。Next.js、Payload CMS、各ライブラリは継続的にバージョンを追従しています。また、公開HTMLやHTTPヘッダに不要な情報が露出していないか、攻撃者目線で定期的に点検しています

正直に書いておくと、この構成でも「絶対に安全」ではありません。 弊社が使っているフレームワークにも将来脆弱性は見つかるでしょうし、設定ミスは誰にでも起こり得ます。だからこそ「攻撃面を小さくして、問題が起きたときの影響範囲を限定し、更新と点検を続ける」という姿勢を取っています。安全を宣言するのではなく、構造と運用で備えるということです。

あなたの会社のWebサービスを点検する6つの質問

自社のWebサービスや業務システムを点検するための6つの質問です。開発ベンダーにそのまま聞いてみてください。 即答できない項目があれば、そこが点検の出発点です。

#

質問

「危ない」兆候

1

使っているフレームワーク・ライブラリとそのサポート状況を一覧で出せますか?

一覧がない。「作った会社しか分からない」。Seasar2 / Struts 1 / 古い PHP など EOL 製品が含まれている

2

公開HTMLやHTTPヘッダから、使用技術とバージョンが読み取れませんか?

ブラウザの「ソースを表示」でフレームワーク名やバージョンが見える

3

「ログインした本人のデータしか返さない」チェックは、すべてのリクエストで行われていますか?

画面側で制御しているだけで、サーバー側の非同期リクエストはIDを変えれば他人のデータが見える

4

本人確認書類などの機微なファイルは、会員情報と別の場所に隔離されていますか?

画像が同じサーバー・同じストレージに、URLを知っていれば見える状態で置かれている

5

退会者や未完了者のデータの保持期間と削除手順は決まっていますか?

「消していない」「法律があるので全部残している」。保管義務のあるデータも本番DBに置いたまま

6

普段と違う大量のデータ読み出しを検知し、遮断する仕組みはありますか?

アクセスログは取っているが誰も見ていない。検知から遮断までの手順が決まっていない

質問1と2が「侵入されにくくする」ための点検、質問3から6が「侵入されても被害を小さくする」ための点検です。第2回で見たとおり、この両方が必要です。

点検して「危ない」兆候が出たら

6つの質問で「危ない」兆候が出ても、すぐにシステムを全部作り直す必要はありません。優先順位の付け方の目安を書いておきます。

  1. まず「被害を小さくする」側(質問3〜6)から着手する。 フレームワークの移行は時間がかかりますが、機微なファイルの隔離、退会者データの切り離し、大量読み出しの監視は、既存システムのまま比較的短期間で手を打てます

  2. 次に、露出を減らす(質問2)。 HTMLやヘッダからフレームワーク名・バージョンを消すだけでも、機械的な「狙う先探し」の対象になりにくくなります。根本対策ではありませんが、費用対効果は高い

  3. 最後に、土台の更新(質問1)を計画する。 EOL フレームワークからの移行は、段階的に進める計画と、切り戻せる形での実施が要点です

まとめ:連載全体の学び

  • 原因が未公表でも、学べることはある。 タイムズカーの事件は2026年10月2日時点で原因が公表されていません。それでも「EOL フレームワークの痕跡が公開HTMLに見えていた」「退会者を含む全会員のデータと画像が一度に流出した」という公開情報だけで、多くの企業に共通する構造的な課題が見えてきます

  • 攻撃側の前提が変わった。 AIによって脆弱性発見と「狙う先探し」が自動化され、企業規模で選別される時代は終わりました。「小さい会社だから狙われない」は成立しません

  • 「侵入されにくくする」と「侵入されても被害を小さくする」の両方が必要。 フレームワークの更新だけでも、データの隔離だけでも足りません

  • 弊社は「攻撃面を構造的に小さくする」方針で、サーバーレス + Headless CMS + 保持データの最小化 + 継続更新と定期点検という構成を採っています。 それでも「絶対に安全」とは言いません。構造と運用で備え続けることが、現実的な答えだと考えています

よくある質問

6つの質問に開発ベンダーが答えられない場合、どうすればよいですか?
まず「答えられない」こと自体を記録し、ベンダーに期限を切って回答を求めてください。それでも出てこない場合は、第三者による現状調査(使用技術の棚卸し、公開情報の露出確認、データ保持状況の確認)を依頼する選択肢があります。弊社でもこうした現状把握からのご相談をお受けしています。
サーバーレスや Headless CMS にすれば、情報漏えいはなくなりますか?
いいえ。攻撃面は構造的に小さくなりますが、「絶対に安全」にはなりません。フレームワークの脆弱性や設定ミスは、どの構成でも起こり得ます。弊社も自社サイトについて「安全」とは言わず、「攻撃面を小さくし、影響範囲を限定し、更新と点検を続けている」と表現しています。構成の選択は、守るべき場所を減らす手段の一つです。
既存の古いシステムを、すぐに作り直す必要がありますか?
すぐに全面的な作り直しが必要とは限りません。優先順位としては、まず機微なファイルの隔離・退会者データの切り離し・大量読み出しの監視といった「被害を小さくする」対策を既存システムのまま進め、並行してフレームワーク移行の計画を立てるのが現実的です。移行は段階的に、切り戻せる形で進めることが要点です。

ご相談お待ちしております。

「6つの質問、半分も即答できなかった」という方も多いのではないでしょうか。それは珍しいことではなく、多くの企業に共通する状態です。大切なのは、今回の事件を「他社の話」で終わらせず、自社の点検の出発点にすることだと考えています。

栃木県でシステム開発・アプリ開発・Web サイト制作の会社をお探しの方、既存のWebサービスや業務システムのセキュリティ点検、サポート終了したフレームワークからの移行、Cloudflare を活用した攻撃面の小さいサイト構築をご検討中の方へ。 システムデザインワークスでは、自社サイトで実践した構成と点検の経験をもとに、現状の棚卸しから設計の見直し、移行・運用まで一貫してサポートしております。「まず何から点検すればいいか」というご相談からで構いません。お気軽にお問い合わせフォームよりご連絡ください。