【2026年7月最新】初の自律型AIランサムウェア確認｜企業の実務対策

2026年7月1日、クラウドセキュリティ企業Sysdigは、偵察から認証情報の窃取、権限昇格、データ破壊、身代金要求まで、AIエージェント(大規模言語モデル)が人間の逐次操作を介さず一気通貫で実行したとみられる攻撃「JADEPUFFER」を確認したと公表しました。Sysdigはこれを「初めて文書化されたエージェント型ランサムウェア」と位置づけています。

この記事の要点:

• 攻撃者は公開されていたAI開発基盤Langflowの脆弱性(CVE-2025-3248)を悪用して侵入し、そこからAIエージェント自身が認証情報の収集・横展開・データベースの暗号化と削除・身代金要求メモの設置までを自律的に実行したとSysdigは分析している
• 2025年8月にESETが報告した「PromptLock」は概念実証(実際の攻撃には未使用)だったのに対し、JADEPUFFERは本番システムに対する実際の攻撃として観測された点が質的に新しい
• 人間が関与したのは標的の選定とインフラの用意までで、それ以降の技術的な実行判断はほぼすべてAIエージェントが担い、失敗したステップも自ら診断して数十秒で修正していたとSysdigは報告している

対象読者: 生成AIエージェントの業務導入を検討・推進している経営者、情シス・DX担当者、社内のAI活用ガイドライン策定に関わる方

読了後にできること: 自社が使っている生成AI関連ツール・エージェントの「棚卸し」の視点と、AIエージェントに権限を渡す際に最低限入れておきたい承認ゲートの考え方が分かります。

「ランサムウェアの実行犯が、人間ではなくAIだった」——そう聞くと、SFの話のように感じるかもしれません。しかし2026年7月、これが実際に観測された攻撃として報告されました。

これまでも「AIを使って攻撃の効率を上げる」事例は数多く報告されてきました。フィッシングメールの文面をAIに書かせる、脆弱性スキャンをAIに手伝わせる、といったものです。しかし今回Sysdigが報告した「JADEPUFFER」は、初期侵入から認証情報の窃取、社内システムの偵察、権限昇格、データベースの暗号化・削除、身代金要求メモの設置までの一連の技術的判断を、AIエージェントが人間の逐次指示なしに実行したとされる点で、これまでの延長線上にはない事例です。

この記事では、公開されているセキュリティベンダーの報告と複数の主要メディアの報道をもとに、JADEPUFFERで何が実際に起きたのか、なぜ「自律型」と言えるのか、そして企業がこれを踏まえて今すぐ着手すべき実務対策を、攻撃の再現につながる技術的な手順には踏み込まずに整理します。

何が起きたのか — JADEPUFFER事件の全体像

時系列で整理すると、今回の報告の位置づけが分かりやすくなります。

侵入から身代金要求までの流れ(概要)

Sysdigの報告によると、攻撃はおおむね次の流れで進んだとされています。攻撃の再現につながる具体的なコマンドや通信先などの技術的詳細は、ここでは扱いません。

• 侵入: インターネットに公開されていたAI開発基盤Langflowの脆弱性(CVE-2025-3248)を突いて、任意のコードを実行できる状態を作った
• 偵察・情報収集: 侵入したホスト上で、OpenAIやAnthropicなど生成AIサービスのAPIキー、AWS・GCP・Azureや複数のクラウド事業者の認証情報、暗号資産ウォレット情報などを幅広く探索した
• 横展開: 得られた認証情報をもとに、別の本番サーバー(構成管理サービスNacosを載せたMySQLサーバー)へ移動した
• 権限昇格・破壊: Nacos側の認証不備を突いて管理者権限を偽装し、1,342件の設定データを暗号化したうえで、複数のデータベースそのものを削除した
• 金銭要求: ビットコインアドレスと連絡先を記載した身代金要求メモを設置した

Sysdigの報告では、身代金が実際に支払われたかどうかは明らかにされていません。一部の報道では、暗号化に使われた鍵がその場限りでしか出力されておらず保存や送信がされていなかったとされ、支払ったとしても復号できない可能性が指摘されています。被害を受けた組織の名称・業種も公表されていません。

何をもって「自律的」と言えるのか

今回の報告で特に注目されているのは、AIエージェントが「失敗を自分で診断し、修正して、再挑戦した」という点です。Sysdigが公開したログでは、管理者アカウントの作成が失敗した後、原因(プログラムの実行環境の設定不備)を突き止めた修正コードを実行するまで、わずか31秒だったと報告されています。

ほかにも、あるデータの取得先が想定と異なる形式で応答した際に、即座に別の形式向けの読み取り処理へ自動的に切り替えていたことも報告されています。生成されたコードには「なぜこの操作をするのか」を説明する自然言語のコメントが数多く残されており、Sysdigの脅威リサーチ担当者は「ペイロード自体が自己説明的だった」と述べています。これらが、今回「人間が逐一操作したのではなく、AIエージェントが判断していた」と評価されている根拠です。

ただし、Fortuneなどの報道が指摘する通り、攻撃対象を選び、攻撃用のインフラを用意したのは人間です。「最初から最後まで完全に無人だった」わけではなく、「攻撃対象を決めた後の技術的な実行判断のほぼすべてをAIエージェントが担っていた」というのが、より正確な理解です。

AIエージェントの基本的な仕組みや企業導入のステップについては、AIエージェント導入完全ガイドで体系的にまとめています。

2025年の「PromptLock」と何が違うのか

「AIを使ったランサムウェア」という報告自体は、今回が初めてではありません。2025年8月、セキュリティベンダーのESETが「PromptLock」という検体を報告しています。ただしJADEPUFFERとは前提が大きく異なります。

つまり「AIが攻撃コードを書く」という要素は2025年の時点で既に確認されていましたが、「AIエージェントが最初から最後まで一つの攻撃を完遂し、実際の被害を出した」という意味での事例は今回が初めて、というのがより正確な理解です。1年足らずの間に、AIが関わるランサムウェアは「研究者が作った実験」から「実際にシステムを壊す攻撃」へと段階が進んだことになります。

なぜ他人事ではないのか — 企業が向き合うべき3つの構造変化

「うちは大企業ではないから狙われない」「特殊な業界の話だろう」と受け止めたくなるかもしれませんが、この事件が示す構造変化は業種や企業規模を問いません。

1. 攻撃の”習熟コスト”が下がった

これまでランサムウェア攻撃には、脆弱性を見つけて悪用し、横展開し、暗号化ツールを用意するといった専門知識を持つ人・チームが必要でした。今回の事例が示すのは、その専門知識の相当部分をAIエージェントが代替できるようになったという事実です。攻撃側の「参入障壁」が下がるほど、攻撃の頻度や対象の裾野は広がりやすくなります。

2. 標的は「有名企業」ではなく「公開されている脆弱なホスト」

今回の初期侵入経路は、インターネットに公開されていたAI開発・自動化基盤の脆弱性でした。セキュリティ企業の分析では、この種の基盤が同種の脆弱性を抱えたまま数百単位でインターネット上に公開されている状態も確認されています。攻撃側の探索自体が自動化されている以上、「狙われるかどうか」は知名度ではなく「公開資産の管理状態」で決まります。

3. 人間の監視が追いつく前に被害が完了しうる

今回の報告で象徴的だったのは、失敗から修正までにかかった時間が数十秒単位だったという点です。従来型の「異常を検知してから人間が対応する」運用では、AIエージェント側の実行速度に追いつけない場面が今後増えると考えられます。防御側にも、検知や一次対応の自動化・高速化が求められます。

こうした自律的なAIエージェントを「どこまでなら安全に動作させてよいか」という設計思想は、フロンティアAIモデル側の安全機構の作り方とも直結するテーマです。主要モデルがどのような安全機構・監視の仕組みを備えているかは主要AIモデルの安全機構を比較した記事で詳しく解説しています。

【要注意】「AIランサムウェア」でよくある3つの誤解

誤解1: 「大手・有名企業しか狙われない」

❌ 自社は無名の中小企業だから対象外だと考える

⭕ 今回の初期侵入は、公開されたツールの脆弱性を自動的に探すところから始まっている。企業規模ではなく「公開資産の有無」で対象になり得る

なぜ重要か: 攻撃側の偵察自体が自動化されている以上、狙われるかどうかは知名度と無関係です。

誤解2: 「ChatGPTやClaudeのような有名サービスを使わなければ関係ない」

❌ 自社は有名な生成AIサービスしか使っていないので無縁だと考える

⭕ 今回悪用されたのはオープンソースのAI開発基盤であり、2025年のPromptLockもローカルで動く比較的軽量なモデルを使っていた。有名な商用AIサービスの契約有無とは別の話

なぜ重要か: リスクは「どのAIサービスを契約しているか」ではなく、「社内でどんなAI関連ツール・基盤が動いているか」全体で考える必要があります。

誤解3: 「バックアップさえあれば復旧できるので大きな問題ではない」

❌ 暗号化されてもバックアップから戻せば済むと考える

⭕ 今回の事例では暗号化に加えてデータベースそのものが削除されており、身代金を払っても復号できない可能性も報じられている。「復旧できる前提」自体が崩れつつある

なぜ重要か: 復旧できる前提の対策(バックアップ運用)だけでなく、そもそも侵入・権限昇格をさせない予防側の対策が今まで以上に重要になっています。

企業が今すぐ着手すべき実務対策

Sysdigの報告では、企業側の対策としていくつかの具体的な推奨事項が示されています。ここではそれをベースに、AI研修・導入支援の現場でよく相談される内容もあわせて、着手しやすい順に整理します。

1. 公開資産の棚卸しと迅速なパッチ適用

まずは自社がインターネットに公開しているAI関連の開発基盤・自動化ツール・検証環境を棚卸しし、既知の脆弱性が放置されていないかを確認します。今回のケースでは、修正パッチが提供されて久しい脆弱性が悪用されました。「公開したまま放置されているツール」の有無を確認するだけでも、リスクは大きく下がります。

【公開資産・棚卸しチェックリスト(コピペしてご利用ください)】
□ 社内でインターネットに公開しているAI関連ツール・開発基盤を全てリストアップしたか
□ それぞれのバージョンが最新化されているか、既知の脆弱性が残っていないか確認したか
□ 「誰が」「いつ」そのツールを立てたのか、管理者・利用目的が分かっているか
□ 使われなくなった検証環境・デモ環境が公開されたまま放置されていないか
□ 上記の棚卸しを一度きりで終わらせず、定期的な運用として回す担当者・頻度を決めたか

不明点や自社での判断が難しい項目があれば、
専門家に相談のうえ優先順位を決めることをおすすめします。

2. AIエージェントに渡す認証情報の置き場所を見直す

今回の攻撃で被害が拡大した一因は、AIエージェントを動かすサーバー上に、生成AIサービスやクラウドの認証情報がそのまま置かれていたことでした。AIエージェントを動かす基盤と、機密性の高い認証情報の保管場所は分離し、認証情報は専用の管理の仕組み(vault)でローテーションする、というのがSysdigの推奨です。

3. AIエージェントに「承認ゲート」を設計する

AIエージェントに、データベースの変更・権限の付与・外部への通信といった重大な操作を行わせる場合は、事前に人間の承認を挟む「承認ゲート」を設けることが有効です。権限は必要な範囲・必要な時間だけに絞り(最小権限・時間制限付き)、実行中のセッションを監視できる状態にしておくことが、複数のセキュリティ専門家からも共通して推奨されています。

4. 生成AI利用ガイドラインを社内で明文化する

ここまでの内容を、担当者の頭の中だけでなく社内ルールとして明文化しておくことが重要です。「どのAIツールなら業務利用してよいか」「AIエージェントにどこまでの権限を渡してよいか」「新しいAI関連ツールを社内に立てる際の申請フロー」といった項目は、事故が起きてから作るのではなく、平時のうちにひな形を用意しておくと運用がぶれません。

Uravationでは、こうした社内ルール作りの出発点として使える生成AI利用ポリシーのひな形を無料で配布しています。ゼロから作るのではなく、自社の状況に合わせて調整する形で使うと着手しやすくなります。

【社内向け注意喚起の文面テンプレート(Slack・メールでそのまま共有可)】
件名: AIエージェント関連ツールの公開状況を至急ご確認ください

各位

セキュリティ企業から、AI開発・自動化ツールの脆弱性を突いて
AIエージェント自体が攻撃を自律実行した事例が報告されています。

つきましては、以下のご協力をお願いします。

1. 部署内でインターネットに公開しているAI関連ツール・検証環境が
   あれば、至急[担当者名/部署]までご連絡ください
2. 該当ツールのバージョンが最新化されているかご確認ください
3. 不明点があれば[問い合わせ先]までお気軽にご相談ください

ご協力よろしくお願いいたします。

本テンプレートは自社の体制・呼称に合わせて調整してご利用ください。

よくある質問

Q. JADEPUFFERによって、実際にどのくらいの被害が出たのですか?

A. Sysdigの報告によると、標的となった本番データベースの設定データ1,342件が暗号化され、複数のデータベースが削除されました。被害を受けた組織名や業種は公表されておらず、身代金が実際に支払われたかどうかも明らかにされていません。

Q. 日本企業も対象になり得るのでしょうか?

A. 今回の初期侵入経路はインターネットに公開されたツールの脆弱性であり、攻撃側の探索自体が自動化されています。国・地域を問わず、該当する脆弱なツールを公開している組織であれば対象になり得ると考えるべきです。

Q. これはChatGPTやClaudeなど、特定の生成AIサービスが危険という話なのでしょうか?

A. いいえ。今回悪用されたのはオープンソースのAI開発基盤の脆弱性であり、特定の商用生成AIサービス自体の欠陥ではありません。ただし、攻撃者が窃取しようとした情報の中には生成AIサービスのAPIキーも含まれていたと報告されており、「AIサービスの認証情報をどう保管するか」は業種・利用サービスを問わない共通課題です。

Q. 中小企業でもできる、最初の一歩は何ですか?

A. まずは「自社がインターネットに公開しているAI関連ツール・システムの棚卸し」から始めることをお勧めします。特別な予算や専門チームがなくても、公開資産のリストアップとバージョン確認だけであれば着手できます。

まとめ:今日から始める3つのアクション

1. 今日やること: 自社がインターネットに公開しているAI関連ツール・開発基盤・検証環境をリストアップし、既知の脆弱性が放置されていないか確認する
2. 今週中: AIエージェントに渡している認証情報の保管場所を確認し、権限を必要最小限に絞れないか棚卸しする。あわせて社内向けの注意喚起を共有する
3. 今月中: 生成AI利用ガイドラインと、AIエージェントに重大な操作をさせる際の承認ゲートを社内ルールとして明文化する

あわせて読みたい:

• AIエージェントのセキュリティリスク完全解説|9項目チェックリスト — AIエージェント特有のリスクをより詳しく整理
• 中小企業のAIセキュリティ対策|情報漏洩を防ぐ実践プロンプト — 情報漏洩対策の具体策

参考・出典

• JADEPUFFER: Agentic ransomware for automated database extortion — Sysdig公式ブログ(参照日: 2026-07-08)
• 31秒で失敗を修正 考えながらランサムを仕掛けるAI攻撃者の実態 — ITmedia(参照日: 2026-07-08)
• The first known ‘agentic ransomware’ has arrived — Fortune(参照日: 2026-07-08)
• Researchers Claim First Fully Agentic Ransomware: JadePuffer — Infosecurity Magazine(参照日: 2026-07-08)
• Sysdig Details JADEPUFFER, the First Documented Agentic Ransomware Operation — Hackread(参照日: 2026-07-08)
• ESET discovers PromptLock, the first AI-powered ransomware — ESET公式(参照日: 2026-07-08)
• Critical Langflow Flaw Added to CISA KEV List Amid Ongoing Exploitation Evidence — The Hacker News(参照日: 2026-07-08)

次回は、AIエージェントに業務権限を渡す際の承認フロー設計について、テンプレートを交えてさらに掘り下げます。

著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。
SoftBank IT連載7回執筆(NewsPicks最大1,125ピックス)。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。