GitHub公式の説明では、自ホストRunnerの利用にGitHub-hosted Runnerの実行料金はかかりません。ただし、これはRunnerを動かすMacの費用が無料という意味ではありません。GitHub Actionsの料金説明を踏まえ、GitHub Actions Mac CIのコスト分担は開発者数で均等割りせず、作業負荷ごとの実際のMac資源費と、プラットフォーム料金を分けて記録してください。

今週は、PR検証、正式リリース、定期回帰、臨時増強の作業を台帳上で区別し、空き容量と専用ノードの負担先を決めます。作業の帰属、資源の使用、請求の出所を結び付ければ、チーム間で検証できるルールを作れます。

複数の製品チームでMac CIを共用するFinOps担当者は、作業別の費用帰属ルールを作る際にお読みください。
GitHub Actionsと自ホストRunnerを管理する基盤チームは、ジョブ記録とインフラ費用の照合に役立てられます。
Macの調達・レンタル予算を担うIT担当者は、通常負荷、リリース時の増強、待機容量を分けて確認できます。

01

最初に請求元とMac資源費を切り分ける

GitHub Actionsのプラットフォーム料金と、Mac本体の調達・レンタル・運用費は、別々の費目として扱います。GitHub公式の課金と使用量の説明は、GitHub Actions側の課金範囲を確認するための資料です。自ホストRunnerでは、Macの費用や保守作業までGitHubの請求に含まれるとは限りません。

月次の費用台帳には、少なくとも次の項目を分けて記録します。

  • プラットフォーム費用：GitHub側で発生した料金。請求レポートの対象範囲を確認します。
  • Mac資源費：購入費、レンタル費、保守費など。会社の請求書や調達記録を根拠にします。
  • 運用費：Runnerの監視、更新、障害対応など。担当部署と記録方法を決めます。
  • 空き・待機容量：ジョブに使われなかった時間や、障害に備えて確保した資源。実作業費と混ぜずに扱います。

GitHubの請求レポート資料を参照し、GitHubの請求とMacの請求を別々に照合してください。チームへの配賦額を計算する際は、同じ費用をプラットフォーム費用とMac資源費の両方に計上しないことも確認します。

Mac CIのプラットフォーム料金とホスト費用はどう分けますか。 GitHubの請求記録はプラットフォーム費用の根拠にし、Macの請求書や社内資産台帳はホスト費用の根拠にします。両者を同じジョブの記録に関連付けても、費目は一つにまとめません。

02

PR検証はジョブとチームの対応を記録する

PR検証では、リポジトリ、ワークフロー、ジョブ、依頼元のチーム、Runnerのラベルを結び付けます。GitHubのワークフロージョブAPIで確認できるジョブ情報を手掛かりに、社内台帳に必要な識別情報をそろえます。集計に使う項目は、導入している記録方法で取得できることを先に確かめてください。

配賦の基本式は、たとえば次のように置けます。

チーム別PR検証費 ＝ Mac資源費の対象額 × 当該チームの有効なジョブ占有量 ÷ 対象ノード全体の有効なジョブ占有量

ここでいう占有量は、チーム間で合意した計測単位です。ジョブの開始・終了時刻だけを使う場合も、同じ時間に複数ジョブが動くノードでは、排他的な占有を示すとは限りません。Runnerの実際の並列稼働状況を記録できないなら、見かけ上の実行時間を精密な資源消費量として扱わず、推計であることを明記します。

共有Mac CIは構築時間と人数のどちらで配賦しますか。 実際の負荷を追跡できるなら、合意したジョブ占有量を基準にする方が、人数だけで均等に割るより作業の違いを反映できます。ただし、計測できない期間まで正確な実績として扱わず、推定値と記録欠損を区別します。

ジョブがない時間やRunnerが利用できなかった時間は、PRを実行したチームの有効な構築量に混ぜません。障害による停止と、単に仕事が発生しなかった待機は意味が異なるため、理由と期間を別に残します。

Runnerのジョブ記録だけでは、Macの請求金額や停止理由まで自動的に説明できるとは限りません。作業記録、Runnerの稼働記録、資源の請求根拠を別々に保管し、後から対応付けられる形にします。

03

正式リリースは署名用の専用容量を切り離す

正式リリースで専用の信頼済みノードを使う場合、そのMac資源費はPR用の共通プールに機械的に混ぜません。専用容量を利用するプロジェクト、リリースジョブ、ノード、費用を負担するコストセンターを記録し、事前に決めたサービスルールに従って帰属させます。

署名情報やリリース権限を扱うノードは、誰が利用できるか、どのワークフローを許可するかを費用配賦とは別に管理してください。GitHub Actionsの安全な利用に関する公式ガイドを確認し、権限や信頼境界を費用の都合で曖昧にしないことが重要です。

自ホストRunnerの費用は誰が負担すべきですか。 専用ノードは事前に定めた利用プロジェクトやコストセンター、共有ノードは記録された実作業または合意済みの配賦規則に基づいて負担します。どちらのルールを使う場合も、リリースを担当したチームと費用の根拠をたどれるようにします。

04

定期回帰は負荷と待機容量の負担先を決める

夜間や周期的な回帰テストは、実行時刻だけでチームを判定せず、プロジェクトとワークフローの対応表から帰属先を決めます。共有基盤として定期実行するなら、実行ジョブの資源費と、ノードを維持するための空き容量・キャッシュ管理費を別の項目にします。

配賦方式 主な根拠 向いている条件 空き・待機容量の扱い
実消費ベース チーム別の有効なジョブ占有量 ジョブとチームの対応を継続して記録できる 共通基盤費として別途決める
保留容量ベース 事前合意した確保枠や利用権 特定チーム向けに容量を維持する 確保を依頼したチーム、または合意した共通予算が負担する

自ホストRunnerの空き時間や予備容量もチームに計上しますか。 空き時間を実行済みジョブの消費として扱うのではなく、待機容量の費目として記録します。共通の障害対策なら基盤予算、特定チームのために確保する容量ならそのチーム、といった負担先を事前に合意してください。

ジョブの実行量だけで配賦すると、容量を常に待機させる費用が帳簿から抜けることがあります。反対に、待機容量をすべて実行チームへ割り振ると、実作業量との関係が不明瞭になります。どちらの方式にも説明できる根拠を付け、途中で方式を変える場合は適用開始時点を残します。

05

臨時増強は申請と費用の行き先をセットにする

リリース集中、緊急回帰、短期プロジェクトに伴う一時的なMac増強は、申請者、業務上の理由、利用対象、利用期間、費用負担先を一まとまりで記録します。基盤チームが共通予算で確保した容量なら、どの条件で依頼元へ付け替えるのか、どの条件なら弾力枠として共通負担するのかを先に定めます。

月次集計では、臨時増強費 ＝ 追加Mac資源の請求額 × 対象期間のうち当該依頼に帰属する割合のように変数で表せます。実際の請求額と期間は有効な請求記録から入力し、根拠を確認できない単価や利用時間で埋めないでください。

06

月次の照合でshowbackからchargebackへ進む

配賦を始めるときは、まずチーム別の費用を表示するshowbackで、記録とルールに無理がないか確認します。金額を実際の部門請求に使うchargebackへの移行は、財務部門とプラットフォーム部門が、証拠、責任者、異議申し立ての手順を合意してから判断します。

月次の照合は、次の流れで進められます。

  • GitHub Actionsのジョブ記録から、リポジトリ、ワークフロー、実行結果などを集めます。
  • 取得可能なジョブ情報をRunnerの使用記録と突き合わせます。GitHub Actionsのメトリクス資料も参照し、目的の集計に使えるデータを確認します。
  • Mac資源の請求書、資産記録、運用費の記録を集め、プラットフォーム料金と分けます。
  • 合意したルールを適用し、チーム別の費用と共通・待機容量の費用を集計します。
  • 作業記録が欠けている分は強引にチームへ割り当てず、未配賦として責任者と確認期限を記録します。
  • 費用の根拠、ルールの版、問い合わせ先、再確認の条件を残して月次レビューを完了します。

作業記録が欠けた場合、費用はどこに付けますか。 根拠のない配賦はせず、いったん未配賦として扱います。記録の欠落を修正できない場合は、財務・基盤チームがあらかじめ定めた共通費の規則に従い、次回のレビューで処理を確認してください。

計測が難しい間は、人数割りを暫定的に採用するより、未配賦額と記録不足を可視化する方が後の修正につながります。運用を続けるには、記録の作成者、請求との照合者、配賦ルールの承認者を分け、争いが起きたときに何を証拠として再確認するかも決めておきます。

07

実負荷とMacの調達方式を照合する

コストの帰属を整理したら、現在のMac資源がどの作業に使われ、どの期間で必要になるかを調達記録と照合します。購入したMacは、初期の資金負担に加えて、保守や更新を社内で管理する必要があります。共用ノードだけで運用すると、リリースの集中時に通常のPR検証と容量が競合することもあります。一方、継続的に専用稼働し、物理ポートや社内設置を必要とする用途では、自社保有が適する場合があります。

購入とレンタルの検討では、資産や利用期間などの前提をそろえてください。調達条件の確認にはMac miniの注文案内を参照し、リモートMacの選択肢はVpsMeshの案内で、実際の期間や提供条件に照らして検討できます。

Mac CIの利用量を追跡できており、一時的なリリース増強やテスト環境が必要なら、現在の資源構成と遠隔Macのレンタル条件を同じ期間・用途で比較してください。購入済みの機材は初期費用や保守負担があり、共用プールはピーク時の競合が起きやすく、Mac以外の実行環境ではmacOS向けジョブをそのまま担えません。常時専用で稼働させる環境や物理接続が必要な用途は購入も含めて比較し、必要な期間だけ容量を補う用途ではVpsMeshの条件を確認してから予算に反映するのが堅実です。