2026 マルチリージョンのリモート Mac ビルドプールと Thunderbolt 5：2台目の追加判断、トポロジ、FinOps

RAM やディスクを足してもキューが解消するとは限らない理由

リモートの Apple Silicon 上のビルドクラスタには、三つの「一見ローカル」の問題が残ります。

1. 構造的な並列性 は、統一メモリ帯域に当たります。並行デプロイ、多数のシミュレータ、重いメディア基盤が一緒に奪い合います。ディスクを大きくしても、その競合を直列化できません。
2. Git やレジストリへの太いネットパス は、ビルダーがレジストリと海を挟むと壁時計の支配的因子になります。同じ不適切なトポロジ上で CPU だけ積めば、より速いアイドルになります。
3. スキームをまたぐジョブ同士の干渉 は、近所のVMよりも、共有ホスト上の共有キャッシュから来ることが多いです。隔離とキュー方針が、新しいチップ購入に勝つこともあります。

二台化の前の四択：2台分を買う前の意思決定表

分けてチャートにするシグナル：CPU、GPU/メディア、ディスク、ネット

少なくともリリースに合わせた2週間の窓で。CPU、メモリ圧力、書き込みスループット、太い接続先へのネットを1本の時系列に載せてください。リンカーやインデクサへの短いスパイクと、多核が長く同時に熱を出すパターンは違います。後者が、上位ティアや2ノード目の根拠になります。

Thunderbolt 5（または同類の局所リンク）が本質的になる条件

極めて高い Gbps というマーケ数字は、ワークロードの適合なしには意味を持ちません。2台がオブジェクトストアから供給され、可変の局所状態を共有しないなら、2台目+きちんとしたキャッシュで足りることが多いです。ストレージ方針を同じ所に揃えられないせいで、週何時間の十GB級の rsync を繰り返すなら、高帯域VPNより物理の高速導線が上回る日が来ます。TB リンクは、壊れた成果物トポロジの治療薬であって、正しい都市のレジストリの代替ではありません。

太い道を先に同じ所へ：6リージョンと FinOps

人、リポ、レジストリ、テスト消費者の位置づけを図示します。当方の AI支援の選択マトリクス への導線が入力の重み付けに、リージョン別料金ガイド がハードを足す前の用語揃えに使えます。

ベースラインとピーク帯：台帳を正しく

飢えてはいけないキューには、月枠か四半期枠のベースライン枠を、リリース山用には日枠・週枠のアドオンを。ピーク承認は「雰囲気」ではなくP95待ち時間など、数のトリガーに固結してください。公表価格は、同一RAM、同一ストレージ階、ベアメタル専有か共有、イグレス仮定まで揃えた一枚で比較します。

戻し可能なプール展開：6段階

1. エビデンスの束を凍らせる（分位点と「ディスクだけではない理由」という物語付きで）。
2. 財務上可能なら、レジストリとキャッシュをビルダーと同じリージョンへ 置き直す。
3. 長い1本のジョブが小さなPRを塞がないよう、キューをシャード（インタラクティブ/CI/リリース）し、ランナーラベルで分ける。
4. 2ノード目のコールドスタートを定義：イメージ供給元、初回ビルドの許容時間、1ノードへの戻し方。
5. ホスト間の週移動バイト量と、同期に燃やすエンジニア時間のリンク案を採点する。
6. 1、2、4週目にアイドルと、トリガーが下がったらピーク機の返却を点検する。

# pool-baseline: 月/四半期； pool-peak: 日/週 + チケットID
# label = region + role + xcode_major
# 2本目のNIC/ケーブル予算の前に、太い道のコロケーション
# ロールバック: pool-bをドレイン、15分で無効化、ランナーは1台へ

レビュー向けの三事実（文脈付きで引用）

• 多くのAPAC拠点と米国西部の 大陸横断のRTT は、150–220ms RTT 帯に入ることがしばしばあります。契約書の数字は、本文ではなく自社の痕跡で補え。それでも、2026年も「同じ都市のレジストリ」が響くのは、そのオーダー感からです。
• 公表リストにおける 短期と長期のレンタル損益分岐 は、月あたりの 連続して高利用な日数が数日程度 付近に乗ることが多い、という程度の話です。実支払いの日額と月額で再計算してください。
• 忙しい Xcode+シミュレータ対では、クリーン方針なしに 1日当たり数百GB の ディスク書き込み になりうる—容量計画には、科目だけでなくオーナー名を。

機械を分けるのではなくキューだけ分けるとき：M4 と M4 Pro

2台目の前に、統一メモリの大きい M4 Pro の1台で、最悪の並列スライスを片付けられないか確認します。Pro は「少し速いMHz」ではなく、1台のホスト上で複数シミュレータ、重いメディアエンコード、大きな Swift グラフを、スワップを避けて同時に扱う正攻法になることが多いです。既にCIと手元作業を別アカウントで隔離しているのにディスクかキャッシュで衝突する痕跡なら、小さめのマシンが2台の方が1台の大チップに勝てます—ただし成果物とレジストリの話が健全なときに限ります。悪い順序は、2台M4を買ってから、五GBのコンテナ層を、レジストリを海外のままにして何時間も二重引きし続けた、です。

アドホック端末と安易なトンネルが、この用途で不利な理由

ラップトップのテザリング、家庭アップリンク、CGNATは、多キュー・リリース路線向けの不安定土台です。「安い余剰VM」は分散を、エンジニア時間のばらつきに移動させます。 6拠点の置き方が分かり、財務に出せるレンタル算式 のある管理プールの方が、バラのMacの棚を抱えるより背負いやすい、ということが多いです。ビルドプールを本番扱いするチームにとっては、 MACCOME のクラウド Mac の方が、その運用モデルに乗りやすい、ということが多いです。リージョンは明確、専有の Apple Silicon、経理隣の条件が置ける—Thunderbolt とイーサの問いを、根拠で押さえられます。

専用2台目の導入初週の運用ルール

先にキューを分けないまま2倍化しないでください。そうでないと、2台のホスト上で、同じ競合するキャッシュ経路のコピーになります。1日当たりの移動バイト数を示す前に、接続導線を足さないでください。最後に当番とロールバックを定義：2本目のランナー群の無効化は、1ノードの安定状態へ、1営業時間以内。これらが、プールを学術的実験ではなくサービスにするガードレールです。