GitHub Actions が遅い原因：ローカルより何倍も遅いのはなぜか

手元で 6 分のテストが GitHub Actions で 18 分かかるなら、払っているのは 2 つの差です。手元の PC は、パッケージもツールもビルドの結果も Docker のレイヤーもディスクに残っていて、コアも 8 以上あるのが普通です。GitHub ホストランナーのジョブは、まっさらな VM でそれを全部ダウンロードしてインストールし直し、プライベートリポジトリの ubuntu-latest なら 2 CPU・メモリ 8 GB で動きます。増えた 12 分は、準備と、4 分の 1 のコアで回るテストです。ジョブのステップの時間を見て、準備が大きければ状態が残るマシンを、テストが大きければコアを足してテストランナーに使わせるのが答えです。

Skipbox は、手元の PC と同じように使える GitHub Actions ランナーです。マシンはジョブのあとも残るので、前のジョブで入れたものとビルドしたものが次のジョブまでディスクにあり、ジョブは 4〜16 vCPU で動きます。ワークフローの runs-on を 1行書き換えるだけで、月 6,000 円の定額で使い放題になります。

手元の PC とランナーを比べる

公開リポジトリの ubuntu-latest は 4 CPU・メモリ 16 GB です。ジョブが何を見ているかは、最初のステップで確かめられます。

- run: nproc && free -h && df -h

遅いのは、毎回まっさらな VM から始まるから

GitHub ホストランナーは、ジョブのたびに新しい VM を用意します。前のジョブが入れたものは、何も残っていません。だから同じ準備を毎回くり返します。

上の 4行は、昨日と同じ状態を作り直しているだけです。コードは何も変わっていません。

GitHub のキャッシュを入れても、この構造は変わりません。キャッシュは 1つのリポジトリに 10 GB まで、7日間使われないと消え、新しい機能ブランチはほかのブランチのキャッシュを使えません。当たったときでも、毎回アーカイブのダウンロードと展開が走ります（キャッシュの上限）。

テストが使えるコア

テストランナーは、マシンに合わせてワーカーの数を決めます。Jest はコアの数から 1 を引いた数で、2 CPU なら 1 つです。Playwright の既定はコアの半分で、CI ではワーカー 1 つが推奨です。pytest は -n auto を付けるまで 1 本です。手元で 8 コアに広がるテストも、ランナーでは 1 つか 2 つずつしか進みません。コアの数は、ワークフローの設定では増えません。

待ち時間は、毎日チーム全員にかかる

準備に 3分かかるジョブを、チームで 1日 100回動かすなら、準備だけで 1日 300分です。プルリクエストを出した人は、そのたびに結果を待ちます。レビューもマージも、その分だけ遅れます。

しかも分課金では、待っている分数にも請求が来ます。4 vCPU のランナーの月の請求はこうなります。

GitHub の額は、GitHub Team に含まれる無料分を引いたあとの請求です。自分のチームの分数は、トップページの料金計算で出せます。

CI の回数は、これから増える一方です。

• AI のコーディングエージェント。 エージェントが push するたびに CI が走ります。待ち時間も請求も、push の数で増えます。
• テストの追加。 E2E テストやマトリクスを足すと、1回の push で準備が何回もくり返されます。
• 予算の上限。 請求を抑えようと予算を設定すると、月の途中でジョブが始まらなくなり、マージが止まります。

自分で速くしようとすると

先にやるのは、お金のかからないワークフローの直しです。concurrency のグループで古い実行をキャンセルし、変わっていないファイルのジョブを飛ばし、独立したジョブを待たせている needs: を外します（効く順番）。そのうえで GitHub ホストランナーのまま速くするには、こういう作業が要ります。

• ロックファイルのハッシュでキャッシュのキーを作り、restore-keys を調整する
• buildx を入れ、Docker のキャッシュを cache-to で書き出して、10 GB の枠に収める
• テストをシャードに分ける。シャードごとに準備がくり返されるので、分数はかえって増える
• セルフホストランナーを立てるなら、サーバーの用意、OS の更新、ジョブの後片付け、落ちたときの復旧を自分でやる

どれも、ジョブのたびに状態を作り直す仕組みを補う作業です。Skipbox なら、マシンが残るので、どの設定も要りません。

Skipbox に替えると

準備がディスクに残る

Skipbox は、アカウント専用のマシンでジョブを動かし、そのマシンを使い続けます。Docker のイメージ・レイヤー・ビルドキャッシュ、npm・pnpm・pip・Gradle などのパッケージのキャッシュ、setup-node などで入れたツール、チェックアウトしたコードと Cargo の target/・turbo のキャッシュが、次のジョブまで残ります。GitHub 公式の 7倍以上のキャッシュ容量があり、7日で消えることも、ブランチで分けられることもありません。

大きなマシンも定額

実行時間は無制限です。コンパイルやテストのワーカーはコアの数だけ動くので、大きなマシンほど CPU を使うステップが短くなります。Skipbox のジョブは GitHub の分数を使わないので、GitHub の予算で止まることもありません。

マシンの管理は要らない

マシンの用意、OS とツールの更新、ジョブごとの後片付け、ヘルスチェックと自動復旧まで、Skipbox が行います。

移行は runs-on を 1行書き換えるだけ

jobs:
  build:
    runs-on: skipbox # ubuntu-latest から書き換える
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

1. Skipbox に GitHub でログインする
2. Skipbox の GitHub アプリを入れて、使うリポジトリを選ぶ
3. runs-on を書き換えて push する

1回目のジョブで準備したものが、2回目からはディスクにあります。

セキュリティ

• マシンはアカウントごとの専用です。ほかの会社のジョブと同じマシンで動くことはありません。
• ジョブが終わるたびに、ランナーの認証情報、プロセスとコンテナをすべて消します。2026年11月13日からは、チェックアウトしたコードと Cargo のビルド結果（target/）を専用のマシンに残し、次のジョブで使います。「毎回クリーン」なら、ジョブごとに新しいマシンで動きます。
• 書き込み権限のない人のコード（フォークからのプルリクエストなど）は、使い捨ての新しいマシンで動きます。

くわしくはジョブの分離のしくみにあります。

いちばん遅いジョブで試す

カード不要で、7日間かジョブの合計 3,000分まで無料です。いちばん遅いジョブを 1つ runs-on: skipbox に替えて、続けて 2回動かしてください。GitHub での時間と、ステップごとに比べてみてください。

2026年11月13日 更新