専有物理Mac miniを提供し、iOS/macOSチームがツールチェーン、署名環境、タスクの順序を自分たちで管理できるようにします。仮想マシンではなく、他の利用者のキューにビルドを押し込むこともありません。
日・週・月・四半期単位で利用できます。ノードの空き状況はコンソールに表示される最新情報をご確認ください。
このサービスを始めた背景には、共有CI環境で繰り返し起きる2つの課題があります。実行リソースをチームで管理できず、署名環境の独立性も保ちにくいことです。
コードを送信しても、パイプラインはコンパイルを始める前に実行環境の空きを待つことがあります。スクリプトの調整でコンパイル工程は減らせても、共有キューを自分のプロジェクト専用にはできません。工程が遅くなったのか、リソースが割り当てられていないのか、チームには判断しにくい状況です。
私たちは物理ノード1台を1テナントに割り当てています。runnerが受け付けるプロジェクトを限定し、タスクのラベル、起動条件、実行順序をチームで設定できます。他のテナントのビルドがこのマシンのキューに入ることはありません。
証明書、プロビジョニングプロファイル、Keychain、Xcodeのパス、依存関係のキャッシュがビルド環境を構成します。共有環境のクリーンアップやバージョン変更により、再現できるはずのArchiveが失敗し、手作業での調査が必要になることがあります。
専有ノードなら、チーム独自のディレクトリ構成、権限、ツールチェーンのルールを整えられます。Xcodeのバージョンを固定し、テストとリリースのタスクを分け、署名設定を記録して、ルールをパイプラインに反映できます。環境は使い捨てのブラックボックスではなく、検証・再構築できるエンジニアリング資産です。
「待ち時間をなくす」とは、他のテナントにノードを使われるのを待たずに済むという意味で、任意の数のタスクが同時に完了する保証ではありません。ビルド速度はプロジェクトの規模、依存関係のダウンロード、メモリ負荷、並列実行の設定に左右されます。まず自分のプロジェクトで検証し、構成と利用期間を決めてください。
リソースの割り当て、料金、ハードウェア仕様を明示しています。次の3つの方針は、短期の検証から長期のビルド運用まで共通です。
物理ノード1台を1テナントに割り当てます。CPU、ユニファイドメモリ、内蔵ストレージを他のテナントと共有せず、仮想マシンに分割して重複割り当てすることもありません。
複数のプロジェクトを実行できますが、タスクの並列数はチームで管理してください。まず単一タスクで基準値を取り、その後runnerの並列数を増やし、メモリ、ディスク、成果物の出力が安定しているか確認することをおすすめします。
3種類の構成それぞれについて、日・週・月・四半期の料金を掲載しています。エントリーモデルはXR Build 16で、$21.7/日です。長期間利用する場合は短期料金を単純に合算せず、該当期間の料金をご確認ください。
ストレージの拡張とThunderbolt 5の追加オプションは別料金で掲載しています。プランを比較する際は、ノードの利用料と必要なオプションを分けて確認し、お支払い前に構成の詳細を再度ご確認ください。
掲載構成はM4 / 16GB / 256GB、M4 / 24GB / 512GB、M4 Pro / 64GB / 2TBの3種類です。モデル名だけでなく、チップ、メモリ、ストレージ容量をご確認ください。
サンプルタスクの所要時間を、プロジェクトの性能保証として示すことはありません。テストでは、クリーンビルド、インクリメンタルビルド、Archiveを計測し、コード、Xcodeのバージョン、キャッシュ条件を揃えてください。
以下は代表的な利用者像をもとにしたワークフロー例で、導入事例や実測結果ではありません。各ケースで実行内容を示し、検証に適した構成をご案内します。
日中はローカル環境でSwiftUIを書き、操作をデバッグ。コードを送信したら、クラウドノードで指定ブランチを取得し、依存関係を解決してテストを実行、 xcodebuild archiveその後、署名済み成果物を書き出し、チームの手順に沿ってTestFlightにアップロードします。
まずは単一アプリ、低い並列数から始め、XR Build 16で検証しましょう。リリース用スクリプトと失敗ログを保存しておけば、翌日に問題へ対応するときも環境を推測し直す必要がありません。
XR Build 16 · M4 / 16GB / 256GB
午前中に前回の失敗ログを確認し、午後にコードをマージするとGitHubまたはGitLabのself-hosted runnerが自動で起動。ラベルでユニットテストとリリースのタスクを分け、Fastlane gymでビルド工程を管理し、アプリ、Widget、Extensionで一貫した署名設定を維持します。
複数のTarget、テスト、キャッシュを同時に扱う場合は、まずXR Build 24で検証しましょう。並列数は段階的に調整し、複数のArchiveが同じ出力先に書き込んだり、署名状態を奪い合ったりしないようにしてください。
XR Build 24 · M4 / 24GB / 512GB
午前中にMLXで小規模モデルの推論を検証し、モデル、量子化方式、メモリ使用量を記録。午後はファインチューニングを試し、チェックポイントを保存してから、必要に応じてCore MLへの書き出しを検証します。夜間にビルドする場合は、実験プロセスを終了するか、並列数を制限してください。
この用途はXR Build Pro 64から検証できます。ユニファイドメモリ64GBという構成は明確ですが、すべてのモデルを実行できるわけではありません。モデル、ランタイム、他のタスクを含めた総使用量を事前に見積もってください。
XR Build Pro 64 · M4 Pro / 64GB / 2TB
日中はmacOSのGUIでプロジェクトと素材のパスを確認し、LogicやFinal Cutに必要なソフトウェアのライセンス、プラグイン、フォントをチェック。夜間にレンダリングや一括トランスコードを実行します。完了後は成果物を書き出し、ファイルの完全性を確認してから一時キャッシュを削除してください。
大規模なプロジェクトはXR Build Pro 64で検証できますが、元素材と完成データの外部バックアップは必ず保管してください。リモート操作の快適さはローカルネットワークとノードまでの距離に左右されます。正式に移行する前に、実際の素材と接続でテストしてください。
XR Build Pro 64 · M4 Pro / 64GB / 2TB
全6拠点でApple Silicon Mac miniを提供し、構成は3種類から選べます。チームの稼働時間とネットワーク環境をもとに地域を選び、実際に接続してリモート操作を確認してください。タイムゾーンが近くても、ネットワーク遅延が小さいとは限りません。
SG · UTC+8
東南アジアのチームが日中の共同作業と夜間タスクを組みやすい拠点です。移行前にソースコードのリポジトリと依存関係の配信元へ実際にアクセスできるか確認してください。
JP · UTC+9
日本時間での共同作業を中心とするチームに適しています。CI設定にリリースタスクのタイムゾーンを明記し、定期実行がローカルのデフォルト設定に左右されないようにしてください。
KR · UTC+9
韓国および北東アジアのチームがビルドログや成果物を確認しやすい拠点です。リモートデスクトップをテストする際は、文字入力とファイル転送も確認してください。
HK · UTC+8
華南・東南アジアの稼働時間に合わせた共同作業に適しています。地域をまたいでリポジトリにアクセスする場合は、接続の安定性と依存関係のダウンロードをそれぞれ確認してください。
US-E · UTC−5 / UTC−4
北米東部のチームに適しており、西欧の稼働時間とも連携しやすい拠点です。夏時間によって現地のUTCオフセットが変わるため、定期実行ではタイムゾーンを明示してください。
US-W · UTC−8 / UTC−7
北米西海岸のチームが共同で調査やリリースを進めるのに適しています。時差のあるチームと連携する場合は、ログにUTCオフセットを残し、タスクの実行順を誤認しないようにしてください。
表示中のステータスは現在提供中のラインアップに基づきます。注文時の空き状況はコンソールに表示される最新情報をご確認ください。ノードは年間365日稼働し、ハードウェアの異常には障害対応手順に沿って対応します。
ハードウェアの問題をビルドログに紛れ込ませません。納品時に環境を確認し、利用中はアプリケーションとノードの障害を切り分けます。ハードウェア対応が必要な場合は、データと復旧の範囲を明確にしてから作業します。
チップ、メモリ、ストレージ、地域を確認し、macOSとXcodeの環境を準備します。割り当て後、コンソールでSSHとリモートデスクトップの接続情報を確認できます。チームでも管理者権限、Xcodeのパス、プロジェクトの依存関係を確認し、小規模な検証タスクが完了してから本番のパイプラインを移行してください。
ノード側では接続状況とハードウェアの稼働状態を確認します。プロジェクト側では、チームでディスクの空き容量、キャッシュの増加、タスクの失敗ログを確認してください。問題が発生したらコンソールからチケットを送信し、ノードの地域、構成、発生時刻、エラー情報をお知らせください。まずネットワーク、ツールチェーン、署名、ハードウェアの問題を切り分け、すべての失敗をビルド性能の問題と決めつけないようにします。
ハードウェアの異常を確認したら、チケットでノードの修理または交換を調整し、接続情報に変更があるか、再設定が必要なものは何かをお知らせします。チーム側ではバックアップからソースコード、依存関係、署名環境を復元し、ツールチェーンのバージョンと検証ビルドを確認してください。ハードウェアの交換はデータのバックアップではありません。確認していない成果物を復旧成功の根拠にしないでください。
チップ、メモリ、ストレージ、料金期間を確認し、自分のプロジェクトで検証してください。再現性のあるArchiveを、ビルドキュー移行の第一歩にしましょう。
お支払いはUSDT-TRC20、Visa / Mastercard / Amex（Stripe）に対応しています。米ドル建てです。利用可能な決済ゲートウェイはバックエンドの応答をご確認ください。