# Macのキャッシュ削除：~/Library/Cachesの見極め方

> キャッシュと状態・データを分け、所有者と容量を確認してから消し、削除後にアプリの動作を検証します。

Published: 2026-06-17 | Updated: 2026-09-28

本当にキャッシュと呼べるものは再構築できますが、「Cache」という名前のフォルダが自動的に削除して安全とは限りません。アプリは、捨ててもよいファイルの隣に、オフライン用のダウンロード、セッション状態、インデックス、未同期の作業を混ぜて置くことがあります。役に立つのはパス一覧を覚えることではなく、所有者、再構築の元データ、キャッシュミスの結果を見極めることです。

ここでは、Macのキャッシュを削除（クリア）する前に知っておきたい種類ごとの意味、保存場所、巻き添えを出さない消し方と、消したあとに何が起きるかを整理します。

Appleの [Libraryディレクトリの説明](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html)では、キャッシュは再生成でき、アプリが永続性に依存してはいけないデータとされています。Application Supportとは回復条件が違います。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/cache-lifecycle.webp" width="1360" height="454" loading="lazy" alt="キャッシュ照合が高速なヒットと、元データを取得してキャッシュを再構築するミスに分岐します">
  <figcaption>キャッシュヒットならすぐ返ります。ミスなら元データを取りに行き、捨ててよいコピーを再構築し、次の要求のために保存します。</figcaption>
</figure>

## `~/Library/Caches` と `/Library/Caches` は範囲が違います

- `~/Library/Caches` はユーザー単位のアプリキャッシュで、日常いちばん大きいグループです。サブフォルダは `com.google.Chrome` のようにバンドル識別子で名付けられます。
- `/Library/Caches` はシステム全体のキャッシュです。
- `/System` はSystem Integrity Protectionで保護されており、触るものではありません。絶対に試さないでください。

Appleはバンドル識別子の慣習を文書化していますが、見慣れた名前は安全の保証書ではありません。ひとつのアプリが、キャッシュデータベース、セッション状態、ダウンロードを隣り合わせに置くことがあります。サンドボックス化されたアプリは、関連するデータをユーザーのCachesではなくContainersの中に置くこともあります。

Appleの[ファイルシステム概要](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html)が示すように、`/System/Library` は対象外です。Cachesのルートを再帰削除せず、権限エラーが出ても一般的な削除に `sudo` を足さないでください。

## 決める前に中身を分類する

アプリが本体バンドルの外に持つものは、次の3つに分かれます。意図的に置き換え可能なのは最初の1つだけです。

- **キャッシュ**は再計算できるものです。描画済みのサムネイル、コンパイル結果、速度のために残したダウンロードなど。消すと起動が遅くなる、ネットワークを使う、オフライン利用ができなくなる、といったことが起きます。
- **状態**には、開いていたウィンドウ、スクロール位置、下書きなどが含まれます。未保存の作業や唯一の下書きが失われることもあるため、単なるキャッシュとして削除しません。
- **データ**は替えがききません。メッセージ、写真ライブラリ、保存したログイン情報。消すと本物の損失です。

上に挙げたフォルダはこれらが混ざることがあるので、「キャッシュを全部消す」系のツールは危険です。`~/Library/Caches` 配下という事実は有用な手がかりではあっても、安全の完全な証明にはなりません。

| 種類 | 削除で失うもの | 基本の対応 |
| --- | --- | --- |
| キャッシュ | 再構築の時間、電力、通信量 | 所有者を確認し、アプリの清掃機能を使う |
| 状態・セッション | タブ、Cookie、下書き、ログイン状態 | 明示されたリセット以外は残す |
| データベース・索引 | 検索、オフライン記録、唯一のローカルコピー | 所有者が再構築可能と明記した場合だけ扱う |
| ユーザーデータ | 書類、写真、チャット、モデル、認証情報 | キャッシュとして扱わない |

キャッシュ掃除が正当なのは、測った結果として必要な空き容量を食っているとき、アプリの公式トラブルシューティングが指示しているとき、インデックスが明らかに古いか壊れているときです。習慣としてやる意味はありません。macOSや多くのアプリは、容量が逼迫するとすでにキャッシュを追い出します。何でも再構築させると、しばらくのあいだ性能、バッテリー、ネットワーク負荷がかえって悪化することがあります。

Application Support、Containers、Group Containers、環境設定、キーチェーン、隠しツールディレクトリは、所有者が特定の子要素を再構築可能と示すまで、状態またはユーザーデータとして扱います。

## まず大きい所有者を測る

何かを消す前に、いちばん大きいキャッシュを見つけてください。

```
du -sh ~/Library/Caches/* 2>/dev/null | sort -h
du -sh /Library/Caches/* 2>/dev/null | sort -h
```

下から読みます。最後の数行がいちばん大きい項目です。ひとつずつアプリ、バンドル識別子、文書化されたツールのキャッシュに結びつけ、所有者がはっきりしないならそこで止めます。所有者がはっきりした50 MBのキャッシュのほうが、正体のわからない20 GBのディレクトリより判断しやすいはずです。この数字は測定値であって、回収できる容量の約束ではありません。ファイルが開いたままのこともあり、APFSはクローンとスナップショットでブロックを共有し、Finderと `du` とシステム設定では容量のまとめ方が違います。

権限エラーが出たら止めます。結果を埋めるために `sudo` を足す場面ではありません。
`~/Library/Caches` は現在のユーザー向けですが、`/Library/Caches` は複数ユーザーやシステムサービスに影響する可能性があります。

Appleの [Macストレージガイド](https://support.apple.com/102624)でいう「システムデータ」は、ほかの分類に入らないファイルの集合であり、削除対象となる単一フォルダではありません。具体的な所有者フォルダと実際の空き容量を測ってください。

## 削除前の5つの質問

1. 所有者はどのアプリ、ツール、システムサービスか
2. 元ファイルまたはリモートデータから再構築できるか
3. 再構築に必要な時間、電力、通信量、オフライン機能はどれくらいか
4. アプリ、デーモン、パッケージマネージャ、モデルサーバーは動いていないか
5. 完全削除の前にプレビュー、ゴミ箱、再ダウンロードという回復経路があるか

ひとつでも不明なら、そのフォルダは残します。

## 所有者のクリーンアップ機能を優先する

所有者は、参照関係、共有されたブロブ、使用中のバージョン、古く見えてもまだ必要なファイルを把握しています。所有者の機能なら、ファイルシステムを再帰的にたどるコマンドより、消す量は少なく、戻せる容量は安全に増やせます。

### ブラウザ

Chromeの[閲覧データ削除ガイド](https://support.google.com/chrome/answer/2392709?hl=en-uk)では、キャッシュ画像とファイルを、履歴、Cookie、パスワード、サイト設定、オフラインデータと分けて選べます。容量回復だけならキャッシュだけを選び、プロファイルフォルダは消しません。

ほかのブラウザも、名前が違うだけで同じような区別を持っています。ブラウザのストレージ設定かプライバシー設定を開き、選ばれている項目をひとつずつ読んでください。

### 開発ツール

開発ツールのキャッシュは、ディスク容量とビルドやインストールの速さを交換しているので大きくなりがちです。使うコマンドは所有者に合わせます。

Xcode Derived Dataは再構築できますが、時間と電力がかかります。Homebrewは[公式のcleanup説明](https://docs.brew.sh/Manpage.html#cleanup-options-formulacask-)に従い、`brew cleanup --dry-run` で先に確認します。npmはまず `npm cache verify` を使います。[npmのキャッシュ文書](https://docs.npmjs.com/cli/v11/commands/npm-cache/)でも、`npm cache clean --force` を日常作業にしないよう説明されています。

```bash
npm cache verify
```

ソース、依存パッケージ、ツールチェーンが使えることを確かめてから、Xcode と関連するビルドやテストを終了します。対象は作り直す予定のプロジェクトに限り、できるだけ Xcode 自身のクリーン操作や設定画面を使ってください。パッケージのリポジトリ、署名用ファイル、シミュレータのデータ、取得したソースは、開発用というだけでは Derived Data と同じように扱えません。

### AIツールとダウンロード済みモデル

```bash
hf cache ls
hf cache rm model/example --dry-run
hf cache prune --dry-run
```

```bash
ollama ls
ollama rm <model>
```

AIツールはフォルダを直接消さず、所有者の機能を使います。Hugging Faceは
`hf cache ls` の後に `hf cache rm model/example --dry-run` または
`hf cache prune --dry-run` で確認します。引数は [Hugging Faceのキャッシュコマンド](https://huggingface.co/docs/huggingface_hub/main/en/guides/cli#hf-cache)に従ってください。Ollamaは `ollama ls` でモデルを確認し、[CLIリファレンス](https://github.com/ollama/ollama/blob/main/docs/cli.mdx)に従って `ollama rm <model>` で選んだモデルだけを削除します。モデルは意図して保存したダウンロードであり、一般的なキャッシュではありません。チャット履歴、認証情報、セッション、プロファイル、稼働中のデータベースも対象外です。

ファイルを手で削除する前に、そのアプリと関連する処理を終了してください。開いているファイルやメモリにマッピングされたファイルを、書き込み中に削除すると、キャッシュのデータベースが壊れてアプリが正常に動かなくなるおそれがあります。

ブラウザキャッシュにはもうひとつ区別があります。Cookie、サイトデータ、履歴、保存パスワード、キャッシュされたページ資源は、別々のコントロールです。目的がディスクの回復なら、キャッシュされたコンテンツだけを選んでください。閲覧データを全部消すと、ログアウトしたり、オフライン用のサイト状態が消えたりするのに、実質的にキャッシュ以上の回収はほとんどありません。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/mole-clean-review.webp" width="2584" height="1741" loading="lazy" alt="Mole のクリーン確認画面。キャッシュをカテゴリごとにサイズ付きで一覧し、それぞれにチェックボックスがあり、下部に選択中の 5.14 GB を完全に削除するボタンがある。">
  <figcaption>Mole の「クリーン」画面。削除の前にキャッシュをカテゴリごとにサイズ付きで一覧し、チェックしたものだけを削除します。</figcaption>
</figure>

手作業でも確認できますが、バンドル識別子やフォルダ名だけでは用途が分からないことがあります。削除前に、使っているアプリ、パス、サイズ、分類を確認でき、設定、書類、モデル、会話履歴を対象から外せることが大切です。[Mole](https://mole.fit/ja/) の「クリーン」画面も、実行前に候補を確認する方式です。見つかった件数より、何を残すかと、削除直前のパス検証を重視しています。

## 手動での削除がまだ必要な場合

所有者に適切な機能がなく、5つの質問に答えられた場合だけ手作業に進みます。所有者を終了し、特定した子フォルダ1つをゴミ箱に移し、アプリを再起動して書類、ログイン、オフラインデータ、設定、ビルドやモデルを確認します。Appleの [Macストレージガイド](https://support.apple.com/102624)にあるとおり、ゴミ箱を空にするまで容量は解放されません。この待ち時間を回復手段として使います。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/cache-safety-gates.webp" width="1360" height="454" loading="lazy" alt="キャッシュ候補はレビュー前に時間制限付きサイズ調査と安全ゲートを通り、稼働中のツール、欠落したツール、ガードファイル、保護ドメインはスキップまたは保持へ振り分けます">
  <figcaption>候補がゴミ箱に入るのは、レビューと確認を経たときだけです。ツールの状態、明示的なガードファイル、保護ドメインが、レビューに進むか触れずに残すかを決めます。</figcaption>
</figure>

細部こそが要点です。安全な実装は、可能ならパッケージマネージャ自身の掃除インターフェースを使い、デーモンが動いているあいだはビルドキャッシュに触れず、解決したパスをすべて検証し、遅いサイズ計測にはタイムアウトをかけ、明示的に保護されたフォルダを残します。所有者ツールが無い、またはカテゴリが曖昧なら、推測よりレビューのほうが安全です。Cachesフォルダ全体の再帰削除は、こうしたチェックをすべて迂回します。

- **AIアシスタントのチャット履歴とトランスクリプト。** キャッシュの近くにありますが、替えのきかないデータです。空き容量のために消さないでください。
- **環境設定と保存ログイン。** 捨ててよいキャッシュとは別物です。
- **`/System` 配下のすべて。**
- **用途が特定できないフォルダすべて。**

どのMac掃除でも安全を保つルールはこれです。ファイルの用途がわからないなら、消さない。

## キャッシュとシステムデータが再び増える理由

先に測る。所有者を終了する。組み込みのストレージや掃除コマンドを使う。カテゴリは一度にひとつ。ゴミ箱を空にする前にアプリを開き直す。環境設定、プロファイル、チャット、書類、正体不明のApplication Supportデータは、キャッシュ扱いしない。空き容量やトラブルシューティングの利益が、再構築とダウンロードのコストを上回るときだけ消す。このやり方は「全部削除」より遅いですが、アプリ内部が変わっても安全に保てます。

キャッシュは、サムネイル、ダウンロード、ビルド出力、索引を作り直すため再び増えます。システム設定の「システムデータ」は、ほかの分類に入らないファイルの合計で、直接消せるフォルダではありません。表示の更新も遅れることがあります。清掃後は実際の空き容量とアプリの動作を確認し、遅れている分類表示を追って削除範囲を広げないでください。

## よくある質問

### Macのキャッシュを削除（クリア）するとどうなりますか？

本当のキャッシュなら、アプリが次に必要になったときに作り直します。起動や最初の読み込みが一時的に遅くなり、画像やダウンロードを取り直すぶん通信が増えますが、データそのものは失われません。困るのは、Cachesフォルダの中に下書き、オフライン用のダウンロード、ログイン状態が混ざっている場合です。

### キャッシュをクリアしても大丈夫ですか？

ブラウザの「閲覧履歴データを削除」やパッケージマネージャの掃除コマンドのように、所有者のアプリが用意した方法で消すなら大丈夫です。`~/Library/Caches` を丸ごと削除したり、`sudo` を付けて消したりするのは避け、子フォルダをひとつずつゴミ箱に移してアプリの動作を確かめてください。

### キャッシュを削除したのに空き容量が増えないのはなぜですか？

ゴミ箱を空にするまで容量は解放されません。アプリを使えばキャッシュは再び作られ、システム設定の「システムデータ」の表示も更新が遅れることがあります。実際の空き容量は Finder の「情報を見る」かターミナルの `df -h` で確かめます。

---

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
