本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第4弾として、フロントエンドフレームワークについて解説する記事です。
選択肢が多く、「5年運用できるか」が第一の判断軸です。本記事ではReact／Vue／Svelte／AstroなどのUIライブラリと、Next.js／Nuxt／SvelteKitなどのメタフレームワークを比較し、用途別の選び方・人材確保・AI時代の生成精度まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。
この記事の結論
- アプリはReact+Next.js、コンテンツサイトはAstroを選ぶ
- 選定の実体は「メタFW選び」。素のReactでルーティング自作はしない
- Tailwind+shadcn/uiに揃えるとAI生成コードをそのまま取り込める
- マイナーFWは趣味に留め、業務は主流に寄せる
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもフロントエンドフレームワークとは何か
フロントエンドフレームワークとは、ざっくり言えば「ブラウザ上で動くUIを効率よく作るための骨組みとツールセット」です。
画材セットを想像してください。油絵具セット（React）・水彩セット（Vue）・デジタルペイントソフト（Svelte）──どれでも絵は描けますが、道具の特性や描き方が全く違います。一度その道具で作品を描き始めると、途中で別の道具に持ち替えるのは描き直しと同じです。加えてメタフレームワーク（Next.js・Nuxt等）は「画材＋キャンバス＋額縁」をセットにしたもので、ルーティングやSSRまで含めた基盤を提供します。
なぜフレームワーク選定が重要なのか
もし選定を間違えたらどうなるか。特に人材確保は軽視できません。マイナーなFWを選ぶと「開発できる人が見つからず3か月採用活動」という悲劇が起きます。技術的優位性よりも採用・チーム拡張性を優先するのが、実務では正解になることが多い領域です。「技術的に一番良い」より「5年運用・人材確保できる」が選定の基準です。
階層構造 ― 選定の実体はメタFW選び
現代のフロントエンドは階層構造になっており、「React単独」ではなく「React+Next.js」のように組み合わせて使うのが主流です。
| 分類 | 代表 | 役割 |
|---|---|---|
| UIライブラリ | React / Vue / Svelte | コンポーネント記述 |
| メタフレームワーク | Next.js / Nuxt / SvelteKit | ルーティング・SSR・ビルド統合 |
| マルチフレームワーク基盤 | Astro | 複数UIライブラリを混在可能 |
UIライブラリ単独ではルーティング・ビルド・SSRが不足するため、メタFW選びこそが実質的な選定です。
主要フレームワークの使いどころ
React+Next.js ― アプリ開発の既定値
Reactはエコシステム・求人数・情報量のどれを取っても圧倒的No.1で、特段の理由がなければ既定値として選んで構いません。意図的に必要最小限の機能しか提供せず、周辺ライブラリで補う設計思想です。そのReactの事実上の標準メタFWがNext.jsで、App Router（RSC+Server Actions）・SSR/SSG/ISRのページ単位切り替え・画像最適化まで揃います。SaaS・EC・大規模Webアプリ・SEO重視サイトの本命です。ReactメタFWには他にRemix（Shopifyが買収しReact Router統合路線）等もありますが、情報量・サポート範囲で「既定はNext.js」が最も無難です。
Astro ― コンテンツサイトの第一候補
Astroはコンテンツサイト特化のマルチフレームワーク基盤で、デフォルトでJSを一切送らず、必要な部分だけをIslandとしてReact / Vue / Svelteで動かせます。Markdownネイティブ・コンテンツコレクション・Lighthouse 100点が容易という特性で、ブログ・ドキュメント・LPでは現代最速の選択肢です。本シリーズが置かれているsenkohome.comもAstroで構築されています。
Vue+Nuxt ― 学習コストと日本での実績
Vueは学習曲線が緩やかでHTML寄りの単一ファイルコンポーネントが直感的、日本・中国で人気が根強く、公式でRouter / Piniaが揃います。メタFWのNuxtはNext.js相当の機能を提供し、下回りのNitroエンジンでどこにでもデプロイできる汎用性が強みです。日本案件・小〜中規模・既存Vue資産がある組織で有力です。
Svelte / Solid / Qwik ― 技術先行の新興勢
Svelteは仮想DOMなし・コンパイラ最適化でバンドルが極小、記述量も少ない優れたFWですが、大企業での採用実績はまだ限定的で人材確保に慎重さが要ります。Solid（React互換近似で高速）、Qwik（Resumabilityで JS送信ほぼゼロ）も技術的には非常に優秀ですが、採用実績が少なく本番投入には早すぎる可能性があります。個人プロジェクトで楽しむのが現実的な位置づけです。
どう選べばいいのか ― 用途×規模×人材
※ 2026年4月時点の実務対応表です。
| 用途 | 第一候補 | 5年後予測 |
|---|---|---|
| ブログ・ドキュメント・LP | Astro | ○ 拡大 |
| 中小〜大規模SaaS | Next.js+Tailwind+shadcn/ui | ◎ 主流 |
| 管理画面・社内ツール | Vite+React+shadcn/ui | ○ 継続 |
| Vue文化圏のSaaS | Nuxt 3 | ○ 継続 |
| 軽量・最高性能 | SvelteKit | △ ニッチ |
| 既存Rails / DjangoにUI追加 | Hotwire / Turbo | ○ 特定領域 |
「React+Next.jsがAIツールのデファクト」で、v0・Bolt等のUI生成AIが最も高精度に書けるのがこの組み合わせです。Svelte / Qwik / Solidは技術的に優れていても人材確保が10倍難しくなるため、業務では慎重な判断が必要です。業務はReact+Next.js、コンテンツはAstro、迷いなくこの2択です。
なお現代のトレンド（RSCの普及・Server Actions・Islands・tRPC等の型安全フルスタック・Edge First）は、いずれも「JSバンドル削減」と「型共有」に向かっており、今後数年は主流であり続けると予測されます。
3つのシナリオで考える
個人開発・スタートアップの場合
コンテンツサイトならAstro、アプリならNext.jsにTailwindとshadcn/uiを組み合わせる。この2択で迷う必要はないと思います。v0やBoltのようなUI生成AIが最も高精度に書けるのがこの構成ですので、1人開発の生産性が実質数倍になってしまいます。
中小SaaSの場合
Next.jsとTailwind、shadcn/uiにDesign Tokenを加えた構成が本命です。とは言っても、Vue文化圏のチームであればNuxt 3の継続が合理的で、無理にReactへ乗り換えるコストは正当化しにくいでしょう。この規模では人材採用のしやすさをフレームワーク選定の一級基準に置くべきだと考えています。
大企業の場合
社内の既存スキルセットと採用市場が決定要因になります。Angularが根付いている組織であればAngular継続が合理的ですし、新規プロダクトからReactとNext.jsを導入していく二本立てが現実解です。SvelteやQwikなどは技術的に優れていても人材確保が10倍難しくなってしまうため、業務システムでは避けるのが無難です。
AI判断軸 ― AI UIジェネレーターと揃える
Tailwind+shadcn/uiがAI時代に圧倒的に有利な理由
Tailwindはクラス名がそのままスタイルの意味を表すため、AIが「このコンポーネントの見た目」を文脈から正確に再現できます。独自のCSS設計だとプロジェクト固有の命名規約をAIに教え込む必要がありますが、Tailwindなら公開情報だけで正確なコードが出てきます。shadcn/uiはコンポーネントを「コピーしてプロジェクトに貼り付ける」設計思想のため、AIが中身を直接読み書きでき、「このボタンの角丸をなくして」のような修正指示がそのまま通ります。
さらにVercel v0・BoltのようなAI UIジェネレーターの出力は基本的にReact+Tailwind+shadcn/uiです。自分のプロジェクトをこのスタックに揃えておけば、AIが生成したコンポーネントをそのまま取り込めます。独自CSS設計やマイナーUIライブラリでは、取り込むたびに変換作業が必要になります。
Server Componentsの境界はAIが扱いやすい
Next.js App RouterのRSCは、ファイル先頭の 'use client' の有無で境界が決まるため、AIがそのコンポーネントの実行場所をファイル単位で判断でき、誤った場所でブラウザAPIを呼ぶミスが起きにくい構造です。Astroの client:load 等のディレクティブも同様に明示的で扱いやすい。手書きでHydration境界を細かく制御する構成は、AIが境界を正しく把握できないことがあります。
やってはいけないこと
「新しい・尖っている」で選ぶと5年後に人材確保で詰みます。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 廃止・メンテ終了FWを使い続ける | AngularJSは2022年EOLで世界中が全面書き直しになった → 5年後の公式サポートを選定軸にする |
| 素のReactでルーティングから自作 | 車輪の再発明 → Next.js / React Routerを使う |
| ブログをNext.js SSRで作る | Astroなら静的配信で圧倒的に速く安い → 用途で使い分ける |
| 尖った新興FWを業務採用 | 採用に半年〜1年かかる → 個人開発に留める |
| Create React Appで新規プロジェクト | 2023年に公式メンテ終了 → Vite / Next.jsを使う |
| メジャーバージョンアップを3年以上放置 | 一気に追うのが不可能になる → 年次で追従する |
2023年のCRAメンテ終了、2024年のstyled-componentsメンテナンスモード入り──フロント界は「当時の最新」が数年で負債化する典型的な領域です。
筆者メモ ― 「当時の最新」が地雷になった日
2022年1月にAngularJSが公式サポート終了した時、世界中の現役プロジェクトが全面書き直しを強いられました。AngularJSとAngular（2以降）は別物のフレームワークで、移行というより新規作り直しに近く、「Google製だから安心」と信じていた現場が大量に被弾しました。移行で疲弊したチームが結局Reactに乗り換えた、という結末も少なくありません。
同系統の話はBackbone・Ember・Knockout・Meteorにも当てはまります。どれも一時代のスターでしたが、現在は新規採用の選択肢にまず挙がりません。「3年後、そのFWの求人は残っているか？」──これに胸を張れないなら、主流に寄せるのが安全です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- UIライブラリ（React / Vue / Svelte等）
- メタFW（Next / Nuxt / SvelteKit / Astro）
- RSCの採否（Next.js採用時）
- UIコンポーネントの基盤（Tailwind+shadcn/ui等）
- サポートブラウザ範囲
- メジャーバージョンアップの追従方針
決定理由の残し方
フレームワーク選定は数年単位でプロジェクト全体を拘束する判断です。選定時の背景と理由をADRとして文書化しておくと、メンバー交代や技術トレンドの変化があっても判断の経緯を追えます。
| 項目 | 内容 |
|---|---|
| タイトル | フロントエンドフレームワークに React を採用する |
| ステータス | 承認済み |
| コンテキスト | 新規 SaaS プロダクトのフロントエンドを構築する。チーム6名中4名が React 経験者で、採用市場でも React エンジニアが最も多い |
| 決定 | React 19 + Next.js 15（App Router）を採用する |
| 理由 | ・チームの既存スキルを活かせるため立ち上がりが最速 ・npm エコシステムで必要なライブラリ（認証・フォーム・テーブル等）が最も充実している ・AI コード生成で React の精度が最も高い |
| 却下した代替案 | Vue 3 + Nuxt → 経験者が1名のみで教育コストが高い。Svelte + SvelteKit → エコシステムが未成熟でエンタープライズ事例が少ない |
| 結果 | Server Components の学習コストが発生する。RSC 対応ライブラリへの移行判断を3か月後にレビューする |
ADRはリポジトリの docs/adr/ にナンバリングして保管し、技術選定のPRに添付するのが効果的です。後から見返したとき「なぜこの選択をしたか」が一目でわかることが、ADRの最大の価値です。
この記事に関連する記事
まとめ
本記事はフレームワーク詳細について、UIライブラリ・メタFW・人材確保・AI精度まで含めて解説しました。如何だったでしょうか。
アプリはReact+Next.js、コンテンツならAstro。AIの恩恵も最大になる組み合わせが2026年の現実解です。
次回はCSS設計（Tailwind/CSS Modules/CSS-in-JS）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は React 公式ドキュメント も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（40/95）