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

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 のキャッシュのルール

GitHub の依存関係のキャッシュのリファレンス、Actions の課金、10 GB を超えるキャッシュについての変更履歴から:

キャッシュが消える理由

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

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

gh cache list --sort size_in_bytes --limit 20

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

復元が遅い理由

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

戻ってくるものも、思っているより少ないことが多いです。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 を、それぞれのジョブそのままで動かした結果です。

• 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 のレイヤーキャッシュ）。
• **actions/cache・setup-*・rust-cache はそのまま使えます。** 保存したものは GitHub のストレージではなくマシンのそばに残り、容量は GitHub のリポジトリごと 10 GB より多く、復元は手元からの読み込みです。
• ディスクの中身に 7日の期限はありません。 ジョブのあとでディスクがほぼいっぱいになるまで何も消さず、いっぱいになったら、使われたのがいちばん古いものから消します。

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

プライベートリポジトリの ubuntu-latest は 2 CPU・メモリ 8 GB・SSD 14 GB です。Skipbox の実行時間は無制限。4 vCPU を月 20,000分使うと、GitHub は 約 35,120 円参考値：2026年11月10日の為替レート・1ドル＝158.22円。米ドルの料金を、このレートで円に換算した概算です。、Skipbox S は 6,000 円で、毎月 約 29,120 円参考値：2026年11月10日の為替レート・1ドル＝158.22円。米ドルの料金を、このレートで円に換算した概算です。安くなります。

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

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 で動きます。キャッシュは読めますが、書き換えられません。

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

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

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

2026年11月13日 更新