ブログに戻る

Xcode Simulator が Mac の容量を圧迫している?まず何をクリーンアップすべきか

シミュレーターランタイムとシミュレーターデータの違い、何を安全に削除できるか、iOS 開発環境を壊さずに Mac のディスク容量を回復する方法を解説します。

発行済み 2026年4月1日 著者 StorageRadar Team 読み取り時間 読了目安 2 分 更新されました 2026年4月5日
XcodeSimulatorDeveloper Cleanup

Xcode Simulator が Mac の容量を圧迫している場合、何かを削除する前にシミュレーターランタイムとシミュレーターデバイスデータを分けて考えましょう。まず、何が利用不可か、何が非アクティブか、テストにまだ何が必要かを確認してください。すべての Apple 側フォルダーを破棄可能なキャッシュとして扱うと、シミュレーターのクリーンアップはリスクを伴うようになります。

これは、開発者が一つのクリーンアップルールを学び、それをあらゆる場所に適用したときに犯す間違いです。DerivedData は一つのことです。シミュレーターランタイムとシミュレーターデバイスの状態は別のことです。

ストレージは回復可能です。ただ、影響が一律ではないということです。

基本ルール: シミュレーターストレージはレイヤーごとにクリーンアップする。まず利用不可デバイスを削除し、デバイスデータはリセットする意図がある場合のみ消去し、ランタイムはその OS バージョンがもう不要な場合のみ削除する。

簡潔な回答

  1. 実際のフットプリントがシミュレーターランタイムなのか、シミュレーターデバイスデータなのか、その両方なのかを確認する。
  2. 何かを削除する前に xcrun simctl list devicesxcrun simctl list runtimes を実行する。
  3. 利用不可セクションに表示された場合、まず xcrun simctl delete unavailable で利用不可デバイスを削除する。
  4. erase はシミュレーターデバイスの内容と設定をリセットしたい場合にのみ使用する。
  5. ランタイムは、ビルド、プレビュー、テストでそのプラットフォームバージョンがもう不要だと確信できる場合のみ削除する。
  6. Apple 側のストレージがシミュレーターだけにとどまらない場合、一つのフォルダーから推測するのではなく、DerivedDataArchivesCoreSimulator をまとめて確認する。
StorageRadar の CoreSimulator クリーンアップ確認画面に、選択されたシミュレーターデバイス、ドライラン合計、適用前の確認ゲートが表示されている
選択、ドライラン合計、確認ステップが明示的に保たれている方が、広範なリセットの背後に隠すより、シミュレーターのクリーンアップは安全です。

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 フォルダー

ここからクリーンアップが反応的ではなく合理的なものになります。

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つの異なる決定です。

今後のシミュレーターストレージ管理

実践的な目標は「シミュレーターを増やさないこと」ではありません。目標は「シミュレーターストレージが見えないものにならないようにする」ことです。

次のような確認のリズムを使用しましょう:

  1. 主要な Xcode や SDK の変更後にデバイスとランタイムを一覧表示する。
  2. 利用不可デバイスが現れたら削除する。
  3. 問題がランタイムのインベントリではなくデバイスの状態である場合、古いシミュレーターデバイスをリセットする。
  4. OS バージョンを完全に削除する前にランタイムの使用状況を確認する。
  5. Apple 側のストレージが増え始めたら、CoreSimulatorDerivedDataArchives をまとめて比較する。

これにより、クリーンアップの決定が実際にコストのかかるレイヤーに整合します。

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 はデバイスの内容と設定をクリアすると説明されています。これはシミュレーターデバイスをリセットしますが、背後にあるランタイムイメージを削除するものではありません。

間違った Xcode データをワイプする前に、シミュレーターストレージを確認しましょう。

StorageRadar はシミュレーターの状態、ランタイム、DerivedData、アーカイブ、その他の Apple 開発者プロファイルを分離するため、サイズ、リスクを確認し、適用前にドライランできます。