DockerベースのGitHub Actionsを「爆速」にする：コンテナビルドの呪縛から解放される極限の最適化戦略
こんにちは。テックリードの私たちが日々直面する最大のストレスの一つ、それは「GitHub Actionsのコンテナアクション、お前遅すぎ問題」ではないでしょうか。
JavaScript製のカスタムアクションとは異なり、Dockerベースのアクションは、独立した環境と依存関係を完全にカプセル化できる強力な武器です。しかし、その代償として支払う「毎回フルビルドされるイメージの構築コスト」と「巨大なレイヤーの転送時間」は、チーム全体のフィードバックループを確実に蝕んでいます。
「PRを出してからCIが完了するまでにコーヒーを一杯飲み干せてしまう」そんな開発体験を、今日で終わりにしましょう。
今回は、GitHub ActionsのDockerベースアクションにおけるビルドオーバーヘッドを極限まで削ぎ落とし、「秒速」で完了させるための上級テクニックを理論と実践コードベースで伝授します。
—
なぜDockerアクションは遅いのか？（根本原因の特定）
コンテナアクションが遅いのには明確な理由があります。デフォルトのGitHub Actionsランナーでは、ステップごとにコンテナが破棄されるため、キャッシュが効かない状態では以下の重い処理が毎回実行されます。
1. ベースイメージのプル（数GB規模になることも）
2. 依存関係の解決とビルド（`npm install`, `bundle install`, `cargo build` など）
3. イメージ自体の圧縮・ tar化・アップロード／ダウンロード
これを解決する鍵は、「GitHub Container Registry (GHCR) をリモートキャッシュのストレージとして完全にハックし、Docker Layer CachingをCI環境にクロスロードすること」です。
—
極限最適化：4つのベストプラクティス
1. マルチステージビルドによる「成果物のみ」の抽出
開発時のツールチェーン（コンパイラやSDK）を本番イメージに含めてはいけません。これは常識ですが、アクションのコンテナにおいても徹底すべきです。不要なレイヤーを削ることでイメージサイズを劇的に小さくし、プル・プッシュのネットワークコストを消し去ります。
2. GHCRをキャッシュバックエンドにした `–cache-from` / `–cache-to` 戦略
これが本記事の核心です。Docker Buildxの実験的機能（現在は標準機能）を使い、前回のビルドキャッシュをGHCRに保存し、次回のビルド時にそれを参照させます。これにより、コードの変更がないレイヤーのビルドは一瞬でスキップされます。
3. アクション定義（`action.yml`）とワークフローの分離設計
Dockerアクションを呼び出す側（Workflow）と、定義する側（`action.yml`）の責務を正しく分離し、無駄な再ビルドトリガーを排除します。
4. チーム開発におけるキャッシュ共有ルール
ブランチ戦略（Main, Feature）に応じたキャッシュのスコープ設定を間違えると、キャッシュがヒットせず意味がなくなります。最適なキャッシュモードを構築します。
—
実践：爆速コンテナアクション構築バイブル
それでは、理論を具体的なコードに落とし込みます。
以下の構成を持つカスタムDockerアクションと、それを限界まで最適化してビルド・実行するワークフローのベストプラクティスです。
フォルダ構成
.
├── .github/
│ └── workflows/
│ └── ci.yml # アクションのテスト＆リリース用ワークフロー
├── my-docker-action/
│ ├── Dockerfile # マルチステージビルド対応Dockerfile
│ ├── entrypoint.sh # エントリポイントスクリプト
│ └── action.yml # アクションのメタデータ
—
1. 究極の `Dockerfile` （マルチステージビルド）
==========================================
ステージ 1: ビルド環境 (重いSDKや依存関係を含む)
==========================================
FROM golang:1.22-alpine AS builder
WORKDIR /app
依存関係定義ファイルのみを先にコピーしてキャッシュ効率を最大化
COPY go.mod go.sum ./
RUN go mod download
ソースコードをコピーしてビルド
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /bin/action-binary ./main.go
==========================================
ステージ 2: ランタイム環境 (極小のセキュアなイメージ)
==========================================
FROM alpine:3.19
ランタイムに必要な最小限のパッケージをインストール（例: ca-certificatesなど）
RUN apk –no-cache add ca-certificates tzdata
WORKDIR /root/
ビルドステージからコンパイル済みのバイナリだけを抽出
COPY –from=builder /bin/action-binary /usr/local/bin/action-binary
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT [“/entrypoint.sh”]
—
2. メタデータ定義 `action.yml`
name: ‘Lightning Fast Docker Action’
description: ‘Dockerベースでありながら爆速で動作するサンプルアクション’
inputs:
message:
description: ‘表示するメッセージ’
required: true
default: ‘Hello, World!’
runs:
using: ‘docker’
image: ‘Dockerfile’ # 注: ここで直接Dockerfileを指定するとキャッシュが効きにくいため、
# 事前にビルド・プッシュしたGHCRイメージを指定するのが真のベストプラクティス
# 例: image: ‘docker://ghcr.io/owner/repo/my-action:latest’
args:
- ${{ inputs.message }}
> プロの知見: `image: ‘Dockerfile’` と記述すると、GitHub Actionsランナーが毎回ローカルで `docker build` を行い、キャッシュの制御が困難になります。本番運用では、あらかじめビルドされたイメージをGHCRから引く形（`docker://…`）にするのが、実行時間を数秒にするための絶対条件です。
—
3. 爆速ビルドを実現するCIワークフロー (`.github/workflows/ci.yml`)
イメージのビルドとGHCRへのキャッシュプッシュを行う、最も重要で洗練されたワークフローです。Docker BuildxとGitHub Actions Cache (`type=gha`) を組み合わせます。
name: Build and Push Docker Action
on:
push:
branches: [ “main” ]
paths:
- ‘my-docker-action/’
workflow_dispatch:
permissions:
contents: read
packages: write
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
# 1. Docker Buildx のセットアップ（マルチプラットフォーム・キャッシュ対応に必須）
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
# 2. GitHub Container Registry (GHCR) へのログイン
- name: Log in to the Container Registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
# 3. Buildx を使った超高速ビルド ＆ ターゲットキャッシュの適用
- name: Build and push Docker image
uses: docker/build-push-action@v5
with:
context: ./my-docker-action
push: true
tags: ghcr.io/${{ github.repository }}/my-action:latest
# 秘伝のタレ：GitHub Actions専用のキャッシュバックエンドを使用
cache-from: type=gha
cache-to: type=gha,mode=max
—
チーム開発を加速させる「プロのハック」
秘伝のタレ：`type=gha` キャッシュバックエンド
上記のワークフローで使用している `cache-from: type=gha` と `cache-to: type=gha,mode=max` は、GitHub Actionsの内部キャッシュストレージにDockerレイヤーを直接保存・取得する機能です。
外部のS3やレジストリを経由しないため、転送速度が圧倒的に速く、リポジトリのキャッシュ容量制限（デフォルト10GB）の範囲内でスマートに管理されます。`mode=max`を指定することで、中間ステージを含むすべてのレイヤーがキャッシュ対象となります。
パスフィルタリング（`paths`）による無駄撃ちの防止
ドキュメントの修正や関係のないファイルの変更で、重いDockerイメージのビルドが走るのを防ぐため、ワークフローのトリガーには必ず `paths` を設定してください。
on:
push:
paths:
- ‘my-docker-action/’
- ‘.github/workflows/ci.yml’
これにより、本当にコードが変わった時だけビルドが走り、それ以外は一瞬でスキップされます。
—
まとめ：開発体験はインフラストラクチャである
「CIが遅い」という小さなストレスの積み重ねは、エンジニアのフロー状態を破壊し、チーム全体のデプロイ頻度を低下させます。
今回紹介したマルチステージビルドとGHCR/Buildxを活用したキャッシュ戦略を導入すれば、数分かかっていたコンテナアクションのビルドを文字通り数秒に短縮することが可能です。
あなたのチームのパイプラインを極限までチューニングし、真の「アジリティ」を手に入れてください。
それでは、快適なDevOpsライフを！