ディープスキャンは徹底的です。そこが利点であり、同時に欠点でもあります。ブラウザキャッシュ、一時インストーラー、サムネイルDB、クラッシュログなどの小さな断片を大量に列挙します。このノイズは「本命が消えた」証拠ではありませんが、強く絞り込まないと本当の候補を埋もれさせます。
この記事は、実ユーザーファイルを見落とさずにノイズを削る実務手順です。パスヒューリスティクス、サイズ帯、時間窓、そして溺れず前進するための書き出し習慣を扱います。
まず実ユーザーフォルダから見る
「プロジェクトを失った」案件の多くは、予測しやすいルートにあります。Documents、Desktop、Downloads、Documents\GitHub配下のリポジトリ、または社内標準フォルダです。無作為な%TEMP%行を眺める前に、これらルートに一致するパス断片で絞ってください。
時間とサイズを粗フィルタに使う
「昨日午後に編集した」と分かるなら、その時間帯周辺で並べ替えて確認します。「120 MBの動画」と分かるなら、切断を疑う理由がない限り200 KB候補は優先度を下げます。フィルタは完全ではありませんが、一覧が巨大なときの認知負荷を大きく下げます。
- 同じ拡張子で極小サイズのサムネイル群は、重複ノイズとしてまとめて扱う。
- 個人PCではブラウザプロファイルパスに注意する。Chrome/Firefoxキャッシュは特にノイジー。
- Docker/WSL利用者では見慣れないパスが出るため、その日の利用スタックを確認する。
書き出し規律: 少量バッチと早期オープン
「念のため5,000件」より、「有望50件」を先に書き出す方が有効です。早めに開いて検証すれば、復元先ディスクを埋める前に誤選定へ気づけます。複数日にまたがる案件では、候補ID・サイズ・結果を簡単な表で管理すると再作業を減らせます。
ノイズ自体が本命になる場面
ユーザーの「文書」が実は一時出力しかなかったケースもあります。たとえばWebアプリ由来のキャッシュPDFやダウンロードCSVです。この場合はキャッシュパスが重要になります。ファイル生成経路を聞くことが、適切なパスフィルタの前提です。