🐺

Vibe coding に .env は使わない

に公開
Security
Claude Code
Codex
tech

対象

  • .env に API キーを入れてそのまま開発している
  • セキュリティーを意識して、Vibe Coding を行いたい方

はじめに 　~.envはなんで危ない？~

🧑‍💻：「.env 読まないでね」
🤖：「かしこまりました！ では .env を読み込みます」

ではでは、.envを読み込まれるとなにが問題なの？

AIに.env を読まれると機密情報が学習されることが真っ先に思い浮かびますが、

実際問題になるのは、学習よりも前の段階で
機密情報(.env)がAIとその周辺のツールの処理に乗ることです。
(もちろん、AIエージェントの設定で学習されるリスクもあります)

具体的に何が起きるのか

.env を AI が読める状態にしていると、以下のようなリスクがあります。

1. 生成コードへの埋め込み

「この API を使って通信処理を書いて」と依頼した際に、.env から読み取った値がハードコードされたコードが生成されること

2. ログ・履歴への漏出

AI エージェントの実行ログやデバッグ出力に、環境変数の値がそのまま含まれるケースがあります。

[Agent] Reading file: .env
[Agent] Found: OPENAI_API_KEY=sk-proj-abc123...
[Agent] Executing: curl -H "Authorization: Bearer sk-proj-abc123..."

ログファイルは .gitignore されていないこともあり、
気づかずリポジトリに含めたり、チャットに貼ったりするリスクがあります。

3. コンテキストへの混入

CLAUDE.md や AGENTS.md に「.env を読むな」と書いたとしても、
コンテキスト収集やツール利用の過程で .env が参照される可能性をゼロにはできません。

解決の方向性　~秘密情報をファイルから切り離す~

根本的な対策は、
秘密情報をローカルファイルとして持たないこと です。

大事なのは、

  • .env をうまく隠すこと
  • AI に読まないようお願いすること

ではなくて、

  • そもそも秘密情報ファイル(.env)をプロジェクト内に置かないこと
  • 必要なときだけ実行時に注入すること

解決策: Infisical を使う

いろんなサービスがあるのですが、Infisical を使ってます。

Infisical はオープンソースのシークレット管理ツールで、ローカル開発時にも CLI 経由で環境変数を注入できるので、.env をプロジェクト直下に置かずに開発できます。

何が変わるのか

.env 運用 Infisical 運用
秘密情報の保存場所 プロジェクト内のファイル Infisical サーバー
AI エージェントからの可視性 読める 読めない
チーム共有 .env を手動コピー 招待するだけ
環境の切り替え ファイルを差し替え --env フラグ
監査ログ なし あり

Infisical 以外の選択肢

「.env を置かない」という考え方を実現できるツールは他にもあります。

ツール 特徴
Infisical OSS、セルフホスト可、CLI が手軽
Doppler SaaS 型、チーム向け、CI/CD 連携が豊富
1Password CLI 既に 1Password を使っているなら導入コストが低い
direnv + 外部ストア 軽量、既存ワークフローに組み込みやすい
AWS Secrets Manager / GCP Secret Manager クラウドインフラと統合したい場合に最適

どれを選ぶかはチームの状況次第ですが、共通するのは 「ローカルにシークレットファイルを置かない」 という設計思想です。

Discussion