Next.js、Pages Routerはもう書くな──App Router中心設計への完全移行

Next.jsとは何か──Reactエコシステムの中心的存在

Next.jsはVercelが開発・メンテナンスするReactベースのフルスタックフレームワークだ。 2016年に初版がリリースされ、2024年末時点でバージョン15が最新となっている。 Reactは「UIを構築するためのライブラリ」であり、ルーティング、SSR（サーバーサイドレンダリング）、データ取得といった機能は含まれていない。 Next.jsはそれらの欠けたピースをすべて提供し、プロダクションに耐えるWebアプリを効率的に構築できる環境を整える。

2026年時点の主要Reactフレームワークを比較すると、それぞれの設計思想の違いが明確に見えてくる。

フレームワーク	開発元	設計思想	向いているユースケース	GitHub Stars（概算）
Next.js	Vercel	フルスタック・サーバー中心	ECサイト、メディア、SaaSダッシュボード	130,000+
Remix	Shopify	Web標準・ネストレイアウト	フォーム操作の多いアプリ、ECフロント	30,000+
Gatsby	Netlify	静的サイト生成特化	ブログ、ドキュメントサイト	55,000+
Astro	Astro	コンテンツ中心・Islands Architecture	ランディングページ、ドキュメント	48,000+

Next.jsが他と一線を画す点は「フルスタック性」にある。 単一のリポジトリでフロントエンドのUIとバックエンドのAPIロジックを管理でき、Server Actionsを使えばデータベース操作すらAPIルートなしで実装できる。 ReactエコシステムのデファクトスタンダードとしてVercelがNext.jsに積極的に投資している背景もあり、React 19の新機能（Server Components、Actions）をいち早く実用化する場になっている。 Remixはフォーム中心のUXに強く、AstroはJavaScriptをできるだけ送らないコンテンツサイトに最適だが、「まず覚える1つのフレームワーク」としての汎用性はNext.jsが最も高い。

App Routerの基本概念──Pages Routerとの決定的な違い

Next.jsを学ぶ上で最初の壁となるのが「App RouterとPages Routerのどちらで書くか」という問題だ。 2023年にApp Routerが安定版になって以来、公式はApp Routerへの移行を推奨している。 2026年時点では新規プロジェクトでPages Routerを選ぶ理由は少なく、既存の移行案件を除けばApp Routerを前提に学習を進めるべきだ。 なお、既存プロジェクトをPages RouterからApp Routerへ段階的に移行するための公式マイグレーションガイドも整備されている。

比較項目	Pages Router（旧）	App Router（現行推奨）
ルートディレクトリ	pages/	app/
レイアウト管理	_app.tsx で管理	layout.tsx でネスト可能
データ取得	getServerSideProps / getStaticProps	async Server Componentで直接fetch
サーバー処理	API Routes（pages/api/）	Server Actions（'use server'）
コンポーネントのデフォルト	クライアントコンポーネント	サーバーコンポーネント
ローディングUI	なし（手動管理）	loading.tsx で自動的にSuspense
エラーUI	なし（手動管理）	error.tsx でエラーバウンダリ
キャッシュ制御	revalidate オプション	fetchのキャッシュオプションで細粒度制御
React Server Components	非対応	完全対応

App Routerの最も重要な変更点は「デフォルトがサーバーコンポーネント」であることだ。 Pages Routerではすべてのコンポーネントがクライアントで動作するため、バンドルサイズが肥大化しやすかった。 App Routerではサーバーで実行されるコンポーネントがデフォルトとなり、クライアントに送るJavaScriptの量を最小限に抑えられる。 クライアントの状態（useState、useEffectなど）が必要な場合のみ、ファイル先頭に 'use client' ディレクティブを追加する。 この「サーバーかクライアントかを明示する」設計は最初は戸惑いを生むが、慣れると責務の分離が明確になりコードの見通しが改善する。

プロジェクト構造──ファイルベースルーティングの全体像

Next.jsはファイルシステムがそのままURLになる「ファイルベースルーティング」を採用している。 app/ ディレクトリ以下に配置したフォルダとファイルが、そのままルートとして機能する設計だ。 設定ファイルに複雑なルート定義を書く必要がなく、ファイルの配置を見るだけでURLの構造が把握できる。 Expressのような手動ルート定義と比べると、チームメンバーがプロジェクトに参加した際にも学習コストが低く抑えられる。

ファイル・ディレクトリ	役割	具体例
app/page.tsx	ルートのページコンポーネント	/ へのアクセスで表示
app/layout.tsx	全ページ共通レイアウト	ヘッダー・フッター・フォント設定
app/[slug]/page.tsx	動的ルートのページ	/articles/nextjs-guide などに対応
app/[slug]/layout.tsx	ネストレイアウト	セクション固有のサイドバーなど
app/loading.tsx	Suspenseフォールバック	ページ読み込み中のスケルトンUI
app/error.tsx	エラーバウンダリ	予期しないエラーのフォールバック
app/not-found.tsx	404ページ	ページが存在しない場合のUI
app/api/route.ts	APIエンドポイント	REST APIの実装（外部サービス連携など）
app/actions.ts	Server Actions	フォーム処理・DB操作
public/	静的ファイル	画像、favicon、robots.txt など
next.config.ts	Next.js設定ファイル	画像ドメイン、リダイレクト、環境変数設定

実際のブログ構築プロジェクトでは、app/blog/page.tsx に記事一覧ページ、app/blog/[slug]/page.tsx に記事詳細ページを配置するのが基本パターンだ。 動的ルートでは generateStaticParams 関数を使うことで、ビルド時に全記事ページを静的生成できる。 共通のヘッダーやナビゲーションは app/layout.tsx に記述し、ブログセクション固有のサイドバーは app/blog/layout.tsx に切り出すことで、レイアウトを段階的に構成できる。 ネストされたレイアウトはPages Routerにはなかった仕組みで、大規模なサイト構築で特に威力を発揮する。

レンダリング戦略──SSR・SSG・ISRの使い分け

Next.jsの強みの一つが、ページごとにレンダリング方式を選択できる柔軟性だ。 同一アプリ内で、トップページは静的生成、ダッシュボードはサーバーサイドレンダリング、ブログ記事はISRという組み合わせが可能だ。 パフォーマンスとリアルタイム性のバランスをルート単位でコントロールできる点が、Next.jsが本番環境で選ばれる大きな理由の一つだ。 これはReact単体では実現できない機能であり、フレームワークとしてのNext.jsの価値の核心部分でもある。

レンダリング方式	生成タイミング	キャッシュ	向いているページ	App Routerでの実装方法
SSG（静的サイト生成）	ビルド時	CDNキャッシュ	ランディングページ、ブログ記事	デフォルト動作（fetchキャッシュ有効）
ISR（増分静的再生成）	ビルド時 + 定期的に再生成	CDNキャッシュ + 再生成	ニュース記事、商品ページ	next.revalidate オプション指定
SSR（サーバーサイドレンダリング）	リクエストごと	なし（または短時間）	ダッシュボード、パーソナライズページ	cache: 'no-store' オプション指定
CSR（クライアントサイドレンダリング）	ブラウザで実行	ブラウザキャッシュ	インタラクティブなUI、リアルタイム更新	'use client' + useEffect
PPR（部分的プリレンダリング）	静的部分はビルド時、動的部分はリクエスト時	静的部分はCDN	多くの本番ユースケース	next.config で ppr 有効化

App RouterではPages Routerの getServerSideProps / getStaticProps という明示的な関数がなくなり、fetch関数のキャッシュオプションで制御する方式に変わった。 revalidate: 3600 を指定すると1時間ごとにデータを再検証するISR相当の動作になる。 PPR（Partial Prerendering）は2025年にNext.js 15で安定版となった新機能で、1ページの中で静的部分と動的部分を混在させられる。 ページの大部分はCDNキャッシュで高速配信しつつ、ユーザー固有のデータだけをリクエスト時に取得するという設計が可能になり、パフォーマンスとリアルタイム性を高い次元で両立できる。

データ取得方法──Server ComponentsとServer Actions

App RouterにおけるデータのやりとりはServer Componentsによる読み取りとServer Actionsによる書き込みに大別される。 従来のSPAアーキテクチャで必要だった「APIルートを定義してクライアントからfetch」というパターンを省略できるのが大きな変化だ。 この設計変更によりコード量が削減され、データフローが追いやすくなった。 型安全なデータフローを維持するためにTypeScriptとZodを組み合わせる実装パターンが広く採用されている。

データ処理	方式	特徴	主な用途
読み取り（一覧・詳細）	Server Componentで直接fetch	コンポーネント内で非同期処理が完結	ブログ一覧、商品詳細、ユーザープロフィール
読み取り（クライアント依存）	useEffect + fetch または SWR/TanStack Query	ブラウザ情報に基づく動的取得	位置情報依存データ、リアルタイム更新
書き込み（フォーム）	Server Actions	HTMLのformと連携、JSなしでも動作	問い合わせフォーム、コメント投稿
書き込み（インタラクティブ）	Server Actions + useTransition	ローディング状態を管理しつつ非同期実行	「いいね」ボタン、カート追加
認証セッション管理	Middleware + Server Actions	Edge Runtimeで高速認証チェック	ログイン・ログアウト、セッション更新
外部APIとの連携	Server Componentでプロキシ	APIキーをサーバー側に秘匿	外部サービスとのデータ統合

ブログ構築の実例でいえば、記事一覧ページはServer Component内でSupabaseクライアントを呼び出し、記事データを取得して表示する。 新規コメントの投稿はServer Actionsを使い、フォームのaction属性に関数を直接渡す形で実装できる。 Server Actionsはサーバーで実行されるため、環境変数のAPIキーはクライアントに公開されない。 データベースの直接操作もサーバー側で完結できるため、フロントエンドエンジニアが単独でフルスタック機能を実装できる体制が整う。 認証ライブラリはAuth.js（旧NextAuth.js）が最も普及しており、SupabaseやPrismaとの組み合わせ事例も多い。

デプロイ先の選択肢──Vercelだけではない現実

「Next.jsはVercelにデプロイするもの」というイメージは強いが、実際には選択肢は幅広い。 プロジェクトの規模、コスト要件、既存インフラとの兼ね合いによって最適解が変わる。 特に本番トラフィックが増えてきた段階でVercelの従量課金が課題になるケースは珍しくない。 デプロイ先の選択は「後から変更できる」という点も重要で、最初はVercelで開発速度を優先し、スケール後に最適化する方針が多くのスタートアップで採用されている。

デプロイ先	特徴	無料枠	向いているケース	App Router対応
Vercel	Next.js開発元、最もネイティブな対応	あり（帯域制限付き）	スタートアップ、個人開発、プロトタイプ	完全対応（PPRなど最新機能も即時対応）
AWS（Lambda + S3 + CloudFront）	細かい制御が可能、コスト最適化しやすい	無料枠あり（12ヶ月）	大規模サービス、既存AWSインフラとの統合	OpenNextで対応可能
Google Cloud Run	コンテナベース、スケーリングが柔軟	無料枠あり	GCPを使う組織、Dockerコンテナ運用チーム	コンテナ化で対応
Cloudflare Pages	Edge Networkによる高速配信、コスト安	無料枠あり	グローバル展開、静的サイト寄りのプロジェクト	@opennextjs/cloudflareで対応
セルフホスティング（VPS）	完全な制御、月額固定コスト	なし（VPS費用が必要）	コスト予測が重要な企業、データ主権が必要なケース	Node.jsサーバーとして動作可能
Render / Railway	Vercelに近い体験、コスト重視	あり（スリープあり）	コストを抑えたい個人・スタートアップ	標準対応

Vercelは最新のNext.js機能（PPR、Edge Runtime など）との互換性が最も高く、デプロイ設定の手間も最小限だ。 GitHubとの連携でプッシュするだけで自動デプロイが完了するDeveloper Experienceは他の追随を許さない。 一方、本番トラフィックが増えるとコストが急増するリスクがある。 大規模サービスや既存のAWSインフラを持つ企業では、OpenNextを使ったAWSデプロイが費用対効果の面で有利になることが多い。 Cloudflare Pagesは静的コンテンツ配信に強く、グローバルに低レイテンシを実現したい場合に有力な選択肢だ。 個人開発の初期フェーズはVercelの無料枠で十分対応できるため、まずはVercelから始めて必要に応じて移行するアプローチが現実的だ。

学習ロードマップ──段階的に習得するNext.js

Next.jsの学習範囲は広く、闇雲に進めると迷走しやすい。 React基礎から始めてプロダクション運用まで、段階的に積み上げる構造を示す。 各ステージの期間は前提知識や学習時間によって大きく変わるが、週10〜15時間の学習を想定した目安だ。 プログラミング未経験からの場合はJavaScript基礎（変数、関数、非同期処理）をStage 1の前に2〜4週間かけて学ぶことを推奨する。

ステージ	習得内容	目標期間（目安）	到達レベル
Stage 1: React基礎	コンポーネント、props、useState、useEffect、JSX	2〜4週間	カウンターやTodoリストが作れる
Stage 2: Next.js入門	ファイルベースルーティング、App Router構造、layout/page	1〜2週間	複数ページのサイトが作れる
Stage 3: データ取得	Server Components、fetch、動的ルート、generateStaticParams	2〜3週間	DBと連携したブログが作れる
Stage 4: インタラクティブ機能	Server Actions、useFormStatus、Auth.js、フォーム処理	2〜4週間	ログイン機能付きアプリが作れる
Stage 5: スタイリングと品質	Tailwind CSS、shadcn/ui、エラーハンドリング、TypeScript強化	2〜3週間	プロダクション品質のUIが作れる
Stage 6: パフォーマンス最適化	Image最適化、Metadata API、キャッシュ戦略、PPR	2〜4週間	Core Web Vitalsスコアが良好なサイトが作れる
Stage 7: デプロイと運用	Vercel/AWSへのデプロイ、環境変数管理、監視・ログ	1〜2週間	本番公開・継続運用ができる

学習リソースとして公式ドキュメント（nextjs.org/docs）は網羅的でよく更新されており、最初の参照先として最適だ。 公式のインタラクティブチュートリアルはブログアプリを段階的に構築する内容で、Stage 2〜4の内容を実践的に学べる。 日本語コミュニティとしてはZennとQiitaに実装事例が豊富にある。 TypeScriptと組み合わせることが業界標準であるため、JavaScriptベースで学び始めても早期にTypeScriptへ移行することを推奨する。 また、Prisma（ORM）またはSupabase（BaaS）とセットで学ぶとデータ層まで含めたフルスタック開発の全体像がつかみやすい。 「まずブログを1本公開する」という具体的な目標を持つと、ロードマップの各ステージが現実の課題と結びつき、学習が加速する傾向がある。

さらに先へ──Next.jsで何を作るか

Next.jsはReactフレームワークの選択肢の中で最も広い用途をカバーし、個人ブログからエンタープライズのSaaSプラットフォームまで対応できる実力を持つ。 App RouterとServer Componentsによって、従来のフロントエンドとバックエンドの境界線が曖昧になり、フルスタックエンジニアとしてのキャリアを形成しやすい環境が整いつつある。 学習コストは決して低くないが、習得できれば国内外の求人市場での価値は高く、個人開発でもアイデアを素早くプロダクトに変えられる武器になる。 2026年現在、AI機能との統合においてもNext.js + Vercel AI SDKの組み合わせが標準的なスタックとして確立されており、LLMを活用したプロダクト開発のファーストチョイスになっている。 コミュニティの規模も大きく、GitHubのDiscussions、Discord、Zennなど多様なチャンネルで最新情報を収集できる。 フレームワークの進化スピードは速いが、コアの概念（ファイルベースルーティング、Server Components、レンダリング戦略）は安定しており、一度身につければ長く通用する基礎となる。

あなたが今まさに作りたいと思っているWebアプリは、Next.jsのどのレンダリング戦略に最も近いだろうか。

導入5ステップ

ステップ1: Node.js環境とプロジェクト作成

Node.js 20以上をインストールし、npx create-next-app@latest でプロジェクトを作成する。App Router、TypeScript、Tailwind CSS、ESLintを有効化すると推奨構成でセットアップが完了する。

ステップ2: App Routerのルーティング理解

app/ 配下の page.tsx がルートになる仕様を把握する。layout.tsx で共通レイアウト、loading.tsx でサスペンス、error.tsx でエラー境界を配置し、ファイルベースのルーティングを体得する。

ステップ3: Server ComponentsとClient Componentsの使い分け

デフォルトはServer Component、インタラクティブな要素は 'use client' を付けてClient Componentにする。データ取得はサーバー側、状態管理はクライアント側という原則を徹底する。

ステップ4: Server Actionsでミューテーション実装

'use server' ディレクティブを付けた関数をフォームの action 属性に渡す。DB更新後は revalidatePath() でキャッシュを無効化し、APIルートなしで書き込み処理が完結する構成に慣れる。

ステップ5: Vercelへのデプロイと運用

GitHubリポジトリをVercelに接続し、mainブランチへのpushで自動デプロイを走らせる。環境変数をダッシュボードで設定し、プレビューデプロイとAnalyticsで本番運用に入る。

よくある質問（FAQ）

Q. Pages RouterからApp Routerに移行すべき？

新規プロジェクトはApp Router一択です。既存のPages Routerプロジェクトは無理に移行せず、新機能のみApp Routerで実装するハイブリッド運用が現実的です。Next.js 16以降、Pages Routerは機能追加が停止しているため、中長期では移行が必要になります。

Q. Server ComponentsとClient Componentsの使い分けは？

デフォルトはServer Componentsで、useState・useEffect・イベントハンドラが必要な箇所だけ "use client" を付けます。データ取得はServer Componentsで行い、Client Componentsには描画済みの結果を渡すのがパフォーマンス的にも保守性的にも最適です。

Q. デプロイ先はVercel以外でも問題ない？

開発体験はVercelが圧倒的ですが、Cloudflare Pages（安価・高速）やセルフホスト（Docker）も選択肢になります。Server ActionsやISRなど一部機能はアダプターが必要で、特殊な設定が発生することに留意してください。

関連記事

• TypeScript入門｜JavaScriptとの違いと型安全な開発の始め方
• React入門ガイド｜コンポーネント設計からHooksまで体系的に学ぶ
• AIにお任せWeb制作入門──v0で作って、Vercelで公開して、Cursorで直す
• React vs Vue 徹底比較2026
• VS Codeおすすめ拡張機能30選