React Server Components は結局どう使えばいい？（実戦サンプル付き）

2025-12-05

React Server Components（以下 RSC）。 2023〜2025 年のフロントエンド界隈で、最も議論を生んだ概念の一つです。しかし、“結局どう使うのが正解なのか？” を理解している人は意外と少ない。

本記事では、RSC が本当に役立つ場面・使うべきでない場面・実戦コード例を、現場目線でまとめます。

🎯 1. React Server Components とは何か？（要点だけ）

RSC は一言でまとめると 「サーバで実行される React コンポーネント」。

ポイントは次の 4 つだけ覚えれば十分。

サーバで実行 → クライアントへ HTML 断片をストリームで送る
データ取得をサーバ側で完結できる
Node.js や backend API へ直アクセスできる（セキュア）
クライアントバンドルを減らせる → 体感速度が上がる

つまり RSC は “データフェッチ＋表示” に最適化した超軽量なサーバ側 UI 描画エンジン。

🚀 2. Next.js 15 での基本スタイル（実戦コード）

最もシンプルな RSC の例はこれ。

// app/products/page.tsx （RSC）
import { getProducts } from "@/lib/db";

export default async function ProductsPage() {
  const products = await getProducts(); // サーバで直接DBアクセス可

  return (
    <div>
      <h1>商品一覧</h1>
      <ul>
        {products.map((p) => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </div>
  );
}

✔ クライアント側 JS が“ゼロ” • データ取得の JS が不要 • React の state/useEffect も不要 • bundle size が激減

ページの“骨格”を作るには RSC が最強。

🧩 3. じゃあ Client Component はどこで使う？

“インタラクションが必要なところだけ Client Component” にする。

例：いいねボタン / モーダル / 入力フォームなど。

"use client";

import { useState } from "react";

export function LikeButton() {
  const [liked, setLiked] = useState(false);
  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? "❤️ Liked" : "Like"}
    </button>
  );
}

そして RSC 側で読み込む。

import { LikeButton } from "./LikeButton";

export default async function Page() {
  const product = await fetchProduct();
  return (
    <div>
      <h1>{product.name}</h1>
      <LikeButton />
    </div>
  );
}

このように “静的な部分は RSC、動く部分だけ Client” が鉄則。

🔥 4. よくある誤解（現場で実際に見るやつ）

❌ 誤解 1：全部 RSC で書けばよい

→ インタラクションやブラウザ API が必要な部分は絶対に動かない。

❌ 誤解 2：CSR や useEffect は不要になる

→ 全部は置き換わらない。 RSC は UI の土台、Client は動的 UI。

❌ 誤解 3：SEO のために RSC を使う

→ そもそも RSC 以前に Next.js は SSR を持っている。SEO 目的なら RSC は必須ではない。

📦 5. RSC が“刺さる”ユースケース

✔ BFF（Backend for Frontend）パターンの置き換え

API routes を経由せず DB に直アクセスできる。

✔ 大量データのリスト表示

ストリーミングで先頭から描画 → 体感速度が上がる。

✔ 認証情報扱い（サーバ限定処理）

環境変数やアクセストークンをクライアントへ漏らさず処理できる。

✔ サードパーティ API に秘密鍵でアクセスするケース

安全に処理できる。

→ “ブラウザに出したくないものは全部 RSC で扱う” この思想がベスト。

⚙️ 6. RSC を導入するときの設計パターン（実務特化）

🏗 1. RSC = 「ページとデータフェッチ」担当

🧪 2. Client = UI インタラクション

🔄 3. actions（Server Actions）で双方向通信

→ Next.js 15 では Server Actions が非常に強力になっている。

例：

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

export async function addToCart(id: string) {
  await db.cart.add(id);
}

// Client component
("use client");

import { addToCart } from "@/app/actions";

export function CartButton({ id }: { id: string }) {
  return <button onClick={() => addToCart(id)}>カートに追加</button>;
}

RSC（表示） → Client（操作） → Server Actions（書き込み）というシンプル構造が完成する。

⚡ 7. RSC を使うと何が早くなるのか？（本質）

✔ クライアント側の JS が減る → 初期ロードが速くなる

✔ データ取得がサーバに集約 → API 往復が減る

✔ ストリーミング表示 → 体感速度が上がる

✔ セキュアな処理が書きやすい

つまり RSC は「速度」と「セキュリティ」と「設計の単純化」のために存在する。

🧭 まとめ：RSC の正しい使い方は“役割分離”

• 🧱 ページの骨格 → RSC • 🎛 インタラクション → Client components • 🔄 書き込み処理 → Server Actions • 🔐 秘密情報の扱い → RSC に寄せる

React 19 + Next.js 15 の世界では、 RSC を「なんとなく」使うのではなく、 “どこまでをサーバに寄せるか”の設計力が重要になります。

RSC を正しく使えば、フロントエンドは想像以上にシンプルになります。 2025 年以降の React 開発では、RSC の理解が確実に差を生むでしょう。