# データを失わずに Mac のキャッシュを消す
> キャッシュと状態・ユーザーデータを区別し、所有者を測ってそのクリーンアップ手段を使い、ゴミ箱を空にする前にアプリを確認します。
Published: 2026-06-17 | Updated: 2026-08-08
本当にキャッシュと呼べるものは再構築できますが、「Cache」という名前のフォルダが自動的に削除して安全とは限りません。アプリは、捨ててもよいファイルの隣に、オフライン用のダウンロード、セッション状態、インデックス、未同期の作業を混ぜて置くことがあります。役に立つのはパス一覧を覚えることではなく、所有者、再構築の元データ、キャッシュミスの結果を見極めることです。
ここでは、種類ごとの意味、保存場所、巻き添えを出さない消し方を整理します。
## キャッシュ、状態、データは別物です
アプリが本体バンドルの外に持つものは、次の3つに分かれます。意図的に置き換え可能なのは最初の1つだけです。
- **キャッシュ**は再計算できるものです。描画済みのサムネイル、コンパイル結果、速度のために残したダウンロードなど。消すと起動が遅くなる、ネットワークを使う、オフライン利用ができなくなる、といったことが起きます。
- **状態**はセッションです。開いていたウィンドウ、スクロール位置、下書き。失うと面倒ですが、致命的ではありません。
- **データ**は替えがききません。メッセージ、写真ライブラリ、保存したログイン情報。消すと本物の損失です。
キャッシュヒットならすぐ返ります。ミスなら元データを取りに行き、捨ててよいコピーを再構築し、次の要求のために保存します。
下に挙げるフォルダはこれらが混ざることがあるので、「キャッシュを全部消す」系のツールは危険です。`~/Library/Caches` 配下という事実は有用な手がかりではあっても、安全の完全な証明にはなりません。
## 理由があるときだけ消す
キャッシュ掃除が正当なのは、測った結果として必要な空き容量を食っているとき、アプリの公式トラブルシューティングが指示しているとき、インデックスが明らかに古いか壊れているときです。習慣としてやる意味はありません。macOS や多くのアプリは、容量が逼迫するとすでにキャッシュを追い出します。何でも再構築させると、しばらくのあいだ性能、バッテリー、ネットワーク負荷がかえって悪化することがあります。
## Mac 上でキャッシュがいる場所
- `~/Library/Caches/` はユーザー単位のアプリキャッシュで、日常いちばん大きいグループです。サブフォルダは `com.google.Chrome` のようにバンドル識別子で名付けられます。
- `/Library/Caches/` はシステム全体のキャッシュです。
- `/System/...` は System Integrity Protection で保護されており、触るものではありません。絶対に試さないでください。
環境設定には特に注意が必要です。`~/Library/Preferences` のファイルは設定であってキャッシュではなく、macOS は `cfprefsd` というデーモン経由でメモリ上にもキャッシュします。アプリ起動中に手で `.plist` を消すと、設定が失われたり、稼働中の設定状態に上書きされたり、アプリとそのキャッシュ状態が食い違ったりします。まずアプリ側で設定を変えてください。`defaults` は、文書化された preference ドメインとキーにだけ使い、汎用の掃除コマンドとしては使わないでください。
## 消す価値のあるキャッシュと、特に大きいもの
何かを消す前に、いちばん大きいキャッシュを見つけてください。
```
du -sh ~/Library/Caches/* 2>/dev/null | sort -h
```
重い行はだいたい次のとおりです。
- **ブラウザ。** Safari、Chrome などは、ページやメディアのキャッシュをギガバイト単位で持ちます。フォルダを直接消すより、ブラウザ自身の設定から消すほうが安全です。キャッシュと履歴・ログインを分けて扱えるからです。
- **開発ツール。** コーディング用の Mac では、他を圧倒します。Xcode の `~/Library/Developer/Xcode/DerivedData` は数十ギガバイトに達することがあり、パッケージマネージャも独自のストアを持ちます。`brew cleanup` は古い Homebrew のダウンロードを消し、`npm cache clean --force` は npm キャッシュを消し、`~/Library/Caches/` には Swift Package Manager、pip などのキャッシュがあります。npm のキャッシュは自己修復するので、まずは `npm cache verify` から。`npm cache clean --force` は、意図的な空き容量確保かトラブルシューティングのときだけに残してください。
- **QuickLook のサムネイル。** 必要に応じて再構築されます： `qlmanage -r cache`。
必ず、所有者アプリを先に終了してください。アプリ実行中はキャッシュファイルが開いているかメモリマップされていることが多く、書き込みの途中で消すと、アプリが依存するキャッシュデータベースを壊し、空き容量の掃除が壊れたアプリになります。
ブラウザキャッシュにはもうひとつ区別があります。Cookie、サイトデータ、履歴、保存パスワード、キャッシュされたページ資源は、別々のコントロールです。目的がディスクの回復なら、キャッシュされたコンテンツだけを選んでください。閲覧データを全部消すと、ログアウトしたり、オフライン用のサイト状態が消えたりするのに、実質的にキャッシュ以上の回収はほとんどありません。
## より安全なやり方： カテゴリごと、レビューあり
レビュー済みの掃除のあと、完了画面に出るのは見積もりではなく、実際に回収できた容量です。これは Mole の Clean 画面です。
手作業でもできますが、バンドル識別子やフォルダ名はいつも読めるとは限りません。クリーナーは、触る前に所有者、パス、サイズ、カテゴリを見せるべきで、プロファイル、書類、モデルストア、会話履歴は設計上除外するべきです。[Mole](https://mole.fit/) の Clean 画面は、そのレビュー優先のモデルに従っています。広い教訓としては、見つかった件数の派手さより、スキップリストとパス検証のほうが大事です。
## 内部： 「消して安全」が実際に見ているもの
ここは飛ばしても構いませんが、「カテゴリごと、レビューありで消す」がスローガン以上である理由がわかります。次は、[Mole のオープンソース CLI](https://github.com/tw93/Mole)（`lib/clean`）のキャッシュロジックから、実務上のチェックの形です。ネイティブアプリは CLI を呼ばず、これらの多くを Swift で同様に実装しています。
候補がゴミ箱に入るのは、レビューと確認を経たときだけです。ツールの状態、明示的なガードファイル、保護ドメインが、レビューに進むか触れずに残すかを決めます。
細部こそが要点です。安全な実装は、可能ならパッケージマネージャ自身の掃除インターフェースを使い、デーモンが動いているあいだはビルドキャッシュに触れず、解決したパスをすべて検証し、遅いサイズ計測にはタイムアウトをかけ、明示的に保護されたフォルダを残します。所有者ツールが無い、またはカテゴリが曖昧なら、推測よりレビューのほうが安全です。Caches フォルダ全体の再帰削除は、こうしたチェックをすべて迂回します。
## キャッシュの名目でも消してはいけないもの
- **AI アシスタントのチャット履歴とトランスクリプト。** キャッシュの近くにありますが、替えのきかないデータです。空き容量のために消さないでください。
- **環境設定と保存ログイン。** 捨ててよいキャッシュとは別物です。
- **`/System` 配下のすべて。**
- **用途が特定できないフォルダすべて。**
どの Mac 掃除でも安全を保つルールはこれです。ファイルの用途がわからないなら、消さない。
## 安全なキャッシュ掃除の手順
先に測る。所有者を終了する。組み込みのストレージや掃除コマンドを使う。カテゴリは一度にひとつ。ゴミ箱を空にする前にアプリを開き直す。環境設定、プロファイル、チャット、書類、正体不明の Application Support データは、キャッシュ扱いしない。空き容量やトラブルシューティングの利益が、再構築とダウンロードのコストを上回るときだけ消す。このやり方は「全部削除」より遅いですが、アプリ内部が変わっても安全に保てます。
---
Canonical HTML page: https://mole.fit/ja/blog/how-to-clear-cache-on-mac
Blog index for agents: https://mole.fit/ja/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt