Windowsの脆弱性管理がまたもうまくいかない”報われない理由”：情シスを救う3つの基準

Windows環境の脆弱性管理において、月例アップデートの適用がうまくいかないという声がある。本稿は、脆弱性管理において情シスが抱える具体的な課題と、取るべき改善策を紹介する。

[星 陽介，雨輝ITラボ（リーフレイン）]

　「月例アップデートの時期は憂鬱になる」「パッチを当てようとすると業務部門から止めてほしいと言われる」「でも放置して何か起きたら情シスのせいになる」「Windowsのアップデート管理も、業務部門との調整も、経営層への説明も、気付いたら全部自分が抱えている」――。

　Windowsの脆弱（ぜいじゃく）性管理に取り組む情報システム部門（以下、情シス）の現場で、こうした声が聞かれることがある。Windows環境の脆弱性管理は必要なことではあるものの、管理が機能しにくい組織もある。そのような状況を改善するための枠組みを整理する。

月例アップデートを当てている＝脆弱性管理はできている？

併せて読みたいお薦め記事

AIと脆弱性の関連記事

• 「パッチのビッグウェーブがやってくる」　AI悪用で崩壊する脆弱性管理の常識
• サイバー攻撃の“今これが大事”と取るべき対策は？　「22秒で攻撃準備」という現実

　月例更新プログラムを適用していることと、脆弱性が管理できていることは別の話だ。そこには認識のズレがある。

適用作業をこなしていても管理できているとは限らない

　Microsoftは米国時間の毎月第2火曜日（日本時間では翌水曜日）に、Windows OSやOffice製品などの脆弱性を修正する更新プログラムを公開している。プログラムの適用は、多くの情シスにとってセキュリティ管理の基本となる。

　しかし、月例アップデートを適用する作業は進めつつも、「全端末に適用できているか分からない」「テレワーク用端末のアップデート状況を把握しきれていない」「古いシステムとの互換性問題で適用を保留している端末がたまっている」という状況が積み上がっている組織もある。

　月例アップデートの適用は脆弱性管理の一部にすぎない。脆弱性管理を一連のプロセスとして機能させるには、「どの端末・システムが対象か」（資産の把握）、「どの端末を優先して対応するか」（評価）、「誰がいつどのように対処するか」（実行）の3つのステップが必要となる。

対応漏れを防ぐには、判断の仕組みが必要

　この3つのステップのうち、評価と実行に判断基準がなければ、適用漏れは積み上がるだけになる。「どの端末に適用済みで、どこが未対応なのか把握できていない」という状態は、判断の設計が存在しない状態の表れだ。2026年1月14日にNTTデータが公開した解説記事「脆弱性はなぜ消えない？ 資産把握からパッチ適用まで、脆弱性管理が機能しない理由を読み解く」は、脆弱性管理が個別対策やツール導入に分断されてしまっている点を本質的な問題として指摘している。

「いつ」「どこから」当てるかが決まっていないと、対応が属人化する

　月例アップデートの内容は毎月変わる。緊急度が高いものもあれば、様子見で差し支えないものもある。しかし「いつ適用するか」を判断する基準が組織内に存在しないと、毎月の対応が担当者の経験と判断に委ねられ続ける。

「いつ」「どの順番で」当てるのか

　Windows環境では、月例アップデートは原則として全件適用が前提だ。特定のパッチだけを当てるという行為は想定されていない。しかし「全件適用する」という方針を決めただけでは運用は完了していない。Windowsのパッチ適用には再起動を伴うことが多く、「いつ当てるか」「どの端末・システムから展開するか」という判断が毎月発生する。

　ゼロデイ脆弱性（パッチ公開前にすでに攻撃が確認されている脆弱性）が含まれる月は、月例サイクルを待たずに緊急適用を判断する必要がある。一方、業務への影響が大きい基幹システムや、互換性確認が必要な特殊な環境では、即時適用ではなく検証を挟むべき場合もある。こうした判断を毎月担当者が経験則で行っている組織は多い。

情シスが実務で使える判断の軸

　「いつ当てるか」を判断するに当たっては、次の2つが検討の軸になる。

　1つ目は、「その脆弱性は、すでに攻撃で悪用された形跡があるか」だ。Microsoftのセキュリティ更新ガイドやIPA（独立行政法人情報処理推進機構）が公式にゼロデイ脆弱性であることを明記したパッチは、現実の攻撃対象だ。こうした脆弱性を含む更新は、通常より優先度を上げて適用を検討する必要がある。

　2つ目は「どの端末・システムからパッチを適用するか」という順序の基準だ。外部からアクセス可能なサーバや重要度の高い業務システムを優先し、社内端末は段階的に展開するという順序を事前に決めておくことで、再起動による業務停止のリスクを最小化できる。

　この2つの軸を組織として合意しておくことで、毎月の判断が「担当者の経験則」から「決まった基準に従った運用」に変わる。経営層や業務部門へも緊急度と展開順序の基準に従って説明できる。

「誰が何を決めるか」が決まっていないと対処は止まり続ける

　適用のタイミングと順序の基準を整備できても、承認や実施の段階で止まる組織もある。

パッチ適用が進まない本当の理由

　「いつ当てるか」の基準があっても、実際に適用を進めようとすると別の壁にぶつかる場合がある。再起動が必要な場面で業務部門から「今は止めないでほしい」と言われる、スケジュールの調整が長引いて適用が遅れる、といった状況だ。

　Windowsのパッチ適用には再起動を伴うことが多い。対象となるシステムや端末によっては、適用対象の洗い出し、業務影響の確認、実施スケジュールの調整、関係部門への説明と承認の取得という一連の作業が発生する。これは、責任とともに突発作業として情シスに押し付けられる形になりやすい。

　この問題の核心は、「緊急度ごとに誰が承認するか」「どの条件のときにシステムや端末を止めてよいか」が事前に合意されていないことだ。基準がないため、適用のたびに情シスが技術的な説明と業務調整の両方をこなす必要が生じる。

「決まった基準に従って動く」立場に変わる

　この状況を変えるには、パッチ適用を突発作業ではなく「計画された運用プロセス」として設計することが必要だ。

　具体的には、「いつ当てるか」「どの順番で」という基準に加えて、「誰が承認するか」「業務部門へはいつ通知するか」をセットで合意しておく。「ゼロデイが含まれる緊急時は情シスの判断で即時展開できる」「通常の月例適用は○日前に業務部門へ通知して承認を得る」といった形だ。この合意があれば、情シスは「都度説明を求められる役割」ではなく「決まった手順で動く役割」として機能できる。

「判断できる体制がある」と説明できることが情シスの仕事

　Windows環境における脆弱性管理の実務ベースでの理想は、脆弱性の件数をゼロにすることではない。変化し続けるIT環境の中で、適用のタイミングと順序を判断し、「誰が何を決めるか」が明確な体制を持ち続けることにある。

　最初の一歩として取り組めるのは、「今、誰がどの判断をしているのか」「その判断の根拠は何か」を書き出すことだ。判断が特定の担当者に集中しているところが、対処が止まりやすい場所であることが多い。そこに「この条件のときはこう動く」という基準を定め、業務部門と合意することが、仕組みとして進めていくための出発点になる。