2026年 iOS/macOS CI リソースプール選定：単台高配の専有リモート Mac vs 複数台の専有ノード——並行性、キュー、SSH セッション安定性と TCO の意思決定マトリクス＋FAQ
macOS ビルドをすべて専有（マルチテナント VM のノイジーネイバーなし）で回す前提では、本質の分岐は「クラウドかオンプレか」より1 台の強い専用 Macか複数の小さめ専用 Macかに置き換わります。本稿では並行性・キュー挙動・長寿命 SSH 運用・総所有コスト（TCO）を、アーキレビューに貼れるマトリクスとして整理します。
1. TL;DR——多くのチームがどう決めるか
単台の高配専有 Macを選ぶのは、運用ストーリーを単純にしたいときです。キーチェーン境界が 1 つ、Derived Data 方針が 1 本、ディスクレイアウトが読みやすく、SSH エンドポイントの強化対象も少ない——ただし同一ホスト上の競合による直列化は許容するか、その箱上で並列ジョブ数を厳しくキャップする覚悟が必要です。
複数の専有ノードは、独立したキュー列（リリース用とナイトリー用など）、署名アイデンティティの分離、1 台障害時の爆発半径抑制が欲しいときに効きます。その代わりパッチ適用、Runner 登録、SSH／セッション監視が N 倍になります。
ノード間でツールチェーンのレイアウトを再現したい場合は、版固定スクリプトや IaC、あるいは Nix 系の宣言的プロビジョニングで「環境一貫」を先に決めてから台数を増やすのが安全です。ピーク時の待ち時間とキャパシティの足し方については 2026年 iOS CI ピーク対策：Mac mini レンタルがビルド自動化に最適な理由 が補助線になります。
2. 定義：Apple 制約下の「リソースプール」
本稿のリソースプールとは、CI 用に使う物理的に専有された macOS ホストの集合です。各ジョブはフルメタル（または自前の固定分割方針）を前提とし、弾力的なマルチテナント・クラウドスライスは対象外です。比較軸は次のとおりです。
- シングルノード型：ユニファイドメモリと高速 SSD を積んだ 1 台のリモート Mac に、意図した並列上限で Runner を複数載せる構成。
- マルチノード型：N 台の Mac それぞれに、推奨どおりマシンあたり 1 つの Runner サービス主体を載せ、レーン（リリース／PR／UI テストなど）で束ねる構成。
3. 並行性：スループットとテールレイテンシ
Xcode 系ワークロードはメモリ帯域、ディスク I/O、熱設計に裏打ちされた持続クロックに敏感です。1 台の大型 Mac で parallel を上げると、平均スループットはしばらく改善しますが、共有キャッシュと I/O が飽和するとテールが伸び（UI テストのタイムアウト、Simulator の不安定、codesign の停滞など）、体感品質が落ちます。
複数の専有 Mac に分けると、ノードあたりのジョブ性能はより予測しやすくなり、組織全体のスループットはレーンの和に近づきます——代わりにキャッシュとメンテナンスが重複します。Derived Data、モジュールキャッシュ、ディスク予算はノードごとの runbook です。1 台の fat Mac でやっていたコンパイルキャッシュ衛生を、兄弟ノードすべてで揃えないと「runner-2 だけ通る」ドリフトのデバッグに時間を溶かします。
4. キュー：ジョブがどこで待つか
キューは二階にあります。Forge 側（GitHub／GitLab の待ち行列の深さ）とRunner 側（アイドルワーカー）。単一の fat Mac で --jobs 1 のように厳しくすると、FIFO 一本で運用は単純ですが PR が並びます。複数 Mac はラベル付き Runner が増え、需要とレーンが噛み合えば待ちは短くなります——が、ワークフロー YAML が実際にそのラベルを指していなければ意味がありません。
| シグナル | 単台・高配専有 Mac | 複数台・専有 Mac |
|---|---|---|
| PR の待ち時間スパイク | 多くは Runner 占有。キャップ調整、ジョブ分割、2 台目が手 | ラベル不一致でアイドル Runner に流れていないことが多い |
| リリースビルドの飢餓 | CI YAML で優先度キュー／並行グループが必要 | リリース専用ラベルをマシン単位で切ると効く |
| 可観測性 | ホスト 1 台のダッシュボードで相関が取りやすい | ノード横断比較にはログ集約が欲しい |
5. SSH セッションの安定性：1 エンドポイントか N か
運用者はデバッグやアドホックの xcodebuild、復旧のために今も SSH に入ります。単一の主要エンドポイントは証明書と known_hosts の散らばりを減らしますが、障害時はチーム全体が詰まります。複数は耐性は上がる一方、アイドル切断、NAT、keepalive 問題が N 倍になります。
プール形状に依らないベースライン：ServerAliveInterval、壊れやすい回線での長いパイプの避け方、対話 SSH と CI Runner アカウントの分離。踏み台やバスチオンでは鍵ローテーションと最小権限を runbook 化しておくと、エンドポイントが増えたときの負債を抑えられます。マルチノードで署名境界を分ける実務は iOS 証明書と署名を安全に管理するには？独占物理 Mac mini による 2026 年のベストプラクティス を併読ください。
| 症状 | 疑い | まずやること |
|---|---|---|
| コマンド途中で固まる | ネットワークのアイドル切断、DNS の停滞 | keepalive を有効化；ssh -vvv で再現 |
| 重い I/O 中に落ちる | ディスク圧迫、サーマルスロットル | diskutil apfs list で空き容量；並列ジョブを減らす |
| ノード A では通るが B で失敗 | ドリフト（Xcode パッチ、Ruby、CocoaPods） | ツール版をピン留め；ノードごとにヘルスチェックを自動化 |
6. TCO 意思決定マトリクス（設備費、工数、リスク）
TCO はカタログ価格だけではありません。初期構築時間、署名資産のローテーション、監視、開発者のキュー待ちコストを同じ表に載せます。
| 次元 | 単台・高配専有 Mac | 複数台・専有 Mac |
|---|---|---|
| ハードの CAPEX／リース | 台数が少ない；筐体と PSU も少なめになりがち | N にほぼ比例；まとめ買い割引の余地 |
| 運用工数（パッチ、Xcode 更新） | 手順が 1 本；ダウンタイム窓も集約 | N 回繰り返すか、構成管理に投資 |
| セキュリティ境界 | キーチェーン面が 1 つ；監査説明が単純 | アイデンティティ分割は可能だが証明書とトークンが増える |
| リスク／爆発半径 | 1 台障害で全レーンが止まる | 部分キャパシティが残ることが多い |
| 開発者のキューコスト | キャップと優先度設計がないとスパイクしやすい | レーンとトラフィックが合えば下がる；合わなければアイドル浪費 |
7. FAQ
1 台の Mac に Runner サービスを 2 つ載せてよいか
技術的には可能ですが、CPU・メモリ・ディスク予算をサービスアカウント単位で切らない限り競合が戻ります。デバッグの予測可能性のため、多くのチームはマシンあたり 1 Runner サービスを推奨します。
マルチノードがすぐ勝つ局面は
並列リリース列車、アプリや子会社ごとの署名の分離、環境ごとのネットワークセグメント強制など、コンプライアンスや運用レーンが最初から分かれているときです。
RAM を厚くすれば単台大型 Mac は常に正しいか
Swift のコンパイルグラフやSimulator の扇展開には効きますが、キューが外部サービス待ちで支配的ならコアを積んでも改善しません。先にレーン分割やテスト最適化を検討してください。
TCO を公平に比較するには
開発者 1 人あたり週あたりの短縮分数（キュー改善）と、ホストが単純か複製かによるオンコール時間を同じ試算表に載せます。シニア 1 人が CI 待ちするコストは、2 台目 Mac より高いことも珍しくありません。
この意思決定を支える Mac mini／macOS の位置づけ
Apple 専用パイプラインには macOS 上の実 Xcode、codesign、公証が不可欠です。Apple Silicon のユニファイドメモリは、大規模 Swift プロジェクトや並列 Simulator を、DRAM 不足でスラッシングしがちな別構成より安定させやすい材料になります。macOS は ネイティブ Unix ツールチェーン（Homebrew、SSH、シェル）と Runner の実行モデルが素直に噛み合い、Gatekeeper、SIP、FileVault により無人ノードの説明責任も取りやすい側面があります。
本稿の並列キャップ、SSH ベースライン、キャッシュルートを runbook に落とすなら、Mac mini M4 は 2026 年時点でも現実的な足場です。待機電力を抑えつつ省スペースで、持続的な CI 負荷でも挙動が読みやすいクラスです。まずは1 台の強い専有ノードでキュー指標を取り、必要性が数値で立ったところだけ2 台目の専有 Macを足す——その順序が TCO と運用の両方で扱いやすいことが多いです。詳細は SSHMac のトップページ でプランとスペックを確認し、設計レビューに持ち込んでください。