2026年 越境チームの Trunk／Merge Queue とマルチリージョン物理 Mac：オーケストレーションの尾部遅延とロックストームをどう潰す？キュー深度・ラベルルーティング・成果物アフィニティの閾値意思決定マトリクス（コピペ可能な GitHub Actions merge-group 断片＋FAQ）

三枚の意思決定マトリクス：キュー深度・ラベルルーティング・成果物アフィニティ

マトリクス A：Merge Queue／concurrency を締めるタイミング

マトリクス B：ラベルルーティング（マルチリージョン物理 Mac）

マトリクス C：成果物アフィニティ（閾値付き）

三枚はセットで使います。キュー深度は 誰が先に走るか、ラベルは どこで走るか、アフィニティは 走る前に何を動かすか に答えます。一角を落とすと「マージは緑だがリリースは遅い」状態に戻ります。

七ステップ Runbook

1. ベースラインを固定： PR チェック、merge_group、デフォルトへの push の計測を分離。リージョン別の Runner キュー深度とリトライ率を追う。
2. merge_group を SLA 化： 「マージ待ち時間」のビジネス上限内に収める目標時間を置き、成果物ダウンロードの割合は別行で可視化する。
3. concurrency を締める： 共有可変リソースには concurrency または「Runner あたり重いジョブは 1 つ」で、先に偽陰性を潰す。
4. 地域ラベルを足す： デフォルトブランチ検証を成果物・依存ミラーと同じリージョンに固定。越境は読み取り専用加速に留める。
5. 成果物パスを較正： 巨大な中間成果物は同一リージョンで生成→参照→ダイジェスト検証。merge_group 内のフル再アップロード連発を避ける。
6. ゲームデイ障害： 片リージョンをドレインする／スロットリングを注入し、キューのフォールバックが署名法域を壊さないか確認（権威リージョンが動けない場合の RTO を文書化）。
7. 閾値を書き残す： キュー深度／RTT／成果物サイズを ADR に落とし、スケールで暗黙ルールが消えないようにする。

引用用閾値（ADR 向け）

• Merge Queue 待ち P95 > merge_group 1 回検証の おおよそ 2 倍 → ハード購入の前に concurrency とジョブ分割を調整。
• 越境成果物 pull の RTT P95 > おおよそ 80〜120ms かつ 1 回の取得が おおよそ 5GB 超 → デフォルトは同一リージョンでビルド＋検証を揃える。
• セルフホスト物理 Mac では concurrency グループ内で 重い UI ジョブは Runner あたり 1 つ にし、シミュレータ争奪を避ける。
• 短期のキュー再編失敗率 > おおよそ 5% → ブランチ保護とドリフトを疑い、リトライ増加だけに頼らない。

コピペ可能な GitHub Actions merge_group 断片

pull_request に加えて最小限の merge_group トリガーと、セルフホスト Runner のロック嵐を抑える concurrency キーです。runs-on のラベルとリージョン名は自チームのフリートに合わせて置き換えてください。

name: ci

on:
  pull_request:
  merge_group:

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

jobs:
  validate:
    if: github.event_name == 'merge_group' || github.event_name == 'pull_request'
    runs-on: [self-hosted, macOS, region-apac]
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.merge_group.head_sha || github.event.pull_request.head.sha }}
      - name: Build and test (merge queue aware)
        run: |
          echo "Running on ${{ github.event_name }} @ ${{ github.sha }}"
          # xcodebuild / swift test / your merge validation commands

注：merge_group ではキューの一時マージコミットと同じ ref を checkout する必要があります。concurrency キーは PR 実行とマージキュー実行が誤ってキャンセルし合わないよう調整し、必要ならワークフローを分割してください。GitHub の merge_group の意味は進化し得るため、本番前に捨てリポジトリで E2E 検証してください。

FAQ

merge_group と pull_request は同じ job 定義を共有できますか？

ステップは共有可能ですが、明示的な if／ref 処理を残してください。キュー再編で SHA を取り違えると「ランダム赤」になります。

物理 Mac プールと GitHub ホスト Runner は混在させるべき？

可能ですがラベルは排他的にし文書化します。成果物とキャッシュのパス契約を揃え、ファイルシステム構成が異なる Runner 階級をまたぐと concurrency グループが壊れやすいです。

ロックストーム：まずキューを空にする？ジョブを止める？

先に並列度を下げロック粒度を細かくします。キューをドレインすると順序付きマージの意図が失われ、通常は制御面インシデント向けです。

Mac mini でキューを安定運用する

Trunk と Merge Queue はマージの正しさを CI に押し込み、物理 Mac Runner は実際の Xcode とシミュレータ負荷を担います。合わせると 安定性と I/O の一貫性 がピーク GHz より重要になります。Apple Silicon の Mac mini は ユニファイドメモリの帯域 とおおよそ 待機 4W 前後 の消費電力を両立し、リージョナル Runner を夜間もウォームに保ちやすく、多くの x86 タワーで熱変動のたびにロック TTL を振り直す負担を抑えられます。

macOS は開発者端末と同じ根っこを持ち、「ローカルは通るのに CI だけフレーク」という隙を狭めます。Gatekeeper・SIP・FileVault により、典型的な Windows ビルドファームよりセッションとディスク状態を監査で説明しやすいです。Runner を成果物・ミラーに同居させ、ラベルと concurrency でロック境界を強制する——静かで省電力かつ挙動が読みやすいハードウェアで merge_group を回したいなら、Mac mini M4 は価格性能の出発点として依然強力です。

「merge_group がたまに通る」から「キュー深度とアフィニティ閾値を信頼できる」へ進むなら、今すぐ Mac mini を手元に置き、クラウド枠との押し合いだけで終わらせずこのマトリクスを実シリコンで検証してください。