brand logo

ドキュメント

ランタイム設定

Nuxt Kit は、Nuxt ランタイム設定にアクセスし、変更するためのユーティリティを提供します。

useRuntimeConfig

ビルド時に、解決された Nuxt のランタイム設定にアクセスすることが可能です。

function useRuntimeConfig (): Record<string, unknown>

updateRuntimeConfig

ランタイム設定を更新することも可能です。これは既存のランタイム設定とマージされ、Nitro がすでに初期化されている場合は、Nitro ランタイム設定をリロードするための HMR イベントをトリガーします。

function updateRuntimeConfig (config: Record<string, unknown>): void | Promise<void>

tips

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

はじめに:ランタイム設定がもたらす利便性と課題解決

Nuxtアプリケーションの開発において、環境ごとに異なる設定を柔軟に扱うことは非常に重要です。ビルド時に決まる設定だけでなく、実行時に動的に設定を読み込んだり更新したりできることは、開発効率や運用の柔軟性を大きく向上させます。

Nuxtのランタイム設定機能は、こうしたニーズに応えるために用意されています。useRuntimeConfigを使えば現在の設定値を簡単に取得でき、updateRuntimeConfigを使えば実行中に設定を変更し、必要に応じて即座に反映させることも可能です。

しかし、これらの機能を正しく理解しないと、意図しない挙動やパフォーマンス低下を招くこともあります。本記事では、Nuxtのランタイム設定の基本から実務での活用例、注意すべきポイントまで丁寧に解説します。


まず結論:Nuxtランタイム設定の要点まとめ

  • useRuntimeConfigでビルド後のランタイム設定を安全に取得できる
  • updateRuntimeConfigで実行中に設定を動的に更新可能(NitroのHMRもトリガー)
  • 設定はサーバー・クライアント両方で利用可能だが、公開設定と非公開設定を区別することが重要
  • 動的更新は主に開発時や特定の管理画面での設定変更に有効
  • SSRやHydrationのタイミングに注意しないと、クライアントとサーバーで設定がずれるリスクがある

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

使うべきケース

  • 環境ごとに異なるAPIエンドポイントやキーを切り替えたいとき
    例:開発・ステージング・本番環境でAPIのURLを変える場合など。

  • ユーザーの操作や管理画面から設定を動的に変更したいとき
    例:管理者が管理画面で機能フラグを切り替え、即時反映させたい場合。

  • ビルド時に決められない設定を実行時に読み込みたいとき
    例:外部サービスのトークンや動的に変わる設定値。

使わない方がよいケース

  • 頻繁に変更される大量の設定を管理したい場合
    ランタイム設定はあくまで軽量な設定管理向け。大量のデータや頻繁な更新は別の状態管理やAPIで行うべき。

  • クライアント側だけで完結する設定をサーバー経由で管理しようとする場合
    クライアント専用の状態管理(VuexやPiniaなど)を使うほうが効率的。

  • SSRのHydration時に設定の不整合が起きやすいケース
    サーバーとクライアントで設定が異なるとUIの不整合や警告が発生するため、設定の同期に注意が必要。


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

1. 環境ごとのAPIエンドポイント切り替え

const config = useRuntimeConfig()
const apiBaseUrl = config.public.apiBaseUrl

nuxt.config.tsで環境ごとにpublic.apiBaseUrlを設定し、コンポーネントやComposableで取得してAPI呼び出しに利用します。

2. 管理画面からの機能フラグ切り替え

管理画面でupdateRuntimeConfigを使い、機能フラグを動的に切り替えます。

await updateRuntimeConfig({
  public: {
    featureXEnabled: true
  }
})

これにより、NitroのHMRがトリガーされ、即座に設定が反映されます。

3. 外部サービスのトークンを実行時に差し替え

const config = useRuntimeConfig()
const token = config.apiToken

トークンはビルド時に決められない場合が多いため、実行時に環境変数や管理画面から設定し、useRuntimeConfigで取得します。


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

SSRとCSRでの設定の不整合

サーバーサイドレンダリング(SSR)時に取得した設定と、クライアントサイドでの設定が異なると、HydrationエラーやUIの不整合が発生します。特にpublic設定はクライアントにも公開されるため、両者で同じ値を保証することが重要です。

パフォーマンスへの影響

updateRuntimeConfigはNitroのHMRをトリガーするため、頻繁に呼び出すとパフォーマンスに悪影響を及ぼします。動的更新は必要最低限に留め、頻繁な変更が必要な場合は別の仕組みを検討しましょう。

セキュリティ面の配慮

非公開の設定値(APIキーやシークレットなど)はruntimeConfigprivate側に配置し、クライアントに漏れないように管理してください。publicに含めるとクライアントに丸見えになるため注意が必要です。


まとめ

Nuxtのランタイム設定は、環境ごとの設定管理や実行時の動的な設定変更を可能にし、開発と運用の柔軟性を大きく高めます。useRuntimeConfigupdateRuntimeConfigを適切に使い分けることで、環境依存の設定や管理画面からの即時反映など多様なニーズに対応可能です。

ただし、SSRとCSR間の設定の整合性やパフォーマンス、セキュリティ面には十分注意し、ユースケースに応じて使い分けることが重要です。これらを理解し活用することで、Nuxtアプリケーションの品質と開発効率をさらに向上させましょう。