Next.js

なぜ生まれた？: React をサーバーで描くには多くの手順が要り、サーバーとブラウザのコードも分かれていた。
何を解決した？: pages のファイルをそのまま URL にし、サーバーでの描画とコードの分割を自動で行った。
何を残した？: 入れ子のレイアウトが組めずにルーターを作り直し、動かす場所ごとの機能の差も課題になった。

登場: 2016年10月25日
作者: Naoyuki Kanezawa、Guillermo Rauch、Tony Kovanen、Dan Zajdband
状態: 現役

Next.js が生まれる前

サーバーの HTML と、ブラウザのコードが分かれていた

2016年、JavaScript はすでに Node.js でサーバーでも動いていましたが、画面を作るコードはサーバーとブラウザで分かれがちでした。Next.js を発表した ZEIT（2020年に Vercel と改名）の公式ブログは、こう書いています。

“If you for example picked Express and Jade, some HTML would be rendered by the server and then a different codebase (powered by jQuery or similar libraries) would take over.” （たとえば Express と Jade を選ぶと、HTML の一部をサーバーが描き、そのあとは jQuery などで動く別のコードベースが引き継いだ）

続けて、“In many ways, PHP was actually more suited for the “server rendering of HTML” job.”（いろいろな点で、「サーバーで HTML を描く」仕事には PHP のほうが向いていた）とも書いています。

一方で、画面をすべてブラウザで組み立てる SPA も広まっていました。同じ記事は、すぐに反応する画面を作れることから、振り子が “the extreme of “single page app” / “nothing server-rendered""（「シングルページアプリ」「サーバーでは何も描かない」という極端）に一気に振れた、と書いています。

「サーバーで描いたページは省けない」

ZEIT の創業者 Guillermo Rauch は、2014年11月4日の「7 Principles of Rich Web Applications」の第1原則に、この間の道を書いていました。2026年10月時点の題は「Pre-rendered pages are not optional」（事前に描いたページは省けない）で、もとは “server-rendered” だったと本人が注記しています。

“Pre-rendering is not (just) about SEO, it’s about performance.” （事前の描画は SEO（だけ）の話ではなく、性能の話だ）

Rauch は「サーバーで描くアプリか、シングルページアプリか」という二択を “a fairly common false dichotomy”（よくある誤った二択）と呼び、どちらかを捨てるのはよい考えではないとしました。SPA を否定する文章ではなく、両方を取る文章です。

React にはサーバーで HTML を作る仕組みがありましたが、それだけでサイトになるわけではありません。Next.js の最初の README は、作る前に “options for server-rendering React that didn’t involve a large number of steps”（多くの手順を踏まずに React をサーバーで描く方法）を探した、と書いています。同じ README が Next.js に任せられると挙げたのは、webpack と Babel による変換とまとめ上げ、コードを書き換えたときの再読み込み、./pages のサーバーでの描画でした。どれも、それまでは自分で組み合わせていた仕事です。

誕生

20日で公開された「initial spec」

GitHub の zeit/next.js（2026年10月時点では vercel/next.js）のリポジトリは2016年10月5日（UTC）に作られ、Rauch が「initial spec」という最初のコミットを入れました。 20日後の10月25日、ZEIT の公式ブログに「Next.js」が載り、同じ日に GitHub の 1.0.0 のタグと npm の 1.0.0 が出ています。この記事は、公開されたこの日を登場としています。

ブログの署名は Naoyuki Kanezawa、Guillermo Rauch、Tony Kovanen の3人で、README の Authors には Dan Zajdband（Knight-Mozilla / Coral Project）も並びます。ブログは Next.js を、React・webpack・Babel の上に作った “a small framework for server-rendered universal JavaScript webapps”（サーバーで描くユニバーサルな JavaScript の Web アプリのための小さなフレームワーク）と紹介し、動機をこう書きました。

“We created Next.js because we believe universal isomorphic applications are a big part of the future of the web.” （Next.js を作ったのは、サーバーとブラウザで同じコードが動くアプリケーションが、Web の未来の大きな部分を占めると考えているからだ）

React があるのに、なぜその上にもう1つフレームワークが要ったのか

発表の記事は、サーバーでの描画と、アプリを小さな束に分けることを “simultaneously very difficult and highly desirable”（とても難しく、同時にとても望まれていた）仕事に挙げています。 Next.js では pages/ の部品が自動でサーバーで描かれ、ページごとに要るコードだけが束ねられました。ページを描く前にデータを取る非同期の関数 getInitialProps も React の部品に足し、サーバーで描くときにもブラウザの中でページを移るときにも呼ばれるようにしました。

README の FAQ は、同じ年の7月に npm に出た create-react-app との違いを問われて “Yes and No”（そうでもあり、そうでもない）と答えています。どちらも手間を減らすが、Next.js は ファイルの置き方という「構造」を決めることで、サーバーでの描画やコードの自動分割ができる、という説明です。

なぜ pages に置いたファイルがそのまま URL になる形にしたのか

発表が最初に挙げた原則は「Zero setup. Use the filesystem as an API」（設定なし。ファイルシステムを API にする）でした。 Node.js のプロジェクトが package.json と node_modules の置き場所の約束の上にあるように、Next.js はそこに pages を足し、pages/about.js を /about にしました。記事はこれを、すぐに始められる良い既定値だとしています。込み入ったルーティングは後で開発者に任せる予定で、1.0 の時点では、ファイルの置き場所のほかに URL を決める手段はありませんでした。

PHP のようだと言われたのは本当か

README の「What is this inspired by?」（何から影響を受けたか）は、目標の多くが Rauch の「7つの原則」から来ていると書き、続けて PHP を挙げています。作者の誰か1人の発言ではなく、プロジェクトの README の文です。

“The ease-of-use of PHP is a great inspiration. We feel Next.js is a suitable replacement for many scenarios where you otherwise would use PHP to output HTML.” （PHP の使いやすさは大きな手本だ。PHP で HTML を出力していたような多くの場面で、Next.js は代わりになると考えている）

すぐあとに “Unlike PHP”（PHP と違って）と続け、どのファイルも ES6 のモジュールとして、読み込んだりテストしたりできる部品か関数を書き出す、と違いも書いています。React の作者 Jordan Walke の react-page（すでに開発終了）という似たやり方も挙げています。「ファイルを置けばページになる」手軽さは PHP を手本にしたと README 自身が書いていますが、置くのは HTML の混じったスクリプトではなく、React の部品です。

コードで見る違い

API から天気予報を取ってページに出し、「About」へのリンクを置く処理で比べます。どれもこの記事のための作例で、Express の側は Jade のテンプレートと、ブラウザで動かす jQuery のコード（weather.js）を別に用意する前提です。

var express = require('express')
var fetch = require('node-fetch')
var app = express()
app.set('view engine', 'jade') // views/weather.jade で HTML を作る

app.get('/', function (req, res, next) {
  fetch('https://api.example.com/weather/tokyo')
    .then(function (r) { return r.json() })
    .then(function (data) {
      res.render('weather', { forecast: data.forecast })
    })
    .catch(next)
})
app.listen(3000)

html
  body
    p= forecast
    a(href="/about") About
    script(src="/js/jquery.js")
    script(src="/js/weather.js")

import React from 'react'
import Link from 'next/link'
import 'isomorphic-fetch'

export default class extends React.Component {
  static async getInitialProps () {
    const res = await fetch('https://api.example.com/weather/tokyo')
    const { forecast } = await res.json()
    return { forecast }
  }
  render () {
    return <div>
      <p>{this.props.forecast}</p>
      <Link href="/about"><a>About</a></Link>
    </div>
  }
}

Next.js の側は、pages/about.js を置いて next を実行すれば動きます。async/await は Next.js が Babel で変換するので、2016年の Node.js でも書けました。 Express の側は、URL とテンプレートの対応をコードで書き、画面の動きは weather.js に別の書き方で足します。 Next.js の側では、同じ部品がサーバーで最初の HTML を作り、<Link> で移るときはブラウザの中で getInitialProps を呼び直して描き直します。

なぜ広まったのか

README の FAQ は「本番で使えるか」という問いに、Next.js は始めから ZEIT のサイトを動かしてきたと答え、コードベースは CLI を除いて約1,500行だと小ささも挙げています。本番には next build と next start の2つのコマンドで出せ、ZEIT のホスティング製品「now」にもそのまま載せられました。

2017年3月27日の 2.0 の発表は、最初の発表を310万人以上の開発者が読み、GitHub のスターが1万を超えたと書いています（ZEIT 自身の数字です）。2.0 は、1.0 に無かった独自のサーバーを足し、自分の Node.js のサーバーからルーティングと描画を受け持てるようにしました。

2020年4月21日、ZEIT は社名を Vercel に改めます。Rauch はその発表で、Next.js は “the framework to build React apps”（React のアプリを作るための、まさにそのフレームワーク）になり、3万5,000を超えるサイトを動かしていると書きました。これも会社自身の評価です。 フレームワークを作る会社が、それを載せるホスティングも売る形は、ZEIT の時代から続いています。

残した課題と、次に来たもの

ファイルの置き場所だけでは足りなくなる

2019年7月8日の Next.js 9 の発表によれば、動的なルーティングは公開直後に GitHub で最初に寄せられた要望の1つで、2.0 の独自サーバーでいったん「解決」していました。ところが独自サーバーを使う一番の理由がそれで、独自サーバーはアプリ全体を1つのまとまりとして配るため、サーバーレスの環境に載せにくい、と同じ発表は書いています。 9 では pages/post/[pid].js のようにファイル名に [ ] を付けて /post/1 などに対応でき、pages/api のファイルがサーバー側の API になる API Routes も入りました。独自のサーバーに逃がしていた仕事を、ファイルの約束に取り込み直した形です。

9 では、データを待たないページをビルドのときに HTML にする自動の最適化も入り、2020年3月9日の 9.3 で、ビルドのときにデータを取る getStaticProps と、リクエストのたびに取る getServerSideProps が分かれます。描画をどこでいつ行うかの考え方は、CSR・SSR・SSG の記事で扱います。

なぜ App Router で作りを大きく変えたのか

2017年の 2.0 の発表は、ページはそれぞれが文書の全体を決め、“There’s no notion of global layouts”（全体に共通するレイアウトという考えは無い）と書いていました。共通の部分は React の部品の組み合わせで作る、という考えです。のちに全体を包む _app.js が使われますが、2023年5月4日の 13.4 の発表は、これでは足りなかったと書いています。

“With the Pages Router, layouts were not able to be composed, and data fetching could not be colocated with the component.” （Pages Router では、レイアウトを組み合わせられず、データの取得を部品と同じ場所に置けなかった）

getServerSideProps で描いたページはページ全体のハイドレーションが終わるまで操作できなかったとも書き、こうした要望は “This wasn’t an easy thing to retrofit into the existing Next.js router.”（既存のルーターに後から組み込むのは簡単ではなかった）としています。そこで新しいルーターを app ディレクトリに別に作り、React Server Components と Suspense の上に載せました。app/dashboard/layout.js のように、レイアウトをフォルダごとに入れ子にできます（ハイドレーションの仕組みは、ハイドレーションの記事で扱います）。

2022年10月の Next.js 13 では app はベータで、“we do not recommend using it in production yet”（まだ本番での利用は勧めない）とされ、pages も当面サポートすると書かれました。13.4 で App Router は安定版になり、同じフレームワークの中に、考え方の違う2つのルーターが並ぶことになりました。

本当に「Next.js は Vercel でしか動かない」のか

2016年の発表から、Next.js は next build と next start で、Node.js が動くサーバーならどこでも動かせました。ただし、Vercel の上と自前のサーバーの上では、同じ機能が別の仕組みで動いていました。

それが表に出たのが、2025年3月21日に公開された CVE-2025-29927 です。内部のヘッダーを付けるとミドルウェアを素通りできる脆弱性で、Vercel の事後報告（3月25日）は、next start や output: 'standalone' で自前で動かすアプリが影響を受けたと書いています。Vercel ではルーティングが別の仕組みで動いていたため、こう説明されました。

“This made Vercel incidentally invulnerable.” （そのため Vercel は、たまたま影響を受けなかった）

同じ理由で、Netlify と Cloudflare Workers も影響を受けなかったと確かめられています。事後報告は次の手として、各社と進める公式の Adapter API で、文書の無かった内部のヘッダーを文書にするか API に置き換えると書きました。 2025年4月に RFC が出て、2025年10月の 16 でアルファ、2026年3月25日の 16.2 で安定版になります。その日の公式ブログは、サーバーを何台も並べるとキャッシュの同期や再検証の伝わり方を正しく動かす必要があり、各機能の組み合わさり方は “never formally documented”（正式に文書にされたことがなかった）と書きました。Vercel の adapter も同じ公開の約束を使い、オープンソースで Next.js のテスト一式を通すものが「verified adapter」になります。

動かし方	公式ドキュメントの説明（2026年8月6日更新）
Node.js のサーバー（`next start`）	すべての機能
Docker	すべての機能
静的な書き出し	限られる
Adapter	場所による。verified は Vercel と Bun
Cloudflare・Netlify など	各社の独自の統合（公式の検証の外）

動かすこと自体は Vercel の外でもでき、どこでどの機能が同じように動くかを揃える作業が、2026年に公式の仕組みになりました。

2026年10月時点の立ち位置

2026年10月時点で最新の版は、10月23日に公開された 16.4.3 です（npm の latest。10月29日に確かめた）。16 系の最初の版は2025年10月21日に発表されました。

指標	数字	出典
この1年に Next.js で本格的な開発をした回答者（全回答者）	20.8%	Stack Overflow Developer Survey 2025
JavaScript のライブラリがわかるサイトのうち Next.js を使う割合	5.0%	W3Techs（2026年10月）
すべての Web サイトのうち Next.js を使う割合	3.7%	W3Techs（2026年10月）
GitHub のスター	143,190	GitHub API（2026年10月29日）

Stack Overflow の同じ表では、React は 44.7%、Node.js は 48.7% でした。 State of JavaScript 2025 は、Next.js が “the 13th most-loved project”（好かれている順で13番目）である一方 “the 5th most-hated”（嫌われている順で5番目）で、コメントの数はもっとも多かったと書き、評価の分かれる枠組みだとしています。 開発者の調査では React の半分ほどの割合の回答者が使い、同時に、好き嫌いのはっきり分かれる枠組みでもあります。

まとめ

2016年、React の画面をサーバーで描くには多くの手順が要り、サーバーの HTML とブラウザのコードも分かれていました。Rauch は2014年に、サーバーで描くか SPA かの二択を誤りだと書いていました。
ZEIT は2016年10月25日に Next.js を公開しました。pages のファイルをそのまま URL にし、同じ React の部品をサーバーとブラウザの両方で描きます。README は PHP の手軽さを手本に挙げ、違いも書いています。
ZEIT は自社サイトで使い、コマンド2つで本番に出せる手軽さを打ち出しました。その後、動的ルート・API Routes・SSG を取り込み、2023年には入れ子のレイアウトのために App Router を作って、2つのルーターが並びました。
自前で動かすときの機能の差は 2025年の脆弱性で表に出て、2026年3月に Adapter API が安定版になりました。
2026年10月時点の最新は 16.4.3 で、Stack Overflow の2025年の調査では回答者の 20.8% が開発に使っています。

年表

2016年10月5日
GitHub に zeit/next.js（のちの vercel/next.js）のリポジトリが作られ、Rauch が最初のコミット「initial spec」を入れる api.github.com
2016年10月25日
ZEIT が公式ブログで Next.js を公開し、同じ日に npm に 1.0.0 が出る web.archive.org
2017年3月27日
Next.js 2.0 で、自分のサーバーのコードからルーティングと描画を受け持てるようになる web.archive.org
2019年7月8日
Next.js 9 で、`pages/post/[pid].js` の形の動的ルートと API Routes が入る nextjs.org
2020年3月9日
Next.js 9.3 で、ビルドのときにデータを取る `getStaticProps` が入る nextjs.org
2020年4月21日
ZEIT が社名を Vercel に改める vercel.com
2022年10月25日
Next.js 13 で、React Server Components の上に作った `app` ディレクトリがベータとして入る nextjs.org
2023年5月4日
Next.js 13.4 で、`app` ディレクトリの App Router が安定版になる nextjs.org
2025年3月21日
ミドルウェアを素通りできる脆弱性 CVE-2025-29927 が公開され、自前のサーバーで動かすアプリが影響を受ける nextjs.org
2026年3月25日
Next.js 16.2 で、動かす場所ごとに出力を合わせる Adapter API が安定版になる nextjs.org

系譜

前

後

答えAstro2021年6月8日

この技術が出てくる物語

サーバーとブラウザの振り子

出典

一次Next.js（Naoyuki Kanezawa・Guillermo Rauch・Tony Kovanen, ZEIT Blog, 2016-10-25） zeit.co 保存版
一次next.js の README（2016年10月25日のコミット 3d44b58d） raw.githubusercontent.com
一次7 Principles of Rich Web Applications（Guillermo Rauch, 2014-11-04） rauchg.com
一次Next.js 2.0（Arunoda Susiripala・Naoyuki Kanezawa・Tim Neutkens, ZEIT Blog, 2017-03-27） zeit.co 保存版
一次Next.js 9（Next.js Blog, 2019-07-08） nextjs.org
一次Next.js 9.3（Next.js Blog, 2020-03-09） nextjs.org
一次ZEIT is now Vercel（Guillermo Rauch, Vercel Blog, 2020-04-21） vercel.com
一次Next.js 13（Next.js Blog, 2022-10-25） nextjs.org
一次Next.js 13.4（Sebastian Markbåge・Tim Neutkens, Next.js Blog, 2023-05-04） nextjs.org
一次Next.js 16（Next.js Blog, 2025-10-21） nextjs.org
一次Postmortem on Next.js Middleware bypass（Ty Sbano, Vercel, 2025-03-25） nextjs.org
一次Next.js Across Platforms: Adapters, OpenNext, and Our Commitments（Jimmy Lai・JJ Kasper, Next.js Blog, 2026-03-25） nextjs.org
一次Deploying（Next.js のドキュメント、2026-08-06 更新） nextjs.org
一次npm registry（next） registry.npmjs.org
一次vercel/next.js（GitHub API） api.github.com
二次Stack Overflow Developer Survey 2025（Technology） survey.stackoverflow.co
二次State of JavaScript 2025（Libraries） 2025.stateofjs.com
二次Usage statistics and market share of Next.js for websites（W3Techs, 2026年10月） w3techs.com