Docker Composeは、複数のDockerコンテナをYAMLファイル1枚でまとめて起動・停止できる公式ツールです。
「docker run のオプションが長すぎて毎回コピペしている」「DB付きの環境構築をチームで共有したい」。そんな悩みを一発で解決します。
私は業務でも個人開発でもDocker Composeを毎日使っていますが、Compose導入後に「環境構築で半日溶かす」がゼロになりました。
この記事では、compose.yamlの書き方から基本コマンド7つ、初心者がハマるトラブルの直し方まで、30分で手を動かせる最短ルートを解説します。
結論：Docker Composeは複数コンテナをymlで束ねるツール
結論から言うと、Docker Compose は「複数のコンテナをまとめて定義・起動・停止するためのツール」です。
yml形式の設定ファイル1枚にサービス構成を書き、docker compose コマンドで操作します。
WebアプリとDB、キャッシュサーバーをセットで動かしたい場面では、もう Compose 一択と言っていいくらい標準装備です。
nginx:1.30
ポート8080:80"] --> Service2["DBコンテナ
mysql:8.4
ポート3306"] Service2 --> Volume["名前付きボリューム
db_data
データ永続化"] end end Browser["ブラウザ"] -->|"http://localhost:8080"| Service1
1分でわかるDocker Composeの定義
Docker Compose とは、複数の Docker コンテナで構成されるアプリケーションを compose.yaml で宣言的に定義し、まとめて起動・停止・破棄できる公式ツールです。
2026年現在は Docker Desktop や Docker Engine に「Compose v2」がプラグインとして同梱されており、コマンドは docker-compose（旧）ではなく docker compose（スペース区切り）が標準になりました。
つまり、今から始める方が覚えるべきは docker compose up 系のコマンドだけです。古い記事に出てくるハイフン版は気にしなくて大丈夫です。
こんな人におすすめ（向き・不向き）
向いているのは「ローカルでWebアプリの開発環境を整えたい」「DB込みでサンプルアプリを動かしたい」「チームで開発環境を統一したい」人です。
逆に、本番運用で大規模なオーケストレーションをしたいなら Kubernetes のほうが筋がいいので、用途を分けて考えるのが現実的です。
私もローカル開発は Compose、本番は別のオーケストレータ、と完全に切り分けています。
DockerとDocker Composeの違いを比較表で整理
違いを一言で言うと、Docker は「コンテナ1つを操作するための土台」、Docker Compose は「複数コンテナをまとめて操作するための上乗せレイヤー」です。
Compose の中身は結局 Docker を呼び出しているので、別物ではなく親戚みたいな関係です。
ポート・環境変数・ボリュームを毎回指定"] CMD2["docker run db
ネットワークを手動接続"] CMD3["docker network create
別途ネットワーク作成"] end subgraph Compose["Docker Composeでの運用"] direction TB YML["compose.yaml に
全サービス定義"] UP["docker compose up -d
1コマンドで一括起動"] AUTO["ネットワーク・ボリューム
自動生成・接続"] end Docker単体 -.-> |"設定を
ymlに集約"| Compose
単体Dockerだとつらい場面
素のDockerだと、コンテナを増やすたびに docker run のオプションが膨らみます。
ネットワーク作成、ボリュームマウント、環境変数、ポート公開…全部コマンドラインに書く必要があり、あとから誰かに共有するときが地獄です。
「同じ環境を再現してね」とSlackで送るときに、長いワンライナーをペーストする時点で何かがおかしいです。
比較表：コマンド数・再現性・運用負荷
| 項目 | Docker（単体） | Docker Compose |
|---|---|---|
| 起動コマンド | コンテナごとに docker run | docker 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 もしくは Docker Engine に Compose v2 がプラグインとして同梱されているからです。
古い記事のように pip install docker-compose する必要はないので、まずは現状を確認するところから始めます。
macOS / Windows（Docker Desktop同梱）
macOSとWindowsは Docker Desktop を入れるだけで Compose も同時に使えます。
インストール後、ターミナルで以下を叩いてバージョンが返ってくればOKです。
docker compose version
# Docker Compose version v2.x.x のように表示されればOKLinux（plugin版v2のセットアップ）
Linuxの場合は Docker Engine に加えて docker-compose-plugin パッケージを入れます。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", "localhost"]
interval: 5s
timeout: 3s
retries: 10healthcheck と condition: service_healthy を組み合わせれば、DBが本当に接続を受け付けられる状態になってからアプリを起動できます。
「DBが起動したのにアプリが接続エラーになる」という初心者あるあるは、ほぼこれで解決します。
ネットワークのカスタム設定
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 build | Dockerfileから再ビルド |
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 のような数字がパースエラーになるケースがあります。
地味すぎる罠ですが、最初の数十分はだいたいこれで溶けます。
もう一つ、コメント行で # の後に半角スペースを入れずに書くと環境によってはパースエラーになることがあります。
# コメント のようにスペースを空ける癖をつけておくと安全です。
よくある質問（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 を叩いてみてください。
コンテナが立ち上がる瞬間の気持ちよさを味わえれば、もう半分以上理解したのと同じです。
あとは自分のプロジェクトに合わせてサービスを足していくだけで、開発体験が段違いに変わります。
