2026年 iOS/macOS CI：Codemagic ホスト型パイプラインと独占リモート Mac 自ホスト Runner（GitHub Actions／GitLab）はどう選ぶ？同時実行枠・YAML 保守・Apple クレデンシャル境界・SSH ヘッドレス排障——再現可能な意思決定マトリクス＋FAQ

1. ふたつの形を同じ土俵で見る

Codemagic（ホスト型）：リポジトリ連携、ビルドステップ、macOS／Xcode スタック、ログ、多くのシークレット保管がプラットフォーム側にあります。チームは主に codemagic.yaml とダッシュボード設定、ビルド分の予算管理に集中します。

独占リモート Mac ＋ GitHub Actions／GitLab Runner：実行は常設またはプール化した自前／レンタル Mac 上。ワークフローは .github/workflows/*.yml や .gitlab-ci.yml に置かれ、Runner は OS とキーチェーン・ディスクを共有します。SSH が許可されていれば、失敗ジョブの再現はローカル Mac に近い感覚になります。

混同しやすいのは「どちらも Git ホスティングと連携する」点です。差は実行環境の所有、同時実行の上限が誰の契約で決まるか、YAML をどこまで分散させるかにあります。

2. 同時実行枠とキュー：誰の前で待つか

Codemagic：プランに応じた同時ビルド数とビルド分（またはクレジット）が上限になります。チームが増えると「PR ごとにパイプラインを増やす」設計と衝突しやすく、ダッシュボードでのキュー可視化とアラート設計が重要です。

セルフホスト：理論上のボトルネックはあなたが載せた Runner と Mac の台数です。1 台に複数ラベルの Runner を載せると CPU・メモリ・Simulator 同時起動で競合し、見かけ上の「同時実行」が裏で直列化することもあります。GitLab の concurrent や Actions のジョブマトリクスと、実マシンの物理上限をセットで設計します。

判断の目安：PR 数とブランチ戦略が激しいのにホスト型の枠で詰まるなら、独占 Mac を足すか、Runner プールを増やす検討時期です。逆に同時ビルドが少なく SaaS の枠内に収まるなら、運用負荷の低い Codemagic 側が速いことが多いです。

3. YAML 保守面：単一ファイルか、リポジトリ全体か

Codemagic：codemagic.yaml にワークフローを寄せやすく、モバイル向けプリセット（署名、テスト、ストア提出フック）との親和性が高いです。変更レビューは「そのファイル＋ UI で触った差分」に閉じやすい一方、GitHub と GitLab で別アプリを運用する場合はプラットフォーム固有の記法にロックインされる意識が必要です。

GitHub Actions／GitLab：YAML はリポジトリ内の複数ファイルに分散しやすく、再利用は composite action、reusable workflow、include などのパターンで整理します。チームにインフラエンジニアがいるほど再利用とバージョン管理の伸びしろが大きい反面、レビュー対象が広がります。

判断の目安：「モバイル CI の設定を 1 本の yaml にまとめたい」なら Codemagic。「全社で同じ Actions／GitLab パターンを横展開したい」ならセルフホスト側です。

4. Apple クレデンシャル境界：ASC、証明書、キーチェーン

Codemagic：App Store Connect API キー、証明書、プロファイルを統合シークレットとして登録し、ビルド時に注入する流れが中心です。監査はベンダーのアクセスログとローテーション手順に沿います。社内規程で「ビルド鍵はすべて社内 KMS にのみ置く」場合は適合性を個別確認します。

独占 Mac：キーチェーン、ファイルベースの .p12、Vault エージェント、署名用ユーザーの分離などを自組織の境界で完結しやすいです。Fastlane Match や ASC API の運用も、既存のオンプレに近いポリシーに寄せられます。

判断の目安：「SaaS のシークレット保管で SOC2 説明を一本化したい」ならホスト型。「キーチェーンと OS ユーザーを監査ログ付きで自分で切る」なら専用 Mac です。

5. SSH ヘッドレス排障：ログだけか、シェルまで持つか

Codemagic：トラブルシュートはビルドログ、再実行、サポートが基本で、ビルド VM への SSH は通常期待しません。フレークの切り分けはスタック固定とキャッシュ設計に依存します。

独占リモート Mac：契約とゼロトラスト設計が許せば SSH で log show、simctl、ディスク、キーチェーン状態を直接確認できます。長時間 UI テストやコード署名競合のインシデントでは差が出やすいです。

判断の目安：インシデントを分単位で自分で潰す必要があるなら専有 Mac。ワークフローが安定しログで足りるならホスト型で十分なことが多いです。

6. 意思決定マトリクス（要約）

7. FAQ

Q1: Flutter とネイティブ iOS の混在プロジェクトはどちらが楽？

Codemagic は Flutter 系のプリセットと実績が厚い一方、ネイティブのみでも利用可能です。全社で GitLab CI テンプレートを統一しているなら Runner 側の方が一貫しやすいです。リポジトリの「真のソース・オブ・トゥルース」をどこに置くかで決めます。

Q2: Codemagic を使いつつリリースだけ GitHub Actions に寄せられる？

ハイブリッドは可能です。重要なのは署名鍵と ASC API キーをどこに単一化するかです。二重保管はローテーション事故の温床なので、どちらかを正とし、もう一方は参照のみにします。

Q3: GitLab と GitHub の両方から同じ Mac Runner を使いたい

技術的には同一ホストに複数 Runner を載せられます。ただしジョブ隔離（ユーザー分離、ワークスペース、キーチェーン）を設計しないと、並列ジョブで署名やキャッシュが衝突します。ラベルと concurrent を慎重に。

Q4: ホスト型のビルド分が読めないときの第一歩は？

直近 4 週間の中央値と p95 を取り、PR あたり分数と main ブランチの分数を分けます。キャッシュミスとテスト並列度が支配しているかを切り分けたうえで、専用 Mac の固定費と比較します。

Q5: SSH 付き専用 Mac はセキュリティ的にアウト？

アウトではなく設計責任が自前に移るだけです。踏み台、MFA、ビルド専用 OS ユーザー、セッション記録、署名鍵のハードウェアバインドなど、企業標準のゼロトラストで閉じれば監査可能です。

専用リモート CI を支えるハードとしての Mac mini

セルフホスト Runner を載せる独占 Mac は、長時間の xcodebuild、複数 Simulator、DerivedData の I/O を静音・低待機電力で回し続ける用途に向きます。Apple Silicon の Mac mini はコア数とユニファイドメモリ帯域のバランスがよく、Codemagic のような従量ホスト型と並べた TCO 試算でも「常時ビルドが多いチーム」では固定費＋再現性の優位が出やすいです。macOS なら Xcode・コード署名・キーチェーンをネイティブに扱え、Unix 系ツールチェーンもそのまま載せられます。Gatekeeper・SIP・FileVault によりビルド用アカウントを隔離しやすく、長期運用の説明もしやすいです。

Codemagic と専有 Runner のどちらに寄せるか決める前に、同時実行の実測・YAML の所有権・クレデンシャル境界を数字に落とし、専用リモート Mac mini を 1 台足すシミュレーションをしてみる価値があります。ハード面はトップページのプランから選べます。今がちょうどよいタイミングなら、SSHMac のトップページで Mac mini の構成を確認し、CI の土台を固めてください。