Docker vs 仮想マシン：5分で理解する性能差とシーン別選び方ガイド

定例会で上司から「新プロジェクトは Docker と仮想マシンのどちらにする？」と聞かれました。どちらも使ったことはあるのに、違いをはっきり説明するのは意外と難しい。デスクに戻って調べてみると、ネット上の記事は理論ばかりか、「Docker の方が軽量」で終わっている——軽いのはわかるけど、どこが？性能差はどのくらい？どんなシーンでどちらを選ぶ？まったく書いていない。

3 日かけてようやく腑に落ちました。本記事では、Docker と仮想マシンの違いをいちばんわかりやすい形で整理します。読み終われば、両者の本質的な違い（イメージしやすい比喩付き）、性能がどのくらい違うか（実測データ）、判断ツリーで一瞬で技術選定できるようになります。

本質的な違い——コンテナ vs 独立した部屋

まず、いちばんわかりやすい比喩から。

仮想マシンは、ビルの中の独立した一室のようなもの。各部屋にキッチン、バスルーム、水回りがそろっていて、完全な生活空間。2 階に住むあなたと 3 階の隣人は互いに干渉しない。各 VM は Windows や Linux など完全な OS を動かし、独自のカーネル、ドライバ、システムサービスを持つ。最初から最後までフルセット。

Docker コンテナは、港のコンテナのようなもの。すべてのコンテナがクレーン、電力、道路といった港のインフラを共有する。中身はアプリと必要な依存関係だけ。各箱ごとにインフラ一式は不要。Docker コンテナはホスト OS のカーネルを共有し、アプリと実行環境だけをパッケージ化する。

一見小さな違いに見えて、影響は全方位に及ぶ。

アーキテクチャ上、仮想マシンには 2 つの重い荷物がある。Guest OS（ゲスト OS）と Hypervisor（仮想化レイヤー）。Hypervisor は CPU、メモリ、ディスク、NIC までハードウェア一式を仮想化する。VM 起動時は完全な OS を起動し、カーネル読み込み、サービス初期化——まるで PC を再起動するようなもの。

Docker は？ホストカーネルの上で直接動く。コンテナ起動はプロセス起動とほぼ同じ。秒で立ち上がる。ハードウェア仮想化のオーバーヘッドも、追加 OS レイヤーもない。圧倒的に軽い。

「カーネル共有で大丈夫？」と思うかもしれない。後述しますが、これこそ Docker の弱点——隔離性は VM より弱い。でも同時に最大の強み——速い、軽い、省リソース。

この本質的な差を押さえれば、性能比較もユースケースも一本の線でつながる。

性能対決——数字が物語る

理論だけでは不十分。データを見よう。

起動速度：秒 vs 分

先週テストした。設定済み VM（2 コア 4 GB）を起動し、SSH ログインできるまで約 4 分。コーヒーを淹れて SNS を見ている間に終わらなかった。

同じ Redis サービスを Docker で起動したら？3 秒。

マウスから手を離す暇もない。

偶然ではない。VM は完全な OS を読み込む——カーネル初期化、サービス起動、ネットワーク設定、すべて必要。Docker のコンテナ起動はプロセス起動。カーネルはすでに動いている。すぐに仕事に入れる。

リソース消費：MB vs GB

もっと衝撃的なのがリソース消費。Docker 自体のオーバーヘッド？6〜8 MB メモリ。1 桁台の MB です。

Redis コンテナを走らせた実測：CPU 0.08%、メモリ 2.6 MB。存在感ゼロに近い。

VM は？中身が空でも OS だけで 1〜2 GB メモリ。MySQL 用 VM なら 4 GB は当たり前。

残酷な現実：同じ物理サーバーでも、VM は数十個が限界。Docker は数千個。本番環境で 32 コア 128 GB サーバーに 800 個以上のコンテナが余裕で動いているのを見た。VM に換算したら 30 個で限界。

性能ロス：ほぼネイティブ vs 体感できる遅さ

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

今すぐ始める →広告

研究機関のベンチマークでは、Docker コンテナの性能はほぼすべてのシーンでネイティブと同等。場合によっては仮想化オーバーヘッドがない分、速いこともある。VM は通常 10〜20% の性能ロス。

CPU 集約的なコンパイルで試した。VM では 25 分、コンテナでは 21 分、物理マシンでは 20 分。コンテナはほぼ性能ロスなし。

比較表で一目でわかる：

この表を見れば、なぜマイクロサービスが Docker に移行しているかわかる。リソース効率が桁違い。誰もが惹かれる。

隔離性とセキュリティ——強ければいいわけではない

性能の話のあと、Docker の弱点を語ろう。

隔離レベルの違い

VM はハードウェアレベルの隔離。各 VM が独立した OS カーネルを持ち、完全に別の PC のようなもの。A VM が侵害されても、理論上 B VM やホストには飛べない。「ハード隔離」と呼ばれる。

Docker はプロセスレベルの隔離。すべてのコンテナがホストカーネルを共有し、Linux の namespace と cgroups でリソースを区切るだけ。保険感は薄い。

事実もそう。コンテナエスケープ（Container Escape）は Docker 向けの攻撃手法——コンテナの脆弱性からホストへ突破する。昨年の CVE-2024-21626 では、攻撃者がコンテナからホストへ脱出できた。

VM にもリスクはある。ただし難易度ははるかに高い。

VM が必須なシーン

Docker が不安全というわけではない。隔離要件の高さ次第。

クラウド事業者なら、顧客間は完全隔離が必須——VM を使う。AWS など主要なパブリッククラウドも、テナント間は VM で隔離する。A 顧客と B 顧客がカーネルを共有？A が攻撃されたら B も巻き添え。

金融機関なら、ISO 27001 など厳格なコンプライアンス要件がある。監査で Docker のカーネル共有を見たら不合格——素直に VM。

信頼できないコードの実行、例えばオンラインコンパイラ（ユーザーが任意コードを提出して実行）なら、Docker はリスクが高すぎる。VM が必須。

Docker のセキュリティ強化

とはいえ、多くのシーンはそこまで極端ではない。自社内部のマイクロサービス、自社コードだけなら Docker で十分。以下 3 点を守る：

1. root ユーザーでコンテナを動かさない。デフォルトは root 権限。侵害時の影響が大きい。非特権ユーザーに切り替える。
2. コンテナ権限を制限（Capabilities）。不要なシステム権限を与えない。
3. イメージの脆弱性を定期スキャン。Trivy などでベースイメージを更新。

私たちのチームも 3 点すべてを設定し、2 年間セキュリティ事故ゼロ。

要するに、隔離の強さは脅威モデル次第。社内アプリは Docker で足りる。外部公開のマルチテナントだけ VM を検討。

ユースケース——判断ツリー

ここまで読んだら、いつどちらを選ぶか。シンプルな判断フロー。

Docker を優先する 4 シーン

1. マイクロサービスアーキテクチャ

マイクロサービスなら、迷わず Docker。

なぜ？大きなアプリを数十〜数百の小サービスに分割し、各サービスを独立デプロイする。VM だとユーザーサービス 1 台、注文サービス 1 台、決済サービス 1 台……リソースが持たない。

Docker は軽量・秒起動・高密度に最適。EC サイトのユーザー、注文、決済サービスを各コンテナで動かし、リソース隔離しつつ横方向スケールも簡単。

以前参加したプロジェクトでは、30 以上のマイクロサービスをすべてコンテナ化し、5 台のサーバーに配置。VM ならサーバーコストが 3 倍はかかっていた。

2. DevOps と CI/CD パイプライン

開発・テスト・本番環境の不一致は、すべての開発者の悪夢。「私の PC では動く」——何度聞いただろう。

Docker はこの問題のための技術。アプリと依存関係をイメージに固めれば、開発で動けばテストも本番も動く。環境完全一致。

CI/CD も同様。Jenkins が毎回クリーンな環境を必要とするとき、Docker コンテナを起動してテスト、終わったら破棄。20 秒で完了。VM なら起動だけ 5 分、環境クリーンアップも手動。面倒。

3. 迅速デプロイと弾力的スケール

夜 11 時、突然トラフィック急増。緊急で 10 インスタンス追加が必要。

Docker：数秒で 10 コンテナ起動。
VM：1 台 5 分、10 台で 50 分。ユーザーはとっくに去っている。

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

価格を見る →広告

Docker の必殺技——弾力スケール。K8s（Kubernetes）はトラフィックに応じてコンテナ数を自動増減。VM ではこの速度は不可能。

4. 開発環境の統一

チーム 5 人。山田さんは macOS、佐藤さんは Windows、鈴木さんは Ubuntu。MySQL バージョンも Node バージョンもバラバラ。「そっちでは動く？」が日常。

Docker の環境イメージを 1 セット用意すれば、全員 docker-compose up で MySQL、Redis、Nginx が一括起動。バージョン固定、環境一致。環境問題、卒業。

VM を選ぶ 4 シーン

1. 従来型モノリシックアプリ

10 年前の老 ERP、Java 6 + Oracle、CentOS 6 上で動く。コード数十万行、触れない、触りたくない。

この場合 Docker 化は無理。VM で安定稼働、それが正解。コンテナ化のコストとリスクが高すぎる。

2. 複数 OS の要件

Windows アプリと Linux アプリを同時に動かす必要がある。例：テストチームが Windows Server で .NET、Linux で Java。

Docker は Linux コンテナが主（Windows コンテナもあるがサポートは限定的）。VM で 1 台 Windows、1 台 Linux が必須。

Mac で Windows ソフトをテストする開発者も、VMware や VirtualBox で Windows VM を使うしかない。

3. 強い隔離要件

クラウド事業者、マルチテナント SaaS——顧客間は完全隔離。VM なら顧客ごとに独立カーネル。

金融、政府プロジェクト——コンプライアンス監査で強い隔離を証明する必要がある。Docker のカーネル共有は通らない。

4. 完全な OS 環境のシミュレーション

組み込みドライバ開発で特定カーネルバージョンとハードウェア環境が必要。OS 低レイヤー開発。

Docker はホストカーネルを共有する。VM ならハードウェアとカーネルを完全シミュレーション、自由にインストール可能。

ハイブリッド運用が王道

実際、多くの企業は混在運用。

うちの会社の例：

• 基幹取引システム（5 年安定稼働）：VM
• 新規 API ゲートウェイ、マイクロサービス：Docker + Kubernetes
• 開発・テスト環境：すべて Docker
• Windows オフィスシステムテスト：VMware VM

基幹業務の安定性と、コンテナ技術の俊敏性を両立。「ツーモード IT」の典型。

判断ツリーで素早く決める

アプリは新規開発？
├─ はい → マイクロサービス？
│   ├─ はい → Docker ✅
│   └─ いいえ → 頻繁に更新・デプロイする？
│       ├─ はい → Docker ✅
│       └─ いいえ → 他の要素で判断
└─ いいえ（レガシー）→ 特定 OS / カーネルが必要？
    ├─ はい → VM ✅
    └─ いいえ → 強い隔離が必要？
        ├─ はい → VM ✅
        └─ いいえ → コンテナ化改造を試す → Docker ✅

このフローに沿えば、ほとんどの場合判断できる。

実例——みんなどう選んでいるか

机上の空論ではなく、実際のシーン。

事例 1：スタートアップの All-in Docker

友人の SaaS スタートアップ、チーム 15 人。サーバー予算が厳しく、4 コア 8 GB のクラウドサーバー 3 台に十数サービスを載せる必要があった。

VM なら 3 台で最大 15 VM、リソース上限。彼らは Docker + Kubernetes を採用。3 台で 60 以上のコンテナ、まだ余裕。

開発環境も統一。新人入社初日、コード clone、docker-compose up、5 分で環境完成。以前 VM なら半日かかっていた。

コスト削減？VM なら 10 台必要だった。今は 3 台。年間数万のサーバー費用を節約。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

スタートアップにとって、現金の価値。

事例 2：伝統企業の段階的改造

某製造業、15 年稼働の基幹 ERP（SAP + Oracle）、老朽 IBM サーバー（VM）上で動く。触れない。

昨年デジタル化で新サプライチェーンシステム開発。IT ディレクターは賢明：基幹 ERP は据え置き、新規事業は Docker マイクロサービス。

現在のアーキテクチャ：

• 老 ERP：VM、5 台、堅牢
• 新サプライチェーン：Docker + K8s、3 台、70 以上のコンテナ
• API ゲートウェイで連携

基幹の安定性（数百人がこのシステムで働く）と新規の俊敏性を両立。典型的な「ツーモード IT」。

事例 3：クラウド事業者のセキュリティ隔離

某小型クラウド事業者、企業向け仮想ホスティング。顧客ごとに独立実行環境が必要。

最初 Docker を検討——コストが安い。技術ディレクターが却下：顧客間は強い隔離が必須。ある顧客のサイトが侵害されても他に影響を与えられない。Docker のカーネル共有はリスク大。

結局 KVM VM。顧客ごとに 1 VM、カーネル隔離。コストは高いが安全。顧客も納得——契約書に「独立仮想サーバー」と明記、コンテナではない。

セキュリティ優先の典型。

事例 4：ハイブリッドクラウドのベストプラクティス

某インターネット企業、ゲーム事業。コア DB は自社データセンター（データセキュリティ要件）、ゲームサーバーは弾力スケール（イベント時のトラフィック急増）。

彼らの構成：

• 自社 DC：MySQL マスターは VM、安定第一
• クラウド：ゲームサービス全部 Docker 化、K8s 接続、ピーク時自動スケール
• イベント中：10 コンテナ → 100 コンテナ、10 分
• イベント後：20 コンテナに自動縮小、コスト節約

安定性、弾力性、コストのバランス。コアは VM、エッジは Docker。各々の強みを活かす。

これらの事例からわかるように、絶対の正解はない。適合性だけ。

まとめ

結局、Docker と仮想マシンは二者択一ではなく、それぞれ得意分野があるツール。

新規プロジェクト、迅速なイテレーション、環境一致を求めるなら——Docker が最適。起動が速く、リソース消費が低く、マイクロサービスと DevOps にぴったり。私の新規プロジェクトもほぼ Docker スタート。本当に快適。

レガシー保守、強い隔離、複数 OS 実行が必要なら——VM が適切。安定性とセキュリティが担保される。必要なときは迷わず。

多くの企業はハイブリッド運用。基幹は VM で安定、エッジは Docker でスピード。教条より実用主義。

最後に 3 つのアクション：

1. プロジェクトを評価：上の判断ツリーに当てはめ、5 分で適性を判断
2. 小さく試す：Docker を選ぶなら、非コアサービスから。いきなり全部コンテナ化しない
3. 学び続ける：Kubernetes、Serverless、エッジコンピューティング——コンテナ技術は進化中。好奇心を持ち続ける

Docker に興味があれば、次回は「Docker 入門実践：インストールから最初のコンテナまで」を執筆予定。手取り足取りガイド。

ツール選び、作業効率を左右する。本記事が正しい判断の助けになれば幸いです。