Windows ServerのファイルサーバーでCドライブを監視していると、C:\Windowsが短時間で数十GBに膨らんだ後、いつの間にか元に戻る――そんな「ディスク使用量スパイク」に悩むことがあります。原因のフォルダー探しだけでは再発します。本記事ではC:\Windows\Tempが増減していたケースを題材に、サーバー負荷を抑えながら“どのプロセスが書き込んだか”をProcmonで特定し、AV製品（例：Kaspersky）まで突き止める手順をまとめます。
症状を正しく言語化する：まずは「何が増えたのか」を切り分ける
「C:\Windows が急に肥大化して、しばらくすると元に戻る」という現象は、一見するとWindows UpdateやWinSxS（コンポーネントストア）を疑いがちです。しかし、短時間で増えて短時間で戻る場合は、一時ファイル（Temp）や製品のキャッシュが一気に作られて、その後削除されているパターンが多いです。
ここで重要なのは、“Cドライブの空き容量が減った”のか、“特定フォルダーの見かけのサイズが増えた”のかを整理することです。監視の指標が混ざると、調査の方向がブレます。
| 観測しているもの | よくある見え方 | 調査の最初の一手 |
|---|---|---|
| ドライブの空き容量（例：C: の Free Space） | 空きが一気に減るが、後で戻る | 「どのフォルダーが増えたか」をスナップショット比較で確定する |
| フォルダーサイズ（例：TreeSize で C:\Windows を集計） | 特定の配下（Tempなど）が増減して見える | 増減している配下を一点に絞り、“書き込み元プロセス”へ進む |
| 監視ツールの計測値（ハードリンクや圧縮の影響を受けることも） | 同じ場所がツールによって数値が異なる | 実際のディスク消費（空き容量）と突き合わせて評価する |
本記事のゴールは「どのフォルダーが大きいか」を眺めて終わることではなく、“誰（どのプロセス）が書き込んでいるか”を最短で特定し、再発防止まで繋げることです。
まず「どこが増えているか」を最短で特定する
最初のステップは、スパイク時に本当に増えている場所を確定することです。質問のケースでは、TreeSize等で確認したところ、増減していたのは C:\Windows\Temp でした（例：18GBまで増えて、しばらくすると9GB前後へ戻る）。
フォルダーサイズを確認する代表的な方法
| 方法 | メリット | 注意点 |
|---|---|---|
| TreeSize / WizTree などのGUIツール | 増えている配下が一目で分かる、説明・共有がしやすい | スキャン中はディスクI/Oが増えることがある。業務時間帯はタイミングに注意 |
| PowerShellで対象パスだけサイズ計測 | 狙ったフォルダーだけを計測でき、運用に組み込みやすい | 再帰計測は重い。候補を絞って実行する |
| 監視製品（エージェント）のディスク使用量ログ | スパイクの時刻が分かる（いつ起きるかが分かる） | 「どのフォルダーが増えたか」までは出ないことが多い |
PowerShellで「候補フォルダーだけ」サイズを取る例
Windows配下を丸ごと再帰スキャンするのではなく、まずは疑わしい場所を候補にして計測します。例えば、Tempや更新関連の代表パスだけを比較するイメージです。
$targets = @(
'C:\Windows\Temp',
'C:\Windows\SoftwareDistribution\Download',
'C:\Windows\Logs',
'C:\Windows\Installer'
)
foreach ($t in $targets) {
if (Test-Path $t) {
$bytes = (Get-ChildItem -LiteralPath $t -Force -Recurse -ErrorAction SilentlyContinue |
Measure-Object -Property Length -Sum).Sum
[PSCustomObject]@{
Path = $t
GB = [Math]::Round(($bytes/1GB), 2)
Time = (Get-Date)
}
}
} | Sort-Object GB -Descendingこの時点で C:\Windows\Temp が突出して増減しているなら、次は「そこに書いているのは誰か」を捕まえる段階です。
「誰が書いているか」を特定する：Procmonを“軽く”使うのがコツ
プロセス特定の最有力ツールが、Sysinternalsの Process Monitor（Procmon） です。ただし、何も考えずに起動して放置すると、ファイル/レジストリ/プロセス/ネットワーク等のイベントを大量に収集してしまい、本番サーバーでは負荷やメモリ消費が心配になります。
ポイントは、最初から「C:\Windows\Temp だけ」「書き込み系だけ」へ絞り込んで、フィルター外は捨てることです。これにより、長時間監視でも“怖さ”をかなり減らせます。
Procmonを低負荷で運用する設定（実運用向け）
以下は「スパイクの瞬間だけ捕まえたい」「一日中回してもリソース枯渇が怖い」という現場ニーズを前提にした、現実的な設定例です。
| 設定項目 | 推奨 | 理由 | 設定場所の例 |
|---|---|---|---|
| フィルター（Path） | Path contains C:\Windows\Temp | 対象パス以外のイベントを極小化する | Filter（Ctrl+L） |
| フィルター（Operation） | WriteFile / CreateFile / SetEndOfFileInformation など | 容量増加に直結しやすい操作だけ見る | Filter（Ctrl+L） |
| Drop Filtered Events | 有効 | フィルター外を収集しない＝無駄な蓄積を防ぐ | Filterメニュー |
| History Depth | 小さめ（例：100万件） | メモリ消費を抑え、長時間でも安定させる | Optionsメニュー |
| ログの保存先 | C:以外（別ボリューム推奨） | 「Cが増える」調査中にCへログを書いてノイズを増やさない | File → Save / Backing Files |
| Backing File（必要に応じて） | 使用する（循環ログも検討） | メモリ保持ではなくファイル保持に寄せ、長時間運用しやすい | Fileメニュー |
最低限の手順（スパイクを捕まえるまで）
- Procmonを管理者権限で起動し、いったんキャプチャを停止します（ツールバーの虫眼鏡アイコン）。
- Filter（Ctrl+L）で
Path contains C:\Windows\Tempを追加します。 - さらに必要なら Operation を
WriteFile/CreateFileなどへ絞ります。 - Drop Filtered Events を有効にします（フィルター外のイベントを捨てる）。
- Optionsで History Depth を小さめにします（例：100万件）。
- キャプチャを開始し、スパイクが起きたタイミングで停止→保存→解析します。
スパイクが「いつ起きるか分からない」場合は、監視ツールのアラート時刻を見て、その時間帯にだけProcmonを動かす運用でも十分です。ポイントは“常時最大キャプチャ”ではなく、常時でも耐えられる絞り込みです。
Procmonのイベントの見方：容量スパイクに効く「操作」と「並べ替え」
容量が増える現象を追うなら、まずは次の観点で見ます。
| 見るべき列 | 意味 | 使いどころ |
|---|---|---|
| Process Name | 実行ファイル名 | “誰が書いたか”の中心。まずここで犯人候補を絞る |
| Operation | 実行された操作（WriteFile等） | 書き込み/作成/拡張など、容量増加と関係しやすい操作だけに絞る |
| Path | 対象ファイル/フォルダー | Temp配下のどこに書いたか（サブフォルダーや拡張子の傾向）を見る |
| Result | 成功/失敗等 | 大量に失敗している場合、リトライや例外処理で負荷増の手掛かりになる |
| Detail（Lengthなど） | I/O要求のサイズ等 | 「どのイベントが大きいか」の目安。ただし容量増加を単純合算しない |
実務では、Process Nameでソートして「Tempに書いているプロセスが一気に出てくる」状態を作り、上位のプロセスから当たりを付けます。さらに、特定プロセスが怪しいと分かったら、右クリックから Include（このプロセスだけ含める） を使うと絞り込みが一気に進みます。
ケーススタディ：KasperskyがC:\Windows\Tempへ大量書き込みしていた
質問のケースでは、Procmonの結果、C:\Windows\Temp に大量の書き込みを行っていたのは Kaspersky（例：kavfswp.exe） でした。
| 観測結果 | Procmon上の典型的な見え方 | 読み取れること |
|---|---|---|
| Tempが短時間で数十GBへ増加 | kavfswp.exe が WriteFile を連発し、C:\Windows\Temp\... を大量に生成 | リアルタイムスキャン/オンデマンド処理等で一時領域を使っている可能性が高い |
| しばらくすると元に戻る | 同プロセスまたは関連プロセスが削除/クリーンアップを実行（Delete系やCloseの後に消える） | 「ゴミが溜まっている」のではなく、「処理の間だけ膨らむ」タイプ |
| ピークが特定の時間帯に偏る | その時間帯にイベントが集中 | スケジュールスキャン、アップデート、隔離処理などの定期タスクの可能性 |
この段階で重要なのは、“犯人のプロセス名”を確定させることです。フォルダーサイズ調査だけでは「Tempが大きい」で止まりますが、Procmonでプロセス名が出れば、ベンダー設定・ログ・ジョブスケジュールなど、打てる手が一気に増えます。
さらに深掘りする：Tempに書き始める直前に「何を読んでいたか」を追う
原因プロセスが kavfswp.exe と分かったら、次は「なぜTempが膨らむのか」を突き止めます。多くの場合、AVは対象ファイルをスキャンするために一時領域へ展開したり、解析用に一時コピーを作ったりします。Tempに書き始める直前に、何のファイルを読んでいたかを追うと、トリガー（スキャン対象）が見えてきます。
深掘りの手順（Procmon側）
- フィルターを Process Name =
kavfswp.exeに切り替えます（右クリックのIncludeが手早い）。 - Operationは
ReadFile/CreateFile/QueryOpenなども含め、読み取り側を見えるようにします。 C:\Windows\Tempへの最初の大きな書き込み（WriteFile等）を見つけ、その少し前の時刻に戻って追跡します。- 読み取り元のパス（例：特定の共有フォルダー上の巨大ファイル、アーカイブ、バックアップファイル等）が見えたらメモします。
| やりたいこと | Procmonで使う機能 | 補足 |
|---|---|---|
| “このプロセスだけ”に絞る | イベントを右クリック → Include Process Name | まずは犯人を1つに固定すると解析が楽になる |
| 何にアクセスしたかを俯瞰する | Tools → Process Activity Summary / File Summary | 大量イベントを「要約」して傾向を見る。スパイク原因の当たりを付けやすい |
| 特定の拡張子やフォルダーに着目する | Pathの末尾（.zip/.iso/.vhdx等）でフィルター追加 | アーカイブ展開や巨大コンテナがTemp肥大化の原因になりやすい |
| “いつから始まったか”を押さえる | Time of Day / Relative Timeで前後関係を追う | 監視アラート時刻と合わせると再現性が上がる |
ここまでできると、「どの共有フォルダーの、どんな種類のファイルがトリガーになったか」まで絞れることがあります。すると、AV側の調整（スキャン対象、除外、アーカイブ解析、サイズ上限、スケジュール）を“根拠を持って”検討できます。
Kaspersky側で確認・調整したいポイント（例）
AV製品がTempを大量に使う理由は一つではありません。だからこそ、Procmonで得た「時刻」「対象ファイル」「プロセス」を、製品ログやタスクと突き合わせるのが有効です。
| 確認ポイント | ヒントになる兆候 | 次のアクション例 |
|---|---|---|
| スケジュールスキャン（フル/クイック） | 特定の曜日・時刻にスパイクが集中 | 実行時間の分散、対象の見直し、業務時間外へ移動 |
| アーカイブ/インストーラー解析 | .zip/.7z/.iso/.msi等のアクセス後にTempが急増 | 解析設定（深さ/サイズ上限）を調整、巨大アーカイブの扱いを検討 |
| アップデート/データベース更新 | 更新タイミングで一時ファイルが増える | 更新スケジュールやキャッシュの保存場所を確認（可能なら別ボリュームへ） |
| 隔離・消毒処理 | 検知イベントと同時刻にTempが増える | 検知ログを確認し、対象ファイルの所在と一致するかを確認 |
| ファイルサーバー特有の負荷（オンアクセススキャン） | 大量のSMBアクセス時にスパイクが発生 | スキャンモードや除外（場所/拡張子/プロセス）を“最小限で”検討 |
注意：「Tempを使うのが邪魔だから」といって、安易に C:\Windows\Temp を丸ごと除外するのは推奨しません。マルウェアもTempを悪用します。どうしても除外を検討する場合でも、Procmonでトリガーを特定した上で、影響範囲を最小化する（特定の共有パス、特定の拡張子、特定のプロセス、特定の時間帯など）設計が現実的です。
併用策：根本対処までの「安全策」で運用を止めない
原因がAVであっても、すぐに設定変更やアップデートができないことは珍しくありません。調査・調整を進める間、まずは“事故”を防ぐための安全策を入れておくと、ファイルサーバー運用が安定します。
| 安全策 | 目的 | 実施のコツ |
|---|---|---|
| 空き容量のバッファ確保 | C:逼迫による更新失敗・サービス停止を防ぐ | OSボリュームは余裕を持つ（更新/ログ/ページファイル等も考慮） |
| アラート閾値の最適化 | スパイクを見逃さず、捕獲タイミングを作る | 「何GB減ったら通知」だけでなく「変化率」「継続時間」も見ると誤報が減る |
| Procmonログの保存先をC:以外にする | 調査行為がスパイクを悪化させるのを防ぐ | 別ボリュームや一時的な作業用ドライブを用意 |
| Tempの定期清掃（慎重に） | “戻らない肥大化”の保険 | 当日作成分は触らない、古いものだけ対象、業務時間外に実施 |
| AVタスクの実行時間分散 | ピークI/Oの集中を避ける | スキャン/更新/バックアップが重なるとTempも膨らみやすい |
「ディスク クリーンアップ（不要ファイル削除）」は一時的な改善にはなりますが、本件のように“処理のたびに一時的に増える”タイプでは、掃除だけでは再発しやすいです。やはり本筋は、どのプロセスが、何をきっかけにTempを使うのかを掴み、製品設定と運用設計を合わせることです。
補足：Procmonの「Length」を合計しても、ディスク増加量とは一致しにくい
ProcmonのDetail列に出る Length は、主にI/Oの要求サイズ（そのイベントで書こうとしたバイト数）を示します。ここで「Length × イベント数＝増えた容量」と単純計算したくなりますが、実運用ではズレやすいです。
- 同じファイル領域への上書きが起きる（書いたように見えて、容量は増えない）
- キャッシュ、遅延書き込み、圧縮、クラスター単位の確保など、実ディスク消費と一致しない要因がある
- 書き込み要求が成功しても、その後すぐ削除されれば“増えた時間”は短い
容量の増減を正確に捉えるには、フォルダーサイズのスナップショット（TreeSize等）と、Procmonでのプロセス特定を組み合わせるのが現実的です。Procmonは「どれだけ増えたか」を測る道具というより、“誰が何をしていたか”を突き止める道具として使うのが成功しやすいです。
よくある詰まりどころと対処のヒント
| 詰まりどころ | よくある原因 | ヒント |
|---|---|---|
| Procmonを起動したらイベントが多すぎて見えない | フィルターが甘い、Drop Filtered Eventsが無効 | まずは Path contains C:\Windows\Temp と Drop Filtered Events を入れる |
| 監視しているのに、スパイクの瞬間が取れない | History Depth不足、保存タイミングの遅れ | History Depthを増やす/Backing Fileを使う/アラートをトリガーに調査する |
| Tempが増えているがプロセスが複数いる | 複数サービスが同時にTempを利用 | ピーク時刻に限定し、WriteFileの多い順に当たりを付ける |
| 特定プロセスが怪しいが、何を読んでいるか分からない | 書き込みだけ見ている | Process Nameで固定した上で ReadFile / CreateFile も含めて「直前」を追う |
まとめ：ディスク使用量スパイクを最短で潰す実務フロー
- まずはTreeSize等で、増減している場所を一点に絞る（例：
C:\Windows\Temp）。 - 次にProcmonで、対象パスへの書き込み元プロセスを特定する（Filter＋Drop Filtered Events＋History Depth調整）。
- 原因プロセスが分かったら、Process Nameで絞り込み、Tempへ書き始める直前の読み取り対象を追跡する。
- 製品ログ/タスク（スキャン・更新・隔離など）と時刻を突き合わせ、設定と運用を調整する。
- 根本対処までの間は、空き容量バッファ、アラート、ログ保存先などの安全策で運用停止を防ぐ。
C:\Windowsの肥大化という見え方に引っ張られず、増えた場所 → 書いたプロセス → トリガー（読んだ対象）の順で詰めていくと、短時間で原因に辿り着けます。今回のようにAV製品が原因だった場合も、Procmonで根拠を作ってから設定変更やベンダー問い合わせに進めるため、再発防止までのスピードが上がります。
コメント