AIで脆弱性管理を自動化するには？検知から本番反映までの流れと、人が判断する範囲

脆弱性管理では、AIに任せる範囲と人の判断の範囲を決めます。

AIを使い、ソフトウェアの部品（依存関係）の一覧を公開済みの脆弱性情報と継続的に照合する運用が考えられます。

AIは修正案の作成と検証を支えます。判断材料が足りない場合は人が確認し、本番反映の可否は権限を持つ責任者が記録に基づいて決めます。

脆弱性情報の公開が相次ぎ、更新の機会は頻繁になっている

実際に悪用された脆弱性を集めたCISAのカタログでは、2026年の追加数が10月27日時点で276件となり、2025年通年の245件をすでに超えました。出典：CISA KEV公式データ

広く使われている言語の一つ、PHPを例に挙げます。2026年10月21日、PHPは、認証なしのリモートコード実行につながる重大な脆弱性2件を修正した版を、8.2から8.5の各系列で公開しました。深刻度は10点満点で9.2と評価され、回避策は露出を減らすだけであり、更新だけが完全な対処だとされています。出典：PHP公式勧告、PHP公式の事前告知

公開から5日後の10月26日、CISAはこの2件を実際に悪用された脆弱性としてカタログへ加えました。IPAも注意喚起を出し、国内の被害は把握していないとしつつ、更新や移行までの暫定対策やアクセス制限を促しています。出典：IPA注意喚起、CISA公式データ

サポートが終了した8.1以前には修正が出ず、8.2も2026年12月31日に終了します。セキュリティリリースは2026年だけで5回ありました。出典：PHP公式アーカイブ、PHP Supported Versions

2024年にも例があります。PHP-CGIの脆弱性（CVE-2024-4577）は、6月6日の修正版の公開から1週間ほどでCISAのカタログに掲載され、ランサムウェア攻撃での利用が記録されています。出典：PHP公式アーカイブ（2024年6月）、CISA公式データ

IPA「情報セキュリティ10大脅威 2026」の組織向けでも、「システムの脆弱性を悪用した攻撃」が4位に入っています。出典：IPA「情報セキュリティ10大脅威 2026」

公開から数日で悪用が確認され、サポート切れの版には修正が出ず、更新は年に何度も来ます。記憶と手作業だけでは追いにくいため、検知・評価・検証・承認を分け、AIと人の担当範囲を決めます。

上記の出典はいずれも2026年10月28日から29日に取得。

検知から本番反映までの全体の流れ

ソフトウェア部品の照合を例にします。部品一覧と公開情報を継続して照合すると、新しい情報が出た時に影響を調べ始められます。

検知では、この照合をAIが継続して行います。

評価では、AIがリスクと影響範囲を複数の観点から整理します。判断材料が足りない場合は評価を保留し、人が確かめます。

AIは評価の根拠を記録し、検証と承認でも参照できるようにします。

検証では、AIが修正案を作り、隔離した検証環境で変更前後のテストを実行します。

変更前後のテストで修正案を確かめます。通らなければ検証を止め、結果を人の確認に回します。

評価の基準は人が定めます。承認では、権限を持つ責任者が評価の根拠、変更内容、テスト結果の記録を読み、本番反映を判断します。

責任者は、承認するか、保留して再検証へ戻すかを決めます。AIが本番へ直接反映しない仕組みにします。

照合で見つかった脆弱性を三つに分ける

照合で見つかった脆弱性は、緊急、通常、自動で直せないものの三つに分けます。

緊急のものは、人に知らせて優先して扱います。通常のものはAIが修正案を作り、隔離した環境で検証します。自動で直せないものは判断材料とともに報告し、責任者が対応を計画します。どの分類でも、本番への反映は責任者の承認を経ます。

更新で壊さないための四つの方針

AIを使う工程では、安全策をあらかじめ組み込みます。AIが読む公開情報は判断の材料として扱い、AIへの指示としては扱いません。運用では、次の四つを組み合わせます。

変更範囲を限定する。一度に扱う範囲を絞り、影響を確かめられる単位で進めます。

隔離した環境で試す。本番とは分けた環境で、AIが作った修正案の動きを確かめます。

変更前後を同じ条件で比べる。変更前後で同じテストを行い、結果の差を記録します。テスト結果も責任者が読む記録に含めます。

異常時は処理を止めて責任者に渡す。異常が出た修正案は本番反映の候補から外し、責任者が内容を確認します。

例外が生じた場合は、停止した処理と、その理由を記録します。責任者は停止後の経緯も記録で確認し、本番反映を承認するか判断します。

自社や提供会社に確かめたい七つの質問

情シスや調達の担当者は、処理の停止から人の確認、記録、承認までが一続きになっているかを確かめます。

七つの回答を別々に見るのではなく、人が確かめる工程から責任者の承認、停止後の再開までが一続きになっているか確かめます。

参考：一般的な考え方

運用で合わせて確かめる点

ここからは、CISAやNISTの公開資料をもとに、組織を問わず確認したい一般的な観点をまとめます。

• 検知の入口。対象の種類によって異なります。提供元の更新情報や通知を確かめるのが基本です。
• 影響の判断。構成に含まれるという事実のみで、影響があるとは判断しません。該当機能や経路を実際に使うか、外部から到達できるかを確かめます。権限や扱う情報も確かめ、材料が足りなければ人が判断します。出典：CISA「SBOM FAQ」（2026年10月28日取得）
• 情報の更新。公開情報は後から更新されるため、参照日時と版を記録し、対応中も更新を確認して影響を評価し直します。
• 提供元が修正するサービス。告知と自社への影響を確かめたうえで、設定変更や一時的な緩和策を選びます。
• 緊急時。確認の順序を変え、隔離や機能停止などの緩和策を先に取ることがあります。その場合も、判断した理由を記録します。出典：NIST「SP 800-40 Rev.4」（2026年10月28日取得）
• 承認後。結果を監視し、問題があれば元に戻すか緩和策へ切り替えます。出典：NIST「SP 800-40 Rev.4」（2026年10月28日取得）
• 戻せない変更。代替策と復旧の条件を事前に確かめておく考え方もあります。

部品を把握する考え方としてのSBOM

SBOMは、ソフトウェアの構成部品と依存関係の一覧です。CISAは、供給網のリスク把握と透明性の確保に役立つ手段と位置づけています。出典：CISA「Software Bill of Materials」（2026年10月26日取得）

SBOMは部品の把握に役立ちますが、影響の有無までは決まりません。利用者は、版・識別子・作成時点を確認し、導入状況や提供元の影響表明と合わせて評価します。出典：CISA「SBOM FAQ」（2026年10月28日取得）

CISAの公開カタログは優先づけの材料になる

CISAの公開カタログには、実際の攻撃で悪用された脆弱性がまとめられています。CISAは民間企業にも、掲載された脆弱性を優先して直すよう勧めています。出典：CISA「Known Exploited Vulnerabilities Catalog」（2026年10月26日取得）

CISAの公開カタログは優先づけの材料ですが、未掲載でも安全とは限りません。利用者は、提供元の情報、露出状況、資産の重要性も合わせて評価します。

公式データでは、2026年10月27日時点の掲載は1,760件でした。出典：CISA公式データ（2026年10月27日版）

PigeonCloud の公式サイトでは、脆弱性点検、バックアップ、ログ、導入形態に関する情報を公開しています。