Next.js は静的配信かサーバー運用か：判断ガイド

フレームワーク名ではなく、各ルートの動作を見る

Next.js プロジェクトを「フロントエンド」と呼ぶだけでは、必要なホスティング方式は決まりません。ビルド時に完成するページ、リクエストごとに処理するページ、Server Actions、画像最適化、API、定期処理を一覧にします。

会社紹介やドキュメントのように、公開内容がビルドで確定する場合は静的 export が有力です。ログイン後の画面、ユーザー別データ、リクエスト時の認証やサーバー処理が必要なら、Node.js サーバーまたは対応した実行環境が必要です。

静的 export が向いているケース

静的ファイルは単純な Web サーバーや CDN で配信でき、実行プロセスを常時維持する必要がありません。攻撃面と運用項目も比較的小さくなります。しかし、すべての Next.js 機能が export に対応するわけではありません。

Next.js の公式デプロイ資料では、Node.js と Docker は全機能、静的 export は機能が限定されると整理されています。機能を外すために無理なクライアント実装へ変えると、セキュリティや体験を悪化させる場合があります。

Node.js サーバーを選ぶケース

next build と next start を実行できる環境なら、標準的なサーバー運用が可能です。ビルドと開始コマンド、Node.js バージョン、環境変数をリポジトリで明確にします。秘密値はブラウザへ公開される変数に入れません。

ヘルスチェックはプロセスが応答できることを素早く確認します。データベース移行は各インスタンスの開始コマンドに入れず、一度だけ実行するリリース工程に分けます。アップロードもローカルディスクに依存せず、永続ストレージへ保存します。

キャッシュは複数台で設計が変わる

単一インスタンスではローカルキャッシュが正常に見えても、複数台ではそれぞれ異なる内容を持つ可能性があります。公式のセルフホスティングガイドを確認し、共有キャッシュ、タグの無効化、再検証の同期を設計します。

CDN が HTML をキャッシュする場合、Cookie や認証に依存する応答を公開キャッシュしないようにします。古い画面が出たとき、ブラウザ、CDN、Next.js、データ API のどこが応答したか追跡できるヘッダーやログが役立ちます。

画像と環境変数を忘れない

静的 export の画像最適化は、カスタム loader など追加設計が必要になることがあります。サーバー方式でも大きな画像処理はメモリを使うため、実トラフィックに近い画像で測定します。

NEXT_PUBLIC_ の値はクライアントに含まれる前提です。API キーや署名鍵を入れてはいけません。プレビューと本番で公開 URL が違う場合も、ビルド時と実行時のどちらで値が確定するか確認します。

最も安全な判断方法は、必要な機能を一つずつ表にして、静的方式で満たせるか確認することです。静的で十分なら単純さを選び、サーバーが必要なら隠さず運用要件として設計します。

よくある質問

Next.js はすべて静的サイトとして配信できますか？

いいえ。静的 export に対応しないリクエスト時機能があります。利用するルートと機能を確認してから方式を選びます。

Node.js サーバーを選ぶ利点は何ですか？

Next.js の全機能を利用しやすく、サーバー処理、動的ルート、画像最適化などを一つの実行環境で扱えます。

複数インスタンスで注意する点は何ですか？

キャッシュと再検証の状態が各インスタンスで分かれないよう、共有キャッシュや無効化の調整を検討します。