異なる業種の3社を結んだ、一つの不正アクセス事件

2026年10月上旬、証券会社の大和証券、時計メーカーのシチズン時計、そして大手損害保険会社の損害保険ジャパンが、相次いで外部委託先のシステムに対する不正アクセスと、顧客情報の漏えいの可能性を公表しました。

大和証券では約11万人に関係する約22万件の問い合わせ情報、シチズン時計では約10万人分、損害保険ジャパンでは約6万件の問い合わせ情報が、漏えいした可能性のある対象となっています。

証券、時計、保険。

事業内容も顧客層も異なる企業で、なぜ同じ時期に不正アクセスの影響が明らかになったのか。

実は、この3社には一つの共通点がありました。

顧客からの問い合わせに対応するため、同じ事業者が提供するシステムを利用していたのです。

そのシステムが、株式会社スカラコミュニケーションズのFAQサービス「i-ask（アイアスク）」でした。

同社が10月6日に公表した内容によると、i-askの管理サイトに第三者が不正ログインし、サーバー上に不正なプログラムを設置したことが確認されています。

さらに、同じサーバー上で稼働していた複数企業のシステム環境にあるデータベースから、顧客の問い合わせ情報を取得された可能性があるとしています。

影響を受けた可能性があるのは最大5社。対象となる問い合わせ情報は、延べ最大71万3,126件に上ります。

ただし、これは問い合わせ単位の延べ件数であり、実際の被害人数を示す数字ではありません。また、情報の外部流出については引き続き調査が行われています。

今回、不正アクセスを受けたのは、これらの企業が共通して利用していた外部サービスです。それぞれの企業の基幹システムが直接侵害されたという話ではありません。

一つのサービスの管理サイトへの不正ログインが、なぜ複数企業の情報にまで影響したのか。

この疑問が、今回の事件を理解するための重要な手掛かりになります。

10月2日夜、i-askの管理サイトで何が起きたのか

スカラコミュニケーションズの発表によると、不正アクセスが行われたのは、2026年10月2日（金）午後8時30分頃から翌3日（土）午前8時頃までの間です。

攻撃者は、i-askの管理サイトに不正ログインし、同社が管理するサーバー上に不正なプログラムを設置しました。

そして、同一サーバー上で稼働していた利用企業のシステム環境にあるデータベースから、問い合わせ情報を取得した可能性があります。

翌3日の朝、データベースの監視アラートが作動しました。

スカラコミュニケーションズは、このアラートを契機に調査を開始。同日午前8時頃に不正アクセスを遮断し、影響を受けた利用企業には、その日のうちに報告したと説明しています。

公表された経緯を時系列で整理すると、次のようになります。

日時	確認された出来事
10月2日（金）20時30分頃から	i-ask管理サイトへの不正ログイン。不正プログラムの設置
10月2日夜〜3日朝	複数企業のデータベースから問い合わせ情報を取得された可能性
10月3日（土）朝	データベースの監視アラートを契機に調査開始
10月3日（土）8時頃	不正アクセスを遮断
10月3日（土）中	影響を受けた利用企業へ報告
10月5日（月）	大和証券が情報漏えいの可能性を公表
10月6日（火）	シチズン時計、スカラコミュニケーションズが公表
10月7日（水）	損害保険ジャパンが公表

ここで注目したいのは、攻撃者が単に管理サイトへログインしただけではなく、サーバー上に不正なプログラムを設置していたという事実です。

そして、そのサーバー上には、複数企業のシステム環境が存在していました。

今回の事件では、管理サイトへの不正ログインと不正プログラムの設置が確認されています。一方、攻撃者がどのような方法でログインに成功したのか、不正プログラムをどのように設置したのかについては、まだ詳しい説明がありません。

また、不正ログインに使用されたアカウントが、サービスを利用する企業側のものだったのか、それともサービス提供者側の管理権限を持つものだったのかも明らかになっていません。

この違いは、攻撃者が複数企業のデータベースへ到達した経緯を考えるうえで重要です。

問い合わせ情報には何が含まれていたのか

今回、漏えいした可能性がある情報は、単なるFAQの質問と回答だけではありません。

企業の問い合わせ窓口を通じて寄せられた、利用者の個人情報を含むデータです。

公表されている内容を見ると、企業ごとに対象となる情報の種類も異なります。

大和証券では、氏名などの顧客情報に加え、口座番号を含む問い合わせ情報が対象となっています。

シチズン時計では、「シチズン」「ブローバ」「フレデリック・コンスタント」の各ブランドのWebサイトで受け付けた問い合わせ情報が対象です。氏名、住所、電話番号、メールアドレスなどのほか、利用者が問い合わせ本文に記入した内容も含まれる可能性があります。

損害保険ジャパンでは、事業者向けドライブレコーダーサービス「SMILING ROAD（スマイリングロード）」に関する問い合わせ情報が対象となりました。氏名や連絡先だけでなく、勤務先情報、ドライバーを識別するID、運転アラートに関する情報なども含まれる可能性があります。

つまり、同じ問い合わせ管理サービスを利用していても、そこに保存される情報は導入企業の業務によって異なるのです。

なお、スカラコミュニケーションズは10月6日時点で、本件に起因する情報の不正利用などの二次被害は確認されていないと説明しています。

ここまでが、現在公表されている事件の概要です。

では、そもそもi-askとはどのようなサービスなのでしょうか。

そして、一般の利用者がWebサイトで質問を調べたり、企業へ問い合わせたりする仕組みと、今回侵害されたi-ask管理サイトは、どのような関係にあるのでしょうか。

---

i-askとは何か――企業と利用者をつなぐFAQ管理サービス

私たちが企業のWebサイトで商品やサービスについて調べるとき、「よくある質問」や「お問い合わせ」というページを利用することがあります。

例えば、証券会社で口座開設の方法を調べたり、時計メーカーで修理の申し込み方法を確認したり、保険会社で保険金の請求手続きを調べたりする場面です。

こうした「よくある質問と回答」をFAQ（エフ・エー・キュー）と呼びます。英語の Frequently Asked Questions の略です。

「i-ask（アイアスク）」は、株式会社スカラコミュニケーションズが提供するFAQ管理サービスです。

企業が利用者へ情報を提供し、問い合わせに対応するための仕組みを、インターネットを通じて提供しています。

利用者が使う画面と、企業が使う管理サイト

i-askの仕組みを理解するうえで、まず知っておきたいのが、利用者が見る画面と企業の担当者が使う画面の違いです。

一般の利用者は、企業のWebサイトにあるFAQの公開画面から、質問と回答を検索・閲覧します。また、問い合わせフォームが設けられていれば、そこから企業へ質問を送ることもできます。

一方、企業の担当者は、管理サイトへログインして、質問と回答を作成・編集したり、寄せられた問い合わせを確認したりします。

例えば、時計メーカーが修理の申し込み方法を変更したとします。

担当者が管理サイトで案内内容を更新すると、利用者は公開画面から新しい修理方法を確認できるようになります。

利用者は公開画面で情報を探し、企業の担当者は管理サイトで情報を登録・管理する。

この二つの役割を支えているのが、i-askのようなFAQ管理サービスです。

管理サイトでは何ができるのか

i-askには、企業の問い合わせ対応を支えるさまざまな機能が用意されています。

例えば、質問と回答を作成・編集する機能です。商品やサービスの内容が変わった場合、企業の担当者は管理サイトから案内内容を更新できます。

また、PDFやOffice文書、画像などのファイルを添付する機能もあります。

時計メーカーであれば取扱説明書や修理申込書、保険会社であれば各種手続きの案内資料などを、利用者が確認できるようにする用途が考えられます。

さらに、問い合わせを受け付け、内容を確認・管理する機能も備えています。

利用者が問い合わせフォームに氏名、連絡先、質問内容などを入力した場合、企業はその情報を確認し、必要な対応を進めます。

つまり、FAQ管理サービスは単に質問と回答を掲載するだけでなく、利用者から寄せられる情報を扱う業務システムとしての役割も持っています。

管理サイトでは、担当者ごとに操作できる範囲を設定する権限管理も重要です。

例えば、FAQを閲覧する担当者、内容を編集する担当者、公開を承認する担当者といった具合に、役割に応じて権限を分ける運用が考えられます。

なぜ、異なる業種の企業が同じサービスを利用するのか

証券会社、時計メーカー、保険会社では、取り扱う商品やサービスが大きく異なります。

しかし、顧客からの質問に答え、必要な情報を提供するという業務には共通点があります。

i-askのようなサービスは、そうした共通業務に必要な機能を、さまざまな企業へ提供する仕組みです。

この提供方式は、ASP（エー・エス・ピー）やSaaS（サース）と呼ばれています。

企業は自社でFAQ管理システムを一から開発する代わりに、サービス提供者が用意した機能を利用できます。

そのため、システムの開発費用や維持管理の負担を抑えながら、利用者への情報提供や問い合わせ対応を充実させることができます。

また、担当者がブラウザーから管理サイトを利用できることも、日常業務を進めるうえでの利点です。

一方、サービス提供者は複数の企業に機能を提供するため、各企業の情報や利用権限を適切に管理する必要があります。

なお、複数企業が同じサービスを利用していることと、すべての企業の情報が一つのデータベースに保存されていることは、必ずしも同じではありません。情報の保存方法や企業ごとの環境の分け方は、システムの設計によって異なります。

図で見るi-askの仕組み

ここまで説明してきたi-askの基本的な仕組みを、次の図で整理しました。

一般利用者が使う公開画面と、企業の担当者が使う管理サイトは、それぞれ異なる役割を持っています。

公開画面は利用者が情報を探すための入口です。一方、管理サイトは企業が情報を登録・更新し、問い合わせに対応するための入口です。

そして、これらの処理を支えるのが、サーバーやデータベースなどのシステムです。

図1　i-askの基本的な仕組み（概念図）

図1：一般利用者向けの公開画面、企業担当者向けの管理サイト、両者を支えるシステムの関係を示した概念図です。実際の内部構成を再現したものではありません。

このように、i-askは一般利用者と企業の担当者が、それぞれ異なる画面から利用する仕組みになっています。

利用者にとっては、商品やサービスについて必要な情報を探すための便利な窓口です。

企業にとっては、FAQの更新から問い合わせ情報の管理まで、顧客対応を支える重要な業務システムです。

i-askは、企業と利用者の間に立ち、日々の情報提供と問い合わせ対応を支えるサービスなのです。

---

なぜ異なる企業が同時に影響を受けたのか――「よくある質問」を支えるi-askへの不正アクセスと海外類似事例から侵害経路を探る

海外での類似事案――ファイルのアップロード機能が侵入口になった

今回、i-askの管理システムへの不正アクセスに着目して調査を進めるなかで、ネット探検ラボは、海外で最近発生した類似の侵害事例に行き当たりました。

それは、2026年9月に米国のサイバーセキュリティー企業Huntress（ハントレス）が報告した、地方自治体や公園・レクリエーション施設などが利用するWeb管理サービスへの攻撃です。

この事例で注目したのは、攻撃者が正規の利用者登録機能を利用し、ファイルのアップロードを通じてサーバーへの侵入に成功していたことです。

さらに、侵入後にはデータベースへの接続情報を探索し、複数のサーバーへ攻撃を広げていました。

一般利用者向けの機能から侵入し、サーバー内部へ到達する。

この攻撃の流れは、今回のi-ask事案で侵害経路を検証するうえでも、重要な比較材料になると考えました。

ただし、両者の攻撃手法が同じだったと確認されたわけではありません。

攻撃者は、まず正規の利用者として登録した

Huntressの調査で興味深いのは、攻撃者が最初から管理者としてログインできたわけではなかったことです。

最初のサーバーでは、管理者向けログイン画面などへの攻撃を含め、複数の侵入方法を試していました。しかし、それらの試みは成功しませんでした。

そこで攻撃者が利用したのは、一般利用者向けに用意されていた新規登録機能でした。

攻撃者は正規の手続きで利用者アカウントを作成し、ログイン後に利用できるファイルのアップロード機能へ進みました。

この機能は、本来、利用者が必要な書類などをサービス側へ提出するためのものです。

ところが、攻撃者は通常の書類に代えて、不正なプログラムを含むファイルをアップロードしました。

つまり、正規の利用者に認められた操作が、サーバーへの侵入につながってしまったのです。

アップロードされたファイルが、サーバー上で動いてしまった

攻撃者が送り込んだのは、拡張子が「.aspx」のファイルでした。

ASPX（エー・エス・ピー・エックス）は、MicrosoftのWebサーバー環境などで使われる、サーバー側で処理を実行できる形式の一つです。

Huntressによると、攻撃者はこの形式のファイルを使って、Webシェル（ウェブシェル）と呼ばれる不正なプログラムを動作させました。

Webシェルとは、外部からWebサーバーへ命令を送り、サーバー上でさまざまな操作を実行するための仕組みです。

通常、書類や画像を受け付けるアップロード機能は、ファイルを保存するためのものであり、その中身をサーバーの命令として実行する必要はありません。

しかし、この事例では、アップロードされたファイルがサーバー上で実行できる状態になっていました。

ファイルを受け付ける機能と、プログラムを実行する機能の境界が適切に守られていなかったことが、侵害につながったのです。

攻撃者はサーバーの内部を調べ、データベースへ接近した

Webシェルを動作させた攻撃者は、サーバーの内部環境を調べ始めました。

Huntressの調査では、サーバー名や動作中のサービス、Webサイトの配置、設定ファイルなどを確認する操作が記録されています。

特に重要なのが、データベースへ接続するための情報を探していたことです。

Webサービスでは、サーバーがデータベースへ接続するための設定を保持している場合があります。

攻撃者はそうした設定ファイルを調べ、データベースの接続情報や認証情報を取得しました。

さらに、決済関連の情報を探す操作も確認されています。

この事例では、攻撃者がWebサーバー上で命令を実行できるようになった後、保存された情報やデータベースへアクセスを広げていく様子が具体的に記録されていました。

被害は一つのサーバーだけでは終わらなかった

Huntressが確認した侵害は、複数のWebサーバーに及びました。

攻撃者は最初のサーバーで成功した方法を、別のサーバーでも繰り返していました。

しかも、攻撃を重ねるにつれて操作が変化しています。

最初はさまざまな方法を試していた攻撃者が、次のサーバーでは効率よく侵入し、さらに別のサーバーでは不正ファイルの名前や更新日時を操作するなど、発見されにくくする工夫を加えていました。

また、いったん対処されたサーバーが十分な安全確認を終えないまま運用に戻された際には、攻撃者が再び侵入し、ログイン画面で認証情報を盗み取ろうとする仕組みまで設置していました。

ここで注目したいのは、特定のサーバーが侵害されたという事実だけではありません。

共通する機能や構造を持つサービスでは、一度成功した侵入方法が、別の利用環境でも通用する可能性があるという点です。

この海外事例から何が分かるのか

今回の海外事例では、一般利用者向けの登録機能とファイルアップロード機能が侵入の入口となり、その後、サーバー内部の調査やデータベースへのアクセスが行われていました。

一方、i-askの事案では、管理サイトへの不正ログインが公表されています。

したがって、現時点で両者の侵入経路や攻撃手法が同じだったと判断することはできません。

それでも、Webサービスの一つの入口からサーバーへ影響が及び、さらに内部の情報へアクセスが広がるという問題は、比較検証する価値があります。

特に、ファイルのアップロード機能がどのような権限で利用できるのか、保存されたファイルをサーバー上で実行できるのか、そして利用組織ごとの情報がどのように保護されているのかは、重要な確認事項となります。

海外の事例は、i-askへの攻撃手法を証明するものではありません。

しかし、今回の事案で何を確認すべきなのか、その手がかりを与えてくれます。

そこで次は、改めてi-askの仕組みに立ち戻り、管理サイト、ファイルの取り扱い、サーバー、データベースの関係を図面と照らし合わせながら、どの部分が侵害された可能性があるのかを検証していきます。

---

i-askのどこが侵害されたのか――海外事例から推定する攻撃経路

ここで、先ほど紹介したi-askの構成図に立ち戻ってみましょう。

今回、公表情報から確認できる重要な点は、管理サイトへの不正ログイン、サーバーへの不正プログラムの設置、そして複数企業のデータベースへの不正アクセスです。

では、攻撃者はどのようにして、そこまで到達したのでしょうか。

図2　i-askへの不正アクセス――推定される侵害経路

赤色で示した①管理サイト、②サーバー、③データベースは、今回の不正アクセスで注目する箇所です。管理サイトへの不正ログイン、サーバーへの不正プログラム設置、複数企業のデータへの不正アクセスという公表情報をもとに、そのつながりを推定しました。
本図はネット探検ラボによる概念図であり、実際のシステム構成や攻撃経路を再現したものではありません。

図面から考える三つの侵害箇所

① 管理サイト――攻撃者が利用した入口

最初に注目するのは、企業の担当者などがログインする管理サイトです。

不正ログインは公表されていますが、攻撃者がどのアカウントを利用したのか、認証情報をどのように入手したのかは明らかになっていません。

海外事例では一般利用者のアカウントから侵入しましたが、i-askでは管理権限を持つアカウントが悪用された可能性も考えられます。

② サーバー――不正プログラムが設置された場所

次に注目するのは、管理サイトの裏側で動作するサーバーです。

海外事例では、アップロードされた不正ファイルがサーバー上で実行され、攻撃者の操作を可能にしていました。

i-askでも不正プログラムの設置が公表されています。

ただし、ファイルのアップロード機能が悪用されたのか、別の方法で設置されたのかは不明です。

③ データベース――複数企業への影響が生じた場所

最後に注目するのは、問い合わせ情報を保存するデータベースです。

今回、複数企業の情報に不正アクセスが及んだことから、攻撃者が一つの管理機能やサーバーを足掛かりに、複数企業のデータへ到達した可能性があります。

ただし、実際のデータベース構成や、企業ごとのアクセス権限の設定は公表情報だけでは判断できません。

推定される攻撃の流れ

以上を整理すると、次のような経路が考えられます。

管理サイトへの不正ログイン → サーバーへの不正プログラム設置 → データベースへのアクセス

この流れは公表された事象の順序と整合しますが、各段階をつないだ具体的な手法まで確認されたものではありません。

特に重要なのは、管理サイトへのログインに成功した攻撃者が、なぜサーバー上へ不正プログラムを設置できたのかという点です。

ここに、今回の侵害を解明する鍵があると考えます。

一つの侵入口が、なぜ複数企業に影響したのか

今回の事案が示したのは、個々の企業のWebサイトがそれぞれ侵害されなくても、共通サービス側の侵害によって複数企業に影響が及ぶ可能性です。

海外事例では、正規の機能を悪用してサーバー内部へ侵入し、データベースへのアクセスを試みる攻撃が確認されました。

i-askでも同様に、管理サイトからサーバー、そして複数企業の情報へとアクセスが広がった可能性が考えられます。

ただし、これは海外事例を参考にしたネット探検ラボの推定であり、i-askで同じ攻撃手法が使われたと断定するものではありません。

今後の調査で最も確認したいのは、不正ログインに使われたアカウントの権限と、不正プログラムが設置された具体的な経路です。

この二つが明らかになれば、複数企業へ被害が波及した仕組みも、より具体的に見えてくるはずです。

---

最後に――海外で公開された攻撃手法と、日本で起きた不正アクセス

2026年9月10日、米国のサイバーセキュリティー企業Huntress（ハントレス）は、Web管理サービスへの不正アクセスを観測しました。そして9月21日、その侵入手法や攻撃者の行動を詳細に報告し、社会へ情報を公開しました。

それからわずか11日後の10月2日夜、日本ではi-askへの不正アクセスが発生しました。

ネット探検ラボでは、公表情報を比較した結果、この短い期間に発生した二つの事案には、極めて類似した技術的特徴があると判断しています。

ただし、これは海外事例を参考にした推定であり、i-askへの具体的な侵入手法が確認されたわけではありません。技術的な類似性を認めることと、同じ攻撃者による同一の侵害事件だと判断することは、まったく別の問題です。

ここで、サービス提供事業者に一つ問いかけたいと思います。

海外で発生し、攻撃手法まで公開されていた類似事例に、事前に着目していたのでしょうか。

もし、その情報を把握し、自社サービスとの比較検討や技術的な検証を実施したうえで、同様の侵害は発生し得ないと判断していたのであれば、その判断に至った根拠をぜひ知りたいと思います。

一方、こうした海外の侵害情報の収集や比較検討、技術的な研究が十分に行われておらず、それが今回の侵害を許す一因となっていたのであれば、その責任を重く受け止めていただきたいと考えます。

もちろん、現時点で同社がどのような情報収集や安全性の検証を行っていたのかは分かりません。また、海外事例を把握していれば今回の侵害を防げたと断定することもできません。

だからこそ、侵害の原因だけでなく、事前に何を把握し、何を検証し、どのような判断を下していたのかについても、可能な範囲で明らかにしていただきたいのです。

サイバー攻撃の情報を社会で共有する意義は、事件を知ることだけにあるのではありません。そこから得られた知見を、自らのシステムの安全性を検証するために活用してこそ、その価値が生まれます。

今回の事案が、その重要性を改めて認識する機会となり、得られた教訓が今後のサービスの安全性向上に有意義に生かされることを願っています。