まずApp Store Connectからチームとアプリの使用量記録を取り出し、ワークフロー別に需要を見積もってください。単一ビルドの壁時計時間からcompute hoursを推定せず、実際の並行処理を含む記録で補正するのが基本です。安定していてXcode Cloudの環境に合うタスクは継続し、使用枠が合わない作業や環境制御が必要な作業だけ、遠隔Macまたは混合運用を検討します。
企業IT担当者：iOS CI/CDの予算を、説明可能な容量根拠とともにまとめたい方に向けています。
開発効率担当者：ワークフローや並行実行による使用量の変動を把握したい方に役立ちます。
FinOps・購買担当者：契約上の使用枠とチームの実際の需要を照合したい方に適しています。
使用量見積もりの基準をそろえる
Xcode Cloudのcompute hoursは、ビルド画面に表示される経過時間と同じものとは限りません。Appleは使用量をcompute hoursで扱い、ビルド時間と計上される時間が異なる場合があると説明しています。したがって、壁時計時間に一定の係数を掛ける方法ではなく、チームの記録を見積もりの出発点にします。AppleのXcode Cloud使用量に関する説明で計測の考え方を確認できます。
ここで見積もる対象は、Xcode Cloud上で実行されるCIワークフローです。開発者が手元のXcodeで作業した時間は含めず、PR検証、テスト、アーカイブ、リリースなど、実行された作業単位を分けて扱います。
| 指標 | 記録・確認する内容 | 見積もりでの使い方 |
|---|---|---|
| compute hours | チームまたはアプリに記録された使用量 | 月次需要と契約枠を照合します |
| 壁時計時間 | ビルド開始から完了までの経過時間 | 待ち時間や開発体験を把握します。使用量の代用にはしません |
| ビルド実行 | 対象アプリ、ワークフロー、実行結果 | 実行頻度と作業種別を整理します |
| 並行処理 | 実行時のワークフロー構成と並列設定 | 設定変更前後の実績を比較します |
App Store Connectではチームおよびアプリ単位の使用量傾向を確認し、CSVを書き出せます。利用できる表示項目や期間を確認したうえで、データを予算用の基準期間にそろえてください。用量データの確認とCSV書き出しを参照できます。
App Store Connectの用量記録をワークフローに結び付ける
アプリ別の集計だけでは、どの作業が使用量を押し上げているか判断しにくい場合があります。ビルド実行の記録とワークフロー情報を突き合わせ、識別できる範囲で実行を用途別に整理します。ワークフローのAPI資料とビルド実行のデータ説明は、記録を照合する際の確認先になります。
次の項目をそろえると、後から見積もりを再現しやすくなります。
- 集計対象期間とタイムゾーン
- 対象アプリと除外したアプリ
- ワークフロー名と用途の分類
- ビルド実行の識別情報、実行結果、取得できた時間情報
- CSVの取得日、取得元、欠損や分類できなかった実行
- Xcode Cloudの契約上の使用枠と、その確認元
特に、ワークフロー名の変更やアプリ追加を記録しないまま期間比較すると、実際の負荷変化と分類変更が混ざります。記録に存在しない値を平均時間で補わず、「未分類」や「データなし」として残すほうが監査と予算説明に適しています。
ワークフロー別の負荷を組み立てる
Xcode Cloudの使用量見積もりでは、実行回数と作業内容を分けて扱います。PR検証が増えた月とリリース作業が集中した月では、同じアプリでも負荷の内訳が異なるためです。Xcode Cloudのワークフローリファレンスを参照しながら、実際のチーム設定と記録に対応付けます。
| ワークフロー種別 | チーム記録から集める項目 | 予測に反映する変数 |
|---|---|---|
| PR検証 | 起動条件、対象ブランチ、実行回数、処理内容 | PR件数、再実行の有無 |
| 自動テスト | テスト対象、実行方法、実測使用量 | テスト変更、実行頻度 |
| アーカイブ | 起動条件、対象構成、ビルド実行記録 | リリース予定、対象構成の変更 |
| リリース | アーカイブ後の処理、実行頻度、関連ワークフロー | 公開予定、追加された検証工程 |
見積もりには、ワークフローごとの実績使用量と、見込み実行回数を使います。
月次見込み = Σ（ワークフロー別の見込み実行回数 × そのワークフローの実績に基づく1回あたり使用量）＋並行実行の補正
この式の「1回あたり」は全チーム共通の値ではありません。十分な実行記録がない場合は、該当するワークフローの記録範囲と件数を明記し、根拠のない平均値で精度を装わないようにします。Appleの初回ワークフロー設定手順も参照し、実際のトリガーと処理内容に沿って分類してください。
並行テストと月次使用量の関係を検証する
並行処理を使う場合、単一ビルドの壁時計時間だけではcompute hoursを読み取れません。実行するテストやワークフローの構成が変われば、経過時間と計上される使用量の関係も変わり得ます。並行数をそのまま固定倍率として見積もりに掛けるのではなく、設定変更前後の記録で影響を確かめます。
並行設定を変更する場合は、変更日と対象ワークフローを記録し、同じアプリ・同じ分類の実績を比較してください。リリース集中やテスト内容の変更が重なった期間は、並行設定だけの影響として扱わないことが重要です。
App Store Connectの集計とビルド実行記録を照合し、並行設定の変更時期、対象作業、compute hoursの変化を一緒に残します。変更前後で実行頻度やテスト範囲が違う場合は、その差も補正要因として記載します。Appleの使用量説明が示す壁時計時間との違いを踏まえ、時間だけを見て処理能力や使用量を決めないようにします。
月次枠と予算の不足リスクを見える化する
予測は単一の値ではなく、通常月とリリースが集中する月、チームや実行頻度が増えた場合に分けて示します。各ケースの前提を明記し、契約上の使用枠に対する見込みの割合と、不足が見込まれる条件を併記すると、購買判断につなげやすくなります。
- 保守ケース：実行頻度やテスト範囲が減る根拠がある場合だけ反映します。
- 基準ケース：直近のワークフロー別実績と計画上の変更を使います。
- 高負荷ケース：リリース集中、PR増加、テスト追加など、想定する増加要因を明記します。
Appleの公式プランページで、予算作成時点の利用可能なプラン、使用枠、価格条件を確認してください。金額や対象条件は変更される可能性があるため、古い社内資料の値をそのまま転記せず、確認日と参照先を予算資料に残します。Xcodeのバージョン適合性も、Appleのシステム要件で利用時点の条件を照合します。
遠隔Mac CIへ移す条件を切り分ける
Xcode Cloudの使用枠が足りないように見えても、すぐに全ワークフローを移す必要はありません。月次使用量の不足だけでなく、環境をどこまで制御したいか、私有依存をどう扱うか、失敗時の復旧や保守を誰が担うかを合わせて判断します。
- Xcode Cloudを継続：実績が安定し、必要なビルド・テストを現在のワークフローで扱える場合です。
- 一部を遠隔Macに移行：特定の作業だけ使用枠との不一致が続く場合や、独自の環境制御が必要な場合に候補となります。
- 混合運用：標準的な検証はXcode Cloudに残し、環境制約や高負荷のある作業だけを別ノードで試す方法です。
| 判断軸 | Xcode Cloudを継続する場合 | 遠隔Mac・混合運用を検討する場合 |
|---|---|---|
| 使用量 | 実績が契約枠に収まり、変動も説明できる | 不足が特定のワークフローに偏っている |
| 環境 | 現在のワークフロー設定で要件を満たす | 独自ツールや環境制御の要件を再現できるか要検証 |
| 私有依存 | 現行の接続方法で必要な処理を実行できる | 接続・資格情報・ネットワーク条件の検証が必要 |
| 運用責任 | 実行環境の運用負担を抑えたい | ノードの保守、監視、障害対応を担う体制がある |
| コスト | プランと実績使用量で予算を説明できる | レンタル費用に運用工数と予備容量を加えて比較する |
遠隔Mac CIの総費用は、利用料金だけで決まりません。ノードの利用期間、稼働させる作業、監視・復旧にかかる人件費、アイドル時の容量も含めて試算します。RUVCLOUDの料金情報を確認し、社内のXcode Cloud実績と同じ期間・対象作業にそろえて比較してください。Appleの現行プラン金額と遠隔Macの費用を同一条件で確認できない場合は、節約額や削減率を先に置かず、未確定の変数として残します。
予算化前の確認リスト
- [ ] App Store Connectからチームおよび対象アプリの用量記録を取得します。
- [ ] 集計期間、対象アプリ、タイムゾーン、CSVの取得日を記録します。
- [ ] ビルド実行をPR検証、テスト、アーカイブ、リリースに分類します。
- [ ] ワークフロー名やトリガーの変更、未分類データを明記します。
- [ ] compute hoursと壁時計時間を別の指標として集計します。
- [ ] 並行設定の変更前後を、同じ分類の実績で比較します。
- [ ] 通常月と高負荷月の前提を分け、契約枠との使用量カバー率を算出します。
- [ ] 遠隔Macを比較する場合は、費用だけでなく環境制御と運用責任も確認します。
使用量記録があれば、Xcode Cloudを継続する範囲と、別環境で検証すべき作業を分けて説明できます。一方、壁時計時間だけで作った見積もりには根拠が不足し、環境を移す場合もノード管理や復旧対応という別の負担が加わります。まず実績を基準に不足条件を特定し、遠隔Mac CIの候補を小さく試す場合は、RUVCLOUDの利用方法と申込み情報で条件を確認したうえで、既存のCI記録と比較できる検証範囲を決めてください。