--- title: "ヤマト運輸の不正アクセスと後払いの請求情報漏えい｜加盟店と開発者の点検手順" url: "https://www.issoh.co.jp/tech/details/18185/" published: 2026-10-08 updated: 2026-10-08 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ヤマト運輸の不正アクセスと後払いの請求情報漏えい｜加盟店と開発者の点検手順 ヤマト運輸は2026年9月29日、「クロネコ代金後払いサービス」が第三者による不正アクセスを受けたと公表しました。10月2日の第2報では、利用者の氏名・住所・電話番号に加えて、与信番号、請求金額、債権残高、商品明細が漏えいした可能性があると発表しています。本記事では公式発表を時系列で整理し、請求情報が含まれることの重さ、利用者が警戒すべき連絡、後払いを導入していたEC事業者の対応をまとめました。後半では、外部の決済サービスと連携するシステムを持つ開発者向けに、決済手段の切り離しと加盟店APIの認証をPythonのコードで示します。 ## まとめ：ヤマト運輸の不正アクセスで公表された事実と利用者・加盟店の対応 公表済みの事実は、9月28日に「クロネコ代金後払いサービス」への不正アクセスを確認し、同日22時28分にサービスを停止したこと、一部の利用者・加盟店・担当社員の情報が漏えいした可能性があること、クレジットカード情報やパスワード情報は含まれないことです。件数、範囲、原因はセキュリティ専門機関の協力を得て調査中とされています。宅急便を含む他のサービスは通常どおり使えます。 利用者側で最優先なのは、ヤマト運輸や通販サイトを名乗る督促・払込票・SMSを疑うことです。実際の請求金額や商品名を知られている前提で、本物らしく見える請求が届きえます。後払いを導入していた事業者は、注文画面から後払いを外し、出荷前の注文の扱いを決めてください。 | 項目 | 公表されている内容 | | ------- | ----------- | | 確認日 | 2026年9月28日 | | 停止 | 同日22時28分に停止 | | 対象サービス | クロネコ代金後払い | | 対象件数 | 調査中 | | 含まれない情報 | カード情報・パスワード | | 他のサービス | 宅急便など通常どおり | | 原因 | 専門機関と調査中 | ## 公表内容を時系列で確認する｜9月28日の停止から10月2日の第2報まで ### 9月29日の初報で示された不正アクセスの確認日と停止時刻と調査の体制 [初報（2026年9月29日）](https://www.yamato-hd.co.jp/important/img/impo%5F261002%5F1%5F1.pdf)は、9月28日に不正アクセスを確認し、外部からのアクセス制限などの対策を講じたうえで、同日22時28分にサービスを停止したと説明しています。この時点では漏えいの有無には触れず、セキュリティ専門機関の協力を得て原因と影響範囲を調べていること、復旧時期は確認でき次第知らせることを伝える内容でした。 問い合わせ先は電話ではなくメールアドレスのみで、利用者向けの専用コールセンターは初報の段階では案内されていません。初報は現在、PDFとして重要なお知らせのページから参照できる形になっています。 ### 10月2日の第2報で漏えいの可能性が判明した三つの区分の情報 [第2報（2026年10月2日）](https://www.yamato-hd.co.jp/important/info%5F260929%5F1.html)で、調査の過程で情報の一部が漏えいした可能性が判明したと発表されました。対象は、一部の利用者の情報、一部の加盟店の情報、サービスを担当する社員の氏名の三つです。漏えいの可能性がある情報と範囲は引き続き調査中で、漏えいが確認された人には個別に連絡するとしています。 同じ第2報は、心当たりのない不審なメールやSMSのURLを開かず削除すること、不審な電話や郵便物にも慎重に対応することを呼びかけています。サービスの復旧時期は、引き続き「確認が取れ次第案内」との扱いです。 ### 同じ週に公表された佐川急便の事案とのサービス停止の共通点と違いの整理 同じ週には、佐川急便も「お荷物問い合わせサービス」への不正アクセスを公表しています。経緯と点検手順は[佐川急便の不正アクセスと追跡照会サービスの点検手順](https://www.issoh.co.jp/tech/details/18184/)で整理しました。同時期に物流各社で公表された不正アクセスとして、両社とも本業の集配は続けたまま、Web上の個別サービスだけを止めた点が共通しています。 違いは止まったサービスの性質です。佐川急便は荷物の照会と受付、ヤマト運輸は決済の一種である後払いでした。前者で狙われうるのは送り主と届け先の関係、後者は「いくら払うべきか」という請求の情報です。悪用のされ方も、対策を考える立場の人も変わってきます。 ## 漏えいの可能性がある情報を仕分ける｜与信番号・債権残高・商品明細の重さ ### 利用者と加盟店と担当社員の三区分で漏えい対象となりうる情報項目の一覧 第2報が示した項目を区分ごとに並べると次のとおりです。人数が最も多いとみられるのは、後払いを選んで通販サイトで買い物をした利用者です。 | 区分 | 対象となりうる項目 | 想定される悪用 | | ---- | -------------- | --------- | | 利用者 | 氏名・住所・電話・メール | なりすましの連絡 | | 利用者 | 与信番号・請求額・残高・商品 | 偽の督促・払込票 | | 加盟店 | 加盟店名・加盟店コード | 加盟店を装う連絡 | | 担当社員 | 氏名 | 担当者を名乗る電話 | ### 請求金額と債権残高が含まれることで本物らしい督促を作れる理由 カード情報やパスワードが含まれないため、カードの不正利用やアカウントの乗っ取りは起きにくい構図です。それでも今回の情報には、他の流出事案にはあまりない性質があります。「誰が、どの店で、何を買い、いくら払っていないか」が一組でそろう点です。 この組み合わせがあれば、実在する未払いの金額と商品名を書いた督促を作れます。一般的な架空請求は金額や商品が曖昧なため見破りやすいのに対し、実際の注文と一致する請求は、受け取った本人にも区別がつきません。後払いは「後日、払込票などで払う」仕組みなので、請求が届くこと自体に違和感がない点も、悪用する側には都合のよい条件です。 ### 加盟店コードと担当社員の氏名が漏れた場合に事業者側で起きること 加盟店名と加盟店コードは、ヤマト運輸と加盟店のやり取りで加盟店を識別するための情報です。これを知った第三者は、加盟店を名乗ってヤマト運輸に連絡したり、ヤマト運輸を名乗って加盟店に「再登録」や「振込先の確認」を求めたりする文面を作れます。担当社員の氏名が加わると、実在する担当者名を使った電話も可能になります。 加盟店コードが漏れただけで加盟店向けの管理画面やAPIに入れるかどうかは、公表されていません。一般論として、識別子だけで操作できる作りは危険です。この点は後半で、識別子と秘密の情報を分ける設計として扱います。 ## 利用者が今やる対応｜ヤマトを装う督促・払込票・SMSの見分け方 ### ヤマト運輸や通販サイトを名乗る督促・払込票を受け取ったときの確認先 後払いの請求について連絡が届いたら、記載されたURLや電話番号ではなく、自分で開いた通販サイトの注文履歴を確認してください。後払いの代金は買い物をした通販サイトの注文に結びついているため、注文履歴に該当する注文と支払い方法があるかで、請求の真偽をある程度判断できます。 見分ける手掛かりとして、金額や商品名は使えません。漏えいした可能性がある情報そのものだからです。払込票の見た目や差出人の名前も同じく決め手になりません。迷ったら支払う前に通販サイトの問い合わせ窓口へ確認し、偽サイトへの誘導の仕組みは[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)も参考にしてください。 ### 停止中の後払い代金の支払いと購入済み注文の扱いを確かめる手順 サービス停止中の代金の扱いについて、第2報は具体的な案内をしていません。すでに後払いで購入している場合、支払い方法や期限の変更は各通販サイトから案内されるのが通常の流れです。報道では、払込票の発行が遅れる旨や、別の支払い方法での再注文を案内する通販サイトの告知も伝えられています。 購入した店舗からの案内を待ち、案内のない段階で第三者からの「至急の支払い」の要求には応じないことが安全側の判断です。支払い済みの代金を再度求める連絡が来た場合も、払った記録を手元に残したうえで店舗へ確認してください。 ### 個別連絡を待つ間にメールアドレスと電話番号の周辺で見直す設定 漏えいが確認された人には個別に連絡が来ます。それまでの間に見直せるのは、メールアドレスと電話番号を起点にした被害の広がりです。メールアドレスと同じパスワードを複数のサービスで使っている場合は、メールアカウントと決済系サービスから変更してください。 SMSについては、携帯電話会社の迷惑SMSのフィルタを有効にしておくと、大量に送られる誘導SMSの一部を減らせます。家族が同じ通販サイトを使っている場合は、後払いの請求をかたる連絡がありうることを共有しておくと、慌てて支払う事態を防げます。 ## 後払いを導入していたEC事業者が注文画面と出荷で行う停止時の対応 ### 注文フォームから後払いを外し受注処理でも拒否する設定とコード 提供元が停止している決済手段を注文画面に出し続けると、購入者は手続きの最後でエラーを受け、離脱や問い合わせが増えます。最初に行うのは、注文フォームの選択肢から後払いを外すことです。画面から消すだけでは、古い画面を開いたままの購入者や、APIで注文を受ける経路から後払いの注文が入り続けます。受注処理の側でも同じ設定を見て拒否します。 次のPythonコードは、決済手段ごとの受付可否を一つの設定ファイルにまとめ、画面の表示と受注時の検査の両方で同じ設定を参照する例です。停止時は設定ファイルの値を書き換えるだけで、デプロイなしに切り替えられます。 ``` { "credit_card": {"enabled": true}, "convenience_store": {"enabled": true}, "kuroneko_atobarai": {"enabled": false, "reason": "提供元のサービス停止中"} } ``` ``` import json from pathlib import Path CONFIG = Path(__file__).with_name("payment_methods.json") def enabled_methods(): data = json.loads(CONFIG.read_text(encoding="utf-8")) return {k: v for k, v in data.items() if v.get("enabled")} def validate_order(order): method = order["payment_method"] if method not in enabled_methods(): raise ValueError(f"選択できない支払い方法です: {method}") return True ``` Python 3.14で上の設定を読み込むと、画面に出す支払い方法はcredit\_cardとconvenience\_storeの二つになり、kuroneko\_atobaraiを指定した注文は`validate_order`で例外になります。画面の表示を`enabled_methods()`から組み立てておけば、表示と受付の不一致が起きません。 ### 与信承認済みで出荷前の注文を出荷・保留・再注文案内に振り分ける判断 後払いでは、注文時に提供元の与信審査を通してから出荷するのが一般的な流れです。停止の時点で「与信は通ったが出荷していない」注文が残っている場合、そのまま出荷すると、後日の請求や入金の消し込みがどうなるか確定しないまま商品を手放すことになります。 判断の目安は金額と再入手の難しさです。単価が低く在庫も十分な商品なら、購入者に別の支払い方法での再注文を案内し、元の注文は取り消すのが確実です。高額品や受注生産品は、提供元からの案内が出るまで保留し、購入者には保留の理由と見込みを伝えます。どちらの場合も、提供元から個別の案内があればそれに従ってください。 ### 決済手段一つの停止で売上が止まらない構成にしておく基準と見送る場面 後払いの比率が高い事業者ほど、今回の停止による影響が大きくなる構図です。後払いの売上が全体の2割を超える、または後払いでしか買わない顧客層を抱えている事業者は、後払いの提供元を二つ持つか、コンビニ払いなど性質の近い手段を併設しておく価値があります。決済代行との接続方式の違いは[決済システムの仕組みと接続方式の判断軸](https://www.issoh.co.jp/column/details/15263/)で比べています。 後払いの利用が一部にとどまり、カード決済が主力の事業者は、提供元を増やす工数に見合いません。上の設定ファイルのように、止める手段を一か所で切り替えられる状態にしておけば足ります。提供元からの状態変化の通知を受ける作りについては[決済Webhookの署名検証と冪等な注文確定](https://www.issoh.co.jp/tech/details/15734/)も参照してください。 ## 加盟店コードが漏れても使えないAPI認証にする｜識別子と秘密鍵の分離 ### 侵入経路が非公表の段階で決済連携の開発者が自社で点検できる範囲 ヤマト運輸の事案の原因はセキュリティ専門機関と調査中で、侵入経路や手口は公表されていません。ここから先は今回の原因を推測するものではなく、加盟店や取引先とAPIで連携するサービス全般で、開発者が自社を点検するための項目です。 今回の第2報は、加盟店コードが漏えいした可能性のある情報に含まれると明記しています。加盟店コードのような識別子は、請求書や管理画面、問い合わせのやり取りなど多くの場所に書かれるため、外部に知られる前提で扱うべき値です。 ### 加盟店コードを鍵として使わずHMAC署名で送信元を確かめる設計 [OWASP API Security Top 10 2023のAPI2（Broken Authentication）](https://api-security.owasp.org/editions/2023/en/0xa2-broken-authentication/)は、予測しやすいトークンや署名を検証しない作りを認証の欠陥として挙げています。加盟店コードだけを受け取って処理するAPIは、まさにこの状態です。 対策は、加盟店コードを「誰か」を示す識別子に限定し、「本人であること」は別に配布した秘密鍵で証明させることです。よく使われるのが、リクエスト本文と時刻を秘密鍵で署名し、受け取った側で同じ計算をして照合するHMAC署名です。鍵の発行・保管・失効の手順は[APIキー管理の発行・保管・ローテーション](https://www.issoh.co.jp/tech/details/16300/)で詳しく扱っています。 ### Pythonのhmacで署名と時刻を検証するコードと各処理の役割 次のコードは、加盟店コード・時刻・本文・署名の四つを受け取り、署名が正しく、かつ時刻が5分以内のときだけ受け付ける検証処理です。[Python公式ドキュメントのhmacモジュール](https://docs.python.org/3/library/hmac.html)は、署名の比較に通常の`==`ではなく`compare_digest()`を使うよう求めています。比較にかかる時間から正しい値を推測される攻撃を防ぐためです。 ``` import hashlib import hmac import time SECRETS = {"M000123": b"replace-with-secret-from-vault"} TOLERANCE_SEC = 300 def verify(merchant_code, timestamp, body, signature): secret = SECRETS.get(merchant_code) if secret is None: return False if abs(time.time() - int(timestamp)) > TOLERANCE_SEC: return False message = timestamp.encode() + b"." + body expected = hmac.new(secret, message, hashlib.sha256).hexdigest() return hmac.compare_digest(expected, signature) ``` Python 3.14で、正しい秘密鍵で作った署名を渡すと`True`、加盟店コードは正しいが署名がでたらめな場合と、10分前の時刻を付けて同じ署名を再送した場合はどちらも`False`になることを確認しました。時刻を署名に含めるのは、盗み見たリクエストをそのまま送り直す再送攻撃を防ぐためです。`SECRETS`は説明のための書き方で、実際の秘密鍵はコードに書かず、秘密情報の保管庫から読み込みます。 ### 署名方式へ移行する条件と識別子だけの運用を当面続けてよい場面 署名方式への移行が必須なのは、加盟店コードや取引先IDだけで注文の登録、請求の発行、加盟店情報の変更ができるAPIや管理機能を持っている場合です。識別子が漏れた時点で第三者が操作できるため、今回のような漏えいが起きると被害が二次的に広がります。 識別子だけの運用を当面続けてよいのは、そのAPIが閉じたネットワーク内に限られ、通信元を固定IPと証明書で絞り込んでいる場合です。この場合でも、操作の記録に識別子と通信元を残し、普段と違う通信元からの呼び出しを検知できるようにしておきます。ログの見方は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)にまとめています。 ## 漏えい等報告と再発防止の段取り｜決済連携を持つ自社が当事者になったら ### 個人情報保護委員会への漏えい等の報告対象と速報・確報の期限の確認 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的をもって行われたおそれがある行為による漏えい等は、件数にかかわらず報告対象です。速報は発覚から3〜5日以内、確報は不正目的の場合60日以内とされています。ヤマト運輸は確認の翌日に初報、4日後に漏えいの可能性を公表しています。 後払いや決済代行の加盟店は、提供元の事故であっても、自社の顧客への説明を求められます。四つの類型や、件数が確定していない段階での速報の書き方は[個人情報保護委員会への報告義務と速報・確報の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。委託先の事故を委託元として受け止める際の連絡経路も、平時に決めておいてください。 ### 本業を止めずに個別サービスだけを切り離せる構成を平時に用意する理由 今回、ヤマト運輸は後払いのサービスを止めつつ、宅急便を含む他のサービスは通常どおり続けました。止める範囲をサービス単位で選べたのは、決済の機能が配送の機能と分かれていたからです。一体で作られたシステムでは、一部だけを止める判断ができず、全面停止か継続かの二択になります。 自社のシステムで準備しておくのは、外部公開している機能ごとの停止手順、停止中に出す案内文、取引先と利用者への連絡手段の三つです。前半で示した決済手段の切り替え設定は、このうち停止手順を一行の変更にまとめる仕組みにあたります。 ### 決済連携と管理画面を外部の目で点検するときの確認の順番と対象範囲 点検の順番は、外部の決済サービスや取引先とつながるAPIと管理画面の棚卸し、各APIが識別子だけで操作できないかの確認、秘密鍵の保管場所と失効手順の確認、操作ログの保存と検知の有無の確認です。入口の認証だけで終えず、突破された場合にどの情報まで読まれるかまで確かめるのが要点になります。 保管データが狙われた同時期の事例として、[タイムズカーの不正アクセスと保管設計](https://www.issoh.co.jp/tech/details/17925/)も比較の材料になります。診断の種類と費用の考え方は[脆弱性診断とは](https://www.issoh.co.jp/column/details/13101/)で整理しました。決済連携のAPI認証や管理画面の公開範囲の確認を外部に任せたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で画面とAPIの両方を対象に点検できます。 ## よくある質問 ヤマト運輸の不正アクセスについて、利用者と事業者から出やすい質問をまとめました。 ### クロネコ代金後払いを使ったことがあれば対象になりますか？ 対象になる可能性はありますが、確定ではありません。第2報は「一部のお客さま」の情報としており、対象の期間や範囲は調査中です。漏えいが確認された人にはヤマト運輸から個別に連絡するとされています。自分が対象かを調べる方法は、現時点では案内されていません。 ### 漏えいしたのは何件ですか？原因は分かっていますか？ どちらも公表されていません。原因と影響範囲は、セキュリティ専門機関の協力を得て調査中とされています。報道やブログで件数や手口が書かれていても、ヤマト運輸の公式発表に基づかないものは推測として扱ってください。続報はヤマトホールディングスのWebサイトの「重要なお知らせ」に掲載されます。 ### 宅急便の利用や荷物の受け取りに影響はありますか？ 宅急便の利用や荷物の受け取りへの影響はないとの説明です。初報・第2報とも、宅急便を含む他のサービスは通常どおり利用できると明記しています。停止しているのは「クロネコ代金後払いサービス」で、通販サイトで後払いを選べない、または後払いの請求手続きが遅れるといった形で影響が出ます。 ### 後払いの督促や払込票が届いたら支払ってよいですか？ 支払う前に、購入した通販サイトの注文履歴と支払い方法を自分で確認してください。請求金額や商品名が正しくても、漏えいした可能性がある情報で作られた偽の請求である可能性があります。注文履歴と一致しない、または支払い済みの代金を求められる場合は、通販サイトの問い合わせ窓口へ確認するまで支払わないでください。 ### 後払いを導入している事業者は何から対応すればよいですか？ 最初に、注文フォームの選択肢から後払いを外し、受注処理でも後払いの注文を受け付けない設定にします。次に、与信承認済みで出荷前の注文を、金額と商品の性質で出荷・保留・再注文案内に振り分けます。並行して、購入者向けに偽の督促への注意を案内し、提供元からの個別の連絡を確認してください。 ## 関連記事 - [佐川急便の不正アクセスと約100日分の荷物情報｜追跡照会サービスの点検手順](https://www.issoh.co.jp/tech/details/18184/)：同じ週に公表された物流事案の整理と照会サービスの対策 - [APIキー管理とは？発行・保管・失効とローテーションの実装を解説](https://www.issoh.co.jp/tech/details/16300/)：加盟店に配る秘密鍵の扱いを決めるときに - [決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説](https://www.issoh.co.jp/tech/details/15734/)：決済サービスからの通知を安全に受ける実装 - [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：漏えい情報を使ったなりすましへの備え - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：自社が当事者になったときの報告手順 --- 出典: [ヤマト運輸の不正アクセスと後払いの請求情報漏えい｜加盟店と開発者の点検手順]()（株式会社一創）