2026年 エンタープライズ iOS/macOS CI 選定：GitLab Runner（macOS）と GitHub Actions セルフホスト Runner の比較——専用リモート Mac ノードにおける並行性、SSH アカウント分離、キャッシュマウントと運用 FAQ の意思決定マトリクス
リポジトリが GitLab と GitHub の両方にあっても、ビルド能力が同じ専用リモート Macに集約されるとき、体験を決めるのは YAML の見た目ではなく、Runner の並行実行の意味論・実行主体（Unix ユーザー）・ディスク上のキャッシュ境界です。本稿では GitLab Runner と GitHub Actions セルフホスト Runner を、エンタープライズ導入の順序で比較し、SSH アカウント分離、キャッシュマウント、運用向け FAQ マトリクスをまとめます。
1. 「専用ノード」を運用可能な制約に翻訳する
専用リモート Macとは多くの場合、シングルテナントの実機、安定した入口（グローバル IP や専用線）、ログイン状態（Keychain／Xcode ライセンス）を長期保持する許可、そして予測可能な IO を指します。その前提で問うべきは、次の 4 領域が監査可能かです。
- 同時に何ジョブ走るか：shell executor では 1 台がカーネルとディスクを共有し、並行度を上げると Derived Data や Simulator リソースが衝突しやすい。
- どの Unix ユーザーがジョブを実行するか：管理者が SSH 用と同じアカウントか。そうだと手作業の 1 変更がグローバル環境を汚染しうる。
- キャッシュと成果物の置き場：ジョブごとの一時ディレクトリ、Runner 固定ボリューム、ネットワークマウントのどれか／キャッシュ復元失敗時にクリーンビルドへ落ちる設計があるか。
- Forge との結合度：GitLab は Registry・変数・監査をインスタンスと一体で持つ。GitHub は Actions・OIDC・組織ポリシーに深く結びつく——クロスプラットフォームではトークンとネットワーク設計を明示する必要がある。
クラウドの従量課金と固定セルフホスト費用の比較は、本ブログの CI 系記事（Xcode Cloud とセルフホスト GitHub Actions など）と併読すると整理しやすく、本稿はそのセルフホスト二刀流編として位置づけられます。
リモート Mac 上で launchd や SSH 文脈を揃える運用の参考として、 2026年 OpenClaw 大規模アップグレード実践（リモート Mac SSH で再現できる手順） のチェックリストも有用です——Runner の登録トークン更新やサービスログの見方と同じ「再現可能な手順」に寄せられます。
2. 実行モデル：GitLab Runner と GitHub Actions Runner
2.1 GitLab Runner（macOS 上の shell / カスタム）
GitLab Runner は GitLab インスタンスに長期トークンで登録します。macOS では shell executor で、選んだユーザー文脈でジョブスクリプトを走らせる構成が多く、既存ログインセッション・Keychain・稀な GUI 依存との整合が取りやすい反面、並行ジョブは追加の境界（複数アカウント、キュー上限、ディレクトリ分割）なしでは同一ユーザ名前空間を共有します。
2.2 GitHub Actions セルフホスト Runner
セルフホスト Runner はワークフローをジョブ単位で取り込み、macOS でも多くはシェル実行です。差が出やすいのはオーケストレーション側——Actions マーケットプレイス、runs-on ラベル、組織レベル制御（クラウドへの OIDC など）。主リポジトリが GitHub なら同一アイデンティティ平面に Runner を置き、クロスプラットフォーム PAT の露出クラスを減らせることがあります。
Git イベントを社内ボットやチャットに流す場合も、ホスト上の他の自動化リスナーと同様、Runner 登録トークンは最小権限で揃えるのが筋です。
3. 専用 1 台での並行性：スケールより規律を先に
物理 Mac 1 台では、初期線として既定並行度 1、その後マシン追加や明示的なリソース分割から並行を増やすのが安全なことが多いです。concurrent やキュー深さだけを上げると、典型的には次が起きます。
- 2 つの
xcodebuildが同一 Derived Data ルートを奪い合い——増分ビルドの不安定化や署名アイテム欠落。 - Simulator／UI テストがポートやスクリーンショット系サービスで競合——「ローカルでは通るが CI ではフレーク」。
- 書き込み増で SSD 寿命とバックアップウィンドウが圧迫される。
実務：マシンごとに CPU コア、空き RAM、ディスク余裕、UI テストの並列可否といった予算表を持ち、そこから GitLab Runner の concurrent と GitHub の組織ジョブポリシーを導出する。SPM キャッシュやパイプライン層の整理は
遠隔 Mac mini M5 を利用した SPM キャッシュと visionOS 自動化パイプライン
の記事とも噛み合わせやすく、キャッシュルートと掃除閾値を runbook で一本化できます。
4. SSH とアカウント分離：運用ログイン ≠ ビルドユーザー
ありがちなアンチパターンは、管理者が SSH で Xcode を入れ、その同一アカウントで Runner を登録することです。場当たりの brew upgrade、テストスクリプト、証明書エクスポートがすべてパイプラインと HOME を共有し、インシデントの再現が困難になります。
推奨境界：
- 専用
ciアカウント：Runner はここだけ。日常運用はsudoや MDM でシステム変更する別アカウント。 - Keychain の分離：署名身份は CI ログイン Keychain。macOS マイナーアップ後は自動アンロック方針を再確認。
- SSH はブレークグラス：構成管理やスクリプト化ベースラインを優先。SSH セッション内の PATH 変更を長寿命状態にしない。
- 監査：Runner バージョン、登録スコープ（グループ／リポ／組織）、最終トークンローテーションを記録。
GitLab／GitHub は RBAC で誰がジョブを起こせるかを制御しますが、macOS 上では最後の砦は Unix ユーザーとファイル権限であり、どちらのプラットフォームもそれを消してはくれません。
5. キャッシュマウント：ボリューム・パス・無効化
どちらの Runner も依存解決と増分コンパイルを短縮しつつ、汚れた状態と権限を制御することを目指します。
5.1 よくあるマウント先
- Derived Data／SwiftPM／CocoaPods：固定ディレクトリまたは専用 APFS ボリューム。ジョブ開始時に「チェックサムが一致すれば利用、そうでなければ wipe」の防御ロジック。
- 言語ランタイムとグローバルキャッシュ：Ruby／npm などは CI ユーザ HOME 下に正規の 1 パスへ集約。
- ネットワークストレージ（NFS／SMB）：メタデータ遅延とロックに注意。Xcode 負荷はローカル NVMe、アーティファクトとログアーカイブをネットワーク、という切り分けが多い。
5.2 プラットフォームネイティブのキャッシュ語彙
GitLab は .gitlab-ci.yml で cache／artifacts を第一級概念として持ちます。GitHub Actions は actions/cache と明示キーが中心です。どちらも優秀——差は、クォータ・サイズ上限・デバッグ手順のどちらをチームが既に信頼しているかです。
6. 運用 FAQ 意思決定マトリクス（コンパクト版）
同じ専用リモート Mac、同じ運用チーム——プラットフォームへの結びつきを選ぶための表です。コードとパッケージが既に一方の Forge に集まっているなら、トークン拡散と監査の分岐を減らすためにそちらを優先しやすいです。
| 観点 | GitLab Runner（macOS） | GitHub Actions セルフホスト |
|---|---|---|
| Forge との密結合 | CI 変数・Registry・コンプライアンスフックがインスタンス版に連動 | GitHub 権限・OIDC・組織ポリシー API との一体運用 |
| 専用実機での既定並行 | Runner concurrent ＋ shell 環境——キュー規律は自前 |
同様。組織のジョブスケジューリングとラベル一致も要監視 |
| キャッシュ／成果物の語り口 | モノリシック GitLab フローでは cache／artifacts が第一級 | actions/cache ＋ artifacts。エコシステムは豊富、アクション版はピン留め推奨 |
| FAQ：キューに入ったまま動かない | Runner オンライン・タグ一致・concurrent 上限を確認 |
セルフホストラベル・組織上限・Runner サービスログ／リスナーを確認 |
| FAQ：署名が間欠的に失敗 | Keychain アンロック、マルチジョブの Derived Data 競合、ヘッドレスユーザー不一致を疑い——Forge より先に macOS 側を直す | |
7. 締め：防御可能な選定順序
主 Forge と監査チェーンからプラットフォームを決め、その後に専用 Mac 上でCI ユーザー・キャッシュルート・既定並行度を固定する——その順で初めて YAML の書きやすさを比較すると、多くの「Runner が謎」はファイルシステムと Keychain の問題に圧縮され、GitLab／GitHub で共通の切り分けストーリーを持てます。
専用リモート CI を Mac mini／macOS に置く理由
iOS／macOS パイプラインは Xcode と Apple ツールチェーンに依存し、実機上のネイティブ macOSが最短経路です。ネスト仮想化のオーバーヘッドを避け、ユニファイドメモリは大規模 Swift プロジェクトや並列テストに効き、Homebrew・SSH・CLI は Runner スクリプトと相性が良いです。24 時間無人ノードでは安定性と待機電力も重要で、小型の Mac クラス筐体は長時間静音運用に向きます。Gatekeeper・SIP・FileVault の組み合わせは、汎用 PC イメージに比べマルウェア面の攻撃面が小さくなりやすい、という整理もできます。
本文の並行度・キャッシュ・CI ユーザーポリシーを、リモートから保守可能なシングルテナント実機で実現したいなら、2026 年時点でも Mac mini M4 はコストパフォーマンスの基準点のひとつです。今すぐ導入を検討し、GitLab と GitHub の Runner を同じ「実機の規律」で揃えましょう。