「脆弱性が見つかったという連絡は来るのですが、直すかどうかの判断がこちらに投げられて、結局止まっています」——受託で作ったシステムを数年運用している会社から、この種の相談を受けることがあります。診断ツールの結果は月次で届く。ただし何十件も並んでいて、どれが本当に危ないのか、直すのに何日かかるのかが分からない。分からないから決裁が下りず、翌月も同じリストが届きます。
この詰まりの原因は、検出と修正のあいだが人手で埋まっていなかったことにあります。そこを機械で埋めにきた発表が、2026年7月末にありました。
CodeMender は「見つける」だけで終わらない
Google Cloud が公開した CodeMender は、コードの脆弱性を検出したうえで、サンドボックス内で実際に攻撃が成立するかを検証し、成立するものについて修正パッチを生成するAIエージェントです（Google Cloud、AIが自律的にコードの脆弱性検出からサンドボックス内でのリスク検証、修正までを自動実行 — Publickey）。2026年7月時点でプレビュー提供です。
従来の静的解析ツールとの違いは、この「検証」の工程にあります。静的解析は「危ないかもしれない書き方」を大量に挙げますが、実際にその経路に到達できるかまでは判断しません。だから結果リストが膨らみ、現場が読まなくなる。CodeMender は概念実証（PoC）の攻撃をサンドボックス内で試し、成立したものを優先度の高いものとして扱います。
対応言語は C、C++、Go、Java、Python、Rust、TypeScript とされ、メモリ破壊、インジェクション、暗号処理の弱さ、安全でないデータ取り扱いといった種類の欠陥を対象にしています。検証を通った脆弱性については、修正をコードの差分（diff）として開発者のワークフローに届けます。
Google はこれを、オープンソースの保守負担にも効くものとして位置づけています。少人数で維持されているライブラリが、数千のアプリケーションの土台になっている状況に対して、修正案を自動で供給する狙いです。
発注側にとって、何が変わるのか
「AIが直してくれるなら保守が安くなる」と読むと、判断を誤ります。変わるのは費用ではなく、詰まる場所です。
これまでの詰まりは「直し方が分からない」でした。これからの詰まりは「上がってきた修正案を、誰が承認するか」に移ります。修正案が自動で、しかも継続的に上がってくる状態は、承認する側の負荷を確実に増やします。
そして修正案の適用には、必ず副作用の可能性がついて回ります。脆弱性を塞ぐ変更が、既存の挙動を変えることは珍しくありません。セキュリティ的に正しい修正が、業務的に受け入れられないという状況は普通に起こります。
つまり発注側が答えを持っておくべき問いは、次の3つに集約されます。
- 上がってきた修正案を、誰が読んで、誰が適用を決めるのか
- 適用した結果で不具合が出たとき、その責任はどちら側か
- 適用を見送ると決めた脆弱性について、その判断の記録をどこに残すのか
3つめが抜けやすいところです。「今回は見送る」という判断は、後から必ず問われます。何を根拠に、いつ、誰が見送ったのか。記録がなければ、事故が起きたときに議論が始められません。
保守契約に書いておくべきこと
これらは技術の話ではなく、契約と運用ルールの話です。ツールの導入前に決めておけば揉めません。
適用の判断区分を分けておく。 すべての修正を同じ手順に乗せると、緊急のものが日常の承認フローに埋もれます。実務的には、「即時適用してよいもの」「事前承認が必要なもの」「適用しないもの」の3区分で足ります。区分の基準は、外部から到達可能かどうかと、業務挙動を変えるかどうかの2軸で引けます。
検証環境での確認を誰がやるかを決めておく。 修正案がそのまま本番に入る運用は、たとえ機械が生成したものでも危険です。検証環境で流すのが受託側なのか発注側なのか、確認にかけられる時間はどれくらいかを、あらかじめ握っておきます。
対象範囲を明示する。 自社で書いたコードだけが対象なのか、依存しているライブラリまで含むのかで、作業量は大きく変わります。依存パッケージ側の脆弱性は、修正パッチを当てる先が自社のコードではありません。 上流に修正が来るのを待つのか、バージョンを上げるのか、代替に置き換えるのかという別の判断になります。
依存関係の更新運用そのものについてはDependabotが既定で3日待つ — 依存更新の運用を組み直すに、サプライチェーン側のリスクの整理は2026年サプライチェーン攻撃まとめにまとめています。放置された脆弱性が実際にどう刺さるかはReact2Shellから半年、CVSS 10.0がいまも放置サイトで生きているが具体例になります。
AIが生成した修正を、そのまま信じてよいか
この問いには、はっきり「いいえ」と答えるべきです。ただし理由は、「AIだから信用できない」ではありません。
CodeMender のように攻撃の成立をサンドボックスで検証する仕組みは、「本当に危ないか」の判定精度を上げます。ここは人間の目視より安定するはずです。問題はその先、修正が業務要件を壊していないかの判定にあります。
機械はコードから業務要件を読み取れません。「この入力値を弾く」という修正が正しいかどうかは、その入力が実際の業務で使われているかどうかで決まります。そして、それを知っているのは発注側の担当者だけです。AIが得意なのは脅威の判定、人間が担うのは業務影響の判定という分担になります。
だからこそ、保守契約に「修正案の適用可否を判断する自社側の担当者」を1人置く必要があります。技術的な詳細を読む必要はありません。「この機能のこの入力は、実際にこう使っている」と答えられる人であれば足ります。
AIが書いたコードのレビュー体制をどう作るかという話はAIが書いたコードのセキュリティは誰が見るのかにも整理してあります。
次に確認すること
いま運用しているシステムについて、直近1年で「脆弱性が見つかったが対応を見送った」ものがあるか、保守の担当者に聞いてみてください。あるなら、その判断がどこに記録されているかも一緒に確認する。
記録が残っていないなら、そこが最初に手を付ける場所です。ツールを新しくする前に、判断を残す場所と、判断する人を決める。検出と修正の自動化は、その土台の上でしか効きません。
システムの保守体制やセキュリティ対応の設計についてのご相談は、グリームハブの開発・AI・自動化のご相談窓口で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Google Cloud、AIが自律的にコードの脆弱性検出からサンドボックス内でのリスク検証、修正までを自動実行。「CodeMender」プレビュー公開 — Publickey（2026年7月28日）
- Now in preview: Find and fix software vulnerabilities with CodeMender — Google Cloud Blog
- CodeMender: AI Agent for Code Security — Google Cloud
- Google gives developers an AI bug hunter that also writes patches — Help Net Security（2026年7月24日）
