バックエンドが「頭脳」なら、フロントは「顔」。あなたが実際に目にする画面を用意して返すのがフロントサーバです。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
レストランのホール係を思い浮かべてください。注文を受け、料理（データ）は厨房（バックエンド）に頼み、盛り付けてテーブルに運ぶ——お客さんが接するのはこの人です。
フロントサーバは、見た目（HTML・CSS・JS ※1） を組み立てて返します。中身のデータは自分では作らず、バックエンドに頼みます。
登場人物メモ:
- ※1 HTML・CSS・JS — HTML（骨組み）・CSS（見た目の装飾）・JS（動き）。この3つで画面ができる
- ※2 静的ファイル — 画像・CSS・JSなど、誰に対しても同じもの
この部分をもっと深く（中級）
「フロント」と一口に言っても、実体は2種類が組み合わさっています。
- 静的配信（Nginx・CDNなど）— 変わらないファイルをそのまま返す。速く、負荷が軽い
- アプリサーバ（SSR）（Next.js など）— リクエストごとにHTMLを生成する
登場人物メモ:
- ※1 SSR／CSR／SSG — サーバ側生成／クライアント側生成／ビルド時生成
- ※2 ハイドレーション — サーバ生成のHTMLに、ブラウザでJSを結びつけて操作可能にする工程
仕事の流れ
- ブラウザから「このページください」を受け取る
- 画面の器（HTML）を用意する
- 中身のデータが要るなら、バックエンドに頼む（API）
- 受け取ったデータを画面にはめ込み、組み立てて返す
- ブラウザがそれを描画 → あなたが見る
この部分をもっと深く（中級）
- 入口（ロードバランサ／リバースプロキシ）経由でリクエストが届く
- 静的アセット（画像・CSS・JS）は CDN／静的配信から返す（キャッシュが効く）
- 動的ページは SSR でHTMLを生成し、必要なデータは API から取得する
- ブラウザで ハイドレーション（HTMLにJSを載せて操作可能にする）
静的と動的
- 静的配信 — 誰に見せても同じもの（画像・CSS・JS）は、そのまま配る。速い
- 動的（SSR） — 人によって違う画面（ログイン後など）は、その場で組み立てて返す
「トップページの見た目」は静的、「マイページ」は動的、と混ざっているのが普通です。
この部分をもっと深く（中級）
- CSR（クライアント側描画）— 最初は空のHTML＋JSで描く。初期表示は遅めだが操作は軽快
- SSR（サーバ側描画）— 初期表示が速く、SEOに強い。サーバ負荷は上がる
- SSG（ビルド時生成）— あらかじめHTMLを作っておく。最速だが更新に弱い
アニメーション『HTMLをどこで組み立てるか』を開く
静的アセットはハッシュ付きファイル名＋長期キャッシュにして、変更時だけ新しいファイル名で配るのが定石です。
なぜフロントだけじゃダメ？
「フロントだけで全部やればいいのでは？」と思うかもしれません。でも、それだと困ることが3つあります。
- 手元は改ざんできる — ブラウザはあなたのPCの中。中身は見えるし、書き換えられます。もし「支払い済みか」をフロントで判断したら、誰でも書き換えて「済み」にできてしまう。だから大事な判断はサーバ（バック）でやる
- みんなで同じデータを見たい — 在庫や残高は、全員が同じ正しい値を見る必要がある。各自の手元で持つとバラバラになる。だからDBという「1つの正しい置き場」に集める
- 秘密が置けない — DBの鍵やAPIキーは、中身が見えるフロントには置けない。だから秘密に触れるのはサーバ側だけ
つまりフロントは「顔」に徹し、判断とデータは信じられない場所（手元）ではなく、守られた場所（バック）で扱う。これがフロントとバックを分ける理由です。
この部分をもっと深く（中級）
フロントとバックを分ける核心は 信頼境界（trust boundary） です。手元（クライアント）は信用できない、という前提から設計します。
- クライアントは信頼しない — ブラウザから来る値も、そこで走るコードも、すべて改ざん可能。フロントのバリデーションは「親切機能（UX）」であって防御ではない。最終的な検証・認可はバックで必ずやり直す
- 単一の真実（source of truth） — 在庫・残高などの正はDBが唯一。クライアントの計算結果は信用しない
- 秘密情報の隔離 — 資格情報・APIキー・署名鍵はサーバ側だけ。ブラウザに配られるコードは全部読まれる前提
- 関心の分離とスケール — 配信（CDNで剥がせる）と処理（水平スケール）は最適化の方向が違うので、分けたほうが伸ばしやすい
合言葉は「フロントでやったチェックは、サーバでもう一度やる」。二度手間に見えて、これが基本です。
見た目（フロント）と中身（バック）を分け、境界を API（JSON）で薄くつなぐ——この構図が分離の基本形です。
アニメーション『フロントとバックの分離』を開く
⚠️ うまくいかないとき
- 見た目は出るが中身が空 — バックエンドやDBが応答していない（顔はあるが料理が来ない）
- レイアウトが崩れる — CSSやJSが読み込めていない
- 真っ白 — JSのエラーで描画が止まった
この部分をもっと深く（中級）
- TTFB（最初の1バイトまで）が遅い — SSRが重い → キャッシュ／SSGに寄せる
- ハイドレーションのズレ — サーバ生成とクライアントの状態が食い違い、画面が乱れる
- CLS（表示中のガタつき） — 画像や広告の高さを先に確保していない
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. フロントサーバの主な役割はどれ？
問2. 画面をつくる HTML・CSS・JS のうち、「動き」を担当するのはどれ？
問3. 「ログイン後の自分だけの画面」を、その場で組み立てて返す方式はどれ？
問4. 「誰に見せても同じもの（画像・CSS・JSなど）」をそのまま配るのはどれ？
問5. 「支払い済みか」などの大事な判断をフロント（ブラウザ側）だけでやってはいけない理由は？
問6. 「見た目（画面）は出るのに、中身のデータが空」のとき、まず疑うのはどれ？
問7. 画面をつくる HTML・CSS・JS のうち、画面の「骨組み」を作るものを英字4文字で答えてください。
問8. フロント（顔）が、中身のデータを頼むためにバックエンドとやり取りする窓口を英字3文字で答えてください。