# GitHub Actions のキャッシュ上限（容量制限）: キャッシュが消える・復元が遅い・ヒットしない理由

> GitHub Actions のキャッシュはリポジトリごと 10 GB まで。超えると最後に使われたのが古いものから消え、7日間使われないキャッシュも消えます。当たっても、新しい VM に毎回ダウンロードし直しです。直し方ごとのコストと、ディスクが残るランナーならキャッシュの多くが要らなくなる理由をまとめました。Skipbox は月 6,000 円の定額です。

GitHub Actions のキャッシュは、リポジトリごとに 10 GB までです。超えても新しいキャッシュは保存され、そのかわり最後に読まれたのが古いものから、上限を下回るまで消されます。7日間どのジョブにも読まれなかったキャッシュも消えます。読めるのは自分のブランチとデフォルトブランチのキャッシュだけなので、新しいブランチの最初の実行はよく外れます。そして当たっても、中身はダウンロードです。GitHub ホストランナーのジョブは毎回新しい VM で始まるので、アーカイブを毎回ダウンロードして展開し直します。上限は引き上げられ、キーも工夫できますが、このダウンロードは消えません。

Skipbox なら、ダウンロードそのものがなくなります。ジョブはアカウント専用のマシンで動き、マシンはジョブのあとも残ります。npm・pnpm・Gradle・Go・Cargo のキャッシュも Docker のレイヤーも、前のジョブのままディスクにあります（S で 80 GB。GitHub のランナーは 14 GB）。actions/cache が保存したものもマシンのそばに残るので、復元は手元からの読み込みです。ワークフローは `runs-on: skipbox` の 1行を書き換えるだけ。料金は月 6,000 円の定額で、実行時間は無制限です。

- GitHub はリポジトリごと 10 GB、7日使われないと削除、当たっても毎回ダウンロード
- Skipbox はパッケージのキャッシュと Docker のレイヤーが専用のマシンのディスクに残り、キャッシュに使える容量は GitHub の 7倍以上
- 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-cache-size-limit-ja)

## GitHub のキャッシュのルール

GitHub の[依存関係のキャッシュのリファレンス](https://docs.github.com/ja/actions/reference/workflows-and-actions/dependency-caching)、[Actions の課金](https://docs.github.com/ja/billing/concepts/product-billing/github-actions)、[10 GB を超えるキャッシュについての変更履歴](https://github.blog/changelog/2025-11-20-github-actions-cache-size-can-now-exceed-10-gb-per-repository/)から:

| ルール | GitHub の動き |
|---|---|
| 容量 | 既定でリポジトリごと 10 GB。すべてのブランチとワークフローで分け合う |
| 容量を超えたとき | 新しいキャッシュを保存し、最後に使われた日が古いものから、上限を下回るまで消す。削除は 1 時間ごと |
| 使われないキャッシュ | 7日を超えて読まれていないものを消す |
| 上限の引き上げ | Pro・Team・Enterprise のアカウントなら、管理者が容量と日数を引き上げられる。10 GB を超えた分は、1 時間ごとの最大の使用量で課金。予算に達すると、次の請求期間まで読み取り専用 |
| ブランチ | 読めるのは自分のブランチとデフォルトブランチのキャッシュ。プルリクエストの実行はベースブランチのものも。隣のブランチや子のブランチのものは読めない |
| プルリクエスト | プルリクエストのキャッシュはマージ用の ref に結び付き、読めるのはそのプルリクエストの再実行だけ |
| 中身 | 書き換えられない。同じキーがあれば保存し直さない |
| ヒット | `cache-hit` が `true` になるのは `key` に完全一致したときだけ。`restore-keys` での一致は `false` |
| 回数 | リポジトリごとに 1 分あたり保存 200 回、ダウンロード 1,500 回まで |

## キャッシュが消える理由

リポジトリが保存するものは、すべて 1 つの 10 GB に入ります。ブランチごと、プルリクエストごとに別々のキャッシュができます。Node のバージョン 3 つと OS 2 つのマトリックスなら、6 つです。Docker の `type=gha` のビルドキャッシュも、同じ 10 GB に入ります。1 日の保存が上限を超えると、保存のたびに古いキャッシュが消え、次のジョブが使うはずだったものまで消えます。GitHub はこれをキャッシュのスラッシング（cache thrashing）と呼んでいます。

何が枠を埋めているかは、大きい順に一覧できます。

```bash
gh cache list --sort size_in_bytes --limit 20
```

リポジトリの Actions › Caches の画面でも、ブランチと最後に使われた日つきで見られます。

## 復元が遅い理由

GitHub ホストランナーでキャッシュが当たるというのは、新しい VM へのダウンロードと展開のことです。時間はアーカイブの大きさに比例するので、数 GB に育ったキャッシュは、飛ばしたかったインストールと同じくらいかかることがあります。ダウンロードが止まると、actions/cache のセグメントのタイムアウト（既定で 10 分、`SEGMENT_DOWNLOAD_TIMEOUT_MINS`）で打ち切られます。

戻ってくるものも、思っているより少ないことが多いです。[setup-node](https://github.com/actions/setup-node) の `cache:` が保存するのはパッケージマネージャーのダウンロードのキャッシュで、`node_modules` ではありません。復元のあとも、`npm ci` はすべてのパッケージを入れ直します。setup-python の pip のキャッシュも同じで、戻るのはダウンロードしたファイルだけ、環境は毎回作り直しです。

## キャッシュがヒットしない理由

- **キーが変わった。** `hashFiles('**/package-lock.json')` を入れたキーは、ロックファイルが変わるたびに外れます。`restore-keys` で部分一致させられますが、そのとき `cache-hit` は `false` です。
- **新しいブランチ。** 読めるのはデフォルトブランチのキャッシュで、ほかの feature ブランチのものは読めません。デフォルトブランチでワークフローが動いていなければ、読むものがありません。
- **消された。** 容量の上限か、7日の期限で消えています。
- **保存されていない。** キャッシュは書き換えられないので、同じキーがあると保存し直さず、中身は最初に保存したときのままです。フォークからのプルリクエストは、保存そのものが許されないことがあります。

**同じ実行の次のジョブにファイルを渡す**なら、別の道具です。キャッシュは次の実行のためのもの。同じワークフローのあとのジョブが使うビルドの成果物は、`actions/upload-artifact` と `actions/download-artifact` で渡します。アーティファクトは 10 GB の枠とは別のストレージですが、これも新しい VM へのダウンロードです。

## GitHub のランナーのままでできること、そのコスト

- **上限を引き上げる。** 消えにくくなりますが、Pro・Team・Enterprise のアカウントが要り、10 GB を超えた分は使った容量に応じて課金されます。復元はダウンロードのままで、大きいキャッシュほどダウンロードに時間がかかります。
- **保存するものを減らす。** `node_modules` やビルドの成果物ではなく、`~/.npm` や pnpm のストアを保存します。保存はデフォルトブランチだけにして、どのジョブも `actions/cache/restore` で読み、`actions/cache/save` は 1 つのジョブだけで使います。手間がかかり、キャッシュが小さいぶん戻るものも減ります。
- **キーを直す。** ロックファイルをキーにし、`restore-keys` を足し、デフォルトブランチへの push でもワークフローを動かして、新しいブランチが読めるものを用意します。
- **ディスクが残るセルフホストランナー。** ダウンロードも 10 GB の枠もなくなります。そのかわり、マシンの運用は自分で持ちます。OS の更新、キャッシュを消さないジョブごとの後片付け、壊れたときの復旧です。

## ディスクが残るマシンが答えになるとき

キャッシュがあるのは、マシンが忘れるからです。GitHub ホストランナーはジョブのたびに新しい VM なので、ジョブは状態を GitHub のストレージに預け、次のジョブで取り戻します。マシンが残るなら、その状態は最初からディスクにあります。パッケージマネージャーのキャッシュ、ツールのキャッシュ、Docker のイメージとビルドキャッシュ、ビルドの成果物まで。

実在のプロジェクトの CI を、[それぞれのジョブそのままで動かした結果](https://skipbox.dev/ja/guides/rust-cache-slow-rust-ci)です。

- **astro（Node.js、Turborepo）:** GitHub で 528 秒、Skipbox の専用のマシンで 30 秒。turbo のキャッシュが残るので、2 回目以降は 40 のビルドのタスクを動かさず、キャッシュから結果を戻します。
- **helix（Rust）:** ツールチェーンとキャッシュの復元のステップが、専用のマシンで 9〜10 秒、GitHub で 41〜46 秒。
- **tauri（Rust）:** GitHub で 246 秒、`target/` が残る専用のマシンで 53 秒。

## Skipbox ならキャッシュがマシンに残る

プランごとに、アカウント専用のマシンが付き、ジョブのあとも残ります。

- **パッケージのキャッシュはディスクに残ります。** `~/.npm`、pnpm のストア、各ツールの `~/.cache`、Go・Gradle・Cargo・Maven のキャッシュ、`setup-*` で入れたツールも。復元するものがありません。
- **Docker のイメージ、レイヤー、ビルドキャッシュも残ります。** `docker build` は前のビルドのレイヤーを使います（[Docker のレイヤーキャッシュ](https://skipbox.dev/ja/guides/docker-layer-cache-github-actions)）。
- **actions/cache・setup-*・rust-cache はそのまま使えます。** 保存したものは GitHub のストレージではなくマシンのそばに残り、容量は GitHub のリポジトリごと 10 GB より多く、復元は手元からの読み込みです。
- **ディスクの中身に 7日の期限はありません。** ジョブのあとでディスクがほぼいっぱいになるまで何も消さず、いっぱいになったら、使われたのがいちばん古いものから消します。

S で、キャッシュに使える容量は GitHub の 7倍以上。マシンの大きさは、ジョブのラベルで選びます。

| ラベル | マシン | ディスク | プラン |
|---|---|---|---|
| `skipbox` | 4 vCPU・メモリ 16 GB | 80 GB | S、月 6,000 円 |
| `skipbox-8x16` | 8 vCPU・メモリ 16 GB | 160 GB | M、月 12,000 円 |
| `skipbox-16x32` | 16 vCPU・メモリ 32 GB | 320 GB | L、月 23,000 円 |

プライベートリポジトリの `ubuntu-latest` は 2 CPU・メモリ 8 GB・SSD 14 GB です。Skipbox の実行時間は無制限。4 vCPU を月 20,000分使うと、GitHub は 約 35,120 円、Skipbox S は 6,000 円で、毎月 約 29,120 円安くなります。

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

```yaml
jobs:
  test:
    runs-on: skipbox # ubuntu-latest から書き換える
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci && npm test
```

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

キャッシュのステップはそのままで構いません。2 回目の実行は、1 回目のキャッシュをマシンの上で見つけます。

## セキュリティ

- マシンはアカウントごとの専用です。ほかの会社のジョブと同じマシンで動くことはありません。
- ジョブが終わるたびに、ランナーの認証情報、プロセスとコンテナを消します。「毎回クリーン」なら、ジョブごとに新しいマシンで動きます。
- 書き込み権限のない人のコード（フォークからのプルリクエストなど）は、使い捨ての VM で動きます。キャッシュは読めますが、書き換えられません。

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

## キャッシュが当たらないジョブで試す

カード不要で、7日間かジョブの合計 3,000分まで無料です。そのジョブを `runs-on: skipbox` に替えて 2 回動かし、2 回目の復元とインストールのステップを GitHub と並べてください。

## よくある質問

### GitHub Actions のキャッシュの容量制限はいくつ？

既定ではリポジトリごとに 10 GB で、すべてのブランチとワークフローで分け合います。超えても新しいキャッシュは保存され、最後に使われた日が古いものから順に、上限を下回るまで消されます。7日を超えて読まれていないキャッシュは、容量に関係なく消えます。Pro・Team・Enterprise のアカウントなら、管理者が容量と日数の上限を引き上げられます。10 GB を超えた分は使った容量に応じて課金され、予算に達すると、次の請求期間までキャッシュは読み取り専用になります。

### GitHub Actions のキャッシュがすぐ消えるのはなぜ？

リポジトリの中のすべてが、1 つの 10 GB を分け合っているからです。ブランチごと、プルリクエストごと、マトリックスのジョブごと、OS ごとにキャッシュが保存され、Docker の type=gha のキャッシュも同じ枠に入ります。1 日の保存が上限を超えると、保存のたびに古いキャッシュが消え、次のジョブが使うはずのものまで消えます。GitHub はこれをキャッシュのスラッシングと呼んでいます。gh cache list --sort size_in_bytes で、何が枠を埋めているか大きい順に見られます。

### actions/cache の復元が、インストールし直すのと同じくらい遅いのはなぜ？

キャッシュが当たっても、中身はダウンロードだからです。GitHub ホストランナーのジョブは毎回新しい VM で始まるので、actions/cache はそのたびにアーカイブをダウンロードして展開します。キャッシュが大きいほど時間がかかります。setup-node のキャッシュが戻すのはパッケージマネージャーのダウンロードのキャッシュで、node_modules ではないので、復元のあとも npm ci はすべてのパッケージを入れ直します。ディスクが残るランナーなら、キャッシュは最初からそこにあり、何もダウンロードしません。

### 新しいブランチで actions/cache がヒットしないのはなぜ？

読めるのは、自分のブランチとデフォルトブランチのキャッシュだけだからです（プルリクエストの実行はベースブランチのものも読めます）。隣のブランチのキャッシュは読めません。だから feature ブランチの最初の実行は、同じキーをデフォルトブランチが保存していないとヒットしません。デフォルトブランチへの push でもワークフローを動かして保存させ、restore-keys で部分一致させます。cache-hit が true になるのは key に完全に一致したときだけです。

### Skipbox ではキャッシュをどれだけ持てる？

GitHub のリポジトリごと 10 GB より多く、それも GitHub のストレージではなく、マシンのすぐそばに持ちます。クラウドのマシンなら、actions/cache・setup-*・rust-cache が保存したものはマシン自身のディスクに残り、ディスクの半分まで使えます（ディスクは S 80 GB、M 160 GB、L 320 GB）。Skipbox のホストでは、ホストのキャッシュがリポジトリごとに 20 GB を持ちます。どちらも、最後に使ってから 7日残し、ブランチのルールは GitHub と同じです。パッケージのキャッシュと Docker のレイヤーはここを通らず、ディスクにそのまま残ります。

### Skipbox のマシンのキャッシュが消えるのはいつ？

マシンがリセットされたときです。ジョブのあとのヘルスチェックに通らなかったとき、「マシンをリセット」を押したとき、イメージを更新したとき（月に 1 回以上）、ジョブが 6時間の上限に達したとき。プランが終わると、マシンはディスクごと削除されます。それ以外は、ジョブのあとでディスクがほぼいっぱいになるまで何も消さず、いっぱいになったら、使われたのがいちばん古いものから消します。

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

かかりません。カード不要で、7日間かジョブの合計 3,000分まで無料です。キャッシュが当たらない、または復元が遅いジョブを runs-on: skipbox に替えて 2 回動かし、2 回目の復元とインストールのステップを GitHub と比べてください。

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