Next.js Server ActionsとRSCの技術的関係を解説

Server Actionsは「APIを作らずにサーバー関数を呼べる機能」として説明されることが多い。しかし、Qiitaのnogataka氏による記事では、その理解が不十分であることが指摘されている。Next.js App RouterにおいてServer Actionsは、React Server Components（RSC）で構築したサーバー主導のユーザーインターフェースに、更新経路を1本加えるための仕組みなのだ。

概念の分離と役割分担

RSC周辺の技術が分かりにくい原因は、異なるレイヤーの概念が同時に説明されることにある。nogataka氏の記事では、最初に4つの概念を分離して整理している。

• MPA / SPA：ページ遷移をどのように行うか
• SSR / CSR：初期HTMLをどこで生成するか
• Server / Client Components：Reactコンポーネントをどこで実行するか
• Server Actions / Route Handlers：ブラウザからサーバー処理をどう呼び出すか

これらは単純な置き換え関係ではない。Next.js App Routerの1ページは、初回アクセス時にサーバーでHTMLを生成し、Server ComponentとClient Componentを組み合わせ、ページ内遷移をSPAのようにフルリロードせずに行い、Server Actionsを呼び出してデータを更新し、更新後のRSC Payloadを既存のReactツリーへ反映するという複数の性質を同時に持つ。

SSRとRSCの決定的な違い

従来のSSRは、初回表示用HTMLをサーバーで生成する仕組みだ。ReactコンポーネントをサーバーでレンダリングしてHTMLを生成し、ブラウザへ送信する。しかし、ブラウザ上で同じReactコンポーネントを動作させるためには、対応するJavaScriptが必要になる。このJavaScriptの読み込み後に実行されるのがHydrationである。

一方、RSCはコンポーネント自体をサーバーで実行し、そのコンポーネントのJavaScriptをブラウザへ送らない仕組みだ。例えば、データベースアクセスを行うProductListコンポーネントがある。このコンポーネントにはDBアクセスコードやDBドライバー、サーバー専用ライブラリ、ProductList関数の実装が含まれる。これらはすべてサーバー側だけで使用する依存パッケージであり、ブラウザに送る必要がない。ブラウザにはサーバーで実行した結果と、Client Componentとの接続情報だけが送られる。

nogataka氏はこの違いを一文で要約している。SSRはHTMLをどこで生成するかであり、RSCはコンポーネントをどこで実行し、どのJavaScriptを配信しないかである。SSRとRSCは競合するものではなく、Next.jsでは初回表示時に組み合わせて使われる。

RSC Payloadの役割

Server Componentの実行結果は、直接ブラウザ用JavaScriptになるわけではない。Next.jsはServer Componentの実行結果を、RSC Payloadと呼ばれるReact用のデータ表現へ変換する。概念的には、Server Componentのレンダリング結果、Client Componentを挿入する場所、Client Componentのモジュール参照、Server Componentから渡すProps、Suspense境界、Reactツリーを再構成するための情報が含まれる。

初回アクセス時の流れは次の通りだ。まずブラウザがページを要求し、Server Componentsがサーバーで実行されてRSC Payloadが生成される。このRSC PayloadとClient ComponentsからHTMLが生成され、ブラウザへ送信されて表示される。その後、Client Component用JavaScriptが読み込まれ、Client ComponentsがHydrationされて操作可能になる。

Client Componentの実行環境

‘use client’ディレクティブが記述されたClient Componentは、ユーザー操作とブラウザ上の状態を扱う。例えば、useStateフックを使ったCounterコンポーネントが作成できる。しかし、Client Componentはブラウザだけで描画されるわけではない。

Client Componentは、Server Componentから渡されたPropsを受け取り、初期表示を担う。ブラウザでHydrationされた後は、ユーザー操作に応じて再描画される。再描画はブラウザ上で行われ、サーバーとの通信は発生しない。

Server Actionsの詳細な動作

Server Actionsは、ユーザー操作をサーバー状態へ反映するための仕組みだ。具体的には、フォームの送信やボタンのクリックイベントにバインドして、サーバー上の関数を呼び出す。

Server Actionsが呼び出されると、サーバー上で対応する関数が実行される。この関数はデータベースの更新や外部APIの呼び出しなどの副作用を引き起こす可能性がある。関数の実行が完了すると、Next.jsは更新後のサーバー状態に基づいて、新しいRSC Payloadを生成する。

この新しいRSC Payloadは、既存のReactツリーにマージされる。マージの過程で、Server Componentsが再実行され、更新後のUIが生成される。Client Componentsは変更のあった部分だけが更新され、ユーザーに最新の状態が表示される。

Next.jsにおける全体像

nogataka氏の記事では、Server Actionsを単独の機能としてではなく、Next.js App Routerの全体像の中に位置づけている。Server Actionsは単独の便利機能ではなく、RSCで構築したサーバー主導のUIに、更新経路を1本足す仕組みなのである。

この構成は、開発者に明確な役割分担を提供する。Server Componentsはサーバー状態を読み取りUIを生成し、Client Componentsはユーザー操作とブラウザ上の状態を扱い、Server Actionsはユーザー操作をサーバー状態へ反映する。更新後はRSCの再実行が行われ、更新後のサーバー状態からUIを生成し直す。

業界への影響と今後の展望

Server ActionsとRSCの統合は、Web開発のパラダイムに影響を与えそうだ。従来のAPIエンドポイント作成というボイラープレートが不要になり、開発者はよりドメインロジックに集中できる。また、クライアントサイドJavaScriptの削減により、初期表示性能の向上やセキュリティの強化が期待できる。

React 19のAction系Hooksとの組み合わせにより、楽观的UIやポジティブナビゲーションなどのパターンも実現しやすくなる。これはユーザー体験を向上させる可能性がある。

一方で、この新しい開発モデルには学習コストが伴う。概念の数が増え、RRSCやRSC Payloadといった新しい用語を理解する必要がある。開発ツールの進化やドキュメントの充実が、この技術の採用速度を左右するだろう。

編集部の見解

Server ActionsとRSCの統合は、今後3〜6ヶ月でNext.jsエコシステムの開発パターンを変化させる可能性がある。具体的には、データ更新ロジックの統一が進み、APIルートの数が減少する傾向が見込まれる。これはプロジェクト構成の簡素化につながるが、サーバーサイドロジックの管理方法についてチーム内で新しいコンセンサスが必要になる。

長期的に見れば、この技術はWebアプリケーションのアーキテクチャに影響を与える。クライアントとサーバーの境界が曖昧になり、フルスタック開発の必要性がさらに高まる。これは開発者のスキルセットの変化を促し、フルスタックエンジニアの需要を押し上げる可能性がある。

編集部が問うのは、この新しい開発モデルがどのようなセキュリティ上の課題を生むかである。Server Actionsは直接サーバー上の関数を呼び出すため、不正な呼び出しや権限の管理が重要になる。Next.jsのセキュリティモデルがこのシナリオをどこまでカバーできるか、実際のプロジェクトでの検証が待たれる。

参考

• 「備忘録：Next.jsのServer ActionsをRSC・React 19から理解する。SSR・Hydration・再描画との関係を1本の流れに整理する」, by nogataka — Qiita, 2026-08-22T03:52:09.000Z (ARR)
• 元記事URL: https://qiita.com/nogataka/items/8e416beb71e43af91bdb?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items