FAQ・問い合わせ管理システム「i-ask」を提供するスカラコミュニケーションズ（東京都渋谷区）、管理サイトへの不正ログインで最大5社・延べ71万3,126件の問い合わせ情報が漏えいのおそれ

2026/10/06 情報収集中重大情報通信・IT #不正アクセス #サプライチェーン

項目	内容
発生日	2026年10月2日20時33分頃〜10月3日8時1分頃（第三者が「i-ask」の管理サイトに不正ログインし、サーバに不正なプログラムを設置していた時間帯）
公表日	2026年10月6日（株式会社スカラ）。利用企業の一部は10月5日から個別に公表
対象組織・業界	株式会社スカラコミュニケーションズ（東京都渋谷区／FAQ・問い合わせ管理システム「i-ask」を提供。東証上場の株式会社スカラの連結子会社／情報通信・IT）。情報が漏えいした可能性があるのは、同システムを導入していた利用企業の問い合わせ者
影響件数	最大5社・延べ最大713,126件。問い合わせ単位の延べ件数で、同じサーバ上に保存されていた複数社分が対象です。利用企業のうち数社は約10万人規模の対象者数を個別に公表していますが、全5社の社名と内訳は公表されていません
攻撃手法	第三者が「i-ask」の管理サイトに不正ログインし、サーバに不正なプログラムを設置しました。管理サイトへのログインに用いられた認証情報の入手経路は公表されていません
情報源	株式会社スカラ「当社連結子会社における不正アクセスによる個人情報漏えいに関するお詫びとお知らせ」（2026年10月6日・PDF）、シチズン時計「委託先事業者に対する不正アクセスによるお客様情報の漏えいの可能性について」（2026年10月6日）、INTERNET Watch（2026年10月5日）、Bloomberg（2026年10月5日）、セキュリティ対策Lab

概要

株式会社スカラは2026年10月6日、連結子会社の株式会社スカラコミュニケーションズが提供するFAQ・問い合わせ管理システム「i-ask」のサーバが第三者による不正アクセスを受け、個人情報が漏えいした可能性があると公表しました。

漏えいの可能性があるのは、同システムを導入していた最大5社・延べ最大713,126件の問い合わせ情報です。713,126件は問い合わせ単位の延べ件数で、同じサーバ上に保存されていた複数社分がまとめて対象になっています。

侵入が確認されているのは、2026年10月2日の20時33分頃から翌3日の8時1分頃までです。第三者が「i-ask」の管理サイトに不正にログインし、サーバに不正なプログラムを設置していました。スカラコミュニケーションズは10月3日の朝にアクセスを遮断し、同日中に利用企業へ報告しています。

利用企業の一部は10月5日から個別に対象件数を公表しており、約10万人規模の対象者を示した企業もあります。対象となったのは、各社のWebサイトに設置された問い合わせフォームから送信された氏名、住所、電話番号、メールアドレスなどです。問い合わせ内容の記入欄に銀行口座情報やクレジットカード情報を書いていた場合は、それらも漏えいした可能性があると説明した企業もあります。

全5社の社名と内訳は公表されていません。公表時点で、情報の不正利用などの二次被害は確認されていません。

委託先の被害が複数の組織に広がった事例は、委託先の被害で影響を受けた企業・自治体の一覧にまとめています。

経緯

2026年10月2日 20時33分頃: 第三者が「i-ask」の管理サイトに不正にログイン。サーバに不正なプログラムが設置される
2026年10月3日 8時1分頃: 不正アクセスが継続していた時間帯の終わり
2026年10月3日朝: スカラコミュニケーションズがアクセスを遮断。同日中に「i-ask」の利用企業へ報告
2026年10月5日: 利用企業のうち大和証券が先行して公表
2026年10月6日: 株式会社スカラが公表し、最大5社・延べ最大713,126件と明らかにする。同日、シチズン時計も対象件数を公表

原因

公表されているのは、第三者が「i-ask」の管理サイトに不正にログインし、サーバに不正なプログラムを設置したことです。

管理サイトへのログインに使われた認証情報をどのように入手したのか、設置されたプログラムがどのような動作をしたのかは公表されていません。

対策

1. 個人情報を預けている外部サービスを洗い出し、リスクとして数える

この事案で情報が出たのは、利用企業それぞれのシステムではありません。各社が導入していた1つの外部サービスです。自社の設備が無傷でも、個人情報を預けた先が侵害されれば、その情報は外に出ます。今回は提供事業者1社への侵入で、最大5社分の問い合わせ情報が同時に対象になりました。

問い合わせフォーム、FAQ、チャットサポート、アンケート、予約、採用応募。個人情報が通る外部サービスは、導入が手軽なぶん部署ごとに増え、全体像が誰にも見えなくなります。打ち手は、顧客の個人情報が通る外部サービスを名前で挙げられる状態にし、それぞれに「どの項目が」「何件」「どれだけの期間」置かれているかを結びつけておくことです。契約した時点ではなく、運用しながら数え直します。これができていれば、委託先から侵害の連絡を受けた日に、自社の対象範囲を自社の言葉で説明できます。できていなければ、相手の調査結果を待つあいだ、顧客に何も言えない時間が続きます。

2. 外部サービスに預ける情報を、項目と期間の両方で減らす

713,126件は問い合わせ単位の延べ件数です。1日に届く問い合わせの数ではなく、消されずに積み上がった過去の履歴が、そのまま漏えいの規模になりました。

減らし方は二つあります。ひとつは期間で、対応が終わった問い合わせを何か月で消すかを決め、自動で消える状態にしておくことです。もうひとつは項目で、利用者は用件を説明するために自由記述欄へ口座番号やカード番号を書き込むため、入力画面で書かないよう明示し、保存時に数字の並びを検出してマスクし、すでに溜まっている履歴も検査して該当するものを消します。同じ侵入を受けても、外に出る件数と、その中に含まれる最悪の項目が変わります。

3. 管理サイトへのログインを、IDとパスワードだけで通さない

この事案の起点は、脆弱性を突いた侵入ではなく管理サイトへの不正なログインです。正しい認証情報を使ったログインは、システムから見れば正規の利用と区別がつきません。

打ち手は入口を増やすことです。多要素認証をかける、接続元のIPアドレスを事業所や保守拠点に限る、管理画面そのものを公開ネットワークに出さずVPNや専用経路の内側に置く。いずれか一つでも成立していれば、認証情報が攻撃者の手に渡っても管理サイトには入れません。外部サービスを選ぶ側も、管理画面に多要素認証と接続元制限をかけられるかを、導入時に確認する項目に入れておきます。

ヤグラの視点 — 攻撃は起きる前提で、平常時に何を揃えておくか

侵入が確認されている時間帯は、10月2日の20時33分頃から翌3日の8時1分頃までです。遮断できたのは3日の朝でした。11時間半のほとんどが営業時間の外に収まっています。攻撃側は曜日も時刻も選びません。生成AIの普及以降、攻撃は24時間365日にわたって自律的に仕掛けられるようになり、その数は5年で20倍に増えたという報告もあります。守る側だけが日中の体制で待っていると、この時間差がそのまま被害の大きさになります。

さらに、個人情報を預ける先が増えるほど、自社の監視が届かない場所に顧客の情報が置かれていきます。つまり、攻撃を受けないようにする話と、受けたときに何が起きるかを把握しておく話は、別々に用意しておく必要があるということです。起きてから考える体制では、起きた日に「何が出たのか」すら自社では答えられません。そして今回のように、正規の認証情報で入られた侵入は認証の失敗ログを残しません。検知された攻撃の79%がマルウェアを使わないという報告があるとおり、端末上のウイルス対策では捉えようがない侵入です。

それでも痕跡は残ります。普段と違う時刻や接続元からの管理者ログイン、サーバ上に新しく置かれたファイル、外向きに増えた通信。問題は、これらがID基盤の認証ログ、サーバのファイル更新履歴、通信ログと、別々の場所に散らばっていることです。だから平常時のうちに、管理者ログインが普段どの時刻にどこから行われているかと、外部サービスに預けた情報の一覧を同じ場所に集めておきます。そのうえで、そこから外れた動きに自動で一次調査がつく状態にします。深夜に全ログを人手で突き合わせるのは成り立たないので、横断的に集めて機械に拾わせる形にしておくと、検知から初動までを数時間から数日ではなく数分の単位にできます（→ ヤグラ AI SOC）。

今後の対応

今後は、次の点が明らかになるか注目されます。

管理サイトへのログインに使われた認証情報の入手経路
設置された不正プログラムの動作と、実際に外部へ送信された情報の範囲
公表されていない残りの利用企業と、その対象件数
延べ713,126件のうち、個人を特定できる情報が何件含まれるか
漏えいした情報を悪用したフィッシングやなりすましの発生状況

件数はいずれも「最大」として公表されており、調査が続いています。進展があり次第、本記事に追記します。

更新履歴

日時	内容
2026-10-06	第一報を公開