ボリュームとは？Dockerでデータが消える・消えないの違いを初心者向けに整理

先に要点

ボリュームは、Docker でコンテナ外にデータを保持して、消えにくくするための仕組みです。
コンテナ本体にだけ書いたデータは、作り直しや削除で消えやすいです。
MySQL や PostgreSQL のデータは、ボリュームへ逃がすのがかなり基本です。
ホストの特定フォルダを直接見せたいなら bind mount、Docker 管理で永続化したいなら named volume が向きやすいです。

Docker を触り始めた人がかなりの確率でハマるのが、あれ、コンテナ作り直したらデータ消えた です。
アプリ本体はまた作ればよくても、DB やアップロードファイルまで消えると一気に怖くなります。

この記事では、2026年4月14日時点で Docker Docs の Storage Volumes Bind mounts を確認しながら、ボリュームとは何か、Docker でデータが消える・消えないの違いはどこで分かれるのかを初心者向けに整理します。
Docker 全体の基本から見たいなら、Dockerとは？コンテナで何がうれしい？初心者向けに仕組み・メリット・使いどころを解説から読むと流れがつかみやすいです。

なぜ Docker でデータが消えるのか

まず前提として、コンテナ本体の書き込み領域は、長く残す前提の保存場所 ではありません。
止めただけで即消えるとは限りませんが、コンテナを削除したり作り直したりすると、その中に直接置いたデータは消えやすいです。

Docker Docs でも、コンテナデータの永続化は volumes や bind mounts を使って外へ出す考え方で整理されています。
つまり、何も考えずにコンテナの中へだけ DB データを書いていると、環境の作り直し と一緒にデータも消えやすいです。

初心者向けにかなりざっくり言うと、こうです。

コンテナ本体: 作り直しやすいが、一時的
ボリューム: 残したいデータの置き場

ボリュームとは何か

ボリュームは、コンテナ外にデータを保持して、永続化しやすくするための仕組みです。
Docker Docs でも、volumes は persistent data stores for containers とされています。

たとえば、MySQL コンテナを立てるときに、DB データをボリュームへマウントしておけば、コンテナを作り直してもデータを残しやすくなります。

要するに、ボリュームは 消えて困るデータを、コンテナ本体とは別で持つ仕組み です。

一番よくある例は DB データ

これはかなり実務的です。
アプリコンテナは更新や作り直しがあっても、DB データまで巻き込んで消えるのは困ります。

たとえば Compose なら、こういう形です。

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

volumes:
  db-data:

この db-data が named volume です。
こうしておくと、DB コンテナを消して作り直しても、同じボリュームを使う限りデータを保持しやすくなります。

逆に、ボリューム無しで DB を立てると、開発中に down したらデータが消えた でかなりハマりやすいです。

named volume と bind mount は何が違うのか

ここもかなり混ざりやすいです。

観点	named volume	bind mount
管理者	Docker	ホストOSのパス
向く用途	DBデータ、Docker管理の永続化	ソースコード共有、ホストの既存ファイル参照
ホストからの見やすさ	直接触る前提ではない	かなり見やすい
環境依存	比較的少ない	ホストのパス構成に依存しやすい

Docker Docs でも、volumes は Docker が管理し、bind mounts はホストの特定パスを直接つなぐ仕組みとして整理されています。

初心者向けには、

DB や永続データなら named volume
ローカルのソースコードをコンテナへ見せたいなら bind mount

くらいで最初は十分です。

じゃあ何が消えて、何が消えないのか

ここをざっくり整理すると、かなり分かりやすいです。

消えやすいもの

コンテナ本体の writable layer にだけ書いたデータ
コンテナ削除前提で置いた一時ファイル
tmpfs のようなメモリ上の一時データ

残しやすいもの

ボリュームに置いた DB データ
bind mount でホスト側へ保存したファイル
外部ストレージへ逃がしたデータ

大事なのは、Docker を使っているか ではなく、どこへ書いているか です。

bind mount が向いている場面

bind mount は、ホストのフォルダをそのままコンテナへ見せる仕組みです。
Docker Docs でも、ホストとコンテナの両方からファイルへアクセスしたい場面に向いていると説明されています。

たとえば、

ローカルのソースコードをコンテナから読みたい
エディタで編集した内容をすぐ反映したい

といった開発用途ではかなり便利です。

ただし、ホストのパス構成や権限にも影響されやすいので、永続化の基本を全部 bind mount で済ませるより、用途で分けた方が分かりやすいことが多いです。

実務でどう考えると失敗しにくいか

1. 消えて困るものを先に分ける

まず、何が消えたら困るかを決めます。
DB データ、アップロードファイル、ユーザー生成データはかなり優先度が高いです。

2. アプリ本体とデータを分ける

アプリ本体は作り直してよい、データは残す、という切り分けがかなり大事です。
この考え方があると、デプロイやトラブル時も整理しやすくなります。

3. ボリュームがあるだけで安心しない

ボリュームは永続化に役立ちますが、バックアップの代わりではありません。
実務では、ボリュームがあってもバックアップと復旧確認は別で必要です。
ここはバックアップは何世代必要？実務で多い考え方・復旧確認・具体的な戻し方を解説もかなりつながります。

実務での使用例

ローカルの Laravel 検証環境なら、アプリ本体は bind mount で手元のコードを見せつつ、MySQL データは named volume に分ける形がかなり現実的です。コードはすぐ反映したい、でもDBは消したくない、という両方の都合を分けて扱えます。

初心者がよくハマるポイント

`docker compose down` のあとに消えるものを理解していない

Compose の操作で何が消えるかを曖昧にしたまま触ると、後でかなり痛いです。
コンテナを消すのか、ボリュームまで消すのかは分けて理解した方が安全です。

ボリュームと bind mount を同じものだと思っている

似て見えますが、役割は違います。
どちらもマウント ではありますが、誰が管理し、何に向くかが違います。

ボリュームがあるからバックアップ不要だと思ってしまう

ここは危ないです。
ボリュームは消えにくくする仕組みであって、障害・誤削除・破損に備えるバックアップとは別です。

まとめ

ボリュームは、Docker でコンテナ外にデータを保持して、消えにくくするための仕組みです。
Docker でデータが消える・消えないの違いは、コンテナ本体に置いたか ボリュームや bind mount に逃がしたか でかなり決まります。

最初は、

DB データはボリューム
ローカルのコード共有は bind mount

くらいで分けるだけでもかなり理解しやすいです。
続けて読むなら、Docker Composeとは？複数コンテナをまとめて動かす基本を初心者向けに解説や Dockerイメージとは？コンテナとの違いを初心者向けにわかりやすく解説もつながりやすいです。

参考リンク

Docker Docs: Storage
Docker Docs: Volumes
Docker Docs: Bind mounts