2026年版 リモート Mac で GitHub Actions macOS セルフホスト Runner：シンガポール・日本・韓国・香港・米国東部・西部と M4 16GB・24GB（DerivedData キャッシュ、並列シート、日額—月額 TCO）

Windows や Linux を主戦場としつつ iOS / macOS パイプラインを出荷する開発チームにとって、2026 年の分岐点は定番です。GitHub ホスト型 macOS Runner（分課金・エフェメラル環境）の請求とキューを受け入れるか、専用リモート Mac mini に セルフホスト Runner を置いて永続ディスクと月額の見通しを得るか。本記事は後者――GitHub Actions セルフホスト macOS Runner――にフォーカスし、OpenClaw など常駐エージェント運用そのものではありません。ホスト型対セルフホストの経済性、6 リージョン選定、M4 の実メモリと並列シート、DerivedData とディスク設計、label によるシャーディング、登録ハウツー、日額から月額までの総コスト試算と FAQ を通して整理します。プランは 料金ページ（Mac mini） で比較し、Runner と SSH は ヘルプセンター を参照してください。インフラの外側で自動化エージェントも走らせる場合は OpenClaw リモート Mac（米東・米西・M4）実践ガイド を併読できますが、この本文の主人公はずっと CI/CD 側に置いたままです。

1) ホスト型 macOS Runner とリモート Mac セルフホスト――分単位請求・待ち行列・裸金属へ寄せるタイミング

GitHub は macOS ホスト型 Runner を Actions の経過時間に応じて課金します。単価と無料分は GitHub 公式ドキュメント の最新版が正で、ホストランナーの価格改定も 2026 年経済環境だけでなくプロダクト都合でも動くため、試算には必ず直近単価を使ってください。クリーン環境でのゼロオペ開始は強力で、まれな Archive だけ欲しいワークフローなら妥当です。その一方で、DerivedData や SwiftPM キャッシュがジョブをまたいで当たりにくい、日中集中でキュータイムだけが増える、「分」の消費量がそのまま予算になる――といった制約もセットです。

Nuvcloud の M4 Mac mini のような専用裸金属におけるセルフホスト Runner は、「固定ノード」「永続 SSD」という買い物です。actions-runner を launchd 配下へ置き、~/Library/Developer/Xcode/DerivedData を複数 PR で再利用すると、ホストの冷スタートと比べて増分ビルドの壁時計だけが効きやすくなります（差分は単一ソース・ツールチェーン構成に強く依存するため以下の表や例は SLA ではなくテンプレだと読んでください）。

簡単な 12 ヶ月 TCO メモ： ホスト側の単価を P 円／分・月間利用を M 分として年間はだいたい 12×M×P。リモート月額（帯域やサポート込み）は R として年間は 12×R。M×P が R を上回りキャッシュヒットまで含むならセルフを真剣に、M が小さく散発だけならホストへ残すか、まず短期レンタルでワークフロー検証してから縛り込むのが安全です。

2026 年によく効く中庸は、「軽めの Lint／ユニットは Linux のホスト型で吸う」「重量級の xcodebuild と Archive と公証だけを単一または少数のセルフホスト Mac に寄せる」です。ワークフローの README に境界を明示しておけば、どこかでリファクタしたエンジニアがヘビー処理を気づかずホスト macOS に戻す事故を抑制できます。

2) シンガポール・日本・韓国・香港・米国東海岸・西海岸――Git・レジストリ・成果物に近く置く

Nuvcloud はアジア太平洋で シンガポール・日本・韓国・香港、北米では 米国東部・西部（海岸）の配置を SKU 単位で提供します（在庫は チェックアウト で都度確認）。「自宅からの RTT が最小」だけで決めず、Git 上流、コンテナ／バイナリレジストリ、TestFlight や証明書まわり、オンコールのタイムゾーンがどこに偏るかから逆算しましょう。リージョン固有のチェックアウト導線は シンガポール、日本、韓国、香港、米国東部、米国西部 です。

最終候補は共通スクリプトで揃えるのが鉄板です：git clone --depth=1、約 1 GB 級の成果物取得、Cold／Warm での xcodebuild -showBuildSettings。開発者個人 SSH の快適さだけを指標にはしないほうがよく、運用側はランナー OS だけで許可リストを張ったうえでの HTTPS レイテンシをログに残すと次の増設にも流用できます。

企業プロキシ／スプリットトンネルの VPN が絡むなら評価はノートより Runner ホスト側で。外向き TLS がレジストリや Apple 開発者サービスまで一貫して通っているかどうかは「地図上の近さ」より効きます――紙面上的に速くても、成果物バケットがスロットルされる構成なら結果は読めません。

3) M4 16GB/256 と 24GB/512 と M4 Pro――並列席とシミュレータ上限の設計論

Apple Silicon で runs-on: self-hosted を満たすのはひとつの actions-runner ですが、そのマシンの上へ何個のジョブを載せられるかは同時実行設定より先に Xcode／Simulator のピーク常駐メモリに縛られます。M4・16 GB はヘビィな単一コンパイルか軽処理二つ程度、24 GB は Archive と単一 Simulator UI の二系統、アプリストア審査の狭いウィンドウで複数 Xcode マイナーを同居させたいときはPro／上位メモリ側を視野にします。

ワークフローでは、単に Runner の concurrency を 2 に上げるより [self-hosted, macOS, compile] と [self-hosted, macOS, ui-test] のように論理シャードへ逃がすほうが安全です。

GitHub Runner アプリ側の並列許容は単なるチューニング項目ではなく容量計画そのもの――16 GB 機で concurrency=2 と Simulator を二系統立てた瞬間に OOM とジョブ再試行だけが増えがちです。Archive ではまず 1 で、最重スキームのピーク常駐を測り、ひとウィーク memory_pressure が Normal を守れるなら段階的に上げる。App Store が要求する短い Xcode マイナー二段構え運用があるなら、CPU 増設よりSSD とルート計画から先に積んでください。

4) ディスク増設と DerivedData――並列 worktree と保持／ドレイン方針

ホスト側はほぼ毎クリーン開始で DerivedData は蓄積しません。セルフホストの旨味はむしろ ~/Library/Developer/Xcode/DerivedData が PR にまたがることですが、並列ジョブではひとつのパス共有は事故源なので DERIVED_DATA_PATH＝ジョブ単位ディレクトリ、必要なら Git worktree とセットで読み替えるのが鉄則です。

• SSD に留める： DerivedData と SwiftPM キャッシュ／バージョン固定済み Pods ツリー。
• Actions cache が向く： 再現性のあるツールチェーン zip、Lint 結果／再ダウンロードしやすい巨大依存。
• アラート： 空き 20％を切ったら DerivedData LRU で古い順に 30％弱を刈り、10％なら Runner をドレイン（新規キュー無効）まで段階的に締める。

5) 並列化の現実――複数ランマシンへ label と shard で逃がす日／週／月の道筋

一台のメモリ天井に当たったら 2 台目のリモート Mac と label で役割分担します：

• mac-ci-compile — xcodebuild build 専用。DerivedData を温め続けるゴールドライン。
• mac-ci-archive — 署名とアップロード。ワークフロー側 concurrency で証明書とキーチェーンの競合を直列に。
• mac-ci-ui — 24 GB または Pro へ Simulator UI を載せて隔離。

順路は日額でワークフロー検証→週単位でキャッシュ方針の固め→月額へ固定して IP と Runner の同一性まで整える→必要なら台数で shard。GitHub actions/cache が持てるものは共有し続けられる一方、DerivedData はホストローカルを基本と読むと設計ミスが減ります。

ワークフロー matrix の次元は「一台に全部」を避けて label と噛み合わせます。たとえば iOS 17/18 Simulator のナイトリーは Pro＋mac-ci-ui、PR は 16 GB compile だけへ。Secrets がどのラベルにあるかまで README に書いておけば、Fork PR が Archive キューだけに貼ったままタイムアウトする地雷を未然にできます。

6) HowTo――リモート Mac へセルフホスト Runner を登録する最短手順

GitHub 公式：セルフホストランナーの追加 をひととおり踏みつつ UI トークンの差分だけ随時読み替えます。Nuvcloud 側の実機へ入ったあとは：

1. SSH で接続／Xcode 本体とライセンス受諾まで完了。
2. 専用 Unix ユーザーまたは actions-runner ディレクトリを切り離し、そのアカウントに個人用 Apple ID で本番署名をしない。
3. リポジトリ設定 → Actions → Runners で config.sh。macos・m4・地域ラベルを付けて読み間違わない名前にする。
4. svc.sh install などサービス経由で launchd 常駐にし SSH 切断でジョブが途切れないようにする。
5. ワークフローで DERIVED_DATA_PATH と署名ジョブの concurrency: { group: codesign, cancel-in-progress: false } を先に明示。

env:
  DERIVED_DATA_PATH: ${{ github.workspace }}/DerivedData/${{ github.run_id }}
  RUNNER_TOOL_CACHE: /Users/runner/actions-toolcache

xcodebuild \
  -scheme "YourApp" \
  -derivedDataPath "$DERIVED_DATA_PATH" \
  build

7) 日額・週額・月額での TCO ラダー――いつ台数増とメモリ増を読むべきか

「実験の負担」と「本番 Runner の負担」を会計項目から分離して読みます：

粗略な 36 ヶ月比較： 自社保有 Mac の購入＋電気＋人件ベースコストは C_cap、クラウド月額（例：Nuvcloud）を R とすると総額イメージは C_cap 対 36×R。Mac 専門のインフラ head を持たないチームほど C_cap の未定義項目が残り勝ちです。ホスト側分だけ比べるならキューによる機会損失まで入れ込むと並び順がひっくり返ることもあります。

料金ページ で SKU と請求粒度を読み込みつつ更新・増設・契約ウィンドウの実務は ダッシュボード から。このブログでも CI 周辺論点は続けていくので一覧は ブログ目次 を参照してください。

8) FAQ

Q1：セルフホストは GitHub 利用規約として許されますか。
ご自身で所有または正当に賃借するハードウェアへの設置としては前提に沿いやすく、 Runner 機能を第三者に無秩序転売しないことなどが論点になります――最新 Terms を自分でクローズしてください。

Q2：ホスト型 macOS とセルフホストを混在させられますか。
問題ありません。PR はホスト側／メインラインのみセルフホストという二段構成はよくある分割です。

Q3：DerivedData はいつ全削除しますか。
Xcode 大変更・大規模ブランチカット・アラートでの空きディスク逼迫時など。稼働中にいきなり rm -rf しないで LRU とドレインを挟みます。

Q4：SSH が切れたらジョブも止まりますか。
launchd が抱えている Runner サービスは継続します。運用コンソールとしての SSH だけが落ちているだけという整理です。

Q5：地域をまたいだ引っ越しでキャッシュはどうなりますか。
ホスト側 DerivedData は引き継がれません。Actions cache に逃がしている成果物だけを先に揃え、フルコンパイルでホスト側をウォームし直しましょう。

Q6：16 GB 機で並列 Simulator UI は何人まで。
現実には「避ける」側が強い――重い Simulator UI は mac-ci-ui で隔離しましょう。

Q7：署名ワークフローは並列させないほうが良いのでしょうか。
並列でのキーチェーン／証明書同時ロックや二重 IPA 競合があるためconcurrency で直列ロックが典型です。

Q8：短命の日レンタル機を退去するときセーフ運用は。
GitHub 側 Runner 削除 → 発行済み PAT／登録トークン類のローテーション → 検証済みだけ残すキーチェーンと ~/.ssh を消し忘れチェックしてください。

Q9：fork 由来 PR はセルフホストへ流しても大丈夫ですか。
読み込みのみに寄せられるなら許容されますが、`pull_request_target` とシークレット渡しまで含めるとモデルごとレビューし直しましょう。