結論から言うと、Dockerまわりの作業はClaude Codeと相性がいいです。Dockerfileやdocker-composeは「書ける人は一瞬、慣れてない人は半日溶ける」という落差の激しい領域で、しかもエラーメッセージが独特なので、AIに既存設定を読ませて文脈ごと相談できるのは正直かなり効きます。ただし生成された設定をそのまま本番に流すのは危険なので、人がレビューする前提で使うのがコツです。
- 要点1：既存のDockerfile/composeをまず読ませて「いま何が起きているか」を言語化させると、改善の精度が一気に上がる
- 要点2：ビルドエラーはログ全文を貼って原因→修正案→検証手順の3点セットで返させると速い
- 要点3：機密情報（鍵・トークン・認証情報）をイメージやレイヤーに焼き込まない、という一点だけは絶対に人が守る
対象読者：Claude Codeを触り始めた開発者・インフラ担当・個人開発者。今日やること：手元のリポジトリでClaude Codeに既存Dockerfileを読ませ、軽量化の余地を1つ指摘させてみる。本記事の情報はすべて2026年6月時点のものです。
「Dockerは雰囲気で使ってます」という開発者、めちゃくちゃ多いと思います。僕自身そうでした。動けばOKでコピペしたDockerfileが、いつの間にかイメージサイズ2GB超えてビルドに5分かかる、みたいな状態を放置していたんですよね。それをClaude Codeに「このDockerfile、なんでこんなに重いの?」と素直に聞いたら、レイヤーキャッシュの効かせ方からマルチステージビルドの導入まで一気に直してくれて、正直「最初からこうすればよかった」と思いました。この記事では、その流れを再現できるように、指示の出し方とコード例をセットで紹介していきます。
まずは現状把握：既存のDockerfile・composeを読ませる
いきなり「Dockerfileを書いて」と頼むより、すでにある設定を読ませて理解させるのが先です。Claude Codeはカレントディレクトリのファイルをそのまま読めるので、リポジトリのルートで起動すれば、わざわざ中身を貼り付けなくても文脈を渡せます。
最初の一手はこんな感じです。
このリポジトリの Dockerfile と docker-compose.yml を読んで、
いま何をしているのか日本語で要約してください。
そのうえで、ビルドが遅くなる原因・イメージが重くなる原因に
心当たりがあれば、優先度をつけて指摘してください。
（まだ修正はしないでください。指摘だけお願いします）「まだ修正しないで」と添えるのがポイントです。これがないと、確認する前に勝手に書き換えにいくことがあるので、最初は診断だけさせて、こちらが内容を理解してから直すフェーズに進みます。Claude Codeのファイル読み取りや基本的な動かし方は公式ドキュメントにまとまっているので、初見の人は先に目を通しておくと話が早いです。
返ってくる指摘は、だいたい「ベースイメージがフルサイズ（slimやalpineでない）」「COPY . . が依存インストールより前にあってキャッシュが効いていない」「ビルド用の依存が本番イメージに残っている」あたりが定番です。このへんは人間がレビューするときのチェックポイントでもあるので、AIの指摘を鵜呑みにせず「確かにそうだな」と自分で納得してから進めてください。
Dockerfileを作成・改善する：指示の出し方とコード例
現状把握ができたら、実際に直していきます。改善の依頼は、ゴールと制約をセットで渡すと精度が上がります。
この Node.js アプリの Dockerfile を、
マルチステージビルドに書き換えてください。
条件:
- ベースイメージは node:22-slim を使う
- ビルド成果物だけを最終イメージに含める
- 依存インストールのレイヤーキャッシュが効くように COPY の順序を整える
- 最終イメージで非rootユーザーで起動する
変更後、なぜその構成にしたかを一行ずつコメントで残してください。これで返ってくる典型的なDockerfileがこちらです。実際の現場でもこの形に落ち着くことが多いです。
# --- build stage ---
FROM node:22-slim AS builder
WORKDIR /app
# 依存定義だけ先にコピー → ここでキャッシュを効かせる
COPY package.json package-lock.json ./
RUN npm ci
# ソースは依存インストールの後にコピー
COPY . .
RUN npm run build
# --- runtime stage ---
FROM node:22-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production
# ビルド成果物と本番依存のみを持ち込む
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package.json ./
# 非rootユーザーで起動
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]ここで効いているのは2点です。1つはマルチステージビルドで、ビルド時にしか使わないツール類を最終イメージから締め出してサイズを落としています。もう1つはCOPYの順序で、変更頻度の低い package.json を先にコピーすることで、ソースをいじってもライブラリ再インストールが走らないようにしています。この設計思想はDockerの公式ベストプラクティスでも推奨されている王道です。
docker-composeも同じノリで頼めます。「開発用はホットリロード、本番用はビルド済みイメージを使う」みたいな分岐は、口頭で説明するより指示文に書いたほうが早いです。
開発用の docker-compose.override.yml を作ってください。
- アプリのソースをボリュームマウントしてホットリロードを効かせる
- DB は postgres:16 を使い、データを名前付きボリュームで永続化する
- 環境変数は .env から読み込む（compose にベタ書きしない）「環境変数は.envから読み込む（ベタ書きしない）」のように禁止事項を明示しておくと、機密をうっかりcomposeファイルに書き込む事故を減らせます。設定ファイルの扱いをチームで揃えたいなら、settings.jsonの設定ガイドもあわせて見ておくと、Claude Code側の挙動を統一できます。
ビルドエラーの調査：ログ全文を渡すのが最速
Dockerのビルドエラーは、慣れていないと「どの行が悪いのか」すら判別しづらいです。ここでClaude Codeが本領を発揮します。コツはログを要約せず全文渡すこと。エラーの本当の原因は、赤字の最終行ではなく、その数行上に出ていることが多いからです。
docker build 中に以下のエラーで失敗しました。
原因の特定 → 修正案 → 修正後の検証手順 の順で説明してください。
（ログ全文）
------
#8 12.34 npm ERR! code ERESOLVE
#8 12.34 npm ERR! ERESOLVE unable to resolve dependency tree
...（中略。実際は省略せず全部貼る）...
------このとき「修正案だけでなく検証手順も出して」と頼むのが地味に重要です。--no-cache 付きで再ビルドすべきか、特定のレイヤーだけ確認すればいいのか、といった確認の段取りまで出してもらえると、直したあとに「本当に直ったのか」を自分で確かめられます。エラー調査の進め方全般についてはデバッグ・障害調査の実践ガイドに詳しくまとめてあるので、Docker以外でも使える型として押さえておくと便利です。
よくあるパターンとして、ローカルでは通るのにCI上のビルドだけ落ちる、というのがあります。この場合はアーキテクチャ差（Apple Silicon の arm64 と CI の amd64）が原因のことが多いので、その文脈もあわせて伝えると、--platform 指定やマルチアーキビルドまで含めた回答が返ってきます。
イメージの軽量化・最適化を検討する
動くようになったら、次は軽くするフェーズです。イメージサイズはビルド時間・push/pullの速度・コールドスタートに直結するので、ここを詰める価値は大きいです。まずは現状を測ってから相談するのが正攻法です。
# 現状のサイズとレイヤー構成を確認
docker images myapp
docker history myapp:latestこの出力を渡して、こう頼みます。
docker history の出力を貼ります。
どのレイヤーが容量を食っているか分析して、
軽量化の打ち手を「効果が大きい順」に挙げてください。
ただし、可読性やビルド安定性を犠牲にする無理な圧縮は避けてください。定番の打ち手は、(1) ベースイメージを slim/alpine に変える、(2) .dockerignore で不要ファイル（node_modules、.git、テスト、ドキュメント等）をビルドコンテキストから除外する、(3) RUN を && でまとめてレイヤーを減らす、あたりです。特に .dockerignore は効果のわりに見落とされがちなので、最初に確認しておくとよいです。
# .dockerignore の例
node_modules
npm-debug.log
.git
.gitignore
Dockerfile
docker-compose*.yml
*.md
.env
tests/
coverage/ただし「alpineにすれば常に最善」というわけではありません。alpineはmusl libcを使っているため、ネイティブモジュールのビルドで詰まることがあります。なので軽量化はサイズと安定性のトレードオフとして捉えるべきで、Claude Codeにも「無理な圧縮は避けて」と伝えておくのが安全です。Dockerfileの各命令の挙動を正確に押さえたいときはDockerfileリファレンスが一次情報になります。
本番に向けた注意点：そのまま流さない
ローカルで動いたイメージを本番に持っていくときは、開発時とは別のチェックが必要になります。Claude Codeに本番向けのレビューを頼むなら、観点を列挙して渡すのが確実です。
このDockerfileを本番運用する前提でレビューしてください。観点:
- 非rootユーザーで起動しているか
- ヘルスチェック（HEALTHCHECK）が必要か
- ベースイメージのタグが latest 固定になっていないか（再現性）
- 機密情報がイメージ内に残っていないか
- 不要なポートが EXPOSE されていないか
指摘ごとに「なぜ問題か」と「具体的な修正」をセットで出してください。特に イメージタグの固定 は地味だけど重要です。node:22-slim のような可変タグは、ある日ベースが更新されてビルド結果が変わることがあるので、本番ではnode:22.x.x-slim のようにバージョンを固定するか、ダイジェスト（@sha256:...）で指定して再現性を担保するのが定石です。
デプロイのパイプライン全体（CI/CDでのビルド→push→リリース）をどう組むかは、デプロイ・リリースの実践ガイドでまとめて扱っているので、コンテナ化のあとの工程まで一気通貫で整えたい人はそちらを参照してください。
落とし穴：生成設定を鵜呑みにしない・機密を焼き込まない
ここがこの記事で一番伝えたいところです。便利だからこそ、雑に使うと事故ります。実際にやりがちな失敗を ❌→⭕ の形で並べておきます。
❌ 失敗1：生成されたDockerfileを読まずにそのままビルド・本番投入
⭕ 正解：生成物は必ず人がレビューする。特に「なぜこの命令があるのか」を1行ずつ説明させて、自分が納得できない行は残さない。AIは「動くもの」は作れますが「あなたの本番要件に合っているか」までは保証しません。
❌ 失敗2：APIキーや認証情報をDockerfileの ENV や COPY でイメージに焼き込む
⭕ 正解：機密はイメージに含めない。実行時に環境変数で注入するか、ビルド時に必要なら RUN --mount=type=secret（BuildKitのsecret mount）を使う。ENV API_KEY=... はレイヤーに永久に残り、docker history で誰でも読めてしまうので絶対にやめます。Claude Codeに「機密をイメージに書かないで」と最初に伝えておくのも有効です。
❌ 失敗3：rootユーザーのまま本番起動
⭕ 正解：USER node のように非rootで起動する。コンテナが侵害されたときの被害範囲を最小化する基本対策で、これも生成時に明示的に指示すれば守られます。
❌ 失敗4：.env ファイルをイメージにコピーしてしまう
⭕ 正解：.dockerignore に .env を必ず入れる。ビルドコンテキストから除外しておけば、うっかり COPY . . で混入する事故を防げます。
こうした権限・機密まわりの設計思想は、Claude Code自体の権限設計とも地続きです。AIにどこまで自動実行を許すかという話は権限管理の公式ドキュメントに整理されているので、Dockerに限らずチームで運用ルールを決めるときの土台になります。
そしてもう一段上の便利機能として、Claude Code公式はdevcontainer（開発コンテナ）を提供しています。Claude Code自体を隔離されたコンテナ内で動かす仕組みで、ホスト環境を汚さずに済むうえ、--dangerously-skip-permissions 的な踏み込んだ自動化も比較的安全に試せます。Docker環境を整えるついでに、開発環境そのものをコンテナ化してしまうのは筋がいい選択です。詳細は公式のdevcontainerガイドを見てください。
まとめ：Dockerは「相談しながら整える」のが一番速い
Dockerまわりは、ゼロから完璧な設定を書こうとすると時間が溶けますが、Claude Codeに既存設定を読ませて「いまどうなってるか」を起点に少しずつ整えていくと、驚くほどスムーズに進みます。やることはシンプルで、(1) 既存を読ませて診断、(2) ゴールと制約を渡して改善、(3) ビルドエラーはログ全文で相談、(4) サイズを測ってから軽量化、(5) 本番前にレビュー観点を列挙、の5ステップです。
そのうえで、生成物は必ず人がレビューする・機密はイメージに焼き込まない、という2点だけは機械任せにしない。ここを守れば、Dockerが「雰囲気で使う苦手領域」から「サッと整えられる得意分野」に変わります。Claude Codeの実践テクニック全体は12スキルの学習ガイドにまとめてあるので、Dockerの次に何を覚えるか迷ったらそちらを覗いてみてください。
今日からできる3アクション
- 手元のリポジトリでClaude Codeを起動し、既存Dockerfileを読ませて「軽量化の余地を1つ」指摘させる
.dockerignoreに.envとnode_modulesが入っているか確認する（入っていなければ追加）- 本番用イメージのベースタグが
latestや可変タグになっていないか点検し、バージョン固定にする
次回予告：開発環境そのものをClaude Codeで構築・標準化する「devcontainer・環境構築」編を予定しています。チーム全員の環境差をなくす話です。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
