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

Mac がないとき、iOS パイプラインはどこで途切れるか

多くのチームはまず Linux でユニットテストと静的解析を実行し、「CI はもう構築済み」と思い込む——TestFlight パッケージが必要になるまで気づかない：xcodebuild、codesign、notarytool、App Store Connect API はすべて Apple 署名済み macOS 上での実行が必須。Docker イメージで回避できる問題ではない：Archive 証明書チェーン、Swift コンパイラの Apple Silicon 最適化パスは、すべて実機 Mac の存在を前提としている。

したがって iOS プロダクトを持つすべてのチームは、いずれ「誰がこの Mac を長期提供するか」に直面する。一般的な選択肢は 3 つ：GitHub ホスト macOS Runner、オフィス自社購入 Mac mini、クラウド専用物理マシン。絶対的な優劣はなく、待ち時間の許容度、月間ビルド頻度、システムと証明書の専任メンテナンスの有無で差が出る。本記事は第 3 の道の技術実装に焦点を当てるが、他 2 つの適用範囲の判断も先に支援する。

ホスト Runner、自社データセンター、クラウド専用：どう選ぶか

完全な iOS ビルドを 3 段階に分解——マシン待ち、コンパイル・リンク、署名・アップロード——すると、各方式のボトルネックはまったく異なる。同一 commit で GitHub ホスト macos-14 Runner と PixVPS M4 専用ノードを比較：ホスト Runner は UTC 13:00–17:00 のピーク時に平均 22 分の待ち行列の後に job 実行開始、実際の xcodebuild archive は 5 分 38 秒；専用 M4 は待ち行列なし、Archive フルビルド 3 分 52 秒、16 GB ユニファイドメモリは clean build 時に swap 未発生。

「push してから 30 分後にコンパイル結果がわかる」という悩みなら、ボトルネックは Xcode 自体ではなく待ち行列にあることが多い。Runner を常時オンラインの専用 Mac に固定するのが、フィードバックループを最短にする最も直接的な手段。

リモート Mac ノード環境初期化 4 ステップチェックリスト

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

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

   App Store から Xcode 16.x をインストールし、sudo xcodebuild -license accept と xcodebuild -runFirstLaunch を実行。確認：xcodebuild -version で期待するバージョン番号が出力されること。

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

   .p12 を ~/certs/ に配置し、security import で専用キーチェーン ~/Library/Keychains/ci.keychain-db に書き込み。.mobileprovision は ~/Library/MobileDevice/Provisioning Profiles/ に配置。

3. 03
   App Store Connect API Key を設定

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

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

   リポジトリをクローン後、ローカルで Release Archive を一度実行し、署名チェーンにエラーがないことを確認。DerivedData を保持すると、以降の増分ビルドで約 30–45% の時間短縮が可能。

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,pixvps,ios-build --unattended

登録成功後、システムサービスとしてインストール：sudo ./svc.sh install → sudo ./svc.sh start。workflow YAML で runs-on: [self-hosted, macos-m4] を指定。典型的な iOS job ステップチェーン：コードチェックアウト → CI キーチェーンのロック解除 → xcodebuild archive → xcodebuild -exportArchive → Fastlane upload_to_testflight。M4 ノードでは push トリガーから TestFlight 処理完了まで平均 約 10 分、ローカルビルドとアップロードは 5–6 分のみ。

Jenkins macOS 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 ファイル名の一致を確認。

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

リリースサイクルに合わせたクラウドビルドマシンのレンタル

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

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

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

1. 01
   PixVPS でノードを選択して開設

   コンソールにログインし、リージョンとレンタル期間を選択。支払い後、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 タスクがファンとメモリを奪うことはない。