2026年 専有リモート Mac CI：Xcode Command Line Tools のみか 完全 Xcode か？アーカイブ、署名、Simulator、SSH ヘッドレスの意思決定マトリクス＋FAQ
CI 用に完全に支配できる 1 台では「CLT のみ」はディスクとアップデート負荷を抑えられる一方、iOS SDK、archive、Simulator、GUI セッション前提の処理が出た瞬間に穴が開きます。本稿では能力とシナリオの対応、SSH ヘッドレスの注意点、runbook に貼れる FAQ を整理します。
それぞれのインストールがカバーする範囲
Xcode Command Line Tools（CLT）にはコンパイラ、一般的な Unix ユーティリティ、git、make など、主に macOS ターゲット向けのベースラインが含まれます。フル Xcode より遥かに小さく、純 CLI、サーバサイド Swift、macOS 限定の静的解析パイプラインには合理的です。
完全 Xcode（Xcode.app）には Apple プラットフォーム SDK（iOS / iPadOS / watchOS / tvOS / visionOS など）、Simulator ランタイムと CoreSimulator、IDE が前提とする複数プラットフォーム向けの xcodebuild 挙動が同梱されます。多くの iOS アプリ CIでは、こちらをデフォルト計画に置くのが妥当です。
よくある落とし穴は、CLT のみのホストで xcodebuild -scheme … -destination 'platform=iOS Simulator' を回すことです。失敗理由は SDK や destination の欠如であることが多く、スクリプトの 1 行ミスではありません。
シナリオマトリクス（専有リモート Mac CI）
以下は 専用ノード（単一テナントまたはフル予約）を想定しています。マルチテナント共有プールは隔離とクォータが別論です。
| シナリオ | CLT のみ | 完全 Xcode | メモ |
|---|---|---|---|
| macOS のみのビルド／静的解析 | 多くの場合 OK | 任意 | SDK と xcodebuild -version を固定。OS アップグレードでツールチェーンが流れないよう監視。 |
| iOS / tvOS などモバイル SDK ビルド | 不足 | 必須 | Apple が Xcode と同梱する SDK レイアウトが必要。CLT では代替できません。 |
archive＋ IPA / pkg のエクスポート |
不足 | 必須 | 完全なツールチェーンと export オプションが必要。署名は下記。 |
| ユニットテスト（Simulator 不要） | 場合による | 推奨 | iOS ターゲットは Xcode SDK が要ることが多い。macOS のみなら CLT で足りる場合あり。 |
| UI テスト／Simulator が要る処理 | 不足 | 必須 | ランタイムを事前導入。ヘッドレス SSH ではセッションと権限が追加制約に。 |
notarytool／stapler |
多くの場合 OK | 多くの場合 OK | 成否は Apple ID／App Store Connect API キーとキーチェーン方針に依存。「Xcode.app の有無」だけの二択ではありません。 |
経験則：パイプラインに iOS SDK、Simulator、archive／export のいずれかが出るなら、デフォルトは 完全 Xcode。インフラ台帳に正確なバージョン（複数 Xcode 併存ならレイアウトも）を記録してください。
アーカイブと署名：Xcode は第一層にすぎない
完全 Xcode は SDK とビルドツールを揃えます。署名とプロビジョニングは別で、証明書と秘密鍵が適切なキーチェーンにあり、CODE_SIGN_IDENTITY／プロファイルまたは自動署名設定が CI ユーザーで一貫し、エクスポート方式（開発／Ad Hoc／App Store）がブランチ方針と揃っている必要があります。
SSH 自動化では「Xcode がない」より 非対話セッションでキーチェーン UI を開けない、security find-identity に CI ユーザーの証明書が出ない、といった失敗が反復しがちです。キーチェーン作成・アンロック、証明書インポート、App Store Connect API キーでの export／アップロードの有無を文書化し、キーチェーン問題を Xcode 未導入と誤認しないようにしてください。エンドツーエンドの流れは
2026年リモート Mac mini で iOS CI 環境を構築：Xcode から TestFlight までの全工程
と併せて整理すると運用が追いやすくなります。
Simulator：完全 Xcode、ランタイム、ヘッドレスの注意
Simulator スタックは Xcode に同梱され、CLT 単体では simctl が期待するランタイムイメージを提供しません。専用ホストでは、サポートする OS バージョン行列に合わせランタイムを事前ダウンロードし、初回 CI がイメージ取得でタイムアウトしないようにしてください。
GUI なしの純 SSH でも、ウィンドウ付き Simulator やアクセシビリティ許可を暗黙に前提とするスタックは不安定になりがちです。設計として GUI／VNC 付きトリアージ用ノード、実機ラボ、UI 自動化はグラフィカルセッションが保証された Runner に限定する、などを決め切るとよいです。Runner の実行モデルやキャッシュ分離の観点では GitLab Runner と GitHub Actions セルフホスト Runner の比較（並行性・SSH 分離・FAQ） も参照ください。
SSH ヘッドレス：観測項目をチェックリストに含める
ジョブごとにログへ xcodebuild -version、xcode-select -p、swift --version、設定している DEVELOPER_DIR を残してください。複数 Xcode では xcode-select と Runner 環境変数のズレが「手元では動くが CI だけ SDK が違う」バグの典型原因です。
「CLT のみでディスク節約」と「完全 Xcode で確実にリリース可能」を比較するときは、ハードと稼働率と同じ総コストの枠で見るのが公平です。
FAQ
Homebrew でフル Xcode の代わりに iOS ビルドはできる？
App Store や実機署名付き iOS ビルドについて、Apple 公式の iOS SDK と Xcode 配布を置き換える正当な手段はありません。ベースラインは完全 Xcode と公式ドキュメントと捉えてください。
ディスクが厳しい。CLT のまま削ぎ落とせないか？
本当に macOS のみ／バックエンド Swift なら CLT で足りる場合があります。iOS の archive や Simulator が必要になった瞬間、「削減」は多くの場合デバッグ時間の増加に化けます。専用機の SSD 拡張や、コンパイル用と UI テスト用で Runner プロファイルを分ける方が健全です。
複数 Xcode を入れていると何が壊れやすい？
ジョブ単位で DEVELOPER_DIR を固定するか、スコープ付き xcode-select を使う。並列ジョブがグローバルな xcode-select を書き換えて競合しないようにしてください。
SSH 越しに Simulator が黒画面／起動しない？
ランタイム未導入、権限、GUI 前提のテスト要求を切り分けてください。Simulator 系の失敗を CLT の再インストールだけで直そうとしても効かないことが多く、GUI 可能なノードや実機の検討が現実的です。
この Xcode 判断に Mac mini が合う理由
完全 Xcode、Simulator、署名はディスク・メモリ・I/O の安定性に敏感です。専有リモート Mac CIの価値は、凍結した再現可能な環境にあります。Apple Silicon の Mac mini クラスはユニファイドメモリの帯域が高く、待機電力も非常に低く抑えられ、24 時間ビルドノードに向きます。macOS なら Unix 系ツール、SSH、xcodebuild が余計な層なしで使え、Gatekeeper・SIP・FileVault は無人運用時のリスクを多くの汎用 Windows ビルド PC より抑えやすい構成です。
2026 年のベースラインとしては、モバイル SDK 作業がなければ CLT に縮小してよいが、それ以外は バージョン行列が明記された完全 Xcode を既定にするのが安全です。そのパイプラインを静音で効率的な筐体に載せたい場合、Mac mini M4 は価格対安定性のエントリとして有力です。SSHMac で専用機を確保し、アーカイブとテストの再現性を保ちましょう。