コンテナ vs 仮想マシン ― Docker／Kubernetesは中小企業に必要か
「Dockerでアプリを動かしたい」「Kubernetes（K8s）を学びたい」「マイクロサービスに対応したい」――DXや内製化の流れで、中小企業の情シスにもコンテナ技術への関心が広がっています。
ただし、中小企業の業務システムでKubernetesが必要なケースは実はかなり限定的です。まずは「コンテナと仮想マシンは何が違うのか」「自社にとって必要なのか」を見極めることが重要です。
本記事では、コンテナ技術の基礎を中小企業の情シス目線で整理し、Docker／Kubernetesが必要なケースと、そうでないケースを切り分けます。
コンテナと仮想マシンの違い
仮想マシン（VM）
物理サーバ上のハイパーバイザ（VMware ESXi、Hyper-V、Proxmox等）が、完全なOSを内包した仮想マシンを複数動かす方式。各VMは独立したカーネル・OSライブラリ・アプリケーションを持ちます。
[物理サーバ]
├ [ハイパーバイザ]
├ [VM1: WindowsServer + 業務アプリ1]
├ [VM2: Linux + 業務アプリ2]
└ [VM3: Linux + 業務アプリ3]コンテナ
ホストOSのカーネルを共有しながら、ユーザー空間を分離して隔離されたプロセスを動かす方式。Docker・Podman等のコンテナランタイムが管理します。
[物理サーバ または VM]
├ [ホストOS（Linux）]
├ [コンテナランタイム（Docker等）]
├ [コンテナ1: アプリ1+ライブラリ]
├ [コンテナ2: アプリ2+ライブラリ]
└ [コンテナ3: アプリ3+ライブラリ]比較表
| 項目 | 仮想マシン | コンテナ |
|---|---|---|
| 隔離レベル | 強い（カーネル独立） | 弱い（カーネル共有） |
| 起動時間 | 数十秒〜数分 | 数百ms〜数秒 |
| サイズ | 数GB〜数十GB | 数MB〜数百MB |
| OS制約 | OS自由（Windows/Linux等） | ホストOSと同系統に限定 |
| パフォーマンス | オーバーヘッドあり | ほぼベアメタル並み |
| 運用ツール | vSphere, Hyper-V Manager | Docker, Kubernetes |
| セキュリティ | 強い分離 | カーネル共有のため攻撃面あり |
ざっくり「VMは安全だが重い、コンテナは軽いがカーネル共有」と理解してください。
コンテナの代表技術
Docker
最も普及しているコンテナランタイム。1台のサーバ上で複数のコンテナを動かす用途では事実上の標準です。
docker run -d -p 80:80 nginxこのような単純なコマンドでWebサーバが起動するため、開発・検証用途で広く使われています。
Docker Compose
複数のコンテナをまとめて管理するツール。docker-compose.yml に「Webサーバ＋アプリ＋DB」のような構成を書いておけば、1コマンドで起動できます。1〜数台のサーバで完結する小規模な業務システムには十分です。
Kubernetes（K8s）
多数のサーバにまたがって多数のコンテナを管理するためのプラットフォーム。Googleで開発され、OSS化されました。
主な機能：
- 複数ノード（サーバ）にコンテナを自動配置
- ノード障害時に自動で別ノードに再配置
- スケールアウト／スケールインの自動化
- ローリングアップデート
100コンテナ以上を多数のサーバで運用するエンタープライズ用途を想定した設計で、運用には専門知識が必要です。
Podman、containerd、cri-o
Docker代替・後継のコンテナランタイム。RHEL系では Podman が標準採用。Kubernetes は内部的に containerd / cri-o を使います。
マネージドコンテナサービス
自前でKubernetesクラスタを構築・運用するのは負荷が高いため、クラウド事業者のマネージドサービスを使うのが一般的です。
| サービス | 提供元 | 概要 |
|---|---|---|
| AKS（Azure Kubernetes Service） | Microsoft | Azure環境で標準 |
| EKS（Elastic Kubernetes Service） | AWS | AWS環境で標準 |
| GKE（Google Kubernetes Engine） | 元祖。最も成熟 | |
| Azure Container Apps | Microsoft | Kubernetesを意識しない簡易コンテナ |
| AWS ECS / Fargate | AWS | サーバレスコンテナ |
| Cloud Run | サーバレスコンテナ |
「Kubernetesを使いたいわけではなく、コンテナでアプリを動かしたいだけ」なら、Azure Container Apps、AWS Fargate、Cloud Runなどのサーバレスコンテナの方が運用負荷が圧倒的に低くなります。
中小企業でコンテナが必要なケース
以下のいずれかに該当するなら、コンテナ技術の導入を検討する価値があります。
① 自社開発アプリを継続的にデプロイしている。 開発チームがあり、アプリケーションを週次・日次でリリースしているなら、コンテナ＋CI/CDで開発生産性が大きく向上します。
② OSS自社ホスティングを多数運用している。 GitLab、Mattermost、Redmine、NextCloud等のOSSアプリを社内で複数ホスティングしているなら、コンテナで統一運用するとアップデート・移行が楽になります。
③ マイクロサービス的な構成にしたい。 Webサービスや業務アプリを、機能単位で分割して開発・スケールさせたい場合。
④ 開発環境の統一が必要。 「自分のPCでは動くが本番では動かない」問題を解消するため。Docker Composeで開発環境をコード化できる。
⑤ クラウド移行のステップとして。 オンプレ → コンテナ化 → クラウド移行 という段階的な移行戦略を取るケース。
コンテナが不要なケース
以下に該当するなら、コンテナ導入は急がなくて良いです。
① 業務アプリが市販SaaS／パッケージ製品中心。 Microsoft 365、Salesforce、kintone等のSaaSが業務の中心で、自社開発アプリがない場合。
② オンプレミスのWindowsサーバで業務システムが安定稼働。 会計、販売管理、給与計算など、長年動いている業務システム。WindowsサーバアプリのコンテナはWindows Containersで可能だが、運用が複雑。Hyper-V等の仮想化のままが楽。
③ 情シスが1〜2名で、運用負荷を増やせない。 Kubernetesの運用は専門スキルを要し、属人化しやすい。
④ アプリの更新頻度が低い（年数回）。 コンテナ＋CI/CDの恩恵が出にくい。
業務システムの使い分け例
中小企業のIT基盤で、何を仮想マシン、何をコンテナ、何をSaaSにするかを整理すると以下のようになります。
| システム | 推奨 |
|---|---|
| Active Directory・ファイルサーバ | 仮想マシン（または物理サーバ） |
| 会計・ERP・販売管理 | 仮想マシン または SaaS |
| メール・グループウェア | SaaS（Microsoft 365 / Google Workspace） |
| 自社開発の社内Webアプリ | コンテナ（Docker Compose） |
| 統計・データ分析基盤 | コンテナ（Jupyter, Airflow等） |
| 監視・ログ基盤（Grafana, Loki等） | コンテナ |
| バッチ処理・定期実行ジョブ | コンテナ（タスク単位） |
| 開発環境 | Docker Compose |
「業務基盤は仮想マシン／SaaS、開発・自社アプリ・OSSはコンテナ」という棲み分けが、中小企業の現実的な落としどころです。
コンテナ導入のステップ
Step 1：開発環境でDocker導入
開発者のローカルPC、または検証サーバでDockerを導入。最初は学習コストが軽い。
Step 2：社内Webアプリの本番にDocker Compose
「社内勤怠ツール」「社内ポータル」など、小規模アプリの本番環境にDocker Composeを使う。Hyper-V等のVM上のLinuxにDockerを入れる構成が一般的。
Step 3：CI/CDパイプライン整備
GitLab CI、GitHub Actions、Azure DevOps等でビルド・テスト・デプロイを自動化。
Step 4：マネージドKubernetes（必要なら）
アプリ規模が拡大し、可用性・スケーラビリティが必要になったら、AKS / EKS / GKEに移行。ここまで来る中小企業はかなり限定的。
コンテナ導入で陥りやすい失敗
① 「DXだから」とKubernetesから始める。 学習コストが高く、運用負荷も大きい。まずDocker → Docker Compose → 必要ならK8sの順で進めてください。
② コンテナ化したのにバックアップを忘れる。 コンテナ自体は使い捨てだが、永続データ（DB、ファイル）はホストやNAS、クラウドストレージに保存し、別途バックアップが必要。
③ Windowsサーバアプリをコンテナ化しようとする。 Windows Containersは可能だが、運用が複雑で実用性が低い。Windowsアプリは仮想マシンのままが楽。
④ コンテナイメージのセキュリティ管理を怠る。 公式イメージでも脆弱性が含まれることが多い。Trivy等のスキャナーで定期スキャン＋ベースイメージの定期更新を実施。
⑤ docker-compose.ymlを共有せず属人化。 インフラがコード化される利点を活かせない。Gitで管理＋PRレビューを徹底してください。
まとめ
コンテナと仮想マシンは「カーネル共有か独立か」「軽量か重量か」で違いがあり、中小企業の業務基盤の大半は仮想マシン／SaaSのままで十分です。コンテナは「自社開発アプリ・OSS自社ホスティング・開発環境」など、継続的なデプロイと環境統一の価値が高い領域で導入する。Kubernetesは原則として中小企業には過剰で、必要ならマネージドサービス（AKS/EKS/GKE）または**サーバレスコンテナ（Container Apps、Fargate、Cloud Run）**を選んでください。
情シス365のProject365では、コンテナ基盤導入の事前評価から構築・運用支援まで対応しています。無料ヒアリングからお気軽にどうぞ。