攻撃側が「プロンプト」から「自律」に移った。6時間で2万3千件

Google Threat Intelligence Group（GTIG）が2026年9月9日、攻撃者のAI利用に関する報告を出した。中心にある観測はこれである。

2026年5月の報告以降、GTIG は前のめりな攻撃者が基本的なプロンプトから、エージェント型のAIワークフローとAIによる自動化へ移行するのを観測してきた。

時間が詰まった

報告がもっとも重く扱っているのは、能力ではなく速度である。

これらの作戦では、human-in-the-loop の遅延が劇的に減り、防御側が対応する従来の時間枠が圧縮される。 2026年第2四半期、GTIG は攻撃者がクラウド資源を侵害したのち、エージェントを用いた大規模な資格情報収集キャンペーンを6時間未満で計画・構築・実行するのを観測した。

この作戦では 23,800件を超える秘密情報（APIキーを含む）が収集された。使われたのは特別な道具ではなく、AIコーディングチャットボット1つ、プロンプト1つ、エージェント指示のセットである。

Markdown の指示書が作戦手順書として機能し、パイプラインの管理・リアルタイムの障害対応・IPローテーションが人手を介さずに回っていた。

開発者の手元が狙われている

DUSTMAKER と名付けられたマルウェアは、AIコーディング支援と開発者を直接狙う。報告が挙げている機能のうち、2つが実務に効く。

隠しディレクトリによる検知回避。 対象として .claude/・.vscode/・.cursor/ が名指しされている。開発者の手元にある設定ディレクトリが、そのまま隠し場所になっている。

プロンプトインジェクションによるセキュリティスキャナの無効化。 LLMベースのスキャナに対して、生物・核兵器に関する極端な敵対的テキストを埋め込み、安全性による拒否を意図的に引き起こして検査を止める。

ほかに、IDE の起動コマンドへの設定乗っ取りによる永続化、GitHub Actions からの OIDC トークン窃取が挙がっている。

で、SEの実務ではどう使うか

守る場所のリストに、開発者の設定ディレクトリを足す必要がある。

これまで .claude/ や .vscode/ は「個人の設定」として監視の対象外に置かれがちだった。報告が示しているのは、そこが攻撃者にとって都合のよい場所になっているということである。

実務で確認できることが3つある。

設定ディレクトリが監査の対象に入っているか。 リポジトリ内の .claude/ 配下は、コードと同じレビューを通っているか。プラグインやスキルを外部から入れる運用があるなら、そこは実行されるコードと同じ重さで扱う必要がある。

CI の OIDC トークンの扱い。 GitHub Actions の OIDC は署名付きパッケージの公開に使える。窃取されたときの影響範囲を、権限の粒度で絞れているか。

LLM ベースの検査に、拒否を引き起こす入力への耐性があるか。 スキャナが拒否して止まったとき、それが「安全」と解釈されていないか。止まったことを検知できなければ、素通りと区別がつかない。 これは自動化全般に共通する形で、このサイトでも何度か踏んでいる。

速度の話も設計に効く。 6時間で完了する攻撃に対して、日次のバッチ検査は間に合わない。検知の周期が攻撃の周期より遅ければ、検知は事後報告になる。

引用と数字はすべて GTIG の報告に記載されているものである。