--- title: "佐川急便の不正アクセスと約100日分の荷物情報｜追跡照会サービスの点検手順" url: "https://www.issoh.co.jp/tech/details/18184/" published: 2026-10-08 updated: 2026-10-08 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 佐川急便の不正アクセスと約100日分の荷物情報｜追跡照会サービスの点検手順 佐川急便は2026年9月30日、Webサイトの「お荷物問い合わせサービス」で第三者による不正アクセスを確認したと公表しました。翌10月1日には、約100日分の荷物の送り主・届け先の氏名、住所、電話番号などが外部に流出した可能性があると発表し、荷物追跡のAPIを含む9つのWebサービスを止めています。本記事では公式発表を時系列で整理し、流出の可能性がある情報の重さ、利用者が警戒すべき連絡、追跡APIを組み込んでいたEC事業者の対応をまとめた内容です。後半では、番号で情報を照会させるサービスを持つ開発者向けに、認可・列挙対策・応答の最小化をnginxの設定とログ集計のコードで示します。 ## まとめ：佐川急便の不正アクセスで公表された事実と利用者・事業者の対応 公表済みの事実は、9月30日に「お荷物問い合わせサービス」で不正アクセスを確認したこと、9月30日から遡って約100日間に預かった荷物の送り主・届け先の情報、運賃契約先の情報、スマートクラブ会員の情報が流出した可能性があること、クレジットカード情報・パスワード・銀行口座情報は含まれないことです。件数、範囲、原因は第三者機関の協力のもとで調査中とされています。 利用者側で最優先なのは、佐川急便を名乗るSMS・メール・電話を疑うことです。氏名・住所・電話番号に加えて「その時期に荷物をやり取りした」事実まで知られている前提で、本物らしく見える連絡が来ます。追跡APIを業務に組み込んでいた事業者は、停止中の表示と問い合わせ導線を先に整えてください。 | 項目 | 公表されている内容 | | ------- | --------------- | | 確認日 | 2026年9月30日 | | 起点 | お荷物問い合わせサービス | | 荷物情報の期間 | 9月30日から遡り約100日間 | | 対象件数 | 調査中 | | 含まれない情報 | カード情報・パスワード・口座 | | 停止サービス | 追跡API含む9サービス | | 原因 | 第三者機関と調査中 | ## 公表内容を時系列で確認する｜9月30日の検知から10月5日のFAQまで ### 9月30日の第1報から10月1日の第2報・第3報までに出た内容の推移 [第1報（2026年9月30日）](https://www2.sagawa-exp.co.jp/information/detail/419/)の時点では、不正アクセスの確認と、対策の一環としてサービスへのアクセスを一部制限したことだけが告知されました。流出の言及はありません。 翌日の[第2報（2026年10月1日）](https://www2.sagawa-exp.co.jp/information/detail/420/)で、調査の結果として個人情報が外部に流出した可能性が判明したと発表され、対象となる情報と停止した9サービスが示されました。同じ日の[第3報](https://www2.sagawa-exp.co.jp/information/detail/421/)では専用コールセンター（0120-28-3449、午前9時〜午後5時、土日・祝日を含む）の開設が案内され、影響範囲と原因は引き続き調査中とされています。 ### 10月5日公開のFAQで新たに分かった対象期間と関係機関への報告 10月5日には[よくあるご質問（FAQ）](https://www2.sagawa-exp.co.jp/information/detail/425/)が公開され、細部が補われました。「約100日間」は2026年6月下旬以降に預かった荷物を指すこと、スマートクラブ未登録で荷物を送っただけの人や通販の商品を受け取っただけの人も対象になりうること、個人情報保護委員会へ報告し警察へも相談していることが明記されています。 荷物の中身（品名）や配送履歴が含まれるかは「確認を進めている」との回答で、まだ確定していません。流出した可能性のある情報が不正に使われた事例は、現時点で確認されていないとしています。 ### 2026年7月のスマートクラブの事案とは別の事故である点の確認 同じFAQは、2026年7月に公表されたスマートクラブの個人情報漏えいとは別の事案だと説明しています。7月の件はシステム不具合を復旧する作業での設定誤りが原因で、第三者による不正アクセスではありませんでした。今回は第三者の侵入を確認した事案です。 短期間に二件が続いたため報道では混同されがちですが、原因の種類が違えば、再発防止策も別物になります。7月の件は運用手順の問題、今回は外部からの攻撃への備えの問題として、分けて追う必要があります。なお、同時期に物流各社で公表された不正アクセスとして、後払いの請求情報が対象になった[ヤマト運輸の不正アクセスと後払いの請求情報漏えい](https://www.issoh.co.jp/tech/details/18185/)もあります。 ## 流出の可能性がある情報を仕分ける｜送り主・届け先と会員情報の重さ ### 荷物の送り主・届け先と運賃契約先とスマートクラブ会員の三つの区分 第2報が示した対象は三つの区分に分かれます。最も人数が多いとみられるのは、約100日間に荷物を預けた送り主と、その届け先です。会員登録の有無を問わず、通販で受け取っただけの人も含まれます。項目は氏名、住所、電話番号で、法人なら法人名と担当者名です。 二つめは運賃契約を結んでいる法人・個人の顧客で、項目は同じく氏名、住所、電話番号です。三つめのスマートクラブ会員は、これにメールアドレスと会員IDが加わります。 | 区分 | 対象となりうる項目 | 主な悪用 | | --------- | ----------- | ------------- | | 送り主・届け先 | 氏名・住所・電話番号 | 電話・SMSでのなりすまし | | 運賃契約先 | 氏名・住所・電話番号 | 取引先を装う請求 | | スマートクラブ会員 | 上記＋メール・会員ID | 偽ログイン画面への誘導 | ### クレジットカード情報やパスワードが含まれなくても安心できない理由 カード情報とパスワードが含まれないため、直接の金銭被害やアカウントの乗っ取りは起きにくい構図です。それでも軽く見るべきではありません。氏名・住所・電話番号の組は変更が難しく、一度出回ると長く使われ続けます。 さらに荷物の情報には「誰が誰に送ったか」という関係が含まれます。通販事業者と購入者、企業と取引先の組み合わせがわかれば、実在する取引を踏まえた詐欺の文面が作れます。パスワードは変えれば済みますが、取引関係は取り消せません。 ### 品名や配送履歴がまだ確定していないことが今後の判断に与える影響 FAQによると、品名と配送履歴が含まれるかどうかは確認中です。品名が含まれていた場合、医薬品や特定の趣味の商品のように、購入した事実そのものが知られたくない情報になります。配送履歴が含まれれば、在宅の時間帯や受け取り場所の傾向も推測できます。 確定するまでは「含まれていた場合」を想定しておくのが安全です。特に法人は、取引先との荷物のやり取りから取引の頻度や規模を推測される可能性があります。続報で対象情報が確定した時点で、社内の判断を更新してください。 ## 利用者が今やる対応｜佐川急便を装うSMS・電話と使い回しの点検 ### 佐川急便を名乗るSMS・メール・電話を見分けるための三つの確認先 佐川急便は不審な連絡のURLにアクセスせず、個人情報の入力や提供もしないよう呼びかけています。流出した可能性がある情報を使うと、宛名と住所が正しい「不在通知」や「住所確認」のSMSを作れます。宛名が合っていることは本物の根拠になりません。 確認の手段は三つに絞れます。届いた連絡のリンクではなく公式サイトを自分で開くこと、送り状番号があれば最寄りの営業所へ電話で確かめること、本件の相談は専用コールセンターへ電話することです。偽サイトに誘導される仕組みと、受け手側・運営側の技術的な防ぎ方は[フィッシング詐欺の成立の仕組み](https://www.issoh.co.jp/tech/details/13548/)で整理しています。 ### スマートクラブのパスワードは変更不要でも使い回しを見直す場面 FAQによると、スマートクラブのパスワードは流出の可能性がある情報に含まれていません。そのうえで、他のサービスと同じIDとパスワードにしている場合は変更を推奨しています。 見直す理由はメールアドレスと会員IDが対象に含まれる点にあります。ログインに使う識別子が知られていると、他サービスから漏れたパスワードとの組み合わせを試される確率が上がります。使い回しをしている場合は、メールアカウント、決済系サービス、スマートクラブの順で変えてください。 ### 法人の発送担当者と経理担当者に社内で周知しておく内容の具体例 法人では、発送担当者と経理担当者が狙われやすい立場です。運賃契約先の情報が出ていれば、佐川急便や取引先を名乗って「運賃の未払い」「振込先の変更」を伝える連絡が来る余地があります。 社内には、振込先の変更は既知の電話番号へ折り返して確かめる、請求書のPDFに書かれた連絡先には電話しない、といった確認手順を具体的に周知しておきます。発送を外注している場合は、委託先の担当者にも同じ内容を共有してください。 ## 追跡APIを組み込んでいたEC事業者が確認する停止の影響と縮退運用 ### 停止した9サービスから自社業務への影響範囲を洗い出すときの見方 第2報が挙げた停止サービスは、インターネット貨物お荷物問い合わせ、同お荷物問い合わせAPI、飛脚宅配便受付、飛脚往復便受付、飛脚往復便（ゴルフ）受付、商品回収返金サービス、受取先変更の2種類（事前と不在発生後）、回収くんの9つです。集荷・配達そのものは通常どおり続いています。 影響は「照会」「受付」「変更」の三系統に分けると把握しやすくなります。EC事業者に効くのは、自社の注文履歴ページで配送状況を見せる照会の停止と、返品回収の受付の停止です。FAQでは、電話での集荷依頼は受け付けており、配送状況は送り状番号を伝えれば営業所で確認できると案内されています。 ### お荷物問い合わせAPIが止まった間に注文画面と問い合わせ窓口で行う対応 APIを呼んで配送状況を表示している画面は、そのままだとエラー表示や空欄になります。まず画面に「配送会社の照会サービスが停止中」である旨と、送り状番号、営業所への問い合わせ方法を出してください。購入者が問い合わせ窓口へ流れる量が増えるため、窓口側にも同じ案内文を用意しておきます。 APIの再開時期は未定で、法人向けの個別案内は確認中とされています。停止中のAPIへ短い間隔で再試行し続ける作りは、相手側の復旧作業の負荷にもなります。再試行は指数的に間隔を広げ、一定回数で打ち切る設定にしておいてください。 ### 配送会社の照会サービス停止に備えて持っておく縮退設計の判断基準 今回のように配送会社側が安全確認のために照会を止める事態は、どの配送会社でも起こりえます。配送状況の表示を外部APIに直結させている場合、相手の停止が自社の注文画面の不具合として見えてしまいます。 月間の出荷が数千件を超え、配送状況の問い合わせが窓口の負荷の大きな割合を占める事業者は、取得済みの配送状況を自社側に保存し、API停止時には最終取得時刻つきで表示する設計に寄せる価値があります。出荷が月数百件で問い合わせも少ないなら、ここまでの作り込みは過剰です。停止時に案内文へ切り替えられる設定を一つ持つだけで足ります。 ## 荷物追跡のような照会サービスで見直す設計｜認可・列挙対策・応答の最小化 ### 侵入経路が非公表の段階で照会サービスの開発者が点検できる範囲 佐川急便の事案の原因は第三者機関が調査中で、侵入経路や攻撃手法は公表されていません。ここから先は今回の原因を推測するものではなく、番号を入力すると情報が返る種類のサービス全般で、開発者が自社を点検するための項目です。 この種のサービスは、ログインなしで外部に開かれ、番号さえあれば応答が返るという性質を持ちます。[OWASP API Security Top 10 2023のAPI1（Broken Object Level Authorization）](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/)は、オブジェクトのIDを受け取るAPIで利用者がそのオブジェクトに触れてよいかを確かめない欠陥を最上位に置き、推測しにくいランダムなIDの採用を対策に挙げています。 ### 追跡番号だけで返してよい情報と追加の確認を求める情報の線引き 番号を知っていれば見られる照会では、番号そのものが鍵の役割を果たします。番号は送り状や通知メールで多くの人の目に触れるため、強い鍵にはなりません。返す情報は「配送状況」と「おおよその現在地」までに抑え、氏名・住所・電話番号を返す場合は、ログインや電話番号の下4桁の入力など、追加の確認を挟むのが基本形です。 [API3（Broken Object Property Level Authorization）](https://api-security.owasp.org/editions/2023/en/0xa3-broken-object-property-level-authorization/)は、オブジェクトを丸ごと返す汎用的な処理を避け、返す項目を個別に選ぶよう求めています。画面で伏せ字にしていても、APIの応答に全項目が入っていれば意味がありません。権限の確認漏れが起きる典型は[認可バイパスとIDORの実装対策](https://www.issoh.co.jp/tech/details/16399/)で詳しく扱っています。 ### nginxのlimit\_reqで照会APIの連続アクセスを抑える設定例と各値 番号を順に変えて大量に照会する列挙を抑えるには、接続元ごとの照会回数に上限を設けます。[API4（Unrestricted Resource Consumption）](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/)も、リクエスト頻度の制限を対策に挙げています。次は[ngx\_http\_limit\_req\_module](https://nginx.org/en/docs/http/ngx%5Fhttp%5Flimit%5Freq%5Fmodule.html)のディレクティブだけで組んだ例です。 ``` limit_req_zone $binary_remote_addr zone=track:10m rate=30r/m; server { location /api/track/ { limit_req zone=track burst=10 nodelay; limit_req_status 429; proxy_pass http://tracking_backend; } } ``` `rate=30r/m`は接続元IPごとに毎分30回、`burst=10`は一時的な超過を10回まで許す指定です。`limit_req_status`の既定値は503のため、429を明示すると利用側が「混雑」と「制限」を区別できます。公式ドキュメントによると、1MBのゾーンで保持できる状態の数は約1万6千です。IPを替えながら照会する相手にはIP単位の制限だけでは足りないため、次項のログ監視と組み合わせます。方式ごとの違いは[APIレート制限の5方式の比較と429設計](https://www.issoh.co.jp/tech/details/16179/)を参照してください。 ### アクセスログから番号を次々に照会する接続元を見つける集計コード 制限の値を決める前に、実際の照会の分布を知る必要があります。次のPythonコードは、combined形式のアクセスログから接続元IPと1時間ごとに、照会された番号の種類を数え、50種類以上の組を多い順に出します。 ``` import re import sys from collections import defaultdict LINE = re.compile(r'^(\S+) \S+ \S+ \[([^\]:]+:\d{2})[^\]]*\] "GET (\S+)') TRACK = re.compile(r'/api/track/(\d{10,12})') THRESHOLD = 50 seen = defaultdict(set) with open(sys.argv[1], encoding="utf-8", errors="replace") as f: for line in f: m = LINE.match(line) if not m: continue t = TRACK.search(m.group(3)) if t: seen[(m.group(1), m.group(2))].add(t.group(1)) for (ip, hour), nums in sorted(seen.items(), key=lambda kv: -len(kv[1])): if len(nums) >= THRESHOLD: print(f"{hour} {ip} 照会した番号の種類={len(nums)}") ``` Python 3.14で、1つのIPが1時間に80種類の番号を照会し、別のIPが同じ番号を5回照会するサンプルログを与えると、前者だけが「01/Oct/2026:03 203.0.113.7 照会した番号の種類=80」と出力されます。同じ番号を何度も見る利用者は正常な使い方で、異なる番号を次々に見る接続元が列挙の兆候です。パスと桁数は自社の形式に合わせて変えてください。ログ全般の見方は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)にまとめています。 ### 照会サービスに列挙対策と応答の最小化を入れる条件と見送る場面 導入を判断する条件ははっきりしています。ログインなしで照会でき、応答に個人を特定できる項目が一つでも含まれるなら、応答の最小化とレート制限は必須です。外部の事業者にAPIとして提供している場合は、APIキーごとの上限も加えます。 見送ってよいのは、照会がログイン後に限られ、自分の注文しか見られない作りで、応答にも状況しか含まれないケースです。この場合、IPごとの細かな制限を足しても効果は小さく、むしろ社内の一括処理を誤って止める原因になります。先にやるべきは、他人の注文番号を指定したときに必ず拒否されるかのテストです。 ## 漏えい等報告と再発防止の段取り｜自社が同じ立場になったときの初動 ### 個人情報保護委員会への漏えい等の報告対象と速報・確報の期限の確認 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的をもって行われたおそれがある行為による漏えい等は、件数にかかわらず報告対象です。速報は発覚から3〜5日以内、確報は不正目的の場合60日以内とされています。佐川急便が確認日の翌日に流出の可能性を公表し、FAQで委員会への報告を明記しているのは、この枠組みに沿った動きです。 四つの類型や、件数が確定していない段階での速報の書き方は[個人情報保護委員会への報告義務と速報・確報の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。委託先として荷物情報を扱っている事業者は、委託元への報告経路も事前に決めておいてください。 ### 事故時に止めるサービスの単位と告知の順番を平時に決めておく理由 今回、佐川急便は照会、受付、変更の9サービスを止めつつ、集荷・配達は継続しました。止める範囲をサービス単位で選べたのは、本業を止めずに被害の拡大を抑えられる構造だったからです。システムが一体で作られていると、一部だけを止める判断ができず、全面停止か継続かの二択になります。 平時に決めておくのは、外部公開している機能ごとの停止手順、停止中に出す案内文、問い合わせ窓口の開設手順の三つです。佐川急便は第1報の翌日に、流出の可能性の公表と専用窓口の開設まで進めています。自社で同じ速度が出せるかは、手順書を机上でなぞると見えてきます。 ### 同じ構図の事故に備えて自社の照会サービスを外部の目で点検する順番 点検の順番は、外部に公開している照会画面とAPIの棚卸し、各応答に含まれる項目の確認、他人の番号を指定したときの拒否テスト、レート制限とログ監視の有無の確認です。入口の対策だけで終えず、突破された場合にどの項目まで読まれるかまで確かめるのが要点になります。 事業者側の管理画面や保管データが狙われた同時期の事例として、[タイムズカーの不正アクセス](https://www.issoh.co.jp/tech/details/17925/)や[Gyazoの不正アクセス](https://www.issoh.co.jp/tech/details/17839/)も比較する際の参考材料です。診断の種類と費用の考え方は[脆弱性診断とは](https://www.issoh.co.jp/column/details/13101/)で整理しています。照会APIの認可設計や公開範囲の確認を外部に任せたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で画面とAPIの両方を対象に点検できます。 ## よくある質問 佐川急便の不正アクセスについて、利用者と事業者から出やすい質問をまとめました。 ### 佐川急便で荷物を受け取っただけでも対象になりますか？ 対象になる可能性は否定できません。FAQでは、スマートクラブへの登録の有無にかかわらず、2026年9月30日から遡って約100日間（6月下旬以降）に預かった荷物の送り主と届け先が対象とされています。通販で商品を受け取っただけの人も、届け先として氏名・住所・電話番号が含まれうると明記されています。自分が対象かを確認する方法は、現時点では案内されていません。 ### 流出したのは何件ですか？原因は分かっていますか？ どちらも公表されていません。件数と範囲、原因については、第三者機関の協力のもとで調査中とされています。報道やブログで件数や手口が書かれていても、佐川急便の公式発表に基づかないものは推測として扱ってください。判明した事実は同社Webサイトの「重要なお知らせ」で順次案内されます。 ### 佐川急便を名乗るSMSが届いたらどうすればよいですか？ 記載されたURLは開かず、個人情報も入力しないでください。荷物の状況を確かめたい場合は、公式サイトを自分で開くか、送り状番号を伝えて最寄りの営業所に電話します。本件の相談は専用コールセンター（0120-28-3449）で受け付けています。宛名や住所が正しくても、本物の連絡である根拠にはなりません。 ### お荷物問い合わせサービスはいつ再開しますか？ 再開時期は未定です。FAQでは、安全性を確認したうえで、再開が決まり次第Webサイトで知らせるとしています。停止中に配送状況を知りたい場合は、送り状番号を伝えて最寄りの営業所に問い合わせてください。集荷はWeb受付を止めていますが、電話での依頼は受け付けています。 ### 自社の荷物追跡や照会サービスは何から点検すればよいですか？ 最初に確認するのは、ログインなしで番号を入力したときの応答に、氏名・住所・電話番号などの個人を特定できる項目が含まれていないかです。次に、他人の番号やIDを指定したときに拒否されるかをテストします。最後に、接続元ごとの照会回数の制限と、異なる番号を次々に照会する接続元を検知するログ集計の有無を確かめてください。 ## 関連記事 - [認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説](https://www.issoh.co.jp/tech/details/16399/)：照会APIで他人のデータを返さない実装の詳細 - [APIレート制限（レートリミット）とは？5方式の比較と429設計・分散実装【2026年版】](https://www.issoh.co.jp/tech/details/16179/)：列挙対策の制限方式を選ぶときに - [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：流出情報を使ったなりすましへの備え - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：自社が当事者になったときの報告手順 - [Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)：同時期の事案で利用者が回す点検手順の比較に --- 出典: [佐川急便の不正アクセスと約100日分の荷物情報｜追跡照会サービスの点検手順]()（株式会社一創）