Google Cloud社内のAIセキュリティ実践：自律型マルチエージェント防御の全貌
1. 導入：AIが変える脆弱性対応の力学と自律防御への必然性
ソフトウェアセキュリティを取り巻く環境は、人工知能（AI）技術の進化に伴い大きく変化しています。攻撃者がAIを悪用することで、脆弱性の発見から実証コード（エクスプロイト）開発までの時間が大幅に短縮されました。
Google Cloudは、AIによって脆弱性悪用の経済性が根本から変わり、従来のパッチ（修正プログラム）適用猶予期間が実質的に消失したと説明しています。
Mandiant（Google Cloud傘下の脅威インテリジェンス部門）の調査によると、脆弱性の公開から悪用までの平均時間を示す「Time-to-Exploit」は劇的に短縮しています。2018年から2019年には平均63日でしたが、2023年にはわずか5日に縮まりました。
さらに2026年の分析では平均値がマイナス7日を記録し、パッチが公開される前の段階でゼロデイ攻撃として悪用される事例が確認されています。
実際にGoogle Threat Intelligence Groupは2026年5月、攻撃者がAIを用いて開発したとみられるゼロデイ攻撃を初確認したと報告しました。この攻撃はメモリ破壊ではなく、従来の静的解析スキャナーでは検知が難しい高水準の意味論的ロジック欠陥を突くものでした。
加えて、ソフトウェア開発の現場でもAIコーディングツールの普及が進んでいます。GitHubの2024年企業開発者調査では、回答者の97％以上が職場でAIコーディングツールを利用した経験があると回答しました。
また、DORA（DevOps Research and Assessment）の調査では、AI導入率が25％増えると個人の生産性が2.1％向上することが示されています。しかし一方で、AI導入率が25％増加するとデリバリー安定性が推定7.2％低下するというデータも報告されています。
開発速度が加速してコードの生成量が増加する中、下流工程のセキュリティ検査が手作業のままでは追いつきません。ISC2の2024年調査によると、セキュリティ組織の67％が人員不足を、90％がスキルギャップを抱えています。
従来の数カ月から数年を要した検査作業を、攻撃側はAIを用いて数時間から数分で実行できるようになりました。防御側もこれに対抗するため、手作業のチェックリストを脱却し、SDLC（ソフトウェア開発ライフサイクル）全体を自律的に防御するAIエージェント体制へ移行せざるを得ない状況が生じています。
2. 全体像：SDLC全体を覆うマルチエージェント防御体制
Google Cloudは、コード取り込みから本番運用に至るSDLCのすべての段階に、モジュール化され相互接続されたAIエージェントを配置しています。
従来のセキュリティ対策は、SAST（静的アプリケーションセキュリティテスト）やDAST（動的アプリケーションセキュリティテスト）を各開発工程で単発実行する形式が一般的でした。これに対しGoogle Cloudの新体制は、SDLC全体を単一の継続的な制御プレーン（統合制御基盤）として機能させます。
この体制では、各工程に特化した専門エージェントが連携して動作します。設計審査、ソースコード解析、動的ファジングテスト、パッチ生成、本番環境の構成監視までが一連のパイプラインとして結ばれています。
エージェント間でデータや文脈を引き継ぎながら、脆弱性の予防・発見・検証・修復を自律的に繰り返す点が大きな特徴です。
3. 設計・レビュー段階：200超の要件と突合するリアルタイム審査
製品の開発初期段階において、Google Cloudは設計審査パイプラインをエージェント型へと刷新しました。従来の手法では、開発の節目に人間が作成する静的な脅威モデルに依存していました。
新体制では、設計ドキュメントを「コントロール・カタログ」と呼ばれる200件超のセキュリティ要件とリアルタイムに突合します。審査エージェントは設計情報を読み取り、セキュリティ要件との整合性を確認しながら動的な製品ドシエ（製品カルテ）を生成・更新します。
すべての判定をAIだけで完結させるわけではありません。設計審査エージェントが高リスクなアーキテクチャ指標を検出した場合は、自動でトリアージを行い、人間のセキュリティエンジニアへエスカレーションします。これにより、設計段階における構造的な欠陥を早期に見極める体制を整えています。
4. コード解析基盤「Mantis」：トークン85％削減と誤検知の排除
ソースコード解析の中核を担うのが、Google Cloudが構築したマルチエージェント・オーケストレーション基盤「Mantis」です。単純なAIコードスキャンには課題がありました。文脈を理解しない分散型のスキャンではAIの幻覚（ハルシネーション）が頻発し、真陽性率（真の脆弱性である割合）が7％未満にとどまるケースがあったためです。
Mantisはこの課題を克服するため、階層型セキュリティ要約ツリーを採用しました。個別のソースコードファイルをディレクトリ単位、さらにはルート単位の要約へと段階的に圧縮します。
この手法により、大規模なリポジトリ全体の構造的文脈を維持しながら、トークン（AIが処理する文字や単語のデータ単位）の使用量を85％以上削減することに成功しました。
Mantis内部では、役割の異なる複数のAIエージェントが分業して解析を進めます。
- Strategist agent（戦略エージェント）：コードの全体構造、脅威モデル、依存関係グラフを評価し、リスクの高い箇所を特定して調査計画を立案します。
- Research agents（調査エージェント）：戦略に基づき、ソースコードのデータ追跡、制御フロー、入力値のサニタイズ（無害化）処理を深く調査します。
- Deduplicator, Reviewer, Critic agents（重複排除・レビュー・批評エージェント）：検出結果を精査し、ノイズや誤検知をフィルタリングして除外します。
- Reproduction sandbox（再現サンドボックス）：AIが生成した攻撃実証コード（PoC）を隔離されたエミュレーション環境で実行し、実際に悪用可能であるかを検証します。
実環境での悪用可能性をサンドボックス内で実証できた結果のみを開発者に通知することで、誤検知による開発現場の疲弊を防いでいます。
5. 動的解析：自己修復型ファジングによるテスト自律化
動的解析の工程では、AIエージェントによる「自己修復型ファジング」が導入されています。ファジングとは、ソフトウェアに予期しない大量のデータを入力してクラッシュや脆弱性をあぶり出すテスト手法です。
従来のファジングでは、テスト実行用の補助コードである「ファジングハーネス」の作成と保守に多大な人的コストがかかっていました。
Google Cloudの動的解析パイプラインは、複数のエージェントが連携して自己修復ループを形成します。
- Context agent / Drafting agent：製品のロジックや既存のユニットテストを解析し、初期のファジングハーネスを自動生成します。
- Building agent / Testing agent：生成されたハーネスを実行し、テスト環境を稼働させます。
- Hallucination Cleaner agent：コンパイルエラーやリンクエラーが発生した場合に、自動で依存関係やビルド設定を修正する「修理係」として機能します。
- Quality Analyzer agents：テストの実行状態を監視し、コードの深部に到達できるよう入力データを動的に調整します。
この自己修復ループにより、エラーによるテスト中断を手作業で直す手間を削減し、複雑なAPIに対しても継続的かつ深いファジングテストを自律実行しています。
6. 脆弱性修正と検証：再現・パッチ生成・回帰テストの連続パイプライン
脆弱性が検出された後の修正工程でも、エージェント同士が連続して連携するパイプラインが構築されています。脆弱性対応において、問題の検出以上に時間と専門知識を消費するのが「修正コードの作成と安全性の検証」です。
Google Cloudはこの工程を以下の4つのエージェントによって自動化しています。
- Reproduce agent（再現エージェント）：隔離サンドボックス内でクラッシュや不具合の再現を実行します。
- Bug Context agent（コンテキスト把握エージェント）：障害が発生した実行経路を詳細にマッピングし、根本原因を特定します。
- Patch agent（パッチ生成エージェント）：特定された根本原因に対してピンポイントな修正コードを生成します。
- Evaluation agent（評価エージェント）：修正コードを取り込んで再コンパイルし、回帰テスト（修正によって他の機能が壊れていないか確認するテスト）を実行します。
この厳格な回帰検証ループを完全に通過し、安全性が証明されたパッチのみが人間のレビュアーに提出されます。未検証のコードを人間に丸投げしない設計により、セキュリティ専門家の負担を最小限に抑えています。
7. 本番運用と学習ループ：ASPMによる是正とReflection agentの知見蓄積
ソフトウェアがリリースされた後の本番環境においても、自律的なセキュリティ防御は継続します。
Google Cloudは社内のセキュリティ標準カタログを、機械が直接実行可能な「プログラマブル・スキルファイル」へと変換しました。これを利用するASPM（アプリケーションセキュリティポスチャ管理：本番環境のセキュリティ状態を継続監視する仕組み）システムが、本番環境における構成ドリフト（意図しない設定のズレや逸脱）を常時監視します。
ポリシー違反や設定のズレを検知すると、エージェントによる修復処理が自動的に起動します。
さらに、一連のワークフローが完了した後には**Reflection agent（自己反省エージェント）**が稼働します。Reflection agentは実行ログ、使用されたツールの履歴、人間のエンジニアから得られたフィードバックを詳細に分析します。
分析によって得られた「成功した調査軌跡」や「効果的な設計パターン」は、グローバルな知識ストアへと永続的に蓄積されます。新しく起動する後続エージェントのコンテキストウィンドウ（AIが一度に考慮できる情報領域）へこの知見が注入されるため、システム全体の解析精度と修正効率が継続的に向上する仕組みとなっています。
8. エージェントの安全性とHuman-in-the-loop（人間介在）の設計境界
AIエージェントに大きな権限を与えて自律動作させるにあたっては、エージェント自体の安全性確保と適切な実行境界の設計が不可欠です。Google Cloudは、AIの非決定性や創発的挙動、プロンプトインジェクション（悪意ある入力によってAIを乗っ取る攻撃）などの残存リスクを考慮し、多層的な防御策を講じています。
堅牢なインフラとアイデンティティ管理
AI生成コードや攻撃実証コードを実行する環境には、gVisorなどのサンドボックス技術を用いたコンテナや隔離VM（仮想マシン）が用いられます。外部ネットワークへのアクセスは遮断、または厳格な許可リストによって制限されます。また、解析対象のコードに対しては不変の読み取り専用スナップショットを固定し、解析中の状態変化を防ぎます。
アクセス制御においては「Agent Identity」を導入しています。これはエージェントごとに暗号学的な一意のIDを発行し、IAM（IDおよびアクセス管理）の主体として最小権限を直接割り当てる仕組みです。これにより、共有サービスアカウントの乱用や長期認証キーの漏洩リスクを排除します。
さらに、VPC Service Controls（境界セキュリティ機能）を組み合わせることで、万が一エージェントが侵害された場合でも、境界外へのデータ持ち出しを通信レイヤーで阻止します。
人間介在（Human-in-the-loop）の境界設計
Google Cloudのシステムは完全な全自動化を目指したものではありません。危険性の高い判断ポイントには必ず人間を介在させる「Human-in-the-loop」の境界が設けられています。
- 設計段階：200超の要件に抵触する高リスクなアーキテクチャ判断は、人間のエンジニアへエスカレーションされます。
- 実装・修正段階：AIが生成した修正パッチは、自動テストをすべて通過した後に人間のレビュアーが最終確認を行い、承認を得て初めて適用されます。
エージェントに自律的な探索と検証を任せつつ、最終的なリスク判断と承認権限を人間に残すことで、安全性と自動化スピードの両立を図っています。
9. まとめと示唆：AI時代のセキュリティ運用と組織の役割変化
Google Cloudが社内で実践するマルチエージェント防御は、AI時代のセキュリティ運用に対して明確な方向性を示しています。
この体制への移行により、組織内の各役割には次のような変化が求められます。
- CISO（最高情報セキュリティ責任者）：従来のチェックリスト承認者から、セキュリティポリシーやコントロール・カタログの策定、リスク許容度の設定、人間へのエスカレーション基準を統治するデジタルリスクの総責任者へと役割がシフトします。
- セキュリティエンジニア：個別のアラート処理や手作業のコード診断から解放され、エージェントが参照するカタログの維持管理、誤検知の分析、AI実行境界の設計、高リスク事案の対応判断に集中します。
- 開発者：手作業でのテストコード保守や初期の修正案作成をAIに任せ、正確な製品コンテキストの提供と、AIが提示した検証済みパッチのレビューおよびマージ判断を担当します。
AIによる脅威が機械の速度で迫る現在、防御側もAIエージェントの力を活用した自律的なパイプラインを構築することが不可欠となっています。SDLC全体を覆うマルチエージェントの連携と、的確な人間介在の境界設計こそが、次世代のソフトウェアセキュリティを支える基盤となります。
