Xcode 27のビルドが遅い：2026年リモートMac切り分けガイド

2026年8月24日時点で、Appleの公式リリースノートではXcode 27はBetaとして扱われています。Xcodeの公式リリースノートで確認できるこのバージョン状態が、まず重要な判断材料です。

症状 → 最速の対処

Xcode 27のビルドが遅いなら、最初に全キャッシュを消したりMacを増強したりせず、冷間ビルドと増分ビルドのTiming Summaryを別々に保存してください。原因をキャッシュ失効、依存関係とスクリプト、インデックス競合、ディスクとメモリの順に分け、Betaだけで再現するならXcode 26.6の本番経路を残して二重検証します。

この記事は、Xcode 27へ更新してからローカルまたはリモートMacの所要時間が変わったAppleプラットフォーム開発者向けです。常時稼働するCIノードを管理するDevOps担当者や、Beta版を本番へ導入するか判断するリリース担当者にも適しています。

最終更新：2026年8月24日。Xcode 27のバージョン状態と診断方法は、同日確認したAppleの公式リリースノートおよびビルドシステム資料を基準にしています。Betaの内容は後続のBeta、RC、正式版で変わる可能性があります。

まず「遅い工程」を同じ条件で分離する

「ビルドが遅い」という報告だけでは、原因を特定できません。初回の冷間ビルド、日常の増分ビルド、Archive、テスト、エディターのインデックスは、利用するキャッシュと処理経路が異なるためです。

XcodeのメニューからTiming Summaryを有効にするか、コマンドラインでは次のように記録します。

xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Debug \
  -showBuildTimingSummary \
  build

Appleの増分ビルドの速度改善に関する公式資料に沿って、同一コミット、同一Scheme、同一対象プラットフォーム、同一構成で比較してください。Xcode 26.6の安定したジョブとXcode 27の結果を混ぜず、ログを別ファイルに保存します。

「前より遅い」という体感ではなく、どのターゲット、スクリプト、依存準備が時間を占めたかを確認できて初めて、回帰と環境差を区別できます。

第一段階：増分ビルドが全量化していないか確認する

変更していないコードまで再コンパイルされる場合、DerivedDataの容量だけを見ても原因は分かりません。依存関係グラフが再生成されているのか、Run Scriptが毎回実行されているのか、入力ファイルのタイムスタンプやビルド設定が変化しているのかをTiming Summaryと詳細ログで確認します。

確認する項目は次のとおりです。

• Targetの依存関係に不要な循環や広すぎる依存がないか。
• Run Script Phaseに入力ファイルと出力ファイルが定義されているか。
• 構成ごとの条件分岐で、毎回異なるフラグや生成ファイルを作っていないか。
• CIのジョブごとにDerivedDataの保存先を無意味に変えていないか。
• 変更していないターゲットが、毎回Timing Summaryへ現れていないか。

Appleのビルドシステム説明では、ターゲット間の依存関係がビルド順序と再実行範囲に関係します。さらに、明示的なモジュール依存関係の診断資料も参照し、暗黙の依存によって不要な処理が広がっていないかを調べます。

DerivedDataを削除するのは、ログからキャッシュの破損や不整合を確認できた場合だけにしてください。対象プロジェクトのデータを退避してから再生成し、その後の連続した増分ビルドで改善が維持されるかを確認します。削除直後の最初のビルドだけを見て、修復成功と判断してはいけません。

依存パッケージとスクリプトの待機時間を切り分ける

Swift Package、CocoaPods、独自の依存取得処理が毎回動いていると、コンパイラーの速度を測っているつもりで準備処理を測ることになります。初回ログと後続の増分ログを並べ、解決、ダウンロード、生成、コンパイルのどこで待っているかを分けてください。

Run Scriptの入力と出力を設定する公式資料を基準に、スクリプトが「常に実行」される設計になっていないかを確認します。入力を宣言しても、出力先が毎回変わる、生成物を別ディレクトリへ移す、環境変数から不安定な値を読む、といった実装ならキャッシュは安定しません。

CIでSwift Packageを使う場合は、継続的インテグレーションにおけるSwift Packageの公式指針を参照し、依存解決を各ジョブへ無条件に持ち込んでいないかを見直してください。修正後は、変更なしの増分ビルドでスクリプトと依存準備が適切にスキップされることをログで確認します。

インデックスとビルドが同じノードを奪い合っていないか

リモートMacでXcodeをGUI接続したままCIを走らせると、コンパイル以外の処理がCPU、メモリ、ディスクI/Oを使います。インデックス、SourceKit、SwiftUI Preview、Simulatorが同時に動く状態では、純粋なビルドシステムの回帰と、開発セッションの負荷を区別できません。

次の順で比較してください。

• Xcodeを閉じた、またはGUI負荷を切り離した状態でコマンドラインビルドを実行します。
• 同じコミットと構成で、Xcodeを開いた状態のビルドを記録します。
• アクティビティモニタでメモリプレッシャー、スワップ使用量、ディスクI/Oを確認します。
• GUIビルドだけが遅いなら、PreviewやSimulatorなど不要な並列処理を停止します。
• コマンドラインでも同じ段階が遅いなら、インデックスではなく依存関係やスクリプトへ戻ります。

Appleのメモリプレッシャーとスワップを確認する手順では、メモリ使用量だけでなくメモリプレッシャーとスワップ活動を確認するよう案内されています。インデックスを長期的に無効化してしまうと、コードナビゲーションや補完の問題を隠すだけになり、根本原因の解決にはなりません。

FAQ：よくある誤判断をどう避けるか

Xcode 27で変更のたびに最初からビルドされるように見えるのはなぜですか？

依存関係グラフ、スクリプトの入力と出力、条件付きのビルド設定、DerivedDataの保存先が変わると、変更していないターゲットまで再コンパイルされることがあります。まずBuild Timing Summaryで再実行されたターゲットを確認し、キャッシュの容量ではなく、何が入力として扱われたかをログで追跡してください。

リモートMacでXcodeのインデックスが終わらない場合はどうすればよいですか？

インデックス中にSourceKit、SwiftUI Preview、Simulator、コンパイルが同じノードで動いていないかを確認します。GUIを切断してコマンドラインビルドだけを実行し、ビルド自体が遅いのか、編集環境の負荷だけが高いのかを分離してください。インデックスを恒久的に無効化するのは最後の手段です。

DerivedDataを削除すればXcode 27のビルド遅延は直りますか？

キャッシュ破損や不整合がログで確認できる場合は、対象プロジェクトのDerivedDataだけを削除する意味があります。ただし、毎回の依存関係再生成、Run Scriptの無条件実行、ネットワーク待機が原因なら、削除後も同じ遅延が再発します。全プロジェクト分を一括削除する前に、対象範囲を限定してください。

ビルドの遅さがプロジェクト原因かMacの性能不足かを判断する方法は？

同じコミット、Scheme、対象プラットフォーム、構成で、冷間ビルドと連続した増分ビルドを分けて記録します。ビルド段階が一貫して長いなら工程や依存関係を疑い、CPUではなくメモリプレッシャー、スワップ、ディスクI/Oが継続して逼迫するならMac側を疑います。単一ジョブと並列ジョブの差も判断材料になります。

リモートMacの資源不足を疑う前に確認する

長期稼働するリモートMacでは、複数バージョンのXcode、DerivedData、パッケージキャッシュ、CIの作業ディレクトリが蓄積します。しかし、空き容量が少ないという印象だけで拡張を決めるのは危険です。ビルド中のディスクI/O、メモリプレッシャー、スワップ、並列ジョブ数を同時に記録してください。

CIの作業ディレクトリ、DerivedData、パッケージキャッシュを複数ジョブで共有すると、書き込み競合や予期しない再生成が起きます。ジョブ単位で分離した場合に遅延が消えるなら、MacのCPU性能を上げる前にキャッシュ配置と同時実行方針を修正するべきです。

長期運用の構成を見直す場合は、KVMFLUXの利用シーンで継続的なMac環境の使い方を確認し、必要な作業がGUI開発なのか、CI専用なのかを先に整理してください。

第二段階：修正、切り戻し、拡張を条件で選ぶ

判断は、次の順序にすると失敗しにくくなります。

• [ ] 同じコミット、Scheme、対象プラットフォーム、構成を固定した。
• [ ] 冷間ビルドと増分ビルドのTiming Summaryを別々に保存した。
• [ ] 再コンパイルされたターゲットとRun Scriptの実行状態を確認した。
• [ ] 依存解決、ダウンロード、生成処理の待機時間を分離した。
• [ ] GUI接続時とコマンドラインのみの結果を比較した。
• [ ] メモリプレッシャー、スワップ、ディスクI/Oをビルド中に記録した。
• [ ] 単一ジョブと並列ジョブで同じ症状が出るか確認した。
• [ ] Xcode 26.6とXcode 27を同一プロジェクト条件で分離して検証した。
• [ ] 修正後に冷間ビルド、連続した増分ビルド、再起動後のビルドを再確認した。

プロジェクトの依存関係やスクリプトに遅延が集中しているなら、先に工程を修正します。Xcode 27 Betaでだけ再現し、Xcode 26.6では安定しているなら、Xcode 26.6を本番CIに残し、Beta用の隔離ノードで検証します。

一方、ビルド段階そのものは正常なのに、メモリプレッシャーやディスクI/Oの逼迫が継続し、並列ジョブでのみ悪化するなら、ノードの分離または構成拡張を検討します。判断に使うのは一度の最長時間ではなく、同一条件で繰り返しても再現する資源ボトルネックです。

Xcodeの複数版を使う場合は、Xcode 27の開発環境を確認できるKVMFLUXの案内を参照し、本番用と検証用の費用条件を比較しながら、安定版の経路を残したまま独立したMacで基線を取り直す方法が現実的です。

現在の構成が共有MacやLinux中心のCIであれば、ジョブ競合、macOS専用ツールチェーンの不足、GUI接続時の資源衝突が隠れた欠点になります。自前のMac miniは物理機器の保守、設置場所、故障時の復旧を自分で担う必要があり、短期のBeta検証や一時的な二重ツールチェーンには過剰になりがちです。

Xcode 27とXcode 26.6を分離して同じプロジェクトを検証したい、または既存ノードの資源変数を切り離したい場合は、KVMFLUXの料金と利用条件を確認し、必要な期間だけ独立したリモートMacを使う構成が適しています。原因を確認した後に本番ノードを修正・切り戻し・拡張のどれに進むかを決めれば、根拠のないキャッシュ削除やハードウェア購入を避けられます。

関連記事

• XcodeのCIをクラウド上のMacで運用する際の構成と注意点
• Xcode 27のインストール失敗を切り分ける診断ガイド

よくある質問