Xcode 27 GitHub Actions セルフホストRunner構築

2026年7月31日時点で、AppleはXcode 27 beta 4についてApple Silicon MacとmacOS Tahoe 26.4以降を要求しています。したがって、今週の判断は明確です。Xcode 26.6を本番用に残し、独立したApple Silicon MacへXcode 27のセルフホストRunnerを追加する二系統移行を選びます。全量切り替えは、ビルド、テスト、署名、Archiveの検証が終わるまで保留してください。 (Appleのシステム要件)

最終更新日：2026年7月31日。 Xcodeの対応表、Xcode 27 Release Notes、GitHub ActionsのRunner仕様とChangelogを照合しています。Appleの次回ベータ、Release Candidate、正式版の公開、またはGitHubのxcode-27ラベルや対応アーキテクチャの変更があった場合は、環境要件を再確認してください。

今週の移行判断を先に固定する

Xcode 27 GitHub Actions セルフホストRunnerを導入する際に避けるべきなのは、既存の本番Runnerへベータ版を上書きすることです。Xcode 27 beta 4はApple Silicon専用で、macOS Tahoe 26.4以降が必要です。一方、Appleのシステム要件表ではXcode 26.6が安定版として掲載され、macOS Tahoe 26.2以降に対応しています。(AppleのXcodeシステム要件)

また、GitHubが提供するxcode-27のホストRunnerは2026年7月16日に公開プレビューとなりましたが、ARM64専用であり、従来のIntel向けRunnerとは扱いが異なります。これは互換性確認には使えますが、署名鍵や社内リソースを含む本番処理を、検証なしで移す根拠にはなりません。(GitHub Changelogの公開プレビュー告知)

この判断は、Xcode 27の新機能を評価する記事ではありません。目的は、現在のiOS CI/CDを止めずに、次のツールチェーンを実際のプロジェクトで検証できる状態へ移すことです。

この手順の対象は、iOSまたはmacOS CI/CDを担当するDevOpsエンジニア、手元にApple Silicon MacがなくSSHで長時間稼働するビルド環境を必要とする開発者、複数アプリの切り戻し条件を決める開発責任者です。単にXcodeをローカルで試したいだけなら、ここまでのRunner分離は必要ありません。

移行前に主ホストとパイプラインの境界を確認する

最初に確認するのは、Xcodeのインストール方法ではなく、検証用Macが本番Jobを受け取らない設計になっているかです。セルフホストRunnerはオンラインで待機しているホストがJobを実行するため、ラベルやRunner Groupを誤ると、Xcode 27の検証Jobだけでなく既存のArchive処理まで同じマシンへ送られる可能性があります。(GitHub公式のセルフホストRunner仕様)

GitHubの公式仕様では、RunnerはGitHubへ接続してJobを受け取るため、外向きHTTPSの443番ポートと、ワークフローに応じたGitHub関連ドメインへの接続が必要です。通信要件として最低70kbpsの送受信速度も記載されていますが、これはXcodeやSimulatorの実用的な性能を保証する数値ではありません。大きな依存関係やSimulatorランタイムの取得を想定する場合は、帯域だけでなく遅延と保存領域も確認します。

次に、既存ワークフローから以下を一覧化します。

• xcodebuildが参照するXcodeのパス
• Swiftの言語モードとコンパイラー
• 使用するSDK、Simulator、テスト対象OS
• Swift Package Manager、CocoaPodsなどの依存キャッシュ
• 証明書、Provisioning Profile、Keychainの参照方法
• Archive、署名、配布処理を実行するJob
• 本番ブランチ、Pull Request、手動実行のトリガー

Xcode 26.6とXcode 27を同一ホストに入れる構成も技術的には可能ですが、同じDerivedDataやSimulatorの状態を共有すると、ツールチェーン差分ではなくキャッシュ汚染が原因の失敗を生みます。初回移行では、ホスト自体を分けるほうが診断しやすく、失敗時の切り戻しも短くなります。

注意： Xcode 27のRelease Notesには、並列テスト時に複数プロセスの標準出力・標準エラーが遅延する既知の問題や、SimulatorデバイスがDevice Hubに表示されない可能性が記載されています。テスト失敗だけでなく、ログの遅延やSimulator検出の異常もベータ版固有の問題として記録してください。(Xcode 27 Beta Release Notes)

最初の1時間でRunner登録と常駐化を終える

1. 登録範囲をリポジトリ単位で決める

検証対象が1つのアプリだけなら、まずリポジトリ単位でRunnerを登録します。複数アプリで共用する場合でも、最初から組織全体へ公開せず、Xcode 27の検証用Runner Groupを作り、対象リポジトリだけを許可する構成が安全です。

GitHubではリポジトリ、組織、エンタープライズの各階層でセルフホストRunnerを追加できます。Runner Groupでは、利用できるリポジトリやワークフローを制限できます。(GitHub公式のRunner管理手順)

2. Apple SiliconとXcode 27をラベルで識別する

Runnerの登録時には、既定ラベルに加えて、例えば次のようなカスタムラベルを付けます。

runs-on: [self-hosted, macOS, ARM64, xcode-27, validation]

ラベルは累積条件です。上記の場合、self-hosted、macOS、ARM64、xcode-27、validationのすべてを持つRunnerだけが候補になります。GitHub公式ドキュメントでも、OS、アーキテクチャ、用途を組み合わせたラベル指定が案内されています。(ラベルによるRunner選択)

ラベル名だけで実機の状態が検証されるわけではありません。GitHubは、設定時に与えられた既定ラベルが実際のOSやアーキテクチャと一致するかを検証しないため、Runner上でuname -m、sw_vers、xcodebuild -versionを実行し、ログへ出力してください。

3. Runnerをサービスとして登録する

Runnerの展開ディレクトリで公式のサービス登録手順を実行し、Macの起動時にRunnerが立ち上がるようにします。GitHubの管理手順では、Runnerアプリケーションをサービス化すると、ホスト起動時に自動開始できると説明されています。

登録後は、次の順で確認します。

1. Macを再起動する。
2. SSHで接続し、Runnerサービスの状態を確認する。
3. GitHubのRunner一覧でオンライン表示を確認する。
4. uname -m、sw_vers、xcodebuild -versionを出力する最小Jobを実行する。
5. SSH接続を閉じた状態でもJobが完了することを確認する。

オンラインにならない場合は、まずサービスのログ、外向き443番ポート、登録トークンの期限、Runnerディレクトリの権限を確認します。Jobが待機したままなら、ラベルの綴り、Runner Groupの許可対象、RunnerがIdle状態かどうかを確認します。

二系統ワークフローでXcodeの選択を固定する

本番用Jobを変更せず、検証用Jobを追加するのが基本です。xcode-selectをホスト全体へ常時適用するのではなく、各Jobの冒頭で使用するDeveloper Directoryを明示します。

Xcodeのパスは環境に合わせて置き換えます。重要なのは、Jobの途中で暗黙に現在の選択状態へ依存しないことです。

jobs:
  xcode27-validation:
    if: github.event_name == 'workflow_dispatch' || github.ref == 'refs/heads/xcode27-validation'
    runs-on: [self-hosted, macOS, ARM64, xcode-27, validation]
    steps:
      - uses: actions/checkout@v6

      - name: Print toolchain
        run: |
          sudo xcode-select -s "/Applications/Xcode-27-beta.app/Contents/Developer"
          uname -m
          sw_vers
          xcodebuild -version
          xcodebuild -showsdks

      - name: Build and test
        run: |
          xcodebuild \
            -workspace App.xcworkspace \
            -scheme App \
            -destination 'platform=iOS Simulator,name=iPhone 17' \
            clean test

actions/checkoutのバージョンはプロジェクトの採用状況に合わせて固定し、サンプルをそのまま本番へコピーしないでください。Xcode 27ではSDKやSwiftの挙動だけでなく、Simulatorの識別、依存関係の解決、署名処理のログも比較対象になります。

キャッシュキーへXcodeのバージョンを含めない設計は避けます。Xcode 26.6で生成した中間生成物をXcode 27が再利用すると、再現性のない失敗が発生し、切り分けに余計な時間がかかります。

初日に実プロジェクトで受け入れを記録する

最初の検証対象は、最重要の本番アプリではなく、依存関係、テスト、署名の構成が本番に近い非中核プロジェクトが適しています。単純なコンパイルだけでは、Xcode 27への移行可否を判断できません。

各段階で、次の情報をArtifactとして保存します。

• 実際のXcode、Swift、SDK、macOS、アーキテクチャ
• xcodebuildのコマンドと主要なBuild Settings
• 依存解決の結果とキャッシュキー
• Simulatorのデバイス名、OS、ランタイム
• Archiveの識別情報と署名検証結果
• 失敗したJobの完全なログと再現条件

AppleのXcode 27 Release Notesには、修正済みの問題と既知の問題が掲載されています。失敗したら、最初からプロジェクトコードの不具合と決めつけず、Release Notes、第三者ライブラリ、Runner環境、署名設定の四つへ分類します。

初週の切り戻し条件と権限分離を決める

Xcode 27のJobが一度失敗しただけで全量切り戻す必要はありませんが、同じ失敗が環境初期化後にも再現し、単体テスト、UIテスト、Archive、署名のいずれかに影響する場合は、Xcode 26.6を既定の本番経路へ戻します。

切り戻しは、Runnerラベルを削除するだけで終わらせません。Xcode 27側で生成したキャッシュをXcode 26.6側へ流さず、検証用Artifactを保管し、同じコミットをXcode 26.6で再実行して差分を比較します。

GitHubは、公開リポジトリでセルフホストRunnerを使うことをほぼ避けるべきだと説明しています。ForkからのPull RequestがRunner上でコードを実行し、秘密情報やホスト環境へ影響を与える可能性があるためです。(GitHubの安全利用リファレンス)

運用上は、次の境界を固定します。

• Xcode 27 Runner Groupは対象リポジトリだけに許可する
• 公開リポジトリのPull Requestを署名用Runnerへ送らない
• 秘密情報を使わないビルド、テスト、署名検証を別Jobに分ける
• 本番証明書を検証ノードへ常時保存しない
• 署名Jobは承認済みEnvironmentと限定ワークフローからのみ起動する
• Runnerの管理者権限とアプリ開発者の変更権限を分離する

GitHubのRunner Groupは、リポジトリだけでなく利用ワークフローを限定する用途にも使えます。Xcode 27の検証段階では、署名を含むJobを少数の承認済みワークフローへ閉じ込める設計が適しています。

切り替え前の可否判定チェックリスト

• [ ] Apple SiliconとmacOS Tahoe 26.4以降をRunner上で確認した
• [ ] Xcode 27の実パスとXcode 26.6の実パスをJobごとに固定した
• [ ] xcodebuild -version、Swift、SDK、CPUアーキテクチャをログへ出した
• [ ] Xcode 26.6とXcode 27でDerivedDataとキャッシュを分離した
• [ ] 検証RunnerのラベルとRunner Groupを確認した
• [ ] Mac再起動後もRunnerがオンラインになることを確認した
• [ ] SSH切断後も最小Jobが完了した
• [ ] 依存解決、コンパイル、単体テスト、UIテストを実行した
• [ ] Archiveと署名検証を実行し、生成物を保存した
• [ ] Xcode 27失敗時にXcode 26.6へ戻す手順を実行した
• [ ] 公開リポジトリや未信頼のPull Requestを署名用Runnerから除外した
• [ ] 初週のログと失敗分類を担当者が確認した

よくある判断をFAQで確認する

FAQの回答は、Xcode 27 beta 4、Xcode 26.6、GitHub Actionsの公式仕様に基づいています。正式版の公開日や将来の互換性は、AppleまたはGitHubが明示するまで移行計画の前提にしないでください。

Xcode 27 GitHub Actions セルフホストRunnerを今すぐ本番化すべきですか

本番の既定ツールチェーンを直ちにXcode 27へ変更する段階ではありません。Xcode 26.6を残し、Xcode 27を独立したApple Silicon Macで検証し、ビルド、テスト、Archive、署名が安定してから対象ブランチを段階的に広げます。

Runnerがオフラインになった場合はどこから確認しますか

Macのサービス状態、Runnerログ、外向き443番ポート、GitHub関連ドメイン、Runner Groupの割り当てを順番に確認します。GitHub上でオンラインでもJobを受け取らない場合は、ラベルの組み合わせとRunnerがIdle状態かどうかを確認してください。

本番移行を急がず、必要な期間だけMac環境を分ける

ローカルMacをCI用に常時稼働させる方法は、電源管理、ネットワーク到達性、OS更新、画面ロック、ストレージ消費、担当者不在時の復旧を開発チーム側で負担することになります。LinuxのクラウドサーバーだけではXcodeとApple SDKを扱えず、仮想化環境ではApple Silicon、Simulator、署名、macOSの更新条件が別の制約になります。

そのため、短期のXcode 27検証や移行期間だけ、root権限とSSH接続を確保できるApple Silicon Macを使う構成は、専用実機を購入するより運用上の切り分けがしやすい選択肢です。VuncloudのMacレンタル環境を検討する場合も、まずは非本番ブランチでRunner登録、サービス常駐、署名なしの検証Jobを通し、その後に必要な権限と秘密情報の扱いを確認してください。

ただし、長期にわたり高頻度の本番ビルドを継続し、物理デバイス接続や専用ネットワーク機器が必要なチームには、自社管理のMac実機のほうが適しています。逆に、Xcode 27の検証期間だけMacが必要、Apple Silicon環境をまだ保有していない、SSHで管理できる一時的なCIノードが必要という条件なら、利用前のサポート情報を確認し、Vuncloudのサービス概要と自社のRunner権限設計を照合するのが現実的です。