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

> 手元で 6 分のテストが GitHub Actions で 18 分かかるのは、まっさらな VM が最初のテストの前にダウンロード・インストール・ビルドをやり直すことと、プライベートリポジトリの ubuntu-latest が 2 CPU・メモリ 8 GB であることの 2 つです。Skipbox なら準備したものがジョブのあとも専用のマシンに残り、4〜16 vCPU を月 6,000 円の定額で使い放題です。

手元で 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 円の定額で使い放題になります。

- 依存パッケージ、Docker のレイヤー、ツール、ビルドの結果がジョブのあとも残り、毎回のダウンロードとビルドし直しを飛ばします
- ラベルで 4・8・16 vCPU。プライベートリポジトリの `ubuntu-latest` は 2 CPU
- 4 vCPU を月 20,000分使うと、GitHub は 約 35,120 円、Skipbox は 6,000 円

**GitHub Actions を月額固定・使い放題に** Skipbox は、アカウント専用のマシンで GitHub Actions のジョブを動かします。何分動かしても月 6,000 円。ジョブが終わっても Docker のレイヤーと依存パッケージのキャッシュが残るので、次のジョブはすぐ始まります。

4 vCPU のランナーを月 20,000分 使うと、GitHub 約 35,120 円 → Skipbox 6,000 円。毎月 約 29,120 円お得。

移行は `runs-on: skipbox` に 1行書き換えるだけです。

[7日間無料で試す](https://app.skipbox.dev/sign-in?ref=g-github-actions-slow-ja)

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

| | 手元の PC | GitHub の `ubuntu-latest`（プライベートリポジトリ） |
|---|---|---|
| CPU とメモリ | 8 コア以上が普通 | 2 CPU・メモリ 8 GB（[GitHub ホストランナー](https://docs.github.com/ja/actions/reference/runners/github-hosted-runners)） |
| ディスク | 数百 GB。昨日の状態が残っている | SSD 14 GB。プロジェクトのものは何もない |
| パッケージ | 入っている | ダウンロードし直すか、キャッシュのアーカイブから戻す |
| ビルドの結果 | 差分だけコンパイルする | 全部コンパイルする |
| Docker | 前のビルドのレイヤーがある | レイヤーがない |

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

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

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

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

| ステップ | GitHub ホストランナー | Skipbox |
|---|---|---|
| Node・Python・Java を入れる | 毎回ダウンロード | 前のジョブのツールがある |
| 依存パッケージを入れる | キャッシュのアーカイブをダウンロードして展開。外れたらレジストリから全部 | パッケージのキャッシュがディスクにある |
| Docker のイメージをビルド | レイヤーなしで一からビルド | 前のビルドのレイヤーをそのまま使う |
| コンパイル | クレートもパッケージも一から | 前のジョブの Cargo の `target/` と turbo のキャッシュがある |
| テストを走らせる | プライベートリポジトリの `ubuntu-latest` なら 2 CPU | 4 vCPU から |

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

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

## テストが使えるコア

テストランナーは、マシンに合わせてワーカーの数を決めます。[Jest](https://jestjs.io/docs/cli#--maxworkersnumstring) はコアの数から 1 を引いた数で、2 CPU なら 1 つです。[Playwright](https://playwright.dev/docs/ci#workers) の既定はコアの半分で、CI ではワーカー 1 つが推奨です。pytest は `-n auto` を付けるまで 1 本です。手元で 8 コアに広がるテストも、ランナーでは 1 つか 2 つずつしか進みません。コアの数は、ワークフローの設定では増えません。

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

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

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

| 月の実行時間（4 vCPU） | GitHub | Skipbox S | 毎月の差額 |
|---|---|---|---|
| 10,000分 | 約 16,140 円 | 6,000 円 | **約 10,140 円** |
| 20,000分 | 約 35,120 円 | 6,000 円 | **約 29,120 円** |
| 30,000分 | 約 54,110 円 | 6,000 円 | **約 48,110 円** |

GitHub の額は、GitHub Team に含まれる無料分を引いたあとの請求です。自分のチームの分数は、[トップページの料金計算](https://skipbox.dev/?lang=ja&ref=g-github-actions-slow-ja#cost)で出せます。

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

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

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

先にやるのは、お金のかからないワークフローの直しです。concurrency のグループで古い実行をキャンセルし、変わっていないファイルのジョブを飛ばし、独立したジョブを待たせている `needs:` を外します（[効く順番](https://skipbox.dev/ja/guides/speed-up-github-actions)）。そのうえで 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日で消えることも、ブランチで分けられることもありません。

### 大きなマシンも定額

| ラベル | マシン | 月額 |
|---|---|---|
| `skipbox` | 4 vCPU・メモリ 16 GB | 6,000 円（S） |
| `skipbox-8x16` | 8 vCPU・メモリ 16 GB | 12,000 円（M） |
| `skipbox-16x32` | 16 vCPU・メモリ 32 GB | 23,000 円（L） |

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

### マシンの管理は要らない

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

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

```yaml
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/`）を専用のマシンに残し、次のジョブで使います。「毎回クリーン」なら、ジョブごとに新しいマシンで動きます。
- 書き込み権限のない人のコード（フォークからのプルリクエストなど）は、使い捨ての新しいマシンで動きます。

くわしくは[ジョブの分離のしくみ](https://docs.skipbox.dev/ja/isolation)にあります。

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

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

## よくある質問

### GitHub Actions はなぜ遅い？

GitHub ホストランナーのジョブは、毎回まっさらな VM で始まるからです。ツールのダウンロード、依存パッケージのインストール、Docker のイメージのビルド、コンパイルを、ジョブのたびに一からやり直します。しかもプライベートリポジトリの ubuntu-latest は 2 CPU・メモリ 8 GB なので、重いステップは 2 つずつしか進みません。Skipbox はアカウント専用のマシンを使い続けるので、それらが次のジョブまでディスクに残り、4 vCPU から使えます。

### 手元では 6 分のテストが、GitHub Actions だと 18 分かかる。なぜ？

2 台のマシンを比べてください。手元の PC はパッケージが入っていて、ビルドの結果も Docker のレイヤーもディスクにあり、コアも 8 以上あることが多いです。CI のジョブは空の 2 CPU の VM で始まるので、増えた分は準備（ダウンロード、インストール、イメージのビルド）と、4 分の 1 のコアで回るテストです。どちらが大きいかは、ジョブのステップの時間でわかります。準備なら状態が残るマシンを、テストならコアを足して、テストランナーに使わせます。

### GitHub Actions のキャッシュを入れたのに遅いのはなぜ？

キャッシュが当たっても、ジョブのたびにアーカイブをダウンロードして展開するからです。しかも GitHub のキャッシュは 1つのリポジトリに 10 GB まで、7日間使われないと消え、ほかの機能ブランチのものは使えません。Skipbox では、パッケージのキャッシュも Docker のレイヤーも、最初からマシンのディスクにあります。

### ランナーを変えるのとワークフローを最適化するのは、どちらが効く？

先にワークフローの無料の直しをします。古い実行のキャンセル、変わっていないファイルのジョブを飛ばすこと、独立したジョブを待たせている needs: を外すこと。そのあとに残る、ジョブごとにくり返す準備と、コアを使い切るステップはマシンの問題で、ディスクが残りコアの多いランナーに替えれば runs-on の 1行で消えます。

### ランナーを替えると、ワークフローを書き直す必要はある？

ありません。Linux のジョブなら、runs-on を skipbox に書き換えるだけです。マシンは Ubuntu 24.04 で、Docker、Node.js、Python が入っています。ステップやアクションはそのまま動きます。

### 試すのにお金はかかる？

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

2026-11-13 更新 · https://skipbox.dev/ja/guides/github-actions-slow