佐川急便への不正アクセス：荷物問い合わせから、約100日分の送り主・届け先情報が対象に。

確認されていること

佐川急便は、2026年9月30日に同社Webサイトの「お荷物問い合わせサービス」で第三者による不正アクセスを確認したと公表しました。10月1日には、お客さまの個人情報が外部に流出した可能性があると発表しています。第2報。

概要図：記事の見出しと、送り主・届け先・電話番号の欄を黒く塗りつぶした送り状のイラスト

概要：この記事のために作成した図です。

表現に注意が必要です。公表は「流出した可能性がある」としており、流出したとは断定していません。件数も示されていません。

対象となる可能性があるのは、次の3つのグループです。

同社が預かった荷物の送り主・届け先。 氏名、住所、電話番号。法人の場合は法人名と担当者名。9月30日から遡り約100日間の累計データとされています。
同社と運賃契約を結んでいる法人・個人の顧客。 氏名、住所、電話番号。法人の場合は同じく法人名と担当者名。
Webサービス「スマートクラブ」の登録者。 氏名、住所、電話番号、メールアドレス、スマートクラブの会員ID。

対象となる可能性のある3つのグループと、それぞれの情報項目の一覧。件数はいずれも公表されていません。

図1：対象となる可能性のある方と情報。この記事のために作成した図です。

同社は、クレジットカード情報とパスワードは含まれていないとしています。

佐川急便は被害拡大を防ぐため、Webサービス9件を停止しました。インターネット貨物お荷物問い合わせとそのAPI、集荷の受付、受取先変更などが含まれます。お荷物の集荷・配達は通常どおり行われています。

停止中のWebサービス9件と、継続している集荷・配達。

図2：停止中のWebサービスと、継続している業務。この記事のために作成した図です。

日付（JST）	出来事	出典
10月1日	第3報：専用コールセンターを開設。影響範囲と原因は引き続き調査中。	第3報
10月1日	第2報：個人情報が流出した可能性を公表。Webサービス9件を停止。	第2報
9月30日	第1報：お荷物問い合わせサービスへの不正アクセスを確認。同サービスへのアクセスを一部制限。	第1報

時系列：対象の荷物データは6月22日ごろから9月30日まで。9月30日に不正アクセスを確認し、10月1日に流出の可能性を公表。7月18日には別の事案としてスマートクラブのメール誤表示が公表されています。

図3：対象データの期間と公表の時系列。この記事のために作成した図です。

佐川急便は、同社を装った不審なメール、SMS、電話への注意を呼びかけています。同社サイトの注意喚起ページは、荷物の集配についてSMSによる案内は行っていないと明記しています。佐川急便の注意喚起。

対象範囲の読み方

件数はまだ公表されていません。 公表は、件数と範囲を調査中としています。他で見かける数字は未確認のものとして扱ってください。

「約100日間」は荷物データの期間であり、侵入の期間ではありません。 9月30日から数えると、6月22日ごろが始点になります。不正アクセスがいつ始まり、どのくらい続いたかは公表されていません。

届け先の方は、同社の会員でなくても対象になり得ます。 荷物を1回受け取っただけの人は、同社にアカウントを持たず、サイトを訪れたこともないかもしれません。それでも氏名、住所、電話番号が対象として挙げられています。

二次情報から原因を持ち込まないでください。 一部のまとめ記事は、脆弱性が悪用された、照会リクエストを偽装する手口だった、修正を適用した、個人情報保護委員会と警察に届け出た、などと記載しています。当サイトが確認した3つの公表文には、いずれの記載もありません。佐川急便は、原因を引き続き調査中としているだけです。

7月の事案とは分けて考えます。 佐川急便は7月、スマートクラブの配達予定通知メールに別の利用者の情報が表示され、約7万人に影響した可能性があると公表しました。原因は復旧作業時の設定の誤りで、不正アクセスではないと説明しています。ITmedia（7月18日）。公表されている範囲では、2つの事案に共通するのはサービス名だけです。

セキュリティ態勢への意味

関連する対応手順： APIデータ漏えいプレイブックで、公開照会の範囲、バックエンドへの到達、別のAPI経路、復旧の証拠を確認できます。対応上の関連であり、佐川急便の公表内容がオブジェクト認可の欠陥や特定のAPI攻撃を示すわけではありません。

この事案からは、2つの見直しが導かれます。1つは外部公開の照会サービスを運用するすべての組織に、もう1つは配送事業者を利用して出荷している企業に関わるものです。

外部公開の照会サービスが読み出せる範囲

不正アクセスを受けたのは荷物の問い合わせサービスです。一方、流出した可能性のある情報は配送状況より広く、約100日分の荷物の氏名、住所、電話番号に加え、運賃契約の顧客やスマートクラブ登録者にも及びます。

当サイトの分析： 公表文は、その経緯を説明していません。当サイトも推測しません。注目すべきなのは、この差そのものです。照会画面が利用者に見せる情報はわずかでも、その裏にあるサービスは、はるかに多くのデータを読み出せる場合があります。

自社の照会・検索・状況確認サービスについて、次の4点を確認します。

サービス自身のアカウントは、どのデータを読み出せますか。画面に表示する範囲より広くなっていませんか。
Web画面とは別にAPIがありますか。そのAPIは、画面に表示する以上の項目を返していませんか。
データはどこまで遡って保持されていますか。その期間は何を根拠に決まっていますか。
照会サービスだけを停止できますか。それとも、停止すると受付や変更の機能まで止まりますか。

4点目は仮定の話ではありません。佐川急便は、集荷の受付や受取先変更を含む9件のサービスを停止する一方、集荷と配達は継続しました。サービス単位での封じ込めです。これは、必要なときにサービスを切り分けられる構成になっていて初めて成り立ちます。

配送事業者の事案に含まれる自社の顧客

自社が佐川急便で出荷している場合、対象になり得る自社のデータは2種類あります。1つは契約の情報で、法人名、担当者名、住所、電話番号です。もう1つは、対象期間に出荷した荷物の届け先、つまり自社の顧客です。

当サイトの分析： 正しい氏名と住所を使い、実際に最近荷物を受け取った人に届く連絡は、一般的な文面よりはるかに信じられやすくなります。佐川急便を装った偽の配達通知は、以前からある手口です。同社の注意喚起ページには、偽の不在通知SMSを含む多数の事例が掲載されています。

佐川急便で出荷している企業は、次を確認します。

自社の契約と、対象期間の出荷分が対象に含まれるかを、佐川急便の担当窓口に確認します。
お荷物問い合わせAPIやWeb集荷受付を呼び出している仕組みを確認します。これらは停止中のため、注文ページや顧客向けメールでエラーやリンク切れが起きる可能性があります。
顧客に何を伝えるかを決めます。顧客の情報が流出したと伝えるのは、範囲が確定してからにします。
カスタマーサポートに共有します。配達に関する連絡が本物かどうか、顧客から問い合わせが来ます。
職場で荷物を受け取る従業員にも知らせます。法人宛ての荷物の担当者名は、対象の情報に含まれています。

SMSと電話はメールゲートウェイを通りません。顧客に対して自社ができる対策は、自社と配送事業者がどのような方法で連絡するか、しないかを明確に伝えることだけです。

どのチームが確認するか

チーム	次の確認事項
委託先リスク	自社の顧客の配送先情報を保有している配送事業者・物流事業者を一覧にする。自社の契約と出荷分が対象か、照会用データの保持期間はどのくらいかを佐川急便に確認する。
IT運用	佐川急便のお荷物問い合わせAPIやWeb集荷受付を呼び出している連携を洗い出し、手作業での代替手順を用意する。自社の外部公開の照会サービスを、上記の4点で棚卸しする。
法務・プライバシー	配送事業者に渡している顧客・従業員の情報を整理する。範囲が確定した段階で、対象者に対する義務の有無を法務担当者が判断する。顧客向けの文面は今から準備する。
メールセキュリティ	佐川急便の名称を使い、同社以外のドメインから届いたメールを確認する。配送事業者ブランドのなりすまし対策を強化する。
SIEM / SOC	下記の調査を実施し、類似ドメインとメールを確認する。現段階で配送事業者からのIOC提供は前提にしない。
EDR	管理対象の端末で、偽の配達ページ経由のペイロードを監視する。管理外のスマートフォンは把握できない範囲として明示する。

IOCとハンティング

確認した公表文には、攻撃者のIPアドレス、ドメイン、ハッシュ値、手口の記載がありません。この記事には本事案のIOCはなく、推測で補うべきでもありません。

企業が調査できるのは、事案の後に続く動きです。偽の配達通知と、その誘導先となる類似サイトがこれに当たります。佐川急便の注意喚起ページには、ホスト名に「sagawa」を含みながら同社のドメインの外にある偽サイトの例が示されています。以下の3つのクエリは、このパターンを探すものです。いずれも例示であり、実データでは実行していません。

佐川急便の名称を使い、別のドメインから届いた受信メール：

// 例示です。Microsoft Defender XDR の Advanced Hunting、EmailEvents テーブル。
// Microsoft Sentinel では Timestamp を TimeGenerated に置き換えます。
// sagawa-exp.co.jp は同社の公開Webサイトのドメインです。
// このフィルターに頼る前に、実際の送信ドメインを確認してください。
EmailEvents
| where Timestamp >= datetime(2026-09-30)
| where EmailDirection == "Inbound"
| where Subject contains "佐川" or Subject contains "sagawa"
    or SenderDisplayName contains "佐川" or SenderDisplayName contains "sagawa"
| extend SenderDomain = tolower(SenderFromDomain)
| where SenderDomain != "sagawa-exp.co.jp"
    and not(SenderDomain endswith ".sagawa-exp.co.jp")
| project Timestamp, SenderFromAddress, SenderDisplayName, Subject,
          RecipientEmailAddress, DeliveryAction, ThreatTypes

ホスト名に「sagawa」を含み、同社のドメインの外にある接続先へ通信した管理対象の端末：

// 例示です。Microsoft Defender XDR の Advanced Hunting、DeviceNetworkEvents テーブル。
DeviceNetworkEvents
| where Timestamp >= datetime(2026-09-30)
| where isnotempty(RemoteUrl) and RemoteUrl contains "sagawa"
| extend ParsedHost = tostring(parse_url(RemoteUrl).Host)
| extend Host = tolower(iff(isempty(ParsedHost), RemoteUrl, ParsedHost))
| where Host != "sagawa-exp.co.jp" and not(Host endswith ".sagawa-exp.co.jp")
| summarize Connections = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
          by DeviceName, Host

同じ考え方を、CrowdStrike FalconのDNSリクエストに当てはめた例：

// 例示です。CrowdStrike Falcon LogScale、DnsRequest イベント。
// このイベントにはセンサーID（aid）が含まれ、ホスト名は含まれません。
// トリアージの前に、aid を自社の端末台帳と突き合わせてください。
#event_simpleName=DnsRequest
| DomainName=/sagawa/i
| DomainName!=/(^|\.)sagawa-exp\.co\.jp$/i
| groupBy([aid, DomainName], function=[count(as=Requests),
          min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)])

結果は、次の3つの限界を踏まえて読みます。

検出は調査の手がかりであり、結論ではありません。無関係の事業者や正規の提携先サイトが、同じ名称を使っている場合があります。
事案を扱う報道やメールマガジンは、メールのクエリに一致します。内容を確認したうえで除外します。
個人のスマートフォンに届く偽の配達SMSは、これらのテーブルには現れません。

未確認の点

佐川急便は、範囲と原因を引き続き調査中としています。下記の確認時点で、公表文では次の点が明らかになっていません。

人数。 3つの対象のいずれについても、件数は公表されていません。
実際に流出したか。 公表文は、流出した可能性があるとしています。流出したとは確認していません。
手口と侵入経路。 記載がありません。
アクセスの開始時期と期間。 不正アクセスを確認した日だけが示されています。
問い合わせサービスからこのデータに到達できた理由。 荷物の問い合わせと、契約情報や会員情報との関係は説明されていません。
個別の通知。 対象者に通知するのか、どのように通知するのかは記載がありません。
サービスの再開時期。 停止中の9件について、再開日は示されていません。
個人情報保護委員会と警察への報告。 3件の公表文には記載がありません。

次の公表が出た時点で、この記事を見直します。件数の確定や原因の公表があれば、上記の評価は変わります。

編集メモ

2026年10月2日03:36 UTC／12:36 JSTまでの公開情報を確認しました。この時点で、佐川急便のお知らせ一覧には第3報より後の更新はありませんでした。本事案に関する事実は、佐川急便の3件の公表文に基づいています。7月の事案はITmediaの報道に基づいて記載しました。同報道がリンクしている佐川急便の7月の公表ページは、確認時点で閲覧できませんでした。

二次情報として、セキュリティ対策Labと一般のニュースブログの2件を、調査の手がかりとして読みました。公表文にない内容については、公表文に従っています。

これは公開された発表に対する独立した編集分析です。SecOpsNomadが実施した調査ではなく、不正アクセスの手口について何らかの主張をするものでもありません。

出典

2026年10月16日： 再利用可能なAPIデータ漏えい対応手順へのリンクを追加しました。事件の事実認定と不明点は変更していません。

30秒でわかる要点