Mac で AI コーディングツールが残したものを片付ける方法

二年間余裕があったディスクが、コーディングエージェントを毎日使い始めてから数か月で満杯になることがあります。エージェント自体は小さいものです。変わったのは、マシンがどれだけの頻度でコンパイルするか、CLI がどれだけの頻度でディスク上の自分自身を置き換えるか、そしてあなた自身の思考のどれだけがテキストとしてホームディレクトリに残るようになったかです。増加分のほとんどは三つのカテゴリに収まり、それぞれ取り戻すコストがまったく違うので、必要な判断も三通りです。

モデルの重みは分かりやすい容疑者ですが、この問題に関しては大抵見当違いです。Ollama、LM Studio、Hugging Face はそれぞれ自分のツールでしか安全にプルーンできないコンテンツアドレス方式のストアを保持していて、これは別にAI ツールの残渣を取り除くで扱っています。この記事が扱うのは、作業中に AI コーディングエージェントが残していくものについてです。

削除する前に測る

二つのコマンドでほとんどの答えが分かります。最初のコマンドはエージェントのホームディレクトリを合計します。

du -sh ~/.codex ~/.claude ~/.local/share/claude ~/.grok ~/.cache 2>/dev/null | sort -h

二つ目のコマンドは、これまで開いたすべてのプロジェクトに散らばったビルド出力を見つけます。ルートは自分がコードを置いている場所に置き換えてください。

find ~/www ~/Projects -maxdepth 3 -type d \
  \( -name target -o -name node_modules -o -name .next -o -name dist -o -name build \) \
  -prune -exec du -sh {} + 2>/dev/null | sort -h | tail -20

-prune は、find がすでにマッチしたディレクトリの中へ降りていくのを止めます。これがここでは重要で、これがないと find は先に進む前に 24 GB の target/ の中のすべてのファイルを歩いてしまいます。この記事を書きながら測定した Mac では、上位二行は 24 GB の Rust の target/ と 9.8 GB の Tauri プロジェクトの target/ で、対する node_modules のツリーは 134 MB から 1.5 GB の範囲でした。この比率こそが要点です。依存関係の問題に見えていたものは、実際の数字のわずか 2% でした。

リストよりマップで見たいなら、Mole の Analyze 画面が同じボリュームをツリーマップとして描き、一番大きな矩形を掘り下げられます。find にどのルートを渡すか推測するより速い方法です。

カテゴリ一、増幅されたビルド出力

このカテゴリ自体は目新しくありません。新しいのは量です。手作業で開発する人は一日に数回コンパイルします。タスクをこなすエージェントは編集のほぼ毎回コンパイルし、テストを実行し、二つ目のアプローチを試し、また再コンパイルします。以前は数か月かけて増えていたキャッシュが、今では一日の午後だけで増え、インクリメンタルビルド用のディレクトリはそもそもディスクを引き換えに速度を買う設計です。

Rust は通常、大差をつけて最大です。target/ ディレクトリにはコンパイル済みの依存関係、インクリメンタルコンパイルの状態、ビルドスクリプトの出力が入り、プロファイルごとに別々に保持されるので、debug と release は丸ごと二つのコピーになります。オプションなしの cargo clean は「target ディレクトリ全体を削除します」。まずプレビューしてください。

cargo clean --dry-run
cargo clean --release

cargo clean -p <package> は指定したパッケージだけをクリーンします。ワークスペースの一つのメンバーだけが問題なら、これが正しい道具です。

JavaScript は出力が薄く広がります。node_modules そのものに加えて、node_modules/.cache（バンドラーやトランスパイラが使う）、Next.js ビルド用の .next、そしてツールチェーンが書き出す dist や build があります。キャッシュだけを狙って見つけてください。

find ~/www -maxdepth 4 -type d -path '*/node_modules/.cache' -prune -exec du -sh {} + \
  2>/dev/null | sort -h | tail

Python はインポートするパッケージのすべての隣に __pycache__ を残します。一つひとつは小さくても、数は何千にもなります。削除する前に数えてください。同じ形のコマンドの末尾に rm -rf を付けたものは、ルートを間違えると容赦がありません。

find ~/www -type d -name __pycache__ -prune -print | wc -l

バイトコードキャッシュは、ネットワークアクセスなしで次のインポート時に再生成されます。だからこれは、この記事全体の中で最も安全に削除できるものです。

Go はプロジェクトごとのディレクトリではなく、一つのグローバルビルドキャッシュを保持します。go env GOCACHE がその場所を表示し、go clean -cache は「go ビルドキャッシュ全体を削除する」動作です。go clean -testcache はコンパイル済みパッケージを破棄せずにキャッシュ済みのテスト結果だけを失効させます。私のマシンではビルドキャッシュが 183 MB、モジュールキャッシュが 38 MB だったので、ダウンロードされたモジュールが小さくてもビルド側は確認する価値があります。

Xcode は独自の扱いが必要です。DerivedData、アーカイブ、デバイスサポート、シミュレータランタイムは四種類のもので、それぞれ復元コストが違うからです。この Mac では DerivedData フォルダが 9.3 GB ありました。Xcode のストレージを片付けるで、どれを削除できてどれをシンボリケーション用に残すべきか扱っています。Gradle と Maven も同じようにプロジェクトごとの build/ ディレクトリと ~/.gradle や ~/.m2 下のグローバルストアに分かれ、グローバル側は開発キャッシュを片付けるにある他のレジストリと同じ扱いです。

カテゴリ二、置き換えられた CLI バージョン

これはほとんど誰も探そうとしないカテゴリで、複数のエージェントを動かしているマシンでは、すべてのキャッシュを合わせたより大きいことがよくあります。

エージェント CLI は、完全な新しいバージョンのリリースをまるごとダウンロードし、ランチャーの参照先をそちらに向けることで自己更新します。各リリースは自己完結していて、前のリリースとファイルを共有しません。ポインタは動きますが、古いリリースはそのまま残ります。誰も掃除しないので、更新のたびに数は一つずつ、永遠に増え続けます。

配置はどれも見た目の違いこそあれ、同じパターンに従っています。

• Codex は ~/.codex/packages/standalone/releases/<version>-<arch>/ を保持し、一つ上の階層にある current シンボリックリンクが生きているものを指します。
• Claude Code は ~/.local/share/claude/versions/<version> を保持し、各エントリはディレクトリではなく単一の実行ファイルで、~/.local/bin/claude が生きているものへのシンボリックリンクです。
• Grok は ~/.grok/downloads/grok-<version>-macos-<arch> をファイルとして保持し、~/.grok/bin/grok と ~/.grok/bin/agent が現行ビルドを指します。
• Cursor Agent は ~/.local/share/cursor-agent/versions/<date>-<sha>/ を保持し、~/.local/bin/cursor-agent がランチャーです。
• npm 経由でインストールされる GitHub Copilot CLI は自分自身をその場で置き換えますが、インストールスクリプトは、root 以外のユーザーでは既定で $HOME/.local になるプレフィックスの下に、バージョン付きのパッケージを書き込みます。Mole は同じ形として ~/.copilot/pkg/universal を確認します。

まとめて一度に測ってください。

du -sh ~/.codex/packages/standalone/releases/* \
       ~/.local/share/claude/versions/* \
       ~/.grok/downloads/* \
       ~/.local/share/cursor-agent/versions/* 2>/dev/null

この記事のために使った Mac では、262 MB から 310 MB の Codex のリリースが五つ、293 MB から 306 MB の Claude Code のバイナリが五つ、Grok のビルドが二つ、Cursor Agent のバージョンが二つと表示されました。合計でおよそ 3.5 GB、そのうち生きていたのは約 920 MB だけです。それ以外はすべて、すでに置き換えられたバイナリでした。Codex 自身の課題管理には、この件についての未解決の要望があり、報告者は更新のたびにおよそ 250 MB ずつ増えると測定しています（openai/codex#22293）。

ディレクトリを一つでも消す前にランチャーを解決する

つい取りたくなる近道は、日付順に並べて最新のものを残すことです。それはやめてください。ありふれた二つの状況がこれを壊します。リグレッションのあとに意図的に古いバージョンに固定した場合と、アップデートがポインタを切り替える前に新しいディレクトリをステージングしていた場合です。生きているリリースを消すと、どこも指していないランチャーだけが残ります。

代わりにランチャーに聞いてください。これはシンボリックリンクなので、解決すればいいだけです。

readlink -f "$(command -v codex)"
readlink -f "$(command -v claude)"
readlink -f "$(command -v grok)"

これで実際の参照先、たとえば ~/.codex/packages/standalone/releases/0.147.0-aarch64-apple-darwin/bin/codex が表示されます。ls -l "$(command -v codex)" は最終的な答えではなく各ホップを見せてくれます。返ってきたものが生きているものです。そのパス上にない兄弟はすべて置き換え済みで、ゴミ箱に送っても安全です。ゴミ箱を空にする前に、一度 CLI を実行してランチャーがまだ解決できることを確かめてください。

カテゴリ三、ジャンクではないエージェントの作業状態

三つ目のカテゴリは、クリーナーが本当の被害を与えかねない部分です。最初の二つとまったく同じように見えるからです。

セッションのトランスクリプト、メモリ、プラン、生成された添付ファイルは ~/.codex/sessions、~/.codex/archived_sessions、~/.codex/memories、~/.claude/projects、~/.grok/sessions にあります。これらはセッション ID で名付けられ、タイムスタンプが付き、追記のみで、増え続けて止まることがない JSONL ファイルです。汎用クリーナーが使うあらゆるヒューリスティックは「ログファイル」だと言います。私が測定した Mac では、~/.codex/sessions が 9.8 GB、~/.claude/projects が 2,362 個のトランスクリプトファイルにわたって 2.7 GB、~/.grok/sessions が 1.3 GB でした。使い捨てに見えるファイルに、大きくて誘惑的な数字が付いているということです。

これらはログではありません。トランスクリプトは、ある変更がどうやってそこに至ったかの記録です。試して却下したアプローチ、それを退けた制約、最終的な形が今の形になった理由。その推論はどこにも他には存在しません。コミットメッセージは何が変わったかを記録し、コードは生き残った選択肢だけを記録し、却下された四つの選択肢は記録しません。何か月分もが静かに積み重なり、なぜそう作られたのかを後から問い直しに戻ったときに初めて、その価値に気づきます。

より大きなリスクはサードパーティのクリーナーではありません。Claude Code は自前の保持期間による一掃機能を持っています。cleanupPeriodDays の既定値は 30 日で、起動時にそれより古い projects/ 配下のトランスクリプト、プランファイル、file-history/ 内の編集前スナップショット、セッションごとのタスクリストを削除します。.claude ディレクトリのリファレンスには、どのパスが一掃され、どのパスが無期限に保持されるかが正確に書かれています。一年分のトランスクリプトを残したいなら、既定値を後から発見するのではなく、今のうちにその数字を上げておいてください。同じページには逆のケース、つまり一つのプロジェクトの状態を意図的に消したい場合のための claude project purge も書かれています。

Mole はこれらのどれにも触れません。この五つのパスに加えて ~/.claude/file-history、~/.claude/plans、~/.claude/tasks、~/.codex/attachments、~/.codex/generated_images も、どれだけ古くても保護リストに入っています。年齢による除外はなく、「90 日より古い」といった例外もなく、それを有効にする設定もありません。かつてこれらのパスに年齢ゲート付きの例外を実装したことがありましたが、同じ日のうちに差し戻されました。古いトランスクリプトは、古びたトランスクリプトではないからです。

仕組みを覗く、サイズではなく復元コストで並べる

これが三つのカテゴリすべてを判断可能にするルールで、この記事の中で覚える価値があるのはこれだけです。すべての候補を、何ギガバイトあるかではなく、取り戻すのに何を払うかで順位付けしてください。

ローカルで再生成できるもの。 ビルド出力、インクリメンタルコンパイルの状態、バイトコードキャッシュ、DerivedData。これらを削除するコストは、今座っているマシンでの数分の CPU 時間であり、ネットワークは一切関わりません。自由に削除してください。一番大きいものから、あまり考えずに削除して構いません。

再構築に手間がかかるもの。 パッケージレジストリ、node_modules、CocoaPods、Python の仮想環境、vendor ディレクトリ、モデルの重み、iOS の DeviceSupport。どれもネットワークと、ロックファイルが指定する正確なバージョンをまだ配信しているレジストリを必要とし、時にはネイティブのツールチェーンも要ります。本当のコストは、良い回線での数分ではなく、電車の中でそもそも作業できるかどうかです。これらは一つずつレビューしてください。

取り返しがつかないもの。 チャットのトランスクリプト、エージェントのメモリ、プランファイル、プロジェクトの状態、ローカルのファインチューン。どれだけ CPU や帯域を積んでも取り戻せません。一括削除の対象には決してしてはいけませんし、うっかり選択できてしまうような扱いにもしてはいけません。

罠は、階層一と階層二が同じに見えることです。target/ と node_modules/ はどちらもプロジェクトルートにある大きなディレクトリで、どちらも依存関係の成果物でいっぱいで、どちらも .gitignore に載っていて、どちらも一つのコマンドで再生成できます。サイズで並べると隣り合います。ですが cargo build はすでにディスク上にあるソースから target/ を再構築するのに対し、npm ci はレジストリがまだ動いていて、ロックファイルがまだ解決できることを必要とします。片方はコーヒー休憩で済みますが、もう片方は午後まるごと止まるか、再インストールできない取り下げ済みパッケージに突き当たることもあります。この二つを混同することが、このカテゴリで最もよくある間違いで、だからこそ「一番大きいフォルダを消す」は、たとえ一番容量を空けられるとしても悪いアドバイスなのです。

これを Mole でやる

手作業のやり方はうまくいきますし、コストもかかりません。Mole が加えるのは、三つのカテゴリすべてが、階層の境界線をすでに適用済みの一つのレビューリストとして届くことです。どのドットディレクトリにトランスクリプトが入っているか、あなたが覚えておく必要はありません。

Clean ツールを開いてスキャンを実行してください。スキャンは無料でライセンスも不要です。すべての候補が正確なパス、所有者、測定済みのサイズとともに届き、リストを承認するまで何も動きません。確信度の低いものは未選択のまま届くので、既定の動作は常に小さいほうです。削除はアンリンクではなくゴミ箱送りなので、間違えても引っ張り出せばよく、バックアップからの復元は要りません。一括操作は、削除したものだけでなく、スキップしたものと失敗したものも報告します。

置き換えられた CLI バージョンについては特に、Mole が上で説明したランチャーの解決をあなたの代わりにやってくれます。各エージェント CLI のランチャーのシンボリックリンクを読み、生きているリリースまで解決して、そのリリースを候補集合から除外します。だから意図的な旧バージョン固定は、古いバージョンとして扱われることなくそのまま残ります。この挙動の背景にある実測ケースは Codex で、1.2 GB の五つのリリースのうち生きているのは一つだけでした。

Mole CLI は無料でオープンソースで、シェルから mo clean で同じ仕事をカバーします。破壊的なコマンドはすべて --dry-run に対応しているので、何かが動く前に完全なパスのリストを読めます。両方とも ~/.config/mole/whitelist の一つの保護リストと ~/Library/Logs/mole/operations.log の一つの操作ログを共有し、すべてローカルで完結し、アップロードもテレメトリもありません。

はっきり言っておく価値があります。Mole はバックアップではなく、マルウェア対策でもなく、ドライバやシステム拡張を伴うソフトウェアのベンダー製アンインストーラの代わりでもありません。モデルの重みや AI のチャット履歴は削除しませんし、削除を提案することもありません。それらは所有しているツール側に残るべきものです。

また積み上がらないようにする

三つの設定変更で、再び積み上がる分のほとんどをカバーできます。

Rust を一つのビルドディレクトリに集める。 CARGO_TARGET_DIR は「生成されたすべての成果物を置く場所」を設定するので、すべてのプロジェクトが一つのツリーに書き込むようになり、一か所で測定してクリーンできます。トレードオフは本物です。Cargo はビルドディレクトリをロックするので、一つの target ディレクトリを共有する二つのプロジェクトは並行してではなく一つずつビルドされます。日常的に並行ビルドを行うなら、分けたままにして代わりに定期的な一掃をスケジュールしてください。

グローバルストアは手作業ではなくスケジュールでプルーンする。 最近の Cargo は通常のビルドや fetch コマンドの中で、すでに未使用のエントリをグローバルキャッシュから取り除いています。npm は自分のキャッシュを自己修復するものと説明していて、メンテナンスコマンドとして npm cache verify を挙げています。ホームディレクトリのドットフォルダをいきなり削除するのではなく、こうしたポリシーに任せてください。ツールごとのコマンドは開発キャッシュを片付けるにあります。

エージェント CLI が自分でリリースをプルーンするか確認し、しないものと想定する。 この記事を書いている時点では、Codex と Claude Code のどちらにも、置き換えられたリリースバイナリをプルーンするドキュメント化されたフラグや設定キーは見つかりませんでしたし、Codex への要望も未解決のままです。Claude Code の cleanupPeriodDays はセッションデータを一掃するものであってバージョンのバイナリではないので、ここでは役に立ちません。それが変わるまでは、これは繰り返し発生する作業であり、エージェントがアップデートを出すたびに戻ってくるので、このリストの中で最も価値の高い項目です。

よくある質問

AI コーディングツールは実際どれだけディスクを使いますか

バイナリは一つあたり数百メガバイトですが、大事なのは積み重なった量です。この記事のために測定したマシンでは、四つのエージェント CLI がバージョンディレクトリ全体でおよそ 3.5 GB を占めていて、そのうち生きていたのはわずか 920 MB でした。セッションのトランスクリプトはおよそ 14 GB、一つの Rust の target/ ディレクトリだけで 24 GB でした。あなたの数字は、エージェントよりも言語によって違ってくるはずなので、この記事も含めて誰かの数字を信じるのではなく、この記事の冒頭にある二つの du コマンドを自分で実行してください。

古い Claude Code や Codex のバージョンを削除しても安全ですか

はい、先にランチャーを解決している限りは安全です。readlink -f "$(command -v claude)" か、使っている CLI に応じた同等のコマンドを実行し、表示されたパスは残して、兄弟をゴミ箱に送ってください。日付順に並べて最新を残すのはやめてください。意図的な旧バージョン固定も、途中で止まったアップデートも、どちらも最新のディレクトリを間違った答えにします。削除したあと、ゴミ箱を空にする前に一度 CLI を実行してください。

Mac クリーナーはエージェントのチャット履歴を削除しますか

一部のクリーナーはそうします。これらのファイルはログにそっくりに見えるからです。それがこのカテゴリ特有のリスクです。Mole は ~/.codex/sessions、~/.codex/archived_sessions、~/.codex/memories、~/.claude/projects、~/.grok/sessions のどれにも、どれだけ古くても触れません。どんなクリーナーを実行する前でも、これらのパスがその候補リストに現れるかどうか確認してください。実行前にリストを見せてくれないツールなら、それが答えです。

ビルドキャッシュを消すと何か遅くなりますか

次のビルドだけ一回、その後は遅くなりません。インクリメンタルコンパイルの状態は、二回目のビルドを一回目より速くするために存在するものなので、それを消すコストはプロジェクトごとにちょうど一回のコールドビルドです。デメリットはそれだけで、だからこそビルド出力は自由に削除していい階層に入り、レジストリへの往復が必要な node_modules のツリーはそこに入らないのです。

Ollama のモデルや Hugging Face のキャッシュはどうですか

ここでは意図的に範囲外にしています。これらのツールは、二つのモデルが同じ塊を共有できるコンテンツアドレス方式のストアを使っているので、ファイルを手で消すと、まだそれを参照しているモデルを孤立させてしまうことがあります。それぞれのツール自身の削除コマンドを使ってください。詳しくはAI ツールの残渣を取り除くで扱っています。

次にどこへ行くか

復元コストで並べ、リリースを消す前にランチャーを解決し、トランスクリプトには触らないでください。測定結果で一番大きかった行がパッケージストアだったなら、ツールごとのプルーンコマンドは開発キャッシュを片付けるにあります。Xcode だったなら、Xcode のストレージを片付けるが、再構築できるフォルダと残しておくべきアーカイブを分けています。モデルストアだったなら、AI ツールの残渣を取り除くが、なぜ所有ツールが削除を担うべきなのかを説明しています。