Google AI Threat Defenseの確認点：Wiz、CodeMender、Mandiant連携で何が変わるか

このテーマをもう少し広げて見るなら、Google Cloud DORAのAI支援開発ROI：Gemini Code Assist導入前に見るJ-Curveと費用 と Gemini in Chromeの地域拡大：日本ユーザーと管理者が確認する提供条件、タブ共有、権限 も合わせて確認してください。AI支援開発や修正自動化を導入する前に、ROIと運用変化を評価する視点を補えるため。

3行まとめ

発表の位置づけ2026年5月28日

Google Cloudは、AI時代の攻撃に対抗するAI活用型セキュリティ構想としてGoogle AI Threat Defenseを発表した。

見るべき中心4段階の接続

Prepare、Scan and prioritize、Remediate、Monitorが、自社のクラウド資産、コード管理、承認フロー、SOC運用に接続できるかを確認する。

確認待ち料金・条件・地域

料金、SKU、対応地域、契約条件、既存Wiz利用者の移行条件は、公式ブリーフィングやGoogle Cloudへの問い合わせで確認する項目として残す。

名前の新しさだけでなく、公式に確認できる構成要素と導入前に残る確認項目を分けて読む。

• Google Cloudは2026年5月28日、Google AI Threat DefenseをAI時代の攻撃に対抗するためのAI活用型セキュリティ構想として発表した。公式説明では、Geminiなどのモデル、Wiz、CodeMender、Mandiantを組み合わせ、攻撃経路の予測、優先順位付け、修正、監視までをつなぐ。
• 導入前に見るべき中心は、名前の新しさではなく、Prepare、Scan and prioritize、Remediate、Monitorの4段階が自社のクラウド資産、コード管理、承認フロー、SOC運用に接続できるかどうかだ。
• 料金、SKU、対応地域、契約条件、既存Wiz利用者の移行条件は、公開ページだけで断定しにくい。2026年6月8日時点では、公式ブリーフィングやGoogle Cloudへの問い合わせで確認する項目として残す。

Google AI Threat Defenseは、単体のスキャナーや新しいダッシュボードだけを指す言葉ではない。Google Cloudの発表は、AIを使う攻撃側の速度に対して、防御側も脆弱性の発見、優先順位付け、修正、監視を機械的に速める必要がある、という問題設定から始まっている。

Alphabet Watch Japanの読者にとって大事なのは、Google CloudのAIセキュリティ領域が、Gemini、Wiz、Mandiant、Google Security Operations、Agent Platformとどう接続されていくかだ。株価や決算の話に飛ぶ前に、まず利用者や導入企業が触れる製品・運用の変化を確認したい。

AI Threat Defenseは何を統合するのか

Geminiとfrontier models推論・深い分析

脅威理解、コード分析、修正案生成などに使われる。どの工程でどのモデルが使われ、出力を監査できるかを確認する。

Wiz文脈付き優先順位

クラウド環境や実行時文脈を踏まえ、どの脆弱性が本番やデータ、権限へつながるかを見る。

GeminiとCodeMender修正・テスト・承認

脆弱性修正、コード安全化、テスト生成、承認付き適用の文脈で見る。リポジトリ権限やCI、ロールバックも確認する。

Mandiant調査・対応支援

脅威解釈、対応準備、インシデント対応、経営報告への支援として読む。契約範囲と社内の役割分担を分ける。

公開情報だけでは料金、提供範囲、契約形態、SLA、地域を確定しきれないため、構成要素と確認項目を分ける。

Google Cloudの公式発表は、Google AI Threat Defenseを「AI-powered cybersecurity solution」と説明している。製品ページでも、AI時代の攻撃を上回るために攻撃を予測し、修正を機械速度で展開する、という趣旨が前面に出ている。

ただし、この言葉を「Google Cloudが新しい単体製品を一般販売した」と読むのは早い。公式ページには「Join a briefing」「Contact us」が置かれており、公開情報だけでは、料金、提供範囲、契約形態、SLA、地域を確定しきれない。まずは公式に確認できる構成要素と、導入前に確認すべき条件を分けたい。

公式発表で確認できる4つの構成要素

Google Cloudの発表で明示されている要素は大きく4つある。

構成要素	公式説明での役割	導入前に見ること
Geminiとその他のfrontier models	推論、深いコード分析、修正案生成、脅威理解に使われる	どのモデルがどの工程で使われるか、ログや出力を監査できるか
Wiz	クラウド環境や実行時文脈を踏まえたリスク優先順位付けに関わる	既存Wiz契約、対象クラウド、コードから本番までの到達可能性
GeminiとCodeMender	脆弱性修正、コード安全化、テスト生成、承認付き適用の文脈で語られる	リポジトリ権限、レビュー、CI、ロールバック、監査ログ
Mandiant	frontline expertiseとして、準備、対応、専門家支援の文脈に入る	インシデント対応契約、演習、経営報告、外部支援の発動条件

この4つは、それぞれ独立した製品名や組織名でもある。AI Threat Defenseを読むときは、どれが既存契約で利用中のものか、どれが新しく確認すべきものかを分けると混乱しにくい。

根拠

公式発表は、AI Threat DefenseがGeminiとその他のfrontier models、Wizの文脈付きリスク優先順位付け、GeminiとCodeMenderのコード修復能力、Mandiantの専門知見を融合すると説明している。さらに、実世界の露出状況をパッチ作成と優先順位付けへ直接つなげ、攻撃経路を予測し、重要な脅威を優先し、検証済みの修正を速く展開する、という流れで説明している。

注意点

この説明は、すべての組織が同じ形で即日利用できるという意味ではない。AI Threat Defenseの製品ページは公開されているが、実際の提供条件はブリーフィングや問い合わせを通じて確認する形に見える。導入判断では、公式の「何を目指すか」と、自社契約で「何が使えるか」を分けて読む必要がある。

6月のGoogle Cloud AI更新で上位に置かれた意味

Google Cloudは2026年6月2日のAI月次更新で、Google AI Threat Defenseを上位トピックとして扱った。同じ更新の中には、Gemini 3.5、Gemini Omni、Google Antigravity、Gemini Spark、Google Workspace、Managed Agents API、CodeMender、Nano Banana 2とNano Banana Proも並んでいる。

この並びから読み取れるのは、Google CloudがAIセキュリティを、単なる周辺機能ではなく、Agent PlatformやGemini Enterpriseの文脈と近い場所で見せていることだ。一方で、これだけで導入企業数、売上影響、競合優位を断定することはできない。

既存の開発者向け文脈を追うなら、Antigravity移行の確認点は公開済みの「Gemini CLIからAntigravity CLIへの移行」が近い。AI Threat Defenseはそこから一歩進んで、開発支援だけでなくセキュリティ運用とコード修正まで含めて読むテーマになる。

読者別に見る関心

導入企業は、Google Cloud、Wiz、Mandiant、既存SOCの契約と運用が重なる部分を見る。開発者は、CodeMenderやGeminiが作る修正案を、誰がレビューし、どのテストで受け入れ、どの権限で本番に進めるかを見る。調査担当者は、AIが見つけた大量の疑いを、到達可能性や本番影響まで含めて絞り込めるかを見る。

つまり、AI Threat Defenseの読解は「新機能一覧」ではなく「セキュリティ運用の接続図」になる。すでにGoogle Cloudの生成AI SDKやVertex AI移行を追っている読者は、「Vertex AI生成AI SDKの移行期限」とあわせて、開発基盤側の前提も確認しておきたい。

Prepare、Scan、Remediate、Monitorで何が変わるか

1. 1土台作り

   資産台帳、所有者、依存関係、既存ツール、例外管理を整え、AIが出す優先順位や修正案を評価できる状態にする。

2. 2到達可能性を見る

   発見数だけでなく、本番露出、認証境界、機微データ、顧客影響、説明責任をもとに対応順を決める。

3. 3修正と承認

   修正案、テスト、承認付き適用で速度を上げる。PR権限、CODEOWNERS、CI、ロールバック、監査ログを確認する。

4. 4継続運用へ戻す

   テレメトリ、SOC運用、Mandiant支援、対応訓練、経営報告を通じて、検知と対応演習を継続運用へつなげる。

セキュリティ担当者だけで完結せず、クラウド管理者、開発チーム、SOC、法務、経営報告まで接続して考える。

Google CloudはAI Threat Defenseを、Prepare、Scan and prioritize、Remediate、Monitorの4段階で説明している。これは、セキュリティ担当者だけで完結する話ではない。クラウド管理者、開発チーム、SOC、法務、経営報告までがつながる話だ。

段階	公式説明の方向性	社内で確認する条件
Prepare	基盤を固め、機械速度の優先順位付けと対応に備える	資産台帳、所有者、依存関係、既存ツール、例外管理
Scan and prioritize	深い分析、AIによる検証、悪用可能性の確認を行う	本番露出、認証境界、機微データ、顧客影響、優先順位の説明責任
Remediate	修正案、テスト、承認付き適用で修正速度を上げる	PR権限、CODEOWNERS、CI、ロールバック、監査ログ
Monitor	継続的な検知と演習済みの対応へ戻す	テレメトリ、SOC運用、Mandiant支援、対応訓練、経営報告

Prepareは土台作りと優先順位付けの準備

Prepareは、AIツールを入れる前の地味な工程に見える。しかし、ここが薄いと、AIが出す優先順位や修正案の良し悪しを評価できない。資産が誰のものか、どのリポジトリが本番に接続されるか、どのライブラリがどのサービスで使われているかが曖昧なままでは、速く動くほど危うくなる。

確認項目

導入前には、クラウド資産、リポジトリ、CI/CD、コンテナ、ID権限、データ分類、脆弱性バックログをつなげて棚卸しする必要がある。特に、インターネットに公開されるアプリ、顧客向けサービス、機微データへ到達できるサービス、認証・認可ロジック、権限の強いサービスは、AI Threat Defenseの文脈でも優先確認の候補になる。

注意点

AIを使うからといって、土台の弱さが自動的に解消されるわけではない。資産情報、所有者、リスク許容度、例外承認が曖昧なら、優先順位付けの結果も社内で説明しにくい。AI Threat Defenseを評価するときは、先に「自社が何を重要資産とみなすか」を定義しておきたい。

Scan and prioritizeは発見数より到達可能性を見る

従来の脆弱性管理では、CVEの深刻度やスキャン結果の件数が先に見えがちだった。AI Threat Defenseの公式説明は、そこからさらに進み、深いコード分析、AIによる敵対的テスト、悪用可能性の検証、実行時文脈を使った優先順位付けへ焦点を移している。

Google Cloudは、frontier modelsが複雑なロジック欠陥、危険な信頼境界、脆弱な依存関係、露出API、低深刻度の問題が連鎖して悪用可能になる経路を見つけうると説明している。同時に、深いスキャンは高コストで時間もかかるため、すべての資産へ同じ密度でかけるのではなく、重要システムを見極める必要がある。

評価基準

見る指標	件数だけを見る場合	AI Threat Defense文脈で追加したい視点
CVE深刻度	CVSSが高いものから順に見る	本番到達可能性、認証境界、実際の露出を合わせる
コード欠陥	静的解析の検出数を見る	複数の低深刻度欠陥が攻撃経路になるかを見る
クラウド設定	ルール違反を列挙する	機微データや特権サービスへつながるかを見る
修正順	セキュリティ部門が一括で決める	所有チーム、顧客影響、リリース予定を含めて決める

注意点

AIが見つけた候補は、必ずしもすべて即時修正すべきものではない。モデルごとに得意なセキュリティタスクが異なる、という公式説明もある。複数モデルや複数パスの結果を使うなら、重複、誤検知、説明可能性、費用を合わせて管理する必要がある。

Remediateはパッチ生成だけでなく検証と承認を見る

Remediateの章で見逃せないのは、Google Cloudが「修正案を出す」だけでなく、「テスト」「承認」「依存システムへの変更」「追跡」までを語っている点だ。公式発表では、AI Threat Defenseが修正の優先順位を付け、開発者のIDEやCLIへ修正案を出し、Gemini、CodeMender、Antigravity、Wizを使って、脆弱なコードの置き換え、古いコードのメモリ安全な言語への書き換え、ライブラリ依存関係の分析を支援すると説明されている。

Google I/O 2026のGoogle Cloud向けまとめでも、CodeMenderがAgent Platformへ統合され、脆弱性を自律的に特定し、精密な修正を提案し、安全にテストし、利用者の承認のもとでパッチや必要な変更を適用できる、と説明されている。

条件

この流れを使うには、開発チーム側の条件確認が欠かせない。ブランチ保護、CODEOWNERS、必須CI、セキュリティレビュー、変更承認、ロールバック、リリース凍結期間、監査ログが整っていないと、修正の速度だけが先に立つ。AIが作った修正案を本番へ進める責任者を決めることも必要だ。

下振れ

自動修正は、ライブラリ互換性、性能、監査要件、規制対応、顧客契約にぶつかることがある。特に、依存システムへ変更が広がる場合、単一のPRでは終わらない。「速く修正できる」と自社効果を断定するより、公式が示した修正、テスト、承認、追跡の流れを自社で再現できるかを見るほうが安全だ。

Monitorは検知と対応演習を継続運用へ戻す

Monitorでは、修正して終わりではなく、検知と対応の継続運用へ戻すことが焦点になる。AI Threat Defenseの製品ページは、Wiz Blue AgentやGoogle Security OperationsのAgentic SOC、Mandiantの支援に触れ、隠れた脅威や活動中の脅威を監視する方向を示している。

確認項目

運用側では、ネットワーク、ID、アプリケーション、コンテナ、ソフトウェア部品、クラウド設定のテレメトリが十分に集まっているかを見る。検知した後に誰が判断し、どのプレイブックで対応し、どの時点でMandiantなど外部支援を呼ぶかも、導入前に決めておきたい。

注意点

監視をAI化しても、対応訓練がなければ意思決定は遅れる。公式説明にある「machine-speed detection」や「active response」を自社の実力として読むのではなく、そこへ近づくためにどのデータと権限が足りないかを確認するのが現実的だ。

Wiz連携で見るべきこと

観点	従来の脆弱性一覧	Wiz文脈を含む優先順位付け
到達可能性	重大度や件数を中心に並ぶ	攻撃経路として到達できるかを見る
本番露出	影響範囲が抽象的になりやすい	どの本番サービス、データ、権限につながるかを見る
所有者	対応先が曖昧になりやすい	クラウド資産とリポジトリの責任者を結び付ける
修正経路	チケット化で止まりやすい	コード修正、承認、監視までの流れに接続する

AI Threat Defenseの中では、Wizが担うと説明されている文脈付き優先順位付けに絞って読む。

Wizは、Google CloudがAI Threat Defenseを語るうえで重要な位置にある。Google Cloudは2026年3月12日にWizをGoogle Cloudへ迎える公式記事を出し、5月15日のCISO向け記事では、Wizの深いクラウドテレメトリとGoogleのAI・量子研究を組み合わせる文脈を説明している。

マルチクラウドと実行時文脈が優先順位を変える

多くの企業はGoogle Cloudだけでなく、複数クラウド、SaaS、オンプレミス、複数のAIモデルを使っている。Wizの価値は、単に脆弱性を見つけることではなく、それが実際にどのクラウド資産、どの本番サービス、どのデータ、どの権限へつながるかを文脈化するところにある。

根拠

Google CloudのCISO向け記事は、世界がマルチクラウド、マルチAIになっていく中で、CISOがコードとインフラを一体で分析する必要があると説明している。さらに、開発者が自律的なエージェントシステムを作るなら、自動化された修正にも人間の監督を合わせるべきだ、という考え方を示している。

注意点

Wiz側の詳細機能を広げすぎると、Google Cloud公式情報の範囲から外れやすい。AI Threat Defenseの中でWizが担うと説明されている文脈付き優先順位付けと、Google Cloud公式記事で確認できる範囲に絞って読むのがよい。

開発者が見るべきWizの出力

開発者にとって大事なのは、Wizの出力が「どのコードを直せばいいか」まで降りてくるか、さらに「なぜそれが先なのか」を説明できるかだ。ソースコード、ライブラリ、コンテナ、クラウド設定、ID権限のどこに修正点があるのかを分ける必要がある。

修正対象	開発チームが見ること	セキュリティ部門が見ること
ソースコード	該当行、テスト、所有者、レビュー担当	悪用可能性、再発パターン、例外管理
ライブラリ	バージョン、互換性、依存先、リリース時期	到達可能性、既知悪用、影響範囲
コンテナ	ベースイメージ、署名、ビルド元	本番露出、デプロイ先、ポリシー違反
クラウド設定	IAM、ネットワーク、公開範囲	データ到達性、特権経路、横展開リスク

Wiz連携を見るときは、チケットやPRまでの動線も確認したい。優先順位が分かっても、修正が誰にも届かなければ意味がない。

CodeMenderとGeminiで開発フローはどこまで変わるか

1. 1発見

   Big SleepやOSS-Fuzzなど、Google側のAIを使った脆弱性発見の流れとつながる。

2. 2提案

   CodeMenderやGeminiがコード修正案を出す前提で、対象リポジトリと権限を確認する。

3. 3検証

   生成されたテストやCI結果を見て、修正が脆弱性を閉じ、既存機能を壊していないかを確認する。

4. 4人間の確認

   CODEOWNERS、レビュー、例外承認、拒否理由を残し、AI由来のPRを通常の変更管理へ入れる。

5. 5反映

   ロールバック手順と監査ログを用意したうえで、承認済みの修正を適用する。

6. 6運用確認

   適用後の検知、再発、例外、顧客影響を追い、次の優先順位付けへ戻す。

DeepMindの研究発表とGoogle Cloudの企業向けプラットフォーム統合は、時点も範囲も分けて確認する。

CodeMenderは、Google DeepMindが2025年10月6日に発表したコードセキュリティ向けAIエージェントだ。DeepMindの発表では、重要なソフトウェア脆弱性を自動的に修正する研究成果として説明され、リアクティブなパッチ適用と、既存コードを書き換えて脆弱性の種類ごと減らすプロアクティブな方向の両方が示されている。

CodeMenderはDeepMind由来のコードセキュリティエージェント

DeepMindの発表では、従来の自動手法だけでは見つけにくく修正にも時間がかかる脆弱性に対し、AIがコードセキュリティを改善する可能性が示された。CodeMenderは、Big SleepやOSS-Fuzzなど、Google側のAIを使った脆弱性発見の流れともつながる。

根拠

DeepMindはCodeMenderを、重大なコード脆弱性を修正するAI-powered agentとして説明している。発表時点では、構築を進めた6か月で、オープンソースプロジェクトに72件のセキュリティ修正を upstream したとも説明している。これは研究・実証の根拠として重要だが、すべての企業コードで同じ結果が出るという意味ではない。

注意点

DeepMindの研究発表と、Google CloudのAgent Platform統合は時点も範囲も違う。前者はCodeMenderの能力と研究の話、後者はGoogle Cloudの企業向けプラットフォーム上でどう提供されるかの話だ。記事では、この2つを混ぜずに読む。

Agent Platform統合で見る承認付き自動化

Google I/O 2026のGoogle Cloudまとめは、CodeMenderをAgent Platformへ統合すると説明している。そこでの重要な言い回しは、CodeMenderが脆弱性を特定し、修正を提案し、安全にテストし、利用者の承認のもとでパッチや必要な変更を適用できる、という流れだ。

条件

承認付き自動化を使うには、AIがどのリポジトリを読めるか、どのブランチへ変更を出せるか、どのテストを必須にするか、誰が拒否できるかを決める必要がある。依存システムへ必要な変更を広げるなら、開発チームだけでなく、SRE、セキュリティ、法務、顧客対応も関係する。

下振れ

自動修正が有効でも、社内の承認が遅ければ修正時間は縮まらない。逆に、承認を薄くしすぎると誤修正や監査リスクが出る。CodeMenderの評価では、平均修正時間だけでなく、誤修正、再発、例外承認、リリース遅延、レビュー負荷を見るべきだ。

開発チームの運用チェック

開発チームは、AIが作る修正案を「便利な補助」として受け取るだけでは足りない。どの範囲なら自動提案を受け入れるか、どの範囲は人間の設計判断が必要か、どの修正はセキュリティレビュー必須にするかを、先に決めておきたい。

確認領域	見る質問
ブランチ保護	AI由来の修正でも必須レビューとCIを通すか
CODEOWNERS	脆弱な箇所の所有者が自動的にレビューに入るか
監査ログ	どのモデルが、何を根拠に、どの変更を提案したか残るか
ロールバック	修正後に障害が出たとき戻せるか
例外承認	すぐ直せない脆弱性を誰がどの期限で承認するか

AI Threat Defenseの話は、開発者にとっては「セキュリティ部門の新ツール」ではなく、PR、CI、レビュー、リリースの設計を見直すきっかけになる。

MandiantとGTIGの文脈で調査・対応をどう読むか

1. 1攻撃側の変化

   攻撃者がAIを脆弱性悪用、運用強化、初期アクセスに使う背景を置く。

2. 2自社への到達可能性

   すべてを即時対応するのではなく、到達可能な経路、顧客影響、データ露出、特権経路をもとに順番を決める。

3. 3準備と対応

   導入前のreadiness、脆弱性管理の見直し、インシデント対応、経営報告、復旧後の再発防止を分けて確認する。

4. 4検知と演習

   ログ、権限、資産台帳、意思決定者を整え、外部支援を呼んだあとに社内が動ける状態にする。

5. 5再発防止

   対応後の学びを、監視、例外管理、経営報告、次の優先順位付けへ戻す。

脅威情報は煽りではなく、自社に到達しうるリスクを説明し、対応順を決めるために使う。

Google AI Threat Defenseは、AIを使う攻撃者への対抗を前提にしている。ここで背景になるのが、Google Threat Intelligence Group、Mandiant、Google Security Operationsの文脈だ。

AIを使う攻撃側の文脈を置く

GTIGは2026年5月12日のAI Threat Trackerで、攻撃者がAIを脆弱性悪用、運用強化、初期アクセスに使う文脈を説明している。この背景があるからこそ、Google Cloudは「人間の速度だけの脆弱性管理では足りない」という問題設定を置いている。

根拠

Google CloudのAI Threat Defense発表は、攻撃側の探索と悪用が速くなる中で、防御側も継続的、自律的な防御を必要とすると説明している。GTIGの脅威文脈は、脆弱性の優先順位付けや対応速度を単なる効率化ではなく、攻撃面の変化への対応として読む根拠になる。

注意点

脅威情報は、煽りに使うと判断を歪める。大事なのは、すべてを即時対応することではなく、自社に到達可能な経路、顧客影響、データ露出、特権経路をもとに順番を決めることだ。

Mandiantは導入前後の準備と対応に効く

Google Cloudのセキュリティページでは、Mandiantの専門家が侵害前、侵害中、侵害後に支援する文脈が示されている。AI Threat Defenseの公式発表でも、Mandiantのfrontline expertiseが構成要素の一つとして入っている。

確認項目

企業は、Mandiantの支援をどの段階で使うのかを確認する必要がある。導入前のreadiness、脆弱性管理の見直し、インシデント対応、経営報告、復旧後の再発防止は、それぞれ契約や支援範囲が違う可能性がある。

上振れと下振れ

専門家支援が入ると、脅威の解釈、優先順位付け、対応演習、経営層への説明が速くなる可能性がある。一方で、社内のログ、権限、資産台帳、意思決定者が整っていなければ、外部支援を呼んでも動きが詰まる。AI Threat Defenseの導入前には、Mandiantを呼ぶ条件と、社内が引き受ける作業を分けておくべきだ。

導入前チェックリスト

確認領域	見る質問	未確認なら残す表現
契約と提供条件	提供範囲、料金、SKU、対象リージョン、既存Wiz契約との関係はどうなるか	公開情報では詳細は確認中
データ、権限、証跡	コード、クラウド資産、ログ、AI生成の修正案、承認や拒否を監査できるか	契約条件と監査方法の確認が必要
運用KPI	平均修正時間、到達可能リスク、再発率、例外件数、検知から対応までの時間を追えるか	効果測定の前提を社内で決める

提供条件や料金は公開情報だけで断定せず、公式ブリーフィングや問い合わせで確認する。

AI Threat Defenseを検討するときは、公式ページを読むだけでなく、自社の前提を照合する必要がある。特に、提供条件や料金は公開情報だけで断定しにくいので、公式ブリーフィングや問い合わせで確認したい。

契約と提供条件

確認領域	見る質問	未確認なら残す表現
提供範囲	AI Threat Defenseで実際に使える機能はどこまでか	公開情報では提供範囲の詳細は確認中
料金	SKU、従量課金、既存契約との関係はどうなるか	料金は公式問い合わせで確認が必要
地域	対象リージョン、データ処理地域、サポート地域はどこか	対応地域は断定しない
Wiz	既存Wiz契約者と新規導入企業で条件が違うか	Wiz連携条件は個別確認が必要
Mandiant	専門家支援は含まれるのか、別契約か	支援範囲と費用は確認項目

データ、権限、証跡

AI Threat Defenseは、コード、クラウド資産、AIプラットフォーム、モデル、CI/CD、ログへ深く関わる。どのデータへアクセスするか、誰が見られるか、どのモデルがどの修正を提案したか、承認や拒否が残るかは重要な確認点になる。

確認項目

• リポジトリの読み取り権限と書き込み権限を分ける。
• 本番環境のクラウドテレメトリをどこまで連携するか決める。
• AIが生成した修正案、テスト、承認者、適用日時を監査できるようにする。
• 拒否した修正案や例外承認も記録する。
• 機微データ、顧客データ、ソースコードがどの契約条件で処理されるか確認する。

運用KPI

AI Threat Defenseの効果を見るなら、修正件数だけでは足りない。脆弱性バックログ、平均修正時間、到達可能リスクの削減、再発率、例外件数、検知から対応までの時間、誤修正率を合わせて見るべきだ。

注意点

公式が示す「機械速度」や「数分で修正に近づける」という方向性を、自社の導入効果としてそのまま置き換えない。KPIは、導入前の基準値を測ってから比較する必要がある。

何が変わり、何は確認待ちか

導入企業責任範囲の整理

Google Cloud、Wiz、Mandiant、既存SOCの契約と責任範囲を整理する。

開発者AI由来PRのルール

修正提案、テスト、承認、ロールバック、監査ログのルールを決める。

調査担当者脅威情報と到達可能性

GTIGやMandiantの脅威情報を、自社の到達可能性と対応優先度へ結び付ける。

経営層運用設計として見る

AIセキュリティ投資をツール導入費だけでなく、攻撃速度に対する運用設計として見る。

変わる点は運用の接続であり、料金、地域、SKU、移行条件などは公式確認待ちとして分ける。

Google AI Threat Defenseで変わるのは、AIをセキュリティの一部に足すだけではなく、コード、クラウド、脆弱性管理、SOC、専門家支援を一つの流れで見せようとしている点だ。

変わる点

導入企業は、脆弱性管理を「スキャン結果を見て手でチケット化する」運用から、到達可能性、コード修正、テスト、監視までつなぐ運用へ移す可能性を検討できる。開発者は、AIが修正案を出す前提で、レビューと承認をどう設計するかが重要になる。調査担当者は、AIが増やす発見数を、実際の攻撃経路と対応優先度へ絞る目が必要になる。

読者別の次の一手

• 導入企業は、Google CloudとWiz、Mandiant、既存SOCの契約と責任範囲を整理する。
• 開発者は、AI由来のPR、テスト、承認、ロールバックのルールを決める。
• 調査担当者は、GTIGやMandiantの脅威情報を、自社の到達可能性と結び付ける。
• 経営層は、AIセキュリティ投資をツール導入費ではなく、攻撃速度に対する運用設計として見る。

確認待ちにする点

2026年6月8日時点で、料金、SKU、地域、既存Wiz利用者の条件、Mandiant支援の範囲、データ処理条件、Agent Platform上でのCodeMender提供範囲は、公開情報だけでは断定しないほうがよい。公式ページの更新、Google Cloud Security関連イベント、製品ドキュメントの追加を待つ必要がある。

Alphabet Watch JapanはAlphabet、Google、Google Cloudと非提携の独立メディアです。商標や公式サービス名は説明目的で使っています。導入判断や契約条件は、必ずGoogle Cloudの公式窓口と一次情報で確認してください。

更新履歴

1. 2026年6月8日 18:00 Asia/Tokyo公式情報を確認

   Google Cloud公式発表、AI Threat Defense製品ページ、Google Cloud AI月次更新、Google I/O 2026のGoogle Cloudまとめ、DeepMindのCodeMender発表、Wiz関連のGoogle Cloud公式記事、GTIGのAI Threat Trackerを確認した。

2. 公開後追記候補を確認

   料金、提供地域、SKU、既存Wiz利用者の条件、CodeMenderの展開範囲、Mandiant支援の扱いが公式ページで更新された場合は追記する。

公開時点で確認した情報と、今後の公式更新で変わりうる項目を分けて残す。

• 2026年6月8日 18:00 Asia/Tokyo時点で、Google Cloud公式発表、AI Threat Defense製品ページ、Google Cloud AI月次更新、Google I/O 2026のGoogle Cloudまとめ、Google DeepMindのCodeMender発表、Wiz関連のGoogle Cloud公式記事、GTIGのAI Threat Trackerを確認した。
• 公開後に、AI Threat Defenseの料金、提供地域、SKU、既存Wiz利用者の条件、CodeMenderの展開範囲、Mandiant支援の扱いが公式ページで更新された場合は追記する。

AlphabetのGoogle Cloud、Gemini、セキュリティ関連の公式発表を継続して追う場合は、2026年6月の重要トピックまとめと資料・確認ログも合わせて確認できます。

---

次に読むなら

参照した主な情報源

• https://cloud.google.com/blog/products/identity-security/introducing-google-ai-threat-defense
• https://cloud.google.com/security/ai-threat-defense
• https://cloud.google.com/blog/products/ai-machine-learning/what-google-cloud-announced-in-ai-this-month
• https://cloud.google.com/blog/products/ai-machine-learning/innovations-from-google-io-26-on-google-cloud
• https://deepmind.google/discover/blog/introducing-codemender-an-ai-agent-for-code-security/
• https://cloud.google.com/blog/products/identity-security/cloud-ciso-perspectives-how-google-wiz-changes-multicloud-strategy-for-cisos
• https://cloud.google.com/blog/products/identity-security/google-completes-acquisition-of-wiz
• https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access
• https://cloud.google.com/security
• https://cloud.google.com/security/ai