Next.js 16 アプリルーター: 制作パターンと落とし穴

Next.js App Router は React アプリケーションの構築方法を根本的に変え、Next.js 16 までにそのパターンは真に本番環境に対応したものに成熟しました。しかし、Pages Router からの概念的な変化は急激です。サーバー コンポーネント、部分的なプリレンダリング、ネストされたレイアウト、完全に再設計されたデータ取得モデルはすべて、ドキュメントだけでは完全に伝えることができないメンタル モデルの再配線を必要とします。

このガイドでは、本番環境で実際に重要なパターン、つまり、キャッシュ ポイズニングを防ぎ、不要なクライアント バンドルを排除し、大規模な Core Web Vitals をグリーンに保つパターンについて説明します。 11 ロケール i18n、動的 OG イメージ、および 5,577 個の MDX コンテンツ ファイルのサーバー側レンダリングを備えた 249 ページの Next.js 16 アプリケーションを構築した経験を活用します。

重要なポイント

• ロケールを意識した SEO が必要なページでは export const metadata を決して使用しないでください。常に generateMetadata() を使用してください。
• サーバー コンポーネントがデフォルトです。実際に対話性が必要な場合にのみ 'use client' を追加してください
• loading.tsx と error.tsx はルートではなく、ルート セグメントと同じ場所に配置されます
• proxy.ts ファイルは Next.js 16 のミドルウェアです - middleware.ts と proxy.ts の両方を作成しないでください
• サーバー コンポーネントの fetch() は、同じレンダリング内の同一リクエストを自動的に重複排除します。
• unstable_cache タグを使用すると、すべてを再検証せずに外科用キャッシュの無効化が可能になります
• generateStaticParams() は、ビルド時に静的に生成する動的ルートに必要です
• JSON-LD 構造化データは、Unicode エンコーディングを使用してスクリプト ブレークアウトをサニタイズする必要があります

---

サーバーコンポーネントのメンタルモデル

App Router に関して開発者が犯す最大の間違いは、'use client' に到達するのが早すぎることです。 Next.js 16 では、app/ ディレクトリ内のすべてのコンポーネントがデフォルトでサーバー コンポーネントになります。これは正しいデフォルトです。サーバー コンポーネントはサーバー上でレンダリングされ、JavaScript バンドルへの影響はなく、データベースと API に直接アクセスできます。

ルール: 'use client' をコンポーネント ツリーのリーフにプッシュします。ページは、データをフェッチし、対話を処理するシン クライアント コンポーネント シェルに渡すサーバー コンポーネントにすることができます。

// app/[locale]/blog/[slug]/page.tsx — Server Component (no directive needed)
import { getBlogPost } from '@/lib/blog';
import { BlogContent } from '@/components/blog/blog-content'; // Client Component

export default async function BlogPostPage({
  params,
}: {
  params: Promise<{ slug: string; locale: string }>;
}) {
  const { slug, locale } = await params;
  const post = await getBlogPost(slug, locale);

  if (!post) notFound();

  return (
    <article>
      <h1>{post.title}</h1>
      {/* Server Component — no JS sent to browser */}
      <PostMeta author={post.author} date={post.date} />
      {/* Client Component — only this file sent as JS */}
      <BlogContent content={post.content} />
    </article>
  );
}

// components/blog/blog-content.tsx — Client Component
'use client';

import { useState } from 'react';

export function BlogContent({ content }: { content: string }) {
  const [expanded, setExpanded] = useState(false);

  return (
    <div>
      <div>{content}</div>
      {/* Client-side interactivity lives here */}
    </div>
  );
}

重要な洞察: BlogContent は JavaScript をブラウザーに送信します。 PostMeta はそうではありません。不要な 'use client' ディレクティブはすべてバンドルを膨張させます。

---

静的メタデータを介してメタデータを生成する

静的 export const metadata はそのシンプルさで魅力的ですが、ロケールを認識できず、ルート パラメーターにアクセスできず、データをフェッチできません。実際のアプリケーションでは、generateMetadata() が唯一の正しい選択肢です。

// app/[locale]/blog/[slug]/page.tsx
import type { Metadata } from 'next';
import { getTranslations } from 'next-intl/server';

export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string; locale: string }>;
}): Promise<Metadata> {
  const { slug, locale } = await params;
  const post = await getBlogPost(slug, locale);

  if (!post) return {};

  const locales = ['en', 'zh', 'es', 'ar', 'pt', 'fr', 'de', 'ja', 'tr', 'hi', 'ur'];

  return {
    title: post.title,
    description: post.description,
    alternates: {
      canonical: `https://ecosire.com/${locale === 'en' ? '' : locale + '/'}blog/${slug}`,
      languages: Object.fromEntries(
        locales.map((loc) => [
          loc,
          `https://ecosire.com/${loc === 'en' ? '' : loc + '/'}blog/${slug}`,
        ])
      ),
    },
    openGraph: {
      title: post.title,
      description: post.description,
      images: [`/api/og/blog/${slug}?locale=${locale}`],
      type: 'article',
      publishedTime: post.date,
    },
  };
}

alternates.languages フィールドは、多言語 SEO に不可欠な、あらゆるロケールの hreflang タグを生成します。検索エンジンはこれらを使用して、各ユーザーに正しい言語バージョンを提供します。

---

ネストされたレイアウトと共有状態

App Router のネストされたレイアウト システムは強力ですが、明らかではない制約があります。レイアウトは prop を介して子にデータを渡すことができません。回避策は、React Context (クライアント コンポーネントのみ) または各レベルで個別にデータをフェッチすることです。

app/
  [locale]/
    layout.tsx          <- Locale layout: fonts, i18n provider, theme
    page.tsx            <- Homepage
    blog/
      layout.tsx        <- Blog layout: sidebar, breadcrumbs
      page.tsx          <- Blog list
      [slug]/
        layout.tsx      <- Post layout: reading progress, TOC
        page.tsx        <- Post content
        loading.tsx     <- Skeleton while post loads
        error.tsx       <- Error boundary for this segment

各 layout.tsx はその子を独立してラップします。親レイアウトでフェッチされたデータは、子に自動的に利用可能ではありません。データを必要とする各コンポーネントは、データを個別にフェッチします。 Next.js 16 は、レンダリング サイクル内で同一の fetch() 呼び出しを重複排除するため、これは思ったほど高価ではありません。

// app/[locale]/layout.tsx
import { NextIntlClientProvider } from 'next-intl';
import { getMessages } from 'next-intl/server';

export default async function LocaleLayout({
  children,
  params,
}: {
  children: React.ReactNode;
  params: Promise<{ locale: string }>;
}) {
  const { locale } = await params;
  const messages = await getMessages();

  return (
    <html lang={locale} dir={['ar', 'ur'].includes(locale) ? 'rtl' : 'ltr'}>
      <body>
        <NextIntlClientProvider messages={messages}>
          {children}
        </NextIntlClientProvider>
      </body>
    </html>
  );
}

---

キャッシュ戦略: 4 つの層

Next.js 16 には 4 つの異なるキャッシュ レイヤーがあります。ページが更新される理由、または更新されない理由を推論するには、次の 4 つをすべて理解する必要があります。

1.リクエストのメモ化 — 1 つのレンダリング サイクル内の同じ fetch() URL が 1 回呼び出されます。自動、設定なし。

2.データ キャッシュ — リクエスト間で永続的です。 fetch() 応答は、デフォルトでは無期限にキャッシュされます。

// Force revalidation every hour
const data = await fetch('/api/posts', { next: { revalidate: 3600 } });

// Never cache (equivalent to SSR)
const data = await fetch('/api/posts', { cache: 'no-store' });

3.フル ルート キャッシュ — 静的ルートの構築時に静的 HTML および RSC ペイロードがキャッシュされます。

4.ルーター キャッシュ — 訪問ルートのクライアント側キャッシュ。ブラウザセッションの間持続します。

データベース クエリ (非フェッチ) の場合は、unstable_cache を使用します。

import { unstable_cache } from 'next/cache';

const getCachedBlogPosts = unstable_cache(
  async (locale: string) => {
    return db.select().from(posts).where(eq(posts.locale, locale));
  },
  ['blog-posts'], // Cache key
  {
    revalidate: 3600, // Revalidate hourly
    tags: ['blog'], // Tag for manual invalidation
  }
);

// Invalidate from a Server Action or Route Handler:
import { revalidateTag } from 'next/cache';
revalidateTag('blog'); // All blog-tagged caches cleared

---

エラー境界: 2 つのレベルが必要

運用アプリケーションには 2 つのエラー境界が必要です。1 つはロケール対応ページ用で、もう 1 つはルートレベルのエラー用のグローバル フォールバックです。

// app/[locale]/error.tsx — Locale-level error boundary
'use client';

import { useTranslations } from 'next-intl';
import { useEffect } from 'react';

export default function LocaleError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  const t = useTranslations('errors');

  useEffect(() => {
    // Log to error tracking service
    console.error(error);
  }, [error]);

  return (
    <div className="flex flex-col items-center justify-center min-h-screen">
      <h2>{t('title')}</h2>
      <p>{t('description')}</p>
      <button onClick={reset}>{t('retry')}</button>
    </div>
  );
}

// app/global-error.tsx — Root fallback (no i18n available here)
'use client';

export default function GlobalError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  // Cannot use useTranslations here — no NextIntlClientProvider above
  // Use inline styles — no Tailwind in root error boundaries
  return (
    <html>
      <body>
        <div style={{ display: 'flex', flexDirection: 'column', alignItems: 'center', padding: '2rem' }}>
          <h2 style={{ fontSize: '1.5rem', fontWeight: 'bold' }}>Something went wrong</h2>
          <button
            onClick={reset}
            style={{ marginTop: '1rem', padding: '0.5rem 1rem', cursor: 'pointer' }}
          >
            Try again
          </button>
        </div>
      </body>
    </html>
  );
}

global-error.tsx は起動時にルート layout.tsx を置き換えるため、<html> タグと <body> タグを含める必要があります。レイアウト内に存在するコンテキスト プロバイダーにはアクセスできません。i18n、テーマ、認証コンテキストはありません。

---

ミドルウェア: proxy.ts と middleware.ts

Next.js はエッジミドルウェアに middleware.ts (または middleware.js) を使用します。 next-intl v4 を使用するプロジェクトでは、ミドルウェア セットアップの名前が proxy.ts に変更されて再エクスポートされることが多く、middleware.ts と proxy.ts__ の両方を作成しないでくださいという重大な落とし穴が生じます。両方があるとビルド エラーが発生します。

i18n と認証保護を組み合わせる正しいパターン:

// src/proxy.ts — This IS the Next.js middleware
import createMiddleware from 'next-intl/middleware';
import { NextRequest, NextResponse } from 'next/server';
import { routing } from './i18n/routing';

const intlMiddleware = createMiddleware(routing);

const protectedPaths = ['/dashboard', '/portal'];

export default function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Check auth for protected paths
  const isProtected = protectedPaths.some((path) =>
    pathname.includes(path)
  );

  if (isProtected) {
    const token = request.cookies.get('ecosire_auth');
    if (!token) {
      const url = request.nextUrl.clone();
      url.pathname = '/auth/login';
      // Prevent open redirect — never allow // prefix
      const redirect = pathname.startsWith('//') ? '/' : pathname;
      url.searchParams.set('redirect', redirect);
      return NextResponse.redirect(url);
    }
  }

  return intlMiddleware(request);
}

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|favicon.ico|.*\\..*).*)'],
};

この 1 つのファイルは、i18n ロケール検出と認証保護の両方を処理します。 config.matcher には、静的ファイル、API ルート、Next.js の内部要素は含まれません。

---

JSON-LD 構造化データのセキュリティ

JSON-LD スクリプトは一般的な XSS ベクトルです。データに終了スクリプト タグが含まれている場合、スクリプト ブロックから抜け出す可能性があります。修正は必須です。小なり文字をエンコードします。

// components/seo/JsonLd.tsx
interface JsonLdProps {
  data: Record<string, unknown>;
}

export function JsonLd({ data }: JsonLdProps) {
  // Sanitize script tag breakout attempts by encoding '<' as unicode
  const json = JSON.stringify(data).replace(/</g, '\\u003c');

  return (
    <script
      type="application/ld+json"
      // Safe: content is JSON-serialized and sanitized above
      suppressHydrationWarning
      ref={(el) => { if (el) el.textContent = json; }}
    />
  );
}

ページ内での使用法:

<JsonLd
  data={{
    '@context': 'https://schema.org',
    '@type': 'BlogPosting',
    headline: post.title,
    description: post.description,
    inLanguage: locale,
    author: {
      '@type': 'Organization',
      name: 'ECOSIRE',
    },
  }}
/>

inLanguage フィールドは多言語 SEO に不可欠です。AI クローラーと検索エンジンにコンテンツの言語を伝え、英語以外のクエリに対するランキングの精度を向上させます。

---

ダイナミック OG 画像

Next.js 16 の ImageResponse API は、エッジでページごとの OG イメージを生成します。ブログ投稿の設定:

// app/api/og/blog/[slug]/route.tsx
import { ImageResponse } from 'next/og';

export const runtime = 'edge';

export async function GET(
  request: Request,
  { params }: { params: Promise<{ slug: string }> }
) {
  const { slug } = await params;
  const post = await getPostMeta(slug);

  return new ImageResponse(
    (
      <div
        style={{
          display: 'flex',
          flexDirection: 'column',
          justifyContent: 'flex-end',
          width: '100%',
          height: '100%',
          background: 'linear-gradient(135deg, #0a0a0a 0%, #1a1a2e 100%)',
          padding: '60px',
        }}
      >
        <div style={{ fontSize: 48, fontWeight: 700, color: 'white', lineHeight: 1.2 }}>
          {post.title}
        </div>
        <div style={{ fontSize: 24, color: '#94a3b8', marginTop: 20 }}>
          {post.description}
        </div>
      </div>
    ),
    { width: 1200, height: 630 }
  );
}

---

よくある落とし穴と解決策

落とし穴 1: サーバー コンポーネントが動作しているときにクライアント コンポーネントでデータを取得する

コンポーネントがデータを表示するだけで、React 状態やブラウザー API を必要としない場合は、サーバー コンポーネントにする必要があります。 'use client' を追加すると、インポートされるすべてのものが強制的にクライアント バンドルに追加されます。

落とし穴 2: 非同期サーバー コンポーネントの周囲にサスペンス境界が存在しない

// Without Suspense — entire page blocks until data loads
export default async function Page() {
  const data = await slowFetch(); // 2 seconds
  return <div>{data}</div>;
}

// With Suspense — page streams, slow part shows skeleton
export default function Page() {
  return (
    <Suspense fallback={<DataSkeleton />}>
      <SlowDataComponent />
    </Suspense>
  );
}

落とし穴 3: キャッシュされた関数での cookies() または headers() の使用

cookies() と headers() は、動的レンダリングへのルートを選択する動的 API です。 unstable_cache コールバック内でこれらを使用すると、キャッシュが静かに破壊されます。

落とし穴 4: Next.js 16 での await params の忘れ

Next.js 16 では、params が Promise になりました。 await を忘れると、実行時エラーが発生します。

// Next.js 15 — params was synchronous
export default function Page({ params }: { params: { slug: string } }) {
  const { slug } = params;
}

// Next.js 16 — params is async
export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params; // Required
}

---

よくある質問

動的レンダリングではなく、generateStaticParams() をいつ使用する必要がありますか?

頻繁に変更されないコンテンツ (ブログ投稿、製品ページ、ドキュメント) には generateStaticParams() を使用します。これにより、実行時のコストがゼロで、ビルド時に静的 HTML が生成されます。パーソナライズされたコンテンツ、リアルタイム データ、またはビルド時間が法外にかかる数千のバリアントを含むページには、動的レンダリングを使用します。時々変更されるコンテンツの場合は、両方を ISR (revalidate) と組み合わせます。

App Router で認証を処理するにはどうすればよいですか?

認証トークンは HttpOnly Cookie に保存します。localStorage や sessionStorage には保存しないでください。ミドルウェア (proxy.ts) を使用して、保護されたルートの Cookie の存在を確認します。サーバーコンポーネントで、next/headers から cookies() を使用して Cookie を読み取ります。クライアント コンポーネントの Cookie を再読み取りすることなく、props または React Context を介してサーバーからクライアントにユーザー データを渡します。

loading.tsx と Suspense の違いは何ですか?

loading.tsx は、Next.js がルート セグメント全体のサスペンス境界に自動的にラップする特別なファイルです。セグメントの非同期コンテンツが読み込まれるとすぐに表示されます。手動の Suspense 境界を使用すると、より細かく制御できます。ページの異なる部分に異なるスケルトンを表示できます。どちらも、同じ基礎となる React Suspense メカニズムを使用します。

サーバー コンポーネントとクライアント コンポーネント間で状態を共有するにはどうすればよいですか?

サーバー コンポーネントは 1 回レンダリングすると実行時状態がありません。小道具を介してサーバーからクライアントにデータを渡します。ナビゲーション間で保持する必要があるクライアント側の状態の場合は、URL 検索パラメータ (共有可能な状態の場合)、Zustand または Redux (一時的な状態の場合)、または Cookie (ユーザー設定の場合) を使用します。クライアント コンポーネントの状態をサーバー コンポーネントにインポートしようとしないでください。

開発用に Turbopack をセットアップするにはどうすればよいですか?

--turbo を開発スクリプト "dev": "next dev --turbo" に追加します。 Turbopack は、コールド スタートと HMR が大幅に高速化された Next.js 16 の Rust ベースのバンドラーです。ほとんどのプロジェクトで本番環境に対応していますが、Webpack プラグインとの非互換性がいくつかあります。切り替える前に、Turbopack 互換性リストと照らし合わせて特定の依存関係を確認してください。

---

次のステップ

11 のロケール、数千のページ、エンタープライズ グレードのパフォーマンス要件を処理する実稼働 Next.js 16 アプリケーションを構築することは、重要なエンジニアリング作業です。 ECOSIRE のフロントエンド チームは、まさにこれを出荷しました。多言語 SEO、動的な OG イメージ、および 1 秒未満の応答時間を備えた 249 ページの Next.js 16 プラットフォームです。

Next.js アプリケーションをスケーリングしている場合、またはエンタープライズ フロントエンド エンジニアリング サポートが必要な場合は、開発サービスを探索 して、当社がどのようにサポートできるかを確認してください。