Laravel .env管理②
投稿日:2026/01/30
本記事では、Laravel実務での基準として
.env に 置いていいもの・ダメなもの を具体例付きで解説します。
✅ .env に置いていいもの
① 環境ごとに値が変わるもの
| 例 | 理由 |
|---|---|
| APP_ENV | 環境判定に必要 |
| APP_DEBUG | 本番では必ず false |
| APP_URL | 環境ごとに異なる |
APP_ENV=production
APP_DEBUG=false
APP_URL=https://example.com
② 認証情報・機密情報
これは必須で .env 管理すべきものです。
- DB接続情報
- APIキー
- OAuth情報
- SMTP認証情報
DB_HOST=127.0.0.1
DB_DATABASE=app_db
DB_USERNAME=app_user
DB_PASSWORD=secret
STRIPE_SECRET_KEY=sk_xxxxx
- ✅ Git管理しない
- ✅ 外部に漏れてはいけない
③ 外部サービスの設定値
MAIL_MAILER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
S3_BUCKET=my-app-bucket
S3_REGION=ap-northeast-1
外部サービスは 環境ごとに差分が出やすい ため、.env 向きです。
④ 本番・検証で切り替えたいフラグ
FEATURE_NEW_UI=true
ENABLE_PAYMENT=false
- 機能ON/OFF
- 段階的リリース
- 一時的な無効化
👉 Feature Flag用途 はOK
❌ .env に置いてはいけないもの
① ビジネスロジックに関わる定数
❌ NG例:
TAX_RATE=0.1
MAX_LOGIN_COUNT=5
理由:
- ロジックが分散する
- コードを見ても意味が分からない
- テストしづらい
✅ 正解例:
// config/constants.php
return [
'tax_rate' => 0.1,
];
② 環境によって変わらない固定値
PAGINATION_LIMIT=10
全環境で同じなら config / 定数 に定義する。
.env に入れると、
- 管理コストが増える
- 設計意図が不明になる
③ 表示文言・メッセージ
ERROR_MESSAGE_LOGIN_FAILED=ログインに失敗しました
これは 完全にNG です。
理由:
- 翻訳・多言語対応不可
- 設定ファイルの役割を逸脱
👉 lang/ja/*.php に定義する。
④ 条件分岐のためだけの魔法の数値
STATUS_ACTIVE=1
STATUS_INACTIVE=0
これは ハードコーディングを.envに逃がしただけ です。
👉 Enum / 定数クラスを使うべき。
⑤ env() を直接コードで使う前提の値
❌ NG:
$timeout = env('API_TIMEOUT');
理由:
config:cache後に壊れる- 本番でハマりがち
✅ 正解:
// config/services.php
'timeout' => env('API_TIMEOUT', 30),
$timeout = config('services.example.timeout');
よくある勘違い
「とりあえず.envに入れれば安全」
👉 ✕
- 設計が崩れる
- 後から意味不明になる
- チーム開発で事故る
「数値だから.envでいい」
👉 ✕
環境差分があるか? が判断基準です。
判断に迷ったときの基準
次の3つで判断すると失敗しません。
✅ .env に置いていいかのチェックリスト
- 環境ごとに変わる?
- 外部に漏れてはいけない?
- インフラ・設定寄りの値?
→ YESなら.env
❌ 置かないほうがいいチェック
- ビジネスロジックに関係する?
- アプリの仕様そのもの?
- コードを見ないと意味が分からない?
→ YESなら.env以外
おすすめ構成まとめ
.env ← 機密・環境差分
.env.example ← 雛形
config/*.php ← 設定値
app/Constants ← 定数・Enum
lang/ ← 文言
まとめ
.env は 便利な逃げ場所ではなく、責任ある設定置き場 です。
- 何でも.envに入れない
- 意味のある設計を保つ
- 本番事故を未然に防ぐ