Xcode の DerivedData と開発者キャッシュを安全に削除する

DerivedData とは何か、なぜ巨大化するのか

DerivedData は、Xcode がソースコードから生成したもの（中間ビルドオブジェクト、コンパイル済みの成果物、モジュールキャッシュ、コード補完や定義へのジャンプに使うシンボルインデックス、ビルドログ）をまとめて保管する場所です。既定の場所は ~/Library/Developer/Xcode/DerivedData で、これまでに開いたプロジェクトやワークスペースごとにサブフォルダが 1 つずつ作られます。

巨大化するのには構造的な理由があります。Xcode は、一度ビルドしたきり二度と触らなかった使い捨てのクローンも含め、開いたすべてのプロジェクトに DerivedData フォルダを作りますが、それを自分から削除することはありません。各フォルダには構成とビルド先（Debug と Release、シミュレータと実機）ごとに別々のビルド成果物がたまるため、どれだけ空くかを推測するのではなく、プロジェクトのサブフォルダのサイズを実際に測ってください。

中身はすべて、定義上、作り直せるものです。それが「derived（派生）」の意味です。DerivedData を削除しても、ソースコード、プロジェクト設定、バージョン管理下のファイルには一切影響しません。唯一のコストは時間です。各プロジェクトの次のビルドはフルのクリーンビルドになり、バックグラウンドでインデックス作成が数分間やり直されます。

DerivedData を削除する

Xcode の Clean Build Folder コマンド（Product > Clean Build Folder、または Shift + Command + K）が消すのは、いま開いているプロジェクトのビルド成果物だけです。おかしなビルドを直すには役立ちますが、ディスクの空き容量はほとんど増えません。本当に容量を取り戻すには、DerivedData フォルダそのものを削除します。Xcode の Locations 設定から Finder に表示する、Finder で直接フォルダを開く、ターミナルで削除する、のどの方法でも結果は同じです。

プロジェクト単位で削除すれば、影響を最小限に絞れます。毎日ビルドする 2〜3 個のプロジェクトの DerivedData は残し、それ以外のフォルダを削除します。丸ごと削除するのがいちばん手早く、それでも問題はありません。全プロジェクトのフル再ビルドのコストを一度に払うだけです。

1. まず Xcode を終了します。Xcode の実行中に DerivedData を削除するとインデクサが混乱することがあり、Xcode が開いているファイルはきれいに削除できない場合があります。
2. フォルダを見つけます。Xcode で Settings > Locations を開き、DerivedData のパスの横にある小さな矢印をクリックすると Finder に表示されます。または、Finder で Command + Shift + G を押し、~/Library/Developer/Xcode/DerivedData を直接入力してください。
3. プロジェクトのサブフォルダをサイズ順に並べ替え、削除したいものを選択して（すべてなら Command + A）、ゴミ箱に入れます。まずゴミ箱に入れるのが安全な習慣です。気が変わっても、すぐに元に戻せます。
4. ターミナルを使う場合は、rm -rf ~/Library/Developer/Xcode/DerivedData で一度にすべて削除できます。非常に大きなフォルダでは Finder より速く終わりますが、使う前に下の注意を読んでください。
5. Xcode を開き直してビルドします。各プロジェクトの初回ビルドは目に見えて時間がかかり、ツールバーのアクティビティ表示に「Indexing」がしばらく出続けます。どちらも一度きりのコストです。

rm -rf の扱いには注意してください。ゴミ箱を経由せずに完全に削除され、取り消しはできません。パスは正確に入力し、この作業では sudo を付けないでください。ターミナルに慣れていない場合は、Finder の手順なら同じ作業を元に戻せる形で行えます。

古いシミュレータランタイムを片づける

シミュレータも、開発者のストレージで大きな割合を占めやすいカテゴリです。ダウンロードした iOS・watchOS・tvOS のランタイムはそれぞれ容量を使い、シミュレートされた各デバイスも ~/Library/Developer/CoreSimulator/Devices の下にデータを保存します。Xcode のアップグレードを何度か経ているなら、もうテスト対象に含まれていない OS バージョンのランタイムがないか確認してください。

手早く効くのは組み込みのクリーンアップコマンドです。ターミナルで xcrun simctl delete unavailable を実行すると、unavailable（利用不可）と表示されたシミュレータデバイスがすべて削除されます。その多くは、削除されたランタイムや古い Xcode が残していった孤立デバイスです。デバイスの中のアプリとデータも一緒に消えるため、先に xcrun simctl list devices で一覧を確認してください。複数の Xcode をインストールしている場合は、この確認が特に重要です。

ランタイム本体は、Xcode の Settings > Components（Xcode 14〜15 では Platforms）で管理します。インストール済みのシミュレータランタイムがサイズ付きで一覧表示されるので、古いものを選んで削除します。古い OS バージョンで実際にテストしているのでない限り、プラットフォームごとに最新のランタイムだけ残せば十分です。

Window > Devices and Simulators で、シミュレートされたデバイスを個別に整理することもできます。Simulators タブに切り替え、まったく使っていないデバイス（古いテストのデータが残ったままの、重複する 6 台の iPhone など）を右クリックして Delete を選びます。そのデバイスに保存されたデータとアプリも一緒に削除されます。

アーカイブ、デバイスサポートファイル、キャッシュ

アーカイブは、配布用ビルドを作るために Product > Archive を実行するたびに ~/Library/Developer/Xcode/Archives にたまっていきます。各アーカイブにはアプリの完全なビルドと dSYM デバッグシンボルが含まれ、1 つあたり 100 MB〜1 GB になることも珍しくありません。削除する前に、何と引き換えになるかを知っておきましょう。中の dSYM は、まさにそのビルドのクラッシュレポートをシンボリケートするために必要なものです。App Store や TestFlight でまだ配信中のバージョンのアーカイブは残し（または App Store Connect に dSYM があることを確認し）、残りを削除してください。いちばん安全なのは Xcode の Organizer（Window > Organizer > Archives）を使う方法で、バージョンなどの情報を確認しながら削除できます。

iOS DeviceSupport（~/Library/Developer/Xcode/iOS DeviceSupport）には、これまでに接続したすべての iPhone や iPad から Xcode がコピーしたデバッグシンボルが、iOS バージョンごとに 1 フォルダ、通常それぞれ 2〜5 GB ずつ保存されています。手持ちのどのデバイスももう使っていない iOS バージョンのフォルダは、容量を占めているだけです。削除して構いません。そのバージョンのデバイスをまた接続すれば、Xcode がシンボルをコピーし直すだけです（「Preparing debugger support」が一度表示されます）。watchOS と tvOS のデバイス用にも同じようなフォルダがあります。

Xcode 自身のキャッシュは ~/Library/Caches/com.apple.dt.Xcode に、シミュレータのキャッシュは ~/Library/Developer/CoreSimulator/Caches にあります。どちらも必要に応じて作り直されますが、消すのは Xcode と Simulator アプリを終了しているときだけにし、見覚えのない CoreSimulator のキャッシュファイルには手を付けないでください。

パッケージマネージャのキャッシュ（SwiftPM・CocoaPods・npm・Homebrew）

パッケージマネージャは、次回のインストールを速くするために、ダウンロードした依存パッケージを保持します。便利な仕組みですが、何年分ものプロジェクトを扱ってきたマシンでは、大きな容量を占めることがあります。これらのダウンロードキャッシュは作り直せますが、次回のインストールではパッケージを再び取得する必要があります。

Swift Package Manager はダウンロードしたパッケージを ~/Library/Caches/org.swift.swiftpm にキャッシュし、各プロジェクトの解決済みチェックアウトはそのプロジェクトの DerivedData フォルダの中にもあります。つまり、DerivedData を消せばそちらも一緒に片づきます。共有キャッシュは Finder から削除するか、そのパスを指定して rm -rf を実行します。

CocoaPods はダウンロードした Pod を ~/Library/Caches/CocoaPods に保存します。きれいに空にするには、組み込みコマンドの pod cache clean --all を使います。プロジェクトの Pods フォルダには影響せず、消えるのはダウンロードキャッシュだけです。

npm のキャッシュは ~/.npm にあり、JavaScript 中心のマシンでは数 GB に達することがあります。npm cache clean --force で空にできます（npm がこのフラグを求めるのは、キャッシュが自己修復型で通常は掃除の必要がないためです。削除しても問題はなく、次回のインストールでパッケージが再ダウンロードされるだけです）。pnpm を使っている場合は、代わりに pnpm store prune を実行できます。

Homebrew は古いダウンロードや旧バージョンのパッケージをため込みます。brew cleanup は旧バージョンと古いダウンロードを削除します。引数なしで実行すると、HOMEBREW_NO_AUTOREMOVE を設定していない限り、どこからも必要とされなくなった依存パッケージもアンインストールされます。brew cleanup --prune=all ならダウンロードキャッシュ全体も空になります。何が消えるかを先に一覧で確認したい場合は、brew cleanup -n でドライランを実行してください。

自動化する

ここまでの方法はどれも有効ですが、開発用のゴミは片づけてもすぐにまたたまります。普段どおり作業していれば DerivedData は 1 週間で元に戻り、キャッシュは再びたまり、Xcode をアップデートするたびに古いランタイムがまた 1 つ取り残されます。6 種類の手作業を毎月繰り返したくないなら、ここは自動化する価値があります。ただし、黙って一括削除するツールではなく、判断の根拠を示すツールを選んでください。

AskClean は開発者ファイルを独立したカテゴリとして扱います。一度のスキャンで、Xcode の DerivedData をプロジェクト別に、古いシミュレータランタイムを（simctl で読み取り、プラットフォームごとに最新版は残して）、デバイスサポートファイルを、そして npm・SwiftPM・cargo・uv などのパッケージマネージャキャッシュを項目ごとに一覧にします。新たな容量食いであるローカル AI モデルも検出し、Hugging Face のモデルは 1 つずつ、Ollama のモデルライブラリはまとめて 1 項目として表示します。いずれも初期状態では選択されていません。

どの項目にも、それが何か、作り直せるか、削除すると何を失うかの説明が付き、確認するまでは何も実行されません。確定した項目はゴミ箱に移動せず完全に削除されるため、確定する前に選択内容を一つずつ確認してください。ソースコードと写真ライブラリには一切触れません。このガイドと同じチェックリストを、1 時間のターミナル作業なしでこなせます。

作り直せるものと、作り直せないもの

これは削除してよい範囲の境界を示す表で、どれだけ容量が空くかを示すものではありません。作業の前後で Mac の空き容量を測ってください。Xcode シミュレータの容量ガイドにある読み取り専用の監査スクリプトなら、何も変更せずにこれらのフォルダを確認できます。

よくある質問