2026年 Jenkins SSH ビルドエージェント vs GitHub Actions セルフホスト macOS Runner：専有リモート Mac 上の並行性、SSH セッション安定性、TCO 意思決定マトリクス＋FAQ

1. 前提：専有リモート Mac 上でそれぞれどう見えるか

Jenkins SSH ビルドエージェント（SSH エージェント）：コントローラが SSH 経由でリモート Mac 上のビルドを起動し、ワークスペースとスクリプト実行はその SSH セッション文脈に乗ります。オーケストレーション、資格情報、キュー意味論は主に Jenkins 側にあります。

GitHub Actions セルフホスト macOS Runner：actions-runner サービスが Mac 上に常駐し、ジョブは GitHub クラウドがスケジュールします。ホットパスは多くの場合、ジョブごとに新規 SSH を張るのではなく Runner の長寿命接続 です。

どちらも テナント専有 のリモート Mac で動かせます。「専有」は他テナントとの競合は消しますが、同一 Mac 上の複数並列ジョブ は RAM、SSD の書き込み増幅、シミュレータ資源を奪い合います。Jenkins か Actions かに依りません。

2. 制御面とデータ面：接続モデルが切り分けを変える

Jenkins SSH では障害が チャネル切断、ワークスペースロック残り、SFTP 同期の停滞 として現れがちで、直感は sshd・ネットワーク・ディスクに向かいます。セルフホスト Runner では Runner の更新、登録トークンのローテ、ラベル不一致 が増え、直感は Runner サービス健全性とクラウド側キューイベント に移ります。

同一ホストで SSH 自動化や常駐デーモン も動かすなら、keepalive・バックグラウンドプロセス・ログの層を CI 用アカウントと揃え、対話デバッグがビルド環境を漂流させないようにします。物理ノード上で CI クラスタと自己修復の発想を整理するには 2026年最強のCI/CDアップグレード：リモート物理Mac mini上でAI駆動の自己修復型クラスターを構築 が参照になります。

Mac から GitHub（またはコントローラ）への外向き通信が制限される場合、トンネルや分割公開は CI の SLO の一部として設計します。Apple ツールチェーンと帯域の扱いをまとめるなら 2026年最強の開発者リソース最適化：SSH経由でリモートMac mini M5をNPU/GPUオフロードとXcode 26高速ビルドクラスターに変える方法 も併せて検討してください。

3. 並行性：設定した「並列度」と実機上の競合

3.1 Jenkins 側：エグゼキュータとラベルが第一原理

SSH エージェントノードでは エグゼキュータ数 がそのノードの同時ビルド上限を決め、ラベル が iOS コンパイル・UI テスト・リリース署名など論理プールを切ります。エグゼキュータを高くしすぎると「キューは短いのに失敗率だけ上がる」——多くはメモリかディスク I/O 飽和で、CPU 不足ではありません。

3.2 GitHub Actions 側：Runner プロセスと concurrency

1 台の Mac に 複数 Runner を載せることは可能ですが無暗に積むのは避け、重い処理は concurrency や環境レベルのミューテックスで直列化します。Jenkins と同様、ジョブあたりのピークメモリと Derived Data の書き込み増幅 を測ってから「同時にいくつの xcodebuild か」を議論します。

コード署名とキーチェーンが絡む場合は、どの ID がどのキーチェーンとプロビジョニングプロファイルに触れるか を文書化します。スタック非依存の規律です。

4. SSH セッション安定性：本当のボトルネックと誤った信号

Jenkins SSH では SSH がしばしば ホットパス です。ジッター、NAT アイドルタイムアウト、macOS のスリープ、sshd のリソース制限がビルドをabortさせます。ベースラインには適切な ServerAliveInterval / ClientAliveInterval、必要に応じたディスクスリープ無効化、専用 CI ユーザー、対話ログインと自動化の分離を含めます。

セルフホスト Actions では SSH は 運用チャネル（切り分け、ファイル同期、手介入）に留まり、Runner の long poll / WebSocket 経路 がクリティカル依存になります。Runner プロセスの生存、証明書更新、OS アップグレード窓を監視し、「SSH は通るのにジョブが動かない」を誤診しないようにします。

同じ Mac に開発用ゲートウェイやスクリプトホストも載せる場合は、事前にリソースと権限境界を定義し、CI とアドホック負荷がポートや CPU を奪い合わないようにします。

5. 機能マトリクス（Jenkins SSH エージェント vs セルフホスト GHA macOS Runner）

6. TCO 意思決定マトリクス（アーキレビューに貼れる短尺）

ハイブリッド現実：Mac ではセルフホスト Runner、他プラットフォームは Jenkins——という構成は珍しくありません。TCO は「どちらが新しいか」より シークレット基盤・監視スタック・アップグレード窓を二重に保守するか が効きます。両方必要なら、Xcode・Ruby／CocoaPods・シミュレータイメージなど 単一の正（single source of truth） にし、二つのオーケストレータが別環境を指さないようにします。

7. FAQ

Q1: Jenkins SSH エージェントは常に Runner より不安定か？

必ずしもそうではありません。不安定の多くは SSH 経路とホストのベースライン（スリープ、ディスク満杯、並行性による sshd 飢餓）から来ます。ベースラインを固めれば SSH は十分安定します。Runner にも長接続とアップグレード固有の失敗モードがあります。

Q2: 1 台の専有 Mac で Jenkins 受けと GHA Runner を同居できるか？

技術的には可能ですが、運用上は通常おすすめしません。二つのキュー、二つのワークスペース規約、二つのログ習慣が積み上がり、切り分けが「どちらのジョブか」から始まります。どうしても試すならユーザーアカウントとディスクを分離し、ラベル隔離を厳格にしてください。

Q3: 並行性は CPU コア数に合わせるべきか？

iOS／macOS CI では メモリとディスク書き込み増幅が CPU より先に効く ことが多いです。ジョブあたりのピーク RAM と UI テスト並列からサイズし、その結果からエグゼキュータ数や Runner 数を決めます。

Q4: 見積もり漏れがちな TCO の行は？

インシデントとアップグレード窓に使うエンジニア時間 です。メジャーな Xcode やプラグイン／Runner 更新のタイミングでパイプラインが 1 時間止まる損失は、ハードレンタル差額の数ヶ月分を超えることがあります。

Q5: いつ Jenkins に明確に軍配が上がるか？

制御面を 強いイントラ内 に置かなければならないとき、または GitHub 外のリポジトリ と Mac／iOS ビルドを mature なプラグインガバナンスとバックアップ訓練で束ねる必要があるとき——移行より Jenkins の TCO が低いことが多いです。

どちらのスタックでも、安定した macOS ベースラインが土台

Jenkins SSH のままにするか、GitHub Actions のセルフホスト Runner に寄せるか、一時的なハイブリッドにするかに関わらず、リモート Mac が担うのは Xcode、シミュレータ、署名、アップロード です。ここでは Apple Silicon 上の macOS が強みを発揮します。ユニファイドメモリは大規模コンパイルでの帯域圧を和らげ、Gatekeeper、SIP、FileVault は典型的な Windows CI ホストより境界が明瞭になり、Mac mini は静音とおおよそ 4W 級のアイドル電力 を両立しやすく、常時稼働の専用ビルドノードを電力と設置面積の観点で正当化しやすくします。

リモート運用とヘッドレス運用に向いたハード に TCO マトリクスを着地させるなら、Mac mini M4 は価格対安定性の優れた出発点です。機材を揃えて Jenkins と Actions に「ワークフロー設計」で勝負できる状態にしておきましょう。