本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
フロントエンドは「ユーザーが触れる唯一の場所」バックエンドが完璧でもUIで躓けば「使われないシステム」になります。本記事では独立領域として扱う理由、レンダリング方式の分類、主要フレームワークの位置づけ、ページ種別×構成の段階表、AI時代の恩恵構造まで俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。
そもそもフロントエンドアーキテクチャとは何か
お店の接客カウンターを想像してください。厨房（バックエンド）でどんなに素晴らしい料理を作っても、カウンターでの提供が遅い・メニューが読みにくい・注文方法がわからない──となれば、お客さんは二度と来ません。
フロントエンドアーキテクチャは、ユーザーが直接触れる画面・操作・表示の設計全体を扱う領域です。レンダリング方式・フレームワーク選定・状態管理・CSS設計・ホスティングなど、ユーザー体験を左右する技術判断を体系化します。
もしフロントエンドアーキテクチャがなければ、バックエンドがどんなに完璧でも表示が遅い・操作しにくい・見た目がバラバラで、使われないシステムになります。
ユーザーに届く唯一のレイヤー
開発者はつい業務要件や非機能要件を満たすためにバックエンドの設計へ意識を向けがちですが、一般ユーザー向けのプロダクトでは「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特有の非機能要件はバックエンドからは見えません。
③ 変更頻度と影響範囲が異なる
ビジネスロジックよりもはるかに頻繁に変わり、小さな変更がユーザー体験に直撃します。
レンダリング方式の分類
| 方式 | 概要 | 代表例 |
|---|---|---|
| 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 | 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 | GraphQL・REST・tRPC（TypeScriptでAPI型共有する仕組み） |
ルーティング・認証・アクセシビリティ
| 項目 | 選択肢の例 |
|---|---|
| ルーティング | ファイルベース / 定義ベース |
| 認証・認可基盤 | Cookie・LocalStorage・Refresh Token（再ログインせず新しいアクセストークンを取得するための長命トークン） |
| 命名規則 | BEM（Block Element Modifier、CSSクラス命名規則）・kebab-case等 |
| ディレクトリ構造 | feature-based / layer-based |
| URLパス | REST的・階層・クエリ設計 |
| アクセシビリティ | WCAG準拠・ARIA（Accessible Rich Internet Applications） |
国際化・SEO・セキュリティ・パフォーマンス
| 項目 | 選択肢の例 |
|---|---|
| 多言語対応（i18n） | next-intl・react-i18next |
| サポート環境 | ブラウザ / OS / 画面サイズの範囲 |
| SEO | メタタグ・OGP（Open Graph Protocol）・構造化データ・sitemap |
| セキュリティ | CSP・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 で設計します。
このカテゴリの知識構造
このカテゴリは全9記事で構成されています。土台から表層へ、そして横断テーマへと進む構造です。
**土台（グループ1）**はホスティング先 → レンダリング方式 → FW選定の順で決めます。CDNで配信するのかEdgeで動かすのかが決まると、使えるレンダリング方式が絞られ、FWの選択肢も自動的に狭まります。
**表層（グループ2）**では、FWが決まった上で状態管理とCSS設計を選びます。ReactならZustand、AstroならSSGベースで状態管理が最小化される、といった具合にFWと密結合しています。
**横断テーマ（グループ3）**のBFF・認証・SEOは、バックエンドやセキュリティといった他カテゴリとの接続面です。BFFはソフトウェアアーキテクチャのAPI設計、認証はセキュリティアーキテクチャの認証設計とそれぞれ対になっています。
やってはいけないこと
各論記事で触れた禁じ手のうち、フロントエンドアーキテクチャレベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 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に組込 |
| 「どのFWでも同じ」と思い込む | 思想が違い生産性が数倍変わる。チームスキルと用途で選定 |
| CSSを後回しにする | クラス名衝突・スタイル重複で改修コスト爆発。最初から設計 |
フロントエンドはユーザーに届く唯一のレイヤーです。Core Web Vitals を業務要件として扱います。
AI判断軸
| AI時代に有利 | AI時代に不利 |
|---|---|
| React + Tailwind + shadcn/ui（主流） | 独自UI実装・内製デザインシステム |
| Next.js / Astro（成熟フレームワーク） | ニッチ・新興フレームワーク |
| 型安全（TypeScript + Zod等） | 素のJavaScript |
| サーバコンポーネント・ファイルベースルーティング | 独自ルーティング・複雑な状態管理 |
- ユーザー体験指標から逆算（LCP・INP・CLSを業務要件として扱う）
- 主流スタックに寄せる（React + TS + Tailwind + Next/Astroが鉄板）
- 型安全をコード全域に（TypeScript + Zodで契約を明示）
- AIに書かせる部分・人間が決める部分を分ける（ブランディング・A11yは人間）
AIに任せる領域と人間が握る領域の境界
フロントエンドでAIが高精度に書ける領域は、データ取得ロジック・フォームバリデーション・API連携・基本的なUIコンポーネントの実装です。Tailwindのユーティリティクラスを使ったレイアウトやshadcn/uiのコンポーネント配置は、AIがほぼ正確に書きます。
一方、ブランディングに関わるデザイン判断・アクセシビリティの網羅的な対応・アニメーションの微調整・ユーザーリサーチに基づくUX設計は人間の領域です。AIが「動くUI」を作れても「使いやすいUI」かどうかは別問題であり、ここの判断は人間が握り続ける必要があります。
フロントエンドの主流スタックとAI生成精度の関係
React + TypeScript + Tailwind CSSの組み合わせは、2026年時点でAI生成精度が最も高いフロントエンドスタックです。GitHub上のコードベースでこの組み合わせの実装例が圧倒的に多く、AIは命名パターン・ディレクトリ構造・テストの書き方まで含めて標準的なコードを出せます。
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
ユーザー体験から逆算し、主流スタックに寄せ、AIに書かせる部分と人間の領域を分ける。これがフロントエンドアーキテクチャの3つの核です。
次回からはこの領域の各論に入り、まずホスティング（CDN・エッジ）から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は MDN Web Docs も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（30/89）