クラウド Mac で Xcode CI/CD：GitHub Actions と Jenkins 実践ガイド

Apple ツールチェーンが macOS ハードウェアに縛られる理由

Android が Linux コンテナで Gradle を実行できるのとは異なり、iOS と macOS のデリバリーパイプラインは—— xcodebuild、codesign、notarytool、App Store Connect API—— すべて Apple 署名済みの OS とチップ上で動作する必要があります。「シミュレータを入れれば回避できる」問題ではありません： Archive と App Store 配布の証明書チェーン、Swift コンパイラの Apple Silicon 向け最適化パスは、 すべて足元に本物の Mac があることを前提としています。

そのため、iOS プロダクトを持つすべてのチームは、いつか同じ問いに答える必要があります： 誰が長期的にこの Mac を提供するのか？ よくある 3 つの道——GitHub ホスト型 macOS Runner、オフィス自社購入 Mac mini、クラウド専用ベアメタル—— 絶対的な優劣はなく、待ち時間の許容度、月間ビルド頻度、システムと証明書の専任メンテナンスの有無で差が出ます。 本記事は 3 つ目の道の技術実装に焦点を当てますが、まず他 2 つの道の境界を判断するお手伝いをします。

CI 所要時間の内訳：待機、コンパイル、署名の割合

多くのチームが「CI が遅い」と嘆きますが、総所要時間を 3 段階に分けていません： マシン待ち、ローカルコンパイル・リンク、 署名とアップロード。同一 commit で GitHub ホスト型 macos-14 Runner と ZovCloud M4 専用ノードを比較し、参考になる数値を得ました。

ホスト型 Runner はピーク時（UTC 13:00–17:00）に平均 22 分の待ち行列の後に job が開始； 実際の xcodebuild archive は 5 分 38 秒。専用 M4 ノードは待ち行列なし、 Archive フルビルド 3 分 58 秒——Swift 並行コンパイルは 10 コア M4 で旧 Intel CI マシンより速く、 16 GB ユニファイドメモリは clean build 時に swap を発生させませんでした。

痛みの本質が「push 後 30 分経ってやっとコンパイル結果がわかる」なら、ボトルネックは Xcode ではなく待ち行列にあることが多いです。 Runner を常時オンラインの専用 Mac に固定することは、フィードバックループを短縮する最も直接的な手段—— 以下第 3 節から、このマシンを再現可能なビルドベースラインに整える方法を説明します。

クラウド Mac 上で再現可能な Xcode ビルドベースラインを構築

ZovCloud が提供する Mac mini は完全な macOS がプリインストールされ、管理者権限が付与されています。開通後、SSH またはブラウザ VNC でログインし、 証明書とプロビジョニングプロファイルは固定ディレクトリ規則で保管することを推奨し、Runner スクリプトごとにパスを探す混乱を避けます。 以下 4 ステップは、新規ノード初期化時の標準チェックリストです。

1. 01
   Xcode をインストールしライセンスに同意

   App Store から Xcode 16.x をインストールし、sudo xcodebuild -license accept と xcodebuild -runFirstLaunch を実行。検証：xcodebuild -version が想定バージョンを出力；xcode-select -p が /Applications/Xcode.app/Contents/Developer を指すこと。

2. 02
   Distribution 証明書とプロビジョニングプロファイルをインポート

   .p12 を安全な経路で ~/certs/ に配置し、security import で専用キーチェーン ~/Library/Keychains/ci.keychain-db に書き込み；.mobileprovision は ~/Library/MobileDevice/Provisioning Profiles/ へ。無人ビルド時のダイアログを避けるため、codesign にパーティションリストの信頼を設定。

3. 03
   App Store Connect API Key を設定

   Apple Developer で API Key を作成し、AuthKey_XXXXXX.p8 を ~/private_keys/ に保存。TestFlight アップロードは xcrun altool または Fastlane pilot upload を使用し、対話型 Apple ID 二要素認証を完全に回避。

4. 04
   初回フル Archive を実行し DerivedData を保持

   リポジトリをクローン後、ローカルで Release Archive を 1 回実行し、署名チェーンにエラーがないことを確認。256 GB システムディスクは中規模プロジェクトに十分；DerivedData を保持すると以降の増分ビルドで約 30–45% 短縮。Swift Package 依存が多い場合は -clonedSourcePackagesDirPath でキャッシュディレクトリを指定可能。

GitHub Actions セルフホスト Runner の登録と workflow 振り分け

セルフホスト Runner 登録完了後、workflow は label で job をこのクラウド Mac に正確に配信し、 共有プールを完全に回避。操作パス：リポジトリ Settings → Actions → Runners → New self-hosted runner、 macOS ARM64 を選択し、画面の指示に従って actions-runner パッケージをダウンロード後に実行：

./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token RUNNER_TOKEN --labels macos-m4,zovcloud,ios-build --unattended

登録成功後、システムサービスとしてインストールし、ノード再起動後も Runner が自動オンラインになるように： sudo ./svc.sh install → sudo ./svc.sh start。 workflow YAML で label を指定：

runs-on: [self-hosted, macos-m4]

典型的な iOS job ステップチェーン：コードチェックアウト → CI キーチェーンのロック解除 → xcodebuild archive → xcodebuild -exportArchive → Fastlane upload_to_testflight または altool --upload-app。 M4 ノードでは push トリガーから TestFlight 処理完了（Apple 側の待ち含む）まで平均 約 10 分、 うちローカルビルドとアップロードは 5–6 分のみ。

Jenkins Agent のマウントとパイプラインの要点

チームに既存の Jenkins コントローラー（Linux 上で動作可）がある場合、macOS ビルド能力は Agent ノード経由で接続。 クラウド Mac に JDK 17 をインストールし、agent.jar をダウンロード、LaunchDaemon で常駐させ、 コントローラーが SSH または JNLP でビルドタスクを配信。

Jenkins の強みは可視化パイプラインとプラグインエコシステム：Credentials Binding でキーチェーンパスワードを注入、 AnsiColor ログ着色、ビルド成果物を Artifactory にアーカイブなど。 典型的な Pipeline は stage('Archive') で sh 'xcodebuild ...' を呼び出し、 stage('Upload') で Fastlane を呼び出します。 GitHub Actions と比べ、Jenkins はマルチブランチ、マルチ環境、人手承認ゲートが必要な社内フローに適しています。

クラウド Mac の日単位レンタルは「弾性 Agent」として使えます：リリース週にノードを開通して Jenkins をマウントし、 閑散期に解放すれば、通年 365 日サーバールーム Mac を運用する必要がありません。 DEVELOPER_DIR を固定して複数バージョン Xcode の切り替え混乱を避けることは、Jenkins 環境で最も見落とされがちな安定性のポイントです。

Archive → Export → TestFlight コマンドライン閉ループ

GitHub Actions でも Jenkins でも、最終成果物チェーンは同じ：Archive で .xcarchive 生成 → Export で .ipa 生成 → App Store Connect にアップロード。 コマンドライン方式は CI の標準手法で、Xcode GUI に依存しません。

Archive 例（Release、scheme 指定）：

xcodebuild archive -workspace MyApp.xcworkspace -scheme MyApp -configuration Release -archivePath build/MyApp.xcarchive CODE_SIGN_STYLE=Manual PROVISIONING_PROFILE_SPECIFIER="MyApp AppStore"

Export には ExportOptions.plist が必要（method を app-store に設定）：

xcodebuild -exportArchive -archivePath build/MyApp.xcarchive -exportPath build/export -exportOptionsPlist ExportOptions.plist

TestFlight アップロード（API Key 方式、無人運用向け）：

xcrun altool --upload-app -f build/export/MyApp.ipa -t ios --apiKey KEY_ID --apiIssuer ISSUER_ID

M4 の 10 コア CPU は Swift 並行コンパイルを旧 Intel CI マシンより明らかに高速化； プロジェクトに大量の Swift Package 依存がある場合、workflow で ~/Library/Developer/Xcode/DerivedData と SourcePackages ディレクトリをキャッシュし、 2 回目以降のビルドで所要時間をさらに約 3 分の 1 短縮できます。

無人環境でのキーチェーンと署名のトラブルシューティング

SSH またはヘッドレス Runner で codesign が失敗する場合、証明書期限切れではなくキーチェーン関連が大多数です。 ビルドスクリプト冒頭でロック解除と認可を固定実行することを推奨：

security unlock-keychain -p "$KEYCHAIN_PASSWORD" ~/Library/Keychains/ci.keychain-db

security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "$KEYCHAIN_PASSWORD" ~/Library/Keychains/ci.keychain-db

パスワードは GitHub Secrets または Jenkins Credentials から注入し、絶対にリポジトリに平文で書かないでください。 errSecInternalComponent エラーの場合、キーチェーンがデフォルトか、codesign が信頼リストに追加されているかを確認。 altool アップロードが認証で止まる場合、API Key の Issuer ID と .p8 ファイル名の一致、Key に「Developer」権限が残っているかを確認。

もう一つの落とし穴は Provisioning Profile と Bundle ID の不一致——Archive 段階ではエラーにならず、 Export 段階で失敗。CI に security cms -D -i profile.mobileprovision で UUID を出力するステップを追加し、 Xcode プロジェクトの PROVISIONING_PROFILE_SPECIFIER と照合することを推奨。

弾性 macOS ビルド算力：Runner をクラウド専用ノードに置くタイミング

個人開発者や小規模チームはジレンマに陥りがち：macOS ビルドが必要だが、CI マシン 1 台のためにオフィスを借り、専用線を引き、停電と OS アップグレードに対応したくない。 パブリッククラウドの Linux VM では不十分（完全な macOS と Apple 署名チェーンがない）； Mac mini を自宅に置くと上り帯域不安定、IP 変動、誤シャットダウンのリスクがある。

ZovCloud は専用物理 Mac mini M4を提供：仮想化なし、オーバーセルなし、 各マシン 16 GB メモリと 1 Gbps 専用帯域、支払い後 1–5 分で自動開通。 5つのリージョン——シンガポール、日本、韓国、中国香港、米国東部——ユーザー分布に応じて選択可能； 日本市場向け App は東京ノードを選び、TestFlight アップロード時の越境遅延を短縮。

日額 $19.8 〜、週額 $53.5、月額 $99.1、長期契約なし。 リリース集中の 1 週間にノードを開通して Runner をマウントし、日常メンテナンス期に解放すれば、通年自社購入マシン＋電気代より経済的なことが多い。 複数マシン並行 Archive が必要な場合、Thunderbolt 5 並列サービスで 80 Gbps クラスターを構成可能。大規模 monorepo や複数 App マトリクスに適しています。

1. 01
   ZovCloud でノードを選択して開通

   コンソールにログインし地域とレンタル期間を選択、支払い後 SSH 認証情報と VNC 入口が自動配信。接続チュートリアルはヘルプセンターを参照。

2. 02
   第 3 節に従い Xcode と署名ベースラインを完了

   キーチェーンパス、API Key パスを環境変数に書き込み、GitHub Actions / Jenkins が統一参照できるように。

3. 03
   Runner を登録し初回 pipeline を通す

   まず Debug ビルドでコンパイルを検証し、次に Release Archive + TestFlight に切り替え、Fastlane lane をリポジトリに固定。

iOS CI/CD のハードルは Xcode メニューバーではなく、安定して予測可能な macOS 算力 + 単一の信頼できる署名環境にあります。 公共 Runner は低頻度ビルド向き；自社サーバールームは運用能力のある成熟チーム向き； クラウド専用 Mac は「待ちたくないが、マシンも買いたくない」中間を埋めます。 コンパイルをクラウドに移せば、ローカルの MacBook はコードを書くことに専念でき、深夜に CI タスクにファンとメモリを奪われません。