ネットプロテクションズは2026年10月22日、後払い決済サービス「NP後払い」の請求書再発行システムに、第三者から機械的かつ連続的なリクエストが行われたと公表しました。お客様の氏名と住所にアクセスがあり、対象は28,884件です。NP後払いそのものは通常どおり使えます。前半では公表文をもとに、件数の意味、問い合わせ窓口、使い続けてよいか、偽の請求への備えを整理しました。後半は、番号を変えて照会を繰り返す攻撃を再発行の窓口で止める設計を、Pythonで動かして確かめます。
まとめ：NP後払いの不正アクセスで見られた氏名と住所、利用者が今日やること
ネットプロテクションズの公表文によると、事案が判明したのは10月14日です。請求書再発行システムに、通常想定されない方法でリクエストが繰り返されていました。同社は原因と影響範囲を調べながらセキュリティ対策を進めており、10月22日時点で情報の不正利用は確認されていません。
NP後払いの利用者が今日やることは2つです。1つは、NP後払いを名乗るメールやSMSで支払いや個人情報の入力を急がされても、文中のリンクから進まないこと。もう1つは、対象かどうか気になる場合に、公表文の窓口へ自分から問い合わせることです。氏名と住所が正しく書かれた偽の請求が届いても、それだけで本物と判断しないでください。
| 項目 | 公表内容（2026年10月22日時点） |
|---|---|
| 判明した日 | 2026年10月14日（水） |
| 対象件数 | 28,884件（NP後払いの一部の取引） |
| アクセスされた項目 | 氏名・住所 |
| 法人の利用 | 会社名・部署名も含む |
| 請求書が返送された取引 | 請求書が未着だった事実も含む |
| NP後払いの利用 | 影響なし、通常どおり使える |
| 再発行システム | 停止中、安全を確認でき次第再開 |
| 未公表 | 原因・手口・人数・再開日・補償 |
NP後払いの利用者が最初に確かめること：対象の範囲、窓口、使い続けてよいか
対象の線引き、2万8,884件は取引の件数で利用者の人数ではない
公表文は対象を「28,884件」とし、対象となるのは「NP後払いをご利用いただいた一部のお取引」と書いています。数えているのは取引で、人ではありません。同じ人が何度もNP後払いで買い物をしていれば、1人で複数件に数えられている可能性があります。実際の人数は28,884人より少ないと見られますが、人数そのものは公表されていません。
住所は購入時に登録したもので、今の住所とは異なる場合があると公表文は注記しています。引っ越し前の住所で買い物をした取引も対象に入りえます。電話番号、メールアドレス、購入した商品、請求金額は、アクセスされた項目に挙がっていません。
問い合わせは平日9時から18時のサポートデスクと専用フォームの2つ
本件の問い合わせ先は、NP後払いのサポートデスクです。電話番号は0570-077-015で、受付は平日の9時から18時、土日祝日は休みです。公表文には本件専用のお問い合わせフォームも載っているので、平日の日中に電話できない人はそちらを使ってください。
対象の利用者には、ネットプロテクションズが電子メールなどで個別に案内を進めるとしています。案内が届かないまま気になる場合は、上の窓口へ自分から問い合わせるのが確実です。届いた案内の真偽を確かめたいときも、メールに書かれた番号ではなく、公表文に載っている番号へかけてください。
NP後払いは通常どおり使え、止まっているのは請求書の再発行だけ
公表文は、NP後払いのサービス提供に影響はないと明記しています。通販サイトで支払い方法にNP後払いを選び、届いた請求書でコンビニや銀行から払う流れはそのままです。今回止まっているのは請求書再発行システムで、セキュリティを強化して安全が確認でき次第、再開するとしています。
請求書をなくした、届かないといった理由で再発行を頼みたい人は、再開までの間はサポートデスクに相談してください。公表文は再開日も、停止中の代わりの手段も示していません。支払期限が近い場合ほど、早めに問い合わせておくと安心です。
氏名と住所を知る相手からの偽の請求書・督促SMSを見分ける基準
今回アクセスされたのは氏名と住所で、請求書が返送された取引では、請求書が届いていなかったという事実まで含まれます。「請求書が届いていないようなので、こちらから支払ってください」という連絡は、この事実を知っている相手なら作れてしまう文面です。ネットプロテクションズ自身も、対象者に電子メールなどで案内するとしているため、本物と偽物が同じ時期に届くことになります。
見分けの基準は単純で、メールやSMSのリンクから支払いや入力の画面に進まないことです。請求の状況はNP後払いの購入者向けサイトをブックマークや検索から自分で開いて確かめてください。郵送で届いた請求書でも、振込先が個人名義の口座になっているものは疑ってかかるべきです。偽の連絡が成り立つ仕組みはフィッシング詐欺の成立の仕組みと技術的対策で取り上げました。
公表文から読む事案の構造：請求書再発行システムへの機械的な連続リクエスト
10月14日の判明から22日の公表まで、時系列と公表されていない事柄
公表文から読み取れる経過は、10月14日の判明、原因と影響範囲の調査、個人情報保護委員会と日本情報経済社会推進協会（JIPDEC）への報告、10月22日の公表、という順です。いつからリクエストが続いていたのか、何を入力すると氏名と住所が返る仕組みだったのかは書かれていません。
読み取れるのは、システムに入り込んで中のデータを持ち出したのではなく、再発行の窓口に外からリクエストを大量に送り、返ってくる情報を集めたという形です。正規の利用者が使う窓口を、人では不可能な速さと回数で叩いた点に特徴があります。原因、手口、人数、再開日、補償の有無は、10月30日時点でネットプロテクションズのニュース一覧に続報が出ていません。
クロネコ代金後払いの漏えいとの違い、同じ後払いでも事業者と経路は別
後払い決済の情報漏えいは、9月にもヤマト運輸の「クロネコ代金後払いサービス」で公表されています。こちらは別の会社が運営する別のサービスで、氏名・住所・電話番号に加えて与信番号や請求金額まで漏えいした可能性があるとされた事案です。経緯はヤマト運輸の不正アクセスとクロネコ代金後払いの対象と窓口で整理しました。
NP後払いの今回の事案でアクセスされた項目は氏名と住所が中心で、請求金額は項目に挙がっていません。どちらの後払いを使ったかで、問い合わせ先も警戒すべき偽の連絡も変わります。手元の請求書やメールで、利用したサービス名を先に確かめてください。
個人情報保護委員会への報告と、確報の期限から見る続報公表の時期
漏えい等の報告は個人情報保護法の第26条が定めています。個人情報保護委員会の漏えい等の対応ページによれば、速報は発覚から3〜5日以内、確報は30日以内が原則で、不正の目的によるおそれがある場合の確報は60日以内です。10月14日の判明から数えると、60日の期限は12月中旬にあたります。原因や確定した件数は、そのころまでに続報として出る可能性があるということです。速報と確報に書く内容は個人情報保護委員会への報告義務の実務で解説しています。
開発側の教訓：番号を変えて照会を繰り返す攻撃を再発行の窓口で止める設計
照会の応答に氏名と住所を出す窓口が、連続リクエストで名簿になる仕組み
請求書の再発行や配送状況の照会のように、番号を入れると本人の情報が返る窓口は、通販や決済のシステムに珍しくありません。1件ずつ人が使う分には便利な機能です。ところが番号に規則性があり、回数の制限が無いと、番号を1つずつ変えて送り続けるだけで、返ってきた氏名と住所が名簿として積み上がります。ここから先は、NP後払いのシステムがどう作られていたかを推測するものではなく、同じ形の窓口を持つシステム全般の話です。
OWASP API Security Top 10のAPI6:2023は、業務上の流れを自動化された過度なアクセスから守らないことをリスクに挙げています。対策として示しているのは、想定外のクライアントの識別、CAPTCHAなどによる人間の判定、人間には不可能な操作パターンの検知、既知のプロキシからのアクセス遮断です。API4:2023は、一定時間内の回数制限と、1つのクライアントが同じ操作を実行できる回数の制限を求めています。OWASPのリスク全体の見取り図はAPIセキュリティとOWASP API Top 10の実装対策にまとめました。
送信元ごとの回数と照会番号の種類数で絞るPythonの再現と実行結果
次のコードは標準ライブラリだけで動きます。対策の無い窓口と、送信元ごとに60秒あたり5回までの回数制限、かつ照会できる取引番号を3種類までに絞る窓口を比べました。時刻の管理にはPythonのcollectionsにあるdequeを使っています。対策した側は、画面に氏名と住所を出さず、登録住所へ郵送したという受付の事実だけを返します。
# 請求書再発行の照会に「機械的かつ連続的なリクエスト」が来た想定で、止め方を再現する（Python 3.8以上・標準ライブラリのみ）
# 使い方: python reissue_guard.py
from collections import Counter, defaultdict, deque
WINDOW = 60 # 判定の窓（秒）
MAX_REQ = 5 # 1クライアントが窓の中で送れる照会の上限
MAX_KEYS = 3 # 1クライアントが窓の中で照会できる取引番号の種類の上限
ORDERS = {f"NP{n:06d}": ("見本 太郎", "東京都見本区1-2-3") for n in range(1, 2001)}
hits = defaultdict(deque) # クライアントごとの照会時刻
keys = defaultdict(deque) # クライアントごとの（時刻, 取引番号）
def naive(client, order_no, now):
# 対策なし：番号が合えば氏名と住所をそのまま返す
if order_no not in ORDERS:
return "404"
return "200 " + " ".join(ORDERS[order_no])
def guarded(client, order_no, now):
q, k = hits[client], keys[client]
while q and now - q[0] >= WINDOW:
q.popleft()
while k and now - k[0][0] >= WINDOW:
k.popleft()
q.append(now)
k.append((now, order_no))
if len(q) > MAX_REQ:
return "429 rate"
if len({x[1] for x in k}) > MAX_KEYS:
return "429 keys"
if order_no not in ORDERS:
return "404"
# 画面には出さず、登録住所へ郵送する。応答は受付の事実だけ
return "202 mailed"
def run(handler, clients, interval, count):
# 取引番号を1から順に試す。clients が複数なら送信元を順番に替える
hits.clear()
keys.clear()
res = [handler(clients[i % len(clients)], f"NP{i + 1:06d}", i * interval) for i in range(count)]
return dict(Counter(r if r.startswith("429") else r.split(" ")[0] for r in res))
one = ["203.0.113.7"]
many = [f"203.0.113.{n}" for n in range(1, 101)]
print("[naive 1 IP, 1s ]", run(naive, one, 1, 100))
print("[guard 1 IP, 1s ]", run(guarded, one, 1, 100))
print("[guard 1 IP, 15s]", run(guarded, one, 15, 100))
print("[naive 100 IPs ]", run(naive, many, 1, 100))
print("[guard 100 IPs ]", run(guarded, many, 1, 100))
print("[user same no. ]", [guarded("198.51.100.4", "NP000123", t) for t in (0, 30)])Python 3.14.7（Windows）で実行した結果です。
$ python reissue_guard.py
[naive 1 IP, 1s ] {'200': 100}
[guard 1 IP, 1s ] {'202': 3, '429 keys': 2, '429 rate': 95}
[guard 1 IP, 15s] {'202': 3, '429 keys': 97}
[naive 100 IPs ] {'200': 100}
[guard 100 IPs ] {'202': 100}
[user same no. ] ['202 mailed', '202 mailed']1行目は、対策の無い窓口に1秒ごとに番号を変えて100回送ると、100件すべての氏名と住所が返ることを示します。2行目では、4回目と5回目が取引番号の種類数で、6回目以降が回数で止まりました。3行目は15秒おきに送って回数制限をくぐろうとした場合です。60秒に4回なら回数の上限には届きませんが、照会する番号の種類で97回が止まります。拒否した照会も窓の中に数えているので、待っても制限は解けません。
6行目は、正規の利用者が同じ番号で2回再発行を頼んだ場合で、どちらも受け付けられています。人が自分の請求書を探す使い方は番号の種類が1つか2つで、種類数の制限に引っかかりません。回数制限の方式（固定窓・スライディングウィンドウ・トークンバケットなど）と429の返し方はAPIレート制限の5方式の比較と429設計で詳しく比べています。
送信元を100に分けられると回数制限は効かない、応答から個人情報を外す理由
4行目と5行目が、このコードの限界です。送信元を100個に分けて1回ずつ送ると、送信元ごとの回数制限も番号の種類数の制限も効かず、5行目では100回すべてが受け付けられました。それでも5行目で氏名と住所が1件も漏れていないのは、応答が「郵送した」という事実だけで、画面に個人情報を出さないからです。
実務で効くのは、この順番です。最初に、照会の応答に氏名や住所を出す必要が本当にあるかを見直します。再発行なら登録住所への郵送や登録メールへの送付で済み、画面に出さなければ番号を当てても何も得られません。次に行うのは、送信元ごとの回数と番号の種類数で絞る処理です。最後に、送信元が分散した攻撃に備えて、窓口全体の404の割合や照会件数を時間ごとに監視し、平常時から外れたら止められるようにします。APIの入口で認可とトークンの失効まで組む手順はAPI不正アクセス対策の実装手順で扱っています。
事業者の判断：照会や再発行の窓口を持つ通販・決済事業者が診断を入れる条件
番号だけで本人の情報が返る窓口があるなら、外部診断で列挙への耐性を確認
請求書の再発行、配送状況の照会、注文履歴の確認のように、ログインせずに番号で使える窓口は利用者には便利です。その分、攻撃者にとっても入口になります。今回のように、侵入ではなく正規の窓口を大量に叩く手口は、通常の脆弱性スキャンだけでは見つかりにくい種類の弱点です。
次の3つのどれかに当てはまるなら、外部の脆弱性診断で、番号を変えた連続リクエストへの耐性を確かめてください。ログインせずに番号だけで氏名や住所が画面に出ること、取引番号や注文番号が連番や推測できる規則で振られていること、窓口の照会件数や404の割合を誰も見ていないことです。逆に、照会の応答に個人情報を一切出さず、結果を登録先へ送る作りになっているなら、まずは回数制限と監視の追加で足ります。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準で解説しています。
自社の照会や再発行の窓口に同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
NP後払いの不正アクセスについて、利用者から出やすい質問をまとめました。
NP後払いを使ったことがあれば、全員が対象ですか？
対象はNP後払いを使った取引のうち一部で、件数は28,884件です。NP後払いを使ったことがある人の全員ではありません。対象の利用者には、ネットプロテクションズから電子メールなどで個別に案内が届きます。案内が無いまま気になる場合は、サポートデスク（0570-077-015・平日9時〜18時）か、公表文に載っている問い合わせフォームで確かめてください。
28,884人の情報が漏れたということですか？
28,884は取引の件数で、人数ではありません。同じ人が複数の取引でNP後払いを使っていれば、1人が複数件に数えられています。そのため実際の人数はこれより少ないと見られますが、10月22日時点で人数は公表されていません。
NP後払いはこのまま使っても大丈夫ですか？
公表文は、NP後払いのサービス提供に影響はなく、通常どおり使えるとしています。止まっているのは請求書再発行システムで、安全が確認でき次第再開する予定です。支払いは届いた請求書の案内どおりに進め、メールやSMSのリンクから支払うことは避けてください。
請求書をなくしたとき、再発行はどうすればよいですか？
請求書再発行システムは本件を受けて止まっており、10月22日時点で再開日は決まっていません。公表文は停止中の代わりの手段を示していないため、サポートデスクに電話するか、問い合わせフォームから相談するのが確実です。支払期限が近い場合は、その旨も伝えてください。
NP後払いの情報漏洩で補償はありますか？
10月22日時点の公表文に補償の記載はありません。情報の不正利用も確認されていないとしています。今後の対応は、個別の案内やネットプロテクションズのニュース一覧に出る続報で確かめてください。
関連記事
- ヤマト運輸の不正アクセス・情報漏えい｜クロネコ代金後払い約526万件の対象と窓口：同じ後払い決済で起きた別事業者の事案
- APIレート制限（レートリミット）とは？5方式の比較と429設計・分散実装【2026年版】：連続リクエストを止める回数制限の方式比較
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：窓口の入口で認可と制限を組む手順
- APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説：業務フローの自動化攻撃を含むリスクの全体像
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時に事業者が報告する内容と期限
