被害の大きさは、件数だけでは判断できない
流出が相次ぐと、経営会議でも件数の多さが話題になります。しかし、メールアドレスの一覧と、本人確認書類の画像、商談の記録、問い合わせの録音では、同じ一件でも含まれる情報と悪用された場合の影響が異なります。自社で問うべきなのは、保有する情報の種類と、その情報を一度に取得できる範囲です。
確認された事実として、タイムズモビリティは第2報で約660万アカウントの情報流出、第3報で約160万アカウント分の本人確認画像の漏えいを公表しています。ここからAtlas Supportが重視するのは、本人確認のために集めた画像を、いつまで、誰が、どの権限で扱うかという保有とアクセスの設計です。
今回のレポートは、2026年9月29日〜10月12日の公表・更新情報を中心に、以前の参考事例を含む40掲載項目を整理しています。続報や関連公表も含むため、独立した40事故や全国の発生頻度を示す標本ではありません。公表対象規模の「約5,770万件相当」も、人・件・アカウント等の混合延べ値で、実際の漏えい総件数ではありません。
侵入の入口と、被害を広げる条件を分ける
侵入の原因が分かっても、被害の大きさまでは説明できません。公開アプリの弱点、盗まれた認証情報、委託先の端末という入口に加え、接続先のデータ、付与された権限、検知までの時間を調べる必要があります。以下は公表事実と、そこから導くAtlas Supportの点検上の示唆を分けた整理です。
| 事例 | 公表された事実 | Atlas Supportの考察 |
|---|---|---|
| infoQ（10月5日公表） | ソフトウェアの脆弱性を悪用した情報の持ち出しと、ポイントの不正交換を確認。 | 修正の有無と併せて、情報取得から金銭操作に進める権限や監視を確認する。 |
| 楽天ドライブ（10月6日時点） | 管理用アカウントの認証情報が不正取得され、保存データ等を取得・閲覧された。 | 管理権限の範囲とデータ取得ログを調べる。認証情報の入手経路は公表内容から断定しない。 |
| 第一興商（10月8日公表） | 委託先の端末がマルウェアに感染。一時保管データに漏えいのおそれがあるが、外部流出は未確認。 | 自社の本番システムに加え、委託先へ渡したデータの複製、保管期間、削除の記録を確認する。 |
入口が未確認でも、点検は進められる
経路が未公表の事例を、既知の脆弱性や特定の攻撃集団に結び付けると、対策の範囲を誤るおそれがあります。今回の40掲載項目には、Atlas Supportの分類で手法未公表とした19項目が含まれます。レポート内の暫定分類は調査の仮説であり、各社が認定した侵入経路ではありません。
IPAの10月9日の注意喚起も、特定の製品やサービスの脆弱性を狙った攻撃とは断定していません。外部公開アプリ、利用している外部サービス、保有データを洗い出し、ログやアカウントの異常を確認するよう求めています。
10月13日付の技術追補として、NICT LETTICEの注意喚起も確認しました。NICTが確認したA2B攻撃は、公開Androidアプリを解析してAPIの接続先や仕様を調べ、その情報を使って接続先サーバーを狙う手法です。アプリ自体に脆弱性がなくても、サーバー側の認証・認可や入力値検証に不備があれば被害につながり得ると説明しています。
この技術情報から、掲載40項目の侵入経路がA2B攻撃だったとは判断できません。NICTはAIによる解析・探索の効率化にも注意を促していますが、確認されたA2B攻撃でAIが使われたとは示していません。AI使用が確認された事例として数えず、10月12日時点の集計にも追加しません。
自社の点検では、アプリの更新状況だけでなく、接続先API、利用者が読めるデータの範囲、旧版・検証環境、情報取得ログまで対象にすることを提案します。アプリの画面で操作できないことと、サーバーが権限外の要求を拒否することは別だからです。これは注意喚起を踏まえたAtlas Supportの点検上の提案です。
Atlas Supportの提案は、点検結果を「確認済み・未確認・証跡なし」に分けて管理することです。ログが残っていない状態を、異常がなかった状態と同じにしない。記録を確認できる担当者と期限を決めるだけでも、次の判断に必要な情報が明確になります。
AIの評価結果を、自社への侵入確率に置き換えない
英国AI Security Instituteの評価では、隔離されたサイバー課題でAIが一定の確率で完了できる作業の長さを、専門家の所要時間で測っています。報告された約4.7か月という倍増期間は、特定の課題群と評価条件に基づく推計です。将来も同じ伸びが続くことや、あらゆる実務で人を上回ることを意味しません。
AnthropicのGLM-5.3評価にある50/410も、既知の脆弱性を対象とする隔離環境での攻撃コード作成の試行結果です。企業410社のうち50社に侵入した、という数字ではありません。今回の国内事例でAIが使われたかどうかも、これらの研究から判断できません。
将来リスクとして考えるべきなのは、探索や試行の効率が上がれば、修正の遅れや放置した権限が利用される機会も増え得ることです。Atlas Supportは、経営指標としてAI製品の導入数よりも、問題を発見してから修正・遮断するまでの時間、更新できていない資産、権限を棚卸しした範囲を重視します。これは評価研究を踏まえた運用上の提案であり、対策効果の実測値ではありません。
AIを守る仕組みを、通常の業務設計につなぐ
Atlas Supportの考察として、防御へのAI利用はログの整理や異常候補の抽出から検討できます。ただし、遮断や削除の判断をどこまで任せるかは別に決める必要があります。誤検知で重要な業務を止めた場合に、誰が解除し、どう戻すのかまで設計します。
自社がAIエージェントを使う場合も、検索・要約の権限と、外部送信・更新・削除の権限を分けます。NCSCのエージェント型AIに関する解説やOWASP LLM Top 10は、AIが扱う外部情報、機密情報、ツールの権限を考える手掛かりになります。Webページや添付資料に紛れた指示が、業務上の命令として実行されないかを検証します。
データ管理では、原本だけでなく、文字起こし、要約、検索用の索引、委託先に残る複製まで所在と期限を確認します。大量の記録をAIで整理しやすくなるほど、漏えい後に情報を関連付けられるリスクも考慮すべきです。これは将来リスクとしての考察であり、今回の国内事例で実際にAI解析による悪用が起きたと確認したものではありません。
不要なデータを減らす際も、事故調査に必要な証拠や業務・法令上保持すべき記録まで一括削除する運用にはしません。保存の責任者と削除の条件を決め、事故発生時には証拠保全を優先できる手順を用意します。
経営者が診断前に決めたい、三つのこと
診断を発注しても、対象が曖昧なままでは、重要な業務や委託先が確認範囲から漏れることがあります。Atlas Supportでは、最初に次の三点を整理することを提案します。
| 決めること | 担当者と確認する問い | 残すもの |
|---|---|---|
| 守る業務とデータ | 停止の影響が大きい業務は何か。原本・複製・AI用データはどこにあるか。 | 対象資産、データの所在、責任者の一覧 |
| 診断の許可と範囲 | 自社が許可できる環境か。委託先の同意、検証用データ、停止条件はそろっているか。 | 対象・除外範囲、実施時間、連絡先、許可の記録 |
| 改善と復旧の条件 | 誰がいつまでに修正するか。残るリスクを誰が判断するか。復元を実際に試せるか。 | 優先順位、担当者、期限、再検証と復旧演習の記録 |
自社で優先して確認する範囲を整理する
公開アプリと接続先API、外部サービスとID、保有データを起点に、診断と改善の進め方を検討します。お問い合わせは任意で、PDF取得の条件ではありません。
調査資料と出典について
本記事は2026年10月12日調査のAtlas Supportレポートを踏まえた独立した考察です。本文で挙げた企業発表・IPA・AI評価研究・防御指針は2026年10月13日に再確認し、同日付のNICT LETTICE資料を技術追補しました。40掲載項目と集計は10月12日時点を維持し、以後の訂正や続報を網羅するものではありません。
PDFには公表資料40項目、分類と集計の注意点、AI評価の条件、NICTのA2B攻撃への注意喚起と参考文献を収録しています。分類は公開資料に基づくAtlas Supportの整理であり、個別企業への技術調査を実施した結果ではありません。