GitHub Universe 2026 macOS Runnerは自前かレンタルか

2026年7月29日現在、GitHub Universe 2026 macOS Runnerの選択は、安定した高稼働率なら自前、波が大きく固定ネットワークや一時的な並列数が必要ならレンタル、標準的な小規模ビルドならGitHubホステッドRunnerが現実的です。GitHub Universe 2026は2026年10月28日から29日にサンフランシスコで開催予定ですが、新しいRunner機能や製品発表の詳細はまだ確定していません。(githubuniverse.com)

この記事は、ビルドキューが頻繁に詰まるiOS・macOSチーム、署名環境や社内ネットワークを分離したいDevOpsチーム、GitHub Universe後にActionsの新機能を検証したいプラットフォーム担当者を対象にしています。大会の発表内容を待つだけでなく、現在の流水線ログから先に判断材料を作るための内容です。

先に見るべき指標は「分単価」ではなく待ち時間です

典型的には、低頻度のコミット、継続的インテグレーション、リリース前の集中実行で必要なRunner数が変わります。朝夕に少数のビルドだけが動くチームは、常時稼働する自前Macを持つとアイドル時間が増えます。一方、複数ブランチのテスト、UIテスト、アーカイブ作成が同時に走るチームでは、1台のRunnerに処理を集約すると、実行時間より待機時間が問題になります。

GitHub Actionsでは、同じワークフローやリポジトリの実行を並列に処理できますが、concurrencyを設定すると重複実行を抑制できます。古いコミットのテストをキャンセルする設計は、キューを減らす一方、順番にすべて検証したいリリース処理には適しません。(docs.github.com)

まず過去4週間から8週間のログで、次の値を分けて集計します。

• ジョブがキューに入ってから開始するまでの時間
• Runnerが実際に処理していた時間
• Xcodeビルド、テスト、署名、成果物のアップロードに要した時間
• 同じ時間帯に待機していたジョブ数
• 失敗後の再実行回数と復旧までの時間

理論上のCPU性能ではなく、待ち時間が許容値を超えた回数を見ることが重要です。たとえば、ビルド自体は短くても、リリース前だけキューが長くなるなら、常設設備を増やすより短期間だけRunnerを追加する方が合理的な場合があります。

三つの方式を同じ費用と制約で比較する

自前Runnerは設備を所有できる反面、使わない時間にもコストが発生します。電力、設置場所、監視、予備機、故障時の交換、macOSやXcodeの更新確認を含めると、単純な機器代だけでは比較できません。

GitHubホステッドRunnerは管理負担を抑えやすい方式です。ただし、macOS大型Runnerではarm64環境に静的UDIDがなく、Intel環境には静的UDIDが案内されています。さらに、macOS大型Runnerでは一般的な固定IPや一部のネットワーク機能に制約があるため、署名や社内接続の条件を先に確認する必要があります。(docs.github.com)

Macレンタルは、設備を持たずに専用環境を確保できる選択肢です。長期の常時稼働では自前の方が合うこともありますが、リリース月だけ並列数を増やす、特定のXcode環境を一時的に検証する、社内設備とは分離したRunnerを用意するといった用途では、待機設備を抱えない点が有利です。必要条件は、Macレンタルの利用方法で接続方式や利用形態を確認してから、チームの権限設計に落とし込みます。

Xcodeと署名の互換性が方式を決めます

iOS CIでは、Xcodeのバージョンだけでなく、macOSの対応範囲、IntelまたはApple siliconのアーキテクチャ、使用するSDK、証明書、プロビジョニングプロファイル、キーチェーンの扱いを一つの環境として管理します。標準イメージでビルドできるアプリでも、社内SDKや独自の署名手順が加わると、Runnerを自由に選べなくなることがあります。

Appleは、アプリの配布方法に応じてApple DistributionやDeveloper ID Applicationなどの署名IDを使い分けるよう案内しています。macOSアプリでは、ネストされたフレームワークや拡張機能の署名順序も問題になるため、単に証明書をRunnerへコピーするだけでは再現性を確保できません。(developer.apple.com)

固定UDIDが必要な場合は、次の順で確認します。

1. 実機テストや開発用プロビジョニングで本当に固定UDIDが必要かを分けます。
2. GitHubホステッドRunnerのアーキテクチャとUDID条件を確認します。
3. Apple Developer側に登録できる識別子か、チームの権限で確認します。
4. 証明書とプロファイルをRunnerへ保存する方法を決めます。
5. Pull Request用のビルドと、署名を伴うリリース処理を別Runner Groupへ分離します。

この要件を満たせない場合、標準Runnerを無理に使うより、固定環境のMacを自前またはレンタルで確保した方がトラブルの切り分けは容易です。

ネットワークと権限は性能より先に設計します

self-hosted runnerは、GitHub Actionsからジョブを受け取るためにホスト上でRunnerアプリケーションが動作している必要があります。GitHubの仕様では、GitHubとの通信に外向きHTTPSの443番ポートが必要で、通信帯域の最低要件として送受信それぞれ70kbpsが示されています。これは実際のXcode成果物の転送に十分な速度を意味するものではないため、依存パッケージやアーカイブの転送量は別に測定します。(docs.github.com)

社内リポジトリ、パッケージレジストリ、秘密管理サービスへ接続する場合は、Runnerの配置場所と出口IPを確認します。GitHubのmacOS大型Runnerは、標準的な固定IPが必要な構成にそのまま適用できない場合があります。固定出口、VPN、許可リスト、プロキシのいずれが必要かを、実際の接続先ごとに一覧化する必要があります。

Pull Requestのコードを自前Runnerで実行する場合は、特に注意が必要です。GitHubは、公開リポジトリのフォークから危険なコードが実行される可能性があるため、self-hosted runnerはプライベートリポジトリでの利用を推奨しています。署名証明書、キーチェーン、社内トークンを保管するRunnerに、不審なコードが到達しないよう、Runner Groupとワークフロー権限を分けます。(docs.github.com)

第1段階：ログから必要な並列数を決めます

過去の流水線ログから、時間帯ごとの待機ジョブ数と実行時間を抽出します。リリース時だけ待機が増えるなら、常設Runnerを増やす前に、その期間だけレンタル環境を追加する案を比較します。

第2段階：Xcodeとアーキテクチャを固定します

必要なmacOS、Xcode、SDK、RubyやNode.jsなどの補助ツールを一覧にします。Intel専用の依存関係やApple siliconで動作しないActionが残っている場合、arm64へ移行する前に、失敗する工程を特定します。

第3段階：署名処理を通常ビルドから分離します

Pull Requestでは署名なしのビルドやテストを実行し、証明書を使うアーカイブ作成と配布処理は保護されたRunner Groupへ送ります。証明書を環境変数へ直接展開するのではなく、保存場所、利用時間、削除手順を決めておきます。

第4段階：Runner Groupとconcurrencyを設定します

ビルド、UIテスト、リリースを別グループに分けます。リリース処理は同時に一つだけ実行し、通常のテストは必要な数だけ並列化するなど、処理の性質に応じて同時実行数を設定します。GitHubの仕様では、条件に合うオンラインかつアイドル状態のRunnerが見つからない場合、ジョブはキューに残ります。60秒以内にジョブを受け取れないRunnerは再キューの対象となり、24時間を超えて待機したジョブは失敗します。(docs.github.com)

第5段階：復旧手順を実際に試します

Runnerサービス停止、ディスク容量不足、証明書期限切れ、Xcode更新後のビルド失敗を想定し、再登録から復旧までを測定します。自前Runnerの費用優位性は、復旧作業を担当する人が確保されて初めて成立します。担当者が不在の休日に復旧できないなら、設備を所有していても可用性の面では不利です。

条件分岐で選ぶmacOS Runner

• ビルドとテストが平日も継続し、稼働率が安定して高い場合は、自前のself-hosted runnerを第一候補にします。
• Xcodeや署名環境を固定し、社内サービスへ接続する必要がある場合は、自前または専用Macレンタルへ進みます。
• リリース前や大型アップデート時だけキューが増える場合は、常設設備を増やさず、短期レンタルで並列数を補います。
• 標準的なXcodeビルドで、固定UDIDや社内ネットワークが不要な場合は、GitHubホステッドRunnerを継続します。
• 公開リポジトリのPull Requestを実行する場合は、署名情報を持つ自前Runnerと同じ環境へ流さない構成にします。
• 3か月以上のログで負荷の波が読めない場合は、自前へ全面移行せず、ホステッドRunnerとレンタルMacを組み合わせて判断材料を集めます。

成長中のチームでは、すべてを一方式へ統一するより、通常の検証はGitHubホステッドRunner、署名と社内接続は保護したself-hosted runner、リリース波形の吸収はMacレンタルという混合Runnerプールが現実的です。Runner Group単位で権限を分ければ、性能と安全性のトレードオフも整理しやすくなります。

GitHub Universe 2026後に再確認する項目

GitHub Universe 2026の公式ページでは、AIエージェント、自動化、開発ツールを含む方向性が示されていますが、2026年7月29日時点でmacOS Runnerに関する新しい製品仕様や提供条件は確定していません。大会後は、次の項目だけを公式ドキュメントで再確認します。(githubuniverse.com)

• macOSホステッドRunnerのアーキテクチャとXcodeイメージ
• 静的UDID、固定IP、プライベートネットワークの対応範囲
• Runner Groupの権限と同時実行数の制御
• self-hosted runnerの自動拡張やRunner Scale Setの対応状況
• Actionsの料金体系や利用上限に関する変更

現時点では大会の発表を理由に設備を先に購入するより、キュー時間、署名失敗、復旧時間を記録し、発表後に差分を確認する方が安全です。

FAQ

GitHub ActionsのmacOS Runnerを自前で用意する価値はありますか？

固定されたXcode環境を長期間使い、毎日ほぼ一定の負荷で実行するチームなら、自前Runnerの価値があります。ただし、稼働していない時間の設備費、OS更新、ディスク掃除、障害対応まで含めて判断する必要があります。単発のビルド料金やActionsの利用分数だけで比較すると、実際の費用を見誤ります。

iOS CIはGitHubホステッドRunnerとクラウド上のMacのどちらが向いていますか？

標準的なXcodeビルドで、固定IPや特定のUDIDが不要ならGitHubホステッドRunnerが扱いやすいです。一方、社内ネットワークへの接続、固定された署名環境、長期的なツールチェーン固定、急な並列数の増加が必要なら、クラウド上の専用MacまたはMacレンタルが候補になります。

macOSのself-hosted runnerで同時実行数を制御する方法は何ですか？

まずRunnerを用途別のRunner Groupに分け、ワークフローのconcurrencyで同一ブランチやリリース処理の重複を制御します。そのうえで、オンラインかつアイドル状態のRunner数を実測し、ビルド、テスト、署名を同じホストへ集中させない構成にします。待機時間と失敗率を週単位で見直す運用が必要です。

固定UDIDが必要なiOS CIでは、どのRunnerを選ぶべきですか？

固定UDIDが必須なら、利用するRunnerのUDIDをApple Developer側へ登録できるかを最初に確認します。GitHubのmacOS大型Runnerでは、Intel環境には静的UDIDが案内されていますが、arm64環境には静的UDIDがありません。UDID要件がある場合は、独立したMacを自前またはレンタルで確保する方が検証しやすいケースがあります。

自前Macは固定環境を作りやすい一方、設備の空き時間、保守担当者の確保、故障時の交換待ち、ネットワーク変更への対応が継続的に発生します。GitHubホステッドRunnerは標準構成なら管理が軽いものの、固定UDID、特定の出口IP、社内ネットワーク、独自Xcode環境では制約が残ります。リリースの波だけを吸収したい場合は、保有設備を増やすよりZilmacでMacをレンタルし、必要な期間だけ独立したRunnerを追加する方が、運用上の負担を抑えやすいです。

まずは本文の条件分岐をチームのログに当てはめ、通常ビルド、署名処理、リリース処理の三つに分けてください。接続方式や利用形態を確認する場合は、ZilmacのクラウドMacレンタル案内とMac VPSの料金案内を照合し、固定環境が必要か、短期の並列増強で足りるかを切り分けるのが安全です。

• macOS Runnerの自前運用とレンタル環境を比較する
• クラウドMacで署名・実機検証・配布を進める手順