
こんなあなたにピッタリな記事👇
- 環境変数設定の意味があやふや
- 環境毎にどのファイルに設定すればいいの?
- 利用するにあたっての注意点が知りたい
がまぁまぁわかります!
困ってた自分に届けたい話
これまでなんとなく、.env
ファイルに設定を書いて「雰囲気で」使っていました。
「API_KEY
?FROM_EMAIL
?なんかよく使うし、とりあえず入れておくか…」
そんなふうに、意味や役割をちゃんと理解しないまま、コピー&ペーストで使っていたんです。
でもある日、上司から「環境変数って何を入れてるの?」「どういうとき使うの?」と聞かれて、
正直うまく答えられませんでした。
自分がよくわかってないことがバレて、恥ずかしかった。

この記事は、同じように困っていた方への備忘録兼シェアとして書いています。
そもそも「環境変数」ってなに?
環境変数とは、プログラムの外から設定できる値(変数)のこと。
例えば以下のような機密性のある情報を、コードに直接書かずに管理できます。
- ✅ APIキー(SendGridやStripeなど)
- ✅ データベース接続情報
- ✅ メール送信元アドレス
- ✅ 本番・開発で切り替える設定値 など
セキュリティ的にも、柔軟性の面でも、使いこなす価値が高い設定です。
環境変数はどう使うの?
① .env ファイルを作成
例えば、開発環境用の.env
を作る場合
これは好みもありますが私は .env.local
というファイル名にして下記の内容を記述します。
SENDGRID_API_KEY=SG.XXXXXX
FROM_EMAIL=admin@example.com
② .gitignoreに除外設定
.gitignore
とはGitに無視してほしいファイルやフォルダを指定するファイルです。
このファイルに書かれたものは、Gitの管理対象から除外されます。
🤷♂️ なぜ除外する必要が?
Gitは通常、変更されたすべてのファイルを追跡しようとします。
でも、以下のようなファイルは追跡したくない・共有したくないことが多いです。
種類 | なぜGitに入れないの? |
---|---|
.env などの環境変数ファイル | パスワードやAPIキーなど、他人に見せてはいけない情報が入っているから |
node_modules/ や vendor/ | 使用しているライブラリが入っているが、あとから自動で復元できるから |
.DS_Store や Thumbs.db | MacやWindowsが勝手に作るゴミファイルで、他の人には不要だから |
dist/ , build/ | コンパイルされた成果物であり、ソースコードではなく再生成できるものだから |
今回は.env
関連ファイルをGitの管理対象外にしたいので、.gitignore
に次を追加します。
.env
.env.local
.env.production
.envファイルの種類と使い分け
.env
ファイルは、複数種類があります。使い分けがあるので、確認しましょう。
ファイル名 | 主な用途・説明 |
---|---|
.env | 全環境で共通の基本設定を記述(例:APIのベースURLなど) |
.env.local | 個人の開発環境専用の設定。Gitに含めず、自分だけの秘密の設定を書く (例:ローカルDBのパスワード) |
.env.production | 本番環境用の設定。デプロイ時にのみ使われる (例:本番DBの接続先、SendGridの本番キーなど) |
.env.test | テスト実行時に使う設定(例:モックAPIのURLやテスト用認証情報) |
環境変数の実用例
Next.js
通常、環境変数の名前は API_KEY
や DB_HOST
など、任意の名前で定義できます。
しかし、Next.jsでは、フロントエンドで環境変数を使う際に特別なルールがあります。バックエンドと異なり、NEXT_PUBLIC_
という接頭辞が必要です。
// OK(フロントエンドでも使える)
NEXT_PUBLIC_API_URL="https://example.com"
// NG(ブラウザからは見えない)
API_URL="https://example.com"
フロントエンドのコードはブラウザに配信されるため、意図的に公開してよい情報だけを NEXT_PUBLIC_
を使って明示する仕様になっています。
Docker
【自動読み込み】Compose自体が使う .env
- ファイル名は定義で「.env」のみ
docker-compose.yml
内の${変数名}
を置換するためのもの- サービスに限らず、
build
やports
の値も置換可能
db:
image: mysql:${MYSQL_VERSION}
【サービス単位の指定】env_file で指定する .env
env_file
で指定したサービスにだけ適用.env.dev
や.env.local
など、名前は自由- 設定された値は、コンテナ内で実行されるプロセスに環境変数として渡される
services:
app:
build: .
env_file:
- .env
🌱 豆知識 :直書きも可能(非推奨 )
案件によっては開発環境でしかDocker使わないという場合は、ローカルPC以外で情報漏れることがないため、直書きで実装しているところもあります。小規模ならOKですが、複数人開発や情報分離を考慮すると .env
がおすすめです。
services:
app:
environment:
- API_KEY=xxx
- FROM_EMAIL=admin@example.com
実際に開発ではどんな感じで環境変数が登場するか?記事はこちらです🤞
おまけ:.env.example を活用しよう
本番の .env
をそのまま共有するのではなく、中身を空にしたテンプレートファイル .env.example
を用意しておくのがおすすめです。
他の開発者はこれを元に、自分の .env
を作成することができます。
// SendGridのAPIキーをここに記入してください
SENDGRID_API_KEY=
// メールの送信元アドレスを記入してください
FROM_EMAIL=
このように、コメント付きの .env.example
を用意しておけば、他の開発者にとっても親切で、Gitに機密情報を含めない安心設計が実現できます。

おつかれさまでした!
コメント