iOS チームが 20 人になると、CI/CD はどこから崩れるか

本稿は iOS CI/CD の Scaling Failure Model（拡員時の崩壊モデル）であり、容量計算機ではありません。引き継ぎ前、チームは 14 か月で 8 名から 20 名へ拡大した一方、Runner トポロジはほぼ据え置きのままでした。結果として、リリース週は PR が全面赤、ビルドが長時間 Queued のまま、TestFlight が 2 日遅れました。以下では「人数が増えると CI が遅くなる理由」と、ボトルネックが pipeline のどこに乗るかを整理します。

「1 日 500 回のビルドに Mac は何台必要か」が知りたい場合は、姉妹記事 3 台の Cloud Mac で 1 日 500 回の iOS ビルドを支える を参照してください。あちらは引き継ぎ後の実装論です。本稿は引き継ぎ前に何が崩れたかに焦点を当てます。

俯瞰：CI が「人数増」から Failure Zone へ滑り落ちる仕組み

図 1 は本稿全体のメカニズム俯瞰図です。pipeline の細部より、postmortem の冒頭やチーム onboarding 向きです。崩壊は単一点ではなく、下記チェーン上の重なり合いとして起きます。

iOS CI/CD アーキテクチャ図：PR から TestFlight までのボトルネック地図

図 2 は macOS Job 1 回分の実行経路（L0/L1/L2）で、本事例で最初に打ち抜かれた 2 箇所を示します。「コンパイルが遅い」のか「Job がそもそも走っていない」のかを切り分けるのに使えます。

起点：8 名のとき「足りていた」CI が、なぜ伸びなかったか

2024 年中期の構成は典型的でした。

• 1 台のオフィス Mac mini M2 が Self-hosted Mac Runner を兼務（GitHub 自ホスト Runner ドキュメント参照）
• その他の Job は GitHub ホスト型 macOS Runner
• Monorepo 内に 2 つの App、workflow は 1 本の YAML で全対応
• 1 日あたり macOS Job 約 80～120 回、キュー P95 は 5 分以内

CTO の言葉は「CI はボトルネックではない。ここに時間をかけるな」でした。8 名なら成立します。人員が倍になっても CI は見えない税となり、容量計画はなく feature team だけが workflow を積み上げていました。

Healthy baseline：何を「正常」と対照するか

20 名の崩壊週だけを見ると、「チームが大きくなれば Mac を大量購入しなければならない」と誤判断しがちです。ここでは健康基線 vs 崩壊週の対照表を補います。数値は当該顧客の 8 名帯の実測と、当社が手がけた中規模 iOS チームの経験レンジに基づきます（業界標準ではありませんが、社内 review には十分です）。

重要な対照：崩壊週の run duration はほぼ不変で、queue time だけが約 10 倍です。問題はコンパイル能力ではなく、キューと workflow にあります。これが「CI が遅い」という言い方でチームを誤導しやすいポイントです。

タイムライン：3 回の警報、3 回とも「偶発」と見なされた

第 1 回（12 名、iOS +4 名）：PR マージ頻度が 1 日平均 6 回から 14 回へ。ホスト型 Runner の build queue が午後に 25～40 分の待ちを記録。チームの反応は「今日は GitHub が不調か」。queue_wait_seconds の曲線は誰も引いていませんでした。

第 2 回（16 名、同一 repo を共有するバックエンド +2 名）：オフィスに2 台目の Mac miniを追加。両方とも self-hosted 登録で、ラベルによるキュー分離なし。Archive と PR Build が同一プールを奪い合い、軽 Job が 8 分から 35 分に化け、重 Job の公証がランダム失敗。反応は「もう 1 台 HDD を買ってみよう」。

第 3 回（20 名、2 App の大型バージョンが衝突）：リリース週に macOS Job が 1 日平均 120 回から280+へ。Slack #ios-ci が 24 時間体制のメンションに。反応は「Mac mini 8 台の調達が進行中」——これが 1 日 500 回の事例で見た 8 台案です。当時は Job の内訳計算は未実施でした。

表の 2 点：16→20 名で Job 量が急増し、Archive 比率は約 18% から 38% へ。queue time と Job 量は非線形——人数は倍になっていないのに、キューは先に倍になります。拡張予算を誤算しやすい箇所です。

閾値モデル：12 名 Warning / 16 名 Structural Debt / 20 名 Failure Zone

本事例を weekly review で使える枠組みに整理しました。精密な式ではありませんが、Runner トポロジを動かすべきかの判断には足ります。

分子 3 項は GitHub Actions ログから算出可能です。分母の「有効 Runner プール」は登録台数ではなく、ラベルで分流できる並列 Mac スロット数です。オフィス mini が開発に占有されると、分母は瞬時に割り引かれます。以下任意 2 つが同時に成立したら、「もう 1 台 Mac mini」ではなく pipeline 再設計を推奨します。

• queue_wait_seconds P95 > 30 分 かつ Archive 系 Job 比率 > 30% → L1/L2 分離必須、PR 全量 Archive を停止
• 1 回の push で起動する macOS Job 数 P99 > 15 → matrix/path filter が制御不能、機械追加より Job 削減を先に
• L2 が 3 日連続 queue P95 > 40 分 かつキャッシュヒット > 60% → 構造的拡張、専用 release プールを検討

当該顧客の 20 名崩壊週は 3 条件すべて該当——Failure Zone であり、「分数パック追加」では解決しない Warning ではありません。

GitHub Actions queue time：12 名以降、最初に失控する指標

多くのチームは「CI 遅延」を compile 遅延と解釈し、DerivedData を調整します。本顧客のログでは失控したのは queue time——Job が長時間 Queued のままです。GitHub は queue_wait_seconds と run duration を分離統計します。後者だけを見ると、コンパイルを直しつつボトルネックは組織並列と Runner 分池のまま残ります。

組織 macOS 並列は GitHub Actions usage limits を参照。12 名以降の午後 PR ラッシュではRunner が遅いのではなく、空きスロット待ちです。UI の Queued スピナーはネットワークや Xcode 問題と混同されがちです。調査時は Job 実行時間とキュー待ちで wait と run を分けてください。

12 名帯で queue P95 はすでに 25～40 分。当時 fast/archive をラベル分池していれば（2 台 mini の混在ではなく）、後続の署名競合は先送りできた可能性があります。Runner トポロジ選定は エラスティックプール vs 常駐ノードの意思決定マトリクス を参照。

拡員時の 5 ボトルネック（Scaling Taxonomy）

以下 5 類は当社の mobile CI 障害ラベルです。図 2 の pipeline と対応し、postmortem 記述に使えます。

① Capacity bottleneck · 組織 macOS 並列の上限

ホスト型 Runner 並列が打ち抜かれると、軽 Job と Archive が同一キューに並び、速いキューが遅い Job に塞がれます。表現は前節の GitHub Actions queue time 曲線と一致します。分数パック以外に、L2 をホスト型プールから切り出す方が安定します。組織並列は常に最初の天井です。

② Resource contention · オフィス Mac mini が「予備開発機」化

エンジニアが SSH できるマシンに Runner を載せると、いずれ誰かがローカルで xcodebuild debug を実行します。Runner と日常開発が CPU/ディスクを奪い合い、タイムアウトや偶発 compile error になります。16 名時、2 台 mini は「金曜全滅・月曜復活」があり、根因は Remote Desktop でのブランチ変更でした。

③ Workflow design debt · 全 PR でフル Archive

8 名期の「PR 緑 = リリース可能」の省略実装：各 pull request workflow の末尾に Archive + アップロード。人数が少ないうちは 1 日 6 回なら耐えられます。20 名ではArchive 系 Job 比率が 10% から workflow 設計で 35%+へ押し上げられ、遅い Job がすでに混雑したキューへ流入します。正しくは L1 統合ビルドと L2 Archive を分離——引き継ぎ後の改造で初めて実装され、姉妹記事の Job 層別章を参照。

④ Scaling explosion · Monorepo マトリクス Job の指数増

20 名時、1 回の push で最大 22 個の macOS Job——人数は 2.5 倍、Job は 4 倍。プロダクトペース下で最も見落とされやすい崩壊点です。

⑤ Crypto / signing contention · リリース日の Keychain と署名競合

2 台の Self-hosted Mac が同時 Archive なら 16GB でも偶発は耐えます。Match 解除、公証、TestFlight アップロードが重なると、Keychain ロックと codesign 競合で同一エラーコードがランダムに出ます。リリース週は「証明書が見つからない」が 4 連続、ローカル Mac 再実行は成功——典型的な複数 Job による署名環境の奪い合いであり、証明書期限切れではありません。設定は Apple Xcode Signing and Capabilities を参照。

試した「修正」が、なぜ状況を悪化させたか

GitHub 分数パックの追加購入：ホスト型キューだけ緩和、Archive 比率は不変。費用はかかり P95 は 60 分超のまま。

オフィス 3 台目 Mac mini：依然 fast/archive ラベルなし、3 台混在で署名失敗率が上昇。

金曜マージ禁止：PR 頻度を人為抑制、リリース週に集中爆発、ピークがより尖る。

各 Job に timeout-minutes: 180：Queued 時間は timeout に含まれず、より多くの Job が長時間スロット占有。

唯一有効だが未完だった試み：Release を別マシンへ——しかし依然オフィス mini、夜間 Keychain 未解除、月曜 L2 キュー滞留。

監視で見るべき、誰も見ていなかった 3 指標

崩壊前の Grafana は「成功率」と「平均時間」のみ。引き継ぎ 1 週目に追加した 3 指標で 80% を特定（queue_wait_seconds の切り口は前節 GitHub 公式モニタリング参照）：

• queue_wait_seconds P95（L0/L1/L2 別バケット）——「コンパイル遅延」と「キュー待ち」の分離
• Archive 系 Job 比率（週次）——workflow 設計の失控検知
• 1 回の push で起動する macOS Job 数 P99——matrix の指数膨張

20 名崩壊週：L1 queue_wait P95 47 分、Archive 比率 38%、push トリガー Job P99 19。3 つのうち 2 つ超過なら、調達よりトポロジ変更を先に。

止血の順序：トポロジを直してから、Mac 台数を議論

引き継ぎ後 2 週間は新規購入なし、4 点のみ実施。

• PR workflow から Archive 削除、L2 は nightly + release ブランチのみ
• path filter 強化、README/バックエンド変更で iOS matrix を起動しない
• オフィス mini から Runner 撤去、開発との争用を回避
• ホスト型は L1 ピークのみ、L2 はすべて専用ノードへ

この 4 点だけで、リリース週 queue_wait P95 は 47 分から22 分へ——まだ不十分ですが、崩壊の主因はトポロジと workflow であり「Mac 台数の神秘公式」ではないことを示しました。その後 Cloud Mac の fast/release 分池と容量検証を実施。エラスティック vs 常駐は GitHub Actions 自ホスト macOS Runner：エラスティックプールと常駐ノードの意思決定マトリクス を参照。

拡大中チーム向け：3 つの早期シグナル

12 名から 20 名へ伸ばしている最中、以下のいずれかが出たら、リリース衝突を待たず当週 30 分の CI 専項レビューを推奨します。

• 開発者が「CI をスキップして先に merge できないか」と聞き始める
• オフィス Mac に「再起動禁止、Runner 実行中」の付箋が出る
• TestFlight ビルドは成功するが「アップロード枠待ち」が常態化

これら 3 シグナルの背後では、通常すでに上記 5 崩壊点のうち 2 つ以上に踏んでいます。

Postmortem Summary（引用可）

FAQ