Featured image of post GitHub Actionsの実行速度を上げるキャッシュアクションの活用法 Featured image of post GitHub Actionsの実行速度を上げるキャッシュアクションの活用法
CI/CD

GitHub Actionsの実行速度を上げるキャッシュアクションの活用法

GitHub Actionsのキャッシュ機能を活用してCI/CDパイプラインを高速化する方法を解説。actions/cacheアクションや各言語のパッケージマネージャ統合キャッシュを使い、ビルド時間を数分から数十秒に短縮する実践テクニックを紹介します。

English
  1. ホーム
  2. web
  3. GitHub Actionsの実行速度を上げるキャッシュアクションの活用法

GitHub ActionsなどのCI/CDツールは、プルリクエストの作成時やメインブランチへのプッシュ時に自動的にテストやビルドを実行し、コードの安全性を担保してくれます。しかし、毎回「コンテナの起動」「外部依存パッケージ（node_modules など）のゼロからのダウンロード」「全ビルドプロセスの再実行」を繰り返していると、ジョブの実行時間は数分以上に膨れ上がります。

これにより、CIの完了待ち時間が長くなり、開発の流れが止まるほか、GitHub Actionsの利用料金（実行時間ベース）も増加してしまいます。

本記事では、GitHub公式のキャッシュアクションを活用し、CIパイプラインの実行速度を劇的に高速化させる設定方法を解説します。

1. キャッシュの仕組みと方針

GitHub Actionsにおけるキャッシュとは、**「あるワークフロー実行時にダウンロード・生成したファイルをGitHub側のストレージに保存し、次回実行時にそれをリストアして再利用する」**仕組みです。

特に時間のかかる以下の処理に対してキャッシュが効果的です。

  • npm, yarn, pnpm などの依存パッケージ（~/.npm フォルダ）
  • Next.js や Nuxt.js などのフレームワークのビルドキャッシュ（.next/cache フォルダ）
  • 各種コンパイラ（Go、Rust等）のビルド中間ファイル

2. Node.js (npm / yarn) での簡単な設定方法

最も手軽に導入できるのが、GitHub公式の actions/setup-node アクションに内蔵されているキャッシュ機能です。現在はこのワンライナー指定がベストプラクティスとなっています。

npmプロジェクトでのワークフロー設定例（.github/workflows/ci.yml）：

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          # キャッシュ対象として npm を指定
          cache: 'npm'

      # package-lock.jsonのハッシュをもとにキャッシュが判定され、
      # 変更がなければダウンロード済みのグローバルキャッシュから一瞬で復元されます。
      - name: Install dependencies
        run: npm ci

      - name: Run test
        run: npm test

cache: 'yarn' や cache: 'pnpm' を指定するだけで、それぞれのパッケージマネージャーに合わせた最適化キャッシュが自動で適用されます。

3. より細かなカスタマイズができる actions/cache アクション

「フレームワークのビルド出力フォルダ」など、特定のカスタムディレクトリをキャッシュさせたい場合は、より強力な actions/cache アクションを使用します。

以下は、Next.jsのビルド結果をキャッシュさせる設定例です。

      - name: Next.js Cache
        uses: actions/cache@v4
        with:
          # キャッシュ対象フォルダを指定
          path: |
            ${{ github.workspace }}/.next/cache
          # キャッシュを識別するためのキーを設定
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-${{ hashFiles('**/*.js', '**/*.ts', '**/*.tsx') }}
          # 完全一致するキーがない場合に、前方一致で部分適用するための代替キー
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/package-lock.json') }}-

設定プロパティのポイント：

  • path: キャッシュしたいディレクトリの絶対パスまたは相対パス。
  • key: キャッシュのバージョン管理用キー。通常はOS名と、依存定義ファイル（package-lock.json）のハッシュ値、コードファイルのハッシュ値などを組み合わせて「コードや依存関係が書き換わったらキーが新しくなる」ように設計します。
  • restore-keys: キーが完全一致しなかった際（キャッシュミス時）に、直近の古いキャッシュをとりあえず復元して差分だけビルドし直すために利用するフォールバック用のキー接頭辞。

4. キャッシュ導入時の注意点

  • キャッシュ容量の制限: GitHub Actionsでは、1つのリポジトリにつき最大 10GB までのキャッシュを無料で保存できます。これを超えると、最も古いキャッシュから自動的に削除されます。
  • セキュリティ: 別のプルリクエストやブランチ間でキャッシュが汚染されないよう、ブランチごとのスコープ制限がかけられています。例えば、ベースブランチのキャッシュはフィーチャーブランチから読み込めますが、その逆はできません。

まとめ

CIパイプラインの高速化は、開発効率を維持するための最も費用対効果の高いアプローチです。

  1. actions/setup-node などのビルトインキャッシュ（cache: 'npm'）をまず有効にする
  2. 重いビルド出力（.next/cache 等）には actions/cache を組み合わせて適用する
  3. 適切な key と restore-keys を設計し、常に最適化された部分ビルドを走らせる

ほんの数行の設定を追加するだけで、日々のビルド待ち時間を数分から数十秒へと短縮できます。ぜひ試してみてください。

© 2022 - 2026 たかおの解説