GitHub ActionsでのCI実行時間を短縮することは、開発者の待ち時間削減とGitHubホストマシンの料金節約の両方に直結します。actions/cache を設定し、依存関係パッケージのインストール時間を劇的に短縮する記述方法を紹介します。

本記事では、主要な言語環境（Node.js、Python、Rust）におけるキャッシュ設定の具体的なYAMLサンプルと、キャッシュミスを防ぐためのベストプラクティスを解説します。

1. なぜCI/CDでキャッシュが必要なのか？

ビルドやテストを実行するたびに、インターネットから何百個ものパッケージをゼロからダウンロードしていると、以下のような問題が発生します。

1. 待ち時間の増大: パッケージのダウンロードとインストール作業だけで数分間が浪費される。
2. ネットワークの不安定性: 外部レジストリ（npmやPyPIなど）が一時的にダウンしていると、無関係な原因でCIが失敗する。
3. コストの増加: プライベートリポジトリの場合、GitHub Actionsの実行時間（分単位）に応じて課金されるため、ビルド時間はコストそのものに直結します。

キャッシュ機能を使用すると、前回の実行時にダウンロードしたファイルを再利用し、ダウンロード・パース時間をほぼゼロに短縮できます。

2. 言語別・キャッシュ統合のYAMLレシピ

2026年現在、主要なセットアップアクション（setup-node や setup-python など）には、標準でキャッシュ機能が組み込まれています。これを利用するのが最も簡単かつセキュアです。

1) Node.js (npm / pnpm / yarn) のキャッシュ設定

actions/setup-node の cache オプションを有効にします。

name: Node.js CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm' # npm, yarn, pnpm から選択可能

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

2) Python (pip / poetry) のキャッシュ設定

actions/setup-python でも同様に、cache キーを利用できます。

name: Python CI

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
          cache: 'pip' # 'poetry' や 'pipenv' にも対応
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run Lint
        run: flake8 .

3) Rust (Cargo) のキャッシュ設定

Rustのコンパイルは特に時間がかかることで知られています。Cargoの依存パッケージとビルドキャッシュ（ターゲットディレクトリ）を保持するには、専用のアクションである swatinem/rust-cache を使うのが業界標準です。

name: Rust CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-rust@v1 # または rustup を使用
      - name: Rust Cache
        uses: swatinem/rust-cache@v2
      - name: Build and Test
        run: cargo test

3. キャッシュキー設計のポイントとトラブル対応

標準的なセットアップアクションを使わず、独自ディレクトリをキャッシュする場合は actions/cache を直接使用します。

キャッシュの定義例

- name: Cache custom directory
  uses: actions/cache@v4
  with:
    path: ~/.my-cache
    key: ${{ runner.os }}-custom-${{ hashFiles('**/lockfile.json') }}
    restore-keys: |
      ${{ runner.os }}-custom-

• key: キャッシュを一意に識別するキー。hashFiles を使用して、ロックファイル（package-lock.json や Cargo.lock など）のハッシュ値を含めることで、依存関係が変更されたときだけキャッシュがクリアされ再構築されるようにします。
• restore-keys: 完全一致するキーがない場合に、前方一致する古いキャッシュを段階的にフォールバックとして検索・再利用するためのリストです。

キャッシュが効かない（キャッシュミス）の対策

1. ロックファイルをGitコミットしておく: ロックファイルが存在しないと、ハッシュ値が安定せず、毎回キャッシュミスが発生します。
2. キャッシュサイズ上限: GitHub Actionsのキャッシュ容量上限はリポジトリごとに累積で 10GB です。これを超えると、古いキャッシュから自動的に削除されます。不要なビルドアセットをキャッシュパスに含めないようにします。

4. まとめ：最優先で導入すべき最適化

ワークフローに数行の cache 指定を追加するだけで、ほとんどのプロジェクトでCI時間は 30%〜60% 短縮 されます。まだ導入していない環境があれば、今すぐリポジトリのCI設定ファイルを見直しましょう。