GitHub Actions macOS Runnerの選び方

ビルドは少ないのにmacOS Runnerの請求と待ち時間が読めない。そんな状態なら、単価ではなく「成功した1回のリリースにかかった総コスト」で判断してください。

低頻度の構築や公開リポジトリはホステッドRunnerが基本です。継続的なXcode CI、固定した署名環境、内向きのAPI、再利用できるキャッシュがあるなら、自前のリモートMacが有力です。多くのチームは、テストをホステッド、署名とアーカイブを自前に分ける二軌道が現実的です。

独立開発者は、専用ノードの保守を増やしたくない場合に向いています。モバイル開発チームは、Xcodeと証明書を固定したい場合に確認してください。DevOpsやプラットフォーム担当者は、複数リポジトリの同時実行数と運用工数まで集計してから決めるべきです。

最終更新:2026年8月15日。GitHub公式の料金、Runner仕様、セルフホステッドRunner要件、Apple公式のXcode対応表を同日に確認しています。

01 単価ではなく総コスト

GitHub Actions macOS Runnerの比較で最初に見るべき指標は、1分あたりの価格ではありません。ホステッド側はジョブの実行時間、無料枠、並列数、ストレージを集計し、自前側はノードの利用期間、空き時間、保守工数、障害による停止時間を集計します。

次の式をスプレッドシートに作ってください。

ホステッド総コスト
= 実行分数 × 適用単価
+ ストレージ費用
+ 再実行による追加時間
+ 待ち時間による納期損失

自前総コスト
= Macの利用料金
+ 空き時間の料金
+ 保守工数
+ 監視・復旧コスト
+ 障害時の再実行コスト

GitHubはジョブの分数と分未満の時間を、次の整数分へ切り上げて計算します。公式料金表では、標準macOS Runnerの単価は1分あたり0.062米ドルです。大型Runnerには別料金があり、macOS 12コアは1分あたり0.077米ドル、macOS 5コアのM2 Pro構成は1分あたり0.102米ドルです。料金は変更されるため、請求期間ごとにGitHub公式のRunner料金表で確認してください。(docs.github.com)

公開リポジトリでは標準のGitHubホステッドRunnerが無料かつ無制限と説明されています。一方、プライベートリポジトリでは契約プランの無料枠と従量課金が関係します。したがって、同じ構築時間でもリポジトリの公開範囲と契約プランによって結論が変わります。(docs.github.com)

02 負荷と待ち時間

構築頻度は、少なくとも次の3種類に分けて記録します。

  • リリース時だけ実行する低頻度負荷
  • 毎日または複数回の継続構築
  • 複数ブランチ、複数リポジトリを同時に処理する高並列負荷

低頻度なら、固定ノードの空き時間が大きくなります。自前Runnerを月単位で確保しても、実行していない時間の料金は消えません。反対に、高並列負荷では1台の自前ノードが待ち行列を作り、ホステッド側の弾性が納期を短くする場合があります。

比較時は「月何分使ったか」だけでなく、次の3つを分けて取得してください。

  1. ジョブがキューに入ってから開始するまでの待ち時間
  2. Runner上で実際に実行した時間
  3. 失敗後の再実行を含む占有時間

GitHub Actionsでは、ホステッドRunnerの各ジョブは指定したイメージの新しいインスタンスで実行されます。自前Runnerは固定ノードを使えるため、環境の再利用に向く一方、同じノードが別ジョブの状態を引き継ぐリスクがあります。(docs.github.com)

03 キャッシュと環境再現性

自前のGitHub Actions自前Runnerでは、Homebrew、Swift Package、CocoaPods、DerivedData、独自ツールをあらかじめ用意できます。依存関係の取得やXcode初期処理を短縮できる可能性があります。

ただし、キャッシュの効果をそのまま自前Runnerの性能差と見なしてはいけません。比較では、同じコミット、同じXcode、同じ依存関係、同じキャッシュ条件を使います。キャッシュありとキャッシュなしを分け、実行時間を記録してください。

長期運用ノードには反対側のコストもあります。古いDerivedData、残ったキーチェーン、環境変数、生成ファイルが次のジョブへ影響します。キャッシュヒット率だけを追うと、再現性の低下を見落とします。

注意:RunnerがOnlineと表示されていても、リリース用ノードとして正常とは限りません。ジョブ受信、Xcode起動、証明書読み込み、再起動後の復帰までを別々に確認してください。

Xcodeの対応範囲は固定ではありません。Appleの対応表では、Xcode 27 beta 5はmacOS Tahoe 26.4以降を必要とし、Xcode 26.3はmacOS Sequoia 15.6からmacOS Tahoe 26.xに対応しています。採用するXcodeとmacOSの組み合わせは、Apple公式のXcodeシステム要件で確認してください。(developer.apple.com)

04 署名とネットワーク制御

Xcode CIで自前Runnerの価値が高くなるのは、単に構築時間が長いときではありません。次のような制御要件がある場合です。

  • 特定のXcodeを長期間固定したい
  • 証明書とプロビジョニングプロファイルを限定されたノードに置きたい
  • 内部パッケージレジストリへ安定して接続したい
  • 社内API、VPN、固定IP、特殊なDNSを使う
  • アーカイブと署名の作業を一般テストから分離したい

ホステッドRunnerでもネットワーク構成によって追加の接続先を指定できる場合があります。そのため、「ホステッドは内向きのネットワークに接続できない」と決めつけるのは危険です。実際に必要なドメイン、固定IP、VPN、認証方式を一つずつ確認してください。

自前ノードでは秘密鍵が長期間残ることが問題になります。専用キーチェーン、ジョブ終了後の消去、アクセス権、ログへの秘密情報出力、ノード再利用の可否を運用規則にしてください。署名処理だけを専用ラベルへ分離する構成は、コストと権限範囲を同時に管理しやすくなります。

05 運用と障害復旧

自前Runnerは、Runnerアプリを起動してジョブを受けられる状態に保つ必要があります。GitHub公式要件では、ホストがGitHub Actionsと通信でき、送信HTTPSの443番ポートを利用できること、さらに最低70キロビット毎秒の送受信速度が示されています。Runnerアプリは新しい版が利用可能になると自動更新されます。(docs.github.com)

自前ノードの見積もりには、次の作業時間を入れてください。

  • macOS更新後の動作確認
  • Xcode切り替えと不要版の削除
  • Runnerアプリの更新確認
  • ディスク使用量の監視とキャッシュ整理
  • 通信断、再起動、ジョブ中断からの復旧
  • 証明書やキーチェーンの更新
  • 失敗したジョブの再実行と原因調査

特に1台構成では、並列数が1に固定されます。2つのリリース作業が重なれば、料金ではなく待ち時間がボトルネックになります。逆に、低頻度であれば複数台を常時維持する必要はありません。

復旧確認リスト

  • [ ] macOS再起動後にRunnerが自動起動する
  • [ ] GitHubからジョブを受信できる
  • [ ] Xcodeの指定バージョンを選べる
  • [ ] 署名用キーチェーンが意図した権限で読める
  • [ ] ネットワーク断から復旧した後にジョブを再実行できる
  • [ ] ディスク不足を検知してジョブを止められる
  • [ ] 異常終了したジョブの作業ファイルを削除できる

06 実測ベースの選定手順

理想的な利用率を仮定して損益分岐点を決めると、実際の導入後に外れます。直近の完全な請求期間を使い、次の順序で確認してください。

  1. GitHub Actionsからリポジトリ別のジョブ一覧を取得します。
  2. Runnerラベルごとに、実行時間、待ち時間、失敗回数を分けます。
  3. Xcodeの版、Macのアーキテクチャ、依存関係、キャッシュ条件を固定します。
  4. 同じワークフローをホステッドと自前のリモートMacで並行実行します。
  5. 月額利用料、空き時間、保守時間、再実行時間を同じ通貨へ換算します。
  6. 署名、アーカイブ、内向きAPIなど、環境依存のジョブだけを先に移します。
  7. 1回のリリース成功までに必要な総時間と失敗率を比較します。

ホステッドRunnerと自前Runnerは、ワークフロー内で混用できます。runs-onにホステッド用のラベル、自前用のラベルやRunnerグループを指定し、ジョブ単位で実行先を分けます。ラベルは複数条件を組み合わせられるため、OS、アーキテクチャ、Xcode用途などを段階的に切り分けられます。(docs.github.com)

07 条件分岐による最終判断

次の条件で決めると、単純な「安い・高い」に引きずられません。

  • 公開リポジトリで低頻度の構築が中心なら、まずホステッドRunnerを選びます。
  • 担当者がRunnerの更新や障害復旧を担えないなら、ホステッドRunnerへ戻します。
  • Xcode、署名、キーチェーンを固定する必要があるなら、自前のリモートMacを候補にします。
  • 内向きAPIや専用ネットワークが必須なら、接続経路を検証したうえで自前ノードを優先します。
  • キャッシュによる短縮効果を同一条件で確認できたなら、自前ノードへの移行範囲を広げます。
  • 複数ジョブが頻繁に重なり、1台では待ち時間が増えるなら、ホステッド併用または自前ノードの増設を検討します。
  • 一般的なLintと単体テストは軽く、署名とアーカイブだけ環境依存なら、二軌道構成にします。

比較を始める前に、CALMVPSの料金プランで利用期間と構成を確認し、同じ期間で実績を取れる形に揃えてください。CALMVPSのリモートMacを検証用ノードにする場合は、日本向けのMacレンタル申込みから、署名またはアーカイブの代表ワークフローを一つだけ移す方法が安全です。

判断軸 ホステッドRunner 自前のリモートMac
料金の発生 ジョブ実行時間を中心に計算 利用期間と空き時間を含めて計算
環境 ジョブごとに新しいインスタンス Xcodeや依存関係を保持しやすい
キャッシュ 毎回の初期化を考慮 効果を出しやすいが状態汚染に注意
署名 一時環境の隔離がしやすい 鍵を固定ノードに置く管理が必要
並列実行 契約と利用可能枠を確認 ノード台数が容量を決める
保守 GitHub側の責任範囲が広い 更新、監視、復旧を自分で管理
実行するジョブ 第一候補 移行条件
Lint、単体テスト ホステッドRunner 固定ツールや内向き依存がある場合だけ再評価
Pull Request検証 ホステッドRunner 待ち時間が納期へ影響する場合は並列構成を確認
Xcodeアーカイブ 自前Runner Xcodeと署名環境を固定したい場合
App Store向け署名 自前Runner キーチェーン、証明書、アクセス経路を監査できる場合
夜間の定期ビルド 実績で判断 月額費用と実行時間を同じ期間で比較
複数リポジトリの高並列処理 併用 待ち時間とノード占有率を測定

08 よくある判断ミス

「自前Runnerなら無制限に安い」という考え方は危険です。実行していない時間にも利用料が発生し、更新や復旧に担当者の時間が必要です。逆に「ホステッドRunnerは必ず割高」という判断も不正確です。低頻度のジョブでは、空き時間と保守責任を持たないこと自体に価値があります。

Xcodeの版だけを比較して、Macのアーキテクチャやキャッシュ条件を変えるのも避けてください。構築時間の差が、CPU性能によるものか、依存関係の再取得によるものかを分離できなくなります。

09 結論と次の検証

GitHub Actions macOS Runnerの選択は、単価の比較ではなく、毎回の成功したXcode CIにいくら払っているかで決めます。低頻度ならホステッド、固定環境と署名が中心なら自前、一般テストとリリース処理が分かれるなら二軌道です。

現在の構成がLinux中心のCIや一時的なホステッド環境だけの場合、Xcodeの固定、署名鍵の管理、内向きネットワーク、ノード障害からの復旧を自分で追加しなければなりません。CALMVPSのリモートMacを1つの署名またはアーカイブ流水線で1利用期間だけ検証し、実際の請求額、待ち時間、失敗率、保守記録を比較すれば、全面移行が必要かを判断できます。長期の高負荷や物理デバイス接続が必要な場合は購入機も候補に残し、短期検証や可変するCI容量にはレンタルを使い分けてください。