Tuist Xcode Cacheは開く価値がある？2026年リモートMacの判断

同じ変更のコンパイルを何度も待たされるならキャッシュ、空きRunnerやUIテストで止まるならノード増設が先です。
Tuist Xcode Cacheは、重複コンパイルが主因のときだけ試し、待ち時間と実行環境の制約が主因ならリモートMacを増設します。両方が支配的なら、キャッシュと拡張を並行して検証してください。

大型のiOS/macOSプロジェクトで、同じ依存関係やソースを繰り返しビルドしている開発者向けです。自前のMac CIを運用するDevOpsエンジニアや、購入・レンタル・既存ノードの改善を判断する開発基盤の責任者にも適しています。

最終更新：2026年9月15日。Tuist Xcode Cacheの仕様、変更内容、Xcodeのビルド計測、CI Runnerの運用条件を公式資料で再確認しています。

SECTION 01まず時間を五つに分けて記録する

「ビルドが遅い」という一文だけでは、キャッシュを有効にしても判断を誤ります。最低限、次の時間を別々に記録してください。

• コンパイル時間
• キャッシュのアップロード・ダウンロード時間
• CI Runnerの待ち時間
• SimulatorやUIテストの実行時間
• 成果物が利用可能になるまでの実効時間

XcodeのBuild Timing Summaryでは、ターゲットや処理単位ごとの時間を確認できます。Appleもインクリメンタルビルドでは、依存関係と不要な再ビルドを確認するよう案内しています。AppleのXcodeビルド最適化資料を基準に、クリーンビルドと増分ビルドを分けて記録してください。

現象から最初の判断をする

この表は性能比率の一般論ではなく、あなたのCI記録をどこから調べるかを決めるためのものです。Runnerはオンラインであるだけでは十分ではなく、ジョブの要件に一致し、ルーティング対象になっている必要があります。セルフホストRunnerの公式ルールも確認してください。

SECTION 02Tuist Xcode Cacheが効く範囲と効かない範囲

Tuist Xcode Cacheはどのようなビルドを短縮できますか。

同じ入力から生成されるXcodeのコンパイル成果物を、別のビルドで再利用できる場合に候補になります。反対に、毎回異なるコンパイルフラグ、SDK、アーキテクチャ、依存パス、生成ファイルを使う処理は、同じ成果物として扱えない可能性があります。

Tuistの公式ガイドでは、Xcodeのコンパイル成果物を共有するための環境条件、CIでの設定、アップロード方法、命中状態の確認方法が説明されています。Tuist Xcode Cache公式ガイドを読み、ローカルで動いた設定をそのままCIへ移すのではなく、認証と保存先まで確認してください。

キャッシュ命中率が高くなくても使い続ける価値はありますか。

命中率だけで継続を決めないでください。命中したタスクが重いコンパイルなのか、軽い処理なのか、さらに取得時間を差し引いて実効時間が短くなったのかを見ます。命中状態が安定せず、同一コミットでも入力が変わるなら、キャッシュを増やす前に再現性を修正するのが先です。

Tuistの最近の変更記録では、キャッシュ成果物の転送でチャンク再利用を扱っています。ただし、転送作業を減らす仕組みであり、すべてのプロジェクトが同じ割合で高速化するという意味ではありません。チャンク再利用に関するTuistの変更記録も、局所的な改善と一般的な性能保証を混同せずに読んでください。

キャッシュを有効にする前の確認

• [ ] 同一コミットをクリーン環境で複数回実行し、コンパイル時間と依存関係解決を分離した
• [ ] Xcodeのビルドログで、再利用候補の処理と毎回実行されるスクリプトを区別した
• [ ] キャッシュ設定、保存先、アップロード方針、CI認証を同じジョブで確認した
• [ ] ローカル命中、リモート命中、未命中をログ上で区別できるようにした
• [ ] SDK、コンパイルフラグ、ターゲットアーキテクチャ、生成パスの差分を記録した
• [ ] 転送時間を含めても実効ビルド時間が短くなるか確認した
• [ ] 命中しない場合にキャッシュを無効化して元のビルドへ戻せるようにした

一つでも確認できない項目があるなら、本番の全ジョブへ広げず、限定したブランチや検証用ジョブで止めてください。

SECTION 03キャッシュ命中後もパイプラインが遅い理由

キャッシュが命中しているのに完了が遅い場合、次のような証拠の衝突が起きています。

• コンパイルは短くなったが、キャッシュ成果物の取得に時間がかかる
• キャッシュは再利用されるが、空きRunnerを待っている
• ビルド成果物は再利用できても、Simulatorの起動とUIテストは実行が必要
• コンパイルは済んでも、アーカイブや署名が専用の資格情報を要求する
• 同じMacでも、グラフィカルセッションやSimulator Runtimeの状態が一致しない

UIテストは、成果物を取得するだけでは完了しません。アプリをSimulatorまたは実機上で実行し、テスト環境を準備する必要があります。AppleのSimulator・実機テスト資料を基準に、コンパイルとテストの時間を別メトリクスにしてください。

署名とアーカイブも同様です。証明書、プロビジョニング、キーチェーン、アーカイブ設定の問題は、コンパイルキャッシュでは解消しません。Appleのアーカイブ問題に関する技術資料を参照し、リリース用Macの権限と秘密情報を確認してください。

SECTION 04待ち時間が主因ならリモートMacを分けて増やす

Xcodeのビルドが遅いとき、キャッシュとRunner追加のどちらを先に行うべきですか。

ビルド処理そのものが長いならキャッシュ、ジョブが空きノードを待っているならRunner追加が先です。キャッシュは実行中の一部処理を短縮できますが、すでに別ジョブで占有されているMacを同時に空ける機能ではありません。

PRごとの検証、定時ビルド、リリース用アーカイブを一つのキューに置くと、短いジョブが長いジョブの後ろで待つ構成になりやすくなります。ルーティング記録から、待ち時間、Runnerの稼働状態、要求されたラベルや環境条件を確認してください。

役割分離の判断

• PRビルド：短時間で結果を返すことを優先し、長いUIテストと分離します。
• 定時ビルド：キャッシュの検証や広いテスト範囲を許容しますが、リリース作業を塞がないようにします。
• リリース：署名、アーカイブ、資格情報を扱うため、専用のMacと復旧手順を用意します。

リモートMac CIの待ち時間とコンパイル遅延はどう見分けますか。

ジョブが受付されてからRunnerへ割り当てられるまでが長ければ待ち時間、Runner上でXcodeが処理を開始してから長ければ実行時間です。両方を一つの「ビルド時間」として集計すると、キャッシュ導入とノード増設の優先順位を誤ります。

CIの認証やジョブ登録に問題がある場合は、キャッシュ設定以前に実行環境の接続を確認してください。TuistのCI認証ガイドでは、CIで必要になる認証の考え方が整理されています。

SECTION 05対照試行で三つの選択肢を絞り込む

同じコミット、同じXcodeツールチェーン、同じターゲット範囲で、キャッシュなしとキャッシュありを比較します。さらに、空きノードが確保された場合と通常のキューの場合を分け、コンパイル、転送、待ち時間、テスト、成果物利用可能時点を記録してください。

判断は次のように固定すると、感覚的な「速くなった」を避けられます。

• キャッシュを採用：再コンパイルが主因で、命中状態と入力が安定し、転送後も実効時間が短い。
• リモートMacを増設・分離：Runner待ち、Simulator、UIテスト、署名が主因で、キャッシュ対象外の処理が長い。
• 双軌で運用：再コンパイルと待ち時間が同時に支配的。キャッシュをビルド系ジョブへ適用し、テスト・リリース用Macを別に確保する。
• いったん戻す：命中状態が再現せず、転送が増え、設定差分のために結果を説明できない。

停止条件も先に決めてください。入力差分を説明できない、ログで命中種別を判定できない、失敗時に通常ビルドへ戻れない、という状態なら、キャッシュの範囲を広げずプロジェクトまたはCI設定の修正へ戻ります。

SECTION 06現在の構成とリモートMacの使い分け

既存構成が単一のMac CIノードに集中している場合、Tuist Xcode Cacheを追加しても、UIテストや署名ジョブの占有は残ります。さらに、長いジョブがキューを塞ぐ、遠いキャッシュ端点から成果物を取得する、再起動後にグラフィカルセッションを復旧できない、といった運用上の弱点もあります。

一方、リモートMacを増やす方法は、ノード費用と環境管理の対象を増やします。物理デバイス、専用の署名情報、特定の周辺機器が必要な場合は、レンタルだけで完結しないこともあります。長期にわたり高負荷を固定して使うなら自社保有、短期の検証やリリース集中期ならMACNOXのMacレンタルを比較する価値があります。

まずはMACNOXのMacレンタル構成で接続方式と利用形態を確認し、継続利用の費用感は料金案内で照合してください。対照試行の結果が「待ち時間、Simulator、署名」に寄っているなら、キャッシュだけで粘らず、必要な期間だけリモートMacを追加してCIの役割を分ける方が、原因と効果を追跡しやすくなります。

再コンパイルが支配的ならTuist Xcode Cache、空きノード待ちや実行環境の制約が支配的ならリモートMac、両方なら双軌です。必要な期間だけ実際のMac環境を試す場合は、MACNOXの利用申込み案内を確認し、先に決めた停止条件と回退経路を残したまま導入してください。