はじめに
「ストレージの空きがあと少しです」——Macを使っていて、この通知にビクッとした経験はありませんか？
私もそうでした。空き容量は27GB。動画編集の書き出しや、ちょっと大きめのデータセットを置こうとするたびに足踏みする。かといって「何を消せば安全なのか」がわからない。とりあえず~/Library/Cachesを眺めて、よくわからないまま閉じる。その繰り返しでした。
そこで今回、Claude Code（ターミナルで動くAIエージェント）にパソコンへのアクセス権を渡して、「不要なストレージを消して空き容量を増やして」と丸投げしてみました。結果から言うと、空き容量は27.9GB → 68.5GBになりました。約40GBの回収です。
この記事は、その一部始終の体験談です。何を消したのか、どこでハマったのか、AIに任せて感じたことまで、全部書きます。
対象読者
- Macのストレージがじわじわ圧迫されていて、でも何を消せばいいかわからない人
- Claude Codeのような端末操作系AIエージェントに、実作業をどこまで任せられるのか知りたい人
最初に大事なことを。この記事で出てくる削除コマンドは、私の環境で私の判断のもとに実行したものです。rm -rfを含む破壊的な操作は、パスを一文字間違えるだけで必要なファイルを巻き込みます。**実際にコマンドを実行する場合は、内容を理解したうえで自己責任でお願いします。**AIに任せる場合も、提案された削除内容を一つずつ自分で確認してから承認するのが大前提です（私も全部そうしました）。
なぜ自分で片付けられなかったのか
正直に白状すると、これまでの私のストレージ整理は「とりあえずキャッシュ削除」で止まっていました。
ブラウザの設定からキャッシュをクリアして、数GB空いて、満足して終わり。でも本当の容量泥棒は、もっと見えにくいところに潜んでいるんですよね。~/Library/Application Supportの奥とか、開発プロジェクトのnode_modulesとか、いつ落としたかも覚えていないインストーラとか。
それらを一個ずつduコマンドで追いかけるのは、面倒くさい。面倒くさいから、やらない。やらないから、また通知が来る。この無限ループから抜け出せずにいました。
あなたの~/Library、最後に中身を覗いたのはいつですか？
実際にやったこと（時系列）
ここからが本題です。Claude Codeとどう進めたかを、時系列で追っていきます。ポイントは、いきなり消させるのではなく「現状分析 → 提案 → 承認 → 削除」の順を踏ませたことです。
① まず現状分析を全部やらせる
最初の指示はシンプルに「まず現状把握をして、何が消せるか提案して」。Claude Codeはdfやduを自分で叩いて、ホームディレクトリの内訳を出してきました。
# ホーム直下を大きい順に
du -sh ~/* 2>/dev/null | sort -rh | head -20
68G /Users/****/Library
5.4G /Users/****/開発
474M /Users/****/Downloads
107M /Users/****/Pictures
...
Libraryが68GBで断トツ。さらに掘るとApplication Supportが47GB、Cachesが14GB。ここで「容量を食っているのは普段見ないところ」というのが数字で見えました。手で一個ずつduを打つのと違って、一瞬で全体マップが出てくるのは気持ちいい。
② 安全なキャッシュから削除（約20GB）
いきなり大物に手を出さず、まず「消しても自動で再生成される」安全なものから着手しました。各種キャッシュ、pip、Homebrew、VS Codeの古いログなどです。
pip cache purge
brew cleanup -s
# ~/Library/Caches の中身をクリア（ディレクトリ自体は残す）
find ~/Library/Caches -mindepth 1 -maxdepth 1 -exec rm -rf {} +
この時点で約20GB。pipのキャッシュだけで2GBあったのには笑いました。
③ 15GBの"犯人"＝エアリアル壁紙の動画
内訳を見ていて一番ギョッとしたのがこれです。
15G /Users/****/Library/Application Support/com.apple.wallpaper/aerials/videos
macOSの「空撮スクリーンセーバー／ダイナミック壁紙」の動画ファイルが、15GBも溜まっていました。あの綺麗な空撮映像、4K動画の実体としてディスクに居座っていたんですね。壁紙を再選択すれば再ダウンロードされるので、思い切って削除。
com.apple.wallpaper/aerials/videosは、エアリアル壁紙を使っていると勝手に増えていきます。15GBは私の例ですが、人によってはもっと大きいかもしれません。一度du -shで覗いてみる価値ありです。
④ 開発系の残骸（node_modules / .venv / npmキャッシュ）
エンジニアのMacといえばこれ。私は「今アクティブなプロジェクトは残し、1ヶ月以上触っていないものの依存だけ消す」という方針にしました。Claude Codeに各プロジェクトの最終更新日を出させて、線引きしたわけです。
# プロジェクトごとの最終更新日を出して、放置プロジェクトを特定
# （現役のものは除外して .venv / node_modules を削除）
放置案件の.venvが合計1GB弱、node_modulesがそれなり。さらに地味に効いたのが~/.npmのグローバルキャッシュで、4.2GBありました。npm cache clean --forceで一掃。インストール済みプロジェクトには影響しません（次回installが少し遅くなるだけ）。
⑤ 一時ファイル・ダウンロード残骸
最後に一時ファイルの掃除。ここで一番「探してよかった」と思ったのが、ダウンロードの中断ファイルです。
# 中断したダウンロードの一時ファイルを横断検索
find ~/Library -name "CFNetworkDownload_*.tmp" -exec du -ch {} + | tail -1
908M total
エアリアル壁紙のダウンロードが何度も中断していたらしく、CFNetworkDownload_*.tmpという一時ファイルが20個近く、合計908MBも放置されていました。完全にゴミです。これと、ブラウザ起動中に作られる一時クローン（code_sign_clone）、導入済みアプリの古い.dmgインストーラなどを削除。
驚いたポイント
ここからが、AIと一緒にやって学びが多かったところです。
「消したのに空きが増えない」問題
途中、4.9GB分を削除したのに、空き容量が1.4GBしか増えないという現象に遭遇しました。「えっ、ちゃんと消えてないの？」と焦りました（実際~/.npmは44MBまで減っていたのに）。
原因はAPFSのローカルスナップショットでした。削除したファイルのブロックが、OSアップデート由来のスナップショットに一時的に保持され、空き容量にすぐ反映されなかったのです。
tmutil listlocalsnapshots /
com.apple.os.update-...
com.apple.os.update-...MSUPrepareUpdate
削除した領域はmacOS上「purgeable（消去可能領域）」として扱われ、システムが容量を必要としたときや、数時間〜24時間で自動的に回収されます。すぐ反映させたいなら再起動が確実です。「消したのに増えない」は故障ではなく、APFSの正常な挙動なんですね。これは知らないと確実に焦ります。
やってみて感じたこと（人間 vs AIエージェント）
一番大きかったのは、判断の往復が速いことです。
従来なら「duを打つ → 結果を読む → 次にどこを掘るか考える → またduを打つ」を全部自分の手でやっていました。Claude Codeはこの「探索 → 要約 → 次の一手」を高速で回してくれて、私は提案に対して「OK」「それは残して」と判断するだけ。実際、私が消すのを止めた場面もあります。「過去案件のCSVは残す」「iCloudのファイルは触らない」といった、文脈を持っている人間にしかできない判断ですね。
逆に言うと、丸投げと言いつつ、最終的な意思決定は全部こちらがやっています。AIが「これ消せます」と出してきたものを鵜呑みにせず、一つずつ確認して承認する。この分担が、安心して任せられた理由だと思います。
正直、ストレージ整理がこんなに捗るとは思っていませんでした。
今日から試せること
真似しやすいように、私が使ったプロンプトの型とコマンドを置いておきます。
最初の一手は、このくらいざっくりで大丈夫でした。
このMacの空き容量を増やしたい。
まず現状分析として今のシェルを叩いて状況を把握したうえで、
何が消せる対象なのか、リスク別に提案して。削除はこちらの承認を得てから。
自分の手で現状把握だけしたい人向けに、効いたコマンドも。
# ホーム直下を大きい順に
du -sh ~/* 2>/dev/null | sort -rh | head -20
# Application Support / Caches の内訳
du -sh ~/Library/Application\ Support/* 2>/dev/null | sort -rh | head -20
du -sh ~/Library/Caches/* 2>/dev/null | sort -rh | head -20
# 中断したダウンロードの一時ファイルを探す
find ~/Library -name "CFNetworkDownload_*" -exec du -ch {} + | tail -1
# ローカルスナップショットの確認（消したのに増えないとき）
tmutil listlocalsnapshots /
今回回収できた内訳（合計約40GB）
| 対象 | 削減量 |
|---|---|
| 各種キャッシュ（Caches / .cache / pip / brew / VS Codeログ） | 約20GB |
| エアリアル壁紙の動画 | 15GB |
| npmキャッシュ + Google Updaterキャッシュ | 約4.9GB |
| 一時ファイル（code_sign_clone / var/folders / ログ） | 約3.2GB |
| 放置プロジェクトの .venv / node_modules | 約1.1GB |
| ダウンロード残骸（CFNetworkDownload tmp） | 908MB |
| Next.jsビルドキャッシュ（.next） | 552MB |
| エディタの旧拡張バージョン | 213MB |
開始時の空き 27.9GB → 最終 68.5GB（約 +40.6GB）
くり返しになりますが、rm -rf系のコマンドは取り返しがつきません。パスをよく確認し、自分が何を消そうとしているか理解したうえで実行してください。不安なものは消さない、が安全策です。
おわりに
「何を消していいかわからない」で止まっていた私が、半日で40GBの空きを手に入れました。技術的に難しいことは何もしていません。やったのは、面倒で後回しにしていたduの往復をAIに任せて、自分は判断に集中しただけです。
もしあなたのMacも空き容量に追われているなら、まずはdu -sh ~/Library/* | sort -rhを一回叩いてみてください。たぶん、思ってもみなかった犯人が見つかります。
次はこの整理を定期実行（スケジュール化）できないか試してみようと思っています。やってみたら、また書きます。もし試した人がいたら、どこで何GB空いたか教えてもらえると嬉しいです。