「AIがついに自分の意思でハッキングを始めた」——2026年7月30日にセキュリティ企業Palo Alto Networksの脅威分析チーム「Unit 42」が公表したレポートは、そんな刺激的な見出しとともに世界に広まった。だが実際にレポートを読み解くと、これは「AIが暴走した」話ではない。むしろ逆で、人間の攻撃者が、安全策の緩いAIをわざわざ選んで悪用したという、AIサービスの設計思想の違いが浮き彫りになった事件だった。SFのような誤解と、実際に起きたことのギャップを整理しておきたい。
460以上のシステムを狙った「ほぼ自動」の攻撃
Unit 42によれば、中国・珠海を拠点とみられる「knaithe」「KnYuan」と名乗る攻撃者は、オープンソースのAIエージェント基盤「Hermes Agent」に中国製AIモデル「DeepSeek」を組み込み、脆弱なサーバーを探して侵入する攻撃パイプラインを構築したと報じられている。Hermes AgentがTelegram経由の遠隔操作や端末操作・実行系を担い、DeepSeekが脆弱性の評価や攻撃対象の選定、攻撃コードの調整といった「判断」を担う役割分担だったという。
司令塔はAI、人間は最初の一言だけ
攻撃者がTelegramで一度指示を送ると、あとはAIエージェントが標的の探索・脆弱性の評価・侵入までを自動でこなす構成だったとみられる。人間が逐一操作するのではなく、AIに任せて「監督者」として離れて見ているだけで攻撃が進む点が、この事件が注目された理由だ。
侵害に成功したのはごく一部
もっとも、狙われた460以上のシステムのうち実際に侵害が確認できたのは限定的だったと報告されている。確認された被害は、Citrix NetScaler機器3件からのデータ窃取（CVE-2026-3055）、分析ノートブック「Marimo」11件でのコマンド実行（CVE-2026-39987）などで、ほかにApache Tomcat（CVE-2026-34486）やWindowsのIKE VPN機能（CVE-2026-33824）など、あわせて7件の既知脆弱性が悪用されたという。数を撃っても大半は失敗しており、「AIによる自動攻撃=何でも突破できる」という話ではない点は押さえておきたい。
なぜDeepSeekだったのか。断ったのはClaudeとOpenAI
この事件で最も興味深いのは、攻撃者が複数のAIサービスを試した形跡が報告されている点だ。報道によれば、攻撃者はAnthropicのClaude Codeや、OpenAIのCodexも設定・試用していたが、実際の攻撃の中核処理には使わなかったとみられる。ClaudeとOpenAI側は、攻撃につながる指示を拒否する安全機構が働き、OpenAI側は該当アカウントを不審なものとして検知したと報じられている。
一方でDeepSeekには、そうした攻撃利用を止める仕組みが組み込まれていなかったとUnit 42は分析している。攻撃者は中国製の他モデル（Qwen、GLM、Kimi、MiniMaxなど）も比較検討していたとみられ、最終的に「制限が少ない」という理由でDeepSeekが攻撃の中核に選ばれたとみられている。
AI各社の安全策に「実戦での効果」があった初の実例
これまでAIの安全機構(ガードレール)は、主に机上のテストや評価ベンチマークで語られることが多かった。今回の一件は、実際の攻撃者が複数のAIを比較した結果として、安全策の有無が攻撃の成否を左右したことを示す実例になったと報じられている。裏を返せば、安全策が緩い、あるいは存在しないAIモデルは、意図せず攻撃インフラの部品として選ばれるリスクを抱えているということでもある。
皮肉な発覚のきっかけ：攻撃者自身の設定ミス
もう一つ見逃せないのが発覚の経緯だ。Unit 42によると、攻撃者が使っていたAIエージェントが、攻撃者自身のホームディレクトリを起点にWebサーバーを誤って公開してしまい、そこにAPIキーや攻撃対象リスト、操作ログ、AIとのやり取りの記録までが露出していたという。攻撃を自動化・効率化するために導入したAIエージェントが、皮肉にも攻撃者自身の運用ミスを助長し、結果として研究者に手の内をすべて見られる形になった。自動化は攻撃者にとっても諸刃の剣であることを示すエピソードといえる。
私たちが受け取るべき教訓
脆弱性管理の重要性は変わらない
今回悪用された脆弱性はいずれも、ベンダーから修正パッチが提供されていたものだったと報じられている。AIによる自動化が進んでも、攻撃の起点は「未対応のまま放置された既知の脆弱性」という基本構造は変わらない。パッチ適用や外部公開資産の棚卸しといった地道な対策が、引き続き最大の防御線になる。
「AIだから危険」ではなく「設計思想の差」を見る
このニュースを見て「AIは何でも悪用できて危険だ」と一括りにするのは早計だ。むしろ焦点は、同じ生成AIでも提供企業ごとに安全設計への投資に差があり、その差が実際の攻撃可否に直結し得るという点にある。今後、企業や開発者がAIエージェント基盤を選ぶ際に、モデル単体の性能だけでなく安全機構の実効性も比較材料になっていくとみられる。
独自の視点｜安全策は「壁」ではなく「コストの上乗せ」として効いたのではないか
ここまでの事実を筆者なりにつなげると、安全機構の性格が見えてくる。攻撃者がClaude CodeやCodexも試したうえで中核処理には使わなかったとされる点と、460以上を狙って実際の侵害はごく一部にとどまった点だ。安全策は攻撃を不可能にしたのではなく、迂回の手間を増やしてより安く済む選択肢へ流れさせたのではないかと考えられる。攻撃者にとってAIは手段の一つに過ぎず、費用対効果の悪い道具は避けられる。安全設計は倫理の話であると同時に経済の話でもあると筆者は見ている。
この見立てが正しければ、安全策の実効性は試験の点数ではなく「どれだけ選ばれなかったか」で語られる展開が予想される。現時点の公開情報からの予想であり、今後の調査次第で変わりうる。
独自の視点｜自動化が増やしたのは「量」であって「質」ではないのではないか
もう一つ注目したいのが、悪用された7件がいずれもパッチの出ていた既知の脆弱性だった点と、攻撃者自身のエージェントが設定を誤って手の内をさらした点だ。両者を重ねると、AIが可能にしたのは新しい突破口の発明ではなく、ありふれた手口の大量反復ではないかと筆者は予想する。しかも自動化は攻撃側の運用ミスまで増幅した。防御側の含意ははっきりしている。目新しい対策より、パッチ適用と公開資産の棚卸しを速く回せるかが効くのではないか。今後の手口の変化次第で、この見方も変わりうる。
よくある質問
Q1. DeepSeekというAIサービス自体が「悪意ある」ということか?
A. そうではない。DeepSeekは通常の用途では多くの開発者・企業に使われている生成AIモデルだ。今回の問題は、攻撃的な指示に対する拒否・検知の仕組みが弱かったために、悪用する側に選ばれてしまったという運用面の課題であり、モデルそのものの善悪の話ではない。
Q2. ChatGPTやClaudeを使っていれば絶対に安全なのか?
A. 「絶対安全」とは言い切れない。今回は攻撃指示を拒否・検知したと報じられているが、安全機構は完璧ではなく、今後も攻撃者側は迂回策を試みるとみられる。ただし今回の件は、安全設計への投資が実際の被害抑止に効果を発揮し得ることを示した点で意味がある。
Q3. 自社のシステムも同様の手口で狙われる可能性はあるか?
A. 可能性はある。今回の攻撃は、インターネットに公開された既知の脆弱性を持つ機器を幅広くスキャンする手法だったと報じられており、特定の業界や企業を狙い撃ちしたものではないとみられる。外部に公開しているサーバーやVPN機器、業務ツールのバージョンを定期的に点検し、パッチが出ている脆弱性を放置しないことが基本的な備えになる。
参考・出典
- Unit 42（Palo Alto Networks）”Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks”
- Tech Times “DeepSeek Ran Autonomous Cyberattacks That Claude and OpenAI Safety Controls Blocked”
- GBHackers “Chinese-Speaking Hacker Uses DeepSeek Agent to Launch Autonomous Cyberattacks”
- BleepingComputer “Hacker uses DeepSeek AI to autonomously attack vulnerable servers”
コメント