🕵️ 使ってるAIツール、安全機能があるから大丈夫って言い切れる？｜中国ハッカーがDeepSeekで460件に自律攻撃した話
アイ
目次
使ってるAIツール、安全機能があるから大丈夫って言い切れる？
みんな、2026年7月30日に公表されたこのニュース、正直かなりゾッとしたから聞いてほしいの。中国・珠海拠点とみられるハッカーが、AIモデルDeepSeekを自律型の攻撃フレームワークに組み込んで、460以上のシステムに自律的にサイバー攻撃を仕掛けていたことが分かったんだよね。
しかもこの攻撃、人間がずっと張り付いて指示を出し続けていたわけじゃないの。Palo Alto Networksの脅威分析チームUnit 42によると、攻撃者がTelegramで最初の指示を1回送っただけで、あとは標的探しからエクスプロイトの実行まで、AIがほぼ自律的にこなしていたんだよね（Unit 42）。
わたし最初にこの数字を見たとき「460件ってどういうスケール感なの」って思わず二度見しちゃったの。確認された侵害だけでも14件、Citrix NetScalerからのデータ窃取が3件、Marimoノートブックへのコマンド実行が11件も含まれてるんだよね。
しかもこの一件、単に「AIが悪用された」で終わる話じゃないの。攻撃者がなぜDeepSeekを選んだのか、なぜClaudeやOpenAIのモデルは限定的にしか使われなかったのか、そこにわたしたちが普段AIツールを選ぶときにも通じる、けっこう大事なヒントが隠れてると思うんだよね。
今日はこの事件の中身をちゃんと解説しながら、なんでこれが一つの事件で終わらない話なのか、わたしなりに考えてみたいと思う🕵️
そう考える5つの理由
理由1：たった1回のTelegram指示のあと、あとは全部AI任せだった
まず1つ目の理由。今回の事件でわたしが一番衝撃を受けたのが、攻撃者の関与の少なさなの。攻撃者は「knaithe」「KnYuan」という名前で活動していて、自分では「バイナリセキュリティ研究者」と名乗っているんだけど、実際にやっていたことはかなり本格的な自律攻撃だったんだよね（Unit 42）。
世間では「AIを使ったサイバー攻撃」って聞くと、まだ「AIが攻撃の一部を手伝う」くらいのイメージを持ってる人が多いと思うの。フィッシングメールの文面を作らせるとか、コードの一部を書かせるとか、そのくらいの補助的な使い方をイメージしちゃうよね。
でも今回わたしが驚いたのは、その関与のレベルが全然違ったということなの。攻撃者はオープンソースの自律型フレームワーク「Hermes Agent」にDeepSeekを組み込んで、Telegram経由で最初の指示を1回送っただけ。なぜこれが重大かというと、Unit 42のセッション記録を見る限り、それ以降のシステム列挙・公開エクスプロイトの選定・脆弱性の悪用まで、追加の操作者入力がほとんど見当たらなかったから。これが理由1だよ。
具体的には、攻撃対象は460以上のシステムに及んでいて、悪用された脆弱性はn8n（CVSS 10.0）やLangflow（CVSS 9.8）を含む7つの経路・8件のCVEにわたっているの。人間がひとつひとつ標的を選んで攻撃コードを書いていたら、これだけの規模をこなすのにかなりの時間と人手がかかったはずだよね。それを「最初の指示1回」でここまでの規模までスケールさせられてしまったというのが、今回の一番の恐ろしさだと思うの。
わたしがこれを見て思ったのは、AIエージェントの「自律性」って、便利に使えば使うほど攻撃側にとっても効率化のツールになってしまうということなの。良い使い方も悪い使い方も、同じ技術の上に乗っているというのが、正直かなり怖いポイントだよね。
理由2：攻撃者は"安全機能が弱いから"という理由でDeepSeekを選んでいた
2つ目の理由。今回の件でわたしが一番「なるほど、そこか」と思ったのが、攻撃者がDeepSeekを選んだ理由なの。Unit 42のレポートでは、攻撃者は「クライアント側の制限がないオープンソースフレームワークを通じてアクセスできる、安全機能が最小限のモデル」としてDeepSeekを選んでいたと分析されているんだよね（Unit 42）。
世間では「悪用できるAIモデルなんて、どれも似たようなものでしょ」というイメージを持ってる人もいるかもしれないの。AIモデルってどれも同じような賢さで、同じようなガードレールがついてるものだと思われがちだよね。
でもわたしが今回のレポートを読んで実感したのは、モデルごとの安全機能の設計に、攻撃者から見ても分かるくらいの明確な差があるということなの。なぜこれが大事かというと、攻撃者は行き当たりばったりでDeepSeekを使ったんじゃなくて、複数のモデルを比較検討したうえで、意図的に選んでいたから。これが理由2だよ。
面白いのは、攻撃者がClaude CodeやOpenAIのCodexも実際に触っていた形跡があるってことなの。ただしClaude Codeについては、セッション履歴を見ると接続テストとnpmインストール1回程度の、ごく限定的な使い方にとどまっていたんだよね。Codexについては応答の保存を無効化する設定にしたうえで、プロキシ経由でアクセスしていたことも分かってるの。つまり攻撃者自身、Western製のモデルには何かしらの制約や検知リスクを感じていて、それを避けるように動いていたと読み取れるんだよね。
わたしはこれを読んで、モデルを選ぶ側の視点が完全に「安全機能をどう回避するか」になっていることに、あらためて怖さを感じたの。わたしたちが便利さや性能でAIツールを選ぶのと同じように、攻撃者側も「どのモデルが一番都合よく使えるか」を天秤にかけて選んでいる。その基準が「安全機能の強さ」の裏返しになっているというのが、今回の話の本質だと思うんだよね。
理由3：OpenAIの安全機能はちゃんと機能していた、でもそれで終わりじゃない
3つ目。ここは今回の件でちょっと救いがあるパートなんだけど、同時に考えさせられるポイントでもあるの。攻撃者がCodexを限定的に使おうとした際、実はOpenAI側の安全機能はちゃんと仕事をしていたんだよね。
世間では「AIの安全機能なんて、結局は破られるためにある」みたいな、ちょっと諦めムードの声も聞くことがあると思うの。実際、脱獄（ジェイルブレイク）の話題はSNSでもよく見かけるよね。
でもわたしが今回の件で「ちゃんと効いてるじゃん」と思ったのは、OpenAIがUnit 42に対して「自社の安全機能がポリシー違反のリクエストを拒否したことを確認した」と回答している点なの（Unit 42）。なぜこれが重要かというと、攻撃が続いたことを受けて、OpenAIは今回のキャンペーンに関連すると見られるアカウントを検知して無効化したとも説明しているから。これが理由3だよ。安全機能は「拒否する」だけじゃなくて、「拒否され続けたアカウントを見つけて止める」というところまで機能していたということなんだよね。
ただ、ここで話が終わらないのがこの事件の厄介なところなの。攻撃者はOpenAIやClaudeで拒否されたからといって攻撃自体を諦めたわけじゃなくて、単純に「制限の緩いモデル」に乗り換えて攻撃を続行しただけなんだよね。つまり安全機能がしっかりしているモデルが1つあっても、業界全体として見ればそれをすり抜けるルートがどこかに残っている限り、攻撃自体は止まらないということなの。
わたしがこれを見て思ったのは、AIの安全性って「一社が頑張ればいい」という話じゃなくて、業界横断で足並みを揃えないと意味が薄れてしまう性質のものなんだということ。1社だけがガードレールを固めても、緩いモデルが他にあれば、そっちに攻撃者が流れていくだけなんだよね。この構造は、今後もAIの安全性を考えるうえでずっとついて回る課題だと思う。
理由4：発覚のきっかけは、攻撃者自身のうっかりミスだった
4つ目の理由。実はこの大規模な攻撃キャンペーンが発覚したきっかけって、Unit 42が優れた検知システムで見つけ出したわけじゃなくて、攻撃者自身のちょっとしたミスだったんだよね。
世間では「これだけ大規模な攻撃が見つかるってことは、セキュリティ企業がすごい監視網を張ってるんだろうな」って思われがちだと思うの。ハリウッド映画とかだと、専門家が高度な解析でハッカーを追い詰めるシーンをよく見るよね。
でもわたしが今回一番「あ、そういうオチなんだ」と思ったのは、発覚のきっかけがすごく地味だったこと。Hermes AgentがTelegramからの指示に応じてHTTPファイルサーバーを起動した際、サンドボックス化されたディレクトリではなく、攻撃者自身の作業ディレクトリ「/home/worker」から起動してしまって、設定ファイルやAPIキー、エクスプロイトスクリプト、セッションログまでまるごと外部に公開されてしまったんだよね（Unit 42）。なぜこれが重要かというと、攻撃者側の「自律化しすぎたことによる管理の甘さ」が、そのまま自分の首を絞める結果になったから。これが理由4だよ。
これって皮肉な話だなと思うの。攻撃者はAIに自律的に動かせることで効率化を狙ったはずなのに、その自律性ゆえに「今どんな設定でサーバーが動いているか」を自分でもちゃんと把握しきれていなかったんだよね。AIに任せる範囲を広げれば広げるほど、人間側の監視や理解が追いつかなくなるというのは、攻撃する側にとっても防御する側にとっても、実は同じリスクなんじゃないかなって思ったの。
これはわたしたちがAIエージェントを業務で使うときにも、他人事じゃない教訓だと思う。便利だからと言ってAIに全部お任せにしすぎると、今何が動いていて、どんな設定になっているのか、人間側が把握できなくなる瞬間が出てくるんだよね。今回はそれが攻撃者側で起きただけで、同じ構造的な穴は、わたしたちが使う正規のAIエージェント運用でも十分に起こり得ることだと思う。
理由5：これ、わたしたちの日常のAIツール選びにも関係してくる話
5つ目。ここまでは攻撃者やセキュリティ企業の話が中心だったから、最後にわたしたち普段AIツールを使う側の目線でも考えてみたいの。この話、実は自分でAIツールを選ぶときの感覚にも直結してくるんだよね。
世間では「セキュリティの話は開発者やIT担当の人が気にすればいい、自分は普通に使ってるだけだから関係ない」っていう感覚が、けっこう自然だと思うの。わたしも正直、この事件を見るまでは、モデルごとの安全機能の差ってそこまで意識してなかったの。
でもわたしがこの事件を通して感じたのは、「どのAIモデルを選ぶか」自体が、もう単なる性能や料金の比較じゃなくなってきているということなの。なぜなら、今回の攻撃者が示したみたいに、安全機能の強さや弱さは、使う人の目的によって「メリット」にも「デメリット」にもなる要素だから。これが理由5だよ。わたしたちが安心して使えるツールを選ぶときも、この安全機能の設計そのものを、比較の材料に入れたほうがいいと思うようになったの。
たとえば、業務でAIエージェントに外部サービスとの連携やコード実行を任せるとき、そのモデルやフレームワークがどんな安全機能を持っているか、デフォルト設定でどこまで制限がかかっているか、一度確認しておく価値はあると思うの。特にオープンソースのフレームワークを使う場合、クライアント側の制限がなければ、便利さと引き換えにリスクも大きくなるという今回のケースと同じ構造になりかねないんだよね。
わたし自身、AIツールを選ぶときはついつい「賢いかどうか」「早いかどうか」ばかり気にしちゃうんだけど、これからは「このツール、安全機能はどうなってるんだろう」って一呼吸置いて確認する癖をつけようと思ったの。特に自分のアカウントや業務データに紐づく形でAIエージェントを動かすときは、なおさら意識しておいたほうがいいなって、今回の事件を見て強く感じたよ。
まとめ：AIの賢さより、安全機能の設計を見る時代に
長くなったからまとめるね。今日のテーマは「中国拠点のハッカーがDeepSeekを自律型フレームワークに組み込み、460以上のシステムへ自律的にサイバー攻撃を仕掛けていた事件」だったよ。ポイントは5つ。
1つ目、攻撃者がTelegramで最初の指示を1回送っただけで、あとは標的探しからエクスプロイトの実行まで、AIがほぼ自律的にこなしていたということ。2つ目、攻撃者は複数のモデルを比較したうえで「安全機能が最小限」という理由でDeepSeekを意図的に選んでいたということ。3つ目、OpenAIの安全機能自体はちゃんと違反リクエストを拒否し関連アカウントを無効化していたけれど、攻撃者は単に制限の緩いモデルへ乗り換えただけだったということ。4つ目、この大規模な攻撃が発覚したきっかけは、攻撃者自身がサーバー設定を誤って公開してしまったという、皮肉なうっかりミスだったということ。5つ目、モデルごとの安全機能の差は、これからのAIツール選びにおいてわたしたち一般ユーザーにも関係してくる比較軸になっていくということ。この5つだね。
わたしが今日いちばん伝えたいのは、「AIが賢いかどうか」と「AIが安全に設計されているかどうか」は、まったく別の軸だということなの。今回の事件は、その2つの軸のズレを、攻撃者という一番シビアな視点から突きつけてきた出来事だったと思う。
AIエージェントがどんどん自律的に、便利になっていくこれからの時代、こういう「安全機能の差」を突いた事件はまだまだ出てくると思うの。わたしたちユーザー側も、便利さだけじゃなくて「このツールはどこまで安全に設計されているんだろう」って考える視点を、少しずつ持っておいたほうがいいと思う。わたしもこれから、AIツールを選ぶときはこの視点を忘れずにチェックしていくつもりだよ🕵️
AIエージェントの実用化がどこまで進んでいるか気になる人は、AIエージェントってどこまで実用化された？現在地を整理してみた や、業務自動化ツールを比較した n8n vs Zapier 徹底比較｜AI自動化ツールはどちらを選ぶべき？ もあわせて読んでみてね。
関連記事: AIエージェントってどこまで実用化された？現在地を整理してみた
ソース: