【保存版】.envファイルの使い分け完全ガイド|Next.js・Docker対応|環境変数設定入門

【保存版】.envファイルの使い分け完全ガイド|Next.js・Docker対応の環境変数設定入門 知識
【保存版】.envファイルの使い分け完全ガイド|Next.js・Docker対応の環境変数設定入門
この記事は約6分で読めます。
てんハロ運営者
てんハロ運営者

こんなあなたにピッタリな記事👇

  • 環境変数設定の意味があやふや
  • 環境毎にどのファイルに設定すればいいの?
  • 利用するにあたっての注意点が知りたい

がまぁまぁわかります!

プロが教える、業界最前線のノウハウ【Coloso】

困ってた自分に届けたい話

これまでなんとなく、.env ファイルに設定を書いて「雰囲気で」使っていました。

API_KEYFROM_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_StoreThumbs.dbMacや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_KEYDB_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内の ${変数名} を置換するためのもの
  • サービスに限らず、buildportsの値も置換可能
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に機密情報を含めない安心設計が実現できます。

てんハロ運営者
てんハロ運営者

おつかれさまでした!

更新をF5連打で待つの、そろそろやめませんか?
( ブログ更新をメールでそっとお知らせします🙇‍♂️ )

スパムはしません!詳細については、プライバシーポリシーをご覧ください。

コメント