📝 .env.example ジェネレーター

実際の .env をペーストすると、コメントと構造を保持したまま値を自動で安全なプレースホルダーに置き換え、Git にコミット可能な .env.example を生成します。

完全無料登録不要ブラウザ完結 5 言語対応ダークモード

🔒 プライバシーは最優先

・入力した .env は一切サーバーに送信されません
・すべての変換はあなたのブラウザ内 (JavaScript) で実行されます
・保存ログ・履歴・データベースは一切存在しません
・それでも心配な方は、ネットワークを切断した状態でも動作します

プリセットコメントを保持ランダムなサンプル値を生成

📥 入力 (.env)

📤 .env.example

➕ フォームから追加

KEY 名とカテゴリを選んで .env.example に追加します。

📖 つまずきやすいポイント

本物の .env を貼り付けると、コメントと構造を保ったまま値だけを安全なプレースホルダーに置き換え、Git にコミットできる .env.example を生成します。処理はブラウザ内で完結し、入力は送信されません。値を置き換えることと、機密が残らないことは別です — コメントの中に本物の値が書かれていれば、そのまま出力に残ります。生成した結果は、コミットする前に必ず自分で読んでください。

ケース	何が起きるか	どうする
コメントの中に本物の値が残る	置き換えの対象は `KEY=VALUE` の値の部分なので、`#` で始まる行はそのまま出力されます。ところが実際の `.env` には、`# 本番は sk-live-abc123 を使う`・`# 旧キー: xoxb-...`・`# 接続先: postgres://user:pass@prod-db.internal:5432` といったコメントの形をした機密が高い確率で含まれています。コメントは「メモ」として書かれるので、値の欄より無防備になりやすいのです。同様に、キー名そのものが情報を持つ場合もあります — `ACME_CORP_API_KEY` という名前は、取引先の名前を公開しています。	生成した `.env.example` を、コミットする前に上から下まで読んでください — とくに「コメントを保持」を有効にしたときは必須です。読む観点は 3 つで — コメントに本物の値が書かれていないか、キー名に取引先名や社内システム名が入っていないか、ホスト名やポート番号が内部構成を明かしていないか。コメントは「なぜこのキーが必要か」を書く場所であって、値を書く場所ではありません — 本物の値をメモしたいなら、それは `.env` 側かパスワードマネージャーに置くべきです。置き換えの前に元の `.env` のコメントを見直しておくと、`.env.example` 側で消す手間が減ります。
キー名だけ並べても新規参加者が動かせない	`.env.example` の目的は「このプロジェクトを動かすには何を設定すればよいか」を伝えることです。ところがキー名とプレースホルダーだけの `.env.example` からは、必要な情報のほとんどが読み取れません — `STRIPE_SECRET_KEY=your_key_here` という 1 行は、どこで取得するのか、テスト用と本番用のどちらか、そもそも必須なのか任意なのかを何も教えてくれません。結果として、新しく参加した人は既存メンバーに聞くことになり、`.env.example` があること自体が形骸化します。	各キーの上に 1 行のコメントを書いてください — 書くべきは「どこで取得するか」「必須か任意か」「値の形式」の 3 点です。`# Stripe ダッシュボード > 開発者 > API キー。テスト環境では sk_test_ で始まるものを使う。必須。` という 1 行があれば、それだけで新規参加者が自分で解決できます。任意のキーには既定値も書いてください — `# 省略時は 3000` のように。この作業の価値は、実は既存メンバーにとってのほうが大きいです — 半年後に環境を作り直すとき、あるいは本番の設定を見直すときに読むのは、たいてい書いた本人だからです。「新規参加者のため」と思って書いたものが、いちばん自分を助けます。
.env.example を作ったのに .env がコミットされている	`.gitignore` に `.env` と書いても、既に追跡されているファイルには効きません — `.gitignore` は「まだ追跡していないファイルを無視する」設定なので、過去に一度でも `git add` したファイルは、以後も変更が追跡され続けます。もう 1 つよくあるのが除外の書き方で、`.env` と書くと `.env.example` まで無視され、せっかく作った雛形がコミットされません* — 「リポジトリに `.env.example` が無い」という状態は、この設定ミスであることが多いです。	除外は 2 行で書いてください — `.env` の次の行に `!.env.example` を置きます (否定の順序が重要で、除外の後に書かないと効きません)。既に追跡されている場合は `git rm --cached .env` で追跡だけを外します* — ファイル自体は手元に残ります。確認は `git ls-files \| grep env` が確実で、`.env.example` だけが出てくるのが正しい状態です。そして最も重要なこと — 過去のコミットに `.env` が含まれていた場合、履歴を書き換えても対処にはなりません。フォーク・CI のログ・他人のローカルクローン・GitHub のキャッシュに残るため、唯一の正しい対処はそのキーを無効化して再発行することです — 気付いた時点で、履歴の整理より先に実行してください。

.env という仕組み自体に限界があることも知っておいてください。まず改行を含む値を表現できません — 秘密鍵や証明書を入れようとすると、必ずここで詰まります (回避策は Base64 にして 1 行にすることですが、これは .env の限界を認めたうえでの妥協です)。次に型がありません — すべて文字列なので、DEBUG=false は文字列の "false" であり、多くの言語で真と評価されます。そして環境ごとの差分を管理する仕組みがありません — 開発・ステージング・本番で .env を別々に持つと、キーが増えたときに全部を手で同期することになります。本番環境では、.env ではなく Secret Manager (AWS Secrets Manager・Google Secret Manager・HashiCorp Vault) を使ってください — アクセス制御・監査ログ・自動ローテーションという、.env には原理的に無い機能が必要になるのは、たいてい本番だけだからです。開発環境は .env のままで構いません。

📖 使い方

1

実際の .env をペースト

左側のテキストエリアに本物の .env をそのまま貼り付け。プリセットから始めることもできます。
2

自動でサニタイズ

PASSWORD/SECRET/TOKEN/KEY を含むキーはランダムなプレースホルダーに、URL は example.com に、PORT は 3000 等の代表値に自動置換。
3

コミット可能なファイルを取得

右側の出力をコピー、または .env.example としてダウンロードして git add -> commit。

❓ よくある質問

入力した .env は本当にサーバーに送信されませんか？

はい。すべて JavaScript でブラウザ内処理されます。ブラウザの開発者ツールの Network タブで送信が無いことを確認できます。心配な方はオフラインでも使用可能です。

どのキーがシークレットとして検出されますか？

キー名に PASSWORD / SECRET / TOKEN / KEY / API_KEY / PRIVATE / CREDENTIAL を含むものを自動でシークレットとして扱い、ランダムなサンプル値に置換します。

コメントや空行は保持されますか？

はい。グルーピング用のセクションコメントや空行はそのまま出力されます。「コメントを保持」をオフにすると除去できます。

🔗 関連ツール

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。