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

- 公開日: 2026-10-02
- 更新日: 2026-10-08
- URL: https://systemdesignworks.co.jp/news/%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%BA%E3%82%AB%E3%83%BC%E6%BC%8F%E3%81%88%E3%81%84%E3%81%AB%E5%AD%A6%E3%81%B6%EF%BC%9A%E8%87%AA%E7%A4%BE%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E7%82%B9%E6%A4%9C%E3%81%99%E3%82%8B6%E3%81%A4%E3%81%AE%E8%B3%AA%E5%95%8F
- 発行: 株式会社システムデザインワークス

> タイムズカー（パーク24）の約660万件漏えいを題材にした連載の最終回です。弊社のコーポレートサイトが「攻撃面を構造的に小さくする」ために採っている構成（Cloudflare Workers のサーバーレス、Headless CMS、保持データの最小化、継続更新と定期点検）を具体的に公開したうえで、経営者や情報システム担当の方が開発ベンダーにそのまま聞ける「自社のWebサービスを点検する6つの質問」をまとめます。即答できない項目があれば、そこが点検の出発点です。

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

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

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

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

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

---

**タイムズカー漏えいに学ぶ（全3回）**

1. [第1回：古いフレームワークを使い続けるリスク](/news/タイムズカー漏えいに学ぶ：古いフレームワークを使い続けるリスク)
2. [第2回：AIが変えた攻撃の常識](/news/タイムズカー漏えいに学ぶ：AIが変えた攻撃の常識)
3. **第3回：自社システムを点検する6つの質問（本記事）**

---

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

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

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

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

- **ホスティング: Cloudflare Workers（サーバーレス）**。自社で管理するOSやミドルウェアを持ちません。OSのパッチ適用漏れ、放置されたポート、古いWebサーバーといった「よくある入口」が存在しません。DDoS 防御と WAF（Webアプリケーションファイアウォール）は Cloudflare のエッジで標準的に効いています。詳細は[Vercel から Cloudflare Workers へフル移行した記録](/news/vercel-to-cloudflare-workers-migration)で公開しています
- **CMS: Headless CMS（Payload CMS）**。**Headless CMS とは、記事などのコンテンツ管理機能だけを提供し、サイトの表示は別のフロントエンドが担う構成の CMS のことです。** 公開ページは事前に生成された静的なページとして配信されるため、訪問者のリクエストが直接データベースに届く経路がほとんどありません。従来型の CMS で頻発する「プラグインの脆弱性からの侵入」という構造も持っていません
- **持たないデータは漏れない**。弊社サイトは会員制サービスではないので、そもそも免許証画像のような機微なデータを保持していません。お問い合わせフォームの内容は、[Cloudflare Turnstile によるボット対策](/news/contact-form-bot-protection-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 + 保持データの最小化 + 継続更新と定期点検という構成を採っています。** それでも「絶対に安全」とは言いません。構造と運用で備え続けることが、現実的な答えだと考えています

## よくある質問

**Q. 6つの質問に開発ベンダーが答えられない場合、どうすればよいですか？**

A. まず「答えられない」こと自体を記録し、ベンダーに期限を切って回答を求めてください。それでも出てこない場合は、第三者による現状調査（使用技術の棚卸し、公開情報の露出確認、データ保持状況の確認）を依頼する選択肢があります。弊社でもこうした現状把握からのご相談をお受けしています。

**Q. サーバーレスや Headless CMS にすれば、情報漏えいはなくなりますか？**

A. いいえ。攻撃面は構造的に小さくなりますが、「絶対に安全」にはなりません。フレームワークの脆弱性や設定ミスは、どの構成でも起こり得ます。弊社も自社サイトについて「安全」とは言わず、「攻撃面を小さくし、影響範囲を限定し、更新と点検を続けている」と表現しています。構成の選択は、守るべき場所を減らす手段の一つです。

**Q. 既存の古いシステムを、すぐに作り直す必要がありますか？**

A. すぐに全面的な作り直しが必要とは限りません。優先順位としては、まず機微なファイルの隔離・退会者データの切り離し・大量読み出しの監視といった「被害を小さくする」対策を既存システムのまま進め、並行してフレームワーク移行の計画を立てるのが現実的です。移行は段階的に、切り戻せる形で進めることが要点です。

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

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

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