パイプラインはそのまま、実行環境を置き換え

クラウドMacで、いつものパイプラインを実行

macOSが必要なビルドやテストを、専有物理Mac miniに移行できます。ネイティブiOS、Flutter、Unity、MLXでは、それぞれリソースのボトルネックが異なります。まずコマンドと前提条件を確認し、メモリ、キャッシュ、並列実行数に合わせてプランを選びましょう。実際に使えるワークフローを紹介します。ベンチマーク結果ではありません。

専有物理マシンで、仮想マシンではありません。1日単位でレンタルでき、料金は $20.5/日から。利用可能状況はコンソールの最新情報をご確認ください。

ワークロードから探す

全5件のシナリオを表示中です。カテゴリを選ぶと該当項目が強調表示され、その位置に移動します。他の項目も引き続き表示されます。

トリガーから成果物の確認まで

実行したい工程を見つける

以下のコマンドはノード上で実行します。プロジェクトの依存関係をインストールしてから、対応する環境変数を設定してください。パスはご自身のプロジェクトや設定ファイルに合わせます。コピーされるのはコマンドのみで、タスクは実行されません。

ネイティブiOS · 夜間ビルド

Gitへのpushでarchiveを作成し、アップロードはfastlaneで実行

クラウドMacをGitHub Actionsのself-hosted runner、GitLab Runner、またはJenkins agentとして登録します。リリースブランチへのpush後、固定したコミットをチェックアウトし、Release archiveとIPAを生成します。TestFlightへのアップロードは別工程にすることで、ビルド失敗とアップロード失敗を分けて再実行できます。

事前に準備するもの

  • 次の環境変数を設定します。 WORKSPACE、SCHEME 、 EXPORT_OPTIONSを、それぞれワークスペース、共有scheme、エクスポート設定に指定します。
  • 署名証明書とプロビジョニングプロファイルを、現在のビルドユーザーに設定します。fastlane matchで管理し、復号用の認証情報はCIのシークレットから渡せます。
  • 次の環境変数を設定します。 ASC_API_KEY_JSONには、fastlaneで使用するApp Store Connect APIキーのJSONファイルを指定します。キーをコードリポジトリに保存しないでください。

成果物の確認ポイント

次の成果物を確認します。 build/App.xcarchive、エクスポートしたIPA、コミット識別子、Xcodeのバージョンを保存します。該当バージョンがTestFlightに届いたことを確認してください。ビルドコマンドが正常終了しても、アップロード完了とは限りません。

この構成を選ぶ理由:Host M4 Plusは24GBのユニファイドメモリを搭載し、複数targetの日常的なビルドに適しています。まずは逐次実行で動作を確認し、メモリ負荷とDerivedDataの使用量を見てから並列数を増やしましょう。

archive → export → upload
set -euo pipefail
: "${WORKSPACE:?Set WORKSPACE}"
: "${SCHEME:?Set SCHEME}"
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"
: "${ASC_API_KEY_JSON:?Set ASC_API_KEY_JSON}"

mkdir -p build
xcodebuild -version
xcodebuild \
  -workspace "$WORKSPACE" -scheme "$SCHEME" \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  -archivePath build/App.xcarchive archive

xcodebuild -exportArchive \
  -archivePath build/App.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist "$EXPORT_OPTIONS"

IPA_PATH="$(find build/export -type f -name '*.ipa' -print -quit)"
test -n "$IPA_PATH"
bundle exec fastlane pilot upload \
  --ipa "$IPA_PATH" \
  --api_key_path "$ASC_API_KEY_JSON"
使用プラン:Host M4 Plus · M4 / 24GB / 512GB 推奨ノード:日本(東京)
Host M4 Plusをレンタル

クロスプラットフォーム · Flutter

AndroidはLinuxで実行し、iOSの工程だけ移行

両OSのパイプライン全体を移す必要はありません。AndroidタスクはLinux runnerに残し、クラウドMacでCocoaPods、Xcodeビルド、IPAのエクスポートを実行します。両方で同じコミット識別子を使い、最後に成果物をまとめます。片方が失敗した場合は、その側のタスクだけを再実行できます。

キャッシュの有効条件を設定

  • Flutter、Ruby、CocoaPods、Xcodeのバージョンを固定し、以下を保存します。 pubspec.lock、Podfile.lock 、 Gemfile.lock。
  • PubとCocoaPodsのダウンロードディレクトリをキャッシュします。キャッシュキーには、少なくともツールチェーンのバージョンと依存関係ロックファイルのハッシュを含めてください。
  • 複数の並列タスクから同じプロジェクトディレクトリに書き込まないでください。DerivedDataと出力先をタスクごとに分け、キャッシュの競合を防ぎます。

成果物の確認ポイント

以下を保存します。 build/ios/ipa 内の署名済みIPA、ビルドログ、依存関係ロックファイルを保存します。デバイスへのインストールまたは後続のテストタスクで成果物を検証してから、ビルド結果をリリース可能として扱いましょう。

この構成を選ぶ理由:Host M4 Liteは、単一タスクから始めるのに適しています。シミュレーターを起動しながらテストとパッケージ作成を行う場合は、まずピーク時のメモリ使用量を測りましょう。並列数をすぐに増やすのではなく、必要に応じてHost M4 Plusを検討してください。

Flutter · iOSジョブ
set -euo pipefail
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"

flutter --version
xcodebuild -version
flutter doctor -v
bundle check || bundle install
flutter pub get

(
  cd ios
  bundle exec pod install --deployment
)

flutter build ipa \
  --release \
  --export-options-plist="$EXPORT_OPTIONS"

find build/ios/ipa -type f -name '*.ipa' -print
使用プラン:Host M4 Lite · M4 / 16GB / 256GB 推奨ノード:シンガポール
Host M4 Liteをレンタル

ゲーム · iOSパッケージ

Unityからエクスポートしたプロジェクトを受け取り、署名、パッケージ作成、サイズ確認を実施

Unityのアセット処理とXcodeのビルドは別工程です。まずプロジェクト固有のエクスポート手順でXcodeプロジェクトを生成し、その後クラウドMacでarchiveとexportを実行します。パッケージサイズを比較する際はアセット設定を統一し、差分がアセット、ビルドオプション、エクスポート方法のどこから生じたかを確認できるようにします。

エクスポートの範囲を明確にする

  • UNITY_IOS_DIR には、エクスポート済みのiOSプロジェクトディレクトリを指定します。以下のコマンドはXcodeの工程から実行するもので、プロジェクトのUnityビルドスクリプトを置き換えるものではありません。
  • プラグインがworkspaceを生成した場合は、 UNITY_WORKSPACEを設定します。生成されていない場合は、 Unity-iPhone.xcodeprojを使用します。2つの入口を混在させないでください。
  • 署名設定と EXPORT_OPTIONSを準備します。App Thinningレポートが必要な場合は、エクスポート設定で該当するレポートオプションを有効にしてください。

成果物の確認ポイント

IPAファイルのサイズ、エクスポートログ、アセットの変更を確認します。IPAの圧縮サイズは、ユーザーが実際にダウンロードまたはインストールするサイズとは異なります。リリースの判断には、エクスポートレポートと配信時の処理結果も確認してください。

この構成を選ぶ理由:Host M4 Proは64GBのユニファイドメモリと2TB SSDを搭載し、大規模なアセットプロジェクトやアーカイブキャッシュに適しています。アセットのインポート、コンパイル、エクスポート各工程の使用量を記録してから、タスクキューを設計しましょう。

Unity export → Xcode
set -euo pipefail
: "${UNITY_IOS_DIR:?Set UNITY_IOS_DIR}"
: "${EXPORT_OPTIONS:?Set EXPORT_OPTIONS}"

mkdir -p build
if [ -n "${UNITY_WORKSPACE:-}" ]; then
  xcodebuild -workspace "$UNITY_WORKSPACE" \
    -scheme Unity-iPhone -configuration Release \
    -destination 'generic/platform=iOS' \
    -archivePath build/Game.xcarchive archive
else
  xcodebuild \
    -project "$UNITY_IOS_DIR/Unity-iPhone.xcodeproj" \
    -scheme Unity-iPhone -configuration Release \
    -destination 'generic/platform=iOS' \
    -archivePath build/Game.xcarchive archive
fi

xcodebuild -exportArchive \
  -archivePath build/Game.xcarchive \
  -exportPath build/game-export \
  -exportOptionsPlist "$EXPORT_OPTIONS"

find build/game-export -type f -name '*.ipa' \
  -exec du -h {} \;
使用プラン:Host M4 Pro · M4 Pro / 64GB / 2TB 推奨ノード:韓国(ソウル)
Host M4 Proをレンタル

ネイティブiOS · 互換性テスト

Xcodeのバージョンを固定し、シミュレーターのテストマトリクスを順に実行

新しいOSへの対応は、コンパイルが通るだけでは不十分です。主要なナビゲーション、権限ダイアログ、ダークモード、重要なレイアウトをテストに含め、Xcodeのバージョンとシミュレーターランタイムごとに結果を保存しましょう。まずはテストマトリクスを再現可能な逐次実行にし、並列化するテストを見極めます。

バージョンとデバイスを追跡可能に

  • xcodesで複数のXcodeバージョンを管理できます。各タスクで DEVELOPER_DIR を設定してバージョンを選び、並列実行中にマシン全体のデフォルトのツールチェーンを変更しないようにします。
  • まず現在のXcodeで利用できるシミュレーターを確認し、 SIM_A と SIM_B にそれぞれ異なるデバイスのUDIDを設定します。実行前に各シミュレーターをインストールしておいてください。
  • 以下を保存します。 .xcresultを保存し、ターミナルの最後の1行だけに頼らないでください。UIスクリーンショット、失敗したテストケース、再試行の記録を同じコミットに紐付けます。

成果物の確認ポイント

各ターゲットのテスト終了コードと結果バンドルを個別に確認します。シミュレーターでの回帰テストだけでは、実機の周辺機器、パフォーマンス、配信の検証はできません。これらは別途実施してください。

この構成を選ぶ理由:Host M4 Plusは、日常的な回帰テストを始めるのに適しています。実行できるシミュレーターの数は実際のメモリ負荷で決まります。24GBでも無制限に並列実行できるわけではありません。

Xcode · シミュレーターマトリクス
set -euo pipefail
: "${DEVELOPER_DIR:?Set DEVELOPER_DIR}"
: "${WORKSPACE:?Set WORKSPACE}"
: "${SCHEME:?Set SCHEME}"
: "${SIM_A:?Set SIM_A}"
: "${SIM_B:?Set SIM_B}"
export DEVELOPER_DIR

mkdir -p build
xcodebuild -version
xcrun simctl list devices available

RUN_ID="$(date +%s)-$$"
for DEVICE_ID in "$SIM_A" "$SIM_B"; do
  xcodebuild test \
    -workspace "$WORKSPACE" \
    -scheme "$SCHEME" \
    -destination "platform=iOS Simulator,id=$DEVICE_ID" \
    -parallel-testing-enabled NO \
    -resultBundlePath \
      "build/$RUN_ID-$DEVICE_ID.xcresult"
done
使用プラン:Host M4 Plus · M4 / 24GB / 512GB 推奨ノード:香港
Host M4 Plusをレンタル

AI · MLX推論実験

ユニファイドメモリにモデルを読み込み、安定して動作するかを確認

Apple Silicon搭載の物理ノードでMLXを使い、対応モデルを読み込んで生成速度、ピークメモリ使用量、コンテキスト長を記録します。まずは単一リクエストで検証し、次にバッチ処理を試しましょう。ビルドタスクと推論実験は同じマシンのリソースを共有するため、測定せずに同時にフル稼働させないでください。

モデルとリソースの条件を確認

  • MODEL_DIR には、準備済みのMLX対応モデルディレクトリを指定します。モデルの入手元、利用ライセンス、量子化形式、依存関係のバージョンを確認してください。
  • 64GBはマシン全体で共有するユニファイドメモリです。システム、モデルの重み、キャッシュ、他のプロセスもメモリを使用します。モデルとコンテキストの設定によって、読み込み可能かどうかが決まります。
  • プロンプトと生成する長さを固定し、初回起動と以降のリクエストを分けて記録します。モデルのダウンロード時間を推論スループットに含めないでください。

成果物の確認ポイント

モデルのバージョン、量子化設定、MLX環境、実行ログを保存します。 /usr/bin/time -l でプロセスの使用量を確認し、システムのメモリ負荷と合わせてスワップの発生を判断します。

この構成を選ぶ理由:Host M4 Proの64GBユニファイドメモリは、より大きなメモリを必要とする実験に適しています。2TB SSDはモデルファイルや実験の成果物を保存するためのもので、モデルが利用できるメモリ容量は増えません。

MLX · ローカル推論
set -euo pipefail
: "${MODEL_DIR:?Set MODEL_DIR}"

python3 -m venv .venv
. .venv/bin/activate
python -m pip install mlx-lm
mkdir -p build

python -m pip freeze > build/mlx-environment.txt
/usr/bin/time -l \
  python -m mlx_lm.generate \
    --model "$MODEL_DIR" \
    --prompt "Explain reproducible builds." \
    --max-tokens 128 \
    > build/mlx-output.txt \
    2> build/mlx-metrics.txt

cat build/mlx-output.txt
cat build/mlx-metrics.txt
使用プラン:Host M4 Pro · M4 Pro / 64GB / 2TB 推奨ノード:米国西部
Host M4 Proをレンタル

コマンドをコピーしたら、ご自身のプロジェクトディレクトリで変数と署名設定を確認してから実行してください。

構成は目安であり、性能を保証するものではありません

実際のタスクで構成を調整

上記のノードはチームの稼働時間帯をもとに提案しています。ネットワーク遅延を実測した結果ではありません。リポジトリ、成果物の保存先、作業者の所在地も使い勝手に影響します。

01

リソースのピークを記録

コミットと依存関係のバージョンを固定し、タスクを一通り実行します。メモリ負荷、キャッシュサイズ、成果物のサイズを個別に記録し、1回のコンパイル時間だけでプランを選ばないようにしましょう。

02

キュー待ちと実行を分けて考える

まずは実行器を1つにして使います。タスクが安定してから並列数を増やし、runnerの待機時間、依存関係のダウンロード時間、コンパイル時間をそれぞれ記録してください。

03

チームの作業環境に近いノードを選ぶ

シンガポール、日本(東京)、韓国(ソウル)、香港、米国西部の5か所から選べます。まずプロジェクトの同期とリモート接続を確認し、その後チームの実行拠点を決めましょう。

成果物の確認基準を決める

明日の朝、何を確認できる状態にしますか?

以下は3つの役割を想定した利用目標であり、顧客の評価や実測記録ではありません。1回のビルドを速くするだけでなく、目標をパイプラインの受け入れ基準にすることが大切です。

「朝には該当コミットのアーカイブ、テスト結果、失敗ログが揃っていて、オフィスのビルド用マシンを確認しに行かなくても済む状態にしたいです。」
iOS開発責任者 · 夜間ビルドの目標
「FlutterのiOS工程だけを移行します。両OSで同じコミットを使い、失敗した側だけを再実行できるようにしたいです。パイプライン全体を作り直す必要はありません。」
モバイルアーキテクト · パイプライン分割の目標
「モデルのバージョン、メモリ使用量、生成結果をまとめて記録したいです。実験を再現できれば、次に使うマシンも根拠を持って選べます。」
機械学習エンジニア · 推論実験の目標

実行する工程を決めてから、マシンを選ぶ

単一タスクの開始にはHost M4 Lite、複数targetのビルドや日常的な回帰テストにはHost M4 Plus、大規模プロジェクトやメモリ負荷の高い実験にはHost M4 Proが適しています。プランページで3つの構成、4種類のレンタル期間、オプションを確認してからお申し込みください。

料金はすべて米ドルです。お支払いにはUSDT-TRC20、Visa / Mastercard / Amex(Stripe)のみご利用いただけます。利用可能な決済ゲートウェイはバックエンドから返される情報をご確認ください。