Windows Server 2016（1607）で長期間ほぼ未パッチの状態が続くと、Windows Update が「更新が見つからない」「すべて失敗する」、手動適用でも「この更新プログラムはお使いのコンピューターに適用できません」となることがあります。本記事では、OS ビルド 14393.3750 で発生しやすい更新不能トラブルを、ログの読み方から SFC/DISM、更新コンポーネントのリセット、修復インストール、最終的な再構築まで実務目線で整理します。
症状：Windows Server 2016 で更新が進まない典型パターン
今回のケースは、Windows Server 2016（バージョン 1607、OS ビルド 14393.3750、インストール日 2018/07/27、ほぼ未パッチ）で次のような現象が重なっている状態です。
- Windows Update を実行しても「更新プログラムが見つかりません」または更新がすべて失敗する
- Microsoft Update カタログ等から手動で更新（例：KB4132216 / KB4346087 / KB4457131 など）を適用しようとしても、「この更新プログラムはお使いのコンピューターに適用できません」と表示される
- Windows Update ログに 0x80240007 / 0x8024000C / 0x80248014 などが出る
- CBS.log で servicing stack の一致するバージョンが見つからない、servicing stack ディレクトリが見つからない、0x80070490（ERROR_NOT_FOUND）などが見える
最初に結論：SSU の前に「更新基盤の破損」を疑うべき
一般論として、Windows Server 2016 の更新は SSU（サービス スタック更新）→ CU/LCU（累積更新）の順で適用するのが定石です。しかし今回のように、SSU を含めて何を当てても「適用できません」になる場合、順番の問題ではなく、前提となるコンポーネント ストア（WinSxS）や servicing stack 周りの不整合・欠損で「適用対象かどうかを正しく判定できない」可能性が高いです。
この状況では「SSU を探して入れれば解決する」よりも、まず OS 側の整合性を回復させて“正常に更新できる土台”へ戻すのが近道です。
「適用対象外」と言われる代表的な原因
「この更新プログラムはお使いのコンピューターに適用できません」は、文字通り対象 OS ではないケースもありますが、現場では“壊れていて判定できない”ケースも多いメッセージです。まずは原因の当たりを付けます。
| 原因パターン | 起きやすい状況 | 確認ポイント | 優先アクション |
|---|---|---|---|
| コンポーネント ストア（WinSxS）の破損 | 長期未更新、障害復旧や強制電断、ディスク不良、ウイルス対策ソフトの誤検知など | CBS.log に 0x80070490 / ERROR_NOT_FOUND、パッケージやマニフェストが見つからない等 | SFC→DISM /RestoreHealth（必要ならソース指定） |
| servicing stack 周りの欠損・不整合 | 更新の途中中断、手動での削除/クリーンアップ、ストレージ障害 | CBS.log に「servicing stack の一致するバージョンが見つからない」「ディレクトリが見つからない」 | DISM で修復。改善しなければ修復インストール |
| 更新チャネルの問題（WSUS/ポリシー） | WSUS 参照設定が残っている、社内 WSUS が死んでいる、プロキシ/SSL 検査 | ポリシー/レジストリで WUServer、UseWUServer、プロキシ設定 | ポリシーを整理して Microsoft Update へ戻す、または WSUS を正常化 |
| 更新の種類が限定（例：Intel マイクロコード、特定機種向け） | CPU/機種/BIOS 条件に依存する更新を、汎用更新のつもりで当てた | KB の説明に「特定 CPU のみ」「特定環境のみ」などの条件がある | OS 更新（SSU/LCU）と切り分け、後回しでよい |
| アーキテクチャ/エディション違い | x86/x64 の取り違い、言語/エディションの取り違い | インストールメディアや MSU の種類、OS のエディション | 正しいパッケージを選び直す |
作業前に必ず取るべき情報（復旧の成功率が上がる）
修復系の作業は「やってみたが戻せない」が最も危険です。最低限、次の情報を控え、可能ならスナップショット/バックアップを取得してから進めます。
| 確認項目 | コマンド例 | 見たいポイント |
|---|---|---|
| OS バージョン/ビルド | winver systeminfo | Server 2016（1607）、Build 14393.x の確認 |
| インストール済み更新 | wmic qfe list brief /format:table powershell -command "Get-HotFix | sort InstalledOn" | 最後に入っている更新がいつか（未パッチ期間の目安） |
| コンポーネント ストアの状態 | dism /online /cleanup-image /scanhealth dism /online /cleanup-image /checkhealth | 「修復可能」「破損」などの判定が出るか |
| Windows Update の参照先 | reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s | WSUS 指定（WUServer）が残っていないか |
| 更新関連サービス | sc query wuauserv sc query bits sc query cryptsvc | 停止/無効化されていないか |
最優先：SFC と DISM で OS を修復する
CBS.log に servicing stack 由来の ERROR_NOT_FOUND が出る場合、ここが直らないと以降の更新適用はほぼ進みません。手順はシンプルですが、成功率を上げるコツがあります。
SFC（システムファイルチェッカー）
まずはシステムファイルの整合性を修復します。管理者権限のコマンドプロンプトで実行してください。
sfc /scannow完了後のメッセージが重要です。「破損ファイルを修復しました」なら次へ進み、「一部を修復できませんでした」の場合も DISM を続けます。
DISM（コンポーネント ストアの修復）
続いて DISM でコンポーネント ストアを修復します。
dism /online /cleanup-image /restorehealth| 状況 | よくある結果 | 次の手 |
|---|---|---|
| インターネットに出られる/Windows Update が生きている | 完了して「復元操作は正常に完了しました」 | Windows Update リセット→SSU/LCU 適用へ |
| 閉域/プロキシ制限で修復ソースに到達できない | 0x800f081f などで失敗（ソースが見つからない） | インストールメディアをソースにして再実行 |
| servicing stack ディレクトリ欠損など深刻 | 0x80070490、ERROR_NOT_FOUND が残る | 修復インストール（インプレース修復）を検討 |
DISM が失敗するときの現実的な解決策（ソース指定）
Windows Update 自体が壊れている環境では、DISM が修復ソースを取りに行けず失敗しがちです。Server 2016 の ISO（インストールメディア）を用意し、同じエディション/同系統のビルドをソースにして修復するのが実務的です。
install.wim / install.esd のインデックスを確認する
ISO をマウントしてドライブ文字（例：D:）を確認し、まずはイメージ情報を確認します。
dism /get-wiminfo /wimfile:D:\sources\install.wim出力されたインデックスから、インストール済みのエディションに合う番号を使います（例：Datacenter / Standard）。
ソース指定で RestoreHealth を実行する
dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:1 /limitaccess/limitaccess を付けると Windows Update に行かず、指定したソースのみで修復します。閉域環境や WU 壊れ気味のサーバーで特に有効です。
Windows Update の構成要素をリセットする
SFC/DISM で OS の整合性を整えたら、次に Windows Update のキャッシュや署名データを初期化します。SoftwareDistribution の再作成は実施済みでも、サービス停止→キャッシュ初期化→再起動→再検出まで通しで行うと改善することがあります。
リセット対象のサービス
| サービス名 | 表示名の例 | 役割 |
|---|---|---|
| wuauserv | Windows Update | 更新の検出/ダウンロード/インストールの中核 |
| BITS | Background Intelligent Transfer Service | バックグラウンド転送（更新のダウンロード） |
| cryptsvc | Cryptographic Services | 署名検証（catroot2） |
| msiserver | Windows Installer | 一部更新の適用で使用 |
代表的なリセット手順（バッチ例）
運用環境では内容を理解した上で実施してください。管理者権限のコマンドプロンプトで実行します。
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 catroot2.old
net start msiserver
net start cryptsvc
net start bits
net start wuauservリセット後は再起動し、Windows Update の再検出を行います。GUI 操作でも良いですが、環境によっては次のコマンドで検出が走ります。
wuauclt /resetauthorization /detectnowSSU → 最新の累積更新（LCU）の順で適用する
土台が直ったら、更新の王道パターンに戻します。Windows Server 2016（1607）は毎月の累積更新（LCU）で内容が置き換わるため、古い KB に固執するより、最新 SSU と最新 LCU を組み合わせて入れるほうが復旧しやすいです。
- まずは SSU（サービス スタック更新）を適用して再起動
- 次に LCU（累積更新）を適用して再起動
- 必要に応じて .NET の累積更新や Defender 定義更新などを追加
この段階でまだ「適用できません」が続く場合は、パッケージの取り違いよりも、更新判定の仕組み自体がまだ壊れている可能性が高いので、次章の「CBS ログの読み解き」と「修復インストール」を検討します。
CBS.log に servicing stack の欠損が出るときの見方
CBS.log は、更新が“なぜ適用できないのか”を最も正直に語るログです。特に次のキーワードが見える場合、単発の KB 追加では解決しにくい傾向があります。
- servicing stack の一致するバージョンが見つからない
- servicing stack ディレクトリが見つからない
- ERROR_NOT_FOUND（0x80070490）
この状態は、更新に必要なファイル群（パッケージ/マニフェスト/カタログ/コンポーネント）が欠けていることを示唆します。原因はディスク障害、強制電源断、ウイルス対策の隔離、過去のクリーンアップ失敗などさまざまです。
追加で確認したいチェックリスト
- ディスクの健全性：イベントログ（System）にディスク関連エラーがないか、可能ならベンダーツールで診断
- 空き容量：更新・修復には一時領域が必要（C ドライブの逼迫は失敗の定番）
- 時刻：大きくズレていると署名検証で詰むことがある
- サードパーティ AV/EDR：一時的に無効化できるか（更新関連フォルダを監視/隔離していないか）
エラーコード別：次に打つ手が分かる早見表
Windows Update 側のエラーコードは抽象的ですが、ログと組み合わせると指針になります。現場でよく当たる組み合わせを表にしました。
| エラーコード | どこで見える？ | 意味の方向性 | まず試すこと |
|---|---|---|---|
| 0x80240007 | Windows Update ログ | 更新エージェント側の処理異常（データ破損/状態不整合） | WU リセット、SFC/DISM |
| 0x8024000C | Windows Update ログ | データが無効、操作が不正など（キャッシュ破損で出やすい） | SoftwareDistribution/catroot2 再生成 |
| 0x80248014 | Windows Update ログ | 更新メタデータの参照に失敗（データベース不整合） | WU リセット→再検出、WSUS 設定確認 |
| 0x80070490 | CBS.log / DISM | 見つからない（パッケージ/マニフェスト欠損の可能性） | DISM /RestoreHealth（ソース指定）、修復インストール |
修復インストール（インプレース修復）で更新基盤を作り直す
SFC/DISM と WU リセットを丁寧にやっても改善しない場合、サーバーでも現実的な打ち手が修復インストール（インプレース修復）です。これは OS を“上書き”することで、欠損したコンポーネントを復旧し、更新の土台を再構築する方法です。
重要：サーバー用途では、実施前に必ずバックアップと検証計画を用意してください。役割（ロール）やドライバ、セキュリティ製品が絡むため、クライアント OS より慎重な手順が必要です。
実施のコツ（失敗しやすいポイントを潰す）
- インストールメディアは 同じ Windows Server 2016 / 同じ言語 / 同じエディションを用意する
- 十分な空き容量を確保し、可能なら一時ファイルの退避も行う
- サードパーティ製 AV/EDR は一時的に無効化できるか確認する
- 役割によってはメンテナンス時間を長めに取る（再起動が複数回入ることがある）
大まかな流れ
- ISO をマウントし、setup.exe を管理者として実行
- 更新のダウンロード選択（環境によりオフライン推奨）
- 「引き継ぐもの」で 個人用ファイルとアプリを引き継ぐ（可能な場合）を選択
- 完了後、SFC/DISM を再実行して状態確認
- SSU→LCU の順で更新を再開
最終手段：新規構築して役割を移行する（再構築）
CBS.log に servicing stack 欠損の痕跡が強く、修復インストールも難しい（または失敗する）場合、結局は再構築が最も確実になりがちです。特に「ほぼ未パッチ」で運用していたサーバーは、修復に時間をかけるより、新規に立て直したほうがトータルのリスクが低いこともあります。
| 判断基準 | 再構築を選ぶ理由 | 実務での進め方 |
|---|---|---|
| DISM がソース指定でも直らない | 更新基盤の欠損が深刻で、修復コストが読めない | 新規サーバーを構築し、最初にフルパッチを適用 |
| 更新のたびに別のエラーが出る | 部分的に壊れており、場当たり対応が増える | ロール/アプリを段階的に移行（並行稼働期間を確保） |
| 重要ロール（AD DS 等）で停止が許されない | 修復作業は不確実で停止時間が読みづらい | 追加サーバーとして参加→レプリケーション→切替 |
「更新が見つからない」を防ぐ運用のコツ
復旧できたとしても、同じ状態に戻さないための運用設計が重要です。特に Server 2016 のような長期運用 OS では、更新の空白期間が長いほど復旧難易度が上がります。
- 月次での更新習慣：少なくとも LCU は定期適用し、未更新期間を短くする
- 更新前のバックアップ：失敗時に戻せるルートがあると攻めた復旧ができる
- ディスク/ストレージ監視：WinSxS 破損はストレージ要因が隠れていることがある
- 定期的な健全性チェック：イベントログ、SFC/DISM の軽いチェックを保守に組み込む
よくある質問
「Server 2016（1607）の更新は途中から出なくなったのでは？」
「更新が見つからない」状態が続くと、更新提供自体が止まったように見えます。しかし実際には、更新検出の仕組み（Windows Update エージェント、コンポーネント ストア、WSUS 設定など）が壊れているだけ、というケースが多いです。まずは本記事の流れで更新基盤を正常化し、それでも更新が見えない場合に、ネットワーク/WSUS/ポリシー側の問題を疑うのが安全です。
「SSU を先に入れれば全部解決する？」
SSU は確かに重要ですが、SSU 自体が「適用できません」になる場合は、SSU 以前の段階（コンポーネント ストア/servicing stack）で破損している可能性が高いです。SFC→DISM→WU リセットで土台を作ってから SSU に戻るのが現実的です。
「KB4346087 のようなマイクロコード更新も入れないとダメ？」
マイクロコード更新は機種・CPU・BIOS など条件が限定されることがあり、OS の更新（SSU/LCU）とは切り分けて考えるのが安全です。まずは SSU/LCU を正常に回せる状態に戻すことを優先し、その後に必要性を評価しましょう。
「更新できないサーバーをそのまま放置してよい？」
セキュリティ更新が当たらない状態は、脆弱性リスクだけでなく、将来的な障害対応（証明書や署名の更新、アプリの依存関係）にも影響します。短期的に復旧できない場合でも、再構築や役割移行の計画を早めに立てるのが結果的に安全です。
コメント