1.1 仮想マシン（VM）とDockerコンテナの違い｜仕組みから使い分けまで徹底解説

【第1章】Dockerとは何か
2026.04.03

「DockerってVMの何が違うの？」——Dockerを学び始めた人が最初にぶつかる疑問です。どちらも「1台のサーバーで複数の独立した環境を動かす」技術ですが、その仕組みはまったく別物で、得意なことも違います。

この記事では図解・シミュレータ・実測値を使いながら、両者の違いを初心者にも上級者にもわかる形で解説します。「なんとなく知っている」から「人に説明できる」レベルを目指しましょう。

目次

  1. 仮想マシン（VM）とは
  2. コンテナとは
  3. アーキテクチャを並べて比較する
  4. 違い①　起動速度：秒 vs 分
  5. 違い②　サイズ：MBレベル vs GBレベル
  6. 違い③　分離レベル：カーネル共有 vs 完全分離
  7. 違い④　ポータビリティと再現性
  8. 使い分けガイド：どちらを選ぶべきか
  9. 補足：WindowsとMacでDockerが動く仕組み
  10. まとめ

1. 仮想マシン（VM）とは

仮想マシン（Virtual Machine）は、ハイパーバイザーというソフトウェアを使って、1台の物理サーバーの上に「仮想的なコンピュータ」を複数作り出す技術です。1960年代のIBMメインフレームにルーツを持つ、成熟した技術です。

各VMは独立したゲストOSカーネルを持ちます。WindowsサーバーにLinux VMを動かすことも、その逆も可能です。

ハイパーバイザーの2種類

種別 動作する場所 代表例 主な用途
タイプ1（ベアメタル） ハードウェアの直上 VMware ESXi、Microsoft Hyper-V、KVM データセンター・本番サーバー
タイプ2（ホスト型） ホストOSの上 VirtualBox、VMware Workstation、Parallels 開発者のローカルPC
仮想マシン 1
アプリ A
ゲストOS
（カーネル）
仮想マシン 2
アプリ B
ゲストOS
（カーネル）
仮想マシン 3
アプリ C
ゲストOS
（カーネル）
ハイパーバイザー（タイプ1）
物理サーバー（ハードウェア）
↑ 各VMに独立したカーネルがある

タイプ2（ホスト型）は、ハイパーバイザー自体がホストOSのアプリとして動作します。VirtualBox・VMware Workstation・Parallels などが該当し、開発者のローカルPCで広く使われます。

仮想マシン 1
アプリ A
ゲストOS
（カーネル）
仮想マシン 2
アプリ B
ゲストOS
（カーネル）
仮想マシン 3
アプリ C
ゲストOS
（カーネル）
ハイパーバイザー（タイプ2）
ホストOS（Windows / macOS / Linux など）
物理PC（ハードウェア）
↑ ホストOSの上でアプリとして動作。セットアップが簡単で開発者のローカルPCに向く
✅ VMの強み：ゲストOSレベルで完全に分離されているため、あるVMでカーネルパニックが起きても他のVMには影響しません。金融・医療系や、見知らぬ第三者のコードを実行するマルチテナント環境で今も重宝されています。

2. コンテナとは

コンテナは、ホストOSのカーネルを共有しながら、プロセス・ネットワーク・ファイルシステムを互いに見えないように分離する技術です。ゲストOSは持ちません。

Dockerはこの技術に「イメージ」「レジストリ」「CLI」「compose」といったエコシステムを加えて、開発者が使いやすい形にパッケージングしたものです。

コンテナ 1
アプリ A
＋ライブラリ
コンテナ 2
アプリ B
＋ライブラリ
コンテナ 3
アプリ C
＋ライブラリ
コンテナランタイム（Docker）
ホストOS（Linux）＋ カーネル（共有）
物理サーバー（ハードウェア）
↑ カーネルは1つだけ。ゲストOSは不要

コンテナの分離を担っているのは、Linuxカーネルに組み込まれている2つの機能です（次の記事 1-5 で詳しく解説します）。

  • 名前空間（namespaces）：プロセス・ネットワーク・ファイルシステムなどの「見える範囲」をコンテナごとに分離
  • cgroups（Control Groups）：CPU・メモリ・I/Oなどのリソース使用量を制限・計測

3. アーキテクチャを並べて比較する

VMとコンテナの最大の違いは、「ゲストOSを持つかどうか」です。図で並べると一目瞭然です。

【仮想マシン（VM）】
App A
App B
App C
GuestOS
カーネル
GuestOS
カーネル
GuestOS
カーネル
ハイパーバイザー ← 重い
ホストOS（ある場合）
ハードウェア
【コンテナ（Docker）】
App A
App B
App C
ライブラリ（各コンテナ）
ゲストOSなし・軽量 ← 軽い
Docker（コンテナ管理）
HostOS＋カーネル（共有）
ハードウェア

VMは各アプリの下にゲストOSが丸ごと乗っています。コンテナはカーネルを共有するため、アプリに必要なライブラリだけを持てばよく、その分だけ軽量になります。

💡 コンテナはゲストOSを持たないからこそ速くて軽い
起動時間が「分」から「秒」になり、イメージサイズが「GB」から「MB」になる理由は、すべてこの「ゲストOSがない」という1点に集約されます。

シミュレータで実際に体感してみましょう。▶ボタンを押すと、VMとコンテナが同時に「起動」を開始します。

4. 違い①　起動速度：秒 vs 分

開発の生産性に直結するのが起動速度の差です。

仮想マシン（VM） コンテナ（Docker）
コールドブート（新規起動） 30秒〜数分 数百ミリ秒〜数秒
起動時にやること BIOS → ブートローダー → カーネルロード → init/systemd → サービス起動 名前空間・cgroups の準備 → プロセス起動（この2ステップだけ）
停止からの再起動 スナップショットなら速いが依然VMより重い ほぼ同じ（数秒以内）

VMはカーネルを一から起動するのに対し、コンテナはホストのカーネルを借りるだけです。カーネルはすでに起動しているので、コンテナは「プロセスを1つ追加する」のと本質的に同じです。

開発現場での意味

  • CI/CDパイプライン：テストのたびにクリーンな環境が数秒で用意できる。VMだと1ジョブあたり数分余計にかかる。
  • スケールアウト：アクセス急増時に新しいコンテナを秒単位で追加できる。
  • 開発サイクル：コード修正→コンテナ再起動→動作確認のループが圧倒的に速い。
⚠️ 補足：VMも「スナップショット」や「ライブマイグレーション」で高速化できますが、コールドブート（初回起動）の差は埋まりません。また、Firecracker（AWS Lambda・Fargate の基盤）のようにマイクロVMでVMの強固な分離とコンテナの起動速度を両立しようとする技術も登場しています。

5. 違い②　サイズ：MBレベル vs GBレベル

サイズの違いは、ストレージコスト・転送時間・CI/CDのキャッシュ効率に直接響きます。

イメージ／OVA サイズ 種別
alpine（最小Linux） 約 7 MB コンテナイメージ
ubuntu:22.04 約 78 MB コンテナイメージ
nginx（Webサーバー） 約 187 MB コンテナイメージ
ubuntu 22.04 Server（ISO） 約 1.4 GB VM インストールメディア
Ubuntu Server VM（インストール後） 約 2〜5 GB VM ディスクイメージ
Windows Server 2022 VM 10 GB〜 VM ディスクイメージ

なぜコンテナはこんなに小さいのか

コンテナイメージには「カーネル」が含まれません。ubuntu イメージに含まれているのは、Ubuntuのパッケージ群・設定ファイル・ライブラリだけで、カーネルはホストから借りるためです。

さらにDockerはイメージをレイヤー構造で管理しています。同じベースイメージ（たとえば ubuntu）を使う10個のコンテナを起動しても、ディスク上のubuntuレイヤーは1つだけです。VMなら同じOSを10個分保持します。

シミュレータでイメージサイズを体感する

下のシミュレータで実際に docker pull alpine や docker pull ubuntu を実行して、イメージサイズを確認してみましょう。Docker Hub のカタログ（左パネル）には各イメージのサイズも表示されています。

試してみよう：

  • docker pull alpine — 7.34 MB。最小限のLinuxがたったこのサイズ
  • docker pull ubuntu — 77.9 MB。フルのUbuntu環境がVM比で1/50以下
  • docker pull node — 1.1 GB。Node.jsのように依存が多いと大きくなる（alpine タグで軽量版も選べる）
  • docker images — pullしたイメージ一覧とサイズを確認
💡 レイヤーキャッシュの効果
ubuntu ベースのイメージをすでにpull済みなら、それを使う別のイメージ（例：python）をpullするとき、ubuntuレイヤーは再ダウンロードされません。この「共有レイヤー」の仕組みが、コンテナの転送効率をさらに高めています（詳細は第3章で）。

シミュレータでレイヤー共有を体感する

① → ② → ③ の順で pull ボタンを押してください。2回目・3回目の pull では、すでにダウンロード済みのレイヤーがスキップされ、ディスク節約量が確認できます。

6. 違い③　分離レベル：カーネル共有 vs 完全分離

「コンテナがVMより優れている」とは一概に言えません。分離レベルではVMが勝ります。

分離の強さ

観点 VM コンテナ
カーネルの共有 なし（各VMが独自カーネル） あり（ホストカーネルを共有）
カーネル脆弱性の影響範囲 そのVMのみ 同一ホストの全コンテナ
あるコンテナが暴走した場合 他VMへの影響なし cgroupsで制限していないと他コンテナに影響する可能性
root権限の漏洩リスク ゲストOS内のrootはホストに届かない コンテナ内root＋特権フラグがあるとホストに影響しうる

コンテナのセキュリティを高める仕組み（上級者向け）

コンテナの分離の弱さを補うため、Dockerは複数のセキュリティ機構を組み合わせています。

  • Seccomp（Secure Computing Mode）：コンテナが呼び出せるシステムコールを制限
  • AppArmor / SELinux：ファイルアクセスやネットワークをプロファイルで制限
  • Capabilities の制限：root権限を細かく分割し、必要なものだけ付与
  • rootless モード：Dockerデーモン自体を非rootユーザーで動かす
  • user名前空間：コンテナ内のUID 0（root）をホストの非特権UIDにマッピング

これらは第8章（セキュリティ）で詳しく扱います。日常的な開発用途ではデフォルト設定で十分ですが、本番環境では意識が必要です。

7. 違い④　ポータビリティと再現性

「自分のPCで動いたのに本番で動かない」問題を根本から解決するのがコンテナのポータビリティです。

観点 VM コンテナ
環境の再現性 VMイメージを配布すれば再現できる（ただしサイズが大きい） Dockerfile でコード化 → どこでも同じ環境が秒単位で再現
開発・テスト・本番の統一 ハイパーバイザー・OS の差異が残る 同じイメージを使えばすべての環境で同一
バージョン管理 OVAファイルは数GBでGit管理に不向き Dockerfile はテキスト → Git で差分管理できる
別ハードウェア/クラウドへの移動 ハイパーバイザー形式の変換が必要な場合がある Docker が入っていればどこでも動く 
# Dockerfile の例（Python Flask アプリ）
FROM python:3.12-alpine
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

このわずか6行で、Python 3.12 + 必要ライブラリがすべて揃った環境を記述できます。開発者全員が docker build を実行するだけで、誰の環境でも同じ状態が得られます。

8. 使い分けガイド：どちらを選ぶべきか

VMとコンテナは競合ではなく補完関係にあります。多くの本番環境では両方を使っています（例：VMware ESXiのVM上にDockerを動かす、AWS EC2インスタンス上でコンテナを動かす）。

シナリオ 推奨 理由
強固な分離が必要（マルチテナント・SaaS） VM（またはmicroVM） テナント間のカーネル共有を避けたい
異なるOS（WindowsゲストをLinuxで動かす等） VM コンテナはホストカーネルを共有するため同じOSファミリーが前提
GUIアプリ・デスクトップ環境 VM コンテナはGUIを持たないサーバープロセス向けに設計されている
マイクロサービス・APIサーバー コンテナ サービスごとに独立デプロイ・スケールが容易
CI/CDパイプライン（ビルド・テスト） コンテナ クリーンな環境を高速・安価に用意できる
開発環境の統一（チーム開発） コンテナ Dockerfile + Compose で全員が同じ環境
スケールアウトが頻繁に必要 コンテナ 数秒で新インスタンスを追加できる
レガシーアプリの移行（リフト＆シフト） 状況による まずVMで「そのまま移行」し、段階的にコンテナ化するアプローチが多い

9. 補足：WindowsとMacでDockerが動く仕組み

「コンテナはLinuxカーネルを共有する」と説明してきましたが、ではWindowsやMacでDockerを使うときは？という疑問が出るはずです。

実はここで「VMとコンテナの組み合わせ」が使われています。

Windows（Docker Desktop + WSL2）

Windows 11 ホスト
WSL2（軽量Linux VM）← Hyper-Vベース
コンテナ 1
コンテナ 2
Docker Engine（dockerd）
Linux カーネル（ここをコンテナが共有）
ハードウェア（物理PC）

Windows上のDockerコンテナは、WSL2（Windows Subsystem for Linux 2）という軽量LinuxVM内のLinuxカーネルを使って動作します。Docker Desktop for Windowsが自動でこの構成を作ります。

macOS（Docker Desktop + 軽量Linux VM）

macOSでも仕組みは同様です。Apple Silicon（M1/M2/M3）では Apple Virtualization Framework、Intel Macでは HyperKit を使って軽量LinuxVMを起動し、その中でLinuxカーネルを動かしています。

💡 ポイント
「コンテナにはゲストOSが不要」というのは正確にはLinux上で動かす場合の話です。WindowsやMacではLinuxカーネルを提供するための薄いVM層が必ず存在します。ただしこのVM層はDocker Desktopが透過的に管理するため、ユーザーはほとんど意識する必要がありません。

Apple Silicon（ARM64）とイメージアーキテクチャ

M1/M2/M3 MacはARM64アーキテクチャです。docker pull ubuntu のようにアーキテクチャを指定しない場合、Docker DesktopはホストのCPUアーキテクチャに合ったイメージを自動選択します（マルチアーキテクチャ対応イメージの場合）。

# 明示的にアーキテクチャを指定する場合
docker pull --platform linux/amd64 ubuntu   # Intel/AMD向け
docker pull --platform linux/arm64 ubuntu   # Apple Silicon / ARM向け

10. まとめ

VMとコンテナの違いを一文で言うと、「ゲストOSを持つかどうか」です。この違いが起動速度・サイズ・分離レベル・ポータビリティのすべてに波及しています。

比較項目 仮想マシン（VM） コンテナ（Docker）
ゲストOS あり（カーネルも独立） なし（ホストカーネルを共有）
起動時間 30秒〜数分 数秒以内
イメージサイズ 数GB〜数十GB 数MB〜数百MB
分離の強さ 強（カーネル・ハードウェアレベル） 中（プロセスレベル）
ポータビリティ 低〜中（ハイパーバイザー依存） 高（Docker環境ならどこでも）
環境のコード化 困難（OVAはGB単位） Dockerfileで数行
向いているユースケース 強固な分離・異OS実行・GUI Webアプリ・CI/CD・マイクロサービス
✅ 次のステップ
1-5 では、コンテナの分離を実現するLinuxの仕組み「名前空間（namespaces）」と「cgroups」を、実際のコマンド出力と合わせて解説します。「コンテナの中でPIDがなぜ1から始まるのか」が理解できるようになります。

参考リンク

  • Docker Hub（公式） — 公式・コミュニティ製のDockerイメージを検索・取得できるレジストリ。docker pull のデフォルト取得先。
  • Docker 公式ドキュメント — インストール手順からリファレンスまで網羅した一次情報源。

参考：コンテナ関連技術の位置づけ

技術名 役割
Docker コンテナの構築・実行・配布のエコシステム全体
containerd Dockerから分離されたコアランタイム。Kubernetesでも採用
OCI（Open Container Initiative） コンテナイメージとランタイムの業界標準仕様
Kubernetes（K8s） コンテナを大規模に管理・オーケストレーションするプラットフォーム（第11章）
Firecracker AWS開発のmicroVM。VMの強固な分離とコンテナの軽量性を両立（AWS Lambda/Fargateの基盤）

Dockerの基礎を動画で体系的に学びませんか？

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

Udemy Docker入門講座 クーポン割引で講座を見る →

コメント

タイトルとURLをコピーしました