GitHub ActionsでXcode 27.1をどう固定する？2026年企業ガイド

GitHubは2026年10月15日、Xcode 27 Runnerイメージの一般提供を発表しました。対象のOSやRunner構成は、GitHubの公式発表で確認できます。

症状：runs-on: xcode-27にしたのに、実際のXcode小バージョンが不明です。
最短策：イメージ内のXcode 27.1を明示的に選び、ビルドログに選択結果を記録してください。タグだけではバージョン固定の証拠になりません。

この記事は、GitHub ActionsのiOS／macOSワークフローを管理し、RunnerのアーキテクチャやmacOSの要件も確認する技術責任者向けです。自社のMac構築ノードを残すべきか判断したい場合にも、確認項目を使えます。

最終更新：2026年10月18日。 日付とイメージの仕様は、GitHubの公式告知、xcode-27イメージの現行マニフェスト、AppleのXcodeリリース記録を基準にしています。運用前には、マニフェストに記載されたインストール済みバージョンと選択先を再確認してください。

RunnerタグとXcodeの固定は別の設定です

runs-on: xcode-27が指定するのはGitHub ActionsのRunnerイメージです。そこから実際に選ばれるXcodeの小バージョンまで固定されるとは限らず、イメージ更新で既定の選択状態が変わる可能性もあります。ワークフローの宣言と、ビルドに使われたツールチェーンは分けて検証してください。

AppleはGitHubのイメージ告知と同じ2026年10月15日にXcode 27.1を公開しています。利用可能なイメージやXcodeのパスは更新されるため、Runnerイメージのマニフェストにある現行情報を参照し、未確認のパスを設定例として流用しないでください。

GitHub Actionsのxcode-27 Runnerは、既定でどのXcodeを使いますか

ラベル名だけから、実際に選択されるXcodeの小バージョンを断定することはできません。インストール済みバージョン、既定の選択先、イメージの更新内容を、実行時点のマニフェストとジョブログで照合します。

Xcode 27.1を明示選択する手順

必要なのは、イメージに含まれる対象バージョンを調べ、実行環境でそのバージョンを選んだうえで、ビルドプロセス自身が使った版を記録することです。GitHub Actionsのワークフロー構文ではRunnerの指定方法を確認できますが、RunnerラベルとXcodeの選択は別に扱います。

xcode-27イメージ内でXcode 27.1を選ぶ流れ

次の順に確認してください。

1. GitHubの現行イメージマニフェストを開き、対象のXcode 27.1がインストール済みか、該当する開発者ディレクトリのパスが何かを確認します。過去のログや別イメージのパスをそのまま設定しないでください。
2. ワークフローでRunnerラベルを選びます。xcode-27はイメージ選択であり、Xcode小バージョンの固定指定ではないと設定レビューに明記します。
3. マニフェストで確認したパスを使い、Runner上でXcode 27.1を明示的に選択します。具体的なパスや利用可能な切り替え方法はイメージの現行記載に合わせてください。
4. ビルド開始前にxcode-select -pとxcodebuild -versionを実行し、選択された開発者ディレクトリとXcodeのバージョンを記録します。必要に応じてxcrun --findでビルドに使うツールの所在も確認します。コマンドの用途はAppleのコマンドラインツール資料で確認できます。
5. ログをコミットID、Runnerイメージ、ビルド結果とひも付けて保存します。設定ファイルにバージョンを記しただけでは、実際にそのツールチェーンでビルドした証明になりません。

runs-on: xcode-27だけで小バージョンを固定できますか

できません。タグはRunnerイメージの選択に使われるため、そこに含まれるXcodeや既定選択の確認が別途必要です。Xcode 27.1を使ったことを再現可能にするには、明示選択に加え、実行ログとイメージ情報を保存してください。

注意：ビルドが成功した事実だけでは、Xcode 27.1が使われたとは判断できません。ログに実際のバージョンが残っていない場合は、成功結果ではなく検証不十分として扱ってください。

macOSとRunnerアーキテクチャの適合確認

GitHubの案内では、Xcode 27 RunnerイメージはmacOS 27上で動作し、xcode-27とxcode-27-xlargeのラベルが提供されます。また、対応アーキテクチャはApple Siliconで、Intel Runnerはサポート対象外です。これらの仕様は変更され得るため、導入時には公式イメージ一覧と対象イメージのマニフェストを照合してください。

GitHub ActionsのXcode 27.1イメージはIntel Runnerに対応しますか

公式仕様上、xcode-27イメージはIntel Runnerに対応していません。Intel専用の依存関係やテスト要件が残るなら、タグの切り替えだけで解決しようとせず、別の適合するRunnerを維持してください。

導入前には、少なくとも次を個別に確認します。

• OS要件： プロジェクト、SDK、ビルドスクリプトがmacOS 27で動作するか。別のmacOSバージョンが必須なら、xcode-27を前提にしません。
• CPUアーキテクチャ： ネイティブ依存関係、バイナリツール、テスト対象がApple Siliconで実行できるか。Intel前提の処理がある場合は、互換性を実測してから移行します。
• ネットワーク経路： ビルドがプライベートな依存先や社内システムに到達する必要があるか。到達性を確認できない環境では、公開Runnerに移せると仮定しないでください。
• 署名と配布： 証明書、プロビジョニング、成果物の保管とリリース手順が、新しい実行環境で成立するかを確認します。
• デバイス依存： 実機テストや物理接続が必須なら、Runnerイメージだけで要件を満たすと判断しないでください。

実行ログと互換性で移行を判定する

設定宣言、Runnerの初期化ログ、実際のビルドツールの記録は、それぞれ証明する内容が異なります。宣言は意図、初期化ログは割り当てられた環境、xcodebuild -versionなどの記録は選択状態の確認に役立ちます。最終的には同じコミットを対象に、依存関係解決、ビルド、テスト、署名・配布までを隔離環境で比較してください。

比較中は、失敗を「Xcodeの問題」と一括りにせず、OS、CPUアーキテクチャ、依存先への接続、署名設定、ツールチェーン選択に分解します。所要時間や成功率の実測がない段階で、性能差や改善率を推定値として記載するのは避けてください。

GitHubホストRunnerと自社管理ノードの運用条件は、GitHubのセルフホストRunner資料も参照し、責任分界や維持作業を確認します。自社ノードやリモートMacを比較する場合は、ベアメタルと仮想化macOSの違いも判断材料になります。

固定性と移行条件の比較

以下は実測性能ではなく、バージョン固定の証拠と互換性確認の観点から見た運用評価です。記号は固定性を表し、Aが高く、Cは単独では不十分です。

同じコミットで依存解決から署名まで通り、必要なOS・アーキテクチャ・ネットワーク要件も満たすなら、対象ワークフローから段階的に切り替えます。条件を確認できない場合や、Intel、macOS 26、実機接続などの要件が残る場合は、既存ノードを維持して対象を限定してください。マニフェストの更新で版やパスが変わった場合に戻せるよう、旧環境の利用条件と担当者も記録しておきます。

MacDateを含めた実行環境の選択

GitHubホストRunnerはタグだけではXcode小バージョンを保証せず、xcode-27はIntelに対応せず、社内ネットワークや物理デバイス要件も別途検証が必要です。これらが運用上の制約になるなら、すべてをホストRunnerへ移すのではなく、要件に合うMacノードを一部に残す方法もあります。

一方、Macノードの自社運用には、更新管理、障害対応、稼働状態の維持が伴います。短期の検証環境や必要な期間だけ使う構成を比較したい場合は、MacDateの料金案内を確認し、契約前に必要なmacOS、Xcode、CPUアーキテクチャ、ネットワーク条件が実際に提供可能か照合してください。特定のXcodeバージョンを利用できるとは前提にせず、要件を確認してから選ぶことが、不要な切り替えと環境差の再発を防ぎます。