Macのシステムデータとは?安全に減らす方法
Appleメニュー > システム設定 > 一般 > ストレージ を開くと、大きな塊として システムデータ と表示されていることがあります。これはフォルダではなく、また安定した測定値でもありません。macOSがほかの表示可能なカテゴリに振り分けなかったデータの、変化し続ける分類です。そのため、ファイルを削除していなくても、インデックス作成や再分類のあとに数値が変わることがあります。Appleの ストレージのガイド では、このカテゴリをログ、キャッシュ、仮想メモリファイル、一時ファイル、フォント、アプリのサポートファイル、プラグイン、およびmacOSが管理するその他のランタイムリソースとして説明しています。
システムデータの正体、膨らむ理由、そして安全に縮小する方法を整理します。
30秒で判断する
まず 利用可能 な容量を確認します。Appleは、物理的に空いている容量と、macOSが必要に応じて回収できるキャッシュを含む利用可能容量を区別しています。Macがファイルを保存でき、アップデートも完了できるなら、灰色の領域が大きいだけで緊急事態ではありません。
本当に容量が不足している場合は、ディスクユーティリティでAPFSコンテナ全体の空きを確認し、削除前に最も大きい実フォルダを特定します。システムデータという表示だけを削除の根拠にしないでください。
システムデータは分類であって場所ではない
システムデータはひとつのフォルダではなく、カテゴリです。macOSがアプリ、書類、写真、メールなどのカテゴリに分類しなかったデータが入ります。実際には次のようなものが含まれます。
- アプリとシステムの キャッシュ。
~/Library/Cachesと/Library/Cachesにあります。 - macOSとアプリが継続的に書き出す ログと診断レポート。
- ローカルTime Machineスナップショット。バックアップのあいだ内部ディスクに保持され、空き容量が足りなくなると自動で整理されます。
~/Library内の アプリケーションサポートファイル、コンテナ、データベース。- ダウンロード済みのシステムファイル:アップデート用インストーラ、フォントキャッシュ、ステージ済みデータ。
- メモリ負荷に応じて動的に管理される スワップと仮想メモリ。
これらは多数の場所に散らばっているため、空にできる「システムデータ」専用ディレクトリはありません。ストレージ設定が推定して分類しています。
「ほかのユーザと共有」も別のストレージ分類で、数値が大きいからといってアカウントのホームフォルダを削除してよいわけではありません。/Users や /Users/Shared を触る前に、この分類の境界を確認してください。
~/Library、/Library、/private/var、スナップショットを集約して、ひとつのストレージカテゴリにまとめます。システムデータが大きくなる主な原因
容量が増える主な理由は次のとおりです。
- キャッシュの保持ポリシーはさまざまです。 空き容量が必要なとき、macOSは安全なキャッシュを削除でき、行儀のよいアプリは独自の上限を設けます。それでも壊れたキャッシュや上限のないキャッシュは、ギガバイト単位まで膨らむことがあります。
- スナップショットは最近変更されたデータを保持します。 ローカルTime Machineスナップショットは、変更・削除されたファイルのブロックを残すことがあります。macOSはそれらを回収可能として扱い、容量が必要になると間引きます。
- デバイスのバックアップは溜まり続けます。 iPhoneとiPadのローカルバックアップは、Finderの バックアップを管理 で端末と日付を確認してから削除します。Appleのバックアップ管理ガイドがその手順を説明しています。
- 開発ツールはビルド生成物を抱え込みます。 Xcode、パッケージマネージャ、シミュレータは再生成できる成果物と、プロジェクトやツールチェーンを近い場所に保存します。所有するツールのクリーンアップ機能を使ってください。
- 仮想ディスクは実際の使用量が見えません。 仮想マシンやコンテナのスパースディスクは、論理サイズと物理割り当てが一致しません。唯一のプロジェクトやデータベースがないことを確認してから、アプリ側で削除します。
- アプリサポートには実際のコンテンツがあります。 ブラウザ、メディアアプリ、AIツールの
Application Supportには、オフラインメディアやモデルなどの実データがあります。フォルダ全体をキャッシュとして扱わないでください。
これらはいずれも故障の証拠ではありません。まず、物理的な空き容量が本当に不足しているかを確認してください。見た目は大きなカテゴリでも、利用可能な容量に余裕があるなら、何もする必要はないかもしれません。
なぜ数字が食い違うのか
df、Finder、APFSツールの結果が食い違うこともあります。論理ファイル、物理割り当て、スナップショット、回収可能容量について、それぞれ別の問いへの答えだからです。
| 見る場所 | 分かること | 食い違う理由 |
|---|---|---|
| ストレージ設定 | カテゴリごとの推定値 | インデックス作成と再分類に遅れが出る |
| Finderの「情報を見る」 | ファイルやフォルダの論理サイズ | クローン、スパースファイル、アクセス権で結果が変わる |
du |
ディレクトリを辿って到達できたブロック | 保護されたパスを飛ばし、リンクの数え方も違う |
df |
マウントされたファイルシステムの使用量と空き量 | ストレージのカテゴリではなく、ファイルシステム側の集計 |
| APFSコンテナ表示 | 同じコンテナ内の全ボリュームが共有する容量 | スナップショットや同居ボリュームも同じ容量を使う |
AppleのAPFSガイドは、同じコンテナ内のボリュームが空き容量を共有し、必要に応じて割り当てると説明しています。Finderのフォルダを合計しても、ストレージのひとつのカテゴリと同じ数字にはなりません。
変更を加えずにディスクを測る
macOSは内訳を隠していますが、コマンドラインならその多くを確認できます。
df -h /
diskutil apfs list
diskutil apfs listSnapshots /
df は、マウントされたファイルシステムが使う量と空き量として認識している値を報告します。
diskutil apfs list は共有コンテナ、そのボリューム、残容量を示します。スナップショット表示ガイドに対応する diskutil apfs listSnapshots / は、起動ボリュームのスナップショットを一覧します。これらを合わせると、物理割り当てと、ストレージ設定に表示されるカテゴリを切り分けられます。
空き容量が実際にどう分かれているかをイメージすると分かりやすくなります。
ローカルTime Machineスナップショットを一覧するには:
tmutil listlocalsnapshots /
実際に重いLibraryフォルダを探すには、du で辿ります。
du -sh ~/Library/* 2>/dev/null | sort -h
このスキャンには時間がかかることがあり、フルディスクアクセスがないと保護された場所が省略されることがあります。
Application Support はキャッシュの別名ではありません。データベース、ダウンロードしたメディア、仮想ディスク、プロジェクト状態がしばしば含まれます。
リスクの低い順に減らす
- 再ダウンロードできるインストーラ、重複した書き出し、所有者が明確な大きなファイルから始めます。
- アプリの設定にあるキャッシュ削除機能を使います。公式手順に沿ってフォルダを手動削除する場合は、先にアプリを終了します。詳しくはキャッシュの安全な消し方を参照してください。
- iPhoneとiPadのバックアップはAppleのバックアップ管理ガイドに沿い、Finderの バックアップを管理 で端末と日付を確認します。
- Xcode、シミュレータ、コンテナ、ダウンロードモデルは、所有するツールの機能で処理します。開発キャッシュと Dockerには個別の手順があります。
/System、スワップ、稼働中のデータベース、正体不明のLibraryフォルダは触りません。
通常は確認してから削除してよいもの: アプリが文書化しているキャッシュ、古いクラッシュレポート、不要になったインストーラ、再取得できるダウンロード。キャッシュを消すと、サインアウト、オフラインコンテンツの消失、大きな再ダウンロード、設計の粗いアプリでは未同期状態の消去につながることがあります。削除前にアプリを終了し、パスを確認してください。
手作業で減らすには:
- 可能なら、アプリ自身の設定から、大きくて特定できたアプリキャッシュだけを削除する。
~/Library/Application Support/MobileSync/Backupに保存された古いiOSバックアップは、Finderの「バックアップを管理」で端末と日付を確認してから削除する。- 空き容量が必要になったら、Time Machineによるローカルスナップショットの自動削除に任せる。
- 再起動は、アップデート適用時や固まったプロセスの診断時だけにする。スワップは自動管理され、メンテナンス対象ではありません。
ディスクマップなら、同じ計測を一覧ではなく図として示せます。 Mole の「分析」画面は大きなフォルダをブロックで描き、「クリーン」画面は確認済みのカテゴリだけを対象にします。目的は何が容量を使っているかを調べることで、システムデータの数値だけを小さくすることではありません。
通常の清掃に入れてはいけないもの
触らないもの: /System 配下のすべて、APFSとTime Machineのスナップショット内部、スワップファイル、メール・メッセージ・写真などの稼働中アプリのデータベース、そしてはっきり識別できないファイル。ストレージがシステムデータに分類したというだけで、コンテナを手動編集してはいけません。
削除しても数字がすぐ動かない理由
ゴミ箱を空にするまで容量は戻りません。その後もAPFSスナップショットが古いブロックを参照したり、ストレージ設定での再分類に時間がかかったりします。df -h / と対象フォルダを再測定し、色付きバーだけを理由に追加削除しないでください。
システムデータは正常で、動的です。カテゴリサイズの目標値ではなく、物理的な空き容量と、特定できるフォルダでMacを判断してください。本当に空きが足りないなら、ディスクをマップし、まずユーザーが管理できる不要データを削除し、スナップショットとスワップはmacOSに任せ、安全と分かっているカテゴリだけを削除してください。 Time Machineは約24時間ぶんの1時間ごとのローカルスナップショットと、空き容量が必要になるまでの最後の成功バックアップのスナップショットを保持し、 自動で削除します。したがって、コマンドに表示されたスナップショットが、使える容量を塞いでいる証拠にはなりません。
よくある質問
50 GBのシステムデータは正常ですか
すべてのMacに共通する正常値はありません。利用可能容量と、特定できた大きなフォルダで判断します。
~/Library/Caches を全部消してもよいですか
いけません。アプリを終了し、所有者と影響が分かる大きなキャッシュだけを、できればアプリの設定から消します。
ローカルスナップショットは削除すべきですか
通常は不要です。Appleは、Time Machineがその容量を利用可能として数え、古くなるか空きが必要になると自動で削除すると説明しています。コマンドに表示されるだけでは、作業を妨げている証拠になりません。
再起動するとシステムデータは減りますか
再起動はアップデートを完了させたり、固まったプロセスの一時的な状態を片づけたりできますが、日常的なストレージ対策ではありません。macOSとアプリが作業を再開すれば、スワップ、キャッシュ、カテゴリの推定値はまた増えていきます。
どこで止めればよいですか
通常の作業とアップデートに十分な容量が戻り、容量不足の主な原因を解消できた時点で止めます。目標は使える空き容量を確保することで、灰色の領域を小さく見せることではありません。