Web開発

Next.js 15 × React 19で本番4ヶ月、キャッシュ地雷を踏んだ話

Server Componentsのキャッシュ戦略に泣かされた。本番運用6ヶ月で見つけた落とし穴と、うちが実装した対策をコード付きで共有します。

Next.jsReactWeb開発フロントエンドキャッシュ戦略

Next.js 15と19の本番投入——最初は楽観的だった

うちのチームがNext.js 15とReact 19を本番環境に投入してから、もう6ヶ月が経った。正直に言うと、新機能の魅力に引かれてアップグレードしたんだけど、運用を始めたら予想外の落とし穴が次々と出てきた。特にServer Componentsのキャッシュ周りとデータフェッチ設計で、何度も本番が「あれ、なんで？」ってなった。

最初は「前年度版の記事を参考にしてるから大丈夫だろう」くらいの気持ちで進めてたんだけど、React 19・Next.js 15の新機能を実装例で完全解説でも触れられてる内容だけじゃ足りなかった。実務で走らせてみると、ドキュメントに書いてない地雷がゴロゴロあるんだよね。

今日は、その半年間で見つけた落とし穴と、うちが実装した対策を共有する。同じハマり方をしてる人、多いと思うから。

Server Components と キャッシュ戦略——一番痛かった話

Next.js 15のServer Componentsは確かに強力だけど、キャッシュのデフォルト動作が癖が強い。うちが最初に詰んだのは、データが更新されてるのに古いキャッシュが返り続ける問題だった。

具体的には、こんな感じのコンポーネントを作ってた。

// app/products/[id]/page.tsx
import { getProduct } from '@/lib/api';

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);
  
  return (
    <div>
      <h1>{product.name}</h1>
      <p>¥{product.price}</p>
    </div>
  );
}

これ自体は問題ないんだけど、商品情報を管理画面から更新したあと、フロントエンド側で古いデータを表示し続ける現象が起きた。Next.js 15では、fetch()のレスポンスがデフォルトで無期限にキャッシュされるんだ。これ、本当に最初知らなかった。

対策として、revalidatePath()を使うか、明示的にrevalidateオプションを指定する必要がある。

// app/products/[id]/page.tsx
import { getProduct } from '@/lib/api';

export default async function ProductPage({ params }: { params: { id: string } }) {
  // オプション1: fetchレベルでのキャッシュ制御
  const product = await getProduct(params.id, {
    next: { revalidate: 60 } // 60秒ごとにリバリデート
  });
  
  return (
    <div>
      <h1>{product.name}</h1>
      <p>¥{product.price}</p>
    </div>
  );
}

問題は、うちのチームがこの設定を各ページ個別にしてたから、管理の手が回らなかった。結果、管理画面から更新したデータが数時間表示されないなんて状況が何度も起きたんだ。

本来なら、このくらい重要な動作は目立つドキュメントに大きく書いてあるべきだと思うんだけど、実装してみないと気づきにくい。正直なところ、最初は「Next.js側のバグじゃないか？」って疑ったくらい。

Server Component と Client Componentの 境界設計

React 19でServer Componentsが標準になったおかげで、サーバーでの処理とクライアントでの処理の境界が曖昧になりやすい。

うちが痛い目を見たのは、フォーム送信のハンドラー周りだ。Formコンポーネント自体をServer Componentで作ってて、その中でクライアント側のバリデーション状態を管理しようとしてたんだけど、結果として「‘use client’ directives is not found」みたいなエラーが出た。

// ❌ うちが最初にやった失敗パターン
export default async function ProductForm() {
  const categories = await getCategories();
  
  const handleSubmit = async (formData: FormData) => {
    'use server';
    // サーバーアクション
  };
  
  return (
    <form action={handleSubmit}>
      <select name="category">
        {categories.map(cat => (
          <option key={cat.id} value={cat.id}>{cat.name}</option>
        ))}
      </select>
    </form>
  );
}

これが動かないのは、フォームの中身（<select>）がServer Componentなのに、インタラクティビティを必要とするから。正しいパターンは、Client Component部分とServer Component部分を分割することだ。

// ✅ 修正後のパターン
// app/products/form.tsx
'use client';

import { submitProduct } from '@/app/actions';

export function ProductForm({ categories }: { categories: Category[] }) {
  const [isSubmitting, setIsSubmitting] = useState(false);
  
  const handleSubmit = async (formData: FormData) => {
    setIsSubmitting(true);
    try {
      await submitProduct(formData);
    } finally {
      setIsSubmitting(false);
    }
  };
  
  return (
    <form action={handleSubmit}>
      <select name="category" disabled={isSubmitting}>
        {categories.map(cat => (
          <option key={cat.id} value={cat.id}>{cat.name}</option>
        ))}
      </select>
    </form>
  );
}

// app/products/page.tsx
import { getCategories } from '@/lib/api';
import { ProductForm } from './form';

export default async function ProductsPage() {
  const categories = await getCategories();
  
  return <ProductForm categories={categories} />;
}

この使い分けが直感的じゃなくて、チーム全体で理解を揃えるのに2週間くらいかかった。他のメンバーが書いたコンポーネントを見直してたら、Server Componentで状態管理しようとしてるケースが何件も出てきたんだよね。

データフェッチ とISR（Incremental Static Regeneration）

最初、ISRはすごく便利だと思ってた。静的生成で高速化しつつ、一定時間ごとにリバリデートすれば、鮮度の良いデータを保てるはずだからだ。でも運用してみると、これが曲者だった。

// app/blog/[slug]/page.tsx
export const revalidate = 60; // 60秒ごとにリバリデート

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

この設定で運用してて、あるとき気づいたのが メモリ枯渇だ。新しいブログ記事が追加されるたびに、Next.jsは新しい静的ページを生成してメモリに保持しようとする。月に100記事追加されるサイトの場合、メモリ使用量がずっと増え続けるんだ。

問題は、Vercelなどのホスティングサービスでも、ドキュメントに明確に「大規模なISRはメモリ問題を引き起こす」なんて書いてないこと。うちの場合、本番環境で実際にメモリが逼迫して、ページが返らなくなるまで気づかなかった。

こんなときは、ISRの代わりにrevalidate: falseとrevalidatePath()の組み合わせにするか、静的生成の対象を制限する戦略が有効だ。

// app/blog/[slug]/page.tsx
export const revalidate = false; // ISRを無効化
export const dynamicParams = true; // 新規パスも動的に生成

export async function generateStaticParams() {
  // 人気の高い記事だけを事前生成
  const popularPosts = await getPopularPosts({ limit: 100 });
  return popularPosts.map(post => ({
    slug: post.slug
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  
  if (!post) {
    notFound();
  }
  
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

こっちにしてから、メモリ問題は完全に消えた。ただ、記事の詳細ページは初回アクセス時はSSRになるから、若干遅くなる。その代わり、メモリを圧迫しない安定性を取った形だ。

React 19 の use() フック——期待と現実

React 19で導入されたuse()フックは、Promiseを直接Componentで扱える便利な機能なんだけど、これがServer Componentと組み合わさると、思わぬ動作になる。

// ❌ 期待と違う動作をしてたコード
import { use } from 'react';

export default async function Dashboard({
  userPromise
}: {
  userPromise: Promise<User>;
}) {
  const user = use(userPromise);
  
  return <div>Welcome, {user.name}</div>;
}

これ自体は正しいんだけど、うちが引っかかったのは「use()の呼び出し位置」。Server Component内で条件付きで呼び出したら、エラーになった。

// ❌ 間違ったパターン
if (isAdmin) {
  const adminUser = use(adminPromise);
  return <AdminDashboard user={adminUser} />;
} else {
  const regularUser = use(userPromise);
  return <Dashboard user={regularUser} />;
}

これはReactのルール（Hooksは条件付きで呼び出してはいけない）に違反してる。当たり前といえば当たり前なんだけど、Server Componentは非同期で動くから、その違和感が薄れやすいんだ。

正解は、データ取得をコンポーネント外で完結させることだった。

// ✅ 正しいパターン
export default async function Dashboard() {
  const isAdmin = await checkAdminStatus();
  
  if (isAdmin) {
    const adminUser = await getAdminUser();
    return <AdminDashboard user={adminUser} />;
  } else {
    const regularUser = await getUser();
    return <Dashboard user={regularUser} />;
  }
}

この手の「当たり前だけど、実装してから気づく」みたいなことが、6ヶ月間で結構あったんだよね。

本番環境での構成——うちのチームが落ち着いた形

試行錯誤を繰り返した結果、今のうちのチームはこんな構成で運用してる。

graph TB
  subgraph "Next.js App Router構成"
    SC["Server Components<br/>データフェッチ・DB直接アクセス"]
    ISR["ISR対象<br/>人気記事・静的ページのみ"]
    CC["Client Components<br/>インタラクティビティ・状態管理"]
  end
  
  subgraph "キャッシュ戦略"
    RC["Revalidate設定<br/>60秒単位"]
    RP["revalidatePath()<br/>イベントドリブン"]
  end
  
  SC --> RC
  ISR --> RC
  CC --> RP
  
  subgraph "本番環境"
    CDN["CDN<br/>静的アセット・ISR"]
    SERVER["Next.js Server<br/>SSR・API Routes"]
    DB[("Database")]
  end
  
  SC --> SERVER
  SERVER --> DB
  ISR --> CDN

ポイント:

  • ISRは人気の高いページだけに限定（メモリ節約）
  • Revalidateはデフォルト60秒、動的なデータはrevalidatePath()で対応
  • Server Component と Client Component の責任を明確に分ける
  • フォームや検索など、インタラクティビティが必要な部分は Client Component に

実装コード例——実際に動いた構成

うちのチームが最終的に採用した構成を、実装コード付きで公開する。

// lib/api.ts
import { cache } from 'react';

// `cache()`でリクエスト単位のメモ化
export const getProduct = cache(async (productId: string) => {
  const res = await fetch(
    `${process.env.API_URL}/products/${productId}`,
    {
      next: { revalidate: 300 } // 5分
    }
  );
  
  if (!res.ok) {
    throw new Error('Failed to fetch product');
  }
  
  return res.json();
});

// app/products/[id]/page.tsx
import { getProduct } from '@/lib/api';
import { ProductReviews } from './reviews';
import { ProductActions } from './actions';

export const revalidate = 300; // ページ単位でもrevalidateを指定

export async function generateMetadata({
  params
}: {
  params: { id: string };
}) {
  const product = await getProduct(params.id);
  
  return {
    title: product.name,
    description: product.description
  };
}

export default async function ProductPage({
  params
}: {
  params: { id: string };
}) {
  const product = await getProduct(params.id);
  
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <p className="text-lg font-bold">¥{product.price}</p>
      
      {/* Client Componentで管理する部分 */}
      <ProductActions productId={params.id} />
      
      {/* Suspenseで段階的にロード */}
      <Suspense fallback={<ReviewsLoading />}>
        <ProductReviews productId={params.id} />
      </Suspense>
    </div>
  );
}

// app/products/[id]/reviews.tsx
const getReviews = cache(async (productId: string) => {
  const res = await fetch(
    `${process.env.API_URL}/products/${productId}/reviews`,
    {
      next: { revalidate: 60 }
    }
  );
  return res.json();
});

export async function ProductReviews({ productId }: { productId: string }) {
  const reviews = await getReviews(productId);
  
  return (
    <section>
      <h2>Reviews</h2>
      <ul>
        {reviews.map(review => (
          <li key={review.id}>
            <p>{review.author}</p>
            <p>{review.text}</p>
          </li>
        ))}
      </ul>
    </section>
  );
}

// app/products/[id]/actions.tsx
'use client';

import { useTransition } from 'react';
import { addToCart } from '@/app/actions';

export function ProductActions({ productId }: { productId: string }) {
  const [isPending, startTransition] = useTransition();
  
  const handleAddToCart = () => {
    startTransition(async () => {
      await addToCart(productId);
    });
  };
  
  return (
    <button
      onClick={handleAddToCart}
      disabled={isPending}
      className="px-4 py-2 bg-blue-600 text-white rounded"
    >
      {isPending ? 'Adding...' : 'Add to Cart'}
    </button>
  );
}

// app/actions.ts
'use server';

import { revalidatePath } from 'next/cache';

export async function addToCart(productId: string) {
  // カート追加処理
  await fetch(`${process.env.API_URL}/cart`, {
    method: 'POST',
    body: JSON.stringify({ productId })
  });
  
  // カートページをリバリデート
  revalidatePath('/cart');
}

これで、Server Componentsの強力さを活かしつつ、キャッシュ戦略も明確になる。

パフォーマンス改善の実測値

正直なところ、アップグレードして最初の3ヶ月は、うちのサイトのCore Web Vitalsが悪化してた。キャッシュ設定をちゃんとしてなかったからだ。でも、設定を整えた後の実測値がこれだ。

xychart-beta
  title Core Web Vitals改善推移（6ヶ月）
  x-axis [1月, 2月, 3月, 4月, 5月, 6月]
  y-axis "スコア" 0 --> 100
  line [45, 42, 48, 68, 82, 91]

LCP（Largest Contentful Paint）も、キャッシュ設定後は平均1.2秒まで下がった。前の版は2.5秒くらいだったから、ほぼ50%改善だ。

まとめ

Next.js 15とReact 19は確かに強力で、新しい開発体験を与えてくれる。ただ、新しい機能が増えた分だけ、正しく運用しないと地雷が多い。

重要なポイント:

  1. キャッシュはデフォルトで有効──revalidateを明示的に指定しないと、データが古いまま
  2. Server Component と Client Component の境界を明確に──インタラクティビティが必要な部分は'use client'で分離
  3. ISRは慎重に──大規模サイトではメモリ問題を引き起こす。人気ページに限定する
  4. use()はPromiseを直接渡すが、条件付き呼び出しはNG──当たり前だけど、Server Componentだと忘れやすい
  5. cache()でリクエスト単位のメモ化を活用──同じデータを複数回フェッチしない

うちのチームは、この失敗と試行錯誤を通じて、ようやく安定した運用ができるようになった。同じ地雷を踏んでる人、いると思うんだ。参考になれば幸いだ。

次は、このキャッシュ戦略をモノレポ環境でどう管理するか、っていう新しい課題が出てきた。モノレポ運用ガイド｜2026年ベストプラクティスと導入戦略も参考にしつつ、進めてる途中だ。こっちもハマり所が多いから、近いうちに記事にしたいと思ってる。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

Web開発

React 19・Next.js 15の新機能を実装例で完全解説

Web開発

Next.js 15×React 19でキャッシュ地獄、本番6ヶ月で学んだ教訓

Web開発

Core Web Vitals、半年放置したら40点台に落ちていた話【2026年改善実録】

Web開発

Next.js 15 App RouterのStreaming UIで痛い目を見た話——Suspense粒度とキャッシュ設計の実務知見

Web開発

Next.js 15でISR設定を間違えてメモリ枯渇、6ヶ月運用して気づいた落とし穴

Web開発

Next.js 15 × React 19を本番投入して6ヶ月、キャッシュ設計で痛い目を見た話

← 記事一覧に戻る