【仕組み解説】Dockerはどうやってコンテナを動かしているのか — 仮想化との違いも図解

ひよこ

Dockerってよく聞くけど、コンテナって結局なんなの？仮想マシンとは違うの？

ペンギン先生

いい質問だね。仮想マシンは、ハイパーバイザーが仮想的なハードウェアを用意して、その上にゲストOSを丸ごと載せる仕組みなんだ。一方コンテナは、ホストOSのカーネルを共有しながら、アプリケーションの実行環境だけを隔離する技術だよ。ゲストOSを起動しない分、VMより軽量で、起動も速くなりやすいんだ。ちなみにWindowsやMacのDocker Desktopでは、Linux用のVMの中でコンテナが動いているよ。

ひよこ

カーネルを共有するってことは、完全に分離されてないってこと？それで安全なの？

ペンギン先生

そこで活躍するのがLinuxの「namespace（ネームスペース）」という仕組みだよ。namespaceはプロセスID、ネットワーク、マウントポイント（見えるファイルシステム）、ユーザーIDなどをコンテナごとに分けて見せてくれるんだ。通常はプロセスやネットワークの見える範囲を分けるけれど、namespaceを共有する設定もあるよ。ただ、カーネルを共有している以上、分離はVMほど強くないんだ。Dockerは権限（capabilities）を絞るなどの対策をしているけれど、設定が甘かったりカーネルに脆弱性があったりすると、分離が破られる可能性があるよ。

ひよこ

なるほど！じゃあ、あるコンテナがメモリやCPUを使いすぎて他に迷惑かけたりしないの？

ペンギン先生

制御に使うのが「cgroups（コントロールグループ）」だよ。Dockerは既定ではCPU・メモリの上限を設定しないので、必要な制限を自分で指定するんだ。cgroupsはCPU時間、メモリ使用量、ディスクI/Oなどのリソースをコンテナごとに制限できる仕組みなんだ。たとえば「このコンテナはメモリ512MBまで」と設定すれば、それ以上は使えないし、メモリ不足（OOM）になるとプロセスが強制終了されることもあるよ。namespaceが「見える範囲の隔離」なら、cgroupsは「使える量の制限」と覚えるといいよ。

ひよこ

namespaceとcgroupsの役割分担がわかってきた！でもDockerイメージってどういう構造になってるの？

ペンギン先生

Dockerイメージは「レイヤー（層）」を積み重ねた構造になっているんだ。Dockerfileでは、FROMでベースイメージの層を取り込み、COPYやRUNのようにファイルを変更する命令が新しいレイヤーを作る。LABELのようにメタデータだけを変える命令は、レイヤーを増やさないよ。たとえばベースOSのレイヤー、パッケージインストールのレイヤー、アプリコードのレイヤーという具合だね。イメージのレイヤーは作成後に変更できない読み取り専用で、コンテナ起動時にその上に書き込み用のレイヤーが1枚追加される。この重ね合わせには、OverlayFSなどのユニオン系ファイルシステム（ストレージドライバー）が使われることが多いよ。書き込み用のレイヤーはコンテナを削除すると消えるから、残したいデータはボリュームに置くんだ。

ひよこ

レイヤーが分かれてると何がうれしいの？

ペンギン先生

大きなメリットは2つあるよ。1つ目は「キャッシュ」。Dockerfileを変更してビルドし直すとき、変わっていないレイヤーは再利用されるから、ビルドが高速になる。ただし途中のレイヤーが変わると、それ以降のレイヤーは作り直しになるから、変更が少ない命令ほど上に書くのがコツだよ。2つ目は「共有」。同じベースイメージを使う複数のコンテナがあっても、共通レイヤーはディスク上で1コピーだけ保持されるから、ストレージを節約できるんだ。これがDocker効率のカギだよ。

ひよこ

Dockerって実際にはどういうコンポーネントで動いてるの？docker runしたら裏で何が起きてるの？

ペンギン先生

現代のDockerは、いくつかの部品が連携して動いているよ。まずユーザーが操作する「Docker CLI」、リクエストを受けて管理する「Docker Daemon（dockerd）」、コンテナのライフサイクルを管理する「containerd（コンテナディー）」、そして実際にnamespaceやcgroupsを設定してコンテナプロセスを起動する「runc（ランシー）」だ。docker runを実行すると、CLIがdockerdに指示を送り、containerdがコンテナの実行を管理して、runcがLinuxカーネルの機能を使ってコンテナを立ち上げる流れだね。

ひよこ

containerdとかruncって、Docker専用のものなの？

ペンギン先生

実はそうじゃないんだ。これらはOCIという業界標準に基づいて作られているよ。OCIはコンテナイメージの形式（Image Spec）やランタイムの仕様（Runtime Spec）などを標準化したもので、containerdはOCIのイメージ仕様に対応し、runcはOCIのランタイム仕様を実装したものとして使われているんだ。Kubernetesは、以前はdockershimでDocker Engineと直接つながっていたけれど、1.24で廃止されて、今はCRIに対応したcontainerdやCRI-Oなどのランタイム経由でコンテナを動かすよ。それでも標準化されたイメージ形式のおかげで、Dockerで作ったイメージを動かせる場面が多いんだ。

ひよこ

コンテナ技術って奥が深いんだね…。結局、Dockerがやっていることをまとめるとどうなるの？

ペンギン先生

まとめると、DockerはLinuxカーネルが持つnamespace（隔離）、cgroups（リソース制限）、レイヤー構造のファイルシステムという3つの要素技術を組み合わせて、アプリの実行環境をパッケージングしているんだ。VMのようにOSごと仮想化するのではなく、カーネルを共有することで軽量・高速を実現している。そしてcontainerdやruncといったOCI仕様に対応したコンポーネントが実際の処理を担当しているから、エコシステム全体で互換性を保ちやすくなっているんだよ。コンテナは「魔法」じゃなくて、Linuxの機能を賢く組み合わせた技術だということを覚えておくといいね。

制限は「機能がある」だけでは有効にならない

Dockerコンテナには既定でCPU・メモリの資源制限が設定されていません。cgroupsで制御できても、必要な上限は利用者が設定します。メモリの上限・スワップ・CPUの割当は別の設定で、超過時の終了やスロットリングを含めて検証してください。

再起動と削除ではデータの扱いが違う

「コンテナを再起動すると必ず消える」でも「ボリュームならバックアップ不要」でもありません。保存先と復旧方法をセットで決めます。

この説明の対象

ここでは主にLinuxコンテナを説明しています。WindowsやmacOSでLinuxコンテナを動かす場合、VMのLinuxカーネルを共有します。ホストOSのカーネルをどの構成でも直接共有するわけではありません。CPUアーキテクチャの差についてはPodmanとDockerの比較も参考にしてください。

参考資料

確認日：2026年9月26日。

• Docker Engine security — namespaceによる分離、cgroupsによるリソース制限、権限（capabilities）の制限、カーネルの脆弱性と組み合わさると分離が不完全になりうること。

• Docker Storage drivers — ファイルシステムを変更する命令がレイヤーを作りLABELなどのメタデータ命令は作らないこと、書き込み用レイヤーはコンテナ削除後に残らないこと、Engine 29.0以降の新規インストールはcontainerdイメージストアが既定。

• Understanding image layers — レイヤーは作成後に変更されず、再利用される。

• Docker build cache — レイヤーが変わるとそれ以降のレイヤーも再ビルドされる。

• Resource constraints（Docker Docs） — メモリ・CPUの制限とメモリ不足時のOOM。

• Docker overview — Docker CLIとDocker Daemon（dockerd）の役割。

• Virtual Machine Manager（Docker Desktop） — Docker Desktopではコンテナが動くLinux VMを使う。

• containerd — イメージ転送・保存からコンテナの実行・監視までのライフサイクル管理、OCI Runtime Spec（runC）対応。

• Open Container Initiative Overview — Runtime・Image・Distributionの3仕様。

• Linux namespaces(7) — namespaceの種類（PID、Network、Mount、User、UTSなど）。

• Container Runtimes（Kubernetes Docs） — CRI準拠のランタイム（containerd、CRI-Oなど）が必要で、dockershimは1.24以降に含まれない。

• Docker: Storage：書き込み層とボリューム・マウントの独立性。