フロントエンドのアーキテクチャに大きな変革をもたらしている「React Server Components (RSC)」。名前は聞くけれど、SSR（サーバーサイドレンダリング）と何が違うのか、裏側でどのような処理が動いているのかを正確に把握しているでしょうか。 本記事では、その技術的な仕組みを深掘りし、実務での活用事例を考察します。
SSRとの決定的な違い
従来のSSRは、初期ロード時にサーバー側でHTMLを生成し、ブラウザに返却する技術でした。しかしその後、ブラウザ側でJavaScriptを読み込み、コンポーネントを再実行（ハイドレーション）してインタラクティブな状態にする必要がありました。つまり、コンポーネントのコード自体は結局ブラウザにダウンロードされていたのです。
対してRSCは、**「サーバー上でだけ実行され、ブラウザには絶対に送信されないコンポーネント」**です。 RSCはサーバーで処理された後、HTMLではなく特殊なJSONに近いフォーマットにシリアライズされ、クライアントに送信されます。ブラウザ側はこのデータを受け取り、DOMに反映させるだけです。
バンドルサイズの劇的な削減
この仕組みがもたらす最大の恩恵が、クライアント側へ送るJavaScriptバンドルサイズの削減です。
例えば、マークダウンをHTMLに変換する重いライブラリ（markedなど）を使用する場合を考えます。これをRSCで実装すれば、パース処理はすべてサーバーで行われるため、重いライブラリのコードがユーザーのブラウザにダウンロードされることは一切ありません。これはモバイル環境のパフォーマンスにおいて革命的な改善をもたらします。
Client Boundary（境界線）の設計が肝
RSCを扱う上で最も頭を悩ませるのが、サーバーコンポーネントとクライアントコンポーネントの境界線の設計です。
RSCはサーバーで動くため、onClickなどのイベントハンドラや状態管理（useState）を持てません。それらが必要な末端のコンポーネント（ボタンや入力フォーム）だけをクライアントコンポーネントにする必要があります。
「データ取得や重い処理はツリーの上層（サーバー）で行い、ユーザー操作が必要な葉っぱの部分だけをクライアントにする」というツリー構造の設計思想が求められます。
実践的な活用事例
実務においてRSCが最も輝くのは、以下のようなユースケースです。
- ブログやメディアのアーティクル表示: 前述のマークダウン変換のように、静的なコンテンツの描画はRSCの独壇場です。
- データベースへの直接アクセス: RSCはサーバー環境であるため、セキュアに直接データベースへクエリを投げることができます。API層をひとつ省略できるため、開発の手間が省けます。
- SEO重視のランディングページ: 初期ロードが速く、余分なJSがないため、Core Web Vitalsのスコア改善に直結します。
RSCは決して既存のReactを置き換えるものではなく、クライアントとサーバーの「役割分担」を明確にするための新しい武器です。その仕組みを正しく理解し、適切に設計に組み込むことが、これからのフロントエンド開発の要となるでしょう。