Xcode CloudとリモートMac CIの選び方

Xcode CloudとリモートMac CIの選び方

📋 目次

Apple Developer Programには、Xcode Cloudの計算時間が毎月25時間含まれています。Apple公式のXcode Cloud概要にあるこの条件だけを見れば、標準的なiOS開発ではXcode Cloudを先に試す判断が合理的です。

症状： 標準ビルドは動くのに、社内依存や特殊なスクリプトでCIが止まる。
最短解決： 標準検証はXcode Cloud、私有ネットワークや常駐処理はリモートMac CI、中規模チームは二軌道で分けます。

独立開発者、iOS・iPadOS・macOSチームの責任者、DevOps担当者、リリースエンジニアが対象です。単純な機能比較ではなく、あなたのワークロードをどちらへ置くべきか、検証条件と撤退条件まで整理します。

Xcode CloudとリモートMac CIの判断を先に固定する

次の4点を確認すると、比較を機能一覧から運用判断へ変えられます。

  • ソースコードは一般的なGitホスティングか、社内ネットワーク内か
  • Xcode以外に固定したいツールや管理者権限があるか
  • ビルドごとに環境を作り直せるか、永続キャッシュが必要か
  • CIの仕事は短時間の検証か、常駐プロセスを含む長時間処理か

標準的なXcodeプロジェクト、一般的な依存関係、TestFlight配布が中心ならXcode Cloudを優先します。Appleは、Xcode Cloudでビルド、テスト、解析、アーカイブ、TestFlight配布をワークフローとして組み合わせられると説明しています。ワークフローの公式仕様も確認してください。

一方、社内サービスへの接続、固定された証明書ストア、独自CLI、長時間のバックグラウンド処理が中核なら、完全なMacホストを管理できるリモートMac CIが向いています。

判断軸 Xcode Cloud リモートMac CI 判断スコア
標準XcodeビルドとTestFlight 設定が速く、適性が高い 構築作業が必要 Xcode Cloud
私有ネットワークと内部依存 接続元許可と経路設計が必要 VPNや固定経路を設計しやすい リモートMac
一時環境での再現性 毎回クリーンな検証に向く 初期化設計が必要 条件次第
永続キャッシュと専用ツール 制約を受けやすい root権限で調整しやすい リモートMac
並列テスト Appleの環境を利用できる ノード数と容量を自分で管理 用量次第
運用負荷 低め 更新、監視、復旧が必要 Xcode Cloud

ここでのスコアは性能ランキングではありません。構築責任と制約の少なさを、あなたの作業内容に照らして評価するための目安です。

標準的なApp StoreフローならXcode Cloudを先に試す

独立開発や小規模チームで、1つまたは少数のAppleプラットフォーム用アプリを管理しているなら、まずXcode Cloudで代表的なワークフローを作ります。

Apple公式要件では、Apple Developer Programへの登録、Xcode 15以降、App Store Connect上のアプリレコード、共有スキーム、アーカイブ可能な構成などが必要です。利用開始の要件を先に確認してください。

Xcode Cloudの強みは、ビルド環境を自分で常時稼働させなくてよいことです。ソースコードを取得し、依存関係を解決し、ビルドやテストを実行した後、環境を破棄する仕組みです。最初のワークフローに関するAppleの説明では、成果物やログは取得できますが、ビルド環境そのものを長期利用する構成ではないことが示されています。

この方式が合う条件は明確です。

  • Swift Package Managerや一般的な外部依存で構成されている
  • ビルド前に特別な管理者権限を必要としない
  • プルリクエスト、mainブランチ、TestFlight配布を中心にする
  • ビルド後の成果物を外部ストレージやApp Store Connectへ保存できる

注意点は、成果物の保管をCIに任せきりにしないことです。Xcode Cloudのビルド成果物は最大30日間取得できますが、リリース版のアーカイブやdSYMは別の保管先へ移してください。成果物の保存期間に関する公式説明を運用手順に反映します。

多分岐・並列テストでは待ち時間よりキューを測る

チームのコミット頻度が高く、複数ブランチや複数デバイスを検証する場合、単一ビルドの実行時間だけを比較してはいけません。見るべきなのは、キュー待ち、キャンセル、再実行、並列数、失敗からの復旧です。

Xcode Cloudでは、テスト対象を増やすほど実行量と完了までの時間が変わります。Appleは、複数のデバイス構成を並列にテストできる一方、すべてのブランチ変更でUIテストを実行する設計は現実的でない場合があると説明しています。アクションとテストの公式仕様にある自動キャンセルや開始条件も確認してください。

次の状態なら、Xcode Cloudの使用量やワークフローを調整します。

  • 古いコミットのビルドが新しいコミットを待たせている
  • 毎回すべての端末を検証し、計算時間が標準確認を圧迫している
  • PR用の軽いテストとリリース用の重いテストが同じワークフローに混在している

次の状態なら、独立したリモートMacノードを追加します。

  • 特定のXcodeやツールチェーンを固定したい
  • 並列ジョブの分離を自分で制御したい
  • 夜間の定時ビルド、キャッシュ準備、成果物処理を常時実行したい

リモートMac側では、ノードを増やす前にラベル設計を決めます。例えば、ios-standard、ios-release、macos-privateのように用途を分けると、誤ったジョブが特殊環境へ流れにくくなります。自前Runnerのラベルによるジョブ振り分けは、公式のRunnerラベル仕様で確認できます。

私有依存と特殊ツールチェーンはリモートMacへ寄せる

Xcode Cloudは、社内Gitや自己管理型のGitサービスにも接続できます。ただし、Appleが案内する接続元IP範囲をファイアウォールで許可し、必要な権限を整える必要があります。Appleのプロジェクト要件には、自己管理型ソース管理サービスへの接続条件が記載されています。

これは「接続できるか」と「運用上安全か」を分けて考えるポイントです。社内パッケージレジストリ、秘密管理サービス、専用APIへ複数経路で接続する場合、許可する通信先を増やすほど調査対象も増えます。

Xcode Cloudのカスタムビルドスクリプトは有効ですが、永続ホスト上のシェルと同じ感覚で扱えません。Appleの説明では、スクリプトは一時ビルド環境で実行され、作成したファイルは後続スクリプトや次回ビルドにそのまま残る前提ではありません。カスタムビルドスクリプトの仕様に沿って、必要なファイルをリポジトリや外部保管先から明示的に取得します。

次の条件が2つ以上あるなら、リモートMac CIを優先して検証してください。

  • 内部APIや制限付きパッケージレジストリへの接続が必要
  • 特定ディレクトリに大きなキャッシュを保持したい
  • macOS上に専用CLIやライセンス済みツールを常駐させたい
  • 証明書、プロビジョニングプロファイル、秘密鍵の保管場所を細かく管理したい
  • ビルド後もサーバー上で別処理を続けたい

ただし、root権限はメリットであると同時に事故範囲を広げます。署名資産をジョブごとに分離し、ログへ秘密情報を出さず、失敗時にノードを初期化できる手順を作ってください。

クロスプラットフォームと常駐処理は二軌道に分ける

iOSチームのパイプラインにLinuxのAPIテスト、コンテナ処理、複数リポジトリのオーケストレーションが含まれる場合、Macだけで全工程を処理する設計は避けます。

標準のAppleビルドとTestFlight配布はXcode Cloudへ送り、Linux側のテストや社内サービス連携は既存のCIへ残します。特殊なApple署名、専用Xcode、Mac上のリリーススクリプトだけをリモートMac CIへ振り分けると、環境ごとの責任範囲が明確になります。

自前Runnerは自由度が高い一方、Runnerアプリの稼働、OS更新、監視、ログ保管が必要です。GitHubの公式ドキュメントでも、本番の自動スケールでは使い捨てRunnerが推奨され、永続Runnerにはセキュリティと再利用時のリスクがあると説明されています。自前Runnerの運用指針を参考に、固定Macを使う場合もジョブ後の清掃と復旧を設計してください。

常駐プロセスについては、CIジョブと分離します。キャッシュウォームアップ、定時タスク、成果物の中継を同じRunnerへ詰め込むと、ビルド失敗の原因調査が難しくなります。ビルドノードと運用ノードを分けるか、少なくともプロセスごとに監視と再起動条件を設定します。

第一歩：二軌道の小規模検証を実施する

全面移行ではなく、代表的なコミットと同じ依存ロックファイルを使って比較します。次の順番で記録してください。

  1. PR用の通常ビルドを選び、Xcode Cloudで成功ログと計算使用量を保存します。
  2. 同じコミットをリモートMac CIで実行し、待ち時間、実行時間、失敗内容を分けて記録します。
  3. UIテスト、アーカイブ、署名、TestFlight配布を別ジョブとして比較します。
  4. キャッシュを削除した状態と、キャッシュを復元した状態を分けて確認します。
  5. ノード再起動後にRunnerが自動復帰し、同じジョブを再実行できるか確認します。
  6. 私有依存を使うジョブだけ、接続失敗時のログ、復旧手順、担当者の作業時間を記録します。
  7. 成功率、キュー待ち、計算使用量、保守作業、失敗復旧の5項目で月次レビューします。

標準ジョブの比率が高く、私有依存が少ないならXcode Cloudを主系にします。反対に、定制ジョブが多く、固定環境や社内経路が重要ならリモートMac CIを主系にします。どちらにも該当するなら、PR検証をXcode Cloud、署名・リリース・特殊処理をリモートMacへ分ける二軌道が安全です。

FAQ

Xcode Cloudと自前のMac CIは小規模チームならどちらが向いていますか？

標準的なXcodeプロジェクトをビルドし、テスト結果を確認してTestFlightへ配布するだけなら、環境構築と保守を抑えやすいXcode Cloudが候補です。社内サービス、固定IP、専用ツール、常時稼働する処理がある場合は、最初からリモートMac CIを検証してください。

Xcode Cloudから社内ネットワークや内部依存へ接続できますか？

接続できるかは、社内Git、パッケージレジストリ、秘密管理サービスがAppleの接続元を許可できるかで決まります。自己管理型のソース管理サービスへ接続することは可能ですが、任意の社内ネットワークへ自由に入れる前提ではありません。

リモートMac CIは長時間のカスタムビルドスクリプトに使えますか？

適しています。ただし、Macを常時稼働させるだけでは不十分です。Runnerの再起動、ログ保存、証明書の隔離、キャッシュ破損時の初期化、macOSとXcodeの更新手順まで決めてから運用してください。

Xcode Cloudの計算使用量と固定Macノードはどう比較すべきですか？

Xcode Cloudは実行したビルドやテストの計算時間を追跡し、固定Macノードは稼働時間と保守作業を含めて評価します。月間使用量だけで決めず、待ち時間、復旧時間、キャッシュ再構築、担当者の作業時間を同じ表で比較してください。

iOSチームはXcode Cloudと自前Runnerを同時に使えますか？

併用できます。プルリクエストの標準ビルドや一般的なテストをXcode Cloudへ置き、社内依存、特殊な署名処理、リリース前の専用ジョブを自前Runnerへ送ります。ジョブをラベルやブランチで分け、成果物の管理先を統一してください。

現在のCI構成からリモートMacへ移す判断

Linux中心のCIや自前のMac mini構成は、既存のスクリプトを流用しやすい反面、Apple専用ツールチェーンを別途維持しなければなりません。さらに、物理ホストでは故障、OS更新、ディスク不足、同時実行数の制約が発生し、社内に置く場合は電源、回線、アクセス制御まで担当する必要があります。

短期のリリース対応、検証用ノード、固定環境が必要なチームなら、MacDateのMacレンタル料金ガイドやMac miniの料金案内で現在利用できる期間と構成を確認し、代表的なXcodeジョブを実際に流して判断するのが安全です。仮想環境との違いを整理したい場合は、ベアメタルと仮想macOSの比較も、署名やツール互換性の確認材料になります。

常時安定した大量ジョブを長期運用し、物理インターフェースや専用ネットワークが必要なら、自社保有のMacが適する場合もあります。反対に、期間限定の開発、増設前の検証、リリース専用ノードが目的なら、MacDateのリモートMacを一時的な検証環境として使い、実測ログを取ってから本構成を決める方が、先に高額な固定設備を抱えずに済みます。