第１ 無差別な探索と個別の攻撃を分けて考える
１ 自社が有名でなくても点検が必要な理由
AIを悪用したサイバー攻撃では，情報の収集や解析が効率化され，多数のシステムを調べた上で，見付かった弱点に合わせた攻撃が行われる危険がある。
「無差別に探されること」と「自社の仕様に合わせて攻撃されること」は，両立する。
会社の知名度だけを理由に，攻撃対象にならないと考えることはできない。
本記事では「無差別」を，特定の一社に限らず広く対象や弱点を探すという意味で用いる。
全ての会社が同じ手法で攻撃されたことや，AIが一連の操作を全自動で実行したことを意味しない。
以下は令和８年１０月１８日までに確認した公表資料に基づく説明である。
２ AIを使った攻撃とAI自体への攻撃
国家サイバー統括室のサイトに掲載されたIPA担当者のコラムは，AIの悪用により従来の攻撃の速度や量が増す問題と，AI自体が攻撃対象になる問題を分けている。
前者には詐欺メールの作成や攻撃の効率化があり，後者には外部の文章を通じてAIに不適切な指示を与える間接プロンプトインジェクションなどがある。
本記事の中心は前者であり，社内で生成AIを使っていない企業にも関係する。
第２ AIは無差別サイバー攻撃にどう関係するのか
１ 調査や解析の効率化が攻撃対象を広げる
AIは，攻撃者が情報を読み解き，プログラムや通信の仕組みを調べる作業を助ける場合がある。
NICTは，AIの活用によってアプリの解析や脆弱性の発見が効率化され，攻撃がより多くのシステムに広がる可能性に注意を促している。
これは攻撃が広がる仕組みの説明であり，国内の全ての漏えい事案についてAI利用が実証されたという意味ではない。
また，広い範囲を自動で探索する攻撃と，AIの利用は同じ概念ではない。
アクセスが大量又は高速であるという事情だけで，AIが使われたと断定しないことが必要である。
IPA担当者の同コラムも，攻撃の様子だけからAIとの関わりを判別できないのが通例であると説明している。
２ 一般的なスキャンと対象別の解析
JPCERT/CCの令和８年１０月８日公開・２３日更新の注意喚起は，さまざまな既知の脆弱性を探索するケースと，API経由で不正な操作を行うケースなどを挙げている。
同資料は，把握している情報が限定的・断片的であり，全ての事案が同じ攻撃手法によるものではないと留保している。
したがって，最近の被害を一つの原因にまとめず，自社の構成と記録に照らして点検する必要がある。
JPCERT/CCは，令和８年１０月２３日の更新で，Cairn，CyberStrikeAI及びARTEXなどのAIを用いたペネトレーションテスト基盤を悪用した攻撃試行を，ケースEとして追加した。
主に公開Webアプリケーションの脆弱性や管理不備を狙うもので，公開WSUSサーバーを標的とした試行も含まれると説明している。
これは，国内のすべての漏えい事案がARTEXや同じ攻撃者によるものだと認定したものではない。
AIモデル，攻撃基盤及び攻撃者の区別と，韓国向け・国内向け・ConnectWise関係の各報告の違いは，ARTEXとは―AIサイバー攻撃の仕組みと企業が確認すべき対策で扱う。
３ AIワームと従来型ワームの違い
従来型ワームは，あらかじめ組み込まれた探索・侵入・複製の処理を多数の機器へ広げる。
これに対し，AIエージェントが対象ごとに解析又は攻撃手順を変える場合と，AIモデル自体が機器間を移動して推論資源を集める場合は，分けて考える必要がある。
Anthropicが令和８年１０月に公表した実験は，市販のテレビ端末等を使った分散推論，異なる機器への推論環境の構築及び隔離環境での簡略化した伝播を示したものであり，家庭の機器へ無差別に侵入する完全なAIワームが現実に確認されたというものではない。
実験条件，将来予測の限界，日本法上の問題及びスマート家電の対策は，AIワームとは―スマート家電を乗っ取る「デジタル粘菌」は実現したのかで詳しく整理している。
現在確認されている家庭用IoT機器の犯罪利用は，レジデンシャルプロキシとは―家庭用IoT機器が犯罪の踏み台になる仕組みと対策を参照されたい。
第３ 公開アプリから裏側のサーバを狙うA2B攻撃
１ アプリの解析から接続先を調べる
NICTは令和８年１０月１３日，国内で相次ぐ情報漏えい事案の原因の一つとして，公開Androidアプリの解析結果を悪用して接続先のサーバを攻撃するA2B攻撃を特定したと公表した。
攻撃者はアプリが通信する接続先やAPIの仕組みを調べ，その情報を基に対象のサーバに合わせた攻撃を行う。
APIとは，アプリとサーバなどが情報をやり取りするための仕組みである。
アプリ自体に脆弱性がなくても，裏側のサーバの認証・認可や入力値の検証に不備があれば，不正アクセスにつながるおそれがある。
「接続先を一般には知らせていない」「正規の画面には操作ボタンがない」という事情だけでは，安全性を判断できない。
NICTは，同様の問題がiOSアプリやWebサービスのバックエンドAPIにも生じる可能性を指摘している。
２ 個別事件でAIが使われたかは別に確認する
A2B攻撃という手法の確認，AIによる解析効率化の可能性，特定の被害でAIが使われたという認定は，それぞれ別の判断である。
被害件数や攻撃速度だけから，特定のAIサービス，実行者又は侵入経路を決め付けない。
調査で確認できた記録と，専門家の推定，確認できない事項を分けて説明することが大切である。
第４ 企業が点検する対策
１ 公開範囲とAPIの権限を確かめる
最初に，外部から接続できるWebサイト，アプリの接続先，管理機能及び委託先のサービスを把握する。
JPCERT/CCは，一般利用者向けではない従業員用システムやBIツールも被害に遭う場合があると注意している。
担当部署の認識だけでなく，開発・運用の委託先にも実際の公開範囲を確認することが実務上の出発点となる。
APIごとに，誰が，どのデータに，どの操作をできるかを点検する。
必要最小限の権限，トークンの有効期限と無効化，アクセス回数の制限，不要な機能の公開停止，更新の適用及び検知体制を組み合わせる。
NICTが示す「侵害の確認」「脆弱性の点検」「暫定的な緩和策」を，自社の構成に応じて具体化する必要がある。
２ AI向け製品の導入だけで対策を終えない
AIを悪用した攻撃が増えても，従来の対策が無意味になるわけではない。
IPA担当者の同コラムは，従来の対策が引き続き有効であり，AIを取り囲むIT環境や日常の運用も成否に関わると説明している。
製品名だけで安心せず，更新，権限，公開範囲，ログ及び初動の担当が実際に機能するかを確認する必要がある。
点検表や委託契約まで詳しく確認したい場合は，個人情報保護委員会が示した不正アクセス９類型及び企業の個人情報漏えい・不正アクセスに備える法務対応を参照されたい。
３ 脆弱性対応を担当・期限・再確認までつなぐ
点検では，機器やサービスの一覧と，ベンダーが公表する脆弱性・更新情報を対応付ける。
対象の機能・設定，外部からの到達可能性，悪用の情報及び業務への影響を技術担当者が確認し，対応の優先順位を決めるとよい。
AIによる探索を利用する場合も，見付かった指摘をそのまま確定事項とせず，影響範囲と誤検知を確認する担当を置く。
発見事項ごとに，修正する者，適用の予定日，間に合わない場合の暫定措置及び修正後の確認方法を記録する。
委託先が保守するサービスについては，自社の担当者だけを決めるのでなく，委託先の窓口，作業依頼の方法及び結果を受け取る期限まで具体化する。
侵害の疑いがある場合の証拠保全・隔離と，侵害の兆候がない環境での予防的な更新は，状況に応じて調整する。
IPAが公表したSCS評価制度の資料も，更新プログラムの適用，やむを得ず遅れる場合の対応計画及びリスク低減策を扱っている。
ただし，制度上の「１４日以内」は対象と条件を伴うものであり，全ての会社・脆弱性についての一律の法定期限と説明すべきではない。
ここで示した管理表や担当の割当ては，これらの資料を踏まえた実務上の提案である。
SCS評価制度の期限と委託契約への具体化は，SCS評価制度の契約実務―★３・★４の取得，脆弱性対応期限及び委託先管理で整理している。
出典：IPA・SCS－４１０「★３・★４ 自己評価等ガイド」評価基準No.４－４－４－２（９０頁～９２頁），SCS－６２０「★３・★４ 要求事項・評価基準 解説書」（９２頁～９４頁）。
公式掲載ページ
第５ 被害が疑われたときの調査と法務対応
１ AI利用の特定を待たずに対応する
被害が疑われる場合は，社内の連絡体制を動かし，技術担当者と隔離・保全の手順を調整する。
確認した事象，時刻，対象の機器・アカウント，影響するデータ及び未判明事項を記録する。
AIが使われたかを先に決めようとして，必要な調査や報告・通知の検討を遅らせないことが実務上重要である。
報告や本人通知の要否は，AI利用という名称だけでなく，対象データ，発生した事象及び適用される制度に即して判断する。
調査資料の読み方はフォレンジック調査報告書と漏えい評価，組織内の準備と対応は企業の法務対応の記事で詳しく扱っている。
２ 対外説明の断定を調査の範囲に合わせる
「AI攻撃だった」「データは流出していない」と説明するときは，その根拠となる記録と調査の対象範囲を確かめる。
確認済みの事実，提供者の説明，推定及び不明事項を分け，追加の調査で説明が変わる場合の更新方法も決めておくとよい。
これは公表文の作成に関する実務上の提案であり，特定の事故の責任や漏えいの有無を認定するものではない。
第６ よくある質問
１ AIとサイバー攻撃の関係は？
AIは，攻撃者による文章作成や解析の効率化に悪用される一方，防御側の監視や対応にも利用される。
AI自体が攻撃される場合もあり，それぞれ対策の対象が異なる。
AIを業務で使っていない会社でも，攻撃者側のAI利用による影響は受け得る。
２ AIを使うとサイバー攻撃はなぜ広がるのか？
解析や弱点の探索に必要な作業が効率化されると，より多くのシステムを調べられる可能性があるためである。
ただし，無差別な探索が全てAIによるとは限らず，攻撃の速さだけからAI利用を認定することもできない。
特定の事業者が公表した悪用事例は，AnthropicのAI悪用報告書を整理した記事で，公表主体と確認の限界を分けて扱っている。
３ AIに入力してはいけない情報は？
パスワードやAPIキー，顧客・依頼者の個人情報，未公表の契約・事件情報などは，利用するサービスの契約・設定と，入力する権限を確認せずに送信しない。
個人情報保護委員会は，個人情報を含む入力と利用目的の関係や，個人データが回答以外の目的で取り扱われるかの確認について注意を促している。
具体的な確認事項は，企業の法務対応の記事を参照されたい。
４ AIを使わないほうがいい場合はあるか？
入力する権限や情報の取扱条件を確認できない場合，機密情報を含む作業にそのまま使うことは避ける必要がある。
外部システムの操作まで任せる場合は，AIに与える権限と，人が確認する範囲も検討する。
一律に利用をやめるという結論ではなく，情報・目的・権限に応じて利用方法を選ぶことが実務上の提案である。
５ AIによる攻撃と量子コンピューターによる暗号解読は同じか？
仕組みが異なる。
本記事で扱うAIの悪用は，情報収集，プログラム解析又は攻撃手順の作成などを効率化する問題である。
これに対し，量子計算の問題では，十分な能力を持つ量子コンピューターが実現した場合に，RSAや楕円曲線に基づく暗号技術の安全性を支える問題を解けることが懸念されている。
量子技術の発表を，現在の個別の情報漏洩が量子計算によって起きた証拠として扱うことはできない。
NISTは，耐量子暗号の解説で，将来の量子計算に備える暗号技術への移行を説明している。
企業は，現在の脆弱性，設定不備及び認証情報の窃取への対策を続けながら，長期に秘密を守る必要がある情報と，更新に時間のかかる暗号の利用箇所を把握することが考えられる。
量子計算の能力，暗号方式の違い及び準備の順序は，量子コンピューターで暗号は破られるのか―耐量子暗号と企業の備え（AI作成）を参照されたい。
第７ 出典
①NICT「相次ぐ情報漏えい，その原因の一つは『アプリ解析からのサーバ攻撃』」（令和８年１０月１３日）。
https://www1.nict.go.jp/press/2026/10/13-1.html
②NICT CYNEX「相次ぐ情報漏洩，その原因の一つは『アプリ解析からのサーバ攻撃』」（令和８年１０月１３日）。
本記事では案内ページの説明を参照している。
https://cynex.nict.go.jp/library/261013-01.html
③JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（令和８年１０月８日公開，２３日更新）。
https://www.jpcert.or.jp/at/2026/at260030.html
④国家サイバー統括室掲載，IPA担当者「AIがサイバーセキュリティに与える影響」（２０２６年サイバーセキュリティ月間寄稿コラム）。
https://security-portal.cyber.go.jp/cybersecuritymonth/2026/column/c04.html
⑤個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和５年６月２日）。
https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf
⑥Anthropic「AI models may be capable of self-replicating without access to a datacenter」（令和８年１０月１２日）。
https://www.anthropic.com/research/self-replicating-ai
⑦NICT「家庭用IoT機器を悪用するレジデンシャルプロキシの現状をまとめたファクトシートを公表」（令和８年７月２１日）。
https://www.nict.go.jp/press/2026/07/21-1.html
⑧IPA「SCS評価制度 ★３・★４ 自己評価等ガイド」（SCS－４１０）及び「★３・★４ 要求事項・評価基準 解説書」（SCS－６２０）（令和８年１０月３０日確認）。
https://www.ipa.go.jp/security/scs/requirements-criteria.html
⑨NIST「What Is Post-Quantum Cryptography?」（令和８年２月２７日更新）。
https://www.nist.gov/cybersecurity-and-privacy/what-post-quantum-cryptography