2026-05-06 iOS Simulator ランタイム ディスク予算、選択インストール、CI クリーンアップ（レンタル Apple Silicon クラウド Mac、HK / JP / KR / SG / US）

香港・東京・ソウル・シンガポール・米国で Mac mini M4 をレンタルし xcodebuild test を回すチームは、すぐに第二の請求に気づきます。Simulator ランタイムは無料ではなく、Library/Developer/CoreSimulator 配下に数 GB 規模のスライスを取り、DerivedData と NVMe 帯域を奪い合い、watchOS コンパニオンが行列に入るとさらに倍増します。この 2026-05-06 のガイドは三つの運用問いに答えます：何が入っているかを棚卸しする方法、destinations が本当に要請する OS ファミリーだけを選ぶ方法、夜間 UI テストがまだ起動するランタイムを消さずに刈り込む方法です。ヘッドレス Simulator テストを拡張し、ディスク掃除の janitorと組み合わせ、同一ホストで 並列レーンを走らせるときは DerivedData の分離を参照してください。

2026 年の CI がまだ「Xcode を入れた＝Simulator 準備OK」と混同する理由

Xcode.app はツールチェーンを束ねますが、ランタイムはオンデマンドで落とす版付きペイロードです。繰り返し三つの誤り：

• destination ドリフト — YAML は iPhone 15 のままなのに、Xcode 更新後ホストは iPhone 16 イメージだけを用意した。
• 静かな watch ペアリング — ローカルでは Xcode が watch ランタイムを自動取得したが CI はしていない。
• janitor のやり過ぎ — cron が「古い」ランタイムを消し、QA が App Store クラッシュ再現のためにまだ必要としていた iOS 17.6 を失う。

ランタイムのフットプリント：ギガバイトが潜む場所

Apple Silicon ホストはデバイスデータ、dyld 共有キャッシュ、ランタイム単位のスライスを保持します。主要 iOS ランタイムのペア（端末＋年度による watch イメージ）でおおよそ 7–14 GB。UI スクリーンショットレーンで言語パックを入れたならさらに 3–6 GB。重要なのは正確なバイトではなく、五人のエンジニアが同じ共有ビルダーで「とりあえず最新 beta ランタイム」を入れたときの微分です。

ランタイム増加をキュー遅延と相関させてください。空き容量が 12% を下回ると、最初の症状は即失敗ではなく xctest fixture コピーの遅化になりがちです。APFS が連続エクステント探索に苦労するためです。

新しい Xcode メジャーを採用するとき、ランタイム取得は単一チェックボックスではなく容量移行です。複数プラットフォームパックの促し、CoreSimulator キャッシュ再構築、初回の緑ビルド後 24–48 時間にわたる暗黙のウォーム膨張が起きます。レンタルホストに明示メンテ窓を確保し、PR トラフィックと初回一括ダウンロードを重ねないでください。無視したチームはコード変更なしの赤ビルドが翌日消えるフラキーを見ます。その窓で df を毎時ログし、先四半期の定常曲線と比較してください。傾きが履歴の 2× を超えるなら、同一レーンに beta と GA の重なるスライスを載せた可能性が高いです。

最後に誰がランタイムを入れられるかを文書化してください。個人の sudo インストールが共有鍵に「謎の 6 GB」を生む典型です。インフラチケットと CI イメージタグに変更を集約し、ssh セッションを監査可能に——特に署名素材の保存でシンガポールか米東かを規制が縛る場合です。

レーンマトリクス：どのホストがどのランタイムを保持するか

責務を明示的に分割し、すべての runner が交換可能だと仮定しないでください。

レーンラベル	ランタイム方針	掃除の所有者
ios-current	最新 GA iOS と App Store 整合の N-1 を 1 本	週次の刈り込み＋チケット
watch-heavy	watchOS イメージ＋ペア端末のみ	月次；QA 承認なしで N-1 を消さない
archive-only	Simulator 最小；実機 Archive を優先	Simulator に aggressive、鍵には gentle

オペレーターが runbook に貼る棚卸しコマンド

非破壊プローブから始め、段階的にエスカレートします。

xcrun simctl list runtimes df -h / du -sh ~/Library/Developer/CoreSimulator/* 2>/dev/null | sort -h | tail -n 20

Finder と数値が食い違うときは CI ユーザーで実行した du を信頼してください——launchd ジョブはビルダーアカウントで動きます。別ボリュームなら /Volumes/builds でも繰り返します。

選択的インストール runbook（ハッピーパス）

1. キューを凍結するかホストに紐づくラベルをドレイン。
2. 次スプリントの destination 行列に本当に必要なランタイムバンドルだけをダウンロード。
3. ランタイムごとに xcrun simctl boot でスモークし、sysctl hw.model が Apple Silicon のままか確認。
4. イメージ版タグを上げて CI YAML と現実を一致させ、キューを再開。
5. インストール済み集合をインフラリポジトリに記録（孤立 wiki にしない）。

ステップ 2 と 3 の間に、チケットへチェックサムまたは Apple のバージョン文字列を残し、壊れたミラーで切れたランタイムならロールバックが明確になります。

刈り込み方針：何を消してよいか

良い janitor は派生物を aggressive に消し、ランタイムは準静的インフラとして扱います。二段階方針：

成果物	安全な頻度	刈りすぎリスク
未起動のシミュレータ端末	毎日	低——テンプレから再作成
古い .xcresult バンドル	オブジェクトストアへアップロード後	中——法務保持で 30–90 日オフホストが要る場合
ランタイムバンドル本体	四半期＋ QA リスト	高——クラッシュ再現の再現性を壊す

並列レーンと統合メモリ圧力

並列 xcodebuild は Simulator 起動のチャーンを増幅します。キューラベルでホストあたりの同時起動数を抑えてください——並列ジョウの記事を参照。メモリ圧が尖ったらスワップより同時 destination を減らす方を優先；統合メモリでは XCTest がスワップに極めて弱いです。

Xcode アップグレード窓：ランタイム取得と Archive の順序

温かい第 2 ノードが無い限り、ランタイム大容量ダウンロードと TestFlight 提出フリーズ夜を同じ夜に入れないでください。MacXCode ホストで最も安全なのはブルー/グリーンビルダー：候補イメージで xcodebuild test と軽い xcodebuild archive -archivePath /tmp/Smoke.xcarchive が両方緑になってからイメージタグを昇格。二重ノードが買えないなら範囲を縮小：メンテ時間あたり追加ランタイムは一つずつ、五つ同時に入れない。各ダウンロードの壁時計分を記録し、財務が別の 1 TB ビルダーを借りるか週末リリースを燃やすか比較できるようにします。

アップグレード後は YAML の destination 文字列を再検証してください。Apple がシミュレータハードウェア profile 名を変えることがあります。不一致は「destination not found」に見えて simctl list は埋まっているように見える——多くは刈り込みで消したハードウェア文字列をジョブが指しているためです。simctl list devices available の機械可読エクスポートをインフラリポで diff してください。

Grafana に置ける数値目標

• 持続ディスク利用率はページング運用の前に85% 上限。
• 16 GB マシンではプロファイルで余裕が証明されない限り起動済み Simulator は最大 4 台。
• 「ランタイム取得＋起動＋単一 XCTest」のコールド受け入れ上限 22 分；アップグレード後に超えたらアラート。

「巨大フォルダ」を消す前の 9 ステップ

1. 飛行中の Archive ジョブがないことを確認。
2. 現在の simctl list を GitOps にスナップショット。
3. 過去 30 日 ジョブゼロのランタイムを特定。
4. QA に明示的な削除日で通知。
5. 一度に一レーンだけドレイン。
6. サポートされた UI/CLI パスでのみランタイム削除。
7. 残り destination でスモーク再実行。
8. 削除前後の df を比較し差分をチケットに添付。
9. 健全ホストだけでタグを前進。

FAQ：ベータ、Apple Silicon、跨リージョンホスト

質問	実務的な答え（2026-05-06）
ベータランタイムを本番 CI に置くべき？	canary ラベル付きホストに隔離；App Store 提出レーンと混ぜない。
シンガポールと米国ホストは同一集合が必要？	最小共通集合で揃える；地域固有の追加は YAML で符号化されていれば可。

Simulator 偏重 CI で 1–2 TB の Mac mini M4 が勝つ理由

Simulator 負荷はランダムリード寄りです。MacXCode ノードのベアメタル Mac mini M4 NVMe は、同一 PR 行列で四レーンが異なる OS 世代を起動してもブート時間を予測可能に保ちます。その予測可能性が数値予算を規律に変え、ノイジーネイバーの背後にある謎の「大容量クラウドディスク」を買うより優れます。容量計画が第 2 の JP canary を求めたら リージョン別料金 を、誰がランタイムを消した証拠をセキュリティが求めたら SSH/VNC アクセスガイド を添えてください。