経営層から「なんでパッチが当たっていない端末があるんだ。すぐに全台に当てろ」。そう言われて対応に困った経験はないでしょうか。そもそも適用状況がわからない、当てようと思っても自動更新が止まっている、さらに止められないから当てられない・対応してもらえないサーバ群もある。こうして経営層と実際の現場には大きなギャップが生まれます。
本稿は、元タニウム社 TAM として大企業の Tanium 運用とサイバーハイジーンに伴走してきた、私（ザッツイット株式会社 代表取締役 天野）の経験を元に、Windows / Linux のパッチ管理現場で繰り返し直面してきた課題と、Tanium を活用して今すぐ取り組める実践的な戦略を整理したものです。
「同じパッチ管理」という言葉でくくると見えなくなる、OS別の構造的な違いを整理します。
同じパッチ管理でも、OS が違えば課題も異なります。課題を整理することで、経営層と現場の温度差の本質が見えてきます。
並べてみるとシンプルな話に見えますが、現場で一つひとつ対処していくとなると思った以上に手間がかかります。
結果として「Linuxは後回し」「触らないが正解」というムードが組織に広がりがちです。
Tanium を入れると、パッチ管理まわりで次の 3 つが変わります。
どの端末に何が当たっていて、何が未適用なのかがわかります。さらに「再起動していない」「アップデートを止めている」「オフライン」「ストレージ不足」「サポート切れOS」など、なぜ適用できていないのかまで原因を調査できるので、是正の打ち手まで具体的に決められます。
「強制的に当てる」「再起動のタイミングをコントロールする」「ユーザー自身に好きなタイミングで当ててもらう」など、場面に合った当て方を使い分けられます。脆弱性スキャンの結果を起点に「優先順位の高いところから当てる」という動き方にも切り替えやすくなります。
月例パッチの条件指定での自動配信、配信リングでの段階展開、メンテナンスウィンドウ制御。これまで毎月手で回していた作業の多くを定型化できます。経営層 への月次報告も、パッチ適用率 や 平均適用日数 といった指標で語れるようになります。
このあと、Windows と Linux それぞれで、現場でありがちなシナリオに沿って具体的な戦略を紹介します。
Tanium を導入したからといって、必ずしも WSUS / Windows Update for Business（WUfB）といった既存の仕組みを廃止する必要はありません。Windowsのパッチ管理の戦略は、大きく次の 3 パターンに整理できます。
現在の WSUS や WUfB の運用に大きなトラブルがなく、まずは現状を補完するところから始めたい組織向けです。毎月のパッチ配信は WSUS / WUfB で継続しつつ、Tanium を「監査役」として併用します。レポートだけでは把握しきれない「本当に適用されたか」「適用に失敗し続けている端末はどこか」を、Tanium の高速な可視化機能で補完し、管理の死角をなくします。可視化だけならすぐに始められるので、最初の一歩としてもっとも入りやすいパターンです。
既存のパッチ管理システム（WSUS / WUfB など）を廃止し、Tanium でパッチ管理を一元化するパターンです。最大のメリットは、Tanium 独自の「リニアチェーン（Linear Chain）」技術を活用できる点。端末同士がファイルを共有し合うことで、WAN 回線やインターネット帯域への負荷を最小限に抑えながら、大規模環境へパッチを配信・適用できます。既存のパッチ管理インフラの運用負荷からも解放されるため、インフラコストの削減と管理ツールの統合を同時に実現したい場合に向いています。
平時は WSUS / WUfB でパッチを適用しつつ、適用漏れが発生した端末に対してだけ Tanium で配信するパターンです。「どうしても当たらない端末」に Tanium の配信力を使う現実的なアプローチで、多くの組織で採用されています。
ポイント：実案件で多く採用されているのは、パターン 1 とパターン 3 です。まずはパターン 1 で「本当に当たっているか」を可視化し、適用漏れ端末に Tanium 配信を組み合わせるパターン 3 へ段階的に拡張する流れが現実的です。
状況の説明
経営層にパッチ適用状況を聞かれても、WSUS のレポートでは即座に数字で答えにくい。各部門へのヒアリングで集計するのも時間がかかる。
Taniumを使った対策
ポイント：月例パッチや、一定以上の基準を満たすパッチは、あらかじめレポートを作成しておけば、経営層の急な確認にも対応できます。
状況の説明
第 2 火曜の月例パッチを、業務影響を抑えつつできるだけ早く適用したい。WSUS は端末が自分から取りに来ないと適用されない仕組みのため、適用漏れが構造的に発生しがち。適用状況の把握にも時間がかかり、個別対応でのフォローに頼らざるをえない。
Taniumを使った対策
ポイント：月例パッチなど毎月必ず適用するパッチは配信を自動化してしまうのが効果的かつ効率的です。未適用端末のフォロー手順もあらかじめ決めておきましょう。
状況の説明
開発端末、計測端末、検証用PC、役員端末など、業務都合で「今は再起動・適用してほしくない」端末は必ず存在します。製造サイクル間でしかパッチできない製造端末や、手術間でしかパッチできない手術室端末まで含めると、業界を問わず広く見られる課題です。
Taniumを使った対策
ポイント：ユーザー判断にする対象端末の定義、デッドラインを過ぎた場合の強制配信切替えルール、例外申請の承認フローを定めておきましょう。加えて、パッチ適用をやるべきこととして運用に組み込むことが大切です。
状況の説明
話題のゼロデイ脆弱性が公開され、経営層から「うちは大丈夫か。いつまでに当たるのか」と即問われる。この場面で即答できるかどうかは、平時の準備で決まります。
Taniumを使った対策
ポイント：緊急パッチの基準と対応手順（誰が判断し、いつまでに、どうやって当てるか）を平時に整理し、経営層も含めて合意しておきましょう。
Linuxでよくある課題で挙げたように、未適用パッチを片っ端から潰すという単純な話では片付けられません。
そこで重要になってくるのが、パッケージ（パッチ）起点ではなく、脆弱性起点で考えるというアプローチです。
状況の説明
Linux サーバーをスキャンしたら未適用パッチが数百件検出され、優先順位もつけられず手が止まっている。「Linux は後回し」が状態化している。
Taniumを使った対策
ポイント：脆弱性が検出されてから対応方針を決めるのではなく、あらかじめ各指標を参考に対応方針を決めておくことが迅速な対処につながり、攻撃によるリスクを下げることにつながります。
状況の説明
Linux のリポジトリは日々更新されるため、あるバージョンで検証していざ本番に適用しようとすると、検証時とは異なるバージョンが入ってしまうリスクがあります。
Taniumを使った対策
ポイント：月に 1 回メンテナンスウィンドウを確保しておくなど、パッチ適用を想定した運用設計が重要です。
パッチを当てる行為だけが、パッチ管理ではありません。経営層を巻き込んだガバナンス・ポリシーの整備、そしてパッチ適用を想定した運用設計の見直し。この 2 つの土台があってはじめて、パッチ管理は組織の活動として回り始めます。
そこに、パッチ適用状況を把握し、適用する仕組みが加わることで、健全な状態の継続的な維持につながり、経営層と現場のギャップが埋まります。本稿の戦略やケーススタディが、パッチ管理を円滑に進めるヒントになれば幸いです。自社だけで進めるのが難しい場合は、ぜひお気軽にご相談ください。
代表的なのは、長期オフラインや起動頻度が低くカタログ同期できていない端末、配信は届いたが再起動されずに完了していない端末、業務アプリ互換性を理由にユーザー側でアップデートを止めている端末、ストレージ不足や適用失敗で止まっている端末、例外運用が明文化されないまま放置されている端末などです。
WSUS は 2024 年 9 月に非推奨化が発表されており、新規機能の追加は止まっています。加えて、適用状況をリアルタイムに把握しづらい、未適用端末の原因（オフライン／再起動未実施／アップデート停止）を切り分ける仕組みがない、適用が遅れている端末に対して強制的に当てる仕組みがない、といった課題があり、これらを補う手段の必要性が高まっています。
Microsoft のソリューションで考える場合、更新プログラム配信の制御は Intune / GPO + Windows Update for Business（WUfB）が有力な選択肢になります。ただし、これらの組み合わせにはコンテンツのキャッシュ機能がありません。その点をカバーするのが Microsoft Connected Cache（MCC）です。加えて、Tanium のようなサードパーティツールによるパッチ配信にも注目が集まっています。
全台適用には技術面の課題とガバナンス・ポリシー面の課題があり、運用者だけで解決できるテーマではないということを、経営層にも理解してもらうことが大切です。特にガバナンス・ポリシー面は、経営層に提示できる判断材料（適用状況・リスク評価）と打ち手（適用の手段）を揃えたうえで、経営層を巻き込み、全社的な方向性と計画として進めるのが要です。
対象端末を別のコンピュータグループに切り出して強制配信から除外し、ユーザー任意で適用できるポータルを提供することで、適用タイミングをコントロールできるようにすることは可能です。ただし、適用しなくてよいというわけではないので、リスクを評価したうえで「いつまでに当てるか」「未適用のまま放置できるのはどこまでか」を組織としてのポリシーに落とし込んでおくことが大切です。
公開されてから対応を検討するのではなく、緊急パッチが公開されたらどう行動するかの方針を平時に決めておくことが大切です。あわせて、即座に動けるよう資産の把握と適用の手段（影響範囲のスキャン、緊急配信ルート、再起動制御）をいつでも使える状態にしておきましょう。
パッケージ起点ではなく脆弱性起点で考えるのが有力です。Tanium Comply などの脆弱性スキャンで該当 CVE を洗い出し、CVSS／KEV／EPSS などの指標で対応方針を判断します。あらかじめ指標に応じた組織の対応ルールを定めておくと、属人的な運用が避けられます。
