2026年9月10日から、GitHubはxcode-27とxcode-27-xlargeのRunnerをmacOS 27上で稼働させ、いずれもPublic Previewとして扱っています。詳細はGitHub Changelogの変更告知で確認できます。
したがって、Xcode 27 macOS 27 CI移行を通常のXcode更新として本番へ直接適用してはいけません。今週は既存の本番パイプラインを保ち、同じXcode 27を固定したリモート MacのmacOS 26対照ノードで差分を記録し、検証後に移行、二重運用、または保留を判断してください。
このページは、xcode-27ワークフローを管理し、宿主OSの変化がコンパイル、テスト、スクリプトに影響するか確認したい開発者向けです。Apple向けCIを担当するDevOpsエンジニアや、Preview Runnerの本番投入を判断するモバイル開発基盤責任者にも適しています。
※ 最終更新：2026年9月14日。 GitHub Changelog、GitHub-hosted Runner文書、xcode-27のイメージ一覧、AppleのXcodeシステム要件とXcode 27リリースノートを基に確認しています。macOS 27の正式提供状態、RunnerのGA移行時期、今後の修正結果は断定していません。
切替前：Xcode更新と宿主OS変更を分離する
基準環境の保存
最初に、直近で成功した本番ジョブを比較可能な基準として保存します。ワークフローのYAMLだけでなく、ジョブログの実行環境を対象にしてください。
保存対象は次のとおりです。
- Runnerのラベルとイメージ識別情報
- macOSのバージョン
- XcodeのバージョンとDeveloper Directory
- CPUアーキテクチャ
- Swift Package Manager、CocoaPodsなどのロックファイル
- Deployment Target、Scheme、SDK、主要なビルド設定
- 署名方式、キーチェーン、エクスポート設定
- xcresult、Archive、テストレポート
GitHubのmacOS Runnerに関する公式文書では、ホスト型Runnerの環境が固定された自社マシンとは異なることが説明されています。さらに、xcode-27イメージのソフトウェア一覧で、実際に搭載されたツールとバージョンを照合します。
依存関係、証明書、ビルドスクリプトを同時に変更しないでください。比較対象が複数変わると、失敗がXcode 27、macOS 27、依存パッケージ、署名設定のどれに起因するか判断できなくなります。
ラベルから推測しない
xcode-27 RunnerがmacOS 27へ変わった理由は何ですか。 GitHubの告知では、対象イメージが2026年9月10日からmacOS 27上で動作すると明記されています。つまり、同じラベルでも宿主システムが変わったため、ラベル名だけを見て旧環境と同一だと判断できません。
ジョブ冒頭で次の情報を出力し、成果物として保存します。
sw_vers
uname -m
xcode-select -p
xcodebuild -version
xcodebuild -showsdks
xcode-select -pで表示されるDeveloper Directoryと、xcodebuild -versionの結果が想定と一致するかを確認してください。YAMLのラベル、Runnerイメージ、macOS宿主、Xcode、Deployment Targetは別の項目です。
注意： macOS 27上でXcode 27が起動しただけでは、移行完了とはいえません。AppleのXcodeシステム要件とXcode 27リリースノートを確認し、SDKやツールチェーンの変更を記録してください。
初回実行：最小ジョブで失敗層を分ける
検証の順番
いきなりArchiveや本番配布を実行せず、最小構成のジョブから始めます。
- ソース取得とロックファイル検証
- 依存関係の解決
- 署名なしのビルド
- 単体テスト
- Simulatorテスト
- xcresultの生成と既存レポート処理
最小ジョブでも失敗するなら、プロジェクトの機能追加や依存更新を止めてください。完全なログ、環境出力、xcresult、生成物を保存し、macOS 27の宿主差分とXcode 27のツールチェーン差分を分けて調査します。
Xcode 27 CIの更新後にビルドが失敗した場合、最初に見る場所はどこですか。 終了コードだけでなく、最初に失敗した処理を確認します。Set up jobの環境情報、依存解決ログ、xcodebuildの最初のエラー、テスト対象の起動結果を時系列で並べると、後続エラーによる誤判定を避けられます。
差分の切り分け
Xcodeだけの問題か、macOS宿主の問題かを分けるには、同じプロジェクト、同じロックファイル、同じXcode 27でmacOSだけが異なる対照環境を用意します。GitHub ActionsのPreview Runnerと、固定したリモート Macを同じ入力で実行してください。
| 観測結果 | 疑う層 | 次の判断 |
|---|---|---|
| 両方の環境で同じコンパイルエラー | プロジェクト、Xcode、依存関係 | ソース、SDK、ロックファイルを確認 |
| Preview Runnerだけ失敗 | macOS 27、イメージ、権限、アーキテクチャ | 本番移行を停止し、対照ログを保存 |
| 署名なしビルドは成功し、Archiveで失敗 | 証明書、キーチェーン、Export設定 | 配布用資格情報を本番から分離 |
| ビルドは成功し、Simulatorだけ失敗 | ランタイム、テスト起動、並列実行 | Simulatorの存在と起動ログを確認 |
| 成果物は生成されるが解析に失敗 | xcresult形式、レポートスクリプト | パーサーと保存処理を個別に検証 |
XcodeとmacOSのどちらが原因か、どう区別しますか。 同じXcode、同じ依存関係、同じビルド設定で宿主OSだけを変えます。差分がPreview Runnerにだけ現れれば、macOS 27、イメージ内容、権限、CPUアーキテクチャの順に調べます。
最初の確認：スクリプトとアーキテクチャの前提
環境依存の検査
Shellスクリプト内の固定パス、Homebrewの配置、PythonやNode.jsの呼び出し方法を確認します。Intel向けのパス、/usr/localを前提にした処理、GUIログインを必要とするツール、Runner上での権限依存は、宿主変更で表面化しやすい箇所です。
バイナリ依存やネイティブプラグインは、再インストールを先に行わず、アーキテクチャとリンク先を調べます。
file path/to/binary
otool -L path/to/binary
brew config
Community Actionや外部スクリプトも、macOSのバージョン、Intelパス、Developer Directoryを直接参照していないか確認してください。修正できないIntel専用部品やOS依存部品は、移行対象から隔離し、固定リモート Macで同じ入力を再実行します。
macOS ARMのCI環境で何を確認すべきですか。 uname -mの結果だけで判断せず、ネイティブバイナリ、RubyやNode.jsのネイティブ拡張、Homebrewのインストール先、Simulatorランタイムの対応を確認します。アーキテクチャ差分が見つかった時点で、依存を全面更新するのではなく、該当部品だけを再現試験してください。
移行判定の記録
| 判定項目 | 合格条件 | 記録する証拠 |
|---|---|---|
| 環境 | macOS、Xcode、アーキテクチャが想定どおり | ジョブログ、イメージ一覧 |
| 依存関係 | ロックファイルから同じ解決結果を得る | 解決ログ、ハッシュ |
| コンパイル | 署名なしビルドが完了する | xcodebuildログ、生成物 |
| テスト | UnitとSimulatorの結果を取得できる | xcresult、テストレポート |
| 署名 | 管理された資格情報で検証できる | 署名検証ログ |
| 復旧 | 旧経路へ戻し、再実行できる | ロールバック手順と実行記録 |
完全ビルド：テストと成果物を段階的に確認する
Archiveが成功しただけで、移行を完了扱いにしないでください。無署名ビルド、Unitテスト、Simulatorテスト、xcresult解析の順に確認し、どの段階で旧環境との差が出たかを記録します。
Simulatorでは、対象ランタイムが実際に存在するか、テストアプリが起動するか、並列実行時に出力が欠落しないかを確認します。既存のレポートスクリプトが新しいxcresultを読み取れることも、生成物とは別に検証します。
AppleのXcode 27リリースノートに記載された既知の制限や変更と、現場で観測した失敗を対応付けてください。公式説明にない問題を、すぐに「macOS 27の仕様」と断定してはいけません。
候補リリース：署名と配布を本番から分離する
資格情報の扱い
Preview Runnerの初回試行で正式な配布を実行しないでください。非本番の証明書、管理対象のキーチェーン、受け入れ用アプリを使い、署名、Archive、Export、後続の配布処理を個別に確認します。
証明書削除、キーチェーン再構築、署名設定の上書きを行う場合は、影響範囲と復旧入口を先に記録してください。失敗したからといって、Runner上の資格情報を無差別に消去すると、原因調査と復旧の両方を難しくします。
GitHubの自社ホストRunnerに関する説明も参照し、固定したリモート Macを使う場合の登録、権限、ジョブ分離、回収手順を設計します。
xcode-27のPreview Runnerを本番配布に使えますか。 技術的にジョブが完了しても、現時点ではPreviewとして扱うべきです。署名と配布を含む本番経路を直接移さず、既存Runnerを残したまま、固定リモート Macとの成果物、署名検証、ログ、復旧手順を比較してください。
Xcode 27を固定したmacOS 26の対照環境が必要なら、VMSPINのリモート Mac環境で利用可能な構成と受け渡し方法を確認し、プロジェクトの秘密情報を投入する前にアクセス権と削除手順を決めます。料金や利用期間は、作業量と保持したい対照期間に合わせて日本語の料金案内を確認してください。
上線初週：移行、二重運用、保留を決める
本番判定
単一ジョブの成功ではなく、次の観点をそろえて判定します。
- 主要ワークフローを同じ入力で再現できる
- ビルド、Unit、Simulator、xcresult解析が通る
- 署名とExportの結果を比較できる
- Runnerの環境差分を後から追跡できる
- Preview Runnerだけの障害を検知できる
- 旧パイプラインへ戻せる
- 配布前に停止できる承認点がある
macOS 27でしか発生しない障害が残る場合は、Xcode 27を固定したリモート Macを対照ノードとして残し、二重運用を続けます。すべての重要ジョブが通り、成果物と復旧経路を確認できた場合に限り、段階的に対象ワークフローを広げてください。
macOS 26の対照環境をどう保つべきですか。 Xcode、依存ロックファイル、署名方式、Scheme、ビルド設定を固定し、同じコミットまたは同じ成果物でPreview Runnerと比較します。対照ノードは「速い代替」ではなく、宿主OS差分を説明するための再現可能な基準として管理します。
GitHubがPreview状態、宿主OS、ラベル、ソフトウェア一覧を変更した場合、またはAppleが新しいXcode 27ビルドやmacOS 27の状態を公開した場合は、判定をやり直してください。変更履歴はGitHub Changelogとイメージ一覧で確認できます。
今回の移行では、固定Runnerをすぐに捨てるより、実行環境を自分で保持できる対照ノードを用意する方が安全です。ホスト型Runnerだけに依存すると、ラベル変更、ソフトウェア一覧の更新、再現用ログの不足が重なり、障害時の説明が難しくなります。
一方、固定リモート Macは初期設定、アクセス管理、証明書保護、再起動後の復旧を自分で設計する必要があります。長期にわたり高い実行量が続き、物理デバイス接続や専用ネットワークが必要なら自社保有も候補ですが、移行検証や一時的な二重運用なら、VMSPINで固定したMac環境を借りて主要ワークフローを再現する方が、購入前に必要な証拠を集めやすい選択です。
まずは本番を切り替えず、同じXcodeと異なるmacOSという比較条件を作ってください。そこで得たログ、生成物、署名結果、復旧記録を基に、xcode-27を移行するのか、当面は二重運用にするのかを決めるのが、2026年のCI運用では現実的です。