Dockerとは？コンテナで何がうれしい？初心者向けに仕組み・メリット・使いどころを解説

あるアプリは特定の版のNode.js、別のアプリはそれとは異なる版のNode.jsを必要とする。さらにデータベースも必要になる。このようなとき、すべてをPCへ直接インストールすると、更新や切り替えが他の作業に影響します。

Dockerを使うと、アプリごとの実行環境を分けて用意できます。ただし、アプリを箱に入れれば設定もデータも自動でそろうわけではありません。まず仕組みを整理し、実際にファイルを残す実験から「作り直せるもの」と「別に保存するもの」を見ていきます。

Dockerがそろえるもの、別に管理するもの

たとえば、PHPと必要な拡張、アプリのソース、依存ライブラリを一つのイメージへ入れます。そのイメージからコンテナを作れば、PCに直接入っているPHPの版を切り替えずにアプリを起動できます。別のアプリには別のイメージを使えます。

この分離が役立つのは、「依存ライブラリが足りない」「人によって言語の版が違う」といった差です。一方、データベースの中身やパスワードまでイメージに焼き込むと、更新・配布・秘密情報の管理が難しくなります。

同じイメージを配ることと、システム全体を同じ状態にすることは別です。データや設定も含めた手順があると、チームや検証環境で再現しやすくなります。

イメージ・コンテナ・Dockerfile・Composeの関係

まずは、作る順に区別すると理解しやすくなります。

Dockerfileはイメージの作り方、Docker Composeはサービスの組合せと起動設定です。Docker Engineがコンテナを管理し、CLIがその操作を受け付けます。Docker Desktopは、これらをPCで扱いやすくまとめたアプリです。

イメージのタグは名前であって、中身を永久に固定する仕組みではありません。latestだけでなく版番号のタグも差し替わる場合があります。厳密な再現では内容を識別するダイジェストも記録し、更新時にテストします。「固定したから更新不要」にはなりません。

仮想マシンとの違いは、カーネルをどこで動かすか

仮想マシン（VM）はゲストOSのカーネルを持ちます。Linuxコンテナは、実行先のLinuxカーネルを共有してプロセスやファイルの見える範囲を分けます。このため、コンテナごとにOS全体を起動する必要がありません。

WindowsやmacOSのDocker DesktopでLinuxコンテナを動かすときは、Linuxの実行環境を間に置きます。WindowsのWSL 2構成なら、そのLinuxカーネル上で動きます。「WindowsのカーネルでLinuxアプリをそのまま動かす」という意味ではありません。VMとコンテナは併用できます。

起動時間や必要メモリは、アプリ、イメージの取得、ストレージなどに左右されます。コンテナなら何秒、何MBと一律には決められません。また、カーネルや共有先の設定に依存するため、コンテナに入れただけで安全な隔離が完成するわけでもありません。

実験：停止すると何が残り、作り直すと何が消えるか

2026年9月21日、Docker DesktopのLinuxコンテナで確認しました。Engineは29.7.2、使用したalpine:3.21の中身はAlpine Linux 3.21.7です。ネットワークなし・ポート公開なしの小さな検証であり、本番アプリの復旧や性能を測ったものではありません。

1. 検証用のコンテナと保存領域を用意する

Dockerが起動済みで、Linuxコンテナを使える環境が前提です。以下はPowerShellでもBashでも実行できる一行のコマンドです。初回はイメージ取得の通信が発生します。

docker pull alpine:3.21
docker ps -a --filter name=notes-docker-demo
docker volume ls --filter name=notes-docker-data

同名のコンテナやボリュームが既にあれば、既存のものを消さず、この例の名前をすべて別名に変えてください。以降は新しく作る検証用データだけを対象にします。

docker volume create notes-docker-data
docker run -d --name notes-docker-demo --network none --memory 64m --cpus 0.25 --mount type=volume,src=notes-docker-data,dst=/data alpine:3.21 sleep 3600
docker exec notes-docker-demo sh -c "echo local > /tmp/local.txt; echo persistent > /data/note.txt"

/tmp/local.txtはコンテナの書込み領域、/data/note.txtは名前付きボリュームへ保存されます。64mはこの小さな実験の上限で、実アプリの推奨値ではありません。sleep 3600は確認中にコンテナを動かしておくためのものです。

2. 停止してから、同じコンテナを起動する

docker stop notes-docker-demo
docker inspect --format "{{.State.Status}}" notes-docker-demo

確認結果はexitedでした。停止したコンテナは残っており、再び起動できます。

docker start notes-docker-demo
docker exec notes-docker-demo cat /tmp/local.txt /data/note.txt

local
persistent

両方のファイルが読めました。停止だけではコンテナの書込み領域は消えません。ただし、最初から--rmを指定すると、終了時にコンテナを自動削除する動作になるため区別が必要です。

3. 削除し、同じイメージから新しく作る

次のdocker rmは、この実験で作ったコンテナと、その中の/tmp/local.txtを削除します。必要なファイルがあれば先に退避してください。

docker stop notes-docker-demo
docker rm notes-docker-demo
docker run --rm --network none --memory 64m --mount type=volume,src=notes-docker-data,dst=/data alpine:3.21 sh -c "if test -f /tmp/local.txt; then cat /tmp/local.txt; else echo local=missing; fi; cat /data/note.txt"

local=missing
persistent

新しいコンテナには/tmp/local.txtがなく、同じ名前付きボリュームに接続した/data/note.txtは読めました。これが「アプリの実行環境は作り直し、残すデータは別に管理する」という分け方です。

後片付けはdocker volume rm notes-docker-dataです。これは検証用のnote.txtも削除し、この手順では戻せません。結果を確認し、不要になってから実行します。

ボリュームは、コンテナを削除しても残すための仕組みです。ディスク障害や誤削除から守るバックアップではありません。DBのデータを残せても、復旧できるかは別に確認します。バックアップで残すものと復旧確認で、DBとファイルの組を戻す例を説明しています。

どんな作業ならDockerを使う価値があるか

価値が出やすいのは、環境を繰り返し用意する作業です。たとえばアプリ、DB、キャッシュが必要な開発では、それぞれの版と接続を定義して共有できます。CI/CDでも、同じイメージを使ってテスト環境の差を減らせます。

ただし、Composeの起動成功はアプリの準備完了と同じではありません。DBが接続を受け付けるまでの待機、マイグレーション、初期データ、秘密情報の渡し方までそろって初めて、他の人が再現しやすい構成になります。

単発の作業でも、ホストへツールを入れたくないなら使い捨てコンテナは役立ちます。「単発だから不要」とは決めず、そろえたい依存と後片付けの手間を比べます。エディタも含めて共有したい場合はDev Containersが次の選択肢です。

PCが重いときは、コンテナ数だけで判断しない

DB、コンパイラ、待機するだけのサービスでは必要な資源が違います。「8GBなら何個まで」という一律の上限では判断できません。まず、重くなる操作と同じタイミングで観察します。

docker stats --no-stream
docker system df

docker statsでは各コンテナのCPU・メモリなどを確認します。MEM USAGE / LIMITのLIMITは、そのコンテナに専用メモリが予約済みという意味ではありません。コンテナに上限を設定していなければ、実行環境の利用可能なメモリが見える場合があります。また一回の表示では、ビルド中だけのピークやメモリ不足の原因までは断定できません。

Windows上でLinux環境を使うWSL（Windows Subsystem for Linux）2では、Microsoftの資料に.wslconfigのmemoryの既定値はWindowsの総メモリの50%と記載されています（2026年9月21日確認）。これはWSL 2 VMの上限設定で、Dockerが起動時にその量を必ず消費するという意味ではありません。他のWSL作業も含めて調整します。

設定変更でwsl --shutdownを使うと、動いているWSLディストリビューション全体が停止します。作業を保存し、既存設定を控えてから変更します。原因を確認せず上限だけ下げる対処や、一括削除のpruneを最初の手段にする対処は避けます。特にdocker compose down -vは、Composeが管理する名前付きボリュームなどの削除を伴い、DBを初期化する可能性があります。

Dockerに関するよくある質問

Docker Desktopは無料で使えますか？

2026年9月21日時点の公式説明では、個人利用、教育、非商用のオープンソース、小規模事業者（従業員250人未満かつ年間売上1,000万米ドル未満）は無料利用の対象です。無料枠を超える商用利用や政府機関などは有料契約の対象です。Docker EngineとDesktopの利用条件を混同せず、所属先で使う場合は公式のDesktop利用条件を確認してください。

Dockerfileを直せば、動いているコンテナにも反映されますか？

自動では反映されません。イメージを再ビルドし、そのイメージからコンテナを再作成する流れが必要です。バインドマウントしたソースが直接見える開発構成もあるため、何をイメージへ入れ、何を外から接続しているかを確認します。

コンテナ化すれば本番へそのまま出せますか？

イメージを配布する土台にはなりますが、秘密情報、通信の公開範囲、データの保存・復元、ログ、監視、更新と切り戻しは別に設計します。不要な権限やホストの広いディレクトリを渡さず、実行先の要件に合う構成で確認します。

まとめ

Dockerの利点は、アプリの依存をそろえ、実行環境を分けて再作成できることです。今回の実験では、停止・再起動でファイルは残り、コンテナの削除・再作成では書込み領域だけが失われ、名前付きボリュームのデータは残りました。

導入時は「何をイメージに含めるか」「どのデータを外に残すか」「どう起動して正常と判断するか」を決めます。単体の動きをつかんだら、Docker Composeの基本で複数サービスへ進むか、Dev Containersの入門で開発環境をそろえる流れへ進めます。

参考情報

• Docker overview：イメージとコンテナの役割
• What is a container?：仮想マシンとの違い
• Docker Storage：書込み領域と保存先
• Docker Volumes：コンテナと独立した保存領域
• Docker run：実行オプションと終了時の削除
• Docker Resource constraints：メモリなどの上限
• Microsoft：WSLの詳細設定
• Docker Desktopの利用条件