Xcode 27 と Xcode 26 はどう共存する？2026年のリモートMac CI設定

AppleのXcode 27のシステム要件では、対応するmacOSとApple siliconの条件が明示されています。ここから導ける結論は明確です。互換するApple silicon MacならXcode 27とXcode 26の共存は可能ですが、共有CIでは全体設定を切り替えず、各ジョブでDEVELOPER_DIRを固定してください。

対象は、Xcode 26で正式版をリリースしながらXcode 27 Betaで検証したい開発チームです。複数リポジトリを運用するDevOps担当者、リモートMacの更新・容量・障害復旧を担当する管理者にも適しています。

最終更新：2026年9月1日。Xcode 27の仕様、システム要件、コマンドラインツールの挙動は、同日確認したApple Developer公式資料を基準にしています。Beta期間中は要件やコンポーネントの挙動が変わる可能性があります。

Xcode 27とXcode 26の共存で起きる衝突

典型的な失敗は、パイプラインの宣言ではXcode 26を指定しているのに、ログにはXcode 27のSDKが現れるケースです。原因は、ノードのxcode-select、シェルの環境変数、CIランナーが起動する子プロセスの設定が別々に評価されることです。

共存で警戒すべき衝突は次のとおりです。

• アプリケーションの上書きで、正式版の保存先が失われる
• macOSの要件が合わず、片方だけ起動できる
• SDKやシミュレーターが未導入で、ビルドだけ成功してテストで止まる
• DerivedData、Swift Packageのキャッシュ、アーカイブが混ざる
• 署名環境は同じでも、ジョブが意図しないツールチェーンを呼び出す
• ノード再起動後に環境変数や既定の開発者ディレクトリが戻る

ログには少なくともXcodeのバージョン、ビルド番号、SDK、Developerディレクトリを残してください。xcodebuild -versionだけでは不十分です。xcrun --findで実体のパスも確認します。

固定配置とタスク単位の選択を分ける

正式版とXcode 27 Betaは、識別しやすく上書きされない名前で保存します。例えば次のように、アプリケーション名とDeveloperディレクトリを対応させます。

AppleのXcode 27 Release NotesとXcode 26 Release Notesを、導入する版ごとに確認します。対応していないmacOSへパッケージを改変して配置する方法は、CIの基盤にしないでください。

ノード全体の既定値を変更するxcode-select --switchは、同じMacで並列ジョブが動くと影響範囲が広すぎます。保守作業や単独ノードの初期設定には使えますが、共有CIのジョブ選択には向きません。

Appleのコマンドラインツール設定に関する公式説明でも、Xcodeの選択方法は明確に分けられています。ジョブの冒頭で環境変数を設定し、後続コマンドへ確実に継承させてください。

export DEVELOPER_DIR="/Applications/Xcode-26.app/Contents/Developer"

xcodebuild -version
xcrun --find xcodebuild
xcrun --sdk iphoneos --show-sdk-path
xcrun swiftc --version

検証ジョブではパスだけを置き換えます。

export DEVELOPER_DIR="/Applications/Xcode-27-Beta.app/Contents/Developer"

xcodebuild -version
xcrun --sdk iphonesimulator --show-sdk-path

この出力をログへ保存し、期待する文字列と一致しなければ直ちに終了させます。誤ったSDKで生成物を作り続けるより、早い段階で失敗させるほうが復旧しやすくなります。

コンポーネントとキャッシュを版ごとに隔離する

Xcodeのアイコンが開くことは、CI環境の完成を意味しません。対象プロジェクトが必要とするプラットフォーム、シミュレーターランタイム、初回起動処理を、Xcodeごとに確認します。

Appleの追加コンポーネントのインストール手順に従い、コンポーネントの操作対象が正しいXcodeであることを確認してください。追加シミュレーターは、Appleのシミュレーター追加手順も参照します。

キャッシュは、Xcode版だけでなく流水線名も含めて分けます。例えばDerivedData/release-xcode26とDerivedData/validation-xcode27のように保存先を分離します。Swift Packageの解決キャッシュ、アーカイブ、テスト結果、ログも同じ境界で管理してください。

AppleのBuild Settings Referenceにある設定を使い、プロジェクト側の出力先を明示します。古い成果物を再利用している可能性がある場合は、まずクリーンビルドを実行し、その後に同一条件で再ビルドします。ビルド時間や性能については、実際の構成で測定した記録がない限り断定しません。

署名と再起動後の復旧を検証する

署名証明書やプロファイルをXcodeごとに複製する必要はありません。重要なのは、同じ管理されたCIユーザーとキーチェーン境界で、正式版とベータ版がそれぞれ意図したジョブを完了できることです。

確認順序は次のとおりです。

• 正式版ジョブでクリーンビルドを実行する
• 正式版のユニットテストとアーカイブを実行する
• ベータ版ジョブで検証用ビルドを実行する
• 必要な場合だけ、ベータ版でUIテストを実行する
• 両方の署名結果と書き出しログを保存する
• ノードを再起動し、同じジョブを再実行する
• Xcode 27 Betaの更新を想定し、正式版の経路が変わらないことを確認する

共存か専用ノードかを条件で決める

共存を続けるかは、次の分岐で決めてください。

• 正式版と検証版のジョブが同時実行されず、各ジョブがDEVELOPER_DIRと出力先を固定できるなら、同一ノードで共存します。
• 同時実行するが、キャッシュと署名境界を分離し、全ジョブの事前検査を強制できるなら、限定的に共存します。
• 全体のxcode-selectをジョブごとに変更しているなら、設定をタスク単位へ移すまで共用を拡大しません。
• 再起動後にパス、コンポーネント、署名が戻らないなら、Xcode 27の検証を独立ノードへ退避します。
• Xcode 27 Betaの更新で正式版ジョブへ影響が出るなら、Xcode 26を固定した専用ノードへ戻します。
• 物理デバイス、専用キーチェーン、厳格な同時実行が必要なら、最初から専用ノードを選びます。

リモートMac CIのノードを増やす場合は、まずMacHTMLのコンソールでアクセス方式と稼働状態を確認し、管理手順はMacHTMLのヘルプで照合してください。必要な期間だけ検証ノードを分ける運用なら、購入前にMacHTMLのレンタル条件と、保存するキャッシュや署名情報の扱いを確認しておくと判断しやすくなります。

よくある確認事項

FAQでは、同一Macへの導入可否、ジョブ単位の版指定、DEVELOPER_DIRとxcode-selectの使い分け、共有状態、更新前の回 rollback を個別に確認できます。特にBetaを含む場合は、アプリの起動確認だけで完了扱いにしないことが重要です。

まとめ

Xcode 27とXcode 26の共存では、インストールそのものよりも、ジョブが呼び出したツールチェーンを証明できることが重要です。固定したアプリ配置、ジョブ単位のDEVELOPER_DIR、版別キャッシュ、コンポーネント確認、署名と再起動後の復旧検査を一組で運用してください。

既存のMac miniや自社サーバーを使う構成は、購入費用、保守担当者、故障時の交換、設置場所、常時接続の管理が負担になります。Linuxのクラウド環境ではXcodeとAppleの署名ツールチェーンをそのまま扱えず、仮想化構成ではmacOS要件や物理デバイス連携が別の制約になります。共存の検証結果から並列性とロールバック要件が見えたら、正式版ノードを置き換えるのではなく、Xcode 27確認用のMacHTMLリモートノードを期間限定で分ける方法を検討してください。

よくある質問

関連記事: Xcodeの複数バージョン運用に適したCI/CD向けMac miniの性能と構成を確認する リモートMacで開発環境とシミュレーターを整える基本設定を学ぶ