Windows Update の社内運用ルールの作り方

火曜日の午後、経理担当のパソコンが突然再起動を始めた。画面には「更新プログラムを構成しています。電源を切らないでください」の文字。月末の振込データを入力している最中だったが、保存する間もなかった。10分後、パソコンは何事もなかったかのように立ち上がったが、直前まで入力していたデータは一部消えてしまっていた。

こうした光景に心当たりがある方は少なくないはずです。Windows Updateは、各パソコンの自動更新機能に任せておけば「勝手に」適用されます。しかしその「勝手に」が曲者です。業務時間中に予告なく再起動が走る、あるいは逆に、自動更新が滞って何ヶ月も古いパッチのままのパソコンが放置されている。どちらも、担当者が明示的なルールを持たずに各PCの初期設定へ丸投げしていることが根本原因です。

この記事は、ひとり情シスや総務・経理と兼任でシステム管理を担っている方に向けて、Windows Updateを「各PC任せ」から「社内でコントロールする運用」へ切り替えるための考え方と、具体的なルールの作り方を解説します。WSUSやIntuneといった管理ツールの名前を聞いたことはあっても、自社にそこまで大掛かりな仕組みが必要なのか判断できない、という方を主な読者として想定しています。専門用語は都度言い換えながら、無理のない範囲で始められる運用ルールの作り方を順に整理します。

この記事で分かること

Windows Updateを個々のパソコン任せにすることのリスク、社内で運用ルールを作る際に検討すべき論点、そして実際にルールを設計する手順を解説します。WSUS・Intuneなど管理ツールの使い分けにも触れますが、専用インフラを持たない小規模な会社でもすぐに着手できる、グループポリシーや設定変更だけで実現できる範囲の対策を中心に扱います。

結論を先に言うと、Windows Update運用ルールの設計は次の3つの柱で構成されます。

• タイミングの制御: いつ更新を適用し、いつ再起動してよいかを会社として決める
• 段階的な展開: 全PCに一斉適用するのではなく、少数のPCで様子を見てから展開する仕組みを作る
• 状態の可視化: どのPCがいつ更新されたか、更新が止まっていないかを把握できるようにする

この3つは、大企業向けの大掛かりなシステムがなくても、Windowsの標準機能とグループポリシー、あるいは無料〜低コストのクラウドサービスの範囲で実現できます。順を追って見ていきましょう。

なぜ「各PC任せ」のWindows Updateは危険なのか

結論から言うと、各PCの自動更新に任せる運用は「更新されすぎる」リスクと「更新されなさすぎる」リスクの両方を同時に抱えています。一見矛盾するようですが、これは同じ根本原因、つまり「会社としての方針がない」ことから生じています。

更新されすぎるリスク(業務中の予期しない再起動)

Windowsの自動更新は、既定の設定では「アクティブ時間」という、そのPCが使われている時間帯を自動的に学習し、その時間帯を避けてインストール・再起動を試みる仕組みが組み込まれています。しかし、この学習は完璧ではなく、特に不規則な勤務時間のPCや、共有端末では意図しないタイミングで再起動が走ることがあります。作業中のファイルが失われる、接客中に端末が固まる、といったトラブルは、この「会社側で制御していない自動更新」が原因であることがほとんどです。

更新されなさすぎるリスク(パッチ未適用の放置)

逆に、通知を毎回「あとで」と先送りし続けているうちに、気づけば数ヶ月分の更新が溜まっている、というケースも珍しくありません。パッチマネジメントが機能していない状態では、既知の脆弱性がそのまま放置され、攻撃者に狙われやすい状態が続くことになります。特に社外に持ち出すノートPCや、VPN経由でしか繋がらない端末は、社内ネットワークに常時接続されているPCと違って更新のタイミングを把握しづらく、放置されがちです。

IPA(情報処理推進機構)は「情報セキュリティ10大脅威」で、修正プログラム未適用の状態が攻撃の糸口になりやすいことを継続的に注意喚起しています。パッチ適用の遅れは、既知の脆弱性という「すでに公開されている攻撃の手がかり」を放置し続けることに等しく、新種の攻撃を警戒するより先に対処すべき基本的なリスクです。

この2つのリスクは、実は表裏一体です。「いつ更新されるか会社としてコントロールしていない」という同じ状態が、あるPCでは望まないタイミングでの再起動を引き起こし、別のPCでは更新の先送りを許してしまいます。運用ルールを作るということは、この「コントロールされていない状態」に、会社としての意思を通すことを意味します。

Windows Updateの仕組みをおさらいする

結論から言うと、Windows Updateには大きく分けて「品質更新プログラム」と「機能更新プログラム」の2種類があり、それぞれ性質もリスクも異なります。運用ルールを設計する前に、この違いを押さえておくと判断がしやすくなります。

Windows 10・11では、既定でMicrosoftの「一般提供チャネル」から自動的に更新プログラムが配信されます。何も設定していないPCは、この既定の挙動に完全に委ねられている状態です。Microsoft Learnの解説によれば、自動更新を無効にしていない場合、PCは「アクティブ時間」などの組み込みの仕組みを使って、ユーザーにとって都合の良いタイミングでダウンロード・インストール・再起動を試みるとされています。ただし、この「都合の良いタイミング」の判定はあくまでOSの推測であり、会社としての業務スケジュール(月末の締め処理、繁忙期など)までは考慮してくれません。

ここで重要なのが、品質更新プログラムと機能更新プログラムでは「会社としてどこまで待たせてよいか」の目安が異なるという点です。Microsoft Learnの案内では、Windows Update クライアント ポリシー(旧称 Windows Update for Business)を使うと、品質更新プログラムは最大30日、機能更新プログラムは最大365日まで、それぞれ適用を遅らせる(延期する)設定が可能とされています。品質更新プログラムはセキュリティに直結するため延期は最小限にとどめ、機能更新プログラムは互換性検証の時間を確保するために意図的に遅らせる、という使い分けが基本になります。

運用ルールがない会社で実際に起きていること

ここまでの背景を踏まえて、運用ルールが存在しない中小企業でよく見られる状態を整理します。次のいずれかに心当たりがあれば、この記事で扱うルール整備の対象と考えてよいでしょう。

• 各PCの「更新を7日間延期する」ボタンを従業員が個々に押しており、気づけば数ヶ月放置されているPCがある
• 逆に、業務時間中に再起動が走り、保存前のファイルが失われるトラブルが年に数回発生している
• どのPCがいつ最終更新されたか、担当者が一覧で把握できていない
• 新しい機能更新プログラムが適用された直後、特定の業務アプリが正常に動かなくなった経験がある
• 更新関連のトラブルが起きるたびに、その都度個別対応しており、再発防止のルールが存在しない

こうした状態は、担当者の怠慢というよりも、「そもそもWindows Updateは各PCの設定に任せるもの」という思い込みから生じています。実際には、後述するグループポリシーや管理ツールを使えば、会社として更新のタイミングをコントロールすることが可能です。まずはこの前提を切り替えることが、ルール作りの出発点になります。

運用ルール設計のための3つの選択肢

結論から言うと、Windows Updateを社内でコントロールする方法には、大きく3つの選択肢があります。会社の規模やIT予算に応じて、現実的な選択肢を選ぶ必要があります。

選択肢1: グループポリシーによる個別設定(追加コストなし)

Active Directory環境(社内にドメインコントローラーがある構成)であれば、追加のツールを導入しなくても、グループポリシーの設定だけでWindows Updateの挙動をある程度コントロールできます。具体的には、次のような項目を設定可能です。

• 自動更新の動作(自動ダウンロード+インストール前に通知、など)
• 再起動が許可される「アクティブ時間帯」の範囲
• 品質更新プログラム・機能更新プログラムそれぞれの延期日数
• 更新の一時停止(問題が起きた際に、最大35日間、配信を止める)

Microsoft Learnの案内によれば、これらの設定はいずれも「コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > Windows Update」以下のポリシーから行えます。ドメイン環境さえあれば、新たなライセンス費用をかけずに着手できる点が最大の利点です。

選択肢2: WSUS(Windows Server Update Services)による集中管理

オンプレミスでWindows Serverを運用している場合、WSUSというサーバーの役割を使うと、更新プログラムを一度社内のWSUSサーバーにダウンロードし、そこから各PCへ配信・管理する構成が組めます。Microsoft Learnでは、WSUSは「組織内のWindows更新プログラムに関する単一のハブ」であり、更新プログラムを選択的に承認し、配信時期を選び、対象デバイスを決められる仕組みと説明されています。

ただし、重要な注意点があります。Microsoft LearnはWSUSについて「非推奨となり、新機能は追加されなくなった」と明記しています。既存の運用環境では引き続きサポートされ、セキュリティ・品質の更新プログラムも製品ライフサイクルに従って受け取れるとされていますが、今後の新規構築先としては、Microsoftはクラウドベースの仕組みへの移行を志向している点を理解しておく必要があります。すでにWSUSを運用している会社が今すぐ移行を迫られるわけではありませんが、新規にサーバーを立てて導入するかどうかは、慎重に検討したほうがよい局面に来ています。

選択肢3: Intune(クラウドベースの管理)

Microsoft Intuneを使うと、社内にサーバーを構築することなく、クラウド経由でWindows Updateを管理できます。Microsoft Learnによれば、Intuneは「更新リング」という仕組みを使い、遅延期間・期限・再起動の動作・ユーザー体験の設定をデバイスのグループごとに適用し、段階的な展開(ロールアウト)を実現するとされています。

どの選択肢を取るべきかは、後述する「自社の状況を診断するチェック」で整理します。結論を先取りすると、社内にドメイン環境がありリモートワークが少ない会社はグループポリシーから始め、リモートワーク端末が多い、あるいは今後クラウド移行を進めたい会社はIntuneを軸に検討する、という住み分けが現実的です。

自社に合った選択肢を選ぶためのチェック

運用ルールを設計する前に、自社の環境を次の観点で確認してください。

1. Active Directory(社内ドメイン)を運用しているか: していなければ、グループポリシーでの一括制御はできません。個々のPCのローカル設定、またはIntune等のクラウド管理が現実的な選択肢になります
2. 社外で働く従業員のPCがどれくらいあるか: リモートワークやノートPCの持ち出しが多い会社ほど、社内ネットワーク前提のWSUSやグループポリシーだけでは対応しきれません
3. Windows Serverを既に運用しているか: 既にサーバーがあり、保守できる体制があるならWSUSの追加は比較的低コストです。ゼロからサーバーを構築する場合は、非推奨であることを踏まえて別の選択肢を優先的に検討すべきです
4. Microsoft 365やIntuneのライセンスを既に契約しているか: 契約プランによってはIntuneが利用可能な場合があります。追加費用の要否は契約中のプラン内容によって異なるため、契約先の代理店やMicrosoftのライセンス窓口に確認してください

このチェックの結果、いずれの管理基盤も持たない小規模な会社であれば、いきなり大きな投資をする前に、まずは各PCのローカル設定(グループポリシーエディターまたは設定アプリ)でできる範囲のルール運用から始めることをおすすめします。次のセクションでは、その前提で運用ルールの中身を具体的に設計していきます。

運用ルールに盛り込むべき5つの項目

結論から言うと、Windows Update運用ルールは次の5項目を文書化するだけで、多くの会社にとって十分に機能します。細かく作り込みすぎず、まずはこの5項目を埋めることを目標にしてください。

項目1: 更新の適用タイミング

品質更新プログラム(月例のセキュリティパッチ)をいつまでに適用するかを決めます。前述のとおり、Microsoftは最大30日までの延期設定を許容していますが、これは「延期してよい上限」であって「推奨される延期期間」ではありません。セキュリティを重視するなら、社内での検証期間を1〜2週間程度に絞り、それ以降は速やかに全PCへ適用する、という方針が現実的な落としどころです。

機能更新プログラムは、業務アプリとの互換性トラブルのリスクがあるため、リリース直後に飛びつく必要はありません。年1回のペースで来ることを踏まえ、「リリースから2〜3ヶ月は様子を見てから展開する」といった、ある程度余裕を持ったルールにすることをおすすめします。

項目2: 再起動を許可する時間帯

業務時間中の予期しない再起動を防ぐには、「アクティブ時間帯」を会社として明示的に設定することが有効です。Microsoft Learnの案内では、この設定によってユーザーが設定できるアクティブ時間の最大範囲を管理者側で指定できるとされています。

実務上のルールとしては、次のようなシンプルな指定で十分機能します。

例: 「平日9:00〜19:00をアクティブ時間として設定し、この時間帯には自動再起動を行わない。更新の適用・再起動は、業務終了後の19:00以降、または始業前に自動実行されるようスケジュールする」

シフト制など、部署によって稼働時間が異なる場合は、部署ごとに異なるアクティブ時間の設定が必要になることもあります。全社一律のルールが難しい場合は、部署単位でグループを分け、それぞれに合わせた時間帯を設定してください。

項目3: 段階的な展開の順序(展開リング)

いきなり全PCに新しい更新プログラムを適用するのは、思わぬ不具合が全社に一斉に波及するリスクを伴います。Microsoft LearnがWSUSやIntuneの解説で紹介している「展開リング」という考え方は、企業規模を問わず参考になる発想です。少数の検証用PCから始め、問題がなければ段階的に対象を広げていく、という順序を明文化しておきます。

中小企業であれば、大掛かりな仕組みを組まなくても、次のような簡易版で十分機能します。

この順序を踏むことで、仮に特定の更新プログラムが業務アプリと相性が悪かった場合でも、被害を1〜2台の検証機にとどめることができます。

項目4: トラブル発生時の切り戻し手順

更新プログラムの適用後に業務アプリが動かなくなった、パソコンが不安定になったといったトラブルが起きた場合の対応手順も、あらかじめ決めておく必要があります。Windowsには、特定の更新プログラムのインストールを一時的に止める「更新の一時停止」機能があり、Microsoft Learnによれば最大35日間、更新プログラムの配信を一時停止できるとされています。

切り戻し手順の最低限の項目は次のとおりです。

• 問題が起きたPC・部署を特定し、被害の範囲を確認する
• 該当の更新プログラムの配信を一時停止する(グループポリシーまたはIntuneの設定から)
• 個別のPCで問題が起きている場合は、更新プログラムのアンインストールを検討する
• 原因が特定できるまで、第3段階(全展開)への移行を保留する

この手順があらかじめ決まっているかどうかで、トラブル発生時の対応スピードが大きく変わります。

項目5: 状態の記録・可視化

最後に、どのPCがいつ更新されたか、更新が滞っているPCがないかを、担当者が一覧で確認できる状態を作ります。専用の管理ツールがなくても、最低限、次のような簡易的な記録で構いません。

• PC名(または利用者名)、最終更新日、OSバージョンを一覧化したExcelシート
• 月1回程度、各PCの「設定 > Windows Update」画面を目視で確認し、記録を更新する
• 3ヶ月以上更新が確認できないPCがあれば、個別に連絡して確認する

この記録は、社内のシステム管理台帳と合わせて管理すると、システム全体の状態把握が一本化でき、運用の手間も減らせます。

運用ルールの文書化サンプル

ここまでの5項目を、実際の社内ルールとして文書化する際のサンプルを示します。自社の状況に合わせて数字や表現を調整して使ってください。

Windows Update運用ルール(サンプル)

>

1. 品質更新プログラム(月例パッチ)は、公開後2週間以内に全PCへ適用を完了する

2. 機能更新プログラムは、公開後2〜3ヶ月の検証期間を経てから展開する

3. 自動更新による再起動は、平日19:00〜翌9:00の間にのみ許可する

4. 更新プログラムの展開は、情シス担当機→部署代表者→全社の順に、各段階で最低3営業日の様子見期間を置いて進める

5. 展開後に業務アプリの不具合が確認された場合、該当更新プログラムの配信を一時停止し、原因を確認してから展開を再開する

6. 各PCの最終更新日は、月次でシステム管理台帳に記録する

この程度の分量であれば、A4用紙1枚に収まります。最初から完璧な規程集を作ろうとせず、まずはこの粒度で運用を始め、実際に運用しながら不都合があれば見直す、という進め方をおすすめします。

サーバーOSと業務PCで運用ルールを分ける

運用ルールを設計する際、業務用のデスクトップ・ノートPCと、社内で稼働しているサーバーとでは、扱いを分けて考える必要があります。サーバーは複数の業務が同居していることが多く、再起動のタイミングを誤ると影響範囲が一気に広がるためです。

• 業務PC: 前述の展開リングに沿って、比較的短いサイクル(数日〜2週間)で更新を進める
• サーバー: 業務時間外・休日など、影響が最小になる時間帯を選び、単独で計画的に更新する。可能であれば、更新前にバックアップを取得してから作業する

なお、サーバーのOS自体がすでにEOL（サポート終了）を迎えている場合は、月次のパッチ運用以前の問題として、OSの延命・移行・廃止という別の判断が必要になります。この論点は別記事で詳しく扱っているため、該当する場合はそちらもあわせて確認してください。

経営層・従業員への説明で気をつけたいこと

運用ルールを作っても、従業員の協力が得られなければ機能しません。特に、更新のために一時的にPCを使えなくすることへの理解を得る必要があります。

説明の際に押さえておきたいポイントは次のとおりです。

• 「なぜ今のやり方ではダメなのか」を具体的に伝える: 「セキュリティのため」という抽象的な説明だけでなく、「更新が止まっているPCが攻撃の入り口になり得る」「予告なしの再起動でデータが失われた事例がある」など、具体的なリスクを示す
• 業務への影響を最小化する工夫を見せる: アクティブ時間帯の設定や段階的展開など、「会社側も業務を止めないように配慮している」ことが伝わると、協力を得やすくなります
• 例外対応の窓口を用意する: 「どうしてもこの日は再起動されると困る」という個別事情に対応できる相談先を明示しておくと、ルールへの抵抗感が下がります

経営層への説明では、稟議のような正式な決裁が必要な場合、コストのかからないグループポリシーでの運用から始め、実際に効果が出た段階で、Intune等への投資を検討する、という段階的な提案の仕方が受け入れられやすい傾向があります。いきなり大きな予算を求めるのではなく、「まずは無償の範囲でルールを整備し、その運用実績を見て次を判断したい」という進め方は、非エンジニアの経営層にも理解されやすい説明の型です。

保守委託先がいる場合の役割分担

システムの保守を外部の開発会社やITベンダーに委託している場合、Windows Updateの運用がどこまで委託範囲に含まれているかを確認しておく必要があります。保守契約の内容によっては、パッチ適用が対応範囲に含まれていない、あるいは別料金になっているケースもあります。

確認しておきたい項目は次のとおりです。

• 月例のセキュリティパッチ適用は、保守契約の範囲内か、都度課金か
• 更新プログラム適用後にトラブルが起きた場合、どこまで無償で対応してもらえるか
• 緊急度の高い脆弱性が公表された際、通常の月次サイクルを待たずに緊急適用してもらえるか

こうした対応範囲や緊急時の目安が契約書に明記されていない場合は、この機会に委託先へ確認しておくことをおすすめします。特に緊急時にどれくらいの時間で対応してもらえるかは、実際にトラブルが起きてから確認するのでは遅いため、平時のうちに合意を取っておく価値があります。

よくある失敗パターンとその回避策

Windows Update運用ルールの整備でつまずきやすいパターンを紹介します。

失敗パターン1: ルールを作って終わりにしてしまう

文書化した運用ルールが、実際の各PCの設定に反映されないまま「作っただけ」で終わってしまうケースです。ルールを作ったら、必ずグループポリギーやIntuneの実際の設定にまで落とし込み、設定が意図どおりに反映されているかをテスト用のPCで確認するところまでを一連の作業として扱ってください。

失敗パターン2: 検証期間を設けずに一斉適用してしまう

「面倒だから全部一度に」という発想で、展開リングの段階を飛ばして全PCに一斉適用してしまうと、業務アプリとの相性問題が起きた際、被害が全社に及びます。多少手間が増えても、段階的な展開の順序は省略しないことをおすすめします。

失敗パターン3: 例外PCの存在を忘れる

生産設備の制御用PC、特定の古いソフトでしか動かない専用端末など、通常の更新サイクルに乗せると業務に支障が出るPCが、会社によっては存在します。こうした例外PCを事前にリストアップし、通常のルールとは別の扱い(手動での個別確認、更新を長期間停止するなど)を決めておく必要があります。

失敗パターン4: サーバーと業務PCを同じルールで扱う

前述のとおり、サーバーは影響範囲が広いため、業務PCと同じ感覚で更新を適用すると、思わぬ範囲まで影響が及ぶことがあります。ルールを設計する際は、必ず対象を分けて考えてください。

今日からできる最初の一歩

ここまで解説してきた内容を、いきなりすべて実施する必要はありません。まずは次の3つから着手することをおすすめします。

1. 社内のPC台数と、それぞれの最終更新日をざっと確認し、更新が長期間止まっているPCがないかを把握する
2. Active Directory環境がある場合は、アクティブ時間帯の設定だけでも先に有効にし、業務中の予期しない再起動を防ぐ
3. この記事のサンプルを参考に、A4用紙1枚程度の簡易な運用ルールを文書化し、まずは自分の理解を整理する

完璧な運用体制をいきなり構築する必要はありません。「各PC任せ」から「会社としてコントロールしている」状態へ、少しずつ切り替えていくことが、この記事全体を通じたゴールです。

次に読むべき記事

サーバーOS自体がサポート終了(EOL)を迎えている、あるいは近く迎える場合は、『Windows Server のサポート終了（EOL）対応の進め方』を先に読み、延命・移行・廃止の判断を優先して検討することをおすすめします。

また、Windows Update以外の観点も含めた総合的なセキュリティ対策の初動を知りたい方は『ランサムウェア対策は何から始めるか』を、社用スマートフォン・タブレットの更新管理も含めた端末管理全般については『社用スマホの管理（MDM）入門』をあわせてご覧ください。システム全体の状態を一覧管理する台帳の作り方は『属人化を防ぐ社内システム管理台帳の作り方』で詳しく解説しています。