Xcode 27.2 RCをGitHub Actionsに接続するには？2026年リモートMacチュートリアル

Runnerは起動しているのに、Xcodeのジョブが待ち続けたり、RCのビルドが別の環境へ流れたりすることがあります。

最短の解決策は、互換性を確認したリモートMacを自ホストRunnerとして登録し、専用ラベルでジョブを振り分けることです。Xcode 27.2 RCの検証は正式リリース作業と分け、署名情報も共有しない構成にします。

この記事は、ローカルにMacがなく、iOSアプリのGitHub Actions構築環境を用意したい独立開発者向けです。
手作業のXcode構築をワークフローに移したい小規模チームにも役立ちます。
RCを試しながら正式署名情報を保護したいメンテナーは、権限の分離まで確認できます。

最終更新：2026年10月26日。 Xcodeの互換性はAppleのシステム要件、Runnerの手順はGitHub公式ドキュメントを基準にしています。RCの状態や設定画面が変わった場合は、登録前に各ページを再確認してください。

ローカルMacとリモートMac：準備条件の違い

Xcode 27.2 RCをGitHub Actionsから呼び出す場合、リモートデスクトップでMacに接続できることと、Runnerとしてジョブを受け取れることは別の条件です。さらに、ジョブが完了しても、ビルドやテストの成功、配布の完了まで保証されるわけではありません。

自ホストRunnerの選択は、ラベルで行えます。GitHubはself-hosted、OS、アーキテクチャなどのラベルを使って対象を絞る方法を案内しています。ラベルの意味とジョブへの指定方法は、Runner選択の公式説明で確認できます。

RCとmacOS：登録前の互換性確認

最初に、遠隔のMacに入っているmacOSがXcode 27.2 RCの要件を満たすかを調べます。Appleのシステム要件ページで該当バージョンを確認し、Xcodeのリリース記録でRCの状態とリリース情報を照合してください。要件を確認できないままRunner登録へ進むと、接続後にツールチェーンの不整合を調べることになります。

Mac上では、選択中のXcodeとコマンドラインツールの参照先を確認します。

xcodebuild -version
xcode-select -p

出力が意図したXcodeを示すか確認します。Xcodeの起動先が別バージョンを指していれば、インストールの有無だけでは判定できません。プロジェクトの依存関係、利用するSDK、実行する構築・テストコマンドも先に書き出し、RC専用の検証ジョブと正式リリースのジョブを分けます。

手元の端末とGitHub設定：Runnerの登録

Runnerは、リポジトリまたは組織の設定画面から対象を追加します。表示されるmacOS向けの手順に従ってRunnerアプリを取得し、設定コマンドを実行して登録します。登録画面の構成やコマンドは変更される可能性があるため、手順の細部はGitHubのRunner追加ガイドを基準にしてください。

登録時に使うトークンはセットアップのための認証情報です。サンプルや公開ログに貼り付けず、トークンの値、リポジトリ情報、ホスト名、アカウント名も公開ワークフローに書きません。秘密情報の扱いはGitHubのセキュリティガイドを確認してください。

登録後は、標準ラベルだけでなくRC検証専用のカスタムラベルを付けます。例えば、xcode-27-2-rcのようなラベルを追加すれば、他のmacOSジョブと区別しやすくなります。実際のラベル追加方法は自ホストRunnerのラベル設定手順に従います。ラベルは対象を選ぶ目印であり、Xcodeの互換性や署名の安全性を保証するものではありません。

ワークフローとRunner：ジョブの接続

ワークフローでは、標準ラベルと専用ラベルを組み合わせ、RC用Runnerだけを選びます。次の例は設定の形を示すものです。リポジトリ名やアクションの参照値は、実際の環境で承認済みの値に置き換えます。

name: iOS RC build

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: [self-hosted, macOS, ARM64, xcode-27-2-rc]
    steps:
      - uses: actions/checkout@<承認済みの固定SHA>
      - name: Check selected Xcode
        run: |
          xcodebuild -version
          xcode-select -p
      - name: Build for validation
        run: xcodebuild -scheme "<SCHEME>" -destination "<DESTINATION>" build

アクションを含むワークフローは、信頼できるコードだけが実行できるように設定します。特に、外部からの変更提案を扱うジョブに、正式署名用の秘密鍵や配布資格情報を渡してはいけません。ワークフローで自ホストRunnerを指定する書き方や制約は、GitHubの利用方法とセキュリティガイドで照合してください。

状態の確認では、次の境界を混同しないことが重要です。

• Runnerがオンラインでも、ジョブが割り当てられたとは限りません。
• ジョブが開始しても、Xcodeコマンドが実行されたとは限りません。
• xcodebuildが終了しても、テストが合格したとは限りません。
• ビルドが成功しても、署名やストアへの提出が完了したとは限りません。

ログには、選択されたRunner、xcodebuild -versionの結果、実行したコマンド、終了状態を残します。成功判定はワークフロー全体の終了状態と、期待する成果物の有無で行います。待機や失敗時はRunnerの監視・トラブルシューティング手順を使い、Runnerの状態とジョブログを別々に確認してください。

GitHub Actionsの疑問：RC検証で押さえる点

リモートMacでiOSアプリを構築する流れ

macOS要件を満たすMacを登録し、専用ラベルでジョブを指定します。ワークフローにコード取得、Xcodeの確認、構築またはテストのコマンドを記述します。ジョブの割り当て、コマンドの実行、成果物の生成は別々に確認してください。

macOS自ホストRunnerの登録場所

リポジトリまたは組織の設定からRunner追加画面を開き、表示されるmacOS向けの公式手順に沿って取得、設定、起動します。登録トークンは公開せず、Runner一覧でオンライン状態を確認します。登録後にジョブを受け取れることも、別途ワークフローで検証します。

Xcode 27.2 RCに必要なmacOSの確認方法

Appleのシステム要件ページでXcode 27.2 RCの項目を確認し、対象MacのmacOSと照合します。要件の記載やRCの状態は更新される場合があります。インストール済みのXcodeが正しいかだけでなく、xcode-select -pが意図した開発者ディレクトリを指すかも調べてください。

Runner上の構築成功を確認する方法

Runnerがオンラインという表示だけでは合格になりません。ジョブログで対象RunnerとXcodeのバージョンを確認し、構築・テストの終了状態と生成物を照合します。タスクがキューに残る場合はRunnerの選択条件を、コマンドで失敗した場合はログと環境設定を優先して調べます。

自動起動とRC分離：常時稼働前の確認

手動起動のままでは、担当者のログアウトやMacの再起動後にジョブを受けられないことがあります。常時運用する場合は、公式手順に従ってRunnerをサービスとして設定し、再起動後に再びジョブを受け取れるか確認します。サービス設定の条件はGitHubのRunnerサービス構成ガイドに記載されています。

RC検証用のRunnerには、正式リリース用の署名情報をあらかじめ置かない構成が安全です。コードの提供元、ワークフローを変更できる人、Runner上で読める秘密情報を確認し、信頼できないコードが動くジョブと署名ジョブを切り分けます。検証に署名が必要になった場合も、権限を必要な範囲に限定し、検証用と正式配布用の認証情報を分離してください。

手動構築と遠隔Mac：運用へ移る判断

WindowsやLinuxのRunnerだけではXcodeを実行できず、手元のMacをCIに使えば開発作業と自動構築が同じ端末を取り合います。共有型の実行環境では、必要なXcodeや環境を自分の管理下で揃えられるかも事前確認が必要です。これらの制約があり、RC検証のために一時的なmacOS環境や継続稼働する構築先が必要なら、リモートMacのレンタルが選択肢になります。

特定のXcodeを使う作業環境を検討する場合は、SFTPMACの環境案内とレンタル料金の案内を照らし合わせ、必要な期間や運用条件を確認してください。長期にわたる一定負荷の運用や、物理機器への直接接続が必要な場合は、レンタルより専用の実機を保有する方が合うこともあります。利用環境が決まった後も、正式署名を有効にする前に、Runnerの権限と秘密情報の分離を個別に確認してください。