>
>
公開日
Googleが2026年7月22日、コードセキュリティエージェント「CodeMender」のスキャン・修復機能をプレビュー版として提供開始しました。脆弱性を見つけるだけでなく、本当に悪用できるかを自分で攻撃して確かめ、修正パッチまで生成するという点が従来のツールと大きく異なります。
ただし、現時点で全社導入を検討する段階のプロダクトではありません。それでも情シスがこのニュースを追うべき理由は、CodeMenderの登場が「脆弱性対応に許される時間が短くなった」という前提の変化を象徴しているからです。
この記事では、CodeMenderの仕組みと提供条件を一次情報ベースで整理したうえで、自社に開発部門がある企業／ない企業のそれぞれが取るべき実務アクションまで解説します。
CodeMenderとは？「見つける・確かめる・直す」を一気通貫で行うAIエージェント
CodeMenderは、Googleが提供するマネージド型のコードセキュリティエージェントです。脆弱性のスキャン、悪用可能性の検証、修正パッチの生成とテストまでを1つのエージェントが連続して実行する点が最大の特徴です。
従来のSAST（静的アプリケーションセキュリティテスト）やSCA（ソフトウェアコンポジション解析）は「検出」までを担い、その先の「これは本当に危険なのか」「どう直すのか」は人間の判断に委ねられていました。CodeMenderはこの後工程まで踏み込みます。
3つの工程：スキャン → 検証 → 修復
工程 | CodeMenderの動作 | 従来ツールとの違い |
|---|---|---|
スキャン | リポジトリやアプリケーション固有の文脈・目的・機能を理解したうえで、主要な脆弱性クラスを探索 | 静的なパターンマッチではなく、コードの意図を踏まえた探索 |
検証 | 顧客が管理する隔離サンドボックス内で、エージェント自身がPoC（概念実証）エクスプロイトを構築・実行し、実際に悪用可能かを確認 | 「検出＝アラート」で終わらず、実リスクかどうかを実証 |
修復 | 安全なパッチをdiff（差分）形式で自動生成し、既存機能を壊していないかをLLM-as-a-judgeで判定 | 修正案の提示にとどまらず、機能影響の確認までを自動化 |
検出対象として公式に挙げられているのは、メモリ破損、インジェクション、Webセキュリティ上の問題、暗号の欠陥、安全でないデータ処理などです。対応言語はC/C++、Go、Java、Python、Ruby、Rust、TypeScriptとされています。
「勝手にコミットする」わけではない
自動修復と聞くと、AIが人の目を通さずに本番コードを書き換える姿を想像しがちですが、CodeMenderはリポジトリへのコミット前に開発者による手動レビューと承認を必須としています。生成されたパッチは開発ツールにdiffとして届き、採否の判断権は常に開発者側に残る設計です。
また、自社のコーディング規約やスタイルをコンテキストとして与えることで、それに沿ったパッチを生成させることも想定されています。
DeepMindの研究から製品へ：6か月で72件という前史
CodeMenderは2025年10月にGoogle DeepMindが研究プロジェクトとして発表したものが原型です。発表時点では、開発開始から約6か月で72件のセキュリティ修正に貢献し、最大450万行規模のプロジェクトも対象としていたと報告されています。画像処理ライブラリ「libwebp」のメモリ管理を強化した事例なども公開されました。
当時は一般提供されておらず「いずれすべての開発者が使える形にしたい」という段階でしたが、そこから約9か月を経て、エンタープライズ向けのマネージドサービスとしてプレビュー提供に至ったという流れです。
なお、研究段階で「反応型（reactive）」と「先制型（proactive）」の2モードが紹介されていた点も押さえておくと、今後の機能拡張の方向性を読み解きやすくなります。先制型は、まだ問題が顕在化していない危険な実装パターンを安全な書き方へ置き換える動作を指します。
なぜ今このプロダクトが出てきたのか｜脆弱性対応の「時間切れ」問題
CodeMenderが解こうとしている課題は、シンプルに言えば「脆弱性が見つかってから悪用されるまでの時間が、人間の対応速度を下回った」ことです。Googleの脅威インテリジェンス部門（Mandiant）は、この時間がかつての数週間から、現在は数時間〜数日に短縮されていると報告しています。
攻撃側にもAIがある、という非対称性
背景にあるのは、攻撃側がすでにAIを実戦投入しているという事実です。フロンティアモデルは脆弱性の発見と攻撃コードの生成に高い能力を示しており、熟練技術者でも困難だった欠陥を短期間で大量に発見できるとされています。
この文脈は、情シス視点でも複数の切り口ですでに顕在化しています。
攻撃能力そのものを扱うモデルの登場（GPT-Redとは？OpenAIの攻撃専用AIが示すプロンプトインジェクション対策と情シスの実務ポイント）
高い脆弱性発見能力を持つモデルへのアクセス制限（Claude Mythosとは？情シスが押さえるべきポイント）
セキュリティ特化モデルの相次ぐ投入（Fugu-Cyberとは？性能・料金・情シスが導入前に確認すべきポイント）
「AIによる攻撃にAIで対抗する」という構図は、マーケティング上のレトリックではなく、単純な処理速度の問題として成立してしまっているのが現状です。
AIが書いたコードが増えれば、レビューすべき量も増える
もう一つの構造的な要因が、AIコーディングの普及です。生成量が増えれば、当然ながら検証すべきコードの総量も増えます。人手のレビューだけでは追いつかない領域が広がる以上、検証側にも自動化を入れざるを得ないという流れになります。
AIエージェントに開発作業を任せる際のガバナンス設計については、Vibe Codingとエージェント開発のガバナンス設計やClaude Codeの企業導入ガバナンスガイドも併せて参考にしてください。
日本の規制も「1ヶ月」という速度を求め始めた
この動きは海外の話ではありません。日本でも2026年5月18日、内閣官房 国家サイバー統括室をはじめとする計14の府省庁・機関の連名で、AI性能の高度化を踏まえた政府横断パッケージ「Project YATA-Shield」が公表されました。
このパッケージは、重要インフラ事業者・政府機関・ソフトウェアベンダのそれぞれに向けて、より高速かつ大量に脆弱性が発見・修正されることを前提とした対策強化を求めるものです。ソフトウェアベンダに対しては、高性能AIも活用しながらリリース前の脆弱性低減とリリース後のパッチ早期提供を実施するよう促しています。
その4日後の5月22日には、金融庁と日本銀行が金融機関等に対して短期的対応を要請しました。資産管理・脆弱性管理・パッチ適用・監視対応の体制を至急点検するという内容で、9項目について「概ね1ヶ月程度を目途」に対応を進めることが期待されると明記されています。この要請はあくまで応急的措置と位置付けられており、中長期的には脆弱性対応の自動化へ移行する方針も示されました。
金融分野が先行しているものの、Project YATA-Shieldは重要インフラ15分野を横断するフレームワークです。自社が直接の対象でなくとも、取引先や利用しているSaaSベンダーがこの要請を受ける側になる可能性は十分にあります。組織向けの脅威動向はIPA「情報セキュリティ10大脅威 2026」組織編の読み解きでも整理しています。
CodeMenderの提供形態・利用条件｜今すぐ全社導入できるものではない
2026年7月時点のCodeMenderは、誰でも申し込めば使えるプロダクトではありません。プレビュー段階であり、一部の政府機関および特定の組織・企業向けの提供にとどまっています。この前提を押さえずに社内で「Googleが自動修復AIを出した」と共有すると、期待値がずれた議論になりやすい点に注意が必要です。
提供経路は2つ
提供経路 | 概要 | 位置づけ |
|---|---|---|
Gemini Enterprise Agent Platform | 一般提供中のGeminiモデルを利用してCodeMenderを実行 | 開発チームがコードスキャン・修復を単体で使うルート |
Google AI Threat Defense | Wiz・Mandiant・Google Security Operationsと統合された自律型セキュリティ基盤のコアコンポーネント | セキュリティ運用全体の中に組み込むルート |
AI Threat Defenseは2026年5月にRSAC 2026で発表された統合プラットフォームで、Wizが検出結果に実環境の文脈を付与して優先順位を決め、CodeMenderが修復を担うという役割分担です。なお、Wiz側からCodeMenderを呼び出してコードをスキャンする機能は、公式ブログ上「近日提供予定」とされています。
実行環境と開発フローへの組み込み方
既存のCI/CDワークフローへの統合
軽量なCLIクライアントによるローカル開発環境での直接実行
VS Code や Antigravity といった開発者ツールとの連携
ユーザーが管理するサンドボックス内でのスキャン・分析
ファーストパーティのコードだけでなく、オープンソースやサードパーティ製ソフトウェアの分析も対象に含まれます。
データの取り扱い：ソースコードのゼロリテンションを明記
情シスが最も気にする論点はここでしょう。公式には以下のガードレールが示されています。
VPC経由の安全なトラフィックルーティング
データの分離と暗号化
ソースコードデータを保持しないゼロリテンションポリシー
「自社のソースコードを外部AIに読ませてよいのか」という社内稟議は必ず発生します。ゼロリテンションが明記されている点は、その議論の出発点として重要です。ただし契約条件やリージョン、監査ログの取得可否は個別確認が必要になるため、公式ドキュメントと契約書の双方で裏を取ることをおすすめします。
AIサービス全般のデータ取り扱いを社内で評価する枠組みについては、AIガバナンスの実践ガイドも参考になります。
モデルの選択肢と料金の考え方
CodeMenderはマルチモデル構成を取っており、コスト・速度・ディープスキャン性能に応じて適切なモデルを選択する設計です。2026年後半にはサードパーティのフロンティアモデルの選択肢も追加される予定とされています。また、Gemini 3.5 Flash Cyberを搭載した構成は、一部政府機関や特定組織向けに限定提供されています。
Geminiモデルの世代動向は「Gemini 3.6 Flash」など3モデル発表｜情シス向け 性能・料金・導入判断ガイドで整理しています。
料金について、CodeMender単体の価格は現時点で公表されていません。基盤となるGemini Enterprise Agent Platformが従量課金制である点を踏まえると、スキャン対象のコード量・実行頻度・選択モデルによってコストが変動する構造になると考えられます。PoC段階で「1リポジトリあたり月いくらか」を実測する設計にしておくと、予算化の際に困りません。
情シスはCodeMenderをどう捉えるべきか｜立場別の3つの観点
CodeMenderへの向き合い方は、自社に開発部門があるかどうかで大きく変わります。「うちは自社開発していないから関係ない」と判断するのは早計で、むしろ開発部門を持たない企業ほど、別の形で影響を受けます。
観点1：自社開発コードがある企業 — DevSecOpsへの投資判断として見る
自社プロダクトやWebサービスを開発している場合、CodeMenderは既存のSAST/DAST/SCAの置き換え候補ではなく、「検証と修復」という手薄な工程を埋める補完レイヤーとして評価するのが実態に近い捉え方です。
検討すべき論点は次のとおりです。
既存ツールが出しているアラートのうち、実際に悪用可能なものはどれくらいか（誤検知率の現状把握）
修正パッチ作成にかかっている工数は月何時間か
レビュー体制はAI生成パッチの流量に耐えられるか
3点目は見落とされがちですが重要です。パッチ生成が自動化されても、レビューが人間である以上、そこが新たなボトルネックになります。生成量が増えた分だけレビュー負荷が増える構造になっていないか、事前に設計しておく必要があります。
観点2：自社開発コードがない企業 — 「問う側」に回る
開発部門を持たない企業の情シスにとって、CodeMenderは自社が使うツールではなく、ベンダーが使っているかどうかを確認する対象になります。
Project YATA-Shieldがソフトウェアベンダに求めているのは、まさにこの領域です。つまり、自社が利用しているSaaSやパッケージソフトの提供元が、AIを活用した脆弱性の早期発見・修正体制を整えているかどうか。これは今後、ベンダー評価の実質的な項目になっていきます。
サプライチェーン全体のリスクについてはサプライチェーン攻撃とは？手口と対策、部品表による可視化についてはSBOMとは？メリットや注意点をわかりやすく解説で解説しています。
観点3：防御の前提が変わったことを社内に伝える
3つ目は組織的な観点です。「重大な脆弱性が公表されてから1週間以内にパッチを当てる」という従来の運用基準が、そもそも成立しなくなりつつあります。
経営層や事業部門に対して、対応の優先度と体制を見直す必要があることを説明する材料として、Googleのようなプラットフォーマーが自動修復に投資している事実、そして日本政府が「概ね1ヶ月」という期限を明示した事実は、いずれも説得力のある根拠になります。インシデント発生時の初動についてはインシデント対応とは？発生時の流れと備えも併せてご確認ください。
開発部門がない情シスこそ効く、3つの実務アクション
CodeMenderを使えない立場でも、今日から着手できる備えがあります。ポイントは「脆弱性の一報が出たときに、自社がどれだけ速く動けるか」を上げておくことです。
アクション1：IT資産・SaaS台帳の精度を「即答できる水準」まで上げる
脆弱性情報が公表されたとき、最初に問われるのは「うちは影響を受けるのか」です。この問いに数時間で答えられるかどうかが、対応速度を決定づけます。
必要なのは以下の状態です。
全社で利用しているSaaSが漏れなく一覧化されている
各SaaSの利用部門・利用者・管理者アカウントが特定できる
端末のOS・アプリケーションのバージョンが把握できている
情シスの管理外で導入されたサービス（シャドーIT）が検知できている
台帳が表計算ソフトで分散管理されていると、この照合に数日かかります。棚卸しの進め方はSaaS棚卸しの手順と進め方、管理外サービスのリスクはシャドーITのリスクと対策で詳しく解説しています。
AdminaではSaaS利用状況の可視化、デバイス管理、シャドーAIの検知を1つの画面に集約し、「誰が・何を・どのバージョンで使っているか」を常時最新の状態に保てるよう支援しています。
アクション2：ベンダーへの確認項目をテンプレート化する
新規SaaS導入時やセキュリティチェックシートの更新時に、以下の観点を追加しておくと、AI時代のベンダー評価として機能します。
確認カテゴリ | 具体的な質問例 |
|---|---|
脆弱性発見体制 | 静的解析・動的解析に加え、AIを活用した脆弱性検出を実施しているか |
修正提供のスピード | 重大な脆弱性を認知してからパッチ提供までの目標時間（SLA）は定義されているか |
顧客への通知 | 脆弱性情報とパッチ適用状況を、顧客側にどのような手段・タイミングで通知するか |
部品構成の開示 | SBOMの提供、または利用OSSコンポーネントの開示に応じられるか |
AI利用の透明性 | 開発・運用プロセスでのAI利用範囲と、AI生成コードのレビュー体制を説明できるか |
第三者評価 | SOC 2、ISMS、SCS評価制度などの外部評価を取得しているか |
サプライチェーンセキュリティの評価制度への対応は、SCS評価制度への対応でも整理しています。また、導入検討中のSaaSのセキュリティ情報を調べる際は、無料公開しているクラウドサービスセキュリティチェックDBもご活用ください。
アクション3：一報から社内周知までの導線を先に決めておく
技術的な対応以前に、情報伝達の経路が詰まって遅れるケースは少なくありません。次の3点を事前に決めておくだけで、初動は大きく変わります。
一次情報の受信経路 — JPCERT/CC、IPA、各ベンダーのセキュリティアドバイザリをどのチャネルで受け取り、誰が最初に見るか
影響判定の担当と基準 — 誰が台帳と照合し、どの基準で「対応要／不要」を判断するか
社内周知のテンプレート — 従業員向け・経営層向けの文面をあらかじめ用意し、埋めるだけで発信できる状態にしておく
セキュリティフレームワークに沿って全体を体系化したい場合は、NIST CSFとは？6つの機能と活用方法やゼロトラストセキュリティの基本が参考になります。
導入・PoC時に確認すべき評価項目
将来的にCodeMenderが一般提供された際、あるいは同種のツールを比較検討する際に、共通して見るべき項目を整理しておきます。カタログスペックではなく、自社環境で測るべき指標という観点でまとめました。
評価カテゴリ | 確認ポイント | 判断の目安 |
|---|---|---|
検出精度 | 既知の脆弱性を含むテストリポジトリで、どれだけ検出できるか | 既存ツールとの差分で評価する |
誤検知の削減 | PoC検証によってアラートがどれだけ絞り込まれるか | 「検証済み」ラベルの信頼度を実測 |
検証環境 | エクスプロイト実行がどこで行われるか（自社管理サンドボックスか） | 自社ネットワーク・データへの影響範囲を確認 |
パッチ品質 | 生成されたdiffがそのまま採用できる割合 | レビュー工数がむしろ増えていないか |
機能影響 | 既存テストがパッチ適用後も通るか | CI/CDでの自動検証を必須にする |
データ取り扱い | ソースコードの保持有無、リージョン、監査ログ | 契約書・DPAで文書化されているか |
既存ツールとの重複 | 現行のSAST/SCA/DASTとの守備範囲の重なり | 統廃合によるコスト削減余地を試算 |
コスト構造 | 従量課金の変動要因（コード量・実行頻度・モデル選択） | 月次上限とアラート設定が可能か |
権限設計 | リポジトリへのアクセス権限をどこまで付与する必要があるか | 最小権限で運用できるか |
特に「パッチ品質」と「既存ツールとの重複」は、PoCで必ず数値化しておきたい項目です。自動化ツールを追加したのにレビュー工数が増えた、というのは実際に起こりうる結果です。
SaaSの契約とコストの全体最適についてはSaaS管理の完全ガイドでも扱っています。
他のセキュリティAIとの役割整理
セキュリティ領域のAIは短期間で乱立しており、それぞれ守備範囲が異なります。混同すると比較検討が空回りするため、位置づけを整理しておきます。
ツール／モデル | 提供元 | 主な役割 | 情シスから見た関わり方 |
|---|---|---|---|
CodeMender | 自社コードの脆弱性スキャン・検証・パッチ生成 | 開発部門がある企業は導入検討、ない企業はベンダー評価の観点として | |
Anthropic | 開発フローに組み込むセキュリティレビュー | 開発チームの日常的なコードレビュー強化 | |
Sakana AI | サイバーセキュリティ特化モデル | 国産モデルの選択肢として比較 | |
OpenAI | 自動レッドチーミング（攻撃側の検証） | 自社AIエージェントの堅牢性テスト | |
従来のSAST/DAST/SCA | 各社 | 静的・動的解析、依存関係の脆弱性検出 | 既存投資として継続。CodeMenderは置き換えでなく補完 |
Wiz（AI Threat Defense内） | クラウド環境の露出可視化と優先順位付け | インフラ側のリスク管理 |
汎用的なAIエージェントの比較はAIエージェント比較｜情シスが押さえる選定基準、エージェントの外部連携基盤についてはMCPの企業導入ガイドで解説しています。エンタープライズ向けモデルの全体像はClaude Fable 5の企業導入ガイドやGPT-5.6の企業導入ガイドも参考にしてください。
よくある質問（FAQ）
Q. CodeMenderは日本国内で利用できますか？
現時点でプレビュー提供の対象は一部の政府機関および特定の組織・企業に限定されており、日本国内での一般提供時期や日本語対応状況は公表されていません。Google Cloudの営業担当またはパートナー経由で、自社が対象となるかを確認する形になります。
Q. 料金はいくらですか？
CodeMender単体の料金は公表されていません。基盤となるGemini Enterprise Agent Platformが従量課金制であるため、スキャン対象のコード量・実行頻度・選択するモデルによってコストが変動する構造になると想定されます。
Q. AIが生成したパッチをそのまま本番に反映しても大丈夫ですか？
CodeMenderの設計上、リポジトリへのコミット前に開発者による手動レビューと承認が必須とされています。LLM-as-a-judgeによる機能影響の確認は行われますが、最終判断は人間に残される前提です。運用ルールとしても、AI生成パッチのレビュー基準を明文化しておくことをおすすめします。
Q. 自社にソースコードがなくても関係ありますか？
関係します。利用しているSaaSやパッケージソフトのベンダーが、AIを活用した脆弱性の早期発見・修正体制を整えているかどうかは、今後のベンダー評価項目になります。Project YATA-Shieldもソフトウェアベンダに対して同様の取り組みを求めています。
Q. 既存のSASTツールは不要になりますか？
現時点では置き換えではなく補完と捉えるのが妥当です。CodeMenderは「検証」と「修復」に強みを持つ一方、既存ツールが担ってきた継続的な静的解析や依存関係管理には別の役割があります。PoCで守備範囲の重なりを実測したうえで、統廃合を判断するのが安全です。
Q. ソースコードを外部に渡すことになりませんか？
公式にはVPC経由のトラフィックルーティング、データの分離と暗号化、ソースコードデータを保持しないゼロリテンションポリシーが示されています。ただし契約条件・リージョン・監査ログの取得可否は個別確認が必要なため、稟議前に公式ドキュメントと契約書の双方で裏を取ってください。
まとめ｜今すぐ使えなくても、備えは今日から始められる
CodeMenderは、脆弱性の検出から悪用可能性の検証、修正パッチの生成までを1つのエージェントが担う、コードセキュリティの新しい選択肢です。2026年7月22日にプレビュー提供が始まりましたが、対象はまだ限定的で、多くの情シスにとっては「動向を追う対象」の段階にあります。
一方で、このプロダクトが登場した背景 — 脆弱性の発見から悪用までが数時間〜数日に短縮され、日本政府も「概ね1ヶ月」という期限を明示し始めた状況 — は、すでにすべての企業に影響しています。
今日から着手できることは3つです。
IT資産・SaaS台帳の精度を上げ、「影響を受けるか」を即答できる状態にする
ベンダーへの確認項目にAI活用と修正提供SLAを追加する
脆弱性の一報から社内周知までの導線を先に決めておく
いずれも高価なツールを買わなくても着手できます。そして1つ目については、管理対象が可視化されていることが大前提になります。
「マネーフォワード Admina」は、SaaS・デバイス・アカウントを従業員軸で統合管理し、脆弱性情報が出た際に「どこに影響があるか」を即座に特定できる状態を支援します。セキュリティ対策機能や料金プランをご確認いただくか、お問い合わせよりお気軽にご相談ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
