Blacksmith で手軽に GitHub Actions を高速化＆コスト削減

CI のテストやLintの実行時間は、致命的というほどではないものの「速くはない」状態でした。差し迫った課題があったというより、少ない手間で高速化できてコストも下がるなら試してみよう、というくらいの温度感で検討を始めました。

• GitHub Actions 標準ランナー（移行前の構成。スペックとコストの比較対象）

• 移行コストの低さ（既存の GitHub Actions ワークフローをほぼそのまま使えるか）
• 同等スペックあたりのコスト
• 実際のジョブ（テスト・Lint）での速度
• 既存の CI 構成を大きく作り替えずに段階的に移行できるか

workflow定義のruns-on を書き換えるだけで移行でき、移行ツールも用意されているため、試すコストが極めて低かったことです。実際に試したところ、導入当時は同一スペックの per-minute 単価が GitHub 公式ランナーのおよそ半額で、かつハードウェアが速いぶんテスト・Lintの実行時間も短縮できることを小さく検証できました。問題があればすぐ元に戻せる安心感も大きな後押しになりました。

実行時間はいずれも CI の統計情報から抜粋した平均値です。スペックを変えていないジョブと、Blacksmith 化に合わせてスペックを上げたジョブがあるので、その点も明記します。

• Lint（GitHub・Blacksmith とも 2vCPU の同一スペック比較）は、平均実行時間が 1分38秒から 1分7秒に短縮しました。
• フロントエンドのユニットテストは、GitHub Actions の 2vCPU で平均 3分20秒だったものを、Blacksmith では 4vCPU に上げて平均 1分1秒に短縮しました。これは同一スペック比較ではなく、Blacksmith は上位スペックのランナーも安価に使えるため、スペックを上げて高速化する選択を取った例です。
• 料金面では、導入当時、同一スペックの per-minute 単価が GitHub 公式ランナーのおよそ半額でした。
• CI の待ち時間（平均キュー時間）も短くなり、PR のフィードバックループが速くなりました。

ほとんどありませんが、バックエンドの結合テストでランナー高速化後にテストのflakyさが顕在化しました。もともと潜在していたテストの不安定性が高速化で表面化したものと推測し、テストの並列数を調整することで安定化させました。

まずは一部のワークフローの runs-on だけ書き換えて、実際のジョブで速度を計測してみるのがおすすめです。リスクが小さく、効果も計測しやすいので意思決定がしやすいはずです。なお、この領域には Depot・Namespace・WarpBuild といった同種のサービス（高速なランナー＋Docker ビルドキャッシュ）もあります。私たちはそれらを突き詰めて比較したわけではなく、移行の手軽さから Blacksmith を選びましたが、要件によっては併せて検討してみるとよいと思います。コスト面は、GitHub 公式ランナーも値下げ（2026/1）が入っている一方で Blacksmith はジョブが速く消費分数が少ないため、単価表だけでも実行時間だけでも判断できません。ご自身のワークロードで「実行時間 × 最新単価」を両環境で計測して比較するのが正確です。価値の中心は移行コストの低さ・速度・キャッシュの効きやすさにあります。