
Next.js 15リリース、何が変わったのか?
Next.js 15の正式版が公開され、開発者が日常的に書くコードパターンに大きな変化が生じました。最も体感の大きい変化は、リクエストベースのAPIの非同期化と、データキャッシュのデフォルト設定の変更です。前バージョンまで当たり前とされていた同期的な呼び出しや自動キャッシュ動作が変わったため、既存プロジェクトを運用中、あるいは新しいサービスを準備している開発者は、変更された動作方式を明確に把握しておく必要があります。
fetchのデフォルトキャッシュ解除と予測可能なデータフロー
Next.js 14までは、fetchリクエストは特別な設定なしでもビルド時点やランタイムにデフォルトでキャッシュされていました。応答速度が速いというメリットはありましたが、バックエンドデータベースの変更が画面に即時反映されず、混乱する開発者が多くいました。
Next.js 15からは、これらのデフォルト設定が覆りました。今後はfetchリクエストやGETルートハンドラーは、キャッシュされない状態がデフォルトとなります。毎回最新のデータを取得する動作が標準となったため、レスポンスのキャッシュがどうしても必要なエンドポイントにのみ、明示的にオプションを追加すれば良いのです。
非同期に切り替わったCookieとルートパラメーター
サーバーコンポーネントやルートハンドラーで扱っていたcookies()、headers()、そしてページpropsとして渡されていたparamsとsearchParamsがすべて非同期Promise形式に切り替わりました。
伝統的なサーバーサイドレンダリングの手法では、リクエストヘッダーやCookieが完全に到着するまで、サーバーは全体的なレンダリングを止めて待機する必要がありました。Next.jsチームは、リクエストに依存するデータとそうでない静的なコンポーネントを分離し、サーバーが事前にレンダリングを準備できるように基盤構造を刷新しました。この最適化のために、リクエスト情報を読み込むタイミングを明示的な非同期呼び出しに変更したのです。
Next.js 15における動的ルートパラメーターとCookieを読み取る標準的な書き方です。
paramsとcookies()の前にawaitを付ける必要があり、従来の同期的な方法でプロパティに直接アクセスするとコンソールに警告が表示されます。クライアントコンポーネントで非同期のparamsを扱う必要がある場合は、React 19のuseフックを使用してPromiseを解決できます。
開発モードのTurbopack安定化と設定ファイルの改善
開発サーバーの速度を向上させるTurbopackが、開発モードで正式な安定版段階に入りました。大規模なコードベースであっても、ページ遷移やホットリロードが以前のWebpackベースの開発環境よりもはるかに高速に応答します。
TypeScriptをデフォルト言語として使用する流れに合わせて、next.config.tsも公式サポートされます。設定オブジェクトに対して型チェックと自動補完が適用されるため、タイプミスによる設定エラーを未然に防ぐことができます。クライアントサイドナビゲーションを標準サポートする<Form>コンポーネントも新たに追加され、検索フォームやフィルターの実装が一層シンプルになりました。
導入の判断と移行ガイド
新規プロジェクトを開始するなら、迷わずNext.js 15を選択して良いでしょう。キャッシュのデフォルト値が直感的に変更されたことでデータ更新に関する問題のデバッグ時間が短縮され、最新のReact 19エコシステムの機能もすぐに活用できるからです。
運用中の大規模なNext.js 14プロジェクトを移行する際は、段階的なアプローチをとるのが安全です。リクエストAPIの非同期化は、プロジェクト全体の型定義やユーティリティ関数に影響を与えます。公式の移行ツールである@next/codemodを実行して自動変換可能な構文をまず整理し、グローバルキャッシュに依存していた主要なAPI呼び出しに対してcache: 'force-cache'オプションが必要かどうかを確認する手順で作業を進めることを推奨します。
