セキュリティ担当者の机の上には、今日も処理しきれない量の脆弱性アラートが積み上がっている。スキャナが吐き出す警告の数は人手の対応能力をとうに超え、本当に危険な欠陥がその山に埋もれていく。そこへ、攻撃側がAIを使って欠陥の発見と武器化を加速させるという新しい圧力が加わった。脆弱性が公表されてから実際に悪用されるまでの猶予は、もはや数週間では測れなくなっている。Google Cloudが2026年5月28日に発表した「AI Threat Defense」は、この時間差を埋めるために、欠陥の発見・評価・修正・監視を一本の自動パイプラインに通すことを狙った基盤だ。競合が「対応すべき問題のリスト」を渡すのに対し、Googleが出荷すると主張するのは「適用可能な修正」そのものである。
AI Threat Defenseは何を束ねた基盤なのか
AI Threat Defenseの核心は、Googleがこの数年で買収・開発してきた個別の道具を、一つの連続した処理として接続した点にある。構成要素は4つだ。コード解析と脅威の推論を担うGemini、クラウドインフラのリスクを評価するWiz、修正コードを書くDeepMindのCodeMender、そして実際の攻撃から得た知見と対応手順を供給するMandiantである。これらは従来それぞれ独立した製品やサービスだったが、本基盤では入力から出力まで一気通貫でつながる。
AI Threat Defenseは、2025年のGoogle Cloud Nextで示された個別のセキュリティエージェント群や、ブランド統合の枠組みである「Google Unified Security」とは異なる。脆弱性を見つけて終わりにせず、修正の作成と検証まで自動化することを目的に据えている。Googleが繰り返し強調するのは、人間のアナリストが介在する余地を「最終的なパッチの承認」へと圧縮し、その手前の労働集約的な工程を機械に肩代わりさせるという発想だ。
GoogleのこうしたメッセージはFrancis deSouza（Google Cloud COO）の言葉に集約されている。deSouza氏は、競合の多くがセキュリティチームに「長大なアラートのリストを渡すだけ」であるのに対し、Googleは「完成した修正を出荷したい」と語った。アラートは問題の所在を示すが、修正そのものではない。発見と修正の間に横たわる人手の作業をどれだけ削れるかが、この基盤の評価軸になる。
なぜ「数分での修正」を掲げる必要が生まれたのか
修正速度を売りにする背景には、攻撃側の時間感覚が劇的に縮んだという事情がある。Mandiantの調査によれば、脆弱性が公表されてから実際に悪用されるまでの平均時間（time-to-exploit）は、2021〜22年の32日から2023年には5日へと縮んだ。さらに2023年に悪用された138件の脆弱性のうち、約70%にあたる97件が、修正が存在しない状態で攻撃に使われるゼロデイ（公表前・修正前に悪用される未知の欠陥）だった。守る側が数週間かけてパッチを検証・適用するという従来の運用は、この速度の前で破綻しつつある。
この加速を押し上げているのが、攻撃側のAI活用だ。セキュリティ研究者のHimanshu Anand氏は、大規模言語モデルがバグの並列的な発見を加速させるうえ、パッチ差分（修正前後のコードの違いを示す差分情報）を数分で動作する実証コードへ変換できると指摘している。公開されたパッチは、どこがどう脆弱だったかを攻撃側に教える地図にもなりうる。Anand氏はこの現実を根拠に、ソフトウェアベンダーが慣例としてきた脆弱性公表前の「90日の猶予期間」を廃止すべきだと主張する。修正を準備する時間が、そのまま攻撃を準備する時間に転用されるという逆説だ。
Googleはこうした状況を踏まえ、AIで武装した攻撃者は脆弱性を「数週間ではなく数時間で」悪用できると説明する。ただし「数時間で悪用」も、製品名にある「数分での修正」も、Googleの主張ないし目標値であって独立に検証された実測値ではない。攻撃の加速そのものはMandiantの統計が裏付けるが、Googleの基盤がその速度に実際に追いつけるかどうかは、これから本番環境で問われる段階にある。
4段階の自動修復パイプラインはどう動くのか
AI Threat Defenseは、Prepare（準備）、Scan and Prioritize（スキャンと優先順位付け）、Remediate（修復）、Monitor（監視）という4段階のフレームワークで動く。各段階に先述の構成要素が割り当てられ、前段の出力が次段の入力になる設計だ。工程を順に追うと、この基盤が何を自動化しようとしているかが見えてくる。
最初のPrepareでは、Wizが守るべき対象の地図を描く。Googleが2025年3月18日に320億ドル（$32 billion、全額現金）で買収合意したクラウドセキュリティ企業であるWizは、外部に露出したサーバーやAPI、認証情報といった脆弱なシステムをまず洗い出す。続いてWizに組み込まれたペネトレーションテスト用のエージェント（攻撃を模擬して防御の穴を探る自律プログラム）が、検出した欠陥のうち「実際に悪用可能なものはどれか」をシミュレーションで絞り込む。理論上の欠陥と、現実に攻撃経路となる欠陥を区別する工程だ。
Scan and Prioritizeの段階では、複数のモデルを同時に使い分けるコスト設計が採られる。安価で高速なモデルが資産全体を継続的に監視する一方、能力の高いフロンティアモデルが、インターネットに接続されたアプリケーションや認証ロジックといった最重要システムを深く解析する。単一のモデルですべての欠陥を検出することはできない、というのがこの併用方式の前提だ。重要度の低い領域に高価なモデルを総当たりで投入すれば運用費が膨らむため、深い解析を本当に必要な場所へ集中させる狙いがある。
修復を担うRemediateでは、DeepMindが2025年10月に発表したコードセキュリティ用のエージェント、CodeMenderが前面に出る。CodeMenderは開発環境であるIDEやコマンドライン（CLI）に直接入り込み、脆弱なコードを書き換える。古いコードベースを、メモリの不正な読み書きを言語仕様で防ぐメモリ安全な言語へ移植したり、依存するライブラリを解析したりもする。重要なのは、パッチを出荷する前にシステムが自動でテストを生成して各修正を検証する点と、どのパッチがどのモデルから生まれたかを追跡できる（traceable）点だ。自動修正が新たな不具合を生む懸念に対し、検証と追跡可能性で歯止めをかける構えである。
最後のMonitorでは、Mandiantの蓄積が効いてくる。重大な問題が急増した際の対応や、サポート切れのレガシー製品をどう廃止していくかといった対応プレイブックをMandiantが供給し、稼働中はGoogle Security Operationsのエージェントが進行中の攻撃を能動的に探索する。発見から修正までを終えた後も、システムを監視下に置き続けることで、新たな攻撃の兆候を早期に捉えるという流れだ。
「アラートを渡す」競合との違いと残る課題
deSouza氏の「完成した修正を出荷する」という言葉は、防御側ベンダーの競争が次の段階へ移ったことを示す宣言でもある。Microsoftは自社のSecurity Copilotに自律エージェント群を投入し、アラートのトリアージ（優先度の振り分け）やインシデント対応の自動化を進めてきた。多くのベンダーが力を入れてきたのは、膨大なアラートをいかに賢く絞り込み、人間のアナリストの判断を支援するかという領域だ。Googleが引こうとしている一線は、その絞り込みの先にある修正コードの生成と適用までを引き受けるという点にある。
この構図を支えているのが、Googleが過去の買収と自社開発で積み上げた資産だ。320億ドルを投じたWizによる露出資産の特定、2022年に取得したMandiantが持つ実攻撃の知見、Geminiとフロンティアモデルによる解析、DeepMindのCodeMenderによる修正生成が、買収・開発の経緯を超えて一本の処理に統合された。個々の能力で見れば競合も類似の道具を持つが、発見から修正までを切れ目なく連結した点が、Googleの主張する差別化の実体である。
ただし、自動生成されたパッチが本番環境で信頼に足るのか、稼働中のライブコードを自律的に書き換えるエージェントが判断を誤ったときにどう対処するのかは、明らかにされていない。修正の自動生成は、検証されないまま適用されれば新たな障害や脆弱性の温床にもなりうる。発見と評価の自動化は実績の積み上がった領域だが、修正の自動出荷はまだ実運用での裏付けを欠く。
なお背景として、Anthropicの「Claude Mythos Preview」が数千の脆弱性を発見したと報じられ、その能力ゆえに限定的なアクセスで公開されたという話も伝えられている。ただしこれは二次的な情報であり、確証は弱い。攻撃と防御の双方をAIが加速させるこの構図のなかで、Googleが掲げる「数分での修正」が主張通りに機能するかは、導入パートナーであるAccenture、Deloitte、Netenrich、PwC、TENEX.AIといった現場での運用実績が積み上がるにつれて、徐々に検証されていくことになる。
