Docker マウント方式比較：Volume vs Bind Mount 選択ガイド（パフォーマンステスト付き）

Docker を初めて使ったとき、いちばん戸惑うのがデータのマウントです。テスト環境のコンテナが突然再起動し、ページを更新したら真っ白。データベースを開くと、データがすべて消えていました。コンテナを再起動するとデータが消える——これは冗談ではありません。

こんな経験はありませんか？

• コマンドで -v を指定してディレクトリをマウントしたが、データがどこに保存されているのかわからない
• Mac で npm install を実行すると異常に遅く、コーヒーを飲んでもまだくるくる回っている
• 他の人が --mount type=volume を使っているのを見たが、-v との違いがわからない
• Volume と Bind Mount、どちらをいつ使えばいいのか判断できない

これらは、Docker の 3 つのマウント方式への理解不足が原因です。本記事では Volume、Bind Mount、tmpfs の違いと、どのシーンでどれを選ぶかを整理します。判断ツリーと実践シナリオを交え、3 分で選び方の目安がつくように解説します。

Docker データ管理の基礎

なぜコンテナを再起動するとデータが消えるのか？

まず知っておきたい事実：コンテナはデータを保存する場所ではありません。

コンテナは使い捨ての弁当箱のようなものです。食べ終われば箱ごと捨てられ、中身も消えます。コンテナを削除すれば中のデータも消えます。削除しなくても、再起動だけで消えるデータもあります。

だからこそデータの永続化が必要です。重要なデータをコンテナの外に置けば、コンテナが入れ替わってもデータは残り続けます。

-v と --mount の違いは？

Docker を使い始めた頃、この 2 つのパラメータには頭を抱えました。やっていることはほぼ同じなのに、書き方がまったく違うからです。

たとえば、データボリュームをコンテナの /data にマウントする場合：

# 方法1：-v を使う（短いが混同しやすい）
docker run -v myvolume:/data nginx

# 方法2：--mount を使う（長いが明確）
docker run --mount type=volume,source=myvolume,target=/data nginx

-v はコロン区切りで、左がソース、右がターゲットです。シンプルですが、Volume なのか Bind Mount なのか一目ではわかりません。

--mount は type=volume と明記されます。入力は面倒ですが、半年後に見返しても意味がすぐわかります。

私のおすすめ：本番環境では --mount、個人の検証では -v。

次の表で違いを確認しましょう。

[画像：コマンド比較の図解]
提示词：terminal screen showing docker run commands with -v and —mount side by side, modern tech style, blue and green colors, high quality

3 つのマウント方式を深掘り比較

本題に入りましょう。Docker には Volume、Bind Mount、tmpfs の 3 方式があります。それぞれ性格が違い、使い分けを間違えるとハマります。

Volume：Docker に任せる執事

Volume は執事を雇うイメージです。「このデータを管理して」と頼めば、Docker が専用の場所（Linux では /var/lib/docker/volumes/）に保管してくれます。細部を気にする必要はありません。

Volume の強みは クロスプラットフォームで性能が安定している ことです。Linux、Mac、Windows のどこで動かしても挙動はほぼ同じ。チーム開発で「私の環境では動くのに」というズレを避けやすくなります。

Volume は Docker コマンドで直接管理できます。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

# Volume を作成
docker volume create my-data

# すべての Volume を表示
docker volume ls

# Volume の詳細（保存場所など）
docker volume inspect my-data

# Volume をバックアップ（とても簡単）
docker run --rm -v my-data:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data

いつ Volume を使う？

• MySQL や PostgreSQL などのデータベース（データ安全が最優先）
• 複数コンテナで共有するデータ（ファイルアップロード用ディレクトリなど）
• 本番環境の永続データ（バックアップ・移行が容易）

[画像：Volume の仕組み図]
提示词：Docker volume management diagram, Docker managing storage volumes, clean infographic style, blue and white colors, high quality

Bind Mount：自分で管理する

Bind Mount はホストの任意ディレクトリをコンテナに直接マウントします。どこをマウントするかは自分で決めます。Docker は関与しません。

最大のメリットは リアルタイム同期 です。ローカルでコードを直すと、コンテナ内にもすぐ反映されます。開発環境では最高——保存してリロードするだけで、イメージの再ビルドは不要です。

ただし Mac と Windows ユーザーには落とし穴があります。

Paolo Mainardi が 2025 年に行ったテストでは、Mac 上で npm install を実行した際、Bind Mount は Volume より 3.5 倍 遅かったそうです。Mac の Docker Desktop は仮想化上で動いており、Bind Mount のファイルアクセスのたびに VM 境界を越える必要があり、そのオーバーヘッドが大きいためです。

# Bind Mount の例（カレントディレクトリをマウント）
docker run -d \
  --name my-app \
  --mount type=bind,source=$(pwd),target=/app \
  node:18

# または -v 記法（効果は同じ）
docker run -d --name my-app -v $(pwd):/app node:18

いつ Bind Mount を使う？

• ローカル開発（コード変更をリアルタイムで見たい）
• 設定ファイルのマウント（nginx.conf や .env など）
• ログをホストに出して確認したいとき

使わない方がいいケース

• Mac/Windows で node_modules や vendor などの依存ディレクトリ（性能が大きく落ちる）
• 本番環境（パス依存が強く、別マシンで動かない可能性がある）

tmpfs：メモリ上の付箋

tmpfs はデータをメモリに置きます。コンテナが止まればデータも消えます。一見不要に見えますが、用途次第では非常に有効です。

メモリの読み書きはディスクの数十倍〜数百倍速い。Redis キャッシュ、一時トークン、セッションデータなど、もともと一時的なデータなら最速の保存先を選ぶのが自然です。

# tmpfs の例（100MB のメモリ領域を作成）
docker run -d \
  --name fast-cache \
  --mount type=tmpfs,target=/cache,tmpfs-size=100M \
  redis:7

いつ tmpfs を使う？

• 一時キャッシュ（永続化不要）
• 機密情報の一時保存（電源を切れば消えるためより安全）
• 極めて高い I/O 性能が必要な場面（リアルタイムログ分析など）

注意：tmpfs は Linux コンテナでのみ使えます。Mac と Windows の Docker Desktop ではサポートされません。

3 方式の比較

この表を見れば、だいたいの判断はつくはずです。

シナリオ別選択ガイド

まだ迷っていますか？判断ツリーで 3 つの質問に答えるだけです。

クイック判断ツリー

質問1️⃣：データは永続化が必要？
  ├─ 不要（キャッシュ、一時ファイル）→ tmpfs
  └─ 必要 → 質問2️⃣へ

質問2️⃣：開発環境？本番環境？
  ├─ 本番環境 → Volume
  └─ 開発環境 → 質問3️⃣へ

質問3️⃣：ファイルをリアルタイムで直す？（ソースコードなど）
  ├─ する → Bind Mount
  │   └─ Mac/Windows？ → node_modules などは Volume
  └─ しない → Volume

抽象度が高い場合は、具体シナリオで見てみましょう。

シナリオ1：MySQL データベース

DB のデータを失ったら終わりです。迷わず Volume を選びます。

# MySQL コンテナ（推奨）
docker run -d \
  --name mysql \
  --mount type=volume,source=mysql-data,target=/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  mysql:8.0

# Volume 情報の確認
docker volume inspect mysql-data

Volume を選ぶ理由：

• ✅ データが安全。Docker が管理
• ✅ バックアップが簡単（コマンド一発）
• ✅ クロスプラットフォームで性能が安定
• ✅ サーバー移行が容易

[画像：MySQL Volume 保存の図解]
提示词：MySQL database with Docker volume storage, data persistence visualization, professional tech illustration, blue and orange colors, high quality

シナリオ2：Node.js 開発環境（Mac）

Mac で Node.js を開発し、コード変更は即反映したい。でも npm install は遅くしたくない——こういう定番ケースです。

ハイブリッド構成：コードは Bind Mount、依存関係は Volume。

# Node.js 開発コンテナ
docker run -d \
  --name my-node-app \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=bind,source=$(pwd)/package.json,target=/app/package.json \
  --mount type=volume,source=node-modules-cache,target=/app/node_modules \
  -p 3000:3000 \
  node:18 \
  npm run dev

ポイントは次のとおりです。

• src → Bind Mount。コード変更が即反映
• package.json → Bind Mount。依存追加が見える
• node_modules → Volume。Mac の性能問題を回避

初回はコンテナ内で依存をインストールします。

# コンテナ内でインストール
docker exec my-node-app npm install

これで npm install は 3 倍以上速くなることが多いです。私の環境では 2 分かかっていた処理が 40 秒になりました。

シナリオ3：Nginx 設定ファイル

Nginx の設定を変えてコンテナを再起動したら、設定が消えた——運用あるあるです。

Bind Mount で設定ファイルをマウントし、readonly を付けるとより安全です。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

# Nginx 設定をマウント（読み取り専用）
docker run -d \
  --name nginx \
  --mount type=bind,source=$(pwd)/nginx.conf,target=/etc/nginx/nginx.conf,readonly \
  -p 80:80 \
  nginx:latest

# 設定変更後にリロード（再起動不要）
docker exec nginx nginx -s reload

Bind Mount を選ぶ理由：

• ✅ 設定変更が即反映
• ✅ 設定ファイルがホスト上にあり管理しやすい
• ✅ readonly でコンテナからの誤変更を防止

シナリオ4：Redis 一時キャッシュ

Redis をキャッシュ用途で使うなら、データは消えても再生成できます。tmpfs が最適です。

# Redis に tmpfs（最高性能）
docker run -d \
  --name redis-cache \
  --mount type=tmpfs,target=/data,tmpfs-size=512M \
  -p 6379:6379 \
  redis:7 \
  redis-server --save ""

# 注意：--save "" で RDB 永続化をオフ（メモリ上なので）

tmpfs を選ぶ理由：

• ✅ メモリ読み書きが最速
• ✅ キャッシュは永続化不要
• ✅ コンテナ再起動で自動クリア（キャッシュの意味にも合う）

注意：tmpfs は Linux コンテナ専用です。Mac の Docker Desktop では使えません。

シナリオ5：ログ収集

開発中、docker logs を毎回叩くのは面倒。ログをホストに出しましょう。

# ログディレクトリをホストにマウント
docker run -d \
  --name my-app \
  --mount type=bind,source=$(pwd)/logs,target=/app/logs \
  my-app:latest

# ホストでリアルタイム確認
tail -f logs/app.log

ログファイルがローカルにあるので、VS Code で開く、grep する、ログ基盤に送る——自由にできます。

パフォーマンス最適化とよくある落とし穴

シナリオの次は、よく踏む落とし穴です。先に知っておけば時間を節約できます。

落とし穴1：Mac/Windows の性能問題

Paolo Mainardi のテストを思い出してください。Mac 上の Bind Mount は Volume より 3.5 倍遅い。40 秒で終わる npm install が 2 分かかることもあります。

なぜ遅い？

Mac と Windows の Docker は VM 内で動きます。Bind Mount への読み書きのたびに VM 境界を越える必要があり、node_modules のような小ファイルが大量にあるとオーバーヘッドが積み上がります。

対処法：

# 方法1：依存は Volume、コードは Bind Mount（推奨）
docker run -d \
  --mount type=bind,source=$(pwd)/src,target=/app/src \
  --mount type=volume,source=deps,target=/app/node_modules \
  node:18

# 方法2：Bind Mount 必須なら :cached を付ける（Docker Desktop のみ）
docker run -d -v $(pwd):/app:cached node:18

:cached は「ホスト側のファイルが正で、コンテナ側は遅延同期でよい」と Docker に伝えます。同期オーバーヘッドは減りますが、Volume ほどの効果はありません。

落とし穴2：権限問題（Permission denied）

コンテナを起動したら Permission denied——非常によくある問題です。

原因：コンテナ内ユーザーの UID とホスト側 UID が一致していない。

たとえばホストで UID 1000 のユーザーが作ったディレクトリをマウントしても、コンテナ内が UID 0（root）や UID 999 で動いていると権限が噛み合いません。

対処法：

# 方法1：コンテナを自分の UID で実行
docker run --user $(id -u):$(id -g) \
  --mount type=bind,source=$(pwd),target=/app \
  node:18

# 方法2：Dockerfile でユーザーを設定
FROM node:18
RUN useradd -m -u 1000 appuser
USER appuser
WORKDIR /app

手早く試すなら方法1。イメージとして配布するなら方法2が向いています。

落とし穴3：Windows のパス問題

Windows では C:\Users\... をそのまま書くとエラーになりがちです。

正しい書き方：

# PowerShell（推奨）
docker run -v ${PWD}:/app node:18

# CMD
docker run -v %cd%:/app node:18

# Git Bash
docker run -v /c/Users/yourname/project:/app node:18

# ダブルスラッシュも有効
docker run -v //c/Users/yourname/project:/app node:18

迷ったら docker-compose を使いましょう。パス問題を自動で処理してくれます。

落とし穴4：Volume が溜まってディスクが満杯

Volume は便利ですが、コンテナを削除しても自動では消えません。放置すると /var/lib/docker/volumes/ が肥大化します。

定期クリーンアップ：

# すべての Volume を表示
docker volume ls

# 未使用（dangling）Volume を表示
docker volume ls -f dangling=true

# 未使用 Volume を一括削除（注意！）
docker volume prune

# さらに徹底：停止コンテナ・未使用イメージ・Volume も削除
docker system prune -a --volumes

私は週 1 回 docker volume prune を実行しています。テスト用のゴミ Volume を残しても意味がありません。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

落とし穴5：Volume のデータはどこ？手動バックアップしたい

Volume の実体は次で確認できます。

# Volume の実パスを確認
docker volume inspect my-data

# 出力の "Mountpoint" を見る
# 通常：/var/lib/docker/volumes/my-data/_data

ただしこのディレクトリを直接触るのは非推奨です（権限問題など）。バックアップは Docker コマンドの方が確実です。

# Volume を tar にバックアップ
docker run --rm \
  -v my-data:/source \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/my-data-backup.tar.gz -C /source .

# バックアップから新しい Volume に復元
docker run --rm \
  -v new-data:/target \
  -v $(pwd):/backup \
  alpine \
  tar xzf /backup/my-data-backup.tar.gz -C /target

本番 DB の移行などで非常に使えます。

[画像：Volume バックアップのフロー]
提示词：Docker volume backup workflow diagram, tar archive process, clean technical illustration, green and blue colors, high quality

docker-compose ベストプラクティス

ここまでは docker run の話でした。実務では docker-compose を使うことが多いでしょう。3 方式を組み合わせた完全例を示します。

完全な docker-compose.yml 例

典型的な Web アプリ構成：Node.js フロント + API + PostgreSQL + Redis キャッシュ。

version: '3.8'

services:
  # Web アプリ（開発環境）
  web:
    image: node:18
    container_name: my-web-app
    working_dir: /app
    command: npm run dev
    ports:
      - "3000:3000"
    volumes:
      # ソースコード：Bind Mount（リアルタイム反映）
      - type: bind
        source: ./src
        target: /app/src
      # package.json：Bind Mount（依存変更が見える）
      - type: bind
        source: ./package.json
        target: /app/package.json
      # node_modules：Volume（Mac の性能問題を回避）
      - type: volume
        source: node-modules
        target: /app/node_modules
    environment:
      - NODE_ENV=development
    depends_on:
      - db
      - cache

  # データベース（本番級設定）
  db:
    image: postgres:15
    container_name: postgres-db
    ports:
      - "5432:5432"
    volumes:
      # データ：Volume（永続化・バックアップ）
      - type: volume
        source: postgres-data
        target: /var/lib/postgresql/data
      # 初期化スクリプト：Bind Mount（読み取り専用）
      - type: bind
        source: ./init.sql
        target: /docker-entrypoint-initdb.d/init.sql
        read_only: true
    environment:
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
      - POSTGRES_DB=mydb

  # Redis キャッシュ（高性能設定）
  cache:
    image: redis:7
    container_name: redis-cache
    ports:
      - "6379:6379"
    volumes:
      # 一時データ：tmpfs（最高性能・非永続）
      - type: tmpfs
        target: /data
        tmpfs:
          size: 100M  # メモリ使用量を制限
    command: redis-server --save ""  # RDB 永続化をオフ

  # Nginx リバースプロキシ
  nginx:
    image: nginx:latest
    container_name: nginx-proxy
    ports:
      - "80:80"
    volumes:
      # 設定ファイル：Bind Mount（編集しやすく読み取り専用）
      - type: bind
        source: ./nginx.conf
        target: /etc/nginx/nginx.conf
        read_only: true
      # ログ：Bind Mount（ホストで確認）
      - type: bind
        source: ./logs/nginx
        target: /var/log/nginx
    depends_on:
      - web

# トップレベル volumes 宣言（Volume を一括管理）
volumes:
  node-modules:
    driver: local
  postgres-data:
    driver: local
    # driver_opts でバックアップ戦略などを指定可能

設定のポイント（重要）

Web アプリのマウント戦略：

• src → Bind Mount。コード変更が即反映、ホットリロード向き
• node_modules → Volume。Mac ユーザー必須
• package.json → Bind Mount。依存追加後にコンテナ内で npm install

データベースのマウント戦略：

• データディレクトリ → Volume。本番級の永続化
• 初期化スクリプト → Bind Mount + read_only。初回のみ実行、誤変更防止

Redis のマウント戦略：

• tmpfs。キャッシュは永続化不要、メモリが最速
• size: 100M でメモリ食い過ぎを防止

Nginx のマウント戦略：

• 設定ファイル → read_only。コンテナからの改変防止
• ログ → Bind Mount。ホストで tail -f 可能

実用コマンド

# すべてのサービスを起動
docker-compose up -d

# Volume マウントを確認
docker-compose exec web ls -la /app/node_modules

# 初回起動時に依存をインストール
docker-compose exec web npm install

# Nginx 設定をリロード（再起動不要）
docker-compose exec nginx nginx -s reload

# DB Volume をバックアップ
docker run --rm \
  -v blog-write-agent_postgres-data:/source \
  -v $(pwd):/backup \
  alpine tar czf /backup/db-backup.tar.gz -C /source .

# 停止（Volume は残る）
docker-compose down

# 停止して Volume も削除（データ消失に注意！）
docker-compose down -v

Mac/Windows ユーザー向け最適化

上記構成はすでに Mac/Windows 向けに最適化済みですが、さらに踏み込むなら次も有効です。

# web サービスに追加
volumes:
  - ./src:/app/src:cached  # cached で同期オーバーヘッドを削減

:cached はホスト側の更新を優先し、コンテナ側は遅延同期でよいと伝えます。性能は 20〜30% 程度改善することがあります。

[画像：docker-compose アーキテクチャ図]
提示词：Docker compose multi-container architecture, web app database redis nginx, professional system diagram, blue and purple gradient, high quality

まとめ

Docker の 3 マウント方式は、用途に応じた 3 つの道具です。

• Volume：Docker に任せる執事。安心・安定・クロスプラットフォーム
• Bind Mount：自分で管理。柔軟・リアルタイム、ただし性能に注意
• tmpfs：メモリ上の付箋。最速、使い捨て

選び方は 3 つ覚えれば十分：

1. 本番データは Volume（DB、永続ファイル）
2. 開発コードは Bind Mount（リアルタイム変更、ホットリロード）
3. 一時データは tmpfs（キャッシュ、機密情報）

Mac/Windows ユーザーへの注意：

• node_modules や vendor は Bind Mount にしない。Volume なら 3 倍以上速くなる
• どうしても Bind Mount が必要なら :cached を検討

最後に：開発中のプロジェクトで docker run を docker-compose.yml に書き換え、Volume・Bind Mount・tmpfs を組み合わせて動かしてみてください。マウント方式を選び直すだけで、性能もプロジェクト構成もすっきりするはずです。

疑問があれば、コメントで気軽にどうぞ。私も同じ落とし穴を踏んできました。一緒に学びましょう。