ランナー
オープンソースの CI での計測
実在するオープンソースのプロジェクトの CI ジョブを、GitHub のランナーと Skipbox の専用ランナーで計測した結果。すべての実行を GitHub で公開しています。
よく知られたオープンソースのプロジェクトから CI ジョブを一つずつ選び、プロジェクト自身のジョブをステップはそのままに、GitHub ホステッドランナーと Skipbox の専用ランナーで動かしました。すべての実行は GitHub の skipbox-dev で公開しているので、ログを開いて各ステップの時間を確かめられます。
結果
ステップはそのまま、GitHub の ubuntu-24.04 と Skipbox の専用ランナーで。各 4 vCPU、同じコミットの2回目以降。
| プロジェクト | 言語 | GitHub 2回目以降 | Skipbox 2回目以降 | 速さ | GitHub 1回目 | Skipbox 1回目 |
|---|---|---|---|---|---|---|
| BurntSushi/ripgrep | Rust | 200秒 194秒 · 206秒 | 40秒 39秒 · 40秒 | 5倍 | 209秒 | 161秒 |
| helix-editor/helix | Rust | 330秒 293秒 · 366秒 | 224秒 222秒 · 226秒 | 1.5倍 | 627秒 | 442秒 |
| tauri-apps/tauri | Rust | 246秒 220秒 · 271秒 | 53秒 53秒 · 53秒 | 4.6倍 | 474秒 | 285秒 |
| cli/cli | Go | 163秒 155秒 · 170秒 | 137秒 137秒 · 137秒 | 1.2倍 | 294秒 | 222秒 |
| prometheus/prometheus | Go | 335秒 326秒 · 344秒 | 273秒 287秒 · 259秒 | 1.2倍 | 1,212秒 | 967秒 |
| vitejs/vite | TypeScript | 141秒 144秒 · 137秒 | 100秒 | 1.4倍 | 166秒 | 121秒 |
| withastro/astro | TypeScript | 528秒 605秒 · 450秒 | 30秒 31秒 · 28秒 | 17.6倍 | 508秒 | 344秒 |
| pytest-dev/pytest | Python | 416秒 390秒 · 441秒 | 365秒 344秒 · 386秒 | 1.1倍 | 537秒 | 347秒 |
| google/guava | Java | 818秒 715秒 · 921秒 | 651秒 678秒 · 624秒 | 1.3倍 | 788秒 | 747秒 |
| mastodon/mastodon | Docker | 29秒 29秒 · 28秒 | 29秒 30秒 · 28秒 | 1倍 | 550秒 | 388秒 |
表には計測したすべてのプロジェクトがあり、トップページではそのうち3件を紹介しています。「2回目以降」は2回目と3回目の実行、「1回目」は最初の実行です。太字の時間はそれぞれの実行の中央値で、その下に元になった実行をすべて、それぞれの時間つきでリンクしています。時間は GitHub のジョブの API が返す、ジョブの開始から終了までの時間で、キューで待った時間は含みません。失敗した実行も含みません。
比べたもの
- GitHub：プロジェクトのパブリックなフォークで、標準の
ubuntu-24.04ランナー。GitHub のパブリックリポジトリの標準ランナーは 4 CPU・16 GB で、メモリはこの計測での Skipbox のマシン（8 GB）の 2倍です。より大きなランナーは使っていません。 - Skipbox：本番と同じランナーのイメージからつくった VM。4 vCPU・8 GB（計測した日のいちばん小さいプランと同じ）で、Skipbox のサーバーで動かしました。2026年11月14日から、このプランのメモリは GitHub のこのランナーと同じ 16 GB です。ジョブとジョブのあいだは、組織専用のマシンと同じように準備と後片付けをします。認証情報はジョブごとに消し、キャッシュ・Docker のイメージ・チェックアウトしたコード・Cargo の
target/は残します。
Skipbox のサーバーは日本にあり、CPU は Intel Core Ultra 7 265F です。VM には、そのうち最大 4.6 GHz の高効率コアを4つ割り当てました。このサーバーの本番のジョブには、最大 5.3 GHz の高性能コアから先に割り当てます。Hetzner Cloud の組織専用のマシンは別の CPU で動いていて、今回は計測していません。コアの速さから来る差は、このサーバーでのものです。
各プロジェクトの動かし方
- コミットは、プロジェクト自身のリポジトリでそのジョブが最後に成功した実行のものです。一つのプロジェクトの実行は、両方の側ともすべてこのコミットを使います。
- ジョブのステップは、プロジェクトのワークフローから一字一句そのまま写しています。変えたのは計測に要るところだけです。トリガーを手動の起動にし、
runs-onで動かす側を選び、マトリックスは Ubuntu の一つだけを残し、シークレットを外しました。 - それぞれの側で3回続けて動かします。1回目はキャッシュがまったくない状態から始めます。2回目と3回目は同じコミットをもう一度動かすので、前の実行がつくったものがすべて見つかります。両方の側にとって最良の条件です。
差が出るところ
差は二つのところから出ます。どちらが効いているかは、プロジェクトごとに表から読めます。
- 残るディスク：GitHub では、ジョブは毎回、空のディスクの新しい VM で始まり、キャッシュをネットワーク越しに戻します。Skipbox の組織専用のマシンでは、前のジョブのキャッシュ、Docker のレイヤー、チェックアウトしたコード、ビルド結果がディスクに残っているので、Rust の差分ビルドは変わったところだけをコンパイルします。tauri の差はおもにここから出ています。Skipbox では2回目以降が1回目よりずっと速く、両方の側の差も1回目より2回目以降のほうがずっと大きくなっています。astro も同じです。Turborepo のキャッシュ（turbo 2）が残るので、2回目以降はどのタスクも動かし直さず、キャッシュから結果を戻します。何が残り何が消えるかは VM の分離にあります。
- 速いコア：ディスクに何も残っていなくても、同じジョブが Skipbox のサーバーのコアでは速く動きます。各プロジェクトの「1回目」の列にあらわれています。pytest の差はおもにここから出ていて、何も残っていない1回目でも Skipbox のほうが速くなっています。
自分で計測した結果の公開
Skipbox を計測し、その結果を公開するのに、私たちへの連絡や許可はいりません。結果には次の三つを添えてください。
- プラン（例：S、4 vCPU / 16 GB）、またはトライアル
runs-onのラベル（例：skipbox）- 計測した日付
2026年11月13日 更新