公開2026.08.10更新2026.10.24 脆弱性・インシデント

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

CodeMenderは、ソースコードの脆弱性を見つけ、その危険性をサンドボックス内で実証し、修正パッチまで自動生成するGoogleのAIエージェントです。2025年10月6日にGoogle DeepMindが公開し、2026年7月22日にGoogle Cloudからプレビュー版の提供が始まりました。2026年10月のCLI v0.15〜0.16系ではディープスキャンが既定になり、事前確認コマンドとSARIF出力の改善が入りました。この記事では、自己検証の中身、対応言語の現状、CIへ組み込む設定例、自動生成パッチをレビュー工程へどう配置するかを整理します。

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

最初に決めるのは対象リポジトリの絞り込みです。7月時点で7つだった対応言語は、2026年10月時点でPHPとC#を含む既定10系統に広がりました。次に決めるのがレビュー基準で、パッチはコミット前に開発者が手動で承認する設計になっているため、承認を誰がどの観点で行うかを先に文書化しておかないと、承認ボタンだけが残ります。

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

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

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

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

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

もう一つの特徴が自己修復です。生成したパッチが検証で弾かれた場合、そのフィードバックを受け取って自分で書き直す。人間が差し戻す往復がエージェント内部で完結し、外から見えるのは内部反復を経た候補パッチだけです。製品版のCodeMender概要ドキュメントでは、この流れが検出（find）・検証（verify）・修正（fix）の3段階に整理され、CLIのサブコマンドもその単位です。

静的解析・ファジング・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月のプレビュー開始から10月までに広がった提供経路と対応言語

7月に企業が触れる形が具体化し、その後3か月で対象言語とモデルの選択肢が増えました。

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

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

この違いは調達の窓口に直結し、どちらを選ぶかで契約先の部署も運用チームも変わります。10月時点の提供段階はPublic Previewです。セッションデータの保持は最大7日間で、顧客のコードを学習に使わないと説明されています。

7言語から既定10系統へ広がった対応範囲とPHP・C#資産の扱い

プレビュー開始時の対応はCとC++、Go、Java、Python、Ruby、Rust、TypeScriptの7言語でした。2026年9月21日のv0.9.0でC#、Kotlin、PHPなどが既定のスキャン対象に加わり、10月時点では.NETとJavaScriptも含めた10系統が既定のサポート言語です。

基幹をPHPやASP.NETで組んだ国内の業務システムも、いまは検証の土俵に乗れます。既定外の言語は設定のscan.extensions.includeで拡張子を足せますが、公式は既定外では結果の品質が変わりうると注記しています。導入検討では、まず自社リポジトリの言語構成比を出し、既定10系統でカバーできる割合を先に測ってください。カバー率が3割を切るなら、既存の静的解析と診断へ投資したほうが実効は上がります。

既定のGemini 3.8 Flashと許可制のCyber版・4 Argonの選び方

モデルの構成も7月から変わりました。2026年9月16日のv0.8.0で、CLIの既定モデルはGemini 3.8 Flashになっています。セキュリティ特化のGemini 3.8 Flash Cyberは同日付で提供段階こそGAですが、利用には許可リストへの登録が必要です（7月時点の前世代Cyber版は政府機関と一部パートナー限定でした）。さらに10月13日には、--model gemini-4-argonの指定でGemini 4 Argonをプレビューとして選べるようになりました。

報道で語られる精度は特化モデル込みの数字を含みうるため、既定モデルで同じ結果が出るとは限りません。自社の既知脆弱性を含む再現リポジトリで、既定モデルと上位モデルを同条件で回して比べるのが現実的です。

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

従来型ツールとの分岐点は検証工程の位置づけにあります。

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

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

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

サンドボックスが顧客管理下にある点は、コードを外へ出せない案件で効いてきます。ただし実行環境を用意する責任も自社側に残るので、ビルド再現とテスト実行が回るコンテナを先に整えてください。CLIでは設定のbuild.commandにビルドとテストを書き、v0.10.0以降のcm fixはその成功を修正完了の条件にしています。v0.16.0ではcm verifyの書き込み先がプロジェクト直下の.exploit/に限定されました。

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

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

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

cm CLIのv0.15〜0.16で変わったスキャンの既定とCIへ入れる設定例

CodeMenderの実体はcmというコマンドラインツールで、Agent Platformのリリースノートには9月以降ほぼ毎週の改版が載り、10月時点の版はv0.16系です。

ディープ・クイック・差分の3モードとv0.16.0で変わった既定動作

10月21日のv0.16.0で、引数なしのcm findはファイル単位で並列に監査するディープスキャンを既定で実行するようになりました。従来の単一セッションのスキャンは--quickで呼び出します。find modesのドキュメントが示す使い分けは次の通りです。

モード	指定	向く場面
ディープ	既定（–deep-workers）	夜間監査やリリース前
クイック	–quick	手元での素早い確認
差分	–diff	PRのCIゲート
差分の一部	–diff –staged	コミット前の確認

ディープは時間がかかり、PRを止める同期チェックには向かないと公式自身が書いています。PRには差分スキャン、ディープは夜間ジョブ、という分担を最初に決めてください。差分スキャンは変更した関数を呼ぶ未変更ファイルも既定で1ホップ分まで追い、v0.14.0からは削除されたセキュリティ制御も検出します。

手元で試す初期設定とv0.16.0で入ったcm healthの事前確認

必要なAPIはAgent Platform APIとCloud Resource Manager APIで、実行アカウントにはAgent Platform Userロール（roles/aiplatform.user）を付けます。CLIのインストールと設定に沿うと、手元での最初の確認は次の流れです。

gcloud auth application-default login
export GOOGLE_CLOUD_PROJECT="PROJECT_ID"
cd ./your-repo
cm init --verify
cm health --strict
cm find ./src --quick
cm report --status=OPEN

cm healthはv0.16.0で追加され、スキャン前に認証情報・設定・エンドポイント到達性・プロジェクト権限をまとめて確かめます。CIの冒頭に置けば、権限不足で長いスキャンが途中で落ちる無駄を減らせるでしょう。設定ファイルの既定の場所は~/.codemender/config.yamlです。

GitHub ActionsでPR差分を検査しSARIFを送るワークフロー

公式のCI/CD連携ガイドにはGitHub Actions、Cloud Build、pre-commitの3例が載っています。認証は鍵を置かずWorkload Identity Federationで行う構成で、google-github-actions/authの設定と鍵JSONからの移行判断を済ませていればそのまま流用できます。公式例のスキャンジョブから要点だけを抜き出すと次の形です。

name: CodeMender
on:
  pull_request:
permissions: {}
env:
  CM_DOWNLOAD_URL: https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-amd64.zip:download?alt=media
jobs:
  scan:
    runs-on: ubuntu-24.04
    timeout-minutes: 15
    permissions:
      contents: read
      id-token: write         # Workload Identity Federation
      security-events: write  # SARIFをCode Scanningへ送る
      actions: read           # プライベートリポジトリから送る場合
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: google-github-actions/auth@v3
        with:
          project_id: ${{ secrets.GCP_PROJECT_ID }}
          workload_identity_provider: ${{ secrets.GCP_WIF_PROVIDER }}
          service_account: ${{ secrets.GCP_WIF_SERVICE_ACCOUNT }}
      - name: Install the CodeMender CLI
        run: |
          curl -fsSL -o "$RUNNER_TEMP/cm.zip" "$CM_DOWNLOAD_URL"
          unzip -q -o "$RUNNER_TEMP/cm.zip" -d "$RUNNER_TEMP/cm"
          echo "$RUNNER_TEMP/cm" >> "$GITHUB_PATH"
      - name: Scan the pull request
        env:
          BASE_REF: ${{ github.base_ref }}
        run: |
          cm init
          cm find . \
            --diff="origin/$BASE_REF" \
            --fail-on=CRITICAL,HIGH \
            --format=sarif \
            --output=codemender.sarif \
            --sandbox=false --yes --bypass-warning
      - name: Upload results to code scanning
        if: ${{ !cancelled() && hashFiles('codemender.sarif') != '' }}
        uses: github/codeql-action/upload-sarif@v4
        with:
          sarif_file: codemender.sarif
          category: codemender

--fail-onに一致する重大度の指摘がPR由来で見つかると、cm findは終了コード1を返してチェックを落とします。PRで触っていない既存コードの指摘はゲートを止めません。10月14日のv0.15.0ではSARIF 2.1.0出力のルール定義・重大度・相対パスが整えられ、GitHub Code Scanningでの表示互換が上がりました。プライベートリポジトリから送るにはGitHub Code Securityの契約が要ります。

抜粋ではフォークとDependabotのPRを除外する公式例の条件を省きました。--sandbox=falseは使い捨てランナー前提の指定です。公式例にはcm fixの結果を別の修正PRとして開くautofixジョブも続き、受け口はあくまでPRです。

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

成果を分けるのはツールの性能より受け入れ手順の作り方です。

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

コミット前に開発者が手動でレビューし承認する、という前提が公式に明記されている以上、入口はプルリクエスト以外に選びようがありません。保護ブランチへの直接pushを禁止し、CodeMender由来のPRに専用ラベルを付け、コードオーナーの承認を必須にする。この3点を先に設定してください。v0.12.0以降のcm fixは、対象の脆弱性と無関係なCI/CD設定やビルド定義を変更しないよう制限されています。

レビュー担当の割り当ては、機能変更のPRと分けたほうが回ります。セキュリティ修正は「直っているか」ではなく「壊していないか」の観点が主になるためです。Claude Code ActionでGitHubのレビューを自動化する構成を既に組んでいるなら、そのワークフローの隣に並べる形で無理なく収まります。GitHub上で完結する類似の仕組みとしてはGitHub Copilot Autofixがあり、CodeQLの指摘に修正案を付ける方式です。CodeMenderはPoCで実在を確かめてから直す点が異なり、併用するなら担当をリポジトリ単位で分けると重複が減ります。

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

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

実務では、承認までの所要時間を測っておくと判断材料になります。1件あたり30分を超えるレビューが常態化するなら、それは対象選定かテスト資産のどちらかが足りていないサインです。費用の計測にはcm stats --jsonが使え、v0.15.0からはモデル呼び出し回数も出ます。

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

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

手段	拾う対象	主な出力
SCA	依存ライブラリの既知CVE	更新・除去の指示
SBOM	構成部品の一覧と来歴	影響範囲の特定
SAST	自社コードの危険な記述	指摘とルール違反
CodeMender	実証された自社コードの欠陥	検証済みパッチ案

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

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

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

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

採用してよいのは、次の3条件が同時に成立するリポジトリです。既定の10系統の言語に入っていること。CIでテストが安定して通ること。承認権限を持つコードオーナーが実在すること。3つ揃えば、プロアクティブモードで脆弱性クラスをまとめて潰す投資が回収できます。libwebpの事例のように、境界チェックを入れる書き換えは人手だと後回しにされ続ける類の作業だからです。プレビューの間は検証用の複製リポジトリで差分スキャンを回し、的中率とレビュー時間を2〜4週間測ってから範囲を広げてください。

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

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

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

第三に、既定10系統の外にある言語が主体の環境と、本番コードへの即時適用を求められる場面です。COBOLや独自DSLが中心なら、拡張子を足しても品質は保証されません。Public Previewは評価目的の提供でもあるため、この場合は検証環境での評価にとどめ、正式提供を待つ判断でかまいません。

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

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

DeepMind側も、生成されたパッチはupstream提出前にすべて人間の研究者がレビューしていると明記しました。製品ドキュメントも、人の確認を無効にした場合の責任は利用者にあると注記しています（CI例の--yesはその確認を飛ばす指定です）。承認を1人の兼任担当へ集中させ、件数が増えたら流し読みになる運用は最初から破綻しています。承認の観点をチェックリスト化し、テストの緑だけを根拠にしないところまで含めて設計してください。

よくある質問

導入検討でよく挙がる論点を、2026年10月時点の公開情報で整理します。

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

2026年7月22日にプレビュー版の提供が始まり、10月時点でも提供段階はPublic Previewです。利用開始には営業担当への問い合わせが必要です。評価目的の提供で本番用途は想定されておらず、Gemini 3.8 Flash Cyberは別途許可リストへの登録が要ります。

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

想定されていません。公式には、コミット前に開発者が手動でレビューし承認する設計と説明されています。CI連携の公式例でも、修正は別の修正PRとして開かれ、各コミットを確認してからマージするよう案内されます。自己検証は機能等価性までで、業務要件との整合は対象外です。

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

置き換えではなく役割が異なります。SASTはルールに基づいて広く指摘する手段で、ルール調整や監査証跡では現行製品に分があります。CodeMenderは実証で誤検知を落とし、修正案まで出す。既存SASTの指摘を取り込んで裏づける並べ方から始め、重複を測ってから範囲を見直す順序が安全です。

PHPやC#のリポジトリにも使えますか？

使えます。プレビュー開始時は7言語でしたが、2026年9月21日のv0.9.0でC#やPHP、Kotlinが既定のスキャン対象に加わりました。10月時点の既定は10系統です。これ以外の言語も設定で拡張子を追加できますが、結果の品質は変わりうるとされています。対象外の資産は静的解析と定期診断で守る方針を続けてください。

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

2026年10月時点で、CodeMender単体の価格表は公式ドキュメントに載っていません。利用量はCloud Billingのレポートで確認する案内です。cm statsはv0.12.0から課金量と一致するトークン集計を出すので、試行期間に1PRあたりの消費を測ると見積もりの根拠になります。ビルド環境とレビュー工数も別に見込んでください。

SCAとは？ソフトウェア構成分析の仕組みとSAST・SBOMとの違い・導入判断を解説：依存ライブラリ側の守備範囲
SASTとは？DAST・SCAとの違いとCI/CDへの組み込み・導入判断を実装視点で解説：指摘を出す側の既存手段
SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説：構成把握の土台づくり
GitHub Copilot Autofixとは？対応言語・料金とエージェント型autofixのGA変更点：GitHub側の自動修正との比較
GitHub Code Scanningとは？CodeQLの設定手順・対応言語・料金とAI Scan：SARIFの受け皿
CVEとCWEの違いとは？脆弱性管理の基礎をCVSS・相互関係とあわせて解説：脆弱性クラスの語彙
Semgrepとは？使い方・ルールの書き方・料金と無料版の検出範囲：パターン検出側の既存手段

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

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

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