GitHub Actionsの公式Runner資料では、xcode-27はPublic previewとして記載されています。また、macOS arm64 Runnerには固定UUID/UDIDが提供されません。
症状 → 最短の判断
Runnerラベルにxcode-27があっても、企業内網へ接続できるとは限りません。公開依存で完結するジョブは托管Runnerを試し、内網、固定IP、特定端末の条件があるジョブは、自社管理Macまたは混合構成で検証してください。
この記事が役立つ方
GitHub Actionsと企業ネットワークの要件を確認するIT担当者。
PR、端末テスト、リリース処理の実行先を分けたいプラットフォームエンジニア。
Mac基盤の増設や調達を検討する技術責任者。
最終更新:2026年9月28日。xcode-27の状態、macOS Runnerのネットワーク制限、UUID/UDIDの記載をGitHub公式資料で確認しています。端末登録と署名要件はApple Developer資料を参照しています。
SECTION 01ジョブの性質でRunnerを振り分ける
GitHub Actions xcode-27 Runnerの企業向け選定では、Runnerラベルよりも、ジョブが何に接続し、どの端末や資格情報を必要とするかを先に確認します。托管Runnerは企業の一般的な内網ノードと同義ではありません。接続条件が未確認のまま本番ジョブを移すのではなく、シナリオ単位で実行先を決めてください。
| ジョブのシナリオ | ネットワーク・端末の条件 | 署名の条件 | まず選ぶ実行先 |
|---|---|---|---|
| 公開依存を使うPR検証 | 公開リポジトリや一般の外部依存へ接続できれば成立 | 通常は本番配布用資格情報を渡さない | xcode-27の托管Runnerを評価 |
| 私有リポジトリのビルド | リポジトリ認証に加え、内部パッケージ保管庫などへの接続確認が必要 | テスト用資格情報に限定 | 接続確認後に托管Runner、未達なら自社管理Mac |
| 社内APIや固定IP許可が必要な処理 | 内網経路または許可済みの送信元アドレスが必要 | ジョブごとに最小権限で設定 | 条件を満たすと確認できた自社管理Mac |
| シミュレーター中心のテスト | 利用するツールと依存先がRunnerから到達可能 | 配布用署名が不要な構成も可能 | 小規模に托管Runnerで検証 |
| 登録端末を使うテスト・配布 | 端末登録や特定UDIDへの依存を確認 | 開発用プロビジョニングなどが必要 | 端末条件を実証できるMac |
| 本番署名・正式リリース | 内部の成果物保管先や承認系への接続条件を確認 | 本番資格情報の露出を厳しく制限 | 独立した署名経路を設計し、適合するMacへ分離 |
GitHubはxcode-27のラベルとプレビュー状態をRunner資料に掲載していますが、ラベルの存在は特定企業のファイアウォールや内部サービスへの接続を保証しません。Runnerの種類ごとの対応範囲は、公式のRunnerリファレンスで確認し、他OSや別種類のRunnerにある機能をmacOSへ当てはめないでください。
SECTION 02公開依存のPR検証は托管Runnerから評価する
ソースと依存パッケージがRunnerから取得でき、企業専用のネットワーク入口や端末UDIDを必要としないPR検証なら、托管macOS Runnerを候補にできます。ただし、「ワークフローが起動した」だけでは移行完了ではありません。実際のビルド、テスト、成果物保存まで成功することを確認してください。
最初に、ワークフローのruns-onが利用対象のRunnerラベルと一致するかを見ます。次に、依存の取得元、成果物の保存先、プロジェクトで使うコミュニティ製Actionsがその環境で動くかを確認します。GitHub Actions全体の実行環境とネットワーク上の前提は、Runnerの概念とネットワーク説明も照合してください。
注意:Public preview中の機能は、社内標準の恒久的な前提にせず、対象アカウントとRunnerで現在利用できるかを公式資料で再確認してください。プレビューという状態自体が変われば、採用判断も更新が必要です。
シナリオ例として、公開依存を使う通常のPRテストは托管Runnerで実行し、結果を既存パイプラインと比較できます。コミット、テスト結果、成果物の取得先を記録し、失敗時に従来の実行先へ戻せる状態を作ってから対象を広げます。
SECTION 03私有リポジトリの権限と内網接続を別々に検証する
GitHub Actions macOS Runnerが私有リポジトリをチェックアウトできても、社内のパッケージ保管庫、成果物サーバー、プライベートAPIへ接続できるとは限りません。SCM(ソースコード管理)の認証と、企業ネットワーク上の任意のサービスへの到達性は別の確認項目です。
まずワークフローがリポジトリを取得する際のトークンや権限範囲を確認します。続いて、内部依存のホスト名解決、接続先ポートへの到達、認証後の読み取りを実際のジョブから確認してください。GitHubの自社管理Runnerに関する説明では、組織側の環境でRunnerを運用する場合の前提を確認できます。内網依存が届かない場合は、その依存を公開可能な経路に変更できるか検討するか、必要なネットワーク経路を持つ自社管理Macへジョブを振り分けます。
「企業iOS CIで自社管理Macが必要か」は、全体を一括で決める問題ではありません。内網アクセスや固定送信元が必須のジョブが托管Runnerで要件を満たさないなら、そのジョブだけを分離するのが現実的です。逆に、ネットワーク条件を満たすと実証できた処理は、托管Runnerを含めて運用負荷を比較できます。
SECTION 04固定IPや私有ネットワークが必須なら先に実証する
固定IPの許可リスト、プライベートネットワーク接続、一般的な外向き通信は、別の要件です。外部へ通信できることを理由に、企業内のサービスにも接続できると判断してはいけません。GitHubのlarger runnerに関する仕様ではネットワーク機能の制限を確認できますが、記載された条件をmacOS Runnerに適用できるか、対象のRunner種別ごとに照合してください。
運用チームには、少なくとも次の証拠を残してもらいます。
- ファイアウォールログに記録された送信元と宛先。
- 対象サービスへの接続結果と、認証後に必要な操作が成功した記録。
- 接続失敗時にどのRunnerへ再実行・振り分けされたか。
- Runnerの種類、ラベル、実行時点が特定できるワークフロー記録。
送信元IPを許可リストへ登録できることと、内網へ経路があることは同じではありません。調達前に、ネットワーク担当者とCI担当者が同じ対象サービスを使って受け入れ試験をしてください。
SECTION 05実機テストと開発署名は別ジョブで判定する
シミュレーターでの検証と、登録済みの実機を使うテストは要件が異なります。Appleは開発用プロビジョニングで対象端末の登録を扱っており、単一端末の登録手順や登録端末へのアプリ配布に関する説明に沿って、プロジェクトの端末条件を確認できます。
とくにmacOS arm64 Runnerで固定UUID/UDIDが提供されない点は、端末登録を前提にした作業で見落とせません。GitHubのRunner資料の記載を確認し、托管環境でビルドできたことを、登録端末でのテストや配布も可能である証拠として扱わないでください。開発用プロビジョニングプロファイルの条件は、Appleの作成手順と照合します。
開発署名が必要なジョブでは、証明書、プロビジョニングプロファイル、キーチェーンをどの実行環境が扱うかを明示します。本番署名の資格情報はPRの実行経路から切り離し、必要な承認と最小限の権限を適用してください。GitHubのActionsを安全に利用するための指針を踏まえ、信頼できない変更を処理するワークフローに本番用資格情報を渡さない設計にします。
SECTION 06FAQ:内網、私有依存、端末条件の確認
xcode-27 Runnerから社内APIやパッケージ保管庫へ接続できますか?
Runnerラベルがあることだけでは接続できると判断できません。対象のmacOS Runnerから、社内APIやパッケージ保管庫への接続を実ジョブで試してください。失敗する場合は、必要な経路を持つ自社管理Macへ処理を分けるか、依存の提供方法を再検討します。
GitHubの托管macOS Runnerで私有リポジトリを使えますか?
適切な認証と権限があれば、私有リポジトリを取得できる場合があります。ただし、その認証権限は社内ネットワーク上の別サービスへ接続する権限とは異なります。リポジトリの取得と内部依存への接続を別々に試験してください。
どのジョブを自社管理Mac Runnerに残しますか?
固定送信元IP、企業内網、登録済み実機などの条件があり、托管Runnerで満たせる証拠がないジョブを候補にします。公開依存のPR検証まで一緒に移す必要はありません。条件の強いテストやリリース処理を分け、障害時の戻し先も決めてください。
xcode-27 Runnerは実機テストや開発署名にも使えますか?
ビルドが成功しても、必要な端末登録や署名条件が満たされるとは限りません。macOS arm64 RunnerのUUID/UDIDの扱いと、Apple Developer側のプロビジョニング条件を確認し、実機が必要なジョブを個別に試験してください。
SECTION 07本番リリースは資格情報と戻し先を分離する
不特定の変更を検証するPR、本番資格情報を使わない通常ビルド、署名済み成果物を公開するリリースでは、必要な信頼水準が異なります。ジョブのトリガーだけでなく、利用できるシークレット、実行先、成果物の保管先を一組として設計してください。托管Runnerを採用するために、本番署名の秘密情報を広い範囲のワークフローへ渡すのは避けます。
切り替え前には、次の項目をチームで確認してください。
- [ ] 対象のRunnerラベルと実際の実行環境を公式資料で照合した。
- [ ] 私有リポジトリの取得と、社内依存サービスへの接続を別々に確認した。
- [ ] 固定送信元IP、内網経路、外向き通信を区別して検証した。
- [ ] シミュレーターと実機テストを分け、UDIDや端末登録の要件を確認した。
- [ ] 開発署名と本番署名の資格情報、利用者、実行経路を分離した。
- [ ] 失敗時の再実行先と、ファイアウォール・サービス・ワークフローの監査記録を決めた。
全ジョブの移行は必須ではありません。通常のPR検証は托管Runner、内網依存や登録端末に結びつく処理は自社管理Mac、本番署名はさらに制限した経路、という混合構成も選択肢です。GitHub Actions xcode-27 Runnerの状態やネットワーク条件が変わった場合に備え、確認結果には対象Runnerと検証日を残してください。
托管Runnerだけで構成すると、社内ネットワークや端末登録の条件を満たせない可能性が残ります。一方で、Macをすべて自社購入して固定運用すると、機器の調達、保守、空き容量の確保を継続して担う必要があります。私有依存や端末関連の処理だけをMacで運用したい場合は、要件を整理したうえでMACNOXの料金情報とリモートMacの利用案内を確認してください。契約前に、必要な内網経路、端末利用条件、署名資格情報の扱いが実際の提供条件に合うかをMACNOXへ確認し、適合が実証できたジョブから割り当てるのが安全です。
SECTION 08よくある質問 FAQ
xcode-27 Runnerから社内のAPIやパッケージ保管庫へ接続できますか?
Runnerのラベルやリポジトリを取得できる権限だけでは、社内APIやパッケージ保管庫への接続は保証されません。対象のmacOS Runnerで実際の接続経路を試し、ファイアウォール記録とサービス側のアクセス記録を残してください。届かない依存があるジョブは、自社管理Macへ振り分けるか、依存の提供方法を見直します。
GitHubの托管macOS Runnerで私有リポジトリを使えますか?
ワークフローに必要な認証と権限があれば、私有リポジトリを取得できる場合があります。ただし、そのことは社内ネットワーク上の別サービスにも接続できるという意味ではありません。SCM認証の確認と、内部の依存サーバーやAPIへの疎通確認を分けて実施してください。
どのようなiOS CIジョブを自社管理Macに残すべきですか?
社内ネットワークへの到達、許可済みの固定送信元IP、特定端末の登録など、托管Runnerで満たせると確認できていない条件に依存するジョブは、自社管理Macを候補にします。すべてのジョブを移す必要はありません。公開依存のPR検証と、ネットワークや署名の要件が強いリリース処理を分けて判断します。
xcode-27 Runnerで実機テストや開発署名まで完了できますか?
コンパイルできることだけでは、特定端末を使うテストや登録済み端末向けの配布まで実行できるとは判断できません。macOS arm64 RunnerのUUID/UDIDに関する制限と、Apple Developer側の端末登録・プロビジョニング条件を照合し、端末を必要とするジョブを個別に検証してください。