タイムズカー漏えいに学ぶ：AIが変えた攻撃の常識
こんにちは！システムデザインワークスの渡辺です。
第1回では、タイムズカー（パーク24）の約660万件の情報漏えいについて、公式発表で確認できる事実と、公開HTMLに残っていた「2016年にサポートが終了したフレームワーク Seasar2/Teeda」の痕跡を、事実と推測に分けて整理しました。原因は2026年10月2日時点で未公表です。
第2回のテーマは、「古いフレームワークは危ない」という昔からの話が、なぜ今、以前よりはるかに深刻になったのかです。
結論を先に書きます。弊社が最も重要だと考えているのは、脆弱性を見つける作業と、その脆弱性を持つサイトを探す作業の両方が、AIによって自動化され、コストが桁違いに下がったことです。攻撃側はもう「狙う価値のある大企業」を人間が選ぶ必要がありません。条件に合うサイトを機械的に全部リストアップして、順番に試せばよいのです。「うちは小さい会社だから狙われない」は、成立しない前提になりました。
そしてもう一つ。フレームワークを最新にすれば解決、という話でもありません。全会員のデータが1か所に集まり、画像が同居し、退会後も何年もオンラインにある設計のままでは、どこか1か所の穴から同じ規模の被害が出ます。後半でこの「被害を大きくする設計要因」を整理します。
本連載は2026年10月2日時点の公開情報に基づいています。
タイムズカー漏えいに学ぶ（全3回）
第2回：AIが変えた攻撃の常識（本記事）
AIは攻撃側の何を変えたのか — 脆弱性発見と「狙う先探し」の自動化
変化1: 公開コードの脆弱性を、AIが人間より速く見つけるようになった
2024年から2026年にかけて、AIによる脆弱性発見の実績が立て続けに公表されました。いずれも一次情報として確認できるものです。
公表時期 | 主体 | 内容 |
|---|---|---|
2024年11月1日 | Google Project Zero / DeepMind | AIエージェント「Big Sleep」が、SQLite の未知のメモリ安全性の脆弱性を発見。「AIエージェントが広く使われる実ソフトウェアで未知の悪用可能な脆弱性を見つけた最初の公開事例」と発表。従来のファジング（150 CPU時間）では見つからなかった |
2025年6月24日 | XBOW | 自律型ペネトレーションテストAIが、バグ報奨金プラットフォーム HackerOne の米国リーダーボードで1位に。90日間で約1,060件を報告、うち重大度「Critical」54件・「High」242件。提出前に人間のセキュリティチームがレビュー |
2025年10月31日 | OpenAI | 自律型セキュリティ調査エージェント「Aardvark」を発表。テスト用リポジトリで既知および人為的に埋め込んだ脆弱性の92%を検出 |
2026年4月7日 | Anthropic | 「Project Glasswing」を公表。AIがオープンソースソフトウェアの脆弱性を大規模に発見。OpenBSD の27年前から存在したバグ、FFmpeg の16年前のバグなどを含む。2026年8月26日時点で392のプロジェクトに2,300件を開示 |
ここで注目したいのは、FFmpeg の「16年前のバグ」や OpenBSD の「27年前のバグ」です。Anthropic の報告書には「モデルのスケーラビリティにより、本来なら十分に監査済みとして見過ごしてしまうファイルも含めて、重要なファイルのほぼすべてでバグを探せる」という趣旨の記述があります。つまり、長年誰も見ていなかった古いコードほど、AIにとっては「未発見の脆弱性が眠っている場所」になるということです。
Seasar2 や Teeda のソースコードは、EOL 後も GitHub 上に公開されたままです（これはオープンソースとして自然なことで、問題ではありません）。しかし、「公開されているが誰も保守していないコード」は、攻撃側の AI にとって格好の調査対象になります。見つけた脆弱性を直す人がいないからです。
変化2: 「そのフレームワークを使っているサイト」を探す作業も自動化された
脆弱性を見つけただけでは攻撃はできません。攻撃側は次に「その脆弱性を持つサイトはどこか」を探す必要があります。従来、これは手間のかかる作業でした。
しかし、Webフレームワークの多くは、HTMLやHTTPレスポンスに**そのフレームワーク固有の痕跡（フィンガープリント）**を残します。第1回で紹介した /view/teedaExtension/org/seasar/teeda/... というパスは、その典型です。このようなパスは Teeda を使っているサイト特有のもので、インターネット全体をクロールして収集したHTMLから機械的に検索できます。
検索エンジンや、インターネット上のサーバーを網羅的にスキャンして情報を蓄積するサービスは、以前から存在します
AIエージェントは、こうしたデータソースを横断して「特定の文字列を含むサイトの一覧を作る」「そのサイトのバージョンを推定する」「侵入の優先順位をつける」までを、人手を介さず実行できるようになりました
念のため強調しますが、タイムズカーが実際にこの手順で狙われたと言っているわけではありません。ここで述べているのは一般論です。しかし、この一般論が成り立つ以上、「公開HTMLにEOLフレームワークの痕跡が見えている」という状態は、それだけで「私はここにいます」と攻撃側に知らせているに等しいのです。
変化3: 「うちは小さい会社だから狙われない」が成立しなくなった
変化1と変化2を合わせると、攻撃側のコスト構造が変わります。かつては「狙う価値のある大企業」を人間が選んで攻めていました。今は、条件に合うサイトを機械的に全部リストアップし、順番に試すことができます。そこに企業規模の判断は入りません。弊社が自社サイトを Cloudflare Workers へ移行した記事でも書いたとおり、「小さい会社だから狙われない」は、もう通用しない前提です。
フレームワークを最新にしても防げない「被害が660万件になる」設計上の要因
ここまで読むと「フレームワークを新しくすれば解決」と思われるかもしれません。しかし弊社は、今回の事件のもう一つの教訓はそこではないと考えています。
仮にフレームワークが最新だったとしても、次のような設計であれば、どこか1か所の穴から同じ規模の被害が出ます。
公開情報から読み取れる構造 | なぜ被害を大きくするか | 設計で変えられること |
|---|---|---|
現会員・退会者・入会未完了者の全データが、同じWebシステムから一度に取り出された | 1か所の侵入で全件に到達できる | 稼働中に必要なデータと、保管義務のためだけに残すデータを物理的に分ける |
本人確認書類の画像が、会員情報と一緒に流出した | 画像は「なりすまし」に直結する最も機微なデータ。会員情報と同じ場所にあると一緒に抜かれる | 審査完了後は画像を削除する、または本番システムから到達できないストレージへ隔離する |
退会後も約7年間、データが保持されていた | 「法令上の保管義務」はあっても、オンラインの本番DBに置き続ける義務はない | 保管義務のあるデータは、ネットワークから切り離した形で保管する。保持期間を過ぎたら物理削除する |
検知から遮断まで約22時間。検知前にどれだけ読み出されていたかは未公表 | 大量のデータ読み出しをリアルタイムに検知・遮断する仕組みがなければ、流出量は時間に比例して増える | 通常と異なる量・パターンのデータアクセスを検知し、自動で遮断または通報する |
これらはタイムズカー固有の話ではありません。「会員DBが1つ、画像も同じ場所、退会者も残っている、大量読み出しの監視はない」という構成は、日本中の会員制サービスや業務システムで一般的です。フレームワークの更新は「侵入されにくくする」対策で、この表の項目は「侵入されても被害を小さくする」対策です。両方が必要です。
まとめ
2024年以降、AIによって公開コードの脆弱性発見とそのフレームワークを使うサイトの抽出が自動化されました。Google・XBOW・OpenAI・Anthropic の公表資料で一次情報として確認できます
長年誰も見ていなかった古いコードほど、AIにとっては未発見の脆弱性が眠る場所になります。EOL フレームワークの痕跡が公開HTMLに見えている状態は、攻撃側に「私はここにいます」と知らせているに等しい
攻撃側はもう企業規模で選別しません。「小さい会社だから狙われない」は成立しない前提です
フレームワークの更新は「侵入されにくくする」対策にすぎません。データを分ける・隔離する・消す・大量読み出しを検知するという「被害を小さくする」設計が、同時に必要です
最終回では、弊社サイトが攻撃面を小さくするために採っている構成と、自社システムを点検する6つの質問をまとめます
よくある質問
- 中小企業の小さなWebサイトでも、本当に狙われるのですか？
- はい。AIによって脆弱性の発見と、その脆弱性を持つサイトの抽出が自動化されたため、攻撃側は「条件に合うサイトを機械的に全部リストアップして順番に試す」ことができます。企業規模で選別される時代ではなくなりました。守る側も「狙われない」前提を捨て、攻撃面を小さくし、保持するデータを最小限にする設計が必要です。
- フレームワークを最新版に更新すれば、情報漏えいは防げますか？
- 更新は「侵入されにくくする」ために必要ですが、それだけでは不十分です。全会員のデータが1か所にあり、本人確認書類の画像が同居し、退会者のデータが何年もオンラインに残り、大量の読み出しを検知する仕組みがなければ、どこか1か所の穴から同じ規模の被害が出ます。「侵入されても被害を小さくする」設計を同時に行う必要があります。
- 法律で保管が義務づけられているデータは、消せないのではないですか？
- 保管義務があることと、オンラインの本番システムに置き続けることは別の問題です。保管義務のあるデータは、Webサービスから到達できない場所に切り離して保管し、保持期間を過ぎたら物理的に削除する、という運用が可能です。「法律があるので全部残している」状態は、攻撃者から見れば「古いデータまで一度に取れる」状態と同じです。
ご相談お待ちしております。
「古いシステムだけど、うちは小さいから大丈夫」と思っていた方ほど、今回の話は耳が痛かったかもしれません。ただ、攻撃側の前提が変わった以上、守る側の前提も変える必要があります。
栃木県でシステム開発・アプリ開発・Web サイト制作の会社をお探しの方、既存のWebサービスのセキュリティ設計の見直し、保持データの整理や隔離の設計をご検討中の方へ。 システムデザインワークスでは、自社サイトで実践した構成と点検の経験をもとに、現状の棚卸しから設計の見直し、移行・運用まで一貫してサポートしております。お気軽にお問い合わせフォームよりご連絡ください。
参考（一次情報・2026年10月2日時点）: