brand logo

ドキュメント

nuxt build

Nuxt アプリケーションをビルドします。

Terminal
npx nuxt build [ROOTDIR] [--cwd=<directory>] [--logLevel=<silent|info|verbose>] [--prerender] [--preset] [--dotenv] [--envName]

build コマンドは、アプリケーション、サーバー、および依存関係がすべてプロダクション用に準備された .output ディレクトリを作成します。

引数

引数説明
ROOTDIR="."作業ディレクトリを指定します(デフォルト: .

オプション

オプションデフォルト説明
--cwd=<directory>作業ディレクトリを指定します。これは ROOTDIR よりも優先されます(デフォルト: .
--logLevel=<silent|info|verbose>ビルド時のログレベルを指定します
--prerenderNuxt をビルドし、静的ルートをプリレンダリングします
--presetNitro サーバープリセット
--dotenvルートディレクトリからの相対パスで .env ファイルをロードします
--envName設定のオーバーライドを解決する際に使用する環境(ビルド時のデフォルトは production、開発サーバー実行時は development

このコマンドは process.env.NODE_ENVproduction に設定します。

--prerender を使用すると、常に presetstatic に設定されます。

tips

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

Nuxtのbuildコマンド補足解説

Nuxtのbuildコマンドは、開発したアプリケーションを本番環境にデプロイするために必要なビルド処理を行います。単にコードをまとめるだけでなく、サーバーや依存関係も含めて最適化された形で出力されるため、パフォーマンスや安定性の向上に寄与します。

本記事では、Nuxt公式ドキュメントの説明を補完し、実務での活用シーンや注意点を踏まえた解説を行います。初〜中級のNuxtユーザーが理解を深め、より効率的にビルドを活用できるようになることを目指しています。


1. イントロ:なぜbuildコマンドが重要か?

  • 本番環境向けの最適化
    開発中のコードはそのままではパフォーマンスやセキュリティ面で不十分です。buildコマンドはコードの圧縮や依存関係の整理、サーバー側の最適化を行い、実際の運用に耐えうる形に変換します。

  • 静的サイト生成やプリレンダリングの対応
    オプションを使うことで静的なHTMLを事前生成し、SEOや初期表示速度の改善が可能です。

  • 環境変数の適用や設定の切り替え
    ビルド時に環境ごとの設定を反映できるため、開発・ステージング・本番で異なる挙動を簡単に管理できます。


2. まず結論:buildコマンドの要点

  • npx nuxt build でプロダクション用のビルドが生成される
  • 出力は .output ディレクトリにまとめられ、サーバーや依存関係も含む
  • --prerender オプションで静的ルートのプリレンダリングが可能
  • --cwdROOTDIR でビルド対象のディレクトリを指定できる
  • --logLevel でビルド時のログ詳細度を調整可能
  • 環境変数は .env ファイルや --envName で切り替えられる
  • ビルド時は自動的に process.env.NODE_ENVproduction に設定される

3. いつ使うべきか・使わない方がよいケース

使うべきケース

  • 本番環境にデプロイする直前
    開発中のコードを最適化し、実際の運用に耐えうる形に変換したいとき。

  • 静的サイト生成を行いたいとき
    SEO対策や高速な初期表示を実現するために、プリレンダリングを利用したい場合。

  • 環境ごとに異なる設定を反映したいとき
    .envファイルや環境名を切り替えて、ビルド時に適切な設定を適用したい場合。

使わない方がよいケース

  • 開発中のホットリロードが必要なとき
    buildは本番用のビルドを作るため、開発中はnuxt devを使うべきです。

  • 頻繁にビルドを繰り返す必要がある場合
    ビルドは時間がかかるため、開発中は不要なビルドを避けるのが効率的です。


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

ユースケース1:本番環境向けのビルド生成

npx nuxt build
  • デフォルトの設定でビルドを行い、.outputに本番用ファイルを生成します。
  • 生成物はサーバーにアップロードして運用します。

ユースケース2:静的サイトのプリレンダリング

npx nuxt build --prerender
  • 静的ルートを事前にHTML化し、SEOやパフォーマンスを向上させます。
  • --prerenderを指定すると自動的にpresetstaticに設定されます。

ユースケース3:特定ディレクトリでのビルドと環境変数の指定

npx nuxt build ./my-app --cwd=./my-app --dotenv=.env.production --envName=production
  • 複数プロジェクトがある場合や環境ごとに異なる設定を使いたい場合に便利です。
  • .env.productionの内容がビルド時に反映されます。

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

SSRとCSRの違いによる影響

  • buildコマンドはSSR(サーバーサイドレンダリング)を前提に最適化されます。
  • クライアントサイドのみの挙動を期待する場合は、ビルド後の挙動を必ず検証してください。

Hydrationエラーに注意

  • ビルド時に生成されたHTMLとクライアント側のVueアプリの状態が一致しないとHydrationエラーが発生します。
  • 動的なデータやクライアント専用の処理は適切に分離し、build後の動作確認を行いましょう。

パフォーマンス面の注意

  • 不要な依存関係や大きなライブラリを含めるとビルドサイズが増大し、初期読み込みが遅くなります。
  • build前に依存関係の見直しやコード分割を検討してください。

ログレベルの設定

  • デフォルトでは情報レベルのログが出力されますが、詳細なデバッグが必要な場合は--logLevel=verboseを使うと良いでしょう。
  • 逆にCI環境などでログを抑えたい場合は--logLevel=silentが便利です。

6. まとめ

Nuxtのbuildコマンドは、本番環境に向けてアプリケーションを最適化し、安定した運用を支える重要な機能です。静的サイト生成や環境変数の切り替えなど多彩なオプションを活用することで、より柔軟で効率的なデプロイが可能になります。

ただし、開発中のホットリロードとは役割が異なるため、使い分けが重要です。また、Hydrationエラーやビルドサイズの増大などの落とし穴にも注意し、ビルド後の動作検証を怠らないことが成功の鍵となります。

本記事の内容を参考に、Nuxtのビルドプロセスを理解し、実務での活用に役立ててください。