ヤマト・バーガーキングでも
情報漏洩｜
10月の発表と
AI開発で見直す対策

10月16日、ヤマト運輸が後払いサービスの情報の不正持ち出しを公表しました。

前日の15日には、バーガーキングが公式アプリの会員情報約1,118万件の漏洩を発表しています。

今回の情報漏洩ニュースでは、古い決済ログや開発用クラウドまで、調査の対象になっています。スカイチケットは初報のカード情報に関する説明を訂正し、ショップサーブも最終調査結果を公表しました。

現在のシステムでカード情報を保存しなくても、古いログに残っていたらどうなるのか。AIで業務システムを作る企業にも関わる問いです。まずは、各社の最新発表で何が分かったかを読み解きます。

以下は2026年10月17日時点の確認内容です。発表が近いだけで、同じ攻撃者や原因と判断するものではありません。

この記事で分かること

• 直近の情報漏洩について、最新の続報で何が訂正・確定したかを確認できます
• 旧ログと開発環境の被害から、AI開発でもコードの外の保存先を確かめます
• 利用者への対応依頼と、AI化する企業の点検を分けて説明します

ヤマト、バーガーキング
などで、何が公表された？

今回取り上げる5件は、情報の流出が公表されています。ただし、確認された項目と追加調査中の範囲は別です。事件全体の件数と、追加公表されたカード情報の対象人数を混同しないように読みます。

表の日付は公式発表・続報の公表日であり、すべての攻撃がこの日に起きたわけではありません。企業の規模や被害件数を順位付けする表でもありません。

出典：ヤマト運輸・第4報、バーガーキングの発表、スカイチケット・第2報、ショップサーブ・最終報。

開発環境の事案の出典：日本経済新聞社・10月16日発表。

各社の数字を足して「何千万人が被害」とは数えられません。件数と人数の違いがあり、サービスをまたいだ利用者の重複も、この発表だけでは分からないためです。

スカイチケットは
初報を訂正。
旧ログに
カード情報が残っていた

旅行予約サービス「スカイチケット」の運営会社は10月16日、初報の「カード番号は流出した情報に含まれない」という説明を訂正しました。現在はカード情報を保存しない決済方式でも、移行前の決済ログが残っていたためです。

対象は、2017年2月〜
2018年6月の一部の決済

今回追加公表されたカード情報の対象は、当該期間に「skyticketプレミアム」の会費決済でカードを登録または利用した最大6,140名です。事件全体の対象者数の上限ではありません。

カード番号、名義、有効期限が含まれ、一部は番号のみ。セキュリティコードは含まれていません。

保存していたカード情報は移行時に削除しましたが、会費決済の記録はサーバーに残っていました。10月2〜4日の不正アクセスにより、3日にログが取得されたことを確認したと説明しています。

カード情報は暗号化されていたものの、暗号化に用いる情報も取得され、読み取られるおそれがあるとしています。

2018年7月以降の支払・登録に関するカード情報は流出していないと説明する一方、プレミアム会費以外の古い決済情報が残っていないかは調査中です。全利用者のカード情報が対象ではありません。

同じ第2報では、プレミアム特典のベネフィット・ステーションを使うための会員ID・氏名・パスワードの流出も公表しています。現在も利用する方へパスワード変更を案内しており、カード情報だけの続報ではありません。

出典：アドベンチャー・10月16日第2報。

AIへ確認を頼む範囲にも、
古い保存先を含める

例えば、AIに現在のコードだけを読ませ、「カード情報を保存していますか」と聞く場面を考えます。これは本記事の設計例で、同社がAIで開発していたという説明ではありません。

AIが読める範囲に旧ログや古い保存先がなければ、その所在まで確認できるとは限りません。コード確認とは別に、移行前のログ、書き出したファイル、使わなくなった環境を担当者が調べます。

新しい仕組みを作る作業と、古い仕組みに残る情報を確認する作業は、別々に必要です。保存の必要性や削除の可否は、契約・規程・事故調査の条件を確認できる責任者が判断します。

ヤマト・日経など4社の
発表で分かったこと

ヤマトは「可能性」ではなく、
持ち出しを確認

ヤマト運輸の第4報は、調査で情報の不正な持ち出しが判明した発表です。対象は「クロネコ代金後払いサービス」であり、利用者情報約526万件、お届け先情報約5万件、加盟店情報約4,100件と区分されています。

氏名・住所・電話に加え、区分によって商品明細や管理用情報なども含みます。クレジットカード情報とパスワードは含まれていません。

自社の通販でどの後払いサービスを使っているか、顧客のどの情報が渡るかを担当者と確認します。「ヤマトを使っている」という会社名だけでは、対象かどうかを判断できません。

出典：ヤマト運輸・10月16日第4報。

バーガーキングは、
公式アプリの会員情報が対象

バーガーキングの10月15日発表は、公式アプリの会員情報約1,118万件の漏洩です。不正アクセスは10月2〜7日、漏洩が判明したのは13日としています。

対象には会員ID、メールアドレス、氏名、電話番号、生年月日などがあります。カード番号は保有しておらず漏洩していないと説明し、ログインパスワードの漏洩は確認されていません。

詳しい原因は調査中です。アプリの会員情報が対象だからといって、どの認証処理に欠陥があったかまで補って説明しないようにします。

出典：バーガーキング・公式発表。

ショップサーブは、10月の
新規侵入ではなく最終調査報告

ショップサーブは、Eストアーが提供するネットショップの構築・運営サービスです。購入者がサービス名を知らなくても、買い物をした店舗が利用している場合があります。

10月16日の最終報は、対象者約2,335万6,000人、対象店舗7,858店としています。過去の利用店舗も含み、人数は重複をできる限り除いた概数です。完全な実人数の確定値とは分けて扱います。

約209万6,900人には、カード名義、番号の先頭6桁と末尾4桁、有効期限が含まれます。完全なカード番号やセキュリティコードが漏れたという発表ではありません。

確認した攻撃期間は5月21日〜8月1日。アプリの脆弱性を悪用して不正なプログラムを実行し、データベースから情報を外へ送信したと説明しています。期間自体は8月の第2報でも公表されており、10月に新たに侵入された事案ではありません。

今回の最終報では、調査で原因と対象範囲を確定するとともに、以前は対象としていた店舗メール・FTPの認証情報、振込先口座情報を対象外へ訂正しました。過去の報告とは集計単位も異なるため、人数が何倍に増えたという説明はできません。

同社の関係会社のサービスは異なる環境で管理され、本件対象外としています。親会社やグループ全体の顧客情報へ、範囲を広げて読まないでください。

出典：Eストアー・最終報、8月2日の第2報。

日経の発表は、開発用の
クラ
ウドも点検対象だと示している

「日経」は日本経済新聞社です。10月16日の発表は、システム開発に使うクラウドへの認証情報が窃取され、不正アクセスされた事案でした。新聞サイトの画面だけの話ではありません。

約183万件の内訳は、氏名やメールなどを含む約15万件と、単体では個人を特定できない識別子のみの約168万件です。

約183万人全員の住所・氏名が流出した、という読み方はできません。また、認証情報が盗まれた手段や、AI開発の関与は公表されていません。

自社の点検では、本番の業務システムだけでなく、試作の保存先や開発用のコピーも調べます。「テスト用」という名前でも、実際の顧客情報を入れていれば、その情報を守る必要があります。

出典：日本経済新聞社の10月16日発表。

タイムズとinfoQの
続報は、
保存していた
情報の違いも示した

タイムズカーは10月16日、本人確認画像を会員期間中・退会後7年間保有するルールから、登録確認後に即時削除する運用へ変更すると発表しました。現在保有する画像も10月末までに削除する予定です。

一方、アンケートサイトinfoQの10月14日・第2報では、個人情報89万4,082件の持ち出しを確定しました。別の9,068件の記録は持ち出されたものの、退会後の方針に基づき、個人情報はすでに削除されていました。

侵入を防ぐ対策と、持ち出される情報を減らすための保存管理は、別々に必要です。削除すれば侵入を防げる、infoQの削除期間が他社にも正解、という結論ではありません。

10月17日時点でタイムズの現在保有分がすべて削除済みになったわけでもありません。予定と完了を分けて読みます。

出典：タイムズカー・第4報、infoQ・第2報。

攻撃側のAI利用は、
どこまで分かっている？

JPCERT/CCは10月15日、攻撃元サーバーの調査で、AIを利用した既知の脆弱性のスキャンやAPI経由の攻撃を確認したと公表しました。ただし、本記事に挙げた各社の事件を、AI攻撃と特定した発表ではありません。

APIは、アプリなどがサーバーの情報を取得・更新するための窓口です。

公表日が近いという理由で、原因を調査中の事案まで、同じ攻撃者・同じ手口の被害として説明しないようにします。

企業側で注目したいのは、攻撃者がアプリの内部情報や通信先を調べ、利用者向け画面とは別の経路からアクセスする可能性です。画面上でボタンを隠す対策だけでは、サーバーへのアクセスを制限したことになりません。

JPCERT/CCは、長期間使える秘密情報をアプリ内へ埋め込まないこと、サーバー側で利用者と操作対象の権限を確認することなどを挙げています。

過剰なアクセスの制限や監視も対策に含まれます。新しいAI製品を買う前にも確認できる、システムの基本条件です。

出典：JPCERT/CC「連続不正アクセス事案の攻撃手法に関する調査」。公開前の具体的な確認方法は、AI開発のセキュリティ対策と公式スキルの使い分けでも解説します。

まるっとAIの
見解｜コードの
外にある
保存先と連携も確かめる

スカイチケットでは旧ログ、日経では開発用クラウドが調査の対象になりました。まるっとAIとしては、AIへ現在のコードを確認させただけで、業務全体の点検を終えないことが必要だと考えます。

各社と自社に同じ欠陥があると決めつけず、利用中のサービスと自作システムを分け、古い保存先や委託先も含め、どの情報を誰が取り出せるかを確かめます。

例えば、見積依頼フォームからメールへ通知し、AIで問い合わせを分類して、顧客管理表へ記録する業務を考えます。以下は実在企業の事故ではなく、点検のための架空の設計例です。

AIへの入力前に、利用するAIの契約・保存条件と、その環境へ一覧を入力してよいかを確認します。

社内で閲覧できる情報でも、外部AIへの送信が許可されているとは限りません。顧客名を消しても、担当者名やファイルの場所などが社外秘に当たる場合があります。

保存期間は、AIに決めさせない

本人確認画像、契約書、問い合わせの添付ファイルでは、残す必要がある理由が違います。社内規程や契約、法令上の保存が関わる資料を、古いという理由だけで消すことはできません。

AIには、保存理由や期限が未記入の資料を挙げさせるところまで任せます。削除する対象と時期は、業務・契約上の条件を確認できる責任者が決めます。

事故を疑っている資料は、調査の証拠を失わないよう、通常の整理・削除とは分けて扱ってください。

外部連携は、
使わなくなった後も確認する

サービスのアカウントを整理しても、別サービスへアクセスする連携や認証用のキーが残る場合があります。キーは、システムが接続を許可されるための秘密情報です。

連携の管理画面で、何につながり、どの権限を与え、誰が更新するのかを確認します。

漏洩が疑われるキーは、文字列を消すだけでなく、発行元での無効化・再発行や履歴の確認が必要です。順序は、被害拡大の防止と証拠保全を両立できる担当者が判断します。

出典：OWASPの秘密情報管理に関する指針。AIが外部ツールへ接続する仕組みは、MCPの用途と注意点でも確認できます。

AIを使っても、更新・
多要素認証・バックアップは必要

AIの点検を追加しても、ソフトウェアの更新やアカウント管理を省けるわけではありません。パスワード以外の確認も求める多要素認証、不要な権限の削除、異常な利用の監視は、利用サービスや社内の管理画面で実施します。

バックアップは、作成成功の通知だけで終えず、必要な情報を戻せるかを確認します。通常のアカウントが侵害されても、一緒に失われないかも担当者と調べてください。

AIには確認予定や結果の整理を手伝わせ、設定変更や復元を無条件に実行させないようにします。

IPAの中小企業向けガイドライン第4.0版は、基本対策にバックアップを加えた情報セキュリティ6か条を示しています。AIは既存の対策を続けるための補助として使い、基本対策との置き換えにしません。

出典：IPAのガイドライン第4.0版。各サービスの利用可能な認証方式や権限設定は、管理者が公式案内で確認してください。

生成AIには、一覧の照合と
確認項目の作成を任せる

今回のニュースでAIに手伝わせるなら、まず公開された公式発表から、対象サービス・対象期間・対応依頼・続報の予定を整理する使い方があります。初報だけを渡して判断せず、最新の続報を人が開いて確認します。

ヤマトの対象は後払いサービス、ショップサーブは利用店舗の先にいる購入者等も対象です。会社名の一致だけで判定せず、契約一覧と実際の利用サービスを担当者が照合してください。

自社の点検では、コードに加え、旧ログ・開発用コピー・委託先の保存・接続権限を確認対象に含めます。一覧の空欄をAIが埋めたことを、管理画面で設定を確認した記録に置き換えないようにします。

別の利用者の情報を取得・変更できないかは、合意した試行環境と架空データで実際に操作して確認します。具体的な点検表と、スキルを取り込ませる手順はAI開発の公式セキュリティツールと使い方へ分けています。

漏洩が疑われるとき、
AIへログの原本を渡さない

不審な取得や外部公開に気づいた場合は、社内の対応責任者と契約先の窓口へ連絡し、被害拡大の防止と証拠保全を進めます。

本記事は、事故発生時の個別判断に代わるものではありません。AIとの相談だけで初動を終えないでください。

ログには、個人情報や認証情報、社内システムの構成が含まれることがあります。そのまま外部の対話型AIへ渡すと、調査の過程で情報の送信先を増やしてしまいます。

AIで補助する必要がある場合は、責任者が許可した環境で、原本と分析用のコピーを分け、必要部分を最小限にします。秘匿する項目を担当者が確認し、AIが編集したログで原本を上書きしないようにしてください。

原因究明、影響範囲の確定、本人や関係機関への連絡の要否は、専門家や関係する担当者の判断が必要です。報告の要件・期限も事案によって確認が必要なため、ここでは一律の期限や「この対策で完了」という判定を置きません。

出典：IPA「中小企業の情報セキュリティ対策ガイドライン」のインシデント対応の手引き、個人情報保護委員会の漏えい等対応の案内。

利用者は最新の案内を、
AI
開発では古い保存先を確認する

まず、利用中のサービスの最新発表で、自分や自社が対応を求められていないか確認してください。サービスごとに対象の期間や情報、必要な対応が違います。

スカイチケットの第2報は、対象となる古いプレミアム会費の決済に使ったカードについて、10月以降の明細確認などを案内しています。特典サービスを現在も利用する方へのパスワード変更案内もあります。

一方、ショップサーブは本件に関連してカード情報の再入力や再決済を求めないと明記しています。漏洩を装った連絡もあるため、スカイチケットの公式案内やショップサーブの最終報へ直接アクセスして確認します。

AIで業務を変える企業は、現在のコードとデータベースだけでなく、移行前のログ、開発用コピー、委託先の保存、使わなくなった連携も点検の範囲に含めてください。

新しい仕組みで何をするかと一緒に、使い終えた情報をどう扱うかまで決める。まるっとAIとしては、今回の続報を、この確認を具体化するきっかけにすべきだと考えます。

AIの導入そのものに許す権限は、Claude Codeの法人導入で確認する権限・MCP・機密情報、業務の選び方はAI導入の進め方で整理しています。作ったアプリを公開する前の検査は、開発担当者と分けて確認しましょう。