BuildkiteはコントロールプレーンをSaaSに置き、ジョブ実行は自前のbuildkite-agentに任せる二層構造です。macOS/iOS向けパイプラインでは、そのエージェントを「常時オンの社内Mac」ではなく按日課金のクラウドMacへ載せる選択が増えています。本稿では、Elastic CI Stackの増減と突発ビルド、Artifactの保持方針、キュー待ちのSLOを一つの表に落とし込み、意思決定のFAQとして整理します。
Elastic Stackと「突発ビルド」の弾力
按日クラウドMacは、リリース直前やホットフィックスのようにジョブが短期間だけ跳ね上がる局面で効きます。Buildkite側ではqueueとtagsを分け、バースト用キューだけエージェント台数をAuto Scalingで伸ばすのが定石です。常時ジョブ（lintや単体テスト）は別キューに固定し、課金対象のApple Siliconノードを「本当に必要なステージ」に閉じ込めます。
# launchd または CI専用ユーザーのログイン項目から常駐させる例 export BUILDKITE_AGENT_TAGS="queue=mac-burst,cloud=daily" buildkite-agent start --disconnect-after-job
Artifact保持：Buildkite標準とオブジェクトストレージ
IPAやdSYM、テストレポートはビルドごとに肥大化します。Buildkite組み込みのArtifactに任せるか、ビルド完了後にS3互換へアップロードしてメタデータだけBuildkiteに残すかは、保持日数とエグレス単価のトレードオフです。コンプラ上「組織外にバイナリを置けない」場合は標準Artifact＋短いTTL、公開配布が前提なら署名URL付きの外部バケットが扱いやすいです。
キューSLOの意思決定マトリクス
「待てる上限」を数値化し、超えたらキューではなくコスト側に打ち手を打つ合意を先に作ります。併走上限やマネージドCIの待ち行列と比較する切り口は、たとえば2026年・短周期iOSビルドの代替案：CircleCIのクラウドmacOSと日単位クラウドMacのセルフホストRunner——プライベート依存、並行上限、キューSLOの意思決定マトリクスFAQと近いです。按日Runnerの凭証注入とキャッシュキー設計は、2026年短周期 Expo EAS iOS ビルドキュー圧：`eas build --local` と按日クラウド Mac Runner の凭証注入・キャッシュキー、分パック対按週運用の意思決定マトリクス FAQの整理とも噛み合わせて読むと実装が早いです。
| シグナル | まず伸ばすもの | 次に見直すもの |
|---|---|---|
| p95キュー待ちがSLO超過 | バーストキュー専用エージェントの最小台数 | ジョブ粒度（分割しすぎ／結合しすぎ） |
| Artifact転送がボトルネック | 近傍リージョンのストレージエンドポイント | 成果物の圧縮・差分アップロード |
| エージェント再接続ループ | ネットワーク安定性・プロキシ除外リスト | トークン／ACLのローテーション手順 |
| 按日課金が予算上限に達しそう | 夜間バッチのLinuxオフロード比率 | macOS必須ステージのキュー優先度 |
按日クラウドMacなら、Buildkiteの弾力設計が締まる
BuildkiteのmacOSジョブは、ネイティブのXcode・シミュレータ・コード署名チェーンが揃ったApple Silicon上でこそ意味があります。Mac mini M4クラスはユニファイドメモリでリンカーとコンパイラのピークを吸収しやすく、按日ノードを増減させても体感のビルド時間がぶれにくいです。待機電力が約4W程度と低いため、常時1台をキープしつつバースト時だけ追加するハイブリッド運用とも相性がよいです。
macOSは長期無人運用でもクラッシュ率が低く、GatekeeperやSIP、FileVaultを組み合わせればビルドノードとしてのセキュリティ境界も説明しやすくなります。同価格帯の汎用PCと比べても静音・省スペースでラックを圧迫しない点は、クラウド事業者側の設備コストにも効き、結果として按日単価に反映されやすい構造です。
突発ビルドに耐えるキュー設計を、実機の上で試したいチームには、VPSSparkのクラウドMac mini M4が現実的な出発点です——プランを今すぐ確認し、エージェント台数とArtifactポリシーを本番に近い負荷で検証してください。