チームの作業を専用環境で

待ち行列のCIパイプラインを
専用Macへ移行

Apple Silicon搭載M4 Mac miniを1台まるごと1社で利用。PRチェック、夜間アーカイブ、リモートXcodeを同じ管理されたツールチェーンで実行でき、他の利用者とCPUを奪い合うこともありません。

macOSビルド環境を借りる移行の3ステップを見る

M4構成は2種類 · $20/日から · 専用物理マシン、仮想マシンではありません

チーム専用の実行環境

PRコミットをチェック
Testビルドと単体テスト
Archiveアーカイブと配布

専用なのはマシン全体です。チーム内のタスク並列数や優先順位は、runnerの設定で決まります。

タスクを分けてから、リソースを割り当てる

4つの作業を用途別に整理

まずマシンの主な用途を決めてから、メモリとストレージを選びましょう。開発作業、リリースアーカイブ、モデル実験には同じ種類のノードを使えますが、制限なく1台を共有するのには向いていません。

用途1 · PRチェック

コミットごとにビルドと単体テストを実行

単一プロジェクトのCI、SwiftUIの小規模アプリ、オフィスのビルドマシンを移行したいチームに適しています。PRごとにコードをチェックアウトし、依存関係を復元して単体テストを実行。結果は既存のCIプラットフォームに返します。

Merge M4 Sから始めるのがおすすめです。Apple Silicon M4、16GB RAM / 256GB SSDを搭載。マシン全体を1社で使えるため、ビルド時に他の利用者がCPUコアを使うことはありません。チーム内のタスクには並列数の上限を設定し、複数のビルドによるメモリ不足を防ぎましょう。

最初のパイプラインは3つだけ

リポジトリのコミット、依存関係のロックファイル、Xcodeのバージョンを固定します。
まずは1つのschemeでビルドと単体テストを実行します。
待ち時間、ビルド、テストの各段階を記録し、時間がかかる箇所を特定します。

構成の目安：複数のtargetやシミュレーターでの並列テストでメモリ使用量が大きく増える場合は、24GB構成を検討しましょう。チームの人数だけで必要なマシン数を決める必要はありません。

Merge M4 Sを借りる

用途2 · 毎日のリリース

nightlyアーカイブはリリース用ノードへ

テストビルドの毎日生成、定期アーカイブ、Fastlaneによる自動ビルドを行うチームに適しています。既存のlaneを活用し、アーカイブ、書き出し、TestFlightへのアップロードを1つのリリースタスクにまとめられます。

Merge M4 Lがおすすめです。Apple Silicon M4、24GB RAM / 512GB SSDを搭載。エントリー構成よりメモリと内蔵ストレージに余裕があり、複数プロジェクトの依存関係や必要なシミュレーターランタイムを保存できます。ビルドへの効果はプロジェクトやキャッシュの状態によって異なります。

リリースタスクに専用のゲートを設ける

専用のrunnerラベルを使い、通常のPRがアーカイブの実行時間を占有しないようにします。
CIのシークレットから証明書、プロビジョニングプロファイル、配布に必要な認証情報を注入します。
アーカイブ成功後にログと成果物を保存し、ルールに従ってローカルファイルを整理します。

構成の目安：ノードは365日、継続して稼働します。定期タスクの実行やアップロードの成否を確認できるよう、CIプラットフォームで失敗通知と再試行を設定してください。

Merge M4 Lを借りる

用途3 · リモート開発

手元にMacがなくてもXcodeを使える

VNCの画面共有でmacOSのGUIを使い、Xcodeでプロジェクトの確認やビルドエラーの調査、シミュレーターの実行ができます。SSHではコマンドラインビルド、ファイル同期、runnerの管理が可能です。

Xcode、シミュレーター、開発ツールを同時に使う場合は、Merge M4 Lを検討しましょう。GUIとCIタスクが同じ物理マシンのリソースを使うため、対話型のデバッグと自動アーカイブの時間をずらすか、別のノードに分けることをおすすめします。

接続を確認してから、プロジェクトを移行

コンソールでインスタンスの接続情報を確認し、まずSSHとVNCで接続できるか試します。
リモート画面の解像度を下げ、入力やウィンドウ操作の応答を確認します。
小規模なプロジェクトでXcodeとシミュレーターを試してから、本番プロジェクトを同期します。

利用範囲：クラウド環境はビルド、署名、シミュレーターでのテストに適していますが、手元のiPhoneに直接アクセスできるわけではありません。ローカル端末への接続が必要な作業は別途残してください。

SSH・VNCの接続方法を見る

用途4 · AI実験

MLX実験のリソースを計画

Apple Silicon上でMLXによるローカル推論を実行し、量子化モデルや小規模モデルのファインチューニング手順を検証できます。まず小さなモデルで動作する基準を作り、コンテキスト長、バッチサイズ、学習データの規模を段階的に増やしましょう。

Merge M4 Lに+2TB SSDオプションを追加し、モデルの重み、データセット、チェックポイントの保存に活用するのがおすすめです。24GB RAMは実行時のメモリ容量、追加SSDはファイルの保存容量です。互いに代用することはできません。

モデルファイルのサイズだけでなく、最大使用量も確認

モデルの読み込み、推論、ファインチューニングの各段階でメモリ使用量のピークを記録します。
ダウンロード、展開、チェックポイント保存に必要なディスク容量も確保します。
同じマシン上のCI並列実行を一時停止し、リソース競合で実験結果が左右されないようにします。

構成の目安：モデルがメモリに収まるかどうかは、量子化精度、コンテキスト、実行方法にも左右されます。+2TB SSDオプションでメモリは増えず、あらゆるモデルの動作が保証されるわけでもありません。

Merge M4 Lと拡張ストレージを選ぶ

マシンが専用でも、タスクを無制限に並列実行できるわけではありません。まず同時実行数を制限し、メモリのピーク、ディスクの空き容量、タスクの待ち時間を確認しましょう。リリースタスクに安定した実行時間が必要なら、すべてを1つのキューに集めるのではなく、runnerの役割を分けるのがおすすめです。

依存関係に沿って移行を進める

環境を再現してから、パイプラインを切り替える

最初から既存のビルドマシンを撤去しないでください。データ、ツールチェーン、CI連携の順に移行し、新旧環境で同じコミットを実行します。成果物とログを確認してから、本番タスクを切り替えましょう。

01 · データ

プロジェクト、署名情報、キャッシュを分けて移行

リポジトリからプロジェクトとサブモジュールを再度チェックアウトし、依存関係のロックファイルを保持します。ローカルの作業ディレクトリ全体をコピーして、そのまま再現可能な環境として使わないようにしましょう。
- 証明書とプロビジョニングプロファイルは管理された方法で転送し、パスワードはCIのシークレットに保存します。
- Xcodeのバージョン、依存関係のロックファイル、アーキテクチャごとにキャッシュキーを分けます。
- 再利用できることを確認したキャッシュだけを移行します。古いDerivedDataは必須の入力データとして扱いません。
確認項目：指定したコミットをチェックアウトでき、署名ファイルの場所が分かり、機密情報がリポジトリに含まれていないこと。
02 · ツールチェーン

バージョンは記録し、記憶に頼らない

Xcode、Homebrew、Ruby、CocoaPodsのバージョンを揃えます。まずプロジェクト内のバージョン指定ファイルを確認し、移行と同時に依存関係をアップグレードして問題の原因が混在しないようにしましょう。
```
xcodebuild -version
xcode-select -p
uname -m
ruby --version
bundle exec pod --version
```
確認項目：arm64環境、選択中のXcodeのパス、依存関係のバージョンを確認してから、1つのschemeでローカルのコマンドラインビルドを実行します。
03 · CI連携

まずテストタスクを接続し、その後リリースを追加

既存のプラットフォームにself-hosted runnerまたはagentを登録し、ノードに分かりやすいラベルを設定します。GitHub Actionsでは次のラベルを使用できます。ほかのプラットフォームでは、それぞれのスケジュール設定を使ってください。
```
runs-on:
  - self-hosted
  - macOS
  - ARM64
  - macos-m4
```
確認項目：同じラベルで実際に登録され、テスト用ブランチのジョブが新しいノードで実行され、ログと成果物を取得できること。本番へ切り替える前に、元のrunnerへ戻す設定を残します。

登録トークンや署名情報をサンプルコマンドや公開ログに含めないでください。ノードの変更後は、CIプラットフォーム上のrunnerの稼働状況、タスクラベル、実行条件を確認し、すべて正しいことを確認してからチームで使い始めましょう。

runnerの接続・トラブルシューティング

移行結果を検証できる形に

チームの定例で同じコミットを比較

ビルド時間は同じ条件で比較しましょう。キャッシュヒット時とキャッシュミス時の結果を分け、ダウンロード、再試行、テスト範囲の変更をハードウェアの差と混同しないようにします。

チームの定例でビルドログと移行記録を確認する、ノートPCでの開発風景 — 開発チームの連携をイメージした写真です。ビルドの比較にはチーム自身のCIログを使用してください。この画像は導入事例や性能の証明を示すものではありません。

条件を固定

コミットハッシュ、Xcodeのバージョン、scheme、テスト対象デバイス、依存関係のロックファイルを記録します。比較前にテスト範囲が変わっていないことを確認します。

工程ごとに計測

待ち時間、依存関係の取得、ビルド、テスト、アーカイブ、成果物の転送を分けて確認します。マシンを専有することで他の利用者とのリソース競合はなくなりますが、ネットワーク転送はなくなりません。

切り戻し手段を残す

元のrunnerラベルとパイプライン設定を保存します。新しい環境で繰り返し実行できることを確認してから、旧ノードでの本番タスクを停止しましょう。

用途に合わせて構成を選ぶ

PRチェックは16GBから。複数のtarget、シミュレーター、リリースアーカイブには24GBを検討しましょう。プランページで構成、4種類の課金期間、ストレージオプションを確認し、チーム専用の実行環境を用意できます。

構成一覧を見るクラウドMacを今すぐ借りる

待ち行列のCIパイプラインを専用Macへ移行