# リリース成果物を失わずに Xcode を整理する > Xcode の容量を減らす前に、DerivedData、シミュレーター端末、ランタイム、DeviceSupport、リリースアーカイブを切り分けます。 Published: 2026-07-12 | Updated: 2026-08-08 Xcode のストレージは、ビルド出力、インデックス、Archives、DeviceSupport、シミュレータ デバイス、ダウンロード可能なプラットフォーム runtime に広がります。再現できるものもあれば、 リリース用 Archive やその dSYM の唯一のコピーであるものもあります。安全なやり方は、種類ごとに 計測し、可能なら Xcode 経由で削除し、出荷済みビルドに紐づく成果物は残すことです。 ## Xcode のギガバイトが行く先 まず、ユーザー領域の主要な 2 つのルートから始めます。 ``` du -sh ~/Library/Developer/Xcode/* ~/Library/Developer/CoreSimulator 2>/dev/null | sort -h ``` よく重いのは次のものです。 - **DerivedData**: ビルド成果物、インデックス、モジュールキャッシュで、通常はプロジェクトごとに 1 フォルダです。作り直せますが、全部消すと以降のインデックスとビルドが高くつきます。まず 古いプロジェクトを狙ってください。 - **DeviceSupport**: 実機と OS ビルド向けに取得したシンボルとサポート成果物です。古いエントリでも クラッシュのシンボル化にまだ使えることがあります。 - **Archives**: アプリをエクスポートまたは出荷するたびに保存されたビルドです。Apple は、配布した すべてのビルドについて Archive を保持するよう求めています。バイナリと対応する dSYM が、あとから クラッシュ報告を診断するときに必要になることがあるためです。Mac から一度も出なかったビルドの Archive のほうが、掃除候補としては安全です。 - **シミュレータデバイスとプラットフォーム runtime**: デバイスは CoreSimulator 配下にあり、 ダウンロード可能な runtime は Xcode のコンポーネントとして管理されます。ひとつのキャッシュでは ありません。 ## 種類ごとに安全に片付ける **DerivedData** はプロジェクト単位で扱うのがいちばんです。Xcode を終了し、**Xcode > Settings > Locations** から Derived Data を開き、古いプロジェクトのフォルダを特定して、そのフォルダだけを ゴミ箱へ移します。全体クリアは、グローバルなインデックスやビルド問題が再ビルドのコストに見合うときだけに してください。 **利用できないシミュレータデバイス**には専用コマンドがあります。 ``` xcrun simctl delete unavailable ``` これは runtime が利用できないデバイス記録を削除します。runtime イメージ自体はアンインストールしません。 インストール済みプラットフォームとシミュレータ runtime、回収可能なサイズは **Xcode > Settings > Components** で確認し、再ダウンロードできる runtime を外してください。Apple の [Xcode components guide](https://developer.apple.com/documentation/xcode/downloading-and-installing-additional-xcode-components) でも、同じ管理された削除経路が説明されています。デバイス記録は **Window > Devices and Simulators** を使います。 Archives は **Window > Organizer** で見直します。配布済みビルドの Archive と dSYM は、まだ使われている 古い本番バージョンも含めて残してください。Apple の [debugging information guide](https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information) では、バイナリと dSYM はビルド UUID が一致するときだけ一緒に使えるとされています。 DeviceSupport も一括消去ではなく、選別して見直す価値があります。 DerivedData を移す前に Xcode を終了し、インデックスやビルド用データベースが書き込み途中にならないように します。次回の起動とビルドでは、再インデックス、依存関係の解決、出力の再生成が走るので、 所要時間はプロジェクトと手元に残っているもの次第です。 ## 仕組み： なぜ DerivedData は安全で、DeviceSupport は同じではないのか DerivedData は再現可能なビルドとインデックスの出力です。プロジェクトごとに、パスのハッシュから名前が付いた フォルダができ、コンパイル済みオブジェクト、モジュールキャッシュ、インデックス、ソース・設定・ ツールチェーン・依存関係から導かれたビルド成果物が入ります。消しても、手元に残っている入力から Xcode が 作り直します。時間とネットワークが要ることがあります。DeviceSupport は種類が違います。実機をデバッグすると、 その OS ビルド向けのサポートとシンボルデータが取り込まれます。シミュレータデバイスと runtime イメージも、 普通のキャッシュフォルダではなく、それぞれ別の管理対象です。選別して残す価値があるのは Archives で、 App Store ビルドのクラッシュ報告をシンボル化するのに必要な dSYM がそこにあります。作り直せるキャッシュと 取得済み成果物の区別が、安全に消してよいものと残すべきものとの境界そのものです。
Xcode の開発者フォルダは再構築可能なキャッシュである DerivedData と module cache、および採取済みアーティファクトである DeviceSupport、Archives、シミュレータに分かれます
Xcode のフットプリントは、再現可能な出力と取得済み成果物に分かれます。Archives と dSYM は、ビルド出荷後も運用上重要であり続けることがあります。
## ディスクマップが役立つ場面 [Mole](https://mole.fit/) の Analyze のようなディスクマップは、圧力の正体が DerivedData、CoreSimulator、 Archives のどれかを示せます。削除そのものは Xcode の Components、Devices、Organizer に任せてください。 runtime、デバイス、リリース成果物を理解しているのはそちらです。 ## 安全な作業順 進行中のビルドを止め、Xcode と CoreSimulator を別々に測り、古いプロジェクト単位の DerivedData を消し、 利用できないシミュレータデバイスを削除し、Components から未使用の runtime を外します。Archives は、 出荷済みバージョンとシンボル化の必要性を照らしてから削除してください。ゴミ箱を空にする前に、重要な プロジェクトを 1 つ開き直し、ビルドを通してください。 --- Canonical HTML page: https://mole.fit/ja/blog/how-to-clean-up-xcode-mac Blog index for agents: https://mole.fit/ja/blog/llms.txt Site index for agents: https://mole.fit/llms.txt