Next.js の Pages Router から App Router へ段階的に移行する完全ガイド。共存モードの使い方、規模別の工数見積もり、getServerSideProps や API Routes の書き換え、破壊的変更対策まで実務ベースで解説します。
最終更新: 2026年9月10日
Next.js の Pages Router から App Router への移行は、app/ ディレクトリを既存の pages/ と並行して段階的に導入するのが基本戦略です。両ルーターは同一ビルド内で共存でき、ルート単位で切り替えられるため、20〜50ルート規模の実プロダクトなら概ね5〜15営業日で完了できます。本記事では、Next.js 16 環境で getServerSideProps / getStaticProps / API Routes / _app.tsx を実運用ベースで書き換える具体的な手順、互換性の落とし穴、そして工数見積もりのテンプレートを提示します。
pages/ と app/ は同一ルートを持てないが、それ以外は自由に混在させられる。getServerSideProps は Server Components の fetch() へ、getStaticProps は静的 Server Components + generateStaticParams へ、API Routes は Route Handlers へ移行する。_app.tsx / _document.tsx は app/layout.tsx に統合され、グローバル CSS ・プロバイダ・メタデータの取り扱いが根本的に変わる。結論から言えば、2026年時点で新規プロジェクトは全て App Router、既存プロジェクトは「向こう2年以上メンテする予定」なら移行する価値があります。公式の App Router ドキュメントでも Pages Router は「引き続きサポートするが、新機能の追加は行わない」と明言されています。私が過去14ヶ月で移行を手伝ったチームは12社で、そのうち10社は「早めにやっておいてよかった」と述べ、残り2社は「小規模なランディングページなので Pages Router のままで十分だった」というのが率直な感触です。
判断のチェックリストは以下の通りです。移行すべき：Server Components による初期ペイロード削減が効くコンテンツ重い SPA、PPR や Cache Components を使いたい EC・メディアサイト、React 19 の非同期コンポーネント機能を活用したいチーム。据え置きでよい：近く廃止予定のプロジェクト、6ヶ月以内にリライト予定、機能追加が凍結されたレガシー管理画面。判断を後回しにすると、依存ライブラリ側が App Router 前提の API しか提供しなくなる時期（体感で2027年後半以降）に一気に負債が顕在化するため、少なくとも「移行ロードマップの下書き」は今作っておくのが安全です。
結論から言うと、できます。pages/ と app/ ディレクトリは同一プロジェクトに共存でき、同じルートパス（例：/dashboard）を両方に置かない限り衝突しません。同じパスが両方に存在する場合は app/ が優先され、ビルド時に警告が出ます（正直この警告メッセージは見落としがちなので、CI のログを目視で追う癖をつけておくと安心です）。この共存モードこそが、段階的移行の心臓部です。1日で全ページを書き直す必要はなく、影響範囲の小さいルートから1つずつ App Router へ移していけます。
ただし共存には注意点があります。グローバル CSS は _app.tsx と app/layout.tsx の両方でインポートすると2重ロードされるため、片方に寄せる必要があります。認証セッションは Pages Router 側では getServerSideProps でクッキーを読むのに対し、App Router 側では Server Components 内で cookies() を使うため、両ルートで同一の認証ヘルパを共有する薄いラッパを最初に作っておくと後が楽です。Middleware はプロジェクトルートの middleware.ts 1つで両ルーターに対して動作するため、ここは書き直し不要です。Next.js Middleware の認証・国際化実装パターンは既存の記事で詳しく扱っているので、認証周りを触る前に一読しておくことをお勧めします。
移行工数を「なんとなく1ヶ月」で見積もる会社が多いのですが、私が過去のプロジェクトから抽出した実測値をベースにした見積もりテーブルを共有します。以下は Next.js 経験3年以上のエンジニア1名がフルタイムで作業した場合の実数値です。
| プロジェクト規模 | ルート数 | API Routes数 | 認証 | 予想工数（人日） |
|---|---|---|---|---|
| マイクロ（LP・ブログ） | 1〜10 | 0〜3 | なし | 2〜5日 |
| 小規模（SaaSの一部） | 10〜25 | 3〜10 | OAuthのみ | 5〜10日 |
| 中規模（プロダクト全体） | 25〜60 | 10〜30 | 複数プロバイダ | 10〜20日 |
| 大規模（EC・複雑なCMS） | 60〜150 | 30〜80 | SSO・多要素 | 3〜6週間 |
| エンタープライズ | 150+ | 80+ | SAML等 | 2〜4ヶ月 |
これらの数値には以下が含まれます：ルート書き換え、データ取得の Server Components 化、認証ヘルパの共通化、テストの再整備、CI/CD の調整。含まれないもの：デザインの刷新、UI コンポーネントライブラリの入れ替え、React 18 から 19 への破壊的変更対応（追加で3〜7日）。「複数プロバイダ認証」を含む中規模プロジェクトで、私が最近担当したケースでは正味13営業日でした。事前の見積もりが12日、実績13日。この精度で見積もれるようになるまでには3〜4回の実案件経験が必要です。
App Router への移行を8つのフェーズに分けて進めます。それぞれのフェーズが独立してデプロイ可能で、途中で凍結してもプロダクションは動き続けるのが理想です。
まず Pages Router のまま Next.js を最新版に上げます。App Router は Next.js 13.4 以降で安定版ですが、Server Actions と PPR が完全に揃うのは 15 以降、Cache Components を含めて最も洗練されているのは 16 です。codemod ツールで大半の破壊的変更は自動対応できます。
npx @next/codemod@canary upgrade latest
npm run build
npm testapp/layout.tsx と app/page.tsx の最小構成を追加します。この時点では既存の Pages Router が引き続き優先されるルートを作らないこと。
// app/layout.tsx
import type { ReactNode } from 'react'
import './globals.css'
export const metadata = {
title: {
template: '%s | MyApp',
default: 'MyApp',
},
}
export default function RootLayout({ children }: { children: ReactNode }) {
return (
<html lang="ja">
<body>{children}</body>
</html>
)
}フェーズ3は共通レイアウトの移設、フェーズ4は認証プロバイダ・状態管理の Client Component 化、フェーズ5は静的ページ（About・利用規約など）から順次 App Router へ移動、フェーズ6は動的データ取得ページ（ダッシュボード等）、フェーズ7は API Routes を Route Handlers に、フェーズ8は最後に残った _app.tsx / _document.tsx を削除して pages/ ディレクトリごとリムーブします。各フェーズを1〜2日ずつに区切って PR を分けると、レビュー負荷が現実的な範囲に収まります。
さて、ここが移行作業の心臓部です。Pages Router のデータ取得 API は、App Router では基本的に Server Components 内の await fetch() に置き換わります。この一点だけでコード量が減り、型推論も自然になります。私が最初に触ったときは「え、これだけ？」と拍子抜けしたぐらいシンプルです。まずは getServerSideProps の直訳例を見ていきましょう。
// Before: pages/products/[id].tsx
export async function getServerSideProps({ params }) {
const res = await fetch(`https://api.example.com/products/${params.id}`)
const product = await res.json()
return { props: { product } }
}
export default function ProductPage({ product }) {
return <h1>{product.name}</h1>
}
// After: app/products/[id]/page.tsx
export default async function ProductPage({
params,
}: {
params: Promise<{ id: string }>
}) {
const { id } = await params
const res = await fetch(`https://api.example.com/products/${id}`, {
cache: 'no-store',
})
const product = await res.json()
return <h1>{product.name}</h1>
}getStaticProps + getStaticPaths の組み合わせは、Server Components に generateStaticParams を組み合わせる形になります。ISR（Incremental Static Regeneration）を使っていた場合は、fetch() の next: { revalidate: 60 } オプションに置き換えるだけで、同等の再検証挙動が得られます。Cache Components と use cache の詳細解説は App Router 移行と密接に絡むため、データ取得を書き換える前に一度目を通しておくと理解が早くなります。
API Routes（pages/api/*.ts）は App Router では Route Handlers（app/api/*/route.ts）へ移行します。ハンドラの引数が (req, res) から Web 標準の Request オブジェクトに変わり、レスポンスは Response または NextResponse を返す形式になります。この変更により、Edge Runtime との互換性が高まり、Cloudflare Workers など他の Web 標準ランタイムへの移植も現実的になります。
// Before: pages/api/users/[id].ts
export default async function handler(req, res) {
if (req.method === 'GET') {
const user = await db.user.findUnique({ where: { id: req.query.id } })
return res.status(200).json(user)
}
return res.status(405).end()
}
// After: app/api/users/[id]/route.ts
import { NextResponse } from 'next/server'
export async function GET(
req: Request,
{ params }: { params: Promise<{ id: string }> }
) {
const { id } = await params
const user = await db.user.findUnique({ where: { id } })
return NextResponse.json(user)
}HTTP メソッドごとに関数をエクスポートするため、if (req.method === 'GET') のような分岐が不要になり可読性が向上します。ミドルウェア的な処理（認証チェック、レート制限）は共通ヘルパにまとめ、各 GET / POST ハンドラの冒頭で呼び出す形にすると保守が楽です。詳しい REST・Webhook 実装はRoute Handlers での REST API・Webhook 実装ガイドで扱っています。
Pages Router 時代の _app.tsx（全ページ共通ラッパ）と _document.tsx（HTML の骨格）は、App Router では app/layout.tsx 1ファイルに統合されます。これは単なる置き換えではなく、責務の分離が根本から変わります。<html> と <body> タグは layout.tsx 内に置き、グローバル CSS もここでインポートします。フォント最適化は next/font、メタデータは export const metadata または generateMetadata() 関数で宣言的に扱う形になります。
状態管理ライブラリ（Zustand、Jotai、Redux Toolkit）のプロバイダは Client Component として別ファイルに切り出し、それを layout.tsx 内で <Providers> のように呼び出します。ここで一番よくある事故は、layout.tsx 自体を Client Component 化してしまうこと。私も最初のプロジェクトでこれをやらかしました。1日デバッグして「なぜバンドルが小さくならないんだ…」と首をひねった記憶があります。これをやると Server Components のメリットが全滅するので、必ずプロバイダ側だけを Client Component にする形を守ってください。
// app/providers.tsx
'use client'
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
import { useState } from 'react'
export function Providers({ children }: { children: React.ReactNode }) {
const [client] = useState(() => new QueryClient())
return <QueryClientProvider client={client}>{children}</QueryClientProvider>
}
// app/layout.tsx
import { Providers } from './providers'
export default function RootLayout({ children }) {
return (
<html lang="ja">
<body>
<Providers>{children}</Providers>
</body>
</html>
)
}Client Components でルーター操作を行う場合、useRouter のインポート元が next/router から next/navigation に変わります。API 形状も変わっており、router.query は廃止、代わりに useSearchParams() と useParams() を使います。router.pathname は usePathname() に置き換わりました。
// Before
import { useRouter } from 'next/router'
const router = useRouter()
const { id } = router.query
router.push('/dashboard')
// After
'use client'
import { useRouter, useParams, useSearchParams } from 'next/navigation'
const router = useRouter()
const { id } = useParams<{ id: string }>()
const searchParams = useSearchParams()
router.push('/dashboard')移行時の頻出バグは、Server Components 内で useRouter を使おうとしてビルドが落ちるケースです。Server Components ではルーター API 全般が使えず、代わりに Server Actions での redirect()（next/navigation からインポート）や revalidatePath() を使います。この線引きに慣れるまで数日かかるので、最初のうちは PR ごとに Server / Client の境界を明示的にレビューする習慣をつけると事故が減ります。
App Router 移行時に「動くはずなのに動かない」という現象が出やすい定番パターンを、私が見た頻度順に挙げます。事前に把握しておくとデバッグ時間が半分以下になります。
window / localStorage アクセス：ビルドは通るがランタイムで落ちる。'use client' ディレクティブを付け忘れている典型例。metadata エクスポートに置き換える。pages/_error.tsx は無視される。app/error.tsx と app/not-found.tsx を作成する必要がある。cookies() を呼べる。_document.tsx の hack が効かないため、App Router 対応の CSS-in-JS 設定に書き換えが必要。App Router への移行に迷う理由の1つは「そもそも他フレームワークに乗り換えた方がいいのでは」という選択肢が視界に入るからです。フェアに比較しておきます。Remix（React Router v7 と統合済み）は、フォームベースの UI と Web 標準準拠の哲学に強みがあり、既存の React コードベースからの移行難易度は Next.js App Router と同程度です。Astro はコンテンツ主体のサイト（ドキュメント・マーケティング）に圧倒的に向いており、動的な SaaS には不向き。SvelteKit は React エコシステムを離れる決断が必要なので、React 資産が大きい場合は現実的な選択肢になりません。
私の経験値では、既に Next.js Pages Router で運用中のプロジェクトについては、App Router 移行の方が Remix 移行より工数が20〜40%少ないケースが多数派です。理由はシンプルで、依存ライブラリ・デプロイ設定・チームの学習曲線がすべて連続的だからです。他方、コンテンツ量が多くインタラクションが少ない場合は Astro への移行が最も投資対効果が高いケースもあります。「フレームワークを変える」ことが目的ではなく、「今後2〜3年の開発体験と性能を最適化する」ことが目的なので、まず既存資産の性質を測ってから決めてください。
2026年9月時点で公式な廃止スケジュールは発表されていません。Vercel は「引き続きサポートするが新機能は追加しない」というスタンスを維持しています。ただし PPR や Cache Components などの目玉機能が App Router 専用のため、事実上の非推奨化が進行しており、新規プロジェクトを Pages Router で始める積極的な理由はありません。
はい、共存モードを使えば無停止で移行できます。ルート単位で App Router に切り替えるたびに個別デプロイし、問題が発生した場合はそのルートだけ Pages Router 側にロールバック可能です。私が担当した12案件のうち、本番停止を伴った移行は0件でした。
多くの場合は上がりますが、無条件ではありません。Server Components により初期 JavaScript ペイロードが平均20〜40%減り、LCP は15〜35%改善する実測データが多いです。ただし全ページを Client Components だらけにしてしまうと逆にオーバーヘッドが増えるため、Server / Client の境界設計が改善幅を決めます。
params と searchParams が Promise 化された Next.js 15 以降、公式の codemod（npx @next/codemod@canary next-async-request-api）で大半は自動書き換え可能です。ただしカスタムの型ヘルパを持っている場合は手動修正が必要になります。
技術的には可能ですが、推奨しません。ビルドサイズが増え、開発者が「どちらのルールでコードを書くか」を毎回判断する必要が生じます。目安として、共存期間は3〜6ヶ月以内に収め、その間に完全移行を終える計画を最初に立てておくのが健全です。
Next.js 16 App Routerのエラーハンドリングを、error.tsx・global-error.tsx・not-found.tsx・Sentry・onRequestErrorの5層で実装するパターンを、100件超の本番障害調査から得た知見と型安全なコードで解説します。
Next.js 16のStreaming SSRとSuspenseでTTFBを40〜90ms、LCPを400ms台まで短縮する実装パターンを、本番事例の計測データとReact DevToolsのトレース、PPR連携、アンチパターンまで含めて解説します。
Next.js 16 で default になった Turbopack を本番ビルドで使うための完全ガイド。monorepo での root 設定、persistent cache、Turborepo との組み合わせ、Webpack からの移行手順、CI キャッシュ戦略、トラブルシューティングまで、Cal.com の公式ベンチマークと実プロジェクトの経験を交えて解説します。