CodeMenderとは？脆弱性を自動修正するAIエージェントの仕組みと導入判断

CodeMenderは、ソースコードの脆弱性を見つけ、その危険性をサンドボックス内で実証し、修正パッチまで自動生成するGoogleのAIエージェントです。2025年10月6日にGoogle DeepMindが公開し、2026年7月22日にGoogle Cloudからプレビュー版の提供が始まりました。開発期間の6か月で、オープンソースへ72件のセキュリティ修正をupstreamした実績があります。この記事では、自己検証の中身、プレビュー版で確定した提供経路と対応7言語、そして自動生成されたパッチを自社のレビュー工程へどう配置するかを整理します。

まとめ：自社リポジトリへ入れる前に決める適用範囲とレビュー基準

最初に決めるのは対象リポジトリの絞り込みです。対応言語はCとC++、Go、Java、Python、Ruby、Rust、TypeScriptの7つ。この範囲外の資産は従来の手段で守る前提になります。次に決めるのがレビュー基準で、パッチはコミット前に開発者が手動で承認する設計になっているため、承認を誰がどの観点で行うかを先に文書化しておかないと、承認ボタンだけが残ります。

導入判断について立場を明確にします。テストが薄いリポジトリへ先に入れる価値は薄い。CodeMenderは差分テストとLLM judgeで機能等価性を確かめますが、その判定を最終的に受け入れるのは自社のテスト資産と人間のレビューだからです。逆に、テストが整っていてコードオーナーが明確な基盤系リポジトリでは、バッファオーバーフローのような脆弱性クラスをまとめて潰す使い方が効きます。既知CVEの依存関係側はSCAとSBOMの領分で、そちらを置き換えるものではありません。

CodeMenderが検出から検証・修正まで自律実行する処理構造

この節では、単なるパッチ生成モデルとの違いを構造から切り分けます。差がつくのは、生成したパッチを自分で疑う工程の有無です。

Gemini Deep Thinkを土台にしたエージェント設計と修正の自己修復

DeepMindの公開情報によれば、CodeMenderはGemini Deep Thinkモデルの推論能力を土台にした自律エージェントです。入力は脆弱性の指摘そのものではなく、リポジトリ全体のコンテキスト。表層のパターンではなく根本原因まで遡り、原因箇所へ手を入れる方針を取ります。

もう一つの特徴が自己修復です。生成したパッチが検証で弾かれた場合、そのフィードバックを受け取って自分で書き直す。人間が差し戻しを繰り返す往復が、エージェント内部で完結します。つまり外から見えるのは、複数回の内部反復を経た後の候補パッチだけです。

静的解析・ファジング・SMTソルバーを束ねた自動検証工程の中身

自己検証に使う道具立ては具体的に公開されています。静的解析、動的解析、差分テスト、ファジング、SMTソルバー、そして機能等価性の判定に設定されたLLM judgeツール。この6系統を組み合わせ、根本原因を直しているか、変更が正確か、リグレッションを起こしていないかを確かめます。

注目すべきは差分テストとLLM judgeの併用でしょう。セキュリティ修正で怖いのは、脆弱性は消えたが挙動も変わったという結果です。パターン検出に軸足を置くSemgrepのような静的解析ツールは「危ないコードの形」を指摘するところまでを担いますが、CodeMenderは指摘の先にある修正結果の等価性まで自分で確かめにいきます。

リアクティブ修正とプロアクティブ書き換えという2つの動作モード

動作は2モードに整理されています。リアクティブは、新たに見つかった脆弱性へ即座にパッチを当てる使い方。プロアクティブは、既存コードを書き換えて脆弱性クラスそのものを成立させなくする使い方です。

後者の実例が公開されています。画像圧縮ライブラリのlibwebpに対し、境界チェックを強制するコンパイラ機能である-fbounds-safetyのアノテーションを適用したケース。libwebpは2023年にヒープバッファオーバーフローのCVE-2023-4863を出し、zero-click iOSエクスプロイトの一部として悪用された経緯があります。DeepMindはこの脆弱性について、アノテーションを適用した範囲では他の大半のバッファオーバーフローとあわせて永続的に悪用不能になっていたはずだと述べました。個別修正ではなく、クラス単位の封じ込めを狙う設計です。

2026年7月のプレビュー版で確定した提供経路と対応言語の範囲

発表から約9か月を経て、企業が触れる形が具体化しました。ここは先行記事の多くが未反映の部分です。

Agent Platform経由とAI Threat Defense組み込みの2経路

Google Cloudが2026年7月22日に公開した内容では、提供経路が2つ示されています。1つはGemini Enterprise Agent Platform経由で一般提供中のGeminiモデルを使う形。もう1つはAI Threat Defenseのコアコンポーネントとして組み込む形です。

この違いは調達の窓口に直結します。前者はエージェント基盤の一機能として扱われ、後者は脅威防御製品の一部として入る。どちらを選ぶかで契約先の部署も、運用を担うチームも変わります。マルチモデル対応がうたわれ、2026年後半にはサードパーティのフロンティアモデルを選択肢へ加える計画も示されました。

CからTypeScriptまで7言語という対応範囲と選定への影響

プレビュー版の対応言語は7つです。

• CおよびC++
• Go
• Java
• Python
• Ruby
• Rust
• TypeScript

PHPとC#が入っていない点は、日本の受託開発や社内システムの現場では効きます。基幹をPHPで組んでいる場合、CodeMenderの守備範囲に入るのはフロント側のTypeScriptと周辺のPythonバッチだけ、という状況が普通に起こりうる。導入検討では、まず自社リポジトリの言語構成比を出し、カバー率が何割になるかを先に測ってください。カバー率が3割を切るなら、既存の静的解析と診断へ投資したほうが実効は上がります。

Gemini 3.5 Flash Cyber版が限定提供にとどまる制約と代替

公開情報でもう一段の切り分けがあります。セキュリティ特化のGemini 3.5 Flash Cyberを載せた構成は、少数の政府機関と信頼できるパートナーに限定して提供されると明記されました。一般のプレビューで使えるのは、Agent Platform上の一般提供モデルです。

ここを取り違えると期待値がずれます。報道で語られる検出精度や修正実績は、特化モデル込みの数字を含みうる。一般提供モデル構成で同じ結果が出るとは書かれていません。検証段階では、自社の既知脆弱性を含む再現リポジトリを用意し、そこで実際に何を拾い、何を落とすかを測るのが現実的な進め方です。

サンドボックス内でのエクスプロイト実証が誤検知を落とす仕組み

プレビュー版の説明で最も実務に効くのが検証工程の位置づけです。ここが従来型ツールとの分岐点になります。

顧客管理サンドボックスでPoCを構築・実行する検証工程の位置

公式の説明では、静的なコードパターン分析を超えて、エージェント自身がエクスプロイトコードを構築し、隔離された顧客管理のサンドボックス内で実行して攻撃をシミュレートします。工程を並べると次の順序です。

1. 主要な脆弱性クラスをスキャンし、リポジトリの文脈と目的を把握する
2. 候補となる欠陥に対してPoCエクスプロイトを構築する
3. 顧客管理のサンドボックス内で実行し、実在するリスクかを判定する
4. 実証された欠陥に対して安全なパッチを自動生成する
5. 開発者が手動でレビューし、承認したものだけがコミットされる

サンドボックスが顧客管理下にある点は、コードを外へ出せない案件で効いてきます。ただし実行環境を用意する責任も自社側に残るため、ビルド再現とテスト実行が回るコンテナを先に整えておく必要があります。

SASTの指摘一覧との差＝実証済みリスクだけを優先度付けする運用

SASTを入れた現場で起きるのは、数百件の指摘が積み上がり、誰も踏み込まなくなる状態です。危険度の判定が人手に残るため、トリアージが詰まります。CodeMenderはこの部分を、PoCによる実証という形で自動化しました。公式の表現では、この検証フェーズが誤検知を排除し、実証済みのリスクへ優先度を付けられるようにする、とされています。

守備範囲の違いも押さえておきましょう。自社コードの欠陥はCodeMenderの領分ですが、依存ライブラリの既知CVEはSCA（ソフトウェア構成分析）の領分です。両者は競合せず、拾う対象がそもそも違います。

自動修正パッチを既存のレビュー工程とCI/CDへ組み込む配置設計

ここからは受け入れ側の設計です。ツールの性能より、受け入れ手順の作り方で成果が分かれます。

パッチをPRで受け取る前提のブランチ保護とレビュー担当の割当

コミット前に開発者が手動でレビューし承認する、という前提が公式に明記されている以上、入口はプルリクエスト以外に選びようがありません。保護ブランチへの直接pushを禁止し、CodeMender由来のPRには専用ラベルを付け、コードオーナーの承認を必須にする。この3点を先に設定しておけば、後から運用でねじ込む手間が消えます。

レビュー担当の割り当ては、機能変更のPRと分けたほうが回ります。セキュリティ修正は「直っているか」ではなく「壊していないか」の観点が主になるためです。Claude Code ActionでGitHubのレビューを自動化する構成を既に組んでいるなら、そのワークフローの隣に並べる形で無理なく収まります。

リグレッション判定を人が肩代わりしないためのテスト資産の要件

CodeMender側は差分テストとLLM judgeで機能等価性を確かめますが、その判定はエージェントの内部基準です。自社の受け入れ基準は別に要ります。目安として、対象リポジトリのテストがCIで安定して緑になり、修正対象のモジュールに回帰テストが存在すること。この2条件が満たせないリポジトリでは、パッチの妥当性判断が全部レビュアーの読み込みに戻ります。

実務では、承認までの所要時間を測っておくと判断材料になります。1件あたり30分を超えるレビューが常態化するなら、それは対象選定かテスト資産のどちらかが足りていないサインです。

SBOMとSCAで拾う依存側の脆弱性との守備範囲と分担の決め方

脆弱性対応の手段は重ならないように配置します。混ぜると同じ脆弱性を二重管理することになり、対応漏れがかえって増えます。

この4つのうち、構成把握の土台になるのがSBOM（ソフトウェア部品表）です。どの部品がどこに入っているかが分からないままCodeMenderを回しても、直った範囲を説明できません。順番としては、SBOMとSCAで依存側を整理してから、自社コードへエージェントを向けるのが筋の通った並びになります。

自動修正エージェントを採用してよい条件と見送るべき現場の線引き

ここは判断を言い切ります。全社導入か見送りかの二択にせず、リポジトリ単位で線を引くのが実際的です。

採用条件＝テスト網羅とコードオーナーが揃うリポジトリへ限定する

採用してよいのは、次の3条件が同時に成立するリポジトリです。対応7言語に入っていること。CIでテストが安定して通ること。承認権限を持つコードオーナーが実在すること。3つ揃えば、プロアクティブモードで脆弱性クラスをまとめて潰す投資が回収できます。libwebpの事例のように、境界チェックを入れる書き換えは人手だと後回しにされ続ける類の作業だからです。

逆に、条件が揃っていない状態で自動修正を先に入れるのは順序が違います。まず現状のリスクを外部の目で洗い出し、直す優先順位を確定させるほうが先。脆弱性診断・セキュリティ診断で対象システムの実態を押さえてから、自動化をどこに効かせるかを決める流れであれば、投資の順番が崩れません。

見送るべき場面＝保守権限が外部にあるコードと規制対象の制御系

見送るべき現場も明確にしておきます。第一に、保守権限が外部ベンダーにあり、自社でコードを変更するとサポート対象外になる資産。パッチが生成できても適用できないため、レビュー工数だけが積み上がります。第二に、変更のたびに再認証や再バリデーションが必要な規制対象の制御系。医療機器や産業制御の領域では、修正1件あたりの手続きコストが自動化の利得を上回ります。

第三に、対応言語カバー率が低い環境。前述の通りPHPやC#が主体なら、いま入れる意味は薄い。この3つに当てはまる場合、プレビュー段階での導入は見送り、対応言語とモデル選択肢が広がる時点まで様子を見る判断でかまいません。

失敗パターン＝AIが直したから安全と扱いレビューが形骸化する

最も避けたい失敗は、検証工程の存在を理由にレビューが空洞化することです。CodeMenderが実証するのは「その欠陥が実在するリスクか」であって、「そのパッチが自社の業務要件を壊さないか」ではありません。判定の対象が違います。

DeepMind側も、生成されたパッチはupstream提出前にすべて人間の研究者がレビューしていると明記しました。オープンソースへの貢献ですら人手の確認を外していない。承認を1人の兼任担当へ集中させ、件数が増えたら流し読みになる、という運用は最初から破綻しています。承認の観点をチェックリスト化し、テストの緑だけを根拠にしないところまで含めて設計してください。

よくある質問

CodeMenderの導入検討でよく挙がる論点を、公開情報の範囲で整理します。

CodeMenderは今すぐ日本企業でも使えますか？

2026年7月22日にプレビュー版の提供が始まっており、Gemini Enterprise Agent Platform経由、またはAI Threat Defenseのコアコンポーネントとして利用する形が示されています。ただしアクセスは段階的な拡大が予定されている状態で、全ての組織へ即座に開かれているとは公表されていません。セキュリティ特化のGemini 3.5 Flash Cyberを載せた構成は、少数の政府機関と信頼できるパートナーに限定されます。実際の可否は自社のGoogle Cloud担当窓口で確認する形になります。

生成されたパッチをそのままマージしても問題ありませんか？

製品の設計上、そのままマージする経路は想定されていません。公式には、コードがリポジトリへコミットされる前に開発者が手動でレビューし承認することで、開発者が制御権を持ち続けると説明されています。エージェント側の自己検証は差分テストやLLM judgeによる機能等価性の確認までで、自社の業務要件との整合は対象外です。承認者と観点を決めたうえで受け入れてください。

既存のSASTツールは置き換えられますか？

置き換えではなく役割が異なります。SASTはコードの危険な記述をルールに基づいて広く指摘する手段で、対応言語も設定の自由度も現行製品のほうが広い。CodeMenderの持ち味は、実証によって誤検知を落とし、修正案まで出すところにあります。対応7言語の主要リポジトリで検証を通し、指摘の重複具合を測ってから、既存ツールの適用範囲を絞る順序が安全です。

対応していない言語のリポジトリはどうすればよいですか？

プレビュー版の対応はCとC++、Go、Java、Python、Ruby、Rust、TypeScriptの7言語です。PHPやC#が主体の資産は現時点で対象外になるため、静的解析ツールと定期的な脆弱性診断で守る方針を継続してください。マルチモデル対応と選択肢の追加が2026年後半に計画されているため、対応範囲の更新は定点で確認する価値があります。

料金はどのくらいかかりますか？

2026年8月時点で、CodeMender単体の価格体系は公開されていません。提供がGemini Enterprise Agent PlatformまたはAI Threat Defenseを経由する形である以上、費用はそれらの契約条件に紐づく構造になります。試算する場合は、エージェント基盤側の利用料に加えて、サンドボックス実行のためのビルド環境と、パッチをレビューする人的工数を見込んでおくのが実態に近い見積もりです。

関連記事

• SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い：依存ライブラリ側の守備範囲
• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断：構成把握の土台づくり
• CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説：脆弱性クラスの語彙
• Semgrepの基本概要と静的解析ツールとして選ばれる3つの理由：パターン検出側の既存手段
• Claude Code Action v1の使い方と設定｜GitHubのコードレビューをAIで自動化する：PR経由でAIを噛ませる実装