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

> 2026年の GitHub-hosted Actions ランナーへの最良の代替。マネージドおよび self-hosted の選択肢を、コスト、速度、キャッシュ、信頼性で比較。

Source: https://latchkey.dev/ja/learn/compare-runners/best-github-actions-runner-alternatives  
Updated: 2026-08-20

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

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

## Comparison

| プロバイダ | モデル | 得意分野 |
| --- | --- | --- |
| Latchkey | Managed | 自己修復 + 低コストランナー |
| Depot | Managed | 高速な Docker ビルド + リモートキャッシュ |
| Blacksmith | Managed | 高クロック CPU |
| WarpBuild | Managed | マルチクラウド + スナップショット |
| Namespace | Managed | ランナー + ビルド基盤 |
| BuildJet | Managed | 手頃で高速なランナー |
| RunsOn | 自社 AWS 上の self-hosted | 生の EC2 コスト、自社クラウド |
| Actuated | self-hosted microVM | 自社ハードウェア上の隔離 |
| Ubicloud | Managed (オープンソース) | 低コスト、オープンソース |
| Cirun | 自社クラウド上 | オンデマンドの GPU ランナー |
| Ubicloud | サイズ別の公表なし | 月$2のクレジット | GitHub Actionsより7倍安いと主張 |

## 選び方

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。

> RunsOn is the one to model separately rather than compare per minute. At high volume a flat EUR 3,600/yr licence against your own EC2 spend beats every metered provider here; at low volume it is the most expensive option on the page.

## 多くが欠く差別化要因

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

| If your bottleneck is | The provider built for it | Mechanism |
| --- | --- | --- |
| Single-threaded compile or bundle | Blacksmith | Bare-metal gaming CPUs, single-thread PassMark 4484 |
| Docker layer builds and large caches | Depot | RAM disk by default, unlimited cache at 1,000 MiB/s |
| Many short jobs in a wide matrix | Depot | Per-second billing removes per-minute rounding |
| Raw Linux compute cost at equal vCPU | Namespace | Unit pricing from $0.001/vCPU-min prepaid |
| Very high volume with in-house AWS | RunsOn | Flat annual licence, compute billed by AWS to you |
| Data residency or private networking | RunsOn or WarpBuild BYOC | Runners execute inside your own cloud account |
| Jobs that fail intermittently and get re-run | Latchkey | Detects, repairs, and retries transient failures on the runner |

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

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

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

> 料金で選ぶ前に、実行のうちどれだけが過去に失敗したjobの再実行かを測ってください。それが数パーセントを超えるなら、その数字は料金表の20〜40%の差を上回ります。

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

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

```workflow.yml
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.

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

## 結論

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

## FAQ

### 最も安いGitHub Actions runnerの代替は?

2 vCPU / 8 GBのLinux構成の公表定価では、$0.0025/minのLatchkeyがこのページで最安です。Namespaceは前払いでおよそ$0.002/minとさらに低くできますが、そのunitモデルでは8 GBではなく2 vCPUと4 GBになります。非常に大規模な場合はRunsOnが両者を下回り得ます。年額固定のライセンス料を課金し、コンピュートは自身のAWS請求に載るためです。

### パブリックリポジトリではGitHub Actions runnerは無料ですか?

はい。GitHubは、標準のGitHubホスト型runnerがパブリックリポジトリで無料かつ無制限であると文書化しています。またパブリックリポジトリでは、プライベートリポジトリの2 vCPU / 8 GBではなく4 vCPU / 16 GBが割り当てられます。例外は大型runnerで、これはパブリックリポジトリでもGitHubが課金します。

### GitHub Actionsのrunnerプロバイダの切り替えは難しいですか?

いいえ。ここに挙げたdrop-in型のプロバイダはすべて `runs-on` labelで選択するため、導入は1行の変更で、元に戻すのも同じです。runnerの選択はjob単位なので、pipelineを移行せずに1つのjobだけで試せます。

### なぜベンダーはGitHub Actionsの半額だと主張するのですか?

それがLinux 2-coreの旧定価$0.008/minに対しては事実だったからです。GitHubは現在$0.006/minを掲示しているため、$0.004という料金は50%ではなく33%の節約です。いくつかのベンダーサイトはこの主張を更新していないので、見出しの数字で事業判断を組み立てる前に、現行の定価で計算し直してください。

### マネージドrunnerとセルフホストrunnerの違いは?

セルフホストとは、マシンのプロビジョニング、パッチ適用、セキュリティ確保、スケーリングを自分で行い、クラウドプロバイダに直接支払うことです。マネージドrunnerはベンダーが運用して分単位で課金し、jobごとにクリーンなVMという一時的なモデルを保ちます。RunsOnとWarpBuildのBYOCはその中間で、ベンダーがコントロールプレーンを運用し、コンピュートは自分のクラウドアカウントで動きます。

### これらのプロバイダの中に、失敗したjobを自動で修復するものはありますか?

挙げたプロバイダの中ではLatchkeyだけです。他は最後まで走るjobの速度と価格で競っています。他のプロバイダで一時的な失敗が起きると、jobは失敗し、失敗したminuteと再実行が課金され、人が再実行を押すのを待ちます。

### 複数のプロバイダを同時に使えますか?

はい。大規模なmonorepoではむしろ正しいことが多いです。runnerの選択はjob単位なので、同じworkflowファイル内でコンパイル中心のjobを一方に、Docker中心のjobを他方に向けられます。代償は、複数のベンダー関係、請求、ステータスページを見続けることです。

### 必要なのが速いrunnerか、より信頼できるrunnerかをどう判断しますか?

2つの数字を測ってください。最も遅いjobに `/usr/bin/time -v` を追加してCPU律速かI/O待ちかを見ること、そして直近1か月のworkflow実行から、失敗した実行の再試行が占める割合を計算することです。前者はどのアーキテクチャを買うべきかを、後者はそもそも料金が最適化すべき対象なのかを教えてくれます。

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt