タイムズカー、ローソン、NewsPicks。身近なサービスから情報漏洩やその可能性が相次いで公表され、「自分が登録した情報も含まれているのでは」と気になるニュースが続いています。134
その背景として聞こえてくるのが、「中国系のAIが、企業のセキュリティの穴を突いているのではないか」という話です。AIがコードを書き、複雑な作業まで進めるようになった今、攻撃にも使われているのでしょうか。
AIを使った攻撃は、すでに現実のものです。ただし、日本で相次ぐ漏洩の主因が中国系AIだと特定されたわけではありません。 AIが攻撃を後押ししていることと、個々の事件の原因が判明したことは、分けて考える必要があります。1011
大切なのは、AIの脅威を過小評価しないことと、事件の原因を証拠なしに決めつけないこと。その両方を押さえながら、2026年10月9日時点で分かっていることを整理します。
国内で何が起きている？ 最新の漏洩発表を確認する
まず、最近の発表を確認してみましょう。同じ「情報漏洩」のニュースでも、情報が外部に渡ったと確認された事案と、漏洩の可能性を調査している事案では、公表内容が異なります。
| サービス・確認した発表 | 公表されている内容 | 読み取る際の注意点 |
|---|---|---|
| タイムズカー／9月28日第2報、9月29日第3報（利用者向け第3報は10月1日更新） | 約660万アカウントの情報を第三者が取得。運転免許証画像などの本人確認書類が漏洩したアカウントは約160万件。12 | 約160万件は本人確認書類に関する内訳。約660万件と足し合わせる数字ではない。 |
| ローソン／10月8日発表 | ローソンIDの215万5,345件と、ローソンアプリ予約の26件で情報漏洩を確認。3 | IDと予約では対象項目が異なる。住所などは入力していた場合に対象となる。 |
| NewsPicks／10月8日に発覚した不正アクセスの案内 | 業務管理ツールへの不正アクセスにより、一部利用者の氏名、勤務先、連絡先などが漏洩した可能性。件数や影響範囲は調査中。4 | 「全利用者の漏洩が確定」ではない。カード関連で挙がっているのは名義や番号の下3桁・下4桁などで、番号全体とは区別する。 |
いずれも、ここで確認した発表からは、攻撃者が使ったAIを特定する記述は確認できません。各社の件数を足して「その人数の日本人が被害に遭った」とするのも不適切です。アカウント数と人数は同じとは限らず、サービス間の重複も分からないためです。
ニュースが並んだ日と、侵入された日は違う
ローソンの10月8日発表では、ローソンIDへの不正アクセスは9月12〜14日、アプリ予約への不正アクセスは9月17日だったとされています。それが10月7日の調査で判明しました。3
つまり、10月に発表が集中していても、すべての攻撃がその日に一斉に起きたわけではありません。公表日、発覚日、実際の侵入時期を分けないと、「急に同じ攻撃が始まった」と誤って受け取ってしまいます。
もちろん、発表が続いていること自体を軽視してよいわけではありません。ただ、ニュースの多さだけで、共通の攻撃者やAIまで特定することはできないのです。
「中国系AIの悪用」には、具体的な調査報告がある
10月7日、米セキュリティ企業CrowdStrikeは、韓国の金融機関への攻撃で、中国開発の侵入テスト用AIツール「ARTEX」と、主にDeepSeekが使われたと報告しました。GLMやGrokの併用もあり、攻撃者側のサーバーからAIの作業履歴や設定ファイルが見つかっています。5
攻撃者側に残っていた、AIの使用記録
「速い攻撃だからAIだろう」と推測することと、作業記録から道具を確かめることでは、証拠の種類が違います。この報告が重要なのは、後者の手がかりが得られた点です。
ARTEXはAIモデルそのものではなく、モデルと実行用の道具を組み合わせる仕組みです。記録にはClaude Codeも登場しますが、操作用アプリと、その裏で動くモデルは別です。 アプリ名だけでモデルの開発元まで決めつけることはできません。5
一方、AIを使った記録があっても、「AIがなければ、この被害は起きなかった」とまでは証明できません。AIが実際の攻撃工程に組み込まれていたことを示す調査として読む必要があります。
中国製の道具、中国語の使用、中国政府の関与は別の話
攻撃者は中国語話者で金銭目的の可能性がある、というのが同社の中程度の確信度による評価です。特定の攻撃グループへの帰属は確定していません。5
したがって、この報告から「中国政府が実行した」「DeepSeekの開発企業が情報を盗んだ」とは言えません。道具の開発国、使った人物、攻撃の指示者を同じものとして扱わないことが、噂を読む際の重要な線引きです。
AIが変えているのは、攻撃の規模と試行錯誤の速さ
AIの影響は、「人間には絶対に見つけられない穴を発見すること」だけではありません。英国の国家サイバーセキュリティセンター（NCSC）は、AIによって弱点の発見や悪用が、より容易に、速く、安価になると警告しています。6
これは、攻撃にかけられる人手と時間が変わる、ということです。以前なら手間に見合わず後回しにされていた対象にも、調査が及びやすくなると考えられます。
知識を教えるだけでなく、結果を見て次の作業を進める
エージェント型AIは、文章を返すだけでなく、計画を立て、道具を使い、作業を実行できます。セキュリティ分野でも、調査結果の解釈や次の作業の選択などに使われます。7
以前から攻撃を自動化するプログラムはありました。AIの違いを考える際は、単に処理を高速で繰り返すだけでなく、状況に合わせた分析や作業の組み立てまで支援する点を見ると分かりやすくなります。
米英など5か国のサイバーセキュリティ機関も、2026年6月の共同声明で、AIが攻撃への参入障壁を下げ、脆弱性の発見から悪用までの時間を短縮していると警告しました。8
600台超の機器が侵害された事例でも、入口は基本的な不備だった
Amazonの調査チームは2月20日、ロシア語を使う攻撃者が複数の生成AIサービスを利用し、1月11日〜2月18日に55か国超・600台超のネットワーク保護機器「FortiGate」を侵害したと報告しました。11
注目すべきなのは、FortiGateの脆弱性を突いた形跡は観測していない、という説明です。入口となったのは、外部に公開された管理機能、弱い認証情報、多要素認証のない状態でした。AIは、技術力が限定的な攻撃者による作業の大規模化を支えていました。11
対策の強い環境では攻撃が失敗し、より攻めやすい対象へ移ったことも報告されています。この事例が示すのは、AIがどんな防御でも破れることではなく、基本的な不備を探して悪用する効率が上がったことです。11
米国企業のAIも悪用されており、AI自身の失敗もある
Anthropicは2025年11月、Claude Codeを悪用したサイバー諜報活動を報告しています。同社によると、攻撃対象は約30組織で、侵入に成功したのはその一部でした。AIは助言だけでなく攻撃工程を担う一方、誤った認証情報を生成したり、公開情報を機密情報と誤認したりする失敗も起こしています。12
攻撃への利用は、中国系モデルに限った問題ではありません。同時に、AIが使われたというだけで、完全自律で正確無比な攻撃だったと受け取る必要もありません。
日本の情報漏洩とAIは、どこまで結び付けられるのか
海外での実例を踏まえたうえで、日本の調査に戻りましょう。ここで重要なのは、国内で確認された「侵入の手口」と、攻撃者がAIを使ったかという「作業手段」を分けることです。
既知の脆弱性だけでなく、APIや管理用システムも対象に
JPCERT/CCが10月8日に出した注意喚起では、主に次の攻撃が挙げられています。すべての被害が同じ手法・同じ製品によるものだとする発表ではありません。9
- 既知の脆弱性や管理不備の悪用：ソフトウェアの既知の弱点や、設定・バックアップファイルの不適切な管理など。
- API経由の不正操作：アプリの裏側にあるデータのやり取りや管理の窓口を、不正に利用するもの。
- 分析ツールMetabaseの脆弱性悪用：データ分析に使うシステムの弱点を突くもの。9
対象には利用者向けアプリだけでなく、従業員向けの管理システムや、社内で使う分析ツールも含まれます。表側のサイトが正常に動いているかだけでは、点検が足りないということです。9
「ログインできる人」と「その情報を見てよい人」は違う
APIは、アプリやシステムがデータや処理をやり取りする窓口です。そこで必要になるのが、「誰なのか」を確かめる認証と、「何をしてよいか」を確かめる権限の確認です。1314
例えば、自分の注文履歴を見られることと、別の利用者の注文履歴まで見られることは違います。会員として正しくログインしていても、他人の情報にアクセスできてしまえば問題です。また、画面から管理ボタンを隠すだけでは、裏側の窓口を守ったことにはなりません。サーバー側で、情報や操作ごとに権限を確認する必要があります。1314
これは問題を説明するための一般例であり、上で挙げた企業の侵入経路を再現したものではありません。
国内の専門家もAI利用を疑っているが、決め手となる記録は別
マクニカが10月7日に公開した国内事案の分析は、この点を明確に分けています。10月6日時点の情報として、一連の事案についてAI使用を断定できる操作記録（ログ）や痕跡は確認されていないとしています。10
その一方、執筆者は、サイト固有の機能や不備を広く調べる動きから、AI利用の可能性を強く見ています。ただし、これは専門家の見立てであり、使用モデルを特定した結果ではありません。10
したがって、現段階の受け止め方は、「国内でもAIの関与は十分に疑われる。ただし、今回確認した公表情報からは、どの事件に、どのAIが、どれほど関与したかまでは分からない」となります。
速さや件数は調査の手がかりにはなりますが、それだけでは使用モデルの証明にはなりません。日本の漏洩増加のうち、何割がAIによるものかを示す数字にも置き換えられないのです。
「AIが原因の漏洩」は、経路によって対策が違う
AIと情報漏洩の話には、攻撃者のAI利用だけでなく、利用者側のデータの扱いや、AIに与える権限の問題も混ざりがちです。次のように分けると、何を点検すべきかが見えてきます。
| AIが関わる経路 | 何が問題になるのか | 主な確認対象 |
|---|---|---|
| 攻撃者がAIを使う | 調査や攻撃の作業が効率化される。被害側がAIを使っていなくても起こり得る。 | システムの弱点、認証、アクセス権、監視。8 |
| 利用者が機密情報をAIに入力する | 顧客情報や業務資料が、組織の承認していない外部サービスへ渡る。 | 入力してよい情報、保存・利用条件、承認済みサービス。15 |
| AIが生成したコードに不備が残る | 機能は動いても、認証やデータの保護に問題があるまま使われる。 | コードのレビュー、権限の検証、公開前のテスト。16 |
| AIエージェントに広すぎる権限を渡す | 意図しない操作や侵害の影響が、接続先のファイルやシステムへ広がる。 | 読み書きの範囲、接続先、実行環境、人による承認。17 |
「中国系AIに情報を入力して漏れた」と「中国系AIを使う攻撃者に侵入された」は、まったく違う経路です。 後者なら、自分がそのAIを使わないだけでは対策になりません。
また、AIへ入力した情報が必ず一般公開されたり、必ず学習に使われたりするわけではありません。保存や利用の扱いはサービス・契約・設定によって確認する必要があります。「学習利用の可否」と「外部サービスへの送信を許可してよいか」も別の判断です。15
AIで作ったシステムについても、今回の国内事案が「AIの生成コードのせいだった」と確認されたわけではありません。英国NCSCが指摘するように、認証や顧客データなどを扱うコードでは、その用途のリスクに応じてレビューや検証を行うことが重要です。16
「どこの国のAIか」だけでなく、誰が、どんな情報を渡し、どの権限で使っているのかまで確認すると、対策の焦点を合わせやすくなります。
利用者とサイト運営者が、いま確認したいこと
事件の全容が判明するまで、何もできないわけではありません。利用者は自分の情報とアカウントを守ること、運営者は侵入や情報取得につながる不備を減らすことから始められます。
利用者は、漏れた情報と二次被害を分けて確認する
まずは利用しているサービスの公式発表で、自分が対象か、どの情報が漏れたのかを確認します。そのうえで、次の行動を優先してください。
- メールやSMS内のリンクだけで判断しない。 「漏洩したので本人確認が必要」と届いても、公式アプリや普段使う公式サイトから確認します。パスワードや認証コードを返信で渡してはいけません。418
- 使い回しをなくし、利用できる場合はパスキーや多要素認証を使う。 パスワードの流出が分かった場合は、そのサービスと同じパスワードを使っているサービスを見直します。18
- 身に覚えのないログインや請求は、公式窓口へ相談する。 偽サイトにパスワードやカード情報を入力してしまった場合も、変更やカード会社への連絡など、その情報に応じた対応を取ります。18
ただし、多要素認証は主に自分のアカウントへの不正ログインを防ぐ対策です。企業のサーバー側が侵害され、保存データを盗まれる経路まで、利用者の設定だけで防げるわけではありません。
利用者ができることと、企業側が責任を持って行うべき対策は分けて考える必要があります。
運営者は「ちゃんと動く」だけでなく「できてはいけない操作」を確かめる
AIでサイトやツールを作る人にも重要なのは、正常に動く画面だけで完成と判断しないことです。例えば、権限のない利用者には情報を返さない、一般会員には管理機能を使わせない、といった拒否すべき動作の確認も必要になります。1316
優先したいのは、次の3点です。
- 管理機能と裏側のAPIまで洗い出す。 不要な外部公開を減らし、機能・データごとのアクセス権をサーバー側で確認します。一般向けサイトとは別の管理画面や、古いAPIも点検対象です。1314
- 更新、権限、保存データを見直す。 修正済みの更新を適用し、必要以上の権限を与えないこと。不要になった接続用の認証情報を無効化できるようにし、保存期間や業務上の必要性を確認して、不要な個人情報を残さないことも大切です。89
- 記録と対応担当を用意する。 不審な操作や情報取得を調べられるログを残し、異常時に誰が確認し、連絡し、止めるかを決めます。点検を「診断を受けたことがある」で終えないようにします。14
AIエージェントには、作業に必要な範囲のファイルや接続先だけを許可します。試作環境と本番環境を分ける、閲覧だけの仕事には書き込み権限を渡さないなど、実行環境と権限で制限することが重要です。「危険なことはしないで」という文章の指示だけを、安全対策の代わりにはできません。17
防御側のAIにも期待できるが、導入だけで解決はしない
AIは、防御側の脆弱性発見や分析にも使えます。ただし、「攻撃がAIなら、防御もAIに任せればよい」とは限りません。NCSCは9月21日、防御の自動化には、対処によって正規の業務を壊さないことの確認や、組織側の準備が必要だと説明しています。19
例えば、怪しい接続を見つけることと、それを止めても顧客の業務に影響しないと判断することは別です。便利な防御AIの登場を待つのではなく、今あるシステムの管理と、対応できる体制の整備を進める必要があります。19
まとめ｜AIの脅威と、個々の事件の原因を分けて考える
AIの攻撃利用は現実の問題であり、日本の専門家も、一連の漏洩への関与を強く疑っています。一方で、日本の被害を一括して「中国系AIが原因」と断定するには、証拠が足りません。1012
注目すべき変化は、これまでなら時間や人手が必要だった弱点の調査が、より速く、広い範囲へ及ぶようになることです。目新しい攻撃ばかりではなく、認証や設定、アクセス権の基本的な不備を放置する危険が大きくなっています。6
情報漏洩のニュースを見たら、まず「何が漏れたか」「どこまで確認されたか」「原因の根拠は何か」を分けて読む。AIを使って開発・運営する側なら、便利に動くことに加えて、許可していない操作を確実に拒めるかを確かめる。
AIを怖がるか、信じるかの二択ではありません。起きている変化を正しく理解し、守るべき場所を具体的に点検することが、いま必要な対応です。
参考資料・出典
情報確認日は2026年10月9日（日本時間）。被害件数や調査状況は各発表時点のもので、その後の続報で変わる可能性があります。記事中の一般例は、特定企業のシステム構成や攻撃経路を再現したものではありません。
- タイムズモビリティ「タイムズカーWebシステムへの不正アクセスに関する調査結果および今後の対応について（第2報）」、2026年9月28日。約660万アカウント、第三者による取得の確認、調査状況。原文を確認する
- タイムズカー「『タイムズカーWebシステム』への不正アクセスに関する調査結果および今後の対応について（第3報）※追記あり」、2026年9月29日公表、10月1日更新。本人確認書類の漏洩が確認された約160万アカウントと利用者への案内。原文を確認する
- ローソン「第三者による不正アクセスに伴う個人情報漏えいに関するお詫びとお知らせ」、2026年10月8日。サービス別の漏洩件数、情報項目、9月の不正アクセスと10月の発覚。原文を確認する
- NewsPicksヘルプセンター「【重要】NewsPicksのお客様の個人情報漏洩の可能性に関するお詫びとお知らせ」、2026年10月8日に発覚した事案の案内（10月9日確認）。不正アクセス、漏洩の可能性がある項目、調査中の範囲、利用者への注意。原文を確認する
- CrowdStrike, Ashley Campion, “Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance”, 2026年10月7日。攻撃者側のAI利用記録、ARTEXと各モデル、攻撃者に関する確信度・帰属の限界。原文を確認する
- NCSC, Richard Horne, “Retaining defensive advantage in the age of frontier AI cyber capabilities”。2026年4月15日付Financial Times掲載の書簡を基にした公式記事。AIによる弱点の発見・悪用の低コスト化と防御側の対応。原文を確認する
- NCSC, “Frontier AI: what you need to know”。2026年10月9日確認。エージェント型AIの性質、攻撃・防御への影響。原文を確認する
- NCSCほか、Five Eyesのサイバーセキュリティ機関による共同声明 “The AI shift in cyber risk: why leaders must act now”, 2026年6月22日。攻撃への参入障壁、速度、脆弱性の発見から悪用までの時間に関する評価。原文を確認する
- JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」、JPCERT-AT-2026-0030、2026年10月8日。攻撃類型、情報の限界、API・管理機能・データ保持等の対策。原文を確認する
- マクニカ セキュリティ研究センター「相次ぐWEBシステムからの情報漏洩事案について」、2026年10月7日（10月6日時点の情報）。国内事案の調査・ログ分析とAI使用に関する見立てを区別した報告。原文を確認する
- Amazon / AWS Security Blog, CJ Moses, “AI-augmented threat actor accesses FortiGate devices at scale”, 2026年2月20日。55か国超・600台超の侵害、認証や管理機能の問題、AI利用と攻撃の限界。原文を確認する
- Anthropic, “Disrupting the first reported AI-orchestrated cyber espionage campaign”, 2025年11月13日。Claude Codeの悪用、標的と侵入成功の区別、AIの誤りや制約に関する同社の調査報告。原文を確認する
- OWASP, “OWASP Top 10 API Security Risks – 2023”。オブジェクト・機能単位の権限確認、認証、APIの管理など。2023年版を参照。原文を確認する
- OWASP Cheat Sheet Series, “REST Security Cheat Sheet”。各APIでのアクセス制御、管理機能の公開制限、監査ログ等。2026年10月9日確認。原文を確認する
- NCSC, “The hidden risks of shadow AI”, 2026年9月7日。未承認AIサービスへの業務情報の入力と、データ管理上のリスク。原文を確認する
- NCSC, “The ‘vibe coding spectrum’ approach to AI-assisted software development”, 2026年6月18日。用途のリスクに応じた生成コードのレビュー・検証。原文を確認する
- NCSC, “Managing the cyber risk of agentic AI”, 2026年8月20日。エージェントの権限、接続先、実行環境の隔離、監督。原文を確認する
- IPA「インターネットサービスへの不正ログインによる被害が増加中」、2025年8月28日。パスワードの使い回し防止、パスキー・多要素認証、フィッシングへの対応。原文を確認する
- NCSC, Dave Chismon, “One does not simply defend agentically”, 2026年9月21日。防御の自動化に必要な検証と組織的な課題。原文を確認する
コメント