Skip to main content

第30章：仕上げ：自分用“速度テンプレ”を完成させる 🏁🎁

この章は「全部入りの最終成果物」を作って終わりです！😆✨ やることはシンプルで、速くなる型（テンプレ）を“固定の形”として手元に残すだけ。次からはコピペで爆速スタートできます 🐳⚡️

1) 今日作る“速度テンプレ”の中身 🧰📦​

テンプレは「開発」「ビルド」「CI」の3点セットにします ✅

  • 開発：編集→反映が速い（リビルド地獄から脱出👀🔁） → Compose Watch を使う（docker compose up --watch）(Docker Documentation)
  • ビルド：依存が速い（キャッシュをちゃんと使う） → BuildKit の cache mount（RUN --mount=type=cache）(Docker Documentation)
  • CI：毎回速い（キャッシュを“持ち運ぶ”） → buildx のキャッシュバックエンド（gha / registry / local）(Docker Documentation)

2) 速度テンプレ（フォルダ構成）📁✨​

こんな構成にしておくと、あとから増やしても崩れません 👍

your-speed-template/
  compose.yaml
  Dockerfile
  .dockerignore

  package.json
  pnpm-lock.yaml   # npmなら package-lock.json
  tsconfig.json
  src/
    index.ts

  .github/
    workflows/
      ci.yml

3) テンプレ①：速い .dockerignore 🧹💨​

「余計なものを送らない」だけで、体感が変わります 😳 ビルドコンテキストが小さいほど速いです（第5章の総仕上げ！）

## 依存と生成物
node_modules
dist
.cache
.npm
.pnpm-store

## Git とエディタ
.git
.vscode

## OS系
.DS_Store
Thumbs.db

## ログ
*.log

4) テンプレ②：速い Dockerfile（Node + TS）🏎️🧑‍💻​

ここは「キャッシュが壊れにくい順番」＋「BuildKitのcache mount」で作ります 🧠✨ BuildKitのcache mountは「レイヤが再実行されても、ダウンロード済みを使い回せる」ので、依存の速度に効きます (Docker Documentation)

Nodeは “Active LTS” が扱いやすいので、例は v24 系にしています（2026年初頭時点で Active LTS）。(Node.js)

## ===== base =====
FROM node:24-slim AS base
WORKDIR /app

## ===== dev (開発用) =====
FROM base AS dev

## 依存インストール（ここがキャッシュの命）
COPY package.json pnpm-lock.yaml ./

## pnpmはCorepack経由で固定して使うのが定番
## ※ Node v25 以降はCorepack同梱が変わるので、そこだけ注意（後述）:contentReference[oaicite:6]{index=6}
RUN corepack enable

## BuildKit cache mount：pnpmストアを使い回す
RUN --mount=type=cache,id=pnpm-store,target=/pnpm/store \
    pnpm config set store-dir /pnpm/store && \
    pnpm install --frozen-lockfile

## ソースは “Watchで同期” する想定（COPYしない）
CMD ["pnpm","dev"]

## ===== build (ビルド用) =====
FROM base AS build
COPY package.json pnpm-lock.yaml ./
RUN corepack enable

RUN --mount=type=cache,id=pnpm-store,target=/pnpm/store \
    pnpm config set store-dir /pnpm/store && \
    pnpm install --frozen-lockfile

## ここで初めてソースをコピー（キャッシュ温存）
COPY tsconfig.json ./
COPY src ./src

RUN pnpm build

## ===== prod-deps (本番依存だけ) =====
FROM base AS prod-deps
COPY package.json pnpm-lock.yaml ./
RUN corepack enable

RUN --mount=type=cache,id=pnpm-store,target=/pnpm/store \
    pnpm config set store-dir /pnpm/store && \
    pnpm install --prod --frozen-lockfile

## ===== runner (実行用) =====
FROM node:24-slim AS runner
WORKDIR /app
ENV NODE_ENV=production

COPY --from=prod-deps /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
COPY package.json ./

CMD ["node","dist/index.js"]

🧩 pnpmの固定はどうする？（超重要🔒）​

  • package.json に packageManager を入れて固定するのがよくあるやり方です（例："packageManager": "pnpm@X.Y.Z"）
  • ただし Node v25 以降はCorepack同梱が変わるので、そこだけ“テンプレに注意書き”を残しておくのが安全です (Node.js)

5) テンプレ③：速い compose.yaml（Watchで編集→即反映）👀⚡️​

Compose Watch は docker compose up --watch で起動できて、同期・再ビルドのルールを自分で決められるのが強いです (Docker Documentation)

services:
  app:
    build:
      context: .
      target: dev
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development

    # node_modulesはホスト共有しない（速さの定番）🚫📁
    volumes:
      - node_modules:/app/node_modules

    develop:
      watch:
        # ふだんの編集は同期だけ（再ビルドしない）
        - action: sync
          path: ./src
          target: /app/src
        - action: sync
          path: ./tsconfig.json
          target: /app/tsconfig.json

        # 依存が変わったら再ビルド（ここだけ重いのはOK）
        - action: rebuild
          path: ./package.json
        - action: rebuild
          path: ./pnpm-lock.yaml

volumes:
  node_modules:

起動コマンド（覚えるのはこれだけ）🧠✨​

docker compose up --watch

docker compose watch という専用コマンドもあり、ログを分けたい時に便利です (Docker Documentation)

6) テンプレ④：CIで速い .github/workflows/ci.yml 🧪🏎️​

CIは「毎回まっさら」になりやすいので、外部キャッシュがほぼ必須です (Docker Documentation) GitHub Actions なら type=gha が“おすすめ枠”として案内されています (Docker Documentation)

name: ci

on:
  push:
  pull_request:

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

      - name: Set up Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build (cache)
        uses: docker/build-push-action@v6
        with:
          context: .
          file: ./Dockerfile
          target: runner
          push: false
          tags: your-app:ci
          cache-from: type=gha,scope=your-app
          cache-to: type=gha,scope=your-app,mode=max

🧨 CIキャッシュの“現実”も知っておこう​

  • type=gha は便利だけど、キャッシュ容量や運用制限の影響を受けます（制限内ならおすすめ、という位置づけ）(Docker Documentation)
  • リポジトリのキャッシュ上限は「無料枠10GB」が基本で、増やせるようになった（課金で拡張）という変更もあります (The GitHub Blog)
  • キャッシュが溢れる/不安定なら、registry backend（GHCRなど）に逃がすのが定番の逃げ道です (Docker Documentation)

7) “速度テンプレ” 最終チェックリスト ✅📄✨​

ここまでできたら、テンプレ完成です！🎉

✅ ビルドが速い​

  • COPY package.json + lock → install → COPY src の順になってる
  • RUN --mount=type=cache が依存インストールに入ってる (Docker Documentation)
  • .dockerignore が効いてる（node_modules / dist / .git が送られてない）

✅ 開発が速い​

  • node_modules をホスト共有してない（volumeに逃がしてる）
  • Watch で sync と rebuild が分かれてる (Docker Documentation)

✅ CIが速い​

  • cache-from / cache-to が入ってる
  • 伸び悩んだときの逃げ先（registry cache）も想定してある (Docker Documentation)

✅ Windowsまわりの“地雷”回避（該当する人だけ）​

  • WSLは新しめが推奨で、古いと挙動が怪しくなることがある (Docker Documentation)
  • ファイルが遅いときは「置き場所」が効く（WSL側に置くのが推奨）(Docker)

8) 🧪ミニ演習：テンプレを“自分の案件”に移植して完成させる 🎮✨​

ステップA：テンプレをコピー 🐣➡️🐳​

  1. いまのプロジェクトに Dockerfile / compose.yaml / .dockerignore / ci.yml を移植
  2. compose.yaml の watch の path だけ自分の構成に合わせる

ステップB：計測して合格ラインを決める 🧪⏱️​

  • 初回ビルド時間
  • 2回目ビルド時間（ソースだけ変更）
  • 依存変更時ビルド時間（package.json変更）
  • 編集→反映までの体感（Watch）

合格ライン（例）🎯

  • ソース変更だけなら「依存インストールが走らない」✅
  • 依存変更だけが「再ビルド対象」✅
  • node_modules 共有で重くならない✅

9) 🤖AI活用：この章の“勝ちプロンプト”集 🪄💬​

① Dockerfileレビュー（キャッシュ壊しポイント検出）🕵️‍♂️​

「この Dockerfile を見て、キャッシュが壊れやすい場所を3つ指摘して。 直すなら“最小差分”で提案して。BuildKitのcache mountも使ってOK。」

② compose watch の設計（sync / rebuild の切り分け）👀​

「このプロジェクト構成で、Watchのルールを作って。 普段はsync、依存や設定が変わった時だけrebuild、の方針で。」

③ CIキャッシュの相談（gha vs registry）🧠​

「このCIログ（貼る）を見て、キャッシュが効いてない原因を推測して。 type=gha が厳しそうなら type=registry への切り替え案も出して。」

10) おまけ：テンプレを“さらに自動化”したくなったら 🍱⚙️​

複数サービス・複数ターゲットが増えてきたら、buildx bake で「ビルド定義をファイルに寄せる」のもアリです（並列ビルドもしやすい）(Docker Documentation)

まとめ 🎁✨​

これで「速くするテク」を、**いつでも再利用できる“自分専用テンプレ”**に封印できました 🧙‍♂️📦 次に新規案件を始めるときは、このテンプレをコピペして “初日から快適” を狙えます 😆🚀

必要なら、このテンプレを 「API＋フロント（Vite）＋DB（Postgres）」の3サービス版に拡張した“完成形スターター”も、第30章の続編としてそのまま書けますよ 🐳🔥