原因となっていた作業

自分の業務の中で、ストレージが影響を受けるものは以下です。

Dockerで環境整備されているRailsアプリケーションの開発
uv仮想環境を使ったPythonアプリケーションの開発

Railsアプリケーション開発においては、git worktreeを使って並列開発することがほとんどです。worktreeを使った開発セッションを起動するタイミングで、worktree（ブランチ）1つに対してDocker Composeが1つ立ち上がるように動作しています。（Railsアプリ側の自動テストやE2Eテストの実行にはブランチごとに環境を用意しておく必要があるんでやむなし。）

Pythonアプリケーションの開発については、AWSのLambdaの実装を行ったりする時に使います。Dockerにしても良いんですが、Lambdaにデプロイした時に「インラインエディタでコード修正したり検証したりできた方が良い」とのことで、uv仮想環境を使うようにしています。

あとはなんだかんだでClaudeさんにデータ集計などを投げると、OSのPythonバージョンと使用したいPythonバージョンが違うとかで、OSのPythonバージョンを汚さないためにuv環境を使ったPythonでデータ集計したりします。

Docker関連のキャッシュやゴミを削除

コマンド	正しい意味
`docker image prune`	使われなくなったイメージだけ削除
`docker image prune -a`	どのコンテナからも参照されていないイメージを削除
`docker volume prune`	未使用の匿名ボリュームを削除
`docker volume prune -a`	未使用の匿名・名前付きボリュームを削除
`docker buildx prune`	選択中ビルダーの使われなくなったビルドキャッシュを削除
`docker buildx prune -a`	選択中ビルダーの未使用ビルドキャッシュを広く削除
`docker system prune`	停止済みコンテナ、未使用ネットワーク、使われなくなったイメージ、ビルドキャッシュを削除
`docker system prune -a --volumes`	上記に加えて未使用イメージと匿名ボリュームを削除

uv環境のキャッシュを削除

以下を実行。

# 未使用キャッシュと不要になったvenvを削除
uv cache prune

# uvキャッシュを全削除
uv cache clean

# 特定パッケージのキャッシュだけ削除
uv cache clean ruff

--forceをつけることによって強制的にキャッシュ削除できますが、稼働中のMCPサーバーが壊れるなどのリスクがあるので、実行しないようにするべし。

結果

自分の場合は、これによって、480GB近くあった使用済み容量が400GB近くまで減りました。

PC動作が良くないなぁって時に見直すべきは仮想環境のキャッシュであることを実感しました。