コンテナとは

1. はじめに

この記事を作成する背景は、コンテナの説明が「仮想マシンより軽い」という一言にまとめられやすい一方で、イメージとコンテナの違い、ホスト OS との関係、Windows コンテナ固有の互換性が十分に説明されないことです。旧稿には 2021 年当時の Windows 20H2、.NET 5、Alpine Linux 3.14 のイメージサイズが残っており、現在の選定材料としては使えなくなっていました。

この記事の目的は、一般的なコンテナの基礎と Windows コンテナの解説を一つに統合し、2026-08-17 時点の情報へ更新することです。コンテナの構成要素、仮想マシンとの違い、OCI 標準、Linux と Windows の実装差、Windows Server 2025 のベースイメージ、セキュリティ、Docker による実行例を順に整理します。

2. コンテナの構成要素

コンテナは、アプリケーションとその依存関係をイメージとして配布し、ホスト上で分離されたプロセスとして実行する仕組みです。Docker はコンテナを扱う代表的なプラットフォームですが、コンテナという技術そのものと Docker という製品・エコシステムは同義ではありません。

イメージ

コンテナイメージは、コンテナを作るための読み取り専用のひな型です。アプリケーション、ランタイム、ライブラリ、既定のコマンド、環境変数などのメタデータを、複数のレイヤーとして保持します。Dockerfile の各命令からレイヤーを作り、同じレイヤーを複数のイメージやコンテナで再利用できます。[^docker-overview][^oci-overview]

コンテナ

コンテナは、イメージから作成した実行可能なインスタンスです。起動時の引数、環境変数、ネットワーク、ボリュームなどの設定と、書き込み可能な一時レイヤーを持ちます。永続ストレージへ保存していない変更は、コンテナを削除すると失われます。[^docker-overview]

コンテナエンジンとランタイム

コンテナエンジンは、イメージの取得、ビルド、ネットワーク、ストレージ、コンテナのライフサイクルを管理します。Docker Engine では Docker CLI がデーモンへ API リクエストを送り、デーモンがイメージやコンテナを管理します。ランタイムは、その下でイメージから作ったファイルシステムと実行設定を受け取り、コンテナプロセスを起動します。[^docker-overview][^oci-overview]

レジストリ

レジストリはコンテナイメージを保存・配布するサービスです。docker pull はレジストリからイメージを取得し、docker push はイメージを登録します。Docker Hub、Microsoft Container Registry（MCR）、Azure Container Registry などがこの役割を担います。[^docker-overview][^windows-about][^windows-base-images]

次のように流れを分けると、用語を混同しにくくなります。

Dockerfile とソースコードからイメージをビルドする
イメージをレジストリへプッシュする
実行環境がレジストリからイメージをプルする
エンジンとランタイムがイメージからコンテナを作成する
永続化が必要なデータはボリュームや外部サービスへ保存する

3. コンテナと仮想マシンの違い

仮想マシンはゲスト OS のカーネルまで持ちます。通常のプロセス分離コンテナはホストのカーネルを共有し、アプリケーションに必要なユーザーモードのファイルだけをイメージへ含めます。[^containers-vm][^windows-about]

観点	コンテナ	仮想マシン
OS カーネル	通常はホストと共有	ゲストごとに保持
起動単位	分離されたプロセス	完全なゲスト OS
起動・停止	一般に高速	OS 起動を伴うため一般に時間がかかる
CPU・メモリ・ストレージ	OS 全体を持たないため比較的少ない	ゲスト OS 分のリソースが必要
OS の自由度	ホストと互換性のあるカーネル・API が必要	異なるゲスト OS を選びやすい
セキュリティ境界	軽量な分離。共有カーネルを前提に追加対策が必要	ハイパーバイザーによる、より強い分離
更新方法	ベースイメージを更新して再ビルド・再デプロイ	ゲスト OS ごとに更新、または VM イメージを更新
主な適性	アプリ配布、CI/CD、水平スケール、短命なワークロード	強い分離、異種 OS、既存システム全体の移行

両者は競合するだけの技術ではありません。クラウドでは、仮想マシンをコンテナホストとして使い、その上で複数のコンテナを動かす構成が一般的です。強いインフラ分離と、アプリケーション単位の配布・更新を両立できます。

4. OCI 標準と「どこでも動く」の境界

Open Container Initiative（OCI）は、コンテナの相互運用性を高めるために、次の 3 仕様を管理しています。[^oci-overview]

仕様	標準化する対象
Image Specification	イメージのマニフェスト、設定、ファイルシステムレイヤー
Runtime Specification	展開したバンドルをコンテナとして実行する方法
Distribution Specification	レジストリとの間でコンテンツを配布する API

OCI によってイメージ形式や実行手順の共通化は進みましたが、「どのイメージも、どのホストでも動く」という意味ではありません。少なくとも次の条件を合わせる必要があります。

CPU アーキテクチャ（amd64、arm64 など）
OS カーネルの種類（Linux または Windows）
必要なシステムコールや OS API
Windows コンテナではホストとイメージのバージョン互換性

Linux ディストリビューションが異なるイメージを同じ Linux ホストで動かせるのは、イメージがユーザー空間のファイルを持ち、ホストの Linux カーネルを利用するためです。一方、Windows イメージは Windows カーネルと API を必要とします。Windows PC 上で Docker Desktop の Linux コンテナを実行する場合も、WSL 2 バックエンドなどが Linux カーネルを提供しています。OS の境界が消えたわけではありません。[^docker-wsl]

5. コンテナの利点と注意点

主な利点

再現性: イメージと起動設定を固定し、開発・テスト・本番の差を減らせる
配布のしやすさ: アプリケーションと依存関係を一つの単位としてレジストリ経由で配布できる
起動の速さ: OS 全体を起動せず、必要なプロセスを開始できる
集積率: 同じホスト上で複数のワークロードを比較的少ないオーバーヘッドで実行できる
更新とロールバック: 不変のイメージを差し替える運用により、版を追跡しやすい

主な注意点

永続データ: コンテナの一時レイヤーと、ボリュームや外部データベースを分離して設計する必要がある
ネットワークと監視: コンテナの増減を前提に、サービス検出、ログ、メトリクス、トレースを設計する必要がある
互換性: OS、CPU、ドライバー、カーネル機能への依存は残る
イメージ管理: ベースイメージの脆弱性対応、再ビルド、署名・スキャン、廃止タグの管理が必要になる
セキュリティ: 分離は提供されるが、設定ミスや共有カーネルのリスクがなくなるわけではない

向くユースケース

Web API、バックグラウンドワーカー、バッチ処理
マイクロサービスやイベント駆動のアプリケーション
CI/CD のビルド・テスト環境
同じ成果物を複数環境へ展開したいアプリケーション
既存の Windows サービスや IIS アプリを段階的に近代化する場合

慎重な検討が必要なユースケース

デスクトップ UI や対話的なログインセッションを前提とするアプリケーション
特定のハードウェア、カーネルモジュール、ホスト設定へ強く依存する処理
永続データ、バックアップ、障害復旧の設計なしにデータベースを載せる場合
信頼できない複数テナントを、プロセス分離だけで同じカーネル上へ載せる場合
変更頻度が低く、既存 VM のままで運用上の問題がないシステム

6. Linux コンテナと Windows コンテナ

どちらを選ぶかは、開発 PC の OS ではなく、アプリケーションが必要とするランタイムと OS API で決めます。

観点	Linux コンテナ	Windows コンテナ
主な用途	Linux 向けアプリ、クロスプラットフォーム対応ランタイム	Windows API、.NET Framework、IIS、Windows サービス
分離の基盤	namespaces と cgroups	Windows の名前空間・リソース制御、または Hyper-V
カーネル	通常は Linux ホストと共有	プロセス分離では Windows ホストと共有
ベースイメージ	Debian、Ubuntu、Alpine など多数	Nano Server、Server Core、Windows Server など
イメージ選定	必要な libc、パッケージ、サポート期間、サイズを比較	必要な Windows API、ホスト互換性、LTSC を比較
オーケストレーション	Kubernetes の標準的な機能を広く利用可能	Kubernetes では Windows 固有の制約を確認

Linux では namespaces がプロセス、ネットワーク、マウントなどの見え方を分離し、cgroups が CPU、メモリ、I/O などを計測・制限します。Docker Engine もこれらを利用してコンテナを分離します。[^docker-security]

Windows コンテナには、次の 2 つの分離モードがあります。どちらも同じイメージを使用できます。[^windows-isolation]

プロセス分離

コンテナはホストおよび他のコンテナと Windows カーネルを共有します。ファイルシステム、レジストリ、ネットワークポート、プロセス ID 空間などを分離します。Windows Server での標準的な実行方式で、オーバーヘッドを抑えられます。

Hyper-V 分離

各コンテナを最適化された軽量仮想マシン内で実行し、専用カーネルを持たせます。プロセス分離より強いセキュリティ境界を提供し、ホストとイメージのバージョン差にも対応しやすくなります。その代わり、プロセス分離より多くのリソースと起動時間を必要とします。

7. Windows Server 2025 のベースイメージ

Microsoft のドキュメントでは Windows のベースイメージを 4 系統に分類しています。ただし、2026-08-17 時点で各 Windows Server 世代に同じ系統が提供されているわけではありません。[^windows-base-images]

ベースイメージ	主な用途	Windows Server 2025 での選定
Nano Server	現行 .NET（旧 .NET Core 系）など、必要 API が少ない新規アプリ	`nanoserver:ltsc2025`
Windows Server Core	.NET Framework、IIS、既存 Windows Server アプリ	`servercore:ltsc2025`
Windows Server	広い Windows API、追加のサーバー機能、GPU が必要な処理	`server:ltsc2025`
Windows	Windows API を広く含む旧来の大規模イメージ	Windows Server 2025 版なし

実際のイメージは MCR から取得します。

text

mcr.microsoft.com/windows/nanoserver:ltsc2025
mcr.microsoft.com/windows/servercore:ltsc2025
mcr.microsoft.com/windows/server:ltsc2025

Windows イメージは Windows Server 2022 向けにビルドされておらず、Windows Server 2025 でも利用できません。Docker Hub の現行リポジトリで案内される安定タグは ltsc2019 です。新規の Windows Server 2025 ワークロードでは、Windows Server、Windows Server Core、Nano Server から必要な API に合うものを選びます。[^windows-image-repo][^windows-server-repo]

選択の目安は次のとおりです。

クロスプラットフォーム対応のアプリなら、まず Linux イメージを利用できるか確認する
Windows が必要で、現行 .NET と限定的な Windows API で動くなら Nano Server を検討する
.NET Framework、IIS、既存の Windows Server API が必要なら Windows Server Core を検討する
Server Core にない API、サーバー機能、GPU が必要なら Windows Server を検討する
実際の依存関係をコンテナ上でテストし、必要以上に大きいイメージを選ばない

古い記事にあった 20H2、.NET 5、Alpine Linux 3.14 のサイズ比較は、タグもサイズも現在の選定には使えません。イメージサイズは更新や圧縮状態で変化するため、利用するタグを docker pull したうえで docker image ls やレジストリの情報から比較してください。

8. Windows コンテナの互換性と運用

Windows はユーザーモードとカーネルモードの結合が Linux より強く、ホスト OS とコンテナイメージのバージョン互換性が重要です。Microsoft は Windows Server 2025、2022、2019、2016 と Windows 11 の組み合わせごとに、プロセス分離と Hyper-V 分離の互換表を公開しています。[^windows-compatibility]

安全側の運用方針は次のとおりです。

ホストと同じ Windows Server 世代の LTSC タグを既定にする
異なる世代を組み合わせる場合は、公式互換表を確認する
互換表でプロセス分離が認められない組み合わせは Hyper-V 分離を検討する
ホストとベースイメージの双方へ最新のセキュリティ更新を適用する
ベースイメージ更新時はアプリケーションイメージを再ビルドし、テストして再デプロイする
latest に依存せず、ltsc2025 など意図した OS 世代をタグで明示する

Windows Server 2025 ホストでは、Windows Server 2025 と 2022 のイメージをプロセス分離で実行できる組み合わせが公式表に掲載されています。Windows 11 では Windows Server 2022 イメージがサポートされ、Windows Server 2025 イメージのサポートは Windows 11 24H2 以降です。一方、古い世代を含む組み合わせには制約があるため、「新しい Windows なら古い Windows イメージが必ず動く」とは判断しないでください。[^windows-compatibility]

Windows Server のコンテナ向けベースイメージには LTSC と Annual Channel があり、サポート期間と更新方針が異なります。本稿の例では長期運用を想定して LTSC 2025 を使用します。採用時にはベースイメージのライフサイクルを確認してください。[^windows-lifecycle]

Kubernetes で Windows コンテナを運用する場合、現行ドキュメントは Windows Server 2022 または Windows Server 2025 のワーカーノードをサポート対象としています。コントロールプレーンは Linux 上で動かし、同じ Pod に Linux コンテナと Windows コンテナを混在させることはできません。また、Kubernetes の Windows コンテナはプロセス分離が前提で、Hyper-V 分離には対応していません。[^windows-kubernetes]

9. コンテナのセキュリティ

コンテナは分離機構を提供しますが、それだけでアプリケーションが安全になるわけではありません。Microsoft は、プロセス分離の Windows コンテナと Linux コンテナが共有するカーネルを、信頼できないマルチテナント環境の強固なセキュリティ境界とは見なしていません。Windows で強い境界が必要な場合は Hyper-V 分離、または専用の仮想マシンを使用します。[^windows-security]

実装と運用では、少なくとも次を確認します。

コンテナを root、ContainerAdministrator などの管理者権限で常用しない
Windows では可能な限り ContainerUser を使用する
必要のない Linux capabilities、デバイス、ホストパスを渡さない
Docker ソケットやコンテナエンジンの API をアプリケーションへ公開しない
信頼できる配布元のベースイメージを使い、ダイジェストや署名を検証する
イメージを継続的にスキャンし、ベースイメージ更新時に再ビルドする
パスワード、API キー、証明書をイメージへ埋め込まない
書き込み可能な領域とネットワーク公開範囲を必要最小限にする

特に、ホストディレクトリのマウントや Docker デーモンへのアクセスは、コンテナからホストを変更できる経路になり得ます。分離機能だけに頼らず、権限、構成、イメージ供給網、ホストの更新を一体として管理します。[^docker-security]

10. Docker でコンテナを実行する

Linux コンテナで NGINX を実行する

Docker が Linux コンテナを実行できる状態で、次のコマンドを実行します。Docker Official Image の nginx:alpine を取得し、ホストの 8080 番ポートをコンテナの 80 番ポートへ割り当てます。[^nginx-image]

bash

docker run --rm --name demo-nginx -d -p 8080:80 nginx:alpine
curl http://localhost:8080
docker stop demo-nginx

--rm を指定しているため、docker stop で停止したコンテナは自動的に削除されます。イメージはローカルに残るので、不要なら docker image rm nginx:alpine で削除できます。

Windows Server 2025 で Nano Server を実行する

Windows コンテナへ切り替えた、互換性のある Windows Server 2025 または Windows 11 環境で実行します。

powershell

docker pull mcr.microsoft.com/windows/nanoserver:ltsc2025
docker run --rm -it mcr.microsoft.com/windows/nanoserver:ltsc2025 cmd.exe

コンテナ内で ver を実行すると Windows のバージョンを確認でき、exit で終了できます。ホストとの組み合わせがプロセス分離に対応しない場合は、Hyper-V を有効にしたうえで --isolation=hyperv を指定します。

powershell

docker run --rm -it --isolation=hyperv mcr.microsoft.com/windows/nanoserver:ltsc2025 cmd.exe

Microsoft の入門手順では Nano Server のプル、Windows コンテナへの切り替え、対話実行の流れを確認できます。実際のアプリケーションイメージは、実行中コンテナを手作業で変更するのではなく、Dockerfile とソースコードから再現可能な形でビルドしてください。[^windows-first-container]

11. まとめ

コンテナは、アプリケーションと依存関係をイメージとして配布し、分離されたプロセスとして実行する仕組みです。仮想マシンより軽量に扱いやすい一方、通常はホストのカーネルを共有するため、OS・CPU・API の互換性とセキュリティ境界を理解する必要があります。

Linux コンテナと Windows コンテナは、アプリケーションが必要とする OS API から選びます。Windows Server 2025 では Nano Server、Windows Server Core、Windows Server の ltsc2025 を中心に、必要な API とホスト互換性から決定します。旧来の Windows イメージや 20H2 のサイズ比較を、そのまま新規設計へ使ってはいけません。

コンテナ化の成否は、イメージを作ることだけでは決まりません。永続データ、ネットワーク、監視、更新、権限、脆弱性対応まで含め、再ビルドと再デプロイを継続できる運用として設計することが重要です。

12. 参考情報

What is Docker? — Docker の構成要素と基本概念
Open Container Initiative — Image、Runtime、Distribution の各仕様
Containers vs. virtual machines — コンテナと仮想マシンの比較
About Windows containers — Windows コンテナの構造と用途
Overview of Windows Container Base Images — Windows ベースイメージの選択
Windows container version compatibility — ホストとイメージの互換表

[^containers-vm]: Containers vs. virtual machines — Microsoft Learn（確認日: 2026-08-17）

[^docker-overview]: What is Docker? — Docker Docs（確認日: 2026-08-17）

[^docker-wsl]: Docker Desktop WSL 2 backend on Windows — Docker Docs（確認日: 2026-08-17）

[^oci-overview]: Open Container Initiative — Open Container Initiative（確認日: 2026-08-17）

[^windows-about]: About Windows containers — Microsoft Learn（確認日: 2026-08-17）

[^windows-base-images]: Overview of Windows Container Base Images — Microsoft Learn（確認日: 2026-08-17）

[^windows-image-repo]: microsoft/windows — Microsoft（確認日: 2026-08-17）

[^windows-server-repo]: microsoft/windows-server — Microsoft（確認日: 2026-08-17）

[^windows-isolation]: Isolation modes — Microsoft Learn（確認日: 2026-08-17）

[^windows-compatibility]: Windows container version compatibility — Microsoft Learn（確認日: 2026-08-17）

[^windows-lifecycle]: Base image servicing lifecycles — Microsoft Learn（確認日: 2026-08-17）

[^windows-kubernetes]: Windows containers in Kubernetes — Kubernetes Documentation（確認日: 2026-08-17）

[^windows-security]: Secure Windows containers — Microsoft Learn（確認日: 2026-08-17）

[^docker-security]: Docker Engine security — Docker Docs（確認日: 2026-08-17）

[^nginx-image]: nginx — Docker Official Image（確認日: 2026-08-17）

[^windows-first-container]: Run Your First Windows Container — Microsoft Learn（確認日: 2026-08-17）