>
>
公開日
最終更新日
CodeMenderは、脆弱性の検出・悪用可能性の検証・修復から予防的なコード書き換えまで自律実行するGoogleのAIエージェントです。Google CloudのCodeMenderの製品案内では、コードを調べるだけでなく、攻撃の再現と修復まで担う仕組みを示しています。
IPAの公表資料によると、GoogleはCodeMenderを2026年7月21日に公開しました。2026年10月時点でも、情シスが最初に判断するのは全社導入の可否ではなく、自社が評価できる対象か、ソースコードを扱う条件を満たせるかです。料金とCLIの仕様を押さえたうえで、自社開発がある企業は限定的なPoCへ、開発部門がない企業はベンダーへの質問と資産台帳の整備へ進みます。
この記事で確認したこと（確認日: 2026年10月30日）：Google CloudのCodeMender製品ページ、CodeMenderのドキュメント、Gemini Enterprise Agent Platformの料金表、IPAのAIセキュリティ動向資料をもとに、機能、提供条件、評価時の判断材料を整理します。
CodeMenderとは？脆弱性の発見・検証・修復を担うAIエージェント
Google CodeMenderは、コードの脆弱性を探し、悪用可能性を実証し、修正パッチを生成する自律型AIセキュリティエージェントです。従来のセキュリティツールでは、検出、再現確認、修正案の作成を別々に進めることが多く、担当者の時間と手作業を要しました。同製品は、対象コードの動作を隔離環境で確かめながら、探索から修復までを通貫して扱うプロダクトとして位置付けられています。
本記事のポイント
アラートの生成に加えて、攻撃の再現とコード修復まで実行します。
推論はクラウドで動き、コンパイルや攻撃の再現は顧客管理下の隔離環境で実行します。
2026年10月時点のプレビューはテスト・評価目的に限定され、商用・本番目的では使えません。
情シスは、自社開発があればPoCで精度と総工数を測り、なければ利用ベンダーの修正・通知体制を評価します。
検出で終わらない自律実行の範囲
このエージェントは、発見した問題が実際に攻撃に使えるかを調べ、その結果を修正へつなげます。Google Cloudの脆弱性の発見・検証・修復に関する製品説明では、顧客管理下の環境でPoCエクスプロイトを自律的に構築・実行する機能を挙げています。PoCは、問題を悪用できることを示す概念実証です。
情シスが見るべき差は、検出件数ではなく、担当者へ渡される証拠と修正候補の具体性です。「危険な可能性がある」という通知と、再現条件・実行結果・差分パッチがそろった報告では、その後の調査手順が変わります。ただし、検証に失敗した問題を安全と判定してはいけません。実行環境や依存関係の不足で再現できなかった可能性を、未解決事項として残します。
3つの工程と基本コマンドの対応
CLIでは、探索・検証・修復をそれぞれcm find、cm verify、cm fixで扱います。GoogleのCodeMenderのCLI実習では、これらのコマンド全体でデフォルトの推論エンジンにgemini-3.8-flashを使用しています。
工程 | 基本コマンド | 情シスが評価記録に残す内容 |
|---|---|---|
スキャン |
| 対象リビジョン、探索条件、検出箇所、想定する脆弱性 |
検証 |
| 再現手順、実行環境、悪用の成否、未検証の理由 |
修復 |
| 差分パッチ、テスト結果、残存リスク、レビュー判定 |
Googleのスキャンモードのドキュメントでは、cm findに3つのスキャンモードを用意しています。PoCではモードを記録し、同じ対象・同じ条件で結果を比較します。異なる探索条件の検出件数を、そのまま精度の優劣に読み替えない運用にします。
対応言語と探索対象の範囲
Googleの現行ドキュメントは、C/C++、C# / .NET、Go、Java、JavaScript、TypeScript、Kotlin、Python、Ruby、Rust、PHPをデフォルトの対応言語として挙げています。対象の一覧はCodeMenderの対応言語で確認できます。
Google Cloudが挙げる探索対象には、メモリ破損、インジェクション、Webセキュリティ、暗号の欠陥があります。自社の言語が一覧にあっても、ビルドやテストを再現できなければ修復の評価は進みません。情シスは開発部門と、依存パッケージ、テストデータ、実行に必要な外部接続を洗い出し、隔離環境で動かせるリポジトリから対象を選びます。
発見済みの問題への対応と予防的な書き換え
見つかった脆弱性への対応と、危険な実装を先回りして置き換える予防的な対応の両方を扱います。IPAは2025年12月の資料で、OpenAIのAardvarkによる脅威モデル構築からパッチ検証までの自律化と、DeepMindのCodeMenderによる予防的なコード書き換えを取り上げています。
評価では、この2つを別の課題として扱います。既知の脆弱性を直す検証では再現の解消を測り、予防的な変更では仕様への影響と変更範囲を調べます。書き換え量が大きいほど良いと判断せず、開発部門が変更の目的を説明できるかまで記録します。
▶ 関連記事: 【2026】生成AI・AIエージェントのセキュリティ運用ベストプラクティス
▲ CodeMenderが脆弱性の発見から検証・修復までを自律的に進める3つの工程。
脆弱性対応の自動化を進める背景と国内企業の動向
自動化の検討では、AIの能力向上そのものより、発見から修正までのどこに人手が滞留しているかを先に把握します。脆弱性対応の前史をたどると、検出技術の進化に対して、影響判定、修正、レビュー、適用の速度が追いつかない非対称性が課題になってきました。このエージェントの評価でも、ツールの導入自体にコミットするのではなく、どの工程を自動化し、どの判断を人間に残すかを切り分けます。
Google DeepMindの修正実績と人間のレビュー
Google DeepMindは、同製品の開発開始から6か月間に、最大450万行のコードを含むOSSプロジェクトへ72件のセキュリティ修正パッチを適用したと公表しています。2025年のCodeMenderの研究発表では、すべてのパッチをアップストリームへ送る前に、人間のセキュリティ研究者がレビューしたことも明記しています。
同発表では、画像処理ライブラリ「libwebp」のメモリ管理を強化する事例も紹介しています。情シスがこの実績から読み取れるのは、大規模なコードにも修正を試みられることと、公開前の人間の判断を残していたことです。72件という結果を、自社でも同じ件数を処理できる保証や、レビューを省ける根拠には使いません。
Chromeでの脆弱性発見事例と提供先限定の経緯
Googleは、Chromeに13年以上残っていたサンドボックスエスケープをGeminiベースのエージェントで発見したと公表しています。これはCodeMenderそのものの導入実績ではなく、同系統の技術が持つ検証能力の例です。CodeMenderは2026年7月21日の公開時に、悪用防止のため提供先を信頼できる組織に限定しました。
これらはIPAのAIセキュリティ動向資料に基づく情報です。防御に役立つ検証能力は攻撃にも転用できるため、情シス側も実行権限と対象範囲を制限して扱います。
GMOインターネットグループの2026年の取り組み
GMOインターネットグループは、発表の中で、2026年9月24日にGoogle Cloudとの「AI推進プロジェクト」の開始を決定し、CodeMender、Wiz、Mandiantを活用したAgentic Defenceの構築を推進すると述べています。同社のAI推進プロジェクトの発表は、国内企業がコード修復をセキュリティ運用全体へ組み込もうとする具体例です。
整理項目 | 発表内容 |
|---|---|
業種・対象範囲 | インターネット関連事業を展開するGMOインターネットグループのAI推進プロジェクト |
開始決定の時期 | 2026年9月24日 |
課題と施策 | AI主導の防御を構築するため、CodeMender、Wiz、Mandiantを活用 |
成果の扱い | 発表段階の取り組みとして扱い、工数削減率や修復件数の達成実績とは区別 |
自社の稟議では、同社の取り組みを採用効果の証明にせず、運用設計の参考にします。コードの欠陥、クラウド環境での露出、脅威情報を別々に管理しているなら、どの情報を修正担当者へ渡すかを先に決めます。
自社の対応時間を測るための分解
情シスは、脆弱性情報の受信、影響判定、修正依頼、検証、承認、適用の各時刻を記録すると、自動化する工程を絞れます。パッチ作成が速くなっても、資産の照合や承認待ちが長ければ、適用までの時間は縮まりません。
次回の対応から、チケットに各工程の開始・終了欄を追加します。担当部門がまたがる場合は引き渡し時刻も残し、作業時間と待ち時間を分けます。経営層へは「AIを導入したか」ではなく、「どの待ち時間を減らし、その結果をどう測るか」を説明します。
▶ 関連記事: Claude Mythosとは？セキュリティ機能と情シスの活用法
限定プレビューの利用条件とクラウド・隔離環境の役割
2026年10月時点の同製品は、全社の本番運用へ直接投入するのではなく、利用資格と評価目的の条件を満たした範囲で検証する製品です。提供条件、データの扱い、実行権限に関する規制や社内規程との整合を、評価開始前に整理します。
提供対象と契約上の利用範囲
Google Cloudは同製品をプレビューとして案内し、Gemini Enterprise Agent Platformを通じた利用と、Google AI Threat Defenseのコアコンポーネントという位置づけを示しています。また、2026年7月の提供開始時点では、Gemini 3.5 Flash Cyberを搭載する構成を一部の政府機関や特定の組織・企業向けとしていました。現行のドキュメントでは、Gemini 3.8 Flash CyberとGemini 4 Argon Cyber PermissiveをFairwind Programでアクセスできる顧客向けとしています。これらの区別はGoogle CloudのCodeMender提供案内に基づきます。
さらに、GoogleのCodeMenderの利用条件は、限定的なテスト・評価目的のみを認め、商用または本番目的での使用を許可していません。料金表に単価が載っていても、本番利用の権利まで得られるわけではありません。
稟議の前に、Google Cloudの担当窓口と利用条件を確認します。対象資格と許可される評価範囲がそろえば検証環境の準備へ進み、そろわなければ自社コードを投入せず、同種のツールを評価できるテスト資産と判定基準を整えます。日本国内での利用可否、対象組織、契約条件の判断は、このブロックへ集約して管理します。
クラウド推論と顧客管理環境の分担
Google CloudのCodeMenderのアーキテクチャ説明では、中核となる推論とオーケストレーションはクラウドで動き、コンパイル、テスト、エクスプロイトのシミュレーションは顧客管理下のローカルサンドボックスまたは分離されたVMで実行します。CLIをローカルで動かしても、推論まで端末内で完結する構成ではありません。
この分担に合わせて、情シスは2種類の通信を整理します。一方はクラウドの推論基盤へ送る情報、もう一方は検証環境からビルドやテストのために必要となる通信です。後者に本番の認証情報や本番データが混ざらないよう、検証専用の接続先と資格情報を使います。攻撃を再現する環境では、社内ネットワークへの到達経路も設計対象に含めます。
データ保護を判断するための文書
評価時は、コード、プロンプト、実行ログ、生成パッチを別々の情報資産として管理します。ソースコードの保持条件だけを見て承認せず、どの情報がどこへ送られ、どこに保存され、誰が削除するかを対応表にします。
対象情報 | 契約・設計で確定する事項 | 判断への反映 |
|---|---|---|
ソースコードと入力 | 送信範囲、保持、学習利用、処理地域 | 社内の持ち出し基準に合うコードだけを評価対象にする |
実行ログとセッション | 保存場所、閲覧者、保存期間、削除担当 | 保存先を管理できる端末・VMへ実行環境を限定する |
認証情報 | 発行者、有効期間、権限、失効手順 | 評価専用に発行し、終了時に失効させる |
成果物とパッチ | 保管先、レビュー担当、利用できる範囲 | 評価用のブランチと本番の変更経路を分離する |
法務・セキュリティ部門が条件を文書で判断できれば、許可された評価へ進みます。条件を確定できない場合は機密コードの投入を止め、公開コードや社内で利用を承認した教材へ対象を切り替えます。AIサービス全般の審査項目はAIガバナンスの実践ガイドと合わせて整理できます。
既存の開発環境との接続範囲
VS CodeやAntigravityを使う環境でも、評価の初期段階ではCLIの出力とパッチを既存のレビュー手順へ渡す構成に絞ります。開発ツールから呼び出せるかより、誰が何を承認し、どの記録を残すかを先に決めます。
CI/CDへの組み込みを検討する場合は、評価専用のジョブを本番のデプロイ経路から切り離します。許可された範囲で結果を蓄積し、処理が失敗したときは既存の解析と手動対応へ戻します。AIエージェントへの権限付与はVibe Codingとエージェント開発のガバナンス設計、開発環境の統制はClaude Codeの企業導入ガバナンスガイドで補足しています。
▶ 関連記事: Fugu-Cyberとは？性能・料金・情シスが導入前に確認すべきポイント
▲ クラウド推論基盤と顧客管理下の隔離環境におけるCodeMenderの処理分担。
CodeMender CLIの基本操作とセッション管理
CodeMender CLIの評価では、コマンドの実行結果を対象コード・モデル・セッションと結び付け、後から同じ条件を追えるようにします。
find・verify・fixの実行記録
GoogleのCLI実習の基本コマンドでは、ローカルリポジトリに対してcm find、cm verify、cm fixを使います。コマンド名だけで手順を固定せず、導入したCLIのバージョンに対応する引数や前提条件をそろえて評価します。
実行前：対象リポジトリのリビジョン、CLIのバージョン、モデル、ビルド手順、テストコマンドを記録します。
探索後：検出箇所と根拠を保存し、既知の問題、新しい候補、対象外を担当者が分類します。
検証後：悪用の成立・不成立・実行不能を分け、使用した環境と再現手順を残します。
修復後：差分とテスト結果をレビュー担当へ渡し、採用・修正後採用・不採用と理由を記録します。
同じリポジトリでも、依存パッケージやビルド設定を変えると結果が変わる可能性があります。情シスは評価中の環境変更をチケットへ追記し、変更前後の結果を一つの集計へ無条件に混ぜません。
3つのスキャンモードの比較条件
cm findのモードは、探索結果を比較するときの条件として管理します。Googleの3つのスキャンモードに関する案内に沿って選び、対象範囲と実行条件を評価票へ残します。
探索を広げた実行と、限られた対象を調べた実行では、件数や時間をそのまま比較できません。既存ツールとの差を調べるなら、まず対象リビジョンと既知の脆弱性の一覧を固定します。次にモードごとの検出結果、検証に進んだ割合、消費トークンを分けて記録します。探索の深さを変えた効果と、モデルを変えた効果も別々に測ります。
state.dbによるステートフルセッション管理
Googleのセッション管理ドキュメントでは、スキャン、検証、修復の各試行をステートフルセッションとして追跡し、ローカルのSQLiteデータベースstate.dbへ保存します。情シスはクラウド側の契約と別に、このローカル保存物の管理責任を割り当てます。
共有端末や使い捨てVMを使う場合は、担当者の退職・異動やVMの破棄で評価履歴を失わない保管方法を決めます。一方、データベースを無差別に共有すると、対象コードに関する情報へのアクセス範囲が広がります。評価担当者だけが読める保存先を用意し、報告書に必要な結果と実行環境の作業データを分けます。
停止・再実行・引き継ぎの手順
長時間実行や途中失敗に備え、停止判断の担当者と再実行の条件を事前に決めます。単にプロセスを再起動するのではなく、直前の結果を確認し、同じ対象に対する重複実行を避けます。
引き継ぎ票には、対象リビジョン、セッションの識別情報、完了した工程、失敗した工程、次に実行する作業を残します。検証不能の原因が外部接続ならネットワーク担当へ、テスト不足なら開発部門へ渡します。エージェント連携の構成まで広げる場合は、MCPの企業導入ガイドで接続先と権限の整理方法を確認し、CLI単体の評価とは別の変更として管理します。
CodeMenderの料金とPoC予算の組み立て
利用料金は、対象モデルの入力・出力トークン単価で計算し、検証環境と人間のレビューにかかる費用を別に集計します。
お試し価格の単価と適用期間
Google CloudのGemini Enterprise Agent Platformの料金表では、CodeMenderでGemini 3.8 Flash、Gemini 3.7 Flash、Gemini 3.6 Flashを使用する場合のトークン単価を公表しています。2026年12月31日までは100万トークンあたり入力0.75ドル・出力3.75ドルのお試し価格で、2027年1月1日からは入力1.5ドル・出力7.5ドルの標準料金です。Gemini 3.6 Flashは非推奨となり、2026年11月19日に提供終了予定です。
お試し価格は、Gemini 3.8 Flash Cyber、Gemini 3.5 Flash、Gemini 3.1 Proなど対象外のモデルへ当てはめないようにします。料金表に載らない構成や個別契約の料金は、Google Cloudへの問い合わせで確定させます。モデルの世代動向を社内で整理する場合は、「Gemini 3.6 Flash」など3モデル発表｜情シス向け 性能・料金・導入判断ガイドを参照し、CodeMenderで使う構成の見積もりとは分けます。
実測値から予算へ変換する計算方法
モデル利用料は、実測した入力トークンと出力トークンへ、それぞれ該当する単価を掛けて合算します。コードの行数だけから金額を推定せず、同じ対象でも再探索・検証・修復の反復によって消費が増える前提で測ります。
モデル利用料＝入力トークン数÷100万×入力単価＋出力トークン数÷100万×出力単価
情シスは、リポジトリ単位に加えて、スキャン、検証、修復の工程ごとに費用を分けます。失敗や再実行に使った分も含め、採用できたパッチに至るまでの消費量を残します。年度をまたぐ予算では、お試し価格で測ったトークン数に切り替え後の単価を掛け直し、価格差と利用量の増加を混同しないようにします。
モデル料金以外の費用と継続判断
PoCの総費用には、検証用VM、環境構築、ログ保管、担当者の調査、コードレビューを含めます。人手の費用を金額へ換算する場合は、自社の原価基準を使い、根拠のない時間単価を置きません。
既存の対応工数を取得できるなら、同じ対象で手動対応と比較します。取得できない場合は最初の評価で基準値を作り、削減効果を先に宣言しません。契約費だけを集めず、利用頻度と担当者の作業までまとめる方法はSaaS管理の完全ガイドでも整理しています。
▶ 関連記事: 【2026年8月最新】Claude Code 企業利用の統制ガイド｜APIキー管理・MCP連携・シャドーAI対策
SAST・SCAやWizとの役割分担
このエージェントは、既存の検出・依存関係管理を一括で置き換えるのではなく、悪用可能性の検証とコード修復を追加する位置づけで評価します。
既存ツールとの比較軸
情シスは、製品名ではなく、何を入力し、どの判断材料を出力するかで役割を比較します。SASTは静的解析、DASTは実行中のアプリケーションへの動的な検査、SCAは依存コンポーネントの分析を担います。製品ごとに修復支援などの機能差があるため、「従来ツールはすべて検出だけ」とは扱いません。
手法・エージェント | 主な対象 | 担当させる作業 | 評価に残す成果物 |
|---|---|---|---|
SAST | ソースコード | 静的解析による問題候補の検出 | 検出箇所、ルール、追跡記録 |
DAST | 実行中のアプリケーション | 外部からの動的な挙動検査 | リクエスト、応答、再現条件 |
SCA | 依存コンポーネント | 構成と既知の脆弱性の照合 | 依存関係、影響するバージョン |
CodeMender | 対象コードと顧客管理下の実行環境 | 探索、PoC検証、修正パッチ生成 | 検証の証拠、差分、テスト結果 |
Aardvark | ソフトウェアの脆弱性対応工程 | 脅威モデル構築からパッチ検証までの自律化 | 自社の評価では各工程の証拠を取得して比較 |
IPAは自律型の脆弱性対応に関する資料でAardvarkとCodeMenderを取り上げています。両者の比較でも、検出件数だけで決めず、許可される利用条件、再現の証拠、人間へ引き渡す成果物をそろえて評価します。
Google AI Threat Defense内の分担
Google AI Threat Defenseでは、コード修復とセキュリティ運用を別の役割として接続します。IPAのGoogle AI Threat Defenseに関する公表資料は、Google Security Operationsの強化と、Wizのコンテキスト分析、CodeMenderのコード修復との連携を紹介しています。
情シスはWiz、Mandiant、Google Security Operationsとコード修復のエージェントを、同じ機能の候補として並べません。クラウド側の情報から修正対象を決める担当、脅威情報を判断する担当、コード変更を承認する担当を分けます。連携を評価する場合は、検出IDと修正チケットを対応付け、インフラのリスク判断からパッチの検証まで追跡できるかを調べます。
関連モデルやプラグインとの区別
セキュリティ用途のモデルと、作業を実行するエージェントは、同じ比較表へ無条件に並べません。Claude Security pluginを調べる場合も、CodeMenderと名称や出力の印象で比べず、開発フローのどこへ組み込むかを切り分けます。
GPT-Redとは？OpenAIの攻撃専用AIが示すプロンプトインジェクション対策と情シスの実務ポイントは攻撃を想定した評価の論点、Claude Mythosとは？情シスが押さえるべきポイントは利用条件を整理するための関連解説です。Fugu-Cyberとは？性能・料金・情シスが導入前に確認すべきポイントでは、セキュリティ特化モデルを検討する際の論点を扱います。これらの記事への導線は、同製品の提供条件や性能の根拠とは分けて扱います。
社内の製品分類を統一するなら、AIエージェント比較｜情シスが押さえる選定基準を使って、モデル、実行エージェント、運用基盤を区分します。Claude Fable 5の企業導入ガイドやGPT-5.6の企業導入ガイドを参照する場合も、汎用モデルの選定とコード修復の業務評価を別の稟議項目にします。
▶ 関連記事: IPA情報セキュリティ10大脅威2026｜AIリスクと情シス対策
社内稟議に使えるPoC評価チェックリスト
PoCは、検出精度だけで合否を決めず、修正までの総工数・再現性・安全性を同じ対象で測定します。
開始前に固定する評価条件
自社開発がある企業では、情シスと開発部門が評価対象、合否基準、終了条件を先に合意します。既知の脆弱性を含む対象と、正常な動作を期待するテストを用意し、実行後に都合のよい対象だけを集計しないようにします。
評価票の先頭には、対象リポジトリ、リビジョン、利用モデル、CLIのバージョン、スキャンモード、実行日、レビュー担当を記載します。既存ツールとの比較では、対象期間とコードをそろえます。テストが不足するリポジトリは、パッチの生成可否と機能影響を同時に判定できないため、まずテストの整備へ戻します。
測定基準と合否判定ライン
以下の表は、社内稟議やPoCのチェックシートへ転記できる評価項目です。数値目標が必要な項目は、自社の現行実績を基準に事前合意し、測定後に判定ラインを変更しません。
評価カテゴリ | 測定基準 | 合否判定ライン |
|---|---|---|
利用条件 | 契約上の対象組織、目的、対象コード | 全条件を満たす場合のみ開始。満たさなければ中止 |
検出精度 | 既知の脆弱性の検出数／評価対象数 | 事前指定した重大な問題を検出。見逃しは原因と残る対策を記録 |
検証の信頼性 | 検証済み判定を担当者が再現できた数／再確認数 | 実行条件と証拠を第三者が追跡できること |
未検証の扱い | 実行不能・時間切れ・環境不足の分類 | 未検証を安全判定へ混ぜていないこと |
パッチ品質 | 採用、修正後採用、不採用の件数と理由 | 変更目的と差分をレビュー担当が説明できること |
機能影響 | 既存テストと追加した再現テストの結果 | 既存テストが通り、対象問題の再現が解消すること |
総工数 | 環境構築、実行監視、調査、レビューの作業時間 | 事前に置いた工数上限内。超過時は工程を分けて再評価 |
データ管理 | 契約・保存先・アクセス記録・削除記録 | 社内基準を満たし、評価終了後の処理まで実行できること |
権限と隔離 | リポジトリ権限、到達可能なネットワーク、資格情報 | 許可対象外へ書き込み・接続できないこと |
費用管理 | 工程別トークン、環境費、再実行分の利用量 | 予算内に収まり、超過前に停止判断できること |
既存ツールとの関係 | 新規検出、重複、既存ツールのみの検出 | 残す機能と統合する機能を説明できること |
運用引き継ぎ | 担当者以外による結果の追跡と再実行 | 個人端末や個人の記憶に依存せず引き継げること |
「パッチが生成された」を成功条件にすると、不採用の差分やレビュー負荷を見落とします。採用率と総工数を合わせて見て、修正候補が増えた分だけ調査が長くなっていないかを判定します。
開始から終了までの担当と成果物
PoCの各段階に責任者を置くと、途中で止まった理由を製品の問題と社内準備の問題に分けられます。情シスだけでコード修正の妥当性を判断せず、開発部門にテストと差分の評価を割り当てます。
フェーズ | 担当 | 完了時の成果物 | 次へ進む条件 |
|---|---|---|---|
利用審査 | 情シス・法務・セキュリティ | 利用目的、許可対象、データ条件の記録 | 評価範囲の承認 |
環境準備 | 情シス・開発部門 | 隔離環境、テスト、基準値、停止手順 | 既存テストの再現 |
実行と測定 | 評価担当・開発部門 | 検出、検証、差分、工数、費用の記録 | 事前に決めた対象の評価完了 |
判定と終了処理 | 承認者・情シス | 評価報告、残課題、資格情報の失効記録 | 継続評価または終了の決裁 |
稟議書へ転記する判定文
稟議では、効果、未解決事項、次の行動を一つの文章にまとめます。合格・不合格だけを書かず、どの範囲なら次へ進めるかを限定します。
今回の評価対象は［対象リポジトリ・リビジョン］です。既知の問題の検出は［実測結果］、パッチの採否は［実測結果］、総作業時間と利用料は［実測結果］でした。［利用条件・隔離・データ管理］の基準を満たしたため、［許可された次の評価範囲］へ進みます。未解決の［課題］は［担当部門］が処理し、解消するまで対象を拡大しません。
工数の基準値がなければ、今回の結果を初回測定として残します。社内報告で「効率化した」と断定せず、次回の比較条件と担当を決めて終了します。
▶ 関連記事: AIガバナンスの実装手順｜ISO42001対応とシャドーAI対策
導入時の注意点と失敗パターン
CodeMenderの評価で避けるべき失敗は、修復の速さだけを測り、権限・レビュー・既存機能への影響を評価対象から外すことです。
自動生成と自動承認の混同
差分が生成されても、人間のレビューを省く理由にはなりません。Google DeepMindは研究段階のパッチを人間がレビューしており、情シスも評価用パッチの承認者を明示します。
やってはいけないのは、AIの判定をそのまま採否の条件にする運用です。開発部門が再現テスト、既存テスト、差分の妥当性を調べ、承認記録を残します。評価用ブランチへ変更できても、本番ブランチへ書き込める権限は与えません。
再現できない問題の過小評価
PoCエクスプロイトが成功しなかった場合は、悪用不能と実行不能を分けます。ビルド失敗、外部サービスへの接続不可、必要なデータの不足は、脆弱性そのものの否定にはなりません。
評価票へ「検証済み」「未検証」「対象外」の区分を設け、未検証には担当者と次の調査を割り当てます。優先順位を下げる場合も、エージェントが再現できなかったという理由だけで決めず、公開範囲、権限、扱うデータと既存の対策を人間が判断します。
レビュー待ちによる新たな滞留
パッチの生成量にレビュー体制が追いつかない場合は、実行対象を絞ってから次のスキャンへ進みます。未処理の差分を積み上げても、適用までの時間は短くなりません。
情シスは、生成からレビュー開始までの待ち時間と、レビューに使った作業時間を分けて集計します。前者が長ければ担当の割り当てや同時実行数を見直し、後者が長ければ証拠の不足や変更範囲の大きさを調べます。採用件数だけを成果指標にせず、不採用の調査へ使った時間も含めます。
既存の検査を先に止める失敗
PoCの一部で良い結果が出ても、SASTやSCAを直ちに停止しません。CodeMenderで見つかった問題と、既存ツールでしか見つからなかった問題を突き合わせ、残す検査を決めます。
特に依存関係の把握や継続的な監視は、単発のコード修復とは管理対象が異なります。ツールの統廃合は、評価対象外のリポジトリや定期実行の要件まで含めて判断します。予算削減を先に決めてから機能差を調べる順序にはしません。
連携と権限を一度に広げる失敗
CLIの評価が終わる前に、リポジトリ、チケット、CI/CD、外部エージェントへ接続を広げると、失敗時の原因を切り分けにくくなります。まず探索・検証・修復を限定環境で測り、その後に許可範囲内の連携を一つずつ追加します。
想定外の書き込みや通信が発生した場合は接続を切り、既存の手動手順へ戻します。停止できる担当者が不在のまま、無人で実行を継続しない運用にします。
▶ 関連記事: 「Gemini 3.6 Flash」など3モデル発表｜情シス向け 性能・料金・導入判断ガイド
▲ PoCエクスプロイト実行結果に応じたステータス分類と対処の判断手順。
開発部門がない情シスの資産管理とベンダー評価
自社コードを扱わない情シスは、この種のAIツールの導入有無ではなく、利用ベンダーが脆弱性を修正し、自社へ影響と対応状況を伝えるまでの手順を評価します。
影響判定に使うIT資産・SaaS台帳
脆弱性の一報を受けたら、情シスは利用製品、対象バージョン、利用部門、管理者、連絡先を台帳から照合します。SaaSでは顧客側で内部のバージョンを取得できない場合もあるため、ベンダーのアドバイザリと問い合わせ先を対応付けます。
製品名、契約先、利用目的、重要な業務との関係を記録します。
利用部門、社内管理者、緊急連絡先、代替連絡先を記録します。
端末やインストール型ソフトでは、取得できるバージョンと更新状況を記録します。
ベンダー管理のサービスでは、障害・脆弱性の通知先と影響判定の窓口を記録します。
未管理の利用を見つけたら、所有部門の特定と継続利用の判断をチケットへ残します。
表計算で管理する場合でも、更新担当と更新の契機を決めれば着手できます。入退社、契約更新、端末配布などの作業と台帳更新を結び付けます。進め方はSaaS棚卸しの手順と進め方、未管理の利用を扱う際の論点はシャドーITのリスクと対策で補足しています。
ベンダーへ送る確認テンプレート
質問票では、AIの採用を合否条件にせず、発見・修正・通知を実行できるかを判定します。ベンダーがAIエージェントを使っているという回答だけでは、契約上の利用範囲や本番の対応手順まで分かりません。
確認カテゴリ | 具体的な質問 | 回答を受けた後の判断 |
|---|---|---|
発見体制 | 静的解析、動的解析、依存関係管理、AI利用をどの工程で実施していますか | 対象製品と実施範囲を説明できれば評価を継続。対象外の工程は代替策を評価 |
修正提供 | 重大度ごとの修正目標と、期限を超えた際の対応は何ですか | 自社の業務継続条件に合えば採用判断へ反映。合わなければ暫定対策を契約条件に追加 |
通知 | 影響の有無、回避策、修正予定を誰へ、どの手段で通知しますか | 社内窓口と接続できれば運用開始。できなければ自社の監視・問い合わせ担当を設定 |
パッチ検証 | AI生成を含む変更を誰がレビューし、どのテストで承認しますか | 承認手順と証跡を評価。自動生成だけの説明なら追加の安全策を要求 |
構成管理 | SBOM、または利用OSSの影響調査結果を提供できますか | 提供できれば台帳と照合。できなければ影響回答の窓口と回答期限を合意 |
外部評価 | SOC 2、ISMSなどの対象範囲と直近の評価資料を提示できますか | 取得名だけで判断せず、対象サービスと例外事項を審査 |
評価用AIの利用 | プレビュー製品を使う場合、利用目的と契約条件をどう管理していますか | 評価と本番の手順を分離できているかを審査 |
ソフトウェアの部品から影響を調べる場合は、SBOMとは？メリットや注意点をわかりやすく解説を使って開示範囲を整理します。委託先まで含む論点はサプライチェーン攻撃とは？手口と対策、評価制度との対応付けはSCS評価制度への対応で補足しています。質問票の下調べにはクラウドサービスセキュリティチェックDBも利用できますが、掲載情報だけで最新の契約条件を代替しません。
一報から周知までの担当と順序
情シスは、情報を受ける担当、影響を判定する担当、業務停止を決める承認者を先に割り当てます。通知先を増やすだけで終わらず、誰が次の作業を引き受けるかまで決めます。
受信：JPCERT/CC、IPA、利用ベンダーの情報を担当窓口で受け、製品名と問題の概要をチケット化します。
照合：資産台帳と利用部門へ当たり、影響あり・なし・調査中を分けます。
暫定対応：修正を待つ間に制限できる機能や接続を、業務部門と判断します。
周知：利用者へ必要な操作、禁止事項、問い合わせ先を伝え、経営層へ業務影響を報告します。
完了：適用結果と残存リスクを記録し、台帳・手順・質問票の更新を担当者へ割り当てます。
連絡の設計はインシデント対応とは？発生時の流れと備え、全体の役割整理はNIST CSFとは？6つの機能と活用方法に接続できます。アクセス制限の判断にはゼロトラストセキュリティの基本、社内で優先順位を説明する材料にはIPA「情報セキュリティ10大脅威 2026」組織編の読み解きを使います。
台帳の維持方法とAdminaの検討範囲
管理対象を担当者が継続して更新できるなら、既存の台帳やチケット管理から始めます。契約情報、アカウント情報、端末情報を何度も照合しているなら、連携可能な管理ツールを比較します。
マネーフォワード Adminaを検討する場合は、SaaS利用状況の可視化、デバイス管理、シャドーAIの検知の対象を、自社の台帳要件と突き合わせます。導入前に、利用サービスとの連携範囲、収集できる項目、収集できない資産の補完方法を評価します。
Adminaによる資産情報の整理と、コードの検証・修復を担うAIエージェントの利用は別の用途です。資産台帳を整えても脆弱性が自動修復されるわけではなく、コード修復ができても全社の利用サービスを把握できるわけではありません。セキュリティ対策機能と料金プランを検討材料にし、取得したい項目が決まった段階でデモで連携範囲を確かめると、導入する場合と既存運用を続ける場合を比較できます。
まとめ
CodeMenderは、脆弱性の探索、悪用可能性の検証、修復をつなぐAIエージェントです。情シスは、限定プレビューの利用条件とクラウド・隔離環境の役割を押さえ、許可された範囲で評価します。
明日からの最初の一歩は、自社開発があるなら評価対象と既存の対応工数を一つ決めることです。開発部門がないなら、主要な利用サービスの管理者・通知先・影響回答の窓口を台帳へ追加します。製品の採用判断は、その準備を終えてから進めます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
