GitHub Actions の macOS Job が Queued のまま動かない（Xcode が遅いわけではない）

VPSSpark CI キュー診断スタンダード（クラウド Mac CI シリーズ #2）。読み順：Hook → 公式 → 症状 → Failure Model → Hard Rules → Runbook → FAQ。関連：#1 キャパシティ · #5 スケール失敗事例 · #3 セルフホスト TCO · #8 ビルド高速化。

1 · Hook：直感に反する結論

GitHub Actions のタイムラインを開くと、赤い PR が「コンパイルが遅い」と報告されがちです。しかし 待ち行列（Queued） と 実ビルド（In progress） は別メトリクスです。SRE 視点では、まず「待ちが実行を圧倒しているか」を切り分けないと、Xcode バージョンアップや分課の追加は的外れになります。本稿はその切り分け用の規格です。

2 · コア：たった一つの公式

以降の章はすべて、この判定を展開したものです。オンコール Wiki にそのまま貼ってください。

CI queue problem  ⇔  wait time  >>  run time

日本の iOS チームでは、ホステッド macos-latest と自前ランナーを混在させるケースが多く、「分は余っているのに Queued」 という矛盾が起きやすいです。これは課金単位（minutes）と同時実行枠（concurrency）の混同が根底にあります。公式が true のときだけ、プール設計とトリガー設計に手を入れてください。

3 · 症状：Queued ≠ Running

GitHub Actions では Queued はジョブがワークフローに入ったが まだランナースロットがない 状態です。In progress で checkout、xcodebuild、署名が走ります。1 時間赤い PR を「遅いコンパイル」と見なし、タイムラインを開くと 待ち 52 分・実行 11 分 という典型パターンが出てきます。

よくある誤修正：Xcode を上げる、timeout-minutes を延ばす、GitHub の分を買い足す。Queued 時間は、設定したつもりのタイムアウトに含まれないことが多い ので、タイムアウトだけ伸ばしても待ち行列は解消しません。

計測は ジョブ実行時間（queue_wait_seconds と実行時間）で行います。週次で P95 を見ると、金曜のマージラッシュ前に Trigger Explosion を検知できます。

Slack に「CI が遅い」と流れるとき、まず UI のバッジを確認してください。Queued が長いのに開発者が DerivedData を疑うのは、観測点が実行フェーズに偏っているためです。Runbook では待ちと実行を必ず分けて記録します。

4 · 説明：CI Queue Failure 3 Layer Model

wait time >> run time のとき、原因は次の SRE 型レイヤーのいずれか（または積み重ね）です。

Capacity Limit — ホステッド macOS ランナー と組織の macOS 同時実行上限（制限）に当たります。Pool Misdesign — 典型根因はジョブ階層 L2 が PR に載っていること、プールの混在です。Trigger Explosion — ハードより YAML を直します。（Failure レイヤー ≠ ジョブ階層 L0/L1/L2。）

3 層は排他ではありません。金曜 17 時に matrix が増え（Trigger）、Archive が fast プールを占有し（Pool）、ホステッド枠も枯れる（Capacity）という「三重苦」は、20 人規模チームの事例記事 #5 でも再現性が高いです。切り分けは上表のシグナル列から始めてください。

5 · 修正：CI Hard Rules（MUST NOT 違反禁止）

Runbook 向けの規範文です。提案ではなく、違反はインシデント扱いにしてください。

Rule 1: PR MUST NOT run L2
                Rule 2: L2 MUST run on isolated pool  (macos-archive)
                Rule 3: fast pool MUST remain unblocked  (fast ≠ archive)

                # Mapping
                PR     → L0 + L1 only     → macos-fast
                main   → L2 only            → macos-archive

ジョブ階層リファレンス（Hard Rules の実装のみ）：

「PR で Archive を一度だけ」は例外に見えても、38 分の L2 が fast ラベルを奪うと、レビュアー全員の L0/L1 が Queued になります。例外運用はプール設計を壊すので、ナイトリー／main 専用ジョブに寄せてください。

jobs:
                  pr-fast:
                    if: github.event_name == 'pull_request'
                    runs-on: [self-hosted, macos-fast]

                  release-archive:
                    if: github.ref == 'refs/heads/main' || github.event_name == 'schedule'
                    runs-on: [self-hosted, macos-archive]

ランナー構成：弾性プール vs 常時オン比較 · #1 サイジング · キュー健全化後 → #3。

6 · Runbook：1 ページ（オンコール）

0. CI queue problem ⇔ wait time >> run time  ?  ─No→ #8
                1. Layer: Capacity | Pool Misdesign | Trigger Explosion
                2. MUST: Rule1 PR no L2 · Rule2 L2 isolated · Rule3 fast unblocked
                3. PR workflow has no archive/export/upload ?
                4. wait P95 < 8min → then size runners (#3)

一行まとめ： macOS CI の queued の多くは PR パスの L2 であり、ハード不足ではありません。 macOS runner queued ＝プール飽和。wait >> run → Failure Model → Hard Rules の順で適用してください。

インシデント後の振り返りでは、「台数を増やした」だけでは再発します。Rule 1〜3 がリポジトリに入っているか、PR テンプレに「Archive ジョブを追加していないか」をチェック項目として載せると再発率が下がります。

7 · FAQ