公開2026.09.05更新2026.10.02 開発

Next.jsとは？16系App Routerで最小アプリを動かす手順と採用判断

Q: Vercel以外のサーバーでもデプロイできますか？

できます。Node.js 20.9以上が動く環境であれば、 next build でビルドし next start で本番サーバーを起動する形で運用できます。コンテナ化してAWSやGoogle Cloud上で動かす構成も一般的です。16ではデプロイ基盤ごとにビルド出力を加工できるBuild Adapters APIがalpha版として追加され、プラットフォーム側の統合手段も整備が進んでいます。

Q: Next.js 15から16へ上げると最初に壊れるのはどこですか？

多くの場合、 params と searchParams 、および cookies() ・ headers() ・ draftMode() の同期アクセスです。16でこれらは非同期化され、 await を付けない呼び出しは削除されました。次に来るのが next lint の削除によるスクリプトの失敗と、Node.js 18環境での起動不能です。 npx @next/codemod@canary upgrade latest で機械的な置換はまとめて処理できます。

Q: Pages RouterのままでもNext.js 16は使えますか？

使えます。Pages Routerは16でも動作し、 package.json に記載したReactのバージョンがそのまま使われます。ただしCache ComponentsやServer Actionsといった新しい仕組みはApp Router向けの機能で、Pages Routerでは利用できません。新規に作るならApp Router、既存のPages Router資産は段階的に共存させながら移す進め方が現実的です。

Next.jsとは？16系App Routerで最小アプリを動かす手順と採用判断

npm registryが返すnextの最新版は16.3.4で、動かすにはNode.js 20.9以上が要ります（2026年9月5日時点）。Next.jsはReactを土台にしたフルスタックのWebフレームワークで、ルーティング・サーバー処理・ビルド・画像配信までを1つのパッケージにまとめたものです。この記事では、まず本体の版数とディレクトリ構成という実体を押さえ、create-next-appで最小アプリを起動し、サーバーとクライアントの書き分け、キャッシュ設定、16系で入った破壊的変更への対応までを、そのまま実行できるコードで追います。最後に、受託開発でNext.jsを採る条件と、WordPressに任せて見送る線引きも示しました。

まとめ｜Next.jsの実体と16系で最初に動かす最小構成の結論

Next.jsの正体は、Reactに「ファイル配置がそのままURLになるルーティング」「サーバー側で完結するデータ取得」「本番ビルドと配信の仕組み」を足したフレームワークです。手を動かす順番は決まっています。npx create-next-app@latestで雛形を作り、app/layout.tsxとapp/page.tsxの2枚が画面になることを確認し、そこから'use client'を付ける境界を決める。ここまでで全体像はつかめます。

16系で押さえるべき変更は3つです。Turbopackが既定バンドラになったこと、暗黙キャッシュが廃止されキャッシュが"use cache"による明示的なopt-inに変わったこと、そしてparamsやcookies()が非同期アクセス必須になったこと。15以前のコードを持ち込むと、この3つ目で最初に壊れます。

採用判断は条件で切り分けます。検索流入が売上に直結し、かつログイン状態や在庫といった動的な出し分けが同じ画面に同居する案件なら採る価値があります。更新が月数回のコーポレートサイトで動的要素がなく、運用側にReactを読める人がいないなら採りません。

Next.jsの実体とNode.js要件、appディレクトリ最小構成の確認手順

「Next.jsとは何か」を概念で説明する前に、パッケージとして何が入っていて何を要求するかを確認したほうが早く済みます。レジストリと公式ドキュメントの2か所を見れば、動かせる環境かどうかは数分で判定できます。

npm registryで確認するnext本体の版数とNode.js下限

本体の情報はnpm registryのnext最新版メタデータに出ています。2026年9月5日時点のversionは16.3.4、enginesはnode>=20.9.0、peerDependenciesのreactは^18.2.0 || ^19.0.0という指定でした。公式のInstallationページも同じ下限を示し、TypeScriptは5.1.0以上、対応ブラウザはChrome 111以上・Edge 111以上・Firefox 111以上・Safari 16.4以上と明記しています。

ここで判定が1つ決まります。Node.js 18で止まっているサーバーには16系を載せられません。Next.js 16はNode.js 18のサポートを打ち切ったため、移行計画にはランタイムの入れ替えを先に入れる必要があります。既存環境の版数はnode -vとnpm ls nextで先に確認しておくと、後戻りが減ります。

layout.tsxとpage.tsxだけで成立する最小のappディレクトリ構成

App Routerでは、ファイルの置き場所がそのままルートになります。画面を1枚出すのに必要なファイルは2つだけです。app/layout.tsxがルートレイアウトで、html要素とbody要素を含むことが必須。app/page.tsxが/に対応するページです。

// app/layout.tsx（ルートレイアウト・html と body は必須）
export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="ja">
      <body>{children}</body>
    </html>
  )
}

// app/page.tsx（ / に対応するページ ）
export default function Page() {
  return <h1>Hello, Next.js!</h1>
}

公式ドキュメントには、ルートレイアウトを作り忘れた場合next devの起動時に自動生成されるとの記述があります。静的ファイルを置くpublicフォルダは任意で、public/profile.pngは/profile.pngとして参照します。設定ファイルとアプリコードを分けたい場合は、プロジェクト直下にsrcフォルダを置いてその中にappを入れる構成も選択肢です。

create-next-appでの初期化からnpm run devで起動するまでの実作業

雛形生成にはCLIを使います。手動インストールとの違いは、TypeScriptやリンタの設定ファイルを自分で書くかどうかだけで、生成されるアプリの中身は同じです。

create-next-appの–yesが決める既定構成とカスタマイズ項目

3行で開発サーバーまで到達します。ブラウザでhttp://localhost:3000を開くと、先ほどのpage.tsxの内容が表示されます。

npx create-next-app@latest my-app --yes
cd my-app
npm run dev

--yesは対話を飛ばして既定値を採る指定で、TypeScript・Tailwind CSS・ESLint・App Router・Turbopackが有効になり、import aliasは@/*が設定されます。コーディングエージェント向けのAGENTS.mdも同梱される構成です。対話でcustomize settingsを選ぶと、リンタをESLint／Biome／なしから選ぶ、React Compilerを入れる、src/ディレクトリを使う、import aliasを変える、といった項目を個別に決められます。既定のまま進めて差し支えないのは、後からpackage.jsonとtsconfig.jsonを編集すれば同じ状態に持っていけるためです。

手動インストール時にpackage.jsonへ置くdev・buildの記述

既存プロジェクトに後から入れる場合は、パッケージ3つを入れてスクリプトを書きます。npm i next@latest react@latest react-dom@latestを実行し、package.jsonに次を追加します。

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "eslint",
    "lint:fix": "eslint --fix"
  }
}

next devが開発サーバー、next buildが本番ビルド、next startが本番サーバーの起動にあたります。リンタの行がeslintを直接呼んでいるのは、16でnext lintコマンドが削除され、next buildがリンタを走らせなくなったためです。15以前の"lint": "next lint"を引き継ぐと動きません。移行用のcodemodとしてnpx @next/codemod@canary next-lint-to-eslint-cli .が用意されています。

Turbopack既定化とwebpackへ戻す–webpackフラグの使い分け

Next.js 16のリリースノート（2025年10月21日公開）によると、Turbopackは開発・本番ビルドの双方で安定版となり、全アプリの既定バンドラになりました。公式が挙げる効果は本番ビルドが2〜5倍速、Fast Refreshが最大10倍速です。15.3以降では開発セッションの50%超・本番ビルドの20%超がすでにTurbopackで動いていたという公表値も添えられています。

webpack前提のカスタム設定を抱えている場合は、next dev --webpackとnext build --webpackで従来のバンドラに戻す運用が可能です。判断としては、独自loaderやplugin設定がnext.configに積み上がっているプロジェクトだけ--webpackで凌ぎ、それ以外は既定のまま進めるのが手数が少なくて済みます。Turbopackのビルドキャッシュを含む16.3系での改善点はNext.js 16.3の新機能を実装者目線で解説した記事で個別に扱っています。

サーバー側とクライアント側の書き分けとデータ取得コードの実装手順

App Routerを触り始めて最初に迷うのが、どのファイルがサーバーで動きどれがブラウザで動くかという線引きです。ここは規約が単純で、既定値を覚えれば判断できます。

既定がサーバー側という前提と’use client’を付ける判断基準

App Router配下のコンポーネントは、何も書かなければすべてサーバーコンポーネントとして扱われます。ブラウザでしか動かないものを使うときだけ、ファイル先頭に'use client'を書いてクライアントコンポーネントに切り替えます。境界を引く基準は3つです。useStateやuseReducerで状態を持つ、onClickなどのイベントハンドラを渡す、windowやlocalStorageといったブラウザAPIを触る。このいずれかに当たる場合だけクライアント側に置きます。

失敗しやすいのは、ページの最上位に'use client'を付けてしまう書き方です。配下の子コンポーネントがまとめてクライアント扱いになり、サーバー側でデータを取る利点が消えます。状態を持つボタンやフォームなど末端だけを小さく切り出すのが定石で、認証まわりでサーバー用とクライアント用のクライアントを作り分ける具体例はSupabaseとNext.jsを連携させるApp Router構成の記事にまとめてあります。

asyncコンポーネントでのfetchとawait paramsの必須化

サーバーコンポーネントはasync関数にでき、その中で直接await fetch()を書けます。APIルートを経由する必要はありません。16系で変わったのは、動的ルートのparamsとsearchParamsがPromiseになり、同期アクセスが廃止された点です。

// app/posts/[id]/page.tsx
export default async function Page({
  params,
}: {
  params: Promise<{ id: string }>
}) {
  // 16系では await が必須（同期アクセスは削除された）
  const { id } = await params
  const res = await fetch(`https://example.com/api/posts/${id}`, {
    cache: "no-store",
  })
  const post = await res.json()
  return <article>{post.title}</article>
}

同じ扱いになったのがcookies()・headers()・draftMode()で、いずれもawaitを付けて呼びます。公式のバージョン16アップグレードガイドにも削除項目として並んでおり、15から上げたプロジェクトが最初に型エラーで止まるのはたいていこの箇所です。件数が多い場合は手で直さずcodemodに任せたほうが確実に終わります。

静的・動的レンダリングとCache Componentsを設定で切り替える手順

Next.jsの表示速度の話は、突き詰めるとキャッシュをどこに効かせるかという設定の話になります。16系はここの設計思想が変わり、以前より読みやすくなりました。

cacheComponentsを有効化してuse cacheでキャッシュを明示する設定

16では、ページ・レイアウト・APIルート内の動的コードは既定でリクエスト時に実行されます。App Routerが以前持っていた暗黙のキャッシュは外され、キャッシュしたい箇所に"use cache"ディレクティブを書くopt-in方式になりました。有効化はcacheComponents設定で行います。

// next.config.ts
const nextConfig = {
  cacheComponents: true,
}
export default nextConfig

// app/lib/posts.ts（関数単位でキャッシュを明示する）
export async function getPosts() {
  "use cache"
  const res = await fetch("https://example.com/api/posts")
  return res.json()
}

この仕組みはPartial Pre-Rendering（PPR）の完成形として位置づけられており、静的な外枠を即座に返しつつ、動的な部分だけをSuspense境界で後から埋められます。15系の実験フラグから名前が変わっている点に注意が必要です。experimental.dynamicIOはcacheComponentsへ改名され、experimental.pprとルート単位のexport const experimental_pprは削除されました。フラグ名をそのまま持ち込むと設定が効きません。

revalidateTagとupdateTagの使い分けとcacheLife指定

キャッシュを捨てるAPIも整理されました。revalidateTag()は第2引数にcacheLifeプロファイルを要求するようになり、'max'・'hours'・'days'といった組み込み名か{ expire: 3600 }のようなオブジェクトを渡します。引数1つの旧形式は非推奨です。

"use server"
import { revalidateTag, updateTag } from "next/cache"

export async function publishPost(id: string) {
  await db.posts.publish(id)
  // 背景で再検証する（stale-while-revalidate）
  revalidateTag("posts", "max")
}

export async function updateProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile)
  // 同一リクエスト内で書いた値をそのまま読み直す
  updateTag(`user-${userId}`)
}

選び分けの基準は、ユーザーが自分の変更を即座に見る必要があるかどうかです。フォーム送信やユーザー設定のように書き込み直後の反映が求められる場面はServer Actions専用のupdateTag()、記事一覧のように多少の遅れを許容できる箇所はrevalidateTag()に'max'を添える。キャッシュを触らず未キャッシュのデータだけ更新したいときはrefresh()を使います。通知バッジの数だけ更新するような用途がこれに当たります。

proxy.ts移行とrevalidateTag引数変更など16系の破壊的変更の対応

16は削除項目が多い版です。既存プロジェクトを持ち上げる場合、新機能より先にここを見積もっておかないと工数が読めません。

middleware.tsをproxy.tsへ改名する手順と非推奨化の扱い

リクエストを横取りする仕組みの名前が変わりました。middleware.tsはproxy.tsに置き換わり、ネットワーク境界であることを名前で示す設計になっています。作業はファイル名と関数名の変更だけで、中身のロジックは書き換え不要です。

// proxy.ts（旧 middleware.ts ・ Node.js ランタイムで動く）
import { NextResponse, type NextRequest } from "next/server"

export default function proxy(request: NextRequest) {
  return NextResponse.redirect(new URL("/home", request.url))
}

export const config = {
  matcher: ["/((?!_next|favicon.ico).*)"],
}

旧来のmiddleware.tsもEdgeランタイム用途では残っていますが非推奨で、将来のバージョンで削除されると公式に告知されています。proxy.tsはNode.jsランタイムで動くため、実行環境が1つに定まる利点があります。改名を後回しにする理由は特にありません。

AMPとnext lintの削除、Node.js 18切りという移行時の障害

削除されたのは、AMP関連API一式（useAmpとconfig = { amp: true }）、next lintコマンド、serverRuntimeConfigとpublicRuntimeConfig、unstable_rootParams()などです。ランタイム設定を使っていたプロジェクトは.envによる環境変数へ移す必要があります。既定値が変わったものも押さえておきます。

設定	16より前	16の既定
images.minimumCacheTTL	60秒	14400秒（4時間）
images.qualities	1〜100	75のみ
images.imageSizes	16を含む	16を除外
images.maximumRedirects	無制限	3回
既定バンドラ	webpack	Turbopack

画像の品質指定は既定が[75]のみになり、qualitypropはimages.qualitiesの中で最も近い値へ丸められる仕様です。90や100を指定していたサイトは、明示的にimages.qualitiesへ追加しないと見た目が変わります。images.domainsも非推奨で、images.remotePatternsへの書き換えが要ります。

codemodで一括変換する手順と手作業が残るparallel routes対応

移行の起点は自動変換です。npx @next/codemod@canary upgrade latestを実行すると、依存の更新と機械的に置換できる箇所の書き換えが走ります。それでも手作業が残る代表が3つあります。

parallel routesの全スロットにdefault.jsが必須になり、無いとビルドが失敗する（notFound()を返すかnullを返す実装を置く）
自動で当たっていたscroll-behavior: smoothが外れたため、HTML要素にdata-scroll-behavior="smooth"を付けて明示する
ESLint設定がFlat Config形式（eslint.config.mjs）前提になり、.eslintrcのままだと想定どおり動かない場合がある

16系の移行作業そのものは、機能追加を伴わないぶん見積もりを立てやすい部類です。何が入った版なのかを先に把握しておくと判断が早くなるため、版としての全体像はNext.js 16の概要と主要機能を整理した記事を先に読むのが順路になります。

受託開発でNext.jsを採用する条件と、静的CMSに任せて見送る場面

ここからは技術の説明ではなく、案件でNext.jsを選ぶかどうかの判断です。フレームワークの人気度で決めると運用フェーズで詰まります。条件を先に置きます。

Next.jsを採用してよい案件の条件｜SEO要件と更新頻度の組み合わせ

採用してよいのは、次の2つが同時に成り立つ案件です。第一に、検索流入が売上や問い合わせに直結し、初期表示のHTMLに本文が乗っている必要があること。第二に、同じ画面のなかでログイン状態・在庫・価格・地域といった出し分けが発生すること。この2つが重なると、静的生成だけでも素のSPAだけでも要件を満たせず、静的な外枠と動的な部分を1画面で混在させられるNext.jsの構造が効いてきます。

3つ目の条件は組織側にあります。React経験のある開発者を運用フェーズまで確保できること。年1回のメジャーバージョン追随を保守見積もりに織り込めない体制なら、技術要件を満たしていても採るべきではありません。既存サイトをこの構成へ載せ替える判断で迷う場合は、要件と運用体制を踏まえた組み立てからWebサイトリニューアルの相談として持ち込んでいただければ、現行資産をどこまで残すかを含めて設計できます。

Next.jsを見送る場面｜WordPressで足りる規模の線引き

見送るべき条件も明確です。更新が月に数回のコーポレートサイトで、ページごとの出し分けが無く、更新作業を非エンジニアが担当する。この形ならWordPressや静的サイトジェネレータで十分です。Next.jsを入れると、記事1本の修正にビルドとデプロイが挟まり、運用担当者が自力で直せない状態を作ってしまいます。共用レンタルサーバーのようにNode.js 20.9以上を置けない環境も、そもそも候補から外れます。

実際に起きる失敗はバージョン追随の停止です。16系ではランタイム下限の引き上げ、await paramsの必須化、proxy.tsへの改名、revalidateTag()の引数変更が一度に来ました。追随できないまま古い版で止めると、セキュリティ修正だけを取り込むことも難しくなります。実例として、Next.jsが同梱するRSCの脆弱性React2Shell（CVE-2025-55182）では、対象版の確認と更新が必要になりました。年1回の追随工数を保守契約に入れられない案件では、Next.jsは過剰です。この線引きは規模の大小ではなく、更新の主体が誰かで引くのが実務に合います。

よくある質問

Next.jsを触り始めた段階で検索されることの多い質問を、公式ドキュメントの記述にもとづいて整理しました。

Next.jsとReactの違いは何ですか？

ReactはUIを組み立てるライブラリで、ルーティングもサーバー処理もビルド構成も含みません。Next.jsはそのReactを土台に、ファイル配置がURLになるルーティング、サーバー側でのデータ取得とレンダリング、画像やフォントの配信調整、本番ビルドの仕組みをひとまとめにしたフレームワークです。React単体で始めると別途選定が必要になる部品が、既定で組み込まれた状態で始められます。

Next.jsは無料で使えますか？

Next.js本体はMITライセンスのオープンソースで、商用利用を含めて無料です。開発元のVercelが提供するホスティングサービスは別物で、こちらは無料枠と有料プランがあります。Vercelを使わずに自社サーバーやクラウド上で動かす場合、Next.js側に費用は発生しません。

Vercel以外のサーバーでもデプロイできますか？

できます。Node.js 20.9以上が動く環境であれば、next buildでビルドしnext startで本番サーバーを起動する形で運用できます。コンテナ化してAWSやGoogle Cloud上で動かす構成も一般的です。16ではデプロイ基盤ごとにビルド出力を加工できるBuild Adapters APIがalpha版として追加され、プラットフォーム側の統合手段も整備が進んでいます。

Next.js 15から16へ上げると最初に壊れるのはどこですか？

多くの場合、paramsとsearchParams、およびcookies()・headers()・draftMode()の同期アクセスです。16でこれらは非同期化され、awaitを付けない呼び出しは削除されました。次に来るのがnext lintの削除によるスクリプトの失敗と、Node.js 18環境での起動不能です。npx @next/codemod@canary upgrade latestで機械的な置換はまとめて処理できます。

Pages RouterのままでもNext.js 16は使えますか？

使えます。Pages Routerは16でも動作し、package.jsonに記載したReactのバージョンがそのまま使われます。ただしCache ComponentsやServer Actionsといった新しい仕組みはApp Router向けの機能で、Pages Routerでは利用できません。新規に作るならApp Router、既存のPages Router資産は段階的に共存させながら移す進め方が現実的です。