GitHub Actions macOS Runnerの選び方？2026年のコスト、同時実行数と自主管理の比較

2026年9月4日時点では、低頻度・短時間のジョブはGitHub ActionsのmacOS Runnerを優先し、安定した高負荷や固定環境、私有ネットワークが必要なら自主管理Macを評価してください。今週は、過去のビルド記録から待ち時間、実行時間、再実行回数を分けて集計し、同じ条件で小規模な試行を始めるのが安全です。

GitHub Actions macOS Runnerで迷っているDevOpsエンジニア、iOSビルド費用を見積もるチーム責任者向けの記事です。自主管理Runnerを導入するプラットフォームチームにも、判断に必要な確認項目を整理しています。

※最終更新：2026年9月4日。料金、制限、Runnerイメージの状態は、GitHub Actions公式の料金資料、制限資料、公式Runner Imagesを基に確認しています。

料金比較ではなく総コスト

GitHub Actions macOS Runnerの費用はどのように計算するか。

まず、請求対象の実行時間だけを集計しないでください。1か月の総コストは、次のように分解します。

• 実行分数 × macOS Runnerの単価
• 失敗したジョブの再実行に使った分数
• キューで待った時間による開発遅延
• キャッシュが効かず発生した依存関係の取得時間
• 自主管理Macのレンタルまたは設備費
• ネットワーク、証明書、Runner更新にかかる保守工数

GitHubの公式料金資料では、標準macOSの分単価は標準Linuxの10倍として扱われます。実際の請求額はプランやRunnerの種類で変わるため、社内計算では契約中の料金表をそのまま使ってください。macOSを含む公式のRunner料金区分を確認せず、第三者の料金一覧だけで判断するのは避けるべきです。

自主管理Macでは、ジョブ実行中の分数がそのまま請求されるとは限りません。しかし、アイドル時間も機材やレンタル枠を占有します。さらに、OS更新、Xcode更新、ディスク整理、故障時の交換を誰が担当するかまで費用に含めます。

注意：同じワークフロー、同じブランチ、同じ統計期間で比べてください。単発の最速ビルドを基準にすると、月末の再実行や待ち時間を見落とします。

同時実行数とキューの比較

月間分数が少なくても、リリース前にジョブが集中すればキューは伸びます。必要容量は、次の3つから見積もります。

• ピーク時の1時間あたりの投入ジョブ数
• 1ジョブの平均実行時間
• 開発者が許容できる待ち時間

たとえば、プルリクエスト検証、配布用アーカイブ、UIテストを同じRunnerに集約すると、平均値だけでは不足します。ピーク時に必要な同時実行数を別々に記録し、待ち時間の95パーセンタイルも確認してください。ここでの数値は自社ログから取得し、公式のプラン別上限とは分けて扱います。

GitHub Actionsにはプランごとの同時実行制限があり、ジョブには実行時間の上限もあります。公式制限資料では、通常のジョブ実行時間の上限は6時間と案内されています。長いUIテストや停止したシミュレーターがこの上限に達しないよう、公式のActions制限で契約プランと現在の上限を確認してください。

iOSビルドの同時実行数が足りない場合の拡張方法。

まず、ジョブを増やす前に、キューの発生箇所を分けます。プルリクエスト用、夜間回帰テスト用、リリース用にRunner Groupとラベルを分け、重要なジョブが低優先度のテストに埋もれないようにします。Runner Groupの公式説明では、アクセス可能なリポジトリやワークフローを管理する方法が示されています。

それでも待ち時間が目標を超える場合は、次の順で拡張します。

1. 直近の一定期間からピーク投入数を抽出します。
2. ジョブを種類別に分け、平均実行時間と失敗率を記録します。
3. 並列化できるテストと、署名を伴う直列処理を分離します。
4. ホスティングRunnerの追加利用、自主管理Macの追加、混合構成を比較します。
5. 試行後に待ち時間、成功率、1ビルドあたりの実コストを再計測します。

Xcode環境とキャッシュの比較

ホスティングRunnerは、公式イメージの更新を利用できます。新しいSDKやXcode 27のプレビュー環境を早く試せる一方、イメージ更新によってツールチェーンや既定パッケージが変わる可能性があります。Runner Imagesの更新履歴を確認し、ワークフローで利用するイメージを曖昧にしないでください。

自主管理Runnerは、macOS、Xcode、SDK、RubyやSwift Package Managerなどの依存関係を固定しやすい構成です。その代わり、固定したままではセキュリティ更新や新SDKへの移行が遅れます。Xcode 27へ移行する場合は、次の情報を同じ記録に残します。

• macOSとXcodeのバージョン
• SDKとシミュレーターの種類
• パッケージマネージャーの依存関係
• DerivedDataと依存キャッシュの保存方針
• ビルドスクリプト、署名設定、Runnerラベル

依存関係キャッシュはジョブを速くする可能性がありますが、キャッシュキーが不適切だと古い生成物を使います。GitHubの公式資料では、リポジトリのキャッシュ保存容量は10GBが上限です。容量超過時の削除やキー設計も含めて、依存関係キャッシュの仕様を確認してください。

ホスティングRunnerはジョブごとに環境が初期化されるため、DerivedDataやシミュレーターの準備時間が毎回発生しやすい構成です。自主管理Macは永続ディスクを使えますが、キャッシュ破損、ディスク逼迫、SDKの混在を自分で検知して清掃する必要があります。

Xcode 27のCI移行では、まず1つの代表アプリを選び、同じコミットを新旧環境でビルドします。署名なしのコンパイル、単体テスト、アーカイブ、配布前検証を分けると、どこで差が出たかを特定しやすくなります。iOS開発の検証工程を整理する際は、iOSアプリ開発の自動化事例も参考になります。関連するMac開発環境の選び方は、Mac上の開発環境を比較する記事で確認できます。

署名とネットワーク権限の比較

自主管理Runnerで署名証明書を安全に管理する方法。

証明書をリポジトリへ保存する設計は避けてください。短期トークンや暗号化されたシークレットを利用し、ジョブの終了後に一時キーチェーンを削除します。自主管理Macでは、次の境界を明確にします。

• 本番署名用Runnerとプルリクエスト検証用Runnerを分離する
• 信頼できないブランチから本番証明書へ到達できないようにする
• Runner Groupで利用可能なリポジトリを制限する
• 証明書と秘密鍵を定期的にローテーションする
• ビルドログへ秘密情報やキーチェーンの内容を出力しない
• 内部APIやプライベートパッケージへ接続する経路を限定する

自主管理Runnerは、管理者がOSとホストを保護する責任を負います。公式資料も、信頼できないワークフローを自主管理Runnerで実行しないよう注意しています。自主管理Runnerの責任範囲とRunner追加時の安全上の注意を、権限設計の基準にしてください。

一方、ホスティングRunnerは短期利用の認証情報と相性がよく、ホスト自体の交換や初期化を自社で行う必要がありません。ただし、私有ネットワーク内のサービスへ接続する場合は、接続方式、許可IP、秘密情報の保管場所を別途設計する必要があります。

導入前の選定チェック

次の項目を上から確認してください。チェックが付いた条件によって、ホスティングRunner、自主管理Mac、混合構成の候補を絞り込めます。

• [ ] 月間のジョブ数が少なく、実行量の増減が大きい
  → ホスティングRunnerを優先します。固定設備を持たず、使った分を中心に管理しやすいためです。
• [ ] macOSやXcodeのバージョンを固定し、同じ環境で再現性を保つ必要がある
  → 自主管理Macを評価します。更新担当者と更新期限まで決められる場合に適しています。
• [ ] プルリクエスト検証とリリース作業が同じ時間帯に集中する
  → Runner Groupとラベルを分け、足りない部分だけ追加します。それでもピーク待ちが残るなら混合構成を試します。
• [ ] 社内API、私有パッケージ、物理デバイスなど外部から隔離すべき資源がある
  → 自主管理Runnerを候補にします。署名用と検証用のホストを分離できない場合は、導入を急がないでください。
• [ ] OS更新、証明書更新、キャッシュ清掃、障害交換を担当できる人がいない
  → ホスティングRunnerへ戻します。自主管理は実行料金が見えにくいだけで、保守負担が消えるわけではありません。
• [ ] 通常時は少量だが、リリース時だけ大量のMacジョブが発生する
  → 混合構成を選びます。通常検証はホスティング、固定環境や社内資源を使うジョブは自主管理Macに分けます。

試行期間中は、単価だけでなく、平均キュー時間、失敗後の再実行時間、キャッシュヒット率、署名エラー数、保守担当者の作業時間を記録します。特定の節約率を先に決めるのではなく、現在のワークフローを同じ条件で比較してください。

現在のGitHub Actionsホスティング環境は導入が簡単ですが、ピーク時の待ち時間、毎回の環境準備、私有ネットワーク接続の制約が弱点になります。自社でMacを保有する方法も、初期調達、故障交換、OS更新、証明書管理を継続して負担しなければなりません。

そのため、短期のCI容量確保や固定したMac環境の試行では、HashvpsのMacレンタルを比較対象に加える価値があります。月間タスク数、ピーク同時実行数、Xcode 27の固定要件を先に整理し、実際の待ち時間と復旧手順を確認してから、長期構成へ進めるのが安全です。