YAMLを数行変えただけでGithub Actionsの料金を70%削減できて実行時間まで減った話

※この記事は「COUNTER WORKS Advent Calendar 2025」の1日目の記事です。

結論: Blacksmithのrunnerを使うといいよ！

サードパーティであるBlacksmith製のrunnerを利用した所、1分あたりの単価が半額になった上に、実行時間も減り、結果コストも約70%削減できました。

今回の結果は、正確には、Github Actions用yamlの各Jobのrunnerを変更（runs-onを修正）する前に、導入に向けての調査や、Blacksmith自体への登録という作業をしたことにより実現しております。

はじめに

ご無沙汰しております。
去年に引き続き、あらためて自己紹介なのですが、株式会社カウンターワークスにて、テックリード的存在として、リーシングのDXを実現するクラウド管理システム「ショップカウンター エンタープライズ」を開発しておりますshimです。

11月上旬から、これめっちゃ良かったから導入記事を書こう！と思っていたら、気がついたら12月になり、結局導入しての1ヶ月の振り返りとして、アドベントカレンダーに混ぜてもらうことになりました。
導入と実績、2つの記事に分割して記事数を稼ごうと思ったのに…

サードパーティ製のrunner導入の経緯

弊社ではGithub Actionsを使って自動テストおよびデプロイを実行しています。

プロダクトの成長に比例し、実行時間もコストもどんどん増えていきました。
開発者体験的には自動テストの実行時間が長いとストレスもたまりますし、かといって並列実行数を増やすと当然費用も上がります。

テストは減らしたくないし、テストのパフォーマンスチューニングも限界がある、自前でself-hosted runnerを構築すれば安くなるかもしれないが、管理コストがかかります。

弊社はAWSを主に使っているので、Codebuildを利用したself-hosted runnerも検討したのですが、チューニングの余地が増えるものの、かける工数の割に費用削減効果が見込めないと判断しました。

簡単に、もっと安く、あわよくば高速化しないかなあと考えていた時にサードパーティ製のrunnerの選択肢が挙がりました。

サードパーティ製のrunnerの比較

導入にあたっては名の知れていた Blacksmith と WARPBUILD を比較検討しました。

両社とも

• 著名なVCから資金調達
• SOC2 Type 2準拠
• 同一スペックの時間単価がGithub Actionsの半額

という点で、甲乙つけがたく、実際に両方とも試してみました。
（最初は新たにリポジトリを作って試し、ログに不審な点は見当たらないか確認し、実際のプロダクトのリポジトリに導入というステップを踏みました）

試した結果、管理画面の使いやすさと安定性、資金調達額の大きさからBlacksmithを選択しました。
※Blacksmithは個人のリポジトリは使えませんが、GitHub Organization利用なので問題にはなりませんでした。
※WARPBUILDのダッシュボードは画面遷移前の情報が表示されるときがあるなど、私の環境下では若干挙動が怪しい点がありました

Blacksmithの導入

導入にあたって、

• Blacksmithへ登録
• BlacksmithアプリをGithubにインストール

をしてから、yamlの修正をしました。

yamlの修正は、公式のドキュメントの通り、 Instance Types のように、対象のjobにて

jobs:
  build:
-    runs-on: ubuntu-latest
+    runs-on: blacksmith-2vcpu-ubuntu-2404

とするだけです。

Github Actionsからは self-hosted runner として扱われます。

結果1: Jobの実行時間が60%〜短くなり高速化した

Blacksmithの提供するrunnerは高性能なハードウェアを使っているとうたっていて、半信半疑だったのですが、実際は下記のようにかなりの効果がありました。

自動テストが60%弱高速化

導入前

導入後

と合計テスト実行時間が約55分から約23分となり、60%弱高速化となりました。
上記は一例ですが、導入後かなりの回数試行してきて概ね同様の結果となっています。
すごい。

Docker buildが70%強高速化

デプロイ用にDocker buildをしているのですが 40x Faster Docker Builds という記事の通りの対応をしました。

結果、2分30秒程度かかっていたものが、40秒程度で完了するようになり、70%強高速化しました。
弊社の環境下では公式の通り40倍とまではいかなかったですが、こちらもすごい。

結果2: 費用が70%削減できた

具体的な金額は出せないのですが、1/3程度になり、先月比70%程度削減できていました。

そもそもの単価が安い（同じスペックで半額）上に、実行時間が減った為このような結果となりました。
良いこと尽くしですね。

なお、他にもいくつかGithub Actionsのデフォルトのrunnerを利用している所があり、順次Blacksmithのrunnerや、Githubが提供し始めたubuntu-slimに置き換えていっていたので、来月はもう少しコスト削減できる見込みです。

他に導入して良かった点

ダッシュボードが多機能で、サマリーやログが見やすいのも良かったです。


かっこいい！

他に導入して良くなかった点

仕方ないことですが、Github側の障害だけでなく、Blacksmith側の障害にも影響を受けることになります。
ちょうど記事を修正しているときにも調子悪いかも？と感じることがありましたが、果たしてBlacksmith側の問題なのかGithub側の問題なのか…。
なお、SLAはEnterpriseプランのみ記載されています。

なぜBlacksmithのrunnerは安くて速いのか

AIにまとめさせました。長いので興味ある方はトグルを展開していただければ

1. ゲーミングCPUのベアメタル

Blacksmithは、Azure上の汎用VMで動くGitHub公式Runnerと異なり、ベアメタルのゲーミングCPU上にmicroVMを立てる構成を採用している。(blacksmith.sh)

• 「bare metal gaming CPUs with the highest single-core performance」を使用
• CPU集中型ワークロードで40〜60%高速 (blacksmith.sh)
• CIの典型タスク(コンパイル/テスト/lint)はシングルスレッド性能に依存するため、最新ゲーミングCPU + 薄い仮想化が圧倒的に有利 (Medium)

2. CI特化のキャッシュ・ストレージ最適化

キャッシュの最適化:

• ジョブが実行される同一データセンター内にキャッシュを配置
• 4倍高速なキャッシュダウンロード
• 各リポジトリに25GiBの高速キャッシュを提供 (GitHub)

Dockerビルドの最適化:

• Docker layerをNVMe上に永続化
• 40倍高速なDockerビルド (blacksmith.sh)
• ローカルDockerレジストリミラーを保持

→ actions/cacheのヒット率向上 + ネットワーク越しのレジストリアクセスを削減

3. microVM (Firecracker系) による高速起動

ベアメタル上にmicroVMをオーケストレーションする構成を採用している。(LinkedIn)

• 1ジョブ1 microVMの「ほぼエフェメラルRunner」
• 起動時間が短く、事前プールにより「Waiting for a runner...」がほぼ発生しない
• ノイジーネイバー問題も最小化

→ 待ち時間 + 実行時間のトータルでGitHub公式Runnerより大幅に短縮

4. CI専用クラウドの効率性

CIワークロードの特性は「スパースだけどスパイキー」である。(SlideShare)

• 常時100%稼働ではない
• 朝〜夕方やリリース前にスパイク

CI専用クラウドとしてのメリット:

• CI特化のスケジューリング・キャパシティ計画
• ベアメタルを大量調達してコスト最適化
• microVMによる高密度実装でアイドル時間削減
• オーバーヘッドの小さいスタック選定

5. 機能を絞った特化型アーキテクチャ

GitHub公式Runnerは以下の要件を満たす必要がある:

• Azure上の汎用インフラ
• Windows/macOS/ARM/旧バージョンの互換性など、広範な要件

一方、Blacksmithは以下に特化している:

• 主力はLinux (Ubuntu) とCI向けワークロード
• macOSや超ニッチ用途をカバーする必要がない
• CIのメトリクス/ログ周りは自前のコンソールで提供 (docs.blacksmith.sh)

CI特化により不要な機能を削減し、インフラからソフトスタックまで最適化している。

結論

もちろん情報漏洩や提供元の破綻等々、安定と信頼のGithub提供よりリスクもありますので、どの現場にも絶対おすすめ！安心安全！というわけではないと思います。
しかし、気軽にGithub Actionsを高速化＆コスト削減ができたので、今はテストやCIのチューニングより機能開発を優先したいんじゃ…という開発チームにとってはとても良い選択肢です。

最後になりますが、株式会社カウンターワークスではコスパ・タイパ・開発者体験も重視しているエンジニアを募集しております。