Googleのエージェント型コードセキュリティ、脆弱性チェックを提出前に移行

Googleは、脆弱な変更が本番環境に入る前に、数億行に及ぶインフラコードの変更をすべてスキャンするエージェント型セキュリティシステムを導入したと述べている。Googleのエージェント型コードセキュリティパイプラインは、AIスキャン、構造的な検証、夜間テスト、人間によるレビューを経たパッチを組み合わせる。Googleによれば、このプロセスにより、毎月数百件の脆弱性がコードベースや本番システムに入り込むことを防いでいる。

重要な変化は、GoogleがGeminiを使ってバグを見つけるという点だけではない。Googleは、AI支援型セキュリティを、提案された個々のコード変更がたどる経路に組み込んだ。これは、多数の変更を開発者が統合した後で広範なセキュリティスキャンを実行する従来モデルに挑戦するものだ。

この発表は、OpenAI、Anthropic、Cisco、Microsoft、Googleが、ソフトウェアの脆弱性を検出または修復するAIシステムを拡大するなかで行われた。こうしたシステムは防御能力を高め得るが、同時に難しい運用上の問題も生む。脆弱性をより多く見つけても、チームがそれらを検証し、優先順位を付け、安全に修正できなければ役に立たない。

Googleのエージェント型コードセキュリティはコードが取り込まれる前に始まる

Googleは、一部の遅いリポジトリ全体のセキュリティ作業を、個別のコード変更によって起動される限定的なレビューへ置き換えている。

Googleは2026年9月18日にこのシステムを公表した。同社によれば、グローバルネットワーク、AIシステム、ユーザー向けサービスを支えるインフラ全体で稼働している。

提案された変更はそれぞれ、Googleのエンジニアがすでに使っている開発ツール内で、提出前のスキャンを受ける。提出前スキャンとは、コードが共有コードベースの一部になる前に確認することだ。このシステムは、セキュリティフィードバックを別個の監査ではなく、コンパイラ警告や可読性レビューに近いものとして扱う。

このタイミングが重要なのは、個別の変更に含まれる対象がリポジトリ全体より少ないためだ。エージェントは、無関係なすべてのコンポーネントを処理せずに、変更されたコード、その直接的な依存関係、関連する脅威の前提を調べられる。

限定的なレビューは、スキャナーにより有用な問いも与える。巨大なリポジトリに何か疑わしいものがあるかを問う代わりに、1件の変更が到達可能なセキュリティ上の弱点を導入するかを問う。

Googleの説明では、ワークフローは複数の段階に分かれている。

• 軽量なエージェントが、提案された各コード変更を調べる。

• ローカルの脅威モデルが、影響を受けるコンポーネントのセキュリティコンテキストを提供する。

• トリアージエージェントが、疑われる攻撃経路に構造上の到達可能性があるかを確認する。

• 夜間の統合テストが、複数の変更の相互作用によって生じた問題を探す。

• 修復エージェントが、人間によるレビューに向けて修正案と裏付け情報を用意する。

同社によれば、このパイプラインは数億行に及ぶ、デプロイ済みのインフラコード全体で動作している。また、このシステムが毎月数百件の脆弱性を阻止しているとも主張する。これらの数値はGoogleによるものであり、独立した監査は受けていない。

「検出する」と「防止する」の違いには注意が必要だ。エンジニアが無視したり、大半を誤報と判断したりするなら、スキャナーは多くの警告を出してもセキュリティを改善できない。

Googleは、自社の推奨事項が社内で広く採用されていると述べている。しかし発表では、採用率、深刻度の内訳、従来型スキャナーとの比較は公表されていない。

同社が明らかにした最も強い性能指標は、トリアージ段階に関するものだ。Googleによれば、このエージェントは92%以上の適合率を達成し、1分未満で応答する。

適合率は、ツールが既存の脆弱性をどれだけ発見するかではなく、報告された所見のうち本物がどれだけあるかを測る。システムは正確なアラートを出しても、発見が難しい脆弱性を見逃す可能性がある。Googleは、そのもう一つの問題を測る助けとなる再現率を公表していない。

Googleは、一部の状況では誤検知率が3%まで低いとも報告している。「一部のケース」という表現は、この数値をどこまで広く適用できるかを限定する。言語、コンポーネント、脆弱性の種類、脅威モデルの違いにより、結果は大幅に異なり得る。

それでも、このアーキテクチャはソフトウェアセキュリティにおける意味のある変化を示している。GoogleはAIレビューを、独立したセキュリティチームのための時折のアシスタントではなく、継続的な本番管理として扱っている。

このことは、今回の発表を単なるモデルベンチマーク以上に重要なものにしている。システムの価値は、開発者がコードを提出するまでの短い時間内に、信頼できる判断を下せるかにかかっている。

脆弱性発見の高速化がパッチチームに圧力をかける

AIは脆弱性発見のコストを下げているが、修復は依然としてテスト、レビュー、デプロイ能力に制約されている。

セキュリティチームは長年、発見と修復の不均衡を管理してきた。静的解析ツール、ファザー、研究者、インシデント報告は、保守担当者がすぐに調査できる数を超える問題を特定できる。

AIはこの不均衡を拡大する。エージェントは、個々の試行ごとに同等の人手を必要とせず、リポジトリを繰り返し調査し、攻撃仮説を立て、概念実証用の入力を生成できる。

しかし、信頼できる所見はいずれも作業を生む。誰かが悪用可能性を確立し、影響を受けるバージョンを特定し、深刻度を評価し、安全な修正を設計してテストし、デプロイを調整しなければならない。

Google自身のセキュリティ組織も、このボトルネックを認めている。自動化されたOSS-Fuzzパッチに関する説明で、同社は純粋にエージェント型のスキャナーが高い誤検知率を生み得ると述べている。また、最先端モデルによる継続的なスキャンは、多くのプロジェクトにとって依然として高コストになり得るとも指摘する。

この自動パッチ適用パイプラインは、OSS-FuzzとGoogle DeepMindが開発したエージェントであるCodeMenderを組み合わせる。OSS-Fuzzは再現可能なクラッシュを提供し、CodeMenderは原因を調査して修正案を提示する。

この組み合わせは、生のモデル能力だけでは不十分である理由を示している。再現可能なクラッシュは、広範なコードレビューの最中に生成された制約のない疑いよりも、修復エージェントに強い証拠を与える。

Googleのインフラシステムも、提出前に同様の原則を適用している。スキャンエージェントは問題を提案するが、別のトリアージエージェントがコード構造と到達可能性を調べる。

コールグラフは、どの関数が他の関数を呼び出せるかを示す。抽象構文木の解析は、ソースコードを単なるテキストではなく構造化されたプログラム要素として表現する。これらのツールを組み合わせることで、攻撃者が制御するデータが危険な操作に到達できるかを判断しやすくなる。

この決定論的な層は、従来のアプリケーションセキュリティ製品に圧力をかける。考えられる問題でダッシュボードを埋めるだけのスキャナーは、経路を検証しパッチを提案するシステムの隣では、役に立たないように見えるからだ。

この圧力は開発者にも及ぶ。コードレビューに直接組み込まれたセキュリティシステムは、迅速に有用な結果を返さなければならない。遅いスキャンは作業を中断し、ノイズの多い所見は開発者にアラートを無視することを学習させる。

Googleによれば、迅速な検証段階は1分未満で完了する。この性能が多様なコードベースで維持されるなら、開発者に別のワークフローを強いることなく、頻繁なスキャンを支えられる。

このアプローチは、中央集権的なセキュリティチームの役割も変える。専門家はドメインルールと脅威の前提をコード化し、エージェントが日常的なコード変更全体にそのコンテキストを適用できる。

これは人間によるセキュリティ作業をなくすものではない。専門家の役割を、管理策の設計、異例の所見の調査、最も影響が大きい可能性のある変更のレビューへと移す。

競合他社も関連するモデルを追求している。OpenAIは、リポジトリを分析し、サンドボックス内で疑われる脆弱性をテストし、修正案を提示するエージェントとしてCodex Securityを導入した。同社によれば、テスト中に約800件の重大な問題と、1万500件を超える高深刻度の問題を発見した。

これらはOpenAIの数値であり、独立して確認された測定値ではない。それでも、そのワークフローはコンテキスト分析、悪用可能性の検証、修復案を組み合わせるGoogleの手法によく似ている。

AnthropicもAI支援型の脆弱性発見を推進しており、Ciscoは自社製品全体でマルチモデルスキャンを導入している。CiscoはAxiosに対し、8週間で25のプログラミング言語にまたがる18億行をスキャンしたと述べた。

Ciscoはまた、月次のセキュリティ開示から月2回のリリースへ移行した。この変化は、より大きな発見能力が組織に開示と修復プロセスの加速を迫るという、より広範な制約を示している。

したがって主な競争は、Googleと特定の1社のベンダーとの間にあるのではない。継続的でコンテキストを認識するレビューと、検出を開発から切り離す、遅延した広範なスキャンとの競争である。

従来型スキャナーが消えることはない。シグネチャチェック、依存関係分析、ファジング、手動レビューは、それぞれ異なる失敗モードを検出する。Googleのシステムは、これらの能力の周囲に新たなオーケストレーション層を加える。

勝つアプローチは、確率的なエージェントと決定論的な証拠を組み合わせる可能性が高い。エージェントは未知のコード全体で仮説を立てられ、構造ツールとテストは裏付けのない結論を退けられる。

この組み合わせはGoogleの主張の中心にある。同社は、1つのモデルに疑問の余地のないセキュリティレビュアーとして振る舞うよう求めているわけではない。スキャン、トリアージ、テスト、修復、人間による承認を、別個の管理策に分けている。

GoogleのAI脆弱性スキャンはいかに検索範囲を狭めるか

このシステムは、複数の専門エージェントに限定的な責任とコード固有のコンテキストを与えることで、精度を高めている。

大規模なリポジトリをレビューする汎用モデルは、コンテキストの問題に直面する。コードだけでは、どの資産が重要か、信頼境界がどこにあるか、どの呼び出し元が信頼できない入力を提供できるかを説明できることは少ない。

Googleは、局所化された脅威モデルでこの弱点に対処している。脅威モデルは、保護対象の資産、想定される攻撃者、信頼境界、もっともらしい悪用経路を記録する。

同社によれば、これらのモデルは切り離された文書ではなく、稼働中のコードベースメタデータから情報を引き出す。この接続は重要だ。古い脅威モデルは、すでに存在しないアーキテクチャに基づく確信に満ちた所見を生みかねないからだ。

Googleは、オープンソースのマルチエージェントレビュー用ハーネスであるMantisを進化させ、スキャンエージェントを局所化されたモデルと接続した。ハーネスは、基盤モデルを中心にプロンプト、ツール、証拠、引き継ぎを調整する。

Mantisレビュー用ハーネスが重要なのは、システムのアーキテクチャを単一のモデルリリースから分離しているためだ。Googleによれば、適切に設計されたハーネスは、モデル間のばらつきを補える。

最初のエージェントは、関連するセキュリティコンテキストを用いて提案された変更を調べる。疑わしいデータフロー、欠落した認可チェック、安全でないメモリ操作、または別の潜在的な弱点を特定できる。

次に2番目のエージェントが、プログラム構造を用いてその仮説を検証する。コールグラフをたどり、構文を解析し、インデックス化された安全ルールを適用して、脆弱な経路に到達可能性があるかを判断する。

この段階は信頼性フィルターとして機能する。コードが脆弱なパターンに似ているかだけでなく、攻撃者が疑われる欠陥を実際に利用できるかを問う。

この違いは、報告された適合率を説明する助けになる。静的解析の警告の多くは、攻撃者が制御する入力では実行できない、理論上安全でないコードを示している。到達可能性分析は、こうしたアラートの一部を除外できる。

しかし、到達可能性だけでは、悪用可能性のすべてを確立できない。実行時設定、権限、デプロイトポロジー、そして表面化していない環境上の前提も、攻撃の成否を左右しうる。

Googleは、複数の変更にまたがる弱点を検出するため、夜間のpost-submitスキャンを追加している。pre-submitスキャナーは個々の変更を明確に捉えられる一方、別々の変更が相互作用して生じる挙動を見逃す可能性がある。

これにより、二段階のモデルが生まれる。高速なチェックは開発者の作業フローを守り、より低速な統合処理は、ピーク時間外にシステム全体への広範な影響を探索する。

パイプラインが脆弱性を検証すると、修復エージェントは検出結果と生成された証明を受け取る。その証明は、脆弱な挙動をどのように実行できるかを示すコード例である。

その後、エージェントはGoogleのコーディング標準に沿ったパッチを構築する。承認なしにデプロイするのではなく、レビューのために元の変更リクエストへ提案を添付する。

人間によるレビューは重要な安全策である。パッチはある悪用経路を遮断する一方で、正当な挙動を壊したり、別の制御を弱めたり、より見つけにくい脆弱性を生み出したりする可能性がある。

Googleのこれまでの取り組みは有用な文脈を示している。2024年の技術レポートによれば、Geminiが生成した修正は、ユニットテスト中に見つかったsanitizerバグの15％を解決した。この結果はC++、Java、Goを対象とし、数百件のパッチにつながった。

このAIパッチ適用に関する研究は、sanitizerによる検出が大量に発生するため、控えめな成功率にも価値があると位置付けた。自律修復が一般的なソフトウェアセキュリティを解決したとは主張していない。

新たなインフラストラクチャ・パイプラインは、その目標を拡張する。既知のsanitizer障害だけにモデルを適用するのではなく、通常の開発ライフサイクルの中で発見、検証、修復を結び付ける。

そのアーキテクチャは、各段階の間に有用な独立性も生み出す。Googleは、開発、スキャン、トリアージを担うエージェントについて、ルール、コンテキスト、ハーネスを分離して維持することを推奨している。

この分離は、相関した誤りを減らす。あるエージェントがコードを書き、同一のコンテキストを使って自らの出力を評価する場合、同じ誤った前提を繰り返す可能性がある。

独立したトリアージシステムであれば、当初の推論に異議を唱えられる可能性がより高い。決定論的なチェックは、単一モデルの説明への依存もさらに低減する。

この原則は、金融や安全工学で確立された統制に似ている。変更を作成する主体だけが、その変更が受け入れ可能かどうかを判断すべきではない。

同様のシステムを検討する企業にとって、隠れた要件は組織的な記憶である。ローカルの脅威モデル、依存関係マップ、安全ルール、過去のレビュー基準を最新に保たなければならない。

AIは、組織が記録していないコンテキストを利用できない。断片化したドキュメントや文書化されていないアーキテクチャは、危険な挙動と正当な例外をエージェントが見分ける能力を制限する。

このため、検索可能なエンジニアリング知識ベースには隣接する役割が生まれる。自動レビューを効果的に活用する前に、チームはアーキテクチャ上の意思決定、コード所有権、セキュリティ上の前提へ信頼できる形でアクセスできる必要がある。

したがって、この技術的仕組みは「agentic」というラベルが示唆するほど魔法的なものではない。Googleは、モデルを構造化されたコード分析、維持されたコンテキスト、非同期テスト、レビューゲートと組み合わせている。

その優位性は、こうした要素をすべての変更の周囲に配置している点にある。モデルは、セキュリティ仮説を実行可能な証拠へ変換するよう設計されたシステムの一要素にすぎない。

自動AIパッチ適用には依然として検証上の問題がある

Googleの内部結果は有望だが、公表された証拠だけでは、再現率、意味的正確性、一般的な企業への移植性は確立されない。

最も明確な不確実性は測定に関するものだ。Googleは適合率と一部の偽陽性の数値を開示したが、独立した評価データセットは提示していない。

また、検出された欠陥のうち、どれだけが重大だったのか、本番環境で悪用可能だったのか、あるいはagenticスキャンに固有のものだったのかも明らかにしていない。数百件の脆弱性を防いだという数字は、重大度と確信度が幅広く異なる事例を含みうる。

もう一つ欠けている指標は再現率である。10件の実在する脆弱性を報告し、誤報がゼロのスキャナーは高精度に見える。しかし、ほかに100件の欠陥を見逃しているなら、それは不完全なままである。

脆弱性の総数は未知であるため、再現率の測定は難しい。研究者はしばしば意図的に埋め込んだ欠陥や過去の事例を用いるが、どちらの手法も結果を歪める可能性がある。

過去のベンチマークには、トレーニングデータに公開済みのバグ報告や開発者のパッチが含まれる可能性があるため、汚染のリスクがある。エージェントは未知の脆弱性について推論するのではなく、記憶した修復を再現するかもしれない。

新しい研究はこの問題を示している。PatchBenchは、記憶された公開事例から修正を取得しにくい、移植・改変された脆弱性を対象にエージェントを評価する。

著者らは、エージェントのパッチの25％が、過去の開発者による修正と大幅に類似していたと報告した。また、概念実証のみの検証では、解決率が平均で1.83倍に水増しされることも確認した。

より強いセキュリティおよび意味的チェックの下では、主要なエージェントであってもベンチマーク課題のおよそ半数しか解決できなかった。評価対象となった11のエージェントすべてで未解決のまま残った課題は67件に上った。

PatchBenchの評価では、エージェントが根本原因を修正せずに、報告されたクラッシュだけを抑制する場合があることも示された。このようなパッチは限定的なテストには通過しても、根底にある弱点を残す可能性がある。

これらの知見は、Googleの内部での主張を直接反証するものではない。Googleの環境では、過去のベンチマークだけでなく、ライブのコード変更、局所化された脅威モデル、構造的な検証、人間によるレビューが用いられている。

しかし、この研究は、パスする証明が完全な証拠として機能しない理由を示している。パッチは、より広範な脆弱性クラスを遮断しながら、正当な機能を維持しなければならない。

Googleの夜間テストはこのリスクへの対処に役立つが、テストスイートが網羅的になることはない。生成されたパッチが、既存テストでカバーされていない挙動を変更する可能性はある。

このシステムは、脅威モデルに由来する盲点も引き継ぐ可能性がある。精密で最新のモデルはコンテキストを改善する一方、不完全なモデルは最も重要な攻撃経路を除外しかねない。

こうしたモデルの維持には継続的な作業が必要となる。サービスの進化に伴い、チームは境界、依存関係、権限、悪用ケースを更新し続けなければならない。

Googleは広範な社内ツールとセキュリティの専門知識によって、この取り組みを支えられる。より小規模な組織には、結果を再現するために必要なコードインデックス、脅威モデリングの規律、計算資源がない可能性がある。

コストも未解決の問題として残る。Googleは推論への支出、アクセラレータの使用、パイプライン運用にかかるエンジニアリングコストを開示していない。

小さな変更を1件スキャンするコストは、リポジトリ全体を繰り返しスキャンするより低い。それでも、多数のリポジトリにまたがるすべての変更へエージェントを適用すれば、累積的な需要は大きくなりうる。

Googleは、TrilliumやIronwoodのシステムを含む自社のTPUインフラストラクチャ上でGeminiを稼働させている。大半の組織は、外部プロバイダーから推論を購入するか、より厳しい予算の下で小規模なモデルを運用することになる。

データガバナンスも導入を複雑にしうる。独自のソースコードや脅威情報をホスト型モデルへ送信することは、契約、プライバシー、サプライチェーンに関する問題を生む。

企業には、コード保持、モデル学習、アクセス制御、監査ログ、テナント間分離について明確な境界が必要になる。高度に規制されたチームは、プライベートデプロイメントの選択肢を必要とするかもしれない。

利益相反の問題もある。同じAIプロバイダーが、コード生成、セキュリティレビュー、クラウドインフラストラクチャ、そしてそのすべてを評価するモデルを提供しうる。

一つのベンダーが複数の層を占める場合、独立した統制が重要になる。Axiosは、企業が作成と防御を一つのプラットフォームに依存するのではなく、複数のプロバイダーを組み合わせて維持するとセキュリティ幹部が見込んでいると報じた。

この懸念は、エージェントと検証コンテキストを分離するというGoogleの推奨を支持する。しかし、単一ベンダーのスタック内における論理的な分離は、組織的またはサプライヤーとしての独立性と同一ではない。

人間によるレビューは、こうした不確実性に対する最後の防御線であり続ける。この安全策が機能するのは、レビュアーに生成されたパッチへ異議を唱えるための十分な時間、専門性、証拠がある場合に限られる。

もっともらしい修正が大量に届けば、ノイズの多い検出結果が大量に届く場合と同じように、レビュアーは容易に圧倒される。自動化はボトルネックを解消するのではなく、移動させるだけかもしれない。

Googleは、オープンソースのメンテナーがすでに、レビュー価値がマイナスとなるAI生成のコントリビューションを受け取っていることを認めている。そのため、CodeMenderプログラムではベータ期間中に隔離テストとGoogleエンジニアによるレビューを用いている。

この教訓は企業内にも等しく当てはまる。修復エージェントは、単にプルリクエストを増やすのではなく、レビューに必要な総工数を減らすべきである。

したがって、Googleの発表を最も信頼できる形で読むなら、その意味は限定的である。同社は高度な社内パイプラインを構築し、励みになる運用指標を開示した。

この発表は、自律エージェントがセキュリティエンジニア、形式検証、ファジング、独立評価を代替できることを証明するものではない。Google自身もそのような明示的な主張はしていない。

むしろこのシステムは、信頼できる検出結果を、脆弱性が現れる瞬間により近づけようとしている。その成功はAI出力の量ではなく、証拠の品質と安全な修復にかかっている。

GoogleのAgenticコードセキュリティの次の展開

次の試金石は、Googleがより広範な測定結果を公表できるか、ワークフローを自社環境の外へ移せるか、そして修復品質を発見量より先行させ続けられるかどうかである。

Googleのagenticコードセキュリティが持続的な運用上の転換を示すかどうかは、三つのシグナルによって決まる。

第一のシグナルは測定の品質である。Googleは、異なる言語やインフラストラクチャ層における再現率の推定値、重大度の分布、導入率、パッチ回帰の結果を開示すべきだ。

外部評価は信頼性を高めるだろう。独立した研究者は、既知のパッチを再現したり、限定的なベンチマーク条件を利用したりせずに、パイプラインが新規の欠陥を検出できるかを検証できる。

より精密な報告は、「月に数百件」という主張の意味も明確にする。読者は、このシステムがなければ何件の検出結果が本番環境に到達していたか、また、その重大度がどのように確立されたのかを知る必要がある。

Googleが未知の脆弱性にまたがる再現可能な結果を公表すれば、そのアプローチへの信頼は高まる。報告が選択された適合率の数値に限られたままであれば、不確実性は続くだろう。

第二のシグナルは、Googleの外部におけるMantisの実用的な導入である。ハーネスをオープンソース化すれば、ほかの組織もオーケストレーションのロジックにはアクセスできるが、Googleの社内メタデータや運用上の成熟度までは得られない。

外部チームは、脅威モデル、コードインデックス、安全ルール、評価データセット、レビュー工程を自ら用意しなければならない。その結果は、Googleの性能のどの程度がハーネス自体に由来するかを示すことになる。

導入の成功は、インストール数やGitHubスターの数以上のものを意味する。チームは、回避された脆弱性の減少、許容可能な偽陽性率、回帰の増加を伴わない修復時間の短縮を報告すべきである。

失敗も有益な情報となる。利用者がコンテキストの維持やモデルコストの管理に苦労するなら、このアプローチは異例なほど成熟したエンジニアリング体制を持つ企業に集中したままとなるかもしれない。

第三のシグナルは競合各社の対応である。OpenAI、Anthropic、Microsoft、Cisco、そして既存のアプリケーションセキュリティベンダーは、検証済みの発見と自動修復へと収束している。

重要な比較は、どのモデルが最も多くの検出結果を生み出すかではない。悪用可能な経路を実証し、意味的に正しい修正を生成し、日々の開発に組み込めるのはどのシステムかである。

Ciscoが開示頻度を増やす決定を下したことは、AIによる発見がすでに下流の運用を変えつつあることを示している。より多くのベンダーが、リリーススケジュール、検証能力、顧客とのコミュニケーションを調整する必要に迫られるだろう。

攻撃者も、より強力な分析ツールを手にすることになる。防御側が脆弱な呼び出しパスを追跡するのを支援するエージェントは、公開されたソフトウェアを調査する者にも同様の優位性をもたらし得る。

この対称性により、脆弱性の発見から悪用までの間隔は短縮される。防御の価値は、検知だけでなく、ますますパッチ適用の速度に左右されるようになっている。

Googleのプレサブミット戦略は、攻撃者がリリース済みの成果物を調べる前に脆弱性を排除することで、これに対応するものだ。インシデント対応が迅速であっても、導入後に欠陥を発見するより強い立場にある。

ただし、プレサブミットスキャンですべての弱点をカバーできるわけではない。設定ミス、実行時の状態、侵害された依存関係、ソーシャルエンジニアリング、アーキテクチャ上の誤りは、単一のコード変更の範囲外で発生し得る。

組織は、エージェント型コードレビューを防御の一層として捉えるべきだ。ファジング、依存関係の管理、ペネトレーションテスト、ランタイム監視、アクセス制限、インシデント対応は、引き続き必要である。

開発者にとって当面の問いは、セキュリティフィードバックがより関連性を増し、妨げが少なくなるかどうかだ。到達可能なパスとレビュー済みのパッチを伴う1分未満の検出結果は、速度と信頼性の両方を向上させ得る。

セキュリティ責任者にとっての問いは、エージェントがアラートの量を増やすのではなく、総合的なリスクを低減できるかどうかだ。そのためには、流出した欠陥、修復時間、レビュアーの負担、回帰をまとめて測定する必要がある。

エンタープライズの購入担当者にとって、重要なのはエビデンスの移植可能性である。Googleの社内規模での実績は、このアーキテクチャが高度に設計された一つの環境内で運用可能であることを示している。しかし、他の環境でも同一の結果が得られることを保証するものではない。

より大きな変化は、すでに明らかになっている。アプリケーションセキュリティは、定期的な検査から、開発ワークフロー内で継続的に行われる、エビデンス主導の介入へと移行しつつある。

Googleのエージェント型コードセキュリティは、このモデルを最も明確に実装した事例の一つだ。そのエージェントは、コードが本番環境に到達する前に、スキャン、検証、再テスト、修正案の提示を行う。

今後数カ月で、Googleがより広範な検証結果を公開するか、また外部のMantisユーザーが同社の成果を再現できるかが明らかになるはずだ。こうした結果は、新たな見出し向けの検出件数よりも重要である。

エンジニアリングチームは、まず自らの基盤を見直すべきだ。脅威モデルは最新か、依存関係は把握されているか、テストは意味のあるものか、レビューの責任範囲は明確か。

これらが欠けている場合、エージェントを追加しても、そのギャップが露呈するだけで解消はされない。整っている場合には、継続的なエージェント型レビューによって、その組織的知識をより早期のセキュリティ判断へと転換できる。

本当の問いは、AIが疑わしいコードを特定できるかどうかではなくなった。組織が、各検出結果を安全かつ迅速な修正へと結び付ける、管理されたプロセスを構築できるかどうかである。