最近、X で話題になった「Claude Code が .env を読み込んで認証情報が漏洩し、広告アカウントが乗っ取られた」という事件がありました。
この騒動を見ながら、「そもそも .env って、いつからみんなが当たり前のようにプロジェクトルートに置くようになったんだっけ？」と、ふと歴史が気になりました。

この記事では、

  • .env 文化がどのように生まれ、広がってきたのか
  • そして生成AI時代にその前提がどう崩れつつあるのか

という流れで整理してみます。

.env が生まれる前：環境変数と設定ファイルの世界

.env そのものは比較的新しい文化ですが、「環境変数」という概念はものすごく古くから存在しています。

  • Unix 系 OS では 1970年代から環境変数がありました
  • Windows / DOS でも 1980年代から環境変数は普通に使われていました

ただし、この頃の「環境変数」は、あくまで OS／シェルレベルの仕組みであって、

  • シェルの設定ファイル (.bash_profile や .bashrc)
  • アプリケーションごとの設定ファイル (config.ini, settings.yml など)

と組み合わせて運用されるのが一般的でした。

いま私たちがイメージするような「アプリケーションごとに .env を置き、そこから環境変数をロードする」というスタイルは、2000年代前半にはまだ主流ではなかったと言えます。

2010年代前半：Heroku と 12-factor と .env

転機になったのは、PaaS の代表格である Heroku と、いわゆる「12-factor app」の考え方です。

12-factor app（Twelve-Factor App）は、Heroku のエンジニアがまとめた「クラウド前提の Web / SaaS アプリをどう設計・運用すべきか」という 12個のベストプラクティス集です。

12-factor では、アプリケーションの設定（特にシークレットや接続情報）は、

  • コードとは分離し、
  • 環境変数として注入する

ことが推奨されました。

しかし、ローカル開発では「環境変数をいちいち手で export する」のは非常に面倒です。
ここで登場したのが、アプリケーション起動時に「.env ファイルから環境変数をまとめて読み込む」というパターンです。

この流れの中で、

  • Heroku 系ツール（Foreman など）が .env を扱い始める
  • それを受けて各言語向けに「dotenv」ライブラリが整備されていく

という形で、.env 文化が一気に広がっていきました。

各言語での「dotenv」ブーム

2010年代前半〜中盤にかけて、主要な言語で「dotenv」系のライブラリが出そろい、事実上の標準のような扱いになっていきます。

Ruby / Rails

  • Ruby では dotenv gem が登場し、Rails プロジェクトで .env を読み込む運用が広まりました
  • 特に Heroku や 12-factor を意識した Rails デプロイでは、「本番では環境変数、開発では .env」という構成が自然な選択だったため、一気に浸透していきます

Node.js / JavaScript

  • Node.js では motdotla/dotenv が登場し、require('dotenv').config() という一行で .env を読む書き方が「お約束」のように使われるようになりました
  • Express.js、Create React App、Next.js などのフレームワークも、.env を前提にした設計／ドキュメントを提供しはじめ、「とりあえずプロジェクトルートに .env」が半ば常識化していきます

Python / PHP など

  • Python では python-dotenv などが登場し、Flask や Django の開発環境で .env を読むのが定番パターンに
  • PHP では vlucas/phpdotenv が広まり、Laravel プロジェクトで .env が完全にデフォルトの存在になりました

こうして 2010年代半ばには、

「モダン Web アプリなら、だいたいプロジェクトルートに .env を置く」

という文化が、言語をまたいで共有されるようになりました。

「プロジェクトルートに置く」前提の問題

ここで一度、当時の前提を整理してみます。

  • ローカル開発環境は「自分のマシン」
  • .env ファイルは「ローカルだけで使う秘密の設定」
  • 本番環境には .env をコピーせず、環境変数だけを設定する（あるいは別の仕組みで注入する）

この前提がある限り、

  • .env がプロジェクトルートにあっても、
  • 読むのはアプリケーションのランタイム（サーバプロセス）だけであり、
  • それ以外の「第三者」が .env にアクセスするシナリオはあまり想定されていませんでした。

Git へのコミットさえ気をつけていれば、基本的には「ローカルマシン上の秘密ファイル」として成立していたわけです。

生成AI時代：プロジェクトルートは「AI の視界」のど真ん中

ところが、2020年代半ばにかけて登場したのが、Claude Code のような生成AIベースのコーディングアシスタントです。

これらのツールは、

  • エディタや IDE、ブラウザ上で動き
  • プロジェクト全体をスキャンしてコンテキストを作り
  • その情報をクラウド上の LLM に送信して補完やリファクタリングを行う

というアーキテクチャを取ることが多いです。

ここで問題になるのが、

「AI に見える範囲」と「自分が安全だと思っている範囲」がズレている

という点です。

多くのツールは、「カレントディレクトリ配下のファイルは AI が参照可能」という形でサンドボックスを敷いています。
つまり、プロジェクトルートに .env を置いている限り、

  • 人間のつもりでは「ここはローカルだけの秘密の設定ファイル」
  • ツールの視点では「解析対象のコードと同じ階層にある普通のファイル」

になってしまうのです。

実際に起きている事故：.env を読まれる・送られる・漏れる

先述の X で話題になったケースのように、Claude Code をはじめとする AI コーディングアシスタントが、

  • .env ファイルを自動的に読み込む
  • その内容をログなどの形で出力してしまう
  • ログ経由で認証情報が漏洩し、外部から悪用される

という事故が、すでに現実世界で発生し始めています。

さらに厄介なのは、

  • .gitignore やツール独自の ignore 設定に .env を書いていても、
  • 実装やバグによって、その設定が無視されてしまうケースがある

という点です。

開発者側は「このフォルダ以下しか見えないようにしているから大丈夫」と思っていても、
AI アシスタントは「そのフォルダ以下は全部スキャン対象」として振る舞うため、

「フォルダ単位のガードレール」では守りきれない

ことが、徐々に明らかになってきています。

心理モデルのアップデート：「AI はリモート共同開発者」

ここで、前提をまるごとアップデートした方が早いと感じています。

  • 旧来の前提：
    • 開発環境はローカル
    • .env はローカル専用の秘密ファイル
  • これからの前提：
    • エディタや CLI はクラウドと常時つながっている
    • AI アシスタントは「ほぼリモートの共同開発者」
    • その共同開発者は、フォルダの中身をかなり自由に読める

このモデルで考えると、

「そのフォルダに置いた時点で、AI にも見られる可能性がある」

とみなすのが安全側の判断になります。

もはや「プロジェクトルートに置いておけば安全」という時代ではなく、

「プロジェクトルートに置いたものは、AI の視界に入る」

と考えるべき時代に移行しつつある、という感覚です。

生成AI時代の新しい .env 運用方針

では、これからどう運用を変えていくべきか。
いくつか現実的なガイドラインを挙げてみます。

1. AI 用ワークスペースに本番秘密を置かない

  • Claude Code や GitHub Copilot などの AI ツールと一緒に使うリポジトリには、原則として本番用シークレットを置かない
  • 開発・検証用のダミーキーやテストアカウントを使う
  • 本番用の認証情報は、別の管理手段（専用の秘密管理サービスや、VPN 内の別リポジトリなど）に分離する

2. .env をプロジェクトルートから物理的に分離する

  • ~/.secrets/ や OS 標準の credential store など、プロジェクトフォルダの外に秘密を置く
  • プロジェクト側からはパスだけを参照し、AI 用ワークスペースにはその実体を入れない

「AI に見えるフォルダ」と「シークレットを置くフォルダ」を物理的に分離する発想です。

3. ツールごとの deny 設定をちゃんと使う（そして信用しすぎない）

  • AI コーディングツールが提供する ignore 設定やパーミッション設定で、.env / secrets/ / keys/ などを明示的にブロックする
  • ただし「設定したから絶対に安心」とは思わず、「それでも漏れる可能性はゼロではない」という前提で運用する

バグや仕様変更で挙動が変わる可能性を常に意識し、仕組みを二重化するイメージを持った方が安全です。

終わりに：.env 文化の更新が必要になってきた

2010年代に普及した .env 文化は、

  • 12-factor app の思想と
  • PaaS 時代の開発フロー

に非常にマッチした、素晴らしい設計でした。

しかし、2025年の生成AI時代に入り、

  • 「プロジェクトルートに置いておけば安全」という暗黙の前提が崩れつつある
  • 「AI の視界」を前提にしたセキュリティ設計に切り替える必要が出てきた

という現実が見え始めています。

これから私たちがやるべきことは、
.env をやめる／悪者扱いすることではなく、

「.env をどこに置くのが安全なのか」
「どのフォルダに何を置いたら AI から見えるのか」

というメンタルモデルと運用ルールをアップデートすることだと思います。

生成AIと一緒に開発するのが当たり前になった今、
「プロジェクトルート」と「AI の視界」を意識した設計に、そろそろ本気で移行していきたいですね。