Webサーバー、WAS、そしてフロントエンドの境界はどこにあるのか？

「Webは静的、WASは動的」と覚えたあの公式、今日も有効だろうか？

この記事で扱うこと

• WebサーバーとWASの伝統的な役割分担
• Frontend/BackendはWASのサブカテゴリなのか？
• 現代のアーキテクチャでFrontendもWASを持つようになった理由
• 用語の混乱を減らすための思考の枠組み

なぜこのテーマは混乱しやすいのか？

新米開発者、さらには経験者でさえ、一度は答えに迷う質問がある。

Next.jsサーバーはWebサーバーですか、それともWASですか？

ReactアプリはフロントエンドだからWASではないですよね？

SSRとWASは何が違うのですか？

問題は、私たちが学んだ教科書が2000年代初頭のJavaウェブアーキテクチャを基準に書かれている点だ。当時はFrontendとBackendがほぼ同じWAS内で動作していた。しかし、今は完全に異なる世界になった。

伝統的観点 — Webサーバー vs WAS

まず、本来の定義から明確に整理しよう。

Webサーバーの役割

静的コンテンツを応答するサーバーだ。HTML、CSS、JavaScriptファイル、画像、フォントなど、リクエストが来ても内容が変わらないファイルをそのまま返す。

代表的な製品はNginx、Apache HTTPDで、特徴は以下の通りだ。

• 速い（ディスクからファイルを読み込んで即座に応答）
• 同時接続数が多い
• ビジネスロジックを実行しない

WASの役割

動的コンテンツを生成するサーバーだ。ユーザーのリクエストに応じてDBを照会し、条件文を実行し、結果を組み合わせて応答を作成する。

代表的な製品はTomcat、JBoss/WildFly、WebLogicで、特徴は以下の通りだ。

• ビジネスロジック（Service Layer）の実行
• DBコネクションプール、トランザクション管理
• セッション、認証、権限処理

ここまでが「本来の定義」だ。そしてこの時点では、Frontend/BackendはWAS内部で起こる階層区分だった。JSPやServletでHTMLを生成すればFrontend、Service/DAOでDBからデータを加工すればBackend。どちらも同じTomcat内で動作していた。

では、WASはFrontendとBackendに分かれるのか？

この点が核心的な質問だ。結論から言えば — 「以前はWAS内部の階層区分だったが、今はWAS自体が2種類に分化した」 が最も正確な答えだ。

なぜ分化が起こったのか？

2010年代半ばから二つのことが同時に起こった。

一つ目はSPA（Single Page Application）の台頭だ。React、Vue、Angularが登場し、フロントエンドがブラウザで独立して動作するようになった。サーバーはHTMLを生成せず、JSON APIだけを提供し、ブラウザが自分で画面を描画する。

二つ目はSSR（Server-Side Rendering）の再登場だ。SPAのSEO、初期ロード問題を解決するために、Node.jsベースのNext.js、Nuxt.jsのようなフレームワークが再びサーバーでHTMLを生成するようになった。

この二つ目の時点で「フロントエンド専用WAS」という概念が新たに生まれた。

現代の3層区分

区分	役割	代表技術
Web Server	静的リソースの提供	Nginx, Apache, CDN
Frontend WAS	SSRによるHTML動的生成	Next.js, Nuxt.js, Remix
Backend WAS	ビジネスロジック + DB	Spring Boot, Django, Rails

つまり、あなたが尋ねた「WASをFrontendとBackendに区分できるか」という質問は、現代的な意味で「WASの範疇内に2種類のサーバーが生まれた」と理解するのが最も正確だ。WASの内部が二つに分かれたのではなく、WASという名前で呼ばれるサーバーの種類が二つに増えたのだ。

簡単な比喩 — レストラン

三つのサーバーをレストランに例えると理解が早い。

• Webサーバー = 入り口に貼られたメニュー板。変わらない情報を素早く見せる。
• Frontend WAS(SSR) = ウェイター。客の注文を受け、厨房に伝え、注文書をきれいに整理して返す。（UI組み立て担当）
• Backend WAS(API) = 厨房。実際の料理（ビジネスロジック）を行い、材料（DB）を取り出す。

伝統的なアーキテクチャでは、ウェイターと厨房は一つの空間に隣接していた。今は両者が分離され、独立して働く。ウェイターがいないレストラン（SPA + API専用構造）も多い。

実際の構成例

現代のクラウドアーキテクチャでは、一つのサービスの構成は通常このように描かれる。

[Browser]
    ↓ HTTPS
[CloudFront / Nginx]           ← Web Server (정적 자원)
    ↓
[Next.js on Node.js]           ← Frontend WAS (SSR)
    ↓ REST / GraphQL
[Spring Boot on Tomcat]        ← Backend WAS (API)
    ↓ JDBC
[PostgreSQL / MySQL]           ← Database

ここで注目すべき点は、各階層が異なるインスタンスまたはコンテナで動作するということだ。Frontend WASが停止してもBackend WASは生きており、その逆もまた然りだ。これがMSA（Microservices Architecture）時代の柔軟性である。

⚠️ よくある誤解三つ

一つ目、「Reactアプリ自体がWASだ」 — 違う。Reactアプリはブラウザで実行されるJavaScriptバンドルだ。Webpack、Viteでビルドされた静的リソースがNginxで提供されることが多い。この時、FrontendはWebサーバーの後ろに置かれた静的ファイルに過ぎず、WASではない。

二つ目、「Next.jsはWebサーバーだ」 — 違う。Next.jsがSSRモードで動作する時は、リクエストごとに動的にHTMLを生成するため、明らかにWASだ。ただし、Static Exportモードでビルドすれば静的ファイルしか生成されないため、その成果物はWebサーバーに置いてもよい。

三つ目、「NginxがAPIロジックも処理する」 — 誤解だ。NginxはリバースプロキシとしてリクエストをWASに転送するだけで、それ自体でビジネスロジックを実行しない。ロジックは背後にあるWASが処理する。

✅ まとめ

• 原則は依然として有効だ: Webサーバー = 静的、WAS = 動的という基本公式は変わっていない。
• WASの外延が広がった: 現代ではWASがFrontend（SSR）層とBackend（API）層の2種類に分かれることがある。
• 判別基準: 「リクエストごとにサーバーでコードが実行されるか」を基準に判断すれば明確だ。
• 実務的観点: 自分のサービスアーキテクチャを描く際、各構成要素をWebサーバー / Frontend WAS / Backend WAS / DBの4つの枠のどこに置くべきか当てはめてみればよい。

結局、用語は時代とともに外延が広がるものだ。教科書の定義に固執して争うよりも、各階層が静的か動的か、クライアントコードかサーバーコードかを区別する思考の枠組みを持つ方がはるかに実用的だ。

---