銀のさらで何が起きたのか――最大650万件の顧客情報とIDCFクラウド侵害の接点を追う

サイバーセキュリティー

ネット探検ラボ|2026年10月15日

2026年10月7日、宅配寿司「銀のさら」の公式サイトと公式アプリで、注文を受け付けられなくなる障害が発生しました。

同じ日、クラウドサービスを提供するIDCフロンティアでも、大規模なランサムウェア攻撃による障害が発生しています。

そして10月13日、銀のさらを展開するライドオンエクスプレスホールディングスは、最大約650万件の登録済み顧客情報について、漏えいの可能性があると公表しました。

この二つの事件には関係があるのでしょうか。

ネット探検ラボでは、両社の公式発表に加え、企業構成や技術者向け求人情報を調査しました。その結果、ライドオンエクスプレスのシステム環境に「IDCFクラウド」が含まれていたことを示す公開資料を確認しました。

本記事では、確認できた事実と状況証拠を整理し、顧客情報の安全性について考えます。

1.銀のさらで何が起きたのか

ライドオンエクスプレスホールディングスが10月13日に公表した第3報によると、事件の経過は次のとおりです。

日付公表された事実
10月5日以降利用サーバーへの第三者による不正アクセスを検知し、調査を開始
10月7日早朝一部サーバーでシステム障害が発生
10月7日サーバー運営会社からランサムウェア攻撃の報告を受け、システムを停止
その後委託先に保管していたデータの取り出し・復元が困難との報告
10月13日最大約650万件の個人情報について漏えいの可能性を公表

影響を受けたのは、銀のさらだけではありません。

同じグループが展開する「釜寅」「すし上等」も、公式サイト・公式アプリからの注文が停止しました。

一方、電話注文、店頭での持ち帰り、出前館やUber Eatsを通じた注文は継続されています。

つまり、店舗の営業全体が停止したわけではなく、主に自社のオンライン注文システムが影響を受けたことになります。

注目したいのは、ライドオン側が、自社の登録者情報を保管していたサーバーについて、その運営会社がランサムウェア攻撃を受けたと説明している点です。

なお、ライドオン側は、サーバー運営会社の名称を公表しておらず、今回の障害がIDCフロンティア(IDCFクラウド)への攻撃によるものだとも明言していません。

そのため、ネット探検ラボでは、公開されている企業情報や技術者の求人資料などから、両社の接点を調査しました。

2.銀のさらとIDCFクラウドの接点を探る

銀のさらを運営する企業はどこか

まず企業構成を整理してみました。

銀のさら、釜寅、すし上等を事業として展開しているのは、株式会社ライドオンエクスプレスです。

その持株会社が、株式会社ライドオンエクスプレスホールディングスです。

2017年10月に持株会社体制へ移行しており、現在の構成は次のようになっています。

株式会社ライドオンエクスプレスホールディングス(持株会社)
↓
株式会社ライドオンエクスプレス(事業会社)
↓
銀のさら・釜寅・すし上等(サービスブランド)

今回の事件を公表したのは持株会社ですが、各ブランドを展開する事業会社との関係は、公式の会社情報から確認できます。

技術者の求人情報に「IDCFクラウド」の記載

次に、事業会社のシステム環境を調べてみました。

2026年5月14日から掲載された株式会社ライドオンエクスプレスのサーバーエンジニア求人には、担当業務として、自社ECサイト、基幹システム、店舗向けシステムなどのサーバー設計・構築・運用が記載されています。

さらに、同じ求人の開発環境欄には、次の技術が記載されています。

項目求人情報に記載された環境
インフラAWS、IDCFクラウド、Docker
データベースMySQL、Snowflake
開発言語PHP、Python、Java
主な担当領域自社ECサイト、基幹システム、店舗向けシステム

これは重要な状況証拠です。

なぜなら、IDCFクラウドが、銀のさらを展開する企業の実際の開発・運用環境として記載されているからです。

しかも、担当するシステムには、今回停止したオンライン注文サービスと関係する自社ECサイトも含まれています。

ただし、この求人情報だけで、今回被害を受けた顧客情報の保管サーバーがIDCFクラウド上に存在していたと確定できるわけではありません。

そこで、両事件の発生状況も比較してみます。

3.二つの事件はどこまで一致しているのか

比較項目銀のさら側IDCフロンティア側
障害発生10月7日早朝10月7日午前3時40分頃
攻撃サーバー運営会社がランサムウェア被害IDCFクラウドがランサムウェア被害
主な影響公式注文システムの停止クラウドサービスの一部で障害
データ復旧取り出し・復元が困難との報告一部データの取り出し・復元が困難と公表
技術的接点求人情報にIDCFクラウドを記載IDCFクラウドが攻撃対象

両事件は、発生時期、攻撃の種類、復旧上の問題という複数の点で共通しています。

さらに、ライドオンエクスプレスの技術環境には、IDCFクラウドが明記されています。

これらの状況証拠を合わせると、銀のさらのシステム障害がIDCFクラウドへの攻撃と関連している可能性は、優先して検証すべき仮説と考えられます。

一方、ライドオン側は被害サーバーの運営会社名を公表しておらず、IDCF側も銀のさらのシステムが被害対象だったとは個別に公表していません。

したがって、現段階では、両事件の直接的な因果関係が確認されたとまでは言えません。

しかし、単に発生日が一致したというだけではなく、実際のクラウド利用を示す公開資料が存在することは、今回の調査で確認できた重要な事実です。

4.最大約650万件とは、どのような情報なのか

銀のさら側が公表した最大約650万件とは、公式サイトや公式アプリに過去登録された顧客情報のうち、漏えいした可能性がある件数です。

650万件の窃取が確認されたという意味ではありません。また、重複を除いた650万人の人数が確定したものでもありません。

対象となる可能性がある情報には、次のものが含まれています。

  • 氏名、住所、電話番号、メールアドレス
  • 性別、生年月日
  • パスワードのハッシュ値
  • 注文履歴
  • デリポイント会員ID
  • 登録された家族の情報や、別の配達先の氏名・住所・電話番号

なお、クレジットカード情報は同社で保有していないため、対象に含まれないと説明しています。

ここで注意したいのは、単なる連絡先だけでなく、注文履歴や配達先情報も対象となる可能性があることです。

仮にこれらの情報が攻撃者に取得されていた場合、利用者の生活に関係する情報を悪用したフィッシング詐欺などにつながる危険があると危惧します。

5.IDCFは「情報流出なし」と判断している

一方、IDCフロンティアは10月14日に公表した第5報で、被害を受けた東日本リージョン1の4ゾーンにある顧客の仮想サーバー内データについて、調査結果を説明しています。

外部のセキュリティ専門企業と連携し、侵入経路、アクセスログ、認証ログ、操作ログ、攻撃者が実行した処理、データ持ち出しの痕跡などを調査したとしています。

その結果、データが照会されたり、外部に持ち出されたりしたことを示す痕跡や裏付け事実は確認されなかったと説明しました。

そして、IDCFは外部へのデータ流出はなかったという判断に達しています。

ここは正確に区別する必要があると思います。

IDCFは、単に流出を確認できなかったと述べているのではなく、調査結果に基づいて「流出なし」という結論を示しています。

ただし、その結論を第三者が独立して検証できるだけの詳細な技術資料は、公開されていません。

また、IDCFはクラウドポータルで48社の登録情報に対する不正な照会が行われたことも確認しています。これは顧客の仮想サーバー内データとは別の情報です。

銀のさら側の発表との違い

銀のさら側は10月13日時点で、個人情報の漏えいについて明確な痕跡や事実、範囲を特定できていないと説明しています。

そのため、最大約650万件について漏えいの可能性を排除していません。

一方、IDCF側は、調査対象の仮想サーバー内データについて流出なしと判断しています。

仮に両社が同じ被害基盤について説明しているのであれば、この判断の違いは注目に値します。

IDCFがどの範囲を調査し、何を根拠に流出を否定したのか。銀のさら側の懸念と、どのように整合するのか。

これらについては、今後の説明を待つ必要があります。

ネット探検ラボとしても、実際に顧客情報が窃取されたのかどうかを、公開情報だけで判断することはできません。

6.登録済み顧客への注意喚起を

銀のさら側は10月13日の発表で、対象となる可能性のある顧客へ順次案内を送る方針を示し、不審な電話やメールへの注意も呼びかけています。

この対応は重要です。

最大約650万件の顧客情報について漏えいの可能性が排除できない以上、今後も対象顧客への迅速で確実な通知を進め、特にフィッシング詐欺への警戒を継続して呼びかけることが求められます。

情報漏えいが確定するまで待つのではなく、被害の可能性がある段階で利用者の安全を守ることが大切です。

7.クラウドを利用する企業が学ぶべきこと

今回の事件は、クラウドという共通基盤に自社システムを預ける企業にとって、重要な教訓を含んでいます。

クラウド事業者が攻撃を受ければ、利用企業が直接侵入されていなくても、サービスの停止やデータの利用不能という重大な影響が及ぶ可能性があります。

クラウド事業者の安全対策に依存するだけでは、自社の事業継続や顧客情報の保護を十分に保証できない時代になっています。

利用企業自身も、独立したバックアップ、復旧手順、委託先との情報共有、顧客への緊急連絡体制などを見直し、必要なルールと投資を進めていくべきではないでしょうか。

守るべきものは、自社のシステムだけではありません。取引先、そしてサービスを信頼して利用する顧客の安全です。

今回の事例を、クラウド事業者と利用企業の双方が、より強い防御と事業継続体制を構築するための教訓として生かしてほしいと思います。


参考資料

コメント

タイトルとURLをコピーしました