2026年 独占リモート Mac iOS／macOS CI：Dagger コンテナ化パイプラインとネイティブ Shell／xcodebuild 組み立てはどう選ぶ？——再現性、Runner 権限面、Derived Data キャッシュと SSH ヘッドレス排障の再現可能な意思決定マトリクス＋FAQ
独占リモート Macでは、すでに「予測可能なベアメタル」に投資している前提で、論点はステップの梱包方法に移る。Daggerでモジュール化しコンテナ境界を切るか、薄い Shell ドライバで xcodebuild／fastlane／xcrun に寄せてホスト結合を受け入れるか。本稿は Apple 系 CI で効く四軸——再現性、Runner 権限面、Derived Data とキャッシュ戦略、SSH ヘッドレス排障——で比較する。ワークフロー事前検証と Runner 運用の文脈は
2026年 iOS/macOS CI：act によるワークフロー事前検証と、専用リモート Mac 上の GitHub Actions セルフホスト Runner の比較——コード署名、Apple Silicon、トラブルシュート FAQ の意思決定マトリクス、署名クレデンシャルの境界と鍵運用は
2026年 独占リモート Mac CI：App Store Connect API（.p8）と Fastlane の app_store_connect_api_key——SSH ヘッドレス環境における鍵の保管・ローテーションとパイプライン注入の意思決定マトリクス＋FAQ
を参照。
1. 両者を同じ地図に載せる
Dagger 寄りパイプラインは、CI を汎用言語上のモジュールとして記述し、多くの前処理をコンテナ（多くは Linux）で回しつつ、macOS 専用作業だけをホストに委譲するハイブリッドになりやすい。Apple CI では「コンテナ一発完結」の幻想を捨て、Xcode・Simulator・署名素材は macOS 側に残る前提が現実的だ。
ネイティブ Shell＋xcodebuild 組み立ては、bash／zsh、Makefile、小さな Ruby／Swift ドライバから xcodebuild を直接叩き、DEVELOPER_DIR を固定し、キャッシュパスを明示する。単純だが、リポジトリ横断でスクリプトが複製されると、結局バラバラな「独自モジュールシステム」になりがちだ。
いずれも GitHub Actions／GitLab／Buildkite 等のスケジューラを置き換えない。スケジューラとマシンのあいだに挟まり、再現性とブラスト半径の形を決める。
2. 四軸の意思決定マトリクス（再現性・権限・Derived Data・SSH）
脅威モデルとリリース頻度に合わせてセルに点数を振る想定で読む（数値はイメージでありベンダー公表値ではない）。
| 観点 | Dagger コンテナ寄りパイプライン | ネイティブ Shell＋xcodebuild |
|---|---|---|
| 再現性 | Apple 以外のステップ（リンター、コード生成、API クライアント等）では、イメージ固定とキャッシュキー設計ができれば強い。弱点は依然としてmacOS ホスト断面——Xcode パッチ、Rosetta、Simulator データは Dagger の外で版管理する必要がある。 | 規律次第。同一スクリプト＋固定 DEVELOPER_DIR＋ロック済み SwiftPM／CocoaPods 入力なら決定性は高い。共有ライブラリが無いとリポごとにドリフトしやすい。 |
| Runner 権限面 | Docker／BuildKit権限、イメージ取得、クレデンシャル転送パターンが増える。ソケットマウントや秘密の環境変伝播の誤設定は、アプリがネットワークに触れなくてもブラスト半径を広げうる。 | 主にCI ユーザー＋キーチェーン＋ sudo 方針。デーモン群より部品は少ないが、レガシー curl | bash インストーラは供給鎖上の穴として残る。 |
| Derived Data とモジュールキャッシュ | DerivedData、SPM グローバルキャッシュ、CocoaPods 成果物のためにホスト bind かリモートキャッシュを明示モデル化しないと、見かけ上クリーンでも毎回フルビルドになる。 |
温かい常駐 Runnerと整備されたキャッシュルート、外側ワークフローでの攻撃的なキー付けが最短ルート。Xcode アップグレード後のインデックス陳腐化は自動退避が無いとリスク。 |
| SSH ヘッドレス排障 | 障害がコンテナログとホストログに分断され、ネットワーク・マウント・UID 写像の帰属を理解する必要がある。デバッグ動詞（dagger call … 等）を標準化すると強い。 |
SSH ファースト：Runner ユーザーで接続し ~/Library/Developer を覗き、CoreSimulator を再起動し、同じ Shell 断片をそのまま再実行——Xcode 固有インシデントでは速い。 |
3. Dagger を先に置くべきとき
- ポリグロットパイプライン（バックエンド＋モバイル＋コード生成）を維持し、bash のコピペより型付きモジュール境界を優先したい。
- 開発者ノート PC と CI で同一のコンテナ化リンター／SBOM ツール挙動を揃えたい。
- 「mac 断面」の契約を切れる：Xcode バンドル固定、Simulator ベースライン文書化、キャッシュボリュームを本番データストア並みに運用できる。
4. ネイティブ Shell＋xcodebuild を先に置くべきとき
- 失敗の多くがコード署名、プロビジョニング、公証、Flaky な UI テストで、直接ホストコマンドと SSH で追う方が速い。
- 配布用証明書を載せたマシンにDocker ソケット権限を足すことへのコンプライアンス懸念が強い。
- 単一アプリの最短イテレーション：スクリプト変更→ジョブ再実行で、モジュールグラフ再構築を挟みたくない。
5. 実務的ハイブリッド（成熟チームの多く）
Linux で安全な処理——API 差分、protobuf 生成、ライセンススキャナ——は Dagger（または同等）に寄せ、最小限の macOS ステージだけで xcodebuild test／archive と共有キャッシュルートを回す。境界の引き渡し（環境変、キーチェーン分割、アーティファクトパス）を Runbook 一行で追える形に固定する。
6. FAQ
Q1: Dagger は GitHub Actions や GitLab CI の YAML を置き換えるか？
いいえ。ジョブ内部の手続き糊を置き換える。トリガー、承認、シークレット統合はプラットフォーム側に残る。
Q2: macOS 上で Xcode を完全にコンテナ内だけで回せるか？
実務的には、チームが期待するLinux 的ヘルメティックとしては難しい。macOS コンテナを使うにしても最適化扱いにし、再現性の正はホストツールチェーンの固定に置く。
Q3: Derived Data はどうキー付けすべきか？
Xcode ビルド版＋Swift コンパイラ版＋ロックファイル（Package.resolved、Pod チェックサム）でキーする。ロックファイルに現れないコンパイラフラグ変更時は手動で「エポック」を上げる。
Q4: Dagger レイアウトで署名秘密はどこに置くか？
秘密鍵はOS 保護ストア（キーチェーン／HSM）に置き、ビルドステップへ渡すのは短命セッション成果物に留める。.p12 をコンテナレイヤに焼くのは避ける——レイヤは秘密基盤ではない。
Q5: SSH でフレークを潰しているが、Dagger は邪魔になるか？
mac ステージを不透明なラッパーの裏に隠さない限り、害は小さい。逃げ道として実際の xcodebuild 行を必ず印字し、CI_DERIVED_DATA_PATH 等をエクスポートし、SSH オペレータがそのまま追える Runbook を添える。
信頼できるハードウェア上で macOS 断面を回す
糊コードが Dagger でも Shell でも、高コストなコンパイルとリンクは結局 Apple Silicon 上で走り、CPU・GPU・Neural Engine とユニファイドメモリの一体最適化が、ノート PC で Docker と Xcode を同時に詰め込んだときのようなメモリ圧迫型の不安定さを減らす。macOS は Unix ツールチェーンと常時稼働 Runner に向いた消費電力特性を持ち、Gatekeeper・SIP・FileVault といったセキュリティ叙述とも整合しやすい。
iOS／macOS CI 用の独占リモート Mac プールを標準化するなら、スループットと待機時の効率のバランスで Mac mini M4 は依然有力で、署名用途にロックダウンしやすい静音常駐機としても扱いやすい。謎の VM との戦いをやめ、自前メタルに CI を固定したい段階では、今すぐ Mac mini M4 を手元の基盤に据えるのが、Dagger でも素の xcodebuild でも「退屈なほど安定した」運用へ近づく現実的な一歩になる。