2026年 グローバルチーム：GitHub Actions 自前 macOS Runner で Set up job の長尾遅延を近接物理 Mac がどう圧縮するか（Actions キャッシュ・ミラー・Runner リージョン配置の閾値マトリクス／FAQ）
3 大陸にまたがるプラットフォームチームでも、macOS CI で xcodebuild に到達する前に「Set up job」が checkout、cache リストア、依存取得で数分を溶かすことがあります。本稿は長尾を生むフェーズに名前を付け、フェーズ優先度・Actions cache とプライベートミラー・Runner 地理の 3 つの閾値マトリクス、7 ステップの展開、引用用数値、FAQ を 1 本にまとめ、財務説明と同じ資料でリージョナル物理 Mac 方針を防衛できるようにします。
1. グローバル macOS「Set up job」遅延の痛点
1) コントロールプレーン RTT は、壊れるまで見えない。 Runner 登録、ジョブ割当、メタデータ取得は GitHub API をまたぎます。大陸のズレたプールでは、ワーカーが空いていてもオーケストレーション待ちでシェルが止まり—特にセルフホストラベルと重い workflow_dispatch の扇を混ぜるときに顕在化します。
2) checkout と cache リストアは、CI に化けた WAN 問題。 shallow clone は効きますが、LFS、サブモジュール、数 GB の cache tarball は大洋経路で CPU が遊んでいるのに時間を食います。多くのチームは「より速い Mac」を買いますが、正解は Git と成果物エンドポイントを Runner とコロケーションすることです。
3) ミラーと cache の意思決定はガバナンスなしに漂流する。 リージョンごとに公開 CDN へ pod install すると作業が重複し、再現性が壊れ、どのジョブが永続セルフホスト状態を本当に要するかが見えなくなります。
Runner ライフサイクル（長寿命セルフホストと Ephemeral Mac プール）、ラベル設計、成果物エグレスは 1 つの決定として扱います。cache 方針とフリートトポロジは同じアーキレビューに載せ、別々の RFC に分けないでください。単一拠点に Runner を寄せたときの生産性コストの型は 2026年コスト避坑ガイド：なぜ単一拠点でのリモートMac配備がグローバルチームの生産性を15%低下させるのか？ が整理しています。
2. 意思決定マトリクス：Set up job のどのフェーズを優先するか
単一 macOS ジョブで分散が大きいとき—中央値は許容でも p95 がナイトリーを壊す—に使います。支配的なタイムレンジに合う行を選び、ハードウェア購入の前に対応を実行します。
| 支配的フェーズ | 症状パターン | 最初の手 |
|---|---|---|
| Runner ハンドシェイク／ジョブ取得 | 断続的スパイク。GitHub 障害や VPN フラップと相関 | エグレス強化（スプリットトンネル、冗長 DNS）、リージョン別プール分割、Runner バージョンの偏りにアラート |
actions/checkout |
リポジトリサイズに比例。リポが米東で APAC／EMEA が不利になりやすい | 同一大陸 Runner、部分 clone 設定、マトリクスジョブでの重複 checkout を避ける |
| Cache リストア | 巨大 tarball、無害なコミット後の連続ミス | キー締め、tarball 上限、バイナリはオブジェクトストアへ。cache API 経路を Runner とコロケーション |
| 依存解決 | CPU 低・ネットワーク高。フィーチャブランチのロックファイル乱流 | リージョンプルスループロキシ、不変の社内ミラー、ロックファイル CI の強制 |
iOS リリーストレインでアップロードと署名ステップがまだマシン地理に支配される理由は、パイプラインのさらに手前—Set up job 内—でも同じ RTT 論理が効く、という整理です。キュー・依存キャッシュ・適合性テストまで含めた越境配信の比較は 2026年 越境iOSデリバリー：Xcode Cloudかマルチリージョン物理リモートMac企業プールか？ビルドキュー、依存キャッシュ、適合性テストの意思決定マトリクス（実行可能な閾値とFAQ） を参照してください。
3. 意思決定マトリクス：GitHub Actions cache とプライベートミラー／レジストリ
Actions cache は製品同梱で手軽ですが、数 GB 級成果物の CDN ではありません。以下はプラットフォームとモバイル責任者の交渉アンカーです。
| シグナル | 閾値（目安） | 典型的な対応 |
|---|---|---|
| 週次 P95 cache blob サイズ | < おおよそ 900 MB | actions/cache のまま。キーとリストア順を最適化 |
| 週次 P95 cache blob サイズ | > おおよそ 1.8 GB | 大きい成果物はリージョン S3 互換ストアまたはレジストリへ。cache はメタデータ層のみ |
| 大洋横断 cache リストア（1 日） | ホットブランチで > おおよそ 28 回 | 各大陸に読み取りレプリカまたはプルスルーキャッシュ。小さな共有レイヤだけ Actions cache |
| バイナリ／コンテナベースレイヤ | 非自明なサイズなら常に | Actions cache の主格納にしない。コンテンツアドレス blob ストアとライフサイクルで管理 |
長寿命の実機 CI ではキャッシュの「温まり方」が使い捨て VM と異なります。ワークスペースを温めたまま運用する前提なら、ディスク衛生と Runner ユーザーの一貫性が cache キー設計とセットで効いてきます。
4. 意思決定マトリクス：いつ別リージョンに物理 Runner プールを足すか
リージョンは高コストです。トークン、踏み台、Xcode ライセンス、SOC2 エビデンスが倍増します。指標が 2 週連続で以下の帯を跨いだときに追加し、VP の一度きりの不満では増やしません。
| 観察 | 閾値 | アクション |
|---|---|---|
| Set up job 中央値（checkout＋依存） | リージョン A で > おおよそ 95 s、参照 B で < おおよそ 38 s | Git とミラーに揃えた物理 Runner を A に立ち上げ、カナリジョブで比較 |
| macOS ラベルの p95 キュー待ち | > 中央値ジョブ時間の 2〜3 倍 | 同時実行を増やすかラベルでプール分割。ネットワークのせいにする前にキャパを疑う |
| データレジデンシー要件 | 成果物エグレスのハード制約 | リージョン必須プール＋リージョン内ミラー。SCIM とシークレット範囲をリージョン別に文書化 |
| 単一大陸チーム | 大洋をまたぐ貢献者なし | プレミアム 1 プール＋ミラーが、早すぎるマルチリージョン複雑化に勝つことが多い |
5. 7 ステップの展開
- Set up job 内にタイミングをタグ付け。 checkout、cache、ブートストラップを軽いタイムスタンプ（
/usr/bin/timeラッパーでも可）で囲み、ダッシュボードにフェーズ比率を出します。 - 候補 Runner から Git とレジストリ RTT を地図化。 開発者が使う経路（社内 VPN と直結）で測り、偽陰性を避けます。
- cache とミラーのマトリクスを適用。 Runner 台数を増やす前に巨大 blob を cache の外へ出します。
- 1 リージョンの物理プールをパイロット。 高回転 workflow だけラベルで流し、
runs-onの切替でロールバック可能にします。 - ミラーを正規化。 CocoaPods／SPM／npm のエンドポイントをリージョンごとに固定。方針で許す範囲でアドホック上流取得を CI から遮断します。
- 2 スプリント観察。 Set up job の p50／p95 の動きを要求し、CPU の見栄えだけで終わらせません。
- 四半期レビュー。 Xcode、Swift ツール、モノレポ肥大は cache 効率を動かすので、マトリクスを四半期で再実行します。
6. 設計書に引用できる数値
- フェーズガードレール： checkout または cache リストア単体が Set up job 所要のおおよそ 40% を超えるなら、Xcode フラグよりトポロジ（ネットワーク）を先に疑う。
- キャッシュサイズ帯： 週次 P95 tarball がおおよそ 900 MB 未満なら Actions cache。おおよそ 1.8 GB を超えるならリージョンプライベートストア計画。
- 大洋横断リストア： main 系で 1 日おおよそ 28 回を超える重いリストアは、同一大陸ミラー追加のブレークポイントになりやすい。
- リージョンプール起動条件： 遠方リージョンで checkout＋依存の中央値がおおよそ 95 秒、参照でおおよそ 38 秒の差が 2 週続くならローカル物理プールのパイロット。
- ヘッドルーム： リージョンあたり macOS 同時スロットに 20〜35% の余剰を残し、Runner アップデートと不安定リトライでスループットが潰れないようにする。
7. FAQ
shallow clone は常に Set up job を短くしますか？
大きい履歴には効きますが、サブモジュール、LFS、sparse-checkout の誤設定で打ち消されます。git フラグではなく転送バイトを測ってください。
すべてのセルフホスト Runner に永続 DerivedData ボリュームを載せるべきですか？
再現性ルールが許すときだけです。永続は反復ビルドを速くしますがクリーンルーム要件を複雑にします。リリース専用プールはより厳しいワイプ方針で分離します。
ミラーを信頼できる状態に保つには？
CI のプロモーションジョブで成果物を昇格させ、ロックファイルにチェックサムを固定し、社内バイナリの可変タグを遮断します。ミラーは読み取り中心とし、書き込みは監査します。
第 2 リージョン追加で最も壊れやすいミスは？
IAM スコープなしでシークレットをコピーし、Runner 登録トークンを共有し、両リージョンが同一上流 CDN を叩いて大洋ホップを増やすこと—コストが二重になるだけです。
8. 準備重視の macOS CI には適切なメタルで
Set up job は、コンパイル農場が動く前にディスクスループット、安定 DNS、Apple Silicon ネイティブのツールチェーンが効く局面です。Mac mini M4 はアイドル時わずか数ワット級の消費電力と、Swift Package の解決と cache 展開を同時にさばくユニファイドメモリ帯域を兼ね備え、各リージョンのエッジで常時稼働するセルフホスト Runner に合うプロファイルです。
macOS は長寿命 Runner にとって Gatekeeper、SIP、FileVault をベースラインのガードレールとして提供しつつ、CI チームが慣れた Unix 系自動化面も揃えます。マトリクスが「リージョンプールを足せ」と言ったとき、ミラーの隣に Mac mini クラスを置くのは、PR ごとに WAN 税を繰り返し払うより安くつくことが多いです。
フリート全体に広げる前に閾値を実機で証明したいなら、本番に近い GitHub Actions Runner ホストとして Mac mini M4 は手堅い出発点のひとつです。同じプレイブックを大陸横断で複製できます。
指標が示す場所に Runner を置く準備ができたら、ZoneMac を見る でマルチリージョン物理 Mac キャパシティをご確認ください。
Set up job をリポジトリの居場所に合わせて短く
GitHub Actions 型ワークロード向けマルチリージョン物理 Mac mini ノード。checkout と cache の WAN 負荷を下げ、読みやすい Apple Silicon 性能とミラー伸びしろをまとめて確保。