.envファイルのベストプラクティス：本番環境ガイド （2026年）

.envファイルとは？

.envファイル（「ドットエンブ」と発音）は、アプリケーションの環境変数を保存するプレーンテキストの設定ファイルです。シンプルなKEY=VALUE形式に従い、dotenv（Node.js）、python-decouple（Python）、godotenv（Go）、vlucas/phpdotenv（PHP）などのライブラリによってアプリケーション起動時に読み込まれます。

.envファイルの基本思想はTwelve-Factor App方法論に由来し、設定をコードではなく環境に保存することを推奨しています。これにより、同じコードベースが.envファイルを切り替えるだけで開発、ステージング、本番環境で動作します — コード変更は不要です。

.envファイルに保存される一般的なものには、データベース接続文字列、APIキー、サードパーティサービスのクレデンシャル、フィーチャーフラグ、ポート番号、アプリケーションモード設定があります。

.envファイルのフォーマットルール

.envフォーマットはシンプルですが、パーサーによって微妙に異なる重要なルールがあります。これらを一貫して守ることで微妙なバグを回避できます：

基本的なKEY=VALUE構文

# 1行に1変数
PORT=3000
NODE_ENV=production
APP_NAME="My Application"

値のクォート

スペース、特殊文字を含む値、または先頭/末尾の空白を保持する必要がある値はクォートが必須です。シングルクォートとダブルクォートの両方がほとんどのパーサーでサポートされていますが、ダブルクォートの方が互換性が高いです：

# 必須：値にスペースが含まれる場合
APP_DESCRIPTION="A production-ready web application"

# 必須：# や $ などの特殊文字
DB_PASSWORD="p@$$w0rd#2026"

# 任意だが問題なし：シンプルな値
PORT="3000"

複数行の値

秘密鍵や証明書など複数行にまたがる値には、リテラル改行を含むダブルクォート値または\nエスケープシーケンス（パーサー依存）を使用します：

# ダブルクォート内のリテラル改行（dotenv v15+構文）
PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA...
-----END RSA PRIVATE KEY-----"

# 代替：エスケープ改行（より互換性が高い）
PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQEA...\n-----END RSA PRIVATE KEY-----"

コメント

#で始まる行はコメントとしてパーサーに無視されます。インラインコメント（同じ行の値の後）はすべてのパーサーでサポートされているわけではないため、避けるべきです：

# これは単独行の安全なコメントです
PORT=3000

# 避けるべき：インラインコメントはパーサーを壊す可能性があります
# PORT=3000 # web server port  <-- 値が "3000 # web server port" になる

環境変数の命名規則

一貫した命名規則により.envファイルが理解しやすく、監査しやすくなります。以下の確立されたパターンに従ってください：

SCREAMING_SNAKE_CASEを使用

環境変数名はすべて大文字で、単語をアンダースコアで区切ります。これはすべてのOSと言語で普遍的に受け入れられている規則です：

# 正しい
DATABASE_URL=postgres://...
MAX_UPLOAD_SIZE_MB=50
STRIPE_SECRET_KEY=sk_live_...

# 間違い
# databaseUrl=postgres://...
# maxUploadSize=50
# stripe-secret-key=sk_live_...

サービスまたは機能領域でプレフィックスを付ける

関連する変数に共通のプレフィックスを付けてグループ化します。これによりファイルがスキャンしやすくなり、複数サービスの設定時に名前の衝突を避けられます：

# Database
DB_HOST=localhost
DB_PORT=5432
DB_NAME=myapp_production
DB_USER=appuser
DB_PASSWORD=your_strong_password

# AWS
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG
AWS_REGION=us-east-1
AWS_S3_BUCKET=my-app-assets

# Stripe
STRIPE_PUBLIC_KEY=pk_live_...
STRIPE_SECRET_KEY=sk_live_...
STRIPE_WEBHOOK_SECRET=whsec_...

.envをGitにコミットしない

これが最も重要なルールです。公開リポジトリにコミットされた.envファイルは、シークレットをインターネット全体に公開します — そしてgit履歴は永続的です。後続のコミットでファイルを削除しても、シークレットは履歴からアクセス可能なままです。

まず.envを.gitignoreに追加

新しいプロジェクトでコードを1行も書く前に、.envを.gitignoreに追加してください。これが最初に作成すべきファイルです：

# .gitignore

# 環境ファイル - 絶対にコミットしない
.env
.env.local
.env.development.local
.env.test.local
.env.production.local

# ただしexampleテンプレートはコミットする
# !.env.example

.envが既にコミットされてしまった場合

.envファイルが既にリポジトリにコミットされている場合、以下の手順を直ちに実行してください：

1. 公開されたすべてのクレデンシャルを即座にローテーション。リポジトリが公開か非公開かに関わらず、そのファイル内のすべてのシークレットは漏洩したとみなす必要があります。APIキーの無効化、パスワードの変更、トークンのローテーションを行ってください。
2. ファイルをgitの追跡から削除：git rm --cached .env
3. .envを.gitignoreに追加してその変更をコミット。
4. 履歴を書き換えてファイルを除去。小規模リポジトリにはBFG Repo Cleanerを使用。機密性の高い履歴のリポジトリにはgit filter-repoを検討。
5. クリーンな履歴を強制プッシュ：git push --force --all
6. リポジトリが公開されていた、またはフォーク・クローンされている場合、履歴の書き換え後もシークレットは永久に漏洩していると想定してください。

.env.exampleテンプレートを作成

.env.exampleファイル（.env.sampleや.env.templateとも呼ばれる）は、.gitignoreエントリの補完です。アプリケーションに必要なすべての変数を、実際の値を公開せずにドキュメント化します。このファイルはリポジトリにコミットすべきです。

# .env.example
# このファイルを .env にコピーして値を入力してください
# .env は絶対にコミットしない — このファイルのみコミット

# Application
NODE_ENV=development
PORT=3000
APP_URL=http://localhost:3000

# Database — DBAまたはクラウドコンソールからクレデンシャルを取得
DATABASE_URL=postgres://user:password@localhost:5432/mydb

# Stripe — dashboard.stripe.com/apikeys で確認
STRIPE_PUBLIC_KEY=pk_test_your_key_here
STRIPE_SECRET_KEY=sk_test_your_key_here

# OpenAI — platform.openai.com/api-keys で確認
OPENAI_API_KEY=sk-your_openai_key_here

.env.exampleのベストプラクティス：

• アプリケーションの実行に必要なすべての変数を例外なく含める。
• 実際の値の取得先がわかるプレースホルダー値を使用する（例：空文字列ではなくsk_test_your_key_here）。
• 自明でない変数やクレデンシャルの取得先を説明するコメントを追加する。
• 実際の.envファイルと同期を保つ — 変数を追加・削除する際は更新する。
• 任意で安全な非シークレットのデフォルト値（PORT=3000など）を含め、新しい開発者がすぐに開始できるようにする。

本番環境でのシークレット管理

不都合な真実：本番環境では.envファイルを使用すべきではありません。ディスク上のファイルはスケールでシークレットを管理する方法としては不適切です。誤ってログに記録されたり、コンテナイメージに含まれたり、侵害されたプロセスに読み取られたり、廃棄されたサーバーに残されたりする可能性があります。

本番ワークロードには専用のシークレットマネージャーを使用してください：

本番環境のパターンは、デプロイメントに.envファイルを同梱するのではなく、オーケストレーター（Kubernetes Secrets、ECSタスク定義、Fly.io secrets）経由でコンテナ起動時に環境変数としてシークレットを注入することです。

フレームワーク固有の.env読み込み

ほとんどのモダンフレームワークは基本的な.envフォーマットを独自の規則で拡張しています。これらを理解することで「なぜ変数がundefinedなのか？」というバグを防げます：

Next.js

Next.jsは以下の優先順位で変数を読み込みます：.env.local > .env.[environment] > .env。NEXT_PUBLIC_プレフィックスが付いた変数のみがブラウザに公開されます。それ以外はすべてサーバーサイドのみです：

# サーバーのみ（ブラウザに送信されない）
DATABASE_URL=postgres://...
OPENAI_API_KEY=sk-...

# ブラウザバンドルに公開（注意して使用）
NEXT_PUBLIC_APP_URL=https://myapp.com
NEXT_PUBLIC_STRIPE_KEY=pk_live_...

Vite

ViteはVITE_プレフィックスでクライアントサイドコードに変数を公開します。プレフィックスなしの変数はvite.config.js内でのみ利用可能で、アプリコードからはアクセスできません：

# vite.config.js でのみアクセス可能
SOME_BUILD_CONFIG=value

# クライアントコードで import.meta.env.VITE_API_URL としてアクセス可能
VITE_API_URL=https://api.myapp.com
VITE_APP_TITLE="My App"

Create React App (CRA)

CRAはすべてのカスタム変数にREACT_APP_プレフィックスを必要とします。このプレフィックスのない変数は無視されます：

# process.env.REACT_APP_API_URL として利用可能
REACT_APP_API_URL=https://api.myapp.com
REACT_APP_VERSION=1.0.0

# CRAに無視される（プレフィックスなし）
# SECRET_KEY=this-wont-be-bundled

.envファイルを検証する

経験豊富な開発者でも.envファイルでミスを犯します — クォートの欠落、誤ってコミットされたシークレット、間違った命名規則の変数など。ステージングや本番環境にプッシュする前に、クイック検証を実行することをお勧めします。

当社のENV インスペクターツールは、.envファイルをブラウザ内で完全にチェックします（サーバーサイド処理ゼロ）。キー名パターンによる公開シークレットの検出、スペースを含む未クォート値や無効なキー名などのフォーマット問題のフラグ、シークレットを秘匿した安全な.env.exampleの自動生成が可能です。

関連開発者ツール

• JWTデコーダー — ブラウザでJSON Web Tokenをデコード・検証
• Docker Composeジェネレーター — 環境変数サポート付きのdocker-compose.ymlファイルをスキャフォールド
• ハッシュジェネレーター — パスワードやトークン用のSHA-256などのハッシュを生成
• 全ての無料開発者ツールを見る