← 用語集一覧へ戻る

.env

.env
security beginner
環境変数をまとめて書いておくための設定ファイルのこと。
.env (.env)

概要（サマリー）

環境変数をまとめて書いておくための設定ファイルのこと。

プロジェクトのフォルダ内に .env という名前で置かれることが多く、APIキー、データベース接続情報、メール設定などの「環境ごとに変わる値」や「外に出してはいけない秘密情報」をまとめて管理するために使われる。
コードの中に直接パスワードや秘密鍵を書くのではなく、.env に分けて置くことで、コードと機密情報を分離しやすくなる。

ただし、このファイルには本物のパスワードや秘密のキーが入ることが多いため、GitHubなどへ公開してはいけない重要ファイルである。
通常は .gitignore と組み合わせて、誤って公開しないようにする。

詳細解説

.env とは、環境変数をファイル形式でまとめて管理するための設定ファイルである。
読み方はそのまま「ドット・イーエヌブイ」と呼ばれることが多く、dotenv として説明されることもある。
日本語では「ドットエンブ」と呼ばれることもある。

ここでいう「環境変数」とは、プログラムの動作に必要な設定値のうち、コード本体とは分けて持っておきたい情報のことである。
たとえば次のようなものがある。

  • APIキー
  • データベースの接続先
  • データベースのユーザー名
  • データベースのパスワード
  • メール送信設定
  • 本番環境か開発環境かの区別
  • 外部サービスのURL

このような値を、コードの中に直接ベタ書きするのではなく、.env にまとめて置いておくことで管理しやすくする。

なぜ .env が必要なのか

もし秘密情報や環境ごとの設定をコードに直接書いてしまうと、いくつか問題が起きやすい。

  • Git にそのまま残る
  • GitHub に誤って公開しやすい
  • 開発環境と本番環境で値を切り替えにくい
  • 他の人と共有するときに危険
  • 設定変更のたびにコードを触ることになる

そこで .env を使うと、

  • コードと設定を分けられる
  • 機密情報をコード本体から外せる
  • 環境ごとに値を変えやすい
  • 公開してよいコードと、公開してはいけない情報を分離しやすい

というメリットがある。

つまり .env は、
「コードには書きたくない設定値の置き場所」
として非常によく使われる。

どんなイメージで考えればよいか

初心者向けには、次のようなたとえがわかりやすい。

金庫付きの設定メモ

プログラム本体とは別に、重要な設定だけをメモしておく紙のようなもの。
ただし、その紙には秘密情報が書かれているので厳重管理が必要である。

差し替え可能な設定カード

本番用、テスト用、開発用で中身だけ差し替えるイメージ。
プログラム本体は同じでも、カードの内容を変えることで動作先を変えられる。

裏方用の設定表

ユーザーには見せないが、システムを動かすために必要な内部設定をまとめておく場所である。

.env にはどんな書き方をするのか

.env では、一般に次のような形で書かれることが多い。

APP_ENV=local
DB_HOST=127.0.0.1
DB_NAME=myapp
DB_USER=myuser
DB_PASSWORD=secret
API_KEY=xxxxxxxx

基本的には、

項目名=値

の形で1行ずつ書いていくことが多い。

このように書いておくと、プログラム側が .env を読み込み、その値を使って動作できるようになる。

ただし、.env は置くだけで必ず自動的に読み込まれるわけではない。
フレームワーク、ライブラリ、実行環境、設定ファイルなどが .env を読み込む仕組みを持っている場合に、その値を使えるようになる。

どんなときに使われるのか

.env は、特に次のような場面でよく使われる。

1. APIキーの管理

外部サービスのAPIを使うときの秘密キーを入れる。

2. データベース接続

ホスト名、DB名、ユーザー名、パスワードを管理する。

3. メール送信設定

SMTP情報や送信元アドレスなどを入れる。

4. 環境切り替え

開発環境・ステージング環境・本番環境で設定を分ける。

つまり .env は、環境ごとに変わる値 と 公開してはいけない値 の両方を扱うことが多い。

コード本体に書かない理由

初心者がよくやりがちなのが、次のようにコードへ直接書いてしまうことだ。

const apiKey = "xxxxxxxx";

これでも動くが、実務的には危険である。
理由は次の通りである。

  • そのままGitに残る
  • 公開リポジトリで漏れる
  • 環境切り替えが面倒
  • 他人に渡すとき危険
  • AIへコードを見せたときも漏えいする

そのため、秘密情報はコードではなく .env や環境変数へ分離するのが基本になる。

ただし、.env に入れれば必ず秘密になるわけではない。
特にフロントエンドでは、VITE_ や NEXT_PUBLIC_ のような公開前提の接頭辞が付いた値は、ビルド後にブラウザ側から見えることがある。
ブラウザで動くコードに渡す値は、ユーザーに見られる前提で扱う必要がある。

.env と環境変数の関係

ここは少しややこしいが大事である。

  • 環境変数 = プログラムが参照する設定値そのもの
  • .env = その環境変数をファイルとしてまとめて書いておくための方法の1つ

つまり .env は、環境変数そのものではなく、
環境変数を扱いやすくするための保存形式
と考えるとわかりやすい。

プログラムは .env を読み込んで、その内容を環境変数として使うことがある。

.env と .gitignore の関係

.env を使うときに非常に重要なのが .gitignore である。
.gitignore は、「このファイルはGitで管理しない」という指定を書くためのファイルである。

たとえば .gitignore に次のように書いておく。

.env

すると、通常は .env をGitへ含めないようにしやすくなる。
これにより、誤ってGitHubへ公開してしまう事故を減らせる。

つまり .env は単体で安全になるわけではなく、
.gitignore とセットで考えることが多い。

ただし、すでにGitで管理されている .env は、あとから .gitignore に書いただけでは追跡が止まらない。
その場合は、Gitの管理対象から外す作業や、漏れたキーを無効化して再発行する対応が必要になることがある。

本番環境と開発環境での違い

.env の便利な点の1つは、環境ごとに値を変えられることである。

たとえば、

  • ローカルではローカル用DBに接続する
  • 本番では本番用DBに接続する
  • 開発環境ではテスト用APIキーを使う
  • 本番では本番用APIキーを使う

といった切り替えがしやすくなる。

このため、同じコードでも .env の内容を変えることで、
違う環境に対応しやすくなる。

.env.example という考え方

プロジェクトによっては、.env 本体ではなく、.env.example のようなファイルを置くことがある。

たとえば次のような形である。

APP_ENV=local
DB_HOST=
DB_NAME=
DB_USER=
DB_PASSWORD=
API_KEY=

これは「このプロジェクトではこういう設定項目が必要です」という見本であり、実際の秘密値は入れない。
他の人はこれをコピーして .env を作り、自分の環境に合わせて値を埋める。

つまり .env.example は、
中身の項目だけ共有し、本物の秘密情報は共有しないための見本ファイル
としてよく使われる。

.env の注意点

.env は便利だが、いくつか重要な注意点がある。

1. 公開してはいけない

GitHub や共有チャットへ貼るのは危険である。

2. AIにそのまま読ませない方がよい

APIキーやパスワードを含むことが多いため、必要がない限り全文を渡すべきではない。

3. サーバー上での置き場所に注意

公開ディレクトリ直下に置くと危険な場合がある。
環境によってはWebから見えない位置へ置く工夫が必要になる。

4. バックアップや共有方法に注意

気軽に送ると、秘密情報の漏えいにつながる。

AIコーディングで重要な理由

AIコーディングでは、APIやDB、メール設定などを扱うことが多いため、.env の理解はかなり重要である。

たとえばAIが、

  • .env に API_KEY を追加してください
  • DB_HOST を設定してください
  • 本番環境では別の値を使ってください

のように指示してくることがある。

このとき .env の意味が分かっていないと、

  • どこに書けばよいのか分からない
  • コード本体へ書いてしまう
  • そのままGitHubへ上げてしまう
  • 本番用の秘密情報を漏らしてしまう

といった危険がある。

逆に .env を理解していれば、
設定と秘密情報を分けて安全に管理する意識
を持ちやすくなる。

よくある勘違い

.env は公開しても問題ない設定ファイル？

問題ある。
本物のAPIキーやパスワードが入っていることが多く、公開は非常に危険である。

.env = 環境変数そのもの？

完全には同じではない。
.env は、環境変数をファイルで管理するための方法の1つである。

コードに直書きしても動けば問題ない？

動いても安全とは限らない。
後で漏えいや管理のしにくさにつながるため、実務では避けるべきである。

.gitignore に書けば絶対安全？

かなり重要な対策ではあるが、それだけで絶対安全とは言えない。
すでにGitへ入っていた場合は別対応が必要になることもある。

.env に入れれば秘密情報は必ず守られる？

そうとは限らない。
フロントエンドで使う値はブラウザ側に含まれることがあり、サーバー側だけで使う秘密情報とは扱いを分ける必要がある。

AIに .env を全部貼れば早い？

早いことはあっても危険である。
特に本物のキーやパスワードは伏せて扱うべきである。

より詳しくAIに聞いてみよう

  • .env とは何かを、中学生でもわかるように説明してください。
  • 環境変数と .env の違いを初心者向けに整理してください。
  • なぜ APIキーやDBパスワードを .env に入れるのか教えてください。
  • .env と .gitignore の関係を具体例つきで説明してください。
  • .env.example は何のために使うのか、初心者向けに教えてください。
  • フロントエンドの .env に入れてよい値と、入れてはいけない値の違いを教えてください。