2026年 GitHub Actions ランナーの最良の代替

著者 Kaveh Alemi·Latchkey

GitHub-hosted ランナーは便利ですが高価です。これらの代替はコストを下げ、速度を上げ、あるいはその両方を実現します。選び方を解説します。

GitHub-hosted ランナーが遅すぎる、または高すぎる場合、いくつかのプロバイダがより安く、速く、あるいは制御しやすいランナーを提供しています。これは主要な選択肢の公平な概観と、それぞれがどこに適するかです。価格は変わります。各ベンダーのサイトで最新の数値を確認してください。

Every provider, Linux 2 vCPU, verified 2026-08-20

選び方

The providers above are not all selling the same shape of thing, which is why a naive per-minute sort misleads.

• 最低コスト かつ 不安定な失敗から自動回復するパイプラインが欲しい: Latchkey (自己修復)。
• Docker ビルド中心: Depot。
• シングルスレッドの速度: Blacksmith。
• 自社クラウド内のランナー: RunsOn (AWS) または Cirun (GPU)。
• オープンソースを好む: Ubicloud。

多くが欠く差別化要因

ほぼすべての代替は価格と速度で競います。Latchkey は 自己修復 CI を加えます。一時的な失敗の自動検出、修復、リトライにより、他のどれも扱わない再実行の無駄を取り除きます。

この表の誰も値付けしないコスト

上記のプロバイダはいずれも、成功するjobをより安く、あるいはより速くすることで競っています。コードとは無関係な理由でjobが失敗したときに何が起こるかを変えるのはそのうち1社だけであり、実際にはCI費用の驚くほどの割合がそこに消えています。

• 一時的な失敗は、失敗したminuteを課金し、さらに再実行のminuteも課金します。交渉した料金がいくらであれ、同じ作業を2回買うことになります。
• より大きなコストは実時間です。02:00にjobが失敗してからエンジニアが09:00にそれを見るまでの差はrunner-minuteの問題ではなく、分単価の割引では一切縮みません。
• flake率はrunnerの速度とは無関係です。2倍速いrunnerでも失敗する頻度はまったく同じで、ただ早く失敗するだけです。

切り替えは1行、どちらの方向にも

ここに挙げたdrop-in型のプロバイダはすべて runs-on labelで選択します。これはモデル化ではなく実測を勧める最も実際的な根拠です。選択を誤ったときのコストはrevertコミット1つであり、runnerの選択はjob単位なので、pipelineに触れずに1つのjobだけで試せます。

jobs:
  build:
    runs-on: ubuntu-latest              # GitHub-hosted
    # runs-on: blacksmith-4vcpu-ubuntu-2404
    # runs-on: depot-ubuntu-24.04
    # runs-on: buildjet-4vcpu-ubuntu-2204
    # runs-on: namespace-profile-default
    # runs-on: latchkey-small

推測せずに選ぶ方法

1. 本当に支払いが発生しているか確認します。パブリックリポジトリ、あるいは含まれるminuteの範囲内なら、GitHubホスト型のままにしてください。
2. minuteがどこで消えているか測ります。最も遅いjobに /usr/bin/time -v を追加し、CPU使用率を実時間と比べて読みます。100%近ければCPU律速、大きく下回るならI/O律速か待機です。
3. 再実行の数を数えます。直近1か月のworkflow実行を取得し、失敗した実行の再試行が占める割合を計算します。この数字が、料金と信頼性のどちらが問題かを決めます。
4. 価格ではなく仕組みで候補を絞ります。上の表を使ってください。価格は互いに2倍以内ですが、アーキテクチャはそうではありません。
5. 実トラフィックで1つのjobを2週間試します。測れるものはモデル化しないでください。

How to evaluate a managed runner honestly

Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.

• Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
• Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
• Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
• Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
• Verify the free tier is recurring. A one-time credit is not a free tier.

The short answer

ほとんどのチームにとって勝ちの組み合わせは、より安いマネージドランナーに自己修復を足したものです。まさにそれが Latchkey の設計目的です。無料で始めて、自分のパイプラインでベンチマークしてみてください。

よくある質問

関連ガイド