Mac のストレージが足りなくなると、多くの人がまず同じ疑問を持ちます。「何が容量を食っているんだ?」
これはシンプルな質問に聞こえますが、「ファイルを削除するには?」とは別の問題です。クリーンアップの前に必要なのは可視性です。難しいのは削除ボタンを押すことではなく、大まかなカテゴリや無害に見えるフォルダ、あるいはたまたま目についた大きなファイルを「犯人」と思い込まずに、本当の原因を見つけることです。
良いストレージ診断には一定のアプローチがあります。まず全体像を把握し、ツリービューで詳細を確認し、最も重いパスを検査する。問題が再発するなら、スナップショットを時系列で比較します。
ざっくりまとめ
Storage settingsは第一歩としては有用ですが、大まかなカテゴリの背後にある本当の原因が見えなくなることがよくあります。Finderは普段使うフォルダの確認に便利ですが、ストレージツリー全体を表示したり、Mac 全体で最も重いブランチをランキングしたりするのは苦手です。- ツリービューは、ディレクトリを一つずつ開く代わりに、大きなフォルダをコンテキスト付きで確認できるため重要です。
- 現在のスナップショットは「今何が大きいか」を答えます。スナップショットの比較は「何が変わったか」を答えます。
- ストレージを圧迫する一般的な原因は、Downloads、メディアライブラリ、アプリのサポートデータ、残存ファイル、バックアップ、仮想マシン、シミュレータのデータ、開発系のビルド成果物、そして System Data に含まれる各種キャッシュ類です。
- 目的は単に大きなファイルを一つ見つけることではありません。クリーンアップ前に正しいパスを特定し、そのパスの所有者を理解することです。
重いブランチが以下のいずれかに該当する場合は、それぞれの解説記事を参照してください
大まかな System Data ブランチ
さらに詳しくMac の System Data が大きい理由と確認すべきこと を読んで、内蔵のカテゴリ表示が手がかりでしかない場合にどう掘り下げるかを確認してください。
アンインストール済みアプリの残存ファイル
さらに詳しくデータを失わずに Mac のアプリ残存ファイルを削除する方法 を使って、重いパスがアンインストールの残りか Library 内のサポートデータの場合に対処してください。
Apple 開発者向けストレージ
さらに詳しくXcode の DerivedData が Mac のストレージを圧迫している場合に最初に確認すること に切り替えて、重いブランチが ~/Library/Developer 以下にある場合に対処してください。
Docker のイメージ、レイヤー、ボリューム
さらに詳しくDocker が Mac のディスクを消費している理由と実態 を使って、容量の主が通常のフォルダではなくコンテナ関連の場合に確認してください。
繰り返し発生する問題
さらに詳しくMac のディスク使用量を時系列で比較する方法 を使って、本当の問題が「2つの時点の間で何が増えたか」にある場合に確認してください。
Finder とストレージ設定だけでは不十分な理由
どちらの内蔵ツールも便利ですが、どちらか一つですべて解決というわけにはいきません。
Storage settings は、どの大まかなカテゴリに問題がありそうかを教えてくれる点では優れています。「ドキュメント」が大きければ助けになりますし、「System Data」がおかしく見える場合も有用です。しかし、カテゴリビューは複数の異なるパスを一つのラベルにまとめてしまいます。
そこが問題です。カテゴリが教えてくれるのは「次にどこを探すべきか」であって、「何を削除すべきか」ではありません。
Finder には逆の弱点があります。カテゴリの概要ではなく、パスベースの表示です。怪しいフォルダがすでに分かっている場合にはうまく機能しますが、本当の問題が予想外の深い階層に隠れている場合には不向きです。
そのため、多くの人が次の 2 つの良くないワークフローに陥りがちです。
- カテゴリビューを過信して、
System Dataや「ドキュメント」を一つの安全なクリーンアップ対象と見なしてしまう。 - Finder で手動探しをして、目についた大きなフォルダがすべての原因だと決めつけてしまう。
どちらのワークフローにも、同じものが欠けています。それはコンテキストです。
macOS のストレージ設定で分かること
ストレージ設定は、次のような広範な質問に答える最初のステップとしては有用です。
- 圧迫の主因は、個人ファイル、アプリ、それとも System Data のようなあいまいなカテゴリか。
- 問題はメディア、開発系ストレージ、それとも単なる散乱か。
- どのカテゴリを優先的に詳しく調べるべきか。
第一歩としては有用ですが、実際のパスレベルでの確認に取って代わるものではありません。
Finder で分かること
Finder は、既知のパスを確認したり、怪しいフォルダを開いて中身に見覚えがあるか確かめたりするのに使えます。
ただ、Finder が次のような質問にうまく答えられない点が問題です。
- ストレージツリーのどのブランチがディスクを支配しているか。
- 全く別の親フォルダに存在する大きなパスはどこか。
- カテゴリが重いのは、1つの巨大なフォルダのせいか、それとも多数の中サイズフォルダの累積か。
- 先週から今日までの間に何が増えたか。
実際、こうした質問に答えることが最も重要になります。
ストレージツリーが Mac の容量圧迫の原因特定に役立つ理由
ストレージツリーは、Finder の表示とカテゴリビューが解決できない可視性の問題に答えてくれます。
独立したフォルダを一つずつ調べる代わりに、容量が親パスと子パスにどう分布しているかを俯瞰できます。これにより、診断は劇的に変わります。
たとえば次のようなケースです。
- 巨大な
Downloadsフォルダは、単純なユーザー所有のクリーアップ問題です。 ~/Library/Application Support以下の重いブランチは、アプリが所有するデータの問題です。~/Library/Developer以下の重いブランチは、開発系のビルド成果物の問題です。- 広いカテゴリの中で予想外に支配的な 1 つのフォルダが、ディスク全体の状況を説明していることもあります。
ツリービューがランダムなフォルダ探しより有用な理由はここにあります。サイズと構造が同時に見えるからです。
Treemap が大きなフォルダを素早く見つけるのに役立つ理由
Treemap は、同じ階層のフォルダ同士を素早く比較したい場合に特に便利です。それぞれを手動で開かなくても、どのブランチが親ディレクトリを支配しているかが一目で分かります。
「このストレージツリーのどこを最初に調べるべきか?」という疑問に役立ちます。
Sunburst が深くネストされたパスの確認に役立つ理由
Sunburst は、フォルダのネストの深さを理解し、階層の中から一つの重いブランチをたどる場合に役立ちます。
「この大きなブランチの中で、具体的にどこに容量が集中しているのか」という疑問に答えてくれます。
重要なのは、どちらか一方のビジュアルが常に優れているわけではないということです。構造を理解することが重要な場合、どちらのビューも単なるフォルダ一覧よりも多くの情報を提供してくれます。
診断の鉄則: 大まかなカテゴリは「どこから始めるか」を示してくれます。ツリービューは「実際に何が重いのか」を教えてくれます。
現在のサイズと時系列での増加の違い
これはストレージ分析において最も重要な違いの一つです。
現在のスナップショットが答える質問は次のとおりです。
- 現在、何が大きいか。
- 今ディスクを圧迫しているファイルやフォルダはどれか。
- ツリーの中で最も重いブランチはどこにあるか。
これは、Mac がすでに容量不足で、現在の圧迫要因を特定したい場合に適したビューです。
しかし、より良い質問は別のところにあるかもしれません。
- 最近増えたものは何か。
- 前回のクリーンアップから何が変わったか。
- 数日おきに増え続けているブランチはあるか。
- 同じフォルダがずっと大きいのか、それとも最近になって急に問題になったのか。
これはサイズの問題ではなく、時間の問題です。
現在のサイズと最近の増加が別の質問である理由
フォルダが大きくても、数か月間安定していることはよくあります。だからといって、それが急なストレージ不足の原因とは限りません。
逆に、別のフォルダは全体としては小さくても、急速に増えていることがあります。そちらが容量を食い続ける本当の原因かもしれません。
単一の現在のスキャンと時系列比較は、同じものとして扱うべきではありません。
Largestは「今何が重いか」を教えてくれます。Reportsのスナップショット比較は、時点間の変化を可視化します。
増加の傾向こそが本当の問題だと思うなら、Mac のディスク使用量を時系列で比較する方法 を参照してください。
時間の次元を無視すると、実際に増え続けているものではなく、単に目についた大きなものを片付けてしまいがちです。
Mac のストレージを最も圧迫しやすいもの
ほとんどの Mac では、予測可能な一連のカテゴリがストレージを消費しています。重要なのは「それらが存在するかどうか」ではなく、「今、自分の Mac でどれが支配的か」です。
| カテゴリ | なぜ増えるか | 最初に確認すること |
|---|---|---|
| Downloads、デスクトップ、ドキュメント | インストーラ、エクスポート、アーカイブ、複製、プロジェクトの一時コピー、録画などが知らず知らずのうちに蓄積されます。サイズ順で並べ替えて、古い DMG、ZIP、動画、重複フォルダ、一度きりのエクスポートを探してください。 | |
| メディアライブラリ | 写真、動画、画面録画、音楽プロジェクト、編集済みのエクスポートは当然大きくなります。アプリが所有するデータに触る前に、最も大きなライブラリとエクスポート済みメディアを確認してください。 | |
| アプリケーションとインストーラ | 古いアプリバンドル、インストーラ、重複したアプリのコピーが、セットアップや移行後に残っていることがあります。インストール済みのアプリと、不要な DMG やアーカイブされたインストーラを分けてください。 | |
| アプリのサポートデータと残存ファイル | アプリはキャッシュ、サポートファイル、コンテナ、ログ、インデックス、ローカルデータを保持します。Library パス内のデータを削除する前に、それがどのアプリのものか確認してください。 | |
| バックアップ、VM、シミュレータのデータ | iPhone バックアップ、仮想マシンのディスク、シミュレータのランタイムは仕様上大きくなります。そのワークフローがまだ有効かどうか、データの削除ではなく移動で対応できないか確認してください。 | |
| 開発系のビルド成果物 | Xcode、Docker、パッケージキャッシュ、ビルド出力、ランタイムは速度優先でストレージを消費します。そのストレージが再生成可能なキャッシュなのか、ランタイムの状態保持なのか、それとも現在も使っているものなのかを確認してください。 | |
| System Data の各種要因 | キャッシュ、ログ、ローカルスナップショット、一時ファイル、システムが報告するストレージが混在しており、合計が分かりにくくなっています。対処する前に、カテゴリの背後にある実際の重いパスを特定してください。 |
Downloads、デスクトップ、ドキュメント
これらのフォルダは見落とされやすく、内容も理解しやすいため、最もよくある原因です。どれか一つが巨大な場合、クリーンアップは通常は簡単です。
写真、動画、エクスポート済みのファイル
いくつかの編集済み動画、画面録画、写真ライブラリ、音声のエクポートだけで、何千もの通常ファイルを超える容量になることがあります。特に開発者以外の Mac では、最も優先的に確認すべき対象です。
アプリが所有するデータ
ここから規模とリスクのバランスが難しくなります。パスは大きくても、安易に削除して良いとは限りません。重いブランチがアプリに関連している場合、まずはそのアプリとデータモデルを確認してください。すでにアンインストールしたアプリの残存データだと分かった場合は、データを失わずに Mac のアプリ残存ファイルを削除する方法 に焦点を当てたガイドを参照してください。製品のワークフローを確認したい場合は、App Uninstaller に進んでください。
バックアップ、仮想マシン、シミュレータ
これらは仕様上大きくなるものなので、単なるフォルダとしてではなく、ワークフロー全体として評価する必要があります。まだ使っているなら、削除するよりアーカイブや移動を検討してください。
開発系のビルド成果物
開発用 Mac では、最も大きいパスのいくつかは個人ファイルではありません。Xcode のキャッシュ、シミュレータのデータ、コンテナのレイヤー、パッケージキャッシュ、ビルド成果物など、生成された出力とランタイムストレージです。これが原因だと分かった場合は、Xcode の DerivedData が Mac のストレージを圧迫している場合 や Docker が Mac のディスクを消費している実態 のような個別ガイドを参照してください。大まかな推測で消すより確実です。この問題に特化した製品機能を使いたい場合は、Dev Cleanup に直接進んでください。
問題が System Data の場合
内蔵のストレージ概要で System Data が大きいと表示されている場合、それは診断結果ではなく手がかりです。Mac の System Data が大きい理由と確認すべきこと は、まさにその問題のために書かれたガイドです。
Mac の容量を圧迫している犯人を見つける実践的な手順
確実なワークフローが必要な場合は、次の順序で進めてください。
1. 大まかなカテゴリビューから始める
まず内蔵のストレージ概要を使います。ここでの目的は精度ではありません。どのカテゴリをより詳しく調べるべきかを知ることです。
2. 現在のスナップショットで最も大きいものを確認する
どのあたりが怪しいか大まかに分かったら、現在のスナップショットビューに移ります。Largest は最も重いパスを直接表示するため、フォルダを一つずつ開くより効率的です。
3. 何かを削除する前にストレージツリーを開く
重いパスを特定したら、ツリーコンテキストで確認します。Disk Map は、単一の大きい項目を構造的な説明に変えてくれます。問題が1つのフォルダなのか、1つのサブツリーなのか、それとも複数のブランチにまたがるパターンなのかが分かります。
4. クリーンアップ前にパスを分類する
そのパスがどの所有権カテゴリに属するかを確認します。
User-owned: 個人ファイル、エクスポート、Downloads、アーカイブ、メディア。App-owned: サポートファイル、コンテナ、Library 内のデータ、インデックス、ローカルデータベース。System-ownedまたはワークフロー所有: スナップショット、仮想マシン、シミュレータのデータ、ランタイムストレージ、開発ツール。
この分類により、次のアクションが削除、移動、保持、さらなる調査のいずれかが判断できます。
5. 問題が繰り返し発生する場合はスナップショットを比較する
容量を空けても同じ問題が再発するなら、一回限りのクリーンアップでは解決しません。それは増加追跡の問題です。
そこで Reports が重要になります。互換性のあるローカルスナップショットを比較すると、2つの時点の間で何が増え、何が減り、何が現れ、何が消えたかが分かります。記憶に頼って原因を推測するよりはるかに確実です。
StorageRadar がどう役立つか
これにより、ワークフローが実質的に変わります。
- 現在のスナップショットから始めて、重いパスを特定する。
- ツリービューに切り替えて、コンテキストを理解する。
- 同じ問題が繰り返し発生する場合は、時系列比較に切り替える。
カテゴリから推測したり、フォルダをランダムに探したりするより、はるかに確かな診断アプローチです。
ローカルスキャンを一度実行して Largest を確認し、その後 Disk Map を開いてから、重いものの削除、アーカイブ、移動に進みましょう。
やってはいけないこと
次のよくある間違いを避けてください。
System Dataや「ドキュメント」のような広いカテゴリを、一つの安全なクリーンアップ対象として扱わないこと。- Finder で最初に目についた大きなフォルダがすべての原因だと決めつけないこと。
- 現在の大きなパスと、時系列で増え続けているパスを混同しないこと。
~/Library、仮想マシンのストレージ、シミュレータのデータ、その他のアプリ所有・ワークフロー所有のパスで安易に削除しないこと。- パスの所有者と予想される結果を説明できるようになる前に、削除に着手しないこと。
まとめ
Mac のストレージを圧迫しているものを見つけることは、実際には削除の問題ではなく、可視性の問題です。
まず全体像を把握し、ツリービューで詳細を確認し、現在の重いパスを検査する。問題が再発するならスナップショットを時系列で比較する。何が大きくて、どこにあり、増え続けているのかが分かれば、クリーンアップの判断はずっと簡単で安全になります。
よくある質問
隠しフォルダを見落とさずに、Mac のストレージを圧迫しているものを見つけるにはどうすればよいですか?
Finder だけでは難しいのが現実です。Finder は普段使うフォルダの確認には便利ですが、ストレージ全体をツリー表示したり、複数のブランチにまたがる重いパスをランキングしたり、時系列での変化を追跡するのは苦手です。
macOS のストレージ設定だけでは不十分な理由は何ですか?
ストレージ設定は大まかなカテゴリ分けとしては役立ちますが、「ドキュメント」や「System Data」のようなカテゴリの背後には、実際にはさまざまなパスが混在しています。問題のありかは示してくれますが、具体的なフォルダやファイルまで特定してくれるわけではありません。
Finder で手動探しするより早く大きなファイルを見つけるにはどうすればよいですか?
ツリービューを使うと、フォルダを一つずつ開かなくてもコンテキスト付きでサイズを確認できます。どのブランチがディスクを支配しているか、親フォルダと子フォルダの関係はどうなっているか、大きなパスが全体構造のどこに位置しているかが一目で分かります。
現在のスナップショットと時系列比較の違いは何ですか?
現在のスナップショットは「今何が大きいか」を教えてくれます。一方、スナップショット同士を比較すると「2つの時点の間で何が増えたか、減ったか、現れたか、消えたか」が分かります。それぞれ別の質問に答えるもので、クリーンアップの判断も変わってきます。
Mac のストレージを最も圧迫しやすいものは何ですか?
よくある原因としては、Downloads フォルダの肥大化、デスクトップやドキュメントの散乱、写真や動画のライブラリ、アプリのサポートデータ、アンインストール済みアプリの残存ファイル、バックアップ、仮想マシン、シミュレータのデータ、開発系のキャッシュやビルド成果物、そして System Data に分類されるキャッシュやローカルスナップショットなどが挙げられます。
大きなファイルを見つけたらすぐに削除してもよいですか?
いいえ。まずはそのパスがユーザー所有なのか、アプリ所有なのか、システム所有なのかを確認してください。特に Library フォルダ、仮想マシンのストレージ、シミュレータのデータ、開発ツール関連のパスは、安易に削除すると取り返しがつかないことがあります。