Next.js×AI開発ワークフロー:SSR/ISR/App Routerの実装支援

AIを知りたい

Next.jsのApp RouterってPages Routerと全然違うので、移行が大変そうです…。Server ComponentsとClient Componentsの使い分けが特によく分かりません。

AIエンジニア

App Routerへの移行は確かに学習コストが高いですが、AIを使えばServer ComponentsとClient Componentsの使い分けを自動判定してくれます。「use client」ディレクティブを付けるべきコンポーネントをAIが正確に判断し、最小限のクライアント境界で設計してくれます。既存のPages Routerコードの移行もAIが一括で対応できます。

AIを知りたい

SSRとISRとSSGの使い分けもAIに相談できますか?ページごとにどれを選ぶべきか判断基準が欲しいです。

AIエンジニア

もちろんです。ページの特性(データの更新頻度、パーソナライゼーションの有無、SEO重要度)に応じて最適なレンダリング戦略をAIが提案してくれます。例えば動的なダッシュボードならSSR、ブログ記事ならISR(revalidate: 3600)、完全に静的なLPならSSGといった判断を自動化できます。

Next.js×AI開発ワークフローとは

Next.js×AI開発ワークフローとは、Claude CodeなどのAIツールを使ってNext.jsアプリケーションの設計・実装を効率化する手法です。App Routerのディレクトリ構造設計、Server/Client Componentsの使い分け、データフェッチングパターン(fetch / Server Actions)、ミドルウェア設定、ISR/SSR/SSGの選択まで、Next.js固有の複雑な判断をAIが支援します。

特にPages RouterからApp RouterへのマイグレーションでAIの支援が大きな効果を発揮します。getServerSidePropsからasync Server Componentsへの変換、_app.tsxからlayout.tsxへの移行、APIルートからRoute Handlersへの書き換えなど、大量の変換作業をAIが自動化してくれます。Next.js 15の新機能(Turbopack安定化、React 19対応等)にもAIは対応済みです。

Pages Router vs App Router比較

AIを知りたい

Pages RouterとApp Routerの違いを整理してもらえますか?移行の判断材料にしたいです。

AIエンジニア

主要な違いを一覧で比較しましょう。App Routerは機能面で大きく進化していますが、既存のPages Routerプロジェクトは段階的に移行できるので、AIに移行計画を立ててもらうのがおすすめです。

機能 Pages Router App Router
ルーティング pages/ディレクトリ app/ディレクトリ
デフォルトレンダリング クライアントコンポーネント Server Components(RSC)
データ取得 getServerSideProps / getStaticProps async Server Components + fetch
レイアウト _app.tsx(グローバルのみ) layout.tsx(ネスト可能)
ローディングUI 自前実装が必要 loading.tsx(自動Suspense対応)
エラー処理 _error.tsx(グローバル) error.tsx(ルートセグメント別)
データ変更(ミューテーション) APIルート + クライアントfetch Server Actions(直接DB操作可能)

AIによるApp Router実装パターン

AIを知りたい

App Routerでのフォルダ構成ってどうすればいいんですか?特殊なファイル名(layout.tsx、loading.tsx等)が多くて混乱します。

AIエンジニア

AIに「Next.js App Routerのディレクトリ構成を設計して。認証、ダッシュボード、ブログ機能を含めて」と依頼すると、Route Groups、Parallel Routes、Intercepting Routesも含めた最適な構成を提案してくれます。特殊ファイル(layout, loading, error, not-found等)の配置も自動的に行われます。

# AIが生成するApp Router構成例(実践的なプロジェクト)
app/
├── layout.tsx              # ルートレイアウト(html, body, フォント設定)
├── page.tsx                # トップページ(SSG)
├── loading.tsx             # グローバルローディングUI
├── error.tsx               # グローバルエラーUI
├── not-found.tsx           # 404ページ
├── globals.css
├── (marketing)/            # マーケティング用Route Group
│   ├── layout.tsx          # LP用レイアウト(ナビなし)
│   ├── page.tsx            # LP
│   └── pricing/page.tsx    # 料金ページ
├── (auth)/                 # 認証用Route Group
│   ├── layout.tsx          # 認証用シンプルレイアウト
│   ├── login/page.tsx
│   └── register/page.tsx
├── dashboard/
│   ├── layout.tsx          # サイドバー付きレイアウト
│   ├── page.tsx            # ダッシュボードトップ(SSR)
│   ├── loading.tsx
│   └── settings/
│       └── page.tsx
├── blog/
│   ├── page.tsx            # 記事一覧(ISR: revalidate=60)
│   └── [slug]/
│       ├── page.tsx        # 記事詳細(ISR: revalidate=3600)
│       └── opengraph-image.tsx  # OG画像の動的生成
└── api/
    └── webhook/route.ts    # Route Handler(Webhook受信)

Server ComponentsとClient Componentsの使い分け

AIを知りたい

どのコンポーネントをServerにして、どれをClientにすればいいんですか?「use client」をどこに書けばいいか分かりません。

AIエンジニア

基本原則は「デフォルトはServer Component、インタラクティブ機能が必要な箇所だけClient Component」です。useState、useEffect、onClick等のイベントハンドラを使うコンポーネントにだけ「use client」を付けます。AIはこの判断を自動的に行い、必要最小限のクライアント境界を設計してくれるので非常に頼りになります。

AIを知りたい

間違って「use client」を付けすぎるとどうなるんですか?パフォーマンスへの影響が気になります。

AIエンジニア

バンドルサイズが増大し、Server Componentsの恩恵(サーバーサイドでのDB直接アクセス、JSバンドル削減等)が失われます。AIは最小限のクライアント境界を設計するのが得意なので、「use client」の最適配置はAIに任せるのが効果的です。実際にNext.jsの公式ドキュメントでも「クライアント境界をできるだけ葉ノードに近づける」ことが推奨されています。

使う機能 Server Component Client Component
データベースアクセス ◎ Prisma等で直接可能 × 不可(API経由が必要)
useState / useEffect × 使用不可 ◎ 必須(状態管理)
onClick等のイベント × 使用不可 ◎ 必須(ユーザー操作)
環境変数(秘密鍵) ◎ サーバー側で安全にアクセス × ブラウザに露出するリスク
外部API呼び出し ◎ サーバーサイドで実行 ○ CORS設定に注意が必要
SEO(メタデータ) ◎ generateMetadata関数 △ 限定的(SSR時のみ)

Server Actionsによるデータ変更パターン

AIを知りたい

Server Actionsって何ですか?APIルートとは違うんですか?

AIエンジニア

Server Actionsは、フォーム送信やデータ変更をサーバーサイドで直接実行できる仕組みです。従来のようにAPIエンドポイントを別途用意する必要がなく、コンポーネント内にサーバーサイドロジックを「use server」ディレクティブで記述できます。AIにCRUD操作の実装を依頼すれば、Server Actionsを活用した効率的なパターンを生成してくれます。フォームバリデーション、楽観的更新(useOptimistic)、エラーハンドリングまで含めた本番レベルの実装が手に入ります。

// AIが生成するServer Actionsの例
// actions/user.ts
"use server";

import { revalidatePath } from "next/cache";
import { z } from "zod";

const UserSchema = z.object({
  name: z.string().min(1, "名前は必須です"),
  email: z.string().email("有効なメールアドレスを入力してください"),
});

export async function createUser(formData: FormData) {
  const parsed = UserSchema.safeParse({
    name: formData.get("name"),
    email: formData.get("email"),
  });

  if (!parsed.success) {
    return { error: parsed.error.flatten().fieldErrors };
  }

  await db.user.create({ data: parsed.data });
  revalidatePath("/dashboard/users");
  return { success: true };
}

まとめとして、Next.jsのApp Router移行と実装はAI支援で大幅に効率化できます。Server/Client Componentsの使い分け、レンダリング戦略の選択(SSR/ISR/SSG)、ディレクトリ構成の設計、Server Actionsによるデータ変更など、Next.js固有の複雑な判断をAIに任せることで、フレームワークの学習コストを抑えながら最新のアーキテクチャを活用できます。特にPages Routerからの移行作業は大量のパターン変換が必要ですが、AIならば一括で正確に変換してくれるため、移行コストを大幅に削減できます。

関連記事