シチズン時計は2026年10月6日、ブランドサイトの問い合わせフォームの受付を委託していた株式会社スカラコミュニケーションズのサーバーに不正アクセスがあり、約10万名分の顧客情報が漏えいした可能性があると公表しました。対象はシチズン、ブローバ、フレデリック・コンスタントの3ブランドの問い合わせです。氏名や住所に加えて、問い合わせ内容欄に銀行口座やクレジットカードの情報を書いた人は、その記載も対象になりえます。本記事では公表内容を時系列で整理し、利用者の点検手順を示したうえで、問い合わせの本文に書き込まれたカード番号を保存前に止める実装と、移行中の旧システムに残るデータの消し方をコード付きで解説します。
まとめ：シチズン時計の不正アクセスで確定した事実と利用者・開発者がやること
確定しているのは、委託先（以下SC社）の問い合わせ受付システムに10月2日夜から3日朝にかけて不正アクセスがあり、3ブランドのフォームから送られた約10万名分の情報が漏えいした可能性があることです。シチズン時計自身のシステム、ECサイト、会員制サービスへのアクセスは確認されていません。SC社の発表では、管理サイトへの不正ログインが起点で、同じサーバーに同居していた利用企業最大5社の環境が対象になりました。
利用者が警戒すべきは、問い合わせの中身を知った者からの連絡です。本文に口座番号やカード番号を書いた覚えがあるなら、明細の確認を先に済ませます。開発者の論点は、決済画面ではない問い合わせフォームが、カード番号の想定外の保存先になっていた点です。
| 項目 | 公表されている内容 |
|---|---|
| 不正アクセスの時間帯 | 10月2日20時33分頃〜3日8時1分頃 |
| シチズン時計への報告 | 10月3日（SC社から） |
| 公表日 | 10月6日（シチズン時計・SC社とも） |
| 対象 | 3ブランドの問い合わせフォーム約10万名分 |
| 項目 | 氏名・住所・電話番号・メールアドレス等 |
| 本文の記載 | 口座・カード情報を書いた場合は対象 |
| 自社システム・EC | アクセスは未確認 |
公表内容を時系列で確認する｜10月2日夜の侵入から10月6日の2社公表まで
シチズン時計の公表で確定した3ブランドの問い合わせと約10万名の範囲
シチズン時計の2026年10月6日のお知らせによると、同社は10月3日にSC社から報告を受けました。対象は、シチズン、ブローバ、フレデリック・コンスタントの各ブランドのWebサイトにある問い合わせフォームから送られた情報で、件数は約10万名分です。項目は氏名、住所、電話番号、メールアドレスなどです。
同社は、ECサイト、会員制サービス、生産システム、社内ネットワークへのアクセスは確認されておらず、漏えいした可能性がある情報で同社のシステムにアクセスすることはできないとしています。個人情報保護委員会への報告と所轄の警察署への相談は済んでおり、対象者には順次個別に連絡するとのことです。
SC社の発表で分かったi-ask管理サイトへの不正ログインと最大5社への波及
SC社も同じ10月6日にFAQシステム「i-ask」への不正アクセスに関するお知らせを出しました。第三者がi-askの管理サイトに不正ログインし、管理サイトから不正なプログラムを設置して、同じサーバー上の利用企業のデータベースから問い合わせ情報を取得した可能性があるという説明です。データベースの監視アラートを契機に10月3日朝に調査を始め、8時頃に遮断しています。
対象は同一サーバー上の最大5社で、件数は問い合わせ単位の延べ最大713,126件です。同じ顧客の重複を含み、実際の人数は名寄せ中とされています。対応として、全環境の管理者パスワードの変更、アップロードしたファイルをプログラムとして実行できない設定への変更を行い、多要素認証の導入と環境間の分離を再発防止策に挙げました。
大和証券と同じ時間帯の事案で公表済みの事実と未公表のまま残る事項
侵害の時間帯は、前日に公表した大和証券の公表文と分単位で一致します。大和証券は約11万名分、約22万件が対象で、口座番号が含まれていました。同じ事案の大和証券側の論点は大和証券の不正アクセスと問い合わせ管理の委託先に残さない設計で扱っています。
一方、管理サイトのログインに使われた認証情報を攻撃者がどう入手したかは、10月8日時点で公表されていません。脆弱性なのか、パスワードの流出や推測なのかで対策は変わるため、本記事では特定の手口に結び付けた推測はしません。
本文に書いた口座番号とカード番号が対象になる構図｜問い合わせ欄の盲点
漏えい項目に「記載していた場合」と付く理由と自由記述欄の中身
シチズン時計の発表は、問い合わせ内容欄に銀行口座やクレジットカードの情報を記載していた場合は、それらも対象になる可能性があるとしています。フォームに口座やカードの入力欄があったわけではありません。顧客が修理代の返金先や、購入時の支払いを説明するために、自分で本文に書き込んだ分です。
時計の問い合わせでは、修理の見積もり、ベルトや電池の交換、海外ブランドの正規保証の確認など、購入や支払いに触れる相談が多くなります。「このカードで払った件ですが」と番号を添える人は一定数いるはずです。企業はその記載を求めていなくても、受け付けた本文はそのまま履歴として保存されます。
カード情報の非保持化と問い合わせ経路が設計の検討から外れやすい理由
クレジット取引セキュリティ対策協議会のクレジットカード・セキュリティガイドラインは、2026年3月の6.1版でも、加盟店にカード情報を保持しない非保持化か、保持する場合のPCI DSS準拠を求めています。非保持化とは、自社で保有する機器・ネットワークでカード情報を「保存」「処理」「通過」のいずれも行わないことと定義されています。
EC加盟店は決済の画面を決済代行会社へ切り出して、この要件を満たすのが一般的です。ところが問い合わせフォームは決済の仕組みとして扱われないため、本文にカード番号が入ってきた場合の扱いが設計の議論に上がりません。電話や紙で受けたカード番号には別の整理がありますが、Webフォームの本文はシステムにテキストとして蓄積されます。
シチズン時計の問い合わせ利用者が今やる点検｜明細の確認と偽連絡の見分け方
本文にカード番号や口座番号を書いた覚えがある人が先に確かめること
過去の問い合わせでカード番号を書いた覚えがあれば、カード会社の利用明細に身に覚えのない請求がないかを確かめます。有効期限やセキュリティコードまで書いた場合は、カード会社に連絡して再発行を相談するのが確実です。口座番号だけでは引き出しはできませんが、口座番号を示して本物らしく装う連絡の材料にはなります。
対象かどうかの確認は、シチズン時計がお知らせに掲載した専用の問い合わせフォームから行います。シチズン時計は、同社や関係者を装う不審なメール、SMS、電話には個人情報を提供せず、添付ファイルやURLを開かないよう求めています。
修理や保証の相談内容を知った者からのメール・SMS・電話の見分け方
今回の対象に含まれる情報の一つは、問い合わせ内容です。修理を依頼した時計の型番や、保証の相談をした経緯を正確に書いた「修理代金の再請求」「保証延長の手続き」といった連絡が届けば、本物と見分けるのは難しくなります。判断は、届いた連絡のリンクや電話番号を使わず、自分で開いた公式サイトから窓口をたどる、の一点に絞ります。
カード情報の入力を求めるページへ誘導された時点で、詐欺を疑ってください。手口の全体像はフィッシング詐欺の成立の仕組みと技術的対策で解説しています。
問い合わせ本文のカード番号を保存前に止める｜Luhnチェックによる判定の実装
13〜19桁の数字列をLuhnで判定し口座番号の記載も拾うPythonコード例
カード番号の桁数はブランドによって異なり最大19桁で、末尾の1桁がLuhnと呼ばれる計算の検査数字になっています。数字列の桁数だけで判定する方法では、修理番号や注文番号まで検知の対象です。Luhnを満たすものだけを候補にすると、誤検知を大きく減らせます。次の例はPythonの標準ライブラリreとunicodedataだけで書いたもので、全角の数字やハイフンも正規化してから判定します。
# 問い合わせ本文にカード番号・口座番号らしき記載がないかを保存前に判定する（Python 3）
import re
import unicodedata
CARD = re.compile(r"(?<!\d)\d(?:[ -]?\d){12,18}(?!\d)")
ACCOUNT = re.compile(r"口座(?:番号)?\D{0,8}?(\d{7})(?!\d)")
def luhn_ok(digits: str) -> bool:
total = 0
for i, ch in enumerate(reversed(digits)):
d = int(ch)
if i % 2 == 1:
d *= 2
if d > 9:
d -= 9
total += d
return total % 10 == 0
def check_inquiry(text: str) -> list[str]:
text = unicodedata.normalize("NFKC", text)
found = []
for m in CARD.finditer(text):
digits = re.sub(r"\D", "", m.group())
if luhn_ok(digits):
found.append("カード番号の可能性: 末尾" + digits[-4:])
for m in ACCOUNT.finditer(text):
found.append("口座番号の可能性: 末尾" + m.group(1)[-3:])
return found
if __name__ == "__main__":
samples = [
"時計のベルト交換について。支払いはカード ４１１１－１１１１－１１１１－１１１１ でした",
"修理番号 1234567890123 の進捗を教えてください",
"返金先は口座番号 普通 1234567 でお願いします",
"電話は 090-1234-5678 です",
]
for s in samples:
print(check_inquiry(s) or "問題なし")4件の模擬入力で実行すると、全角で書いたテスト用のカード番号は「カード番号の可能性: 末尾1111」、Luhnを満たさない13桁の修理番号は「問題なし」、口座の記載は「口座番号の可能性: 末尾567」、携帯電話番号は「問題なし」と出力されました。戻り値には番号の末尾だけを入れているので、判定結果をログに書いても番号全体は残りません。
判定に当たった問い合わせを受け付けずに書き直しを促す保存前の分岐
判定に当たったときの扱いは、伏せて保存するより、受け付けずに書き直してもらう方を選びます。伏せる処理を入れても、元の本文がWebサーバーのログや外部サービスへの送信データに残る経路は残ります。保存も転送もしなければ、委託先が破られても番号は出てきません。
サーバー側では、check_inquiryの結果が空でなければ保存と転送の前に処理を止め、「カード番号や口座番号は入力しないでください。返金などで必要な場合は担当者から別の方法でご案内します」と画面に返します。ブラウザ側でも、フォームのsubmitイベントで同じ判定をして送信を止めると、入力者にその場で伝えることが可能です。ただしブラウザの判定は回避できるので、保存を止める判定は必ずサーバー側に置きます。
本文から口座番号を伏せる方式と受け付けない方式を使い分ける条件
受け付けない方式が合うのは、メーカーのサポート窓口のように、本文にカード番号や口座番号が書かれる必要がそもそも無い業務です。今回のシチズン時計の問い合わせはこちらにあたります。返金先の口座は、担当者が個別に案内する専用の手続きで受ければ足ります。
一方、証券や銀行のように口座番号で顧客を特定しないと回答できない業務では、拒否すると問い合わせ自体が成り立ちません。この場合は、外部へ送る前に番号を参照IDへ置き換える方式を選びます。実装に使えるのは、大和証券の記事で示したHMACによる参照IDです。カード番号を自社で持たずに済ませる仕組みの全体は決済トークンとはで整理しています。
移行中の旧システムに残った10万名分｜利用終了と削除の日付を先に決める
新規受付を止めた後も旧システムに問い合わせ履歴が残っていた構図
シチズン時計の発表には、もう一つ見落とせない事実があります。今回の問い合わせ受付システムは他のシステムへの移行中で、新規の問い合わせ受付にはすでに使っていませんでした。2026年10月中旬に利用を終える予定で、保管している個人情報は移行期間の終了後に全て削除する予定だったとしています。
つまり、受付をやめた旧システムに約10万名分の履歴が残っている期間に侵害が起きました。移行中は旧システムの監視や更新が手薄になりやすく、データだけが残る状態になります。移行を終えた旧基盤から過去の注文データが漏れた同時期の事例はPFUの不正アクセスと移行済みEC基盤に残る旧データの消去設計で扱っています。
移行計画に入れる旧データの引き取り・削除依頼・完了確認の3工程
問い合わせ管理のサービスを乗り換えるときは、旧システム側の後始末を移行計画の独立した工程にします。順番は次のとおりです。
- 新システムへ引き継ぐ履歴の範囲を決め、それ以外は引き取らない
- 新規受付を止めた日に、旧システムの削除を依頼する日付を決める
- 削除の対象範囲・完了日・バックアップから消える日を文書で受け取る
引き継ぐ範囲は、回答済みで一定期間が過ぎた問い合わせを外すと小さくできます。旧システムに履歴を残す期間は、新システムで回答業務が回ることを確かめるまでの数週間で足ります。受付を止めた日から削除まで日付の無い期間をつくらないことが、今回の構図を避ける最短の手です。
問い合わせを外部に任せる委託元の確認範囲｜管理サイトの認証と同居環境
契約前と年1回の点検でSaaS事業者に確かめる管理画面と環境分離の4項目
今回の侵害は、利用企業の手が届かないSaaS事業者の管理サイトから始まりました。委託元が契約前と年1回の点検で確かめておくのは、次の4項目です。
- 事業者側の管理サイトに多要素認証と接続元の制限が掛かっているか
- 利用企業ごとの環境がサーバーやデータベースの単位で分かれているか
- 管理サイトからアップロードしたファイルが実行されない設定か
- データベースへの異常な読み出しを検知する監視があるか
SC社が再発防止策に挙げた多要素認証と環境間の分離は、この1項目めと2項目めにあたります。多要素認証の方式ごとの強さは多要素認証（MFA）の3要素と実装方式で比べています。今回は4項目めの監視アラートが、侵害を約11時間半で止める契機になりました。委託先を起点にした攻撃の型の整理はサプライチェーン攻撃とはが参考になります。
委託元として個人情報保護委員会へ報告する立場と速報・確報の期限
委託先で起きた漏えいでも、顧客情報の取り扱いを委託した企業が報告と本人への通知の主体になります。個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある漏えいは件数にかかわらず報告の対象で、速報は把握から3〜5日以内です。シチズン時計は10月3日に報告を受け、6日の公表時点で報告を済ませています。
報告書式の項目と記入の段取りは個人情報保護委員会への報告義務の実務で解説しています。自社の問い合わせフォームから外部サービスへの連携、保存される本文の中身までを第三者の目で確かめたい場合は、脆弱性診断・セキュリティ診断で、フォームの入力から委託先へのデータの流れまで含めて点検できます。
よくある質問
シチズン時計の不正アクセスについて、利用者と開発者から出やすい質問をまとめました。
シチズン時計のどの情報が漏えいした可能性がありますか？
シチズン、ブローバ、フレデリック・コンスタントの各ブランドのWebサイトにある問い合わせフォームから送られた、約10万名分の氏名・住所・電話番号・メールアドレスなどです。問い合わせ内容欄に銀行口座やクレジットカードの情報を書いていた場合は、その記載も対象になる可能性があります。
シチズンのオンラインストアや会員サービスも被害を受けましたか？
シチズン時計の発表では、ECサイト、会員制サービス、生産システム、社内ネットワークへのアクセスは確認されていません。漏えいの可能性があるのは、委託先の問い合わせ受付システムに保存されていた情報に限られています。この情報で同社のシステムにアクセスすることはできないとしています。
問い合わせにカード番号を書いた場合はどうすればよいですか？
カード会社の利用明細に身に覚えのない請求がないかを確かめてください。有効期限やセキュリティコードまで書いた場合は、カード会社へ連絡して再発行を相談するのが確実です。シチズン時計や関係者を名乗る連絡でカード情報を求められても応じず、公式サイトから自分でたどった窓口で確かめます。
大和証券の情報漏えいと同じ事件ですか？
同じ委託先の同じ時間帯の侵害です。SC社の発表では、FAQシステムi-askの管理サイトへの不正ログインを起点に、同じサーバー上の利用企業最大5社の環境から問い合わせ情報が取得された可能性があります。大和証券は約11万名分、シチズン時計は約10万名分を公表しています。
問い合わせフォームにカード番号を書かせない方法はありますか？
本文の数字列をLuhnで判定し、カード番号らしき記載があれば保存と外部への転送の前に受け付けを止め、書き直しを促す方法があります。ブラウザでも同じ判定をすると入力者にその場で伝えられますが、回避できるため保存を止める判定を置く場所はサーバー側です。返金先の口座などは別の手続きで受けます。
関連記事
- 大和証券の不正アクセスと約11万人分の口座番号：問い合わせ管理の委託先に残さない設計：同じ委託先の侵害で、口座番号を送る前に伏せる実装と委託先台帳
- PFUの不正アクセスと最大16万件の注文データ漏えい｜移行済みEC基盤に残る旧データの消去設計：使い終えた旧基盤のデータを消す手順
- 問い合わせ管理システムとは？機能・種類とExcel管理の限界、自社開発の判断基準：問い合わせ管理の仕組みと選び方
- タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計：残す必要のないデータが漏れた別事例
