本ページはプロモーションが含まれています

Docker

Docker Compose入門|yml書き方と使い方

CATEGORY
REV.
DRAWN BY
TOM
SHEETS
9枚
compose .yml(Docker Composeの書き方入門)

トム

SESで約8年、環境を変えられないもどかしさの中にいました。32歳で自社開発企業に転職し、今はClaude Codeと自動化で、仕事も時間も組み直している途中です。
・Javaバックエンドエンジニア(Java歴12年以上)
・資格:基本情報技術者/応用情報技術者/Java Silver/Python3エンジニア認定基礎
詳細なプロフィール

𝕏

Docker Composeは、複数のDockerコンテナをYAMLファイル1枚でまとめて起動・停止できる公式ツールです。

「docker run のオプションが長すぎて毎回コピペしている」「DB付きの環境構築をチームで共有したい」。そんな悩みを一発で解決します。

私は業務でも個人開発でもDocker Composeを毎日使っていますが、Compose導入後に「環境構築で半日溶かす」がゼロになりました。

この記事では、compose.yamlの書き方から基本コマンド7つ、初心者がハマるトラブルの直し方まで、30分で手を動かせる最短ルートを解説します。

この記事でわかること

  • Docker Compose の正体とDockerとの違い
  • docker-compose.yml の最小構成と書き方
  • 毎日使う必須コマンド7つ
  • 初心者がハマりやすいトラブルの直し方

PARTS LIST /目次

結論:Docker Composeは複数コンテナをymlで束ねるツール

結論から言うと、Docker Compose は「複数のコンテナをまとめて定義・起動・停止するためのツール」です。

yml形式の設定ファイル1枚にサービス構成を書き、docker compose コマンドで操作します。

WebアプリとDB、キャッシュサーバーをセットで動かしたい場面では、もう Compose 一択と言っていいくらい標準装備です。

開発マシンの上で動く Compose の構成(Nginx + MySQL)
Compose仮想ネットワーク
CLIENT / 開発マシンブラウザ
WEB / nginx:1.30Webコンテナポート 8080:80
DB / mysql:8.4DBコンテナポート 3306
VOLUME / 名前付きボリュームdb_dataデータ永続化
NOTEサービス名がそのままホスト名になるので、web から db へは db:3306 で接続できます。

1分でわかるDocker Composeの定義

Docker Compose とは、複数の Docker コンテナで構成されるアプリケーションを compose.yaml で宣言的に定義し、まとめて起動・停止・破棄できる公式ツールです。

2026年現在は「Compose v2」が Docker Desktop に同梱され(Linux の Docker Engine ではプラグインとして追加します)、コマンドは docker-compose(旧)ではなく docker compose(スペース区切り)が標準になりました。

つまり、今から始める方が覚えるべきは docker compose up 系のコマンドだけです。古い記事に出てくるハイフン版は気にしなくて大丈夫です。

こんな人におすすめ(向き・不向き)

向いているのは「ローカルでWebアプリの開発環境を整えたい」「DB込みでサンプルアプリを動かしたい」「チームで開発環境を統一したい」人です。

逆に、本番運用で大規模なオーケストレーションをしたいなら Kubernetes のほうが筋がいいので、用途を分けて考えるのが現実的です。

私もローカル開発は Compose、本番は別のオーケストレータ、と完全に切り分けています。

DockerとDocker Composeの違いを比較表で整理

違いを一言で言うと、Docker は「コンテナ1つを操作するための土台」、Docker Compose は「複数コンテナをまとめて操作するための上乗せレイヤー」です。

Compose の中身は結局 Docker を呼び出しているので、別物ではなく親戚みたいな関係です。

あわせて読む
Docker単体と Docker Compose の運用の違い
DOCKER / 単体コマンドを1つずつ打つdocker network create:ネットワークを別途作成docker run db:ネットワークを手動接続docker run web:ポート・環境変数・ボリュームを毎回指定
→
COMPOSE / ymlに集約compose.yaml に全サービスを定義docker compose up -d:1コマンドで一括起動ネットワーク・ボリュームは自動で生成・接続

単体Dockerだとつらい場面

素のDockerだと、コンテナを増やすたびに docker run のオプションが膨らみます。

ネットワーク作成、ボリュームマウント、環境変数、ポート公開…全部コマンドラインに書く必要があり、あとから誰かに共有するときが地獄です。

「同じ環境を再現してね」とSlackで送るときに、長いワンライナーをペーストする時点で何かがおかしいです。

比較表:コマンド数・再現性・運用負荷

項目Docker(単体)Docker Compose
起動コマンドコンテナごとに docker rundocker compose up 1回
設定の保存シェルスクリプト等で外出しyml1ファイル
ネットワーク手動で作成・接続自動で生成・接続
環境の再現性手順書頼みymlがそのまま手順書
向いている用途単発の検証複数コンテナの開発環境

個人的には、コンテナが2つを超えた瞬間にComposeへ移行するのがベストだと感じています。

1つだけなら docker run でも問題ないのですが、2つ目のコンテナが登場した時点で、どうせymlを書くことになるからです。

Docker Composeを使う3つのメリット

メリットは大きく分けて「コマンド削減」「再現性」「ヒューマンエラー削減」の3つです。どれも地味に見えて、開発スピードに直結します。

私自身、Compose を本格導入してから「環境構築で半日溶かす」が消滅しました。

複数コンテナを1コマンドで起動できる

Web・DB・Redisを束ねた構成でも、docker compose up -d 1発で全部立ち上がります。停止も down だけ。

コマンドを覚える脳のリソースが空くので、本来やりたいアプリ実装に集中できます。

yml1ファイルで環境を再現できる

compose.yaml をGitに含めておけば、別のPCでもチームメンバーでも、cloneして1コマンドで同じ環境が立ちます。

「私の環境では動くんですけどね」みたいな伝統芸能が滅びます。OSや言語ランタイムの差にも振り回されません。

チーム開発でのミスが減る

環境変数やポート、ボリュームのマウント先がymlに集約されるので、誰が見ても構成が把握できます。

レビューもしやすく、変更履歴がGitに残るので「いつDBバージョン上げたっけ?」が git log で追えるのは精神衛生にいいです。

Docker Composeのインストール手順

2026年時点では、Docker Desktop を使う macOS / Windows では個別インストールは不要です。Linux の Docker Engine だけはプラグインを追加します。

Docker Desktop には Compose v2 が同梱されているからです。Linux の Docker Engine には同梱されないため、後述のとおりプラグインを入れます。

古い記事のように pip install docker-compose する必要はないので、まずは現状を確認するところから始めます。

macOS / Windows(Docker Desktop同梱)

macOSとWindowsは Docker Desktop を入れるだけで Compose も同時に使えます。

インストール後、ターミナルで以下を叩いてバージョンが返ってくればOKです。

docker compose version
# Docker Compose version v2.x.x のように表示されればOK

Linux(plugin版v2のセットアップ)

Linuxの場合は Docker Engine に加えて docker-compose-plugin パッケージを入れます。Docker 公式の apt リポジトリを登録済みのUbuntu系なら以下です。

sudo apt-get update
sudo apt-get install -y docker-compose-plugin
docker compose version

古い docker-compose(ハイフン版)が残っていると混乱の元になるので、見つけたらアンインストールしておきましょう。

新規で入れる方は v2 だけで大丈夫です。

compose.yaml(docker-compose.yml)の書き方を実例で解説

yml の書き方はシンプルで、services の下にコンテナを並べていくだけです。最低限 image と ports を書けば動きます。

最初から完璧なyml を書こうとせず、必要な項目を1つずつ足していくのが挫折しないコツです。

基本構造:services / volumes / networks

compose.yaml のトップレベルでよく使うキーは3つだけ覚えれば十分です。

  • services:起動するコンテナ群(必須)
  • volumes:データを永続化する領域
  • networks:コンテナ同士をつなぐ仮想ネットワーク(省略可)

networks を省略しても、Compose がプロジェクト専用のネットワークを自動で作ってくれます。

サービス名で名前解決できるので、最初は気にしなくてOKです。

最小構成サンプル(Nginx + MySQL)

WebサーバーとDBの定番セットを20行で書けます。

これをコピペして docker compose up -d すれば、http://localhost:8080 でNginxの初期画面が拝めます。

初回はイメージのダウンロードが走るので回線速度によっては数分かかります。2回目以降はキャッシュ済みなので数秒で起動します。

あわせて読む
services:
  web:
    image: nginx:1.30
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: mysql:8.4
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: app
    volumes:
      - db_data:/var/lib/mysql
volumes:
  db_data:

環境変数とボリュームの設定例

パスワードや接続文字列をyml に直書きするのは事故のもとです。

.env ファイルに切り出し、ymlからは ${VAR} 形式で参照するのが安全な書き方になります。

# .env
MYSQL_ROOT_PASSWORD=rootpass
MYSQL_DATABASE=app

# compose.yaml の一部
db:
  image: mysql:8.4
  environment:
    MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    MYSQL_DATABASE: ${MYSQL_DATABASE}

.env は必ず .gitignore に追加します。

これを忘れて公開リポジトリにpushしてしまう事故、定番すぎるので最初に防御線を張っておきましょう。

depends_onと起動順序の注意点

depends_on を使うとコンテナの起動順序を制御できますが、「起動した=準備完了」ではない点に注意が必要です。

たとえばMySQLコンテナが立ち上がっても、内部の初期化が終わるまでアプリからの接続は失敗します。

services:
  web:
    image: nginx:1.30
    depends_on:
      db:
        condition: service_healthy
  db:
    image: mysql:8.4
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1"]
      interval: 5s
      timeout: 3s
      retries: 10

healthcheck と condition: service_healthy を組み合わせれば、DBが本当に接続を受け付けられる状態になってからアプリを起動できます。なお -h localhost だと、初回起動時の初期化用の一時サーバー(ネットワークを使わず Unix ソケットだけで待ち受けるもの)にも ping が通ってしまい、早すぎるタイミングで healthy になることがあります。そのため上の例では -h 127.0.0.1(TCP接続)にしています。

「DBが起動したのにアプリが接続エラーになる」という初心者あるあるは、ほぼこれで解決します。

「起動した」と「準備完了」は違う(depends_on だけ/service_healthy)
場面
A:depends_on だけ
B:condition: service_healthy
1. up 直後docker compose up
db:コンテナ起動web:待機
db:コンテナ起動web:healthy まで待機
2. db 初期化中
web:起動db は「起動した」ので web も起動してしまう
db:ping 失敗web:healthy まで待機
3. db 初期化中
✕ 接続エラー初期化が終わる前に接続して失敗
db:ping を再試行web:healthy まで待機
4. db 初期化完了
✕ 接続エラーのまま
healthy → web 起動 → 接続OK
NOTE本文のyml(healthcheck:mysqladmin ping・5秒間隔)の動きを簡略化した図です。B は DB が接続を受け付けられる状態になってから web を起動できます。

ネットワークのカスタム設定

Composeはプロジェクトごとにデフォルトネットワーク(プロジェクト名_default)を自動作成し、全サービスがそこに接続されます。

サービス名がそのままホスト名になるので、web コンテナから db へは db:3306 で接続できます。

フロントエンドとバックエンドでネットワークを分けたい場合は、networks キーで明示的に定義します。

DBをフロント側ネットワークに入れないことで、意図しないアクセスを防ぐ簡易的なセキュリティ対策にもなります。

docker compose の基本コマンド7選

毎日使うコマンドは7つで足ります。最初はこの表をブックマークして、必要に応じて引いてくる運用で十分です。全部暗記する必要はありません。

up / down / ps / logs / exec / build / restart

コマンド役割
docker compose up -dコンテナ起動(バックグラウンド)
docker compose downコンテナ停止+削除
docker compose ps稼働中コンテナの一覧
docker compose logs -f web指定サービスのログを追跡
docker compose exec web shコンテナ内でシェルを開く
docker compose buildDockerfileから再ビルド
docker compose restartサービスを再起動

-d オプションと開発時の使い分け

-d(detached)はバックグラウンド起動で、ターミナルがすぐ返ってきます。普段使いはこちらが便利です。

一方、起動時のログをガッツリ見たいときは -d を外して docker compose up をフォアグラウンドで実行するほうがデバッグが速いです。

私は新しいymlを書いた直後だけ -d なしで動かして、安定したら -d に戻す運用にしています。

Docker Composeでよくあるトラブルと解決方法

初心者がハマりがちなトラブルは大体3パターンに集約されます。原因と対処をセットで覚えておけば、同じ落とし穴を2回踏まずに済みます。

ポート競合エラーの直し方

port is already allocated が出たら、ホスト側のポートが他のプロセスに使われています。

yml の ports をたとえば "8080:80" から "8081:80" に変えるか、占有しているプロセスを lsof -i :8080 で特定して止めれば解決します。

私はだいたい古い compose down し忘れが原因です。

ボリューム・権限エラー

permission denied が出るのはマウント先のオーナーがコンテナ内のユーザーと食い違っているケースです。

Linuxホストでは、ホスト側ディレクトリの所有者を確認し、必要なら chown で揃えます。

MySQLのボリュームを作り直したいときは docker compose down -v でボリュームごと削除してから up すれば、初期化処理が再実行されます。

yml記法のハマりどころ

yml はインデントがすべてです。タブとスペースが混ざるとエラーになるので、エディタで「タブをスペースに変換」設定を有効にしておくのが安全です。

あと、ports の値はクオートで囲って文字列扱いにしないと、22:22 のような数字が YAML で60進数の数値(1342)として解釈され、意図しないポート指定になることがあります(エラーにならずに食い違うので気づきにくい罠です)。

地味すぎる罠ですが、最初の数十分はだいたいこれで溶けます。

もう一つ、行末のコメントは # の前に半角スペースが必要です。image: nginx:1.30# メモ のように直前にスペースがないと、# 以降もコメントではなく値の一部として読まれてしまいます。

image: nginx:1.30 # メモ のように、値とコメントの間にスペースを空ける癖をつけておくと安全です。

よくある質問(FAQ)

初心者からよく受ける質問をまとめました。詰まったら、まずここを見るとだいたい解決します。

Q. docker-compose と docker compose は何が違いますか?

A. ハイフン版は v1 系の旧コマンド、スペース区切りはプラグイン化された v2 系の新コマンドです。2026年現在は v2 が標準なので、新規プロジェクトでは docker compose を使えば問題ありません。

Q. compose.yaml と docker-compose.yml はどちらを使うべき?

A. 公式が推す新しいファイル名は compose.yaml です。Compose v2 は両方読めますが、新規作成なら compose.yaml を選ぶのが今後のスタンダードに合います。

Q. 本番運用にも使えますか?

A. 小規模なら可能ですが、スケーリングや自己復旧が必要な本番環境では Kubernetes など専用のオーケストレータを推奨します。Compose は「ローカル・検証環境のための最強ツール」と割り切るのが一番幸せです。

Q. Dockerfile と compose.yaml はどう使い分ける?

A. Dockerfile は「1つのコンテナの作り方」、compose.yaml は「複数コンテナの組み合わせ方」を書きます。役割が違うので両方書くのが普通で、競合する関係ではありません。

あわせて読む

Q. ymlを変更したのに反映されません

A. docker compose up -d をもう一度実行すれば、変更があったサービスだけ再作成されます。

Dockerfileを変えた場合は --build を付ければ再ビルドされます。

まとめ:まずは up -d で動かしてみよう

Docker Compose は、複数コンテナをまとめる「設定ファイル+コマンド」のセットです。

最初に覚えるのは up -d・down・logs の3つで十分で、慣れてから残りを足していけば十分戦えます。

  • Compose は複数コンテナをymlで束ねる公式ツール
  • 2026年現在はv2が標準でdocker compose(スペース区切り)
  • 最小構成は services と image・ports だけでOK
  • 機密情報は .env へ切り出し、.gitignore 必須
  • 困ったら logs -f でコンテナのログを覗くのが最短

Composeに慣れたら次は profiles や watch 機能を試してみるのがおすすめです。

profilesで開発用・テスト用のサービスを切り替えられるようになると、ymlの使い回しが格段に楽になります。

まずは記事中の最小構成ymlをそのまま貼り付けて、docker compose up -d を叩いてみてください。

コンテナが立ち上がる瞬間の気持ちよさを味わえれば、もう半分以上理解したのと同じです。

あとは自分のプロジェクトに合わせてサービスを足していくだけで、開発体験が段違いに変わります。

REVISIONS / 改訂履歴
REV.DATE内容
52026-10-16図解を描き直し(図面のデザインにそろえた)
42026-10-06記載内容の事実確認と修正
32026-09-042026年9月時点の情報で全体を見直し
22026-05-292026年5月時点の情報で全体を見直し(古い記述を2件更新)
12026-05-03初版
NEXT READ本棚から1本

AIで開発を組み直すなら、まずこの5冊から

入門・実践・設計まで、Claude Codeの本をレベル別に5冊選んで比べました。

→ おすすめ5冊を見る

  • この記事を書いた人
  • 最新記事

トム

SESで約8年、環境を変えられないもどかしさの中にいました。32歳で自社開発企業に転職し、今はClaude Codeと自動化で、仕事も時間も組み直している途中です。
・Javaバックエンドエンジニア(Java歴12年以上)
・資格:基本情報技術者/応用情報技術者/Java Silver/Python3エンジニア認定基礎
詳細なプロフィール

𝕏

Docker