AIが作った初のゼロデイ脆弱性とは？Google検出・2FA突破・恐喝キャンペーン阻止・日本企業への影響を解説【2026年5月】

2026年5月11日、Google Threat Intelligence Group（GTIG）は世界で初めて「AIによって開発されたと考えられるゼロデイ脆弱性エクスプロイト」を確認した。対象は2FA（二要素認証）を回避できる脆弱性で、GTIGの事前検知により大量悪用は阻止されたが、AI生成攻撃ツールが現実の脅威として表面化した事案として世界的に注目されている。

本記事でわかること：

• AI生成ゼロデイとは何か、なぜ「AIが作った」と判断できるのか
• 2FA（二要素認証）バイパスの技術的なメカニズム
• 恐喝キャンペーン（TeamPCP/UNC6780・SANDCLOCKスティーラー）の全体構造
• KnowledgeDeliver CVE-2026-5426と日本企業への具体的な影響
• 企業・セキュリティ担当者が今すぐとるべき対策（優先順位付き）

主な対象読者： 企業のセキュリティ担当者・IT部門責任者・開発者・AIセキュリティの動向を把握したいすべての方。

AIが作った「初のゼロデイ脆弱性」とは──2026年5月の事案全体像

2026年5月11日にGTIGが発表した内容の核心は、「著名なサイバー犯罪グループ」がAI（LLM）を使って開発したと考えられるゼロデイエクスプロイトを実際の攻撃キャンペーンに組み込もうとしていた、というものだ。

事案の主要ファクト（公式確認済み）

なお、対象ツールの具体名・CVE番号・攻撃グループ名はGoogleが現時点でも非公開としている。「パッチは適用済み」であることは公式に確認されており、大規模な被害拡大は阻止された。

GTIGのチーフアナリスト、John Hultquist氏はレポートの中でこう述べている。

「AIを使った脆弱性探索の競争が迫っているという誤解がある。現実はすでに始まっている。」
"There's a misconception that the AI vulnerability race is imminent. The reality is that it's already begun."

出典: Google Cloud Blog – Google Threat Intelligence Group

AI生成エクスプロイトの証拠：なぜ「AIが作った」と断定できるか

GTIGがこのエクスプロイトを「AI生成」と判断したのは、コード自体に複数の「LLM特有のパターン」が埋め込まれていたからだ。攻撃コードを見て「これはAIが書いた」と識別できるほど、LLMのコーディング癖は特徴的だという。

GTIGが公式レポートで示した判断根拠は4点ある。

1. 過剰な教育的docstring（説明文）が含まれている
LLMは学習データに見られる「教科書的なコード整理パターン」を再現しやすい。攻撃ツールとは思えないほど丁寧なコメントが付されていた。

2. 架空のCVSSスコアが記載されている（ハルシネーション）
LLMが「ありそうな情報」を生成してしまう「幻覚（ハルシネーション）」の典型例。実在しないCVSSスコアが記載されており、人間のハッカーが書いたとは考えにくい痕跡となった。

3. テキストブック的なPythonic形式
LLMの学習データには教科書・チュートリアルが大量に含まれている。その影響で、実用的なハッキングツールにしては不自然なほど整然としたコードフォーマットになっていた。

4. CLIカラークラスの実装・詳細なヘルプメニューの組み込み
「わかりやすく書こうとする」LLMの傾向が表れており、攻撃ツールとしては過剰な機能が実装されていた。

GTIGの公式表現を引用する。

"The script contains an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data."

これらの痕跡から、攻撃者がAIアシスタントを使って脆弱性の探索・実装を行い、生成されたコードをほぼそのままエクスプロイトとして流用した可能性が強く示唆される。

従来の脆弱性探索ツールでは見つけられなかった理由

今回の脆弱性が「2FA（二要素認証）バイパス」というセマンティックロジック欠陥だったことが重要だ。

従来のセキュリティツール（ファジング・静的解析）は、メモリ破損・バッファオーバーフローといった「コードの構造的バグ」を発見するのが得意だ。一方、今回のような「機能的には動いているが、セキュリティ設計が矛盾している」という論理欠陥は、コードの「意味」を理解しないと発見できない。

LLMは開発者の意図を推測し、認証フローの矛盾を文脈で理解する能力を持つ。これが従来ツールの盲点を突く新しい脆弱性探索手法となっている。

2FA（二要素認証）バイパスの手口

今回確認された2FAバイパスの技術的なメカニズムを整理する。

攻撃の前提条件

• 攻撃者が対象アカウントの「有効な認証情報（パスワード）」を事前に入手済み
• 対象ツールがインターネット上に公開されている

脆弱性の根本原因

開発者が認証フローに「信頼の例外」をハードコードしていた矛盾が根本原因だ。

• 通常フロー： パスワード認証 → 2FAコード入力 → アクセス許可
• 攻撃フロー： パスワード認証 → 特定の条件を満たすと2FAをスキップ → アクセス許可

「特定の条件」とは、開発者が「このケースは信頼できる」とハードコードした例外処理だ。意図的に設けた抜け穴というより、認証フローの設計段階で見落とした矛盾点だと考えられている。

なぜ発見が難しかったか

• コードの行数で言えば、脆弱性のある箇所は「普通に動いている」ように見える
• 手動の脆弱性診断では、正常系テストが通れば見落とされやすい
• AIは「認証フロー全体を俯瞰して矛盾を見つける」能力を発揮した

AIセキュリティのリスクと企業対策の全体像については、生成AIのセキュリティリスクとは？情報漏洩・プロンプトインジェクション・企業と個人の対策を解説も参考になる。

恐喝キャンペーンの全体構造──GitHubサプライチェーン攻撃からランサムウェア連携まで

AI生成ゼロデイは単独の攻撃ツールとして使われるのではなく、大規模な恐喝エコシステムの一部として計画されていた。GTIGレポートが明らかにした全体構造は以下の通りだ。

出典: Google Cloud Blog – Google Threat Intelligence Group

ステップ1: TeamPCP（別名UNC6780）によるGitHubリポジトリ侵害（2026年3月）

2026年3月、サイバー犯罪グループ「TeamPCP（UNC6780）」が複数のGitHubリポジトリを侵害した。主な侵害リポジトリは以下：

• Trivy（人気の脆弱性スキャナー）
• Checkmarx（アプリケーションセキュリティテストツール）
• LiteLLM（LLM統合ライブラリ）
• BerriAI（AIフレームワーク）

これらのビルド環境に「SANDCLOCK」と呼ばれる認証情報スティーラーを埋め込んだ。SANDCLOCKは開発者のビルド実行時に起動し、以下の情報を窃取する：

• AWSアクセスキー
• GitHubトークン
• その他クラウドシークレット

ステップ2: 窃取情報の現金化

盗んだ認証情報は、ランサムウェアグループ・データ窃取恐喝グループとのパートナーシップで現金化される仕組みが確立されていた。

「サイバー犯罪者はランサム活動の標的を変えなければならない。ゼロデイを長期間使い続けることは難しいため、最善の選択は素早い大量展開だ」

ステップ3: AI生成ゼロデイを使った「大量悪用イベント」の計画

最終段階として、AI生成ゼロデイを使って対象ツールを使用する多数の組織を同時攻撃する「大量悪用イベント（Mass Exploitation Event）」が計画されていた。GTIGが事前検知し、この段階での阻止に成功している。

GTIGが記録したAI生成マルウェア4種

AIエージェントが攻撃インフラとして悪用されるリスクについては、AIエージェントのセキュリティ対策｜リスクの全体像と実務で使える対策チェックリストも参照されたい。

GoogleはどうやってAI生成ゼロデイを阻止したか

GTIGによる今回の阻止は「計画段階での事前検知」だった。大量展開が始まる前に攻撃インフラとエクスプロイトの存在を確認し、影響を受けたベンダーと協力して責任ある情報開示（Responsible Disclosure）を実施。パッチを適用した。

Googleが展開する防御側AIツール

「防御側もエージェンティックモデルを採用し、攻撃者のスピードに追いついていく必要がある」

防御側AIを活用したセキュリティの具体的なアプローチについては、Claude Securityとは？脆弱性スキャンのしくみ・Enterprise公開ベータ・CrowdStrike/Palo Alto Networks連携を徹底解説も参考になる。

日本企業への影響──KnowledgeDeliver CVE-2026-5426・Hexstrike攻撃・世界6位ターゲット

今回の事案を「日本には関係ない海外の話」として見過ごすことはできない。GTIGレポートには、日本固有のシステムへの実際の攻撃が複数記録されている。

出典: Google Cloud Blog – Google Threat Intelligence Group

日本製LMS「KnowledgeDeliver」の実際の攻撃（CVE-2026-5426）

GTIGレポートには、AI生成ゼロデイとは別に、日本で実際に被害が発生したゼロデイ攻撃も記録されている。

GTIGが記録した実際の攻撃ステップ：

1. __VIEWSTATEパラメータに悪意あるペイロードを送信
2. BLUEBEAMウェブシェル（.NETインメモリ・ファイルレス）を展開
3. JavaScriptファイルを改ざん → フェイク「セキュリティプラグイン」を表示してエンドユーザーを欺く
4. 最終的にCobalt Strike Beaconをインストール

KnowledgeDeliverを利用している組織は、2026年2月24日以前のバージョンが残っていないか至急確認が必要だ。

中国系グループによる日本テクノロジー企業への標的攻撃

GTIGレポートには、中国系グループがHexstrikeとGraphiti（時系列知識グラフ）を使用して、日本のテクノロジー企業と東アジアの主要サイバーセキュリティプラットフォームを標的にしていることも記録されている。

• Strix（マルチエージェント侵入テストフレームワーク）で脆弱性の自動識別・検証を実施
• SubfinderとhttpxツールをHexstrike経由で自律的に連鎖実行
• 「最小限の人手による監視で偵察活動を大規模化できるAI駆動型フレームワーク」として評価

日本のテクノロジー企業がAIエージェントが半自律的に動作する偵察攻撃の対象になっているという事実は、AIコーディングや開発環境のセキュリティリスクとも直結する。AIコーディングのセキュリティリスクとは？も合わせて参照してほしい。

日本を取り巻くサイバー脅威環境（2026年5月時点）

• 日本は世界で6番目に標的とされている国（GTIGレポート）
• 「YY来魚」フィッシング・アズ・ア・サービス：決済・交通プラットフォームに偽装し、日本ユーザーに特に焦点を当てたフィッシング
• IPA「情報セキュリティ10大脅威2026」：「AIの利用をめぐるサイバーリスク」が組織向け脅威で初登場（3位）
• 経済産業省（2026年5月1日）：電力・ガス・化学・クレジット・石油の重要インフラ事業者に対し、高性能AIのサイバーリスク対策を直接要請

業界横断でのAIセキュリティ標準化の動きについては、Anthropic Project Glasswingとは｜AWS・Apple・Google・Microsoft・JPMorgan 12社連携でも関連する取り組みを確認できる。

従来型ゼロデイ vs AI生成ゼロデイ：何が変わったか

今回の事案が「新しい段階の始まり」とされる理由を、従来のゼロデイ攻撃との比較で整理する。

AI生成ゼロデイは「AIがすべて自動でやってくれる」わけではない。今回の事案でも、攻撃者はAIを使って脆弱性を探索・コードを生成したが、最終的な悪用計画は人間が設計していたと考えられる。本質的な変化は「参入コストが下がり、より多くの攻撃者が高度な脆弱性探索を行えるようになる」点だ。

国家系サイバー攻撃グループのAI悪用状況

今回の事案は「サイバー犯罪グループ」によるものだが、GTIGレポートには国家が支援する攻撃グループのAI活用状況も記録されている。

特に注目すべきは、北朝鮮のAPT45が「数千件の反復プロンプト」をAIに送信してCVE分析を行っていることだ。これは高度な技術を持たなくても、AIを使った大規模な脆弱性調査が可能になっていることを示している。

今後の見通し：AI攻撃の産業化が意味するもの

GTIGのJohn Hultquist氏が強調するのは、これが「将来の脅威」ではなく「すでに進行中の現実」だという点だ。

攻撃側の変化：参入コストの低下と大量展開への移行

• 脆弱性探索のコスト低下：高度な専門知識がなくてもAIを使えば脆弱性候補を列挙できる段階に入っている
• エクスプロイト開発の民主化：従来「エリートハッカーしかできなかった」作業がAI補助で可能になりつつある
• 大量展開キャンペーンの計画：今回は阻止されたが、次回が同様に阻止される保証はない

ゼロデイ攻撃サイクルの短縮

従来のゼロデイサイクル：

1. 脆弱性の発見（数週間〜数ヶ月）
2. エクスプロイトの開発（数週間）
3. 悪用・拡散（徐々に広がる）

AI生成ゼロデイが変えるもの：

1. 脆弱性の発見（数時間〜数日に短縮の可能性）
2. エクスプロイトの開発（AIが補助・短縮）
3. 大量悪用イベント（同時多数組織への一斉攻撃）

この「スピードの変化」こそが企業のパッチ管理・脆弱性対応に最も大きなプレッシャーを与える。「月次パッチ管理」では間に合わなくなりつつある。

防御側の変化：「AIで守る」必要性

攻撃側がAIを使うなら、防御側もAIを使わなければ速度差で負ける。これがLuke McNamara氏の「防御側もエージェンティックモデルを採用する必要がある」という発言の背景だ。

企業・担当者が今すぐとるべき対策（優先順位付き）

出典: Google Cloud Blog – Google Threat Intelligence Group

優先度1（即日対応）: パッチ適用の加速とKnowledgeDeliverの確認

• KnowledgeDeliver利用組織：2026年2月24日以前のバージョンが残っていないか確認し、直ちに最新版へ更新
• オープンソースのWebベース管理ツール全般について、2026年5月以降リリースのパッチ適用状況を確認
• 定期的なパッチ管理サイクルを「週次確認」に短縮することを検討

優先度2（今週中）: 2FA認証フローの例外処理レビュー

• 自社開発ツール・採用OSSの認証フローに「信頼の例外」がハードコードされていないか確認
• 2FA実装において「特定条件下でスキップできるロジック」が含まれていないかコードレビューを実施
• 外部委託ベンダーが管理するツールについても同様の確認を依頼

優先度3（今月中）: AIサプライチェーンの監視強化

今回のTeamPCP/UNC6780が標的にしたのは開発ツールのリポジトリだった。

• GitHub ActionsなどのCI/CDパイプラインに不審なコードが混入していないか確認
• PyPI・npm等からインストールするパッケージのハッシュ検証を実施
• LiteLLM・BerriAI・Checkmarxを2026年3月前後にビルドした環境では認証情報のローテーションを実施

優先度4（今四半期中）: フィッシング耐性MFAへの移行

今回のゼロデイは「パスワードが事前に入手されている」ことが前提だった。フィッシング耐性MFA（FIDO2パスキー・ハードウェアセキュリティキー）への移行で、この前提条件を崩せる。

• SMS・メールOTPは「フィッシング耐性なし」と分類し、段階的廃止を検討
• 管理者アカウントはYubiKey等のハードウェアキーを必須化
• パスキー（FIDO2）対応アプリへの移行ロードマップを策定

優先度5（継続対応）: 防御側AIツールの評価・導入

• GoogleのBig SleepのようなAIを活用した脆弱性先制発見ツールの評価
• WAFルールの定期的なAI支援最適化
• セキュリティ情報のAI要約・優先順位付けツールの導入検討

特に影響が大きいケース / 比較的影響が小さいケース

特に影響が大きいケース

以下に当てはまる組織は、今回の事案を受けた対策が特に急務だ。

• KnowledgeDeliverを利用している教育機関・企業（CVE-2026-5426の直接的な影響）
• 日本のテクノロジー企業（中国系グループHexstrike/Strixによる標的攻撃が確認済み）
• 電力・ガス・化学・クレジット・石油の重要インフラ事業者（経産省が高性能AIリスク対策を直接要請）
• GitHubでOSSの開発・運用を行っている組織（サプライチェーン攻撃の直接的なリスク）
• LiteLLM・BerriAI・Checkmarxを使用しているエンジニアリングチーム（SANDCLOCKスティーラーの侵害対象リポジトリ）
• Webベースの管理ツールをインターネットに直接公開している組織（今回のゼロデイの攻撃条件に合致）
• SMS OTP・メールOTPのみで2FAを実装している組織（フィッシング耐性なし）

比較的影響が小さいケース

• オフライン・閉域ネットワーク環境のみで運用している組織
• 管理ツールをゼロトラスト・VPN必須の内部ネットワークのみに限定している組織
• FIDO2パスキー・ハードウェアキーによるフィッシング耐性MFAを既に全面導入済みの組織
• オープンソース管理ツールをインターネット公開していない組織

「比較的影響が小さい」は「影響がない」ではない。AI生成脆弱性探索が広まれば、どの組織も潜在的な標的となり得る。

よくある質問（FAQ）

Q1: 攻撃対象になった管理ツールは何ですか？

Googleは現時点でも対象ツール名を公開していない。公式の表現は「人気のオープンソース・Webベース・システム管理ツール」のみだ。CVE番号も未公開だが、GTIGがベンダーと協力してパッチを適用済みであることは公式に確認されている。

Q2: 自社がすでに攻撃を受けていた可能性はありますか？

GTIGの事前検知により大量悪用は阻止されたため、広範な被害が発生した可能性は低い。ただし、KnowledgeDeliver CVE-2026-5426については、2026年2月24日以前のバージョンを使用していた組織は実際に攻撃された可能性があるため、ログの精査が推奨される。

Q3: AIを使えば誰でもゼロデイエクスプロイトを開発できますか？

現時点では「誰でも簡単に」というレベルではない。ただし、高度な専門家のみができた作業の一部がAIによって補助されるようになっており、参入コストが下がっていることは事実だ。GTIGが強調するのは「この競争はすでに始まっている」という点であり、2FA突破のような「意味的論理欠陥の発見」においてLLMは従来ツールより高い能力を持つ。

Q4: ゼロデイ（Zero-Day）とは何ですか？

ゼロデイとは、ソフトウェアのベンダーがまだ認識しておらず、パッチ（修正プログラム）が存在しない未知の脆弱性のこと。パッチが「0日」しか存在しない状態で攻撃が行われることからこの名称がある。ベンダーが知らない間は修正できないため、防御が極めて困難。

Q5: 2FAを導入していれば安全ですか？

今回の事案はその認識を覆すものだ。「2FAを実装していても、認証フローに論理的な矛盾がある場合は回避される可能性がある」ことが証明された。また、SMS OTP・メールOTPは「フィッシング耐性がない」ため、フィッシング耐性MFA（FIDO2パスキー・ハードウェアキー）への移行が推奨される。

Q6: 業務でのChatGPT・Claude利用と今回の事案は関係ありますか？

今回の事案は「攻撃者がAI（LLM）を使ってエクスプロイトを開発した」という話であり、企業が業務でChatGPTやClaudeを使うことの危険性とは直接リンクしない。ただし、生成AIの業務利用には情報漏洩・プロンプトインジェクション等の別リスクが存在する。それらについては生成AIのセキュリティリスクとは？を参照してほしい。

Q7: SANDCLOCKスティーラーの影響を受けていないか確認する方法は？

侵害されたリポジトリ（Trivy・Checkmarx・LiteLLM・BerriAI）を2026年3月前後にビルド・インストールしていた環境では、AWSキー・GitHubトークン等のクラウドシークレットが窃取されている可能性がある。

対処手順：

1. 該当期間にビルドしたCI/CDログを確認
2. AWSアクセスキー・GitHubトークン・その他クラウドシークレットをローテーション（無効化・再発行）
3. CloudTrail等でキー使用ログを確認し、不審なアクセスがないか調査

まとめ

2026年5月にGoogleが確認した「AI生成ゼロデイエクスプロイト」は、AIセキュリティの新しい段階の始まりを示している。今回はGTIGの事前検知で阻止できたが、次回の大量悪用イベントが同様に阻止される保証はない。

今回の事案から学ぶべき3つの教訓：

1. 2FAは万能ではない：認証フローの論理的な矛盾がある場合、AIによって見つけられ突破される可能性がある。フィッシング耐性MFA（FIDO2）への移行が現実的な次のステップだ
2. パッチ管理の速度が命運を分ける：AI生成ゼロデイはエクスプロイト開発のサイクルを短縮する。月次パッチ管理では間に合わなくなりつつある
3. 開発ツールのサプライチェーンが新しい攻撃経路：TeamPCP/UNC6780のGitHub供給チェーン攻撃は「信頼できるツールのビルド環境」が感染経路になることを示した

AIセキュリティ全般のリスクについては生成AIのセキュリティリスクとは？、AIエージェントを悪用した攻撃への対策についてはAIエージェントのセキュリティ対策も合わせて参照してほしい。