CBS.log とは何か——そして数 GB に肥大化する理由

Component-Based Servicing をひと段落で

CBS は Component-Based Servicing の略で、Windows Update、オプション機能、DISM による修復を支える仕組みです。WinSxS ストアからコンポーネントを準備し、TrustedInstaller が所有するトランザクション内でパッケージを適用し、途中で失敗すればすべてを巻き戻します。その各ステップが、タイムスタンプとエラーコード付きで 1 行ずつ CBS.log に書き込まれます。システムファイルチェッカーの報告も同じファイルに落ちます。sfc /scannow が残す [SR] 行は、詳細が必要なとき findstr /c:"[SR]" で拾い出します。健康なマシンなら数か月で数十 MB 程度が積もるだけで、壊れたものがない以上、掃除する箇所もありません。

つまりこのログは診断装置であって、ゴミではありません。何かが壊れた日のためにこそ存在します。更新が 87% で止まるときや機能のインストールがどうしても確定しないとき、設定アプリが示す一般論ではなく、実際のエラーが記録されるのは CBS.log の中です。

何が GB 級に膨らませるのか

GB 規模の肥大には圧倒的な原因がひとつあります。リトライループです。更新が常に同じステップで失敗し、Windows が再試行を予約し、再試行が同じ形で失敗し、そのたびに何千行も書き込まれます。典型的な引き金は、コンポーネントストアの破損（0x80073712 や 0x800f081f の系統）、永遠に確定できない保留中パッケージ、そしてトランザクション途中で TrustedInstaller の作業を失敗させるディスクエラーです。こうして立ち往生したマシンは 1 日に数百 MB を追加することもあり、その時点でもうログは問題そのものではなく、症状のカウンターです。

CBS.log が巨大になっているからといって、削除して先へ進みたくなるのは我慢してください。ファイルは TrustedInstaller の所有で保護されているため、通常の削除ははじかれます。名前を変えるには先に所有権を取得する必要があり、それを済ませた頃には、失敗しているパッケージとエラーコードを指し示す記録そのものを破壊してしまっています。

CBS.log が 1 日あたり数十 MB 以上のペースで増える
更新履歴の中で同じ KB が何度も失敗を繰り返す
起動のたびに TrustedInstaller が何時間も CPU を消費する
DISM /CheckHealth や /ScanHealth がストアの破損を報告する
0x80073712 や 0x800f081f などのエラーがログで繰り返される
「更新プログラムの処理中」の画面に異常に長く留まる

直すべきはファイルではなくループ

実際に効く順序はこうです。まず DISM /Online /Cleanup-Image /RestoreHealth でコンポーネントストアを修復し、次に sfc /scannow、その後に再起動して Windows Update をもう一度試します。この順番なのは、DISM が SFC の動作する土台を直すからです。その後に更新履歴を確認し、特定の KB が失敗し続けるなら、ループを回し続けるのではなく更新を一時停止して次の累積更新を待ちます。ループが止まれば CBS.log は通常の数十 MB に戻り、そのまま落ち着きます。

「CBS.log を縮小」と宣伝するクリーニングツールは、領収書だけを治しています。ログを削除しても更新が失敗する理由は何も変わらず、証拠が失われるだけです。名前の変更は切り札です。ループを解決した後、小容量ドライブ上で数 GB のログが残っているような場合にのみ、TrustedInstaller 権限で、日誌を消す自覚を持って行ってください。