FAQシステム「i-ask」最大71万件の問い合わせ情報が漏えいした可能性、氏名・メールアドレス・問い合わせ内容で何をされるのかまとめました

2026年10月6日、株式会社スカラコミュニケーションズは、同社のFAQシステム「i-ask」が第三者による不正アクセスを受けたと公表しました[1]。同社によると、第三者がi-askの「管理サイト」に不正にログインし、不正なプログラムを設置したうえで、同じサーバー上で動いていた利用企業（最大5社）のデータベースから、お問い合わせ情報を取得した可能性があるとしています。

件数は最大713,126件です。ただしこれは問い合わせ単位の延べ件数で、同じ人の複数回の問い合わせを重複して含み、実際の人数は名寄せ中としています[1]。項目は氏名、メールアドレス、お問い合わせ内容等で、利用企業によって異なります[1]。公表時点で二次被害は確認されていないとしていますが、それで安心とは言い切れません。

利用企業の側も、それぞれ自社で公表しています。報道によると、大和証券（10月5日）、シチズン時計（10月6日）、損害保険ジャパン（10月7日）、オリックス生命保険（10月8日）などです[10][11]（※報道で確認。各社の一次発表は未確認）。このうちシチズン時計は、各ブランドのお問い合わせフォームの受付に使っていたシステムで、約10万名分の氏名・住所・電話番号・メールアドレス等が対象になるとしています[2]。

「自分が送った問い合わせで、これから何をされるのか」。「会社として、どこから手を打てばよいのか」。この記事では、その2つに答えるために、漏れた可能性のある情報が悪用されうる場面と、i-askのようなサービスで認証が使われる場所を、公開情報から整理しました。事故の経緯は短くとどめます。

この記事の要点

• 過去に企業へ送った問い合わせの中身を踏まえた、「先日のお問い合わせの件で」といった偽メールや偽SMS、電話が届きやすくなります。
• 問い合わせ欄に口座番号やカード番号を書いた覚えがある人は、明細や取引の確認をしておくと安心です。
• 会社側がまず見直したいのは、管理サイトに入る人の確認のしかたと、ログインした後にできる操作の範囲です。

なお、本記事は公表文や製品ページなど、公開情報だけをもとにしています。管理サイトのログイン画面を実際に試すような調査はしていません。確認できなかった点は「確認できず」と書いています。

何が起きたか（要約）

スカラコミュニケーションズの公表文[1]と、親会社の株式会社スカラの開示[7]によると、概要は次のとおりです。

利用企業の例として、シチズン時計の公表[2]では、シチズン、ブローバ、フレデリック・コンスタントの各ブランドのお問い合わせフォームが対象です。お問い合わせ内容の欄に銀行口座情報やクレジットカード情報等を書いていた場合は、それも漏えいした可能性があるとしています。同社のECサイトや会員制サービスへのアクセスは確認されていないとし、本件システムの利用は2026年10月中旬に終了する予定としています[2]。

漏れた可能性のある情報で、何ができてしまうか

今回の特徴は、氏名や連絡先に加えて「お問い合わせ内容」が含まれる点です。誰が、どの会社に、何について困って連絡したのかが、ひとまとまりで分かります。

スカラコミュニケーションズは、同社や利用企業を装った不審なメールや電話に注意し、URLや添付ファイルを開かないよう呼びかけています[1]。シチズン時計もメール・SMS・電話への注意を呼びかけています[2]。

i-askで認証が使われる場所

今回の事故は、一般の利用者のログインではなく、管理サイトへのログインで起きました。そのため、認証が使われる場所は、利用企業の担当者やサービスの運用者が入る画面を中心に並べました。製品ページとよくある質問で確認できた範囲です。

※「狙われやすさ」は、公開情報をもとにした当社の見立てです。実際のしくみを確かめたものではありません。

i-askはSaaS（ASP）形式で提供されています[6]。今回は、1つの管理サイトへの不正ログインが入口となり、同じサーバー上の最大5社に影響が及んだ可能性があるとされています[1]。管理者のログイン1つの重みが、1社分にとどまらなかった点が、この事故の大きな特徴です。

会社がまず見直すとよい所（優先順）

公表文では、今後の対策として「管理者認証の強化（多要素認証の導入等）」「環境間の分離」「監視体制の強化」「第三者による定期的な脆弱性診断」が挙げられています[1]。認証の観点からは、次の順で見直すことが考えられます。

1. 管理サイトに入る人を、パスワードだけで確かめない。今回の事故は管理サイトへの不正ログインで起きました[1]。公表文にある多要素認証の導入は、ここを固める対策にあたります。運用者と利用企業の担当者の両方が対象になるかを確かめることが考えられます。

2. ログインした後にできる操作を絞る。ファイルの設置や設定の変更など、影響が大きい操作には、その場でもう一度本人を確かめる考え方があります。ログインが一度破られても、被害を広げにくくなります。

3. 窓口での本人確認から、今回の項目を外す。利用企業の側でも、氏名・メールアドレス・問い合わせの履歴が合えば本人とする扱いになっていないか。仕組みを作り直さなくても、運用の見直しから始められます。

認証の観点から：「番号を知っている」と「その電話を持っている」は違う

管理者のログインは、利用者のログインより人数が少ない分、見落とされがちです。けれども今回のように、1つの管理者ログインが複数の会社のデータにつながることがあります。

管理者を確かめる方法で分けて考えたいのは、「知っていること」と「持っていること」の違いです。パスワードは、漏れたり推測されたりすれば、第三者も「知っている」状態になります。電話番号も、今回のシチズンの例のように漏れれば第三者に知られます。一方で、その人が実際に持っている電話回線は、情報が漏れても変わりません。

SMSで届く確認コードも「持っているか」を確かめる方式の一つです。ただし米国NISTのガイドラインは、SMSなど電話網を使う確認方法を「制限付き（restricted）」の手段と位置づけています[8]。禁止ではありませんが、SIMの切り替えや電話番号の乗り換え（ポーティング）といったリスクを踏まえ、それだけに頼りきらない設計が求められています。

当社Infront Securityの電話番号認証は、利用者がワンタップで指定の番号に発信し、その発信者番号と端末の情報をサーバー側で照合して本人を確かめます。電話番号を知っていても、その回線から発信できなければ認証は通りません。偽サイトは利用者の電話回線を持っていないため、フィッシングに耐性のある方式です。

管理サイトのログインを壊さずに「持っているか」の確認を足す方法については、お気軽にご相談ください。

お問い合わせはこちら