1. 導入：なぜ使い分けが必要なのか？
Dockerでアプリケーションをコンテナ化する際、必ずと言っていいほど登場するのが「変数」です。しかし、Dockerfileで使うARGとENVの違いを曖昧にしていると、思わぬセキュリティリスクに繋がったり、意図した通りに設定が反映されなかったりします。この2つは「いつ値が有効か」というライフサイクルが全く異なります。本記事では、初心者が迷いがちなこの2つの違いと、現場で必須となる使い分けのポイントを解説します。
2. 基礎知識：ARGとENVの違い
ARG（ビルド引数）は、Dockerfileをビルドしている「その瞬間」だけ有効な変数です。例えば、ライブラリのバージョンを指定したり、ビルド時に必要な一時的な設定値を渡すのに適しています。ビルドが終わると、この値はコンテナ内には残りません。
一方、ENV（環境変数）は、コンテナが「実行」されている最中も保持される変数です。アプリケーションが起動した後にデータベースの接続先やAPIキーを参照したい場合、これらはENVで定義する必要があります。
重要な注意点として、どちらもビルド後のイメージを確認すれば値が読み取れてしまう可能性があります。特に機密情報は、イメージ自体に書き込まない工夫が必要です。
3. 実装/解決策：役割分担の黄金ルール
基本的な使い分けの指針は以下の通りです。
・ARG：ビルドの過程（インストールやパスの設定）で使うもの。
・ENV：アプリ実行時にOSやプログラムが参照するもの。
セキュリティ上の観点から、機密情報（パスワードや本番環境のAPIキー）をDockerfileのARGやENVに直接書くのは厳禁です。これらはDockerイメージのレイヤーとして保存され、誰でも中身を確認できてしまうためです。機密情報は、実行時にコンテナへ渡すのが鉄則です。
4. サンプルプログラム：Dockerfileの書き方
以下のコードは、ビルド時にバージョンを指定し、実行時に環境変数を反映させる標準的なパターンです。
ビルド時に指定する変数（デフォルト値を設定可能）
ARG APP_VERSION=1.0.0
ビルドフェーズで利用する
RUN echo "Building version: ${APP_VERSION}"
実行時にも引き継がせたい場合はENVに代入する
ENV VERSION_INFO=${APP_VERSION}
アプリケーション起動時に環境変数を参照する設定
CMD ["sh", "-c", "echo 'Running app version: ' $VERSION_INFO"]
5. 応用・注意点：現場で役立つセキュリティ対策
現場で最も陥りやすいミスは、「ビルド時の秘密情報」をそのままイメージ内に残してしまうことです。
もしビルド時にどうしてもAPIキーなどが必要な場合は、マルチステージビルドを活用しましょう。ビルドステージだけでその変数を使用し、最終的な実行用イメージにはその変数が残らないように設計します。
また、実行時の環境変数（DBパスワードなど）は、Dockerfileに直接書くのではなく、Docker Composeの「.env」ファイルや、Kubernetesの「Secret」を利用して、実行環境の外側から注入するのがベストプラクティスです。これにより、コードの安全性と運用上の柔軟性を両立させることができます。
コメント