佐川急便は10月23日、流出した可能性のある個人情報が現時点で最大約5,323万件と公表しました。重複が残る情報の件数であり、実人数でも、全件の外部流出を確認した件数でもありません。スマートクラブ未登録でも荷物の送り主・受取人は対象となる可能性があります。不審なSMSやメールのリンクから確認しないでください。
宅配サービスの会員でなくても、荷物を受け取れば送り状に氏名・住所・電話番号が載ります。今回のケースは、「自分でアカウントを作っていないから関係ない」と判断できない情報流出の問題です。佐川急便の第5報と公式FAQをもとに、利用者と出荷企業が確認すべき範囲を整理します。
確認日は2026年10月26日朝（日本時間）。最新の第5報とFAQ更新は10月23日で、日付では3日前です。公式ページに公表時刻はなく、経過時間を厳密には確定できません。今回の新情報は、件数の集計結果とWebの荷物問い合わせ再開であり、不正アクセスが10月23日に初めて発生したという意味ではありません。
被害概要：送り状・運賃契約・スマートクラブの3種類
| 情報の区分 | 対象となる範囲 | 第5報で示された項目 |
|---|---|---|
| 送り状データ | 2026年6月21日～9月30日に預かった荷物。約100日間という範囲はシステムの保管期間に基づく | 依頼主・届け先の氏名、住所、電話番号 |
| 運賃契約の契約者情報 | 佐川急便と運賃契約を結ぶ顧客のリスト | 氏名、住所、電話番号 |
| スマートクラブ会員情報 | 同Webサービスに登録した顧客 | 氏名、住所、電話番号、メールアドレス、会員ID |
出典は第5報「流出した可能性のある情報」です。手書きの送り状で預かった荷物の情報は今回の流出対象に含めないとしています。ただし、その人が別途スマートクラブ会員である場合など、他の区分まで対象外になるとは限りません。約100日間という条件を、契約者情報や会員情報にも一律に適用しないことが大切です。
公式FAQのQ2-4・Q2-5は、スマートクラブに未登録の送り主や、通販の商品を受け取った人も対象となり得ると説明しています。第5報は、対象情報にクレジットカード情報とパスワードは含まれないとしています。FAQでは銀行口座情報も対象外とする一方、荷物の品名・配送履歴を含む詳細は確認中です。未確定の項目を「すべて漏れた」「絶対に漏れていない」と補わないでください。
件数を正しく読む：名寄せしても実人数とは限らない
第5報の最大約5,323万件は、同じ人の情報をまとめる名寄せを一定程度行った後の数字ですが、重複は残っています。同じ住所に何度も荷物が届いたり、氏名や住所の書き方が異なったりするためです。会社は、3区分それぞれの件数も実人数を適切に表しにくいとして公表していません。集計の説明
| 区別する数字 | 今回わかっていること |
|---|---|
| 流出した可能性のある情報の最大件数 | 現段階で約5,323万件。重複を含む |
| 対象者の実人数 | 特定・整理を継続中。5,323万人とは言えない |
| 実際に外部流出を確認した件数 | 最大件数のすべてについて確認したという発表ではない |
| 送り状・契約者・会員の区分別件数 | 公表していない。推計して埋めない |
名寄せには、同じ人を別人として数える誤りと、同姓同名などの別人を一人にまとめる誤りの両方があります。企業が事故の範囲を整理するときも、「元の記録数」「重複処理後の件数」「確認できた実人数」「まだ照合できない記録」を別々に持つと、途中の数字が独り歩きしにくくなります。これは本件の公表内容から考えられる、編集部のデータ管理上の提案です。
時系列：発覚、遮断、再開を同じ日付にしない
| 日付・時刻（日本時間） | 会社が公表した出来事 |
|---|---|
| 9月30日7:30 | 不正アクセスが発覚。侵入そのものの発生日時は調査対象 |
| 9月30日 | 第1報を公表。荷物問い合わせへのアクセスを一部制限 |
| 10月1日正午 | インターネット貨物システムへの外部アクセスを遮断 |
| 10月1日 | 個人情報保護委員会へ速報を提出したと会社が説明 |
| 10月9日 | 第4報。対象範囲の調査、情報の重複整理、監視強化などを説明 |
| 10月23日 | 第5報。最大約5,323万件という集計結果と、Webの荷物問い合わせ再開を公表。FAQも更新 |
また、FAQのQ1-4は、7月公表のスマートクラブの情報漏えいとは別事案だとしています。7月の事象は復旧作業時の設定誤り、今回は第三者の不正アクセスという説明です。似たサービス名の過去事故を同じ原因としてまとめないようにします。
原因：侵入経路の詳細はまだ確定情報として示されていない
公式FAQのQ1-2では、第三者専門機関と原因・事実関係を調査中です。確認した第5報にも、悪用されたCVE、特定製品の修正不足、認証情報を入手した方法などの詳細な侵入経路は示されていません。特定の脆弱性や担当者のミスを原因と断定する材料はありません。
会社は第4報でシステム構成、アクセス制御、脆弱性管理、権限管理、監視体制の点検・見直しを説明し、第5報でもアクセス管理・監視の強化を進めるとしています。これらが点検対象であることと、それぞれに不備があったと確定したことは別です。
10月23日の第5報では、本件に関連した個人情報の不正利用などの二次被害は確認されていないとしています。これは会社がその時点で確認できた状況であって、今後も起きないという保証ではありません。氏名や住所などの情報を使って信頼できそうな連絡に見せる可能性を考え、受け手側でも確認経路を分けます。
利用者と出荷企業が、いま確認すること
- 1利用者は公式サイトをブックマーク等から直接開き、第5報とFAQを確認する。メールやSMSのリンクに個人情報を入力して対象判定を求めない。
- 2スマートクラブ会員かどうかだけで判断せず、対象期間に荷物を送った・受け取った可能性も確認する。通知がまだ届かないことを対象外の証拠にしない。
- 3身に覚えのない請求や荷物、不審な電話があれば、その連絡先へすぐ折り返さず、公式サイトの窓口から確認する。
- 4出荷企業は対象期間の出荷履歴、利用する送り状発行システム、顧客窓口の担当を整理する。原本の個人情報は社内の承認された場所で管理し、外部LLMへ丸ごと渡さない。
- 5委託元としての連絡・報告の進め方は、佐川急便の案内を担当部門で確認する。自社の確認事項と会社側の調査待ちを分けて記録する。
FAQのQ4-3は、スマートクラブのパスワードは対象情報に含まれないとしたうえで、他サービスとID・パスワードを使い回している場合には変更を勧めています。「今回パスワードも流出したから全員変更必須」と説明を変えないでください。第5報は個別案内が難しい場合には公表をもって通知に代えるとも述べています。
出荷履歴についてはFAQのQ2-7に、利用中の送り状発行システムで確認する手順があります。Biz-LogiWEBは検索範囲が3か月以内、Biz-LogiWEBⅡは1か月以内とされているため、対象期間を分けて検索します。本稿は実データの検索を行っていません。社内で確認する際は、期間の境目の漏れや、重複取得にも注意してください。
第5報では、会社と出荷人の連名による個人情報保護委員会への報告を準備中と説明しています。案内があることだけで自社の対応完了とはせず、対象範囲・連名の取り扱い・必要な社内確認を担当者が公式案内で確認してください。ここでは個々の企業の法的義務の有無を判定しません。
サービス再開と、漏えい調査の完了は別
10月23日に再開したのはWebの「インターネット貨物のお荷物問い合わせ」です。第5報では、お荷物問い合わせAPI、飛脚宅配便受付、往復便関連の受付、商品回収返金サービス、受取先変更、回収くんなどは引き続き停止としています。Web画面が開くことから、自社のAPI連携まで復旧したと判断しないでください。
公式FAQでは荷物の集荷・配達は通常どおりと説明されています。一方、情報の名寄せや対象者の特定は続いています。「業務が再開した」「サービスの対策と確認が済んだ」「過去の被害範囲が確定した」を、別々の状態として管理する必要があります。
どうしたら被害を抑えられるか：原因の断定ではなく、自社の点検へ
以下は、佐川急便に特定の不備があったと指摘するものではありません。侵入経路が未確定のため「この対策で必ず防げた」とも言えません。顧客情報を扱う自社システムに、似た被害が広がる条件がないかを確認する観点です。
| 観点 | 自社で確認する問い | 残しておく根拠 |
|---|---|---|
| 外部公開機能からのアクセス範囲 | 荷物1件の照会に必要な情報だけに制限されているか。別顧客の情報や大量データへ届かないか | 設計書、認可ルール、サービスアカウントの権限一覧 |
| 保管期間とデータの複製 | 本体・ログ・CSV・バックアップに何が何日残るか。削除方針と実際の保存が一致するか | データ台帳、保持設定、削除結果。調査対象の証拠は不用意に消さない |
| 大量取得を見つける監視 | 普段と違う件数・速度・期間・顧客範囲の参照を検知できるか | 個人情報を除いた集計、通知先、監視テストの結果 |
| 区画ごとの遮断・復旧 | 公開APIと管理機能、取引先の連携を分けて制限できるか | 依存関係図、停止条件、代替手順、復旧後の検査記録 |
| 事故の集計と通知 | 記録数と人数、流出確認と可能性を区別して説明できるか | 名寄せの基準、未確認項目、通知対象を決めた記録 |
たとえば、照会APIのサービスアカウントが広いデータを読める構成なら、認証の強化だけでなく、取得できる項目や範囲を狭める設計も検討します。ただし、これは一般的な被害軽減策です。今回そのような権限構成だったという調査結果は公表資料から確認していません。
LLMへの指示例：個人情報を渡さず、点検の抜けを探す
LLMに任せるのは、許可された資料から点検表を作るところまでです。顧客名・住所・電話番号・メールアドレス・会員ID・追跡番号・認証情報は渡さず、項目名、匿名化した構成、集計値、権限の種類で説明します。実際の名寄せや個人への連絡は、組織が認めた環境と担当者で扱います。
私たちが管理する顧客情報システムについて、情報流出の被害範囲を抑えるための読み取り専用の点検計画を作ってください。佐川急便の事案を参考にしますが、未公表の侵入経路を推測して事実扱いしないでください。
入力は、機密・個人情報を除いたデータ項目一覧、保持期間、構成図、権限の種類、件数の集計、監視の設計、公式資料URLと確認日時です。顧客情報の実データ、追跡番号、会員ID、認証情報、個人を再識別できるログは要求しないでください。
1. 公開機能が参照できるデータの範囲と、業務に必要な範囲を比較する。2. 本体・ログ・CSV・バックアップの保持期間と削除の証拠を確認する。調査中の証拠の削除は提案しない。3. 大量・異常な参照の検知、通知先、停止と復旧の判断基準を整理する。4. 記録数、重複処理後件数、実人数、実際の流出確認、流出の可能性を別の欄にする。未公表の数値を推計で埋めない。5. 委託先への確認事項、利用者への案内、社内の担当者と期限を整理する。法的義務は自動判定せず担当部門へ確認事項として残す。
出力：対象／確認済みの事実／根拠と日時／未確認事項／被害軽減の提案／副作用／担当者／完了証拠。攻撃の再現、外部システムの探索、実データへのアクセス、設定変更、更新、削除、通知送信は行わないでください。資料不足は未確認とし、安全性や被害ゼロを保証しないでください。点検依頼文をテキストでダウンロードできます。出力された提案は、権限・可用性・証拠保全への影響を担当者が確認してから実施します。LLMが「問題なし」と回答しただけでは、被害がないことの証明になりません。
本稿は2026年10月26日朝に、佐川急便の第1報、第4報、第5報、公式FAQを照合したケース解説です。実環境へのアクセス、攻撃再現、顧客データの取得や名寄せは行っていません。会員情報を扱うAPIの点検はソースネクストの事例でも説明しています。