React Server Components (RSC) の深淵へ —— 現場で使える「境界線」の引き方

やあ。最近、現場で「RSCって結局何が嬉しいの？ただのサーバーサイドレンダリング（SSR）と何が違うの？」という質問をよく受ける。

結論から言おう。RSCは単なる「サーバーで動くコンポーネント」ではない。「JSのバンドルサイズをゼロにし、ネットワークの往復を劇的に減らすための、Reactの設計思想そのものの転換」だ。

今日は、中級エンジニアの君たちが明日から現場で胸を張って設計できるように、RSCの本質と、その泥臭い実務的な境界線の引き方を解説する。

—

1. RSCは何を変えたのか？（ブラウザの裏側で起きていること）

これまでのReactは、基本的に「クライアント側でJSをパースし、実行し、DOMを生成する」という重たいプロセスをブラウザに強いてきた。

RSCが登場して何が変わったか。それは「コンポーネントの実行結果が、HTMLではなく『React独自のデータフォーマット（RSC Payload）』としてサーバーから送られてくる」ようになったことだ。

SSRとの決定的違い: SSRは「HTML文字列」を送り、ハイドレーション（イベントの付与）を待つ。一方、RSCはサーバーで処理が完結し、クライアントには「最小限のデータ」だけがシリアライズされて届く。つまり、RSCそのものはブラウザで一切実行されない。

2. 境界線：`”use client”` の正しい作法

現場で最も混乱するのが「どこで `”use client”` を書くか」だ。
ここで一つ、鉄則を教えておく。

> “use client” はコンポーネントの「機能」を定義するものではなく、サーバーからクライアントへ「橋渡しをする地点」を定義するものだ。

RSCからクライアントコンポーネントを呼び出す際、その境界線でデータは「シリアライズ可能（JSON化できるもの）」である必要がある。関数やクラスインスタンスをPropsとして渡そうとしてエラーが出た経験はないか？それがRSCの現実だ。

実践的なサンプルコード

まずは、データ取得（RSC）とインタラクション（Client）を分離した構成例を見てほしい。

// 1. Server Component: サーバーでDBからデータを取得する (async可能)
// ここではブラウザにJSは送られない
export default async function UserProfile({ userId }) {
const user = await db.user.findUnique({ where: { id: userId } });

return (

{user.name}

{/ 2. Client Componentを呼び出す境界線 /}

);
}

// 3. Client Component: インタラクションを担当
‘use client’; // これを忘れずに

import { useState } from ‘react’;

export function LikeButton({ initialLikes }) {
const [likes, setLikes] = useState(initialLikes);

return (

);
}

3. 現場で意識すべき「データ取得の最適化」

RSCの最大の武器は、「ネットワークのウォーターフォール（直列処理）を解消できる」ことにある。

昔のやり方では、`useEffect`でデータ取得を始めていたため、「コンポーネントがマウントされる→JSが動く→APIを叩く」という遅延が発生していた。RSCなら、コンポーネントのレンダリングと同時にサーバー内部でDBクエリが走る。

チップス：並列化による高速化

`Promise.all` を活用すれば、複数のデータを待機時間なしで取得できる。

async function Dashboard() {
// 並列でリクエストを投げる
const userPromise = fetchUser();
const postsPromise = fetchPosts();

// どちらか早い方を待つのではなく、両方揃うまで待機（並列実行）
const [user, posts] = await Promise.all([userPromise, postsPromise]);

return (

);
}

4. 最後のアドバイス：泥臭い現実

RSCを導入する際、君たちが直面する最大の敵は「ライブラリの互換性」だ。
まだ多くのライブラリが `”use client”` を明示していない場合、自分のコンポーネントでラップしてあげる必要がある。

1. コンポーネントを小さく保て: インタラクションがない部分は極力RSCとして維持する。それが最強のパフォーマンス最適化だ。
2. 無理にRSC化しない: データ取得が不要な静的コンポーネントを無理にRSCにしても恩恵は少ない。まずは「APIを叩く場所」をRSCに移行することから始めよう。

RSCは魔法の杖じゃない。しかし、正しく理解すれば、君たちのアプリケーションをよりシンプルで、驚くほど高速なものに変えてくれるはずだ。

明日からの開発で、一度 `console.log` をサーバー側で叩いてみてくれ。ブラウザのコンソールに何も出ないとき、君は本当の意味で「サーバーサイドのReact」と対話できていることになる。

健闘を祈る。また現場で会おう。

【実務・中級編】 React Server Components (RSC) の基本概念 – React実践ガイド