macOS CI auf GitHub Actions ist extrem langsam - ist das normal?
Auf Hosted macos-latest leider oft ja. Der Schmerz beginnt meist in der Queue, nicht bei der CPU.
In L1-Q02 vergleichen wir self-hosted runner vs macos-latest nach Queue, GitHub Actions billing und xcodebuild.
先に結論
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検討
Mit einer dieser Fragen hier?
Direkt zum relevanten Abschnitt springen:
- self-hosted runnerは本当に元が取れる? → Cloud Macの実質TCO + 判断ツリー
- Cloud MacにしたらCIは速くなる? → queueとCPUのどちらが効くか
- なぜmacos-latestはいつもQueued? → iOS CIが詰まる構造
- self-hosted runnerは無料CI? → 誤解:self-hosted != 無料
- iOS CIのbuild timeが毎回ブレる理由は? → 性能差 + 比較表
Drei Begriffe, sauber getrennt
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: drei macOS-CI-Optionen
見るべきはベンチマークではなく、wall-clockとqueue timeの安定性です。
| Dimension | Hosted macos-latest |
Cloud Mac self-hosted runner | Lokaler 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で維持済み |
Warum bei macOS CI queue time teurer ist als CPU
Actionsログでxcodebuildが18分だと、マシンが遅いと誤解しがちです。実際の損失はその前、Queuedの待ち時間です。
iOS開発ではwall-clock = queue time + build time + retry。Hosted macos-latestは平日ピークのqueueが読めず、請求書には出ない待ち時間損失が速度を削ります。
まず切り分けましょう。遅いのはqueueかcompileか? queue起因ならself-hosted runnerが効き、compile起因ならXcode設定や依存・キャッシュ最適化です。
Warum iOS CI auf GitHub Actions oft stuck in queue ist
macos-latestはGitHubの共有macOS runner pool上で動くため、供給より需要が勝ちやすいです。
- iOS CIはmacOS必須。
ubuntu-latestへ逃がせない - 時間帯ピークが重なる。米欧朝とアジア午後でpushが集中
- 並列を増やしても待つ。3ジョブ同時でも3倍速ではなく3本待ちになりがち
- 実行後は分課金継続。
xcodebuild分はそのままGitHub Actions billing
PRレビュー後もChecksが黄色のまま、という体験はよくあります。コード不具合ではなくrunner未割当。Hostedで遅いのは設定ミスより構造要因です。
Zwei typische Fehlannahmen
Fehlannahme 1: Mit Cloud Mac ist CI automatisch gelöst
Cloud Macは常時稼働のmacOS基盤です。queue解消にはself-hosted runner登録と正しいruns-onラベルが必要です。
Fehlannahme 2: self-hosted runner bedeutet kostenloses CI
GitHubの分課金は減っても、Cloud Mac費用、証明書管理、運用当番は自社負担です。無料化ではなくTCOの移動です。
Reale TCO eines Cloud Mac self-hosted runners
単価だけでなく、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を常時運用しているなら自然な選択です。
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- und xcodebuild-Unterschiede
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ではなくメモリ競合のことがあります。
Wann sich Cloud Mac self-hosted runner lohnt
- 毎日1本以上のiOS CIがあり、build queueに疲れている
xcodebuild・署名・notarize・TestFlightを頻繁に回す- push後5-15分でChecksの赤緑を確定させたい
- 同じCloud MacでClaude CodeとCIを統合したい
この段階の問いは「self-hostedにするか」ではなく、Cloud MacかローカルMacかです。
Wann macos-latest die bessere Wahl bleibt
- 月1-2回程度のarchiveで、たまのqueueを許容できる
- 主ワークフローはLinuxで緑、macOS jobは少ない
- iOSパイプライン検証フェーズで、まずHostedで十分
- runner更新・token更新・ディスク清掃を持つ担当がいない
Ein Cloud Mac für Claude Code + Runner - realistisch?
可能です。日中にClaude Code、夜間に重いxcodebuildへ分離すると安定します。16GB環境でOllama+Runner+Agent同時高負荷はSwapでCIを落とすことがあります。Claude CodeはDiff、GitHub RunnerはFactを作る役割分担が現実的です。
Entscheidungsbaum, wenn die Queue nicht mehr tragbar ist
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と同じマシンで回せる?
可能です。ピーク負荷を分離し、メモリ競合を避ける運用が前提です。
Bei langsamem macOS CI zuerst klären, ob Queue oder Build das Problem ist. Danach ggf. schrittweise auf Cloud Mac self-hosted runner wechseln.
Genug von der build queue?
Cloud Mac zwei Wochen testen und queue time plus Kosten vergleichen
専有Apple Silicon macOSでself-hosted GitHub Actions runnerを構成し、macos-latestのbuild queueから抜け出せます。GitHub Actions billingとxcodebuildのwall-clockを比較してから固定化してください。
