Docker Composeとは？複数コンテナをまとめて動かす基本を初心者向けに解説

先に要点

Docker Compose は、複数のコンテナをまとめて定義・起動しやすくする仕組みです。
`アプリ + DB + Redis` のように、複数サービスを一緒に立ち上げたいときにかなり便利です。
`docker run` を何回も打つより、構成をファイルに残して再現しやすくできます。
最初は `services` `ports` `volumes` `environment` あたりを読めれば十分です。

Docker は何となく分かったけど、Compose は何が違うの？ で止まる人は多いです。
実際、単体コンテナだけなら docker run でも動くので、わざわざ別の仕組みが必要に見えにくいです。

でも実務では、アプリ単体で終わることはあまりありません。
DB、Redis、メール確認用ツール、ジョブワーカーなど、複数サービスをまとめて動かしたい場面がかなり多いです。

この記事では、2026年4月14日時点で Docker Docs の Compose ドキュメントと Quickstart 系の公開情報を確認しながら、Docker Compose とは何か、何が便利なのか、初心者が最初にどこまで理解すればよいかを整理します。
Docker 自体の意味から先に押さえたいなら、Dockerとは？コンテナで何がうれしい？初心者向けに仕組み・メリット・使いどころを解説から読むと流れがつかみやすいです。

Docker Composeとは何か

Docker Compose は、複数コンテナの構成をファイルにまとめて、まとめて起動・停止しやすくする仕組みです。
初心者向けにかなりざっくり言うと、複数の docker run を、分かりやすい設定ファイルにしたもの と考えると入りやすいです。

たとえば Web アプリを動かすだけでも、

アプリ本体
MySQL や PostgreSQL
Redis

が必要になることがあります。
これを毎回手で順番に立ち上げるのは面倒ですし、チーム内で同じ条件をそろえるのも大変です。

Compose を使うと、このプロジェクトは何を何と一緒に起動するか を compose.yaml に残せます。
その結果、再現性がかなり上がります。

何がうれしいのか

1. 複数サービスをまとめて起動できる

これがいちばん分かりやすいです。
アプリと DB を別々に考えるのではなく、この開発環境一式 としてまとめて扱えます。

たとえば、

PHP アプリ
MySQL
Redis

を使う Laravel 案件なら、1つずつコンテナを起動するより Compose でまとめた方がかなり楽です。

2. 構成がファイルに残る

誰かのPCでは動いているけど、どう起動したか分からない は地味にしんどいです。
Compose なら、ポート、環境変数、ボリューム、依存関係がファイルに残るので、あとから見返しやすいです。

3. チームで共有しやすい

README に長い起動手順を書くより、docker compose up -d で近い状態まで持っていける方が入りやすいです。
新しく参加した人が、ローカル環境で詰まりにくくなるのはかなり大きいです。

4. 検証環境を作り直しやすい

Compose は、壊れたらもう一回立てる 発想と相性がいいです。
もちろん永続データはボリュームの扱いに注意が必要ですが、少なくとも開発用の複数サービス構成はかなり戻しやすいです。

docker run と何が違うのか

docker run は単体コンテナを動かすには十分便利です。
ただ、複数サービスになると、だんだん管理がつらくなります。

観点	docker run	Docker Compose
向いている場面	単体コンテナの試行	複数サービス構成の管理
設定の残しやすさ	コマンド履歴頼りになりやすい	`compose.yaml` に残せる
チーム共有	ややしづらい	かなりしやすい
起動停止	個別操作が増える	まとめて扱いやすい

要するに、1個だけ試すなら docker run でもよいですが、プロジェクト構成として残したい なら Compose の方がかなり向いています。

最小の compose.yaml で何を書くのか

最初は全部理解しなくて大丈夫です。
まずは次の項目だけ見ればかなり足ります。

services: どのサービスを立てるか
image または build: 何からコンテナを作るか
ports: どのポートを外へ開けるか
volumes: どこを永続化するか
environment: 環境変数

たとえば、かなり単純化するとこんな形です。

services:
  app:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db

  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: app
      MYSQL_ROOT_PASSWORD: secret
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

この例で見たいのは、文法の細かさより app と db を一緒に定義している ことです。
ここが Compose の本質にかなり近いです。

実務でよくある使い方

ローカル開発環境をそろえる

いちばん多い入口です。
特に Laravel、Django、Node.js のように、アプリと DB をセットで動かしたい構成ではかなり相性がいいです。

ステージングで軽く再現する

本番そのものではなくても、開発チーム内で近い構成を簡単に再現したい場面があります。
このとき Compose は扱いやすいです。

VPS で複数サービスをまとめて管理する

小規模構成では、Compose でアプリと周辺サービスをまとめて管理することもあります。
VPS まわりまでつなげて見たいなら、クラウド、VPS、レンタルサーバーの違いは？コスパ比較と実務での使い分けを解説や Linuxサーバーの初期設定で最初にやることは？見直したい項目を実務目線で整理もつながります。

実務での使用例

ローカルの Laravel 検証環境で、`app` `nginx` `mysql` `redis` を Compose でまとめる形はかなり現実的です。アプリ担当が増えても同じ構成を渡しやすく、`ローカルだけ Redis が無い` みたいなズレも減らしやすいです。

初心者が最初につまずきやすい点

depends_on があれば全部安心だと思ってしまう

depends_on は起動順の助けにはなりますが、アプリが DB 接続可能になる瞬間まで完全に保証してくれるわけではありません。
そのため、実務ではヘルスチェックや再試行も考えることがあります。

ボリュームを理解しないまま使う

DB のデータを永続化したいのに、ボリュームなしで作ると、コンテナを消したときに中身も消えやすいです。
逆に、開発用なのに古いボリュームが残っていて、状態が変に引き継がれることもあります。

何でも1ファイルに詰め込む

Compose は便利ですが、サービスが増えるほど設定も膨らみます。
最初から全部入りにせず、まずは本当に必要なサービスだけで始める方が分かりやすいです。

まずどう触ればいいか

最初は次の順で十分です。

app + db の2サービスだけで作る
docker compose up で起動する
docker compose down で止める
必要になったら volumes や environment を読む
その後に Redis やワーカーを足す

この順なら、いきなり複雑な YAML に飲まれにくいです。
Compose は 全部の機能を覚えてから使う より、必要な2〜3項目だけで実際に動かす 方が理解しやすいです。

まとめ

Docker Compose は、複数のコンテナをまとめて定義・起動しやすくする仕組みです。
特に アプリ + DB + Redis のような構成ではかなり便利で、設定をファイルに残せるので再現性も上げやすいです。

単体コンテナだけなら docker run でも十分ですが、プロジェクト構成として管理したいなら Compose の方がかなり分かりやすいです。
最初は services ports volumes environment だけ読めれば十分なので、まずは小さく触って慣れるのがよいです。

続けて読むなら、Dockerとは？コンテナで何がうれしい？初心者向けに仕組み・メリット・使いどころを解説と Dev Containersとは？ローカル開発を汚さない開発環境の作り方を初心者向けに解説もかなり相性がいいです。

参考リンク

Docker Docs: Docker Compose
Docker Docs: How Compose works
Docker Docs: Quickstart: Compose and Rails