https://error-daizenn.hatenablog.com/entry/2025/09/16/213630

2025年9月16日公開。2025年9月の累積更新プログラム「KB5065426」（Windows 11 24H2、OSビルド26100.6584）が一部環境で「インストールに失敗」や「更新が始まらない」といった不具合を引き起こしています。本稿は一般ユーザーから企業のシスアドまで、更新が適用できない・ネットワーク共有が壊れたなどの現象に直面した人が“いますぐ解決の糸口”を得るための実践ガイドです。当該更新は月例パッチ（Patch Tuesday〔毎月のセキュリティ更新〕）であり、重要な脆弱性修正を含む必須配信です。マイクロソフトサポート+1

発生概要：配信日・対象・ビルド

KB5065426は2025年9月9日に配信されたWindows 11 24H2向け累積更新で、適用後のOSビルドは26100.6584です。 配信は順次段階的に行われ、セキュリティ修正や品質改善（SSU〔Servicing Stack Update〕同梱）を含みます。企業や一般家庭を問わず、Windows Updateで自動的に検出・適用される設計です。マイクロソフトサポート

エラーコードの実態：何が表示されているか

報告の多いエラーは0x800F081F、0x800F0922、0x800F0991、0x80071A2D、0x80070302、0x80070306、0x8000FFFF、0x800700C1などで、同じPCでも再試行ごとに異なるコードが出る場合があります。 0x800F081Fは「必要なコンポーネントが見つからない/参照不可」を示す典型例で、ストア（component store）破損や前回更新の残骸が原因になりがちです。0x800F0922は更新サービスや接続の問題、回復パーティション不足が関与することがあります。実際にMicrosoft Q&Aやフォーラムでも同様の症状が相次いでいます。Windows Latest+2Microsoft Learn+2

影響範囲：“入らない”だけではない

一部では更新後にSMB/ファイル共有が使えない、資格情報が拒否され続ける、ネットワークプロファイルが勝手に「パブリック」化された等の報告が出ています。「System error 86」や「ユーザー名またはパスワードが正しくありません」の連続表示、共有へ到達しても認証で弾かれる現象が代表例です。小規模オフィスで複数台同時発生という報告もあります。これらは現時点で広範に一般化したとは言い切れませんが、24H2同士のピア共有で目立ちます。Microsoft Learn+3Windows Latest+3Microsoft Learn+3

公式対応状況：確認できること・未公表のこと

MicrosoftのサポートページにはBuild 26100.6584の改善点と既知事象（例：PSDirectの一部失敗）が掲載されていますが、SMB共有断の一般向け“既知の問題”としての明記は本稿執筆時点（2025年9月16日）では確認できません。一方で「24H2の既知/解決済み問題」ページは随時更新されるため、まず一次情報での動きを監視するのが安全です。マイクロソフトサポート+2Microsoft Learn+2

他ユーザーの声：現場の一次情報

失敗事例は複数の場で共有されており、現象の幅と手応えがつかめます。 たとえば「Install error – 0x800F081F」（インストールエラー0x800F081F）というQ&A投稿や、カタログからの単体インストールでも「インストールされませんでした」と完了するとの報告が見られます。Redditでも「資格情報を受け付けないのでKBをアンインストールしたら直った」との声が上がりました。引用します。
“Install error – 0x800f081f.”（Microsoft Q&A）Microsoft Learn
“refuses to accept the credentials… uninstalling the KB… got right back into the share.”（Reddit）Reddit

推定原因：サイズ増・署名/認証の厳格化・破損残骸

今回の更新はパッケージが大きく、ダウンロード/適用に時間がかかるうえ、SMBや認証まわりの強化と相まって環境差の影響を受けやすい構造です。 カタログ版スタンドアロン（.msu）でも失敗するケースは、コンポーネントストアの不整合や旧ビルド由来の署名/ポリシー差分が疑われます。大容量化はAIコンポーネントの同梱も一因とされ、回線品質の低い家庭では失敗→再開→失敗のループを誘発します。Windows Latest+1

まず試すべき標準手順（一般〜上級）

“順番通りにやる”ことが、原因の切り分けと成功率の双方を引き上げます。
(1) Windows Updateの一時停止を解除し、再起動後に「更新のチェック」を実行します。
(2) ストレージの空き容量を20GB以上確保し、外付けドライブやSDは外します。
(3) 回線を5GHz帯に切り替えるか有線接続にし、ウイルス対策の一時停止を検討します。
(4) 既存の保留更新（再起動待ち）がないか確認し、全て完了させます。
(5) 管理者としてコマンドプロンプトを開き、DISM /Online /Cleanup-Image /RestoreHealth を実行し、完了後に sfc /scannow を実行します。
(6) 失敗コードが0x800F0922系なら、更新履歴で失敗のKBを選び「アンインストール」→再起動→再試行の順で再適用を試みます。
(7) なおカタログ版（Microsoft Update Catalog〔カタログからの手動適用〕）でも失敗する報告があるため、.msu単独での再挑戦は“最後の確認”に留めます。Microsoft Learn+2Microsoft Learn+2

“最後の一手”：上書きインストールで環境を整える

Windows Updateが何度やっても失敗する場合は、Media Creation Tool（メディア作成ツール）での in-place upgrade（上書きインストール）か、Update Assistant（更新アシスタント）を用いた再構成が実効性の高い回避策です。方法は簡潔です。
(1) MicrosoftのダウンロードポータルからMedia Creation Toolを取得します。
(2) 起動後に「このPCを今すぐアップグレード」を選び、「個人用ファイルとアプリを引き継ぐ」を必ず有効にします。
(3) 再起動後にWindows Updateを開き、KB5065426の状態を確認します。
(4) うまくいかない場合はUpdate Assistantで同様に再試行します。
Media Creation Toolは更新コンポーネントや署名の不整合を“ならす”効果が期待でき、破損の残骸で止まるPCでも通る可能性があります。Windows Latest

ファイル共有が壊れた場合の暫定運用

SMB共有が認証で弾かれる場合は、まず更新のアンインストールで復旧するかを確認し、業務影響が大きいなら当該更新の一時停止と代替手段（OneDrive/SharePoint/クラウド共有）で凌ぐのが現実的です。併せてネットワークプロファイルがパブリック化していないか、ファイルとプリンターの共有・ネットワーク探索が無効化されていないかを点検します。企業環境では署名やNTLM/ゲストのポリシー変更も絡みやすいため、同一ドメイン内での差分調査を勧めます。Microsoft Learn+1

対象ユーザー層と当面の判断

一般ユーザーは“まず標準手順→ダメなら上書きインストール”、企業のシスアドは“影響端末の切り分けと一時回避、共有障害はアンインストールで即復旧”が当面の最善策です。月例パッチの性質上、長期の放置は推奨できません。復旧後は更新一時停止を短期で解除し、公式の既知問題ページの更新を追従しましょう。Microsoft Learn

根本対策の設計図：更新に“勝てる”環境を作る

最重要点は、今回だけを凌ぐのではなく「次の月例でも同じ失敗を起こさない更新パイプライン」を家庭・職場ごとに設計し直すことです。 回線品質と空き容量、セキュリティ製品、周辺機器の常駐ドライバーが三位一体で失敗率を左右します。24H2ではパッケージ肥大と署名の厳格化が進んでいるため、毎月の“準備運動”を定形化しましょう。再起動を週1回は実施し、ディスク最適化と一時ファイル削除を習慣化すると、コンポーネントストアの整合性が保たれやすくなります。企業では更新の波及前に、代表端末での先行検証と段階配信を徹底して、障害の面展開を防ぎます。

企業向けインシデント対応：WSUS／Intuneでの切り戻しと段階配信

最重要点は“止める→隔離→緩やかに戻す”の順番で、影響を最小化することです。 WSUSでは該当KBを一旦未承認に戻し、影響の出たコンピューターグループだけ配布停止します。Intuneでは配布リングの展開を一時停止し、問題端末のデバイスコレクションを切り分けて、対象外に移します。SMB共有断が業務停止級なら、当面は該当KBのアンインストールを許可し、業務セグメントごとに代替共有（OneDrive/SharePoint/Teamsファイル）へ誘導します。切り戻し後は、メディア作成ツールの上書きインストールを小規模で試し、成功率を見て段階的に復帰するのが安全です。

Windows Update構成の初期化：コンポーネントリセット手順

最重要点は“止める→捨てる→整える→再開する”の順でWindows Updateの土台をリセットすることです。 手順は次のとおりです。
(1) 管理者としてコマンドプロンプトを開き、BITS、Windows Update、CryptSvc、MSIサービスを停止します。
(2) C:\Windows\SoftwareDistribution と C:\Windows\System32\catroot2 を SoftwareDistribution.old／catroot2.old へリネームします。
(3) netsh winsock reset を実行し、IPリセット（netsh int ip reset）も続けます。
(4) サービスを起動順で再開します（CryptSvc→BITS→Windows Update→MSIの順）。
(5) 再起動し、更新の再チェックを行います。
この一連で破損したキューや古い配布キャッシュを切り離せます。0x800F0922や0x800700C1の再発が止まるケースが多い手筋です。

コンポーネントストア修復の“最終火力”：DISM拡張メニュー

最重要点は、基本のRestoreHealthだけで直らない場合に、StartComponentCleanupやResetBaseを段階的に加えて“重整備”することです。 手順は次のとおりです。
(1) DISM /Online /Cleanup-Image /StartComponentCleanup を実行します。
(2) 続けて DISM /Online /Cleanup-Image /RestoreHealth を実行します。
(3) 改善がない場合のみ DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase を検討します（古い置換コンポーネントを破棄）。
(4) sfc /scannow を実行し、破損が検出・修復されたら再起動します。
ResetBaseは更新の巻き戻し余地を狭めるため、企業ではメンテナンスウィンドウ内での実施と事前のイメージバックアップを推奨します。

SMB／共有トラブルの診断フロー：認証・探索・ポリシーを三段で確認

最重要点は“認証が通るか→探索が見えるか→ポリシーに矛盾がないか”の順に分解することです。 まず両PCのネットワークプロファイルがプライベートで一致しているかを確認し、資格情報マネージャーに残った旧資格情報を削除のうえ、同一ユーザー名とパスワードで再登録します。次に、機能探索サービス（Function Discovery Provider Host／Resource Publication）とTCP/IP NetBIOS Helperが自動起動になっているかを確かめます。最後に“パスワード保護共有”のオンオフが相手側の設定と合っているか、ローカルセキュリティポリシーで不要な例外を作っていないかを点検します。SMB1の有効化は回避し、どうしても必要なら限定ネットワークでの一時対応に止めましょう。

ログで原因を掘る：どのファイルを見れば良いか

最重要点は“何が壊れているか”をログで客観化し、次の打ち手（WU初期化／DISM／上書き）を選び分けることです。 Windows Updateのトラブルでは、C:\Windows\Logs\CBS\CBS.log と C:\Windows\Logs\DISM\dism.log、C:\Windows\WindowsUpdate.log（PowerShellのGet-WindowsUpdateLogで生成）を合わせて読みます。インストールが途中で止まる場合は、C:$WINDOWS.~BT\Sources\Panther\setuperr.log／setupact.log に致命エラーの手掛かりが残ります。0x800F081Fでは欠落したパッケージ名、0x800F0922ではサービス接続や回復領域関連の記述が見つかることが多く、次の一手を定めやすくなります。

よくある質問：カタログ版も落ちる／回復パーティションが小さいほか

最重要点は“カタログが通らない＝環境の整合性が壊れている”と捉え、上書きインストールで土台を揃える判断です。 スタンドアロンの.msuが60％付近で失敗するのは、前提コンポーネントの不整合や署名検証の失敗が典型です。Media Creation Toolの「このPCを今すぐアップグレード」で個人用ファイルを保持したまま再構成すれば、同時に回復パーティションのレイアウトも健全化されます。0x800F0922で回復パーティション不足が疑われる場合も、上書きインストールが最短です。なお、ストレージ暗号化（BitLocker）環境では、事前の回復キー保管を忘れないでください。

リスクと注意：レジストリ変更や“力技”は最終手段

最重要点は、未検証のレジストリ変更や古い暗号／プロトコルの有効化（SMB1など）は“治ったように見えて深刻なリスクを招く”ことです。 インターネット上の“レジストリでWUを強制”といった断片的な対処は、副作用でサービスの起動順や署名検証に影響し、後続の更新で再発する温床になります。企業では変更管理台帳にすべてのレジストリ・ポリシー変更を記録し、標準構成へのロールバック手段を常に用意してください。家庭でも、未知のスクリプトを実行するより、公式ツールでの上書きインストールを軸に据えた方が総合的に安全です。

既知問題の今後と“見極めポイント”

最重要点は、公式の既知問題ページと配信ヘルスの更新を追い、サーバー側の是正（配信の調整）が入った気配を見極めることです。 具体的には、更新履歴ページに“解決策：サーバー側で是正済み”の記述が追加されるか、ビルドのマイナー増分（例えば26100.66xx）が予告なく広がるかを確認します。SMB周りは累積での再修正が入ることが多い領域なので、共有が不安定な組織は展開リングを狭め、先行端末の観測期間を通常より長めに取りましょう。家庭では「すぐ更新」に固執せず、数日遅らせてから適用するだけでも成功率が上がるケースがあります。

まとめ：判断の軸と“安全第一”のアップデート習慣

結論は「標準手順→WU初期化→DISM強化→上書きインストール→（必要なら）アンインストールで暫定回避」という一本の梯子を、慌てず順に上ることです。 KB5065426（Windows 11 24H2、OSビルド26100.6584）は重要なセキュリティ更新であり、長期の保留は推奨できません。とはいえ業務や家庭の共有が止まるなら、一時的な切り戻しと代替運用で安全を優先してください。更新が通ったら、次回に備えて“環境を整える仕組み”を残しましょう。

フォーラムに集まろう：あなたの環境で“効いた一手”を共有してください

コメント欄では、出たエラーコード、どの段で成功したか、共有復旧に要した操作を具体的に教えてください。 例として、エディション（Home／Pro）、ストレージ空き容量、常駐のセキュリティ製品名、ネットワーク（有線／Wi-Fi 2.4GHz／5GHz）、SMBの設定（パスワード保護共有の有無）、上書きインストールの所要時間、ログに現れたキーワードなどを書いてもらえると、他の読者が再現しやすくなります。家庭の“うまくいった手順”、企業の“展開設計”、どちらの知見もこの場でつながります。あなたの一行が、次の誰かの復旧を早めます。