LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

CI/CD実行コストが膨らむ仕組み：ジョブ時間×並列×実行回数の課金構造

CI/CD実行コストの削減とは、継続的インテグレーション・継続的デリバリー（CI/CD）パイプラインの実行時間や実行回数を最適化し、クラウド型CI/CDサービスへの支払いを抑える取り組みです。GitHub Actionsをはじめとするサービスでは、ジョブが動作した時間に応じて課金されるため、ビルド設計の良し悪しがそのまま月次コストに反映されます。

GitHub Actionsの課金は、ジョブが実行された分数（1分単位で切り上げ）に対して発生します。課金額を分解すると「1回のジョブ実行時間 × 並列に動いているジョブ数 × 1日の実行回数」という掛け算です。どの要素が大きいかによって有効な打ち手が変わります。

実務上でコストが膨らむ主な原因は次の3点です。

• 不必要なトリガの設定：全ブランチ・全ファイル変更でワークフローが起動する設定になっており、ドキュメント修正やCSSの変更でもビルドが走る。
• キャッシュ未設定による毎回フルビルド：npmやPip等の依存パッケージを毎回ダウンロードし、Dockerイメージも毎回フルビルドしている。
• マトリクスビルドの組み合わせ爆発：OS × Node.jsバージョン × ブラウザなど、必要以上の組み合わせでビルドが走り、並列ジョブ数が膨らんでいる。

これらはいずれも、ワークフローファイルの設計を見直すだけで削減できる余地があります。ビルド環境が複雑になるほど、コストの増大は気づかないまま進みやすい傾向があります。

GitHub Actionsの料金体系と2025年12月の改定内容

GitHub Actionsの課金はリポジトリの公開設定とプランによって大きく異なります。GitHubの公式ドキュメントによると、パブリックリポジトリでの標準ランナー利用は無料です^*1。プライベートリポジトリは各プランに応じた無料分（GitHub Freeで月2,000分、GitHub Teamで月3,000分など）を超えた分が課金対象となります。

ランナーの種類によって料金単価が異なります。Linux標準ランナー（ubuntu-latest）が最も単価が低く、Windows・macOSランナーは倍率が高く設定されています。macOS向けのビルドが多いiOS開発チームでは特にコスト圧迫が大きくなります。

2025年12月の公式発表：ホストランナーの値下げとセルフホスト課金の保留

GitHubの2025年12月の公式発表によると、GitHubホストランナーの料金を2026年1月1日から値下げしました^*2。公式ブログでは上限として39%程度の引き下げを示しており、無料利用枠の変更はありません。同じワークフローを動かしている場合、2026年1月以降は請求額が下がる計算になります。

一方で同時期に、セルフホストランナーに対して1分あたり0.002ドルの課金を2026年3月1日から適用する計画も発表されました。これに対してコミュニティから強い反発が起きました。GitHubのSVP Jared Palmer氏は「事前にフィードバックを得る機会を逃した」と認め、2025年12月17日にこの課金計画を保留・再検討すると表明しています^*2。2026年6月時点でセルフホストランナーへの課金は確定していないため、今後の公式発表を継続的に確認することが大切です。

なお、GitHub Enterprise Serverを自社ホストで運用しているケースはGitHub Actionsのホストランナー課金の影響を受けません。

実行コストを削減する具体的な施策

GitHub Actionsのコスト削減には、ワークフロー設計の見直しからビルドの高速化まで、段階的に取り組める施策があります。効果が出やすいものから順に整理します。

トリガフィルタで不要な実行を減らす：pathsとbranchsの活用

ワークフローのトリガにpathsフィルタを設定すると、特定ファイル・ディレクトリの変更時だけワークフローが起動するようになります。たとえばドキュメントのみ変更した場合にCI全体が走ることを防げます。同様にbranchesフィルタを使えば、開発中のフィーチャーブランチではlintだけ実行し、mainへのマージ時だけフルテストを走らせる、といった制御も可能です。

設定例として、on: push: paths: ['src/**', 'package.json']のように書くことで、srcディレクトリかpackage.jsonが変更された場合にのみジョブが起動します。設定コストは低く、即効性が高い施策です。

concurrencyで重複実行をキャンセルする

同じブランチに連続してpushした場合、前のジョブが終わらないうちに新しいジョブが起動し、古いジョブが無駄に実行され続けます。concurrencyグループとそのcancel-in-progress: true設定を使うと、新しいジョブ起動時に進行中の古いジョブを自動キャンセルできます。

フィーチャーブランチ開発中にコミットを頻繁に積む場合は、この設定だけで実行時間の削減につながります。プルリクエスト単位でグループを設定する設計が一般的です。

依存パッケージとビルドキャッシュを活用する

GitHubが提供するactions/cacheアクションを使うと、npmやPip・Mavenなどの依存パッケージのダウンロード結果をキャッシュできます。初回ダウンロードは時間がかかりますが、2回目以降はキャッシュから復元されるため、大幅に時間を短縮できます。

Node.jsプロジェクトではactions/setup-nodeのcache: 'npm'オプションで自動キャッシュが有効になります。Dockerイメージのビルドにはレイヤーキャッシュの活用が有効です。docker buildxとGitHub Actionsのキャッシュを組み合わせることで、変更のない層の再ビルドを防げます。

マトリクスビルドの組み合わせを必要最小限に絞る

マトリクスビルドは複数の環境・バージョンを一括テストできる便利な機能ですが、組み合わせ数が並列ジョブ数に直結するため、必要以上に広げるとコストが膨らみます。たとえばNode.js 16/18/20 × ubuntu/windows/macosの全組み合わせは9並列ですが、実際に必要なのはLTS版2種 × Linuxのみだった、というケースは珍しくありません。

マトリクスを定期的に見直し、EOLを迎えたバージョンや実環境で使われていない組み合わせを削除することが大切です。include/excludeを使った柔軟な制御も選択肢です。

テスト分割と並列化で単位時間あたりの効率を上げる

テストスイートが増えると1ジョブあたりの実行時間が延びます。jest --shardやpytest-xdistを使ってテストを複数ジョブに分割・並列化することで、トータルの実行時間を短縮できます。ただし並列数を増やすとジョブ数も増えるため、時間短縮とコストのバランスを実測しながら調整することが大切です。

また、コミット単位でフルテストを走らせるのではなく、変更範囲に関係するテストのみを選択実行する「テスト影響分析」ツールの導入も、大規模リポジトリでは効果的です。

セルフホストランナーという選択肢：コスト効率と運用負担のトレードオフ

セルフホストランナーとは、GitHubが提供するクラウドランナーではなく、自社のサーバーやクラウドインスタンス（EC2・Azure VMなど）上にランナーエージェントを構築してジョブを実行する方式です。現在はセルフホストランナーへの課金は保留中であり、実行時間に応じた従量課金が発生しない点が大きな特徴です（ただし今後の変更を引き続き確認する必要があります）。

コスト効率が高まるのはどのような状況か

GitHubホストランナーの費用がEC2等のインスタンス代を上回るほど実行時間が多い場合に、コスト逆転が起きやすくなります。目安として、月間の実行時間が数万分を超えるような大規模な継続的デリバリー環境では、セルフホスト移行の費用対効果を検討する価値があります。

また、GPUを使ったモデルビルドや機械学習パイプラインのテストでは、GitHubのGPU搭載ランナーは高額になります。専用のGPUインスタンスをセルフホストで用意する方が、実行コストを抑えられるケースがあります。

運用・セキュリティ・スケーリングの負担

セルフホストランナーには構築・運用のコストが伴います。ランナーエージェントのインストールとOSのメンテナンス、セキュリティパッチの適用、スケールアウト時のインスタンス管理など、担当エンジニアの工数が継続的に必要です。

セキュリティ面では、GitHubはパブリックリポジトリへのセルフホストランナーの使用を非推奨としています^*1。プライベートリポジトリでも、シークレット管理や最小権限の設定が重要です。不適切な設定のまま運用すると、CI環境を経由した認証情報の漏洩リスクが生じます。

スケーリングの自動化にはActions Runner Controller（ARC）などのKubernetesオペレーターを使う方法があります。ただし、Kubernetes自体の運用知識が求められます。EC2 Auto Scalingと組み合わせる方式も選択肢ですが、設計・構築・テストに相応の工数が必要です。

内製で構築する場合は、GitHubホストランナーと比較した際の実質コストを正確に試算することが大切です。インスタンス代だけでなく、運用工数・セキュリティ審査・スケーリング基盤の開発費も含めた総コストで判断する必要があります。

外注の使いどころ：委託で解決できる課題と判断軸

CI/CDパイプラインの最適化は、インフラとアプリケーションの両方を理解したエンジニアの知識が必要な領域です。自社に専任のインフラエンジニアがいない、あるいはいてもCI/CDコスト最適化に割ける工数がない場合は、外注による解決が現実的な選択肢になります。

外注で解決しやすい3つの課題

外注が特に効果を発揮しやすい課題は次の3つです。

• コスト診断と最適化提案：現在のワークフロー設計のどこにコストが集中しているかを可視化し、削減ロードマップを作成する段階。外部の目で既存設定を点検することで、内部では気づきにくいボトルネックが明確になります。
• セルフホストランナー基盤の設計・構築：EC2やKubernetesを使ったランナー基盤の設計・構築・セキュリティ設定は、専門知識が必要な初期作業です。初期設計を外注し、運用フェーズは内製に移すという切り分けが現実的です。
• パイプライン全体の再設計：モノレポ化やマルチリポ統合、デプロイ戦略の変更など、構成変更を伴う大掛かりなリファクタリング。変更が広範囲に及ぶため、専門チームによる設計と移行支援に委ねることでリスクを管理できます。

委託先を選ぶ際の判断軸

委託先を選定する際は、次の観点で評価することをお勧めします。

GitHub Actions・CI/CDの実績：類似規模・スタックでの最適化経験を持つかどうかを確認します。実行時間の削減実績（例：月間XX分→XX分）など、具体的な成果を示せるかが判断材料になります。

セルフホスト基盤の設計・運用経験：セルフホストランナーの導入を検討する場合は、ARCやEC2 Auto Scalingを使った構築経験があるかを確認します。セキュリティ設計の経験も問い合わせておくことが大切です。

コスト計測・継続改善の仕組みを持つか：一回きりの最適化で終わらせず、コスト計測の仕組みを残し、継続的な改善をサポートできるかどうかも重要です。GitHub ActionsのコストはAWS Cost Explorerのように一元化されているわけではなく、レポーティングの仕組みを整えるだけでも工数がかかります。

外注後の内製移管を見据えるなら、ドキュメント整備・ナレッジ移転のプロセスが提案に含まれているかも確認してください。ランナー基盤の設計図や運用手順書が残らないと、改修のたびに外注依存が続きます。

まとめ：CI/CDコスト削減の3つの判断軸

本稿では、GitHub ActionsのCI/CD実行コストが膨らむ課金構造の整理から、2025年12月の料金改定の内容、具体的な削減施策、セルフホストランナーの活用と外注の判断軸を整理しました。要点を3つに集約すると次のとおりです。

第一に、コスト削減はワークフロー設計の見直しから始めます。トリガフィルタ・concurrency設定・キャッシュの3点を整えるだけで、専門的な基盤変更なしに実行時間を削減できます。第二に、セルフホストランナーは大規模・GPU用途では有効ですが、運用コストを含めた総額での判断が必要です。第三に、外注は「コスト診断→基盤設計→継続計測」の流れで活用すると、内製では手が届きにくい設計の抜本的な見直しが実現できます。

GitHub Actionsの料金改定は今後も続く可能性があります。公式ドキュメントとブログを定期的にチェックし、コスト構造の変化に対応できる体制を整えておきましょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：GitHub「GitHub Actionsの課金について」（2025年）
2. *2　出典：GitHub公式ブログ「GitHub Actions – Simpler pricing」（2025年12月18日）

Tweet