こんにちは、かつコーチです。
これでDocker編は14本目、いよいよ最終回です。
「Dockerって、結局のところ仮想マシン（VM）と何が違うの？」
これは、Dockerの学習を始めた方から本当によく聞かれる質問です。
どちらも「1台のPCの中に、隔離された実行環境を作る」という点では似ているように見えます。
しかし、その中身の仕組みは大きく異なり、得意分野もはっきり分かれています。
この記事では、アーキテクチャ・パフォーマンス・用途の3つの軸で、DockerとVMを比較検証します。
読み終える頃には、「なぜDockerは軽くて速いのか」「どんな場面でVMを選ぶべきか」がはっきり分かるようになります。
アーキテクチャの違いを比較する
仮想マシンの仕組み（ハイパーバイザー・ゲストOS）
仮想マシン（VM）は、ハイパーバイザーと呼ばれるソフトウェアの上に、独立したゲストOSをまるごと1つ動かす仕組みです。
ハイパーバイザーが物理的なCPU・メモリ・ストレージを仮想的に分割し、それぞれのVMに「1台のコンピュータ全体」を模した環境を割り当てます。
つまり、VMの中にはOSのカーネルからアプリケーションまで、フルセットが積み込まれています。
Dockerの仕組み（ホストOSのカーネルを共有）
一方Dockerのコンテナは、ホストOSのカーネルを共有しながら、プロセスやファイルシステムだけを隔離する仕組みです。
コンテナの中には、アプリケーションの実行に必要な最小限のファイルだけが入っており、OSのカーネル部分はホストのものをそのまま利用します。
一戸建てとマンションの部屋に例える
この違いは、住居に例えると分かりやすくなります。
VMは、一戸建てのようなものです。
1軒ごとに基礎・水道・電気設備をすべて独自に持っており、他の家とは物理的に完全に独立しています。
その分、土地（リソース）を多く必要とし、建てるのにも時間がかかります。
Dockerのコンテナは、マンションの1部屋に近い存在です。
建物の基礎・配管・エレベーターといったインフラ（ホストOSのカーネル）は共有しながら、それぞれの部屋（コンテナ）は独立した生活空間として区切られています。
共有インフラのおかげで、一戸建てを1軒建てるよりもずっと少ない資源で、素早く部屋を用意できるのです。
アーキテクチャの比較表
| 項目 | 仮想マシン（VM） | Docker（コンテナ） |
|---|---|---|
| 隔離の単位 | ハードウェアレベル（ハイパーバイザー） | プロセスレベル（OSカーネルの機能） |
| ゲストOS | 必要（フルセットのOSを個別に持つ） | 不要（ホストOSのカーネルを共有） |
| イメージサイズ | 数GB〜十数GBが一般的 | 数十MB〜数百MBが一般的 |
| 例え | 一戸建て（基礎から独立） | マンションの部屋（インフラは共有） |
パフォーマンス・起動速度の違いを比較する
起動時間の比較
VMは、OSの起動処理（ブートプロセス）を毎回フルで行うため、起動に数十秒〜数分かかるのが一般的です。
Dockerのコンテナは、すでに起動しているホストOSのカーネル上でプロセスを1つ立ち上げるだけなので、起動時間は数秒以内で完了します。
実際に、起動時間を体感するには以下のコマンドが便利です。
time docker run --rm alpine echo "起動確認"
筆者の環境でこのコマンドを実行すると、実行時間（real）は1秒未満で表示されました。
同じ検証をVMで行うと、OSの起動を待つだけで数十秒はかかります。
この差は、開発中に「ちょっと試したい」を繰り返す場面で、体感速度として大きく効いてきます。
リソース消費の比較
VMはゲストOSをまるごと動かすため、あらかじめ確保するメモリ・ディスク容量も大きくなりがちです。
Dockerはホストのカーネルを共有する分、コンテナ1つあたりのオーバーヘッドが小さく、同じマシン上でより多くのコンテナを同時に動かせます。
| 項目 | 仮想マシン（VM） | Docker（コンテナ） |
|---|---|---|
| 起動時間 | 数十秒〜数分 | 数秒以内 |
| メモリ消費（目安） | 数百MB〜数GB/台 | 数十MB〜数百MB/コンテナ |
| 同時起動できる数（同一スペック上） | 少ない | 多い |
用途の違いを比較する
Dockerが向いているケース
Dockerは、以下のような場面で強みを発揮します。
- アプリケーションの実行環境をコード化して、チーム全員・本番環境で統一したいとき
- マイクロサービスのように、多数の小さなサービスを軽量に並行稼働させたいとき
- CI/CDパイプラインで、毎回まっさらな環境をすばやく用意したいとき
「アプリを動かすための環境を、素早く・軽く・繰り返し再現したい」というニーズに最適です。
VMが向いているケース
一方VMは、以下のような場面で必要になります。
- Windows上でLinuxを、あるいはその逆を動かすなど、ホストと異なるOSそのものを丸ごと動かしたいとき
- 顧客ごとに完全に独立したサーバー環境として、セキュリティ境界を強く分離したいとき
- カーネルレベルの設定変更やドライバ検証など、OSの深い部分まで含めて検証したいとき
ホストOSのカーネルを共有しないという特性上、OSそのものが違う環境を動かせるのはVMならではの強みです。
併用パターンも実務では一般的
実務では「DockerかVMか」の二択ではなく、VMの中でDockerを動かす構成もよく使われます。
多くのクラウド環境（AWS EC2など）は、そもそも仮想マシンの上でサービスが提供されており、そのVMの中でDockerコンテナ群を運用するのが実質的な標準構成です。
Docker Desktop for Mac/Windowsも、内部的には軽量な仮想マシン（Linux VM）を経由してLinuxカーネルを提供する仕組みになっています。
つまり、DockerとVMは競合技術というより、役割が異なるレイヤーの技術として組み合わさっているケースが大半です。
どちらを選ぶべきか
目的別の判断基準
- アプリの実行環境を軽量・高速に再現したい → Docker
- CI/CDでビルド・テスト環境を素早く使い捨てたい → Docker
- ホストと異なるOSをそのまま動かしたい → VM
- 強固なセキュリティ境界で環境を完全分離したい → VM
- クラウド上でアプリを運用したい → 多くの場合、VM上でDockerを動かす併用構成
「軽さ・速さ」を取るならDocker、「OSレベルの独立性」を取るならVM、というのが基本の判断軸です。
そして実務では、両方を理解したうえで適材適所に組み合わせる発想が最も現実的です。
まとめ
この記事のポイント
- VMはハイパーバイザー上でゲストOSを丸ごと動かし、Dockerはホストのカーネルを共有してプロセスを隔離する
- 例えるなら、VMは一戸建て、Dockerはマンションの部屋。インフラ共有の有無が軽さの差を生む
- 起動速度・リソース消費ではDockerが優位、OSそのものの独立性ではVMが優位
- 実務ではDockerとVMは対立関係ではなく、VM上でDockerを動かす併用構成が一般的
次に読むべき記事
- Dockerとは？コンテナ技術を初心者向けに解説（第1回）
- docker-composeでWeb+DB構成を連携させる
- よくあるDockerエラーまとめ
これでDocker編（全15本）は完結です。
ここまでお読みいただき、ありがとうございました。
タグ: Docker, 中級者向け, 比較検証
