🔧

GitHub Actions を Blacksmith で47%高速化した話

に公開
GitHub
CI
GitHub API
blacksmith
tech

TL;DR

  • GitHub Actions の CI 実行時間とコストが急増し、3月は月間 $200 超に到達
  • サードパーティランナー Blacksmith を導入し、テスト系ワークフローの完了時間を 47%短縮
  • runs-on の1行変更だけで導入でき、ロールバックも1行で済む
  • ただし shivammathur/setup-php との相性問題あり。ワークフローごとに効果を検証する必要がある

はじめに

こんにちは、melank です。長らく無職期間を続けていたのですが、QOLを意識しつつも、少しずつ働く機会を設けようと、プロダクトエンジニアとして仕事を再開しました。

私が開発に加わった月から、運用しているリポジトリにおいて GitHub Actions の月間課金額が急増していました。自分の開発スタイルが Organization 全体に悪影響を与えている可能性もあったため、調査を進めました。

月 Billable 分数 実課金額
2026-01 11,542 $59
2026-02 16,323 $93
2026-03（25日時点） 31,110 $183

コスト急増の原因を切り分けるため、Push数・PR数・ワークフロー構成の3軸を調査しました。結果、ワークフローの追加や実行時間の変化は確認されず、PRあたりのPush回数が4.5倍に増加していたことが主因でした。AI 導入による開発速度向上だけでなく、Claude Code 等による自動コミット（PR作成）の増加が寄与している可能性が高いです。

このリポジトリの構成では、現時点で PHP + フロントエンドの両方を含む push 1回で約 36分の billable time が発生するため、push 回数の増加がダイレクトにコストに跳ね返っていました。

補足: billable time の計算
GitHub Actions の課金はジョブ単位です。2分のジョブが4並列で走れば、壁時計時間は2分ですが billable time は8分になります。テスト系ワークフローが matrix や shard で並列化されていると、1回の push で発生する billable time は見た目以上に大きくなります。

Push 回数を減らす運用は開発速度の観点から望ましくないため、CI 実行基盤そのものを見直すこととし、GitHub Actions 互換のマネージドランナーである Blacksmith の導入を検討しました。

Blacksmith とは

Blacksmith は、マネージド GitHub Actions ランナーサービスです。

  • ゲーミング CPU を採用し、シングルコア性能が高い
  • キャッシュダウンロードが約4倍高速（コロケーション）
  • キュー待ち時間ゼロ
  • 既存の GitHub Actions がそのまま動作
  • 3,000分/月の無料枠

導入は runs-on を1行変えるだけで、既存のワークフローを変更しないので非常に簡単です。

# Before
runs-on: ubuntu-latest

# After
runs-on: blacksmith-4vcpu-ubuntu-2404

ワークフロー単位・ジョブ単位で選択的に適用できるため、効果の高いワークフローだけを切り替えられます。

高速化手段の比較

内心では Blacksmith の導入は調査段階でほぼ決めていたのですが、社内の許可を取るために、念のため他のランナーとの比較を取りました（サードパーティ製は無視）。

GitHub Larger Runners セルフホスト Blacksmith
4vCPU 料金 $0.012/分 インフラ費 + $0.002/分 $0.008/分
CPU 性能 標準クラウド VM 選択可能 ゲーミング CPU
無料枠 なし なし 3,000分/月
プラン要件 Team / Enterprise 制限なし 制限なし
導入コスト Org Settings で作成 サーバー構築・運用 GitHub App + runs-on 変更
ロールバック runs-on 変更 構成巻き戻し runs-on 1行戻すだけ

料金は執筆時点（2026年3月）のものです。

GitHub サブスクリプションが Team以上 であれば GitHub Larger Runners という選択肢もありますが、単純にBlacksmith はコスト・性能・導入の手軽さのバランスで最も合理的でした。

Larger Runners を利用するメリットは今のところサポートが手厚いくらいしか見えないのですが、

  • 定常的にオフィスに出社できるエンジニアがいる
  • 複雑なワークフローを持つフェーズがある
  • さらなる高速化が必要

という状況なのであれば、Self-Hosted の選択肢も十分にあるのではないかとも思います。

導入結果

テスト実行時間が短縮

テスト GitHub 標準 Blacksmith 短縮率
Pest（PHP バックエンドテスト） 109s 21s 81%短縮
Vitest（フロントエンドテスト） 136s 16s 88%短縮

GitHub標準とBlacksmith のインスタンス性能差の効果が顕著に表れました

ワークフロー全体の完了時間がおよそ半分に

ワークフロー GitHub 標準 Blacksmith 短縮率
tests（最遅ジョブ基準） 4m17s 2m16s 47%短縮
vitest（最遅シャード基準） 4m07s 2m10s 47%短縮

このリポジトリでは CI の半分以上がテスト用のワークフローだったので、実行時間の短縮が PR のフィードバックループに劇的に機能しています。ワークフロー全体では 47% の速度改善という結果になりました。

shivammathur/setup-php との相性問題

テストの速度改善という1点では劇的な効果がある一方で、ワークフロー全体でみると2倍程度の速度改善に留まっています。原因として、GitHub 標準のランナーにはプリセットされている PHP イメージが Blacksmith にはなく、都度ビルドしなくてはいけないことでした。

原因

shivammathur/setup-php は GitHub 公式ランナーでは RUNNER_ENVIRONMENT=github-hosted を検出してビルド済みバイナリを使用します（数秒）。Blacksmith 等のサードパーティランナーでは self-hosted 扱いとなり、apt から PHP をフルビルドするため 60秒以上かかります。

これは Blacksmith 固有の問題ではなく、Depot / Namespace / BuildJet 等すべてのサードパーティランナーに共通する既知の問題です。

https://github.com/shivammathur/setup-php/issues/1056

試した回避策

アプローチ 結果
Sticky Disk で /var/cache/apt/archives をキャッシュ FUSE マウントが apt I/O を阻害しハング
Sticky Disk で /opt/hostedtoolcache をキャッシュ setup-php がキャッシュを無視してフルビルド
RUNNER_ENVIRONMENT の上書き setup-php 内部のフェイルセーフで失敗
setup-php のフォーク メンテナに却下済み
useblacksmith/setup-php 存在しない（Node / Python / Gradle はあるが PHP はない）

いずれも効果がなく、現時点では ~60秒のオーバーヘッドを受容する という判断にしています。テスト実行の大幅な高速化がこのオーバーヘッドを十分に上回っているためです。

最終的な設定と効果

PHP Setup の時間がワークフロー全体の処理時間を超えてしまうような場合は、Blacksmith の導入は速度の悪化を招きます。このリポジトリでは、phpstan や typecheck のワークフローは GitHub 標準のランナーを引き続き利用することとしました。

ワークフロー メイン処理 Blacksmith にすると
tests / vitest テスト実行が長い（20〜136s） 47%短縮
lint（Setup PHP なし） Setup PHP を使わない 純粋に高速化
phpstan メイン処理 6s 47%悪化
typecheck メイン処理 2s 85%悪化

メイン処理の実行時間が Setup PHP のオーバーヘッドを十分に上回るかどうか、を導入の判断軸としてください。


小規模プロジェクトでは導入しないほうがいい？

PHP Setup の相性問題が残っている限りは、テストスイート全体が 1〜2分で終わるような小規模プロジェクトでは、Setup PHP の+60秒が全体に占める割合が大きく、Blacksmith にしたらむしろ遅くなります。前述の通り、メイン処理が短いワークフローでは悪化しました。

目安として、PHP プロジェクトで setup-php を使う場合、テスト実行だけで 2分以上かかっていなければ Blacksmith の恩恵はほぼない と考えてよいです。逆に、Setup PHP を使わないフロントエンド専用のワークフローであればこの制約はなく、小規模プロジェクトでも効果があります。

補足

なお、私たちの開発リポジトリではフロントエンド開発に Inertia を利用しているため、vitest に Ziggy のルート生成テストが含まれています。そのために vitest でも PHP Setup が必要という事情がありました。Inertia を利用していない場合には、更なる速度向上が見込めるかと思います。

導入手順

1. Blacksmith GitHub App をインストールする

  1. github.com/apps/blacksmith-sh にアクセス
  2. 対象の Organization を選択（Org Admin 権限が必要）
  3. リポジトリのアクセス範囲を選択

App をインストールしただけではワークフローに影響しません。runs-on: blacksmith-* を明示的に指定したジョブだけが Blacksmith で実行されます。

2. 効果の高いワークフローから選択的に切り替える

runs-on: blacksmith-4vcpu-ubuntu-2404

切り替えの優先順位:

  1. テスト系（実行時間が長く、CPU が要）→ 効果大
  2. フロントエンド lint/build（Setup PHP なし）→ 純粋に高速化
  3. PHP lint/静的解析（Setup PHP あり、メイン処理が短い）→ 個別に検証が必要
  4. Claude Code Review 等の AI レビュー → 実行時間の大半が API 待ち時間のため、ランナー性能を上げても効果はほとんどない。切り替えは不要

まとめ

観点 結果
テスト実行時間 Pest 81%短縮、Vitest 88%短縮
ワークフロー全体 tests / vitest ともに 47%短縮
導入コスト runs-on の1行変更
ロールバック 1行戻すだけ
注意点 setup-php との相性問題あり。ワークフローごとに効果検証が必要

Blacksmith は「低リスクで導入でき、効果の高いワークフローだけを選択的に適用できる」のが最大の強みです。導入を検討する場合、まずは重いテスト系ワークフローだけを切り替えて効果を実測し、段階的に展開していくのをおすすめします

Discussion