# より速いCIのための依存関係cache戦略

> 実行ごとに依存関係を再ダウンロードするのは無駄な時間だ。何をcacheするか、lockfileでどうkey化するか、hit率を殺す落とし穴を学ぼう。

Source: https://latchkey.dev/ja/learn/ci-cd-concepts/dependency-caching-strategies  
Updated: 2026-06-25

最大で最も安価なCIの高速化は、実行ごとに同じ依存関係を再ダウンロードしないことだ。package storeをcacheし、lockfileでkey化すれば、ほとんどのインストールがほぼ瞬時になる。

依存関係のインストールは多くのCIのjobを占める。良いcache戦略は前の実行からpackage storeを復元し、インストーラが実際に変わったものだけを取得するようにする - 数分を数秒に変える。

## プロジェクトではなくstoreをcacheする

`node_modules`のようなプロジェクトディレクトリよりも、パッケージマネージャのグローバルstoreやdownload cache(npm cache、`~/.m2`、pip wheel cache、Cargo registry)をcacheするほうがよい。storeはポータブルで、copyされたファイルを盲信するのではなく、インストーラに速く検証済みのインストールをさせられる。

## lockfileでkey化する

cache keyは、依存関係が変わったときちょうど変わるべきだ - lockfile(`package-lock.json`、`poetry.lock`、`Cargo.lock`)のhash。同じlockfile → 同じcache → 完全hit。変わったlockfile → 新しいcacheエントリ、そしてrestore-keyのfallbackが前のstoreの大部分を回復する。

```Lockfile-keyed cache
key: deps-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
  deps-${{ runner.os }}-
```

## よくある落とし穴

- 常に変わる値でkey化する → hit率0%。
- `node_modules`を直接cacheし、lockfileのdriftを隠す。
- keyにOS/archを含めない → 互換性のないバイナリを復元する。
- 無効化より速くcacheし、古い推移的depsを提供する。

## 見返りを測る

cache hitとcold実行でインストール時間を比べる; 似ているなら、cacheはhitしていない。健全な依存関係cacheは、数分のインストールを数秒に変えるべきで、hit率はlockfileに触れないbranchで高いはずだ。

## FAQ

### What is Dependency caching strategies for faster CI?

Dependency installation dominates many CI jobs. A good caching strategy restores the package store from a previous run so the installer only fetches what actually changed - turning minutes into seconds.

### Cache the store, not the project?

Prefer caching the package manager’s global store or download cache (npm cache, ~/.m2, pip wheel cache, Cargo registry) over a project directory like node_modules. The store is portable and lets the installer do a fast, validated install rather than blindly trusting copied files.

### Key on the lockfile?

The cache key should change exactly when dependencies change - a hash of the lockfile (package-lock.json, poetry.lock, Cargo.lock). Same lockfile → same cache → full hit. Changed lockfile → new cache entry, and a restore-key fallback recovers most of the previous store.

### Measure the payoff?

Compare install time on a cache hit vs a cold run; if they are similar, the cache is not hitting. A healthy dependency cache should turn a multi-minute install into seconds, and the hit rate should be high on branches that do not touch the lockfile.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt