お問い合わせ

Blog

【2026年】国内の情報漏洩・個人情報流出事例まとめ｜生成AI時代のサイバー攻撃の原因と対策

出稿 改訂

国内473件を調査。生成AI時代の情報漏洩をまとめてみた。日本地図と虫眼鏡を配した紙コラージュ。

「クラウドは全部ハッキングされちゃうんじゃないの？」

優秀な情シスほどAIハッキングに戦々恐々だ。
見てしまったのだ...しらみ潰しに穴を探すLLM特有のアクセスログを。

御社のWAFのログにも残っていないだろうか？
是非確認してほしい。

我々は注意喚起の為、国内で公表されたサイバー攻撃473件を、1件ずつ原因まで調査した。
その勢いをご覧頂きたい。

2026年に国内で公表された473件の所在地

2026.01.01

再生すると、公表順に地図上で発火する全473件

週ごとの公表件数

公表事案の所在地473 / 473件

公表順の一覧

各事案を、被害6類型・侵入経路11区分・防止可能性4段階で分類した。

掲載した事案について、確認した公表資料に攻撃者の生成AI利用を明記したものはなかった。利用されなかったと断定することもできない。件数の推移だけでは、攻撃者が使った道具は分からない。

「どんな手法でやってくる？」「どう対策すべき？」

本稿では、

  • 月ごとの件数の推移と9月24日以降に生じた変化、
  • 生成AIをめぐる背景、
  • 速度、規模、ゼロデイ攻撃、
  • AI特有のハッキングスタイル/プロンプトインジェクションなど、

標的となりやすい12類型と、従来の対策だけでは防げなくなる7つの理由を扱ったうえで、
優先順位を付した10項目の対策を示す。

情報漏えい、業務停止、改ざん・乗っ取り、金銭の窃取、資源の悪用・踏み台、閲覧障害を対象とした。システムへの侵入を伴わず、メールやSNSで経営者になりすまして送金させる22件も含む。情報漏えいの類型には、流出が確定した事案に加え、漏えいの可能性を調査中の事案も含めている。

月ごとの公表件数の推移

月ごとの公表件数（2026年）1月29件 → 9月76件
  1. 291月
  2. 252月
  3. 463月
  4. 404月
  5. 335月
  6. 576月
  7. 617月
  8. 688月
  9. 769月
  10. 3810月

9月の件数は1月の2.6倍だ。一直線に増えたわけではない。3月に46件まで増えたあと、5月には33件に減り、6月から9月までは毎月増えている。10月は8日までの途中集計で、38件を掲載した。月全体の件数とは比較できない。

被害の類型別の内訳

被害の類型別の件数全473件
情報漏えい
226件48%
業務停止
72件15%
改ざん・乗っ取り
87件18%
資源の悪用・踏み台
52件11%
金銭の窃取
26件5%
閲覧障害
10件2%

1件で複数の被害が出た事案は、主な被害で分けた。

被害の類型226件

情報漏えい

顧客・会員・従業員などの情報が外部から閲覧・取得された事案。漏えいのおそれが公表されたものも含む。

該当事例226件を一覧で見る

被害の類型72件

業務停止

社内システムや業務サービスが使えなくなり、業務に支障が出た事案。

該当事例72件を一覧で見る

被害の類型87件

改ざん・乗っ取り

ウェブサイトの書き換えや不正な転送、SNSアカウントの乗っ取りなどが起きた事案。

該当事例87件を一覧で見る

被害の類型52件

資源の悪用・踏み台

アカウントやシステムが、不審メールの送信などに悪用された事案。

該当事例52件を一覧で見る

被害の類型26件

金銭の窃取

偽の送金指示や不正な交換・購入などにより、金銭やポイントを奪われた事案。

該当事例26件を一覧で見る

被害の類型10件

閲覧障害

DDoSなどにより、ウェブサイトの閲覧やアクセスに支障が出た事案。

該当事例10件を一覧で見る

公表が集中した92件の原因

侵入経路の区分別の件数9月11日〜10月8日の92件
フィッシング・端末の乗っ取り
8件
機器・ソフトウェアの脆弱性
6件
正規認証情報の悪用
11件
自社実装の脆弱性
7件
設定・管理の不備
2件
委託先・外部サービス経由
3件
人を欺く手口（送金・操作の誘導）
1件
ランサムウェア（侵入経路未公表）
5件
原因未公表
49件

この92件を一覧で見る

473件のうち92件は、9月11日から10月8日までの28日間に初めて公表された。うち53件は東京都内の組織だ。公表日と攻撃の発生日は一致しない。ムラウチドットコムとニチレイの9月の発表は続報なので、本稿では7月の初報日に計上した。ジェイアール東海髙島屋も5月8日の初報で数えている。

この92件のうち、侵入経路が公表された38件は7つの区分に分かれる。次のように異なる手口を含んでおり、同じ攻撃者や共通の原因によるものかどうかは、公表資料からは判断できない。

  • VPN機器の脆弱性
  • 画像アップロード機能の脆弱性
  • 権限の設定不備
  • 認証機能の設計不備
  • GitHubの認証情報の流出
  • クラウドサービスのアカウントへの不正ログイン
  • メールアドレスの登録有無を判定できる機能の仕様の不備
  • 偽の警告画面による遠隔操作
  • 委託先の従業員端末のマルウェア感染
  • 電話で聞き出した本人確認情報によるなりすましログイン

次に、9月24日以降の公表件数と被害の内訳を見る。この比較も、公表された時期を基準にしたもので、攻撃の発生時期を比べるものではない。

9月24日以降の15日間に生じた変化

9月23日までとの比較

15日間の公表件数

1.7倍

41件7月24日〜8月7日
71件9月24日〜10月8日

情報漏えいの割合

1.7倍

43%9月23日まで
75%9月24日以降

9月24日以降の71件を一覧で見る

比べた相手は7月24日から8月7日まで。9月23日までで、公表が最も多かった15日間だ。増加は情報漏えいに集中していて、15日間の件数は、9月23日までの最多24件に対して53件ある。変わったのは件数だけではない。次の指標にも変化が出ている。

指標9月23日まで（402件）9月24日以降（71件）
侵入経路を公表していない事案の割合40%（162件）68%（48件）

侵入経路未公表の割合は、「原因未公表」と「ランサムウェア（侵入経路未公表）」の2区分を合計した。発生日と検知日をそろえて比較できる資料がないため、攻撃から公表までの日数は集計していない。

71件には、一般の利用者が会員登録をして使う、次のようなウェブ上のサービスも含まれる。

  • カーシェアリング
  • レンタカー
  • 宿泊および飲食の予約
  • チケット販売
  • 宅配
  • ポイント
  • 飲食店や小売店の会員アプリ
  • アンケートサイト

検知日は、攻撃が始まった日とは限らない。公表や検知が短期間に集中していても、攻撃そのものが同時期に起きたとは判断できない。

この71件について、AIエージェントによる並列攻撃だと確認できる資料はない。海外で報告されているAIエージェントを並列に動かす攻撃は、「LLMによるサイバー攻撃への影響」の章の末尾で紹介する。

LLMによるサイバー攻撃への影響

生成AIの攻撃能力を懸念し、提供範囲や開発速度を見直す動きがある。2026年のAI開発企業の発表を確認する。ただし、これらの動きは、国内で防御が不可能になったことを示すものではない。

4月7日

Anthropicが最上位モデルの提供を限定

Anthropicは、新しいモデル「Claude Mythos Preview」を一般には提供せず、防御を目的とする組織だけに提供する枠組み「Project Glasswing」を発表した。同社によれば、このモデルは主要なOSとブラウザから数千件の未知の脆弱性を見つけた。27年間見つからなかったOpenBSDの脆弱性も、その中にある。脆弱性の発見と悪用で、AIは最も熟練した者を除くすべての人間を上回りうる水準に達した。同社はそう説明している。

6月10日

保護機能を実装したモデルの一般公開

後継の「Claude Mythos 5」に保護機能を付けた「Claude Fable 5」が、一般に公開された。

6月12日

米政府の指令による提供の全面停止

公開から3日後、米政府の輸出規制指令を受けて、Anthropicは両モデルの提供を全面的に止めた。報道によれば、政府は保護機能を回避する手法を把握したとしている。同社はこの判断に反論している。

7月

OpenAIの研究モデルが他社のシステムへ侵入

OpenAIの社内で、サイバーセキュリティ評価の最中に起きた。一般公開の予定がない研究モデルが、インターネットから隔離するための管理策をすり抜け、共有基盤の脆弱性を突いてHugging Faceのシステムへ到達した。人間が侵入を指示したわけではない。報道によれば、互いに隔離されているはずだった約1,200のエージェントが無許可の経路で連絡を取り合い、うち700が侵入に関わった。

8月26日

OpenAIが侵入事案の報告書を公表

OpenAIは、7月の事案の報告書を公表した。同社はこの事案を、自社と世界全体への「警鐘」と位置づけた。監視と安全対策の水準を保つため、必要ならモデルの能力向上の速度を調整するとも表明している。

9月1日

後継モデルの公開

Anthropicは後継の5.1を公開した。Mythosを使えるのは、審査を通った専門家だけ。一般向けのFableは、脆弱性の発見には使えるが、攻撃コードの作成には使えない設定になっている。

9月12日

開発の減速を求める文章

Anthropicのダリオ・アモデイCEOは、AIモデルの能力を上げる速度を落とすべきだとする文章を公表した。同氏は、6か月から12か月のうちに、AIエージェントの集団がインターネット全体を乗っ取る能力を持ちうると述べ、その損害を数千億ドル規模と見積もっている。OpenAIのサム・アルトマンCEOはこれに賛同し、第三者の評価者を社内に常駐させる仕組みを入れる意向を示した。

9月15日

3社による安全性の協議

OpenAIは、Anthropic、Google DeepMindと、安全性についての協議を数週間続けていることを認めた。

9月28日

最新モデルの公開取りやめ

OpenAIは、最新モデル「Astra 6.1」の公開を取りやめた。社内の試験で安全基準を満たさなかったためだという。

9月29日

自主規制の合意

ホワイトハウスでの会合で、AnthropicとOpenAIを含む主要企業の幹部が、安全対策の自主規制の合意に署名した。報道によれば、合意に法的拘束力はなく、中身は内部統制、社内のリスク評価、外部監査、取締役会による監督だ。開発の速度に数値の上限を設ける取り決めや、法的拘束力のある合意は、本稿の執筆時点で確認できていない。合意が実際に効くのかについては、報道でも疑問が出ている。

9月30日

Googleも最上位モデルの提供を限定

合意の翌日、Googleは新しい最上位モデル「Gemini 4 Argon」を発表した。同社によれば、このモデルはソフトウェアの重大な脆弱性を自律的に見つけ、検証し、修正できる。同社は一般への提供に先立ち、審査を通ったサイバー防御の担当組織に限って提供を始めた。これらの組織と同社の社内部門には、サイバー分野の保護機能を外した版を提供するという。一般への提供時期は示されていない。この水準の能力を安全に提供するには段階を踏む必要があり、広く提供する前に保護機能の強化を続ける、というのが同社の説明だ。Anthropic、OpenAIに続いて、Googleも最上位モデルの提供範囲を当面絞ったことになる。

記録されているAIエージェント群の攻撃

海外では、AIエージェントを並列に動かす攻撃が報告されている。国内の集計とは別の証拠として、2つの報告を紹介する。

Anthropicは2026年9月の報告書「Countering misuse of AI: September 2026」に、ある攻撃者を記録している。主となるAIエージェントが偵察と侵入後の作業を分解し、並列で動く多数の副エージェントへ割り当てる。この「エージェント群」を、攻撃者は日常的に運用していた。

「エージェント群」の構成（報告書の記述に基づく作図）

攻撃者

指示

主となるAIエージェント偵察と侵入後の作業を分解する

割り当て

副 副 副 副 副 副 副 副

この攻撃者が標的とした約50の組織の分野

教育 小売 エネルギー 技術 医療 金融 製造 政府機関

並列のAIエージェントによる攻撃は、ほかにも報告されている。セキュリティ企業のGambit Securityは、2026年9月22日の記事「Autonomous AI agents breach online retailers at $25 a company」で、2026年7月から続く攻撃を記録した。同社によれば、攻撃者は脆弱性の探索、侵入、全体の統括を3つのAIの仕組みに分担させ、9月10日から15日までの間に少なくとも27社の通販サイトへ侵入し、うち2社から60万件を超えるカード情報を盗んだ。費用は4週間で約7,000ドル、1社あたり平均25.46ドルだった。同社は、国内の旅行予約サイト1件が、カード情報を盗むスクリプトの配信先に含まれていたとも述べている。社名の記載はなく、当事者の発表も確認できていない。

ただし、9月24日以降の71件がAIエージェントによる攻撃だと確認されたわけではない。71件のどの発表にも、生成AIが使われたという記載はない。

標的となりやすい12類型

473件を、業種や規模ではなく、「侵入の起点」と「被害を広げた要因」で分け直した。1件が複数の類型に当てはまることがある。右上の数字は該当する事案の数だ。各カードの末尾には、最初に確認すべき事項を書いた。

放置22件

放置された外部参照と失効ドメイン

提供元が変わった外部スクリプトの参照を残していた12件と、使い終えたドメインを第三者に取得された10件。自社のシステムは侵入されていないが、利用者の目には公式サイトの異変として映る。

22件を一覧で見る

最初に確認すべき事項外部から読み込むスクリプトと、過去に使用したドメインの一覧が存在するか。

踏み台42件

メールアカウントの乗っ取りと送信の踏み台化

教職員や社員のアカウント、メール配信基盤が乗っ取られ、迷惑メールやフィッシングメールの送信元にされる。大学と中小の事業者に多い。被害者であると同時に、加害の経路にもなる。

42件を一覧で見る

最初に確認すべき事項全てのメールアカウントに多要素認証が適用され、大量送信を検知できるか。

誘導23件

偽の警告画面による遠隔操作

偽の警告画面から電話をかけさせ、職員自身に遠隔操作ソフトを入れさせる。学校、自治体の出先機関、委託先の端末で起きていて、端末内の名簿や口座が被害を受ける。起点は職員自身の操作で、システムへの侵入ではない。

23件を一覧で見る

最初に確認すべき事項利用者の権限で、未承認の遠隔操作ソフトを導入・実行できない設定となっているか。

送金22件

経営者を装う送金指示

代表者を名乗るメールからSNSのグループへ誘い込み、担当者に送金を指示する。システムへの侵入は伴わないので、脆弱性診断や侵入検知では見つからない。22件のうち19件で金銭の被害が出ていて、地方の中小企業と福祉法人が多い。

22件を一覧で見る

最初に確認すべき事項送金と振込先の変更について、依頼とは別の経路で本人に確認する手順が存在するか。

認証60件

正規認証情報の悪用

流出した、使い回された、あるいは推測された認証情報で、正面から入られる。記録の上では正常なログインなので、多要素認証がなければ検知は難しい。会員サイトへのリスト型攻撃と、リポジトリやクラウドの認証キーの流出を含む。

60件を一覧で見る

最初に確認すべき事項全ての管理者アカウントと外部から到達可能なサービスに、多要素認証が適用されているか。

更新60件

機器・ソフトウェアの脆弱性

VPN機器、ネットワーク機器、CMSとそのプラグイン、第三者製ソフトウェア。更新の通知が届かず、公開済みの修正が当てられないまま残る。この類型60件のうち42件は、脆弱性の所在や修正の有無などの情報が足りず、防止可能性を判定できない。

60件を一覧で見る

最初に確認すべき事項外部に面した機器とソフトウェアの一覧と、各々の最終更新日を即答できるか。

実装19件

自社実装の認証・認可・入力処理

ファイルのアップロード、管理画面のログイン、APIの認可、登録情報の更新。依存ライブラリの検査では見つからない、自社コードの欠陥だ。

19件を一覧で見る

最初に確認すべき事項依存ライブラリではなく、自社のコードと設定を対象とする診断を実施した時期。

侵害71件

ランサムウェア

暗号化で業務が止まるうえに、情報も盗まれる。71件のうち19件は、情報漏えいが主な被害だ。IDCフロンティアのクラウド基盤への攻撃では、契約する495の企業・自治体に影響が及んだ。バックアップから復旧しても、盗まれた情報は戻らない。侵入経路が公表されない事案が多く、公表まで数か月かかる例もある。

71件を一覧で見る

最初に確認すべき事項復旧手順とは別に、窃取された場合の影響範囲を特定できる台帳が存在するか。

供給網38件

委託先および共通基盤

業務委託先、ECカート、予約基盤、メール配信、クラウドサービス。1社への侵入が、その基盤を使う多数の組織へ波及する。YCC情報システムへの攻撃では、山形市の住民情報約55.8万件に漏えいの可能性があると公表された。両毛システムズへの攻撃は、同社に業務を委託するガス事業者と自治体へ波及した。スカラコミュニケーションズの「i-ask」では、最大5社の問い合わせ情報、延べ最大713,126件に漏えいの可能性がある。大和証券の約11万名、シチズン時計の約10万名、東武鉄道、岩手銀行は、その波及先であり、別の攻撃として数えていない。IDCフロンティアのクラウド基盤へのランサムウェア攻撃では、契約する495の企業・自治体に影響が及び、SKE48 Mailや日水物流の入出荷が止まった。第一興商では、委託先の従業員のパソコン1台のマルウェア感染で、約872万件の顧客・従業員情報に漏えいのおそれが生じた。さくらインターネットの事案では、セーファーインターネット協会も通報・連絡内容などが閲覧・取得された可能性を公表した。実際の閲覧・取得は確認されていない。委託元は、検知も調査も委託先に頼ることになり、自社の設定だけでは防げない。

38件を一覧で見る

最初に確認すべき事項委託先へ提供しているデータの種類と件数を即答できるか。

決済17件

通販サイトの改ざんとカード情報

通販サイトの決済画面や申込フォームが改ざんされ、入力されたカード情報が盗まれる。カード会社からの連絡で発覚する例が多く、脆弱性の所在は公表されないことが多い。

17件を一覧で見る

最初に確認すべき事項決済画面を構成するファイルの改ざんを検知する仕組みが存在するか。

データ14件

変更不能なデータの保持

本人確認書類の画像や番号、マイナンバー、健康情報、診療・手術の記録、通話音声、平文のパスワード。漏えいした後に本人が変更できないか、変更の負担が大きい。

14件を一覧で見る

最初に確認すべき事項確認済みの本人確認書類の画像と、退会者のデータを削除しているか。

運用11件

検知から特定・公表までの空白

さくらインターネットでは不正アクセスが約3年続き、Eストアーでは不正なプログラムが約2か月半動いていた。デジタル庁は、検知から侵入の確定までに2週間、公表までに2か月半かかっている。ムーンスターは3月の初報から10月の続報で情報取得の可能性を公表した。ZonExpertは2025年8月に検知した事案を2026年10月に公表している。日本経済新聞社は、8月上旬に検知した不正ログインを10月4日に公表した。エイチ・アイ・エスは、2025年12月に検知した不正アクセスを2026年10月7日に公表した。検知を前提にした運用は、検知できていない間の被害を防がない。流出内容を特定する台帳がなければ、通知も遅れる。

11件を一覧で見る

最初に確認すべき事項異常を検知した担当者が、その場で遮断する権限と手順を有しているか。

国内473件は防げたのか

答えから言えば、判定できた事案の大半は防げた。基本的な対策か設計の変更で防げたと評価した事案が、判定できた169件のうち168件ある。起点は認証情報の悪用、公開済み修正の未適用、設定の不備といった、生成AI以前からある不備だ。この章では、防止可能性の判定、被害の類型ごとの対策、侵入経路、生成AIの利用の有無を順に確かめる。そのうえで、生成AIを防御に使っても残る課題と、開発企業の提供制限が攻撃側に届かない理由を述べる。それでも従来の対策だけでは防げなくなる理由は、次の章で扱う。

判定結果：防げた事案が大半を占める

63件

基本的対策で防止可能

無償の設定変更、公開済み修正の適用、認証情報の保管場所の見直し、不要なシステムやドメインの整理により防止できた事案。

105件

設計変更で防止可能

工数を要するが、認証・認可の設計、機能の分離、多要素認証の導入、送金時の別経路による確認により防止できた事案。

1件

防止困難

侵入の起点が、当時未知とされる脆弱性であった事案。

304件

原因未公表・判定不能

経路の区分が「原因未公表」または「ランサムウェア（侵入経路未公表）」の210件と、その他の区分で防止可能性を判定できない94件。

145件

基本的対策で防止可能（推定）

304件の48%。

145件

設計変更で防止可能（推定）

304件の48%。

4件

防止困難（推定）

304件の1%。

10件

推定の対象外

閲覧障害の10件。判定できた事案が存在しないため、推定していない。

208件

基本的対策で防止可能（推定を含む）

公表63件と推定145件。473件の44%。

250件

設計変更で防止可能（推定を含む）

公表105件と推定145件。473件の53%。

5件

防止困難（推定を含む）

公表1件と推定4件。473件の1%。

10件

推定の対象外

閲覧障害の10件。

473件のうち、侵入経路か手口が公表されていて、防げたかどうかを判定できた事案は169件ある。この169件を、当時の標準的な対策で防げたかどうかで分けた。

この分類は、公表内容をもとに我々が事後に評価したものだ。当事者の責任を問うためのものではない。対策の優先順位を決めるための整理である。原因未公表・判定不能の304件がどこに入るかで、比率は変わる。防止困難としたKDDIの1件は、当事者が発生時点では未知の脆弱性だったと公表した事案だ。この事案では、パスワードを平文で保存していたことが被害を広げた。被害の規模は、基本的対策で小さくできた。

判定ごとの件数は次のとおり。「一覧で見る」で、国内サイバー攻撃の観測記録の表をその判定の事案に絞り込める。

判定件数該当事案
基本的対策で防止可能63件一覧で見る
設計変更で防止可能105件一覧で見る
防止困難1件一覧で見る
原因未公表・判定不能304件一覧で見る

原因未公表・判定不能の304件は、公表内容からは判定できない。しかし、判定できた169件の比率を当てはめれば、内訳は推定できる。図の2番目と3番目のタブが、その推定だ。あくまで推定で、個々の事案への判定ではない。

推定の方法は次のとおり。

  • 侵入経路の区分が示された事案のうち、同じ区分で判定済みの事案が5件以上ある78件には、その比率を当てはめた。「脆弱性・外部接続機器（詳細未公表）」は「機器・ソフトウェアの脆弱性」にまとめて計算した。
  • 経路が公表されていない事案と、同じ経路で判定できた事案が5件に満たない事案の計216件には、同じ被害の類型で判定できた事案の比率を当てはめた。
  • 閲覧障害の10件は、同じ類型で判定できた事案がないため、推定の対象から外した。各事案への配分を合計し、判定区分ごとに四捨五入した。

判定できた169件と合わせると、473件のうち基本的対策で防げた事案は208件、設計変更で防げた事案は250件、防止困難な事案は5件になる。防げた事案は458件で、全体の97%を占める。ただし、この推定には仮定がある。原因を公表しなかった事案も、公表した事案と同じ傾向を持つ、という仮定だ。原因を公表しない事案には、侵入経路を特定できなかったものが含まれる。実際の比率は違うかもしれない。特に業務停止は、判定できた事案が7件しかなく、ランサムウェア被害についての推定は不確かだ。

推定の内訳は次のとおり。区分ごとに、判定済みの事案の比率（件数）と、それを対象件数に当てはめた配分を示す。配分を合計して四捨五入した値が、図の3番目のタブの推定の件数になる。「一覧で見る」で、その区分の原因未公表・判定不能の事案を確かめられる。

区分当てはめた比率対象基本的対策設計変更防止困難該当事案
情報漏えい同じ被害の類型の判定済み106件28%（21件）
29.3件		71%（54件）
75.3件		1%（1件）
1.4件		一覧で見る
業務停止同じ被害の類型の判定済み54件71%（5件）
38.6件		29%（2件）
15.4件		0%（0件）
0.0件		一覧で見る
機器・ソフトウェアの脆弱性同じ侵入経路の判定済み42件83%（15件）
35.0件		11%（2件）
4.7件		6%（1件）
2.3件		一覧で見る
改ざん・乗っ取り同じ被害の類型の判定済み35件83%（33件）
28.9件		18%（7件）
6.1件		0%（0件）
0.0件		一覧で見る
正規認証情報の悪用同じ侵入経路の判定済み22件30%（11件）
6.5件		70%（26件）
15.5件		0%（0件）
0.0件		一覧で見る
資源の悪用・踏み台同じ被害の類型の判定済み20件18%（4件）
3.6件		82%（18件）
16.4件		0%（0件）
0.0件		一覧で見る
自社実装の脆弱性同じ侵入経路の判定済み8件9%（1件）
0.7件		91%（10件）
7.3件		0%（0件）
0.0件		一覧で見る
フィッシング・端末の乗っ取り同じ侵入経路の判定済み4件9%（4件）
0.3件		91%（42件）
3.7件		0%（0件）
0.0件		一覧で見る
設定・管理の不備同じ侵入経路の判定済み2件97%（30件）
1.9件		3%（1件）
0.1件		0%（0件）
0.0件		一覧で見る
金銭の窃取同じ被害の類型の判定済み1件0%（0件）
0.0件		100%（24件）
1.0件		0%（0件）
0.0件		一覧で見る
閲覧障害推定の対象外10件判定済みの事案がないため推定せず一覧で見る
配分の合計（四捨五入前）304件基本的対策
145件（144.9）		設計変更
145件（145.3）		防止困難
4件（3.7）

被害の類型別：何を変えれば防げたか

判定の基準は被害の大きさではなく、侵入経路と当時使えた対策だ。類型ごとに、何を変えれば防げたと評価したかを整理する。

被害の類型別に見た判定の割合公表資料にもとづく473件の評価
  • 基本的対策で防止可能
  • 設計変更で防止可能
  • 防止困難
  • 未公表・判定不能
情報漏えい226件
基本的対策
21件
設計変更
54件
防止困難
1件
未公表・判定不能
150件
業務停止72件
基本的対策
5件
設計変更
2件
防止困難
0件
未公表・判定不能
65件
改ざん・乗っ取り87件
基本的対策
33件
設計変更
7件
防止困難
0件
未公表・判定不能
47件
資源の悪用・踏み台52件
基本的対策
4件
設計変更
18件
防止困難
0件
未公表・判定不能
30件
金銭の窃取26件
基本的対策
0件
設計変更
24件
防止困難
0件
未公表・判定不能
2件
閲覧障害10件
基本的対策
0件
設計変更
0件
防止困難
0件
未公表・判定不能
10件

帯の長さは、各類型の全件を100%とした割合。件数は公表資料にもとづく評価で、推定値を含まない。未公表・判定不能は、防げたかどうかを判断する根拠が足りない事案であり、防止困難とは区別する。

  • 情報漏えい。公開済み修正の適用、権限設定や認証情報の保管の見直しで防げたものは、基本的対策に含めた。多要素認証の導入や、認証・認可の作り直しが必要なものは設計変更とした。侵入時点では未知だった脆弱性の悪用は、防止困難と評価した。
  • 業務停止。設定不備の是正、公開済み修正の適用、VPNへの多要素認証で防げたと評価した事案がある。バックアップによる復旧は、侵入自体の防止とは分けて考える。判定できたのは72件中7件で、残りを防止困難とは判断していない。
  • 改ざん・乗っ取り。使わなくなった外部スクリプトやドメインへの参照を削除すること、ソフトウェアを更新することで防げたと評価した事案が多い。一方、アカウントの乗っ取りでは、追加の認証要素を設けるなどの設計変更が必要だった。
  • 資源の悪用・踏み台。メールの中継設定やAPIキーの保管・権限を見直して防げたものは、基本的対策に含めた。盗まれたパスワードでメールアカウントへ入られた事案などは、多要素認証を含む認証設計の変更で防止可能と評価した。
  • 金銭の窃取。送金依頼とは別の経路で本人を確かめることや、複数人で承認する手順を設けることが、防止の中心になる。ポイントの不正交換などでは、追加認証や交換時の本人確認も設計変更に含めた。はてなの約11.8億円の不正送金は、警察関係者を名乗る相手への対応中に遠隔操作を許した事案だ。システムへの侵入だけを監視しても、この種の被害は防げない。
  • 閲覧障害。10件すべてが判定不能だ。公表内容からは、防げたかどうかを判断するだけの根拠を得られなかった。防止困難だと確認した事案とは区別している。

侵入経路：起点は従来と変わらない

侵入経路の区分別の件数全473件
  1. 正規認証情報の悪用59件12%
  2. 機器・ソフトウェアの脆弱性51件11%
  3. フィッシング・端末の乗っ取り50件11%
  4. 設定・管理の不備33件7%
  5. 人を欺く手口（送金・操作の誘導）23件5%
  6. 自社実装の脆弱性19件4%
  7. 委託先・外部サービス経由13件3%
  8. 脆弱性・外部接続機器（詳細未公表）9件2%
  9. 過負荷攻撃（DDoS）6件1%
  10. ランサムウェア（侵入経路未公表）45件10%
  11. 原因未公表165件35%
侵入経路件数該当事案
自社実装の脆弱性19件一覧で見る
正規認証情報の悪用59件一覧で見る
機器・ソフトウェアの脆弱性51件一覧で見る
設定・管理の不備33件一覧で見る
フィッシング・端末の乗っ取り50件一覧で見る
委託先・外部サービス経由13件一覧で見る
人を欺く手口（送金・操作の誘導）23件一覧で見る
過負荷攻撃（DDoS）6件一覧で見る
脆弱性・外部接続機器（詳細未公表）9件一覧で見る
ランサムウェア（侵入経路未公表）45件一覧で見る
原因未公表165件一覧で見る

「ライブラリの脆弱性の放置か、従業員端末への侵入か、実装起因の脆弱性か、認証情報の漏えいか」という問いには、この表が答えている。経路が公表された事案で最も多いのは、正規認証情報の悪用（59件）だ。機器・ソフトウェアの脆弱性（51件）、フィッシング・端末の乗っ取り（50件）、設定・管理の不備（33件）が続く。

最多の正規認証情報の悪用は、記録の上では正常な操作に見える。マネーフォワード、CAMPFIRE、中部電力が、この形で侵入された。設定・管理の不備に分類した集英社でも、不正に作られた特権アカウントが正規のAPIを繰り返し呼び出していた。脆弱性診断だけでは、こうした認証情報の悪用を見つけきれない。通常と異なるログイン、大量取得、外部送信などの挙動も監視する必要がある。

国内で確認された生成AIの利用

本稿に載せた473件について、確認した公表資料に攻撃者が生成AIを使ったという記載はなかった。一方で警察庁は、2026年に公表した2件の報告書に、攻撃や詐欺に生成AIが使われた国内の事例を記載している。誰がどう述べたかを、以下に示す。

事案生成AIの用途述べた主体
複合カフェのアプリへの攻撃（2025年1月。会員情報の漏えい）高校生が、攻撃プログラムの作成に生成AIを使用した警察庁（令和7年の報告書）
動画配信サービスへの攻撃（2025年11月。約4万6,800アカウントの退会処理）高校生が、自ら発見した脆弱性に対する自作の攻撃プログラムを、生成AIを用いて修正した警察庁（令和8年上半期の報告書）
eSIM契約システムを悪用した回線の不正契約自作プログラムの作成に生成AIを使用した警察庁（令和7年の報告書）
フィッシングサイトの作成、パスワードリスト攻撃サイトの作成と改修、攻撃用プログラムの作成に生成AIを使用した警察庁（令和7年の報告書）
ランサムウェアの作成（2026年6月に逮捕。被害の記載はない）AIに出力させたソースコードを組み合わせて作成した警察庁（令和8年上半期の報告書）
警察官を装う特殊詐欺警察官役の顔をAIで生成した警察庁（令和8年上半期の報告書）
海外の集団によるサポート詐欺標的の特定、警告画面の作成、日本語への翻訳に生成AIを使用した警察庁（令和7年の報告書）
北朝鮮の攻撃集団によるIT技術者を標的とした攻撃オンライン面接において、AIによる顔画像交換ソフトを使用した警察庁および国家サイバー統括室（2026年9月18日の注意喚起）
幹部を装う相手からの社員への接触AIで合成した幹部の顔写真が使用されたNTTデータの事業部長（報道向け説明会での説明。クラウドWatchの報道による）

企業のサービスが攻撃を受け、しかも生成AIの利用が確認された事例は、表の冒頭の2件だ。どちらも高校生による攻撃で、起点はそのサービスの実装上の脆弱性だった。脆弱性の発見に生成AIを使ったとは、どの資料も述べていない。生成AIの用途は、攻撃プログラムを作ったり直したりするときの補助である。どちらの事案も当事者の最初の公表が2025年なので、本稿の地図と一覧には入れていない。

企業への侵入とランサムウェア被害では、事情が違う。警察庁の令和8年上半期の報告書は、ランサムウェアの被害報告を半期として過去最多の123件と記載している。だが、その項にも感染経路の統計にも、攻撃者による生成AIの利用についての記述はない。JPCERT/CCが2026年に公表した注意喚起29件に、生成AIを使った攻撃を主題とするものはない。情報処理推進機構（IPA）は「情報セキュリティ10大脅威2026」で、現状を「従来と変わらないサイバー攻撃がAIによって半自動化・高速化されているといったものに留まります」と書いている。

経営者を装う送金指示については、同じ解説書がビジネスメール詐欺の項で、生成AIを悪用した手口の多様化と、なりすましへのディープフェイクの利用に触れている。ただ、いつ、どの事案で確認されたのかは書かれていない。本稿に載せた22件にも、当事者や警察が生成AIの利用を述べた事案はない。22件を載せたのは、生成AIの悪用が指摘されている手口だからだ。個々の事案で生成AIが使われたことを示すものではない。

フィッシングについては、警察庁が、AI技術の発達で文章の自然さと偽装の精度が上がり、見抜きにくいものが増えていると記載している。文面の不自然さを手がかりにする見分け方には、もう頼れない。

ただし、確認できなかったことは、使われていないことを意味しない。攻撃者が手元で使った道具は、被害側のログからは分からないことが多い。公表資料に記載がない理由も、個々の事案については判断できない。

攻撃者の端末や供述、AIサービス提供者の調査などが、利用を確認する手がかりになる。被害組織の発表だけで、生成AIの利用実態を数えられるとは限らない。

国内事例を確認できなかった手口

海外で報告の多い手口について、国内の被害事例と、公的機関の注意喚起があるかを調べた。事例を確認できなかった手口は次のとおりだ。これも、起きていないことを意味しない。

手口国内の被害事例国内の公的機関等による注意喚起
暗号資産の窃取個人の被害2件を確認した（兵庫県警察の発表に関する報道）。交換業者からの2026年の流出は確認できなかった警察庁の報告書に記載がある。国内の事業者からの窃取として挙げられているのは2024年の事案である
偽の認証画面によりコマンドを実行させる手口感染に至った被害の公表は確認できなかった静岡県警察が注意喚起。ESETは検出数の14%が日本であり国別で最多と報告
偽アプリNTTドコモが、不正アプリに感染した端末を介した不正購入の被害発生を公表したNTTドコモ、PayPay、フィッシング対策協議会が注意喚起
悪性のブラウザ拡張機能確認できなかった確認できなかった
経営者の映像・音声を偽装した送金指示確認できなかった。経営者を装う送金指示22件は、いずれもメールとSNSによるものであるIPAに一般的な記述があるが、時期と事案は示されていない
ヘルプデスクを装う認証情報の再設定確認できなかった確認できなかった
AIエージェントおよびその接続機構の悪用確認できなかった警察庁、IPAが海外の報告を紹介。JPCERT/CCは、LLMと連携するソフトウェアの脆弱性を標的とする通信を観測

防御側の生成AI：基本的な不備は埋まらない

ここまで見たとおり、被害の起点は認証情報の悪用や未適用の修正といった基本的な不備だ。生成AIを検査に入れても、この不備は埋まらない。それに加えて、次の章で述べる7つの点のうち、プロンプトインジェクションと知識のカットオフは、防御側の生成AIにもそのまま当てはまる。さらに、生成AIを検査に使うこと自体から生まれる問題がある。

  1. 防御側の生成AIも、プロンプトインジェクションの対象になる。攻撃者が書いた文章を検査する以上、その文章に誤誘導される余地が残る。
  2. 防御側の生成AIにも、最新情報との照合が必要だ。検索や脆弱性データベースを使わずに、学習済みの知識だけで検査を完結させない。未知の欠陥を分析で見つけることもあるが、検出の網羅性は保証されない。
  3. 生成AIの判定は再現性を保証しない。通すか止めるかを決める機構は、同じ入力に同じ結果を返さなければならない。確率的に動く生成AIは、大量の検出結果を人が確認できる量まで絞り込む用途には向く。だが、強制する機構そのものには向かない。
  4. 検査のために渡した情報が、新しい漏えい経路になる。検出された認証情報の値や顧客データを外部の生成AIへ送れば、検査そのものが情報の持ち出しになる。
  5. もっともらしい報告が、検査の代わりになってしまう。設定を書いただけで有効にしていない。過去のデータを現状として報告する。こうした結果を、人が検証せずに受け取る危険がある。導入していないことより、導入済みだと思い込むことのほうが危ない。

だから生成AIは、人が確認すべき対象を絞り込む補助として使う。通すか止めるかの最終判断を任せてはいけない。

プレフィル：提供の制限は攻撃側に届かない

プロンプトインジェクションは、他者が運用する生成AIを誤動作させる攻撃だ。これとは別に、攻撃者が自分で使う生成AIの安全対策を外す手法も研究されている。対象は、重みが公開され、利用者が手元で動かせるモデルだ。

提供が制限されたモデルや、運営企業のサーバー上でしか動かないモデルは、有害な依頼を外部の仕組みで断れる。重みが公開されたモデルは違う。利用者が応答の冒頭部分をあらかじめ指定し、その続きを生成させられる。「プレフィル」と呼ばれるこの操作で、モデルに組み込まれた拒否の動作を回避できる。

2026年2月に公表された研究は、20種類を超えるプレフィルの手法を、Qwen3、DeepSeek-R1、Llama、GPT-OSS、Kimi-K2、GLM-4.7を含む50のモデルで検証し、主要な公開モデルのすべてに一貫して有効だったと報告している。有害な依頼179件を使った評価では、大半のモデルで、いずれかの手法の成功率が90%から100%に達した。大型の推論モデルは、汎用の手法には一定の耐性を見せたが、モデルごとに調整した手法には弱かった。

この研究は研究者による検証で、攻撃者が実際に使っているかどうかを示すものではない。それでも、開発企業による提供の制限が公開モデルには及ばないことは分かる。最上位のモデルの提供を絞っても、攻撃者は安全対策を外した公開モデルを使える。守る側の生成AIにも、攻撃側のモデルの制限にも、頼り切ることはできない。

守る側に残るのは、基本的な不備をなくすことと、生成AIが変えた速度と規模に合わせて対策を見直すことだ。次の章で、従来の対策だけでは防げなくなる7つの理由を述べる。

なぜ従来の対策だけでは防げないのか

攻撃側の変化4つと、利用する組織の弱点3つ各項目から対応する節へ進める

攻撃側の変化

  1. 速度脆弱性の公表から悪用まで、侵入から窃取までの時間が縮み、対処の猶予がなくなる
  2. 規模攻撃者1人が並行して進められる作業の範囲が広がる
  3. ゼロデイ攻撃修正プログラムがない脆弱性は、修正の適用では防げない
  4. 適応検知された攻撃手段が自動で作り直され、既知の特徴による検知が効かなくなる

生成AIを使う組織に生まれる弱点

  1. プロンプトインジェクション生成AIを誤動作させる指示は自然な文章に紛れるため、通信やコードの検査だけでは見分けにくい
  2. 知識のカットオフ学習済みの知識だけでは、最新の脆弱性と修正情報を取りこぼす
  3. 生成AIの供給網生成AIにつなぐ拡張機能や部品が、新しい侵入経路になる

前の章で見たとおり、公表資料から判定できた国内事案の大半は、従来の対策で防止可能と評価した。その対策を続けながら、生成AIによる攻撃の変化と、生成AIを業務に組み込む際の弱点にも備える必要がある。攻撃側の変化を4つ、利用する組織の課題を3つに分けて考える。

速度：対処の猶予が失われる

従来の対策は、時間の余裕を当てにしている。脆弱性が公表されてから修正を当てるまでの時間。侵入を検知してから遮断するまでの時間。生成AIは、この両方を縮める。

Anthropicの「Project Glasswing」の発表で、CrowdStrikeの最高技術責任者は、脆弱性の発見から悪用までの期間について、かつて数か月かかったものがAIによって数分で起きるようになったと述べている。侵入した後も速い。Anthropicの2026年9月の報告書には、2つの事例がある。企業向けソフトウェアの企業への侵入が、最初のアクセスから大量のデータの窃取まで数時間で終わった事例。そして、開発者のトークン1件の窃取から、約3時間でクラウド環境の管理者権限を握られた事例だ。

月に一度の修正適用と、検知してから人が判断して動く運用では、この速度に追いつけない。外部に面した機器への修正は、その日のうちに当てる。異常を検知したら、人の判断を待たずに遮断する。この2つの仕組みが要る。

規模：並行して進められる作業が増える

広範囲のスキャンや攻撃の自動化は、生成AIの普及前から行われてきた。生成AIは、標的ごとの調査や侵入後の判断を伴う作業まで自動化する範囲を広げうる。「小さな組織だから狙われない」とは考えないほうがよい。

Anthropicの報告書は、主となるAIエージェントが作業を分解し、並列で動く副エージェントへ割り当てる攻撃者を記録している。こうした運用は、攻撃者1人が扱える作業量を増やしうる。ただし、9月24日以降の国内事案の集中が、この種の攻撃によるものかどうかは確認されていない。

ゼロデイ攻撃：修正の適用では防止できない

前の章に示した判定で、防止困難と評価したのは1件だ。侵入時点で未知だったと公表された脆弱性を突く攻撃である。未公表・判定不能の事案に後述の仮定を当てはめる試算では、防止困難は合計5件となる。ただし、これを確認済みのゼロデイ攻撃件数として扱うことはできない。

Googleの脅威分析部門の集計では、実際の攻撃に悪用されたゼロデイ脆弱性は、2024年の78件に対して2025年は90件だった。うち48%にあたる43件は、VPN機器やセキュリティ製品を含む企業向けの製品が対象で、この割合は過去最高だ。同社は2026年について、攻撃者がAIで偵察、脆弱性の発見、攻撃コードの開発を自動化し、規模を広げると予測している。

生成AIがどれほど速く脆弱性を見つけるかは、先に見たClaude Mythos Previewの例が示している。攻撃者の側も同じだ。Anthropicが2026年9月に報告した攻撃者は、主要なセキュリティ製品を対象に並列のAIエージェントで脆弱性を探し、1か月で十数件のゼロデイの候補を得ていた。これまで、ゼロデイ脆弱性を見つけられるのは高度な技能を持つ少数の者だけで、その希少さが攻撃の件数を抑えていた。この制約もなくなりつつある。

ただし、生成AIのせいでゼロデイ攻撃が何件増えたかを示す統計はない。Googleの集計は、個々の脆弱性の発見に生成AIが使われたかどうかを区別していない。確認できるのは2点だけだ。悪用の件数が増えていること。生成AIが、発見にかかる期間を大幅に縮めたこと。ゼロデイ攻撃は、修正の適用では防げない。だから、侵入される前提で被害の範囲を絞る、次の対策が重要になる。

  • 機器の管理画面を外部へ公開しない
  • パスワードや認証キーを、そのまま読める形（平文）で保存しない
  • 1台に侵入されても、ほかのサーバーや端末へ広がれないよう、ネットワークと権限を区切る

適応：既知の特徴に基づく検知が効かなくなる

セキュリティ製品の多くは、既知の攻撃手段の特徴をもとに検知する。これまでは、新しい検知方法が配備されるたびに、攻撃者は手段を作り直すことになり、活動が遅れた。

Anthropicの報告書には、この関係が逆転した事例がある。ある攻撃者は、配備したマルウェアがセキュリティ製品に検知されたかどうかを、AIエージェントに見張らせていた。検知されたら、検知されなくなるまで、マルウェアの修正と再構築を自動で繰り返させる。同社は、有能な攻撃者が、防御側が検知方法を開発して配備するよりも速く、従来の検知を回避できるようになると述べている。

既知の特徴による検知だけに頼る防御は、この適応についていけない。見張るべきは侵入後の挙動だ。ふだんと違う権限の使い方、大量のデータの取得、外部への送信である。

プロンプトインジェクション：文章に紛れた指示への対策が必要になる

生成AIを業務に組み込んだ組織には、従来の対策の体系に入っていない攻撃が成り立つ。代表がプロンプトインジェクションだ。

プロンプトインジェクションは、生成AIが処理する文章に指示を紛れ込ませ、利用者の意図と違う動作をさせる攻撃だ。2種類ある。利用者自身が入力欄に指示を書き込む直接的なもの。そして、生成AIが読むメール、文書、ウェブページ、プルリクエストのコメントに指示を埋め込む間接的なものだ。後者では、攻撃者は標的のシステムに侵入しなくていい。標的の生成AIが読む場所に、文章を置くだけで足りる。Microsoft 365 Copilotで報告された「EchoLeak」は、攻撃者がメールを送るだけで、受信者が何も操作しなくても、生成AIが参照できる社内の情報を外部へ送り出させるものだった。

対策を考えるうえで押さえるべき点は3つある。

  1. 指示とデータの区別に限界がある。言語モデルは、渡された文章のどこまでが指示で、どこからがデータなのかを、確実には区別できない。個別の実装の修正に加え、参照する情報と実行できる操作を制限する必要がある。
  2. 攻撃は自然な文章として届く。不正な通信や不正なコードを検知する製品は、文面だけではこれを見分けられない。
  3. 生成AIは正規の権限で動く。認証や多要素認証を破る必要がない。生成AIに与えた閲覧範囲と実行権限が、そのまま被害の範囲になる。

IPAは「情報セキュリティ10大脅威2026」の解説書で、間接的プロンプトインジェクションを「AIに固有の弱点を狙った新時代の攻撃」と位置づけている。国内で、プロンプトインジェクションによって実害が出たとする当事者や公的機関の発表は、確認できなかった。ただし、この攻撃は侵入の痕跡が残りにくい。被害を受けた組織が気づいていない可能性がある。

対策は、生成AIの出力を信頼しない設計に尽きる。

  • 外部から来た文章を読む生成AIには、機密情報の閲覧権限と外部への送信手段を同時に与えない。
  • 送金、削除、公開設定の変更のように取り消しのきかない操作は、人の承認を経て実行する。
  • 生成AIに与える権限は、従業員の権限と同じく最小限にし、定期的に棚卸しする。

知識のカットオフ：最新情報との照合が必要になる

生成AIの学習済みの知識には、収録された情報の時点による限界がある。学習後に公表された脆弱性や修正について、モデルの記憶だけに頼ると古い回答や誤答が生じうる。ただし、検索や入力資料を通じて最新情報を参照することはできる。

  1. 提案されるコードと設定が古い。生成AIが提案するライブラリの版や設定は、カットオフ時点の知識によるものだ。その後に脆弱性が公表された版を、そのまま指定することがある。
  2. 最新の既知脆弱性を見落としうる。脆弱性情報を検索・照合する仕組みがなければ、学習後の公表情報を確実には反映できない。検査を通ったことは、安全性の保証にはならない。
  3. 未知の欠陥の発見と、最新情報の参照は別の能力だ。コードを分析して未公表の脆弱性を発見することもある。前述のProject Glasswingはその一例だが、全ての欠陥を検出できるという意味ではない。

新しいモデルへ更新するだけでなく、最新の脆弱性情報や提供元の文書と照合する運用が必要だ。国内473件について、学習済みの知識の古さを原因とする当事者の発表は確認できなかった。

対策は、最新の情報を生成AIの外から与えることだ。

  • 依存するライブラリの版と脆弱性の有無は、生成AIの回答ではなく、脆弱性情報のデータベースと照らし合わせる。
  • 生成AIに検査をさせるなら、最新の脆弱性情報と修正情報を入力として与える。
  • 生成AIが提案した版と設定は、提供元の最新の文書で確かめてから採用する。

生成AIの供給網：拡張機能や部品が新たな侵入経路となる

生成AIを業務に組み込むときには、外部のツールへつなぐ部品や、機能を足す拡張機能を入れる。これらは、従来のソフトウェアの依存関係と同じく、侵入経路になる。しかも、生成AIに与えられた権限で動く。侵害されれば、影響はその生成AIが届く範囲の全体に及ぶ。

海外の調査報告で確認された攻撃を、以下に示す。プロンプトインジェクションの事例も含む。同じ種類の製品を使う国内の組織も、対象になりうる。

攻撃仕組み確認された内容有効な対策
間接的プロンプトインジェクション生成AIが読み取る文章に指示を埋め込む。利用者の操作を要しないプルリクエストのコメントによりCI上のAIエージェントを操作し、認証情報を出力させる手法（2026年4月報告）外部由来の文章を指示として解釈させない。生成AIの実行環境に本番の認証情報を配置しない
ツール接続機構の脆弱性生成AIを外部ツールへ接続する部品が、受領した命令を検証せず実行するMCPを組み込んだ製品に、任意のコマンドを実行できる脆弱性。深刻度の高いCVEが10件超（OX Security、2026年4月）接続先を許可済みのものに限定し、版を固定する
悪意あるAIスキルAIエージェントの拡張機能に、情報の持出しや不正な実行を埋め込む約90万個の調査において3,000個超が悪意あり、約2万5,000個が不審（ESET、2025年12月から2026年5月）公開直後のものを導入しない。導入前に内容を確認する
AIのAPIキーの窃取と転用窃取したキーにより攻撃用の処理を実行する。費用は被害者が負担し、追跡も被害者へ向かう窃取したキーを他組織への侵入に転用した集団を確認（Anthropic、2025年12月から2026年8月）キーをコードやファイルに配置しない。リポジトリを継続的に検査する

生成AIを業務に組み込んでいない組織では、侵入の起点になる不備は従来と変わらない。優先すべき対策も変わらない。ただ、速度と規模が変わったぶん、対策を打つまでの猶予は短くなっている。生成AIを組み込んだ組織は、これに加えて、プロンプトインジェクション、知識のカットオフ、生成AIの供給網への対策が要る。

対策の優先順位

「どう対策すべき？」。答えは地味だ。生成AIへの対策を足す前に、基本的な不備をなくす。推定を含めても、被害の大半は基本的な対策と設計の変更で防げた。防止困難な事案は一部にとどまる。優先順位は次のとおりだ。

  1. 外部から届く画面と機器を一覧にする。主力以外のものから先に点検する。
  2. 全ての管理者アカウントとメールアカウントに多要素認証をかけ、認証情報に有効期限を設ける。
  3. 送金と振込先の変更は、依頼とは別の経路で本人に確かめ、複数人で承認する。
  4. 利用者の権限では遠隔操作ソフトを入れられない設定にし、警告画面が出たときの連絡先を決めておく。
  5. 外部から読み込むスクリプトと、使い終えたドメインやシステムを棚卸しする。
  6. 持つ必要のないデータを消す。確認済みの本人確認書類、退会者のデータ、使い終えたシステムから着手する。
  7. リポジトリ、ファイル、端末から、期限のない認証情報と顧客の実データをなくす。
  8. 外部に面した機器とソフトウェアに公開済みの修正を当てる。悪用が確認されている脆弱性を優先する。
  9. 委託先へ渡すデータを最小限にし、渡した内容を台帳に記録する。
  10. 1つのアカウントによる大量取得と大量送信を検知し、検知した担当者がその場で遮断できる体制を整える。

対策に抜けがないかを確かめる物差しには、次の公開資料が使える。

  • 中小企業の情報セキュリティ対策ガイドライン（IPA）。何から手を付けるかを、組織の規模に合わせて示している。専任の担当者がいない組織の出発点になる。
  • CIS Controls（CIS）。機器とアカウントの一覧化、権限の管理、修正の適用、委託先の管理など、基本的な対策を18の項目に優先度つきでまとめている。
  • Known Exploited Vulnerabilities Catalog（米国CISA）。実際の攻撃に悪用された脆弱性の一覧。どの修正から当てるかを決めるのに使う。
  • JVN iPedia（IPA）。国内で使われている製品の脆弱性情報のデータベース。使っている機器やライブラリの版を照らし合わせる先になる。
  • NIST SP 800-63B（米国NIST）。認証の基準。多要素認証の方式や、パスワードと認証情報の扱いを決めるときの拠り所になる。
  • ビジネスメール詐欺（BEC）対策（IPA）。経営者や取引先を装う送金指示の事例と、送金前の確認手順をまとめている。
  • OWASP Top 10（OWASP）。ウェブアプリケーションに多い弱点の上位10項目。自社で実装した認証、認可、入力処理を点検するときの項目になる。
  • OWASP ASVS（OWASP）。アプリケーションが満たすべきセキュリティ要件の一覧。設計の見直しや診断の発注で、確認する範囲を決めるのに使う。
  • PCI DSS（PCI SSC）。カード情報を扱う事業者の基準。決済ページで読み込むスクリプトの管理と、改ざんの検知を求めている。
  • OWASP Top 10 for LLM Applications（OWASP）。プロンプトインジェクションや供給網など、生成AIを組み込んだアプリケーションの弱点の上位10項目。
  • OWASP Top 10 for Agentic Applications（OWASP）。AIエージェントに固有の弱点の上位10項目。エージェントに与える権限と、つなぐツールを見直すときに使う。

出典

掲載した全事案は、国内サイバー攻撃の観測記録で一覧にしている。被害の類型、侵入経路、判定、標的の類型、期間で絞り込め、本文の図やカードの「一覧で見る」はその表を絞り込んだ状態で開く。

各事案の出典は、当事者の発表を優先した。473件のうち28件は報道を出典にしている。

委託先への1回の攻撃が複数の組織へ波及した場合は、起点の組織で1件と数えた。スカラの事案には、大和証券の10月5日の発表と、シチズン時計の10月6日の発表を併記する。東武鉄道の10月7日の発表と岩手銀行の10月6日の発表も、同じ事案の波及先として併記する。IDCフロンティアの事案は、影響を公表したSKE48 Mailとニッスイの発表、および報道で影響先を確認したが、起点の1件で数えている。茨城県は因果関係を調査中とし、小平市とサイバー大学は事業者名を明示していない。さくらの事案への波及は、セーファーインターネット協会の10月2日の発表で確認した。

ALSOKジョイライフは7月31日の初報で計上した。134件の入居者情報が閲覧された可能性を公表し、10月1日の調査結果では、流出を示す事実は確認されなかったとしている。

楽天の会員データ約1億100万件を販売するという投稿は、漏えいの事実を確認できないため集計に含めていない。10月6日のASCII.jpの取材に対し、楽天は漏えいの事実とサンプルに該当するアカウントを確認していないと回答した。楽天ドライブへの不正アクセスとの関連も確認されていない。

各事案の出典を表示する（473件）
調査報告および報道を表示する（31件）

国内サイバー攻撃の観測記録

リサーチのページで開く

表示中473件

2026.10.08アドベンチャー（旅行予約サイト「skyticket」）件数非公表。氏名、生年月日、連絡先、ハッシュ化パスワード東京都渋谷区情報漏えい原因未公表未公表・判定不能

対AIハッキング用脆弱性診断

詳しく見る

ご相談

AIによる攻撃を想定した脆弱性診断、自動診断ツールの利用、その他のご相談は、お問い合わせより承ります。

お問い合わせ
ブログ一覧へ