2026 年の iOS 現場でよく聞くのが「GitHub Actions が遅い」です。実際は Actions そのものより、共有 macOS runner に重い工程を集中させている構成が詰まりの主因です。背景から押さえるなら iOS CI 遅延と GitHub Actions 待ちの入門記事 が先に効きます。
どこで詰まるのか：よくある4つのボトルネック
- 共有 macOS プール：リリース前の queue が build 時間を超える
- キャッシュの非持続性：DerivedData / SPM / Pods が毎回冷える
- 署名環境の再現性不足：キーチェーンとプロファイル管理が不安定
- 負荷の偏り：PR レベルの軽作業まで Mac で処理している
要点は明確です。iOS に必要な「重い Mac 処理」だけを専有化すると、待ち時間と失敗率が同時に下がります。
2026 年の設計思想：オーケストレーションと実行を分離する
| レイヤー | 実行場所 | 役割 |
|---|---|---|
| Fast Check | ubuntu-latest | lint・unit test・静的解析 |
| Release Build | self-hosted macOS | archive・codesign・notarization・配布 |
| Orchestration | GitHub Actions | トリガー・承認・通知・artifact 制御 |
IDE 側の進化（例：Xcode 27 Agent の流れ）は開発体験を押し上げますが、リリース基盤は別の最適化が必要です。
パターン1：混合パイプライン（Linux を先に走らせる）
最初に効くのはこの方式です。PR のたびに macOS を消費せず、main/tag のみ Mac に切り替えます。
pull_requestは Linux：lint + test + diff gatemain/tagは Mac：archive + signing + upload- 夜間 prewarm ジョブで依存解決を前倒し
Windows / Linux 主力チームの分業は リモート Mac build island FAQ が参考になります。
パターン2：Mac ビルド島 + self-hosted Runner
次の段階では、専有 Mac ノードで実行環境を固定します。運用面は self-hosted Runner キャッシュ FAQ の知見がそのまま活かせます。
- 署名用ノードに beta Xcode を混ぜない
- cache key に Xcode major を含める
- 並列ジョブは DerivedData パスを分離する
調達判断は 購入 vs レンタルのマトリクス、全体設計は 企業 Mac CI リソースプール が判断しやすい導線です。
パターン3：リリース週だけ burst 増設
負荷が波型なら常時増設は非効率です。Cloud Mac を短期で追加し、リリースジョブのみ burst ラベルへ流します。
- 平常時：1〜2 台で常設運用
- リリース週：1〜3 台を短期追加
runs-on: [self-hosted, macos, burst]を release に限定- 終了後は即減設し Opex を戻す
選び方：三択ではなく三点セットで考える
| 状況 | まず導入 |
|---|---|
| 待ち時間を早く減らしたい | 混合パイプライン |
| archive が多く環境が揺れる | Mac ビルド島 |
| リリース前だけ急増する | burst 増設 |
実務では「混合 + 常設島 + burst」が再現性の高い形です。OpenClaw まで含めるなら 統合運用ガイド が直結します。
最小 Runbook：今週中に実行するなら
- PR ジョブから macOS 必須でない処理を Linux へ移動
- self-hosted macOS Runner 1 台で archive を移管
- cache key に Xcode major + lockfile hash を導入
- 次回リリース週だけ burst ノードを追加
この段階で「待ち続ける CI」から「予測できる CI」へ変わります。
FAQ
GitHub Actions は捨てるべきですか？
多くのチームでは不要です。実行層を分離するほうが移行コストが低く、改善が速いです。
最初から購入するべきですか？
先にレンタルで実測し、常時稼働が見えてから購入を判断するのが安全です。
Xcode 27 Agent が出れば CI の Mac は不要ですか？
不要にはなりません。開発補助は進化しても、署名・配布の責務は依然として Mac ノード側です。
まとめ
2026 年の iOS CI は「どの CI を使うか」より「どこで何を走らせるか」が勝負です。GitHub Actions を活かしつつ macOS 実行層を分離すると、待ち時間と再試行コストは大きく下がります。