---
title: "Next.js は静的配信かサーバー運用か：判断ガイド"
description: "Next.js を静的 export、Node.js サーバー、Docker のどれで配信するべきか、ルート、画像、キャッシュ、環境変数、複数インスタンスから判断します。"
canonical: "https://darwa-front.darwa.co/blog/ja/nextjs-static-server-hosting-choice"
language: "ja"
category: "フロントエンドクラウド"
tags: ["next.js", "静的サイト", "node.js", "ホスティング"]
author: "Darwa Engineering"
published: "2026-08-28T06:09:00Z"
updated: "2026-08-31T19:34:34.240722Z"
reading_time_minutes: 1
---
# Next.js は静的配信かサーバー運用か：判断ガイド

ルートごとの実行方式を確認し、静的 export、Node.js サーバー、コンテナのどれが機能・キャッシュ・運用要件に合うか判断します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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