コンテナとVMの違いと使い分け — DockerとVMをいつ選ぶか
本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。
TL;DR
- VM（仮想マシン） はハイパーバイザが物理ハードウェアを分割し、ゲストOSごと独立して動かす。隔離レベルが高く、別OSを動かしたい・強いセキュリティ境界が必要なときに適している。
- コンテナ（Docker等） はホストOSのカーネルを共有し、プロセスレベルで隔離する。軽量・高速起動・大量展開・再現性が強みで、アプリ単位の配布や開発環境の統一に向く。
- 根本的な違いは「OSまるごとを仮想化するか、プロセスを隔離するか」の一点に集約される。
- 現場では「VMの上にコンテナを動かす」構成が多数派。VPSを1台借りてDockerを入れるのが典型。
- カーネル共有のコンテナはVMより隔離が薄い。マルチテナント環境や高セキュリティ要件では依然VMが必要。
VMとは何か — OSをまるごと仮想化する
VM（Virtual Machine / 仮想マシン）は、ハイパーバイザと呼ばれるソフトウェアが物理マシンのCPU・メモリ・ストレージを論理的に分割し、複数の「仮想的なコンピュータ」を作り出す技術です。
ハイパーバイザの2種類
| 種類 | 動作位置 | 代表製品 | 主な用途 |
|---|---|---|---|
| タイプ1（ベアメタル） | ハードウェア上に直接 | VMware ESXi、KVM、Microsoft Hyper-V | データセンター・クラウド基盤 |
| タイプ2（ホスト型） | ホストOS上で動作 | VirtualBox、VMware Workstation | 開発・検証用のローカル環境 |
クラウドのVPS（ConoHa VPS、Xserver VPS 等）はタイプ1に近い構成で、物理サーバーを複数のVMに切り分けて提供しています。あなたが借りる「1台のVPS」も、実際には大きな物理サーバー上のVM1つです。
VMの特徴
VM内にはゲストOS（Ubuntu、Windows 等）が丸ごと入ります。ゲストOSはハードウェアを直接操作しているように振る舞いますが、実際にはハイパーバイザが仲介しています。
- 起動時間: ゲストOSのブート処理が走るため、数十秒〜数分かかる
- リソース消費: OSカーネル・デーモン群をVM台数分だけ消費する
- イメージサイズ: OSを含むため数GB〜数十GBが標準
- 隔離: カーネルレベルで分離されており、あるVMが侵害されても他のVMへの影響は極めて小さい
コンテナとは何か — カーネルを共有してプロセスを隔離する
コンテナはLinuxカーネルの機能（namespaces と cgroups）を利用して、プロセスの見える範囲とリソース使用量を制限する技術です。Dockerはこの仕組みを使いやすくラップしたツールです。
namespaces と cgroups
| カーネル機能 | 役割 |
|---|---|
| namespaces | プロセスから見えるリソース（ファイルシステム・ネットワーク・PID等）を隔離する |
| cgroups（control groups） | CPU・メモリ・I/Oの使用量をプロセスグループ単位で制限する |
コンテナはあくまでホストOSのカーネル上で動く「隔離されたプロセス群」です。コンテナ内のプロセスは独立した環境に見えますが、カーネルそのものはホストと共有しています。
コンテナの特徴
- 起動時間: カーネルのブートが不要なためミリ秒〜数秒で起動する
- リソース消費: ゲストOSが不要なため非常に軽量。同一ホストで数十〜数百コンテナを動かせる
- イメージサイズ: OSのフルセットを含まず、アプリの動作に必要なファイルのみを格納するため数MB〜数百MB
- 再現性:
Dockerfileとdocker-compose.ymlでアプリの環境を宣言的に記述し、どのホストでも同じ状態を再現できる - 隔離: カーネルを共有するため、VMに比べると隔離レベルは低い
根本的な違いを整理する
仮想化の対象が異なる
VMとコンテナの本質的な違いは、「何を仮想化・隔離しているか」です。
【VM の構成】
┌─────────────────────────────────────────┐
│ 物理ハードウェア │
├─────────────────────────────────────────┤
│ ハイパーバイザ │
├──────────────────┬──────────────────────┤
│ ゲストOS（VM1） │ ゲストOS（VM2） │
│ ┌──────────┐ │ ┌──────────┐ │
│ │ アプリA │ │ │ アプリB │ │
│ └──────────┘ │ └──────────┘ │
└──────────────────┴──────────────────────┘
【コンテナの構成】
┌─────────────────────────────────────────┐
│ 物理ハードウェア │
├─────────────────────────────────────────┤
│ ホストOS（Linuxカーネル） │
├──────────────────┬──────────────────────┤
│ コンテナ1（アプリA）│ コンテナ2（アプリB） │
│ （namespace分離） │ （namespace分離） │
└──────────────────┴──────────────────────┘VMはゲストOSごと分離します。コンテナはカーネルを共有したまま、プロセスから見える「名前空間」を分離します。
4つの観点での比較
| 観点 | VM | コンテナ（Docker） |
|---|---|---|
| 隔離レベル | カーネルレベル（高い） | プロセスレベル（低〜中） |
| 起動速度 | 数十秒〜数分 | ミリ秒〜数秒 |
| オーバーヘッド | ゲストOSのリソースが必要（大） | カーネル共有で軽量（小） |
| イメージサイズ | GB単位 | MB〜数百MB |
| 同一ホストでの多重起動 | 台数に限界あり（メモリ消費大） | 数十〜数百コンテナが現実的 |
| 別OSの実行 | 可能（Windows上でLinux等） | 原則不可（カーネルはホストと同じ） |
| 再現性の担保 | スナップショット、テンプレート | Dockerfile / Compose で宣言的 |
| ポータビリティ | VMイメージは大きく移動コスト大 | コンテナイメージは軽量で共有しやすい |
使い分けの判断軸
VMを選ぶべきケース
強い隔離が必要なとき
マルチテナント環境（複数のユーザーやチームが同一ホストを使う）や、セキュリティ要件が厳しいシステムでは、カーネルを共有するコンテナではリスクが残ります。コンテナのカーネル脆弱性（後述）を突かれると、ホスト全体に影響が及ぶ可能性があります。VMならゲストOSが侵害されても、ハイパーバイザの隔離がそれ以上の拡大を防ぎます。
ホストとは異なるOSを動かしたいとき
コンテナはLinuxカーネルを前提とします。LinuxホストでWindowsアプリを動かしたい、あるいはその逆の場合は、VMを使う必要があります。開発環境でWindowsの動作確認用VMを用意するケースが典型です。
OS全体の設定・カーネルパラメータを変えたいとき
コンテナはカーネルを共有するため、sysctl 等のカーネルパラメータ変更がホスト全体に影響します。アプリごとに異なるカーネル設定が必要な場合は、VMの方が安全に隔離できます。
コンテナを選ぶべきケース
アプリを軽量・多数・高速に動かしたいとき
マイクロサービス構成、CI/CDパイプライン、開発・ステージング・本番の環境統一など、多数のプロセスを効率的に扱いたい場面ではコンテナが優れています。1台のVPSで10〜20本のサービスを動かすような自己ホスト構成も、コンテナならリソース効率よく実現できます。
「どこでも同じ動作」を保証したいとき
Dockerfile と docker-compose.yml で環境を宣言的に記述すれば、ローカル・CI・本番を問わず同じイメージで動かせます。「ローカルでは動いたのにサーバーで動かない」という問題を構造的に減らせます。詳しい構成方法は Docker Composeで自己ホストを始める で解説しています。
デプロイ・スケールの速度が重要なとき
Kubernetesに代表されるコンテナオーケストレーションを使うと、負荷に応じたスケールアウト・ローリングアップデート・障害時の自動復旧が自動化できます。VMで同等のことをやろうとすると、起動時間とリソースの重さがボトルネックになります。
両者の併用 — VMの上にコンテナを動かす
現実の構成では、VMとコンテナは対立するものではなく、VMの上でコンテナを動かすのが一般的です。
┌──────────────────────────────────────────────────────┐
│ 物理サーバー │
├──────────────────────────────────────────────────────┤
│ ハイパーバイザ │
├──────────────────────────────────────────────────────┤
│ VM（Ubuntu 24.04 LTS）←— あなたが借りるVPS │
│ ┌──────────────────────────────────────────────┐ │
│ │ Docker Engine │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Nginx │ │ PostgreSQL│ │ Nextcloud│ │ │
│ │ │コンテナ │ │コンテナ │ │コンテナ │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘ConoHa VPSやXserver VPSは、クラウド基盤のVM上にUbuntuを提供します。ユーザーはそのVM（VPS）にDockerをインストールし、その上でコンテナを動かします。VMの強い隔離（VPS同士は独立）と、コンテナの軽量・再現性の両方を自然に享受できる構成です。
セキュリティ観点 — カーネル共有のリスク
コンテナがVMより隔離が薄い理由を、具体的に押さえておきます。
コンテナのエスケープリスク
コンテナはホストカーネルを共有します。コンテナランタイム（Docker等）やLinuxカーネルに脆弱性があると、コンテナ内から「エスケープ」してホストに到達できる可能性があります。VMの場合、ゲストからの攻撃はハイパーバイザを通過しなければならず、このレイヤーが追加の防御壁になります。
rootコンテナのリスク
コンテナ内のプロセスが root で動いている場合、ファイルシステムや /proc などの操作を通じてホストへの影響が生じるリスクがあります。本番環境では非rootユーザーでコンテナを動かす（USER 命令の利用）、--read-only フラグの活用、seccompプロファイルの適用といった対策が重要です。
リスクを踏まえた現実的な使い方
| 環境 | 推奨方針 |
|---|---|
| 個人・自己ホスト（1人運用） | コンテナで十分。定期的なDockerとOSのアップデートを徹底する |
| 社内システム（複数ユーザー） | VPSレベルのVM隔離を基盤に置いた上でコンテナを運用する |
| マルチテナントSaaS | ユーザーごとのVM分離を検討する。コンテナのみでは隔離が不十分な場合がある |
コンテナが普及した現在も、セキュリティ要件が厳しい環境でVMが使われ続けているのは、このカーネル共有リスクを理由とした合理的な判断です。
まとめ
| 観点 | VM | コンテナ（Docker） |
|---|---|---|
| 仮想化の単位 | OSごと | プロセス（カーネル共有） |
| 隔離の強度 | 高い（カーネル分離） | 低〜中（namespace分離） |
| 起動速度 | 遅い（OS起動が必要） | 速い（ミリ秒〜秒） |
| リソース効率 | 重い（OS台数分消費） | 軽い（アプリ分のみ） |
| イメージサイズ | GB単位 | MB〜数百MB |
| 別OS実行 | 可能 | 原則不可 |
| 典型的な用途 | 強隔離・別OS・カーネル設定 | アプリ配布・CI/CD・自己ホスト |
| 現実の組み合わせ | VMの上にコンテナを動かすのが一般的 | — |
コンテナとVMは「どちらが優れているか」ではなく、「何を解決したいか」で選ぶものです。強い隔離や別OSが必要ならVM、軽量・再現性・多数展開が必要ならコンテナを選びます。実際の自己ホスト環境では、VPSというVM上にDockerを入れてコンテナを動かす構成が最も現実的で、両者の長所を自然に組み合わせられます。
各サービス公式
VPSの契約は各公式サイトから行えます。
