AI最新情報読了 6 分

AIが24時間休まず弱点を探す攻撃用サーバー、世界に約1,000台をJPCERTが確認

Shiritomo編集部 @shiritomoAI_jp 2026年11月15日更新

世界のどこかで、人の手を離れたまま夜も休まず動き続けるサーバーが、少なくとも1,000台近くあります。
中を調べると、ウェブサイトの弱点を探し出すためのAIツールが入っていました。

日本のJPCERTコーディネーションセンターが、10月から海外のセキュリティ企業と連携してこの実態を調査してきました。
分かってきたのは、以前は専門知識や時間が必要だった不正アクセスが、AIの力で誰にでも実行しやすくなりつつあるという話です。
自分でサーバーやアプリを運用している人はもちろん、個人でサイトを持つ人にとっても無関係ではありません。

先に結論をまとめると：
– JPCERTコーディネーションセンターが10月上旬から各国のセキュリティ企業と調査し、AIで脆弱性を探索・侵入を試みるサーバーを世界で約1,000台確認した
– 発見されたサーバーの中には、アプリ解析ツールの痕跡があり、海外メディアによれば本来は開発者向けのAnthropic製プログラミング支援ツールの痕跡も見つかったとされ、AIが偵察から攻撃補助まで使われていたとみられる
– JPCERT/CCは、認証情報をアプリに埋め込まない・サーバー側の認証を強化する・APIアクセスを監視するといった、開発者・運用者向けの対策を呼びかけている

何が起きたのか

JPCERTコーディネーションセンター（東京）は2026年10月上旬から、海外のサイバーセキュリティー企業と協力して調査を進め、11月14日までに世界のインターネット上で少なくとも約1,000台のサーバーが、AIを悪用した攻撃の拠点になっている疑いがあると明らかにしました。
海外メディアの報道では、このうち600〜700台を継続して追跡しているとも伝えられています。

調査チームは、捕捉できたファイルの構成やAIツールの稼働状況を分析。
対象のサーバーは国内外のウェブサイトを標的に、AIを使って弱点を探索し、不正侵入を試みていた痕跡があったといいます。
サーバーは専用の設備で構築されたものだけでなく、クラウドのような仮想環境で運用されているケースもあったとのことです。

この調査のきっかけになったのが、JPCERT/CCが10月8日に公表した、国内の複数組織で相次いだ不正アクセス事案でした。
そこから浮かび上がった攻撃手口の中身を、もう少し詳しく見ていきます。

調べて分かったこと

なぜAIが攻撃のハードルを下げたのか

JPCERT/CCの技術ブログでは、実際に捕捉した3台の攻撃用サーバーの中身が報告されています。
あるサーバーには、スマートフォンアプリ（APKファイル）を解析するためのツール「Blutter」「jadx」が入っており、アプリの内部構造を自動で読み解いて、外部に公開されていないAPI（アプリ同士がデータをやり取りする窓口）を突き止める目的で使われていたとみられます。

別のサーバーでは、Pythonスクリプトを使ってSSRF（サーバー側リクエスト偽造：外部から送り込んだ命令でサーバー自身に不正な通信をさせる手口）の脆弱性を自動で試す仕組みが見つかりました。
さらに3台目では、Webサーバーやデータベース（MySQL）、開発用サーバー（Jenkins）を狙った攻撃や、検知を逃れるための痕跡隠し（EDR回避）の形跡も確認されています。

これまでアプリの内部構造を解析して突破口を探すには、相応の専門知識と時間が必要でした。
それをAIが肩代わりすることで、作業のスピードと規模がこれまでとは桁違いになっている、というのが今回の調査が示している部分です。

侵入用サーバーの中に、開発支援AIの痕跡も

今回の調査で目を引くのが、海外メディアの報道によると、攻撃用サーバーの中からAnthropic製のプログラミング支援ツールの痕跡が見つかったという点です。
本来は開発者の作業を助けるためのAIが、攻撃用コードの作成や調整にも転用されていた可能性がある、ということになります。

海外メディアの報道によると、JPCERT/CCのアナリスト、ケン・サジョ氏（佐條研氏）は、AIがサイバー攻撃に使われ始めたのはまだ初期段階で、今後さらに手口が巧妙化していく可能性があると指摘しています。
便利な開発ツールと攻撃用ツールの境界線が、使う側の意図でしか分けられなくなってきているということでもあります。

個人や中小企業も対策が必要なのか

ここは慎重に見る必要があります。
JPCERT/CCが実際に呼びかけているのは、秘密鍵や認証情報をアプリに埋め込まないこと、サーバー側の認証・認可を強化すること、APIへの不正な呼び出しを監視し、アクセス数に制限（レート制限）をかけること、SSRF対策としてサーバーがアクセスできる外部の範囲を制限することです。

いずれもアプリやウェブサービスを作る側が見直すべき、開発寄りの対策です。
「ソフトウェアを最新版に保つ」「多要素認証を使う」といった一般的な心がけも無駄にはなりませんが、今回のJPCERT/CCの発表が中心に置いているのは、あくまでアプリ・サーバーを提供する側の設計の甘さだという点は押さえておきたいところです。

Shiritomo編集部の考察：明日からやることは2つ

今回の話は「攻撃者がすごい」で終わらせない方が良さそうです。
Claude CodeのようなAI開発支援ツールは、今やSNS運用者や個人開発者でも日常的に使う存在になりました。
同じ自動化の力が、サーバーの脆弱性探しやAPI解析にもそのまま使えてしまう以上、「自分は狙われるほどの規模じゃない」という前提は崩れつつあります。

実務的にやることは2つです。
1つは、自分や自社が運用しているAPIやLP（ランディングページ）に、認証情報をコードへ直書きしていないか確認すること。
もう1つは、外部から大量アクセスが来てもサーバーが音を上げないよう、レート制限や監視の仕組みを最低限入れておくことです。
どちらもエンジニアでなくても、担当者に確認を依頼できる範囲の話です。