はじめに
2025年現在、Next.jsはApp Router（/app ディレクトリ構成） が正式な推奨構成となりました。
既存のPages Routerから移行する案件も増え、App Routerを理解しているかどうかが実案件でも大きな差になります。
この記事では、実務案件で通用するNext.js App Router構成の設計ポイント・詰まりポイント・ベストプラクティスをまとめます。
想定読者
- Next.jsで最新構成を理解したい方
- 案件設計でApp Routerを採用したい方
- フロントエンド受託・SaaS開発の実務担当者
App RouterとPages Routerの違い整理
| 比較項目 | App Router | Pages Router |
|---|---|---|
| ルーティング |
app/ ディレクトリベース |
pages/ ディレクトリベース |
| Server Component | 標準対応 | 非対応（Client Only） |
| レイアウト管理 |
layout.tsxによる階層管理 |
_app.tsxに全体管理 |
| データ取得 |
fetch / server actions
|
getServerSideProps 等 |
| SEO最適化 | 柔軟に構成可能 | 比較的限定的 |
👉 App RouterはSSR/SSGの切り替え自由度が圧倒的に高い。
App Router基本構成テンプレ
/app
/layout.tsx （共通レイアウト）
/page.tsx （トップページ）
/dashboard
/layout.tsx （ダッシュボード専用レイアウト）
/page.tsx （ダッシュボードTOP）
/api
/route.ts （APIエンドポイント）
- ルート定義がディレクトリ階層そのまま → 視認性が非常に高い
- layoutのネストで共通ヘッダー・サイドバーを整理しやすい
実案件設計でのキモ
✅ Layoutの正しいネスト設計
export default function Layout({ children }: { children: ReactNode }) {
return (
<div>
<Header />
<Sidebar />
<main>{children}</main>
</div>
);
}
- ページ種類別にLayoutを細かく分割 → 保守性が爆上がり
- SaaS管理画面 / コーポレートサイトでも非常に有効
✅ Server Component前提の設計思想
- デフォルトでServer Componentになる
- DB接続・APIフェッチ・ヘビー処理は極力Server側で実施
- クライアント専用は
"use client"で分離
データ取得設計の変更ポイント
✅ getServerSideProps → fetch + async/await へ移行
App Routerの例：
import { getUser } from '@/libs/api';
export default async function Page() {
const user = await getUser();
return <div>{user.name}</div>;
}
👉 非同期処理がより自然な形で統合可能に。
✅ Server Actionの活用（実務登場し始めている）
'use server';
export async function submitForm(data: FormData) {
// DB登録処理
}
- Form直結でDB書き込みも可能
- 実案件ではまだ採用見極め段階（商用SaaSは要注意）
API設計：/api ルートの使い分け
- 軽量API →
/api/route.ts - 重量API / 本格API → BFF化 (tRPC / external server)
👉 App Router内APIは小規模用が相性良い。
Client Componentの整理
- 状態管理・UIインタラクションはクライアントへ分離
'use client';
import { useState } from 'react';
export default function Button() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>{count}</button>;
}
👉 "use client" を上位に限定する方がパフォーマンス最適
実案件での詰まりポイントまとめ
| 詰まりポイント | 回避策 |
|---|---|
| レンダリング混乱 | Server/Client責務を明確に |
| API設計迷走 | 軽量APIはApp Router内、それ以上はBFFへ |
| Layout肥大化 | ページ単位でネスト分離 |
| 認証処理の場所 | Server Component内セッション判定推奨 |
| データ取得二重処理 | Server側先取りフェッチを基本に |
App Routerを採用すべき案件例
- SaaS管理画面（内部管理・ダッシュボード）
- コーポレートサイト（SSG/ISR活用）
- 小〜中規模のプロトタイプSaaS開発
- BtoBシステムの管理ポータル
👉 API連携・状態管理・保守性全体が綺麗に整理しやすい
App Router設計を提案できる強み
- 設計提案段階で差別化できる
- 保守コストが下がる → クライアント評価高い
- SaaS/受託/内製問わず長期案件に入りやすくなる
おわりに
App Routerはまだ移行期にありますが、2025年の受託・SaaS開発では完全に主流になりつつあります。
ここを理解して設計提案できるエンジニアは実務でも非常に重宝されます。
Qiitaでは今後もこういった最新フロント設計Tipsを発信していきますので、ぜひLGTM・フォローお願いします！