React Server Components(RSC)とは何か？仕組み・Client Components との違い・Next.js App Router での使い方

Next.js の App Router に切り替えたら 「use client」 って書かないとエラーが出るようになった」 RSC ってよく聞くけど Server Side Rendering とどう違うの？ データ取得は 「useEffect + fetch」 でいいのか、それとも 「async コンポーネント」 で書くのか分からない」 ── React と Next.js が一気に進化したことで、「書き方の前提」 が大きく変わったのが2024年以降の状況です。

ざっくり言うと、Server Components は サーバで動かす React コンポーネント で、「これまでの React コンポーネント」 とは 動く場所と使える機能 が違います。 「サーバで動くから速い」 という単純な話ではなく、「 クライアントに JS を送らない」 という選択肢を React 自身に持たせた、というのが本質的な変化 です。

この記事では、2026年5月時点の React 19 / Next.js 15 系をベースに、RSC の仕組み・Client Components との境界・データ取得のコード・落とし穴・採用判断 を、「なんとなく書いていたが理屈が掴めていない」 レベルから一段上に行けるよう整理します。

まず2行で言うと

長文を読む前に、結論だけ先に固定しておきます。

「RSC = SSR の新版」 ではなく、`SSR の世界に 「クライアント JS を載せないコンポーネント」 という新しいピースを追加したもの」 と捉えるのが正確です。

なぜ RSC が必要になったか

「React と Next.js は何が足りなくて RSC を導入したのか」 を見ると、設計意図が分かります。

つまり 「 クライアントに送らないでいい部分はサーバに留めたい」 という最適化を、コンポーネントモデルそのものに組み込んだ のが RSC です。

サーバとクライアント、それぞれで何ができて何ができないか

具体的な利用可否を表で押さえます。

「どの機能はどっち側か」 を意識しないと、「useState が使えない」 「event handler は使えない」 系のエラーで詰まります。 RSC 時代の React は、「 この境界を意識すること」 が新しい必須スキル です。

「use client」 ディレクティブとは

Next.js / React は、ファイルの先頭に 「'use client';」 と書くことで、「このファイル(とその関数 / コンポーネント)はクライアント側」 と明示します。

'use client';

import { useState } from 'react';

export function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

このファイルからエクスポートされるものは、それを使う側に Client 境界を引きます。 RSC からは普通に 「import」 して埋め込めますが、「 use client」 を書いたファイルとその先」 はバンドルに乗る、と理解するのがコツです。

「use client」 は 「 ここから先はクライアントですよ」 の境界線 であって、「このファイルをクライアントに送る」 だけのスイッチではない、というのが正確な理解です。

Next.js App Router での書き方

実際の Next.js App Router で 「データを取って表示する RSC」 はどう書くのか、コード例で確認します。

// app/users/[id]/page.tsx
import { db } from '@/lib/db';
import { LikeButton } from './LikeButton';

export default async function UserPage({ params }: { params: { id: string } }) {
  const user = await db.user.findUnique({ where: { id: params.id } });

  if (!user) return <div>Not found</div>;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
      <LikeButton userId={user.id} initialLikes={user.likes} />
    </div>
  );
}

// app/users/[id]/LikeButton.tsx
'use client';

import { useState } from 'react';

export function LikeButton({ userId, initialLikes }: { userId: string; initialLikes: number }) {
  const [likes, setLikes] = useState(initialLikes);
  return (
    <button onClick={() => setLikes(l => l + 1)}>♥ {likes}</button>
  );
}

「データ取得用のhooks がいらなくなった」 のが、App Router の体験を大きく変えた点です。 tRPC と組み合わせる場合も、「procedure をサーバコンポーネントから直接呼ぶ」 のような構成が普通に書けます。

データ取得とキャッシュ

App Router の RSC は、「fetch を直接書く」 だけで Next.js が裏でキャッシュを管理してくれます。

const res = await fetch('https://api.example.com/posts', {
  next: { revalidate: 60 }, // 60秒キャッシュ
});

このキャッシュ設計と Vercel の請求が高くなる原因 は密接に関係します。 「revalidate を小さくしすぎる」 と関数実行や帯域がそのまま課金に響くので、「本当に短くする必要があるか」 を毎回考えるのが大事です。

RSC のよくある詰まりどころ

実際に開発していてよく出会う罠を整理しておきます。

「境界をどこに引くか」 を意識するだけで、ほとんどの問題は解決します。 慣れるまではエラーが多めですが、慣れてくると 「 自然と Client は葉先だけ」 という配置に向かう ようになります。

採用判断の軸

「RSC を採用すべきか」 の判断材料を整理しておきます。

`新規プロジェクトで Next.js なら、まず App Router + RSC で始めて、必要に応じて 「use client」 を貼る」 が、2026年現在の現実的な標準です。 v0 で UI を作る ような AI 連携の文脈でも、「生成された UI は Client、データ取得は Server」 という配置が自然に決まりやすくなります。

AI 時代の RSC

AI を組み込んだアプリで RSC が嬉しい場面はいくつかあります。

「AI が出力 → サーバが整形 → 必要な部分だけ Client で動かす」 という現代的な構造が、RSC によって自然に書けるようになったのが大きな変化です。

React Server Components に関するよくある質問

Q. RSC は SSR とどう違うのですか？

A. SSR は 「初回 HTML をサーバで作る + クライアント側 JS も送る」、RSC は 「クライアントに JS を送らない種類のコンポーネント」 です。並べて使うもので、「SSR + RSC」 が App Router の標準的な構成になっています。

Q. すべてを RSC にすべきですか？

A. いいえ。「動かす部分(ボタン、フォーム、ドラッグ操作など)」 はどうしても Client Components が必要です。葉の部分だけ Client にして、構造は RSC という設計が一番素直に書けます。

Q. RSC からクライアントに 「props」 で何でも渡せますか？

A. シリアライズ可能なものに限定されます。関数 / クラスインスタンス / DOM ノード / Promise(条件付き) は基本的には渡せません。「値や JSX」 は渡せます。

Q. ローカルストレージや Cookie は RSC で扱えますか？

A. localStorage はクライアント専用 なので RSC では触れません。Cookie はサーバで 「cookies()」 API を使えば読めます。これにより 「ログイン中ユーザーで分岐」 のような処理を RSC で完結できます。

Q. RSC でエラーをハンドリングするには？

A. 「error.tsx」 を App Router のルートセグメントに置くと、その配下でエラーが起きたときに表示される Client Component が動きます。「try / catch + JSX」 を直接書くことも可能です。

Q. RSC の本番運用は安全ですか？

A. 2024年〜2025年で大幅に成熟しました。Next.js を本番採用している企業の多くが App Router に移行済みで、本番運用上の問題は概ね小さい 状態です。とはいえ、「古いライブラリの非互換」 等は残るので、移行時には依存の点検が必要です。

Q. RSC は将来的に標準になりますか？

A. React の中核機能としてすでに 「標準」 です。React 19 でリリースされ、Remix(React Router) / Waku など Next.js 以外のフレームワークでも採用が進んでいます。「一過性のトレンド」 ではなく 「React の進化方向そのもの」 と捉えるのが現実的です。

参考リンク

• React 公式: Server Components
• Next.js: App Router 公式
• Next.js: Server and Client Components
• React 公式: 「use client」
• Vercel Blog: Understanding React Server Components
• Remix(React Router): 公式