1. 「CVE、本当は見なきゃいけないんだろうな」
多くのエンジニアが、口には出さないもののうっすら感じていることがあると思います。
日々公開される脆弱性情報、本当は自社への影響を確認すべきなのでは？
実態はどうでしょうか。多くの現場では「Dependabotがアラートを出したら見る」「顧客やニュースで騒ぎになったら調べる」が標準運用になっているはずです。NVDやJVNを毎日巡回して、自社システムへの影響を能動的に確認している中小のシステム開発会社は、ほとんど存在しません。
これは責められる話ではありません。数字を見れば、人手で追うのが不可能なことは明らかだからです。
2. なぜ「放置」が業界標準になったのか
2-1. 物量の問題：1日137件
2025年に公表されたCVEの総数は49,972件。2024年の40,704件から前年比約23%の増加です（出典：電通総研テックブログ「2025年の公開脆弱性情報を振り返る」）。単純計算で1日あたり約137件の脆弱性が新規公開されている計算になります。
この中から自社に関係するものを見つけるには、次の3段階が必要です。
- 自社が何を使っているか把握している（資産の棚卸し）
- 公開されたCVEが自社の資産に該当するか照合する（マッチング）
- 該当した場合、実際に影響があるか判定する（影響判定）
1日137件に対してこれを毎日やる。専任のセキュリティチームがいない組織で回るはずがありません。
ここで「とはいえ、今までこの体制で問題は起きていないのだから、これからも大丈夫だろう」と考えるのは危険です。2026年6月27日のKimi K3の公開を機に、情報セキュリティを取り巻く環境はガラッと変わる危険性があるからです。攻撃側もまたAIを手にしたことで、脆弱性の発見から攻撃コードの作成までのコストが激減しつつあります。「今まで大丈夫だった」は、攻撃コストが高かった時代の話であり、その前提はすでに崩れ始めています（詳細は拙記事「あと10日で攻撃コストが激変する。Kimi K3公開前にやるべきセキュリティ対策」をご覧ください）。
2-2. 質の問題：アラートの大半は「正しいが、影響しない」
「SCAツール（Dependabot等）を入れているから大丈夫」と思われるかもしれません。しかし、SCAツールを運用したことがある方なら、アラートの山が塩漬けになっていく光景をご存知のはずです。
ここで重要なのは、塩漬けになる理由は誤検知ではないという点です。
SCAツールのアラートは「該当バージョンのライブラリを使っている」という検知としては正しい。問題は、脆弱性の多くが特定の関数・特定の設定・特定の使い方でのみ成立することです。つまりアラートの大半は、
検知は正しい。該当バージョンを確かに使っている。ただし、自社の使い方では悪用条件が成立しないので、対応の必要がない
というものになります。これは誤検知（false positive）ではなく、到達可能性（reachability）の問題と呼ばれます。脆弱な関数がコードベースに存在していても、自分のコードからその関数への呼び出し経路がなければ、実質的な影響はありません。
参考までに、2025年に公表された全CVEのうち、PoC（実証コード）が公開されているものは2.47%に過ぎません（出典：同上）。実際に悪用が観測されCISAのKEVカタログに登録される件数は四半期あたり数十件レベルです。つまり、大量のアラートの中で本当に対応が必要なものはごく一部であり、その仕分けこそが脆弱性管理の本体なのです。
そしてこの仕分け＝到達可能性の判定は、コードを読んで文脈を理解する作業です。ツールでは自動化できず、人手では物量的に回らない。だから塩漬けになる。
誤検知なら「ツールの精度が悪い」で済みます。正しい検知だからこそ「一応確認しなければならない」という心理的負債が積み上がり、確認が追いつかず、やがて誰もアラートを見なくなる。SCA運用が形骸化する本当のメカニズムはこれです。
2-3. 公式データベースですら処理が追いついていない
さらに象徴的な事実があります。NVD（米国の脆弱性データベース）は2024年2月頃に解析処理が滞り、公開されたCVEにCVSSスコアや影響製品情報が付与されないバックログが急増しました。その後、処理支援の導入で分析数は回復傾向にあるものの、新規公開件数自体が高水準で推移しているため、バックログは高止まりしやすい構造になっています（出典：ネットワンシステムズ「CVE件数増加：NVDバックログとCVSSバージョン推移」）。
国家レベルの機関が専任体制で取り組んでも人手では処理しきれない物量を、中小のエンジニアが片手間で追えるはずがない。CVEの放置は怠慢ではなく、そもそも中小企業では物理的に不可能であり、大企業であっても経済合理性の観点からすべてに対応するという判断はまず下されない——ここまでが前提の整理です。
3. 前提が変わった：コードを読んで文脈判定できるAIの登場
生成AI、特にコードベース全体を扱えるエージェント型のAIツール（Claude Code等）の登場で、この構造の一番のボトルネックが解消可能になりました。
「コードを読んで、文脈を理解し、判定する」——人手でしかできなかったこの作業を、機械的に回せるようになったのです。
脆弱性対応のライフサイクル全体で見ると、AIが介入できるポイントは次のようになります。
【平時：監視】
資産棚卸し → CVEフィード照合 → 到達可能性の一次判定 → 通知
│ │ │
└────────────┴───────────────────┘
これまで人手では不可能だった領域
【有事：対応】
詳細調査 → 影響範囲特定 → 改修 → テスト → 報告
│ │ │ │ │
└──────────┴──────────┴───────┴───────┘
時間勝負の全工程を圧縮できる領域
以降、平時と有事に分けて具体的に見ていきます。
4. 平時編：日常のCVE監視をAIで回す
4-1. 資産の「実態ベース」棚卸し
最初の関門は「自社が何を使っているか」の把握です。ここで重要なのは、composer.jsonやpackage.jsonなどの宣言された依存関係だけでは不十分という点です。
保守開発の現場、特に歴史の長いコードベースには、依存関係グラフに載らないものが大量にあります。
- 手動で配置されたJSライブラリ、vendorディレクトリに直接コピーされたコード
- CDN経由で読み込まれるライブラリ
- フォーク・改造されてバージョン番号が原型を留めていないライブラリ
- Apache、nginx、OpenSSL、PHP本体などのミドルウェア・実行環境
SCAツールは宣言された依存しか見ませんが、AIエージェントならコードベースを走査して「実際に何が使われているか」を実態ベースで棚卸しできます。SBOM（ソフトウェア部品表）の実態版を作るイメージです。これは一度作れば、以降は差分更新で維持できます。
4-2. CVEフィードとの突き合わせと、到達可能性の一次判定
資産一覧ができれば、あとは日次で回す仕組みの問題です。構成のイメージは次のとおりです。
[cron/CIの定期実行]
│
▼
[NVD API / JVN から当日公開分のCVEを取得]
│
▼
[資産一覧と機械的にマッチング] ─── 該当なし → 終了
│ 該当あり
▼
[AIによる到達可能性の一次判定]
・CVEの内容を読解（どの関数・どの設定・どの条件で成立するか）
・コードベースを走査（該当機能を使っているか、呼び出し経路があるか）
・「影響の可能性：高/低/なし」+ 判定根拠を出力
│
▼
[Slack等へ通知]
影響の可能性が高いものだけ、根拠付きで人間に上がってくる
ポイントは最後の段です。従来のSCA運用では「バージョン該当＝全部アラート」だったものが、この構成で人間に届くのは、あなたのコードのこの箇所がこの条件に該当するため影響の可能性が高い、という根拠付きの通知だけになります。
もちろんAIの判定は一次スクリーニングであり、最終判断は人間が行うべきです。しかし「137件/日 → 数件/週の根拠付き候補」まで絞り込まれれば、人間の判断は十分に回ります。到達可能性の判定を機械で回せるようになったこと自体が、VEXのような規格が人手前提で運用しようとして普及に苦しんできた課題への、実務的な回答になっています。
4-3. 判定精度についての注意
注意事項として、AIの到達可能性判定は完璧ではありません。
- 偽陰性のリスク：動的な呼び出し（リフレクション、動的require等）は静的な走査で見落とす可能性がある
- 判定の再現性：同じ入力でも判定が揺れることがあるため、「影響なし」判定の根拠は記録として残す運用が望ましい
したがって推奨は「AIの判定を鵜呑みにして自動クローズ」ではなく、「AIが根拠付きで優先順位をつけ、人間が上位だけ確認する」運用です。それでも、全件を人間が見る（＝実際には誰も見ない）現状と比べれば、セキュリティ水準は桁違いに向上します。
5. 有事編：ゼロデイ・緊急対応の工程を圧縮する
平時の監視で「影響あり」が見つかったとき、あるいは世間を騒がせる脆弱性が公開されたとき、対応は時間勝負になります。脆弱性の公開からエクスプロイトの出回りまでの時間は年々短くなっており、対応にかかる日数がそのまま被害リスクに直結します。
実例を挙げます。2014年、SSLの著名な脆弱性「Heartbleed」が公開された際、国内では大手カード会社の三菱UFJニコスがこの脆弱性を突かれ、894人分の会員情報（カード番号・氏名・生年月日・住所等）が不正閲覧される事件が起きました。注目すべきはその速度です。脆弱性の公表が4月7日、不正アクセスの発生が4月11日——わずか4日で攻撃が届いたのです。同社は対策を進めていましたが、攻撃の方が速かった。「対策講じるも間に合わず」と報じられたこの事件は、脆弱性対応が文字どおりの時間勝負であることを示しています。しかもこれは10年以上前の話であり、攻撃までの猶予は当時より確実に短くなっています。
そして緊急対応には、増員が効かないという特徴があります。ボトルネックは調査と判断であり、人を投入しても速くなりません。「人員には余裕がある」組織であっても、この領域では余裕が意味を持たないのです。ここがAIの介入価値が最も明確に出る場面です。
工程ごとに見ていきます。
5-1. 調査
公開されたアドバイザリ、CVE詳細、ベンダー情報、コミュニティの分析を読み込み、「何が・どの条件で・どう悪用されるのか」を要約する。英語の一次情報の読解を含め、従来なら半日かかっていた初動の状況把握が数十分に短縮できます。
5-2. 影響範囲の特定
該当ライブラリ・該当機能の使用箇所をコードベース全体から走査し、呼び出し経路を追跡する。「どの画面・どのAPI・どのバッチが影響を受けるか」の一覧化は、システムを熟知した担当者でも丸一日仕事になりがちな工程ですが、AIエージェントなら網羅的かつ高速に行えます。属人化した知識に依存しない点も重要です。
5-3. 改修
パッチ適用が可能ならバージョンアップに伴う破壊的変更の洗い出しを、即時のバージョンアップが困難なら回避策（WAFルール、設定変更、該当機能の一時無効化）の実装案を出させる。レガシーなフレームワークでパッチ提供が終了しているケースでも、脆弱性の原理を踏まえた独自の応急対策を検討できます。
5-4. テスト
改修の影響箇所に絞った回帰テストの観点出しと、テストコードの生成。緊急対応で最も削られがちなのがテストであり、「急いで直したら別の場所が壊れた」という二次障害の温床です。テスト工程を圧縮できることは、速度だけでなく品質の担保に直結します。
5-5. 報告
顧客・上位会社向けの対応報告書のドラフト作成。影響範囲、対応内容、再発防止策を、技術者でない相手にも伝わる形に翻訳する。緊急対応の終盤、疲弊しきったタイミングで発生するこの作業をAIに任せられる意味は、経験者ほど分かるはずです。
5-6. 全体として
各工程の短縮が積み上がると、「対応完了まで3日」が「1日」になる、という規模の圧縮が現実的になります。緊急対応において時間はそのまま被害リスクなので、この差は品質改善やコスト削減とは別次元の、リスク低減として直接的な経営価値を持ちます。
6. おわりに：「見なくていい理由」は消えた
整理します。
- CVEの放置は怠慢ではなく、1日137件という物量と、到達可能性判定が人手でしか行えないという構造による「合理的な諦め」だった
- コードを読んで文脈判定できるAIの登場で、この構造のボトルネックが解消可能になった
- 平時は「根拠付きの絞り込み済み通知」として監視を回せるようになり、有事は調査から報告までの全工程を圧縮できるようになった
諦めの前提が崩れた以上、「見なくていい理由」はもうありません。逆に言えば、この仕組みを回している組織とそうでない組織の間で、セキュリティ水準の差はこれから静かに、しかし確実に開いていきます。
最後にもう一点。本記事でAIが行ったことを能力単位で振り返ると、「文書を読む」「コードベースを理解する」「書く」「テスト観点を出す」「文書化する」の5つでした。どれも緊急時専用の能力ではありません。 時間勝負の最も過酷な場面で通用する能力が、平時の保守開発で通用しないはずがない——同じ能力を日常業務に向けるとどうなるかは、次回の記事で扱います。
参考情報
- 電通総研 テックブログ「2025年の公開脆弱性情報を振り返る」
- ネットワンシステムズ「CVE件数増加：NVDバックログとCVSSバージョン推移」
- CISA Known Exploited Vulnerabilities Catalog
- 三菱UFJニコス「弊社会員専用WEBサービスへの不正アクセスにより一部のお客さま情報が不正閲覧された件」(2014年4月18日) ほか当時の各社報道