nextjs.org

Next.jsは、Reactを使用してフルスタックWebアプリケーションを構築するためのフレームワークです。Reactはユーザーインターフェースのコンポーネントモデルを提供し、Next.jsはルーティング、レンダリング、データアクセスの規約、サーバー機能、コンパイル、バンドル、キャッシュ、本番環境向けツールを追加します。

主題はフレームワークであり、そのドメインではありません。nextjs.orgは公式Webサイトで、整備されているドキュメント、ガイド、コミュニティへのリンク、プロジェクトに関する情報を確認できます。

Next.jsは、Reactを使用しながら、ブラウザのみで動作するインターフェースを超える機能をサポートしたいチームに最も適しています。1つのプロジェクトに、事前レンダリングされたページ、リクエスト時のレスポンス、サーバーサイドのデータアクセス、API形式のエンドポイント、ブラウザで動作するインタラクティブなコンポーネントを含められます。

Next.jsがReactに追加するもの

Reactは、開発者がインターフェースをコンポーネントとして記述できるようにしますが、完全なアプリケーションアーキテクチャまでは規定しません。Next.jsは、ファイルをルートに対応付け、コードの実行場所を決め、データを読み込み、レスポンスを生成し、デプロイに向けてアプリケーションを準備するための規約を提供します。

したがって、その価値はサーバーサイドレンダリングだけにとどまりません。Next.jsアプリケーションでは複数のレンダリングおよび配信方式を使用でき、同じプロジェクト内で併用することもあります。このフレームワークは、すべてのルートを1つのモデルに押し込むのではなく、Reactを中心にそれらの方式を連携させます。

役割分担は、次のようにまとめると理解しやすくなります。

• Reactは、コンポーネント、状態、props、インターフェースの構成を定義します。
• Next.jsは、ルート、レイアウト、レンダリングの選択肢、サーバーのエントリーポイント、ビルドの動作を定義します。
• アプリケーションは、データの規則、クライアント境界、キャッシュポリシー、デプロイ要件を定義します。
• ホスティング環境は、利用可能なランタイム機能とその動作方法を決定します。

Next.jsをReactのクライアントアプリケーション、静的サイトジェネレーター、または別のWebフレームワークと比較する際には、この区別が重要です。このフレームワークは幅広い機能を提供しますが、プロジェクトが恩恵を受けられるのは、適切に活用した機能からだけです。

Server ComponentsとClient Components

App Routerでは、レイアウトとページはデフォルトでServer Componentsです。Server Componentsはサーバー環境で実行され、コンポーネントの実装をブラウザへ送信することなく、サーバーサイドのデータ処理を実行できます。

Client Componentsは、インターフェースの一部にブラウザ上の状態、イベントハンドラー、エフェクト、またはブラウザ専用APIが必要な場合に使用します。開発者はuse clientディレクティブでクライアント境界を指定し、その境界より下にあるコンポーネントはクライアントサイドのモジュールグラフに含まれます。

質問	Server Component	Client Component
コンポーネントのロジックはどこで実行されますか？	サーバーのレンダリング環境	クライアントバンドルに含まれた後のブラウザ
ブラウザ上の状態やクリックハンドラーを使用できますか？	いいえ	はい
ブラウザ専用APIを直接使用できますか？	いいえ	はい
コンポーネントのコードはブラウザに送信されますか？	クライアントコンポーネントのコードとしては送信されません	はい
一般的な役割	データに基づくコンテンツ、レイアウト、サーバーサイドでの構成	フォーム、メニュー、エディター、フィルター、その他のインタラクティブなコントロール

ルートは、どちらか一方の種類だけを選ぶ必要はありません。Server Componentでコンテンツをレンダリングし、ページ内のインタラクティブな部分に選択したClient Componentsを組み込めます。これにより、ルート全体をクライアントアプリケーションとして扱うのではなく、特定のニーズがある箇所にブラウザ用JavaScriptを配置できます。

ただし、境界の設定には注意が必要です。大きなコンポーネントのサブツリーをuse clientの内側へ移すと、ブラウザへ送信されるJavaScriptが増える可能性があります。一方、小さなコントロールをすべて個別の境界に分割すると、コードを理解しにくくなることがあります。フレームワークの名称だけで判断せず、代表的なページを測定する必要があります。

また、Server Componentsはルートの配信戦略とは別の概念です。Server Componentは、事前レンダリングされた出力に含まれることも、動的レンダリングに参加することもあります。コンポーネントをサーバーサイドと説明するだけでは、ルートがビルド時に生成されるのか、後で更新されるのか、リクエストごとに生成されるのかは分かりません。

App RouterとPages Router

Next.jsでは現在、2つのルーティングシステムがドキュメント化されています。App Routerは新しいシステムで、Server ComponentsなどのReact機能を取り入れています。Pages Routerは以前からあるシステムで、現在もサポートされています。

領域	App Router	Pages Router
主なルート構造	appディレクトリ	pagesディレクトリ
デフォルトのコンポーネントモデル	レイアウトとページはServer Components	従来のNext.jsページモデルを使用
共有UI	ネストされたレイアウトが中心的な規約	一般にアプリケーションとページのパターンを通じて構成
最適な出発点	現在のアーキテクチャを採用する新規開発	Pages Router APIを中心に構築された既存のアプリケーションまたは依存関係

移行は、フォルダー名を変更するだけではありません。App Routerのコードでは、サーバーファーストのコンポーネントモデルに加え、レイアウト、データアクセス、読み込み状態、ルートの動作について異なるパターンが導入されます。成熟したアプリケーションを変換する前に、チームはこうした概念上の変化を特定する必要があります。

新しいプロジェクトでは通常、App Routerのドキュメントを最初に確認すべきです。そこではフレームワークの現在のモデルが説明されているためです。既存のPages Routerアプリケーションでは、サポートが継続されていることを欠点として扱うのではなく、実際の利点、依存関係、テスト工数、保守コストを踏まえて移行を評価すべきです。

ドキュメントや例は、一方のルーターだけを対象としている場合があります。実装をコピーする前に、開発者はどのルーターが使用されているか、参照されているAPIが自分たちのプロジェクトに適用できるかを確認する必要があります。

レンダリング、キャッシュ、再検証

Next.jsは、すべてのページを同じ方法でレンダリングするわけではありません。ルートは、訪問者が来る前に準備したり、リクエスト固有の情報を使用して生成したり、キャッシュしたり、再検証ポリシーに従って更新したりできます。

ルートの要件	想定される配信方式	確認すべき質問
入力が事前に判明している	事前レンダリングされた出力	どのイベントによって出力を変更すべきですか？
出力がCookie、ヘッダー、リクエストデータに依存する	動的レンダリング	処理の一部を安全にキャッシュできますか？
コンテンツが管理されたスケジュールで変更される	再検証を伴うキャッシュ出力	レスポンスはどの程度古くなっても許容されますか？
サーバー専用機能が必要ない	静的エクスポートが適する可能性がある	すべてのルートとアセットはエクスポートの制限に対応していますか？

キャッシュは、データアクセスから切り離して理解できる単一のスイッチではありません。チームは、どの処理がキャッシュされ、どのルートが動的になり、無効化や再検証がどのように行われるのかを把握する必要があります。これらの規則は、現実的なコンテンツ変更を使ってテストすべきです。

これは、認証済みページ、価格、在庫、ダッシュボード、その他の鮮度要件が明確な情報で特に重要です。キャッシュされた出力の配信は有用ですが、アプリケーションの正確性に関する規則が許容する場合に限られます。

パフォーマンスや検索上の可視性を、レンダリング方式の名称だけから推測してはいけません。事前レンダリングはリクエスト時の処理を減らせる可能性があり、サーバーレンダリングは意味のある初期HTMLを提供できますが、実際の結果はページ構造、アセット、データの遅延、ブラウザ用JavaScript、キャッシュ、デプロイ時の動作によって異なります。

静的エクスポートとランタイム要件

Next.jsでは、プロジェクトがサーバー専用のフレームワーク機能に依存していない場合、静的エクスポートを生成できます。生成されたHTML、CSS、JavaScript、アセットは、通常の静的ファイルに対応するインフラストラクチャから配信できます。

静的な出力にもClient Componentsを含められます。静的配信は、ビルド結果をどのようにホストするかを表すものであり、すべてのインターフェースを非インタラクティブにしなければならないという意味ではありません。ブラウザサイドのコードで、状態、イベント、その他のクライアント動作を引き続き提供できます。

静的エクスポートを選択する前に、プロジェクトで次のものが必要ないことを確認してください。

• リクエスト固有のサーバーデータから生成されるレスポンス。
• 稼働中のNext.jsランタイムに依存するルートの動作。
• サポートされていない画像、ルーティング、サーバー機能。
• 再ビルドまたはその他のサポートされた更新処理では満たせない鮮度規則。
• アプリケーションとともに実行する必要があるサーバーエンドポイント。

これらの機能が必要な場合、アプリケーションには互換性のあるランタイムが必要です。ただし、Vercelへのデプロイが必須というわけではありません。公式のデプロイガイドには、セルフホスティングとプラットフォームアダプターが記載されています。サポート内容はプラットフォームによって異なるため、使用する個々の機能について互換性を確認すべきです。

Route Handlersとサーバーサイドエンドポイント

App Routerでは、Route Handlersを使用して、標準的なリクエストとレスポンスの概念に基づくHTTPリクエストハンドラーをアプリケーション内に定義できます。フォーム処理、Webhook、データレスポンス、連携用コールバックなど、アプリケーションの隣に置くべきエンドポイントに役立ちます。

Route Handlerが、すべてのバックエンドシステムにとって自動的に適切な配置先になるわけではありません。チームは引き続き、認証、認可、検証、レート制御、永続的な処理、エラー処理をどのように管理するか決める必要があります。長時間実行されるサービスや独立してスケーリングされるサービスは、Webアプリケーションから分離したほうが適切な場合があります。

実用的なレビューでは、次の点を確認します。

1. エンドポイントはアプリケーションコードまたは共有型へアクセスする必要がありますか？
2. リクエスト時のシークレットまたはサーバー専用の依存関係が必要ですか？
3. 対象のデプロイ環境は、ドキュメントどおりにハンドラーを実行できますか？
4. 各HTTPメソッドとレスポンスに適したキャッシュ動作は何ですか？
5. 別サービスにすることで、所有責任やスケーリングがより明確になりますか？

Route Handlersはフルスタックの構成を容易にしますが、利便性によって通常のAPI設計やセキュリティ上の責任がなくなるわけではありません。

Next.jsが実用的な選択肢となる場面

Next.jsは、すでにReactに慣れていて、同じコードベース内にアプリケーションルーティングとサーバー機能を必要とするチームにとって有力な候補です。ルートごとに配信要件が大きく異なるプロダクトにも適しています。

一般的に適する例は次のとおりです。

• サーバーデータとインタラクティブなコントロールの両方を備えたアカウント領域やダッシュボード。
• 安定したコンテンツとリクエスト依存の情報を組み合わせるコマースまたはカタログ体験。
• アプリケーションのワークフローも含むドキュメントサイトまたはマーケティングサイト。
• HTMLレスポンス、クライアント操作、サーバーエンドポイントをまとめて必要とするプロダクト。
• ルートごとに異なるキャッシュおよびレンダリングポリシーが役立つReactアプリケーション。

単純なコンテンツサイトには、このフレームワークが必要以上に複雑な場合があります。主に静的な記事を公開するチームは、特にReactによる操作が必要なのがサイトのごく一部だけである場合、コンテンツ配信を中心とするツールと要件を比較すべきです。

チームがランタイム要件に対応できない場合、フレームワーク固有のレンダリング概念を望まない場合、またはサーバーとクライアントの境界を明確に保守するのが難しい場合にも、Next.jsは適さない可能性があります。柔軟性に価値があるのは、アーキテクチャを理解可能な状態に保てる場合だけです。

Next.jsとAstro、その他の選択肢の比較

Next.jsとAstroは、コンテンツとインタラクティブな要素を組み合わせるプロジェクトで比較されることがよくありますが、デフォルトと考え方が異なります。適切な選択は実際のルートによって決まり、一方のフレームワークが速い、または優れているという一般論では決まりません。

有用な比較を行うには、各候補で同じ代表的なページを構築し、次の点を記録します。

• 操作の前後に、どの程度のJavaScriptがブラウザへ送られるか。
• データがどのように読み込まれ、鮮度がどのように制御されるか。
• サーバーランタイム機能が必要かどうか。
• ルーティング、レイアウト、フォーム、エラー状態がどのように実装されるか。
• 対象のホストが必要なすべての機能に対応しているか。
• チームが完成したアーキテクチャをどの程度容易にテストし、説明できるか。

出力の大部分を静的なままにでき、インタラクティブなアイランドが限定されるコンテンツ主導のサイトでは、Astroを特に検討する価値があります。Reactがアプリケーションの中心的なモデルであり、プロダクト全体でサーバー機能とクライアント機能を組み合わせる必要がある場合は、Next.jsの魅力が高まります。

どちらを比較しても、パフォーマンススコアを予測することはできません。画像、フォント、サードパーティースクリプト、コンポーネントの選択、データの遅延、クライアント境界が、フレームワークのデフォルト以上に結果へ影響する場合があります。

起源、ガバナンス、コミュニティ

公式のガバナンスページには、Vercelチームが2016年にNext.jsを作成したと記載されています。また、Vercelのコアチームがプロジェクトの研究開発を主導しているとも記載されています。これはチーム単位の起源とガバナンスに関する記述であり、裏付けのない個人創設者についての主張に置き換えるべきではありません。

2026年8月27日に確認可能だったガバナンスおよびドキュメントページの記載によると、このプロジェクトに公開の場で参加する方法には次のものがあります。

• ソースコード、Issue、プロジェクト活動を確認できる公式GitHubリポジトリ。
• 質問やコミュニティによるRFCの議論に使用するGitHub Discussions。
• 無料のコミュニティサポートを提供するNext.js Discord。
• App RouterとPages Routerの両方について整備されているドキュメント。

これらのチャンネルでは、異なる種類の支援が提供されます。フレームワークの動作についてはドキュメントを最初の参照先とし、Discussionsでは提案や共通の質問を把握でき、Discordではコミュニティでの会話が可能です。いずれも、プロジェクト固有のテストやチーム独自の本番サポートプロセスに代わるものではありません。

判断用チェックリスト

Next.jsを採用する前に、チームは動作するプロトタイプを使って次の質問に答えるべきです。

• どのルートが静的、動的、キャッシュ済み、または再検証対象ですか？
• どのコンポーネントに本当に状態、エフェクト、イベント、ブラウザAPIが必要ですか？
• 各代表的なルートは、どの程度のクライアント用JavaScriptを配信しますか？
• どのエンドポイントをRoute Handlersに置き、どのエンドポイントを別の場所に置くべきですか？
• 対象プラットフォームは、必要なすべてのNext.js機能を実行できますか？
• キャッシュの鮮度、障害、ログ、デプロイをどのように管理しますか？
• チームは、選択したルーターと別のルーター向けに書かれた例との違いを理解していますか？

Next.jsでは、処理をどこで実行し、各ルートをどのように配信するかを意図的に選びながら、Webアプリケーション全体にReactを適用します。ドキュメントに記載された柔軟性は大きいものの、パフォーマンス、検索結果、低い運用コスト、アーキテクチャの単純さを保証するものではありません。これらの結果は、実装と測定を通じて確かめる必要があります。