Next.js 16移行ガイド——Turbopack標準化・Cache Components・React Compilerで何が変わるか

はじめに

「Next.jsのメジャーアップデート、また破壊的変更で移行が大変そう……」

そう身構えている方も多いのではないでしょうか。Next.js 16は確かに大きな変化を含みますが、その多くは これまで experimental だった機能の正式化 です。つまり、すでに片足を突っ込んでいた人にとっては「ようやく安定した」という性格の強いリリースです。

本記事を読み終えると、次のことができるようになります。

• Next.js 16の主要な変更点を整理して把握する
• use cache を使ったCache Componentsの基本を理解する
• middleware から proxy.ts への移行ポイントを押さえる
• 自社のNext.jsプロジェクトを安全にアップグレードする道筋を描く

Next.js 16の主要な変更点

まず全体像を一覧で押さえます。

ひとつずつ、移行の観点で見ていきます。

変更点1: Turbopackがデフォルトに

Rust製バンドラ Turbopack がstableになり、next dev も next build もデフォルトでTurbopackを使うようになりました。Webpackの設定を独自に積み上げていたプロジェクトは、まずここで影響を受けます。

# これまで明示的に有効化していた場合
next dev --turbopack

# 16では --turbopack を付けなくてもデフォルトで有効
next dev

移行時のチェックポイントは次の通りです。

• next.config.js のWebpack専用設定（webpack: (config) => ...）がTurbopackで効かない場合がある
• カスタムローダーを使っている場合はTurbopack対応を確認する
• ビルドが通らない場合、一時的にWebpackへフォールバックする手段を公式ドキュメントで確認する

変更点2: Cache Componentsと use cache

16の目玉が Cache Components です。use cache ディレクティブで、キャッシュ対象を明示的かつ柔軟に指定できます。

架空の在庫管理SaaS「ZaikoFlow」で、商品マスタの取得をキャッシュする例を見てみましょう。商品マスタは更新頻度が低いため、キャッシュの効果が高い対象です。

// src/lib/products/getProductCatalog.ts
import { getProducts } from "@/lib/firestore/products";

interface Product {
  id: string;
  name: string;
  sku: string;
  unitPrice: number;
}

export async function getProductCatalog(): Promise<Product[]> {
  "use cache";
  // Firestoreから商品マスタを取得（更新頻度が低い）
  return getProducts();
}

"use cache" を関数の先頭に置くだけで、この関数の結果がキャッシュ対象になります。Server Componentから呼び出せば、リクエストごとにFirestoreを叩く必要がなくなります。

// src/app/catalog/page.tsx
import { getProductCatalog } from "@/lib/products/getProductCatalog";

export default async function CatalogPage() {
  const products = await getProductCatalog();

  return (
    <ul className="divide-y divide-gray-200">
      {products.map((p) => (
        <li key={p.id} className="py-3">
          <span className="font-medium">{p.name}</span>
          <span className="ml-2 text-sm text-gray-500">{p.sku}</span>
        </li>
      ))}
    </ul>
  );
}

キャッシュの考え方を図にすると、こうなります。

「何を、いつキャッシュするか」をコード上で宣言できるため、従来の暗黙的なキャッシュ挙動に振り回されにくくなります。

変更点3: middlewareからproxy.tsへ

Next.js 16では middleware.ts が proxy.ts にリネームされました。これは「ネットワーク境界で何をしているのか」を名前から明確にする狙いです。

移行はファイル名の変更が基本ですが、役割を再確認する良い機会でもあります。

// proxy.ts （旧 middleware.ts）
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function proxy(request: NextRequest) {
  // 認証トークンがなければログインへリダイレクト
  const token = request.cookies.get("session")?.value;

  if (!token && request.nextUrl.pathname.startsWith("/dashboard")) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/dashboard/:path*"],
};

挙動そのものは従来のmiddlewareと同様ですが、ファイル名と関数名が変わる点に注意してください。

ハンズオン: 移行の手順

実際にアップグレードする流れを、段階を追って示します。いきなり全部を変えるのではなく、ビルドが通る状態を保ちながら一歩ずつ 進めるのが鉄則です。

具体的なコマンドは次の通りです（モリソンの標準である yarn を使用）。

# 1. 移行用ブランチを作成
git switch -c chore/nextjs-16-migration

# 2. Next.jsとReactを更新（バージョンは公式の対応表に従う）
yarn add next@latest react@latest react-dom@latest

# 3. 開発サーバーでTurbopackビルドを確認
yarn dev

# 4. 本番ビルドが通るか確認
yarn build

ビルドエラーが出たら、一気に直そうとせず エラーメッセージ単位で潰す のが結局いちばん速い進め方です。

Tips・注意点

• React Compilerは自動メモ化を担う: 16でstableになったReact Compilerは、不要な再レンダリングを自動で削減します。手動の useMemo / useCallback を減らせる可能性がありますが、まずは挙動を確認しながら段階的に外しましょう。
• DevTools MCP: Next.js DevToolsにMCP統合が入り、デバッグ情報をAIエージェントから扱いやすくなりました。Claude Codeと組み合わせると原因調査が捗ります。
• 公式の移行ガイドを必ず確認: バージョン固有の破壊的変更は公式のアップグレードガイドに正確な情報があります。本記事は概観として活用し、最終判断は公式ドキュメントで行ってください。

まとめ

Next.js 16移行の要点を整理します。

• Turbopackがデフォルト化 され、ビルドが高速になる一方でWebpack設定の見直しが必要
• Cache Components（use cache） でキャッシュを明示的・柔軟に制御できる
• React Compiler 1.0 の統合で自動メモ化が標準に
• middleware.ts → proxy.ts のリネームでネットワーク境界が明確に
• 移行は ビルドGREENを保ちながら段階的に が鉄則

次のアクションとして、まずは検証用ブランチで yarn add next@latest を実行し、Turbopackビルドが通るかだけを確認してみてください。そこさえクリアできれば、残りの移行はぐっと見通しが良くなります。TypeScript側の移行が気になる方はTypeScript 6.0移行ガイドも参考にどうぞ。