作業を任せても、ワークフローはそのまま

こんな作業は、
Apple Silicon搭載クラウドMacにお任せ

夜間ビルド、自動回帰テスト、モデル実験。使い慣れたツールはそのままに、実行処理を仮想マシンではない専有物理Mac miniに任せられます。

まずは検証しやすいタスクを選び、日単位で動作を確認。その後、メモリ使用量、ディスク容量の増加、タスク頻度に応じて、モデルと契約期間を決めましょう。

2つのモデル · 5拠点 · $20.2/日から。実際の空き状況はコンソールでご確認ください。

今あるタスクから始める

4つの用途、それぞれの始め方

おすすめ構成は試運転の出発点であり、性能を保証するものではありません。チップ名を見るだけでなく、ご自身のプロジェクトで試すことが大切です。

01 / BUILD

React Nativeの夜間ビルド

日中はローカルマシンで開発し、夜間のiOSビルドをクラウドに任せましょう。まず固定ブランチで実行し、Node、CocoaPods、Xcode、Fastlaneのバージョンをそろえて、既存の結果を再現できるか確認します。

まずは単一タスクのキューから始め、依存関係のロックファイルを保持します。依存キャッシュと最終成果物は別々に保存しましょう。ビルドのたびにキャッシュをすべて消したり、署名用の情報をリポジトリに保存したりしないでください。

検収では次の3点を確認します。依存関係をインストールできること、ビルドが正常終了すること、成果物を後続のテストで使えること。キャッシュなしと再ビルドの両方を試し、それぞれの所要時間を記録します。

週単位がおすすめ · リリースサイクルをカバー

Flow M4
M4 / 16GB / 256GB

Flow M4でビルドする
02 / RELEASE

Flutterのマルチプラットフォームビルド

iOSとmacOS向けのビルドを、同じmacOS環境に集約できます。Flutter SDK、Dart、Xcodeのバージョンを固定し、同じコミットをローカルとクラウドで同じビルド設定で実行しましょう。

まずは1つのターゲットから移行し、動作を確認してから対象を増やします。シミュレーター、DerivedData、依存キャッシュはディスクを継続的に使用します。必要なランタイムを残し、キャッシュの削除ルールを設定しましょう。

検収では次の3点を確認します。環境診断が通ること、対象の成果物が生成されること、ログと成果物を転送できること。複数のビルドを同時に実行する場合は、並列数を一気に増やすのではなく、Flow M4 Proを検討しましょう。

月単位がおすすめ · 開発環境を固定

Flow M4
M4 / 16GB / 256GB

Flow M4でビルドする
03 / INFERENCE

MLXでのローカル推論実験

M4 Proの64GBユニファイドメモリで、量子化モデルを検証できます。モデルのバージョン、量子化方式、コンテキスト長、テスト入力を決めてから試しましょう。モデルがメモリに収まるか判断する際は、ランタイムとキャッシュの使用量も考慮してください。

実験ごとにPython環境を分けましょう。モデルの重み、ダウンロードキャッシュ、実験結果は別々のディレクトリに保存します。モデルファイルが多い場合は、+2TB SSDの追加を検討すると、再ダウンロードによるシステムディスクの圧迫を避けられます。

検収では次の3点を確認します。モデルを読み込めること、ピーク時のメモリ使用量が許容範囲内であること、固定入力での処理性能を再現できること。まず日単位で検証し、問題がなければ四半期契約を検討しましょう。ストレージを増やしてもユニファイドメモリは増えません。

まずは日単位で検証 · 問題なければ長期利用

Flow M4 Pro
M4 Pro / 64GB / 2TB

Flow M4 Proで実験する
04 / TEST

XCUITest回帰テスト

固定のテストスイートを専用ノードで実行すれば、回帰テストが日常の開発作業とローカルリソースを奪い合うのを防げます。Xcode、シミュレーターランタイム、テストデバイスの構成を固定し、まずは逐次実行で検証してから、並列数を段階的に増やしましょう。

テスト結果のパッケージ、失敗時のスクリーンショット、対応するコミット番号を毎回保存します。テストにGUIセッションが必要な場合は、実行条件を事前に確認してください。SSHで接続できても、すべてのUIテストがそのまま実行できるとは限りません。

検収では次の3点を確認します。繰り返し実行しても結果が安定すること、失敗の記録がそろっていること、並列実行時にメモリの余裕があること。クラウド上のシミュレーターテストに、実機テスト用デバイスは含まれません。

週単位がおすすめ · 回帰テストを一巡

Flow M4 Pro
M4 Pro / 64GB / 2TB

Flow M4 Proでテストする
まずは並列実行を検証してから切り替え

3段階でローカルのタスクを移行

データ、ツールチェーン、CIを分けて検証しましょう。問題が起きたら、その段階に戻って確認すればよく、すべてを同時に変更する必要はありません。

01 · データ

まずコードとキャッシュを移行

ローカルMac

プロジェクト、依存関係のロックファイル、必要なキャッシュ、成果物のディレクトリを洗い出します。一時ファイルや不要なビルド成果物を除外し、まず別途バックアップを作成しましょう。

クラウドMac

プロジェクト用のディレクトリを作成し、rsyncで差分転送します。プロジェクトやキャッシュの容量が大きい場合は、+1TB SSDまたは+2TB SSDの追加をご検討ください。追加ディスクの実際のマウント先は、マシン上でご確認ください。

接続先としてMAC_HOSTを設定して実行

rsync -av --progress ./ "$MAC_HOST:~/workspace/"

引き継ぎ完了の確認:ファイルの読み書きができ、ディレクトリ権限が正しく、重要なファイルのチェックサムが一致すること。rsyncによる同期は独立したバックアップの代わりにはなりません。初回の移行では、転送先のファイルを削除するオプションを有効にしないでください。

02 · ツールチェーン

バージョンの違いを一つずつ解消

ローカルMac

Xcodeとコマンドラインツールのバージョンを記録し、Homebrewの依存関係一覧をエクスポートします。キーチェーンにある証明書のうち、タスクに必要なものを整理し、アクセス権限と用途を確認しましょう。

クラウドMac

必要なツールをインストールしてバージョンを選択し、一覧に沿って依存関係を復元します。署名情報は管理された方法でキーチェーンに取り込み、想定したセッションからコマンドラインタスクでアクセスできることを確認してください。ロック解除用パスワードをログに書き込まないでください。

開発ツールとパスを確認

xcodebuild -version
xcode-select -p

引き継ぎ完了の確認:同じコミットと同じ設定でビルドできること。まず一連のコマンドを最初から最後まで実行してから、自動化に進みましょう。未検証の環境をいきなり既定の実行先に設定しないでください。

03 · CI連携

新しいラベルで試し、従来の経路を残す

ローカルMac

既存のパイプライン設定を保存し、ビルド、テスト、アーカイブ、アップロードの手順を洗い出します。ハードコードされたローカルパスをワークディレクトリ変数に置き換え、切り戻し時に復元する実行ラベルを明確にしましょう。

クラウドMac

self-hosted runnerを登録し、専用ラベルと最小限の権限を設定します。まずテストブランチを新しいノードに割り当て、成果物のアップロードとログの転送を確認してから、本番パイプラインのラベルを切り替えましょう。

GitHub Actionsの実行先ラベルの例

runs-on: [self-hosted, macOS, ARM64, cloud-build]

引き継ぎ完了の確認:タスクが新しいノードで実行され、結果を追跡でき、認証情報が出力に含まれていないこと。信頼できない外部コントリビューターのコードから、署名情報を含むrunnerに直接アクセスさせないでください。

名前ではなく、ボトルネックで選ぶ

まずメモリを決め、ストレージと連携を検討

軽量なビルドならFlow M4から。並列ビルドやMLXにはFlow M4 Proをご検討ください。複数台での連携は別の構成であり、複数台を大容量メモリの1台として使えるわけではありません。

2つのモデルの用途と試運転で確認するポイント
タスクとボトルネック おすすめの構成 利用期間の目安 試運転で確認すること
軽量ビルド、単一タスクのキュー Flow M4
M4 / 16GB / 256GB
リリースを週単位でカバー。安定して使えるようになったら月単位を検討。 キャッシュなし/キャッシュありの所要時間、ピーク時のメモリ使用量、ビルドディレクトリの増加。
並列ビルド、複数のシミュレータータスク Flow M4 Pro
M4 Pro / 64GB / 2TB
まず日単位で並列実行を検証し、その後、テストスイート全体を週単位で実行。 タスク数を段階的に増やし、メモリ負荷、テストの安定性、ディスク書き込みを確認。
MLX量子化モデルの推論 Flow M4 Pro
M4 Pro / 64GB / 2TB
日単位で試し、モデルの適合を確認してから月単位または四半期契約を選択。 モデルの重み、コンテキスト、実行キャッシュの合計使用量と、固定入力での処理性能。
プロジェクト、モデル、キャッシュがディスクを多く使用 必要なメモリに応じてモデルを選び、+1TB SSDまたは+2TB SSDの追加も検討。 選択した契約期間で追加料金を確認。 保存先、マウント先、空き容量、独立したバックアップの有無。
複数ノードで分担して連携 単一マシンでのタスクに合わせて選び、Thunderbolt 5での連結を検討。料金はマシンごとに発生します。 必要なソフトウェアと接続要件を先に検証し、その後で長期契約を検討。 タスクの分割方法とデータ転送方法。連結してもユニファイドメモリが自動的に統合されるわけではなく、ソフトウェアが自動で分散実行されるわけでもありません。

ノードの選び方

シンガポール、日本(東京)、韓国(ソウル)、香港、米国東部の5拠点から選べます。どちらのモデルも利用可能です。対話型の作業にはユーザーに近い拠点、自動ビルドにはコードや成果物の転送経路も考慮しましょう。

試運転の記録方法

コミット番号とツールのバージョンを固定し、準備、ビルド、テスト、アップロードにかかった時間をそれぞれ記録します。同じ入力と環境で比較しなければ、一度速く完了しただけでは、長期的なタスクに適しているとは判断できません。

移行の目標を具体化

移行は少なく、検証は丁寧に

「既存のワークフローを実行できる」「実験で適合性を確認できる」など、検収可能な目標を一文で定めましょう。達成できたら、次の投資を検討できます。

「CIをローカルマシンからソウルのノードに移行。パイプラインのラベルを1行変更するだけで動きました。」

React Nativeチームのエンジニア

「まず日単位で借りてMLXを試し、十分だと確認してから四半期契約に切り替えました。」

AIプロダクトのプロトタイプ開発者

用途を1つ選んで、まず試してみる

プロジェクト、入力データ一式、検収基準を用意しましょう。まずタスクを動かし、どこまでクラウドに任せるかを決められます。

日・週・月・四半期単位から選べます。お支払いはUSDT-TRC20、またはStripe経由のVisa / Mastercard / Amexのみ。米ドル建てです。実際に利用できる決済ゲートウェイはコンソールでご確認ください。