ＡＷＳで整理する、フロントエンドの知識地図

Last updated at 2026-05-02Posted at 2026-05-02

【序章】はじめに

クラウドエンジニアがフロントエンドの領域に手を伸ばすと、React・Next.js・Vue・Nuxt・Laravel・Rails・FastAPI…と技術の選択肢が山ほどあり、何がどう違うのか理解しにくい。本記事では、デプロイ先のインフラ構成を軸に、各フレームワークがどのパターンに対応するか整理する。

先に結論

※ ポイント：ブラウザでUIを構築する役割（FE）を担えるのは、事実上JS/TSだけ。他言語はBE（🔌）として参加する。

分類	デプロイ先	主要技術
FE/BE分離型 (SPA、SSG)	FE： CloudFront＋S3 BE： APIGW＋Lambda / ELB＋ECS等	FE：JS/TSのみ（React/Vue/Angular/Astro） BE：自由に選択可
モダンSSR	FE： Vercel / ELB＋ECS等 BE： APIGW＋Lambda / ELB＋ECS、SaaS等	FE：JS/TSのみ（Next.js/Nuxt/Astro） BE：自由に選択可（必要な場合のみ）
MPA	ELB＋EC2(ECS)等	PHP/WordPress/Java/Ruby/Python/の伝統領域
BEのみ	API GW + Lambda / ELB＋EC2(ECS)等	Spring Boot/Rails API/Django DRF/FastAPI/Go
SaaS	SaaS内部	Salesforce/SAP/BIツール/ノーコード/ローコード/ECプラットフォーム等（ただしHeadless API連携でBE連携可能）
組み込み型	スマホ・ゲーム機・産業用機器	Swift / Kotlin / Flutter、その他独自規格等 ※本記事の対象外

対象範囲：ブラウザで動くWebアプリ

本記事が扱うのは、ブラウザ（Chrome・Safari等）でアクセスして使うWebアプリに限定する。Webアプリの画面はHTMLで構成されており、サーバまたはブラウザ上でHTMLを生成してユーザに届けることが基本である。

「画面のあるITシステム」は世の中に多数存在するが、本記事はその中でも「ブラウザで開いて使う」ものに絞って整理する。以下は本記事の対象外とする。

ブラウザ外で動くアプリ（ネイティブアプリ）

OSや専用ハード上で直接動作するアプリ。HTMLでない独自のUI技術で構築されている。

スマホアプリ（iOS / Android）：デバイス内にインストールされ、Swift / Kotlin / Flutter等で構築。描画にHTMLは使わない
PCインストール型アプリ（Word / Excel等）：OS上でネイティブ動作するアプリ
- ただしElectron系（Slack、VSCode、Discord、Steamクライアント等）はHTML/CSS/JSベースでデスクトップアプリ化しており、Webの延長と言える
家庭用ゲーム機（Nintendo Switch、PlayStation、Xbox等）：独自OS・独自UIで動作。ブラウザは使わない
組み込み機器・産業用機器（ATM、POS、券売機、カーナビ、工場制御HMI、パチンコ等）：専用ハード上で独自UIが動作。一部にWeb技術を採用するケースもあるが基本はネイティブ

ブラウザ内だが特殊用途（本記事の整理軸に乗らない）

ブラウザで動くがHTMLベースのフレームワークとは別系統で、本記事の分類軸（FE/BE分離、SSR/MPA等）に乗らないもの。

ブラウザゲーム・XR系（Unity WebGL、Three.js、PlayCanvas、WebXR等）：ブラウザで動くがCanvas / WebGLで描画するため、HTMLベースのフレームワークとは別系統
ブラウザ拡張機能（Chrome拡張等）：HTML / JSベースだが配信方式が特殊。既存のWebアプリへのアドオンという位置付け
BIツール（Tableau、Power BI、Looker等）：ブラウザで使うがデータ可視化特化のSaaS製品。本記事の分類軸ではSaaS系として後述8章で言及する

補足：境界線について

技術の進化により、これらの境界は完全には明確ではない。

Electron / Tauri：HTML/JSでデスクトップアプリを構築する技術。Webの知識でPCアプリが作れる
PWA（Progressive Web App）：Webアプリにオフライン機能・通知等を追加してネイティブアプリに近づける技術
React Native / Flutter Web：モバイルアプリ用フレームワークでWebも出力可能

本記事では、これらは「ブラウザでアクセスするWebアプリ」という主目的で使われる場合のみ対象とする。

対象外：バックエンドのデプロイ先の選定方法

バックエンドのデプロイ先（API GW＋Lambdaか、ELB＋ECS(EC2)か等）はフロント側の言語制約とは異なり、トラフィックパターン・処理時間・コスト構造・チームの運用体制・既存資産など複数の判断軸が絡み合う設計判断である。同じフレームワークで、両方の構成を使い分けることもある。「フロントエンドをデプロイする箱」に集中するため、本記事では対象外とする。
GPU要件・レガシーなOS依存・ファイルシステムマウント（EFS等）の複雑さなど、フロント側の言語制約とは別次元の判断軸が絡むため、EC2・ECS/EKSの選定も対象外とする。

【１章】パターン概要

パターン①：フロントエンド・バックエンド分離型（SPA / SSG）

HTMLの生成場所：ブラウザ（SPA）またはビルド時（SSG）
インフラ構成はどちらも同じで、CDN（CloudFront + S3等）から静的ファイルを配信する。サーバは不要（バックエンドAPIは別途必要）。

このパターンには、SPA（Single Page Application） と SSG（Static Site Generation） の2つのアプローチがある。インフラ構成は同じだが、HTMLをどの時点で・どこで作るかが異なる。

SPA：サーバから受け取るHTMLはほぼ空。ブラウザがJavaScript（React等）を実行し、DOM（画面の構造）を動的に組み立てる。初回アクセス時にJSファイルの読み込みが発生するため表示が遅くなりやすいが、以降の画面遷移はJSが制御するため高速。

SSG：ビルド時（デプロイ前）にHTMLが完成した状態で生成される。ブラウザはそのHTMLをそのまま表示するだけなので、初回表示も高速。ただし、コンテンツ更新時は再ビルドが必要なため、更新頻度が高いページには向かない。

FE/BE分離型：フロントエンド

CloudFront + S3 でHTML / CSS / JS / 画像を配信
SPA：初回のみサーバからファイルを取得し、以降の画面描画はJS（React等）が制御。ブラウザ上でUIが完結する
SSG：ビルド済みのHTMLファイルをそのまま配信。ブラウザはHTMLを受け取って即座に表示する

FE/BE分離型：バックエンド

APIGW + Lambda + DB
ALB + ECS + (Redis) + DB
ALB + EC2 + (Redis) + DB

JSONのみ返す。HTMLは返さない。

FE/BE分離型：トレードオフ

観点	メリット	デメリット
パフォーマンス	【SPA】初期ロード後の画面遷移が高速【SSG】初回表示も高速（HTMLが完成済み）	【SPA】初回ロードが重くなりやすい【SSG】コンテンツ更新にはビルドし直しが必要
SEO	【SSG】 HTMLが完成済みのため、クローラがそのまま読める。SEO対策が可能	【SPA】クローラがJSを実行できない場合、コンテンツが認識されないリスク
開発分離	FE・BEを完全に分離して開発できる	FE・BEで別々のチーム・デプロイが必要
インフラ	CDNで静的配信できるため低コスト・高速	BEは別途必要
スケーラビリティ	FEはCDN、BEもオートスケールで、大量アクセスに強い	BEの設計次第でDB接続数がボトルネックになることも
向いてるアーキテクチャ	マイクロサービス・API駆動・BFF（Backend for Frontend）構成と相性が良い	モノリス構成とは相性がやや悪い
向いてる用途	【SPA】管理画面・SaaS・ログイン後の機能画面・大量アクセスが想定されるサービス【SSG】ブログ・LP・ドキュメントサイト・ポートフォリオ・更新頻度が低いコンテンツサイト	【SPA】SEOが重要なコンテンツサイト【SSG】更新頻度が高い動的コンテンツ

パターン②：サーバサイドレンダリング型（SSR / MPA）

HTMLの生成場所：サーバ（サーバサイド）
サーバがHTMLを生成してブラウザに返す。ブラウザはそのHTMLを表示する。

このパターンには、MPA（Multi Page Application / 従来型） と SSR（モダン型） の2つのアプローチがある。インフラ構成は同じ（サーバ常駐が必要）だが、ページ遷移時の挙動とUI構築の方法が異なる。

MPA（従来型）：ページ遷移のたびにサーバから新しいHTMLを丸ごと取得する。画面が一瞬白くなりリロードされる。サーバ側のテンプレートエンジン（ERB・Blade・Thymeleaf・Jinja2等）でHTMLを生成する。PHP・Rails・Django・Spring MVC・WordPress等が該当する。

SSR（モダン型）：初回アクセス時はサーバでHTMLを生成して返すが、以降の画面遷移はJavaScriptが制御し、SPA的に滑らかに動作する（ハイドレーション）。React・Vue等のコンポーネントをサーバ上で実行してHTMLを生成する。Next.js・Nuxt.js・React Router v7（フレームワークモード）等が該当する。

SSR/MPA：フロント兼サーバ

Vercel（Next.js）
ALB + ECS + (Redis) + DB
ALB + EC2 + (Redis) + DB
Lightsail（WordPress等）

サーバがHTML + CSS + JSを生成してブラウザに返す。

SSR/MPA：バックエンド（必要な場合のみ）

APIGW + Lambda + DB
ALB + ECS + (Redis) + DB
Vercel + AWS BEの組み合わせも可能

SSR/MPA：トレードオフ

観点	メリット	デメリット
パフォーマンス	【共通】初回表示が速い（HTMLが完成した状態で届く）【SSR】初回以降の遷移もSPA的に動作し高速	【共通】リクエストのたびにサーバ処理が発生【MPA】ページ遷移のたびに画面全体がリロードされる
SEO	クローラがHTMLをそのまま読めるため有利（SSR・MPA共通）	—
開発	【MPA】FE・BEが同じ言語・同じフレームワークで完結しやすい【SSR】React/Vue等のモダンなUI構築が可能	【MPA】UIの表現力がテンプレートエンジンに依存【SSR】React/Vue等のFEスキルが別途必要になる
インフラ	—	サーバが常駐するためコストが高くなりやすい
スケーラビリティ	ECS・EC2のオートスケーリングで対応は可能	⚠️ リクエストのたびにHTMLを生成するため、大量アクセス時にサーバ負荷が高くなりやすい。セッション管理をRedis等に外出しする設計が必要になる
向いてるアーキテクチャ	モノリス・MVC構成と相性が良い。小〜中規模のシンプルな構成で力を発揮	マイクロサービス化が進むと管理が複雑になる
向いてる用途	【MPA】コーポレートサイト・CMS・管理画面・非エンジニアが更新するサイト・FEとBEを同じチームで完結させたい場合【SSR】SEOが必要かつSPA的なUXも欲しいサービス・ECサイト・SaaSのマーケティングページ	大量同時接続・リアルタイム更新が多い画面

補足1：ISR（Incremental Static Regeneration / 増分静的再生成）について

ISRはNext.js等が提供する機能で、「SSGのように事前生成したHTMLをCDNから配信しつつ、一定間隔でバックグラウンドにてサーバがHTMLを再生成する」というキャッシング戦略である。思想としてはSSG（FE/BE分離型）の拡張だが、再生成にサーバが必須であるため、インフラ構成としてはサーバサイドレンダリング型（SSR/MPA）に分類される。

Vercelでは、ISRの再検証プロセス（キャッシュ管理・再生成のトリガー・CDNパージ）がすべてマネージドで動作するため、開発者はコード上でrevalidateの秒数を指定するだけで利用できる。

一方、AWS上でセルフホストする場合は構成が大幅に複雑になる。OpenNext等のアダプタを利用しても、以下のリソースが必要になる。

Lambda/ECS/EC2（HTML再生成の実行）
S3（キャッシュファイルの保存）
SQS（再検証キューの管理）
DynamoDB（タグベースのキャッシュ管理）
CloudFront invalidation（CDNキャッシュの手動パージ）

CloudFrontのキャッシュとNext.js内部のキャッシュが二重に存在するため、整合性の担保が難しく、運用負荷が高い。AWSでシンプルに同等の効果を得たい場合は、「SSR + CloudFrontのCache-Controlヘッダー」 で擬似的にISR相当のキャッシュ挙動を実現する方法が現実的な選択肢となる。

補足2：Vercel + SaaSパターン

ISRやSSRをVercelのマネージド環境で動かしつつ、バックエンドをSaaS化する構成は、近年のWeb開発で頻出パターンとなっている。

メディア・コーポレート：Vercel + Contentful / microCMS（ヘッドレスCMS）
EC：Vercel + Shopify Headless（ヘッドレスEC）
B2Bポータル：Vercel + Salesforce / HubSpot（CRM API連携）
認証分離：Vercel + Auth0 / Clerk

このパターンが選ばれる理由は明確で、上述の通りAWSでISRをセルフホストする構成は複雑になりがちな一方、Vercelならマネージドで動作する。さらに、データ層をSaaSに切り出すことで、自前でDB・管理画面を構築する必要もない。

つまり「フロントキャッシュ問題」と「データ管理の手間」を両方マネージドに任せられる構成であり、開発スピードと運用負荷の軽さが評価されている。ただし、SaaSへのロックイン、ライセンス料の積み上げ、Vercel ↔ SaaS API間の通信レイテンシ等のトレードオフは認識すべきである。

なお、大手SaaSをBEとして利用するこのパターンの詳細は「8.SaaS系」を参照。

【２章】フレームワーク別分類

1. JavaScript / TypeScript 系

ポジション： JavaScriptはブラウザが直接実行できるプログラミング言語であり、Webのフロントエンドを担うには避けて通れない存在である。さらにNode.jsの登場により、サーバサイド（バックエンド）でもJavaScriptが動作するようになり、フロントからバックまで同じ言語で統一できるようになった。TypeScript（JSに型を加えた上位互換）の普及により、大規模開発でも型安全に書けるようになっている。フロントエンド（React・Vue等）からBEフレームワーク（NestJS・Express等）、フルスタック（Next.js・Nuxt等）まで、最も広い守備範囲を持つ言語である。

補足：WebAssembly系の選択肢 ：ブラウザ上で実行できるのはJavaScriptだけではなく、WebAssembly（Wasm）も実行可能である。これによりBlazor WebAssembly（C#）、Yew / Leptos（Rust） 、Flutter Web（Dart） 等、JS/TS以外の言語でフロントエンドを書く選択肢が存在する。インフラ構成上はSPAと同等（CloudFront + S3）で、初回ロードでWasmランタイムをダウンロードする方式である。ただし採用例は限定的であり、現状はJS/TSが圧倒的なデファクトスタンダードとなっている。

1.1 React 系

思想： UIをコンポーネントという単位で分割・再利用し、状態（state）の変化に応じてブラウザ上でDOMを差分更新する。「UIは状態の関数である（UI = f(state)）」という考え方が根底にあり、宣言的にUIを記述できるのが特徴。React単体はライブラリとしての機能を最小限に絞っており、ルーティング・状態管理・通信は別ライブラリやフレームワーク（Next.js・React Router等）に委ねる設計になっている。

1.1.1 React（素）

FE/BE分離型のみ（SPA専用）
React単体で使う場合は、ルーティングにReact Router（ライブラリモード）、状態管理にReduxやZustand、API通信にAxiosやTanStack Query等を組み合わせて構成する。フレームワークとしてのレールがないため自由度は高いが、構成の意思決定が多くなる。
向いてるアーキテクチャ： API駆動のSPA。BFFやREST API・GraphQL APIと組み合わせる構成。
向いてる用途： 管理画面・SaaS・ダッシュボード・ログイン後の操作が多い画面
BEは別途必要（APIGW + Lambda、ALB + ECS等）

※ SolidJSも記述スタイルは異なるが、デプロイ先はReact（素）と同様。

1.1.2 React Router（v7）

基本はFE/BE分離型
思想： Reactのルーティングライブラリとして生まれたが、v7でRemixと統合され、フルスタックフレームワークに進化した。「ルートがデータフェッチの単位」という設計思想を持つ。v7には2つのモードがあり、ライブラリモード（従来のルーティングライブラリとしての使い方）とフレームワークモード（旧Remix相当のフルスタック機能を含む）を選択できる。
フレームワークモードでSSRを有効にすれば → サーバサイドレンダリング型（SSR）も可能
向いてるアーキテクチャ： ルートベースのデータローディング構成。サーバとクライアントの処理を同一ファイルに共存させたい場合に有効。
向いてる用途： SPA〜フルスタックWebアプリまで幅広く対応

1.1.3 Next.js

思想： Reactに「ページ」「ルーティング」「サーバ」の概念を加え、フルスタック開発を可能にしたフレームワーク。「適切なページに適切なレンダリング戦略を選ぶ」という思想。
向いてるアーキテクチャ： モノレポ構成・BFF構成・JAMstack。Vercelへのデプロイと相性が良い。
向いてる用途： コンテンツサイト・ECサイト・SEOが必要なサービス・SaaSのマーケティングページとアプリ画面が混在する構成

Next.jsにはPages Router（従来型） と App Router（v13.4以降） の2つのルーティング方式がある。

Pages Router では、ページ単位でレンダリング戦略を選択する。

モード	説明	パターン
SSG	ビルド時にHTML生成 → CDN配信	①FE/BE分離型
SSR	リクエストごとにサーバがHTMLを生成。サーバ必須	②サーバサイドレンダリング
ISR（SSGの拡張）	SSGにキャッシュ再検証を追加。一定間隔でサーバがバックグラウンドで再生成する。サーバ必須	②サーバサイドレンダリング
混在	ページ単位でSSG・SSRを使い分け。動的APIも呼べる	両方

App Router では、React Server Components（RSC）が導入され、コンポーネント単位でサーバ実行 / クライアント実行を選択するモデルになっている。

デフォルトで全てのコンポーネントがサーバコンポーネント（サーバ上で実行され、JSをブラウザに送らない）
インタラクティブな操作が必要な部分にのみ "use client" を付けてクライアントコンポーネントにする
ページ単位ではなく、コンポーネント単位で静的 / 動的を細かく制御できるため、1つのページ内にサーバで処理する部分とブラウザで処理する部分を混在させることが可能

※SvelteKitおよびQwikのデプロイ先についても、Next.JSと同様に理解できる

1.2 Vue 系

思想： ReactよりもHTML・CSS・JSの伝統的な書き方に近い「シングルファイルコンポーネント（.vue）」を採用し、<template> <script> <style> を1ファイルにまとめて書く。学習コストの低さと、既存のHTMLページに部分的に組み込みやすい設計が特徴。Reactが「JSの中にHTMLを書く（JSX）」アプローチなのに対し、Vueは「HTMLの中にロジックを書く」という、より直感的な方向性を取っている。

1.2.1 Vue.js（素）

FE/BE分離型のみ（SPA専用）
Vue単体で使う場合は、ルーティングにVue Router、状態管理にPinia（旧Vuex）を組み合わせて構成する。Reactの素と同様にフレームワークとしてのレールはないが、公式が推奨するライブラリの組み合わせが明確なため、迷いにくい。
向いてるアーキテクチャ： API駆動のSPA。Reactと同様にBEと分離した構成。
向いてる用途： 管理画面・社内ツール・比較的小〜中規模のWebアプリ。Laravelとの組み合わせも多い。

1.2.2 Nuxt.js（Vue の Next.js 相当）

思想： Vue.jsにルーティング・SSR・データフェッチの仕組みを加えたフルスタックフレームワーク。設計思想・機能セットはNext.jsに近い。「コンベンション（規約）でコードを減らす」という方針が強い。
向いてるアーキテクチャ： Next.jsと同様。Vueエコシステムを使いつつフルスタック構成を取りたい場合に選択される。
向いてる用途： Vue技術スタックのチームが担当するコンテンツサイト・ECサイト・フルスタックWebアプリ

モード	説明	パターン
SSG	ビルド時にHTML生成 → CDN配信	①FE/BE分離型
SSR	サーバがHTMLを生成。サーバ必須	②サーバサイドレンダリング
混在	ページ単位で使い分け可能	両方

1.3 Angular

思想： Googleが開発した「フレームワークが全部入り」の設計思想。DI（依存性注入）・ルーティング・フォーム・HTTPクライアント・テストユーティリティが標準搭載されており、ライブラリ選定の意思決定がほぼ不要。型安全・テスタビリティ・大規模開発での一貫性を重視しており、React・Vueが「自分で組み合わせる」思想なのに対し、Angularは「フレームワークが決めたやり方に従う」思想を取る。

基本はFE/BE分離型（SPA）
@angular/ssr を使えば → サーバサイドレンダリング型（SSR）も可能
向いてるアーキテクチャ： 大規模なモジュール分割構成。マイクロフロントエンドとの相性も良い。チームが大きく、厳密なコーディング規約が必要な現場に向く。
向いてる用途： 大規模エンタープライズWebアプリ・金融・官公庁系・社内基幹システムのフロントエンド

補足： Angular 17以降、従来の「Angular Universal」は非推奨となり、SSR機能は @angular/ssr パッケージに統合された。

1.4 Astro

思想： 「デフォルトでJSをブラウザに送らない」という思想が核心。ページ全体を静的HTMLとして出力し、インタラクティブな部分だけにJSを局所的に配置するアイランドアーキテクチャを採用している。React・Vue・Svelteなど複数のUIフレームワークを1プロジェクトで混在させることもできる。React・Vue・Angularが「アプリケーション」を作るためのフレームワークなのに対し、Astroは「コンテンツサイト」を最速で届けることに特化している。

基本はFE/BE分離型（静的サイト生成が得意）
SSRモード / Server Islands → サーバサイドレンダリング型（SSR）も可能
向いてるアーキテクチャ： コンテンツ重視のJAMstack構成。複数のUIフレームワークを組み合わせたい場合にも有効。
向いてる用途： ブログ・ドキュメントサイト・LP・ポートフォリオ・パフォーマンスとSEOを最優先するコンテンツサイト

1.5 Node.js 系バックエンドフレームワーク（Express / NestJS / Fastify / Hono 等）

思想： フロントエンドと同じJavaScript / TypeScriptでバックエンドも書くことで、言語を統一し開発効率を上げるアプローチ。従来はJava（Spring Boot）やRuby（Rails）やPython（Django）が担っていたAPI層を、TS/JSで代替するケースが増えている。フロントエンジニアがそのままBEも書ける、型定義をFE・BE間で共有できる、といった利点がある。

FE/BE分離型のBE専用（REST APIサーバ）
主なフレームワーク：
- Express：最も歴史が長く、エコシステムが最大。最小限の機能だけを提供し、残りはミドルウェアで拡張する思想。Flask（Python）に近い立ち位置。
- NestJS：TypeScriptファーストのエンタープライズ向けフレームワーク。DI（依存性注入）・デコレータ・モジュール構成など、設計思想はSpring Boot（Java）に非常に近い。大規模チームでの採用が多い。
- Fastify：Expressの後継的存在で、パフォーマンスを重視。JSON Schemaによるバリデーションやプラグインアーキテクチャが特徴。
- Hono：超軽量（約14KB）でCloudflare Workers・Deno・Bun・AWS Lambda等あらゆるランタイムで動作する。エッジ・サーバレス環境との相性が良い。
向いてるアーキテクチャ： REST API・マイクロサービス・BFF構成。フロントとBEの言語をTypeScriptに統一したいチームに向く。
向いてる用途： SPA / SSGのバックエンドAPI・マイクロサービスの1サービス・BFFサーバ・サーバレスAPI
デプロイ先：APIGW + Lambda、ALB + ECS / EC2、Cloudflare Workers（Hono）等

2. PHP 系

思想： 「HTMLの中にロジックを書く」というWebの黎明期から続く設計思想。サーバサイドでHTMLを生成してブラウザに返すサーバサイドレンダリング型（MPA）が原点。PHPはWebサーバ上で動くことを前提に設計されており、インフラの敷居が低い。

2.1 PHP（素）/ Laravel

基本はサーバサイドレンダリング型（MPA）（BladeテンプレートでサーバがHTMLを生成するMVC構成）
LaravelをAPIモードにすれば → FE/BE分離型のBEとしても使用可能
思想（Laravel）： 「開発者の幸福」を掲げた高機能フレームワーク。ORM（Eloquent）・認証・キュー・スケジューラ等が標準搭載。Railsに影響を受けたMVC + 規約重視の設計。
向いてるアーキテクチャ： モノリスMVC構成。フルスタックで素早く作りたい中小規模向け。APIモードにすればSPA + REST API構成のBEとしても機能する。
向いてる用途： 受託Webサービス・CMS・ECサイト・管理画面・スタートアップのMVP開発

2.2 WordPress

サーバサイドレンダリング型（MPA）のみ（PHPがHTMLを生成）
思想： ノーコード・ローコードでWebサイトを構築することを目的とした CMS（コンテンツ管理システム）。プラグインとテーマによる拡張が前提の設計。
向いてるアーキテクチャ： コンテンツ管理 + テーマによるUI制御のモノリス構成。
向いてる用途： コーポレートサイト・ブログ・ニュースサイト・非エンジニアが更新するWebサイト
デプロイ先：Lightsail・EC2・レンタルサーバ等

3. Java 系

思想： 型安全・堅牢性・大規模チームでの保守性を重視。エンタープライズ領域での実績が長く、DI・AOP・トランザクション管理などの仕組みが成熟している。近年はREST APIサーバとしての用途が主流になっている。

3.1 Spring MVC（旧来型）

サーバサイドレンダリング型（MPA）が主（JSP・ThymeleafでサーバサイドにてHTML生成）
思想： MVCパターンをサーバサイドで実現するフレームワーク。URLに対応するControllerがModelを操作しViewでHTMLを生成するという、サーバ中心の設計。
向いてるアーキテクチャ： サーバサイドMVC構成。現在は新規採用は少なく、既存システムの保守・改修での登場が多い。
向いてる用途： 既存エンタープライズシステムの保守・レガシーマイグレーション対象

3.2 Spring Boot

現代的な使い方はFE/BE分離型のBE（REST APIサーバ）
Thymeleaf等のテンプレートエンジンを使えば → サーバサイドレンダリング型（MPA）も可能（この場合、上記 Spring MVC 的なサーバサイドHTML生成の構成になる）
思想： Spring MVC を内包しつつ、その設定の複雑さを「自動設定（AutoConfiguration）」で解消し、すぐに起動できるAPIサーバを作ることを目指したフレームワーク。マイクロサービスとの相性も良い。
向いてるアーキテクチャ： REST API + マイクロサービス構成。ドメイン駆動設計（DDD）との組み合わせも多い。大規模チームでの分割開発に向く。
向いてる用途： 金融・保険・エンタープライズの基幹API・大規模Webサービスのバックエンド
デプロイ先：ALB + ECS or EC2

3.3 jQuery + Java

フロント：jQuery（FE/BE分離的だがSPAではない）
バック：Java（Spring等）がHTMLの一部またはJSONを返す
思想： ページ遷移ベースのWebアプリにjQueryで動的UI部分だけを追加したハイブリッド構成。SPAではなく、ページ単位でサーバがHTMLを返し、一部の操作をAJAXで処理する。
向いてるアーキテクチャ： レガシーなサーバサイドMVC構成。
向いてる用途： 古い社内システムの保守・段階的モダナイズの過渡期。

4. Ruby 系

思想： 「開発者の喜び（Matz）」「設定より規約（CoC）」「同じことを繰り返さない（DRY）」がRubyおよびRailsの根本思想。少ないコードで素早くプロダクトを作ることを優先する。スタートアップ文化と親和性が高い。

4.1 Ruby on Rails

伝統的にサーバサイドレンダリング型（MPA）（ERBテンプレートでサーバがHTMLを生成）
APIモード（rails new --api）にすれば → FE/BE分離型のBEとしても使用可能
フロントをReact/Vueにして、RailsをAPIサーバにする構成も多い
思想： MVCをフルスタックで実現し、CRUD操作に必要な雛形を自動生成するscaffoldが象徴するように「素早く動くものを作る」ことを最優先する。
向いてるアーキテクチャ： モノリスMVC構成（伝統的）。APIモードにすればSPA + REST API構成のBEとしても機能。
向いてる用途： スタートアップのMVP・受託Webサービス・プロトタイプ開発・SNS・ECサイト
デプロイ先：ALB + ECS or EC2 or Heroku

5. Go 系

思想： シンプルさ・高速性・並行処理の効率を重視。言語仕様を意図的に小さく保ち、コンパイル後の単一バイナリで動作する。「必要なものだけを書く」という哲学がAPIサーバ・マイクロサービスの分野で支持されている。

5.1 Go（Echo / Gin / Fiber 等）

基本はFE/BE分離型のBE（REST APIサーバ）
高速・軽量でAPIサーバとして優秀
テンプレートエンジンを使えばサーバサイドレンダリング型（MPA）も可能だが、稀
思想： Webフレームワーク自体は薄いラッパーに留め、ルーティング・ミドルウェアの組み合わせでAPIを構成する。重厚なフレームワーク機能より、シンプルで速いAPIサーバを作ることが目的。
向いてるアーキテクチャ： マイクロサービス・イベント駆動・高スループットが求められるAPIサーバ。コンテナ（ECS）との相性が良い。
向いてる用途： 大量リクエストを捌くAPIサーバ・マイクロサービスの1サービス・インフラツール・CLI
デプロイ先：ALB + ECS（バイナリが小さいためコンテナ向き）

6. Python 系

思想： 「読みやすさ・書きやすさ」を重視したPythonの思想がそのまま反映されている。Web開発だけでなく機械学習・データ分析との親和性が高く、AI/MLバックエンドのAPIサーバとして近年需要が急増している。

6.1 Django

伝統的にサーバサイドレンダリング型（MPA）（テンプレートエンジンでHTML生成）
DRF（Django REST Framework）を使えば → FE/BE分離型のBEとしても使用可能
思想： 「バッテリー同梱（Batteries Included）」という思想のもと、ORM・認証・管理画面・フォームなどが標準搭載。設定より規約を重視し、フルスタックWebアプリを少ない意思決定で構築できる。
向いてるアーキテクチャ： モノリスMVC（MVT）構成。DRFと組み合わせればAPI駆動構成のBEにも転用可能。
向いてる用途： コンテンツ管理システム・ECサイト・データ管理ツール・APIサーバ（DRF使用時）・AI/MLモデルを組み込んだWebサービス

6.2 FastAPI

FE/BE分離型のBE専用
思想： Pythonの型ヒントを活用して、高速なAPIサーバとOpenAPIドキュメントを自動生成する。「正確な型定義がそのままドキュメントになる」という設計。非同期処理（async/await）対応により高スループットを実現。
向いてるアーキテクチャ： API駆動構成。ML推論エンドポイント・マイクロサービスのAPIゲートウェイ的役割。
向いてる用途： AI/ML推論API・高速なREST API・LLMを組み込んだバックエンド・プロトタイプのAPIサーバ

6.3 Flask

軽量で両方可能（APIサーバとしてもMPAとしても使える）
思想： 「マイクロフレームワーク」を標榜し、最小限の機能だけを提供して残りは開発者が選択する。Djangoと対照的に「何も強制しない」自由度を重視。
向いてるアーキテクチャ： 小規模APIサーバ・プロトタイプ・シンプルなSSRアプリ。大規模になるほど設計の一貫性を保つ難度が上がる。
向いてる用途： 小規模Webアプリ・社内ツール・プロトタイプ・ML推論の簡易APIラッパー

7. OSS-CMS セルフホスト型

思想： OSSのCMS（コンテンツ管理システム）を自前のインフラ（AWS Lightsail / EC2 / レンタルサーバ等）にデプロイして使うパターン。AWSへのセルフホストが可能な点が、後述する8章のSaaS系との大きな違いである。本記事の分類軸ではサーバサイドレンダリング型（MPA） に該当する。

「ノーコード・ローコードでWebサイトを構築する」という思想を持つツール群であり、コードをほぼ書かずに非エンジニアが運用できることを目指して設計されている。プラグインとテーマによる拡張が前提。

中小商店のコーポレートサイト・LP・小規模ECの大多数は、これらのツールで構築されている。フレームワーク選定で悩む案件より、テンプレート選定で済む案件のほうが圧倒的多数であるという現実を反映する選択肢である。

7.1 主なツール

ツール	用途	特徴
WordPress	コーポレート・ブログ・ニュース全般	世界シェアNo.1のCMS、プラグイン・テーマが豊富
EC-CUBE	EC全般	日本国内シェアNo.1のOSS-EC、日本商習慣・決済対応に強み
Magento	中〜大規模EC	海外発の高機能OSS-EC、現在はAdobe Commerceが商用版
WooCommerce	EC（WordPress拡張）	WordPressにEC機能を追加するプラグイン
Drupal	コーポレート・大規模サイト	カスタマイズ性が高い、海外で根強い

7.2 デプロイ先

AWS Lightsail（最も手軽）：WordPressやEC-CUBEのテンプレートが用意されており数クリックで起動可能
AWS EC2 + RDS：自由度が高く、本格運用向け
レンタルサーバ（さくら、ロリポップ、エックスサーバー等）：低コストで運用可能

7.3 マネージドCMSとの関係

これらのOSSは、「マネージドCMS」としてSaaS化されたバージョンも存在する：

OSS	マネージド版（SaaS化）
WordPress	WordPress.com（Automattic社）、WP Engine、Kinsta
Magento	Adobe Commerce（旧Magento Commerce）
EC-CUBE	ec-cube.co（クラウド版）

マネージド版を選ぶ場合は、インフラ管理がサービス側になるため**本記事の対象外（次章のSaaS系に該当）**となる。「OSSをセルフホストするか、マネージド版を契約するか」は実務での重要な選定軸である。

7.4 向いてる用途

コーポレートサイト・ブログ・ニュースサイト
中小〜中規模EC
非エンジニアが更新するWebサイト
既存のテーマ・プラグインで要件を満たせるサイト
インフラを自社管理してカスタマイズしたいケース

7.5 向いてない用途

高度な業務ロジックを持つアプリ
高頻度で大量アクセスを捌くサービス
独自のユーザー体験を作り込むサービス
フルスクラッチで構築したほうが早いケース

8. SaaS系（本記事の対象外）

思想： インフラ・アプリ・データ全てがサービス提供側でマネージドされる製品群。利用者は月額契約してブラウザでサービスを使うだけで、AWS等の自前インフラへのデプロイ概念がない。本記事の分類軸（自前インフラへのデプロイ）からは外れるため対象外として扱うが、実務では極めて重要な選択肢である。

7章のOSS-CMSと違い、ソースコードのダウンロードや自社環境への移行は基本的にできない。「どのプラットフォームと心中するか」の選定が、企業のIT戦略を左右することになる。

8.1 SaaS系の分類

SaaSは内部の機能領域で多様に分かれているが、インフラ視点では全て同じ「サービス側マネージド」 である。本記事の分類軸ではどれも対象外として一括りで扱える。

カテゴリ	主要製品	主な用途
大手エンタープライズSaaS	Salesforce / SAP S/4HANA / Oracle Cloud / ServiceNow / Workday	大企業の基幹業務（CRM/ERP/ITSM/HR）
ローコード業務アプリ	Microsoft Power Apps / kintone / OutSystems / Mendix / AppSheet / Retool	社内業務アプリ・ワークフロー
BIツール	Tableau / Microsoft Power BI / Looker / Domo	データ可視化・ダッシュボード
ノーコードWebサイトビルダー	STUDIO / Wix / Webflow / Squarespace / ペライチ / Jimdo	中小商店のサイト・LP
ECプラットフォーム	Shopify / BASE / STORES / makeshop	小〜中規模EC
マネージドCMS	WordPress.com / Adobe Commerce / ec-cube.co	7章OSSのSaaS版
コラボレーション	Microsoft 365 / Google Workspace / Slack / Notion	グループウェア・情報共有

8.2 共通の特徴：インフラはブラックボックス

これらのサービスの内部実装はMPA/SPA様々だが、利用者から選択することはできない。サービス提供側がSEO・パフォーマンスを商品力として競争しているため、内部最適化は提供側の責任となる。

設定画面に「レンダリング方式：SPA/SSR/SSG」のような項目はなく、利用者の関心事ではないため提示されない。

8.3 重要な特徴：aPaaS（大手エンタープライズSaaS特有）

大手エンタープライズSaaSは、「出来合いのSaaS製品」だけでなく、その上で独自アプリを開発できるプラットフォーム（aPaaS：Application PaaS）を提供している点が特徴的である。これがノーコード系SaaSとの決定的な違いである。

SaaS	aPaaS
Salesforce	Lightning Platform（Apex言語、Lightning Web Components）
ServiceNow	Now Platform（JavaScript-based、UI Builder）
SAP	BTP（Business Technology Platform）、ABAP、Fiori

これにより、利用企業はSaaSの標準機能をベースに、自社固有のカスタマイズや新規アプリ開発が可能となる。ローコード業務アプリ（Power Apps / kintone等）も類似の特徴を持つ。

8.4 SaaSのアーキテクチャパターンと本記事の分類軸での位置付け

パターン	説明	本記事の分類軸での位置付け
A. 標準UI利用	SaaS提供の画面をそのまま使う	対象外（インフラ管理しない）
B. aPaaSでカスタムUI	SaaSのプラットフォーム上で独自UI開発	対象外（インフラはSaaS側）
C. Headless / API連携	フロントは自前でAWS/Vercel等にデプロイ、データはSaaS APIから取得	🔌（BE）相当
D. ハイブリッド埋め込み	自前サイトに部分的にSaaS画面を埋め込む	部分的に絡む

8.5 Headless / API連携パターン（本記事の文脈で重要）

パターンCは、フロントエンドを自前で開発しつつ、バックエンドの業務ロジックとデータをSaaSに任せる構成である。SIerアーキ・外資コンサル案件で頻出する。

[フロント：自前で開発、AWS or Vercel等にデプロイ]
React / Next.js / Vue 等
       ↓ API呼び出し
[バック：大手SaaS]
Salesforce REST API / GraphQL
SAP API（OData / REST）
ServiceNow REST API

構成例

B2B顧客ポータル：Next.js（Vercel） + Salesforce REST API
社内向けカスタム業務画面：React + ServiceNow API
基幹業務のフロント刷新：Vue + SAP BTP API

なぜこの構成が選ばれるか

既にSalesforce/SAP等を導入している企業で、標準UIのUXが古臭い問題を解決できる
データの一次管理はSaaSのままなので、業務プロセスを変えずにフロントだけ刷新できる
段階的モダナイズに向いている

8.6 Vercel + SaaS パターン

Headless / API連携パターンの中でも、特にフロントをVercelにホストする構成は、近年のWeb開発で鉄板パターンとなっている。

ユーザー
  ↓
Vercel CDN（ISRでキャッシュ）
  ↓
Next.js on Vercel
  ↓ API
SaaS（Salesforce / Contentful / Shopify / Auth0等）

代表的な組み合わせ

用途	構成
メディア・コーポレート	Vercel + Contentful / microCMS（ヘッドレスCMS）
EC	Vercel + Shopify Headless（ヘッドレスEC）
B2Bポータル	Vercel + Salesforce / HubSpot
認証分離	Vercel + Auth0 / Clerk

なぜVercelが選ばれるか

本記事「補足1：ISRについて」で述べた通り、AWSでISRをセルフホストすると構成が複雑になりがちだが、Vercelならマネージドで動作する。さらにデータ層をSaaSに切り出すことで、自前でDB・管理画面を構築する必要もない。「フロントキャッシュ問題」と「データ管理の手間」を両方マネージドに任せられるのが最大の利点である。

トレードオフ

SaaSへのロックイン
ライセンス料の積み上げ（SaaS分 + Vercel分）
Vercel ↔ SaaS API間の通信レイテンシ
データのオフショア保管に対するコンプライアンス対応

8.7 補足：AWS自身もSaaS的機能を提供している

「SaaSは別世界」と言いつつ、AWS自身も多くのSaaS的機能をマネージドサービスとして提供している。これらは厳密にはIaaS/PaaSの枠を超え、SaaSとIaaSの境界を曖昧にしている。

AWSサービス	該当するSaaS領域	外部SaaSの代替例
Amazon Connect	クラウドコンタクトセンター	Salesforce Service Cloud
Amazon QuickSight	BIツール	Tableau / Power BI
AWS WorkSpaces	VDI（仮想デスクトップ）	Citrix
Amazon Chime / WorkMail	Web会議・メール	Microsoft 365
Amazon Pinpoint	マーケティングオートメーション	Salesforce Marketing Cloud
AWS AppFlow	SaaS間データ連携（iPaaS）	Mulesoft / Boomi
AWS Amplify Studio	ローコード開発環境	Power Apps

これらはAWSアカウント内で完結するため、「自前インフラ」と「外部SaaS」の中間に位置する。SIerアーキ視点では、外部SaaS（Salesforce等）を選ぶか、AWS内マネージド（Connect等）を選ぶかは重要な判断軸となる。

例えば「コンタクトセンターを作りたい」という要件に対して：

選択肢A：Salesforce Service Cloud（外部SaaS、CRM連携が強い）
選択肢B：Amazon Connect（AWS内マネージド、AWS他サービスとの連携が容易）
選択肢C：自前構築（フレームワーク + ECS、フルカスタマイズ可能）

この3択をフラットに評価できるのがアーキテクトの視点である。

8.8 大手SaaSとAWSの関係

大手SaaSはAWSと連携することが多い。代表的な構成パターン：

フロント：Next.js等でAWS（CloudFront + S3 or ALB + ECS）にデプロイ
バック：Salesforce / SAPのREST APIを呼ぶ
データ連携：AWS AppFlow、AWS EventBridge、Amazon Connect等でSaaSとAWSをつなぐ
認証：Amazon Cognito + Salesforce SSO、Microsoft Entra ID連携

外資コンサル/SIerの大規模案件では、AWS + 大手SaaSのハイブリッド構成が頻出である。

8.9 アーキテクトとしての判断軸

「Reactで作るかWordPressで作るか」より前に、「そもそもSaaSの世界で足りないか？」「AWS内マネージドで足りないか？」を問うのがアーキテクトの視点である。

状況	適切な選択肢
大企業の顧客管理を刷新したい	Salesforce / Microsoft Dynamics（大手SaaS）
社内の申請ワークフローを作りたい	Power Apps / kintone / ServiceNow（ローコード業務アプリ）
データの可視化ダッシュボードがほしい	Tableau / Power BI / Amazon QuickSight
コンタクトセンターを作りたい	Salesforce Service Cloud / Amazon Connect
中小商店の販促サイトをすぐ立ち上げたい	STUDIO / Wix / ペライチ
小規模ECを始めたい	Shopify / BASE / STORES
ブログ機能つきコーポレートサイトを自社運用したい	OSS-CMS（WordPress on Lightsail） — 7章
日本国内向けECで決済・配送を細かくカスタマイズしたい	OSS-CMS（EC-CUBE） — 7章
グローバル展開する高速ブランドEC	Vercel + Shopify Headless
こだわりのUI/UXで業務システムを刷新したい	フルスクラッチ（前述各章）

STUDIOで30万円・月額数千円で済むサイトに、フルスクラッチで500万円かける意思決定はアンチパターンである。顧客にとって最適な選択肢を提示できるのがアーキテクトの価値である。

8.10 向いてる用途

大企業の基幹業務システム（CRM・ERP・ITSM・HR）
外資系企業のグローバル標準導入案件
業界標準の業務プロセスを採用したい場合
中小商店のコーポレートサイト・LP・小規模EC
短期間・低予算で立ち上げたいケース
インフラ管理コストを最小化したいケース

8.11 向いてない用途

業界標準と大きく異なる独自プロセスを持つ業務
データを自社で完全管理したいケース
独自の業務ロジックを実装するサービス
ライセンス料がペイしない小規模案件（大手SaaSの場合）
B2C向けの一般消費者向けサービス（大手SaaSの場合）

【３章】まとめ

フレームワーク	条件	FE/BE分離	SSR/MPA	備考
React（素）	—	✅（FE）	❌	SPA専用
Next.js	SSGモード	✅（FE）	❌	CDN配信（SSG）
Next.js	SSRモード	❌	✅（SSR）	モダンSSR。サーバ必須
Next.js	ISR	❌	✅（SSR）	SSGの拡張だがサーバ必須
Next.js	混在モード	✅（FE）	✅（SSR）	両方対応
React Router（v7）	ライブラリモード	✅（FE）	❌	従来のルーティング
React Router（v7）	フレームワークモード（SSR有効時）	✅（FE）	✅（SSR）	旧Remix相当
Astro	通常（静的）	✅（FE）	❌	アイランドアーキテクチャ（SSG）
Astro	SSRモード / Server Islands利用時	✅（FE）	✅（SSR）	—
Vue.js（素）	—	✅（FE）	❌	SPA専用
Nuxt.js	SSGモード	✅（FE）	❌	CDN配信（SSG）
Nuxt.js	SSRモード	❌	✅（SSR）	モダンSSR。サーバ必須
Nuxt.js	混在モード	✅（FE）	✅（SSR）	Next.js相当
Angular	通常	✅（FE）	❌	SPA
Angular	@angular/ssr 使用時	✅（FE）	✅（SSR）	旧Angular Universal
NestJS / Express等	—	🔌（BE）	❌	TS/JSのBE専用
WebAssembly系（Blazor/Yew/Leptos）	—	✅（FE）	❌	Wasm経由でJS以外の言語でFE構築可能
PHP（素）	—	❌	☑（MPA）	テンプレートでHTML生成
Laravel	通常	❌	☑（MPA）	Bladeテンプレート
Laravel	APIモード使用時	🔌（BE）	☑（MPA）	両方対応
Spring MVC	—	❌	☑（MPA）	旧来型
Spring Boot	通常（REST API）	🔌（BE）	❌	Spring MVCを内包
Spring Boot	Thymeleaf等使用時	🔌（BE）	☑（MPA）	Spring MVC的な構成
jQuery + Java	—	△	△	古い構成・混在
Ruby on Rails	通常	❌	☑（MPA）	ERBテンプレート
Ruby on Rails	APIモード使用時	🔌（BE）	☑（MPA）	—
Go（Echo / Gin 等）	通常	🔌（BE）	❌	—
Go（Echo / Gin 等）	テンプレートエンジン使用時	🔌（BE）	△	稀
Django	通常	❌	☑（MPA）	Djangoテンプレート
Django	DRF使用時	🔌（BE）	☑（MPA）	—
FastAPI	—	🔌（BE）	❌	API専用
Flask	—	🔌（BE）	☑（MPA）	軽量・両方対応
WordPress（セルフホスト）	—	❌	☑（MPA）	Lightsail等、世界シェアNo.1
EC-CUBE（セルフホスト）	—	❌	☑（MPA）	日本国内シェアNo.1のOSS-EC
Magento（セルフホスト）	—	❌	☑（MPA）	海外発の高機能OSS-EC
大手エンタープライズSaaS（Salesforce / SAP / ServiceNow / Workday等）	標準UI / aPaaS利用	❌	❌	対象外（インフラ自前管理しない）
大手エンタープライズSaaS（Salesforce / SAP / ServiceNow等）	Headless API連携	🔌（BE）	❌	フロントは別途JS/TS系で構築
ローコード業務アプリ（Power Apps / kintone / OutSystems等）	—	❌	❌	対象外（インフラ自前管理しない）
BIツール（Tableau / Power BI / Looker等）	—	❌	❌	対象外（データ可視化特化のSaaS）
ノーコードWebサイト（STUDIO / Wix / Webflow等）	—	❌	❌	対象外（インフラ自前管理しない）
ECプラットフォーム（Shopify / BASE / STORES等）	—	❌	❌	対象外（インフラ自前管理しない）
マネージドCMS（WordPress.com / Adobe Commerce等）	—	❌	❌	対象外（OSSのSaaS版）

凡例

✅（FE） : FE/BE分離型のフロントエンド側を担える（SPA / SSGとしてブラウザ上でUIを構築）

✅（SSR） : モダンSSR対応（React/Vue等のコンポーネントをサーバで実行。SPA的なUXを維持）

☑（MPA） : 従来型MPA対応（テンプレートエンジンでHTML生成。ページ遷移のたびにサーバからHTML取得）

🔌（BE） : FE/BE分離型のバックエンド側としてのみ対応（JSON APIを返す。フロントは別途JS系フレームワークが必要）

△ : 条件付き・限定的に対応

❌ : 非対応（または一般的でない）

1. FE/BE分離型のFEを担えるのはJS/TSだけ

FE/BE分離型（パターン①）のフロントエンド（ブラウザ上でUIを構築する側）を担えるのは、JavaScript / TypeScript 系のフレームワークのみである。これはブラウザが直接実行できる言語がJavaScriptだけであることに起因する。※WebAssembly系を除く

PHP・Java・Ruby・Go・Python系のフレームワークがFE/BE分離型に対応する場合、それはすべてバックエンド（API側）としての参加（🔌（BE）） であり、フロント側には別途React・Vue等のJS系フレームワークが必要になる。

2. モダンSSR（✅（SSR））もJS/TSが必須

モダンSSRとは、React/Vue等のコンポーネントをサーバ上で実行してHTMLを生成し、ブラウザに届いた後にJavaScriptが引き継いでSPA的に動作する（ハイドレーション）仕組みである。これはReact/VueというブラウザUI向けのライブラリが前提にあって初めて成り立つため、モダンSSR（✅（SSR））を実現するにはJS/TSが必須となる。

Java（Spring Boot）やRuby（Rails）等のテンプレートエンジン（Thymeleaf・ERB等）で生成したHTMLは、ブラウザに届いた後にJSが引き継ぐ仕組みを持っていないため、これらは常に☑（MPA）に分類される。

3. 従来型言語がモダンなUI体験を提供したい場合の選択肢

PHP・Java・Ruby・Go・Python等の従来型言語でモダンなUI体験を実現したい場合、主な選択肢は以下の通りである。

FE/BE分離型のBE（🔌）として参加する：RailsやLaravelをAPIモードにし、フロントはReact/Vue等で別途構築する。FE/BE完全分離の構成。最も一般的な選択肢。
Inertia.js等のハイブリッドアプローチ：Laravel/Railsのサーバサイドルーティングとコントローラをそのまま使いつつ、View層だけをReact/Vue/Svelteに差し替える。API設計が不要でMPA的な開発フローのまま、SPA的なUXを実現できる。

4. FE/BE分離型とSSR/MPA型は併用されることもある

FE/BE分離型（パターン①）とサーバサイドレンダリング型（パターン②：SSR/MPA）は排他的な選択ではなく、同じサービス内で併用されることも実際にはよくある。 主に以下のようなケースで発生する。

段階的モダナイズ：既存のRails/Laravel/SpringのMPAアプリに、一部の画面から段階的にReact SPAを導入していく過渡的な構成。大規模サービスの移行では一般的に発生する。
画面特性に応じた使い分け：LP・ヘルプページ等はMPA（SEO重視・更新が簡単）、ログイン後のダッシュボードや管理画面はSPA（操作性重視）という構成。超大規模エンタープライズアプリでは画面ごとに最適なパターンを選択することも珍しくない。

5. インフラを持つ世界と、SaaSの別世界

本記事の表は、Webアプリの世界が2つの世界に分かれていることを示している。

世界A：インフラを自前管理する世界（本記事の対象）

フレームワークを選び、AWS等にデプロイする
✅（FE）/ ✅（SSR）/ ☑（MPA）/ 🔌（BE）の軸で整理可能
対象：JS/TS系、PHP系、Java系、Ruby系、Go系、Python系、OSS-CMSセルフホスト

世界B：SaaSの世界（本記事の対象外）

インフラ・アプリ・データ全てがサービス提供側
月額契約してブラウザで使うだけ
レンダリング方式は選択不可
対象：大手SaaS（Salesforce / SAP / ServiceNow等）、SaaSマネージド型（Shopify / Wix / STUDIO等）

両者は前提が違う別世界である。ただし、世界の境界は完全な二元論ではない。

大手SaaSはHeadless API連携という形で世界Aに再登場する（🔌（BE）として）。
Vercel + SaaSパターンがその代表例である。
AWS自身もSaaS的機能をマネージドサービスとして提供している（Amazon Connect、
QuickSight、WorkSpaces等）。これらは「自前インフラ」と「外部SaaS」の中間に位置する。

「Reactで作るかWordPressで作るか」を論じる前に、「そもそもSaaSの世界で足りないか」
「AWS内マネージドで足りないか」を問うのが、最適な選定への第一歩である。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up