GitHub Actions macOS Runner のコスト配分：2026年の複数チーム予算モデル
ビルドは少ないのに、GitHub Actions のmacOS請求額が大きく、チーム別の原因も説明できない状態になっています。
最も妥当な方法は、開発者数ではなく、チームに帰属するタスク利用量、共有Macの基礎容量、リリース用の専用容量に分けることです。 安定した本番負荷は予約したMac容量へ、変動する負荷は従量リソースへ配分し、最初はshowback、検証後にchargebackへ移行します。
この判断を必要とする担当者
企業IT・FinOps担当者は、監査できるCI/CD費用台帳と予算ルールを整備する必要があります。開発生産性・プラットフォーム責任者は、リポジトリ、ワークフロー、Runner Group、占有時間をチームへ正しく対応付けます。
技術責任者と購買担当者は、共有の遠隔Mac、専用ノード、GitHub Actionsの従量課金を、どの予算で持つか判断します。単に「Macを安く借りるか」ではなく、費用の責任境界を決める記事です。
人数配分と実利用配分では結果が変わる
開発者数による均等配分は、説明しやすい反面、費用の原因を隠します。たとえば、少人数のチームが署名付きリリースを頻繁に実行し、大人数のチームが軽量なテストだけを実行する場合、人数割りでは前者の消費が後者へ移ります。
| 費用の見方 | 帰属対象 | 記録すべき証拠 | 判断する担当 |
|---|---|---|---|
| 直接利用費 | リポジトリ、ワークフロー、Job | 実行時間、Runner種別、請求データ | 開発チーム |
| 共有基礎容量 | 共用Macプール、待機ノード | 占有時間、予約枠、利用権限 | プラットフォーム |
| リリース専用容量 | 署名、私有依存関係、承認済み公開 | 信頼境界、監査ログ、復旧要件 | セキュリティ・リリース |
| 障害・予備費 | 交換、復旧、待機系 | 障害記録、復旧手順、予備方針 | IT・共通予算 |
GitHub Actionsでは、組織のメトリクスからワークフローの利用状況を確認できます。組織単位の指標については、GitHub公式のActionsメトリクス説明を参照してください。
請求台帳には、少なくとも次の3種類のデータを分けて登録します。
- GitHubから請求されたRunner利用量
- self-hosted runnerの実行時間とMac占有時間
- 失敗、再実行、待機、予備容量にともなう運用コスト
Jobの実行時間は、成功した処理だけでなく、失敗した処理も含めて確認します。Job実行時間を確認する公式手順では、ワークフローごとの処理時間を調査できます。
開発チームはリポジトリ単位で制御可能な費用を持つ
開発チームへ請求すべきなのは、単純な「使った分」だけではありません。チームが改善できる消費と、プラットフォームが提供する共通容量を切り分ける必要があります。
通常ビルド、テスト、署名、公開準備は、ワークフローまたはJobの種類で分けます。失敗後の無効な再実行、直列化された処理、不要なブランチ実行は、担当チームが改善できる費用として記録します。
GitHub Actionsの利用データを抽出する際は、リポジトリ名をチーム台帳へ結び付けます。請求情報の集計には、GitHubのBilling Usage APIや、支出分析とCSVレポートを扱う公式のインサイト手順が使えます。
記録形式は、次のように単純化できます。
repository,workflow,job,runner,owner,execution_time,retry_count,cost_class
ios-app,build,archive,macos,team-a,exported,exported,build
ios-app,release,sign,macos-private,release,exported,exported,restricted
出力例は次のようになります。
cost_class=build
owner=team-a
source=repository_workflow_job
allocation=direct
cost_class=shared-capacity
owner=platform
source=runner_occupancy
allocation=common
ここで重要なのは、チーム名を後から請求額へ推測で割り当てないことです。リポジトリの所有者、変更承認者、ワークフローの責任者を台帳のマスターデータとして管理します。
プラットフォームチームはRunner Groupで境界を固定する
共有Macを複数チームへ開放する場合、Runner Groupは費用帰属とアクセス制御の接点になります。グループごとに許可するリポジトリを定義し、ワークフローのラベルと実行先を統一します。
Runner Groupの公式仕様では、組織内でRunnerへのアクセス範囲を管理する考え方が説明されています。さらに、self-hosted runnerのアクセス制御を確認し、誰がどのMacへJobを送れるかを明示します。
共有池、部門池、プロジェクト専用池は、次の条件で分けます。
- 共有池：ワークロードの時間帯が分散し、同じ実行環境で問題がない場合
- 部門池：複数チームが同じXcodeや依存関係を使い、部門内で容量を調整できる場合
- 専用池：署名鍵、私有ネットワーク、公開承認など、信頼境界を分離する必要がある場合
プラットフォームチームは、成功Jobの時間だけでなく、キュー待機時間、失敗率、ノード占有時間も保有します。請求対象外に見える待機時間が長い場合、容量不足やルーティング不備を共通費へ隠すことになります。
同時実行数の制御も費用管理に関係します。GitHub公式のConcurrency設定を使えば、同一ブランチの不要な重複実行を抑える設計を検討できます。
セキュリティ・リリース担当はリスク容量を別会計にする
本番署名用のMacを通常のCIと同じ単価で割り当てると、隔離のために確保した容量が見えなくなります。署名鍵を扱うノード、私有ネットワークへ接続するノード、承認済みの公開処理を行うノードは、実行時間ではなく信頼境界と復旧要件で判断します。
専用容量の負担先は、次の順番で決めると説明しやすくなります。
- そのノードを要求した単一プロジェクトがあるか
- 複数の製品が使うリリース基盤か
- 企業全体の監査・復旧要件で確保しているか
- 利用権限と署名操作の監査記録を誰が所有するか
単一製品の署名容量なら製品予算へ配分します。複数製品の公開基盤なら、リリース部門またはプラットフォーム共通費が候補です。災害復旧用の待機ノードは、通常の開発チームへ直接請求するより、リスク管理費として独立させた方が監査に耐えます。
購買担当は従量課金とMac容量を同じ式で比較する
托管Runnerと遠隔Macレンタルの比較では、公開料金だけを掛け算してはいけません。自社運用のMacには、契約費、設置、監視、OS更新、障害対応、空き容量、交換や復旧の費用が含まれます。
GitHubが公開しているActions Runnerの料金表は、托管Runner側の単価確認に使えます。ただし、料金、無料枠、Runner仕様、権限条件は変更される可能性があるため、予算確定時点の公式情報と企業の請求書を優先します。
比較式は、金額を仮置きせず、実データを入力できる形にします。
托管Runner総費用
= 実請求額
+ 無効な再実行の費用
+ 待機による開発遅延コスト
Mac容量の総費用
= 契約費
+ 運用・監視費
+ 空き容量費
+ 障害・復旧費
+ 予備容量費
| 負荷パターン | 先に確認するデータ | 向く容量設計 | 損益分岐点の見方 |
|---|---|---|---|
| 安定した本番基準負荷 | 月別実行時間、占有時間、署名要件 | 予約した専用Mac容量 | 固定費と実請求額を同じ期間で比較 |
| 季節性のあるリリース | 高負荷期のJob数、待機時間、失敗率 | 基礎容量＋追加の弾性容量 | 高負荷期だけの追加費用を分離 |
| 短期プロジェクト | 期間、リポジトリ、必要な隔離 | 従量Runnerまたは短期レンタル | 契約期間と撤去コストを含める |
| 署名・私有依存関係あり | 鍵の保管、接続元、監査、復旧 | 専用Macプール | 容量費ではなくリスク低減費も比較 |
SFTPMACのMacレンタル料金に関する案内を候補にする場合も、表示価格だけで結論を出すべきではありません。対象期間、交付条件、利用する地域、運用担当の作業を、GitHubの実請求と同じ予算期間へそろえて試算します。複数台の導入を検討する場合は、Macの注文方法と利用条件も確認対象になります。
IT管理層はshowbackからchargebackへ段階移行する
いきなり内部請求を始めると、タグ漏れや共有容量の扱いが原因で、チーム間の不公平感が強くなります。先にshowbackで費用を表示し、リポジトリ所有者、Runner Group、失敗Job、共有容量のルールを検証します。
表示するダッシュボードには、次の項目を同時に置きます。
- チームが制御できる直接利用費
- プラットフォームが管理する共有基礎費
- セキュリティ・リリース用のリスク容量
- キュー待機時間、失敗率、ノード占有時間
- 予算との差額と、差額が発生した理由
そのうえで、次の条件に該当するかを月次で判定します。
- 実行量が安定し、固定容量の占有率が継続して高いなら、予約Mac容量を検討する
- 高負荷が一時的で、平常時の空き容量が大きいなら、従量リソースへ戻す
- 署名や私有依存関係があるなら、通常の共有Poolから分離する
- 失敗と重複実行が多いなら、増設前にワークフローを修正する
- 使われない予約容量が続くなら、専用Poolを縮小し共有Poolへ戻す
予算台帳を作る5段階
-
請求元を確定する
GitHubの請求情報、Actionsメトリクス、企業の会計データを同じ期間で保存します。 -
帰属キーを統一する
リポジトリ、ワークフロー、Job、Runner Group、所有チームの命名をそろえます。 -
費用プールを分ける
直接利用、共有基礎容量、専用署名容量、障害・復旧容量を別項目にします。 -
showbackで差異を確認する
チームへ利用量と費用を表示し、タグ漏れ、再実行、待機、共有費の異議を修正します。 -
chargebackの条件を文書化する
何をチーム予算へ請求し、何をプラットフォームまたは全社予算で負担するかを決めます。
FAQ
GitHub ActionsのmacOS実行費用は、リポジトリ単位とチーム単位のどちらで配分すべきですか？
まずリポジトリ、ワークフロー、Job、Runner種別、実行時間を記録し、その後に所有チームへひも付けます。チーム人数で均等配分するのではなく、通常ビルド、失敗による再実行、リリース作業など、制御可能な消費を分ける方法が監査しやすくなります。
self-hosted macOS Runnerは、実行時間だけを原価として扱えばよいですか？
実行時間だけでは不十分です。Macの固定費、契約期間、保守、監視、待機中の容量、障害対応、バックアップや交換に備えた予備容量も含めて原価化します。共有プールでは、稼働時間と占有時間を分けて記録すると、空き容量の負担先を決めやすくなります。
共有Macビルド機の空き容量は、どの部署が負担するのが妥当ですか？
特定チームが予約している専用容量なら、そのチームの負担です。一方、複数チームが利用できる待機容量や災害復旧用の予備は、プラットフォーム費用または全社共通費に置くのが自然です。予約ルール、利用権限、監査記録が負担先を決める証拠になります。
GitHub Actionsの従量課金と遠隔Macレンタルの損益分岐点はどう計算しますか？
同じ期間の請求額と、Macレンタルの契約費、運用費、空き容量、障害時の代替費用を並べます。安定した基準負荷は固定容量、変動する短期負荷は従量課金として別々に比較し、実際の利用記録がそろってから契約期間を決めるのが安全です。
最終的な比較では、現在の托管Runnerだけに依存する構成は、実行量の増加に応じて請求が変動し、署名や私有ネットワーク向けの隔離容量を別途設計しにくいという弱点があります。自社保有のMacだけに寄せる方法も、空き容量、監視、障害時の交換、契約終了後の資産管理が固定費として残ります。
そのため、安定した基準負荷を持つチームには、SFTPMACの遠隔Macを候補に加え、実際のGitHub Actions請求額と占有記録で比較する方法が現実的です。まず直近の予算期間からリポジトリ別の実行時間、再実行、共有容量を整理し、試算用のMac構成を合わせます。結果が固定容量に有利な場合だけ、長期レンタルへ進む判断にすれば、推測による過剰契約を避けられます。