.envと.env.localとは何か？どちらを使うべき？違い・環境変数の優先順位や使い方を実例で分かりやすく解説(env.example, .env.development, .env.production)

windows-terminal-prograshi（プロぐらし）-kv Language
windows-terminal-prograshi（プロぐらし）-kv
2026/1/13
記事内に広告が含まれていることがあります。


Next.jsやViteなどの多くの開発環境（フレームワーク）では、.envや.env.localというファイルを使います。

しかし、いざ開発を進めると .env.local や .env.production など似たようなファイルがいくつも登場し、「結局どれに何を書けばいいの？」と混乱していませんか？

実は、これらの使い分けには明確なルールがあり、間違えると大切なAPIキーやパスワードを世界中に公開してしまう危険性もあります。

本記事では、初心者の方に向けて .env と .env.local の決定的な違いや読み込みの優先順位を、実例を交えて分かりやすく解説しています。

この記事を読めば、もう環境変数の運用で迷うことはありません！


.envファイルとは何か？

.envファイルとは、プロジェクトで使う設定値やサーバーの情報などをまとめて記載しておくファイルです。

Next.jsやViteなどの多くの開発環境において、最初に.envファイルの内容を読み込みます。


.env.localとは何か？

プロジェクトによっては.envファイルに、APIキーなどの重要な接続情報を記述することもありますが、複数メンバーが関わるプロジェクトでは.env.localも作成するのが一般的です。

データベースのパスワードや、有料APIのシークレットキーなど 「絶対に他人に知られてはいけない情報」を書き込みます。

GitHubなどの共有サーバーにアップロードする際、.gitignore という設定ファイルによって、.env.localはアップロード対象から除外する設定になっていることがほとんどです。

Point

プロジェクトによっては .envファイルも.gitignoreでアップロード対象外となっていることがあります。

# env files (can opt-in for committing if needed)
.env*


ファイル読み込みの優先順位（オーバーライド）

プロジェクトがファイルを読み込む際に優先順位があります。

先に.envを読み込み、次に.env.localファイルを読み込みます。

このため、それぞれのファイルの中にAPI_KEY=という環境変数があった場合、.envファイルのものは、.env.localファイルの内容で上書きされます。

Point

この仕組みは、「範囲が狭くて具体的なものほど優先される」というルールに基づいています。

優先順位はフレームワークで決まっています。


.envと.env.localの違いと使い分け

実際に開発を進める際に、.env と .env.local は以下のように使い分けます。

一番のポイントは、「.envはみんなで使う『土台』。公開しても問題なし」、「.env.localは自分だけが使う『本物』。重要な設定」という使い分けです。

.envと.env.localの使い分けルール
  • 共通の設定 ⇒ .env
  • 他人にバレたらまずい ⇒ .env.local
  • 開発者によって値が違う ⇒ .env.local
特徴.env.env.local
役割プロジェクトのデフォルト設定開発者個人のローカル設定
優先順位低い高い（.env を上書きする）
共有 (Git)通常は共有する（コミットする）共有しない（必ず無視する）
用途全環境共通の変数など個人のAPIキー、DBパスワードなど


具体的には以下のように記述します。

# APIの接続先URL（全員共通）
API_BASE_URL=https://api.news-provider.com/v1

#DB接続情報
DB_HOST=localhost
DB_USER=root

# 基本的には分析ツールをオンにする
NEXT_PUBLIC_ANALYTICS_ENABLED=true
# 自分専用のAPIキー（絶対にGitHubに上げない！）
API_KEY=abc123456789_secret_key

# 自分のPCのDBパスワード（人によって違う場合がある）
DB_PASSWORD=my_personal_password_999

# 自分の開発中は邪魔なので、分析をオフにする
#（優先順位が高いので、上のtrueがfalseで上書きされる）
NEXT_PUBLIC_ANALYTICS_ENABLED=false


.envファイルの書き方

基本ルール

.envファイルは「名前（環境変数）＝値」として記述します。

.envファイルの書き方
  1. 「名前（環境変数）＝値」として記述する。
  2. 一行ずつ記述する。
  3. スペースは入れない。
  4. 環境変数は大文字で書く。
  5. アンダースコアでつなぐ（スネークケース）。
  6. 基本は（ダブル）クオテーションは不要。
  7. ファイルはルートディレクトリに配置する。

例えば、ポート番号で3000番を使う指定であれば PORT=3000 と記述します。

# これはコメントです（プログラムには無視されます）
PORT=3000
DATABASE_URL=https://my-database.com
API_KEY=abc123456789


大文字と小文字の使い分け

.envファイルの環境変数は大文字で記述する最大の理由は、「プログラム内の普通の変数」と「環境変数（外から来た大事な設定）」を一目で見分けるためです。

このルールにより変数名を見ただけで、大文字の変数（例: DB_PASSWORD）は、.env などの外から読み込んだ、システム全体に関わる「重要な設定」だな。

小文字の変数（例: userPassword）は、プログラムの中で一時的に使うデータだなという識別ができます。


クオテーションは基本不要

環境変数の値を指定するときに、基本的に（ダブル）クオテーションはつけません。

API_KEY=abc123456789 とすれば、右側を文字列として認識します。

ただし、以下の場合はダブルクオテーションをつけます。

ダブルクオテーションをつける場合
  • 空白を含めたい時
    値の中にスペースが入る場合は " " で囲みます。

    例：MESSAGE="Hello World"
  • パスワードに特殊文字がある時
    # などの記号がパスワードに含まれていると、そこから先が「コメント」だと勘違いされることがあるので、" " で囲むのが安全です。


実例

外部サービス・APIの連携（よく使われる例）

GoogleやStripe、OpenAIなどのサービスを使う時に必要なAPIキー（認証用の合言葉）を記述します。

# OpenAIのAPIキー（例）
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxx

# Google MapsのAPIキー（例）
GOOGLE_MAPS_API_KEY=AIzaSyAxxxxxxxxxxxx


フロントエンド（React/Next.jsなど）で使う場合

Next.jsやViteなどのツールでは、セキュリティ上の理由から「特定の名前から始めないとプログラムから読み取れない」というルールがあります。

  • Next.jsの場合: NEXT_PUBLIC_ をつける
  • Viteの場合: VITE_ をつける
# Next.jsで画面に表示したい設定
NEXT_PUBLIC_ANALYTICS_ID=G-12345

# Viteで画面に表示したい設定
VITE_API_BASE_URL=https://api.example.com


.envファイルは必須？

.envファイルがなければ、エラーにはなりませんが、設定値が読み込めないので、連携しているAPIなどが動かなくなります。（「環境変数は設定されていない（空っぽ）」と判断して進みます）

ですが実際の開発では以下の2つの理由により.envファイルは実質必須と言われています。

.envファイルが実質必須な理由
  1. パスワードを隠すため
    外部に漏らしたくない情報を守る場所が他にない。
  2. 環境を切り替えるため
    プログラムを書き換えずに「今はテスト用」「今は本番用」と切り替える仕組みが他にない。


.env.developmentと.env.development.local、.env.production

.envファイルには他にも以下のような種類があります。

.envファイルの種類
  • .env
  • .env.local
  • .env.development
  • .env.development.local
  • .env.production
  • .env.production.local
  • .env.example

これらの違いは、ファイル読み込み時の優先順位です。


.env.example

プロジェクトでこのファイルは読み込みません。書き方の参考情報を記述するために使います。


本番環境と開発環境の使い分け

.env.develpmentと.env.productionは、個人開発レベルであれば使う必要はありません。

プロジェクトが大きくなり、開発環境と本番環境で設定を分けるニーズが出てきた場合に使用します。


.env.developmentと.env.development.local

npm run devで開発環境を起動したときに、.env.developmentと.env.development.localファイルの設定を読み込みます。

優先順位は以下のようになります。

開発環境（npm run dev）
  • .env
  • .env.development
  • .env.local
  • .env.development.local

.env.development.lcoalが「最も範囲が狭くて具体的」になるので、最優先されます。

.env.productionは無視されます。


.env.productionと.env.production.local

npm run buildで本番環境を構築する際は、.env.productionを読み込みます。

優先順位は以下のようになります。

開発環境（npm run build）
  • .env
  • .env.production
  • .env.local
  • .env.production.local



必ず.gitigonoreを確認する

基本的にはフレームワークが自動的に無視するファイルを.gitignoreに記述します。

もし、重要なパスワードが入ったデータが流出したら一大事なので必ず.gitignoreの設定を確認します。

全ての.envファイルを無視する

.envも含め、.envから始まる全てのファイルをアップロード対象から無視する場合は以下のように記述します。

.env*


.envファイルはアップする

.envファイルのみアップする場合は以下のようにします。

.env.*


.envファイルと.env.exampleはアップする

.envファイルと.env.exampleはアップする場合は以下のようにします。

.env.*
!.env.example
否定は！

冒頭に！をつけると、否定となり、アップロード対象にすることができます。


.localがつくファイルのみアップロードから除外する

.localがつくファイルのみアップロードから除外するには以下のように記述します。

.env*.local
否定は！

冒頭に！をつけると、否定となり、アップロード対象にすることができます。


個別に設定する

より細かく指定したい場合は、アップロード対象外のファイル名を個別に記述します。

※記入漏れに注意してください

.env.local
.env.production
.env.production.local
.env.development
.env.development.local
タイトルとURLをコピーしました