GoogleのAI and Infrastructureチームは2026年9月19日、自社のソフトウェア開発に、AIエージェントによる脆弱性の検査と修正を組み込んだ方法を公表しました。

同社によると、インフラに配備する数億行のコードについてすべての変更を継続的に検査し、月に数百件の脆弱性がコードベースや本番環境に入るのを防いでいます。

原典:Google Cloud Blog — Changing the game: Using agentic AI to secure infrastructure code

資料の範囲と数値の扱い

この記事は、Google Cloudのブログに掲載されたGoogleの記事1本を基にしています。原典の確認日は2026年10月3日です。

記事中の数億行、月数百件、92%超、1分未満、3%は、いずれもGoogleによる自社運用の説明で、TechDaylightは検証していません。原典は第三者による検証も示していません。

提出前に変更ごとに検査し、夜間に提出後も検査

Googleの方式は、コード変更の提出前に行う検査(プリサブミット検査)を中心に、夜間の提出後の検査と自動のバグ修正エージェントを組み合わせています。

提出前の検査では、スタックのすべての層について、コード変更を1件ずつAIエージェントでリアルタイムに評価します。プリサブミット検査は、開発者が普段使うツールに組み込まれています。

同社によると、テック業界で従来使われてきた大規模な一回限りのスキャンは、遅く文脈も足りないため、脆弱性の発見が遅れがちです。AIの観点でも、変更1件の検査なら、一回限りのスキャンより必要な文脈がはるかに少なく、検査の効果が大きく高まるとしています。

提出前の検査には、開発の生産性を妨げないよう、コードを生成する開発者やエージェントに素早く応答することが求められます。遅延を抑えるため、Googleは2段階の検証を行っています。

まず軽量な検査を手早く行い、その検出結果を専門のトリアージエージェントで確かめます。トリアージエージェントは、脆弱な経路に攻撃者が実際に到達できることを証明するため、コードの実際の構造をプログラムで調べます。使うのは抽象構文木の解析とコールグラフの走査、そして事前に索引化した、領域ごとの安全ルールです。

次に、夜間の統合テストの一部として提出後の検査を行い、2層目の防御にしています。負荷の低い時間帯の計算資源で、複数の変更をまたいで入り込んだ可能性のある脆弱性を調べます。

Mantisを発展させ、局所的な脅威モデルを組み合わせる

セキュリティエージェントの適合率(precision)を上げるため、Googleは自社のオープンソースのマルチエージェント型レビューハーネス「Mantis」を発展させました。エージェントには、局所的な脅威モデル群を組み合わせています。

脅威モデルは、コードと切り離された静的な文書ではなく、現在のコードベースから得るメタデータを使います。検査エージェントは、パッケージやライブラリをまたぐ依存関係のコールグラフで、脅威モデルの文脈を広げ精緻にします。

同社によると、脅威モデルを継続的な検査に組み込むことは、開発者に脅威と依存関係の更新を続けるよう促します。その結果、脅威モデルは最新に保たれるとしています。

誤検知率は一部で3%、トリアージの適合率は92%超

Googleは、局所的で精密な脅威モデルのデータで正確さが大きく向上し、検査の誤検知率が一部のケースで3%まで下がったとしています。

Googleによると、トリアージエージェントの適合率は92%を超え、処理は1分未満で終わります。

原典は、誤検知率が3%になったケースの条件や、誤検知率と適合率の測定期間・対象の件数を示していません。

修正案は元の変更依頼で人のレビューに回す

最後の構成要素であるバグ修正エージェントは、検査結果と、生成された証明(脆弱性がどう発動するかを示すコード片)を使います。

このエージェントは、社内のコーディング規約に沿った修正を自律的に組み立て、元の変更依頼のレビューの一部として人のレビューに提出します。

Googleは、これで検出から解決までの時間がさらに短くなるとしています。

EDITORIAL VIEW

編集部の見立て

ここからは、上の事実をもとにした編集部の読みです。確認された事実ではありません。

Googleの説明からは、脆弱性の検査を開発の後でまとめて行う作業としてではなく、コード変更の流れの中に置こうとしていることが読み取れます。AIの検出結果を構文木やコールグラフによる構造的な確認で絞り込み、修正案は既存のコードレビューに載せる構成です。

検出結果にはトリアージエージェント、修正案には人という、エージェントの出力ごとに別の確認役を置いている点も読み取れます。ただし、92%超や3%はGoogle自身の公表で測定条件が示されておらず、他の環境で同じ結果になるかは原典からは判断できません。

確度 低限られた資料からの推測で、新しい材料が出れば変わりえます。

見立ての根拠にした資料
  • Google Cloud Blog — Changing the game: Using agentic AI to secure infrastructure code:提出前の検査、局所的な脅威モデルとコールグラフ、トリアージエージェントによる到達可能性の構造的な確認、夜間の提出後検査、修正を元の変更依頼の人のレビューに出す流れ、各数値がGoogleの公表であることを確認しました。開発・検査・トリアージのエージェントのハーネス、ルール、文脈を分けるという同社の挙げた原則も読みました。
出典・更新履歴
  1. Google Cloud Blog — Changing the game: Using agentic AI to secure infrastructure code一次資料 · 発表・更新 2026-09-19 / 確認 2026-10-03

2026.10.03 11:21:原典を確認して初稿を作成しました。

SATOSHI

技術と利用条件

新機能の仕組み、料金、利用条件を具体的に整理する担当です。開発者が変更点を確かめられる、簡潔なニュースを担当します。 公開・訂正はTechDaylight編集部が担当します。

筆名について →訂正・情報提供

人気記事ランキング

COMING SOON

公開後の閲覧数をもとに、
よく読まれた記事を紹介します。

ランキング・集計について →