「攻撃側がAIで脆弱性を見つけてくる速さに、守る側の手作業が追いつかない」——SOCや情シスの現場で、ここ最近いちばん切実に語られている悩みです。そこへGoogle Cloudが2026年5月28日、AIが脆弱性の発見から修復までを自動でこなす企業向けプラットフォーム「Google AI Threat Defense」を発表しました。
この記事では、攻撃者の視点も交えながら、Google AI Threat Defenseが「何を自動化する製品なのか」「SOCの運用がどう変わるのか」「自社で導入できない場合でも何を真似できるのか」を、一次情報をもとに現場で使えるレベルで整理します。製品を売り込むのではなく、守る側が冷静に評価するための視点を提供することがこの記事のねらいです。
Google AI Threat Defenseとは？（概要・なぜ重要か）
Google AI Threat Defenseは、Google Cloudが2026年5月28日に発表した、AIを活用してサイバー攻撃に自動で対処する企業向けセキュリティプラットフォームです。公式の説明では「常時稼働する自律型（always-on / autonomous）」と位置づけられており、人が常に張り付かなくても、脆弱性の発見から修復案の生成までをAIが回し続ける構成になっています。
このプラットフォームは、Googleが持つ複数の技術を1本に束ねた点が特徴です。具体的には、推論とコード生成を担うGemini、クラウドやAPIの露出状況を可視化してリスクの優先順位を付けるWiz、脆弱性の修正コードを自動生成するCodeMender、最前線の脅威インテリジェンスを担うMandiant、そしてネットワークやログを常時監視するGoogle Security Operations（SecOps）を組み合わせています。
なぜ今これが重要なのか。Googleは「攻撃者がAIを使い、かつてない速さで脆弱性を発見・悪用するようになった」「以前は数週間かかっていた攻撃が、いまや数時間から数日で実行されうる」と背景を説明しています。攻撃の速度が上がれば、守る側も同じ速度で動かなければ間に合わない——その「速度差」を埋めるためのプラットフォーム、というのが本質です。
この発表が示しているのは、セキュリティ運用の重心が「検知」から「対処の速さ」へ移りつつあるという潮流です。これまでは「いかに早く異常に気づくか」が勝負どころでしたが、攻撃が機械の速度で来る以上、気づいた後に「いかに早く塞ぐか」まで含めて自動化しないと間に合わなくなってきました。Googleが発見だけでなく修復までを一本のサイクルにまとめてきたのは、この変化を見据えてのことです。守る側としては、自社が「気づいてから塞ぐまで」にどれだけ時間がかかっているかを、あらためて測り直すきっかけにできます。なお、本記事では公式に公表されている範囲の情報のみを扱い、価格や正式な提供開始日など未公表の事項は推測で補いません。
4ステップの自律フレームワーク（敵を知り、先回りする）
Google AI Threat Defenseは、防御の流れを4つのステップに分けて自動化します。攻撃者がどの順番で弱点を探ってくるかを意識すると、各ステップの意味がつかみやすくなります。
1. Prepare（準備）——攻撃面を先に潰す
Wizの技術で、アプリケーション・クラウドインフラ・APIがどれだけ外部に露出しているかを継続的に把握し、いわば「ライブ露出マップ」を作ります。さらにAI駆動のペネトレーションテスト（疑似的な侵入テスト）エージェントが、攻撃者より先に弱点を突いてみることで、攻撃面（アタックサーフェス）を最小化します。攻撃者が偵察に使う情報を、先に自分でつぶしておく発想です。
2. Scan and Prioritize（スキャンと優先順位付け）——「全部やる」をやめる
複数のAIモデルで脆弱性を深く分析し、悪用可能性まで検証したうえで、ビジネスリスクの大きさで対処の優先順位を決めます。Googleは「単一のモデルではすべてを捕捉できない。複数のモデルで複数回パスをかけるべきだ」と説明しており、モデルを使い分ける設計を取っています。膨大な脆弱性を機械的に並べるのではなく、「先に直すべきもの」を選び出すのがこの段階です。
3. Remediate（修復）——数週間を数分に
このプラットフォームのいちばんの売りが修復の自動化です。CodeMenderが脆弱性の修正コードを自動生成し、依存関係の分析と自動テストまで実施します。Googleは「脆弱性を特定してから修復までの時間を、数週間から数分に縮める（weeks to minutes）」ことを目標に掲げています。発見して終わりではなく、直すところまで持っていく点が、他社の「発見・フラグ付け中心」のアプローチとの差別化だと公式は主張しています。
4. Monitor（監視）——機械の速度で見張る
Google Security Operationsがネットワークトラフィックやログを常時監視し、Mandiantの知見をもとにした運用フレームワークで脅威ハンティングと動的な攻撃への対応を続けます。攻撃が「機械の速度」で来る以上、監視も機械の速度で回す、という考え方です。
| ステップ | 主に使う技術 | 守る側にとっての意味 |
|---|---|---|
| Prepare | Wiz / AIペンテストエージェント | 攻撃面を先に最小化する |
| Scan and Prioritize | 複数AIモデル | 直すべき脆弱性を選び出す |
| Remediate | CodeMender / Gemini | 修正コードを自動生成・テスト |
| Monitor | Google Security Operations / Mandiant | 常時監視と脅威ハンティング |
SOC運用は何が変わるのか（攻撃者視点で読み解く）
攻撃者の立場で考えると、この種の自律型プラットフォームがいやがらせになる理由ははっきりしています。攻撃の成立は「弱点を見つけてから、守る側が直すまでの時間差（パッチギャップ）」を突くことで成り立ちます。修復が数週間から数分に縮めば、その時間差で稼ぐ攻撃モデルが崩れます。攻撃者にとっては「見つけても、すぐ塞がれてしまう」状況になるわけです。
SOC運用の側では、おそらく次のような変化が起きます。第一に、アラートの一次トリアージ（ふるい分け）と単純な修復が機械側に移り、人は「機械が出した修正案が本当に正しいか」を確認する役割に寄っていきます。第二に、優先順位付けがビジネスリスク基準で自動化されるため、「数百件の脆弱性をどれから手を付けるか」という消耗戦が減ります。第三に、自動修復が本番コードに手を入れる以上、「AIが生成した修正をどこまで人手のレビューなしで適用するか」というガバナンスの線引きが、新しい運用ルールとして必要になります。
注意したいのは、これは「SOCが要らなくなる」話ではないという点です。むしろ、機械が出してくる大量の修正案や検知結果を評価・承認する判断力が、これまで以上に問われます。自動化が進むほど、最後に責任を持って「適用する／しない」を決める人の重みは増します。
従来のSOC運用と、自律型を組み込んだ運用の違い
言葉だけでは変化が伝わりにくいので、攻撃の偵察から修復完了までの流れを、従来型と自律型で並べて比較します。ポイントは「人が手で回していた工程のうち、どこが機械に移るか」です。
| 工程 | 従来のSOC運用 | 自律型を組み込んだ運用 |
|---|---|---|
| 露出把握 | 定期スキャン＋手動の資産棚卸し | 常時の露出マッピングで自動更新 |
| 優先順位付け | CVSSスコア中心に担当者が判断 | 悪用可能性とビジネスリスクで自動採点 |
| 修復 | 担当者が修正・検証・適用（数週間） | 修正コードを自動生成・自動テスト（数分目標） |
| 監視 | アラートを人が一次トリアージ | 機械が一次トリアージ、人は承認・例外判断 |
| 人の役割 | 作業の実行者 | 機械出力の評価者・最終承認者 |
Before/Afterで言えば、従来は「脆弱性が見つかってから、担当者が手順書を引っ張り出し、検証環境で試し、本番に適用するまで数週間」というのが珍しくありませんでした。Afterの世界では、その大部分を機械が下書きし、人は「この修正で副作用が出ないか」を確認して承認する、という流れに変わります。仕事が消えるのではなく、作業から判断へ重心が移るわけです。
攻撃者がこの仕組みをどう嫌がり、どう回避を試みるか
防御を語るには、攻撃側がどう出てくるかも想定しておく必要があります。修復が高速化されると、攻撃者は「塞がれる前に使い切る」短期決戦か、自動化が見落としやすい領域へ狙いを移すと考えられます。たとえば、コードの脆弱性そのものより、設定ミス・認証情報の窃取・正規ユーザーになりすます手口は、コード修復の自動化では直接ふさげません。だからこそ、自動修復に任せる部分と、人が設計・運用で守る部分を切り分けて考えることが重要になります。自律型プラットフォームは万能の盾ではなく、防御の一部を高速化する道具だと捉えるのが健全です。
PR
攻撃者のTTPsをどう収集・分析し、SOCの意思決定に落とすかを体系立てて解説した一冊です。AIが優先順位付けを自動化する時代でも、その出力を評価する側の「脅威インテリジェンスの基礎」は人が持っておくべき土台になります。
自社で導入できない場合でも真似できる「考え方」
Google AI Threat Defenseはエンタープライズ向けで、価格や正式な提供開始時期は公式ブログに明記されていません。中小企業の情シスがすぐ導入できるとは限りません。ただ、設計思想そのものは予算がなくても取り入れられます。攻撃者視点で言えば、守る側が次の4点を意識するだけで、つけ込まれる隙はかなり減ります。
・露出の可視化を先にやる: 外部に公開しているサーバー・API・管理画面を棚卸しし、不要な公開を止める。攻撃者が偵察で最初に探すのがここです。
・「全部直す」をやめて優先順位を付ける: 実際に悪用されうる脆弱性から先に塞ぐ。CVSSスコアだけでなく「自社の資産にとっての影響」で並べ替える。
・パッチギャップを縮める段取りを作る: 検証環境・適用手順・ロールバック手順を平時に用意しておけば、いざというとき数日が数時間になる。
・ログの常時監視を仕組み化する: 高価なツールがなくても、重要な認証ログ・通信ログを集約して見る習慣だけで初動は変わる。
つまりGoogleが製品で自動化しているのは「露出把握 → 優先順位 → 高速修復 → 常時監視」というサイクルであり、このサイクル自体は規模を問わず防御の王道です。製品を買えなくても、この順番で自社の運用を見直す価値は十分にあります。
中小企業でも今日からできること
大がかりな自律プラットフォームの前に、明日から手を付けられる現実的な一歩を挙げます。どれもコストはほとんどかかりません。
・公開資産の棚卸し: 自社ドメイン配下で外部公開しているものをリスト化し、不要なものを閉じる。
・多要素認証の徹底: 管理画面・VPN・クラウド管理コンソールにMFA（多要素認証）を必須化する。攻撃の入口の多くはここで止まります。
・更新の自動化: OS・ミドルウェア・ライブラリの更新をできる範囲で自動化し、適用状況を月1で確認する。
・バックアップの3-2-1: データを3つ、媒体を2種類、1つは隔離。自動修復が普及しても、最後の砦はバックアップです。
・インシデント連絡網の明文化: 「誰が・いつ・誰に連絡するか」を1枚にまとめておく。
姉妹サイトLinuxMaster.JPでは、Linuxサーバーの権限管理やログ監視の具体的な設定を解説しています。手元のサーバーで露出を減らす実装は、そちらも参考にしてください。クラウド側のIAMやネットワーク分離についてはクラウドマスターズ.TOKYOでも扱っています。
導入を検討する前のセルフチェックリスト
自律型プラットフォームの導入を検討する前に、自社が「機械に任せられる前提」を満たしているかを確認しておくと、過剰な期待や失敗を避けられます。以下に当てはまる項目が多いほど、自動化の恩恵を受けやすい状態です。
・資産台帳がある: 守るべきサーバー・サービス・データが一覧化されているか。台帳がなければ、機械も「何を守るか」を判断できません。
・本番への変更管理ルールがある: 誰がどの手順でコードや設定を本番に反映するかが決まっているか。自動修復は変更管理の上で動きます。
・検証環境がある: 自動生成された修正を、本番前に試せる環境があるか。
・ログが集約されている: 監視を機械に任せる以上、見るべきログが1か所に集まっているか。
・承認の責任者が明確: 機械の修正案を「適用してよい」と判断する人が決まっているか。
これらが整っていないなら、高価なプラットフォームを入れる前に、まずこの土台づくりから始めるほうが費用対効果は高くなります。自動化は、整った運用の上でこそ威力を発揮します。
PR
サイバーセキュリティ 組織を脅威から守る戦略・人材・インテリジェンス（松原実穂子 著）
技術だけでなく、戦略・人材・インテリジェンスの観点から組織防御を論じた一冊です。AIによる自動化が進んでも「どう守るかを決める組織の力」は人が担います。経営層に説明する材料を探している情シスにも向いています。
よくある誤解と注意点
「AIが自動で直すなら、もう人は要らない」という受け止めは誤解です。前述のとおり、自動修復が本番コードに触れる以上、その妥当性を判断するのは人です。また「導入すれば100%安全」という保証はどこにもありません。攻撃側も同じAIを使って速度を上げてくる以上、これは終わりのない速度競争であり、特定の製品で「上がり」になることはありません。
もう一点、価格や正式な一般提供時期は本稿執筆時点で公式に公表されていません。導入を検討する場合は、必ずGoogle Cloudの公式情報と自社のパートナー（Accenture・Deloitte・PwCなどが戦略アドバイザーとして公表されています）を通じて、最新の提供条件を確認してください。本記事の数値や仕様も、必ず公式の一次情報で裏取りすることをおすすめします。
よくある質問（FAQ）
Q1. Google AI Threat Defenseは、いつ・誰が発表したものですか？
2026年5月28日にGoogle Cloudが発表した、企業向けのセキュリティプラットフォームです。AIで脆弱性の発見から修復までを自動化することを掲げています。
Q2. 既存のGoogle GTIG報告書（AI脅威レポート）とは何が違うのですか？
GTIG報告書は「攻撃者がAIをどう悪用しているか」を分析した脅威レポートです。一方Google AI Threat Defenseは、その脅威に対処するためにGoogleが提供する防御プラットフォーム製品です。前者は「現状分析」、後者は「対処手段」という位置づけの違いがあります。
Q3. 「数週間から数分」とは何の時間ですか？
脆弱性を特定してから修復（パッチ適用）までの時間です。CodeMenderによる修正コードの自動生成と自動テストで、従来数週間かかっていた工程を数分単位に縮めることを目標に掲げています。
Q4. 中小企業でも導入できますか？
現時点で価格や提供条件は公式に明記されておらず、基本的にはエンタープライズ向けです。ただし「露出把握 → 優先順位 → 高速修復 → 常時監視」という設計思想は規模を問わず有効なので、運用の見直しに取り入れる価値があります。
Q5. これでSOCの人員は減らせますか？
単純な人員削減ではなく、役割の移行と考えるのが現実的です。一次トリアージや単純修復は機械側に寄り、人は「機械の出力を評価・承認する」判断業務に重心が移ります。自動化が進むほど、最後に責任を持つ人の重要性はむしろ高まります。
本記事のまとめ
Google AI Threat Defenseは、攻撃側がAIで上げてきた速度に、守る側を同じ速度で追いつかせるためのプラットフォームです。露出の可視化、優先順位付け、自動修復、常時監視という4ステップを束ね、「発見して終わり」ではなく「直すところまで」を自動化しようとしている点が要点でした。
攻撃者視点で見れば、修復が数週間から数分に縮むことは、パッチギャップで稼ぐ攻撃モデルへの直接的な対抗策です。導入できる組織はその恩恵を受けられますが、自動修復の妥当性を判断する人の役割はむしろ重くなります。そして製品を導入できない組織でも、同じサイクルを自社の運用に落とすことはできます。正しく知って、自社にできる順番から備えていきましょう。
攻撃のスピードに、守る側の「段取り」で対抗しませんか？
AIが防御を自動化する時代でも、何を優先し何を承認するかを決めるのは人です。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。
