CodeMenderとは何か
ソフトウェアの脆弱性対応は、多くの開発チームにとって慢性的なボトルネックになっています。検出ツールが大量の警告を出しても、そのどれが本当に危険なのかを見極め、影響範囲を確認し、安全な修正を当てるまでには相応の人手と時間がかかります。こうした一連の作業を自律的に肩代わりするAIエージェントとして注目されているのが、Google Cloudが2026年7月22日にプレビュー公開を発表した「CodeMender」です。国内でもPublickeyが2026年7月29日に報じ、話題になりました。
CodeMenderは、コードの脆弱性を検出し、それが実際にリスクをもたらすかをサンドボックス内で検証したうえで、修正コードの生成までを自律的に実行するエージェントです。もともとはGoogle DeepMindが2025年10月6日に研究プロジェクトとして発表した技術で、そのDeepMindの研究成果を土台に、Google Cloudがエンタープライズ向けのプレビューとして提供を始めました。エンジンにはGeminiモデルが用いられており、DeepMindの発表時点ではGemini Deep Thinkの推論能力を活用すると説明されています。
対応言語はC/C++、Go、Java、Python、Ruby、Rust、TypeScriptと幅広く、サーバーサイド開発で使われる主要な言語をおおむねカバーします。提供形態はGemini Enterprise Agent Platform経由、あるいはGoogleのセキュリティ基盤であるAI Threat Defenseの構成要素としての利用が案内されています。また、サイバーセキュリティ向けに調整されたGemini 3.5 Flash Cyberについては、一部の政府機関や信頼できるパートナーに限定して提供し、今後アクセスを順次拡大していく方針が示されています。
研究段階での実績も公表されています。DeepMindの発表によると、CodeMenderの開発を進めてきた約6か月のあいだに、オープンソースプロジェクトへ72件のセキュリティ修正をupstreamとして提出しており、そのなかには最大で450万行規模のコードベースも含まれていたとされています。また、新たな脆弱性を即座に修正するreactiveな側面と、既存コードを書き換えて堅牢化するproactiveな側面の両方を備えている点も特徴として挙げられています。
検出から修正までを支える3段階のフロー
CodeMenderの動作は、検出(Scan)、検証(Verify)、修正(Remediate)という3つの段階で構成されています。単にコードを走査して警告を並べるのではなく、危険を実証してから修正まで踏み込む点が特徴です。全体像を次の図に整理しました。

それぞれの段階でCodeMenderが担う役割を、次の表にまとめます。
段階 | 主な役割 |
|---|---|
検出(Scan) | リポジトリを走査し、静的解析やモデル単体のスキャンでは見逃されがちな高度な脆弱性を見つけ出します |
検証(Verify) | 隔離されたサンドボックス内でエクスプロイトコードを構築して実行し、実証コードによって本当にリスクがあるかを確かめて誤検知を排除します |
修正(Remediate) | テスト済みの修正コードを生成し、別のAIをLLM-as-a-judgeとして用いて既存機能を壊さないかを確認します |
検証段階で使われるサンドボックスは顧客側で管理する隔離環境であり、その中で脆弱性を突く実証コードを実際に動かして危険性を裏付けます。この実証を経ることで、対応すべき本物のリスクに優先順位を付けやすくなります。DeepMindの技術基盤としては、静的解析や動的解析に加えて差分テスト、ファジング、SMTソルバーといった手法が組み合わされていると説明されています。
従来の静的解析やSASTとの違いと位置づけ
従来の静的解析やSASTツールは、コードのパターンから怪しい箇所を洗い出すことに長けている一方で、検証されていない大量の指摘を生み出しやすいという課題を抱えてきました。開発チームは、そのなかから本当に危険なものを人手で選り分ける必要があり、警告疲れに陥りがちです。両者の違いを次の表に整理します。

観点 | 従来の静的解析・SAST | CodeMender |
|---|---|---|
検出の根拠 | コードパターンによる推定が中心 | 実行可能なエクスプロイトで危険性を実証 |
誤検知の扱い | 未検証の指摘が多く選別が必要 | 実証を通じて誤検知を減らす |
アウトプット | 警告やレポートが中心 | テスト済みの修正コードまで提示 |
CodeMenderはリポジトリ固有のコンテキストや目的を踏まえて修正を提案する点も強みとされています。Google Cloudの発表では、金融サービスのRobinhoodが、他のAIツールが見逃していた重大な脆弱性をCodeMenderが一貫して検出したとコメントしたことが紹介されています。もっとも、検出率や誤検知率といった定量的なベンチマークは公式には示されていないため、既存のSASTを全面的に置き換えるものと断定するのは早計です。まずは既存ツールを補完し、検証と修正の負荷を下げる存在として位置づけるのが現実的でしょう。
開発現場に導入する際の実務上の注意点
この種の自律型セキュリティエージェントを開発現場に取り入れる際には、いくつか押さえておきたい実務上のポイントがあります。DeepMindの発表では、研究段階においてCodeMenderが生成したパッチはすべて人間の研究者がレビューしたうえでupstreamへ提出されたと明言されています。自動化されていても、最終的な判断を人間が担う前提は変わりません。主な注意点を次の表にまとめます。
観点 | 実務上の注意点 |
|---|---|
誤検知対応 | エクスプロイトで検証されるとはいえ、提示された修正の妥当性は開発チームが確認する運用を前提にします |
レビュー体制 | 自動生成されたパッチをそのままマージせず、プルリクエストとコードレビューのゲートを必ず通す設計にします |
権限管理 | サンドボックスやリポジトリへの接続権限を最小化し、機密コードの取り扱いポリシーを整備します |
責任分界 | AIが提案し人間が最終判断するという責任の分担を明文化し、チーム内で合意しておきます |
導入の初期段階では、いきなり広い範囲へ適用するのではなく、限定したリポジトリや非クリティカルなコンポーネントから試し、生成される修正の傾向やレビュー工数を実測してから対象を広げていく進め方が現実的です。あわせて、どの脆弱性に対してどの修正が提案され、誰が承認したのかを追跡できる監査ログの整備も、後から説明責任を果たすうえで役立ちます。
とりわけサーバーサイドやセキュリティを担う開発リーダーにとっては、ツールを導入して終わりではなく、生成された修正をどのプロセスで受け入れるかという運用設計が成否を分けます。サンドボックスが顧客管理である以上、実行環境のリソースや権限の設計も自チームの責任範囲になる点は見落とせません。
まとめ
CodeMenderは、脆弱性の検出からサンドボックスでの検証、修正コードの生成までを自律的に進めるAIエージェントであり、実証を伴う検証によって誤検知を抑えつつテスト済みの修正まで届けようとする点が従来の静的解析やSASTと大きく異なります。一方で、現時点ではプレビュー段階であり、定量的な性能指標は公式に公表されていません。過度な期待で全面的に任せきるのではなく、人間のレビューと権限管理を組み込んだDevSecOpsの運用に組み込むことで、その価値を安全に引き出せるはずです。まずは自チームのワークフローのどこに置くかを見極めるところから検討を始めてみてはいかがでしょうか。








.webp?q=65&fm=webp&w=400&h=260&fit=crop)








