本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
フロントエンドは「ユーザーが触れる唯一の場所」で、バックエンドが完璧でもUIで躓けば「使われないシステム」になります。本記事では独立領域として扱う理由、レンダリング方式の分類、主要フレームワークの位置づけ、ページ種別×構成の段階表まで俯瞰します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』も参考にしてみてください。
この記事の結論
- ユーザー体験指標（Core Web Vitals）から逆算して技術を選ぶ
- ページ種別で方式を使い分ける（「全部SPA」も「全部SSR」も雑な選定）
- 主流スタック（React+TS+Tailwind+Next / Astro）に寄せる
- AIに書かせる部分と人間が決める部分を分ける
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもフロントエンドアーキテクチャとは何か
お店の接客カウンターを想像してください。厨房（バックエンド）でどんなに素晴らしい料理を作っても、カウンターでの提供が遅い・メニューが読みにくい・注文方法がわからない──となれば、お客さんは二度と来ません。
フロントエンドアーキテクチャは、ユーザーが直接触れる画面・操作・表示の設計全体を扱う領域です。レンダリング方式・フレームワーク選定・状態管理・CSS設計・ホスティングなど、ユーザー体験を左右する技術判断を体系化します。
なぜ独立したアーキテクチャとして扱うのか
理由は3つあります。第一に、フロントエンド専用のフレームワーク・ビルドツール・状態管理といった「異なる技術文化」が形成されていること。第二に、ページ表示速度（LCP）・入力応答性（INP）・レイアウト安定性（CLS）といったUI特有の非機能要件はバックエンドからは見えないこと。第三に、ビジネスロジックよりはるかに頻繁に変わり、小さな変更がユーザー体験に直撃することです。
一般ユーザー向けのプロダクトでは、UI/UXの重要性は事業成果に直結するレベルで大きい。フロントエンドを「見た目の領域」として軽視するのは、事業価値を軽視しているのと同じことです。
レンダリング方式の分類
| 方式 | 概要 | 代表例 |
|---|---|---|
| MPA | 画面遷移ごとにサーバーでHTML生成 | WordPress・Rails伝統 |
| SPA（CSR） | 1つのHTMLにJSで画面を切り替える | React CSR・Vue.js |
| SSR | サーバー側で都度HTMLを生成 | Next.js・Nuxt.js |
| SSG | ビルド時にHTMLを生成 | Astro・Next.js Static |
| ISR | SSRとSSGのハイブリッド | Next.js |
フレームワークの主役は3つです。エコシステム最大・求人最多のReactとそのメタFWのNext.js（SSR/SSG対応でSEO重視のWebアプリの本命）、そしてコンテンツ重視・高速SSGのAstro（ブログ・LP・ドキュメントの本命）。ほかに学習コストの低いVue.js、大企業向けのAngular、軽量なSvelteもありますが、明確な理由がある時の選択肢です。
どう選べばいいのか ― ページ種別×構成の段階表
※ 2026年4月時点の業界相場値です。
フロントエンドは「1サイト=1方式」が破綻の元なので、「ページ種別で方式を使い分ける」のが定石です。
| ページ種別 | レンダリング方式 | 状態管理 |
|---|---|---|
| ブログ・ドキュメント・LP | SSG（Astro） | useState |
| EC商品詳細 | ISR（60〜300秒） | Zustand+TanStack Query |
| SaaSダッシュボード・管理画面 | CSR | Zustand+TanStack Query |
| ニュース・メディア | ISR+Streaming SSR | TanStack Query |
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設計を選びます。横断テーマ（グループ3）のBFF・認証・SEOは、バックエンドやセキュリティといった他カテゴリとの接続面です。
AI判断軸 ― AIに任せる領域と人間が握る領域
主流スタックとAI生成精度の関係
React+TypeScript+Tailwind CSSの組み合わせは、2026年時点でAI生成精度が最も高いフロントエンドスタックです。GitHub上にこの組み合わせの実装例が圧倒的に多く、AIは命名パターン・ディレクトリ構造・テストの書き方まで含めて標準的なコードを出せます。独自UI実装や内製デザインシステムは、この恩恵を受けられません。
AIに任せる領域と人間が握る領域の境界
AIが高精度に書ける領域は、データ取得ロジック・フォームバリデーション・API連携・基本的なUIコンポーネントの実装です。Tailwindのレイアウトやshadcn/uiのコンポーネント配置はほぼ正確に書きます。一方、ブランディングに関わるデザイン判断・アクセシビリティの網羅的な対応・ユーザーリサーチに基づくUX設計は人間の領域です。AIが「動くUI」を作れても「使いやすいUI」かどうかは別問題であり、ここの判断は人間が握り続ける必要があります。
やってはいけないこと
各論記事で詳しく触れる禁じ手のうち、全体レベルで押さえるべき核心を6つに絞ります。
| 禁じ手 | なぜダメか |
|---|---|
| SEO必須サイトをCSRのみで構築 | クローラーが空のHTMLを読み、検索流入が壊滅する |
| JWTをlocalStorageに保存 | XSS一撃で全員分漏洩する。httpOnly Cookie必須 |
| 素のReactでルーティング・SSRを自作 | Next.js / Astroを使わない理由がない |
フロントだけで認可判定（user.role === 'admin'） | F12で書き換え可能。サーバ側認可が必須 |
| 画像を元サイズで配信 | LCP悪化の定番。Next/Image等で自動変換する |
| CSSを後回しにする | クラス名衝突・スタイル重複で改修コストが爆発する |
筆者メモ ― 「モダンだから」で壊れた検索流入
あるメディアサイトのリニューアル案件で、「モダンだから」という理由だけで全ページをReact CSR（SPA）で作り直し、リリース後3ヶ月で検索流入が半分になった、という事例があります。原因はシンプルで、OGPとmetaタグがJS実行後にしかHTMLに入らず、検索とSNSのクローラーが空のHTMLを読んでいたからです。
技術選定を「流行っているから」で決めると、後からUXと事業指標のダブルで殴られます。特にコンテンツ中心のサイトをSPAで作るのは典型的な地雷です。記事はSSG、管理画面はSPA、とページ単位で方式を使い分けるのが現代の本命です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。それぞれの詳細は配下の各論記事で扱います。
- ホスティング（CDN・エッジ）
- レンダリング方式（ページ種別ごとに）
- フレームワーク（React / Vue / Astro等）
- 状態管理とCSS設計
- BFFの要否と認証方式
- SEO・アクセシビリティ・Core Web Vitalsの目標値
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
ユーザー体験から逆算し、主流スタックに寄せ、AIに書かせる部分と人間の領域を分ける。これがフロントエンドアーキテクチャの3つの核です。
次回からはこの領域の各論に入り、まずホスティング（CDN・エッジ）から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は MDN Web Docs も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（36/95）