GitLab Hosted macOS Runner は Xcode 27 に対応していますか？2026年企業選定

2026年9月5日時点では、Xcode 27の本番移行をGitLab Hosted macOS Runnerだけに任せないでください。GitLab公式の公開イメージにはXcode 27がまだ含まれていないため、当面は安定したツールチェーンをHosted Runner、Xcode 27の検証・私有ネットワーク作業・本番署名を専用の自托管Macへ分けるのが安全です。

最終更新：2026年9月5日。 GitLab Hosted macOS Runner、Compute Minutes、Hosted Runnerのライフサイクル、Apple Xcode Release Notesを基に内容を確認しています。GitLabのイメージ追加やBeta状態の変更、AppleによるXcode 27 RCまたは正式版の公開時には、再確認が必要です。

SECTION 01 この記事を読むべき担当者

Xcode 27の適用計画を作成し、GitLab CI/CDのmacOSイメージがどこまで使えるか確認したい開発生産性責任者向けです。コード署名、社内依存サービス、ネットワーク分離を審査する企業IT担当者にも適しています。

Hosted Runnerの計算使用量と、自托管Macの設備・運用・セキュリティを含むTCOを比較したい技術責任者や購買担当者も、最後の分岐表から構成を絞り込めます。

SECTION 02 バージョン対応の現在地

GitLab公式ドキュメントでは、Hosted runners on macOSはBetaとして扱われ、公開されているmacOSイメージにはmacOS 15／Xcode 16とmacOS 26／Xcode 26が記載されています。Xcode 27はその一覧にありません。これは「GitLab Hosted macOS Runnerが利用できない」という意味ではなく、「Xcode 27を指定したビルド環境として公式に選べる状態ではない」という意味です。GitLabのHosted macOS Runner公式一覧と、AppleのXcode 27 Release Notesを分けて確認してください。

GitLab Hosted macOS RunnerがXcode 27に対応する時期は、公式のイメージ一覧に追加されるまで確定できません。コミュニティの投稿や報道を、公開予定日の根拠にしてはいけません。対応を待つ間は、Xcode 27を使うジョブだけを別のRunnerタグへ分け、既存のXcode 26ジョブを急いで変更しない構成にします。

SECTION 03 環境再現性と制御範囲

Hosted Runnerは、利用可能なイメージとプリインストール済みツールを基準に選びます。ただし、イメージを選択できることは、更新時期や全パッケージの変更内容を企業側が決められることを意味しません。Xcodeのマイナー更新、Simulator Runtime、Homebrew依存ツールの差分が、同じコミットの結果を変える可能性があります。

自托管MacはXcode 27、必要なSimulator Runtime、RubyやNode.jsなどの依存ツールを固定できます。一方、自由にインストールできる環境は、管理しなければ開発者ごとの差分と同じ問題を抱えます。自托管Macを選ぶなら、Runnerの登録設定だけで完了と考えず、環境台帳と変更承認を運用に組み込んでください。

次の検証を同一のコミットで実施します。

1. Xcode、SDK、Simulator Runtime、主要な依存ツールのバージョンを出力します。
2. その一覧をリポジトリまたは変更管理台帳へ保存します。
3. 同じPRをHosted Runnerと自托管Macで実行します。
4. コンパイル、単体テスト、UIテスト、アーカイブの差分を記録します。
5. クリーンビルドとキャッシュ利用時の結果を分けて比較します。
6. 同じコミットを再実行し、成果物のハッシュと署名結果を確認します。

GitLab RunnerのmacOS導入方法は、公式のmacOSインストール手順に沿ってください。ここで重要なのは登録作業ではなく、Runnerタグをxcode-27、signing-production、private-networkのように役割で分離し、ジョブが意図しないノードへ流れないようにすることです。

SECTION 04 署名境界とジョブ隔離

通常のコンパイルや公開情報だけを使うテストは、Hosted Runnerへ流しやすい処理です。しかし、Appleの証明書、Provisioning Profile、App Store Connectの認証情報を扱う本番署名は、Hosted Runnerの一時環境や権限モデルが自社の監査基準を満たすかを個別に確認しなければなりません。

「ビルドが成功する」ことと、「本番署名を許可できる」ことは別の判定です。証明書を環境変数へ投入するだけでは、ログ出力、ワークスペース、キャッシュ、失敗時の残留データまで説明できません。自托管の専用Macでも、Keychainのロック、証明書の配置、Profileの期限、作業ディレクトリの消去、Runner管理者権限の監査が必要です。

GitLabのHosted Runnerはジョブごとの隔離方式や利用条件を公式仕様で確認できます。Hosted Runnerの全体仕様を読み、次の順で署名可否を決めます。

• 署名情報を扱わない検証ジョブなら、Hosted Runnerを候補にします。
• 署名は必要だが社内規定で一時環境が許可されないなら、専用の自托管Macへ分けます。
• 本番アカウント、配布証明書、リリース用Profileを扱うなら、監査済みノードだけにRunnerタグを付けます。
• ジョブ終了後にKeychain、作業領域、生成物、キャッシュを消去できない場合は、本番署名へ使いません。

GitLabが証明書管理を代行するかどうかだけで判断せず、秘密情報の保管場所、アクセス主体、失敗時の回収手順をセキュリティチームの承認記録に残してください。

SECTION 05 私有ネットワークと接続範囲

コードを取得できることは、企業の依存サービスへ到達できることを意味しません。内部のSwift Package、私有CocoaPodsリポジトリ、アーティファクト保管庫、社内API、固定出口アドレスの許可リストがある場合、Hosted Runnerからの経路を個別に検証する必要があります。

特に、次の条件が一つでもある場合は、自托管Macを優先します。

• 内部制御されたパッケージリポジトリに接続する。
• 固定IP、プロキシ、VPN、専用DNSが必要です。
• データを特定地域または社内セグメントから出せません。
• 失敗ログにソースコードや内部URLを含めることが許可されません。
• セキュリティ審査で実行ノードの所在とアクセス経路が必要です。

判断材料は印象ではなく、ネットワーク流向図、接続先一覧、失敗ログ、出口IPの確認結果、セキュリティ担当者の承認記録です。社内依存のない公開アプリのテストだけをHosted Runnerへ流すなら、ネットワーク境界を狭く保てます。

SECTION 06 キューと処理能力

Runnerの選定では、単発のクリーンビルド時間やMacのハードウェア仕様だけでノード数を決めないでください。実際のPR、単体テスト、UIテスト、アーカイブ、再試行を含むジョブ構成で、待機時間・実行時間・キャッシュ命中率・失敗からの復旧時間を分けて測定します。

Hosted Runnerでは、待機時間と実行時間に加えて、GitLabの計算使用量ルールを確認します。請求対象の扱いはプランや実行条件によって変わり得るため、Compute Minutesの公式計算ルールと自社の請求画面を突き合わせてください。自托管Macでは、稼働中の時間だけでなく、保守、更新、監視、障害対応、予備ノードの費用を含めます。

容量は、次の変数で計算すると過不足を説明しやすくなります。

必要容量 ＝ 同時実行ジョブ数 × 1ジョブの占有時間 ÷ 許容稼働率

ここでいう占有時間には、キュー待ちを含めるか、実行だけにするかを先に決めます。ピーク時のPR集中、キャッシュ消失、ノード再起動、Xcode更新による再検証を別シナリオとして計算し、安定時の平均だけで購入台数やレンタル台数を決めないでください。

SECTION 07 TCOと選択条件

自托管Macのコストは、月額または購入価格だけでは比較できません。次の式で同じ期間の費用をそろえます。

総コスト ＝ 計算使用量またはレンタル費 ＋ CI管理工数 ＋ セキュリティ運用費 ＋ 保守・交換費 ＋ 失敗による遅延コスト

GitLab Hosted Runnerの計算使用量は公式ルールと企業請求で確認し、自托管Macは実際のレンタル契約または購入見積もりを入力します。未検証の単価や構成を一般的な相場として埋めると、企業の購買判断を誤らせるため、変数のまま比較するのが安全です。

実際の選択は、次の条件分岐にすると決裁資料へ落とし込みやすくなります。

• Xcode 27が必須で、公式Hostedイメージに未掲載なら、自托管Macで先行検証します。
• 私有ネットワークまたは本番署名が必須なら、監査済みの専用Macへ分離します。
• 安定版Xcodeで公開依存だけを検証するなら、Hosted Runnerを優先します。
• 負荷のピークだけが問題なら、Hosted Runnerを弾性容量として残します。
• 安定した高負荷、物理アクセス、特殊な周辺機器が必要なら、自社保有または専用レンタルを比較します。
• Xcodeの版、署名、ネットワーク、負荷の条件が混在するなら、単一環境ではなく混在Runnerプールにします。

企業向けのMac運用をレンタルで試す場合は、VPSNIXの料金情報で契約条件を確認し、実際のGitLabジョブを使った検証を先に行ってください。購入前に、必要なXcode、接続先、署名方式、復旧手順をVPSNIXのヘルプセンターで確認しておくと、見積もり後の要件変更を抑えられます。

SECTION 08 実行に移す検証手順

1. バージョン表を固定します。
   Xcode 27、macOS、SDK、Simulator Runtime、依存ツールを列挙し、Hostedで利用できる版と自托管で導入する版を分けます。

2. ジョブを感度で分類します。
   コンパイル、単体テスト、UIテスト、アーカイブ、署名、配布、内部依存アクセスを別ジョブとして整理します。

3. Runnerタグを設計します。
   hosted-stable、self-managed-xcode-27、private-network、production-signingのように、バージョンと信頼境界をタグへ反映します。

4. 同じコミットで比較します。
   PR、テスト、アーカイブを含む実際のパイプラインを両方で実行し、待機、実行、キャッシュ、失敗、復旧を記録します。

5. 署名を分離して審査します。
   署名なしの成果物を先に比較し、証明書とProfileを扱うジョブは専用ノードだけへ流します。

6. 私有接続を証跡化します。
   接続先、出口、プロキシ、DNS、失敗ログを記録し、セキュリティ担当者の承認を得ます。

7. 混在構成のTCOを更新します。
   Hostedの計算使用量、自托管Macの契約費、運用工数、予備容量、復旧時間を同じ期間で比較し、ノード追加の条件を決めます。

Xcode 27の正式移行前に専用GitLab Runnerを用意するべきかという点は、Xcode 27を実際のジョブで検証するなら、先に分離用Runnerを作る価値があります。ただし、単にRunnerを登録するだけでは不十分で、バージョン固定、署名境界、ネットワーク経路、復旧記録まで検証対象にしてください。

SECTION 09 現行構成からの移行判断

GitLab Hosted macOS Runnerだけに依存する構成は、Xcode 27の公開イメージがないこと、Betaサービスの状態に影響されること、社内依存や本番署名の境界を自社都合だけで固定しにくいことが弱点です。反対に、自托管Macだけへ寄せると、ホスト更新、Runner障害、キャッシュ管理、予備容量、セキュリティ監査を自社で引き受ける必要があります。

そのため、安定版ツールチェーンと変動する検証負荷はHosted Runner、Xcode 27の試行、私有ネットワーク、正式署名は専用の自托管Macという分担が、現時点の企業判断として無理がありません。自前購入では初期費用と減価、交換、保守の責任が残りますが、VPSNIXのMacレンタルなら、まず独立ノードでGitLab RunnerのPoCを行い、実測した待機・構築・復旧記録から拡張を判断できます。

まず本文の分岐表でXcode 27、署名、私有ネットワーク、負荷変動の該当項目を印付けしてください。Hostedイメージに版の不足がある場合だけ、VPSNIXの申込み案内を確認し、実際のパイプラインと復旧記録を基準にRunnerプールを増やすか判断するのが安全です。