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

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

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

巨大化するのには構造的な理由があります。Xcode は開いたすべてのプロジェクトに DerivedData フォルダを作り — 一度ビルドしたきり二度と触らなかった使い捨てのクローンも含めて — そのどれも決して削除しません。各フォルダは構成とデスティネーション（Debug と Release、シミュレータと実機）ごとに別々のビルド成果物を抱えるため、中規模のプロジェクト 1 つで数 GB を占め、フォルダ全体では現役の開発マシンで 20〜50 GB に達するのが普通です。

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

DerivedData を削除する

やり方は 3 通りあり、行き着く先は同じです。Xcode の Clean Build Folder コマンド（Product > Clean Build Folder、または Command + Shift + K）は、現在開いているプロジェクトのビルド成果物しか消しません — 不可解なビルドエラーの修復には有効ですが、ディスク容量の針はほとんど動きません。本当に容量を取り戻すには、DerivedData フォルダそのものを削除します。

プロジェクト単位で削除するのが外科手術的な選択肢です。毎日ビルドする 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 ルートで同じことを可逆的にできます。

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

シミュレータは通常、DerivedData に次いで 2 番目に大きい開発者向けの容量食いです。これまでにダウンロードした iOS・watchOS・tvOS のランタイムはそれぞれ 5〜8 GB を占め、シミュレートされた各デバイスは ~/Library/Developer/CoreSimulator/Devices の下に自分のデータフォルダを持ちます。Xcode のアップグレードを何度か経ているなら、何年も前に対象から外した iOS バージョンのランタイムがまだ残っている可能性が高いでしょう。

最速で効くのが組み込みのクリーンアップコマンドです。ターミナルで xcrun simctl delete unavailable を実行してください。ランタイムがもうインストールされていないシミュレータデバイス — 古い Xcode バージョンが置き去りにしていったもの — をすべて削除し、まだ使えるものには一切触れません。

ランタイム本体は、Xcode の Settings > Platforms（古い Xcode では Components）で管理します。インストール済みの各シミュレータランタイムがサイズ付きで表示されるので、古いものを選んで削除します。古い 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 とシミュレータアプリが動いていないときに消して安全で、必要になれば作り直されます。

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

パッケージマネージャは、次回のインストールを速くするために、これまでダウンロードした依存パッケージをすべて保持します。エンジニアリングとしては正しく、ディスク衛生としては最悪です。キャッシュは増える一方で、数年分のプロジェクトを経たマシンでは気づけば 10〜20 GB になっています。どれも消して安全です — 最悪の場合でも、次のインストールでパッケージを再ダウンロードするだけです。

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 で旧バージョンと古いダウンロードを削除し、brew cleanup --prune=all ならダウンロードキャッシュ全体も空にします。何が消えるかのドライラン一覧を見たければ、先に brew cleanup -n を実行してください。

自動化する

上記の方法はすべて有効ですが、開発者ゴミはトレッドミルのようなものです。普通に仕事をしていれば 1 週間で DerivedData は戻り、キャッシュは再びたまり、Xcode のアップデートのたびにランタイムがまた 1 つ置き去りになります。6 つの手動手順を毎月やり直したくないなら、ここが自動化する価値のある部分です — 黙って一括削除するのではなく、判断の根拠を見せてくれるツールで。

AskClean は開発者ファイルを第一級のカテゴリとして扱います。一度のスキャンで、Xcode DerivedData をプロジェクト別に、古いシミュレータランタイムを（simctl 経由で読み取り、プラットフォームごとに最新版を保持して）、デバイスサポートファイルを、そして npm・SwiftPM・cargo・uv などのパッケージマネージャキャッシュを項目化します。さらに新顔の容量食い — Hugging Face と Ollama のモデルキャッシュ — もモデル別に一覧化し、初期状態では未選択のままにします。

どの項目にも説明が付きます — それが何か、作り直せるか、消したら何を失うか — そして、あなたが確認するまで何も実行されません。削除はゴミ箱へ移動するので、誤クリックもドラッグ＆ドロップひとつで元通り。ソースコード、書類、写真には決して触れません。このガイドと同じチェックリストを、1 時間のターミナル作業抜きでこなせます。

FAQ