Next.js 15 リリース候補 (RC) | Next.js

claudejamodel: claude-sonnet-4-20250514

Next.js 15 RC

2024年5月23日（木）

投稿者：Delba de Oliveira @ delba_oliveira、Zack Tanner @ zt1072

Next.js 15 Release Candidate（RC）が利用可能になりました。この早期バージョンでは、今後の安定版リリース前に最新機能をテストできます。

React: React 19 RC、React Compiler（実験的）、ハイドレーションエラー改善のサポート
キャッシュ: fetchリクエスト、GET Route Handler、クライアントナビゲーションがデフォルトでキャッシュされなくなりました
Partial Prerendering（実験的）: 段階的導入のための新しいLayoutとPageの設定オプション
next/after（実験的）: レスポンスのストリーミング完了後にコードを実行する新しいAPI
create-next-app: デザインの更新とローカル開発でTurbopackを有効にする新しいフラグ
外部パッケージのバンドル（安定版）: App RouterとPages Routerの新しい設定オプション

Next.js 15 RCを今すぐ試す

npm install next@rc react@rc react-dom@rc

React 19 RC

Next.js App Routerは、フレームワーク向けのReact canaryチャンネル上に構築されており、開発者がv19リリース前にこれらの新しいReact APIを使用してフィードバックを提供できるようになっています。

Next.js 15 RCは、Actionsなどのクライアントとサーバーの両方の新機能を含むReact 19 RCをサポートしています。

詳細については、Next.js 15アップグレードガイド、React 19アップグレードガイドを参照し、React Conf Keynoteをご覧ください。

注意: 一部のサードパーティライブラリはまだReact 19と互換性がない場合があります。

React Compiler（実験的）

React CompilerはMetaのReactチームによって作成された新しい実験的コンパイラです。コンパイラは、プレーンなJavaScriptセマンティクスとReactのルールの理解を通じて、コードを深いレベルで理解し、コードに自動最適化を追加できます。

コンパイラは、useMemoやuseCallbackなどのAPIを通じて開発者が行う手動メモ化の量を削減し、コードをよりシンプルで保守しやすく、エラーが起こりにくくします。

Next.js 15では、React Compilerのサポートを追加しました。

babel-plugin-react-compilerをインストール：

npm install babel-plugin-react-compiler

次に、next.config.jsにexperimental.reactCompilerオプションを追加：

const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};
module.exports = nextConfig;

オプションで、コンパイラを「オプトイン」モードで実行するように設定できます：

const nextConfig = {
  experimental: {
    reactCompiler: {
      compilationMode: 'annotation',
    },
  },
};
module.exports = nextConfig;

注意: React CompilerはBabelプラグインを通じてNext.jsでのみ使用可能で、ビルド時間が遅くなる可能性があります。

React Compilerと利用可能なNext.js設定オプションについて詳しく学んでください。

ハイドレーションエラーの改善

Next.js 14.1では、エラーメッセージとハイドレーションエラーの改善が行われました。Next.js 15では、改善されたハイドレーションエラービューを追加してこれらの改善を継続しています。

ハイドレーションエラーは、問題の解決方法に関する提案とともに、エラーのソースコードを表示するようになりました。

キャッシュの更新

Next.js App Routerは、独自のキャッシュデフォルトで開始されました。これらは、必要に応じてオプトアウトする機能を持ちながら、デフォルトで最もパフォーマンスの高いオプションを提供するように設計されていました。

あなたのフィードバックに基づいて、キャッシュヒューリスティックと、Partial Prerendering（PPR）やfetchを使用するサードパーティライブラリなどのプロジェクトとの相互作用を再評価しました。

Next.js 15では、fetchリクエスト、GET Route Handler、Client Router Cacheのキャッシュデフォルトを「デフォルトでキャッシュ」から「デフォルトでキャッシュしない」に変更しています。

以前の動作を保持したい場合は、引き続きキャッシュをオプトインできます。

fetchリクエストがデフォルトでキャッシュされなくなりました

Next.jsは、Web fetch API cacheオプションを使用して、サーバーサイドfetchリクエストがフレームワークの永続的HTTPキャッシュとどのように相互作用するかを設定します：

fetch('https://...', { cache: 'force-cache' | 'no-store' });

no-store - リクエストごとにリモートサーバーからリソースを取得し、キャッシュを更新しない
force-cache - キャッシュ（存在する場合）またはリモートサーバーからリソースを取得し、キャッシュを更新する

Next.js 14では、cacheオプションが提供されていない場合、動的関数や動的設定オプションが使用されていない限り、force-cacheがデフォルトで使用されていました。

Next.js 15では、cacheオプションが提供されていない場合、no-storeがデフォルトで使用されます。これは、fetchリクエストがデフォルトでキャッシュされないことを意味します。

以下の方法でfetchリクエストのキャッシュをオプトインできます：

単一のfetch呼び出しでcacheオプションをforce-cacheに設定
単一ルートでdynamic route configオプションを'force-static'に設定
LayoutまたはPageのすべてのfetchリクエストでforce-cacheを使用するようにfetchCache route configオプションを'default-cache'に設定（明示的に独自のcacheオプションを指定しない限り）

GET Route Handlerがデフォルトでキャッシュされなくなりました

Next.js 14では、GET HTTPメソッドを使用するRoute Handlerは、動的関数や動的設定オプションを使用しない限り、デフォルトでキャッシュされていました。

Next.js 15では、GET関数はデフォルトでキャッシュされません。

export dynamic = 'force-static'などの静的ルート設定オプションを使用してキャッシュをオプトインできます。

sitemap.ts、opengraph-image.tsx、icon.tsxなどの特別なRoute Handlerやその他のメタデータファイルは、動的関数や動的設定オプションを使用しない限り、デフォルトで静的のままです。

Client Router CacheがデフォルトでPageコンポーネントをキャッシュしなくなりました

Next.js 14.2.0では、Router Cacheのカスタム設定を可能にする実験的なstaleTimesフラグを導入しました。

Next.js 15では、このフラグは引き続きアクセス可能ですが、PageセグメントのstaleTimeを0にするようにデフォルト動作を変更しています。これは、アプリ内をナビゲートする際に、クライアントが常にナビゲーションの一部としてアクティブになるPageコンポーネントからの最新データを反映することを意味します。

ただし、変更されない重要な動作があります：

共有レイアウトデータは、部分レンダリングを引き続きサポートするためにサーバーから再取得されません
戻る/進むナビゲーションは、ブラウザがスクロール位置を復元できるようにキャッシュから復元されます
Loading.jsは5分間（またはstaleTimes.static設定の値）キャッシュされたままです

以下の設定を設定することで、以前のClient Router Cacheの動作をオプトインできます：

const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};
module.exports = nextConfig;

Partial Prerendering（実験的）の段階的導入

Next.js 14では、Partial Prerendering（PPR）を導入しました。これは、同じページで静的レンダリングと動的レンダリングを組み合わせる最適化です。

Next.jsは現在、cookies()、headers()、キャッシュされていないデータリクエストなどの動的関数を使用しない限り、デフォルトで静的レンダリングを行います。これらのAPIは、ルート全体を動的レンダリングにオプトインします。

PPRでは、任意の動的UIをSuspense境界でラップできます。新しいリクエストが来ると、Next.jsは即座に静的HTMLシェルを提供し、同じHTTPリクエストで動的部分をレンダリングしてストリーミングします。

段階的導入を可能にするため、特定のLayoutとPageをPPRにオプトインするためのexperimental_ppr route configオプションを追加しました：

import { Suspense } from "react"
import { StaticComponent, DynamicComponent } from "@/app/ui"

export const experimental_ppr = true

export default function Page() {
  return (
    <>
      <StaticComponent />
      <Suspense fallback={...}>
        <DynamicComponent />
      </Suspense>
    </>
  );
}

新しいオプションを使用するには、next.config.jsファイルでexperimental.ppr設定を'incremental'に設定する必要があります：

const nextConfig = {
  experimental: {
    ppr: 'incremental',
  },
};
module.exports = nextConfig;

すべてのセグメントでPPRが有効になったら、ppr値をtrueに設定し、アプリ全体とすべての将来のルートで有効にすることが安全と見なされます。

PPRロードマップについては、Next.js 15 GAブログ投稿で詳しく共有します。

Partial Prerenderingについて詳しく学んでください。

next/after（実験的）でレスポンス後のコード実行

ユーザーリクエストを処理する際、サーバーは通常、レスポンスの計算に直接関連するタスクを実行します。ただし、ログ記録、分析、その他の外部システム同期などのタスクを実行する必要がある場合があります。

これらのタスクはレスポンスに直接関連していないため、ユーザーはそれらの完了を待つ必要がありません。ユーザーへの応答後に作業を延期することは、サーバーレス関数がレスポンスが閉じられた直後に計算を停止するため、課題となります。

after()は、レスポンスのストリーミングが完了した後に処理される作業をスケジュールできる新しい実験的APIで、プライマリレスポンスをブロックすることなくセカンダリタスクを実行できます。

使用するには、next.config.jsにexperimental.afterを追加します：

const nextConfig = {
  experimental: {
    after: true,
  },
};
module.exports = nextConfig;

次に、Server Components、Server Actions、Route Handler、またはMiddlewareで関数をインポートします：

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';

export default function Layout({ children }) {
  // セカンダリタスク
  after(() => {
    log();
  });
  // プライマリタスク
  return <>{children}</>;
}

next/afterについて詳しく学んでください。

create-next-appの更新

Next.js 15では、新しいデザインでcreate-next-appを更新しました。

create-next-appを実行すると、ローカル開発でTurbopackを有効にするかどうかを尋ねる新しいプロンプトが表示されます（デフォルトはNo）。

✔ Would you like to use Turbopack for next dev? … No / Yes

--turboフラグを使用してTurbopackを有効にできます：

npx create-next-app@rc --turbo

新しいプロジェクトの開始をさらに簡単にするため、CLIに新しい--emptyフラグが追加されました。これにより、余分なファイルとスタイルが削除され、最小限の「hello world」ページが作成されます：

npx create-next-app@rc --empty

外部パッケージのバンドル最適化（安定版）

外部パッケージのバンドルは、アプリケーションのコールドスタートパフォーマンスを向上させることができます。

App Routerでは、外部パッケージはデフォルトでバンドルされ、新しいserverExternalPackages設定オプションを使用して特定のパッケージをオプトアウトできます。

Pages Routerでは、外部パッケージはデフォルトでバンドルされませんが、既存のtranspilePackagesオプションを使用してバンドルするパッケージのリストを提供できます。

この設定オプションでは、各パッケージを指定する必要があります。App RouterとPages Router間の設定を統一するため、App Routerのデフォルト自動バンドルに合わせる新しいオプションbundlePagesRouterDependenciesを導入しています。

必要に応じて、serverExternalPackagesを使用して特定のパッケージをバンドルからオプトアウトできます。

const nextConfig = {
  // Pages Routerで外部パッケージを自動的にバンドル：
  bundlePagesRouterDependencies: true,
  // App RouterとPages Routerの両方で特定のパッケージをバンドルからオプトアウト：
  serverExternalPackages: ['package-name'],
};
module.exports = nextConfig;

外部パッケージの最適化について詳しく学んでください。

その他の変更

[破壊的変更] 最小Reactバージョンが19 RCになりました
[破壊的変更] next/image: オプションの依存関係としてsharpを優先してsquooshを削除
[破壊的変更] next/image: デフォルトのContent-Dispositionをattachmentに変更
[破壊的変更] next/image: srcに先頭または末尾のスペースがある場合にエラー
[破壊的変更] Middleware: 推奨されないreact APIインポートを制限するためにreact-server条件を適用
[破壊的変更] next/font: 外部@next/fontパッケージのサポートを削除
[破壊的変更] next/font: font-familyハッシュ化を削除
[破壊的変更] キャッシュ: force-dynamicがfetchキャッシュにno-storeデフォルトを設定するようになりました
[破壊的変更] 設定: swcMinifyを有効化

Next.js 15 RC

要約

Summary

Key Points

Breaking Changes

翻訳

Next.js 15 RC

Next.js 15 RCを今すぐ試す

React 19 RC

React Compiler（実験的）

ハイドレーションエラーの改善

キャッシュの更新

fetchリクエストがデフォルトでキャッシュされなくなりました

GET Route Handlerがデフォルトでキャッシュされなくなりました

Client Router CacheがデフォルトでPageコンポーネントをキャッシュしなくなりました

Partial Prerendering（実験的）の段階的導入

next/after（実験的）でレスポンス後のコード実行

create-next-appの更新

外部パッケージのバンドル最適化（安定版）

その他の変更