ピックゴーの不正アクセス：7NOW約16.9万件と出前館の流出、配送委託先に渡す項目と案件APIの認可

CBcloudが運営する配送マッチングサービス「ピックゴー」が第三者の不正アクセスを受け、配達を委託していたセブン‐イレブン・ジャパンの「7NOW」と出前館の注文者情報が外部に取得されました。両社は2026年11月3日に公表しています。7NOWでは注文者（届け先）の氏名（カナ）など3区分で合計169,151件、出前館では氏名799件などです。前半では利用者が受け取る連絡と二次被害への備えを、後半では委託元が行う渡す項目の棚卸しと連携の止め方、配送の案件APIで担当者以外に届け先を返さない認可の実装を整理します。

まとめ：ピックゴーの不正アクセスで流出した2社の注文者情報と委託元が先に確かめること

判明は2026年11月1日で、CBcloudの調査によるものです。セブン‐イレブン・ジャパンの公表と出前館の公表を並べると、取得された項目と連絡の方法に違いがあります。

両社とも、クレジットカード情報とID・パスワードは漏えいしていないとしています。自社の認証情報や連携設定が流出したり書き換えられたりした事実も、CBcloudの調査では確認されていません。7NOWは通常どおり使えます。

配送を外部の基盤に任せている事業者が先に確かめることは3つです。委託先へ渡している項目に、配達に要らないものが混ざっていないか。委託先の侵害を知った時点で、連携を自社側から止められるか。報告と本人への通知を、委託先と自社のどちらがいつまでに出すか。開発者は、案件のAPIが担当者以外にも届け先を返していないかを点検します。

7NOW・出前館の利用者向け：SMSとメールの連絡と配送会社を装う連絡への備え

7NOWは登録電話番号へSMS、出前館は登録メールで知らせる違いと問い合わせ窓口

7NOWの対象者には、登録している電話番号あてにショートメッセージ（SMS）が順次届きます。出前館の対象者には、登録しているメールアドレスへの連絡です。どちらも「順次」としており、連絡が来ていないことは対象外の証明になりません。

7NOWの問い合わせは7NOWお問い合わせ窓口（0120-711-099、9時〜21時）と、CBcloudのお客様相談窓口（customer.support@cb-cloud.com）の2つです。SMSにURLが書かれていても、まずは公式サイトの公表文と見比べます。SMSで届いた通知が本物かを番号と文面で確かめる考え方は、イエローハットの情報漏洩で届いたSMSの見分け方でも扱いました。

カード情報とパスワードが対象外でも、住所と電話番号で起きる二次被害の型

カード番号やパスワードが漏れていないので、不正ログインや不正決済の心配は小さめです。気をつけるのは、名前・住所・注文した商品を知っている相手からの連絡です。出前館は、同社や配送会社を装った不審な電話・メール・SMSと、身に覚えのない請求や個人情報の入力・支払いを求める連絡に応じないよう呼びかけています。

7NOWで取得された大半の164,180件は氏名（カナ）だけで、住所や電話番号は付いていません。住所と電話番号まで揃うのは209件です。出前館の33件も同じく電話番号まで含みます。この少数の対象者は、配達や再配達を名目にした電話に特に注意します。

公表資料で追う経緯：11月1日の判明から出前館の連携停止と再開までの時系列

2社の公表文から抜き出した日時と、委託元が事態を知るまでのずれ

2社の公表文に書かれた日時を並べると、委託先で判明してから委託元に連絡が届くまで、出前館で1日、セブン‐イレブンで2日かかっています。

セブン‐イレブンの公表文は、7NOWの情報が含まれていたと判明したのを11月3日としています。委託先で侵害が分かった時点では、どの荷主のデータが含まれるかまでは分からないことがある、という例です。

「不正に作成されたアカウント」と「悪用された不具合」から読める範囲と未公表の点

CBcloudの対応について、セブン‐イレブンは「不正に利用されたアカウントの停止」と「不正アクセスに悪用された不具合の修正」、出前館は「不正に作成されたアカウントの無効化」と書いています。第三者がピックゴー上にアカウントを作り、何らかの不具合を使って他社の配達案件の情報を取ったと読める書き方です。一部の機能と日本国外からのアクセスも制限されました。

不具合の名称、侵入の経路、ほかの荷主への波及の有無は、11月4日時点で公表されていません。CBcloud自身の本件の公表文も確認できていません。なお、CBcloudはStudio株式会社の不正アクセスに伴う漏えいのおそれを別に公表していますが、ピックゴー本体の侵害とは別の事案です。Studio側の経緯はStudio不正アクセスとAPIキー・Webhook URLの交換手順にまとめました。

配送マッチングの案件APIで起きやすい認可の抜けと、担当者以外に届け先を返さない実装

OWASP API1・API3に照らした、配送案件の状態ごとに返してよい項目の線引き

本件の不具合が何だったかは分かっていません。ここからは、配送マッチングのように誰でもアカウントを作れるサービスで、案件のAPIが一般に抜けやすい箇所を整理します。OWASP API Security Top 10のAPI1は、IDを書き換えるだけで他人のデータが取れる、オブジェクト単位の認可の欠落です。API3は、見てよい相手にも余計な項目まで返してしまう、プロパティ単位の認可の欠落です。

線引きの要は、届け先の住所と電話番号を「引き受け済み」の担当者にだけ、配達が終わるまでの間だけ返すことです。アカウントを作れば募集中の案件が見えるのは仕様ですが、そこに住所が入っていればAPI3の抜けになります。IDの書き換えで他人の案件が見えるのはAPI1です。2つの違いは認可バイパスとIDORをサーバ側で止める実装、10項目の全体はOWASP API Security Top 10 2023の全10項目と対策で解説しています。

担当者以外に届け先を返さず、別案件の連続参照を429で止めるPythonの例

次のコードは、上の表をそのまま実装したものです。Pythonの標準ライブラリsqlite3のメモリ上のDBに案件を4件入れ、アカウントごとに案件を取得します。担当でない案件は、存在するかどうかも明かさずに404を返します。

# 配送案件APIの認可：担当ドライバー以外に届け先を返さない（Python 3.9以上・標準ライブラリのみ）
import sqlite3
import time
from collections import defaultdict, deque

db = sqlite3.connect(":memory:")
db.row_factory = sqlite3.Row
db.executescript("""
CREATE TABLE jobs (id INTEGER PRIMARY KEY, driver_id TEXT, status TEXT,
  area TEXT, name_kana TEXT, address TEXT, phone TEXT, items TEXT);
INSERT INTO jobs VALUES
 (1001, 'drv-01', 'assigned',  '港区',   'ヤマダ タロウ', '東京都港区芝1-2-3',   '090-0000-0001', 'おにぎり'),
 (1002, 'drv-02', 'assigned',  '品川区', 'スズキ ハナコ', '東京都品川区大崎4-5', '090-0000-0002', '飲料'),
 (1003, 'drv-01', 'delivered', '目黒区', 'サトウ ジロウ', '東京都目黒区中町7-8', '090-0000-0003', '弁当'),
 (1004, NULL,     'open',      '渋谷区', 'タナカ ミキ',   '東京都渋谷区本町9-1', '090-0000-0004', '日用品');
""")

# 状態ごとに返してよい項目（OWASP API3：プロパティ単位の認可）
FIELDS = {
    "open":      ["id", "status", "area"],  # 募集中の案件は全ドライバーに見せるが住所は出さない
    "assigned":  ["id", "status", "name_kana", "address", "phone", "items"],
    "delivered": ["id", "status"],          # 配達が終わったら届け先は返さない
}
WINDOW, LIMIT = 60, 20      # 60秒に20件を超える別案件の参照は列挙とみなす
_seen = defaultdict(deque)  # アカウント -> (時刻, 案件ID) の履歴


def get_job(job_id, account):
    now = time.time()
    q = _seen[account]
    q.append((now, job_id))
    while q and now - q[0][0] > WINDOW:
        q.popleft()
    if len({j for _, j in q}) > LIMIT:
        return 429, {}
    job = db.execute("SELECT * FROM jobs WHERE id = ?", (job_id,)).fetchone()
    if job is None:
        return 404, {}
    # OWASP API1：オブジェクト単位の認可。募集中以外は担当者にしか存在も明かさない
    if job["status"] != "open" and job["driver_id"] != account:
        return 404, {}
    return 200, {k: job[k] for k in FIELDS[job["status"]]}


if __name__ == "__main__":
    print("case1", *get_job(1001, "drv-01"))
    print("case2", *get_job(1002, "drv-01"))
    print("case3", *get_job(1003, "drv-01"))
    print("case4", *get_job(1004, "drv-02"))
    codes = [get_job(i, "drv-99")[0] for i in range(1001, 1031)]
    print("case5", "1-20件目:", sorted(set(codes[:20])), "21件目以降:", sorted(set(codes[20:])))

ここで照合しているのは、ログイン中のアカウントと案件の担当者です。リクエストに書かれた荷主IDやドライバーIDは使っていません。クライアントが送ってくるIDで認可すると、そのIDを書き換えるだけで突破されます。

実行結果から読む案件APIの5つの場面と、列挙を止める閾値の決め方

Python 3.14.7（Windows）で2026年11月4日に実行した結果です。ピックゴーのAPIを再現したものではありません。

case1 200 {'id': 1001, 'status': 'assigned', 'name_kana': 'ヤマダ タロウ', 'address': '東京都港区芝1-2-3', 'phone': '090-0000-0001', 'items': 'おにぎり'}
case2 404 {}
case3 200 {'id': 1003, 'status': 'delivered'}
case4 200 {'id': 1004, 'status': 'open', 'area': '渋谷区'}
case5 1-20件目: [200, 404] 21件目以降: [429]

case1は担当者が自分の案件を見る正常な場面です。case2は同じドライバーが他人の案件IDを指定した場面で、404になります。case3は配達済みの案件で、返却される情報から届け先が消えている状態です。case4の募集中の案件は、担当でなくてもエリアまでは見えます。case5は、作ったばかりのアカウントが案件IDを1001から1030まで順に試す場面です。20件までは404と200が混ざり、21件目からは429で止まります。

閾値は、実際のドライバーが1分間に開く案件の数を本番ログで測ってから決めます。20件はこの例のための仮の値です。認可が正しければ列挙しても届け先は取れませんが、429とその記録があれば、認可に穴があったときの被害の件数を小さくし、気づくのも早くなります。レート制限やトークンの失効をAPI全体に入れる手順は、JPCERTの注意喚起に沿うAPI不正アクセス対策の実装手順で扱いました。

委託元が今週行う点検：配送委託先に渡す項目の棚卸しと連携を止める手順

ガイドライン3-4-4「必要のない個人データを提供しない」と2社の取得項目の差

個人情報保護法ガイドライン（通則編）の3-4-4は、委託先の監督について「委託する業務内容に対して必要のない個人データを提供しないようにすることは当然」と書いています。配達に要るのは、届け先の名前・住所・連絡先と荷物の大きさくらいです。

出前館の公表では、注文メモと料金明細も取得されています。注文メモは利用者が自由に書く欄で、何が入っているかを委託元は制御できません。料金明細も、配達そのものには使いません。7NOWでは注文商品名が取得されました。自社の連携で、次のように渡す項目を減らせないかを確かめます。

{
  "job_id": "A-20261104-0001",
  "deliver_by": "2026-11-04T12:30:00+09:00",
  "dropoff": {"name_kana": "ヤマダ タロウ", "address": "東京都港区芝1-2-3", "phone_relay": "050-0000-0000"},
  "package": {"size": "S", "count": 1, "temperature": "normal"},
  "note_for_driver": "置き配可"
}

この例では、商品名と料金を渡さず、荷物の大きさと温度帯だけを伝えています。電話番号は本人の番号でなく、通話を中継する番号を渡す形です。自由記述のメモの代わりに渡すのは、置き配の可否のように選択肢で表せる項目です。中継番号の仕組みが無い場合でも、商品名・料金・メモの3つを外すだけで、今回のような流出で漏れる情報は減ります。渡す項目の棚卸しの進め方はNTTデータ委託先の情報漏洩と委託先に渡す項目の棚卸しでも整理しています。

出前館が当日中に止めて7時間後に再開した手順と、連携停止スイッチの用意

出前館は11月2日に連携を受け、14時過ぎにCBcloudとの連携を止めました。再開は21時ごろです。再開の前に、CBcloudが悪用された不具合を直したことを確かめ、自社側の通信状況も確かめています。止めるか迷う時間を作らなかった点が、委託元として倣える部分です。

自社で同じことをするには、委託先ごとに連携を止めるスイッチを、コードの修正やデプロイなしで切り替えられる設定として持っておきます。止めている間の配達をどう回すか（別の委託先へ振る、店舗での受け取りに切り替える）も、あらかじめ決めておきます。委託先の障害で荷主の業務が止まった例はニッスイと日水物流のシステム障害でも見られました。

委託元と委託先の双方に報告義務、連名でもよいとするガイドライン3-5-3-2

ガイドライン3-5-3-2は、個人データの取扱いを委託している場合、報告対象の事態では原則として委託元と委託先の双方が報告する義務を負い、連名で報告できるとしています。本人への通知も、同じく双方が義務を負う扱いです。セブン‐イレブンと出前館はいずれも、個人情報保護委員会へ報告済みとしています。

不正アクセスによる漏えいは、件数にかかわらず報告の対象です。確報の期限は、事態を知った日から60日以内です。委託先からの連絡が遅れても、自社が知った日から数えます。報告と本人通知の流れは個人情報保護委員会への報告義務の実務、委託先を選ぶときと契約での取り決めは委託先管理と個人情報保護法25条の監督義務にまとめました。

事業者の判断：配送委託先を使い続ける条件と第三者の診断を入れる範囲

ピックゴーを使い続けてよい条件と、委託先を分けるか決める場面

出前館はCBcloudに対し、原因の全容の究明、ほかの脆弱性を含む全体の点検、恒久的な再発防止策の実施と報告を求めています。使い続けるかは、この3点の報告を受け取れるかで決めます。緊急の修正だけでは、同じ種類の不具合が別の画面やAPIに残っていないかが分かりません。

委託先を分けるのは、配送を1社のマッチング基盤だけに頼り、そこが止まると注文の受付まで止まる場合です。出前館のように7時間止めても受付を続けられる構成なら、委託先を増やすより、渡す項目の削減と停止スイッチの用意を先にします。注文数が少なく、店舗での受け取りに切り替えられるなら、再発防止策の報告を待つ対応で足ります。

自社が作る配送・マッチングのAPIを第三者に診断させる対象と確認範囲

自社で配送やマッチングの仕組みを持つ事業者は、本件を他社の事故で終わらせない方がよいです。誰でもアカウントを作れる画面があり、そのアカウントで案件のAPIを呼べるなら、案件IDの書き換えと状態ごとの返却項目を、作ったばかりのアカウントで試してもらいます。同じ型の委託先経由の事案は、アララの不正アクセスと契約企業の再設定でも起きています。

自社のWebシステムや外部の配送サービスとの連携に、認可の抜けが残っていないかを第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

ピックゴーの不正アクセスについて、7NOWと出前館の利用者、配送を委託している事業者から出やすい質問をまとめました。

7NOWで注文したことがありますが、自分が対象か確かめる方法はありますか？

セブン‐イレブン・ジャパンは、対象者に登録電話番号あてのショートメッセージで順次連絡するとしています。自分から確かめたい場合は、7NOWお問い合わせ窓口（0120-711-099、受付9時〜21時）か、CBcloudのお客様相談窓口へ問い合わせます。SMSの中のURLを開く前に、セブン‐イレブンの公式サイトに載っている公表文と内容が合っているかを見比べてください。

クレジットカード情報やパスワードは漏れましたか？

セブン‐イレブン・ジャパンと出前館はどちらも、クレジットカード情報とID・パスワードは漏えいしていないとしています。取得されたのは注文者（届け先）の氏名・住所・電話番号・郵便番号の一部と、注文店舗名や商品名などです。11月3日の公表時点で、本件を原因とする不正利用の被害は確認されていません。カード会社や配送会社を装う連絡には応じないようにします。

出前館の利用者も対象になっていますか？

なっています。出前館は11月3日に、同社が配達の一部を委託するCBcloudのピックゴーへの不正アクセスで、注文者の氏名799件、住所794件（番地まで）、電話番号・郵便番号33件が取得されたと公表しました。注文メモや料金明細も一部取得されています。対象者には登録メールアドレスへ順次連絡するとしています。

7NOWと出前館は今も使えますか？

使えます。セブン‐イレブン・ジャパンは7NOWが通常どおり稼働しているとしています。出前館は11月2日14時過ぎにCBcloudとの連携を止めましたが、不具合の修正を確かめたうえで同日21時ごろに再開しました。両社とも、自社の認証情報や連携設定が流出・改ざんされた事実はCBcloudの調査で確認されていないとしています。

ピックゴーの不正アクセスの原因は何ですか？

11月4日時点で、具体的な原因は公表されていません。両社の公表文には、CBcloudが不正アクセス元からの通信を遮断し、不正に作成・利用されたアカウントを止め、悪用された不具合を直したと書かれています。不具合の名称や侵入の経路は示されていません。出前館はCBcloudに原因の全容の究明と報告を求めています。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：案件APIに入れる認可とレート制限の全体
• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：IDの書き換えで他人の案件が見える抜けの止め方
• 委託先管理とは？個人情報保護法25条の監督義務とチェックリスト・契約条項の実務：配送委託先との契約で決めておく項目
• NTTデータ委託先の情報漏洩：デジタル特典付き社債の対象確認と委託先に渡す項目の棚卸し：委託先に渡す項目を減らす別の事案
• アララの不正アクセス：メール約7,700万件の持ち出しと契約企業が行うAPIキー再設定・代替送信・連名報告：委託先のSaaSが破られた同時期の事案