2026.10.16 セキュリティ

トイポ不正アクセス：0120-546-030は本物か、対象確認と漏えい項目

店舗向けの会員アプリ「トイポアプリ」を提供する株式会社トイポは2026年10月13日、第三者の不正アクセスで一部の利用者の情報が外部に漏えいしたと公表しました。同じ日、アプリを24店舗で使うJR九州フードサービスも、自社の会員約61,500名のうち約26,900名が対象だと発表しています。漏れたのは電話番号とユーザーIDのほか、登録していた人の氏名・住所・生年月日などで、パスワードやカード番号は含まれていません。前半では、自分は対象か、届いた通知と0120-546-030は本物か、パスワードやアカウントをどうするかに公式発表とFAQで答えます。後半は、ログインした利用者が他人の情報を取れたというAPIの不備を、2つのアカウントで確かめるコードで示します。

まとめ：トイポアプリ不正アクセスで漏れた情報と、利用者が今日確かめること

トイポ社は10月4日に不正アクセスを確認しました。原因は、ログインした利用者が本来見られないはずの他の利用者の情報を取得できる、アクセス制御の脆弱性です。アクセス記録から、第三者がこの脆弱性を使ってユーザー情報を取得した記録が見つかっています。脆弱性は修正済みで、悪用されたアカウントも停止されました。

利用者がやることは多くありません。まず、トイポやうまや・たんやを名乗るメール・SMS・電話で、パスワードや認証コード、カード番号を聞かれても答えないことです。次に、本件を確かめたいときは、届いたメッセージのリンクではなく、公式発表に載っている専用窓口0120-546-030（平日9〜18時）へ自分でかけます。パスワードの変更は、公式FAQでは本件だけを理由に必須とはしていません。

項目	公表されている内容（2026年10月16日時点）
提供会社	株式会社トイポ（トイポアプリの提供会社）
不正アクセスの確認日	2026年10月4日
公表日（トイポ社・JR九州フードサービス）	2026年10月13日
原因	他の利用者の情報を取得できたアクセス制御の脆弱性
JR九州フードサービス分	会員約61,500名のうち約26,900名
漏れていない情報	パスワード・決済情報・ポイント・来店履歴など
専用窓口	0120-546-030（平日9〜18時）
未公表	全体の件数・他の導入店舗・脆弱性があった期間

利用者が最初に確かめること：対象かどうか、届いた通知と専用窓口の真偽

対象者には順次連絡、退会済みなら漏えいは確認されていないという公式回答

トイポ社の「ご質問と回答」は、自分が対象かどうかについて、対象者には当社から順次連絡していると答えています。個別に確かめたい場合は、お問い合わせ窓口で本人確認をしたうえで、確認できる範囲を案内するとのことです。照会用のWebページは設けられていません。

退会した人については、漏えいが起きた時点で退会済みだった利用者の情報の漏えいは確認されていない、という回答です。JR九州フードサービスは、対象となる可能性のある利用者へ、トイポ社からアプリ通知で10月16日までにお詫びを順次送ると発表しました。アプリを開いて通知が届いているかを見るのが、いちばん早い確かめ方です。

トイポからの通知と0120-546-030が本物かを見分けるための手がかり

0120-546-030は、トイポ社の公式発表とJR九州フードサービスの公式発表の両方に載っている、本件の専用窓口です。受付は平日9時から18時で、10月13日13時に開設されました。番号自体は本物ですが、この番号を名乗って電話をかけてくる相手が本物とは限りません。不安なときは、こちらから0120-546-030へかけ直します。

FAQのQ.9は、トイポからの通知でパスワード、認証コード、クレジットカード番号などの入力を求めることはないと明記しています。もしメールやSMSに入力画面へのリンクが付いていたら、それだけで偽物を疑ってよい材料になります。偽のメッセージが本物らしく見える仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しました。

パスワード変更は必須でないという公式見解と、変えたほうがよい2つの条件

公式発表によると、パスワードとパスワードハッシュ、認証トークン、セッション情報は漏えいした情報に含まれていません。FAQのQ.5は、本件のみを理由として必ずパスワードの変更が必要とは、現時点では考えていないと回答しています。Q.6も、漏れた情報だけで直ちにログインできるものではないという認識です。

そのうえでFAQは、変更を考えたほうがよい場面を2つ挙げています。他のサービスで同じパスワードを使っている場合と、不審なログインなどに気付いた場合です。前者に当てはまる人は、トイポではなく使い回している他のサービス側のパスワードを先に変えると、被害の広がりを抑えられます。

漏えいした情報の内訳：電話番号とユーザーIDは全員、氏名や住所は登録者だけ

漏えいした8項目と含まれない6項目、JR九州フードサービス分の約26,900名

トイポ社の発表は、漏えいした情報と含まれていない情報を分けて書いています。登録している項目は人によって違うため、実際に漏れた範囲も人によって変わります。

区分	項目
漏えいした（全員が登録）	電話番号、ユーザーID等の識別情報
漏えいした（登録者のみ）	氏名、氏名カナ、メールアドレス
漏えいした（登録者のみ）	生年月日、性別、住所
含まれない	パスワード・パスワードハッシュ
含まれない	認証トークン・セッション情報
含まれない	クレジットカード番号その他の決済情報
含まれない	ポイント情報、来店履歴、購買・サービス利用履歴

JR九州フードサービスの発表資料（PDF）は、ユーザーIDと電話番号以外は任意登録だと説明しています。同社は来店促進のためのスタンプカードやクーポン配信に、うまや・たんやなど24店舗でトイポアプリを使っていました。対象は同社店舗で会員登録した約61,500名のうち約26,900名で、同社店舗では現在、新規会員の募集を止めています。本人確認書類の画像やマイナンバーは、トイポ社のサービスではそもそも預かっていないとFAQのQ.4にあります。

電話番号と氏名が揃うと届きやすい偽SMSと、店舗でなく専用窓口に聞く理由

全員分が漏れた電話番号は、SMSと電話の宛先そのものです。氏名まで登録していた人には、「◯◯様、トイポの会員情報について」と名前を添えた連絡が届くかもしれません。名前が合っているだけでは本物と判断できず、記載されたURLを開かないことがFAQの案内です。不審な連絡が来たら、送信元の番号・受信日時・内容をメモして専用窓口へ伝えると、関連性を確かめてもらえます。

FAQのQ.10は、本件はトイポ社のシステムで起きた事案なので、店舗ではなく専用窓口へ問い合わせるよう求めています。うまやの店頭で聞いても、店舗のスタッフは対象者を調べる手段を持っていません。漏えい後に届く連絡の真偽を確かめる手順は、タイムズカーの情報漏洩で番号の真偽を確かめた記事でも同じ考え方で整理しています。

アカウント削除の4ステップと、削除前に知っておく約1週間の反映期間

もう使わないなら、アプリからアカウントを削除できます。FAQのQ.11が示す手順は次のとおりです。

トイポアプリを起動する
画面下部の「マイページ」をタップする
マイページ最下部の「アカウントの削除について」をタップする
「アカウントを削除」を選び、画面の案内に従って完了させる

削除すると登録情報を含むすべてのデータが消え、復元はできません。完全に反映されるまで約1週間かかり、その間に再ログインすると削除の手続きが取り消されます。契約中のサブスクや受け取り前の注文があると削除できない点も、FAQに書かれています。削除しても、すでに漏れた情報が取り戻せるわけではない点は分けて考えてください。

公表で追う経過：10月4日の確認から13日の公表まで、アクセス制御の不備の中身

10月4日に確認、7日に導入企業へ連絡、13日に公表という9日間の流れ

両社の発表を並べると、経過は次のようになります。

10月4日（日）：トイポ社が自社システムへの第三者による不正アクセスを確認
10月7日（水）：JR九州フードサービスがトイポ社から漏えいの可能性について連絡を受ける
10月13日（火）：両社が公表。13時に専用窓口を開設
10月16日（金）まで：対象となる可能性のある利用者へアプリ通知でお詫びを順次送付

いつから脆弱性があったのか、第三者がいつから情報を取り始めたのかは、10月16日時点で公表されていません。トイポ全体での漏えい件数も出ておらず、JR九州フードサービス以外の導入企業からの公表は、本記事では一次情報で確認できていません。トイポ社は個人情報保護委員会への報告を済ませたとしています。同委員会は、不正の目的をもって行われたおそれがある漏えい等を報告対象に挙げています。報告の段取りは個人情報保護委員会への報告義務の実務にまとめました。

ログイン済みの利用者が他人の情報を取れた不備がAPI1:2023に当たる理由

トイポ社の説明は「認証されたユーザーが本来アクセス権限を有しない他のユーザーの情報を取得できるアクセス制御上の脆弱性」です。JR九州フードサービスの資料は、これを「一部のAPIにおいて」と書いています。ログインの仕組みは働いていて、ログインした後に「その人がそのデータを見てよいか」の判定が抜けていた、という形です。

この形は、OWASP API Security Top 10の1番目「API1:2023 Broken Object Level Authorization」に当たります。OWASPは、オブジェクトのIDを受け取るすべてのAPIで、ログイン中の利用者がその記録に対して操作してよいかを確かめるよう求めています。弱点の分類ではCWE-639（利用者が制御できるキーによる認可回避）です。平たく言えば、利用者IDを書き換えるだけで他人の情報が返る状態です。トイポ社は「不正アクセスに利用されたアカウントの停止」も発表しており、ログインできるアカウントを足場にこの判定の抜けが突かれた形と読めます。全10項目の位置付けはOWASP API Security Top 10 2023の全10項目で解説しています。

開発側の教訓：他人のIDで情報が返らないことを、複数アカウントで確かめる手順

リクエストのIDを信じず、トークンから本人と所属店舗を決めて判定する実装

トイポのように1つのアプリ基盤を多数の店舗が使う形では、権限の境界が2つあります。会員は自分の情報だけを見てよく、店舗スタッフは自店の会員だけを見てよい、という境界です。どちらも、URLや本文で送られてきたIDではなく、ログイン時に発行したトークンから本人と所属店舗を割り出して判定します。

OWASPのAuthorization Cheat Sheetは、既定を拒否にすることと、静的な資源への要求も含めてすべての要求で権限を確かめることを勧めています。判定に落ちたときは、403ではなく「存在しない」と同じ404を返すと、どのIDが実在するかを外から探られにくくなります。役割ごとの権限を表で持つ設計はRBACの仕組みと導入判断、ID書き換えによる越境の型は認可バイパスの仕組みとサーバ側で止める実装で詳しく扱いました。

標準ライブラリで動く検証用APIと、5ケースの差分テストを実行した結果

次のスクリプトは、架空の会員3名とA店スタッフ1名を持つ検証用APIを同じプロセスで立て、修正前のv1と修正後のv2に同じ5つの要求を送ります。v1はログインさえしていれば指定されたIDの情報を返す実装で、今回の発表が示す不備の形を再現したものです。

# 他人のユーザーIDを指定して個人情報が返るかを、複数のアカウントで確かめる（Python 3.9以上・標準ライブラリのみ）
# 架空データの検証用APIを同じプロセスで立て、修正前(v1)と修正後(v2)を同じテストにかける
import json, threading, urllib.request, urllib.error
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

USERS = {"1001": {"shop": "A", "name": "利用者X", "tel": "090-0000-1001"},
         "1002": {"shop": "A", "name": "利用者Y", "tel": "090-0000-1002"},
         "2001": {"shop": "B", "name": "利用者Z", "tel": "090-0000-2001"}}
# トークンから (本人のID, 役割, 所属店舗) を引く。店舗スタッフは自店の会員だけを見てよい
TOKENS = {"tok-x": ("1001", "member", "A"), "tok-z": ("2001", "member", "B"),
          "tok-staff-a": ("s-01", "staff", "A")}

def allowed(me, target):
    uid, role, shop = me
    if role == "staff":
        return USERS[target]["shop"] == shop          # スタッフは自店の会員だけ
    return target == uid                              # 会員は本人だけ

class Api(BaseHTTPRequestHandler):
    def do_GET(self):
        me = TOKENS.get(self.headers.get("Authorization", "").removeprefix("Bearer "))
        if me is None:
            return self.reply(401, {"error": "unauthorized"})
        ver, _, target = self.path.strip("/").partition("/users/")
        user = USERS.get(target)
        if ver == "v2" and user and not allowed(me, target):
            user = None                               # 修正後: 権限がなければ「存在しない」と同じ応答にする
        self.reply(200, user) if user else self.reply(404, {"error": "not found"})  # v1はログインだけで返す

    def reply(self, code, body):
        data = json.dumps(body, ensure_ascii=False).encode()
        self.send_response(code)
        self.send_header("Content-Type", "application/json; charset=utf-8")
        self.end_headers()
        self.wfile.write(data)

    def log_message(self, *args):
        pass

def status(path, token):
    req = urllib.request.Request("http://127.0.0.1:8765" + path, headers={"Authorization": "Bearer " + token})
    try:
        return urllib.request.urlopen(req).status
    except urllib.error.HTTPError as e:
        return e.code

srv = ThreadingHTTPServer(("127.0.0.1", 8765), Api)
threading.Thread(target=srv.serve_forever, daemon=True).start()
cases = [("会員Xが本人", "tok-x", "1001", 200), ("会員Xが同じ店の他人", "tok-x", "1002", 404),
         ("会員Zが別の店の他人", "tok-z", "1001", 404), ("A店スタッフがA店会員", "tok-staff-a", "1002", 200),
         ("A店スタッフがB店会員", "tok-staff-a", "2001", 404)]
for ver in ("v1", "v2"):
    for label, tok, uid, want in cases:
        got = status(f"/{ver}/users/{uid}", tok)
        print(f"{ver} {label} 期待{want} 実際{got} {'OK' if got == want else 'NG'}")
srv.shutdown()

サーバーはPython標準のhttp.serverで、要求はurllib.requestで送っています。外部のパッケージは使っていません。Python 3.14.7（Windows）で実行した結果は次のとおりです。

$ python bola_check.py
v1 会員Xが本人 期待200 実際200 OK
v1 会員Xが同じ店の他人 期待404 実際200 NG
v1 会員Zが別の店の他人 期待404 実際200 NG
v1 A店スタッフがA店会員 期待200 実際200 OK
v1 A店スタッフがB店会員 期待404 実際200 NG
v2 会員Xが本人 期待200 実際200 OK
v2 会員Xが同じ店の他人 期待404 実際404 OK
v2 会員Zが別の店の他人 期待404 実際404 OK
v2 A店スタッフがA店会員 期待200 実際200 OK
v2 A店スタッフがB店会員 期待404 実際404 OK

v1では5ケース中3ケースで他人の情報が返りました。本人の要求とスタッフの自店会員の要求は、どちらの版でも通ります。この差が示すのは、正常系のテストだけでは認可の不備に気付けないということです。OWASPも、認可の仕組みを確かめるテストを書き、それが失敗する変更は出さないよう求めています。実際の開発ではcasesの表をCIに組み込み、APIを1本足すたびに「他人」と「他店」の行を足します。

実在のサービスに他人のIDを送って確かめる行為は、許可がなければ不正アクセスに当たり得ます。必ず自社の検証環境で行ってください。退会処理のような書き込み系APIまで含めた点検の手順は、同じ型の事案を扱ったセイコーマートの不正アクセスとアプリAPIの認可点検で解説しています。

導入店舗の判断：会員アプリをSaaSで使い続ける条件と、提供会社に聞く4項目

SaaSの会員アプリを使い続けてよい条件と、見直しに入るべき導入店舗

今回の発表で、JR九州フードサービスは提供会社から連絡を受けて初めて事態を知っています。会員アプリを外部のサービスに任せている店舗は、自社で設計していないAPIの不備であっても、自社の会員の情報を失う立場です。会員データの取扱いを提供会社に委ねている関係なら、個人情報保護法第25条の委託先の監督の対象でもあります。

使い続けてよいのは、次の4項目に提供会社が書面で答えられる場合です。答えが返ってこない、または「他店の会員も同じAPIから読める構成」だと分かった場合は、見直しに入るべきと判断します。

会員本人と店舗スタッフの権限の境界を、APIごとにどう判定しているか
他人・他店のIDを使った認可のテストを、リリースのたびに回しているか
1つのアカウントが短時間に多数の会員情報を読んだときに検知できるか
漏えいの疑いが出たとき、何日以内に導入店舗へ連絡するか

小規模な店舗が単独でAPIの中身を検証するのは現実的ではありません。そのため、質問への回答の具体さで提供会社を比べるのが、店舗側にできる現実的な線です。会員アプリを自社で作るか既製品を使うかの比較は店舗アプリの機能・作成方法・費用相場で整理しました。

自社で作った会員アプリや連携APIの認可を、第三者の診断で確かめる場面

自社で会員アプリやAPIを持っている場合、上のスクリプトのような差分テストは社内でも始められます。ただ、APIが数十本に増え、会員・スタッフ・本部と役割が分かれてくると、どのAPIでどの境界を確かめたかを網羅するのは難しくなります。ログイン後の認可の抜けは、自動の脆弱性スキャナーによる検査で見落とされやすい種類の欠陥でもあるのです。

リリース前やAPIを大きく変えた後に、複数アカウントを使った認可の点検を第三者に頼むのが確実です。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準にまとめています。会員情報を預かるアプリやAPIの認可を外部の目で確かめたい場合は、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

トイポアプリの不正アクセスについて、利用者から出やすい質問をまとめました。

トイポアプリの不正アクセスで自分の情報は漏れましたか？

トイポ社は、対象となる利用者に順次連絡しているとしています。JR九州フードサービスの店舗で登録した人には、10月16日までにアプリ通知でお詫びが届く予定です。個別に確かめたい場合は、専用窓口0120-546-030（平日9〜18時）で本人確認のうえ案内を受けられます。漏えいの時点で退会済みだった人の情報の漏えいは確認されていないという回答です。

0120-546-030はトイポの本物の窓口ですか？

トイポ社とJR九州フードサービスの公式発表の両方に載っている、本件の専用窓口です。10月13日13時に開設され、受付は平日9時から18時です。ただし、この番号を名乗ってかかってくる電話が本物とは限りません。確かめたいときは、届いたメッセージの番号ではなく、公式発表に載った番号へ自分からかけてください。

トイポのパスワードは変更したほうがよいですか？

パスワード、パスワードハッシュ、認証トークン、セッション情報は漏えいしていません。公式FAQは、本件のみを理由として必ず変更が必要とは考えていないと回答しています。ただし、他のサービスで同じパスワードを使っている場合や、不審なログインに気付いた場合は変更を検討するよう案内しています。使い回している他のサービスを先に変えると安全です。

うまやや、たんやの店舗に問い合わせてもよいですか？

トイポ社のFAQは、本件は同社のシステムで起きた事案なので、店舗ではなく専用窓口へ問い合わせるよう求めています。JR九州フードサービスも、問い合わせはトイポ社の専用窓口で対応すると発表しました。店頭では対象者を調べられないため、0120-546-030へかけるのが確実です。

トイポアプリのアカウントを削除するにはどうすればよいですか？

アプリの「マイページ」最下部にある「アカウントの削除について」から、「アカウントを削除」を選んで手続きします。データはすべて消えて復元できず、反映まで約1週間かかります。その間に再ログインすると削除が取り消される点に注意してください。契約中のサブスクや受け取り前の注文があると削除できません。

不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：企業として点検する範囲の全体像
タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか：アプリの認可不備で起きた別の漏えい事案
APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説：APIの主要リスクと実装対策の全体像
セイコーマートの不正アクセスと57万人の会員情報｜アプリAPIの認可を点検する手順：同じ型の事案と大量閲覧の検知
タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え：漏えい後に届く連絡の真偽を確かめる手順

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

トイポ不正アクセス：0120-546-030は本物か、対象確認と漏えい項目

まとめ：トイポアプリ不正アクセスで漏れた情報と、利用者が今日確かめること