GitHub Actions Xcode 27 Runner へどう移行する？2026年の受け入れチェックリスト

症状：Xcode 27 Runner に切り替えたのに、ビルドや署名の結果が旧環境と一致しない。
最短の対処：独立ブランチでツールチェーン、署名、配布物、切り戻しを確認し、すべて合格してから正式タスクを移行します。

GitHub Actions の macOS ビルドを Xcode 27 Runner に移す独立開発者や小規模チーム向けです。
複数アプリやリリースブランチを運用している場合も、切替範囲を分けて検証できます。
ローカルにMacがなく、CIでiOSアプリのビルドと配布を行う場合は、再現性の確認に使ってください。

最終更新：2026年10月19日。GitHubの2026年10月15日付のXcode 27 Runner正式提供告知と、Runnerイメージの公式説明、AppleのXcodeシステム要件とバージョン情報を基に確認しています。ラベルやイメージ内容が更新された場合は、正式な切替前に各資料を再確認してください。

移行前に、プロジェクトとRunnerの前提を照合する

Xcode 27 Runner のイメージが正式に利用可能になっていても、既存のワークフローをそのまま移せるとは限りません。GitHubはイメージのラベルや内容を管理しており、プロジェクト側はXcode、SDK、アーキテクチャ、外部ツールの状態に依存します。まず旧Runnerで成功している条件を記録し、新環境との違いを一覧にします。

調査では、設定ファイルのruns-onだけでなく、Xcode選択用の処理、依存関係のキャッシュ、独自スクリプトも確認します。旧環境に含まれていたツールを暗黙に利用している場合、新Runnerでそのツールが使えない、または配置が異なることがあります。問題が起きたときに戻すRunnerの設定も、移行作業の前に保存してください。

独立ブランチでRunnerだけを切り替える

最初の変更は、Runner選択に絞ります。ビルド方式や署名処理、公開手順まで同時に作り替えると、失敗したときに原因を切り分けにくくなります。GitHub Actionsのruns-on設定方法を確認し、Xcode 27用の正確なラベルは、作業時点の公式イメージ説明から転記します。

ラベルをリポジトリ変数で管理する構成なら、試行用の値と旧環境の値を区別し、切り戻し先を明示できます。ワークフローの書き方は、たとえば次のような形です。

jobs:
  build:
    runs-on: ${{ vars.MACOS_XCODE_RUNNER }}
    steps:
      - uses: actions/checkout@v4
      - name: Show toolchain
        run: |
          xcodebuild -version
          xcodebuild -showsdks
          xcode-select -p

この例はRunnerラベルを特定するものではありません。変数を利用する場合は、リポジトリ側に適切な値を設定し、現在のGitHub公式資料でラベルとアーキテクチャを照合してください。変数を使わない運用なら、試行ブランチのワークフローだけを編集し、旧設定を別途保存しておきます。

注意：Runnerのラベルだけを先に本番ブランチへ反映しないでください。ビルドが通っても、署名やアップロードの経路が同じように動作する保証にはなりません。

初回実行でツールチェーンと依存関係を確認する

初回は、正式な公開を伴わない試行用ジョブで実行し、ログから実際の環境を確定します。Xcodeの表示バージョン、選択中のパス、利用可能なSDKを記録し、プロジェクトが求める条件と照合してください。Appleが公開するバージョン別のシステム要件は、要求されるmacOSやSDKを確認する基準になります。

失敗時は「Xcode 27が原因」と一括りにせず、ツールチェーン、依存関係、プロジェクト自身のエラーを分けて記録します。旧Runnerと同じコミットを使った比較ができれば、変更された条件を特定しやすくなります。ログを保存する際は、認証情報や署名用ファイルの内容が出力されていないことも確認してください。

正式切替の前に署名、Archive、IPAを検証する

コンパイルが成功した段階では、移行完了とは判定できません。署名用証明書とProvisioning Profileを読み取れること、Archiveを意図した設定で作成できること、Export後のIPAが予定する配布先に適合することを別々に検証します。

署名用のSecretsを追加・更新するときは、ログ出力やデバッグ用コマンドが秘密値を表示しないようにします。Appleの案内に沿ってアーカイブと配布形式を確認し、IPAの生成とApp Store Connectへのアップロードを別の合否項目にしてください。アップロードが終わったように見えることと、App Store Connect上でビルドの処理が確認できることは、同じ状態ではありません。

条件を満たしたジョブから正式環境へ切り替える

次の分岐で、正式Runnerへ進むか旧Runnerへ戻すかを決めます。条件に達しないまま公開ジョブを移すのではなく、未達項目とログを残して原因を特定してください。

• ビルド、テスト、署名、Archive、IPAの受け渡し、必要なアップロード確認がすべて通る場合：対象のワークフローから段階的に正式Runnerへ切り替えます。
• ツールチェーンが想定と違う場合：ラベルとXcode選択状態を再確認し、Appleの要件とRunnerイメージを照合します。
• 署名や配布物の結果を再現できない場合：正式公開を保留し、保存した旧Runner設定へ戻します。
• 移行後に本番相当のジョブで問題が出た場合：切り替えた値を旧環境へ戻し、失敗ログと環境情報を残して再調査します。

複数のアプリやリリースブランチを保守しているなら、一度に全ワークフローを変更せず、影響範囲を分けて同じ検証を行います。すべてのブランチで同一の依存関係や署名設定が使われていると判断できるまでは、個別の合格記録を残すのが安全です。合格条件を満たせない状態で公開期限が迫る場合は、新Runnerへの移行を延期し、検証済みの旧環境でリリースを続けます。

移行後は、採用したRunnerラベル、確認したXcodeとSDK、変更したワークフロー、検証結果、切り戻し先を記録します。GitHubがイメージのラベルや内容を変更した場合、またはAppleがXcodeの安定版や要件を更新した場合には、同じ記録を基準に再確認してください。

よくある質問

GitHub ActionsのmacOS Runnerは、Xcode 27用ならすぐ置き換えられますか？

ラベルの変更だけで置き換え完了とは判定しません。実際のXcodeとSDK、アーキテクチャ、スクリプトが依存するツールを調べたうえで、同じコミットを使った試行ジョブを実行します。新環境で署名と配布物まで再現でき、旧Runnerへ戻す設定も残っている場合に、正式タスクの切替を進めます。

Xcode 27 RunnerでIPAと署名をどう確認しますか？

試行用ジョブでSecretsから証明書とProvisioning Profileを読み込み、Archive、Export、IPAの保存まで順に確認します。生成物が想定する配布先に合うことも確認し、App Store Connectへのアップロードを行う場合は、アップロード処理とビルドの処理状況を別項目として判定します。秘密値をログに表示しない設定も確認してください。

新Runnerでビルドに失敗したら、旧環境へ戻すにはどうしますか？

移行前に保存した旧Runnerのラベルとワークフロー設定へ戻し、同じコミットで既知の結果を再現できるか確認します。Runner選択を変数で管理している場合は、試行用の値から旧環境の値へ戻します。失敗ログとXcode、SDK、依存関係の状態を記録し、原因を整理してから再移行します。

GitHub ActionsだけでiOSの自動ビルドを続けるべきですか？

ビルド頻度が低く、必要なツールと署名の扱いがホステッドRunnerで問題なく再現できるなら、既存の方式を継続する選択肢があります。一方、環境を保ったまま継続作業をしたい、Runner上の状態を細かく管理したい場合は、別のMac環境も比較対象になります。必要な稼働形態と運用負担を先に整理してください。

今回のように試行ジョブを短期間だけ動かすなら、GitHub ActionsのRunnerを使い続けるのが自然です。ただし、実行環境のイメージ変更に追随する必要があること、ジョブの外に環境状態を保ちにくいこと、ログや成果物を別途管理する必要があることは、運用上の負担になります。継続して使うmacOSビルド環境が必要なら、東京のMac環境や利用プランも確認し、macworkerのリモートMacと現在のRunner運用を比べてください。macworkerではroot権限で使えるMacを継続利用できますが、短期の検証だけなら現行Runnerのままでも十分です。

よくある質問