2026年10月、JPCERT/CCは国内で相次ぐ不正アクセスについて注意喚起を発表しました。

既知の脆弱性を狙った攻撃やAPIへの不正アクセスに加え、その後の調査ではAIを利用した脆弱性の探索や攻撃試行も確認されています。

企業はこれまで、脆弱性スキャナー、EDR、クラウドセキュリティ管理ツールなど、さまざまな検出技術に投資してきました。AIの進化によって、脆弱性を発見する能力もさらに向上しています。

しかし、現場では依然として、パッチの未適用、過剰なアクセス権限、不適切な設定、把握できていないシステムなど、基本的な問題が残り続けています。

問題は、脆弱性を見つけられないことだけではありません。見つかった問題を、安全に修正できていないことです。

脆弱性は見つかっている。それでも修正が進まない

企業のIT運用では、よくある光景です。

重大なCVEが検出され、セキュリティ担当者がチケットを起票する。インフラ担当者に修正を依頼するものの、対象システムの調査、影響確認、テスト、変更承認に時間がかかり、なかなか本番環境に反映できない。

どのサーバーやコンテナで動いているのか。インターネットからアクセス可能なのか。修正すると、どの業務システムに影響するのか。

こうした情報がすぐに分からなければ、担当者は慎重にならざるを得ません。

CVSSは脆弱性の深刻度を示し、CISAのKEVは実際に悪用されている脆弱性の把握に役立ちます。FIRSTのEPSSは、今後30日以内に悪用される確率を推定します。

しかし、これらの情報だけでは、自社環境での実際のリスクや、変更による業務影響までは分かりません。

脆弱性管理の難しさは、検出した後にあります。

SaibaRadarから見える、企業間の依存関係

Aokumoが公開している無料のサイバーインシデント情報サービス「SaibaRadar」では、日本国内の公開情報を収集し、企業やサービス間の関係を整理しています。

例えば、2026年10月30日に掲載したシュッピン（マップカメラ）とPRAISE-NETの事案です。

SaibaRadarでは、いずれもメール配信サービス「Cuenote FC」の不正アクセスに関連する報告として整理しています。

掲載された二次報道では、マップカメラの顧客情報7万7,204件、PRAISE-NETのメールアドレス3万750件について、漏えいの可能性が報じられています。

これらは漏えいが確定した人数ではなく、各社の一次公表資料を確認できていないこともSaibaRadar上に明記しています。

注目したいのは、サービス提供者と利用企業の依存関係です。

一つのサービスでインシデントが発生すると、複数の利用企業で影響調査や顧客対応が必要になることがあります。

自社のサーバーやクラウド環境だけを把握していても、外部サービスを含む依存関係が分からなければ、影響範囲を迅速に判断できません。

セキュリティ運用には、脆弱性の検出だけでなく、資産、設定、アクセス権限、サービス間のつながりを継続的に把握することが求められます。

実際のCVEを例に考える、修正までの流れ

2026年8月、JPCERT/CCはMetabaseのSQLインジェクション脆弱性「CVE-2026-72898」について注意喚起を発表しました。実際の悪用も確認されています。

重要なのは、修正版への更新だけで対応を終えないことです。

脆弱なエンドポイントをインターネットに公開していた場合、すでに侵害されていないかを調査する必要もあります。

では、継続的なセキュリティ運用では、どのように対応するのでしょうか。

1. 影響範囲の調査

影響を受けるMetabaseのバージョン、稼働中のワークロード、外部公開状況、接続先データベースを特定する。

2. リスクと依存関係の把握

対象システムがどの業務に利用され、どのデータや認証情報にアクセスできるのかを確認する。

3. 修正計画の作成

修正版への更新や一時的なアクセス制限を検討し、変更の前提条件と復旧方法を定義する。

4. 実行制御

変更内容をリスクに応じて評価する。例えば、業務システムで使用する認証情報のローテーションや、重要なデータベースへのアクセス変更は、追加承認が必要な操作として扱う。

5. 修正と検証

承認された変更を実行し、脆弱性の解消、侵害の有無、サービスの正常性を確認する。

6. 必要に応じた復旧

変更によって障害が発生した場合は、事前に定義した手順で復旧する。ロールバック可能な操作については、安全に元の状態へ戻す。

ここで重要なのは、パッチの適用自体をゴールにしないことです。

実際にリスクが減ったことを検証して、初めて対応が完了します。

CVE管理から、継続的なセキュリティ運用へ

従来の脆弱性管理は、脆弱性の発見、分類、優先順位付けが中心でした。

これから必要なのは、その先の実行と検証までを一つの継続的なプロセスとして運用することです。

検出 → 影響分析 → 優先順位付け → 対応準備 → 実行制御 → 修正 → 検証 → 継続監視

Gartnerが提唱するCTEM（Continuous Threat Exposure Management）も、脅威への露出を継続的に把握・評価・検証し、対応につなげる考え方です。

企業にとって課題となるのは、こうした判断を実際の本番環境で安全に実行できるかどうかです。

Aokumoが開発する Aokumo AI は、インフラ環境の理解と「Governed Execution（統制された実行）」を組み合わせ、この課題に取り組んでいます。

AIエージェントが操作対象のリソースや依存関係を把握し、変更の影響を評価したうえで、ポリシーに従って実行を制御する仕組みです。

例えば、AIエージェントが本番環境のネットワーク設定変更や認証情報のローテーションを提案した場合、Aokumo AIは操作内容とリスクを評価し、ポリシーに基づいて実行の許可、ブロック、追加承認を判断します。

実行内容と結果を記録・検証し、ロールバック可能な変更については、事前に定義された手順で復旧します。

目指すのは、単なる修復作業の自動化ではありません。本番環境で安全かつ継続的に修復を実行できる仕組みです。

検出件数ではなく、修正できた成果を測る

セキュリティ運用の成果を、検出したCVEの件数やクローズしたチケット数だけで測るのは十分ではありません。

今後は、次のような指標が重要になります。

AIによって脆弱性の発見や分析が速くなっても、修正が進まなければ企業のリスクは減りません。

資産管理、パッチ適用、最小権限、設定管理、ネットワーク分離、バックアップ。セキュリティの基本は変わりません。

変えるべきなのは、それらを継続的に実行できる運用の仕組みです。

検出は出発点。修正し、その結果を検証して初めて成果になります。

CVE管理から、継続的なセキュリティ運用へ。

企業のセキュリティは、検出中心の管理から、実際のリスク低減を重視する運用へ進む必要があります。

重大なCVEの検出から修復・検証まで、どれくらい時間がかかっていますか？

Aokumo AIがインフラ環境の調査、影響範囲の分析、実行制御、修復結果の検証をどのように支援するか、具体的なシナリオでご紹介します。

30分のデモで、Governed Executionによるセキュリティ対応をご覧ください。

デモを予約する

参考資料

• JPCERT/CC：国内組織における不正アクセスに関する注意喚起

• JPCERT/CC：Metabaseの脆弱性 CVE-2026-72898

• SaibaRadar：シュッピン／マップカメラ

• SaibaRadar：PRAISE-NET

• IPA：情報セキュリティ10大脅威 2026