AWS CodeBuild macOS 予約容量は何台必要？2026年企業コストモデル

AWS公式の料金説明では、macOSビルド用の予約容量Fleetは、ノードを設定している期間も料金計算の対象です。つまり、ビルドが少ないからといって、実行時間だけを支払う構成にはなりません。AWS CodeBuildの公式料金を前提に、開発者数ではなく、ピーク到着率、1件の占有時間、許容待ち時間、障害冗長性から台数を決めてください。

症状： 構築頻度は高くないのに、予約ノードの費用が継続して発生する。
最短解決： 1か月分のキュー履歴をシナリオ別に分解し、安定負荷は最小Fleet、低頻度ピークはリモートMacを含む混合容量へ切り替えます。

対象となる担当者

AWS CodeBuildのmacOS予約Fleetに予算を申請し、台数と費用の根拠を説明するIT責任者、FinOps担当者向けです。複数のiOSプロジェクトを管理し、共有容量と署名分離の両立を求める開発生産性責任者にも適しています。

リリース時だけ負荷が跳ね上がり、固定Fleet、弾性のあるリモートMac、混合構成のどれを選ぶか迷っている技術責任者は、後半の分岐条件から確認してください。

日常ビルドと保底容量

開発者数ではなく負荷を採取する

「開発者が何人いるか」は、macOSビルド容量の直接的な入力値ではありません。同じ人数でも、プルリクエストの発生時刻、テスト対象、キャッシュ命中率、再実行率によって必要な並列数が変わります。

最初にCIログから、次の項目を時間帯別に抽出します。

• タスクの到着数と到着時刻
• 1件ごとのMac占有時間
• キューに入ってから開始するまでの待ち時間
• 失敗後の再実行数
• Xcode、依存ライブラリ、署名、アップロードの各工程
• ノード停止、起動待ち、保守による利用不能時間

Fleetの容量は、同時に処理できるビルド数を決めます。AWSのFleet属性に関する公式説明でも、容量と並列処理の関係が示されています。予約容量Fleetの仕様を確認し、単純な平均値だけで台数を決めないでください。

保底台数の変数式

日常負荷の概算は、次の変数で作ります。

平均同時占有数 ＝ 時間帯別の到着率 λ × 平均占有時間 t

保底ノード数 ＝ 切り上げ（ピーク同時占有数 × 再実行係数）
                 ＋ 保守・障害用の冗長ノード数

ここでλは単位時間あたりの到着率、tは1ビルドのMac占有時間です。許容待ち時間を短くするほど、平均同時占有数に近い台数では足りません。ピークの到着が短時間に集中する場合は、時間帯別の最大値を使ってください。

平均利用率が低く見えても、毎朝やリリース前に待ち行列が伸びることがあります。日次平均ではなく、15分や30分など自社のキュー監視単位で、目標待ち時間を守れるかを判定します。

リリースピークと弾性容量

日常のプルリクエスト、夜間回帰、TestFlight配布、正式リリースは、同じ「ビルド」として一括集計しないでください。発生時刻、署名の有無、アップロード先、失敗時の再実行方法が異なるためです。

たとえば、日常検証は待ち時間を許容できても、正式リリースは短い時間枠の中で署名、アーカイブ、アップロードを終える必要があります。ここでピーク専用ノードを通年保持すると、リリース日以外の空き容量にも料金が発生します。

AWS CodeBuild macOSの料金方式、最低利用時間、利用可能な計算タイプは、契約前に公式料金ページとFleetの利用可能なリージョン・計算タイプで再確認します。費用を推計するときは、単価に稼働時間を掛けるだけでなく、予約期間、空き時間、ピーク対策、再実行、運用担当者の確認工数を変数として残します。

共有Fleetとプロジェクト境界

複数のiOSプロジェクトを同じAWS CodeBuild Fleetへ載せると、固定容量の利用率を高めやすくなります。ただし、作業ディレクトリの削除だけでは、前のジョブが残したグローバル状態や認証情報を完全に消せません。

共有の可否は、次の4項目で判定してください。

1. リポジトリと依存関係の信頼度が同じか
2. キャッシュを共有しても情報漏えいにならないか
3. Keychainや証明書の権限を同じ境界で扱えるか
4. VPC内の内部サービスへ同じアクセス権を与えてよいか

プロジェクト設定、環境変数、サービスロールの確認には、CodeBuildプロジェクト環境の公式ドキュメントを使います。IAM権限は、ビルド成功だけでなく、Secrets Manager、アーティファクト保存先、署名関連操作まで含めて棚卸ししてください。IAMアクセス制御の公式説明に沿って、プロジェクト単位の権限境界を記録します。

専用Fleetの空き容量だけを見ると共有が有利に見えます。しかし、共有後に増えるキャッシュ破損、クリーニング、監査、再実行、誤った署名操作の影響もコストです。信頼度の低い検証コードと本番署名を同じMacプールへ送る設計は、利用率のためにリスクを買う形になるため避けます。

署名・私網依存と独立容量

VPC内の依存サービス、Secrets Manager、内部パッケージ、Apple署名証明書を使うビルドは、通常の検証Fleetと同じ境界に置かない方が管理しやすい場合があります。特に、外部コードを取得するジョブへ本番署名環境のネットワーク到達性を与えると、共有による節約より監査負担が大きくなります。

普通の検証プールと信頼済みリリースプールについて、別々に次を算出します。

プロキシ経由の通信には制約があります。CodeBuildのマネージドプロキシに関する公式説明を確認し、内部依存や署名アップロードが同じ経路で成立するかを実ジョブで検証してください。macOSのランタイムやイメージ境界も、利用可能なランタイム一覧と自社のXcode要件を照合します。

障害冗長性と復旧可能性

1台構成は、ビルドが正常なときの費用だけなら小さく見えます。しかし、そのノードの保守、起動待ち、障害、リージョン制約が重なると、継続的なiOS CI/CDの待ち時間を守れません。

次の記録を容量モデルに加えてください。

• ノードが利用可能になるまでの実測時間
• 直近の停止、失敗、再実行の履歴
• Xcodeや依存キャッシュを再構築する時間
• 署名証明書とSecretsの再設定手順
• 別リージョンまたは別方式へ切り替える時間
• 復旧演習で実際に完了したビルド数

AWSのmacOS対応範囲やFleetの提供条件は変わり得るため、料金、最低利用時間、対応リージョン、イメージを定期的に再確認します。単一Fleetで保守と継続配信を同時に満たせないなら、予備ノード、別方式の容量、または短期間で引き渡せるリモートMacを比較対象に入れます。

容量選択の分岐条件

次の条件で、固定、混合、見直しの順に判断します。

• ピーク負荷が平日ごとに発生し、待ち時間の目標を継続して守れない場合は、日常検証用の最小予約Fleetを増やします。
• ピークは低頻度で、通常時間の空きが多い場合は、増設前にリモートMacを含むPoCへ戻します。
• 本番署名と一般検証の権限境界が異なる場合は、利用率が下がっても独立プールを選びます。
• 単一障害でリリース期限を失う場合は、予備容量または別方式の復旧経路を追加します。
• Fleetの利用率は高いが、キュー待ちが目標内の場合は、すぐに増設せず、再実行とリリースピークだけを分離します。
• Xcode更新、プロジェクト増加、署名方式変更がある場合は、過去の台数を継続せず、ログを取り直します。

MacDateのリモートMac料金案内やベアメタルと仮想macOSの比較は、固定Fleet以外の検討軸を整理するときに参照できます。ここで重要なのは、リモートMacを最初からAWS CodeBuildの代替と決めつけることではなく、ピーク、署名、復旧という特定シナリオで成立するかを実ジョブで確認することです。

四半期レビューの判定軸

毎月のキューと請求を保存し、四半期ごとに次の変化を確認します。

• 許容待ち時間を守れない時間帯が増えた
• 予約ノードの空き時間が継続して増えた
• リリースや署名の同時実行数が変わった
• プロジェクト間の信頼度や権限境界が変わった
• Xcode、ランタイム、内部依存の更新で占有時間が変わった
• 障害復旧演習の結果が目標を下回った

固定容量は、安定した高利用率の土台には向いています。一方、構築頻度が低く、ピークが明確なチームは、予約ノードを増やす前に周期的なリモートMac容量を試す方が、空きノードの費用を抑えられる可能性があります。

結論と次の作業

まず1か月分のAWS CodeBuildログから、日常検証、夜間回帰、TestFlight、正式リリース、署名分離、障害復旧を分けてください。開発者数だけで台数を申請せず、ピーク到着率、占有時間、待ち時間、再実行、冗長性を変数として保底容量を算出します。

現在のCodeBuild予約Fleetは、安定負荷には向いていますが、低頻度のリリースピークでも空き時間の料金が続くこと、容量変更に準備と検証が必要なこと、署名用の専用プールを持つと利用率が下がることが弱点です。こうした条件なら、MacDateのリモートMacを周期的に追加するPoCで、実際のXcodeビルド、署名、アップロード、復旧手順を確認すると、固定容量だけでは見えない費用境界を比較できます。