焼肉きんぐを含む直近の不正アクセス13件、
発表文を読み比べた——手口まで書いたのは3社だけだった

2026年10月5日、焼肉きんぐを運営する物語コーポレーションが、公式アプリの会員管理システムへの不正アクセスで、会員情報約1,079万件が漏えいしたと発表しました。原因と侵入経路は、10月6日朝の時点でも公表されていません。

結論：9月11日から10月5日に公表された不正アクセス13件の発表文を読み比べると、手口（どんな弱点を突かれたか）まで書いた会社は3社だけで、被害を受けたシステムは13件中12件が、お客様向けのサービス側（アプリ、Webサイト、メール配信、予約、払戻しなど。私たちの分類）でした。流出の中心は、氏名・電話番号・メールアドレスなどの連絡先です。カード情報とパスワードは、「保有していない」「別のシステム」「流出していない」などと書いた会社が多くありました。

この記事は、きんぐの原因を推測する記事ではありません。各社の発表文に書かれたことだけを並べて、会員アプリ、予約、LINE、問い合わせフォームを持つ会社が、自社で点検できる形にしました。発表文は、2026年10月6日朝の時点のものです。続報で内容が変わる事案があります。

焼肉きんぐで、何が書かれて、何が書かれていないか

物語コーポレーションの発表文（10月5日）に書かれていることは、次のとおりです。

焼肉きんぐの発表文2026年10月5日公表

漏えいした情報が不特定多数に公開された事実や、不正に使われた事実は、発表の時点では確認されていないと書かれています。ほかのブランドの公式アプリでも、同様の措置を取ったうえで、漏えいの事実はないとしています。10月6日朝の時点で、原因や侵入経路について続報は出ていません。

直近の不正アクセス13件を、発表文で並べた

きんぐを含め、9月11日から10月5日に公表された13件を、各社の発表文で確認しました。民間のまとめ記事には、6〜8月に公表された事案が混ざっていたので、発表文の日付で数え直しています。

13件の一覧侵入口と手口は、発表文に書かれた範囲

件数は、版で変わります。セイコーマートは、第一報で「約57万アカウント」、第三報で572,022人、第四報で574,647人と更新されています。表には初報と続報の情報を併記しています。タイムズカーは初報が9月25日で、約660万件は9月28日の第2報です。ニッポンレンタカーは9月26日公表分が41名、10月1日公表の別の攻撃が55名です。ムラウチは初報が7月24日、表の件数は9月15日の第二報です。ヤマト運輸の初報（9月29日）の原文は読めず、10月2日の第2報と報道で補いました。

13件に共通して見えたこと

1つめ：被害を受けたのは、お客様向けサービスのシステムが12件

13件中12件で、被害を受けたのは、アプリ、Webサイト、メール配信、予約、払戻しなど、お客様向けのサービスに付いたシステムでした。例外は、デジタル庁の内部のVPN機器だけです。実際の侵入経路が公表されていない事案もあり、ここで言えるのは「被害を受けたシステムの種類」までです。セイコーマートは、アプリのサーバーを経由して、会員情報を持つサーバーに入られたと書いています。この分類は私たちの判断です。イープラスの払戻し管理やメトロのメール配信は、窓口そのものではなく、お客様向けサービスの裏側のシステムで、境界にあたります。

2つめ：手口まで書いたのは3社だけ

どんな弱点（脆弱性）が、どのシステムにあったかまで書いたのは、Gyazo（画像アップロードサーバーの脆弱性）、ムラウチ（Webシステムの一部の脆弱性）、デジタル庁（VPN機器の脆弱性、修正前に悪用）の3社です。セイコーマートは「情報の開示を差し控える」と書き、きんぐは調査中です。ほかの8件は、不正アクセスがあったことと、入られたシステムの名前までで、弱点がどこにあったかは書いていません。オズモールは、第2報で「脆弱性への対策を実施した」と書いていますが、どこの脆弱性かは書いていないので、この3社には数えていません。発表文を読んだだけでは、他社が「同じ弱点が自社にないか」を確かめる材料が、ほとんど手に入りません。だから、自社の点検は、個別の手口ではなく、入口の種類と持っている情報で進めるほうが現実的です。

3つめ：流出の中心は連絡先。カード情報は「持たない」と書く会社が多い

きんぐ、セイコーマート、イープラスは、クレジットカード情報を会社で保有していないと書いています。タイムズカーも、第2報では「漏えいしていない」と書き、10月1日付のFAQで「保有していない」と書いています。ムラウチは決済情報を別のシステムで管理、オズモールは外部の決済システムを使用、と書いています。パスワードは、きんぐとムラウチが流出していないと書き、ヤマトは漏えいの可能性がある主な情報に含まれないと書いています。タイムズカーは、パスワード情報が漏えい項目に含まれるものの、復元できない形式で保管していると説明しています。一方で、持っているものは出ています。タイムズカーは本人確認書類（運転免許証の画像など）が漏えいしたアカウントが約160万件、イープラスは銀行口座の情報が751件、ニッポンレンタカーは免許証の情報とカード番号の下4桁、日本郵便は送り状の情報が対象でした。保有していないため対象外だった情報と、保有していても流出しなかった情報があり、持っていたものは出た事案もある、という並びです。

4つめ：気づいたきっかけは、小さな異常から委託先の報告まで

発表文に書かれた、気づいたきっかけは、さまざまでした。セイコーマートは、不正な退会処理が1件あったこと。東京メトロは、メール配信サービスの不具合のあと、通常と違う利用記録を見つけたこと。デジタル庁は、保守運用担当者のアカウントで大量のファイルにアクセスがあったこと。オズモールは、海外からの大量のアクセスを自社のシステム部門が検知したこと。Gyazoは、不正な挙動の検知です。ムラウチは、社内システムの障害の復旧作業中に痕跡を見つけました。レゴランドは、委託先からの報告でした。検知の方法を書いていない事案もあります。

5つめ：委託先や他社サービスが絡む例がある

レゴランドは、委託先が運営する予約プラットフォームが被害を受け、その報告で知りました。東京メトロは、利用しているメール配信サービスが対象で、緊急対策に「委託先を含めた原因の調査」を挙げています。きんぐは、「開発会社・関係会社の協力のもと」対策を強化する、と書いていますが、原因の所在は書いていません。自社のシステムだけでなく、会員アプリや予約を作った会社、メール配信や予約の外部サービスが、同じ入口に並びます。

6つめ：お客様への案内は「注意」が中心で、パスワード変更を求めた会社は少ない

パスワードの変更を求めたのは、Gyazoと、ニッポンレンタカーの初報です。ほかは、不審なメール・SMS・電話への注意と、「当社からパスワードやカード情報をお伺いすることはありません」という一文が中心でした。連絡先が出た事案では、そのあと、会社を装った連絡が来ることが心配されているためです。

対策は、していたのか。発表文から分かること

13件を並べると、「各社は何も対策していなかったのか」という疑問が出ます。結論から言うと、発表文を読むかぎり、対策が足りなかったとも、十分だったとも言えません。事故の前から、どんな対策をしていたのかを説明した会社が、ほとんどないからです。事故の前の運用と、対処を進めていたのに起きた経過まで説明したのは、13件中デジタル庁（Q&A）だけでした。

事故の前の対策と、事故のあとの再発防止発表文に書かれた範囲

この表から読み取れることが、3つあります。1つめは、「被害を小さくする設計」は、書いた会社が多いことです。決済情報を持たない、または別のシステムにする、が6件（きんぐ、セイコーマート、ムラウチ、タイムズカー、イープラス、オズモール）、パスワードをハッシュ値や復元できない形式で保管している、が2件（Gyazo、タイムズカー）ありました。入られたあとでも、出る情報が減る仕組みです。

2つめは、「入口で止める対策」（監視、脆弱性の診断、修正の適用）を、事故の前の話として書いたのは、デジタル庁だけということです。ほかの12件は、事故のあとに「監視体制を強化する」「診断を定期的に行う」と書いていても、事故の前にどこまでできていたかは、発表文からは分かりません。「強化」と書かれていても、「それまでなかった」とは言えません。

3つめは、再発防止策に並ぶ言葉が、似ていることです。アクセス権限と認証の見直し、監視と検知の強化、脆弱性診断、全体の点検、外部専門機関との連携が並びます。具体策を公表した複数の会社で、これらの項目が挙げられています。実施の順序や、全社に共通する対策までは分かりません。

デジタル庁は、「対策していたのに」を具体的に書いた

デジタル庁のQ&Aは、対策をしていたのに起きた、という経過を、13件の中でいちばん具体的に書いています。悪用された脆弱性は、攻撃が確認される前に公表されていたもので、公表時の評価は「中（CVSSでMediumレベル）」でした。デジタル庁は、公表時の深刻度に応じた一般的な対応よりも早く対処を進めた、と書いています。それでも、修正プログラムを適用する前に、その脆弱性が悪用されました。そのうえで、「脆弱性管理の強化」として、より実質的なリスクに基づいた迅速で先行的な対応に取り組むとしています。なお、「評価が中だったので防げなかった」とは書かれていません。書かれているのは、公表された脆弱性が、修正の適用前に悪用された、という順番です。

ここで分かるのは、「対策をしていた」ことと、「その間に狙われた」ことは、両立する、という点です。デジタル庁の事案では、修正の適用の前に脆弱性が悪用されました。私たちは、この経過から、修正を適用するまでの手順と、その間の守り方を、点検する必要があると考えます。IPAの「情報セキュリティ10大脅威 2026」（組織向け）でも、「システムの脆弱性を悪用した攻撃」は4位（6年連続）、「サプライチェーンや委託先を狙った攻撃」は2位（8年連続）に入っています。

「対策していたのに」を、どう読むか

私たちは、次のように読んでいます。対策には、入口を閉じる対策と、入られても被害を小さくする対策があります。入口を閉じる対策は、時間差や委託先など、自社だけでは埋めきれない隙間が残ります。被害を小さくする対策は、設計の段階で決められます。今回の発表文で、流出しなかった情報が、この後者の対策と重なっている事案は、多くありました。ただし、持っていた情報は出ています。タイムズカーの運転免許証の画像や、イープラスの口座情報がそうです。

気づいてから公表まで、何日かかったか

気づいた日（確認・検知・判明）が発表文に書かれている10件で、最初の公表までの日数を数えました。

10件のうち5件は、気づいてから2日以内に公表しています。きんぐは3日でした。いちばん長いのはデジタル庁の78日で、これは、6月25日に大量のファイルアクセスを検知してから、VPN機器の脆弱性が悪用されたと判明するのが7月9日、公表が9月11日、という経過です。「確認」「検知」「判明」の言葉は、各社の書き方によるので、厳密な比較ではありません。それでも、公表までの期間は、当日から2か月半まで、大きく開いていました。

会員アプリ・予約・LINEを持つ会社の、7つの点検

13件の共通点から、自社で確かめておきたい点を7つにまとめました。どれも、発表文に書かれた事実の裏返しです。

【お客様と接するシステムの点検表】

1. お客様向けシステムの一覧：会員アプリ、予約、問い合わせフォーム、メール配信、LINE連携など、お客様が使うシステムを全部書き出したか。それぞれ、自社運営か、委託先か、外部サービスか
2. 修正の適用：利用している機器やソフト（VPN機器、Webシステム、アップロードなどの部品）の脆弱性情報を、誰がいつ確認し、公表から何日以内に直すか。直すまでの間の守り方（接続の制限など）は決めてあるか
3. 持っている項目：各システムが持つ個人情報の項目を書いたか。カード番号、パスワード、生年月日、免許証の画像など、持たなくて済むものを持っていないか。パスワードは復元できない形で保管しているか
4. 異常に気づく手がかり：不正な退会や変更、大量のアクセス、システムの不具合を、誰がいつ見るか。記録は残っているか
5. 委託先：システムを作った会社、運用する会社、外部サービスの名前と、事故のときの連絡先を書いたか。向こうから報告が来る窓口は決まっているか
6. 公表の準備：事故のとき、誰が、いつまでに、確認した日・件数・漏えいした項目・案内を書くか。個人情報保護委員会への報告と、問い合わせ窓口の用意まで決まっているか
7. お客様への案内文：「会社からパスワードやカード情報をお伺いすることはありません」という一文と、注意してほしい連絡の例を、事前に下書きしてあるか

2つめと3つめは、今回の13件で、被害の中身を分けた点です。デジタル庁の事案では、修正の適用前に悪用されました。3つめは、持たない、または別のシステムにしていた情報が、流出した項目に入っていなかった事案が多かったためです。7つめは、お客様が最初に目にするのが、会社からの案内文だからです。

この記事で書いていないこと

焼肉きんぐの原因と侵入経路は、書いていません。10月6日朝の時点で公表されておらず、推測は書かないことにしました。ほかの12件も、発表文に書かれていない手口や原因を補っていません。会社の対応の良し悪しの評価もしていません。ヤマト運輸の初報（9月29日）は原文を読めず、第2報と報道で補っています。13件は、9月11日から10月5日に公表された事案のうち、発表文で確認できたものです。この期間のすべての事案を数えたわけではありません。各社が事故の前にどんな対策をしていたかは、発表文に書かれた範囲しか分かりません。書かれていないことは、していなかったという意味ではありません。

社長や同僚に説明するなら

社内で話題になったら、こう説明すると伝わりやすいと思います。

「ここ1か月で、13件の不正アクセスが公表された。会社が手口まで書いたのは3社だけで、12件は、アプリやWebサイトなど、お客様向けのサービスのシステムが被害を受けている。流出するのは、まず氏名・電話・メールで、カード情報は、持っていない、別のシステムにしている、と書く会社が多い。うちも、お客様が使う入口と、持っている情報と、委託先を、書き出してみよう」

よくある質問

焼肉きんぐのアプリの会員は、パスワードを変えたほうがいいですか？

発表文には、パスワード変更の要否は書かれていません。ログインパスワードは漏えいしていない、と書かれています。会社を装った不審なメール・SMS・電話には注意するよう、案内されています。問い合わせ先は、公式アプリ専用コールセンター（0120-795-775、10時〜18時、土日祝を含む）です。

各社は、何も対策していなかったのですか？

発表文からは分かりません。事故の前の対策を説明した会社が少ないためです。決済情報を持たない、別のシステムにする、パスワードを復元できない形で保管する、といった設計は、複数の会社が書いています。「対策していたのに起きた」と書いたのはデジタル庁で、脆弱性の公表から修正の適用までの間に悪用された、という経過でした。

焼肉きんぐの侵入経路は、分かっていますか？

2026年10月6日朝の時点で、公表されていません。発表文は、原因と、不正アクセスが可能となった経緯を調査中としています。

13件は、すべて同じ手口ですか？

分かりません。手口を書いた3社は、いずれも脆弱性の悪用を公表しています。対象は画像アップロードサーバー、Webシステム、VPN機器ですが、脆弱性の具体的な種類や手口が同じかどうかは、これらの記載だけでは判断できません。ほかの事案の手口は、発表文に書かれていません。

中小企業でも、同じ点検が必要ですか？

会員アプリ、予約、問い合わせフォーム、LINE連携のように、お客様が使う入口を持っているなら、点検の意味があります。入口の数や、持っている情報の量で、必要な手間は変わります。

HaruIroAIはこう考える

13件を読み比べて、いちばん気になったのは、手口と、事故の前の対策が書かれていないことです。どこが弱かったかが分からないと、他社は自社を点検しにくい。だから、私たちは、入口の種類と、持っている情報と、委託先を書き出し、修正の適用にかかる日数を決めるところから始めるのが現実的だと考えています。

特に、「持たない」情報の線引きは、事故が起きる前にできる数少ない手です。持っていない情報は、出ようがありません。自社でも、必要のない情報を持っていないか、先に見直してください。

セキュリティの関連ページ

• AIセキュリティ・チャレンジ：AIを安全に使う判断を、場面ごとに試せる無料のチャレンジです。5問から始められ、登録は要りません。
• 実施体制とセキュリティ：当社がお客様のデータをどう預かるか。再委託、契約終了時の返却と削除、事故のときの連絡を書いています。
• セキュリティ・ガバナンスの記事一覧：この領域の記事を、新しい順に並べています。