2026年 越境チームの「インタラクティブ開発」と自己ホスト macOS Runner の同区共プール：マルチリージョン物理 Mac でキュー飢餓とリソース争奪をどう避ける？——地域ノード選定とセッション／CI 区分しきい値の意思決定マトリクス（コピペ可能なパラメータと FAQ）

1. 三つの痛点：飢餓の正体は「Mac が足りない」だけではない

1. 二層のキュー。 GitHub Actions などは並列スロットまたはオンラインで runs-on に合う Runner の有無のどちらかで詰まります。オフライン・誤タグ・不一致は偽の飢餓を生み、紙上は余裕でもジョブだけ滞留します。
2. インタラクティブと CI は同じキャッシュを奪い合う。 リモート IDE の索引、シミュレータ、xcodebuild による Derived Data 書き込みが重なると NVMe 遅延が跳ね、CI の壁時計と SSH の応答の両方を悪化させます。
3. タイムゾーン間の公平性。 地域やチーム単位の concurrency と重いジョブの時間帯設計がないと、一地域のプッシュ嵐がグローバルスロットを占有し、GHz の問題ではなくスケジューリングの問題になります。

2. マトリクス A：ワークロード種別×プーリング戦略

どのワークロードを同一物理機に載せてよいか、どれを別プールまたは別ホストに分けるかを決めます。

3. マトリクス B：マルチリージョンのアフィニティとノード選定

Git に合わせると開発者に合わせるはしばしば衝突します。下表を一次のトレードとして使います。

実務ルール： 地理ごとに少なくとも zone:<region> ラベルを出し、夜間フルスイートなどグローバルな重いジョブは pool:heavy と専用の concurrency グループへ回し、地域の PR プールを飢餓させないようにします。

4. マトリクス C：セッション／CI 区分のしきい値（出発点——負荷試験で調整）

5. コピペ可能なパラメータ（Runner ラベル＋ワークフロー骨格）

GitHub Actions 系の命名例です。利用中の CI のラベル、concurrency グループ、自己ホスト Runner 設定に読み替えてください。

5.1 Runner に登録するラベル

zone:apac
pool:ci-standard
os:macos
arch:arm64
capacity:shared

5.2 ワークフロー：プール選択＋ concurrency（抜粋）

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: [self-hosted, macOS, ARM64, zone-apac, pool-ci-standard]
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

5.3 環境変数（挙動用。秘密情報ではない）

# 例：CI でインデクサ負荷を抑える
export COMPILER_INDEX_STORE_ENABLE=NO

# Derived Data を CI 専用ボリュームへ
export DERIVED_DATA_PATH=/Volumes/ci-derived/PR-${{ github.run_id }}

署名用の秘密は共有プールのデフォルトに載せず、スコープされた environment かリリース専用 Runner に閉じます。

6. 七ステップ実装 Runbook

1. 負荷のヒートマップ化： リポジトリとブランチごとに、日次ジョブ数、ピーク時間帯、所要時間をチャート化する。
2. ラベル文法の凍結： zone／pool／capacity を RFC に文書化し、私用エイリアスを禁止する。
3. インタラクティブと CI の分割： 最低でもボリューム分離。インタラクティブノードは CI ラベルを外してもよい。
4. concurrency グループと timeout： PR とデフォルトブランチでグループを分け、長尺タスクは別ワークフローとより長い timeout-minutes を付ける。
5. 四週間の観測： キュー P95、Runner オフライン率、ジョブ失敗率、エンジニア RTT をアラートに載せる。
6. 四半期スケール： 1 台のスペックアップより、地域内スロットを増やす方を優先する。
7. ロールバックの文書化： ラベル巻き戻し、ワークフロー kill switch、緊急リリース用ホスト引き継ぎのオンコールを明記する。

7. 引用用数値とチェックリスト（SLO と調達向け）

• 並列の出発点： 本番プールではホストあたり CI ジョブ 1。週次で見直してから 2 を試す。
• キューアラート： 地域の待ち時間P95 > 15 分が三連続インターバルで発火したら容量レビュー。
• インタラクティブ RTT： 主要な Remote SSH 経路で片道 < 120 msを目安（許容は組織で調整）。これを超えるなら、CI 用 Mac を増やす前に近いサンドボックスを足す。
• 四半期監査： 実機とラベルを突合し、退役ホストがワークフローに残らないようにする。

8. FAQ

同じリージョンのプーリングは、Remote SSH と CI を同一物理 Mac に載せる必要がありますか？

いいえ。プーリングは地域と FinOps の境界です。本番では interactive と ci のサブプール（必要ならさらに分割）を使い、同一ホストで Xcode とコンパイルがユニファイドメモリとディスク I/O を奪い合わないようにします。

キュー飢餓のとき、最初に何を見ますか？

オーケストレーションのキュー深度、Runner スロット利用率、インタラクティブの RTT／切断を同時に。キューが深いのにスロットが空いているのは、だいたいラベルのずれかオフライン Runner です。

区分マトリクスで「ホストあたり最大並列ジョブ数」はどう選びますか？

まず 1 ジョブでピークメモリと Derived Data サイズを検証し、2 を試す。OOM、コンパイルのフレーク、シミュレータの不安定化が出たら戻す。ユニファイドメモリでは、紙のコア数より並列を絞る方が勝つことが多いです。

マルチリージョン：Runner は Git のリージョンに合わせるべき？ 開発者のリージョンに合わせるべき？

CI は通常 Git・成果物・ミラーに追随。インタラクティブな Remote SSH は毎日打鍵するエンジニアに追随。衝突するときはラベルとプールで分割し、無理に共有ホストに詰めません。

大容量 RAM の 1 台でマルチホスト区分を代替できますか？

メモリは助けになりますが、ディスク書き込み争奪とシミュレータのフレークはインタラクティブと CI を同一障害領域に結びつけます。厳格なラベル付きで水平に Mac を増やす方が、限界まで載せた単一タワーに勝ちがちです。

自己ホスト Runner がフラップするとき、偽の飢餓を止めるには？

Runner プロセスを自動再起動で監督し、ハートビートを監視し、重要プールにN+1 の冗長を確保。ジョブが溜まっているのにオンライン Runner がゼロなら、並列を上げる前に可用性を直します。

Merge Queue／トランク圧力とはどう相互作用しますか？

Merge Queue はデフォルトブランチに負荷を集中させます。merge-group 用に別プールまたは時間帯を用意し、既存のトランク方針と並列度を揃えて PR プールが飢餓しないようにします。