リクルートは2026年10月21日、中古車情報サイト「カーセンサーnet」と中古車販売店向け業務支援サービス「C-MATCH」への不正アクセスで、最大3,709,551件の個人情報が外部に漏えいした可能性があると公表しました。対象は、販売店へ問い合わせをした利用者、口コミを投稿した利用者、C-MATCHに登録している販売店、従業員や取引先の4区分です。本記事では、利用者と販売店が知りたい「自分は対象か」「何が漏れたか」「届いた連絡は本物か」「どこに問い合わせるか」に公式発表の文言で先に答えます。後半では、消費者向けサイトと事業者向けの業務サービスを運営する側に向けて、住所を市区町村までに切り詰める処理と、販売店の口座情報を消費者側のアカウントから読めなくする権限設定を、コードで示します。
まとめ：カーセンサー不正アクセスで公表された事実と利用者・販売店が今日やること
確定しているのは次の事実です。10月17日（土）に「カーセンサーnet」関連システムへの外部からの不審なアクセスを検知し、同日17時頃から、アプリ版やC-MATCHを含む関連サービスをすべて一時停止しました。10月20日（火）の調査で、漏えいした可能性のある項目と件数の最大値を把握しています。原因は「第三者からの不正なアクセス」とだけ書かれ、侵入経路は調査中です。
利用者が今日やることは、カーセンサーを名乗るメール、SMS、郵送物、電話に反応しないことです。クレジットカードなどの決済情報とログインパスワードは、4区分のいずれにも含まれていないと明記されています。販売店は、個人事業主であれば引落口座情報が対象に入っている点を踏まえ、口座の変更や支払いを求める連絡を疑ってください。
| 項目 | 公表されている内容（10月21日時点） |
|---|---|
| 検知と停止 | 10月17日（土）検知・同日17時頃全サービス停止 |
| 件数の最大値 | 3,709,551件（4区分の合計） |
| 含まれないもの | クレジットカード等の決済情報・ログインパスワード |
| 原因 | 第三者からの不正なアクセス（詳細は調査中） |
| 二次被害 | 10月21日時点で確認されていない |
| 当局への対応 | 個人情報保護委員会へ速報済み |
| 本人への連絡 | 対象者へ順次個別に連絡 |
自分が対象か確かめる4区分｜問い合わせ・口コミ・販売店・従業員の項目と件数
販売店へ問い合わせた利用者の321万件と住所が市区町村までである点
10月21日の発表で最も件数が多いのは、カーセンサーnet（アプリ版を含む）で中古車販売店に問い合わせをした利用者の3,210,421件です。単に車を検索しただけの利用者ではなく、販売店への問い合わせをした人が対象と書かれています。
| 漏えいした可能性のある項目 | 件数 |
|---|---|
| 氏名・住所 | 3,176,375件 |
| 氏名・住所・問い合わせ内容・年代・性別 | 33,247件 |
| 上記に電話番号・FAX番号・メールアドレスを追加 | 799件 |
住所は原則として市区町村名までの情報です。ただし、町名・番地・建物名・部屋番号まで含む住所が記載されている可能性がある件数が、最大447,670件あるとされています。なぜ一部に番地まで含まれるのかは、発表に書かれていません。電話番号やメールアドレスまで対象になったのは799件で、大半の利用者は氏名と市区町村の組み合わせです。
口コミ投稿者5,289件と従業員・業務委託先・代理店の10,673件
カーセンサーnetで口コミを投稿した利用者は5,289件です。このうち5,285件は氏名だけ、4件は氏名とメールアドレスが対象です。従業員（退職者を含む）、業務委託先の従業員や個人事業主、カーセンサーの販売代理店の従業員は10,673件で、氏名、メールアドレス、ログインIDが対象になりました。
4区分のすべてに、リクルートが社内で付与する管理用IDが含まれています。管理用IDは利用者が画面で使う番号ではなく、社内のシステムで記録を結び付けるための値と読めますが、その用途は発表からは分かりません。
C-MATCH登録販売店48万件で個人事業主だけ引落口座まで含まれる理由
C-MATCHに登録している中古車販売店は483,168件です。代表者や担当者の氏名と電話番号、古物商の許可番号・許可保有者の氏名・発行都道府県、ログインIDが対象になりました。個人事業主の場合はこれに加えて、事業所や窓口の住所、郵便番号、電話番号、FAX番号、引落口座情報が含まれます。
法人の販売店では、口座の名義は会社であり、個人情報として数える対象に入らないためと考えられます。これは当社の推定で、発表は理由を説明していません。いずれにしても、販売店側では口座番号とログインIDと担当者の電話番号がそろって渡った可能性があり、利用者側より詐欺の材料が多い区分です。
届いた連絡は本物か｜偽のメール・SMS・電話への対処と専用窓口の確かめ方
発表が求める3つの注意と住所が市区町村まででも郵送物に注意が要る理由
発表は、漏えいした可能性のある情報を悪用した不審な連絡が届くおそれがあるとして、メール・SMS・郵送物の開封や電話への応答をしない、本文のリンクを開かない、添付ファイルを開かない、の3点を求めています。リクルートは対象者へ順次個別に連絡するとしているため、本物の連絡と偽の連絡が同じ時期に届く点に注意してください。
本物の連絡かを確かめるときは、届いたメールのリンクではなく、リクルートの発表ページに載っている専用の問い合わせ窓口を自分で開きます。番地まで含む住所が最大447,670件あるため、郵送物を使った詐欺の可能性も残ります。お詫びの金券や再登録をうたう封書は、同封の連絡先ではなく公式の窓口で確かめてください。最新のフィッシング報告はフィッシング対策協議会が公開しています。
パスワードは対象外でも他サービスとの使い回しを見直しておく範囲
ログインパスワードは対象に含まれていないため、今回の発表を理由にパスワードを変える必要は、公表された事実からは読み取れません。一方で販売店と従業員の区分ではログインIDが対象になっており、IDが分かればパスワードの総当たりや使い回しの試行が一段楽になります。同じパスワードを他のサービスでも使っている販売店は、この機会に分けておくのが安全です。決め方はパスワード管理のベストプラクティスで整理しました。
サービス再開は未発表でカーセンサーnetは停止したままの状態
発表には再開時期の記載がありません。2026年10月21日に当社が確認した時点で、www.carsensor.netのトップページは応答コード503（サービス一時停止）を返していました。C-MATCHで在庫や問い合わせを管理している販売店は、再開まで別の手段で顧客対応を続ける必要があります。漏えい時の報告の流れは個人情報保護委員会への報告義務、様式は個人情報保護委員会の「漏えい等の対応とお役立ち資料」にあります。
消費者向けサイトと販売店向けSaaSが同じ事案で対象になった構造の読み方
検知したのはカーセンサーnet関連システムで対象はC-MATCHまで及んだ事実
発表によると、不審なアクセスを検知したのは「カーセンサーnet」関連システムです。一方で、漏えいした可能性のある対象には、消費者の問い合わせ情報、販売店の契約・口座情報、従業員と代理店のログインIDまでが並んでいます。性質の違う3種類のデータが1つの事案でまとめて対象になったことになります。
侵入経路も、データがどのシステムのどこに置かれていたかも公表されていません。同じデータベースだったのか、連携の仕組みを通じて複数の保存先に届いたのかは、本記事では断定しません。ただ、4区分すべてに共通の管理用IDが含まれていたという事実は、少なくとも記録どうしを結び付ける仕組みがサービスをまたいで存在していたことを示します。
問い合わせが販売店へ届く仕組み上サービス間のデータ連携は避けられない前提
中古車の比較サイトでは、利用者の問い合わせが販売店の業務画面へ届くことがサービスの中心です。消費者側と販売店側の間でデータが流れること自体は避けられません。設計で問われるのは、流れるデータを必要な項目に絞っているか、片方の側の認証情報で反対側の機微な情報まで読めないようになっているか、の2点です。この2点を、後半の2つのコードで具体的に示します。
サービスごとに読み書きできる範囲を分ける考え方はRBACとは、APIの認可とトークン失効はAPI不正アクセス対策の実装手順で扱いました。API応答に必要以上の項目が混ざる型の事故はOfferBoxの情報漏洩で解説しています。
問い合わせの住所を市区町村までに切り詰めるPython実装｜本文の電話番号も伏せる
保存の前に切り詰めれば漏えいしても番地は出ないデータ最小化の考え方
今回の発表で住所が原則市区町村までだったことは、漏えいの影響を小さくしています。それでも最大447,670件で番地まで含まれていた可能性があるのは、保存の仕組みが入力値をそのまま受け取る経路を持っていたことを示唆します。これは当社の推測で、発表は原因を説明していません。
販売店が問い合わせに答えるだけなら、多くの場合は市区町村で足ります。保存する前に切り詰めておけば、侵入されても番地は出ていきません。次のコードは、問い合わせを販売店へ渡す前に住所を市区町村までに切り詰め、自由記述の本文から電話番号と番地を伏せる例です。minimize_pii.pyとして保存します。
import re, sys
# 問い合わせを販売店へ渡す前に、住所を市区町村までに切り詰め、
# 自由記述の本文から電話番号・メールアドレス・番地を伏せる
CITY = re.compile(
r"^(?P<pref>東京都|北海道|(?:京都|大阪)府|.{2,3}県)?"
r"(?P<city>(?:[^市区町村]{1,6}郡)?[^市区町村]{1,6}[市町村](?:[^市区町村]{1,4}区)?"
r"|[^市区町村]{1,4}区)")
PHONE = re.compile(r"0\d{1,4}-?\d{1,4}-?\d{3,4}")
MAIL = re.compile(r"[\w.+-]+@[\w-]+(?:\.[\w-]+)+")
BANCHI = re.compile(r"\d+(?:丁目|番地?|号|-\d+)+(?:-\d+)*")
def minimize_address(addr: str) -> str:
m = CITY.match(addr.replace(" ", "").replace(" ", ""))
if not m:
raise ValueError(f"市区町村を特定できない: {addr!r}") # 不明なら全文を保存しない
return (m.group("pref") or "") + m.group("city")
def mask_body(text: str) -> str:
text = MAIL.sub("[メール]", text)
text = PHONE.sub("[電話]", text)
return BANCHI.sub("[番地]", text)
samples = [
("神奈川県横浜市青葉区美しが丘1丁目2-3 グリーンハイツ101",
"週末に試乗したいです。平日は090-1234-5678に連絡ください"),
("東京都世田谷区桜新町2-10-5", "下取り査定もお願いします。自宅は桜新町2-10-5です"),
("北海道札幌市中央区北1条西2丁目", "在庫はまだありますか"),
("愛知県知多郡東浦町緒川1-1", "ローンの審査について知りたい"),
]
for addr, body in samples:
print("住所:", minimize_address(addr))
print("本文:", mask_body(body))2026年10月21日に、Python 3.14.7で実行した結果です。住所欄の番地と建物名は保存されず、本文に書かれた電話番号と番地も伏せ字になりました。データは架空です。
$ python minimize_pii.py
住所: 神奈川県横浜市青葉区
本文: 週末に試乗したいです。平日は[電話]に連絡ください
住所: 東京都世田谷区
本文: 下取り査定もお願いします。自宅は桜新町[番地]です
住所: 北海道札幌市中央区
本文: 在庫はまだありますか
住所: 愛知県知多郡東浦町
本文: ローンの審査について知りたい正規表現の切り詰めが誤る住所と住所マスタでの照合へ切り替える基準
この正規表現は説明のための簡略版です。同じ日に試したところ、「三重県四日市市」や「千葉県市川市」のように地名の中に「市」を含む住所では、市区町村名を途中で切ってしまいました。例外を出さずに誤った値を返すため、本番でこのまま使うと住所が欠けたまま保存されます。
本番では、郵便番号と住所の一覧（住所マスタ）と照合して市区町村を取り出し、照合できない入力は保存せずに入力画面へ戻す設計にしてください。本文の伏せ字も同じで、表記ゆれのある電話番号や全角数字の番地は取りこぼします。伏せ字は「漏れても困らない形で持つ」ための補助で、権限の分離の代わりにはなりません。
販売店の口座を消費者側から読めなくするPostgreSQL 16の列権限の設定例
スキーマとアプリ専用ロールを分けて列単位でGRANTするSQL
OWASP Database Security Cheat Sheetは、データベースのアカウントを1つのアプリケーションやサービスだけで使い、動作に必要な最小限の権限だけを与えるよう求めています。重要なアプリケーションでは、表・列・行の単位で権限を細かく設定するとしています。次のSQLは、消費者向けの問い合わせと販売店向けの契約情報をスキーマで分け、アプリごとのロールに必要な範囲だけを与える例です。データは架空です。
-- 消費者向けサイトと販売店向けSaaSのデータを、スキーマとロールで分ける例
CREATE SCHEMA consumer; -- 消費者向けサイト（問い合わせ）
CREATE SCHEMA dealer; -- 販売店向けSaaS（契約・口座）
CREATE TABLE consumer.inquiries (
id serial PRIMARY KEY, mgmt_id text, name text, city text, body text);
CREATE TABLE dealer.dealers (
id serial PRIMARY KEY, mgmt_id text, rep_name text, phone text,
kobutsu_no text, login_id text, bank_account text);
-- アプリごとにログイン用ロールを分け、自分のスキーマだけに USAGE を与える
CREATE ROLE app_consumer LOGIN;
CREATE ROLE app_dealer LOGIN;
CREATE ROLE app_support LOGIN; -- 販売店への問い合わせ対応（口座は不要）
GRANT USAGE ON SCHEMA consumer TO app_consumer;
GRANT SELECT, INSERT ON consumer.inquiries TO app_consumer;
GRANT USAGE ON SCHEMA dealer TO app_dealer, app_support;
GRANT SELECT ON dealer.dealers TO app_dealer;
-- サポート用は列単位で、口座とログインIDを読めないようにする
GRANT SELECT (id, rep_name, phone) ON dealer.dealers TO app_support;この設定では、app_consumerはdealerスキーマへのUSAGE権限を持たないため、販売店の表を参照できません。app_supportは担当者名と電話番号は読めますが、bank_accountとlogin_idの列を指定するとpermission deniedで拒否されます。スキーマの権限と列の権限の仕組みはPostgreSQL 16の「Privileges」に書かれています。このSQLは文書に沿った設定例で、当社の環境では実行していません。導入前に、自社の検証用データベースで拒否されることを必ず確かめてください。
表全体に与えた後で列だけREVOKEしても口座が読めてしまう落とし穴
列権限でよくある誤りは、表全体にSELECTを与えた後で、隠したい列だけREVOKEする書き方です。
-- 誤り: 表全体に GRANT した後で列だけ REVOKE しても効かない
GRANT SELECT ON dealer.dealers TO app_support_bad;
REVOKE SELECT (bank_account) ON dealer.dealers FROM app_support_bad;
-- app_support_bad は bank_account を読めたままPostgreSQL 16のGRANTの文書は、列への権限か表全体への権限のどちらかがあればその列を操作でき、表全体に与えた権限は列単位の操作の影響を受けないと明記しています。隠したい列がある表には、最初から列を列挙してGRANTしてください。既存の権限を点検するときは、表全体のSELECTを持つロールの一覧から確かめるのが早道です。
権限分離とデータ最小化を今月中に点検する事業者と後回しでよい事業者
消費者と取引先の両方のデータを1つの基盤で持つマッチング型サービス
消費者の問い合わせを事業者へ取り次ぐ比較・予約・求人などのマッチング型サービスで、事業者側の契約情報や口座まで同じ基盤で持っているなら、今月中に2点を確かめてください。1点目は、消費者向けの画面やAPIが使うデータベースのアカウントで、事業者の口座やログインIDを読めないか。2点目は、問い合わせの住所や本文を、取次に必要な範囲まで切り詰めて保存しているかです。前者は権限の一覧の確認で、後者は保存処理のテストで確かめられます。
侵入された場合の影響範囲を第三者の目で洗い出したいときは、脆弱性診断・セキュリティ診断で、外部から到達できる画面とAPIに加えて、アカウントごとに読める範囲まで含めて点検できます。
単一サービスで事業者向けの口座情報を自社で持たない小規模サイト
サービスが1つで、事業者の口座情報を自社で持たず、支払いは決済代行会社に任せているなら、スキーマとロールを細かく分ける作業は後回しでかまいません。先に入れるべきは、住所や自由記述の本文を必要な範囲まで切り詰める処理です。こちらはコードの数十行で入り、漏えい時の影響を確実に小さくします。
よくある質問
カーセンサーの不正アクセスについて、利用者・販売店と、サービスを運営する担当者から出やすい質問をまとめました。
車を検索しただけで問い合わせをしていなくても対象ですか？
10月21日の発表で利用者側の対象とされているのは、販売店へ問い合わせをした人と、口コミを投稿した人です。検索や閲覧だけの利用者は対象として挙げられていません。不安な場合は、リクルートの専用窓口で確かめてください。対象者には同社から順次個別に連絡があるとされています。
アプリ版のカーセンサーで問い合わせた場合も含まれますか？
アプリ版からの問い合わせも対象です。発表は対象サービスを「カーセンサーnet（アプリ版を含む）」としており、アプリから販売店へ問い合わせた利用者も対象の区分に入ります。アプリ版を含む関連サービスは、10月17日17時頃から一時停止しています。
クレジットカードやパスワードは変えたほうがよいですか？
発表は、4区分のいずれにもクレジットカードなどの決済情報とログインパスワードは含まれていないとしています。本件を理由にカードを止める必要は、公表された事実からは読み取れません。販売店の方はログインIDが対象になっているため、同じパスワードを他のサービスで使っていれば分けておくのが安全です。
販売店に口座の変更や支払いを求める連絡が来たらどうすればよいですか？
個人事業主の販売店では引落口座情報が対象に入っているため、口座番号を示して信用させる連絡があり得ます。連絡に書かれた電話番号やリンクは使わず、リクルートの専用窓口や、普段の取引で使っている連絡先から確かめてください。振込先の変更を電話やメールだけで受け付けないことが基本です。
自社のマッチングサービスで同じ事態を防ぐには何から始めればよいですか？
まず、消費者向けの画面やAPIが使うデータベースのアカウントで、事業者の口座やログインIDを読めるかを確かめます。読めるなら、スキーマとロールを分け、必要な列だけをGRANTする設定に変更してください。並行して、問い合わせの住所や本文を取次に必要な範囲まで切り詰めて保存する処理を入れます。
関連記事
- ふるさとチョイス不正アクセスで445万件流出：対象確認・パスワード変更と再開時期：同じ10月に停止した会員サービスと再設定時の流出パスワード照合
- スタディサプリの不正アクセスとメールアドレス3,687件｜アカウント列挙を防ぐ実装：同じリクルートのサービスで起きた事案とアカウント列挙の防ぎ方
- タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え：車関連サービスの漏えいと偽の連絡の見分け方
- フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：お詫びや再登録を装う手口と実装側の対策
- 情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】：情報漏洩を原因別に防ぐ全体像
