React Server Components (RSC) で変わるReact開発を徹底解説

React開発は、その誕生以来、主にクライアントサイドでのUI構築に焦点を当ててきました。しかし、ウェブアプリケーションの複雑化とパフォーマンス要求の高まりに伴い、レンダリングやデータ取得をサーバー側で行うことの重要性が増しています。このような背景から生まれたのが、React Server Components（RSC）です。

RSCは、従来のクライアントサイドレンダリング（CSR）やサーバーサイドレンダリング（SSR）といった既存の概念とは一線を画す、Reactの新しいレンダリングモデルです。これにより、パフォーマンス、バンドルサイズ、開発体験など、Reactアプリケーション開発の様々な側面が劇的に変化します。

本記事では、RSCがなぜ誕生したのか、どのような仕組みで動作するのか、そしてそれがReact開発にどのような変化をもたらすのかを、詳細かつ徹底的に解説します。

1. ウェブ開発の進化とReactの役割

Reactが登場する前、ウェブ開発の主流はマルチページアプリケーション（MPA）でした。サーバーがリクエストごとに新しいHTMLページを生成し、ブラウザはそのHTMLを表示していました。ページ遷移はフルリロードを伴い、インタラクティブ性は限定的でした。

その後、Ajax技術の普及により、ページ全体をリロードすることなくコンテンツを動的に更新する手法が広まります。そして、Reactのようなライブラリが登場し、クライアントサイドでJavaScriptを使ってリッチなユーザーインターフェースを構築するシングルページアプリケーション（SPA）の時代が到来しました。

1.1. クライアントサイドレンダリング（CSR）の台頭

Reactの初期の成功は、そのコンポーネントベースのアーキテクチャと、宣言的なUI構築手法にあります。多くのReactアプリケーションは、クライアントサイドレンダリング（CSR）を採用しています。

CSRの典型的な流れは以下の通りです。

1. ユーザーがURLにアクセス。
2. サーバーは最小限のHTMLファイル（通常は空のdiv要素とスクリプトタグのみ）を返す。
3. ブラウザがHTMLをパースし、JavaScriptファイルをダウンロード・実行する。
4. Reactがブラウザ上で実行され、APIからデータを取得したり、コンポーネントをレンダリングしたりする。
5. UIがブラウザに表示され、インタラクティブになる。

このモデルは、ページ遷移が高速で、複雑なUIを効率的に構築できるという利点があります。しかし、以下のような課題も抱えています。

CSRの課題

• 初期表示速度（First Contentful Paint / Largest Contentful Paint）： サーバーから返されるHTMLが最小限であるため、JavaScriptのダウンロード、パース、実行、データ取得、そしてレンダリングが全て完了するまで、ユーザーは何も表示されない白い画面を見ることになります。これは特にネットワーク環境が悪い場合や、アプリケーションの規模が大きい場合に顕著になります。
• インタラクティブになるまでの時間（Time to Interactive – TTI）： UIが表示されても、Reactが完全にハイドレーション（hydrate: サーバーから送られてきたHTMLにイベントハンドラなどを付加し、クライアントサイドのReactアプリケーションとして機能させること）を完了するまで、ユーザーはUIを操作できません。大量のJavaScriptが必要な場合、TTIが遅延します。
• JavaScriptバンドルサイズの増大： アプリケーションが成長するにつれて、必要なJavaScriptの量が増加します。コンポーネントのロジック、ライブラリのコード、さらにはデータ取得のロジックまで、全てがクライアントサイドのバンドルに含まれます。これはダウンロード時間と実行時間、そしてメモリ使用量に悪影響を与えます。
• データ取得の非効率性（ウォーターフォール問題）： クライアントサイドでデータ取得を行う場合、コンポーネントがレンダリングされてから初めてデータ取得が開始されることがよくあります。ネストされたコンポーネントがそれぞれデータを必要とする場合、親コンポーネントのデータ取得が終わってから子コンポーネントのデータ取得が始まる、というように、複数のデータ取得リクエストが直列に実行され、UIが表示されるまでに時間がかかる「データ取得のウォーターフォール」が発生しやすくなります。
• SEO（検索エンジン最適化）: クローラーがJavaScriptを実行してコンテンツをレンダリングできるとは限らないため、初期HTMLが空に近いCSRアプリケーションは、SEOに不利になる可能性があります。

1.2. サーバーサイドレンダリング（SSR）と静的サイト生成（SSG）

これらのCSRの課題に対処するため、サーバーサイドレンダリング（SSR）や静的サイト生成（SSG）といった手法が普及しました。Next.jsやGatsbyのようなフレームワークがこれらの機能を提供し、人気を博しました。

• サーバーサイドレンダリング（SSR）: サーバーがリクエスト時にReactコンポーネントをHTML文字列にレンダリングし、そのHTMLをブラウザに返します。ブラウザはすぐにコンテンツを表示できます（First Contentful Paintが高速）。その後、クライアントサイドのJavaScriptがダウンロードされ、ReactがHTMLにアタッチされてインタラクティブになります（ハイドレーション）。初期表示は高速になりますが、ブラウザに送信されるJavaScriptの量はCSRと変わらず、ハイドレーションが完了するまではTTIが遅いという課題は残ります。また、サーバーはリクエストごとにHTMLを生成するため、サーバー負荷が増加する可能性があります。
• 静的サイト生成（SSG）: ビルド時に全てのページを事前にHTMLファイルとして生成します。ブラウザは静的なHTMLをダウンロードするだけで済むため、最も高速な初期表示とTTIを実現できます。しかし、ページのコンテンツがビルド時以降に変化しない静的なサイト（ブログ、ドキュメントサイトなど）に限定されます。動的なコンテンツやユーザー固有のコンテンツには不向きです。

SSRやSSGはCSRの初期表示やSEOの課題を解決しましたが、JavaScriptバンドルサイズの増大や、インタラクティブになるまでの時間の遅延といった課題は部分的にしか解決できていませんでした。特に、アプリケーションの規模が大きくなるにつれて、クライアントに送信されるJavaScriptの量は依然として大きな問題でした。

また、データ取得に関しても、SSRではサーバー側でデータを取得してからHTMLを生成しますが、コンポーネントレベルでのきめ細やかなデータ取得の最適化は、依然として工夫が必要でした。

このような背景から、「JavaScriptをクライアントに送る量を最小限に抑えつつ、高速な初期表示とインタラクティブ性を両立させ、サーバーでのデータ取得をよりシンプルに行う」という、ウェブアプリケーション開発の次のステップが求められるようになりました。ここにReact Server Components（RSC）が登場します。

2. React Server Components (RSC) とは？

React Server Componentsは、Reactコンポーネントをサーバー上でレンダリングし、その結果をクライアントに送信する新しいレンダリングモデルです。しかし、これは従来のSSRとは異なります。SSRはサーバー上でコンポーネントをHTML文字列にレンダリングしますが、RSCはコンポーネントを特別なシリアライズ可能なフォーマットにレンダリングします。このフォーマットは、クライアントサイドのReactランタイムによって解釈され、UIツリーとして構築されます。

RSCの核心的なアイデアは、コンポーネントが実行される場所を選択できるようにすることです。全てのコンポーネントがクライアントで実行される必要はありません。データ取得や静的なコンテンツ表示など、クライアントのインタラクションを必要としない部分はサーバーで実行し、インタラクティブな部分だけをクライアントで実行します。

2.1. サーバーコンポーネント vs クライアントコンポーネント vs 共有コンポーネント

RSCモデルでは、コンポーネントは主に以下の3つのタイプに分類されます。

1. サーバーコンポーネント (Server Components):

   • 実行場所: サーバー上でのみ実行されます。
   • 特徴:
     • State (useState) や Effect (useEffect) は使用できません。
     • ブラウザAPI (window, documentなど) にアクセスできません。
     • イベントハンドラ (onClickなど) を直接持つことはできません。（Server Actionを介してサーバーサイドの処理をトリガーすることは可能）
     • ファイルシステムやデータベースなど、サーバーサイドのリソースに直接アクセスできます。
     • サーバーサイドの依存関係（例: Node.jsモジュール、データベースクライアント）をインポートしても、クライアントバンドルに含まれません。
     • async コンポーネントとして定義でき、await を使って非同期処理（主にデータ取得）を待つことができます。
   • 用途: データ取得、ファイル読み込み、APIキーなどの秘密情報を含むロジック、重い計算、静的なレイアウトやコンテンツの表示。
   • 利点: クライアントに送信されるJavaScript量が激減、サーバーサイドでの効率的なデータ取得、機密情報の安全な取り扱い。

2. クライアントコンポーネント (Client Components):

   • 実行場所: クライアント上でのみ、または初期レンダリング時にはサーバー上で（SSRとして）実行され、その後クライアントでハイドレーションされます。最終的なインタラクティブ性はクライアントで提供されます。
   • 特徴:
     • 従来のReactコンポーネントとほぼ同じです。
     • State (useState) や Effect (useEffect) を使用できます。
     • ブラウザAPI (window, documentなど) にアクセスできます。
     • イベントハンドラを持つことができます。
     • コンポーネントファイルの先頭に 'use client'; ディレクティブを記述して明示的に指定します。
   • 用途: ユーザーインタラクション（ボタンクリック、フォーム入力）、アニメーション、ブラウザAPIへのアクセス、State管理が必要なUI部分、クライアントサイドのライブラリを使用する部分。
   • 利点: 既存のReactコードやエコシステムとの互換性、豊富なインタラクティブ性の提供。

3. 共有コンポーネント (Shared Components):

   • 実行場所: サーバーとクライアントの両方で実行できます。
   • 特徴:
     • 'use client'; ディレクティブを持たない .js (または .jsx, .ts, .tsx) ファイルで定義されます。
     • StateやEffect、ブラウザAPIは使用できません。（もし使用すると、サーバー側でレンダリングされる際にエラーになるか、クライアント側でハイドレーション時に問題を引き起こす可能性があります）
     • 主にUI構造やスタイリングなど、純粋なレンダーロジックを持つコンポーネントに適しています。propsを受け取り、JSXを返すようなプレゼンテーションコンポーネントが典型的です。
   • 用途: UIライブラリ、デザインシステムの一部、サーバーコンポーネントとクライアントコンポーネントの両方で利用される共通のUI要素（ボタン、カード、レイアウトコンポーネントなど）。

重要なのは、これらのコンポーネントがどのように組み合わされるかです。

• サーバーコンポーネントは、他のサーバーコンポーネントをインポート・レンダリングできます。
• サーバーコンポーネントは、クライアントコンポーネントをインポート・レンダリングできます。 （ただし、クライアントコンポーネントのJSコード自体はクライアントに送信され、サーバーコンポーネントのレンダリング結果に含まれる特別な参照を通じてクライアント側でマウントされます）。
• クライアントコンポーネントは、他のクライアントコンポーネントをインポート・レンダリングできます。
• クライアントコンポーネントは、サーバーコンポーネントをインポート・レンダリング できません。サーバーコンポーネントはサーバーでのみ実行されるため、クライアントコンポーネントがインポートしても意味がないからです。ただし、サーバーコンポーネントをpropsとして子要素として受け取ることは可能です。これは、サーバーコンポーネントのレンダリング結果をクライアントコンポーネントに「穴埋め」として渡すイメージです（例: Layout クライアントコンポーネントの子として Page サーバーコンポーネントを渡す）。

この最後の点、「クライアントコンポーネントはサーバーコンポーネントを直接インポートできないが、子として受け取ることはできる」というのが、RSCにおけるコンポーネントの親子関係とデータフローを理解する上で非常に重要です。サーバーコンポーネントは「上の方」（ルートに近い方）に配置されやすく、データ取得などを行い、その結果やUIをクライアントコンポーネントに渡す、という構造が一般的になります。

2.2. RSCのレンダリングフロー

RSCのレンダリングフローは、従来のSSRやCSRとは異なります。Next.jsのApp Routerを例に説明します。

1. ユーザーがURLにアクセス。
2. サーバーは、リクエストされたルートに対応するサーバーコンポーネントを特定します。
3. サーバー上で、ルートのサーバーコンポーネントからレンダリングが開始されます。サーバーコンポーネント内でawaitによるデータ取得が行われます。
4. レンダリングツリー中にクライアントコンポーネントが見つかった場合、その部分のレンダリングはサーバー上では停止され、クライアントコンポーネントへの参照が特別なRSCペイロードに含まれます。サーバーコンポーネント自体は、そのクライアントコンポーネントに渡すpropsを含めてレンダリングを続けます。
5. サーバー上でレンダリングされたサーバーコンポーネントの構造と、クライアントコンポーネントへの参照、および初期データなどが含まれたRSCペイロードが生成されます。このペイロードはHTMLではありません。
6. 同時に、Next.jsのApp Routerは、従来のSSRと同様に、ルートの初期HTMLシェルを生成します。これは高速なファーストペイントのためです。このHTMLには、サーバーコンポーネントの一部（Suspenseのフォールバックなど）や、レンダリングツリーの「シェル」が含まれることがあります。
7. ブラウザは初期HTMLを受信し、すぐに表示します。
8. ブラウザは、RSCペイロードを受信します。
9. クライアントサイドのReactランタイムがRSCペイロードを解釈し、UIツリーを構築します。ここで、クライアントコンポーネントの参照が見つかった場合、対応するJavaScriptコードがダウンロードされ、クライアント側でコンポーネントがレンダリング・ハイドレーションされます。
10. UIが完全に表示され、インタラクティブになります。

このプロセスは、ストリーミングを利用することでさらに効率化されます。サーバーはRSCペイロードを一度に全て送信するのではなく、レンダリングが完了した部分から順次クライアントにストリーム送信できます。クライアントはそれを受け取り次第、UIの該当部分をレンダリングします。これにより、データ取得に時間のかかる部分があっても、ページの他の部分はすぐに表示され始め、ユーザーは待たされている感覚を軽減できます。

3. RSCがもたらすReact開発の変化

RSCは、従来のReact開発パラダイムにいくつかの重要な変化をもたらします。

3.1. パフォーマンスの向上

3.1.1. JavaScriptバンドルサイズの削減

これはRSCの最も大きな利点の一つです。サーバーコンポーネントのコードはクライアントに送信されません。これにより、以下のようなコードをクライアントバンドルから完全に排除できます。

• データ取得ライブラリ（例: node-fetch, データベースクライアント）
• マークダウンパーサーや日付フォーマットライブラリなど、サーバーでのみ必要なユーティリティ
• 認証情報やAPIキーなど、秘密情報を含むロジック
• 静的なUIコンポーネントのコード自体

クライアントがダウンロードしてパース・実行する必要があるJavaScript量が減るため、ページのロード時間が短縮され、特に低速なネットワーク環境やリソースに制約のあるデバイスでのパフォーマンスが大幅に向上します。

3.1.2. 高速な初期表示とインタラクティブ化

SSRと組み合わせることで、RSCは高速な初期表示を実現します。さらに、クライアントコンポーネントのJavaScriptのみがダウンロードされればよいため、ハイドレーションに必要なJS量が減り、TTIも改善されます。

3.1.3. データ取得の効率化

サーバーコンポーネント内で直接 await を使用してデータ取得できることは、開発者にとって非常にシンプルです。クライアントサイドで useEffect とローディングステートを組み合わせてデータ取得を行う必要がなくなります。

“`javascript
// 従来のClient Componentでのデータ取得
‘use client’;

import { useState, useEffect } from ‘react’;

function Post({ postId }) {
const [post, setPost] = useState(null);
const [loading, setLoading] = useState(true);

useEffect(() => {
async function fetchData() {
const res = await fetch(/api/posts/${postId});
const data = await res.json();
setPost(data);
setLoading(false);
}
fetchData();
}, [postId]);

if (loading) return

Loading…

;
if (!post) return

Post not found

;

return (

);
}
“`

``javascript
// RSCでのデータ取得 (Next.js App Router)
async function Post({ postId }) {
// サーバー上で直接データをフェッチ
const res = await fetch(${process.env.API_URL}/posts/${postId}`);
const post = await res.json();

if (!post) return

Post not found

;

return (

);
}
“`

RSCでは、コンポーネントのレンダリングとデータ取得がサーバー側で密接に連携します。Next.jsのApp Routerでは、fetch APIが自動的に拡張され、リクエストのメモ化やキャッシュ、再検証（revalidation）といった機能が提供されます。これにより、データ取得のウォーターフォールを防ぎつつ、効率的にデータを扱えます。

また、Suspense と組み合わせることで、データ取得中のローディングステートをより宣言的に扱うことができます。データ取得中のコンポーネントはサスペンドし、その親の Suspense バウンダリで指定されたフォールバックが表示されます。

3.2. 開発体験の向上（特定タスクにおいて）

データ取得をサーバーコンポーネントで行えるようになったことで、クライアントコンポーネントはUIのインタラクティブ性やState管理に集中できます。これは、関心の分離を促進し、コンポーネントの役割を明確にします。

特に、静的なコンテンツやデータ表示が中心のコンポーネントでは、useState や useEffect といったフックを使わずに済むため、コードがシンプルになります。

3.3. セキュリティの向上

APIキー、データベース認証情報、外部サービスのシークレットキーなどの機密情報は、サーバーコンポーネント内であれば安全に扱えます。これらの情報は決してクライアントに送信されないため、情報漏洩のリスクが低減します。

javascript
// サーバーコンポーネント内での安全なAPIキー使用
async function DataFetchingComponent() {
// API_KEYはサーバーの環境変数から取得
const apiKey = process.env.EXTERNAL_API_KEY;
const res = await fetch(`https://external.api.com/data?key=${apiKey}`);
const data = await res.json();
// ... render data
}

従来のCSRやSSRでは、クライアントから直接APIを呼び出す場合、APIキーを環境変数に入れてもビルド時にクライアントバンドルに含まれてしまうリスクがありましたが、RSCではこのような心配がなくなります。

3.4. ストリーミングによるユーザー体験の向上

RSCのレンダリング結果とペイロードはストリーミングが可能です。これは、データ取得に時間のかかる部分がある場合でも、既にサーバーでレンダリングが完了した他の部分から順次クライアントに送信され、表示を開始できることを意味します。

例えば、ページのヘッダーやサイドバーのような高速に準備できる部分はすぐに表示し、時間がかかるメインコンテンツの読み込み中はローディングスピナーを表示するといったことが、Suspense を使うことで容易に実現できます。これにより、ユーザーはページのロードが進行していることを視覚的に確認でき、待ち時間を短く感じることができます。

3.5. SEOとOGPの改善

RSCはSSRと組み合わせて使用されることが一般的です（例: Next.js App Router）。これにより、サーバーでレンダリングされた初期HTMLがブラウザに送信されるため、検索エンジンのクローラーがコンテンツを適切にインデックスできるようになります。OGP（Open Graph Protocol）タグなどもサーバー側で動的に生成しやすくなります。

3.6. サーバーアクション (Server Actions) との連携

RSCの導入と並行して、Reactとフレームワークはサーバーアクションという概念も推進しています。サーバーアクションは、クライアントから直接サーバーサイドのコード（非同期関数）を呼び出すための仕組みです。これは、フォーム送信やボタンクリックなどのユーザーインタラクションによって、データベースの更新やファイル操作といったサーバーサイドの処理を実行したい場合に非常に便利です。

従来のSPA開発では、クライアントからサーバーのAPIエンドポイントに対してHTTPリクエスト（POST, PUTなど）を送信する必要がありましたが、サーバーアクションを使えば、クライアントコンポーネントからサーバーコンポーネント内に定義された非同期関数を直接呼び出すかのような記述が可能になります。

“`javascript
// Server Component (または Server Actionを含むファイル)
‘use server’; // このディレクティブが必要

import { savePost } from ‘@/lib/posts’;

export async function createPost(formData) {
const title = formData.get(‘title’);
const content = formData.get(‘content’);
// サーバー側で安全に処理
await savePost({ title, content });
}
“`

“`javascript
// Client Component
‘use client’;

import { createPost } from ‘@/app/actions’; // サーバーアクションをインポート

function NewPostForm() {
return (
// フォームアクションとしてサーバーアクションを直接指定

);
}
“`

サーバーアクションはRSCと密接に関連しており、クライアントコンポーネントからサーバーサイドの変更操作を簡単に行えるようにすることで、RSCモデルでの開発体験を向上させます。データ取得はサーバーコンポーネントで、データの変更はサーバーアクションで、という役割分担が明確になります。

4. RSC導入における課題と考慮事項

RSCは多くの利点をもたらしますが、導入にあたってはいくつかの課題や考慮すべき点があります。

4.1. パラダイムシフトと学習コスト

最も大きな変化は、開発者が「コンポーネントがどこで実行されるか」を常に意識する必要がある点です。従来のReact開発者は、ほとんどのコードがクライアントで実行されることを前提としていました。RSCでは、サーバーコンポーネントとクライアントコンポーネントの明確な区別、それぞれの制約、そして相互のやり取りのルールを理解する必要があります。

特に、StateやEffect、ブラウザAPIに依存する既存のライブラリは、クライアントコンポーネント内で使用する必要があります。また、クライアントコンポーネント内で定義されたStateは、そのコンポーネントのサブツリーでのみ有効になります。サーバーコンポーネントから直接クライアントコンポーネントのStateを操作することはできません。グローバルなState管理が必要な場合は、クライアントコンポーネントのルートに近い部分でState管理ライブラリをセットアップし、それを他のクライアントコンポーネントに渡す（Contextなどを使用）というパターンが考えられます。

この思考の切り替えには、ある程度の学習コストがかかります。

4.2. 既存ライブラリとの互換性

多くの既存のReactライブラリ（例: UIライブラリ、State管理ライブラリ、アニメーションライブラリ）は、クライアントサイドでの実行、StateやEffectの使用、ブラウザAPIへのアクセスを前提として開発されています。これらのライブラリは、RSC環境では 'use client' を持つクライアントコンポーネント内で使用する必要があります。

ライブラリ自体がRSCフレンドリーに対応しているかどうかも重要です。例えば、一部のUIライブラリは、コンポーネントがサーバーコンポーネントとしてレンダリングされることを想定していません。ヘッドレスUIライブラリなど、レンダリングにStateやEffectを多用しないライブラリは、RSC環境でも比較的簡単に利用できる傾向があります。ライブラリの作者がRSCを考慮して設計・アップデートしていくことが、エコシステム全体のRSC対応を進める上で重要です。

4.3. デバッグの複雑性

コードがサーバーとクライアントの両方で実行されるため、問題の発生箇所を特定するのが従来の開発よりも複雑になる可能性があります。サーバーサイドのログとクライアントサイドのコンソールログの両方を確認し、RSCペイロードのやり取りも理解する必要が出てくるかもしれません。フレームワークやツールのデバッグ機能の進化が期待されます。

4.4. サーバー負荷の増加

データ取得やレンダリングの一部をサーバーに移行するため、サーバーリソースの使用量が増加する可能性があります。特にトラフィックが多いアプリケーションや、データ取得・レンダリングに時間のかかるコンポーネントが多い場合、サーバーのスケールが必要になるかもしれません。これは従来のSSRアプリケーションでも同様の課題ですが、RSCではより多くのレンダリングワークをサーバーが担当する可能性があります。

4.5. キャッシュ戦略の再検討

RSCの優れた点の1つは、fetch APIの拡張による強力なキャッシュ機能です。しかし、これは同時に、データのキャッシュがどのように行われ、いつ無効化されるのか（再検証 – revalidation）を正確に理解する必要があることを意味します。意図しない古いデータが表示されたり、逆に頻繁にデータが取得されすぎたりしないよう、キャッシュ戦略を適切に設計・管理する必要があります。

4.6. SSRとの役割分担の理解

RSCはSSRを置き換えるものではなく、補完するものです。Next.js App RouterのようなRSCをサポートするフレームワークは、多くの場合、初期の高速表示のためにSSR（サーバーでのHTML生成）を行い、その後の動的なコンテンツやインタラクティブ性のためにRSCペイロードのストリーミングとクライアントでのレンダリング・ハイドレーションを行います。この二つのレンダリング手法の役割分担と連携を理解することが重要です。RSCペイロードはHTMLそのものではないため、RSC単体では初期の完全なHTMLを生成できません。

5. RSCの具体的な導入方法（Next.js App Routerを例に）

現時点で、RSCを最も成熟した形でサポートしているフレームワークは、Next.jsのApp Routerです。App Routerは、デフォルトでサーバーコンポーネントをベースとした設計になっており、RSCのコンセプトを最大限に活かせるようになっています。

ここでは、Next.js App RouterにおけるRSCの基本的な使い方を解説します。

5.1. ファイル規約

App Routerでは、ファイル名の規約によってサーバーコンポーネントかクライアントコンポーネントかが区別されます。

• .js, .jsx, .ts, .tsx (ルート、レイアウト、ページなど): デフォルトでサーバーコンポーネントです。これらのファイルはサーバー上で実行されます。
• 'use client'; ディレクティブを持つファイル: 明示的にクライアントコンポーネントとして指定されます。ファイルの先頭に 'use client'; と記述します。

これにより、開発者は特別なファイル拡張子を使う必要なく、ファイルの内容によってコンポーネントのタイプを区別できます。ただし、コードを整理するために、components ディレクトリ内に *.client.tsx や *.server.tsx といった命名規約を採用することも一般的です（これはNext.jsの規約ではなく、コミュニティの慣習です）。

5.2. サーバーコンポーネントでのデータ取得

サーバーコンポーネントは async として定義し、その中で await を使って非同期処理を待つことができます。

“`javascript
// app/page.tsx (Server Component)

async function getData() {
// このfetchはサーバー上で実行される
const res = await fetch(‘https://api.example.com/data’);
// エラーハンドリングは適切に行う
if (!res.ok) {
throw new Error(‘Failed to fetch data’);
}
return res.json();
}

export default async function Page() {
const data = await getData(); // サーバー上でデータを取得

return (

ここでは、getData 関数内で fetch が呼び出されていますが、この fetch はブラウザではなくサーバー上で実行されます。環境変数（process.env.API_URL など）を使ってサーバーサイドのエンドポイントを安全に指定することも可能です。

5.3. クライアントコンポーネントの作成と使用

インタラクティブな要素やStateが必要な場合は、クライアントコンポーネントを作成します。

“`javascript
// components/interactive-counter.tsx

‘use client’; // これがクライアントコンポーネントであることを示す

import { useState } from ‘react’;

export default function InteractiveCounter() {
const [count, setCount] = useState(0);

return (

);
}
“`

この InteractiveCounter コンポーネントは、先ほどの app/page.tsx のサーバーコンポーネントからインポートされ、レンダリングされています。サーバーコンポーネントはクライアントコンポーネントをインポート・レンダリングできます。

5.4. クライアントコンポーネント内でのデータ取得

クライアントコンポーネントでもデータ取得は可能ですが、それはあくまでクライアントサイドでのフェッチになります。例えば、ユーザーのアクションに応じて追加のデータを取得する場合などに使用します。ただし、初期ロード時に必要なデータ取得は、可能な限り親のサーバーコンポーネントで行うのがRSCの思想です。

“`javascript
// components/client-data-fetch.tsx

‘use client’;

import { useEffect, useState } from ‘react’;

export default function ClientDataFetch({ userId }) {
const [userData, setUserData] = useState(null);

useEffect(() => {
async function fetchUserData() {
const res = await fetch(/api/users/${userId}); // クライアント側でAPIを叩く
const data = await res.json();
setUserData(data);
}
fetchUserData();
}, [userId]);

if (!userData) return

Loading user data…

;

return (

);
}
“`

このように、同じ fetch であっても、サーバーコンポーネント内で使用するかクライアントコンポーネント内（useEffectなど）で使用するかで、実行される場所が変わります。

5.5. サーバーコンポーネントからクライアントコンポーネントへのデータの受け渡し

サーバーコンポーネントで取得したデータは、propsとして子であるクライアントコンポーネントに渡すことができます。

“`javascript
// app/post/[id]/page.tsx (Server Component)

import InteractiveCommentSection from ‘@/components/interactive-comment-section’;

async function getPost(postId) {
const res = await fetch(${process.env.API_URL}/posts/${postId});
return res.json();
}

async function getComments(postId) {
const res = await fetch(${process.env.API_URL}/posts/${postId}/comments);
return res.json();
}

export default async function PostPage({ params }) {
const postId = params.id;

// サーバーで投稿とコメントを並列取得
const [post, comments] = await Promise.all([
getPost(postId),
getComments(postId)
]);

if (!post) return

Post not found

;

return (

  <h2>Comments</h2>
  {/* サーバーで取得したデータをクライアントコンポーネントに渡す */}
  <InteractiveCommentSection initialComments={comments} postId={postId} />
</article>