結論：WWDC 26（6月8日）は Xcode 26 / iOS 27 SDK を投入しましたが、新しい Mac は一台も発表されませんでした。iOS チームにとってこれは典型的な「ソフトウェア先行、ハードウェア不在」の状況です——CI パイプラインはキャッシュ消去 + フルリビルド + ホステッド Runner 混雑を同時に受け止めなければならず、ビルド速度が 10% 遅くなるのではなく、構造的に崩壊します。
四つの複合要因：① beta への更新で DerivedData が強制クリア；② iOS 27 SDK モジュールが肥大化、Swift コンパイルが重くなった；③ M5 Mac mini がなく、演算力アップグレードの道が閉ざされた；④ 6月は業界全体が同時に CI を走らせ、macos-latest の待ち時間が急増。
踏んではいけない罠：「M4 が遅い」と断定して秋の M5 を待つこと——チップを換えても ephemeral Runner は直りません。
今すぐ機能する解決策：永続ディスク付き self-hosted Mac mini を導入し、beta 検証と本番 release を Runner ラベルで分離する。詳細は self-hosted 高速化ガイドを参照してください。
6月9日（月曜日）の朝、iOS 担当エンジニアの Slack は一斉に動き始めました。「main の Archive が昨夜 11 分から 34 分に跳ね上がった」「macos-latest が 18 分待っても動かない」「Xcode 26 beta を入れたら DerivedData が消えた」——これは特定リポジトリの設定ミスではありません。WWDC シーズンには毎年 CI 地震が起きます。2026 年はメモリ供給不足・新デスクトップ Mac ゼロ・Apple Intelligence による SDK 肥大化が重なり、揺れが一段と大きくなっています。ハードウェア不在の背景は M5 Mac mini が WWDC 26 に登場しなかった理由 を参照してください。本記事が答えるのは一つだけ：なぜパイプラインが突然遅くなったのか、そして今何を変えるべきか。
1）WWDC 後に CI が遅くなる「三つの典型症状」
Actions ログを開いて以下のうち二つ以上に該当すれば、WWDC ショックウェーブが原因であり、自分のコードに問題が生じたわけではありません：
- bootstrap フェーズの急増：
pod install、SPM resolve、iOS 27 Simulator runtime のダウンロードがそれぞれ数分を占有——ホステッド Runner は毎ジョブゼロから始まるため、このフェーズが最も打撃を受けます。 - ビルドが「フルコンパイル」に逆戻り：Xcode メジャーバージョン更新後、ModuleCache と DerivedData の形式が旧版と互換性を失い、増分コンパイルが無効化されます。
xcodebuildの所要時間がコールドスタートに近づきます。 - キュー待ち時間の長期化：WWDC 後 72 時間以内に多数のチームが beta を試すため、ホステッド macOS 分数の共有プールが混雑し、待ち時間がビルド自体を超えることもあります。
Setup Xcode・Run script の所要時間を比較してください。Setup が 1 分から 8 分になり、コンパイルが増分でなくなっているなら——問題はツールチェーン切り替えであり、Swift のビジネスロジックではありません。2）Xcode 26 beta：強制「キャッシュリセットシーズン」
Apple は WWDC 当日に Xcode 26 beta と iOS 27 SDK をリリースしました。ローカル開発者にとってはインデックス再構築と少しの待ち時間ですが、CI 基盤にとってはディスク上の全状態が無効化されます：
- DerivedData のパスとインデックス形式の変更——旧キャッシュは再利用不可。更新後初の Archive は必ずフルビルドになります。
- Swift コンパイラバージョンの切り替え——
.swiftmoduleバイナリが非互換になり、すべてのターゲットが再コンパイルされます。 - CocoaPods / SPM ロックファイルの揺れ——iOS 27 未対応の Pod があると、
pod installが繰り返し resolve したり完全な repo-update を引き起こします。 - 新 Simulator runtime——1 ランタイムあたり数 GB。ホステッド Runner は毎ジョブ再ダウンロードするため、bootstrap に +5〜15 分追加されます。
より深刻な組織リスクは圧力による beta 採用です。keynote の翌日には必ず「Siri AI に対応したの？」という問いが飛んでくる——チームは準備が整う前に Xcode 26 を main にプッシュしてしまいます。ワークフローを一行変えるだけで、CI フリート全体がコールドスタートモードに入ります。正しいアプローチはパイプラインの分離：本番 release は安定版 Xcode 16 に固定し、ios-27-beta ブランチまたは専用 beta Runner のみで適応作業を行う。詳細は Xcode サポートマトリクスを確認してください。
3）SDK 肥大化：コンパイル量増大、演算力は据え置き
WWDC 26 の主役は Siri AI と Apple Intelligence の拡充でした（MacRumors WWDC 26 まとめ）。アプリエンジニアにとって、これは実際のビルドコスト増につながります：
- 新しいフレームワーク依存（App Intents、ビジョン/音声パイプラインの抽象化）——リンカーグラフに追加されるモジュールが増加。
- Swift 6 の並行性チェックがより厳格に——同じソースコードでもコンパイラの処理量が増えます。
- Asset Catalog とローカライズリソースの膨張——Copy Bundle Resources フェーズが目に見えて長くなります。
ウォームキャッシュがあるローカルの M4 MacBook では「2 分ほど余計にかかる」程度に感じるかもしれません。しかし永続キャッシュのないホステッド Runner では、コールドスタートのペナルティと重なり「遅い」が「許容不可」に変わります。Apple が AI 機能を出荷し、ツケを払うのはCI キューに並ぶ開発者たちという皮肉な構図です。
4）新 Mac なし：演算力アップグレードの道が閉ざされた
例年の WWDC サイクルなら「発表後に CI 用 Mac mini を買おう」と思えたはずです。2026 年はハードウェアゼロ、M5 Mac mini は秋のウィンドウまで待つ見通しで、グローバルのメモリ供給不足により 24 GB / 32 GB SKU は入手困難になりえます。現実的な影響：
- 「新機種購入でビルド遅延を解決しよう」と考えていたチーム——購買判断が 3〜4 ヶ月凍結。
- M2/M3 の 16 GB Runner を運用中のチーム——SDK 更新後はメモリがさらに逼迫し、
swift-frontendと Simulator が並行動作するとスワップが発生してビルド時間が非線形に悪化します。 - 2 台目 Runner を追加して並列度を上げたいチーム——ハードウェア納期が beta 対応期限に間に合いません。
M4 が非力だと言いたいわけではありません——ほとんどの iOS CI では M4 16 GB で十分です。ポイントは、WWDC 後に遅くなった主因がチップ性能ではなく実行モデル（ephemeral か永続ディスクか）にあることです。M5 を待つのはハードウェアの話にすり替えて工学的課題を先送りにしているにすぎません。
5）ホステッド Runner の「WWDC スタンピード」
毎年 6 月、GitHub ホステッド macOS プールは需要ピークを迎えます。2026 年の特殊性は、AI の物語が iOS ネイティブでないチームを macOS ジョブに引き寄せた点です——Core ML 変換の実行や Apple Intelligence サンプルプロジェクトのテストが、本来の App リリースパイプラインと同じプールを争奪します。
ホステッド Runner の三つの構造的弱点が WWDC シーズンに増幅されます：
| 弱点 | 通常時 | WWDC 後 |
|---|---|---|
| Ephemeral ディスク | コールドスタートは許容範囲 | beta ジョブごとに SDK コンポーネントを全量ダウンロード |
| 共有キュー | オフピーク時は問題なし | 平日昼間に queued >10 分が常態化 |
| キャッシュアクションの無効化 | DerivedData が部分的にヒット | Xcode メジャー更新で全 cache key が失効 |
macos-15 や macos-latest ラベルへの切り替えは解決策になりません——ラベルは OS イメージを変えるだけで「明日も DerivedData が残る」わけではないからです。GitHub Actions iOS CI 速度分析によると、中規模 Swift プロジェクトのホステッド P50 は約 28 分で、そのうちキュー + bootstrap が半分以上を占めることが多く、WWDC 後に bootstrap が単独で +40% 増加するケースも珍しくありません。
6）WWDC 前後：同一リポジトリの典型的な所要時間変化（サンプル）
以下は、Nuvcloud の顧客のうち Runner モデルを変更せず、main で Xcode 26 beta にのみ切り替えた Swift/UIKit プロジェクト（CocoaPods、シングルスキーム）の P50 比較です。SLA ではありません。自分のリポジトリで検証してください：
| フェーズ | WWDC 前 P50 | WWDC 後 P50 |
|---|---|---|
| queued | 5 min | 12 min |
| bootstrap | 7 min | 14 min |
| build / archive | 9 min | 16 min |
| sign + upload | 4 min | 5 min |
| 合計 | ~25 min | ~47 min |
同じリポジトリを self-hosted Mac mini M4 に移し、本番ジョブを Xcode 16 に固定、beta Runner のみ Xcode 26 に更新した場合、本番ラインの P50 は WWDC 前の水準を維持できます。beta ラインは初週に 20 分超のフルコンパイルになりますが、main には影響しません。これが Runner 分離の価値です。
7）今すべきこと：実行モデルを直す、M5 を待たない
WWDC 後 48 時間以内に、以下を優先度順に実施してください：
- 本番 release の Xcode バージョンを固定する——ワークフローに
xcode-selectまたはDEVELOPER_DIRをハードコードし、main が自動的に beta を追わないようにする。 - beta 適応は専用ブランチ + 専用 Runner ラベルで行う——例：
runs-on: [self-hosted, macos, xcode26-beta]、本番ios-ciラベルと完全に分離。 - 永続ディスク付き self-hosted Runner を導入する——DerivedData、Pods、SPM キャッシュがジョブをまたいで保持され、2 回目の beta ビルドから増分時間に戻ります。設定方法は GitHub self-hosted runner ドキュメントを参照。
- Simulator runtime は一度だけインストールする——Runner イメージに iOS 27 runtime をあらかじめ焼き込み、ワークフロー内で
xcodebuild -downloadPlatformを実行しない。 - 48 時間日次レンタルで検証する——月次プランにコミットする前に クラウド Mac mini を 2 日間借りてビルドを検証。ノード選定は 6 リージョン Runner TCO 比較を参考にしてください。
8）よくある質問
WWDC 後すぐに Xcode 26 へ移行しなければなりませんか？ いいえ。App Store 審査には安定版 Xcode が引き続き必要です。beta は iOS 27 API への早期適応にのみ使用し、専用パイプラインで隔離してください。
秋に M5 Mac mini が出れば一件落着ですか？ 構造的には解決しません。新チップでフルコンパイルが 10〜15% 短縮されても、ジョブごとのコールドスタートは直りません。メモリ供給不足で M5 の大容量 SKU は高価になる可能性もあります——ローンチ前に TCO を計算してください。
DerivedData を actions/cache でキャッシュするだけでは不十分ですか？ WWDC シーズンは通常不十分です。Xcode のメジャー更新後に cache key が失効しますし、数 GB の DerivedData をアップロード/ダウンロードするネットワーク時間は、永続ローカルディスクと比べてコスト高になりがちです。
beta が不安定で CI が真っ赤になったらどうすればいいですか？ 想定内です。beta Runner は main マージをブロックすべきではありません。beta パイプラインを optional status check に設定するか、nightly 実行のみにスケジュールしてください。
過去の WWDC と比べて 2026 年が特別な理由は何ですか？ 三つの要因が重なりました：AI 主導の SDK 肥大化・デスクトップ Mac の不在・メモリサプライチェーンの逼迫。個別なら対処できますが、三つ重なると「遅い＝マシンが非力」と誤診され、誤った機材調達やホステッド分数の無駄な追加購入につながります。
WWDC は新 SDK をもたらした。演算力は秋まで待たなくていい
本番は Xcode 16 固定、beta は専用 Runner へ——Nuvcloud M4 Mac mini を 48 時間日次レンタルで試してみる → self-hosted 高速化ガイド