Xcode Simulator が Mac の容量を圧迫している場合、何かを削除する前にシミュレーターランタイムとシミュレーターデバイスデータを分けて考えましょう。まず、何が利用不可か、何が非アクティブか、テストにまだ何が必要かを確認してください。すべての Apple 側フォルダーを破棄可能なキャッシュとして扱うと、シミュレーターのクリーンアップはリスクを伴うようになります。
これは、開発者が一つのクリーンアップルールを学び、それをあらゆる場所に適用したときに犯す間違いです。DerivedData は一つのことです。シミュレーターランタイムとシミュレーターデバイスの状態は別のことです。
ストレージは回復可能です。ただ、影響が一律ではないということです。
基本ルール: シミュレーターストレージはレイヤーごとにクリーンアップする。まず利用不可デバイスを削除し、デバイスデータはリセットする意図がある場合のみ消去し、ランタイムはその OS バージョンがもう不要な場合のみ削除する。
簡潔な回答
- 実際のフットプリントがシミュレーターランタイムなのか、シミュレーターデバイスデータなのか、その両方なのかを確認する。
- 何かを削除する前に
xcrun simctl list devicesとxcrun simctl list runtimesを実行する。 - 利用不可セクションに表示された場合、まず
xcrun simctl delete unavailableで利用不可デバイスを削除する。 eraseはシミュレーターデバイスの内容と設定をリセットしたい場合にのみ使用する。- ランタイムは、ビルド、プレビュー、テストでそのプラットフォームバージョンがもう不要だと確信できる場合のみ削除する。
- Apple 側のストレージがシミュレーターだけにとどまらない場合、一つのフォルダーから推測するのではなく、
DerivedData、Archives、CoreSimulatorをまとめて確認する。
CoreSimulator とは何か
CoreSimulator は、iOS・iPadOS・watchOS・tvOS アプリのビルドとテストのために Xcode がシミュレーターランタイムと作成済みシミュレーターデバイスを置いておく、Apple 管理下のフォルダーです。多くの Mac では ~/Library/Developer/CoreSimulator にあり、ランタイムを追加し、デバイスを作り、その中にアプリのデータが溜まるほど大きくなります。
ただのキャッシュではありません。このフォルダーには、まだ必要かもしれないランタイムイメージと、多くの場合はリセットや削除ができるデバイスの状態が混ざっています。「CoreSimulator が数十 GB ある」への答えが一つに決まらないのは、そのためです。
CoreSimulator フォルダーは削除できますか
フォルダーごと無条件に削除するのは避けてください。パス全体を消すのではなく、適切なレイヤーを空けることで、容量のほとんどは取り戻せます。
~/Library/Developer/CoreSimulator を手作業で丸ごと削除すると、Xcode はシミュレーターの状態を作り直すことになり、まだ必要なランタイムも消えます。安全な代替は、Apple 自身の simctl に本当に捨ててよい部分を任せることです。
- 現在の SDK が対応しなくなったデバイスは
xcrun simctl delete unavailableで削除する; - アプリの状態が肥大化しているなら
xcrun simctl erase <device>でデバイスの内容と設定をリセットする; - そのOSバージョンをもうテストしない場合にかぎり
xcrun simctl runtime deleteでランタイムを削除する。
CoreSimulator の容量はレイヤー単位で取り戻すものであり、フォルダーを消して Xcode の復旧に期待するものではありません。
Xcode シミュレーターが保存するものと、それが蓄積する理由
シミュレーターストレージは一つのものではありません。一緒に蓄積される複数のレイヤーです。
大まかに言うと、Xcode シミュレーターストレージには通常次のものが含まれます：
- 異なる iOS プラットフォームバージョンのランタイムイメージ
- 異なる iPhone および iPad モデル用に作成されたシミュレーターデバイス
- シミュレーター内のデバイスごとのアプリデータ、設定、状態
- SDK、デバイスタイプ、Xcode バージョンを切り替えるたびに増大する Apple 側の開発データ
開発者が CoreSimulator に戸惑うのはこのためです。フォルダーサイズを見て全体が単なるキャッシュだと想定しがちです。実際には、一部は破棄可能なテスト状態のようなもので、一部はまだ依存しているランタイムサポートです。
増大のパターンは正常です：
- 新しい Xcode や SDK をインストールする
- 新しいランタイムが現れる
- 新しいシミュレーターデバイスが作成される
- アプリ、テストデータ、設定がその中に蓄積する
- SDK の変更や Xcode のアップグレード後、古いデバイスが利用不可になる
- マシンにまだ十分な空き容量があるため、何ヶ月も確認されない
そしてある日、シミュレーターストレージが本題になるのです。
シミュレーターランタイム vs シミュレーターデータ：違いは何か？
これが最も重要な区別です。
Apple の simctl ツールはランタイムの操作とデバイスの操作を別々に扱います。これは、クリーンアップモデルがレイヤー構造であることを示しています：デバイスはランタイムと同じものではなく、デバイスの消去はランタイムイメージの削除と同じではありません。
| レイヤー | 何を表すか | 一般的なクリーンアップアクション | 主なトレードオフ |
|---|---|---|---|
| シミュレーターランタイム | 特定のプラットフォームバージョンを起動するために使用される OS ランタイムイメージ | 本当に不要なランタイムに対して simctl runtime delete | 今後のシミュレーター利用のためにそのランタイムを追加し直すまで失われる |
| シミュレーターデバイス | 特定のデバイスモデル用に作成されたシミュレーターインスタンス | simctl delete <device> または delete unavailable | デバイスインスタンスが消える |
| シミュレーターデバイスの内容と設定 | デバイス内のインストール済みアプリ、アプリデータ、設定、状態 | simctl erase <device> | デバイスは残るが、内容と設定はリセットされる |
だからこそ、「CoreSimulator をクリアすればいい」といった広範な記述は弱いアドバイスです。異なるクリーンアップの影響を1つの感情的なアクションに圧縮しています。
DerivedData がどこに位置するか
DerivedData は関連していますが、同じ問題ではありません。
DerivedData は一般的に生成されたビルド出力です。シミュレーターストレージはより混在しています。まだ必要なランタイム、もう不要な作成済みデバイス、気にするかもしれないし気にしないかもしれないデバイス内の状態が含まれる可能性があります。
圧迫の主な原因が主に生成されたビルド出力である場合、適切なガイドは Xcode の DerivedData が Mac の容量を圧迫している？まず何をクリーンアップすべきかです。圧迫の主な原因が主にランタイムイメージとシミュレーターの状態である場合は、シミュレーターのワークフローを続けてください。
シミュレーターがどれくらい容量を使用しているかを確認する方法
最初のステップは検査であり、削除ではありません。
Apple 自身のツールを使用して、実際にどのデバイスとランタイムが存在するかを確認しましょう：
xcrun simctl list devices
xcrun simctl list runtimesディスク上の広範な Apple 側ストレージフットプリントを確認したい場合は、主要なフォルダーを直接比較することもできます：
du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archivesこれは重要です。最も大きな Apple 側フォルダーが常に想定したものとは限らないからです。時に DerivedData が主要な問題であり、時に CoreSimulator がひっそりとそれを上回っています。
まず何を探すべきか
Unavailableにリストされているデバイス- もうテストしていない OS バージョンのランタイム
- 複数のランタイム世代にわたる多数の作成済みデバイス
- 複数回の Xcode 更新以降クリーンアップされていないシミュレーター主体の状態
- 現在のテストニーズに合わない大きな
CoreSimulatorフォルダー
ここからクリーンアップが反応的ではなく合理的なものになります。
Xcode でシミュレーターを削除する手順
確認するだけでなく実際に削除したい場合、安全な道は 2 つあります。Xcode の画面と、simctl のコマンドラインです。どちらも、まだ必要なランタイムに触れずに古いシミュレーターを取り除きます。
Xcode アプリから:
- Xcode を開き、Window → Devices and Simulators に進みます。
- Simulators タブを選びます。
- 不要なシミュレーターを右クリックして Delete を選ぶか、現在の SDK が対応しないデバイスをまとめて消す Delete Unavailable Simulators を使います。
コマンドラインから:
# まず一覧を出す
xcrun simctl list devices
# 現在の SDK が unavailable と判定したデバイスをすべて削除する
xcrun simctl delete unavailable
# UDID を指定して特定のデバイスを削除する
xcrun simctl delete <device-UDID>利用不可のシミュレーターの削除がいちばん安全な第一手です。Apple がすでに非対応と示しているデバイスしか消えません。特定のデバイスを削除した場合はそのインスタンスだけが消え、ランタイムイメージは残るので、プロジェクトが必要とすれば作り直せます。
容量の回復が目的なら、ランタイムに手を付ける前にここから始めてください。削除したデバイスはすぐ作り直せますが、ランタイムの削除はより重い判断です。
Mac でシミュレーターランタイムを削除しても安全ですか？
状況によりますが、最も安全な最初のステップではありません。
Apple の simctl runtime ヘルプでは、ランタイムイメージが独自の管理対象オブジェクトであることが明確に示されています。ランタイムの削除は、シミュレーターの内容をクリアすることとは異なります。利用不可デバイスを削除することとも異なります。
つまり、ランタイムの削除が適しているのは次の場合です：
- その iOS バージョンがテストにもう不要な場合
- 古い Xcode や SDK の世代を過ぎた場合
- ランタイムが十分に使用されておらず、容量の方が利便性より価値がある場合
- ランタイムリストを最初に確認し、何を削除するか正確に把握している場合
逆に、適さないのは次の場合です：
- アクティブなプロジェクトがそのランタイムファミリーをまだターゲットにしている場合
- SwiftUI プレビュー、QA 再現手順、またはリグレッションテストがまだそれに依存している場合
- 古いターゲットで問題をデモまたはデバッグする直前の場合
- 実際のテストニーズではなくサイズだけで削除しようとしている場合
より良い最初の一歩：明らかな不要データを削除する
最も安全なシミュレータークリーンアップは、利用不可デバイスの削除から始まることがよくあります。
Apple は simctl delete の中でこれを直接文書化しています：unavailable エイリアスは、現在の Xcode SDK でサポートされていないデバイスを削除します。
xcrun simctl delete unavailableこれは万能の解決策ではありませんが、最もクリーンな最初のパスの一つです。なぜなら、現在の SDK 文脈でサポート外としてマークされたデバイスをターゲットにしているからです。
開発環境を壊さずにシミュレーターデータをクリーンアップする
開発者はここで間違ったツールを使いがちです。
問題が古いアプリデータやシミュレーター内の膨張したデバイス状態である場合、ランタイムを削除する必要はないかもしれません。必要なのはシミュレーターデバイスのリセットだけです。
Apple の simctl erase ヘルプでは、erase はデバイスの内容と設定を消去すると定義されています：
xcrun simctl erase <device>これはランタイム削除の操作ではなく、リセット操作です。
erase に適したケース
- シミュレーター内のアプリの状態をクリアする
- テスト環境をリセットする
- ランタイムイメージ自体を削除せずに、膨張したデバイスレベルの内容を削除する
- デバイスのワークフローを維持しつつ、蓄積された状態を破棄する
erase が「ではない」もの
- ランタイムクリーンアップコマンドではない
DerivedDataクリーンアップコマンドではない- 実際にどのデバイスやランタイムが必要かを確認する代わりにはならない
この区別こそがシミュレータークリーンアップの全容です：デバイスの消去、デバイスの削除、ランタイムの削除は3つの異なる決定です。
CoreSimulator はディスク上のどこにあるか
シミュレーターの容量を調べるとき、重要なパスは 2 つです。
~/Library/Developer/CoreSimulator/Devices には、作成したシミュレーターデバイスが入っています。各デバイスは UDID を名前にしたフォルダーで、その中の data/ がインストール済みアプリ、アプリのデータ、設定を持ちます。simctl erase がリセットし、simctl delete が取り除くのはこの層です。
システム階層の /Library/Developer/CoreSimulator はランタイム側を持ちます。Xcode のバージョンによって、ランタイムイメージは Profiles/Runtimes の下に .simruntime バンドルとして置かれるか、xcrun simctl runtime list が表示するダウンロード可能なランタイムとして Xcode が管理します。ここでの削除は Mac 上のすべてのユーザーアカウントに影響するため、より重い判断として扱ってください。
du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh /Library/Developer/CoreSimulator
xcrun simctl runtime listDevices が大きいなら、原因は溜まったデバイスの状態と、現在の SDK が対応しなくなったデバイスです。システム階層のフォルダーが大きいなら、原因はランタイムイメージです。
CoreSimulator を外付けドライブに移動できますか
内蔵ディスクが小さく、シミュレーターのフォルダーが 40 GB を超えたときに出てくる質問です。Apple は移動のためのサポートされた設定を用意していないため、開発者はシンボリックリンクを使います。~/Library/Developer/CoreSimulator を外付けボリュームにコピーし、コピーを確認し、元を削除して、古いパスを新しい場所にリンクする流れです。
引き受けることになる条件:
- ドライブが未マウントだとパスが消えるため、Xcode はシミュレーターを起動できません;
- バスパワーの USB ドライブでは、内蔵 SSD よりシミュレーターの起動が遅くなります;
- Xcode や SDK の更新が、元のパスにフォルダー構造の一部を作り直すことがあります;
- バックアップと権限の挙動が外付けボリュームでは変わります。
フォルダーごと移す前に、回収できる容量を測ってください。利用不可のデバイスとテストしなくなったランタイムの削除のほうが、移動より多くを空けることがよくあります。しかも Apple がサポートする構成のまま保てます。
今後のシミュレーターストレージ管理
実践的な目標は「シミュレーターを増やさないこと」ではありません。目標は「シミュレーターストレージが見えないものにならないようにする」ことです。
次のような確認のリズムを使用しましょう：
- 主要な Xcode や SDK の変更後にデバイスとランタイムを一覧表示する。
- 利用不可デバイスが現れたら削除する。
- 問題がランタイムのインベントリではなくデバイスの状態である場合、古いシミュレーターデバイスをリセットする。
- OS バージョンを完全に削除する前にランタイムの使用状況を確認する。
- Apple 側のストレージが増え始めたら、
CoreSimulator、DerivedData、Archivesをまとめて比較する。
これにより、クリーンアップの決定が実際にコストのかかるレイヤーに整合します。
Apple 側ストレージのより良いメンタルモデル
DerivedDataは主に生成されたビルド出力Archivesは成果物とビルド履歴を保存CoreSimulatorはランタイムサポートとシミュレーターデバイスの状態が混在- 最も安全なクリーンアップは、どのフォルダーが見えるかではなく、どのレイヤーが大きいかによる
レイヤーで考えるようになると、シミュレーターのクリーンアップははるかに混沌としにくくなります。
エコシステムを認識したアプローチの方が開発者クリーンアップに適している理由
Finder だけで見ると、20 GB や 30 GB の Apple 側フォルダーは1つの明白なクリーンアップ対象に見えます。そうではありません。
ファイルブラウザーは CoreSimulator が大きいことを示せますが、実際に回復可能な容量が次のどれかは教えてくれません：
- サポートされていないデバイス
- リセット可能なシミュレーターの内容
- もう不要なランタイム
- たまたま近くに存在する別の Xcode プロファイル
だからこそ、シミュレーターのクリーンアップは一般的なファイルクリーンアップではなく、開発者クリーンアップに属します。
実際の問題が「シミュレーターに加えて DerivedData とその他の Apple 開発ストレージ」というものであれば、フォルダーパスを一つずつ追跡するより、このようなプロファイル認識型のワークフローの方がはるかに有用です。
まとめ
Xcode Simulator が Mac の容量を圧迫している場合、CoreSimulator を1つの破棄可能なキャッシュバケットとして扱わないでください。
まずデバイスとランタイムを確認しましょう。クリーンな最初のパスとして利用不可デバイスを削除し、シミュレーターの内容と設定をリセットしたい場合のみ erase を使用し、本当にその OS バージョンが不要になった場合のみランタイムを削除してください。
これがより安全なクリーンアップのアプローチです：ランタイムイメージとデバイスの状態を分け、シミュレーターストレージと DerivedData を分け、Apple 側のクリーンアップを盲目的なフォルダー削除ではなく実際のテストニーズに結びつけましょう。
よくある質問
Xcode Simulator が Mac でこれほどディスク容量を消費するのはなぜですか？
シミュレーターストレージは、Xcode がランタイムイメージ、作成されたシミュレーターデバイス、それらのシミュレーター内のアプリデータ、その他の Apple 側の開発状態を時間とともに保持するため増大します。複数の iOS バージョンとデバイスタイプにわたるテストにより、フットプリントは急速に拡大します。
シミュレーターランタイムとシミュレーターデータの違いは何ですか？
シミュレーターランタイムは、Xcode が特定のプラットフォームバージョンのシミュレーターを起動するために使用する OS ランタイムイメージです。シミュレーターデータは、作成されたシミュレーター内のデバイスレベルの状態（インストールされたアプリ、アプリデータ、設定など）です。
利用不可のシミュレーターデバイスを削除しても安全ですか？
通常は安全です。Apple の simctl ツールは、現在の Xcode SDK でサポートされなくなったデバイスである利用不可デバイスの削除を明示的にサポートしています。これは最も安全なシミュレータークリーンアップステップの一つです。
Mac でシミュレーターランタイムを削除しても安全ですか？
状況によります。テスト、プレビュー、古いプロジェクトターゲットでそのランタイムをもう必要としないことが確実な場合にのみ削除してください。ランタイムの削除は、ランタイムイメージ自体を削除するため、シミュレーターの内容を消去するよりも大きな決定です。
シミュレーターを消去するとランタイムは削除されますか？
いいえ。Apple の simctl ヘルプでは、erase はデバイスの内容と設定をクリアすると説明されています。これはシミュレーターデバイスをリセットしますが、背後にあるランタイムイメージを削除するものではありません。
CoreSimulator とは何ですか？
CoreSimulator は ~/Library/Developer/CoreSimulator にある Apple 管理下のフォルダーで、Xcode がシミュレーターランタイムとテスト用に作成したシミュレーターデバイスを保存します。ランタイムの追加、デバイスの作成、内部のアプリデータの蓄積とともに大きくなるため、まだ必要な容量と、リセットや削除ができる容量が混在します。
CoreSimulator フォルダーは削除できますか？
フォルダーごとの削除は安全ではありません。まだ必要なランタイムまで消え、Xcode はシミュレーターの状態を作り直すことになります。容量はレイヤー単位で回収してください。xcrun simctl delete unavailable が非対応デバイスを削除し、xcrun simctl erase がデバイスの内容をリセットし、xcrun simctl runtime delete はもうテストしない OS ランタイムにだけ使います。
Xcode でシミュレーターを削除するには？
Xcode で Window から Devices and Simulators を開き、Simulators タブを選んでシミュレーターを右クリックで削除するか、Delete Unavailable Simulators を使います。コマンドラインでは xcrun simctl delete unavailable が現在の SDK で非対応のデバイスを削除し、xcrun simctl delete <UDID> が特定のデバイスだけを削除してランタイムイメージは残します。
CoreSimulator フォルダーは Mac のどこにありますか？
シミュレーターデバイスは ~/Library/Developer/CoreSimulator/Devices にあり、各フォルダーは UDID を名前とし、data/ の下にインストール済みアプリと設定を保持します。ランタイムイメージはシステム階層の /Library/Developer/CoreSimulator にあり、Xcode のバージョンに応じて Profiles/Runtimes 配下の .simruntime バンドルか、xcrun simctl runtime list が表示するダウンロード可能なランタイムとして置かれます。
Xcode のシミュレーターを外付けドライブに移せますか？
Apple はサポートされた設定を提供していません。開発者は ~/Library/Developer/CoreSimulator から外付けボリュームのフォルダーへシンボリックリンクを張って対応しますが、その後 Xcode はドライブのマウントに依存し、USB では起動が遅くなり、Xcode の更新が元のパスに構造の一部を作り直すことがあります。利用不可のデバイスと未使用ランタイムの削除のほうが、少ないリスクで多くを空けることがよくあります。