Google GTIG報告書が暴いたAI脅威の実態｜SOC・脅威インテリジェンスチームが今すぐ動くべき6つの対応

2026年5月12日、Google Threat Intelligence Group（GTIG）が「AI Threat Tracker」レポートを公開した。

このレポートが示した事実は、セキュリティ業界に明確な転換点を告げている。AIを使って開発されたゼロデイエクスプロイトが、実際の攻撃インフラで確認された。世界初の事例だ。

「いつかAIが脆弱性を発見するようになるかもしれない」という議論は終わった。すでに起きている。そしてGoogleがその計画を事前に察知して阻止できたのは、防御側もAIを使っていたからだ。

今この記事を読んでいるSOC運用者・脅威分析チーム・セキュリティアナリスト・CISOに伝えたいのは一点だ。GTIGレポートは「概要理解」のための文書ではなく、今週の対応アクションを決めるための一次情報だ。本稿では、そのための実務的読み解きを提供する。

Google GTIGレポートの脅威分析的読み解き——攻撃チェーンを整理する

GTIGレポートは、AI悪用の脅威を次の4つの軸で整理している。

1. ゼロデイ脆弱性の発見と悪用（今回初確認）
2. 防御回避能力の強化（ポリモーフィック・デコイコード）
3. 自律型マルウェアの操作（LLM統合バックドア）
4. 情報操作の拡大（AI音声クローン）

この4軸は、従来の脅威モデルとどう違うか。

従来の攻撃者は、既知の脆弱性データベース（NVD・CVE）を参照して攻撃対象を選定し、公開PoC（概念実証コード）を流用していた。攻撃の速度は「公開情報の質」に依存していた。

GTIGレポートが示した新しい攻撃チェーンはこうだ。

Step 1: ターゲット選定
LLMに大量のソースコードを読ませ、高レベルのセマンティック矛盾（開発者の意図と実装のずれ）を発見させる。ファジングや静的解析ツールが見逃す「ロジック欠陥」がターゲットになる。

Step 2: エクスプロイト開発
発見した脆弱性を利用するPythonスクリプトをLLMに生成させる。今回確認されたコードには教育的なdocstring、整ったANSIカラークラス実装など、LLM生成特有のスタイルが見られた。CVSSスコアまで「幻覚」で付与されていた点は特筆すべき観察だ。

Step 3: 大規模展開の準備
今回の攻撃者は、オープンソースのWebベース管理ツールに存在する2FA（二段階認証）バイパス脆弱性を発見し、「大規模な一斉攻撃」として展開する準備段階にあった。Googleが事前に把握して対処したため、大規模悪用は実現しなかった。

このチェーンが示す本質的な変化は「発見から展開までのサイクルが圧縮された」という点だ。

セマンティック脆弱性の発見は、従来は熟練したセキュリティ研究者が数週間～数ヶ月かけて行う作業だった。LLMはこれを大幅に高速化する可能性がある。防御側のパッチサイクルより攻撃側の開発サイクルが先行し始める世界が現実のものになりつつある。

AI悪用攻撃のTTPs——MITRE ATT&CK的観点での整理

GTIGレポートで確認された主要な手法をMITRE ATT&CKフレームワークに対応させて整理する。SOCチームの検知ルール更新・脅威ハンティングの参照用として活用してほしい。

リソース開発フェーズ（Resource Development）

ATT&CK ID	手法	確認された活動
T1587.001	マルウェア開発	CANFAIL・LONGSTREAM（AIデコイコード統合）の開発
T1587.004	エクスプロイト開発	2FAバイパスゼロデイ・PoC悪用コード生成
T1588.002	ツールの調達	CLIProxyAPI・Claude-Relay-Service・ChatGPT自動登録ツールの利用
T1588.007	AIへのアクセス獲得	自動登録パイプライン・CAPTCHA回避・SMS認証自動化でLLMアカウントを不正取得

初期アクセスフェーズ（Initial Access）

ATT&CK ID	手法	確認された活動
T1566	フィッシング	LLMで組織階層を生成し高価値幹部を標的にした精緻なフィッシング
供給チェーン侵害	AIパッケージへの埋め込み	TeamPCP（UNC6780）がLiteLLM・Trivy・CheckmarxのGitHubリポジトリを侵害

防御回避フェーズ（Defense Evasion）

ATT&CK ID	手法	確認された活動
T1027.014	ポリモーフィックコード	PROMPTFLUX: JIT（実行時）動的コード修正でシグネチャ検知を回避
T1027.016	ジャンクコード挿入	CANFAIL: 自己説明的な無用コードブロック挿入。LONGSTREAM: 32個のサマータイム問い合わせを繰り返すデコイ

実行・C2フェーズ

分類	手法	確認された活動
AML.T0103	AIエージェントの展開	PROMPTSPY: AndroidバックドアにGemini APIを統合、UIを自律操作して生体認証をバイパス
T1090.003	多段プロキシ	APT27がORBネットワーク（maxHops=3、4G/5G SIM使用）で住宅IPとして通信を匿名化

特に注視すべき手法：AI供給チェーン侵害

TeamPCP（UNC6780）によるAI関連パッケージへの侵害は、2026年の脅威ランドスケープで最も影響範囲が広いベクターのひとつだ。

LiteLLM（AI APIゲートウェイ）、Trivy（脆弱性スキャナ）、Checkmarx（セキュリティツール）といった防御ツールそのものが侵害対象になっている。これはSAST/DASTパイプラインへの信頼を根底から揺るがす。自分たちが「安全確認ツール」として使っているものが、攻撃者の侵入経路になり得るという現実だ。

SOC運用への影響——検知ルールと脅威インテリジェンスの更新ポイント

GTIGレポートが示した攻撃手法を踏まえ、SOCチームが即座に対応すべき検知シグナルを整理する。

優先度「Critical」：今週中に対応

① LLM APIへの異常な通信検知

PROMPTSPY型バックドアは、感染デバイスからGemini APIエンドポイント（generativelanguage.googleapis.com）に対してAndroid UIの階層構造XMLをPOSTする。エンドポイントの監視に加え、ペイロードがXML形式でUI階層データを含む通信を特別視すること。

② AIツールの不審なアカウント登録パターン

CLIProxyAPI・Claude-Relay-Service・ChatGPT自動登録ツールのネットワークシグネチャを検出ルールに追加する。短時間の大量アカウント登録、CAPTCHA回避ツールの使用、SMS認証の自動化パターンが指標になる。

③ AI関連パッケージの供給チェーン監査

LiteLLM・Trivy・Checkmarx・BerriAIなど、侵害が確認されたパッケージを使用している場合は直ちにバージョン確認とクレデンシャルのローテーションを実施する。ビルドパイプラインへのアクセスログを遡及調査すること。

優先度「High」：今月中に対応

④ マルウェアの振る舞い特性を検知ルールに追加

LLM生成コードには特有のパターンがある。

・過剰に詳細な教育的docstring: 通常の悪意あるコードには付かないような丁寧な説明文
・幻覚されたCVSSスコアや参照番号: 実在しないCVE番号が堂々と記載されている
・教科書的なPython実装スタイル: 整然としたANSIカラークラス、きれいすぎるコード構造
・無意味な繰り返しコードブロック（LONGSTREAM型）: 32回のサマータイム問い合わせなど、解析を撹乱する冗長コード

静的マルウェア解析チームに対して、これらの特性をLLM生成コードのインジケーターとして組み込むよう指示する。

⑤ ポリモーフィックマルウェア対策のルール見直し

PROMPTFLUX型の動的コード修正は、シグネチャベースの検知を意図的に回避する設計だ。振る舞いベース（UEBA・EDR）の検知ロジックに重点を移すことを検討する。

脅威インテリジェンス更新

今回のレポートで命名・確認されたマルウェアファミリーとツールを脅威インテリジェンスプラットフォームに登録する。

名称	種別	主な特徴
PROMPTSPY	Androidバックドア	Gemini API統合、自律UI操作、生体認証バイパス、Firebase C2
PROMPTFLUX	ポリモーフィックマルウェア	JIT動的コード修正でシグネチャ回避
CANFAIL	難読化ツール	LLM生成デコイロジックで解析を撹乱
LONGSTREAM	難読化ツール	反復的な無意味コードブロック挿入
TeamPCP / UNC6780	脅威グループ	GitHub供給チェーン攻撃、AI関連パッケージへの侵害
Claude-Relay-Service	攻撃インフラ	Claude APIへの匿名アクセス中継ツール
CLIProxyAPI	攻撃インフラ	複数LLM APIへの匿名アクセス統合ツール

CISO向け組織対応提言——リスクレジスター・予算・ガバナンスの再設計

CISOが今回のGTIGレポートを受けて経営層に提言すべき内容を整理する。

リスクレジストリの更新：新カテゴリ「AI-Augmented Threat」の追加

従来のリスクレジストリは「CVE管理」「ランサムウェア」「フィッシング」「内部不正」といったカテゴリを軸に構成されていることが多い。ここにAI支援型攻撃（AI-Augmented Threat）という新カテゴリを追加する必要がある。

このカテゴリが既存カテゴリと異なる点は「既知の脆弱性への対応」という前提が成立しない点だ。AI支援型攻撃は、従来ツールでは発見困難なセマンティック脆弱性を標的にする。つまり、現在のパッチ管理プロセスではカバーしきれない残存リスクが存在する可能性を認識する必要がある。

リスクシナリオとして記述するなら以下の形になる。

「AIを利用した脅威アクターが、自社の管理ツールや認証システムに存在するセマンティック脆弱性を発見し、2FA等の認証機構をバイパスして内部システムに侵入する。影響: 機密データの漏洩、業務継続への深刻な影響」

予算への影響：防御側AIへの投資根拠

GTIGレポートが示した防御側の成功事例は重要だ。GoogleがBig Sleep（DeepMindとProject Zeroの共同ツール）を使って攻撃者のゼロデイを事前に察知し、大規模悪用を阻止した。防御側がAIを活用することで、攻撃側のAI優位性を中和できた実例だ。

これはセキュリティ予算の再配分根拠になる。

投資が必要な領域：

1. AI支援型脆弱性スキャン（自社コードへのLLM活用）
2. AI供給チェーン監査の自動化
3. 振る舞い検知（UEBA・NDR）の強化
4. 脅威インテリジェンスプラットフォームへの最新データフィード契約

経営層への説明フレームとしては「攻撃者がAIに投資している。防御側がAIに投資しなければ、構造的な非対称性が生まれる」という軸が有効だ。

ガバナンス：シャドーAIへの対応

今回の報告書と同時期に、警視庁サイバーセキュリティ対策本部も「シャドーAI」への注意喚起を発出している。従業員が組織の管理外のAIサービスを業務で利用することで、機密情報の外部流出や、今回のような攻撃インフラ（CLIProxyAPI等）の悪用経路になる可能性がある。

組織のガバナンスとして対応すべき事項：

1. AIサービス利用ポリシーの策定・更新: 承認済みツールリストの整備と、未承認ツール使用の検知体制
2. AIアカウント管理: 組織単位でのAPI使用状況の可視化と異常検知
3. コードリポジトリへのアクセス制御強化: GitHub Actions・CI/CDパイプラインへの最小権限適用

防御側のAI活用——Red vs Blue AIの軍拡競争に勝つために

GTIGレポートが最も重要なシグナルを送っているのはここだ。防御側がAIを使わなければ、構造的に不利な戦いになる。

Big Sleep：ゼロデイを攻撃者より先に見つける

GoogleはDeepMindとProject Zeroが共同開発したBig Sleepを使い、今回のゼロデイを攻撃者の展開前に発見した。同じ概念を自組織の開発・セキュリティプロセスに組み込むことができる。

具体的には、自社で開発しているシステムのソースコードに対してLLMベースのコードレビューを導入し、セマンティック脆弱性（開発者の意図と実装のずれ）を検出するプロセスを追加することだ。これは特にWeb管理ツール・認証システム・権限管理モジュールに対して優先的に適用すべき領域だ。

CodeMender：修正も自動化する

発見した脆弱性をGemini推論で自動修正するCodeMenderの考え方も参考になる。自社のDevSecOpsパイプラインに「AI支援の自動パッチ提案」を組み込むことで、修正サイクルを短縮できる。

防御側AIの限界も理解する

GTIGレポートは防御側AIの可能性を示すと同時に、現時点の限界も示唆している。

AI支援の脆弱性発見は、有効なユーザー認証情報が攻撃の前提になっている場合が多い。今回の2FAバイパスゼロデイも「有効な認証情報の存在」が前提だ。AI技術への対策と並行して、クレデンシャル管理・特権アクセス管理（PAM）・ゼロトラストアーキテクチャへの基盤整備を怠らないことが重要だ。

脅威ハンティングへのLLM活用

Threat Intelligence チームの業務においても、LLMの活用余地がある。

・大量のインテリジェンスレポート・IOCリストの自動要約と優先順位付け
・過去のインシデントデータとの類似度検索
・YARAルール・Sigmaルールの下書き生成
・アドバーサリーシミュレーション（Purple Team演習）の効率化

ただし、LLMを使った脅威分析では「幻覚」（存在しないCVEや攻撃手法の生成）に注意する。一次情報源（GTIG・CISA・NVD・JVN等）との突合を必ず行うこと。

国内企業が今すぐ取るべき3つの対応

GTIGレポートの内容を踏まえ、日本国内の企業のセキュリティチームが今週中に着手すべき優先アクションを3点に絞る。

対応1: AI関連パッケージの緊急棚卸し

自社の開発・CI/CDパイプラインで利用しているAI関連ライブラリとツールを全量リスト化し、侵害が報告されているパッケージ（LiteLLM・Trivy・Checkmarxなど）のバージョンを確認する。

確認すべき観点：
・最後にハッシュ検証を行ったのはいつか
・異常なコード変更や依存関係の追加がないか
・ビルドパイプラインで使用しているGitHub Actionsのトークン権限は最小化されているか

このアクションは技術的なコストが低く、影響範囲の把握に直結する最優先事項だ。

対応2: 2FA・認証ロジックの特別コードレビュー

今回のゼロデイが「セマンティックロジック欠陥による2FAバイパス」だったという事実は、自社の認証システムへの問い合わせ項目になる。

開発チームまたはセキュリティエンジニアリングチームに依頼すること：
・認証・認可モジュールのロジックレビュー: 特に「ハードコードされた仮定」がないかの確認
・2FA実装に存在するバイパス可能な条件分岐がないかの確認
・外部向けWebベース管理ツールの認証フローの総点検

対応3: 脅威インテリジェンスフィードへのGTIG IOC追加

今回GTIGが公開したIOC（マルウェアハッシュ・C2インフラ・ツール名称）を脅威インテリジェンスプラットフォームに追加する。特に以下を最優先で登録する。
・PROMPTSPY・PROMPTFLUX・CANFAIL・LONGSTREAMのハッシュ・シグネチャ
・CLIProxyAPI・Claude-Relay-Serviceのネットワークシグネチャ
・generativelanguage.googleapis.comへの異常なPOST通信の検知ルール

Google Cloud脅威インテリジェンスの購読、またはMandiantのフィードを参照することで、今後の更新を継続的に取り込む体制を整えること。

「今週できない」は許容されない理由

GTIGが今回報告したゼロデイは、Googleが事前に察知したから大規模悪用が防がれた。防御側が同等の情報を持ち、同等のスピードで対応できなければ、次の「初の実例」は察知される前に展開される可能性がある。

速報として発表されたレポートの価値は、情報を知った日から対応を始めた組織にしか生まれない。

FAQ：SOC・セキュリティ担当者からよく出る疑問と継続活用の体制化

GTIGが今回公開した「AI Threat Tracker」は一度限りのレポートではなく、継続的に更新される追跡ドキュメントとして位置づけられている。Threat Intelligenceチームとして、GTIGレポート更新時（随時）に新規IOC・TTPs・脅威グループをインテリジェンスプラットフォームへ登録し、月次で検知ルール（YARA・Sigma・EDRポリシー）との整合を確認し、四半期ごとにAI支援型攻撃シナリオを含むPurple Team演習を回すサイクルを体制化することを推奨する。

Q: 今回のゼロデイはCVE番号が公開されていますか？
GTIGレポートの時点では、責任ある開示（Responsible Disclosure）プロセスが進行中のため、CVE番号は公開されていません。対象のオープンソース管理ツール名も非公開です。GTIGレポートおよびNVDの更新を継続的に監視してください。

Q: PROMPTSPYはiOSデバイスにも影響しますか？
GTIGレポートで確認されている範囲はAndroidデバイスです。AndroidのAccessibility API（アクセシビリティサービス）を利用した手法であるため、iOSでの同一手法の再現は現時点で確認されていません。ただしiOSを標的とした類似手法の開発可能性は排除できません。

Q: 中小規模のSOCでも今回の対応は現実的ですか？
AI関連パッケージの棚卸し（対応1）は人員規模に関係なく実施できます。脅威インテリジェンスフィードへのIOC追加（対応3）も多くの商用SIEMで対応可能です。認証ロジックの特別レビュー（対応2）は外部のセキュリティ診断を活用するオプションもあります。「人員が少ないから対応できない」ではなく「優先度の高い2点から着手する」姿勢が重要です。

Q: 国内では警視庁もシャドーAIへの注意喚起を出していますが、GTIGレポートとどう関係しますか？
同じ時期に出た2つの警告は、組織内の管理されていないAI利用（シャドーAI）が攻撃インフラとして利用されるリスクという共通の問題を指しています。CLIProxyAPI・Claude-Relay-Service等のツールは、組織内でシャドーAI的に使われているLLMアカウントを横断的に悪用する仕組みです。両方の警告を「AI利用ポリシーとガバナンス整備」という同一の対応アクションで受け止めることができます。

Q: Big SleepやCodeMenderは自社導入できますか？
現時点でBig SleepはGoogle社内のツールであり、外部向けに直接提供されているものではありません。ただし、同様の概念（LLMによるコードのセマンティック脆弱性検出）は商用ツールや研究段階のオープンソースプロジェクトとして存在します。CodeMenderも同様に、Gemini推論を組み込んだ自動修正の概念は段階的に商用化が進む見通しです。

Q: APT27やAPT45といった国家支援型グループは日本国内の組織を狙っていますか？
GTIGレポートでは地域別の標的については詳細が記されていませんが、中国・北朝鮮系と属性付けされたグループによるAI悪用は「脆弱性研究」「マルウェア開発」「ORBネットワーク匿名化」に主眼が置かれており、日本の重要インフラ・防衛関連・製造業も潜在的な標的圏内にあります。IPA・警察庁の国内向け脅威情報も並行して参照してください。

Q: 防御側もAIを使う場合、そのAIツール自体が攻撃対象になりませんか？
指摘の通りで、これはGTIGレポートが示す最も重要な構造問題のひとつです。TeamPCP（UNC6780）はTrivy（脆弱性スキャナ）とCheckmarx（セキュリティツール）そのものを侵害しています。防御ツールへの信頼が成立しない可能性を前提として、依存関係の検証・ハッシュ確認・サプライチェーン監査を自動化することが対策の基本になります。

あわせて読みたい本

—

GTIGレポートが示したのは、「AIがサイバー攻撃を変える」という予測の実現だ。

2026年5月12日以降、セキュリティチームに求められるのは、この現実を経営層に伝えながら、今週の対応アクションに落とし込む実行力だ。レポートを読んで終わりにしてはいけない。

セキュリティマスターズでは、こうした最新の脅威インテリジェンスを継続的に発信しています。組織のセキュリティ体制強化に向けた情報収集を、ぜひ定期的な購読という形でご活用ください。