CI は死んだが GitHub はまだ気づいていない

GitHub Actions や macOS セルフホスト Runner を運用しているなら、2026 年に耳にする不満はかなり具体的です：キューが長い、Xcode のビルド時間がブレる、同じ PR で retry が続く、CI が緑と赤を行き来する。本稿は 4 層で整理します——まずその症状に名前を付け、次に Agent が CI をどう「ループ化」するか、最後に Cloud Mac がどこに効くか。タイトルの「CI は死んだ」は文末 FAQ で扱います。本文は、あなたのチームが今まさに見ている障害から書き始めます。

1 · 第一層：2026 年、GitHub Actions が「遅い・ブレる・flaky になる」理由

ここ半年、VPSSpark が話を聞いた iOS / Flutter / macOS チームの声は驚くほど重なります。問題は「CI という概念が古くなった」ではなく、次の 4 類が同時に増えていることです。

1.1 macOS runner のキュー（Queue）

ホスト macos-latest では、Queued 時間が実ビルド時間を上回ることが珍しくありません。job のタイムラインを開くと、待ち 40 分・実行 12 分——なのにチームは xcodebuild の引数をいじり続けています。診断式は今も wait time >> run time。手順の詳細は macOS runner キュー Runbook を参照してください。2026 年にキューが伸びた背景には、macOS 同時実行 cap に対して repo 内の job 数が追いついていないこと、そしてArchive など重い job がスロットを占有し PR の速報フィードバックまで巻き込むことがあります。

1.2 Xcode ビルド時間のブレ

同一 commit を再実行しても、CI 上の Xcode コンパイルは 18 分のときと 31 分のときがある。ローカル Mac では 15 分前後で安定している、というパターンです。よく重なる要因は runner のコールドスタート、DerivedData ミス、CocoaPods の再 resolve、ランナーイメージの Xcode パッチとローカルの不一致。単体では「キャッシュ設定の問題」に見えますが、retry のたびに cold 環境だとブレは「CI が信用できない」という体感に増幅されます。

1.3 retry 回数の暴走

workflow 内の retry-on-failure 以外に、暗黙の retry が増えています。Agent や bot がログを読み、patch を出し、push し、再び Actions を起動する。1 PR が「人が 2 回 push」から「マシンが 8 回 push」になり、minutes 課金とキュー圧力が同時に上がります。flaky テストのせいに見えて、実態は同じ PR に対して CI が異なるコードで何周も回っていることです。

1.4 Flaky CI：緑と赤が入り混じり、再現しない

古典的な flaky は、テストの偶発タイムアウト、シミュレータ起動失敗、署名キーチェーンの一時ロックです。2026 年はさらに一層：Agent が各ラウンドで出す diff が違うため、「テストが flaky なのか、Agent が別の箇所を壊したのか」を切り分けにくい。リリース担当がいちばん苦しむ一文：「昨夜 CI は緑だったのに、今朝同じ tag で赤になった。」

2 · 第二層：原因は「CI が劣化した」ではなく、CI がループ化した

上の 4 類は、キューだけ、キャッシュだけ、テストだけを直しても一巡分しか効きません。並べて見ると共通の筋が見えます：CI が一度きりの検証ではなく、「失敗 → 修正 → 再実行」のループになったこと。Agent 普及前はそのループはエンジニアの頭の中（直して push）にありました。今はインフラに書き込まれています——モデルがログを読み、patch を出し、workflow を自動起動します。

すでに現場でよく見るチェーンは次のとおりです。

• PR オープン → CI が赤（テスト / コンパイル）
• Agent が Actions ログを読み → fix commit を生成
• push → 新 workflow → また赤の可能性 → 再 fix
• 緑になるか、human が止めるか、token が尽きるまで

名前は GitHub Actions / CI のまま、挙動はすでに Agent retry loop です。ここで扱うのは「ある 1 回の build 失敗」ではなく、複数ラウンドが重なったあとの確率結果——だから第一層の症状が出ます。キューは多周 job で埋まり、Xcode 時間は各ラウンドの cold start でブレ、flaky はコードと環境の組み合わせが毎回変わるからです。

少し抽象ですが実務に効く言い方があります。古典的 CI は決定的（deterministic）を仮定します——同 commit・同環境なら結果は再現するはず。Agent ループ後は経路が確率的（probabilistic）に——何回目で緑になるか、途中で何版コードを経たか、Archive を誤って踏んだか、にランダム性が乗ります。すぐにプラットフォームを替えろ、という話ではなく、「キャッシュを足すだけ」では全部は直らない理由の説明です。

GitHub は workflow、runner、キャッシュを改善し続けています——対象は単発の決定的 jobです。repo がすでに Agent loop を前提にしていると、それらの改善は有効でも、「job 数 × retry 回数」の乗法効果は止められません。タイトルが「GitHub はまだ気づいていない」と言うのはここを指します。プロダクトの語りは CI/CD のまま、使われ方は自動修復ループ装置へドリフトしています。

3 · 第三層：構造の変化——CI パイプラインから retry loop + 実行基盤へ

第一層の症状と第二層の原因を揃えると、構造変化は一文で言えます：CI が直線パイプラインから、フィードバック環を持つ実行システムになった。

旧モデル：Code → Build → Test → Result。一歩失敗すればライン全体が止まる。新モデル：Code → Agent → Modify → Execute → Retry → … → Result。失敗は終点ではなく環の一部。GitHub 上の緑チェックは依然安心材料ですが、意味は変わりました——4 回目でようやく緑で、途中の commit はもう別物かもしれません。

ここで実務向けの用語：execution substrate（実行基盤）。Agent はコードをいくら書き換えても、コンパイル・署名・アップロードは安定して再現可能な macOS 実行面に落ちる必要があります。Serverless job は短すぎて状態を持ち越せない。ローカル Mac は sleep し、Xcode が勝手に上がる。ホスト runner はキューし、スペックがドリフトする。Cloud Mac が埋めるのはこの層——リモートデスクトップではなく、retry loop の中でできるだけ deterministic に保つべき唯一の層です。

実行権も移っています。以前は人が workflow を書き、マシンが従う。今は人が境界を書く（PR に何を入れるか、Archive をどこで許すか、retry の上限）、Agent が境界内で経路を試し、人が最終結果を受け入れる。macOS / iOS チームがいちばん敏感なのは、署名と Archive を retry 環で無限に回すべきではないという点——緑が出てもリリース可能とは限りません。

4 · 第四層：Cloud Mac で実行面を固定する（今すぐできること）

GitHub の narrative が変わるのを待つ必要はありません。Actions を捨てる必要もありません。ループ化 CI に対して VPSSpark 側で繰り返し効果が確認されているのは次の 4 点——Cloud Mac がホスト runner と差が出やすいところです。

4.1 プール分離：retry の被害半径を限定

PR では L0/L1 のみ（analyze、単体テスト、シミュレータビルド）、Archive を PR に入れない。リリース・IPA・公証は main / tag 専用の隔離プールだけ。Agent ループが激しくても、35 分の Archive が fast プールを占有し、全員 Queued にはしません。ハードルールと事例は CI Hard Rules、Flutter の二重プール構成は Cloud Mac 2 台で fast / archive 分離 を参照してください。

4.2 Warm environment：retry のたびに cold start させない

PUB_CACHE、DerivedData、Pods ダウンロードキャッシュを永続化。Runner は起動時自動登録、7×24 オンライン。Agent の 2 回目の retry で 15 分の pod install をやり直す必要はない——そうでないと Xcode 時間のブレが「プロジェクトが重くなった」と誤読されます。Cloud Mac で買っているのは環境を維持するコストであり、単発 CPU 分だけではありません。

4.3 macOS execution substrate：ツールチェーン版を固定

イメージや fvm で Flutter / Xcode のメジャーを pin。Archive 機と fast プールは物理分離し、DerivedData を共有しない。retry の各ラウンドは同じ Distribution 証明書、同じ CLTで走るべき——iOS CI を監査可能にする前提です。セルフホストの境界は GitHub 公式ドキュメント を参照。

4.4 Retry isolation：ループに上限を設ける

workflow で concurrency を使い同一 PR の古い run をキャンセル。Agent トリガー専用の timeout と最大 push 回数を設定。署名機は release プールのみアクセス可。構文は workflow リファレンス 参照。目標は Agent を消すことではなく、ループを制御可能な境界内で回すことです。

5 · FAQ