bind mountとは？ボリュームとの違いと開発で便利な理由を解説

先に要点

bind mount は、ホストのフォルダやファイルをそのままコンテナへ見せる仕組みです。
ボリュームは Docker 管理の保存領域、bind mount はホストの既存パスを直接使う、という違いがあります。
開発で便利なのは、ローカルで編集したコードをすぐコンテナ側で反映しやすいことです。
一方で、パス差、権限、OS差の影響を受けやすいので、何でも bind mount に寄せればよいわけではありません。

Docker を触り始めると、ボリューム と bind mount が似て見えて混乱しやすいです。
どちらも「マウント」と言われるので、結局何が違うのか分からなくなりやすいです。

でも、この2つは役割がかなり違います。
特に開発では bind mount が便利で、DB データ保存ではボリュームが便利、という形で分けて考えるとかなり整理しやすいです。

この記事では、2026年4月14日時点で Docker Docs の Bind mounts と Volumes を確認しながら、bind mount とは何か、ボリュームとの違い、なぜ開発でよく使われるのかを初心者向けに整理します。
Docker でデータが消える・消えない の全体像から先に見たいなら、ボリュームとは？Dockerでデータが消える・消えないの違いを初心者向けに整理もつながりやすいです。

bind mountとは何か

bind mount は、ホスト側の特定フォルダやファイルを、そのままコンテナへ見せる仕組みです。
Docker Docs でも、ホストの filesystem からコンテナへ file or directory を mount する方法として説明されています。

初心者向けにかなりざっくり言うと、手元のフォルダをコンテナからそのまま見えるようにする機能 です。
そのため、ローカルでコードを編集しながら、コンテナの中の実行環境でアプリを動かしたいときにかなり便利です。

なぜ開発で便利なのか

いちばん大きい理由は、コードの即時反映です。

たとえば、Node.js や PHP の開発で、

ローカルのエディタでコードを編集する
コンテナ側のランタイムで実行する
保存後すぐ反映を確認する

という流れを作りやすいです。

もし bind mount が無ければ、コード変更のたびにイメージを作り直したり、コンテナ側へコピーし直したりすることになって、かなり重くなります。
開発時に bind mount が好まれるのは、この手間を大きく減らせるからです。

ボリュームとの違い

ここがいちばん大事です。

観点	bind mount	ボリューム
参照元	ホストの既存パス	Docker 管理の保存領域
向く用途	ソースコード共有、設定ファイル確認	DBデータ、永続化したいデータ
ホストからの見やすさ	高い	直接触る前提ではない
環境依存	パスや権限の影響を受けやすい	比較的整理しやすい

要するに、

開発中のコード共有なら bind mount
消えて困るデータ保存ならボリューム

で考えると、かなり外しにくいです。

どういう書き方になるのか

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

services:
  app:
    build: .
    volumes:
      - ./:/app

この ./:/app は、ホスト側の現在ディレクトリを、コンテナ内の /app に見せる bind mount です。
つまり、ローカルで編集したコードがコンテナ側からも見えます。

これがあると、アプリの実行環境はコンテナ、編集はローカル、という分担がしやすくなります。

実務でよくある使い方

Webアプリのローカル開発

かなり王道です。
PHP、Node.js、Python などのアプリ本体コードを bind mount で見せて、DB はボリュームに分ける形がかなり現実的です。

設定ファイルやテンプレートの確認

ホスト側でファイルを直接見たり編集したりしながら、コンテナ実行へ反映したいときにも便利です。

Dev Containers の一部構成

Dev Containers 周りでも、ローカルのワークスペースをコンテナへ見せる考え方はかなり近いです。
そのため、bind mount を理解すると、ローカルのファイルはどこへ行っているのか が見えやすくなります。

実務での使用例

Laravel のローカル開発なら、アプリのソースコードは bind mount で `./:/var/www/html` のように見せて、MySQL のデータは named volume に分ける形がかなり定番です。コードは即反映したいけれど、DB は消したくない、という役割分担がしやすいです。

気をつけたい点

ホストOSの影響を受けやすい

bind mount はホスト側のパスをそのまま使うので、OS差やファイル権限の影響を受けやすいです。
自分のPCでは問題なくても、別OSの人はパスや権限で詰まることがあります。

本番の永続化を全部 bind mount に寄せるとは限らない

開発では便利ですが、本番で永続データまで全部 bind mount で持つかは別の話です。
保守性や構成管理の都合で、ボリュームや外部ストレージの方が向くことも普通にあります。

ホスト側を直接壊せる

便利さの裏返しで、ホストのファイルを直接触ります。
間違った削除や書き換えをすると、そのまま影響します。

初心者が最初にどう使い分ければいいか

最初はこれで十分です。

コード共有や即時反映が欲しいなら bind mount
DB や消えて困るデータならボリューム
迷ったら コードは bind mount、データはボリューム で分ける

この整理だけでも、かなり事故を減らしやすいです。

まとめ

bind mount は、ホストのフォルダやファイルを、そのままコンテナへ見せる仕組みです。
特に開発では、ローカルで編集したコードをすぐ反映しやすいので、かなり便利です。

一方で、消えて困るデータの保管はボリュームの方が向いていることが多いです。
最初は コードは bind mount、データはボリューム で分けるとかなり分かりやすいです。

続けて読むなら、ボリュームとは？Dockerでデータが消える・消えないの違いを初心者向けに整理や Docker Composeとは？複数コンテナをまとめて動かす基本を初心者向けに解説もかなりつながりやすいです。