コンテナは、ソフトウェアに何をするのか

ソフトウェアを自分のパソコンで開発して正常に動作したとしても、本番サーバーに配置した途端に動かなくなるトラブルは、長年開発者を悩ませてきました。その主な原因は、実行環境ごとに異なるOSの設定、導入されているライブラリのバージョン、実行権限の違いといった「環境の差異」にあります。

コンテナ（Container）は、この課題を解決するために普及した技術です。コンテナは、アプリケーション本体と動作に必要な部品（ライブラリや設定ファイルなど）をひとまとめにし、独立した「隔離されたプロセス」として実行します。しかし、コンテナは環境の違いを魔法のように完全に消し去るわけではありません。本稿では、コンテナがソフトウェアに対して「何を持ち込み、何を持ち込まないのか」、そしてOSの中でどのように隔離されているのかを、基本構造と動作条件から分かりやすく紐解きます。

コンテナの正体：何を持ち運び、何を持ち運ばないのか

コンテナの役割を一言で表せば、「ソフトウェアとその実行環境をひとまとめにして運べるようにすること」です。しかし、「パソコンのOS全体を丸ごと箱に詰めて持ち運んでいる」と捉えると、その実態を見誤ってしまいます。

コンテナを理解する基本は、「ひな型」と「そのひな型から作られた環境」という関係です。ひな型を「コンテナイメージ」、ひな型をもとに作成され実際に稼働する環境を「コンテナ」と呼びます。コンテナは単にメモリ上で実行されているプロセスという瞬間的な状態だけを指すのではなく、作成、起動、一時停止、破棄という一連のライフサイクルを持った実行環境です。

ひな型であるコンテナイメージには、アプリケーションの実行に必要なファイル群が収められています。どのような部品が必要かは、開発言語や設計によって異なります。たとえばPythonやNode.jsで作られたアプリケーションであれば、言語のランタイムや標準ライブラリ、外部パッケージなどの依存ファイルが必要です。一方、Go言語やRustなどで静的リンクされた単一の実行可能バイナリとして作成されたプログラムであれば、OS由来の共有ライブラリすらほとんど必要としない場合もあります。コンテナは、対象ソフトウェアの特性に応じて必要な部品だけをパッケージ化します。

コンテナイメージを構築する際、多くの場合「Ubuntu」や「Alpine Linux」といったOS名が付いたベースイメージが利用されます。重要なのは、これらのベースイメージにはOSの中核である「カーネル」は含まれていない点です。ベースOS層の実体は、シェルや標準Cライブラリ、パッケージマネージャといった、OSの「ユーザー空間」で動作するファイル群の集まりに過ぎません。

コンテナは自分専用のOSカーネルを持たず、下敷きとなるホスト環境のLinuxカーネルを直接共有して動作します。ここでいうホスト環境とは、物理的なベアマシンだけでなく、クラウド事業者が提供する仮想マシン（VM）である場合も含みます。また、WindowsやmacOS上でDockerなどのコンテナ技術を利用する場合、WindowsやmacOSのカーネル上でLinuxコンテナが直接動作しているわけではありません。これらの環境では、OS上で動作する軽量なLinux仮想マシン（WSL2やHyper-V、macOSの仮想化フレームワークなど）が裏で起動しており、コンテナはその仮想マシン内のLinuxカーネルを共有して動作しています。

このように、コンテナはアプリケーションと依存部品をひとまとめにすることで環境の差異を大幅に減らしますが、環境差を「ゼロにする」わけではありません。動作マシンのCPUアーキテクチャ（Intel系かARM系か）、ホストが提供するLinuxカーネルのバージョンや有効化されている機能、実行時のシステム権限、ストレージの保存先パスなど、依然としてホスト環境に依存する条件は残されています。

仮想マシン（VM）との構造的違い：ゲストOSの有無と共有境界

コンテナの仕組みを理解するには、従来から使われてきた「仮想マシン（Virtual Machine: VM）」との構造的な違いを比較するのが効果的です。

上記の構造説明図は、Linuxコンテナがホストカーネルを直接共有するOSレベル仮想化の境界線と、仮想マシン（VM）がハイパーバイザーを介して独立したゲストOS（専用カーネル）を走らせるハードウェア仮想化の境界線の違いを対比するものです。この図を見る際、固定的な起動時間（数ミリ秒 vs 数分）やメモリ消費量（数MB vs 数GB）といった裏付けのない数値をスペックとして固定視しないことが重要です。現代のクラウド環境では、1台のVMの中で複数のコンテナを運用する構成も広く使われています。

仮想マシンは「ハードウェア仮想化」と呼ばれるアプローチをとります。物理マシンの上で「ハイパーバイザー」というソフトウェアが動作し、CPU、メモリ、ストレージ、ネットワークカードといったハードウェアそのものをソフトウェア的にエミュレート（模倣）します。仮想マシンの中には、本物のコンピューターと同じように専用の「ゲストOS」が丸ごとインストールされます。そのため仮想マシンを起動する際は、ゲストOSのカーネルが立ち上がり、仮想ハードウェアのデバイスドライバを読み込み、各種システムサービスを起動するという、PCの電源を入れたときと同じ一連のブート処理が行われます。

これに対してコンテナは「OSレベル仮想化」と呼ばれるアプローチをとります。コンテナはハードウェアをエミュレートするのではなく、ホストOSのカーネル自身が備えている隔離機能を利用します。コンテナを起動する際には新しいゲストOSのカーネルを立ち上げる必要がありません。ホストカーネルから見れば、コンテナ内で動作するアプリケーションは、特別な隔離設定を与えられた「通常のプロセス」として直接実行・スケジュールされます。「コンテナは仮想化の負荷が全く存在しない」と表現されることがありますが、より正確には「コンテナごとに新しいゲストOSを丸ごと起動・常駐させるオーバーヘッドが存在しない」と捉えるのが適切です。

この構造差は、運用の柔軟性にも大きく影響します。仮想マシンは完全な独立性を持つ反面、OS全体の管理やリソース消費を伴います。一方のコンテナはホストカーネルを共有するため、極めて素早くプロセスとして起動できます。

現在普及しているLinuxコンテナの実行環境は、オープンな業界標準である「OCI（Open Container Initiative）Runtime Specification」によって規定されています。コンテナランタイムはこの仕様に基づき、カーネルの標準機能を呼び出して隔離された実行空間を組み立てています（本稿における仕様の整理は、特定のリリースタグではなく執筆時点の最新草案であるmainブランチのruntime.mdおよびconfig-linux.mdに基づいています）。

見せかけの独立性：Linuxカーネルが作る「壁」の正体

コンテナ内で動くソフトウェアから見ると、まるで自分自身が独立したコンピューターを独占しているかのように見えます。プロセスIDは1から始まり、専用のネットワークポートを持ち、独立したルートディレクトリが存在します。しかしホスト上には1つのLinuxカーネルしか存在しません。カーネルはどのようにしてこの「見せかけの独立性」を作り出しているのでしょうか。

その正体は、Linuxカーネルに標準で組み込まれている2つの機能、「Namespaces（名前空間）」と「cgroups（コントロールグループ）」です。

1. Namespaces：プロセスの「視界」を制限する

Namespacesは、プロセスが見ることのできるシステム資源の範囲（視界）を区切る機能です。対応する名前空間を分離した構成において、プロセスは自分と同じ名前空間に属するリソースしか見ることができなくなります。Linuxカーネルには複数のNamespacesが存在します。

• PID（プロセスID）名前空間：プロセスの番号体系を分離します。コンテナ内のプロセスからは自身が「PID 1」として見えます。このPID 1は、コンテナ内で最初に起動されたメインアプリケーションまたはコンテナ用初期化プロセスであり、コンテナ全体のライフサイクルの起点となります。一方、ホストOSのカーネル側から同じプロセスツリーを見れば、そのプロセスにはホスト全体で一意の通常番号（PID 12345など）が割り振られています。
• ネットワーク（NET）名前空間：仮想的なネットワークインターフェース、IPアドレス、ルーティングテーブル、ポート番号の空間を分離します。これにより、ホスト上でポート80が使用されていても、コンテナ内では独立してポート80をリッスンできます。
• マウント（MNT）名前空間：ファイルシステムの階層構造を分離します。コンテナ内のプロセスには、指定されたコンテナイメージの内容がルートディレクトリ（/）として見え、ホストOS上の他のファイルは見えなくなります。
• IPC、UTS、User名前空間：プロセス間通信の隔離（IPC）、ホスト名やドメイン名の分離（UTS）、ユーザーIDやグループIDのマッピング分離（User）を担います。

ただし、これらの壁は常に密閉されているわけではありません。設定によって、あえてホストの名前空間を共有することも可能です。たとえばホストネットワーク設定（--net=host）を使用すればコンテナはホストと同じネットワーク空間を共有しますし、バインドマウント機能を使えばホスト上の特定ディレクトリをそのままコンテナ内から直接読み書きできるように設定できます。

2. cgroups：プロセスの「資源」を制御する

Namespacesが「何が見えるか」を制限するのに対し、cgroups（特にモダンなLinuxで標準となっているcgroups v2）は「資源をどれだけ使えるか」を制御します。1つのコンテナがホストマシンのCPUやメモリを使い果たし、システム全体が停止してしまうのを防ぐ防波堤の役割を果たします。

ただし、cgroupsによる資源制御には注意すべき重要な条件があります。

まず、cgroupsによる制限はコンテナ起動時の設定に依存する点です。既定ですべての資源制限が有効になっているとは限らず、上限値を指定せずにコンテナを起動した場合、そのコンテナはホストマシンのCPUやメモリを制限なく消費できてしまいます。

次に、CPUの制限方式です。cgroupsにおけるCPU制限は、「特定のCPUコアを1つ専有させる」割り当てではなく、一般に単位時間（たとえば100ミリ秒周期）の中でプロセスグループがCPUを使用できる「時間の上限（クォータ）」を配分する形で制御されます。

さらに、メモリ制限の挙動です。cgroups v2でコンテナにメモリ上限を設定した場合、使用量がその上限値に達したからといって、即座にプロセスが強制終了されるわけではありません。Linuxカーネルはまず、ページキャッシュの解放などメモリの回収（リクレイム）を試行します。回収を行ってもなおメモリが不足し、上限超過の状態が解消できない場合に初めて、「OOM（Out of Memory）キラー」と呼ばれる機構が呼び出され、コンテナ内のプロセスを強制終了させます。

セキュリティ境界の実態：カーネル共有と多層防御

「コンテナは仮想マシンのように隔離されているのだから、セキュリティの強さも仮想マシンと同じだろう」と考えるのは危険な誤解です。カーネルを共有している構造は、セキュリティ境界の性質にも決定的な違いをもたらします。

仮想マシンの場合、ハイパーバイザーによるハードウェアレベルの分離が存在します。仮に仮想マシン内のゲストOSがマルウェアに感染し、そのカーネル権限が完全に奪取されたとしても、ハイパーバイザー自体の脆弱性を突いて脱出（VMエスケープ）しない限り、ホストOSや他の仮想マシンに影響を及ぼすことは極めて困難です。

一方、コンテナは単一のホストカーネルをすべてのコンテナが共有しています。Namespacesやcgroupsによって論理的な壁が築かれているとはいえ、システムコールの処理を行うのは同じ1つのカーネルです。もしホストのLinuxカーネル自体に権限昇格や境界突破が可能な脆弱性が存在した場合、コンテナ内の悪意あるプロセスがカーネルを攻撃し、コンテナの外側にあるホスト全体を乗っ取ってしまうリスクが構造的に残されています。

特に危険なのが、コンテナを「特権モード（--privileged）」で実行することです。特権モードで起動されたコンテナは、Linuxカーネルが提供する各種ケーパビリティ制限が無効化され、ホスト上の主要なデバイスファイルへのアクセスが許可されます。この状態のコンテナは実質的にホストOS上でroot権限を持って直接作業しているのと同等になり、コンテナによるセキュリティ隔離は完全に形骸化します。

したがって、「コンテナを使っているから安全」「仮想マシンだから絶対安全」という単純な二者択一ではなく、権限や設定に応じた「多層防御（Defense in Depth）」を講じることが不可欠です。具体的な対策として、以下の原則が推奨されます。

• 非rootユーザーでの実行：コンテナ内のアプリケーションを安易にroot（管理者）権限で動かさず、専用の一般ユーザーを作成してその権限で実行する。
• ケーパビリティの最小化：Linuxカーネルは強大なroot権限を「ケーパビリティ（Capabilities）」という細かい権限群に分割して管理しています。コンテナ実行時は、不要なケーパビリティ（ネットワーク管理者権限やシステム時刻変更権限など）をできる限り剥奪（drop）して実行する。
• User名前空間の適用：コンテナ内でのrootユーザー（UID 0）を、ホストOS上では権限を持たない一般ユーザー（UID 10000など）に対応付ける。これにより、仮にコンテナ内でroot権限を奪われても、ホスト環境に対しては特権を行使できなくなります。
• ルートレスコンテナの活用：コンテナを実行・管理するデーモン自体をroot権限なしで動作させる「ルートレス（Rootless）コンテナ」を採用する。
• システムコールの制限：seccomp（Secure Computing Mode）やAppArmor、SELinuxなどのセキュリティ機構を併用し、コンテナがカーネルに対して発行できるシステムコールを必要最小限に制限する。

イメージの仕組みとデータの行方：レイヤー構造と永続化の原則

ソフトウェアをコンテナで動かす際、作成したファイルや書き換えたデータがどこへ行き、どのように保存されるのかを理解しておくことは、システム設計において極めて重要です。ここには、コンテナ特有の「レイヤー構造」と「Copy-on-Write（CoW）」という仕組みが深く関わっています。

読み取り専用レイヤーと書き込み可能レイヤー

コンテナイメージは、一枚の巨大なファイルディスクではなく、複数の「読み取り専用（Read-Only）レイヤー」が積み重なった多層構造になっています。

たとえば、最下層にベースOSのファイル群があり、その上にWebサーバーをインストールしたレイヤーが重なり、最上位に自作のプログラムファイルを配置したレイヤーが重なる、といった具合です。これらのレイヤーは一度作成されたら内容が変更されることはなく、複数のコンテナ間でディスク容量を無駄にすることなく共有されます。

コンテナを新しく起動すると、この積み重ねられた読み取り専用レイヤーの真上に、薄い「書き込み可能レイヤー（コンテナ層）」が1枚だけ追加されます。コンテナ内で動作するソフトウェアが行うすべての書き込み、ファイルの新規作成、既存ファイルの編集は、この最上位の書き込み可能レイヤーに対して行われます。

既存のファイルを変更しようとする場合、下位にある読み取り専用レイヤーのファイルを直接書き換えることはできません。カーネルのストレージドライバ（OverlayFSなど）は、下位レイヤーから目的のファイルを最上位の書き込み可能レイヤーへと丸ごとコピーし、そのコピーされたファイルに対して変更を加えます。これが「Copy-on-Write（書き込み時コピー）」と呼ばれる仕組みです。

停止・再起動と削除・再作成の決定的な違い

この書き込み可能レイヤーの存在により、コンテナのライフサイクルにおけるデータの挙動には明確な境界線が生じます。

• コンテナの停止と再起動：コンテナのプロセスを一度停止（stop）させ、後から再び起動（start）した場合、最上位の書き込み可能レイヤーは破棄されずそのまま保持されます。したがって、停止前に作成・変更したファイルは消えずに残っています。
• コンテナの削除と再作成：コンテナを破棄（rm）した場合、そのコンテナに紐づいていた書き込み可能レイヤーは完全に削除されます。同じイメージから新しくコンテナを作り直したとしても、以前のコンテナで行った変更は一切引き継がれません。新しく起動したコンテナには、まっさらな書き込み可能レイヤーが1枚添えられるだけです。

ボリュームによるデータ分離の原則

時折、「コンテナはデータを保持できないため、ステートレスな（状態を持たない）Webサーバーしか動かせない」と説明されることがありますが、これは正確ではありません。データベースのような状態を持つアプリケーションであっても、コンテナ上で日常的に運用されています。

コンテナ運用の本質は、「アプリケーション本体（コンテナ）をいつでも安全に破棄し、新しいバージョンに入れ替えられるようにすること」にあります。そのため、長期的に保持すべき重要なデータ（データベースのデータファイル、ユーザーのアップロードファイル、ログなど）は、コンテナ内部の書き込み可能レイヤーに保存してはいけません。

コンテナの外側に独立した保存領域を用意し、そこへデータを逃がす設計をとります。代表的な仕組みが「ボリューム（Volume）」です。ボリュームを利用すると、ホストマシン上の特定ストレージ領域がコンテナ内のディレクトリに直接マウントされます。ボリュームへの書き込みはCopy-on-Writeの管理下から外れ、コンテナが停止・削除されてもボリューム内のデータはそのまま残ります。

ただし、ボリュームを使用しているからといって、データが永久に安全だと過信してはなりません。ボリューム自体も、物理的なハードウェア故障や、運用者が誤ってボリューム削除コマンドを実行してしまうといった事故から自動的に守られているわけではありません。バックアップの取得やストレージの冗長化といった通常のデータ保全策は、コンテナを採用した場合でも変わらず必要です。

移植性とマルチアーキテクチャの真実：どこまでが「そのまま動く」のか

「コンテナを使えば、一度ビルドしたイメージがどんなマシンでもそのまま動く」という表現は、コンテナの大きな魅力として語られます。しかし、これも文字通りの万能性を意味しているわけではありません。

CPUアーキテクチャの壁

ソフトウェアをコンパイルして生成された実行可能バイナリは、CPUが理解できる機械語の命令セットに直接縛られています。IntelやAMDのプロセッサで広く使われている「x86_64」アーキテクチャ向けにコンパイルされたバイナリは、スマートフォンのほか近年のMac（Apple Silicon）やクラウドの省電力サーバー（AWS Gravitonなど）で採用されている「ARM64」アーキテクチャのCPU上では、そのままでは実行できません。

コンテナはOSカーネルを共有するプロセス隔離技術であり、CPUの命令体系を根本から変えるものではないため、x86_64用に作られたコンテナイメージをARM64の物理マシン上で直接そのまま走らせることは原理的に不可能です。

マルチアーキテクチャイメージの仕組み

ではなぜ、手元のMacでビルドしたコンテナが本番のIntel系サーバーでも動いたり、公式イメージをどちらの環境でも同じ名前で起動できたりするのでしょうか。

その裏側を支えているのが「マルチアーキテクチャビルド」という仕組みです。これは「1つの共通バイナリがどこでも動いている」のではありません。開発元が、x86_64用とARM64用のそれぞれ異なるバイナリを含んだ複数のイメージを個別にビルドし、それらを「マニフェストリスト（OCI Image Index）」という目録ファイルで1つのイメージ名に束ねて公開しているのです。

コンテナ実行環境がイメージをダウンロードする際、その目録を参照し、自身が動作しているマシンのCPUアーキテクチャに適合するイメージ層だけを自動的に選択して取得しています。

エミュレーションによる実行とその限界

もし手元に異なるCPU向けのイメージしか存在しない場合でも、QEMUなどのエミュレータを組み合わせることで、命令をソフトウェア的に変換しながら異種アーキテクチャのコンテナを動かすことは可能です。たとえば、ARM64のMac上でx86_64向けのコンテナを実行できます。

しかし、エミュレーション処理には相応のオーバーヘッドが伴います。処理速度の低下の度合いは、実行するプログラムの特性（CPUの計算集約型か、I/O待ちが多いかなど）によって大きく異なりますが、ネイティブ実行に比べて大幅にパフォーマンスが落ちる場合があります。

マルチアーキテクチャ対応はすべてのソフトウェア開発において絶対不可欠とまでは言えない場合もありますが、開発者のPC環境とサーバー環境のアーキテクチャが異なることが一般的となった現代において、極めて有用な技術として広く定着しています。

コンテナ技術を巡る3つの疑問（FAQ）

Q1: コンテナを導入すれば、OSやミドルウェアのセキュリティ更新作業は不要になりますか？

不要にはなりません。コンテナイメージ内に含まれる共有ライブラリやパッケージに脆弱性が発見された場合は、修正されたパッケージを含むベースイメージを取り込んでイメージを再ビルドし、コンテナを再デプロイする必要があります。また、すべてのコンテナが共有しているホストOSのカーネル自体に脆弱性が見つかった場合も、ホストOS側の更新と再起動が不可欠です。コンテナの導入によって更新手順の自動化や迅速化は図れますが、更新管理そのものが不要になるわけではありません。

Q2: 開発環境（MacやWindows）で動作したコンテナが、本番のLinuxサーバーで動かないことはありますか？

起こり得ます。原因として、まずCPUアーキテクチャの違い（ローカルのARM64と本番のx86_64など）が挙げられます。また、ホストマシンのディレクトリをバインドマウントしている場合、ファイルパスの区切り文字やファイル名の大文字・小文字の扱い、パーミッション（ファイル権限）の差異によって本番環境でのみエラーが発生することがあります。さらに、ホスト側のLinuxカーネル設定（ネットワークパラメータやカーネルモジュールの有無など）の違いによって挙動が変わるケースもあります。

Q3: コンテナの中でさらにコンテナを動かす構成（Docker in Docker）は推奨されますか？

一般的な業務アプリケーションの構成としては推奨されません。CI/CDパイプラインにおいてテスト用にコンテナをビルド・実行するといった特殊な用途では利用されますが、コンテナの中でコンテナを動かすためには特権モード（--privileged）の付与が必要になることが多く、セキュリティリスクが高まります。また、ファイルシステム（ストレージドライバ）が二重化されることで競合やパフォーマンス劣化を引き起こしやすいため、慎重な検討が必要です。

結び

コンテナがソフトウェアに対して行う本質的な役割は、「OSそのものを丸ごと複製すること」ではありません。「ホストが提供するOSカーネルを巧みに共有しながら、アプリケーションが動作するために必要な道具一式をパッケージ化し、カーネルの標準機能によって隔離された安全なプロセスとして走らせること」です。

コンテナはあらゆる環境の壁を取り払う魔法の箱ではなく、Linuxカーネルの仕組みの上に成り立つ極めて合理的で実用的なプロセス管理技術です。カーネル共有の境界線、権限とリソースの制約、そしてストレージの分離原則を正しく理解して設計することこそが、コンテナの真価を引き出す鍵となります。