AI Mac クリーナー、モデルが決めていいことと決めてはいけないこと

「AI Mac クリーナー」という言葉は、二つの違う製品を指します。一つはどこかにモデルを内蔵したクリーンアップアプリで、提案の賢さを売りにしています。もう一つは、Claude Code や Cursor、Ollama とそのキャッシュがこの一年で静かに占領してきたディスクを取り戻すツールです。2026 年にこのフレーズを検索する大半の人が求めているのは後者です。それでも先に前者に答えておく価値があります。その答えが、後者のグループを信じていい度合いを決めるからです。

前半、モデルが実際に決めているのは何か

AI を謳うクリーナーは、少なくとも四段階あるパイプラインのうちの一段階について主張しています。

1. 列挙する。 ディスクを走査して計測する。du に似た作業で、判断は一切含まれません。
2. 帰属させる。 各パスをどのアプリやツールチェーンが所有しているかを決める。
3. 順位付けして説明する。 4000 個の候補のうちどの 12 個を見る価値があるか決め、それぞれが何かを一文で言う。
4. 決めて削除する。 何を削除して安全か決め、削除する。

段階 2 と 3 は本当に曖昧な問題で、モデルは本当にそこで役に立ちます。段階 4 は種類の違う問題で、モデルはそれには向いていない道具です。AI クリーナーをめぐる議論のほとんどは、実はベンダーがどの段階を指しているのかという議論です。

モデルが本領を発揮する場所

帰属の判断は、正直なところ本当に難しいケースです。~/Library/Application Support/Foo Labs が 3 GB を占めているのに、ディスク上に Foo Labs という名前のアプリがない、という状況を考えてください。証拠は弱く散らばっています。フォルダ自身の plist に埋まったバンドル識別子の断片、~/Library/HTTPStorages の一致する接頭辞、~/Library/Saved Application State 配下の .savedState バンドル、/var/db/receipts のインストールレシート。名前の一致はすぐに破綻します。ベンダーはある場所には Foo Labs と書き、別の場所には com.foolabs.editor と書くからで、手作業のカタログは上位数百のアプリまではカバーできても、そこから先は崖のように落ち込みます。これはまさにモデルがルールに勝てる形です。弱い手がかりがたくさんあり、決め手になるものはなく、誰も最後までカタログ化しないロングテールがあるという状況です。

順位付けも同じ形をしています。4000 個のパスと 60 GB を返すスキャンは、結果ではなく次の問題です。説明はさらに簡単です。~/Library/Caches/com.apple.nsurlsessiond を平易な一文にするのは、翻訳のような作業だからです。この三つの仕事にモデルを使っていて、そう明言しているツールは、本物の機能を謳っています。

最後の関門はなぜ決定的でなければならないか

削除の判断には、モデルが提供できない三つの性質が必要です。

決定性。 同じディスク、同じバージョンなら、毎回同じ答えが返ること。温度をゼロにしても手に入りません。プロンプトにはあなたのマシンの中身が乗っているからです。アプリを一つ追加すればファイル一覧が変わり、判断の拠り所になるトークンも一緒に変わります。あなたの Mac では成り立つのに同僚の Mac では成り立たない安全ルールは、安全ルールではありません。

事前の監査可能性。 保護リストはパスの接頭辞の集合で、全部で一分もあれば読み切れますし、二つのリリース間で差分も取れます。重みとプロンプトは、何が拒否されるかのリストとして読むことができないので、境界を越える前にそれを見せてくれるものが何もありません。

事後の監査可能性。 決定的なルールが間違ったものを削除したときは、再現可能なバグが手に入ります。このパス、それを許した行、そして今失敗しているテストです。モデルがやらかしたときに残るのはトランスクリプトで、修正はプロンプトの編集になり、その編集が他のすべてのケースに与える影響は測定されません。

失敗のパターンも非対称です。順位付けの失敗はスクロール一回分のコストで済みますが、~/.claude/projects の誤削除は持っているすべてのトランスクリプトを失うコストです。だからこれは「AI は良い、AI は悪い」という枠組みではなく、パイプラインの真ん中で分かれる話です。間違えても払う代償が注意力で済む部分は確率的でよく、間違えるとデータを失う部分は決定的でなければなりません。

Mole はどちら側にいるか

Mole はモデルを一切搭載せず、推論も一切実行しません。あるパスが削除候補になり得るかどうかは、アプリにコンパイル済みの、ブロック対象の相対接頭辞の固定配列によって決まります。.ollama/models、.lmstudio/models、.cache/huggingface、.cache/torch、.claude/projects、.codex/sessions、.grok/sessions、Library/Caches/com.apple.e5rt.e5bundlecache といった項目が入っています。ユーザーが編集できる側はただのテキストファイルで、cat ~/.config/mole/whitelist で読めます。無料の Mole CLI は GPL-3.0 のオープンソースで、同じリストを適用しているので、それを強制しているコードは公開されています。

最後の項目は、この議論の縮図です。com.apple.e5rt.e5bundlecache は ~/Library/Caches の下にあり、名前に入っている単語は cache なので、世の中のあらゆるヒューリスティックはこれを使い捨てとして分類します。実際には Apple Neural Engine のコンパイル済みモデルが入っていて、アプリがモデルを読み込んだ状態でこれを消すと、マシンを再起動するまで認識系の呼び出しが壊れます。この項目が保護されているのは、誰かがその失敗を実際に踏んで、この一行を書いたからです。

だから、ここでのどんなツールに対する実践的なテストも一つの問いに集約されます。四つの段階のうちモデルはどれを担っているのか。列挙、帰属、順位付け、説明であれば信頼できる答えです。「何を削除して安全か決める」という答えが返ってきたら、続けてそのリストを見せてほしいと聞いてください。リストがなければ、レビューするものが何もありません。

後半、AI ツールが残したものを片付けるツール

これが大半の人が本当に求めている問いです。フットプリントは四種類のデータに分かれ、それぞれにルールが異なり、これらを混同するところで事故が起きます。

• ツールのキャッシュとログ。 ~/Library/Caches/claude-cli-nodejs、Cursor の Electron キャッシュ、~/.claude 配下のテレメトリとデバッグ用ディレクトリ。再生成できて、面白みもありません。
• トランスクリプトとプロジェクト状態。 ~/.claude/projects、~/.codex/sessions、~/.grok/sessions。スキャンで一番驚かれることが多く、しかも取り返しがつきません。
• 古い CLI のバージョン。 自動更新するエージェント CLI は、前のリリースを置き去りにします。Codex では 1 リリースあたりおよそ 300 MB で、5 世代積み重なると生きているのは 1 つなのに合計 1.2 GB になります。
• モデルの重み。 ~/.ollama/models、~/.cache/huggingface/hub、LM Studio のモデルディレクトリ。群を抜いて最大で、ダウンロードしたツールが所有しています。

測る前に選ばないでください。

du -sh ~/.claude ~/.codex ~/.ollama/models ~/.cache/huggingface 2>/dev/null | sort -h

すでにこれらのパスを知っている、レビュー前提の一掃なら Mole

Clean はまずスキャンを終え、何かが動く前にレビューできる結果を見せます。候補の各行には正確なパス、所有者、サイズが付き、スキャナーが確信を持てないものは未選択のまま並ぶので、既定のクリックは常に小さいほうの動作です。削除はアンリンクではなくゴミ箱送りで、操作のたびに ~/Library/Logs/mole/operations.log に追記され、そこでは TRASHED と DELETED は別の言葉として区別されます。

AI ツールに特有の重要な挙動が二つあります。古いエージェント CLI のバージョンディレクトリは候補に出しますが、生きているリリースが候補になることは決してありません。ランチャーの参照先を先に解決して固定するので、実行中のバージョンはバージョン番号の推測ではなく構造そのものによって除外されます。そしてアンインストールは名前のマッチングではなく所有関係を推論するので、あるベンダーの一つのアプリを削除しても、まだインストールされている兄弟アプリが所有する共有の Application Support 親フォルダは出てきません。

作業の手順です。Clean を開き、スキャンが終わるのを待ち、大きく見えるグループを展開し、残したいものはチェックを外し、クリーンアップを実行して解放された容量を確認してください。スキャンは無料で、有料機能もそれぞれ 2 回まで無料で試せるので、19 ドルの価値があるかどうかを決める前にレビュー全体を自分で検証できます。

ターミナルから離れたくないなら Mole CLI

これは別の無料製品で、GPL-3.0 のオープンソースであり、brew install mole でインストールします。常にまずプレビューしてください。

mo clean --dry-run
mo purge --dry-run

mo clean はキャッシュとログを扱い、mo purge は古いプロジェクトのビルド成果物を対象にします。破壊的なコマンドはすべて --dry-run に対応しているので、まず正確なパスのリストを読めます。Mac アプリ版と同じ保護リストと操作ログを共有しています。フラグを外す前に知っておくべき違いが一つあります。CLI のキャッシュクリーンアップはファイルを完全に削除しますが、アンインストールと残渣削除は今もゴミ箱送りです。

この問題のために作られたオープンソースのターミナルツール、cc-cleaner

cc-cleaner は MIT ライセンスで、Python 3.10 以降が必要、pipx install cc-cleaner でインストールできます。Claude Code、npm、uv、cargo、Docker、Playwright、ブラウザキャッシュ、そして Hugging Face、PyTorch、Whisper、Ollama をカバーする AI/ML モデル群を含む 22 種類のクリーナーを備えています。cc-cleaner status はサイズの表を出力し、cc-cleaner clean は対話的なピッカーを開き、-n はドライランです。

リスクモデルは明示的です。Safe に分類された項目は既定でクリーンアップされ、Moderate と Dangerous は --force が必要で、README では「会話のトランスクリプト、共有ストア」を Moderate に分類しています。あとはソースコードが教えてくれます。Ollama 用クリーナーは ~/.ollama/models を丸ごと一つのディレクトリとして削除し、Hugging Face 用クリーナーは ~/.cache/huggingface/hub と datasets に同じことをし、Claude 用クリーナーは ~/.claude/projects 配下の *.jsonl トランスクリプトを候補に出します。削除は shutil.rmtree と Path.unlink で行われるので、ゴミ箱には何も入りません。安全層は禁止システムパスの固定集合と、対象がすべてホームディレクトリ配下にあることを要求する仕組みで、人間が書いた決定的なリストであり、それ自体はまさにあるべき姿です。違いは厳密さではなく、線をどこに引くかにあります。cc-cleaner はモデルストアとトランスクリプトをフラグの向こう側に置き、Mole はそれらを拒否します。

同じ領域をメニューバーアプリでカバーしたいなら DevCleaner

DevCleaner は macOS 14 以降向けのメニューバーユーティリティで、現行バージョンは 1.9.0、Xcode の DerivedData や Gradle から npm、Docker まで 23 のエコシステムをカバーし、Claude、ChatGPT、Cursor、Ollama、LM Studio 専用のスキャナーも備えています。Safe な項目は既定で削除され、Warning な項目は「あなたの判断次第」、Danger な項目は決して事前選択されず、認証情報とセッションファイルには固定の拒否リストがあり、稼働中のアプリのキャッシュに触る前には警告が出ます。基本のクリーンアップは無料で、Pro は買い切りか年間サブスクリプションで販売されています。最新の数字はベンダーページで確認してください。削除がゴミ箱に行くかどうかはサイトに書かれていないので、初回実行の前に確かめる価値があります。

MacPaw も同じ成果物を狙った CleanMyMac CLI をパブリックベータとして、Homebrew cask 経由で出しています。プロプライエタリで、リポジトリはソースコードではなく課題管理のためのものであり、挙動は今も明示的に変化しているので、公開されている説明よりも実行時の確認ステップに表示される内容を読んでください。

エージェントに自分のディスクを向けさせる

最後の選択肢は、クリーンアップツールを飛ばして Claude Code のようなエージェントに直接ディスクを片付けさせることです。公開されているクリーンアップ用スキルの一つを経由することもできます。この方法には本物の利点があり、ここで挙げた他のどれも持っていません。エージェントは誰もカタログ化していないレイアウトについて推論できます。先月リリースされたばかりのフレームワークでも、私的なツールチェーンでも、あなたにしか分からない配置のホームディレクトリでもです。

同じくらいはっきり評価しておく必要があります。シェルコマンドは推論の瞬間に、あなたの実際のファイルシステムに対して生成されるので、実行される内容は実行される前に誰にもレビューされません。自分で求めない限りドライランはありません。被害が及ぶ範囲はホームディレクトリ全体で、空だった変数から組み立てられた rm -rf は長い歴史を持つ失敗のパターンです。前半の議論が、安全網を外した状態で当てはまります。判断は確率的で、それが最後の関門に直結しているということです。

四つの防護策は、ほとんどコストをかけずに導入できます。

• 削除を自分で組み立てさせず、プレビューフラグを持つツールを操作させる。 公開されているある Claude Code 用スキルは mo CLI をラップし、mo clean の前に mo clean --dry-run を必須にして、ドライランの出力を全部表示し、タイプによる確認を求めます。エージェントは対象を選ぶだけで、削除を実行するのは決定的なツールです。
• 権限設定で rm を事前承認しない。 削除コマンドは一つずつ承認し、要約ではなくパスそのものを読んでください。
• 既定をゴミ箱にする。 Homebrew の trash や ~/.Trash への mv を使えば、どんな間違いも復元できます。
• 作業対象を区切る。 一つのディレクトリだけを指定し、実行前に du -sh、実行後に df -h を求めて、回収できたと主張する量が推定ではなく実測になるようにしてください。

モデルストアは、それをダウンロードしたツールのもの

ここでは汎用のクリーナーを道具にするべきではありません。上で挙げたものも含めてです。Ollama も Hugging Face も、モデルが塊を共有するコンテンツアドレス方式のストアを保持しているので、どの塊がまだ参照されているかは所有ツールにしか分かりません。ollama ls と ollama rm <model>、hf cache ls と hf cache rm model/<repo> --dry-run を使ってください。塊のファイルを手で消すとなぜモデルが孤立するのかは、AI ツールの残渣を取り除くで扱っています。

比較する

境界をはっきり言っておく

Mole はマルウェア対策ではなく、バックアップでもなく、ドライバや VPN コンポーネント、システム拡張を伴うソフトウェアのベンダー製アンインストーラの代わりでもありません。モデルの重みや AI のチャット履歴も削除しません。だから 200 GB の問題がまるごとモデルライブラリのせいなら、Analyze でそのライブラリの形を見せたうえで、あとは Ollama や LM Studio に仕事を譲ります。これは意図的な境界であって、後で埋めるべき穴ではありません。

一つを選ぶ

200 GB のビルド出力と十数個のツールチェーン。 容量はキャッシュ、古い node_modules、DerivedData、Docker にあり、AI 固有のものではありません。レビュー前提の一掃か mo clean --dry-run から始め、それぞれ専用のプルーンコマンドが必要なストアについては開発キャッシュを片付けるで進めてください。cc-cleaner はリスク階層を先に読んでおけば、二巡目として悪くありません。

大きなローカルモデルライブラリ。 モデルの重みについては汎用クリーナーを完全に飛ばしてください。ollama ls、hf cache ls、LM Studio の My Models 画面だけが、共有された塊を安全に解放できるツールです。ディスクマップでストアの場所を見つけ、変更は所有ツールに任せてください。

Cursor や Claude Code がディスクを食っているのに気づいたばかり。 一番扱いやすいケースです。キャッシュとログは再生成でき、古い CLI バージョンは純粋な無駄で、トランスクリプトだけは触ってはいけません。ここで挙げたレビュー前提のツールならどれでも対処でき、手順ごとに詳しく書いたものはAI コーディングツールを片付けるにあります。

よくある質問

AI 搭載の Mac クリーナーは普通のクリーナーより安全に削除しますか

今分かっている証拠の限りでは、そうとは言えません。孤立したフォルダをどのアプリが所有しているか決めることや、何に注目すべきか順位付けすることでは、モデルはルールに勝てます。それらは弱い手がかりの多い曖昧な問題だからです。あるパスを削除して安全かどうかを決めるには決定性と監査可能なリストが必要で、モデルはそのどちらも提供しません。ベンダーに、自社のモデルがパイプラインのどの段階を実行しているのか聞いてください。「何を削除して安全か決める」という答えが返ってきたら、リストを見せてほしいと促すきっかけとして受け取ってください。

Claude Code に Mac を片付けさせても安全ですか

これは最も柔軟な選択肢であり、最も範囲が定まっていない選択肢でもあります。コマンドは推論の瞬間に生成され、あなたのホームディレクトリに対して実行されます。自分で求めない限りプレビューはありません。もしこれをやるなら、エージェント自身に rm -rf を組み立てさせるのではなく、ドライランフラグを持つツールを操作させ、権限設定で rm を事前承認せず、削除はゴミ箱送りにし、一度に一つのディレクトリだけに限定してください。

Mac クリーナーは Ollama のモデルや Claude Code の履歴を削除しますか

完全にツール次第で、だからこそ最初に確かめるべき問いです。Mole は ~/.ollama/models、~/.lmstudio/models、~/.cache/huggingface、~/.claude/projects、~/.codex/sessions、~/.grok/sessions を、どれだけ古くても削除の関門でブロックするので、候補になることが決してありません。cc-cleaner はモデルディレクトリと Claude Code のトランスクリプトを Moderate リスクに分類し、--force を渡せば削除します。ツールのリスク階層は初回実行の後ではなく前に読んでください。

AI コーディングツールを一年使ったあと、実際に容量を食っているのは何ですか

たいていの場合、みんなが思うキャッシュではなく、古い CLI バージョンとトランスクリプトです。自動更新するエージェント CLI は 1 リリースあたり数百メガバイトを置き去りにすることがあり、Codex では 5 世代積み重なると生きているのは 1 つなのに合計およそ 1.2 GB になります。~/.claude/projects 配下のトランスクリプトは静かに積み重なり、スキャンで一番驚かれやすい項目です。だからこそ一掃の対象に含めるのではなく、除外すべきなのです。

関連記事

• Mac 上の Ollama と LM Studio のモデルを片付ける、コンテンツアドレス方式のモデルストアの仕組みについて。
• ビルドを壊さずに開発キャッシュを片付ける、パッケージマネージャのストアと散らばった node_modules について。
• AI コーディングツールを片付ける、パスごとの手順版について。