Mac mini を「どれでも同じビルド VM」のように扱うプラットフォームチームは、いまだに本質を見落としがちです。キュー時間はサーバー監視の1グラフではなく、プロダクト指標です。本稿では、待機時間のパーセンタイルの測り方、スケジューラの誤設定と真のキャパシティ不足の切り分け、ラベル調整よりもレンタルで Apple Silicon M4 を1台足す方が安くつく局面の見極め方を、比較表・7ステップのサイジング手順・ダッシュボードに貼れる具体的な数値目標とともに整理します。
ランナー接続の土台から整えたい場合は、まず Mac mini M4 上のセルフホスト GitHub Actions で登録フローとセキュリティの前提を固めてください。失敗が「容量不足」ではなく再実行の連鎖に見えるときは、ハードウェアを増やす前に 不安定テストの隔離と再試行バジェット を読み、メトリクスを汚染していないか確認します。
「Mac が足りない」と誤読されやすいサイン
- 再試行の嵐： 不安定な1スイートだけが、グリーン時の 3倍 近い壁時計を占有し、実スループット需要を増やさずにキュー深度だけを膨らませます。
- ラベル飢餓：
macos-xcode15-onlyに固定されたジョブは待機し続け、汎用ランナーが空いていてもオーケストレータが適格な仕事をバックフィルしません。 - モノリシックパイプライン： 巨大ワークフローがランナーを 45〜70 分占有すると、キューに2本の PR しかなくても「障害」のように感じられます。
- リージョン横断レイテンシ： 遠方のオブジェクトストアから成果物を引く時間が「ビルド時間」の大半を占めることがあります。バケットが us-east-1 固定なら、シンガポールにノードを足しただけではエッジキャッシングなしでは解決しません。
シグナルマトリクス：キューの痛みと想定根本原因
週次のキャパシティレビューで使う表です。行はメトリクスダッシュボードが示す主症状、列は「もう1台の承認」を出す前に最初に引く調査スレッドです。財務やクラウド賃借の稟議に回す前に、ここで枝刈りしてください。
| 主な症状 | ランナー CPU 平均 | 想定される根本原因 | 最初の一手 |
|---|---|---|---|
| p95 待機が持続的に 15 分超 | > 78% | 実キャパシティ不足 | ノード追加、またはワークロード種別でプール分割 |
| p95 待機は高いがスパイクのみ | < 40% | スケジューラ／ラベル不整合 | ジョブ→ランナー親和ルールの監査 |
| キュー深度が時間帯で周期的に変動 | 55〜70% | タイムゾーン型のコミット集中 | 重いジョブの時間シフト、またはバースト賃借 |
| ディスクレイテンシ警告 | 任意 | DerivedData または Docker レイヤの churn | キャッシュマウント、薄いイメージ、NVMe 衛生 |
キャパシティの罠： 平均利用率が 32% のまま4台目の Mac を買うのは、多くの場合オーケストレータが過度に厳しい同時実行上限のせいで空きスロットを見せていないだけで、Apple Silicon が遅いからではありません。
意思決定チェックリスト：チューニング・シャーディング・投資
| こちらが真なら… | …こちらも真なら | 判断 |
|---|---|---|
| フレーク率がジョブの 8% 超 | 夜間の再実行後にキューが伸びる | ハードウェア拡張の前にテスト隔離 |
| 単一リポがランナー時間の 40% 超を消費 | 他チームが毎週 SLO を落とす | プロジェクト専用レーン＋プール溢れ用 |
| アジアの PR が最も待つ | ランナーが米国のみ | HK／JP／SG／KR 近傍の Mac ノード追加 |
| ジョブ中央値が 12 分未満 | p95 が 38 分超 | テスト・署名・ネットワークのテール調査 |
防御可能な待機時間 SLO までの7ステップ
GitHub Actions でも Buildkite 型キューでも、エンキュー・開始・終了のタイムスタンプが取れれば同じ計算ができます。手順はオーケストレータ非依存で、週次レビューにそのまま組み込めます。
- SLO を平文で定義： 例：「営業時間内の macOS CI ジョブの 90% は 8 分以内に開始する」。
- 待機＝開始時刻−エンキュー時刻を計測： 手動承認によるキュー停止をプロダクトが同じ予算に含めるかは事前に決める。
- ホストあたり同時実行ジョブ数を追跡： 平均だけでなく最大値をプロット。バーストがユーザー体感の遅さを作る。
- ワークフロー種別でセグメント： UI テスト、ユニット、リリースビルドは SLO と同時実行上限を分ける。
- 週次 p50／p95／p99 を保存： 予算季の前に季節性を見るため 13 週ローリングを推奨。
- 四半期ごとに「ノード1台減らし」ドリル： 1台外すと SLO 違反なら、ヘッドルームはすでに薄すぎる。
- エスカレーションを文書化： p95 が目標の 2倍 を 3 営業日連続で超えたら、グラフ付きでキャパチケを自動起票。
リージョン別 Mac ノードが数式を変える理由
キュー深度は CPU だけではありません。東アジアの開発者が太平洋越しに数ギガバイトのキャッシュを引くと、米国のランナーが空いていても「CI が遅い」という体感が膨らみます。香港・日本・韓国・シンガポール・米国に Mac mini M4 を置くと、SSH セッション、成果物同期、対話デバッグの往復が短くなります。ランナーを大洋横断の clone から毎ホップ 18〜35 ms 削れるケースは珍しくありません。
NodeMac は リージョン別プラン を公開しており、「米国本番＋APAC バースト」を二重にハードを買わずにモデル化できます。その配置とあわせ、署名やシミュレータ問題で GUI が要るときの SSH／VNC パターンは ヘルプドキュメント の運用チェックリストと併読すると安全です。
スループットのガードレール：信頼できる時間あたりジョブ数
待機が健全になったら、持続可能なスループットを裏取りします。Mac mini M4 クラスで混合パイプラインを回す場合、中央値が 18 分なら、フル稼働の重いジョブは時間あたり 9〜11 本が現実的な上限に収まりがちです。メンテ窓、キャッシュコールド、コード署名サーバのジッターで数式はすぐ破綻します。SwiftLint だけなど軽量ジョブは時間あたり本数を上げられますが、財務が人数×マーケ数字で掛け算しないよう社内ランブックに前提を書いておきます。
| ワークロード像 | ジョブ長の中央値 | 実務上の上限（台あたり時間当たり本数） |
|---|---|---|
| Xcode ビルド＋ユニット | 14〜22 分 | 3〜4 |
| UI＋シミュレータマトリクス | 35〜55 分 | 1〜2 |
| Lint／型チェックのみ | 3〜6 分 | 8〜12 |
計測スループットがモデル容量の 15% 下に張り付き、CPU が飽和していないなら、追加マシン承認の前に I/O 競合や外部サービスのレート制限を疑います。逆にモデルと実測が一致するのに SLO が落ちるなら、スケジューリングか公平性の問題であり、1チップの高速化だけでは直りません。
よくある質問
キュー深度の平均だけで調達を計画してよい？
いいえ。平均はテールリスクを隠します。プロダクトとセキュリティレビューは最悪の開発者体験を気にします。平均深度に加え、p95 待機と、SLO を超えたジョブ数をチーム別にバケット化してください。
AI エージェントのワークロードは人間の CI と同じ Mac プールでよい？
ガードレールなしでは通常避けます。エージェントはバースト的なコンパイルグラフを生み、共有キューにとっては DDoS のように見えます。別ラベルとクレジット上限で隔離するか、人間の PR 待機を守るために専用のレンタルノードを割り当てます。
2026年の Apple プラットフォーム CI において Mac mini M4 は依然として現実的な構成単位です。Apple Silicon は CPU・GPU・Neural Engine を省電力にまとめ、ネイティブ macOS は Xcode とシミュレータ向けの脆い仮想化を避けられ、時間分割された macOS ホストより 2〜3 並列の重いジョブで安定した性能が欲しいときに金属の専有が効きます。NodeMac は香港・日本・韓国・シンガポール・米国で SSH と VNC 付きの物理 Mac mini を提供し、寝るノート PCではなくデータセンターノードのようにフリートを扱えます。オンデマンド賃借はピーク週のバーストを Opex に置き換えつつ、キュー SLO をエンジニアリング側でコントロールし続けられます。