平日の業務時間にパソコンが突然ファン全開となり、タスク マネージャーを開くと「Windows Modules Installer Worker（TiWorker.exe）」が CPU を 70 ％ も占有している――そんなトラブルは IT 部門にとって定番の悩みです。本記事では Windows 10／Windows 11 を対象に、原因の仕組みから実務で有効だった対策手順、再発防止の設定まで網羅的に解説します。読み終えるころには、自席で動き出す TiWorker に惑わされず、安定した PC 運用を取り戻せるはずです。
なぜ TiWorker.exe が高負荷になるのか ― 背景を正しく理解する
Windows Modules Installer Worker（以下 TiWorker）は、Windows Update がダウンロードした更新プログラムを適用する裏側のプロセスです。アクティブ時間を設定していても、以下のような処理は例外的に実行される場合があります。
- 累積更新プログラムの適用後に走る コンポーネント クリーンアップ（古いパッチの削除）
- Servicing Stack Update（SSU）適用後の メタデータ最適化
- 自動メンテナンス（毎日 03:00 に予約）で呼び出される整合性チェック
これらは Windows Update サービス（wuauserv）が停止していても起動するため、目安として「アクティブ時間＝CPU が静か」というわけではありません。また、更新キャッシュが壊れていたり、CBS（Component Based Servicing）マニフェストに破損があると、TiWorker が同じ処理を延々とリトライし、負荷が高止まりします。
よくある誤解 ― アクティブ時間を設定すれば安心？
アクティブ時間は「更新プログラムの インストール と再起動」を避ける設定であって、パッチ適用後のクリーニング工程や Servicing Stack の保守作業は対象外です。スケジューラ上は Maintenance Scheduler のジョブに分類されるため、深夜帯にずらすにはレジストリまたはグループ ポリシーでメンテナンス時刻を変更する必要があります（具体例は後述）。
解決フロー ― 効果の高い順に試すステップ
| 手順 | 内容 | 期待される効果／補足 |
|---|---|---|
| 1 | クリーンブート（msconfig でサードパーティ製サービスとスタートアップ無効化） | 他プロセスとの競合・常駐アプリが原因か切り分け可能。質問者は実施済みで効果なし |
| 2 | Windows メモリ診断（mdsched.exe） | メモリエラーが TiWorker 高負荷を誘発していないか検査。実施済みで問題なし |
| 3 | Windows Modules Installer サービスを「手動（Manual）」に変更（services.msc） | 自動起動を抑え、必要時だけ実行させることで勤務中の暴走を防ぐ。実施済みで効果なし |
| 4 | Windows Update コンポーネントのリセットnet stop wuauserv → %SystemRoot%\SoftwareDistribution と %SystemRoot%\System32\catroot2 を .old へリネーム → net start wuauserv | 破損した更新キャッシュやスタックを初期化し、TiWorker の異常ループを解消。👉 次に試すべき推奨手順 |
| 5 | インプレース アップグレード（上書き修復インストール） Media Creation Tool から ISO をマウントし、「個人用ファイルとアプリを保持」を選択 | システムファイル全体を正常な状態へ戻す最終手段。設定やアプリを残したまま OS を再展開できる。バックアップ推奨 |
各手順の詳細ガイド
手順 1：クリーンブートで競合をあぶり出す
第三者製セキュリティソフトが C:\Windows\WinSxS フォルダをリアルタイム スキャンし続けると、TiWorker のアクセスとバッティングし高負荷を助長するケースが多く報告されています。サービスとスタートアップを すべて 無効化して再起動しても症状が続くか観察することで、OS 以外の要因を排除できます。
手順 2：Windows メモリ診断
メモリエラーは一見無関係に思えますが、IDE 上でビルドを行うとき、TiWorker がメモリ不足で途中失敗し、再試行を繰り返す症例があります。ECC 無しのデスクトップ機や、OC メモリを積んでいるゲーミング PC ほど発生率が高い印象です。診断結果が「問題ありません」なら次の手順へ進みます。
手順 3：サービスを手動化して様子を見る
services.msc で「Windows Modules Installer」を「手動」に設定すると、Windows Update が呼び出すタイミング以外は TiWorker が起動しません。これで収まれば「自動メンテナンス」がトリガーだったと判断できます。効果がなければ更新スタックの破損を疑い、手順 4 へ。
手順 4：Windows Update コンポーネントの完全リセット
最も効果が高い定番策です。以下のバッチ スクリプトを管理者 CMD で実行すれば自動化できます。
@echo off
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren %SystemRoot%\SoftwareDistribution SoftwareDistribution.old
ren %SystemRoot%\System32\catroot2 Catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
echo --- 完了しました。PC を再起動してください ---
PC 再起動後に Dism /Online /Cleanup-Image /AnalyzeComponentStore を実行すると、コンポーネント ストアの肥大化具合と再クリーンアップの要否が確認できます。
手順 5：インプレース アップグレード
上記でも改善しない場合は OS 全体に破損が及んでいる可能性が高いため、Media Creation Tool または setup.exe /auto upgrade /quiet /compat ignorewarning で上書きインストールします。ユーザー データを保持しつつ WinSxS と CBS をリセットできるのが強みです。BitLocker ドライブは suspend してから実施してください。
ディープダイブ ― さらなる診断と再発防止策
1. DISM と SFC で CBS マニフェストを修復
手順 4 後でも警告が消えない場合、以下の順で実行します。
Dism /Online /Cleanup-Image /RestoreHealth
sfc /scannow
Dism は Windows Update から正常なコンポーネントを取得して破損ファイルを置き換え、SFC は OS 保護機能でチェックサム不一致を修復します。
2. 自動メンテナンスを深夜帯に変更
企業 PC ならグループ ポリシー一括設定がおすすめです。ローカルで試す場合は以下のレジストリを投入します。
[HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance]
"MaintenanceDisabled"=dword:00000000
"MaintenanceStartTime"="03:00" ; ←24h表記。ここを例えば "02:00" に変更
再起動後、自動メンテナンス (Idle Maintenance) が指定時刻にリスケジュールされ、TiWorker の業務時間出現率を低減できます。
3. 不要な Windows 旧バックアップを切り離す
外付け HDD や NAS に WindowsImageBackup フォルダがあると、コンポーネント クリーンアップの対象としてスキャンされることがあります。ネットワーク越しに巨大 VHDX を走査すると CPU／Disk が跳ね上がるため、検証時は一旦ドライブ レターを外して挙動を比較しましょう。
4. イベント ビューアーでエラーを特定
Applications and Services Logs → Microsoft → Windows → WindowsUpdateClient
および … → CBS 内に出力される Error／Critical が判断材料です。
例：Event ID 1002 - Warning: A reboot is necessary before servicing... は中断ループの典型。原因を片付けずに放置すると、毎回 TiWorker が再走行します。
検証後のパフォーマンス確認
- タスク マネージャー の CPU グラフが 24 h で平均 5 % 以下に落ち着いたか
- 信頼性モニター で「Windows モジュール インストーラー」の失敗イベントが消えたか
- Performance Monitor で
%Processor Time (TiWorker)をログ収集し、ピークが退社後にシフトしたか
それでも断続的なスパイクが残るなら、SSD の SMART 生存率やサードパーティ製 AV の 除外リスト を点検しましょう。
FAQ ― よくある質問
Q. TiWorker をタスク マネージャーで 即終了 してもいい？ A. 処理途中で強制終了すると、更新コンポーネントが破損し症状が悪化するリスクがあります。負荷が高くてもタスク キルより サービス停止 で安全に切り離しましょう。 Q. Windows Update を完全自動にしないとセキュリティ上まずい？ A. 累積更新プログラムは毎月第 2 火曜（日本時間水曜）リリースです。品質更新チャネルを Enterprise/Education など 1 か月遅延に設定すれば、手動メンテナンスと両立できます。 Q. 「一時停止 7 日間」ボタンで高負荷も止まる？ A. 一時停止は 新規更新の検出 を止めるだけで、既にダウンロード済みのパッチ後処理やコンポーネント クリーンアップは継続します。原因切り分けには向きません。
まとめ ― 実運用での優先順位
- まずは コンポーネント リセット（手順 4）で壊れたキャッシュを一掃
- 改善しなければ DISM→SFC を併用して CBS 破損を修復
- なお発生する場合 メンテナンス時刻 を深夜帯へ変更し業務影響を回避
- 最後の砦として インプレース アップグレード で OS を再展開
管理台数が多い環境では、これらの手順を PowerShell スクリプト と Intune／GPO でパッケージ化し、エラー イベントをトリガーに自動適用する運用が理想的です。TiWorker が静かになれば、CPU リソースを本来の業務アプリに振り向けられ、ユーザー満足度と生産性の向上につながります。
付録：スクリプト テンプレート集
PowerShell 版 コンポーネント リセット（一括実行用）
Stop-Service -Name wuauserv, bits, cryptSvc, msiserver -Force
Rename-Item -Path "$env:SystemRoot\SoftwareDistribution" -NewName "SoftwareDistribution.$((Get-Date).ToString('yyyyMMdd'))"
Rename-Item -Path "$env:SystemRoot\System32\catroot2" -NewName "catroot2.$((Get-Date).ToString('yyyyMMdd'))"
Start-Service -Name wuauserv, bits, cryptSvc, msiserver
Write-Host "Windows Update コンポーネントをリセットしました。再起動してください。" -ForegroundColor Green
グループ ポリシー (ADMX) で自動メンテナンス時刻を夜 2 時に変更
コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → 自動メンテナンス
「毎日のメンテナンスの開始時刻を設定する」 = 有効
開始時刻 = 02:00
イベント ビューアーで特定 ID を検知しメール通知 (Task Scheduler + Powershell)
$body = "TiWorker High CPU detected on $(hostname) at $(Get-Date -Format 'yyyy/MM/dd HH:mm')."
Send-MailMessage -To "[email protected]" -From "[email protected]" -SmtpServer "smtp.example.co.jp" -Subject "[Alert] TiWorker High CPU" -Body $body
これらのテンプレートをカスタマイズし、自社環境に合わせて展開すれば、TiWorker トラブルの「探知・隔離・修復・再発防止」を自動化できます。
コメント