Server Actionsとフロント／バックエンド分離はどちらが正解か？ #PERSOL CAREER Advent Calender2025

はじめに
フロントとバックエンドの分離は万能ではない
Server Actions が解決する課題
それでも、分離すべきタイミングはある
- 分離が必要になる条件
では、実際どう判断すべきか？
まとめ：Server Actions は「選択肢を狭めないための技術」

はじめに

こんにちは。

HR forecasterというプロダクトでエンジニアをしている松本です。

Next.js 13 以降で登場した Server Actions は、フロントエンドから直接サーバー処理を呼び出せる新しい仕組みです。
フォーム投稿や DB 操作を暗黙的な API として扱え、開発者は REST や GraphQL を意識せずにデータ処理ができます。
昨今、SNS 等の一部の技術コミュニティで「React2Shell」などと言われるセキュリティリスクが話題になることもありますが、今回はそうしたセキュリティの深い議論ではなく、採用しているサービスとしてどのようなものが向いているかについて考えていきたいと思います。

「フロントとバックエンドは分離した方が良いのでは？」

この疑問は非常に重要で、結論は どちらが正しいかではなく、どの段階にいるプロダクトかによって変わる という点にあります。
以下では、組織・プロダクト規模・技術的性質の観点から、どちらが適しているのかを整理しています。

フロントとバックエンドの分離は万能ではない

まず「分離は正義」という考えには注意が必要です。分離には当然メリットがありますが、それは コストを払って得るメリット です。

分離のメリット	代償
役割が明確になりスケールしやすい	API 仕様の設計と管理コストが増える
複数クライアントで利用できる	UI 改修のスピードが落ちる
テストやモジュール化が進む	開発が重くなる

つまり、分離は長期的資産になるが、短期開発・頻繁な UI 改善には不利になることがある ということです。
HR forecaster などの新規のサービスにおいては UI/UX の大規模な修正が頻繁に発生するケースが多く、スピードが何より求められることが多いです。

Server Actions が解決する課題

Server Actions は「分離しないほうが成果が出る領域」を強化する技術です。
主に以下のようなプロダクトと相性が良いとされています。

特性	該当例
UI とデータ操作が密接	管理画面、ダッシュボード、内部ツール
要件が頻繁に変わる	MVP、スタートアップ、PoC
チームが小規模	フルスタック or フロント主導

これらの領域では API を丁寧に分離するより、UI とサーバー操作を近い距離で扱うほうが生産性が高い という現実があります。
そのため Server Actions は「API をなくす」ではなく、API を意識せず使えるようにする 技術として価値を持っています。
HR forecaster チームが開発・運用するサービスもフロントエンドエンジニア中心でスタートアップ系サービスということもあり、Server Actions との相性が良いと考えられます。

それでも、分離すべきタイミングはある

Server Actions が優秀でも、すべてのプロダクトに適用できるわけではありません。以下の条件が将来見込まれる場合、バックエンド分離は必須になります。

分離が必要になる条件

条件	理由
Web だけでなくモバイルアプリも展開する	Server Actions は外部クライアントから呼び出せない
ビジネスロジックが肥大化する	UI から切り離した「資産化」が必要になる
API を外部に提供したい	URL も仕様も公開できない
チームが職能ごとに拡大する	UI とサーバーでは責務が異なる

この場合、フロントとは独立したサーバー層（BFF や REST/GraphQL）が必要になり、Server Actions 単独では限界が生まれます。
HR forecaster チームが開発するサービスも開発当初は良かったのですが、外部への API 提供が視野に入ってきたタイミングで難しい状況になってきました。

では、実際どう判断すべきか？

重要なのは、単に「分離する・しない」ではなく、

今は分離するべき段階なのか、後で分離できるように育てるべき段階なのか？

という観点です。

状況	推奨
UI を高速に改善したい段階	Server Actions で密結合でよい
機能が複雑化しはじめた	サービス層/ドメイン層を独立させていく
複数クライアント展開や規模拡大	API 化してフロントから切り離す