GitHub Actions macOS-14退役前、企業CI予算をどう算定する？2026

退役告知を受けたものの、Runnerの分単価だけで次年度予算を組もうとしていませんか。
結論：GitHub Actions macOS-14退役前の企業CI予算は、まずMac必須の仕事を分け、実行記録・適用される課金ルール・運用工数を入れて試算してください。多くのチームでは、対象を分流したうえで複数の実行環境を併用する案から検証するのが妥当です。

企業IT・プラットフォーム担当者：退役後の実行環境と予算範囲を決めたい方。
FinOps・購買担当者：Runnerの請求だけでなく、設備、空き時間、運用の負担も比較したい方。
CI/CD担当者：Macが必要な仕事と、ほかの環境へ移せる仕事を仕分けたい方。

更新日：2026年10月27日。退役日と対象ラベルはGitHubの公式告知、課金条件はGitHub Actionsの課金説明を参照しています。組織ごとの実額は、公開資料だけでなく、最新の請求明細とワークフロー実行記録で確かめてください。

IT担当者が最初に定める予算の範囲

GitHubはmacOS 14 Runnerイメージを2026年11月2日に退役させると告知しています。対象として示されているラベルはmacos-14、macos-14-large、macos-14-xlargeです。退役前に容量が減り、待ち時間が長くなる可能性も公式告知に記載されていますが、これは個々の組織で発生済みの費用や遅延を意味しません。実際の影響は自社の実行履歴で判断してください。

ここで扱うのは、退役後のジョブをどの環境で動かすか、その予算をどう見積もるかです。ラベルの置き換えやワークフロー修正を網羅する移行手順とは分け、予算の対象を先に固定します。退役日の変更、代替ラベル、課金条件が更新される場合があるため、判断時にはRunnerの選択に関する公式文書も再確認します。

CI担当者が切り分けるMac必須の仕事

すべてのジョブを新しいMac環境へ移すと、不要なMac利用分まで予算に含めるおそれがあります。反対に、署名や公開に関わる重要な仕事を一般的なスクリプト処理と一括で扱うと、実行環境の要件とリリース上のリスクを見落とします。

ワークフロー名や担当者の記憶だけで割合を推測せず、実行ログ、Runnerラベル、所要時間、再実行の記録、リリースとの関係をジョブ単位で照合してください。GitHub Actions macOS Runnerが必要かどうかは、ジョブが実際に使うツールと依存関係で決めます。GitHubのRunner選択資料で実行環境の要件を確認しつつ、次のように仕分けます。

仕分け結果には、該当するワークフローと根拠を記録します。記録が足りないジョブは、Mac必須とも分流可能とも決めつけず、予算上は未確認として試験対象に残してください。

FinOps担当者が使う再計算式

退役後のCI費用は、Runnerの単価だけでは求められません。GitHub Actionsの課金説明とRunnerの料金資料で、対象プラン、利用枠、Runner種別、請求時の計上条件を確認し、同じ期間の組織請求と実行履歴を突き合わせます。未確認の単価や、過去の料金表を予算に転記するのは避けてください。

月次の比較では、少なくとも次の変数を別々に記録します。

• ワークフローごとの実行回数と実際の実行時間
• 適用対象となる無料枠・利用枠と、枠を超えた場合の扱い
• Runnerの種類ごとに適用される現行の課金ルール
• 成果物やキャッシュなど、利用状況に応じて加わる保存費用
• 自前またはレンタル環境の費用、保守にかかる担当者の工数
• セキュリティ対策、監視、障害時の復旧に必要な社内負担

月次推計は、対象となる実行回数と請求対象時間、確認済みの課金条件、保存関連費用を分けて計算します。年間推計は、その月次推計をそのまま固定せず、繁忙期やリリース時期の実績を反映した各月の合計として扱います。利用枠の超過や再実行が多い月も別に見積もり、通常時だけを前提にした予算との差を確認してください。

基盤担当者が比較する代替環境

托管型macOS Runner、自社保有のMacを使う自托管Mac Runner、遠隔Macレンタルでは、支出の種類だけでなく、設備管理や復旧を誰が担うかも異なります。自托管Runnerは、環境を自社で管理できる一方、GitHubの自托管Runnerに関する説明を踏まえ、稼働監視、更新、アクセス制御、障害対応まで自社の運用範囲として整理します。

相対評価は一般的な運用責任の比較であり、各サービスの性能やSLAを保証するものではありません。大型Runnerなどを検討する場合は、GitHubの大型Runner資料で対象機能と課金条件を確認し、現在の契約と照らしてください。

空き時間と運用工数も、条件をそろえて比較します。自社で設備を保有する場合は、ジョブが動いていない時間にも発生する費用や、保守・復旧の工数を見落とさないようにします。レンタルの場合も、契約上の利用期間とジョブの稼働時間が一致するとは限りません。いずれも、契約条件や実際の稼働記録に基づいて費用化し、未確認の項目はゼロとして扱わないでください。

セキュリティ担当者が予算決定に加える条件

費用比較の前提として、プライベートネットワークへの接続要件、署名資格情報の保管と利用権限、ホストへのアクセス範囲、ジョブ間の分離方法を確認します。これらの条件が満たせない環境は、単価が低く見えても候補から外れる場合があります。

Runnerのラベルやリモートアクセスの有無だけでは、ワークロード間の隔離や署名情報の安全性は確認できません。どのジョブが資格情報に触れるか、プルリクエスト由来のコードをどこで動かすか、退職・異動時にアクセス権をどう停止するかを、実際の権限設定と運用手順で検証してください。必要な監査、鍵管理、ネットワーク制御にかかる費用と工数は、CI本体の試算とは別項目で記録します。

購買担当者が実行する条件分岐と試験

試算結果は、単一の「最安」判定で終わらせず、実行記録と社内の安全基準に照らして次の条件で判断します。

• Mac依存が確認できないジョブがあるなら、まず別環境で試験し、Mac Runnerの対象から外せるか確認します。依存関係が解消できない場合は、Mac上に残して再見積もりします。
• ホスト型の課金条件と利用枠で予算を説明でき、社内の待ち時間・安全基準も満たすなら、ホスト型を維持します。キューの懸念は公式告知だけで費用化せず、チームの記録で影響を確認します。
• 自社で保守できる担当者と障害対応体制があり、稼働率や空き時間を含む試算が成立するなら、自前Macを小さく試します。担当者や復旧手段を確保できない場合は、自社保有の規模を広げず、別の候補に戻します。
• 利用期間を限定したい、またはピーク分のMac環境を補いたいなら、遠隔Macレンタルを試験候補に加えます。契約期間、構成、アクセス方法、サポート範囲を確認できない場合は、見積もりに組み入れず、確認を完了してから比較します。
• 条件を満たす仕事と満たさない仕事が混在するなら、Mac必須ジョブだけを残す混合構成を試します。試験中に予算超過、安全条件の不備、復旧手順の未整備が判明した場合は、対象を拡大せず試験を停止して原因を見直します。

実施手順は、実行履歴と請求明細を同じ期間で集め、Mac必須ジョブを特定し、現行ルールで各候補を試算し、安全条件を通過した構成だけを小規模に試し、予算と運用負担を再確認する流れです。試験の対象、評価期間、停止条件は開始前に文書化し、終了後に実績を使って見積もりを更新します。遠隔Macの候補を比較する際は、VPSMACの提供内容一覧で公開情報を確認したうえで、契約条件や対応範囲を照合してください。チーム向けのMac利用条件や契約内容を確認する場合は、VPSMACのMacレンタル案内で公開情報を参照し、記載のない構成や条件は個別に確認してください。

ホスト型だけに依存すると、課金ルールや実行待ちの変化を受けやすく、自前Macだけに寄せると、設備の空き時間、保守担当者、障害復旧が予算に残ります。固定期間の遠隔Macレンタルは、設備を購入せず試験やピーク補完を行いたい場合の候補になりますが、長期の安定稼働や物理インターフェースが必要な用途では、自社保有が適することもあります。まず実績に基づく混合案を作り、VPSMACを比較する際は公開中の構成・契約周期・価格・提供条件を照合してから、試験規模と継続可否を決めてください。