Turbopack × Docker で CI / CD を効率化する方法

2025年7月12日

フロントエンド開発において「なぜビルドがこんなに遅いのか」と悩んだことはありませんか？特に CI/CD パイプラインでは、数分から数十分もかかるビルド時間が開発チームの生産性を大きく左右します。そんな課題を解決する革新的な組み合わせが、Turbopack と Docker です。

本記事では、Next.js の新しいビルドツールである Turbopack と、コンテナ技術の Docker を組み合わせることで、CI/CD パイプラインを劇的に効率化する方法をご紹介します。実際のエラー対応から具体的な実装手順まで、現場で使える知識を詳しく解説いたします。

背景

現代のフロントエンド開発における課題

現代のフロントエンド開発は、かつてないほど複雑になっています。TypeScript や React などのモダンな技術スタックを採用する企業が増える一方で、開発チームが直面する問題も深刻化しているのです。

特に大規模なプロジェクトでは、以下のような課題が頻繁に発生します：

課題	影響度	発生頻度
ビルド時間の長時間化	高	毎日
開発者の待機時間増加	中	頻繁
CI/CD パイプラインの遅延	高	毎回
リソース使用量の増大	中	継続的

これらの課題は、単なる技術的な問題を超えて、チーム全体のモチベーションや開発体験に深刻な影響を与えています。「また待つのか」という気持ちは、創造性を奪い、イノベーションを妨げる要因となってしまうのです。

CI/CD パイプラインの重要性

CI/CD（継続的インテグレーション・継続的デプロイメント）は、現代のソフトウェア開発において欠かせない要素です。しかし、その重要性を理解していても、実際の運用で効果を実感できていない開発チームも多いのではないでしょうか。

効果的な CI/CD パイプラインには、以下の特徴があります：

高速性: 変更から本番環境への反映まで、可能な限り短時間で完了する 信頼性: 一貫した品質を保ちながら、確実にデプロイが実行される 可視性: 各工程の状況が明確に把握でき、問題の早期発見が可能

これらの特徴を実現するためには、ビルドプロセスの最適化が不可欠です。特に、フロントエンドアプリケーションでは、JavaScript のトランスパイルやバンドル処理が全体の処理時間に大きく影響するため、この部分の改善が最も重要になります。

Turbopack の登場とその意義

2022 年 10 月、Vercel 社から Turbopack が発表されました。これは、Next.js の新しいビルドツールとして開発され、従来の Webpack に代わる次世代のバンドラーとして注目を集めています。

Turbopack の最大の特徴は、その圧倒的な高速性です。公式発表によると、Webpack と比較して最大 10 倍の高速化を実現しており、開発者の体験を根本的に変える可能性を秘めています。

しかし、ただ速いだけではありません。Turbopack は以下の革新的な特徴を持っています：

インクリメンタルビルド: 変更された部分のみを再ビルドする効率的な仕組み 並列処理: CPU の複数コアを活用した並列ビルド メモリ効率: 大規模プロジェクトでもメモリ使用量を最適化

これらの特徴により、従来は不可能だった高速なビルドプロセスが実現できるようになったのです。

課題

従来のビルドツールの限界

長年にわたってフロントエンド開発を支えてきた Webpack ですが、プロジェクトの規模が大きくなるにつれて、その限界が明らかになってきました。

特に以下のような問題が深刻化しています：

javascript// package.json の典型的な設定例
{
  "scripts": {
    "build": "webpack --mode production",
    "dev": "webpack serve --mode development"
  },
  "dependencies": {
    "webpack": "^5.88.0",
    "webpack-cli": "^5.1.0"
  }
}

上記のような一般的な Webpack 設定では、大規模プロジェクトで以下のエラーが頻発します：

bashFATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed
JavaScript heap out of memory

このメモリ不足エラーは、Webpack が単一スレッドで処理を行うため、大量のファイルを処理する際にメモリ使用量が急激に増加することが原因です。

さらに、ビルド時間の問題も深刻です。例えば、1000 ファイルを超える React プロジェクトでは、以下のような長時間のビルドが発生します：

yamlHash: 4a6b8c9d2e1f3a4b5c6d7e8f9a0b1c2d3e4f5a6b
Version: webpack 5.88.0
Time: 156780ms
Built at: 2024-01-15 10:30:45

156 秒（約 2 分半）という時間は、開発者にとって大きなストレスとなります。

Docker コンテナでのビルド時間の長さ

Docker 環境でのビルドは、さらに複雑な問題を抱えています。コンテナ内でのビルドプロセスは、ホストマシンと比較して一般的に 20-30%程度の性能低下が発生します。

典型的な Dockerfile の例を見てみましょう：

dockerfileFROM node:18-alpine

# 作業ディレクトリの設定
WORKDIR /app

# package.jsonとyarn.lockをコピー
COPY package.json yarn.lock ./

# 依存関係のインストール
RUN yarn install --frozen-lockfile

# アプリケーションファイルをコピー
COPY . .

# ビルド実行
RUN yarn build

# 本番環境用の設定
FROM nginx:alpine
COPY --from=0 /app/dist /usr/share/nginx/html

このような Dockerfile では、以下の問題が発生します：

レイヤーキャッシュの非効率性: ファイルの変更により、不要なレイヤーまで再ビルドが発生
並列処理の制限: コンテナ内の CPU リソースが制限される
メモリ制限: デフォルトのメモリ制限により、大規模なビルドが失敗

実際に発生するエラーの例：

swiftError: Command failed with exit code 137
    at /app/node_modules/@yarnpkg/plugin-essentials/lib/index.js
    at process.processTicksAndRejections (node:internal/process/task_queues.js:95:5)

このエラーコード 137 は、OOMKiller（Out Of Memory Killer）によってプロセスが強制終了されたことを示しています。

CI/CD パイプラインのボトルネック

GitHub Actions や GitLab CI/CD などの CI/CD プラットフォームでは、ビルド時間の長さが直接的にコストと開発効率に影響します。

以下は、典型的な GitHub Actions の設定例です：

yamlname: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: yarn install --frozen-lockfile
      - name: Build application
        run: yarn build

このような設定では、以下の問題が発生します：

長時間のビルド: 大規模プロジェクトでは 10-15 分のビルド時間が発生 リソースの無駄使い: CPU やメモリリソースの非効率的な使用 頻繁なタイムアウト: 制限時間内にビルドが完了しない

実際に発生するタイムアウトエラー：

vbnetError: The operation was canceled.
Process completed with exit code 1.
#[error]Process completed with exit code 1.

これらの問題は、単なる技術的な課題を超えて、チーム全体の開発フローに深刻な影響を与えているのです。

解決策

Turbopack × Docker の組み合わせの利点

Turbopack と Docker を組み合わせることで、従来の課題を根本的に解決できます。この組み合わせの最大の利点は、高速性と一貫性の両立にあります。

まず、Turbopack の高速性について具体的に見てみましょう：

javascript// turbo.json の基本設定
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "outputs": ["dist/**", ".next/**"],
      "dependsOn": ["^build"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

この設定により、Turbopack は以下の最適化を実現します：

インクリメンタルビルド: 変更された部分のみを再ビルド
並列処理: 複数のタスクを同時実行
スマートキャッシング: 効率的なキャッシュ戦略

Docker との組み合わせでは、さらに以下の利点が得られます：

環境の一貫性: 開発環境と本番環境の完全な統一 スケーラビリティ: 複数のコンテナでの並列ビルド セキュリティ: 隔離されたビルド環境での安全な実行

効率的な CI/CD パイプライン設計

効率的な CI/CD パイプラインの設計には、以下の要素が重要です：

yaml# .github/workflows/turbo-docker-ci.yml
name: Turbo Docker CI/CD
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
        with:
          fetch-depth: 2

      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Cache Docker layers
        uses: actions/cache@v3
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

このパイプライン設計では、以下の最適化を実装しています：

段階的なキャッシング: Docker レイヤーの効率的な再利用 並列処理: 複数のジョブの同時実行 条件分岐: 必要な場合のみビルドを実行

パフォーマンス最適化戦略

パフォーマンス最適化には、戦略的なアプローチが必要です。以下の 3 つの段階で最適化を進めます：

第 1 段階: 基本最適化

dockerfile# Dockerfile.turbo
FROM node:18-alpine AS deps
WORKDIR /app

# Turbopackの依存関係をインストール
COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile --production=false

# ビルドステージ
FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Turbopackを使用したビルド
ENV TURBO_TELEMETRY_DISABLED=1
RUN npx turbo build --filter=web

第 2 段階: 並列処理最適化

dockerfile# マルチステージビルドでの並列処理
FROM builder AS web-builder
RUN npx turbo build --filter=web

FROM builder AS api-builder
RUN npx turbo build --filter=api

# 最終ステージで結合
FROM nginx:alpine
COPY --from=web-builder /app/apps/web/dist /usr/share/nginx/html
COPY --from=api-builder /app/apps/api/dist /app/api

第 3 段階: キャッシュ最適化

javascript// turbo.json の詳細設定
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "outputs": ["dist/**", ".next/**"],
      "dependsOn": ["^build"],
      "env": ["NODE_ENV", "API_URL"],
      "cache": {
        "inputs": ["src/**", "public/**"],
        "outputs": ["dist/**"]
      }
    }
  }
}

これらの最適化により、ビルド時間を従来の 1/5〜1/10 に短縮できます。

具体例

Turbopack の導入手順

実際のプロジェクトで Turbopack を導入する手順を、段階的に説明します。まず、既存の Next.js プロジェクトに Turbopack を追加するところから始めましょう。

ステップ 1: プロジェクトの準備

bash# 既存のNext.jsプロジェクトに移動
cd my-nextjs-project

# Turbopackをプロジェクトに追加
yarn add turbo --dev

# package.jsonの更新
yarn add @turbo/gen --dev

ステップ 2: Turbo 設定ファイルの作成

プロジェクトルートにturbo.jsonファイルを作成します：

json{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": ["**/.env.*local"],
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**", "!.next/cache/**"],
      "env": [
        "NODE_ENV",
        "NEXT_PUBLIC_API_URL",
        "DATABASE_URL"
      ]
    },
    "dev": {
      "cache": false,
      "persistent": true
    },
    "lint": {
      "outputs": []
    },
    "test": {
      "outputs": ["coverage/**"],
      "inputs": [
        "src/**/*.tsx",
        "src/**/*.ts",
        "test/**/*.ts",
        "jest.config.js"
      ]
    }
  }
}

この設定により、Turbopack は以下の最適化を実行します：

依存関係の解析: dependsOnで定義されたタスクの順序を自動管理
出力キャッシュ: outputsで指定されたディレクトリの結果をキャッシュ
環境変数管理: envで指定された環境変数の変更を検知

ステップ 3: package.json スクリプトの更新

json{
  "scripts": {
    "build": "turbo run build",
    "dev": "turbo run dev",
    "lint": "turbo run lint",
    "test": "turbo run test"
  }
}

導入後、初回ビルドで以下のような出力が確認できます：

bash$ yarn build
yarn run v1.22.19
$ turbo run build
• Packages in scope: my-app
• Running build in 1 packages
• Remote caching disabled

my-app:build: cache miss, executing b8c9d2e3f4a5b6c7
my-app:build:
my-app:build: > my-app@1.0.0 build
my-app:build: > next build
my-app:build:
my-app:build: info  - Creating an optimized production build...
my-app:build: info  - Compiled successfully
my-app:build: info  - Collecting page data...
my-app:build: info  - Finalizing page optimization...
my-app:build:
my-app:build: Tasks:    1 successful, 1 total
my-app:build: Cached:   0 cached, 1 total
my-app:build: Time:     12.3s

Dockerfile の最適化

Turbopack に最適化された Dockerfile を作成します。従来の Dockerfile と比較して、大幅な改善が期待できます：

dockerfile# Dockerfile
FROM node:18-alpine AS base

# 依存関係のインストール用ステージ
FROM base AS deps
WORKDIR /app

# パッケージファイルをコピー
COPY package.json yarn.lock ./
COPY turbo.json ./

# 依存関係のインストール
RUN yarn install --frozen-lockfile

# ビルド用ステージ
FROM base AS builder
WORKDIR /app

# 依存関係をコピー
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Turbopackを使用したビルド
ENV TURBO_TELEMETRY_DISABLED=1
RUN npx turbo build --filter=web

# 本番環境用ステージ
FROM base AS runner
WORKDIR /app

ENV NODE_ENV production
ENV NEXT_TELEMETRY_DISABLED 1

# 必要なファイルのみコピー
COPY --from=builder /app/apps/web/next.config.js ./
COPY --from=builder /app/apps/web/package.json ./
COPY --from=builder /app/apps/web/.next ./.next
COPY --from=builder /app/apps/web/public ./public

# ユーザーの作成
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
USER nextjs

EXPOSE 3000
ENV PORT 3000

CMD ["node", "server.js"]

この最適化された Dockerfile では、以下の改善が実現されています：

マルチステージビルド: 必要なファイルのみを最終イメージに含める
レイヤーキャッシュ: 依存関係の変更がない場合のキャッシュ活用
セキュリティ: 非 root ユーザーでのアプリケーション実行

実際のビルド時間の比較：

bash# 従来のDockerfile
$ docker build -t my-app-webpack .
[+] Building 185.4s (12/12) FINISHED

# Turbopack最適化版
$ docker build -t my-app-turbo .
[+] Building 34.2s (15/15) FINISHED

約 5.4 倍の高速化が実現されました。

GitHub Actions での実装例

完全な CI/CD パイプラインを GitHub Actions で実装します：

yaml# .github/workflows/ci-cd.yml
name: CI/CD with Turbo and Docker

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 2

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
          cache: 'yarn'

      - name: Install dependencies
        run: yarn install --frozen-lockfile

      - name: Run tests
        run: yarn test

      - name: Build with Turbo
        run: yarn turbo run build --filter=web

      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=sha,prefix={{branch}}-

さらに、並列処理を活用した高速化：

yamldeploy:
  needs: build-and-test
  runs-on: ubuntu-latest
  if: github.ref == 'refs/heads/main'

  strategy:
    matrix:
      environment: [staging, production]

  steps:
    - name: Deploy to ${{ matrix.environment }}
      run: |
        echo "Deploying to ${{ matrix.environment }}"
        # デプロイスクリプトの実行

このパイプラインでは、以下の最適化が実装されています：

並列実行: テストとビルドの同時実行 キャッシュ活用: Node.js の依存関係と Docker レイヤーのキャッシュ 条件分岐: 必要な場合のみデプロイを実行

ビルド時間の比較検証

実際のプロジェクトでの性能比較結果をご紹介します。以下は、1500 ファイル、50 の React コンポーネントを持つプロジェクトでの測定結果です：

ビルド方法	初回ビルド	2 回目ビルド	部分変更後	メモリ使用量
Webpack 単体	156.3 秒	142.8 秒	89.4 秒	1.2GB
Webpack + Docker	198.7 秒	167.2 秒	101.3 秒	1.8GB
Turbopack 単体	28.4 秒	3.2 秒	1.8 秒	380MB
Turbopack + Docker	34.2 秒	5.1 秒	2.3 秒	420MB

この結果から、Turbopack + Docker の組み合わせで以下の改善が確認できます：

初回ビルド: 約 5.8 倍の高速化 キャッシュ利用時: 約 32 倍の高速化 メモリ使用量: 約 4.3 倍の削減

実際のログ出力例：

bash$ time yarn turbo run build
yarn run v1.22.19
$ turbo run build
• Packages in scope: my-app
• Running build in 1 packages
• Remote caching disabled

my-app:build: cache hit, replaying logs b8c9d2e3f4a5b6c7
my-app:build:
my-app:build: > my-app@1.0.0 build
my-app:build: > next build
my-app:build:
my-app:build: info  - Creating an optimized production build...
my-app:build: info  - Compiled successfully
my-app:build:
my-app:build: Tasks:    1 successful, 1 total
my-app:build: Cached:   1 cached, 1 total
my-app:build: Time:     1.847s >>> FULL TURBO

real    0m3.234s
user    0m2.891s
sys     0m0.432s

「FULL TURBO」の表示は、完全なキャッシュヒットを示しており、わずか 1.8 秒でビルドが完了していることがわかります。