フロントエンドとバックエンドの「分離」はもう古い？ AI時代の“再統合”という逆説
最近、React や Next.js を触りながら、ふと思うことがある。
昔、PHP や Rails で全部まとめて作っていた頃の方が、実は開発って自然だったんじゃないか？ と。
もちろん、当時に戻りたいわけではない。jQuery 地獄や、ぐちゃぐちゃに混ざった PHP を美化する気もない。
ただ、AI を本格的に使って開発するようになってから、「フロントとバックエンドを綺麗に分離すること」が、絶対正義だったのかは、少し揺らぎ始めている。
ただし、これは「分離は時代遅れだ」という話ではない。場面によって答えが違う、という話だ。
「分離」が正義だった時代
昔はバックエンドエンジニアが HTML を吐いていた。
PHP、JSP、Rails、ASP.NET……。
1つのリポジトリの中で、DBもテンプレートもサーバ処理も全部触る。今思えばかなり密結合だった。
その後、SPA 時代が来る。
React や Vue が流行り、フロントエンドが巨大化した。
UI はどんどんリッチになり、状態管理、コンポーネント設計、非同期通信、SSR、CSR……と、ブラウザ側の責務が爆発的に増えていった。
結果として、
- フロントエンド（TypeScript / React）
- バックエンド（Go / Java / Python）
を分離して、API で通信する構成が“モダン”になった。
実際、この流れには合理性があったと思う。
専門性を分けた方が、大規模開発では効率が良かった。独立デプロイ、チームごとの所有権、明確な契約。
でも最近、AI が小〜中規模ではそこを揺さぶり始めている
Claude Code や各種 AI エージェントを触っていて、最近すごく感じる。
AI は「分離された世界」をあまり得意としていない場面がある。
例えばログイン機能を直したい時。
昔なら、
- API 側の修正
- OpenAPI 更新
- TypeScript 型更新
- React 側修正
- バリデーション同期
みたいなことをやる。
人間でも面倒だ。
AI にやらせても、結局コンテキストが分断される。
しかも、フロントとバックエンドが別リポジトリ、別言語だと、AI の理解が途切れやすい。
「あっち直したのに、こっち忘れてる」が普通に起きる。
ただし、ここは誤解しないでほしい。
だからといって、「分離構成はもうダメだ」と言いたいわけではない。
フロントエンドとバックエンドを別々の場所に置かず、同じリポジトリの中で近くに置き、OpenAPI から型を自動生成し、更新やテストを1コマンドで回せるようにしておけば、AI はかなり追従できる。
問題は、分離そのものではない。
人間が見ても AI が見ても、変更の流れが途中で切れてしまうことだ。
その切れ目をツールでつなげば、摩擦はかなり小さくなる。
つまり、ここで見えている不便さは「分離構成は間違い」という結論ではなく、まだ整える余地のある開発体験の問題だと思う。
AI は「全部見えてる世界」が好きな場面も多い
AI が強いのは、
- 単一リポジトリ
- 単一言語
- 密結合
- 全体を一気に読める構造
だったりする。
だから最近の Next.js App Router とか見てると、ちょっと面白い。
Next.js App Router で使われている Server Actions や RSC（React Server Components）を見ていると、結局かなり「フロントエンドがサーバ側に戻ってきている」ようにも見える。
Remix も、画面とサーバ処理を近い場所に置くという意味では、似た方向性を持っている。
「API を厳密に分離する」というより、“1つの流れ”として処理を書く方向に戻ってきている。
もちろん技術的には昔の PHP と全然違う。たとえば RSC は単に HTML を組み立てる仕組みではなく、どの処理をサーバで動かし、どこからブラウザ側に渡すかをフレームワークが管理する仕組みだ。
でも思想としては、少し韻を踏んでいる気がする。
それでも「分離派」の主張は依然として強い
ここはフェアに書いておきたい。
分離をやめない理由は、ノスタルジーや惰性ではない。
- 複数クライアント問題：Web、モバイル、サードパーティ連携。これらは結局 API を要求する。iOS アプリに Server Actions は出荷できない。
- セキュリティ境界：API という明確な面の方が監査しやすい。UI ツリーのあちこちから呼ばれるサーバ関数より、入口が絞られている方がレビューが効く。
- 独立スケーリング・独立デプロイ：フロントエンドのトラフィックとバックエンドの負荷は別の動き方をする。
- チーム独立性：2チームが並列で動ける方が、1チームが同じファイルで詰まるより速い。
- ベンダーロック：Server Actions はランタイムに縛られる。API はポータブル。
だから、昔ながらの「全部入りモノリス」が全面復活するとは思っていない。
小〜中規模で1チーム、クライアントが Web1つだけ、なら「TypeScript で全部、AI に一気通貫」は強い。実際、開発速度が異常に速い場面がある。
ただ大規模サービスになると、分離が払っていたコストは、何かと交換に支払われていたものだったと気づく。
多分これ、「揺り戻し」の途中なんだと思う
歴史って、結構こういうことを繰り返す。
分離しすぎる。 ↓ 運用コストが増える。 ↓ また統合したくなる。 ↓ でも統合しすぎると破綻する。 ↓ また分離する。
その繰り返し。
AI は、このバランス感覚を「変える」というより、「重心をずらす」感じだと思う。
昔の軸は「人間が分業しやすい構造」だった。
そこに新しい軸が加わってきた：「AI が横断的に理解しやすい構造」。
新しい軸が出てきたからといって、古い軸が消えるわけではない。両方が同時に効く。
最後に
正直、フロントエンドとバックエンドの“再統合”が本当に主流になるのかは、まだ分からない。
数年後には、また全然違うアーキテクチャが流行っているかもしれない。
ありうるのは、AIがもっと賢くなってフロントもバックエンドも両方理解するのがあたりまえになる世界。
ただ少なくとも、
「分離している方がモダンだから正義」
みたいな前提は、少し緩み始めている気がする。
AI を使っていると、「全部つながって見える方が楽」という場面が確かに増えた。
一方で、モバイル含む複数クライアント、複数チーム、強いセキュリティ境界が必要な場面では、分離は今でもしっかり“代金分の価値”を払っている。
20年前、PHP で全部書いていた頃。
PHP の中で HTML を書いて、その中にさらに jQuery を呼ぶ JS を書いていた世界。あの世界は、正直カオスだった。
さすがにあそこに戻る気はしない。
ただ、今 Next.js で Server Actions や RSC を見ていると、形は違っても、「全部ひとつの流れで書ける」あの感触の良い部分だけが、別の文法で戻ってきている気はする。 混沌は置いて、流れだけ持ち帰る。たぶんそういう揺り戻しだ。