brand logo

ドキュメント

.env

.env ファイルはビルド/開発時の環境変数を指定します。

このファイルは、リポジトリに秘密情報をプッシュしないようにするために、.gitignore ファイルに追加する必要があります。

開発、ビルド、生成時

Nuxt CLI は、開発モードおよび nuxt buildnuxt generate を実行する際に、dotenv のサポートを組み込んでいます。

プロセス環境変数に加えて、プロジェクトのルートディレクトリに .env ファイルがある場合、開発、ビルド、生成時に自動的に読み込まれます。そこに設定された環境変数は、nuxt.config ファイルやモジュール内でアクセス可能です。

.env
MY_ENV_VARIABLE=hello

.env から変数を削除したり、.env ファイルを完全に削除したりしても、すでに設定された値は解除されないことに注意してください。

カスタムファイル

異なるファイルを使用したい場合、例えば .env.local.env.production を使用する場合は、Nuxt CLI を使用する際に --dotenv フラグを渡すことで実現できます。

Terminal
npx nuxt dev --dotenv .env.local

開発モードで .env を更新すると、Nuxt インスタンスは自動的に再起動され、新しい値が process.env に適用されます。

アプリケーションコード内では、プレーンな環境変数の代わりに Runtime Config を使用するべきです。

本番環境

サーバーがビルドされた後、サーバーを実行する際に環境変数を設定する責任があります。

この時点では .env ファイルは読み込まれません。これを行う方法は環境ごとに異なります。

この設計上の決定は、サーバーレスプラットフォームや Cloudflare Workers のようなエッジネットワークなど、従来のファイルシステムが利用できない可能性のあるさまざまなデプロイ環境との互換性を確保するために行われました。

本番環境では .env ファイルが使用されないため、ホスティング環境が提供するツールや方法を使用して環境変数を明示的に設定する必要があります。一般的なアプローチは以下の通りです:

  • 環境変数を引数としてターミナルで渡すことができます:

    $ DATABASE_HOST=mydatabaseconnectionstring node .output/server/index.mjs

  • .bashrc.profile のようなシェル設定ファイルに環境変数を設定することができます。

  • Vercel、Netlify、AWS などの多くのクラウドサービスプロバイダーは、ダッシュボード、CLI ツール、または設定ファイルを介して環境変数を設定するためのインターフェースを提供しています。

本番プレビュー

ローカルでの本番プレビュー目的には、nuxt preview を使用することをお勧めします。このコマンドを使用すると、.env ファイルが process.env に読み込まれるため便利です。このコマンドは、パッケージディレクトリに依存関係がインストールされている必要があります。

または、ターミナルを使用して環境変数を引数として渡すこともできます。例えば、Linux や macOS では:

Terminal
DATABASE_HOST=mydatabaseconnectionstring node .output/server/index.mjs

純粋に静的なサイトの場合、プロジェクトが事前レンダリングされた後にランタイム設定を行うことはできません。

こちらも参照 guide > going-further > runtime-config

ビルド時に設定された環境変数を使用したいが、後でそれらを更新することを気にしない(またはアプリ内でのみ反応的に更新する必要がある)場合は、appConfig がより適した選択肢かもしれません。appConfig は、nuxt.config 内(環境変数を使用して)およびプロジェクト内の ~/app.config.ts ファイル内の両方で定義できます。

こちらも参照 guide > directory-structure > app-config

tips

このセクションは公式ドキュメントの翻訳ではなく、本サイト独自の補足記事です。

はじめに:Nuxtにおける環境変数管理の重要性

Nuxtでの開発や運用において、環境変数は設定や挙動を柔軟に切り替えるために欠かせません。.envファイルは、開発やビルド時に環境変数を簡単に管理できる便利な仕組みですが、Nuxtの特性や本番環境での挙動を理解しないと、思わぬトラブルやセキュリティリスクにつながることもあります。

本記事では、Nuxt公式ドキュメントの補足として、.envファイルの基本的な使い方から、実務での活用例、注意すべきポイントまでを詳しく解説します。初〜中級者の方が安心して環境変数を扱えるよう、具体的なコード例や運用のコツも交えて紹介します。


まず結論:Nuxtの.envファイル活用のポイント

  • .envファイルは開発・ビルド・生成時に自動で読み込まれ、process.envに反映される
  • 本番環境では.envは読み込まれず、環境変数はホスティング環境側で設定する必要がある
  • 複数の環境ごとに.env.local.env.productionなどを使い分け可能
  • アプリケーションコード内では直接process.envを使わず、Runtime Configを利用するのが推奨される
  • .envの変更は開発中は自動で反映されるが、ビルド後は再ビルドが必要

いつ使うべきか、使わない方がよいケース

使うべきケース

  • 開発中にAPIキーや設定値を簡単に切り替えたいとき
  • ビルド時に環境ごとの設定を差し替えたいとき(例:開発・ステージング・本番)
  • ローカル環境での動作確認やテストを行う際に環境変数を管理したいとき

使わない方がよいケース

  • 本番環境の秘密情報を.envに直接書いてリポジトリに含める場合(セキュリティリスク)
  • 実行時に動的に環境変数を変更したい場合(ビルド時に固定されるため)
  • クライアントサイドで直接参照する必要がある値(Runtime Configのpublic側を使うべき)

実務でよくあるユースケースとサンプルコード

1. 開発環境と本番環境でAPIエンドポイントを切り替える

# .env
API_BASE_URL=https://dev-api.example.com

# .env.production
API_BASE_URL=https://api.example.com
// nuxt.config.ts
export default defineNuxtConfig({
  runtimeConfig: {
    public: {
      apiBaseUrl: process.env.API_BASE_URL || 'https://default-api.example.com'
    }
  }
})
const config = useRuntimeConfig()
const apiUrl = config.public.apiBaseUrl

2. ローカルでの開発時にのみ有効な設定を.env.localで管理

npx nuxt dev --dotenv .env.local

.env.localは.gitignoreに含めて秘密情報を管理しやすくする運用が一般的です。

3. 本番環境での環境変数設定(例:VercelやNetlify)

本番環境では.envファイルは読み込まれないため、ホスティングサービスの管理画面で環境変数を設定します。これにより、ビルド時や実行時に適切な値が注入されます。


よくある落とし穴・注意点

1. .envの変更が即時反映されない場合がある

開発中はNuxtが自動で再起動し反映されますが、ビルド済みのアプリでは再ビルドが必要です。変更後に反映されない場合はビルドプロセスを見直しましょう。

2. 本番環境で.envが無視される理由

Nuxtはサーバーレスやエッジ環境にも対応するため、ファイルシステムに依存しない設計です。したがって、本番環境では.envを使わず、環境変数はホスティング側で管理する必要があります。

3. クライアントサイドでの環境変数の扱い

process.envはサーバー側でのみ安全に使えます。クライアントで使う値は必ずRuntime Configのpublic側に設定し、useRuntimeConfig()で取得してください。

4. セキュリティリスクに注意

.envに秘密情報を含めたままリポジトリにコミットすると、情報漏洩のリスクがあります。必ず.gitignoreに追加し、秘密情報は安全な方法で管理しましょう。


まとめ

Nuxtの.envファイルは開発やビルド時の環境変数管理に非常に便利ですが、本番環境では使われない点を理解することが重要です。実務では環境ごとにファイルを分けたり、Runtime Configを活用したりすることで安全かつ柔軟な設定管理が可能です。落とし穴を避けるためにも、環境変数の役割とNuxtの動作を正しく理解し、適切に運用しましょう。

環境変数の管理はプロジェクトの規模や運用形態によって最適解が変わります。まずは小さく始めて、必要に応じてRuntime Configやホスティングサービスの機能を活用するのがおすすめです。