松屋公式アプリに不正アクセス、約238万件が漏えい｜相次ぐ「公式アプリ」の事故から発注側が見直すべきこと

はじめに
何が起きたのか
なぜ「公式アプリ」は狙われ、守りが手薄になりやすいのか
発注側が自社で整えておきたい仕組み
まとめ
参考

はじめに

2026年10月、飲食チェーンの公式アプリを狙った不正アクセスの公表が続いています。10月5日には「焼肉きんぐ」、10月15日には「バーガーキング」が、それぞれ約1,000万件規模の会員情報の漏えいを公表しました。そして10月30日、牛丼チェーン「松屋」を運営する松屋フーズホールディングスが、公式アプリの管理システムへの不正アクセスにより約238万件の個人情報が漏えいしたと発表しました。

各社の発表を見る限り、3社の事案に共通の原因や共通の委託先があるとは示されていません。ただ、「公式アプリ」という同じ種類のシステムで大規模な漏えいが相次いでいることは、アプリを持つ企業にとって見過ごせない状況です。

この記事では、松屋の事案の概要を整理したうえで、公式アプリがなぜ守りの手薄な場所になりやすいのか、そして発注側として自社で何を決めておけばよいのかを、発注側支援の立場から解説します。

何が起きたのか

松屋フーズホールディングスの発表と報道によると、概要は次のとおりです。

2026年10月28日21時ごろ、松屋公式アプリの管理システムへの第三者からの不正アクセスを検知した
同日夜から、公式アプリと公式ホームページを停止。アプリ内の弁当予約（松弁ネット）やモバイルオーダーも使えなくなった
10月30日、個人情報の漏えいを公表。松弁ネット、モバイルオーダー、松弁デリバリーの利用者約237万7,127件について、会員ID、氏名、電話番号、松屋ポイント情報が漏えいした。デリバリー利用者は配達先住所も含まれる
このほか、公式アプリの会員登録者約2,000件（最大3,000件）について、生年月日、メールアドレス、暗号化されたパスワードが漏えいした
クレジットカード情報は保有していないとしている
侵入の原因や経路は調査中。個人情報保護委員会へ報告し、対象者への連絡を順次進めている

また、アプリ停止中の補償として、会員ランクの引き上げや割引クーポンの配布などを案内しています。

同じ月の先行事例では、焼肉きんぐ（物語コーポレーション）が公式アプリの会員管理システムへの不正アクセスにより、登録者約1,080万人のうち約1,079万件の会員番号、氏名、メールアドレス、電話番号が漏えいしたと公表しています。こちらも原因は調査中とされています。

なぜ「公式アプリ」は狙われ、守りが手薄になりやすいのか

各社の原因はまだ分かっていないため、ここでは特定の会社の話ではなく、公式アプリという仕組みが一般的に抱えやすい構造について整理します。

情シスの管轄外で生まれ、育つ

公式アプリは、多くの企業でマーケティング部門や販促部門が主導して作られます。目的は集客やリピート促進で、評価されるのはダウンロード数や会員数です。開発や運用はアプリ制作会社やアプリ向けのサービス事業者に任せ、契約も事業部門が直接結んでいる、という形が珍しくありません。

その結果、基幹システムには当てはまる情報システム部門のルール（資産台帳への登録、脆弱性診断、アクセス権限の棚卸しなど）が、公式アプリには適用されていない、ということが起こります。

機能を足すほど、データが集まる

松屋の事案で漏えいの大半を占めたのは、アプリの会員登録者ではなく、弁当予約やモバイルオーダー、デリバリーの利用者でした。最初はクーポンやポイントのためのアプリでも、予約、注文、配達と機能が増えるたびに、氏名・電話番号・住所といった情報がひとつの管理システムに集まっていきます。

機能追加は事業的には正しい判断ですが、そのたびに「守るべきデータが増えた」という認識が持たれないまま進むと、攻撃者にとって魅力的な場所ができあがります。

「会員数」は増えても、減らす仕組みがない

焼肉きんぐの事案では、登録者のほぼ全件が漏えいの対象になりました。会員数を指標にしていると、長く使われていない会員のデータを削除する動機が生まれにくくなります。休眠会員の情報も、現役会員と同じ場所に、同じ形で置かれ続けることになります。

発注側が自社で整えておきたい仕組み

ここからは、発注側支援のコンサルタントとして、同じことを自社で起こさないために何を決めておくべきかを整理します。ポイントは、公式アプリを「販促ツール」ではなく「大量の個人情報を持つ業務システム」として扱い直すことです。

1. 公式アプリを台帳に載せ、「持ち主」を決める

まず、自社が提供している公式アプリ、会員サイト、予約・注文サービスを洗い出し、システム台帳に載せます。台帳には最低限、次の項目を記録します。

事業上の責任者（企画・予算を持つ部門）と、セキュリティ上の責任者（情報システム部門など）
開発・運用の委託先と、利用しているクラウドや外部サービス
保有している個人情報の種類と件数
管理システム（管理画面）にアクセスできる人と、その経路

大事なのは、事業部門が持ち主であっても、セキュリティの確認は情報システム部門が関わる、という役割分担を明文化することです。「事業部門のアプリだから情シスは知らない」という状態を、仕組みとしてなくします。

2. 機能追加のたびに「データの棚卸し」を挟む

予約、注文、デリバリーといった機能を追加するときは、企画の承認フローに「新たに集める個人情報は何か」「既存のデータとどこで結び付くか」「保存期間はどうするか」を確認する項目を入れます。

あわせて、保存期間のルールを決めます。たとえば「最終利用から3年たった会員は通知のうえ退会扱いとし、個人情報を削除する」「配達先住所は配達完了後○か月で消す」といった具合です。会員数のKPIだけでなく、「保有データを必要最小限にしているか」も評価の観点に加えるよう、経営層とすり合わせておくと進めやすくなります。

3. 管理画面の守りを委託先任せにしない

今回の各社の原因は不明ですが、一般論として、アプリそのものよりも、運営側が使う管理画面や管理用の仕組みのほうが、全会員のデータに一度にアクセスできる強い権限を持っています。発注側として、次の点を委託先に確認し、文書で回答をもらいます。

管理画面に多要素認証がかかっているか、アクセス元を制限しているか
管理者アカウントは誰が何人持っているか。退職者や契約終了した外部要員のアカウントが残っていないか
大量のデータ出力や、深夜の一括アクセスを検知する仕組みがあるか
操作ログを何日分保存し、事故時に発注側へ提出できるか

これらは一度確認して終わりではなく、年1回の定期報告として求めるのが現実的です。

4. 委託契約に「事故時の取り決め」と「止まったときの数字」を入れる

アプリの開発・運用契約には、機能や納期の話はあっても、セキュリティ事故時の取り決めが薄いことがよくあります。少なくとも次の項目は契約か覚書に入れておきたいところです。

不正アクセスの疑いを検知してから発注側に報告するまでの時間
調査への協力義務と、ログやデータの提出範囲
年1回以上の脆弱性診断の実施と、その結果の共有
再委託先がある場合の、同等の義務の適用

また、松屋の事案のように、アプリ停止は売上や顧客体験に直結します。復旧までの目標時間や、停止中の連絡体制を数値で決めておくことも重要です。何を数値で決めるべきかは、ベンダーとのSLAで握っておくべき数値を整理した記事でも解説しています。

5. 「アプリを止める日」を前提に段取りを作る

最後に、アプリが止まった日の動きを事前に決めておきます。

停止を判断する権限は誰にあるか（夜間・休日を含む）
予約済みの注文や、定額サービスの利用者への対応をどうするか
顧客向けのお知らせ文、問い合わせ窓口、なりすましメールへの注意喚起の文面
補償やお詫びの方針と、その予算の決め方

松屋は検知当日の夜にアプリとホームページを止め、翌日に公表しています。こうした素早い判断は、事前の段取りがあるかどうかで大きく変わります。年に一度、「明日、公式アプリから全会員データが抜かれたら」という想定で、関係部門と委託先を交えた机上訓練をしておくと、連絡先の古さや判断者の不在といった穴が見つかります。

まとめ

松屋の公式アプリへの不正アクセスで約238万件の個人情報が漏えいした事案は、同じ月に続いた焼肉きんぐやバーガーキングの事案とあわせて、公式アプリが大量の個人情報を抱える場所になっていることを示しています。原因はまだ調査中ですが、公式アプリは事業部門主導で作られ、機能追加とともにデータが集まり、情報システム部門のルールが届きにくいという構造を持ちがちです。発注側にできるのは、公式アプリを台帳に載せて持ち主とセキュリティ責任者を決め、機能追加のたびにデータを棚卸しし、管理画面の守りと事故時の取り決めを委託先と文書で合意し、止まる日を前提に段取りを作っておくことです。まずは、自社が提供しているアプリと会員サービスを一覧にするところから始めてみてください。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。