本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
フロントエンドは「ユーザーが触れる唯一の場所」バックエンドが完璧でもUIで躓けば「使われないシステム」になります。本記事では独立領域として扱う理由、レンダリング方式の分類、主要フレームワークの位置づけ、ページ種別×構成の段階表、AI時代の恩恵構造まで俯瞰します。
このカテゴリの他の記事
ユーザーに届く唯一のレイヤー
開発者はつい業務要件や非機能要件を満たすためにバックエンドの設計へ意識を向けがちですが、一般ユーザー向けのプロダクトでは「UI/UXの重要性は事業成果に直結するレベル」で大きくなります。フロントエンドを「見た目の領域」として軽視するのは、事業価値を軽視しているのと同じことです。
どれだけシステムが機能的でも、ユーザーに使われないシステムは存在しないのと同じです。
なぜ独立したアーキテクチャとして扱うか
① 技術スタックが独自進化している
フロントエンド専用のフレームワーク（React・Vue.js・Angular）・ビルドツール（Vite・Turbopack）・状態管理（Redux・Zustand）など、バックエンドとは「異なる技術文化」が形成されています。
② UX要件が機能要件と直交する
ページ表示速度（LCP、Largest Contentful Paint）・入力応答性（INP、Interaction to Next Paint）・レイアウトの安定性（CLS、Cumulative Layout Shift）など、UI特有の非機能要件はバックエンドからは見えません。
③ 変更頻度と影響範囲が異なる
ビジネスロジックよりもはるかに頻繁に変わり、小さな変更がユーザー体験に直撃します。
レンダリング方式の分類
flowchart LR
USER([ユーザー]) --> EDGE[CDN/Edge]
EDGE --> RENDER{レンダリング方式}
RENDER -->|画面遷移ごと<br/>サーバ生成| MPA[MPA<br/>WordPress/Rails]
RENDER -->|1HTMLでJS切替| SPA[SPA<br/>React CSR/Vue]
RENDER -->|リクエスト毎<br/>サーバ生成| SSR[SSR<br/>Next.js/Nuxt]
RENDER -->|ビルド時静的生成| SSG[SSG<br/>Astro/Next静的]
RENDER -->|静的+部分的再生成| ISR[ISR<br/>Next.js]
classDef user fill:#fef3c7,stroke:#d97706;
classDef edge fill:#f0f9ff,stroke:#0369a1;
classDef classic fill:#f1f5f9,stroke:#64748b;
classDef modern fill:#dbeafe,stroke:#2563eb;
classDef static fill:#dcfce7,stroke:#16a34a;
class USER user;
class EDGE edge;
class MPA classic;
class SPA,SSR modern;
class SSG,ISR static;| 方式 | 概要 | 代表例 |
|---|---|---|
| MPA（Multi Page App） | 画面遷移ごとにサーバーでHTML生成 | WordPress・Rails伝統 |
| SPA（Single Page App） | 1つのHTMLにJSで画面を切り替える | React CSR・Vue.js |
| SSR | サーバー側で都度HTMLを生成 | Next.js・Nuxt.js |
| SSG | ビルド時にHTMLを生成 | Astro・Next.js Static |
| ISR（Incremental Static Regeneration） | SSRとSSGのハイブリッド | Next.js |
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
レンダリング・技術スタック
| 項目 | 選択肢の例 |
|---|---|
| ホスティング | CDN・エッジコンピューティング |
| 画面表示とレンダリング方式 | MPA・SPA・SSR・CSR・SSG |
| 状態管理 | Context・Redux・Zustand・Jotai |
| CSS | CSS Modules・Tailwind・CSS-in-JS |
| フレームワーク | React・Vue.js・Angular・Svelte |
| BFF（Backend For Frontend） | GraphQL・REST・tRPC（TypeScriptでAPI型共有する仕組み） |
ルーティング・認証・アクセシビリティ
| 項目 | 選択肢の例 |
|---|---|
| ルーティング | ファイルベース / 定義ベース |
| 認証・認可基盤 | Cookie・LocalStorage・Refresh Token（再ログインせず新しいアクセストークンを取得するための長命トークン） |
| 命名規則 | BEM（Block Element Modifier、CSSクラス命名規則）・kebab-case等 |
| ディレクトリ構造 | feature-based / layer-based |
| URLパス | REST的・階層・クエリ設計 |
| アクセシビリティ | WCAG（Web Content Accessibility Guidelines）準拠・ARIA（Accessible Rich Internet Applications） |
国際化・SEO・セキュリティ・パフォーマンス
| 項目 | 選択肢の例 |
|---|---|
| 多言語対応（i18n） | next-intl・react-i18next |
| サポート環境 | ブラウザ / OS / 画面サイズの範囲 |
| SEO | メタタグ・OGP（Open Graph Protocol）・構造化データ・sitemap |
| セキュリティ | CSP（Content Security Policy）・XSS対策・CSRF対策 |
| エラーハンドリング | バリデーション・Error Boundary |
| パフォーマンス | Core Web Vitals（LCP・INP・CLS）・画像最適化 |
主要フレームワークの位置づけ
| FW | 強み | 向くケース |
|---|---|---|
| React | エコシステム最大・求人最多 | 中〜大規模WEBアプリ全般 |
| Vue.js | 学習コストが低い・HTML寄り | 中小規模・段階導入 |
| Angular | フル機能・TypeScript標準 | 大企業・堅牢性重視 |
| Svelte | 軽量・ランタイムなし | パフォーマンス重視・小規模 |
| Next.js | Reactベース・SSR/SSG対応 | SEO重視のWEBアプリ |
| Astro | コンテンツ重視・高速SSG | ブログ・LP・ドキュメント |
「モダンだから」で壊れた検索流入（業界事例）
あるメディアサイトのリニューアル案件で、「モダンだから」という理由だけで「全ページを React CSR（SPA）で作り直し」、リリース後3ヶ月で検索流入が半分になった、という事例があります。原因はシンプルで、OGPとmetaタグがJS実行後にしかHTMLに入らず、検索クローラーとSNSシェアのクローラーが「空のHTMLを読んでしまっていた」からです。サムネイル画像も出ず、シェアされても誰もクリックしない、というのが被害の構造でした。
2017年頃、個人ブログを勢いでSPAにして半年後にGoogle Search Consoleを開いたら検索流入が目に見えて減っていて冷や汗をかいた、という体験談もよく聞きます。当時はAstroのようなSSGフレームワークがまだ成熟していなかった時期で、結局WordPressに戻した、というのがよくあるオチです。
技術選定は「流行っているから」「モダンだから」で決めると、後からUXと事業指標のダブルで殴られます。特にコンテンツ中心のサイト（ブログ・LP・メディア）をSPAで作るのは典型的な地雷で、SEOと初回表示が致命的に弱くなる。ページ単位で方式を使い分ける（記事はSSG、管理画面はSPA、など）のが現代の本命で、「全部SPA」も「全部SSR」も雑な選定の代表例です。
「モダン＝正解」ではない。用途ごとに方式を選ぶのがフロントエンド設計の基本です。
ページ種別×構成の段階表
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
フロントエンドは「1サイト=1方式」が破綻の元なので、「ページ種別で方式を使い分ける」のが定石です。
| ページ種別 | レンダリング方式 | ホスティング | 状態管理 | Core Web Vitals |
|---|---|---|---|---|
| ブログ・ドキュメント | SSG（Astro） | Cloudflare Pages | useState | LCP < 2秒 |
| LP・マーケティング | SSG | Vercel / Netlify | useState | LCP < 2.5秒 |
| EC商品詳細 | ISR（60〜300秒） | Vercel | Zustand + TanStack Query | LCP < 2.5秒 |
| SaaSダッシュボード | CSR | Vercel / 自社CDN | Zustand + TanStack Query | INP < 200ms |
| ログイン必須の管理画面 | CSR | 自社CDN | Zustand + TanStack Query | INP < 200ms |
| ニュース・メディア | ISR + Streaming SSR | Vercel | TanStack Query | LCP < 2.5秒 |
Core Web VitalsのGood圏内（LCP < 2.5秒、INP < 200ms、CLS < 0.1）が Google SEO の判定基準です。「75%のページビューがGood圏内」にあるかが評価軸です。
「全ページSSR」は時限爆弾。Vercel関数実行枠を使い切る定番事故になります。Static First で設計します。
フロントエンド全体の鬼門
各論記事で触れた禁じ手のうち、フロントエンドアーキテクチャレベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| SEO必須サイトをCSRのみで構築 | JS実行が数日〜数週間遅延、検索流入壊滅 |
| JWTをlocalStorageに保存 | XSS一撃で全員分漏洩の地雷、httpOnly Cookie 必須 |
| 素のReactでルーティング・SSR自作 | Next.js / Astro を使わない理由がない |
| Tailwindを設定なしで使う | Design Tokenが効かず、色・余白のブレ |
| 画像を元サイズで配信 | LCP悪化の定番、Next/Imageで自動変換 |
| CSS-in-JSをRSC環境で新規採用 | styled-componentsは2024年メンテ入り |
フロントで user.role === 'admin' だけで認可 | F12で書き換え可能、サーバ側認可必須 |
| 同じ事実を2箇所に持つ（items と itemCount） | 片方が必ず嘘になる、派生状態は計算 |
| フォームを10個超useState | React Hook Form で解決 |
| WCAG 2.2 AA を目視だけでチェック | axe-core + LighthouseをCIに組込 |
フロントエンドはユーザーに届く唯一のレイヤーです。Core Web Vitals を業務要件として扱います。
AI時代の視点
AI駆動開発（バイブコーディング）が前提になると、フロントエンドは「AIがUIを直接書ける領域」として劇的に恩恵を受けます。v0・Bolt・Lovable などのAIツールがReact/Tailwind/shadcnのコードを即座に生成できる時代で、主流の技術スタックを選ぶほどAIの生成精度が上がります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| React + Tailwind + shadcn/ui（コピペ型の再利用UIコンポーネント集）（主流） | 独自UI実装・内製デザインシステム |
| Next.js / Astro（成熟フレームワーク） | ニッチ・新興フレームワーク |
| 型安全（TypeScript + Zod（スキーマ検証ライブラリ）等） | 素のJavaScript |
| サーバコンポーネント・ファイルベースルーティング | 独自ルーティング・複雑な状態管理 |
UI/UX設計はAIが得意な領域ですが、「ブランディング・ユーザー文脈・アクセシビリティ」は人間の判断が必要です。AIはパターンを量産できますが、「なぜこの画面なのか」を決めるのは人間の仕事です。
よくある勘違い
- どのフレームワークでも同じ → React・Vue・Svelte・Astroは思想が違い、「チームスキルと用途との相性」で生産性が数倍変わります。流行だけで決めると人材確保と保守性で後悔します
- SPAで作れば全部解決 → SPAは操作感に優れる一方、SEOと初回表示が弱点。ブログやLPにSPAを使うと検索流入が壊滅します。ページ単位で方式を使い分けるのが現代の本命
- CSSは後回しで良い → CSS設計は大規模化で最も差が出る領域で、後回しにすると「クラス名の衝突・スタイルの重複で改修コストが爆発」します
- フロントは簡単だから新人の練習台 → LCP・INP・CLS・アクセシビリティ・XSS対策など「専門知識の塊」軽く扱うと本番でUXが壊れます
最終的な判断の仕方
フロントエンドアーキテクチャは「ユーザーに直接触れる唯一のレイヤー」であり、どれだけバックエンドが堅牢でも、UI/UXが粗ければ使われないシステムになります。選定の核は「機能要件」ではなく「どんなユーザー体験を提供したいか」から逆算すること。
SPAかSSRかSSGか、Context か Redux か、Tailwind か CSS Modules か。技術単体の優劣ではなく、LCP・INP・CLSといったユーザー体験の指標が「業務要件の一部として」扱われる必要があります。フロントエンドは変更頻度が高い領域で、「小さな変更がユーザーに直撃する」ため、変更しやすさと安定性の両立が常に問われます。
決定的な軸は「AIの得意領域に寄せる」ことです。v0・Bolt・Lovable・Cursor・Claude Code など、フロントエンドコードを直接生成するAIツールが実用段階に入り、React + TypeScript + Tailwind + shadcn/ui + Next.js（または Astro）という主流スタックを選ぶだけで「開発速度が桁違い」に上がります。
逆にニッチなフレームワーク・独自デザインシステム・素のJavaScriptを選ぶと、AI生成精度が落ちて工数で損をします。ただしAIが書けるのはパターン化されたUIまでで、「ブランディング・アクセシビリティ・ユーザー文脈は人間の仕事」として残ります。AIに量産させる部分と人間が決める部分を分けるのが、フロントエンドアーキテクチャの現代的な構え方です。
選定の優先順位をまとめると次の通りです。
- ユーザー体験指標から逆算（LCP・INP・CLSを業務要件として扱う）
- 主流スタックに寄せる（React + TS + Tailwind + Next/Astroが鉄板）
- 型安全をコード全域に（TypeScript + Zodで契約を明示）
- AIに書かせる部分・人間が決める部分を分ける（ブランディング・A11y（Accessibility）は人間）
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
ユーザー体験から逆算し、主流スタックに寄せ、AIに書かせる部分と人間の領域を分ける。これがフロントエンドアーキテクチャの3つの核です。
次回からはこの領域の各論に入り、まずホスティング（CDN・エッジ）から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（30/89）