チュートリアルで docker run を打ったらアプリが動いた。でも、イメージとコンテナの違いを聞かれると言葉に詰まる。仮想マシンと何が違うのか、なぜ現場は「コンテナにしておけば安心」と言うのかも、まだ自分の言葉になっていない。そんな状態のまま ECS や EKS の資料を開くと、タスク定義やポッドの前に「そもそもイメージを誰がどこに置くのか」で止まります。この記事では、Docker を4つの言葉の関係として整理し、仮想マシンとの違いと「自分の PC では動くのに」が減る理由・減らない部分までを、人に説明できる形にします。
この記事の結論
- Docker は、アプリと依存するライブラリを「イメージ」に固め、どこでも同じ形で「コンテナ」として動かすための道具です。
- イメージは読み取り専用のひな形、コンテナはイメージから起動した実行中の実体、Dockerfile はイメージの作り方を書いたテキストです。
- レジストリはイメージの置き場で、作る人は push し、動かす側は pull します。AWS では Amazon ECR がこの置き場になります。
- 仮想マシンはゲスト OS を丸ごと持ち、コンテナはホスト OS のカーネルを共有するので、コンテナの方が軽く起動も速くなります。
- コンテナで「自分の PC では動くのに」は減りますが、CPU のアーキテクチャや外から渡す設定値の違いは残ります。
Docker（コンテナ）とは？何を解決するための道具か
コンテナとは、アプリのコードと、それが動くのに要るライブラリ・ランタイム・設定をひとまとめにして、ほかのアプリから隔離された環境で動かす技術です。AWS の「コンテナ化とは」の解説は、コンテナ化を「どのマシンで動かしても同じようにふるまう、自己完結したソフトウェアのパッケージを作ること」と説明しています。
Docker は、そのパッケージ（イメージ）を作り、配り、コンテナとして動かすための代表的な道具です。Docker の公式ドキュメントは、Docker を「アプリの開発・配布・実行のためのオープンなプラットフォーム」と位置づけ、アプリをインフラから切り離して素早く届けられることを目的に挙げています。
たとえるなら、同じ形の箱で運ぶ仕組み
港のコンテナを思い浮かべると掴みやすくなります。中身が家具でも食品でも、箱の外形が決まっているので、クレーンも船もトラックも同じ扱いで運べます。ソフトウェアのコンテナも同じで、中身が Python のアプリでも Java のアプリでも、外から見れば「イメージを pull して起動するもの」として同じ扱いになります。
たとえを正確な言葉に戻すと、こうなります。
- 箱の中身 = アプリのコード・ライブラリ・ランタイム・設定ファイル（イメージに固めたもの）
- 箱の外形 = イメージの標準の形式と、コンテナを起動する決まった手順
- 船やトラック = コンテナを動かす実行環境（開発者の PC、EC2、AWS Fargate など）
何を解決するのか
Docker が出てくる前は、サーバーを用意するたびに「OS に何を入れ、どの版のライブラリを、どの順に入れたか」を手順書で再現していました。手順書と実際のサーバーがずれると、開発者の PC では動くのに本番では動かない、という事故が起きます。コンテナは、その「入れたもの一式」をイメージという1つの成果物に固めて、どこでも同じものを起動する形に変えました。
READ ALSO — 未経験向け・段1 入口
プロセスとサービスとは何か｜systemd がサーバーのプログラムを動かし続ける仕組み
イメージ・コンテナ・Dockerfile・レジストリの関係とは
Docker の説明でつまずく人の多くは、4つの言葉の区別が曖昧なまま先に進んでいます。先に関係を1枚で押さえます。
BUILD, SHIP, RUNイメージの旅
作り方を書き、固めて置き、取り出して動かす
-
Dockerfile
作り方を書く
-
build
イメージに固める
-
レジストリ
push して置く
-
pull
動かす側が取り出す
-
コンテナ
run で起動する
| 言葉 | 何か | たとえ | 主な操作 |
|---|---|---|---|
| Dockerfile | イメージの作り方を1行ずつ書いたテキスト | 箱詰めの手順書 | docker build の入力 |
| イメージ | アプリと依存物を固めた読み取り専用のひな形 | 封をした箱 | build で作る・push / pull で運ぶ |
| コンテナ | イメージから起動した実行中の実体 | 箱を開けて動かしている状態 | docker run で起動・停止 |
| レジストリ | イメージを置いて共有する場所 | 倉庫 | push で置く・pull で取り出す |
イメージは「層」を重ねた読み取り専用のひな形
Docker の公式ドキュメントでは、イメージは「コンテナを作るための指示を含んだ読み取り専用のテンプレート」です。イメージは層（レイヤー）を重ねてできていて、Dockerfile の命令1つごとに層が1枚できます。Dockerfile を書き換えて作り直すと、変わった層から上だけが作り直され、変わっていない層は使い回されます。OS の土台やランタイムの層を多くのイメージで共有できるのも、この層の仕組みのおかげです。
コンテナはイメージの上に「書ける層」を1枚足したもの
コンテナを起動すると、Docker は読み取り専用の層の一番上に、書き込みのできる層を1枚足します。コンテナの中でファイルを作ったり書き換えたりしても、変わるのはこの層だけで、元のイメージは変わりません。そのため、1つのイメージから同じコンテナを何個でも起動でき、コンテナを消せば書いた内容も消えます。残したいデータ（アップロードされたファイルやデータベースの中身）は、コンテナの外の保存場所に置くのが前提です。
Dockerfile は作り方を残す、レジストリは置き場になる
Dockerfile は、土台にするイメージ（FROM）、コピーするファイル、入れるパッケージ、起動のコマンドを順に書くテキストです。テキストなので Git で管理でき、「このイメージは何から、どう作ったか」を後から追えます。
レジストリは、作ったイメージを置いて共有する場所です。Docker の公式ドキュメントは、Docker Hub を既定の公開レジストリとして挙げたうえで、ほかの選択肢として Amazon Elastic Container Registry（Amazon ECR）なども並べています。作る側は docker push で置き、動かす側は docker pull で取り出します。AWS でコンテナを動かすときは、イメージを ECR に置き、そこから ECS や EKS が取り出す形が基本になります。
CHECK 1ここまでの確認
Docker の「イメージ」と「コンテナ」の関係として正しいのはどれ?
答えと解説
答え: 2. イメージは読み取り専用のひな形で、コンテナはそこから起動した実行中の実体
イメージは設計図と部品を固めた読み取り専用のひな形、コンテナはそこから作った実行中の実体です。1つのイメージから何個でもコンテナを起動できます。「4つの言葉の関係」の章を読み直してください。
仮想マシンとコンテナはどう違うのか
「隔離した環境でアプリを動かす」という点では、仮想マシンもコンテナも同じです。違うのは、どの層で分けているかです。
WHAT EACH ONE CARRIES1つずつが抱えるもの
仮想マシンはカーネルごと抱え、コンテナはカーネルを共有する
仮想マシン
- 物理サーバー・ハイパーバイザー
- OS のカーネル
- OS のファイル群・ライブラリ・ランタイム
- アプリ
コンテナ
- 物理サーバー・ハイパーバイザー
- OS のカーネル
- OS のファイル群・ライブラリ・ランタイム
- アプリ
1つずつが持つ層共有する土台
AWS の「コンテナと仮想マシンの違い」の解説は、コンテナは OS レベルの仮想化、仮想マシンはハイパーバイザーによるハードウェアレベルの仮想化だと説明しています。仮想マシンは1台ずつがゲスト OS を丸ごと持ちます。コンテナはホスト OS のカーネルを共有し、その上で隔離されたプロセスとして動きます。Docker の公式ドキュメントは、この隔離に Linux の名前空間（namespaces）という仕組みを使っていると説明しています。
| 観点 | 仮想マシン | コンテナ |
|---|---|---|
| 分ける層 | ハードウェア（ハイパーバイザーの上で OS ごと） | OS（カーネルを共有し、プロセスとして） |
| 1つずつが持つもの | ゲスト OS（カーネルを含む）・ライブラリ・アプリ | ライブラリ・アプリ（OS のファイル群を含めることはあるが、カーネルは持たない） |
| 大きさ・起動 | OS を含むぶん大きく、起動に OS の起動が要る | OS を含まないぶん小さく、プロセスの起動に近い |
| 別の OS を動かす | できる（Linux の上で Windows なども） | ホストのカーネルに合うものだけ |
| 分けられる強さ | OS ごと分かれるので境界が太い | カーネルを共有するので、境界は仮想マシンより細い |
| AWS での例 | Amazon EC2 のインスタンス | Amazon ECS・Amazon EKS のタスクやポッド |
どちらかを選ぶ、ではなく重ねて使う
ここで誤解しやすいのは、「コンテナが仮想マシンを置き換える」という読み方です。AWS でコンテナを動かすとき、その下には EC2 のインスタンスや Fargate の基盤があり、結局は仮想マシンの上でコンテナが動いています。仮想マシンは「OS ごと借りる単位」、コンテナは「その上でアプリを配る単位」と役割で分けて考えると、両方が同じ構成に出てくる理由が説明できます。
READ ALSO — 未経験向け・段1 入口
EC2 とは何か｜インスタンス・AMI・EBS・セキュリティグループを「借りた1台」で理解する
CHECK 2ここまでの確認
仮想マシンと比べたときのコンテナの特徴として正しいのはどれ?
答えと解説
答え: 2. コンテナはホストの OS のカーネルを共有し、アプリと依存するライブラリだけを持つ
仮想マシンはハイパーバイザーの上でゲスト OS を丸ごと動かします。コンテナはホスト OS のカーネルを共有し、その上で隔離されたプロセスとして動くので軽く、起動も速くなります。「仮想マシンとどう違うのか」の章を読み直してください。
「自分の PC では動くのに」はなぜ減るのか、何は減らないのか
減る理由は「作ったものをそのまま運ぶ」から
コンテナを使うと、開発者の PC でテストしたイメージと同じものを、検証環境にも本番にも pull して起動できます。ライブラリの版、言語のランタイムの版、OS のパッケージの版は、イメージの層に固定されています。手順書でサーバーを組み直すのではなく「同じ成果物を運ぶ」ので、環境ごとの小さなずれが入り込む余地が減ります。AWS のホワイトペーパー「Containers on AWS」も、コンテナの利点として速さ・一貫性・密度・資源効率・移植性を挙げています。
それでも減らない4つのずれ
コンテナは万能ではありません。イメージの外にあるものは、環境ごとに違ったままです。
コンテナにしても残るずれ
- CPU のアーキテクチャ: arm64 の PC で作ったイメージは、そのままでは amd64 のサーバーで動かないことがある（複数のアーキテクチャ向けに作るか、動かす側に合わせる）
- 外から渡す設定: 環境変数・秘密情報・つなぎ先のデータベースは、環境ごとに違う値を渡す
- データ: コンテナの書き込み層は消えるので、残すデータは外の保存場所に置く
- ネットワーク: PC では localhost で届いた相手が、本番では別のホストや別のサービスになる
言い換えると、コンテナが固定してくれるのは「箱の中身」で、「箱をどこに置き、何につなぐか」は動かす側の設定です。AWS の ECS では、この「動かす側の設定」をタスク定義という形で書きます。どのイメージを使い、どれだけの CPU とメモリを渡し、どの環境変数を渡すかを、イメージとは別に管理します。
同じタグでも中身が変わることがある
イメージには app:1.2 や app:latest のようなタグが付きますが、タグは付け替えられる名札です。同じ latest を pull しても、昨日と今日で中身が違うことがあります。本番では版の分かるタグを使い、何を動かしているかを追えるようにしておくのが、現場でよく使われる考え方です。
CHECK 3ここまでの確認
コンテナにしても「自分の PC では動くのに」が残りやすいのはどれ?
答えと解説
答え: 2. CPU のアーキテクチャ（arm64 と amd64）や、外から渡す設定値が違う
ライブラリやランタイムの版はイメージに固定できます。一方で、CPU のアーキテクチャの違いや、環境変数・秘密情報・つなぎ先のデータベースのように外から渡すものは、イメージの外に残ります。「なぜ減るのか、何は減らないのか」の章を読み直してください。
AWS ではコンテナをどこで使うのか
Docker で作ったイメージは、AWS ではおおむね次の流れで動きます。
| 役割 | AWS のサービス | この記事の言葉との対応 |
|---|---|---|
| イメージの置き場 | Amazon ECR | レジストリ |
| コンテナを動かし続ける仕組み | Amazon ECS / Amazon EKS | コンテナの起動・入れ替え・台数の維持 |
| コンテナが乗る土台 | Amazon EC2 / AWS Fargate | 仮想マシン（Fargate はサーバーの管理を AWS に任せる形） |
| 関数としてコンテナを動かす | AWS Lambda（コンテナイメージから関数を作る） | イメージをそのまま関数の中身にする |
AWS のコンテナのサービス紹介は、イメージを保存・管理する場所、いつどこでコンテナを動かすかを決めるオーケストレーション、コンテナを動かす計算資源、の3つに分けてサービスを並べています。この記事で覚えた4つの言葉は、そのまま ECR（レジストリ）と ECS・EKS（コンテナを動かす仕組み）の説明の土台になります。ECS と EKS のどちらを選ぶかは、次の記事で扱います。
READ ALSO — 実務向け・段3 基盤
ECS か EKS か、それとも EC2 か Lambda か｜コンテナ基盤の判断を「何を自分で持ちたいか」で決める
まとめ
- Docker は、アプリと依存物をイメージに固め、どこでも同じ形のコンテナとして動かす道具です。
- Dockerfile（作り方）→ イメージ（ひな形）→ レジストリ（置き場）→ コンテナ（実行中の実体）の順に旅をします。
- 仮想マシンは OS ごと、コンテナはカーネルを共有してプロセスとして分けます。AWS では両方を重ねて使います。
- 「自分の PC では動くのに」は減りますが、アーキテクチャ・設定・データ・つなぎ先はイメージの外に残ります。
次は、このイメージを AWS でどう動かし続けるかです。ECR にイメージを置き、ECS か EKS で動かす、という流れを選び方から見ていきましょう。
参照ソース
- What is Docker?（Docker Docs） — Docker の位置づけ、イメージ・コンテナ・レジストリの定義、名前空間による隔離（2026年9月時点の記載）
- Understanding the image layers（Docker Docs） — Dockerfile の命令ごとに層ができること、コンテナの書き込み層（2026年9月時点の記載）
- What is a registry?（Docker Docs） — レジストリの役割と、Docker Hub・Amazon ECR などの例（2026年9月時点の記載）
- What is Containerization?（AWS） — コンテナ化の定義（2026年9月時点の記載）
- Container benefits（Containers on AWS ホワイトペーパー） — コンテナの利点（速さ・一貫性・密度・資源効率・移植性）（2026年9月時点の記載）
- Containers on AWS（AWS） — イメージの置き場・オーケストレーション・計算資源の3つに分けたサービスの並べ方（2026年9月時点の記載）
- Containers vs VM（AWS） — OS レベルの仮想化とハードウェアレベルの仮想化の違い（2026年9月時点の記載）
- What is Amazon Elastic Container Registry?（Amazon ECR ユーザーガイド） — AWS でのイメージの置き場としての ECR（2026年9月時点の記載）
