Xcode 26 Compilation Caching は有効にすべき？2026年CI判断

📋 目次

2026年9月3日時点で、Appleのシステム要件ページには安定版としてXcode 26.6、テスト版としてXcode 27 beta 4が掲載されています。公式のシステム要件が示すとおり、まず対象をXcode 26に固定して判断してください。

症状：Clean Buildやブランチ切り替えのたびにコンパイルが長くなり、キャッシュを有効にしても効果が分からない。
最速解決策：同じコミット、Scheme、ビルド引数、Macノードで命中状況を確認し、持続的にキャッシュを残せる場合だけ段階導入します。

Compilation Cachingは入力の繰り返し、頻繁なブランチ切り替え、Clean Buildが多いワークロードに向きます。一方、毎回破棄されるRunner、ビルド条件が頻繁に変わるCI、空き容量が限られるノードでは、全体へ一括適用しないでください。

先に対象ワークロードを分ける

この判断をする対象は、Xcode 26でiOSまたはmacOSプロジェクトを保守し、ビルド時間とRunnerの維持費を管理する開発者、DevOps担当者、開発基盤の責任者です。単発のアーカイブだけを実行する環境より、同じコードを繰り返しビルドするCIのほうが検証価値があります。

判断は次の3つに分けます。

有効化候補：同じ入力で再ビルドする、複数ブランチを切り替える、Clean Buildを定期的に行う、かつ作業ディレクトリを保持できる。
灰色検証：キャッシュを保存できるが、署名、テスト、スクリプト、依存関係の取得が全体時間の大部分を占める。
先送り：Runnerが毎回初期化される、ビルド引数やSDKがジョブごとに異なる、ディスク容量の監視と清掃ができない。

Compilation Caching、DerivedData、依存パッケージのダウンロードキャッシュ、通常のインクリメンタルビルドは別物です。DerivedDataが残っているだけでは、Compilation Cachingがコンパイルに使われた証拠になりません。AppleのBuild Settings Referenceで設定対象を確認し、ログ上の診断情報と分けて扱います。

命中確認はxcodebuildのログから始める

xcodebuildをCIで実行する場合、総ジョブ時間だけを見てはいけません。Compilation Cachingが本当に使われたかは、公式にサポートされる診断設定、ビルドログ、同じ入力を繰り返したときのコンパイル挙動を組み合わせて確認します。設定名や利用条件は、Xcode 26 Release Notesの記載を基準にしてください。

次の3種類を別々に記録します。

初回ビルド：対象コミットを初めてビルドし、キャッシュ生成の起点にします。
同一入力の再実行：同じコミット、Scheme、SDK、ビルド引数、依存関係で再実行します。コンパイル段階のログに再利用を示す情報が現れるかを確認します。
履歴ブランチへの切り替え：別ブランチをビルドした後、元のコミットへ戻します。入力が変化した部分と、再利用できた部分を分けて見ます。

「2回目のジョブが速い」という事実だけでは不十分です。依存パッケージがすでにダウンロード済みだった、テスト件数が違った、署名処理が短かったという可能性もあります。Appleのインクリメンタルビルド計測方法に沿って、コンパイル工程の時間を独立して記録します。

Clean Buildでの判断

Clean Buildでは通常の増分ビルドの再利用と条件が異なります。Compilation CachingがClean Buildに有効かを確認するには、同じプロジェクトでキャッシュ有効・無効を切り替え、初回と再実行をそれぞれ比較してください。

ただし、Clean Buildのたびに作業領域やキャッシュ保存先まで削除するCIでは、次のジョブが再利用できません。削除処理を「クリーン」と呼んでいても、DerivedDataだけを消すのか、Compilation Cachingの保存領域まで消すのかで結果は変わります。

時間短縮はコンパイル工程と全体工程を分離する

有効性の評価では、次の条件を固定します。

同じプロジェクトのコミット
同じSchemeとSDK
同じ署名条件、ビルド引数、依存関係
同じMacノードと同じ作業ディレクトリ
同じテスト、アーカイブ、配布スクリプト

そのうえで、コンパイル、リンク、テスト、署名、アーカイブ、依存関係の取得、独自スクリプトを別々に計測します。性能試験の設計は、Appleの性能テスト手順も参照できます。

コンパイルが短くなっても、署名やテストが長ければパイプライン全体の改善は小さくなります。したがって「キャッシュ命中率」だけでなく、成功ビルド1回あたりの実効時間と、その状態を維持する管理作業を評価対象にします。出典のない秒数、改善率、速度比較は判断材料にしないでください。

Runnerの寿命と容量が継続価値を決める

自動的に破棄される一時Runnerでは、ジョブ終了時にキャッシュも失われる可能性があります。再起動後に残るかどうかは、Macの再起動そのものではなく、ディスクの保持方式、ワークスペース初期化、ユーザー領域の削除ポリシーで決まります。

自分で管理するMac Runnerでは、次の項目を記録してください。

キャッシュ保存先と所有アカウント
ジョブ終了時に削除されるディレクトリ
再起動前後のキャッシュ状態
空き容量の推移
複数プロジェクト間のアカウント分離
容量超過時の自動清掃と無効化手順

共有ノードでは、あるチームのキャッシュが別チームのビルド条件と混ざらない設計も必要です。キャッシュディレクトリが存在するだけで価値があるわけではありません。命中しない古いデータを保持すれば、容量監視と清掃の負担だけが増えます。

Macを長期運用する方法と、仮想化環境で毎回作り直す方法には、キャッシュ保持とI/Oの違いがあります。判断材料を整理するなら、物理Macと仮想macOSの違いも併せて確認してください。

リリース用ジョブは独立した基準を残す

開発ブランチで速くなったからといって、リリースアーカイブまで同じ設定にする必要はありません。まず全新規クローンからのビルド、キャッシュなしビルド、署名付きアーカイブを定期的に実行し、キャッシュが暗黙の依存関係やスクリプトの欠陥を隠していないか確認します。

共有CIへの放量前には、次の停止条件を決めておきます。

キャッシュ命中を示すログを再現できない
同じコミットで有効・無効の結果が安定しない
空き容量が継続的に減り、清掃後も回復しない
全新規クローンまたはキャッシュなしのアーカイブが失敗する
失敗時にキャッシュを使わない再実行へ切り替えられない

2026年の導入判断チェックリスト

次の項目を、同一プロジェクトで実行してから結論を出してください。

[ ] Xcode 26の対象バージョンと診断設定を公式資料で固定する
[ ] 同じコミット、Scheme、ビルド引数、依存関係を用意する
[ ] Compilation Cachingの有効・無効を分け、初回と再実行を記録する
[ ] コンパイル工程と、テスト・署名・配布工程の時間を分離する
[ ] 再起動後とワークスペース初期化後のキャッシュ状態を確認する
[ ] キャッシュ容量、空き容量、清掃ログ、アカウント分離を記録する
[ ] 全新規クローン、キャッシュなし、リリースアーカイブを検証する
[ ] ログ不明、容量逼迫、再現性低下時の無効化手順を用意する

この結果、入力の繰り返しとキャッシュ保持があり、コンパイル工程にも明確な再利用が確認できたなら、持続的な遠隔Mac CIノードで灰色導入を続けます。Runnerを毎回破棄する場合や、ビルド条件が頻繁に変わる場合は、設定を全量で有効にせず、従来のビルドを基準にしてください。

現在の一時RunnerやLinux中心のCIを使い続ける方法は、キャッシュがジョブ間で消える、macOS専用の署名・Xcode工程を別経路へ分ける、失敗時に同じ環境を再現しにくいという弱点があります。物理Macノードを自分で購入する場合も、初期費用、保守、常時稼働、容量設計を自社で抱えることになります。

そのため、同じプロジェクトを継続的にビルドし、キャッシュを保持できる環境が必要なら、MacDateのレンタルMacを検証用の選択肢に入れる価値があります。Mac miniのレンタル構成と料金の考え方を確認し、まずはキャッシュ有効・無効の対照結果と、再起動後の保持状態を基準にノードを選んでください。短期の検証や一時的なビルド需要ならレンタル、長期の固定負荷や物理インターフェースが必須なら自前機材という切り分けが安全です。

最後に、既存Runnerで同一プロジェクトの灰色検証を済ませ、命中ログ、工程別時間、容量、リリース再現性の4点を保存してください。キャッシュを維持できない構成なら、遠隔Macの利用方法を確認したうえで、持続型ノードへ移行するかを判断できます。