📑 この章の目次
title: コンテナ（Docker） icon: 📦 card_desc: アプリを環境ごと箱詰めしてどこでも同じように動かす技術 — イメージ・コンテナ・Dockerfile・開発と本番の差異をなくす作法 slug: 06-docker
06 コンテナ（Docker） — アプリを「環境ごと箱詰め」してどこでも同じように動かす
「私のPCでは動いていたのに、本番サーバーに置いたら動かない」——開発現場で一番よく聞くこの事故を、根本から防ぐ技術がコンテナです。この章では、アプリを「環境ごと箱詰め」して運ぶ作法を、根本から理解します。
一言でいうと
コンテナは、アプリと、そのアプリが動くために必要なもの（ライブラリ・設定等）を**「丸ごと1つの箱」に詰め込む技術です。Docker（ドッカー）は、その箱を作って動かすための代表的なツールです。箱詰めしておけば、開発用のPCでも・テスト環境でも・本番サーバーでも「同じ箱」を動かす**ことになるので、「環境の違い」で動かない事故が構造的に起きなくなります。
1. なぜコンテナが必要なのか
第1章で「CI環境と本番環境は別物」と書き、その対策として**「可能な限り同じ環境（コンテナ等）を使う」**と触れました。この章は、その伏線を回収します。
チーム開発や本番運用を想像してください：
- 「私のPC（Python 3.12）では動いたのに、本番サーバー（Python 3.9）では動かない」（バージョン違い）
- 「私のPCに入っているライブラリが、ほかの人のPCには入っていない」（依存の差）
- 「Macで開発したが、本番はLinux。OSが違うことで起きる問題にハマる」（OSの差）
- 「新しい人が入ったが、環境構築で丸1日つぶれる」（再現の手間）
これらはすべて**「動かす環境が、人・タイミング・場所でバラバラ」**なことが原因です。
💡 この問題を「手順書をちゃんと書く」で防ごうとすると、環境が変わるたびに壊れ、メンテ不能になります。コンテナの発想は逆です。**「環境そのものを、コードと一緒に運べるものにする」**ことで、バラつきを構造的に消し去ります。
2. コンテナとは何か —— 「環境ごと箱詰め」
コンテナとは、**「アプリが正しく動くために必要なものを、すべて詰め込んだ1つの箱」**です。箱の中には、アプリのコードだけでなく、必要なライブラリ・ツール・設定ファイルが入っています。
大事なのは、**この箱は「中身を一切いじらずに、別の場所へそのまま運べる」**という点です。だから「私のPCで動いた箱」を、本番サーバーで「そのまま」動かせます。
仮想マシン（VM）との違い
「環境を隔離する」という目的は、従来の仮想マシン（Virtual Machine／通称 VM）にもありました。しかし方式が違います：
| 仮想マシン（VM） | コンテナ | |
|---|---|---|
| 何を隔離するか | OSごと丸ごと別のPCを模倣する | OSの機能を共有しつつ、アプリ周辺だけを隔離する |
| 重さ | 重い（OS1つ分のリソースが要る） | 軽い（OSは共有） |
| 起動 | 遅い（数十秒〜分） | 早い（秒以下） |
| 数を増やす | コストが高い | 同一マシンでたくさん動かせる |
例えていうと: 家と部屋
- 仮想マシンは「部屋ごと、別の家を丸ごと建てる」ようなもの。完全に独立していますが、家1つ分のコスト・手間がかかります。
- コンテナは「1つの家の中で、部屋を区切って使う」ようなもの。水道や土台（OS）は共有しつつ、部屋の中（アプリの実行空間）は独立しています。
💡 Docker（ドッカー）は、このコンテナを作る・動かす・運ぶための最も普及したツール兼フォーマットです。「コンテナ」という技術概念と「Docker」という実装がセットで普及したため、現場ではほぼ同義で語られます。
3. 🔑 イメージとコンテナ —— 設計図と実体
ここが本章の核心です。「イメージ」と「コンテナ」を混同するのが、初学者が一番よく陥る罠です。この2つは別のものです。
イメージ（image）= 設計図
イメージは、アプリと環境を詰め込んだ**「設計図（読み取り専用のテンプレート）」です。箱の中身の定義**であって、動いている実体ではありません。イメージは変更不可（読み取り専用）で、何度でも同じものを複製できます。
コンテナ = 実体
コンテナは、そのイメージから**「実際に起動して動いているもの」**です。「イメージという設計図を、実体として走らせた状態」がコンテナです。
例えていうと: レシピとケーキ
- イメージは「レシピ（と、必要な材料が揃ったキット）」。レシピそのものは食べられません（動いていません）。
- コンテナは「そのレシピで実際に焼いたケーキ」。これが「動いている実体」です。
1つのレシピから、ケーキを何個でも焼けるのと同じように、1つのイメージからコンテナを複数、同時に起動できます。
| イメージ（image） | コンテナ | |
|---|---|---|
| 例え | レシピ・型 | 焼けたケーキ |
| 性質 | 読み取り専用のテンプレート | 動いている実体 |
| 数 | 1つ作れば完了 | 1イメージから複数起動可能 |
| 操作 | 「ビルド（build）」して作る | 「起動（run）」して動かす・「停止」して止める |
重要 「イメージを作る」ことと「コンテナを動かす」ことは別工程です。まず設計図（イメージ）を作り、それから実体（コンテナ）を起動する、という2段階で理解するのが正しい入り方です。
4. Dockerfile —— 設計図を書く手順書
では、イメージ（設計図）はどうやって作るのでしょうか。その**「作り方を書いた手順書」**が Dockerfile（ドッカーファイル）です。
Dockerfile の例
# Dockerfile（イメージの作り方を書く手順書）
FROM python:3.12 # ベース: Python 3.12 が入った素材を使う
WORKDIR /app # アプリを置く場所を /app に決める
COPY requirements.txt . # 必要なライブラリ一覧をコピー
RUN pip install -r requirements.txt # ライブラリをインストール
COPY . . # アプリのコードをすべてコピー
CMD ["python", "app.py"] # 箱を起動した時に動かすコマンド
この手順書を ビルド（build） すると、完成したイメージができます。そして、そのイメージを起動（run） すると、コンテナとして動き出します。
💡 Dockerfile は「環境構築の手順書」のコード化です。かつて「このフォルダで pip install して、あの設定ファイルを置いて……」と人間が手順書を読んで手作業でやっていた環境構築を、機械が再現できる形に書き直したもの、と捉えると本質が見えます。手順書がコードになれば、バージョン管理（→ 第2章）でき、CIで検査（→ 第1章）もできます。
5. 🔑 開発と本番で「同じ箱」を動かす —— 差異をなくす作法
ここが、コンテナが単なる「便利な道具」でなく開発の作法たる理由です。
同じイメージを、別々の場所で動かす
コンテナの最大の価値は、「1つのイメージを、開発PC・CI・本番サーバーの全部で、そのまま動かせる」ことです。箱の中身が同じなら、「私のPCでは動いたのに本番で動かない」という事故が構造的に起きません。
ただし「完全に同じ」には分けるべきものがある
ここが重要な落とし穴です。「同じ箱を動かす」といっても、環境ごとに必ず変わるものがあります。それを箱の中に固定してはいけません：
| 箱の中（共通・固定） | 箱の外から与える（環境ごとに変わる） |
|---|---|
| アプリのコード | 環境変数（DBの接続先・APIキー等） |
| ライブラリ・ツール | データ（開発用のテストデータ vs 本番の実データ） |
| 実行環境の設定 | リソース（本番のスペック・台数） |
つまり作法は、**「アプリ部分＝箱の中で共通」「環境依存部分＝箱の外から注入」**と、はっきり分けることです。
⚠ 本番の秘密情報を、イメージに焼き込んではいけない: データベースのパスワードやAPIキーを Dockerfile やイメージの中に直接書くと、イメージが漏れた時に秘密も一緒に漏洩します。秘密は環境変数として、箱の外から実行時に与えるのが正解です（→ 第4章 環境変数・シークレット管理）。
💡 つまりコンテナは、第4章の「環境変数で機密を外だしする」作法とセットで使って初めて完成します。「アプリは箱・設定は外」の分離こそが、環境を運ぶ作法の核心です。
6. なぜ「コンテナ」が開発の作法なのか
ここまでを読むと、コンテナが単なる「動かす道具」でなく、開発から本番まで環境を一致させる基盤であることが見えてきます。
作法として位置づけられる理由
- 環境の再現性 —— 誰のPCでも・いつでも・同じ環境が再現できる（「私のPCでしか動かない」の排除）
- 開発と本番の一致 —— 同じ箱を動かすので、環境差による事故が減る
- オーケストレーションへの入り口 —— コンテナ1個は手軽ですが、本番で数十〜数百を運用するには管理の仕組みが要ります。その基盤が Kubernetes（クーバネティス／通称 K8s）です。
💡 Kubernetes は、複数のコンテナを本番で大量に運用・自動管理する技術です。「コンテナが死んだら自動で再起動」「アクセスが増えたら台数を増やす」等を自動で行います。1個のコンテナならDocker単体で足りますが、本番の大規模運用ではK8sのような管理基盤が前提になります。第6章では「コンテナの基礎」、K8sはその先の「運用の規模拡大」の技術、と位置づけてください。
面接・実務での意味
「Docker、使ったことありますか？」
この質問は、単に「コマンドを打てるか」を聞いているのではありません。**「環境の再現性を意識して、開発から本番まで環境を一致させられるか」**を聞いています。「コンテナで環境を固定し、秘密は環境変数で外だしする」と即答できる人は、現場で信頼されます。
7. よくある落とし穴と対処
| 落とし穴 | 何が起きるか | 正しい対応 |
|---|---|---|
| 秘密情報をイメージに焼き込む | イメージ漏洩でパスワード・APIキーも漏れる | 秘密は環境変数で外から注入（→ 第4章） |
| データをコンテナの中に置く | コンテナを消すとデータも消える | ボリューム（volume）等で、データは箱の外に置く |
タグを latest で固定する |
「いつのバージョンか」分からず再現性が消える | バージョンを明記（python:3.12 等）して固定 |
| 開発と本番で別々のイメージを作る | 「環境差」が復活し、コンテナの意義がなくなる | 同一イメージ＋設定を外から注入して分ける |
| イメージを無駄に大きくする | ビルド・配布が遅く、攻撃対象も増える | 必要最小限にする（不要なファイル・ツールを詰め込まない） |
💡 ボリューム（volume）: コンテナの「外」にデータを保存し、コンテナからそれを「参照」させる仕組み。データベースのデータ等、消してはいけないものはコンテナ（使い捨ての実体）の中ではなく、ボリュームに置くのが作法です。
まとめ
- コンテナは、アプリと実行環境を**「丸ごと1つの箱」**に詰め込む技術。Docker はその代表実装
- 仮想マシン（VM）はOSごと隔離して重い・コンテナはアプリ周辺だけ隔離して軽く早い
- イメージ（設計図・読み取り専用）とコンテナ（実体・動いているもの）は別物。イメージからコンテナを複数起動できる
- Dockerfile はイメージの作り方を書いた手順書。ビルドしてイメージを作り、起動してコンテナを動かす
- 作法の核心は**「アプリ部分＝箱の中で共通・環境依存部分＝箱の外から注入」の分離。秘密は環境変数**で外だし（→ 第4章）
- 同じイメージを開発〜本番で動かすことで「私のPCでは動いた」事故を構造的に防ぐ。大規模運用は Kubernetes（K8s） へ
💡 次のステップ: アプリを動かす「箱」と環境の話が出ました。次は、アプリが蓄えるデータの置き場所——データベースです。第7章では、SQLite・PostgreSQL 等、目的に応じたデータベースの「適材適所」の判断軸を扱います。