GitHub ActionsのmacOS CIは遅いのが普通？キュー待ちはどれくらい深刻？

push後にWorkflowが30分黄色のまま？それ、xcodebuildではなくmacOS runnerのqueue待ちかもしれません。

Cloud Mac AI Stack · L1  ·  2026.06.08  ·  約12分

GitHub Actions macOS CI queue timeとself-hosted runner比較

GitHub ActionsのmacOS CIが遅すぎる。これって普通？

Hostedのmacos-latestでは、はい、よくあります。しかもCPUより先にqueueで詰まることが多いです。月曜朝に20-40分Queuedのまま、はiOSチームでは日常です。

この記事はL1シリーズ第2回。self-hosted runner vs macos-latestをqueue、GitHub Actions billing、xcodebuildで比較し、Cloud Mac self-hosted runnerが得かを判断します。実行レイヤーの前提はGitHub Runnerが実行エンジンである理由へ。

先に結論

HostedのGitHub ActionsでmacOS CIが遅いのは珍しくありません。最大ボトルネックはApple Siliconの性能よりbuild queueです。

  • Hosted macos-latestはピーク時にqueue time 20-40分が普通で、wall-clockが不安定
  • Cloud Macのself-hosted runnerは専有ノードなのでqueueがほぼゼロ、xcodebuildも安定
  • 判断軸は頻度。週5ジョブ未満で待てるならHosted継続、毎日iOS CIでqueue疲れならself-hosted検討

こんな疑問で来ましたか？

必要な部分だけ読みたいなら、以下から直接ジャンプしてください。

3語だけ先に整理

macOS CI = Xcode/Apple Silicon必須ジョブ · Cloud Mac = 常時稼働macOS基盤（L0） · self-hosted runner = GitHub Actionsジョブを取る実行プロセス（L1）

Cloud Macを借りるだけではrunnerは増えません。runnerを入れるだけでもCIは無料になりません。GitHub Actions billingをCloud Mac費用+運用へ置き換える話です。

self-hosted runner vs macos-latest：macOS CIの3択

見るべきはベンチマークではなく、wall-clockとqueue timeの安定性です。

比較軸 Hosted macos-latest Cloud Mac self-hosted runner ローカルMac self-hosted runner
CIコストモデル 従量課金（GitHub Actions billing） Cloud Mac月額 + 軽い運用 ハード購入 + 電力
build queue / 待ち ピーク時は20-40分以上が珍しくない 専有ノードでqueueほぼなし オンラインならqueueなし
xcodebuild安定性 ⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Apple Silicon CI 共有プール・毎回クリーン環境 Xcode/証明書/DerivedDataを固定可能 Cloud Macと同様
向いているケース 低頻度CI・待ち許容 毎日iOS CI・待ちたくない Mac miniを24/7で維持済み

macOS CIの本当のコストはCPUよりqueue time

Actionsログでxcodebuildが18分だと、マシンが遅いと誤解しがちです。実際の損失はその前、Queuedの待ち時間です。

iOS開発ではwall-clock = queue time + build time + retry。Hosted macos-latestは平日ピークのqueueが読めず、請求書には出ない待ち時間損失が速度を削ります。

まず切り分けましょう。遅いのはqueueかcompileか？ queue起因ならself-hosted runnerが効き、compile起因ならXcode設定や依存・キャッシュ最適化です。

GitHub ActionsのiOS CIが"stuck in queue"になる理由

macos-latestはGitHubの共有macOS runner pool上で動くため、供給より需要が勝ちやすいです。

  • iOS CIはmacOS必須。ubuntu-latestへ逃がせない
  • 時間帯ピークが重なる。米欧朝とアジア午後でpushが集中
  • 並列を増やしても待つ。3ジョブ同時でも3倍速ではなく3本待ちになりがち
  • 実行後は分課金継続。xcodebuild分はそのままGitHub Actions billing

PRレビュー後もChecksが黄色のまま、という体験はよくあります。コード不具合ではなくrunner未割当。Hostedで遅いのは設定ミスより構造要因です。

よくある誤解2つ

誤解1: 「Cloud MacがあればCIは自然に速くなる」

Cloud Macは常時稼働のmacOS基盤です。queue解消にはself-hosted runner登録と正しいruns-onラベルが必要です。

誤解2: 「self-hosted runner = 無料CI」

GitHubの分課金は減っても、Cloud Mac費用、証明書管理、運用当番は自社負担です。無料化ではなくTCOの移動です。

Cloud Mac self-hosted runnerの実務TCO

単価だけでなく、macOS分課金 + queue待ち人件費 + 運用時間で比較します。

1) Hosted macos-latest

課金は実行分中心（macOS単価はLinuxより高い）。運用は軽い一方、build queueは制御不可です。

まずActionsのBillingで直近30日macOS CI分数を確認。月200分未満でqueue許容ならHostedが最も簡単です。

2) Cloud Mac + self-hosted runner

コストはCloud Mac月額 + 初期設定（約1-2時間）+ 保守。代わりにqueue timeがほぼゼロの専有Apple Silicon CIを得られます。

目安はL1-Q01と同様。週10ジョブ以上かつqueue疲れがあるなら、固定費型TCOが「従量+待ち損失」を下回りやすいです。料金はプラン一覧へ。

3) ローカルMac mini + self-hosted runner

コストはハード + 電力 + 24/7稼働保証。Mac mini vs Cloud Macの観点で、既にMacを常時運用しているなら自然な選択です。

TCO簡易式 
Hosted月次 ≈ macOS CI minutes × per-minute rate + queue待ちの人件費

Cloud Mac月次 ≈ 月額 + 軽い運用（queue timeが安定）

Hosted月次がCloud Mac月額を継続的に超えるなら、self-hosted（cloud/local）を検討

self-hosted runner vs macos-latest：queueとxcodebuildの実差

self-hostedは常にCPU最速とは限りません。ただしqueueが消えるため、wall-clockは多くの場合短く安定します。

  • queue time：共有pool vs 専有runnerの差が最大
  • xcodebuild：ディスク状態と初期化条件が揃いやすく、iOS CI build timeの分散が下がる
  • concurrency：単一self-hostedは通常1ジョブ。Hostedは並列可能でもmacOSはqueue影響を受ける
  • environment：Xcode/Keychain/DerivedDataを固定できる

RunnerとOllama/Claude Codeを同居させてSwapが出る場合は、ワークロード分離も確認。遅さの原因がqueueではなくメモリ競合のことがあります。

Cloud Mac self-hosted runnerが効くケース

  • 毎日1本以上のiOS CIがあり、build queueに疲れている
  • xcodebuild・署名・notarize・TestFlightを頻繁に回す
  • push後5-15分でChecksの赤緑を確定させたい
  • 同じCloud MacでClaude CodeとCIを統合したい

この段階の問いは「self-hostedにするか」ではなく、Cloud MacかローカルMacかです。

macos-latest継続が合理的なケース

  • 月1-2回程度のarchiveで、たまのqueueを許容できる
  • 主ワークフローはLinuxで緑、macOS jobは少ない
  • iOSパイプライン検証フェーズで、まずHostedで十分
  • runner更新・token更新・ディスク清掃を持つ担当がいない

同じCloud MacでClaude Code + Runnerは可能？

可能です。日中にClaude Code、夜間に重いxcodebuildへ分離すると安定します。16GB環境でOllama+Runner+Agent同時高負荷はSwapでCIを落とすことがあります。Claude CodeはDiff、GitHub RunnerはFactを作る役割分担が現実的です。

queue待ちに耐えられないときの判断ツリー

macOS CIが遅いときの次手 
workflowにmacOS / Xcodeは必須か？
        ↓
      No → Linux hostedを継続

      Yes → build queue（20-40分）を許容できるか？
            ↓
          Yes → macos-latest継続
          No → 月あたりmacOS jobが約10件超？
                ↓
              No → hosted継続でBilling監視
              Yes → 24/7オンラインが必要？
                    ↓
                  Yes → Cloud Mac self-hosted runner
                  No → ローカルMac self-hosted runner（常時起動）

実務的には、Hostedを維持しつつ2週間Cloud MacでAB比較し、queue time、GitHub Actions billing、xcodebuildのwall-clockで判断するのが安全です。

FAQ

GitHub ActionsのmacOS CIが遅いのは普通？
Hosted macos-latestでは珍しくありません。ピーク時のqueue 20-40分は現場でよく見ます。

なぜmacos-latestはQueuedになりやすい？
共有macOS poolの供給不足と、iOS CIがmacOS必須で逃げ先がないためです。

self-hosted runnerは本当に価値がある？
毎日iOS CIを回しqueue許容が低いなら価値が高いです。低頻度ならHosted継続が合理的です。

Cloud MacでCIは速くなる？
CPUが必ず速いとは限りませんが、queue timeが大幅に減りwall-clockは安定しやすいです。

self-hosted runnerは無料CI？
無料ではありません。GitHub課金の代わりにCloud Mac費用と運用コストが発生します。

iOS CIのbuild timeが安定しない理由は？
queue揺らぎと環境揺らぎです。self-hostedでは環境固定でブレを抑えられます。

Claude Codeと同じマシンで回せる？
可能です。ピーク負荷を分離し、メモリ競合を避ける運用が前提です。

macOS CIが遅いときは、まずqueue遅延かbuild遅延かを分離し、必要ならCloud Mac self-hosted runnerへ段階移行するのが最短です。

build queueに疲れたら

Cloud Macを2週間試して、queue timeと請求を比較

専有Apple Silicon macOSでself-hosted GitHub Actions runnerを構成し、macos-latestのbuild queueから抜け出せます。GitHub Actions billingとxcodebuildのwall-clockを比較してから固定化してください。

Cloud Macプランを見る
macOS CI Cloud Mac料金