AIコーディングエージェントがMacのディスクを埋める原因

エージェントがこれほどディスクを使う理由

エージェントは、手が速くて疲れを知らない開発者と同じように作業します。コードをチェックアウトし、依存関係をインストールし、ビルドし、テストを実行し、また最初から繰り返します。多くのツールは、複数のタスクが互いのファイルに触れずに同時に実行できるよう、タスクごとに専用のgitワークツリーを用意します。

ワークツリーは、それぞれが完全な作業コピーです。それぞれに独自の node_modules、仮想環境、ビルドフォルダが作られ、タスクが終わっても、それらを削除するものはありません。終わったタスクが20個あれば、プロジェクトの依存関係のコピーが20個あるということになりかねません。

残ったワークツリーを見つけて削除する

リポジトリの中で下記の1つ目のコマンドを実行すると、gitが把握しているすべてのワークツリーが、パスとブランチとともに一覧表示されます。読み取るだけです。エージェントを使っているリポジトリごとに実行してください。

削除する前に、その作業が安全に残っていることを確認します。フォルダを開いて、git status を実行します。ブランチがマージまたはプッシュされていて、コミットされていない変更がなければ、削除しても何も失われません。

2つ目のコマンドは、ワークツリーのフォルダを削除します。ワークツリーにコミットされていない変更や追跡されていない変更があると、gitは拒否します。これは必要な保護なので、中身を確認していないかぎり --force を付けないでください。3つ目のコマンドは、フォルダがすでになくなっているワークツリーについて、gitの記録を消去するだけです。ワークツリーを削除しても、そのブランチは削除されません。

git worktree list
git worktree remove path/to/worktree
git worktree prune

ホームフォルダにあるセッションログとエージェントのデータ

エージェントとそのコマンドラインツールは、やり取りの記録、履歴、編集したファイルのスナップショット、ダウンロードしたツールを、~/.claude、~/.codex、~/.cursor といったホームフォルダの隠しフォルダに保持します。VS Codeをベースにしたエディタは、さらに ~/Library/Application Support の下にも保持します。

下記のコマンドは、ホームフォルダの隠しフォルダをサイズ順に、最も大きいものが最後になるように一覧表示します。読み取るだけです。

これらのフォルダには、2種類のデータが混ざっています。ログとやり取りの記録は履歴です。古いものを削除すると、そのセッションを再開したり検索したりできなくなります。設定、認証情報、メモリファイルは構成です。削除すると、ツールをもう一度設定することになります。古いセッションは、ツール自身の設定やコマンドが用意されていればそこから消去し、フォルダごと削除することはしないでください。

du -sh ~/.??* 2>/dev/null | sort -h | tail -15

何倍にも増えた依存関係とビルド出力

不要になったワークツリーを削除したあと、残りの領域はたいてい、まだ残っているプロジェクトフォルダにあります。エージェントは、リポジトリを一時フォルダや作業用のフォルダにクローンして、そのまま残していくことがよくあります。

下記のコマンドは、コードのフォルダの下にある node_modules フォルダを見つけ、サイズ順に並べ替えます。読み取るだけです。~/Projects は、コードとワークツリーを置いている場所に置き換えてください。たいてい .venv という名前のPythonの仮想環境や、.build、target、dist などのビルドフォルダも、同じパターンです。

これらはどれも、使っていないプロジェクトのものなら削除できます。インストールやビルドのコマンドで作り直されます。

find ~/Projects -type d -name node_modules -prune -exec du -sh {} + 2>/dev/null | sort -h

パッケージのキャッシュも速く大きくなる

エージェントがインストールを実行するたびに、パッケージマネージャのダウンロードキャッシュは増えます。そしてエージェントは、人よりはるかに頻繁にインストールします。テスト用のツールも独自のものを追加します。たとえばPlaywrightは、完全なブラウザのビルドを ~/Library/Caches/ms-playwright にダウンロードします。

これらのキャッシュは、npm cache clean --force、pnpm store prune、uv cache clean、brew cleanup など、各ツール自身のコマンドで安全に消去できます。どれもダウンロードしたものだけを削除し、代償は、次のインストールでもう一度取得することです。

ローカルモデル

Macでモデルを実行しているなら、それがおそらくディスク上で最も大きい単独の項目です。1つのモデルが数GBあることも多く、いくつか試すとすぐに大きくなります。

• Ollamaは、モデルを ~/.ollama/models に保持します。下記の1つ目のコマンドでサイズとともに一覧表示でき、ollama rm のあとにモデル名を続けると、1つ削除できます。
• Hugging Faceのライブラリは、モデルとデータセットを ~/.cache/huggingface/hub にキャッシュします。2つ目のコマンドは、それらをサイズ順に一覧表示します。
• LM Studioは、ダウンロードしたものを独自のmodelsフォルダに保持します。このフォルダは、アプリから開いて管理できます。
• モデルを削除しても恒久的に失われるものはありませんが、また使いたくなったら、もう一度ダウンロードする必要があります。

ollama list
du -sh ~/.cache/huggingface/hub/* 2>/dev/null | sort -h

コンテナとサンドボックス

エージェントの中には、Dockerコンテナの中でコードを実行するものがあります。イメージと停止したコンテナはどれもDockerのディスクイメージの中に残り、ディスクイメージは大きくなるばかりで、自動的には小さくなりません。

下記の1つ目のコマンドは、Dockerが保持しているものを表示します。読み取るだけです。2つ目のコマンドは、停止したコンテナ、使われていないネットワーク、どこからも参照されていない（dangling）イメージ、使われていないビルドキャッシュを削除します。ボリュームと、コンテナがまだ使っているイメージは削除しません。停止したコンテナの中にしか保存されていないものは失われるので、実行する前に確認してください。

docker system df
docker system prune

Diskzyが役立つところ

Diskzyはディスク全体をマップにし、ファイルが変わるたびに最新の状態を保つので、この問題に向いています。エージェントの実行中に、どのフォルダが大きくなっているかがわかります。「System Data, explained」（システムデータの内訳）は、開発者データとAIモデルを、それぞれ名前の付いた部分としてサイズとともに表示します。

「Clean up」（クリーンアップ）タブは、node_modules、.build、Pods、仮想環境などのプロジェクトのビルドフォルダを、どこにあっても見つけ、プロジェクトが過去14日間に変更されている場合は、そのフォルダのチェックを外したままにします。パッケージマネージャのキャッシュにはチェックが入ります。Ollama、Hugging Face、LM Studioのモデルは、一覧には表示されますが、もう一度ダウンロードすることになるため、チェックは外れています。削除したものはすべてゴミ箱に入ります。