低保守で短期の検証、または利用量が安定しないなら、まずGitHub-hosted macOS runnerを評価してください。継続的なビルドや独自環境が必要なら、自前Macの機器費用だけでなく、保守、待機、障害復旧まで加えて比較するのが適切です。
iOS／macOSチームの責任者：Xcode CIの予算と安定性を見直したい方に向けています。
プラットフォームエンジニア：runnerの構成と保守責任を決めたい方に向けています。
個人開発者・小規模チーム：AppleプラットフォームのCIを無理のない形で運用したい方に向けています。
Xcode 27 GitHub Actions runnerのコストを判断する前提
GitHubはXcode 27のrunnerイメージについて、macOS 27上で動作するpublic previewとして告知しており、対象はGitHub-hosted macOS runner、対応アーキテクチャはarm64のみです。これは利用可能性や価格が今後も同じであることを意味しません。導入前にGitHubのXcode 27 runner告知、runnerイメージのソフトウェア一覧、GitHub Actionsの最新料金説明を確認してください。
比較では、単発の実行料金だけでなく、ビルド待ち、環境更新、失敗時の再実行を同じ対象期間にそろえて扱います。ホスト型は環境準備の負担を抑えやすく、自前Macは環境やアクセス方法を調整しやすい一方、機器を継続して管理する責任が発生します。
| CIの状況 | まず評価する構成 | 判断の理由 | 先に確認すること |
|---|---|---|---|
| 短期の受け入れ検証、利用量が不安定 | GitHub-hosted runner | Macの準備や待機管理を自分たちで抱えずに始めやすい | Xcode 27イメージの提供状況、料金、依存ソフト |
| ビルドが継続し、環境を細かく管理したい | 自前Mac | 必要なツールやアクセス制御を運用要件に合わせやすい | 更新担当、障害対応、待機時間を含む総費用 |
| 標準テストと固定環境が混在 | 混合runner | 作業ごとに適した実行先を分けられる | ジョブの分類、署名情報の扱い、切替時の手順 |
Xcode 27のrunnerイメージが選択できることと、プロジェクトのビルドから署名、配布、リリース確認までが通ることは別の確認事項です。特に署名資格情報やプロビジョニングプロファイルは、runner選定と切り分けて検証してください。
コストを構成する項目
GitHub-hosted runnerの費用は、公式のrunner料金と課金説明で現在の単価と課金条件を確認したうえで計算します。自前Macは機器代だけでなく、初期設定、システム更新、監視、復旧に使う担当者の時間も含めます。
| 費用項目 | GitHub-hosted runner | 自前Mac |
|---|---|---|
| ビルド実行 | 実行時間と現行の公式料金から算出 | 機器の利用費またはレンタル費を計上 |
| アイドル・待機 | 課金条件に沿って対象時間を確認 | ビルドがない時間も占有する場合は費用に含める |
| 環境の維持 | runnerイメージとインストール済みソフトの変更を確認 | macOS、Xcode、依存ツールを更新・検証 |
| 監視・障害復旧 | ジョブの失敗や提供状況を監視 | 機器、接続、ディスク、runnerプロセスの復旧を担当 |
| 再実行 | 失敗ジョブの再実行分を集計 | 再実行時間に加え、原因調査と環境復旧の工数を集計 |
| セキュリティ | 権限、トークン、成果物の取り扱いを設計 | それらに加え、MacへのアクセスやOS管理も担う |
GitHub-hosted runnerは、実行のたびに環境がどう用意されるか、イメージに必要なソフトが含まれているかを確認する必要があります。自前構成では、runnerの登録だけでなく、更新をいつ適用し、問題が起きたとき誰が復旧するかを決めておかないと、表に出ない運用負担が残ります。GitHubの自前runner運用資料では、self-hosted runnerの構成や運用上の前提が説明されています。
利用量と保守を含めた比較式
まず、比較する期間を決め、CIログからビルド時間、同時実行数、失敗後の再実行時間を集計します。集計対象をそろえたら、次の式に実際の値を入れてください。
GitHub-hosted runnerの総費用
＝ Σ（runner種別ごとの課金対象時間 × 現行の公式単価）＋再実行分の費用
自前Macの総費用
＝ 機器費用またはレンタル費用＋初期設定工数＋更新・監視工数＋障害復旧工数＋待機分の費用＋再実行に伴う費用
ここでいう「工数」は、担当者が設定、更新、調査、復旧に使った時間です。人件費として換算する場合は、自社の実コストを使い、根拠のない一律単価は置かないでください。ホスト型でも失敗後の再実行が多ければ実行費用が増え、自前Macでも未使用時間や復旧待ちが長ければ、見かけの時間単価より総費用が高くなることがあります。
| 評価項目 | GitHub-hosted runner | 自前Mac | 混合runner |
|---|---|---|---|
| 短期導入のしやすさ | 高い | 低め | 中程度 |
| 環境の自由度 | イメージと設定の範囲で調整 | 高い | ジョブごとに選択 |
| 保守担当の必要性 | 比較的抑えやすい | 継続して必要 | 対象ジョブに応じて必要 |
| アイドルの扱いやすさ | 利用量に応じて評価 | 未使用時間も費用化しやすい | 自前側の占有を限定できる |
| 独自ツール・固定環境 | 適合性の事前確認が必要 | 要件に合わせやすい | 標準外のジョブだけ分離 |
| 評価 | 短期・変動負荷に向く | 安定負荷・独自要件に向く | 要件が混在するチームに向く |
この表の評価は測定結果ではなく、運用条件に基づく選び分けです。実際のコストは、GitHub Actionsの制限事項や現在の料金条件、実際のジョブログを合わせて判断してください。
CIタスク別の構成選び
短期検証や一時的なビルドでは、GitHub-hosted runnerから試すのが合理的です。自前Macの調達や環境整備を先行させずに済みますが、Xcode 27のpreview中は、必要なジョブを実行できることとイメージの変更有無を確認してから採用してください。
継続的なビルド負荷では、対象期間の実行時間に加え、ピーク時の同時実行や待ち時間も記録します。ビルド量が安定していて専用環境を長く占有するなら、自前Macの費用を比較する価値があります。ただし、負荷が一定に見えても、Xcodeや依存ツールの更新時に発生する検証作業と、失敗時の復旧担当を見落とさないでください。
独自の依存関係やアクセス制御が必要なプロジェクトでは、自前Macの自由度が有利になる場合があります。その代わり、OS更新、runnerの監視、アクセス権の棚卸し、機器の故障対応までチームの責任範囲になります。self-hosted runnerに秘密情報を渡す設計では、GitHubのActions安全利用ガイドを参照し、実行権限やワークフローの信頼境界を確認してください。
シミュレーター、署名、リリース確認は、ひとつの「CI成功」にまとめず工程ごとに合格条件を定義します。シミュレーターでのテスト結果、署名に使う資格情報、生成物の保管、配布後の確認を個別に検証してください。開発用プロビジョニングプロファイルの作成条件は、Appleの開発用プロファイル手順で確認できます。プロファイルが作成できたことだけでは、アプリの署名や配布フロー全体が正常とは限りません。
構成を決める条件分岐
- 環境を長期保守する担当者を置けず、利用量も読みにくいなら、まずGitHub-hosted runnerを評価します。必要なXcodeイメージと課金条件を確認できない場合は、採用を確定せず、現行のrunnerで要件を検証します。
- ビルドが継続し、独自ツールや固定環境が必要で、復旧担当も確保できるなら、自前Macの総費用を算出します。機器費だけで採算を判断せず、更新・監視・待機・故障対応を含めます。
- 標準ジョブはホスト型で処理できる一方、署名や特殊な依存関係のあるジョブだけ環境制約があるなら、混合runnerを候補にします。ジョブの振り分けと資格情報の分離を実装できない場合は、分割を急がず単一構成で再評価します。
実データで費用を確定する手順
- 比較期間を決め、CIのジョブログから成功・失敗の実行時間、再実行、並列ジョブ、待ち時間を抽出します。想定値ではなく、実際の利用記録を使います。
- Xcode 27が必要なジョブを特定し、GitHubの告知とrunnerイメージ一覧で、previewの状態、対応アーキテクチャ、インストール済みソフトを確認します。
- GitHubの料金ページで現在のrunner単価と課金条件を確認し、期間中の対象時間に当てはめます。過去の料金や紹介記事の金額を現行価格として転用しないでください。
- 自前Mac側は、機器費用またはレンタル費用、準備工数、更新、監視、障害復旧、未使用時間を同じ期間で集計します。実際の見積もりや担当者の工数記録がない項目は空欄にし、推測値で埋めません。
- 同じビルド量と成果物要件で両案を比較し、署名、シミュレーター、配布確認の合格条件も照合します。実行費用が低くても、必要なリリース工程が通らない構成は候補から外します。
- 利用量が増減した場合の再計算条件を決めます。runnerのpreview終了、イメージ変更、料金改定、ビルドの再実行率の変化があれば、該当する変数を更新して比較し直します。
SSHMacの当サイト料金や実測ビルド記録を確認できない場合、特定のMac構成や価格を仮定して比較するべきではありません。自前Macやレンタルを候補にする場合は、Macレンタルプランで現在の条件を確認し、上の式に実際の費用を入れてください。CI環境や利用方法について確認が必要なら、サポート窓口で該当条件を確かめてから予算化します。
よくある判断の迷い
Xcode 27のGitHub-hosted runnerが向くプロジェクト
短期の検証、利用量が安定しないチーム、Macの保守担当を増やしたくないケースで評価しやすい選択肢です。一方で、public previewであること、macOS 27上のイメージであること、arm64のみが対象であることを踏まえ、必要な依存ソフトとビルド手順を実環境で確かめてください。
macOS runnerと自前Macの総費用
GitHub-hosted runnerは最新の公式単価と課金対象時間、自前Macは機器費用に初期設定・更新・監視・待機・復旧を加えて算出します。双方とも再実行を含め、同じ期間、同じビルド量で比べる必要があります。料金や利用条件を確認できていない段階では、損益分岐点を断定しないでください。
自前Mac CIに含める保守費
OSとXcodeの更新、依存関係の検証、runnerの監視、セキュリティ設定、署名情報の管理、障害時の復旧を含めます。機器が使われていない時間も継続して確保するなら、その費用も対象です。担当者の作業時間を計上しないと、ホスト型との比較で自前案を実際より安く見積もることになります。
混合runnerに切り替えるタイミング
標準的なビルドやテストはホスト型で処理できるものの、特定の依存関係、固定環境、署名など一部のジョブだけ自前Macが必要な場合に検討できます。振り分け後も資格情報を適切に分離し、各工程の成果物とリリース確認を個別に検証できることが前提です。
短期検証や利用量の変動が大きいならホスト型を起点にし、安定負荷や環境制約が確認できてから自前Macを比較するのが堅実です。既存のCI環境には、従量費用の変動、待ち時間、環境変更の制約が残ることがありますが、自前運用にも更新・監視・障害対応という負担があります。Macの保守を自分たちで抱えずに一時的な構築容量を確保したい場合は、SSHMacの現在のレンタル条件を確認し、GitHub-hosted runnerと同じ利用量・期間で費用を並べて判断してください。