SNSで話題の「.envにシークレットを書くな」論を検証。業界標準の.envファイルが抱えるリスクと、規模別に最適なシークレット管理の選び方を解説します。
「.envに書くな」という主張、あなたはどう受け止めましたか？
こんな経験はないでしょうか。
「.envにAPIキーやDBパスワードを書くのは危険だ」「本番環境ではSecrets Managerを使うべきで、.envはその参照先を書くだけにしろ」——SNSでそんな投稿を見かけて、「自分の運用って大丈夫なのか…？」と不安になった。
LaravelやNext.jsで開発しているエンジニアであれば、.envファイルは日常的に触れるものです。フレームワークの公式ドキュメントにも当たり前のように登場する。それなのに「書くな」と言われると、何が正しいのかわからなくなりますよね。
この記事では、「.envにシークレットを書くな」という主張は正しいのか、それとも極論なのかを多角的に検証します。.envセキュリティの実態、シークレット管理の代替手段、そして2026年時点のベストプラクティスを整理した上で、「あなたの規模では何が最適か」を判断できるようにまとめました。
結論を先に言うと——「.envに書くな」は一理あるが、全員に当てはまる話ではない。重要なのは「どこに置くか」の議論よりも「漏洩経路を塞ぐこと」です。
SNSで広まった論点を整理する
今回話題になった主張を整理すると、大きく2つのポイントに分かれます。
主張①：.envはグローバルで公開できる設計にすべき
「秘匿情報を.envに書かなければ、.envをGitで管理しても問題ない」という考え方です。ローカル開発では即座にローテーション可能なキーを使い、本番環境ではAWS Secrets ManagerのようなシークレットストアにAPIキーやDBパスワードを登録する。.envには「どのシークレットストアを参照するか」という設定だけを書く、というアプローチです。
主張②：環境変数はそもそも安全ではない
.envファイルに限らず、環境変数として展開された値は平文でプロセスから読み取れるため、根本的にセキュアではないという批判です。
どちらの主張も、エンタープライズ規模のセキュリティ要件から出発している点に注意が必要です。正しい部分もありますが、すべての開発者に当てはまるかというと、話は別です。
.envが業界標準である理由
まず前提として確認しておきたいのは、.envファイルは現在も業界標準だという事実です。
- Laravel —
config/database.php等からenv()関数で読み込む設計 - Next.js —
.env.local、.env.production等を公式サポート - Django —
python-decoupleやdjango-environで.envを標準的に利用 - Rails —
dotenv-railsgemが広く使われる
これらのフレームワークは、「設定を環境から分離する」という12-factor appの思想に基づいて設計されています。.envはその実装手段として、開発体験（DX）と移植性のバランスを取った合理的な選択です。
「フレームワーク全体が間違った設計をしている」というわけではありません。設計思想としては正しく、問題は運用の詰めにあるのです。
.envの具体的なリスクを直視する
「.envに書いても問題ない」という楽観論も危険です。.envが抱えるリスクは実在します。
リスク① 平文でプロセスが読める
環境変数として展開された値は、同一ホスト上の別プロセスや、権限を持つユーザーから平文で参照可能です。暗号化されません。
リスク② 漏洩経路が複数ある
2026年時点の調査では、環境変数・.envファイルの主な漏洩経路として以下が挙げられています。
docker execによるコンテナ内確認 —docker exec -it container envで全環境変数が見える- Kubernetesポッド内プロセス —
/proc/1/environから読み取れるケースがある - メモリダンプ — クラッシュレポートやコアダンプに含まれる可能性
- CI/CDビルドログ —
printenvやenvコマンドの出力がログに残る事故が頻発
リスク③ 監査ログがない
「誰がいつその値を読んだか」を追跡する手段がありません。セキュリティインシデント発生時の調査が困難になります。
リスク④ ローテーションが手動
APIキーを定期的に更新しようとすると、.envファイルの手動編集と再デプロイが必要です。自動化が難しく、運用コストが上がります。
よくある事故パターン：GitHubへのpush
.envファイルをうっかりGitにコミットしてしまうケースは、今も後を絶ちません。特に起きやすいのは以下の状況です。
- 新しいリポジトリを作ったとき、
.gitignoreの設定を後回しにした - フロントエンドとバックエンドでリポジトリを分けたとき、片方の
.gitignoreに追加し忘れた .env.exampleを複製して.envを作ったが、.env自体をコミットしてしまった- GitHub Actionsのworkflowファイル内で
cat .envを実行し、ログに平文が出力された
GitHubに一度pushされた.envは、git rmで削除してもコミット履歴に残ります。即座にすべてのキーをローテーションしてください。
「.envには参照先だけ書く」アプローチの評価
SNSで提案されていた「ローカルではローテーション可能なキー、本番ではSecrets Managerでキー管理し、.envにはその参照先だけを書く」というアプローチを評価してみます。
# .env（参照先のみ記載する例）
APP_ENV=production
SECRETS_PROVIDER=aws-secrets-manager
SECRETS_ARN=arn:aws:secretsmanager:ap-northeast-1:xxxx:secret:myapp/prod
# .env（従来の直接記載）
DB_PASSWORD=my_actual_password
AWI_SECRET_KEY=AKIAXXXXXXXXXXXXXXXX
このアプローチの評価：
- ✅ .envをGitで管理できる（秘匿情報が含まれないため）
- ✅ Secrets Managerによる監査ログ・自動ローテーションが活用できる
- ✅ 本番環境のセキュリティレベルを大幅に向上できる
- ⚠️ アプリケーションがSecrets Manager SDKを実装する必要がある
- ⚠️ ローカル開発環境でもSecrets Managerへのアクセスが必要（またはモック）
- ❌ 初期構築コストと学習コストが高い
- ❌ AWSロックインが発生する（Secrets Manager使用時）
結論としてエンタープライズ規模では非常に有効なアプローチです。ただし、1〜3人のチームで個人ブログやコーポレートサイトを管理している環境に同じ要件を求めるのは、コストと複雑性の観点から過剰です。
代替手段の比較
現在利用可能なシークレット管理の選択肢を整理します。
| 手段 | セキュリティ | コスト | 複雑性 | 監査ログ | 推定導入率 |
|---|---|---|---|---|---|
| .env直接記載 | △ 平文・手動 | 無料 | 低 | なし | 〜70% |
| .env参照のみ | ○ 分離設計 | 中〜高 | 中 | Secrets Manager依存 | 〜5% |
| AWS Secrets Manager | ◎ 自動ローテーション | 従量課金 | 高 | CloudTrail連携 | 〜10% |
| HashiCorp Vault | ◎ フル機能 | OSS/有料 | 非常に高 | 完全対応 | 〜3% |
| Doppler | ○ SaaS型 | 無料〜月額 | 中 | あり | 〜2% |
| dotenvx | ○ 暗号化.env | 無料 | 低〜中 | なし | 〜1% |
重要な現実： 2026年時点の調査では、AWS Secrets ManagerやVaultなどのシークレットストアを本番環境で導入している組織は、世界でわずか10%程度に留まっています。残りの90%は何らかの形で環境変数や.envファイルを直接使用しているのが実態です。
「Secrets Managerを使わないのは間違いだ」という主張は、世界の9割の開発現場を「間違い」と断じることになります。それは現実的ではありません。
2026年のベストプラクティス：ハイブリッドアプローチ
ハイブリッドアプローチとは
2026年時点のセキュリティベストプラクティスとして提唱されているのは、「すべてをSecrets Managerに移行する」でも「すべてを.envで管理する」でもなく、情報の種類に応じて使い分けるアプローチです。
設定値（公開可能・ローリスク）→ .envで管理
- ログレベル（
LOG_LEVEL=debug） - アプリケーション名
- 公開用トラッキングID（Google Analytics測定IDなど）
- タイムゾーン、ロケール設定
- キャッシュTTL、ページネーション件数
認証情報（高リスク）→ Secrets Manager推奨
- DBパスワード
- APIシークレットキー（決済、外部サービス）
- JWTシークレット
- SSHキー、TLS秘密鍵
この分類を徹底するだけで、.envに含まれる情報が仮に漏洩しても、実害を大幅に抑えられます。
ただし「推奨」と「必須」は違います。段階的なマイグレーションが推奨されており、今すぐすべてをSecrets Managerに移行しなければならないわけではありません。
規模別の推奨アプローチ
「あなたの規模では何が最適か」を判断するための指針を示します。
規模別の推奨アプローチ
個人・少人数（1〜3人）
推奨：.env + .gitignore + WAFブロック + 基本防御
.envを.gitignoreで確実に除外し、.env.example（ダミー値のみ）をリポジトリで管理する。本番サーバーへのアクセス制限と、.envファイルへのWebアクセスをNginx/Apacheでブロックする。これで十分なケースが大半です。
Secrets Managerの導入コスト（学習・運用・費用）は、このフェーズでは費用対効果が合いません。
中規模チーム（5〜20人）
推奨：.env + CI/CDのシークレット管理（GitHub Secrets等）
CI/CDパイプラインのシークレット機能（GitHub Actions Secrets、GitLab CI Variables）を活用し、デプロイ時に環境変数を注入する。本番サーバーの.envには直接記載せず、デプロイスクリプトが生成する運用にする。
このフェーズではDoppler（SaaS型シークレット管理）の導入も費用対効果が出やすくなります。
大規模・エンタープライズ（20人以上・高リスクデータ）
推奨：AWS Secrets Manager / HashiCorp Vault + ハイブリッドアプローチ
個人情報・決済情報を扱う場合、監査ログと自動ローテーションは必須要件に近い。Secrets Managerへの投資が正当化されます。セキュリティ要件（PCI DSS、ISO 27001等）がある場合は特に重要です。
flowchart TD
A[あなたのプロジェクト] --> B{チーム規模は？}
B -->|1〜3人| C[個人・少人数]
B -->|5〜20人| D[中規模チーム]
B -->|20人以上| E[エンタープライズ]
C --> C1[.env + .gitignore\n+ WAFブロックで十分]
D --> D1[.env + GitHub Secrets\n+ Doppler検討]
E --> E1[Secrets Manager / Vault\n+ ハイブリッド設計]
C1 --> F{個人情報・決済を扱う？}
F -->|Yes| D1
F -->|No| G[現状維持でOK].envを安全に運用するための具体的チェックリスト
Secrets Managerを使わない場合でも、これらを実施することで.envセキュリティを大幅に向上できます。
Nginxでの.envアクセスブロック例
# .envファイルへの直接アクセスを拒否
location ~ /\.env {
deny all;
return 404;
}
.gitignoreの最低限の設定
# 環境設定ファイル
.env
.env.local
.env.*.local
.env.production
# .env.exampleはコミット対象（ダミー値のみ含む）
!.env.example
よくある質問
まとめ：極論に振り回されず、自分の規模に合った選択を
「.envにシークレットを書くな」という主張を改めて評価すると——
- 正しい部分：.envの漏洩リスクは実在する。Secrets Managerは監査・ローテーション面で優れている。認証情報を設定値から分離する設計思想は正しい。
- 言い過ぎな部分：世界の90%の組織が採用している運用を「間違い」と断じるのは現実的ではない。コストと複雑性を無視した主張は、特に個人・少人数チームには害になる。
最も大切なのは「どこに置くか」の議論ではなく、「漏洩経路を塞ぐこと」です。
.gitignoreの徹底、Webサーバーでのアクセスブロック、ファイルパーミッションの設定、キーのローテーション習慣——これらを確実に実施することで、多くの現場で十分なセキュリティレベルを達成できます。その上で、チームの規模や扱うデータの性質に応じて、Secrets Managerへの段階的な移行を検討してください。
SNSの議論は往々にして「自分が経験した規模の常識」を全員に押し付けがちです。エンタープライズで通用する設計を、個人開発者に求める必要はありません。逆に、個人開発の感覚でエンタープライズを運用するのも危険です。
「あなたの規模で、今できる最善を選ぶ」——それが、2026年の現実的なシークレット管理の答えです。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まず今日やるべきこと
記事を読んで「うちの.env運用、見直したい」と思ったら、まずこの3つから始めてください。
git log --all --full-history -- .envを実行して、過去に.envがコミットされていないか確認する.gitignoreを見直して.envが除外されているか確認する- 本番サーバーのNginx/Apache設定で
.envへのWebアクセスをブロックする
これだけでも、よくある漏洩事故の大半を防げます。
より高いセキュリティ要件への対応や、CI/CDへのシークレット管理の組み込み、Secrets Managerの導入検討など、「うちの規模だと何が最適？」という相談は、ぜひFivenine Designにお声がけください。神奈川を拠点に20年以上、Laravel・WordPress・Next.jsでの開発実績を持つ私たちが、現実的な選択肢を一緒に考えます。
