Windows更新を止めた端末がある。業務アプリの検証と例外期限

Windows更新が停止している可能性がある端末がある場合の業務アプリ検証と例外期限の設定手順この記事は2026年10月21日に確認できた公式情報を起点に、本稿では、JPCERT/CC が 2026 年 10 月 21 日に公表した脆弱性情報を踏まえ、Windows 更新が停止している可能性がある端末に対して業務アプリの動作確認や例外期限の設定を行う際の一般的な確認手順を整理します。

自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

更新停止端末の業務影響確認手順

対象端末リストの抽出方法

対象端末の一覧は、会社の台帳、管理担当の情報、実際の利用状況を照合して作ります。更新対象の製品が入っているか、現在稼働しているか、利用している業務は何かを分けて確認します。

取得できる情報や一覧にできる形式は、管理方法によって異なります。専用の画面や書き出し機能があると決めず、担当者へ確認してください。記録が届かない端末や、別の管理経路にある端末は、対象外へまとめず未確認として追跡します。

抽出作業の際に注意すべき点は、資産情報が最新であることを事前に確認することです。資産管理ツールが同期遅延している場合、実際には更新済みでもリストに残ってしまうリスクがあります。そのため、抽出直前にツールの同期ステータスをチェックし、必要に応じて手動でデータをリフレッシュします。

最終的に作成したリストは、担当者がレビューし、承認フローに回す前に必ずバックアップを取っておくことが推奨されます。

業務アプリ動作検証項目

更新停止端末に対しては、業務アプリが正常に動作するかどうかを体系的に検証します。検証担当はまず、対象アプリの主要機能を洗い出し、機能ごとにテストケースを作成します。たとえば、入力画面の表示、データ保存、レポート出力といったシナリオを順に実行し、期待結果と実測結果を比較します。

加えて、パフォーマンス測定として応答時間や CPU 使用率をモニタリングし、更新が無いことによる遅延が顕在化していないか確認します。

検証中にエラーが発生した場合は、直ちにログ取得を行います。Windows のイベントビューアやアプリ固有のログファイルを対象端末から収集し、エラーメッセージやスタックトレースを保存します。取得したログは、後続の原因分析や提供元への問い合わせ資料として必須です。

検証結果は、合格・不合格の判定とともに、取得したログの保存場所、検証実施日時、担当者名を明記したレポートにまとめ、承認者へ提出します。

例外期限設定と承認フロー

例外を認める場合は、期限と承認プロセスを明確に定義します。管理者はまず、例外対象端末ごとに「例外期限（例：2026年12月31日まで）」を設定し、期限が近づいた際に自動通知が届くようにスケジューラを構成します。承認フローは、部門長 → 情報セキュリティ責任者 → 経営層の順で署名を取得する二段階承認とし、承認記録は文書管理システムに保存します。

更新できない端末は、影響する業務、確認している問題、代替の方法、検証を行う担当を整理します。例外の期限だけを記入しても、その間に何を進めるかが分からなければ、未対応が続いてしまいます。

期限や了承する相手は、業務への影響と未対応のリスクを踏まえて自社で決めます。新しい注意情報が出たときや、業務アプリの対応が進んだときは、予定した日を待たずに見直す必要があるかを確認します。例外の終了と、実際の更新完了も分けて追跡してください。

例外適用後の監視と評価基準

リアルタイム監視項目の選定

例外端末に対しては、通常の監視対象とは別にカスタムルールを設定します。監視担当はまず、更新が適用されていないことによるリスクを洗い出し、対象となる指標を選定します。具体的には、ネットワークトラフィックの異常増加、プロセスの不正起動、OS の脆弱性スキャン結果の変化などが挙げられます。

これらの指標を SIEM やエンドポイント検知ツールに登録し、例外端末だけを対象としたアラート条件を作成します。

設定したルールは、テスト環境でシミュレーションを行い、誤検知率が低くなるようチューニングします。アラートが発生した際は、担当者が即座に対象端末のログを取得し、異常の有無を確認します。監視結果は、日次レポートにまとめて上長へ報告し、必要に応じて例外期間の延長や早期更新の判断材料とします。

評価指標と合格基準の定義

例外適用の効果を客観的に判断するためには、まずどのような指標で評価するかを担当者とすり合わせる必要があります。指標は、システムの稼働状況やエラーの発生頻度といった運用実績に基づくものが一般的ですが、具体的な数値や合格ラインは、実際に取得できるデータや業務上の許容範囲を踏まえて決めるべきです。

事前に指標や基準を固定してしまうと、取得できる情報と合致しない場合に評価が不適切になる恐れがあります。

担当者に確認すべきポイントは次のとおりです。

1. 例外適用後に取得できる運用データは何か、どのような形で記録されているか。
2. そのデータをもとに、どの項目を評価指標として設定すべきか。
3. 評価指標に対して、現実的に設定できる基準はどの程度か（例：過去の実績や業務上の許容範囲）。
4. 基準を満たさない場合の対応フローはどのようにするか、再評価のタイミングや手順は誰が担当するか。

これらの質問を通じて、指標と基準が実際の運用状況に合致しているかを確認し、評価結果が適切に判断できるようにします。数字や画面操作に関する具体的な指示は避け、担当者から得られる情報をもとに柔軟に評価基準を設定することが重要です。

評価は、月次で実施し、結果を評価シートに記録します。合格ラインを満たした端末は例外ステータスを維持し、未達成の場合は即座に更新適用計画を立案します。評価プロセスは、担当者、評価日、指標数値、判定結果を明示した文書として保存し、内部監査時に提示できるようにしておきます。

期限切れ時の自動ロールバック手順

例外の期限が来た場合は、更新できない理由が解消したかを管理担当と確認し、次の対応を責任者が判断します。自動で更新や元の状態への復元を行うことを一律に指示するものではありません。運用担当は、期限管理スクリプトを作成し、期限切れ端末を検出したら以下の手順を自動実行します。

①対象端末へリモート接続、②未適用の更新プログラムをダウンロード、③インストール実行、④再起動が必要な場合は自動再起動、⑤完了ステータスを取得してレポートに記録します。

ロールバック手順は、事前にテスト環境で検証し、失敗時のフォールバック策（例：復元ポイントからの復元）もスクリプトに組み込んでおきます。実行後は、検収チェックリストを用いて、更新適用の成功、再起動の完了、エラーログの有無を確認します。チェックリストは、担当者名、実施日時、結果判定を記入し、文書管理システムに保存することで、後続の監査や報告に備えます。

例外適用の文書化と法的留意点

例外適用記録の必須項目

例外の記録には、対象となる端末と業務、更新できない理由、判断した責任者、次の確認と担当を残します。端末の所有者が変わった場合や、利用するアプリが変わった場合も、判断を見直せるようにしておきます。

保存の形式や期間は、自社の運用ルールに合わせて決めます。更新できないことを公に示すための資料ではなく、関係する担当者が対応を進めるための記録です。必要な人に限定して共有し、理由なく管理用の情報を広く公開しないようにします。

内部監査向けチェックリスト

内部監査では、例外手続きが規程通りに実施されたかを点検します。チェックリストの項目例として、①例外適用記録が全端末分揃っているか、②記録に期限と承認者情報が欠落していないか、③例外設定の根拠が技術的評価資料と合致しているか、④例外期間中の監視ログが保存されているか、⑤期限切れ後に自動ロールバックが実行された証跡があるか、を挙げます。

監査担当は、実際の文書とシステムログを突き合わせ、抜け漏れが見つかった場合は是正指示を出します。特に、承認プロセスが口頭のみで残っていないケースは、後々の責任所在が不明確になるため、必ず文書化を徹底させることが重要です。

法的義務との整合性確認

法務担当は、業界ごとの情報セキュリティ基準や個人情報保護法等の規制と例外措置の整合性を評価します。まず、対象アプリが扱うデータの機密性を分類し、更新停止がリスク評価にどの程度影響するかをリスクマトリックスで可視化します。

次に、規制上のパッチ適用義務が「合理的な期間内の適用」と定義されている場合、例外期限がその期間を超えていないかを確認します。必要に応じて、例外理由を文書に添付し、リスク低減策（例えば、ネットワーク分離や追加の監視ルール）を併記すれば、法的リスクを最小化できます。

最終的に、法務部は承認完了の了承を行い、例外適用記録に法的評価結果を付記して保存します。

例外解除後の最終検収プロセス

更新適用確認の自動化スクリプト

例外解除後に端末へ更新が正しく適用されたかどうかを確認する作業は、実際にどのような手順で行われているかを担当者に確認する必要があります。自動的にインストール状況を判定し、結果を一覧にまとめるという考え方は有効ですが、使用しているツールやコマンド、出力形式については公式の手順や社内の運用方針に沿っているかどうかを確認しなければなりません。

たとえば、インストール済みかどうかを判断する根拠となるログや情報がどこに保管されているか、またそれらを抽出する際に必要な権限や手順は何かを担当者に尋ねることが重要です。

さらに、インストールに失敗した端末に対して再度適用を試みる際の回数や条件、再適用後に残るエラーへの対応方法についても、社内の方針や過去の事例を踏まえて確認すべきです。

具体的には、再試行の上限はどの程度設定すべきか、再試行が失敗した場合にどの担当がどのような手順で手動対応に移行するか、そしてその際に必要な情報や報告の形式は何かを担当者に質問してください。これらの確認を行うことで、手順が曖昧なまま自動化に依存することを防ぎ、実際の検証作業が抜け漏れなく実施できるかどうかを判断できます。

再起動待ち状態の検出と対処

更新を適用した端末で再起動が必要かどうかを判断する際は、まず担当の運用担当者に現在の再起動保留の有無を確認してください。その際に必要なのは、再起動が保留されている端末の一覧がどのように管理されているか、またその一覧が最新であるかという点です。運用チームが保有している情報の取得方法や更新頻度を聞き取り、一覧が正確に把握できるかを確認することが重要です。

次に、再起動の実施タイミングについては、業務への影響を最小限に抑えるために、業務時間外に自動で行う方針があるかどうか、あるいは手動で実施する場合の手順や記録方法を担当者に確認してください。具体的には、再起動実施日時や実施者の記録がどのように残されているか、再起動後にシステムが正常に起動したことをどのように確認しているかを尋ねます。

もし再起動に失敗したりサービスが停止した場合の復旧手順が文書化されているか、またその手順が実際に機能するかどうかを確認することも必要です。

以上の質問を通じて、再起動が必要な端末の把握方法、実施タイミングと記録の取り方、そして障害時の復旧手順が確実に運用されているかを確認できます。これにより、更新適用後の環境が安定した状態で運用に戻るかどうかを判断する根拠が得られます。

検収完了報告書の作成指針

最終的な検収完了報告書は、プロジェクトリーダーが中心となって作成します。報告書の構成は、①対象端末一覧と例外適用期間、②更新適用結果（合格端末数・不合格端末数とその理由）、③再起動実施状況と残課題、④法務部の最終承認コメント、⑤次回パッチ適用計画と改善提案、の5 部に分けます。

各項目には、前章で作成した記録やスクリプト出力、監査チェックリストの結果を添付し、証拠として提示します。報告書は PDF で保存し、関係部門（情報システム部、法務部、監査部）へ回覧し、最終承認を得たら正式に保管します。これにより、例外解除プロセス全体が透明化され、将来の同様のケースに対する標準手順として活用できます。