「AIのせい」だけでは済ませられない

9月に入ってから、テレビや新聞を騒がせるサイバー攻撃が頻発している。2026年に入ってからサイバー攻撃の質と量が変わったのは確かだと言える。

この変化の背景のひとつにAIの進化がある。すでに、攻撃側がAIを駆使する段階から、AIにすべてを依存するいわば「バイブハッキング」に移行しつつある。対する防御側もAIを最大限に活用した、プロアクティブな対策が求められている。

テレビや新聞ならば、「AIのせい」で終わらせるかもしれないが、現場でセキュリティ対策を実践するエンジニアやCISOはそうはいかない。もっと解像度を上げた分析を行わないと、有効な対策がとれないからだ。

量的変化:攻撃数は増加傾向が続く可能性

警察庁の「令和8年度上半期におけるサイバー空間をめぐる脅威の情勢等について」では、脆弱性探索とみられる不審なアクセスが前同期比で50%以上も増加しているとする。ランサムウェア被害報告については、昨年上期が116件だったのに対し、2026年上期は123件を記録し、通年では過去数年の統計(220件前後)を上回る可能性がある。

脆弱性探索行為等の不審なアクセス件数(警察庁「令和8年度上半期におけるサイバー空間をめぐる脅威の情勢等について」)
ランサムウェアの被害報告件数(警察庁「令和8年度上半期におけるサイバー空間をめぐる脅威の情勢等について」)

トレンドマイクロが公開している数値では、2025年の公表インシデント数594件に対し、2026年は1月から9月現在で607件となっている。

この手の統計情報は、あくまで報告や届け出があった件数であり、実際の被害件数とは必ずしも一致しない。また、ニュース報道は、ひとつ話題となった事件がおきると類似事件を続けて取り上げる傾向がある。別の側面では、大手企業による被害発表が相次ぐことで、被害公表の心理的ハードルが下がる影響も無視できない。もっとも、サイバー攻撃に関する適切な情報公開、情報共有は防御側にとってもプラスに働くので、公開そのものが悪いわけではない。問題は無責任なメディア報道、SNS投稿だ。

統計や報道の解釈には注意が必要だが、サイバー攻撃、インシデントの「量」はしばらく増加傾向が続くとみられる。

質的変化:狙いや攻撃よりもアタックサーフェスの変化に注意

では「質」の変化はどうだろうか。AIによる影響はあると言ってよさそうだが、実際の攻撃事例や被害状況を比べてみないと、必要な対策、効果的な対処につながらない。

全体の分析は年が終わらないとできないので、ここでは直近で起きた大きなインシデントのうち、メディアでも大きく取り上げられたものに的を絞って分析する。

まず、さまざまなインシデントを分析する指標として、JPCERT/CCが2026年10月23日付で公開した「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」で分類された攻撃手法のケースAからEを利用する。

ケースA:既知の脆弱性と設定不備による被害
ケースB:API経由の不正操作
ケースC:Metabase SQLインジェクション
ケースD:アプリサーバーへのWebシェル設置
ケースE:AIペンテスト基盤の悪用

これらはどれも「不正アクセス」の手段、経路についてまとめたものだが、直近の被害は、不正アクセスからランサムウェア攻撃、情報漏洩、脅迫、詐欺、不正送金など実害に結び付いている。

※JPCERT/CCの公開資料をもとに筆者作成

フィッシングメールや添付ファイルによるアカウント窃取、情報窃取も、依然としてリアルな問題で減ってはいない。昨年までは脆弱性攻撃よりもフィッシングやクラウドの設定ミスによるアカウント奪取やなりすましが攻撃の主流を占めていたが、おそらくAI活用による脆弱性攻撃やハッキングによる不正アクセスが再び勢いを増そうとしている。

直近のインシデントはどのケースに分類されるか

質的変化をもう少し詳しく見ていこう。

それぞれのケースについて、ここ数か月で公開、またはメディア報道されたインシデントはどれに当てはまるかを示したのが次の表だ。ただし、どのインシデントがどのケースに当てはまるかは、筆者が各社のリリース情報などをもとに判断したあくまで一例である。各社、各機関がこのケースに相当すると発表または認めたものではない。内容については、組織、研究者ごとに解釈が成立するという点に注意してほしい。

※該当する事案はあくまでも一例(確定情報ではない)

ケースAからCは、注意喚起を発表した当初JPCERT/CCが分類したパターンである。DとEはおよそ2週間後に追記されたものだ。DとEについては、更新されたタイミングから、Dはパッチが緊急公開されたPHPに関するもの、あるいはPHPの脆弱性に関連して発生した事案に対するものという捉え方もあるが、TomcatなどWebのアプリサーバーやWARファイルに関する言及は、PHPの脆弱性とは関係なく、古いPHPに関する既知の脆弱性に属するものだ(Tomcat Managerの脆弱性を利用してシェルセッションを奪うといったPHP5の脆弱性など)。

Eの事例では、GMOお名前.comクラウドデスクトップに行われた不正アクセスとの関係も疑われるが、AIテンペスト基盤(ARTEX)に関する注意喚起であり、現在のところ、この利用が確認され公開されたのはGMOイエラエが発表したGMOリサーチ&AI InfoQの事例のみである。そして、これはWebアプリの脆弱性が利用された事案であり、API経由の不正操作(ケースB)に分類すべきものと考える。GMOお名前.comクラウドデスクトップの不正アクセスについて、2026年11月2日現在、ARTEXが利用された(ケースE)という情報はない。

アタックサーフェスからさらに手口を分析

これら直近の事例からアタックサーフェス(攻撃面)や手口を分析すると、AI前提であることの他に攻撃にいくつかの特徴があることがわかる。

まず、全体の傾向として脆弱性を突くというより管理不備、設定の不備を突いた攻撃が目立っている。また、API経由でアプリやシステムの不正操作を行う攻撃も同様だ。特定システムの脆弱性を突いた攻撃(BIツールMetabase:ケースC)も過小評価すべきではないが、これも手口の変化を指摘できる。これまでのように脆弱性情報をベースにした全方位的(対象バージョンを利用しているシステム全体に有効な攻撃コード)な攻撃ではなく、事業者のシステムごとの脆弱性をピンポイントで突いてくる攻撃だ。AIによる詳細かつ自動的な偵察や内部探索がなせる業といえるだろう。

なお、PHPの脆弱性が公開されたが、この脆弱性を狙った攻撃トラフィックが確認されたくらいで、現時点でこれが原因と特定された攻撃事例、被害事例の情報はない(筆者調べ)。

API経由の攻撃では、NICTが「A2B(App to Backend)攻撃」と命名した攻撃パターンも確認されている。A2B攻撃は、Androidアプリが通信するサーバーについてAPIの構成、パラメータ、応答データを調べて、接続先サーバーに特化した攻撃をしかけるというもの。iOSでも原理的には適用可能である。A2B攻撃は、JPCERT/CCのケースBのうち、実際に確認された攻撃のひとつだと言える。

委託先、サプライチェーンが攻撃された事例もある。VPN経由で侵入されたという発表もある。したがって、脆弱性攻撃の仕方、設定の不備の利用などの変化はみられるものの、従来からのVPNやリモートデスクトップ、メールやクラウドサービスなどのアタックサーフェスは依然として狙われている認識が必要だ。

また、平均的な攻撃者がAPT並みの内部探索、横展開、長期潜伏をみせるようになった現在、保有するデータのリスクを再評価するべきである。不要な情報、維持コストに見合わない個人情報(生体情報、機微情報)は、インシデント時のインパクトを増大させる。

対策ポイントの考え方は変わらない

最後に、ケースごとの対策ソリューションを考えてみたい。

ケースAは、既知の脆弱性や管理不備・設定不備による被害だ。このような被害に対する備えとしては、攻撃面の洗い出しと管理のためASM/EASMで外部公開資産を棚卸しする。既知の脆弱性に対しては、脆弱性管理とパッチ適用の迅速化を図る。WAFによる仮想パッチという方法もある。設定ファイルについては、CSPM(ポスチャマネジメント)による設定監査・管理を行う。バックアップデータは公開領域から排除することも考えたい。

ケースBはAPI経由の不正操作である。まず、APIゲートウェイでの認証・認可を強制するなどの強化策がある。同様に、エンドポイントごとのアクセス制御を見直す。アクセス範囲や頻度にレート制限を行う。ログイン・パスワードリセット・SMS送信・検索なども個別管理をしたい。WebアプリケーションのAPIに対して、不正なアクセスや脆弱性の自動検出テスト(DAST/BOLAテスト)を行う。アプリトークンの最小権限化、有効期限管理も重要だ。アプリに鍵情報を埋め込まないシークレット管理、アプリ自体の検証(Play Integrity/App attest)も確認しておきたい。

ケースCは、Metabaseの脆弱性の話なので、Metabaseの更新は必須だ。これを機にBIツールのインターネットへの公開を停止する。ゼロトラストネットワークに認証システム(IdP)を実装する。DBアカウントの権限見直し。汚染痕跡(IOC)の確認なども有効だ。

ケースDはアプリサーバーにWebシェルが設置されるという攻撃だ。典型例はTomcat Managerなどの管理機能を利用されるパターンだ。そのため管理機能の無効化、非公開化は効果がある。デプロイ経路や方法の制限、ファイル改ざん検知(FIM)、サーバーEDRの導入により、異常な操作、不審な操作を検知する。外部との通信も監視し、横展開を検知、阻止するソリューションを検討する。

ケースEは、Caim、CyberStrikeAI、ARTEXといったAIペネトレーションテスト基盤を悪用するパターンだ。WAFの中にはボットやAIエージェントを検知できるものがある。これらを利用する対策がある。IPレピュテーションによるアクセス制御、レジデンシャルプロキシの検知、悪性通信のブロックとログの精査もボット、AIエージェントの検知に役立つ。WSUSなどの管理系サーバーは公開しない。ボットやエージェントに対しては、囮やダミーデータを設置するサイバーデセプションも近年注目されている技術だ。

以上をまとめると、攻撃面の変化、手口の変化は見て取れるものの、相手の狙いは大きく変わっているわけではない。したがって、対策ソリューションも原則は同じはずだ。ニュースやSNSの情報に惑わされず、被害と攻撃手法を冷静に分析して、それぞれの対策、対応をしっかり行いたい。

ケースごとの対策ソリューション