サイバー攻撃の主戦場は、もはや「侵入を防ぐ」だけではありません。侵入後の横展開や権限昇格、既知脆弱性の悪用をいかに短時間で封じるかが、被害規模を決める時代です。こうした背景の下、SBGとOpenAIがAIを活用した脆弱性診断と修正支援を包括的に提供する「Patching as a Service」を打ち出し、まず日本の重要インフラを対象に展開するという動きは、セキュリティ運用の前提を変える可能性があります。
「パッチ適用が遅れる構造」が重要インフラを弱くする
重要インフラは、一般企業以上にパッチ適用が難しい領域です。発電・送配電、交通、医療、通信、金融などでは、停止できないシステムが多く、メンテナンスウィンドウが限られます。さらにOT（制御系）やレガシーOS、ベンダ依存の専用アプリ、機器認証の制約が重なり、「脆弱性は分かっているが適用できない」「適用による影響評価が終わらない」といった滞留が常態化しがちです。
一方、攻撃側は脆弱性の武器化を高速化しています。公開情報やPoC、攻撃ツールの流通によって、パッチ公開から悪用までの時間差は短縮する傾向にあります。したがって、防御側に必要なのは単なるスキャンではなく、影響度判定、修正方針、検証、展開、例外管理までを一気通貫で回す運用能力です。ここにAIの介入余地があります。
Patching as a Serviceとは何か──診断から修正までを「運用の単位」にする
「Patching as a Service」を直訳すれば「パッチ提供のサービス」ですが、実態はより広い概念です。脆弱性を見つけるだけでなく、修正の実行可能性を高め、適用までのリードタイムを縮めることが目的になります。典型的には次の要素が含まれます。
- 脆弱性の発見：コード解析、設定監査、依存関係（SBOM）やコンテナイメージの検査、動的テストなど
- 優先順位付け：CVSSだけでなく、資産重要度、露出度、悪用実績、到達可能性を加味して絞り込み
- 修正案の作成：パッチ候補、設定変更、回避策、署名・互換性を踏まえた適用方法の提示
- 検証支援：テストケース作成、リグレッション観点の抽出、適用後の監視ポイント提示
- 展開と例外管理：段階展開、ロールバック計画、適用不可時の補完統制（WAF/IPS/分離/最小権限）
重要なのは、これらを「ツールの寄せ集め」ではなく、成果物（パッチ適用・リスク低減）に責任を持つ運用サービスとして提供する点です。人材不足が慢性化する日本の現場において、運用品質の平準化に直結します。
AIが効く領域は「判断」と「作業」の中間にある
AI活用というと自動スキャンの高度化を想像しがちですが、より効果が出るのは、脆弱性対応のボトルネックになりやすい「調査」と「調整」です。例えば、脆弱性情報と自組織の構成情報を突合し、影響範囲を推定する作業は時間がかかります。また、修正に伴う影響評価の観点が抜けると、障害リスクを理由に適用が先送りされます。
AIは、変更差分の理解、依存関係の推定、設定・コードの問題箇所の要約、修正方針の候補提示、テスト観点の抽出など、専門家の思考を補助する形で生産性を上げられます。これにより、担当者は「調査に追われる」状態から「意思決定と合意形成に集中する」状態へ移りやすくなります。
重要インフラでの導入が先行する理由──高い要求水準と社会的影響
重要インフラはセキュリティ投資の優先度が高い一方、要件も厳格です。可用性最優先、変更管理の厳格さ、監査対応、サプライチェーン制約、ネットワーク分離など、一般的なIT環境の常識が通用しません。だからこそ、ここで成立する運用モデルは、他業界にも波及しやすい「参照モデル」になります。
また、社会的影響の大きさゆえに、単発のコンサルや年次監査だけでは不十分です。日々変化する脆弱性と資産状況に追随するためには、継続的なサービスとしてのパッチ運用が求められます。Patching as a Serviceは、まさにこのギャップを埋める提案です。
導入時の論点──AI任せにしないガバナンス設計
一方で、AIをセキュリティ運用の中核に据える場合、リスクも同時に増えます。特に重要インフラでは、次の論点を最初に設計すべきです。
- 責任分界点：誰が最終判断し、誰が変更承認するのか（AIは助言者に留める設計が基本）
- 再現性と説明可能性：なぜその優先度・修正方針なのかを監査可能な形で残す
- データ取り扱い：構成情報、ログ、ソース、脆弱性情報の機微性を踏まえた隔離と保存期間
- 安全な自動化：自動適用範囲を限定し、段階展開・ロールバック・フェイルセーフを標準化
- サプライチェーン：ベンダ提供パッチと自前修正（暫定パッチ）の混在時の責任と検証手順
加えて、OT領域では「パッチを当てる」以外の緩和策が現実的な場合もあります。ネットワークのマイクロセグメンテーション、踏み台制御、資産の可視化、アプリ制御、脆弱性の露出面削減といった補完統制を、AIが提示する修正案と同じ土俵で扱える設計が望まれます。
セキュリティ担当者が今すぐ準備すべきこと
Patching as a Serviceを有効に機能させる鍵は、AIそのものよりも「入力」と「運用」です。導入検討段階で、次の準備が成果を左右します。
- 資産台帳の整備：機器・OS・ミドルウェア・アプリ・依存関係・責任者を最新化
- 変更管理の標準化：緊急パッチの例外フロー、承認者、停止許容時間を明確化
- テスト環境と手順：最低限の回帰テスト観点とロールバック手順を型化
- リスク受容の基準：適用不可時に何をもって「許容」とするかを定義
これらが揃うほど、AIの提案は「実行可能な作業指示」に近づき、現場の摩擦が減ります。
まとめ──「見つける」から「塞ぐ」へ、運用の重心が移る
脆弱性診断は長年、発見と報告に偏りがちでした。しかし現実のリスクを下げるのは、パッチ適用や緩和策の実装という地味で複雑な運用です。SBGとOpenAIが掲げるPatching as a Serviceは、その運用領域をAIで加速し、重要インフラのように厳しい制約下でも「塞ぐ」までをサービスとして担う点に価値があります。
今後の焦点は、AIの精度競争だけではなく、ガバナンス、監査可能性、変更管理、そして適用不能領域を含めた現実的なリスク低減をどこまで体系化できるかに移ります。セキュリティの勝負は、検知でも診断でもなく、最終的に「修正が回る組織」を作れるかどうかです。
参照: SBGとOpenAI、AIで脆弱性診断「Patching as a Service」提供 まずは日本の重要インフラ向けに