一人会社のフロントエンド構成：Astro、Next.js、React、Tailwind、shadcn/uiの選び方

プロジェクトには /blog、/tools/image-resizer、/dashboard/settings、/pricing という4種類のページがあります。すべてをNext.jsに入れるのか、AstroのブログとNext.jsの管理画面に分けるのかは簡単に決まりません。Astroでブログを運用した後にログイン、決済、履歴を加えると、移行すべきか迷います。反対に、20本のMarkdownと数ページしかないNext.jsプロジェクトでも、キャッシュ、Server/Client Components、デプロイ設定を理解する必要があります。

一人会社のフロントエンド選定は、どのフレームワークが最強かを競う話ではありません。ページ種別、動的データ、保守コストから、リポジトリを分けるか、shadcn/uiのソースを所有するかを決めます。ここではAstro islandsが合う境界、Next.js App Routerのコストが利点を上回る境界、React + Viteの方が単純な境界を扱います。

Node.js、Python、Goなどのバックエンド、CloudflareやVercelなどのデプロイ、PostgreSQLやSupabaseなどのデータベース、認証の実装は後続記事の範囲です。

フレームワーク選定表

人気ではなくページ種別から始めます。動的データと保守コストを並べると、出発点が見えます。

ページ種別	動的データ	保守難度	推奨する出発点	代表例
コンテンツサイト、ブログ、文書	低、主にMarkdown/YAML	低	Astroを優先	ブログ、製品文書、Landing Page
単機能ツール	中、クライアント状態	中	React + ViteまたはAstro islands	画像圧縮、JSON整形、Markdown編集
SaaS管理画面	高、ユーザーデータとAPI	高	Next.js App Router	設定、注文、分析画面
高操作製品	高、クライアントルーティングとリアルタイムデータ	高	Next.jsまたはReact + Vite	共同編集、チャット、エディター
マーケティング・料金ページ	低、静的コンテンツ	低	AstroまたはNext.js SSG	/pricing、/features、/about

複数のページ種別を持つ製品

コンテンツとSaaS管理画面の両方がある場合は比率を見ます。

コンテンツが約80%、管理機能が20%ならAstroを中心にし、管理部分をReact islandsまたは独立Next.jsアプリにできます。

アプリが約80%、ブログが20%ならNext.js App Routerを中心にし、ブログを静的生成できます。

半々ならAstroのコンテンツアプリとNext.js管理アプリを明示的に分けると保守境界が明確です。別リポジトリでなくmonorepoでも構いません。

分割はデプロイと依存管理を増やします。目的は技術的な純粋さではなく、片方のキャッシュや描画規則を全ページに波及させないことです。

保守コストへの注意

Next.jsのキャッシュ、Server/Client Componentsの境界、Vercel、Cloudflare、自前環境の差には学習と検証が必要です。動的ページが少なければ、React + ViteやAstroの方が保守負担を抑えられます。

詳しい技術差はAstroとNext.jsの比較で確認できます。

コンテンツサイト：AstroとIslands

Astroはブログ、文書、マーケティングなどのコンテンツ駆動サイト向けです。server-firstとzero JS by defaultは、ページをビルド時またはサーバーでHTMLにし、明示した対話コンポーネントだけをブラウザで動かすことを意味します。

content collectionsはMarkdownや構造化データを整理、検証、型付きで検索できます。frontmatterの検証や日付、タグ、分類による取得をビルド時に行えるため、索引の手作業を減らせます。

Islands：静的HTMLと局所操作

ページの大部分は静的HTMLのまま、操作が必要な小さな部分だけをislandにします。client:loadやclient:visibleでブラウザに読み込む時点を指定します。

送信ボタンだけをReactコンポーネントにしてclient:loadで動かせます。

テーマ切り替えはlocalStorageとCSS変数を扱う小さなクライアント部品にできます。

画像拡大部品はclient:visibleで表示領域に入ったときだけ読み込めます。

フォーム1個のためにページ全体をhydrationしない点が、コンテンツサイトに小型ツールを置くときの利点です。

Astroだけで抱えない方がよい場面

ほぼ全ルートで認証し、非公開データを読み、大きな共有状態や複雑なクライアントルーティングを扱うなら、Astroが当然の選択とは言えません。認証済みislandだらけの管理画面はNext.js App Routerや独立Reactアプリの方が自然です。

Astro 5のLighthouse実践ではcontent collectionsとislandsの実例を扱っています。

ツールと対話製品：React + ViteとNext.js

ツールは画像圧縮やJSON整形のような一つの操作が中心です。対話製品には複数ルート、共有状態、共同作業、エディターが加わります。

React + Viteが合う場面

サーバー描画に依存しないクライアントSPAや単機能ツールに向きます。

画像圧縮はブラウザ内で処理して結果をダウンロードできます。

JSON整形はサーバーなしで入力を解析できます。

Markdownエディターは編集、プレビュー、localStorageへの保存をクライアントで完結できます。

静的配信が簡単で、Next.jsのキャッシュ境界を持たないのが利点です。一方、検索流入が重要なツールではクライアントだけの構成に別途SEO設計が必要です。

Next.jsが合う場面

サーバー描画、複数ルート、混合描画が必要なツールや製品に向きます。

トップ、ツール、結果という複数ページをサーバー描画できます。

検索向けの説明ページをSSGやSSRで索引可能にできます。

紹介ページは静的、非公開結果は動的という分担もできます。

React + Viteを選ぶ条件

Browser API、localStorage、Canvasだけで主要操作が完結する場合です。

Node.jsランタイムなしで静的配信したい場合です。

Next.jsのルーティング、キャッシュ、SSRが不要な場合です。

明確なクライアントとバックエンドの境界の方が保守しやすい場合です。

検索とサーバー描画が重要なら、その利点とNext.jsの追加コストを比較します。

React 19 Actionsの記事ではフォームと非同期処理を詳しく扱っています。

SaaS管理画面：Next.jsのServer/Client Components

Next.js App RouterはServer ComponentsとClient Componentsでサーバー処理とブラウザ操作を分け、'use client'でクライアント境界を示します。

Server ComponentsとClient Components

Server Componentsはサーバーまたはビルド時に動き、コンポーネント処理をブラウザのJavaScript bundleに加えません。

静的内容、データベース照会、API呼び出しに向きます。

localStorageやwindow、useStateやuseEffect、onClickは利用できません。

Client Componentsはブラウザで動き、操作、状態、Browser APIを扱います。

フォーム、ボタン、状態切り替え、リアルタイム更新に向きます。

ファイル上部の'use client'で境界を宣言します。

Server ComponentsはClient Componentsをimportできます。Client ComponentsからServer Componentsを直接importはできませんが、サーバーで作った描画内容を受け取る構成は可能です。

SaaS管理画面の用途

認証、動的データ、多数のフォームを組み合わせる管理画面に適します。

ユーザー設定では非公開データを読み、設定やパスワードを更新します。

注文管理では一覧、詳細、状態更新を扱います。

分析画面では保護されたデータをサーバーで読み、ブラウザでグラフを操作します。

Server Componentsからデータ層へ接続できるため、認証とデータ権限が中心の画面で役立ちます。

保守コストへの注意

静的・動的描画、revalidate、コンポーネント境界、実行環境は利用するNext.jsの版と一致させます。規則は変化するため、古いスニペットではなく現行文書を確認します。

動的ページが数個なら、React + ViteとNode.jsやSupabaseの独立バックエンドの方が単純で移植しやすいことがあります。

Next.js App Routerシリーズではルーティング、移行、Middleware、Auth、Dark Modeを個別に扱っています。

スタイル層：Tailwindとutility-first

utility-firstは、部品ごとにCSS名を作らず、HTMLやJSXで小さなclassを組み合わせます。<div class="bg-blue-500 text-white p-4 rounded-lg">では各classが一つの見た目を担当します。

Tailwindはスタイル協調層であり、良いデザインを自動生成しません。

CSS名を毎回考える負担を減らします。

利用するmarkupの近くにstyleを置き、CSSとのずれを減らします。

人とAIが配置や外観を修正する共通語彙にもなります。

Tailwindだけではデザイン品質は生まれない

色、文字、余白、角丸の一貫した規則が必要です。

既定utilityを無作為に使うのではなく、製品のtokenを定義します。

ボタン、カード、行で繰り返すclass群は部品に抽象化します。

制約がなければ、markupが密になるだけで製品は整いません。

Tailwindはアプリ基盤と独立している

Astro、Next.js、React + Viteのどれでも使えます。現在のTailwind CSS v4のVite手順は@tailwindcss/viteとCSSの@import "tailwindcss";が中心で、Astroも同じVite pluginを利用できます。実装時は現行の公式ガイドを確認します。

コンポーネント層：shadcn/uiのソース所有と導入

shadcn/uiは固定実装を隠す従来型packageではありません。CLIがコンポーネントのソースをプロジェクトへ追加し、以後はプロジェクトが所有して変更します。

コンポーネントソースはプロジェクトが所有する

上流更新はコピー済み部品を自動更新しないため、差分を確認して取り込みます。

キーボード操作、ARIA、screen readerは実際の組み合わせで検証します。

色、角丸、余白を製品のデザインシステムへ合わせます。

検証や送信などの業務動作はアプリ側で実装します。

ソースが見えて変更できるのが利点ですが、更新、アクセシビリティ、テーマ、状態の責任も引き受けます。

shadcn/uiとTailwind

現在のAstroとNext.js向け手順はいずれもTailwind CSSを前提にしています。Tailwindがstyle言語、shadcn/uiが所有するcomponent sourceを提供します。

適した用途

SaaS管理画面、設定、フォームの多いページに向きます。

Button、Input、Select、Dialog、Tableを管理画面の出発点にできます。

設定ページでは入力部品と検証表示を再利用できます。

登録、ログイン、決済でもprimitiveを使えますが、検証と状態は製品が所有します。

既存の部品ライブラリや厳格なブランドシステムがある場合には優先度が下がります。

Astroへの導入

React部品を動かすためReact integrationが必要です。

コンポーネントのstyleにTailwindも必要です。

フォームやDialogなど局所UIに使い、すべてのコンテンツページをReactアプリへ変える理由にはしません。

公式Astro templateはTailwind CSSとReact integrationを設定します。CLI実行前に現在の手順を再確認します。

Next.jsへの導入

Next.js templateと既存プロジェクト向け初期化手順があります。

操作の有無に応じ、適切なServer/Client Components境界へ置きます。shadcn/uiを使うだけでページ全体をClient Componentにする必要はありません。

CLI、preset、registryは変化するため現行文書に従います。

shadcn/uiを使わない条件

基礎部品ではなく完全なデザインシステムが必要な場合です。

ソース、更新、アクセシビリティ、テーマを所有したくない場合です。

Ant Design、Material UI、社内ライブラリが要件を満たしている場合です。

フォームや管理UIの少ないコンテンツサイトでは不要かもしれません。

一人会社が負担する本当の保守コスト

ページ種別とデータだけでなく、フレームワークの複雑さ、ソース所有、AI生成コードの確認コストが長期作業を決めます。

Next.jsの保守

描画とキャッシュの意図が設定とずれると古いデータを返す恐れがあります。

Server/Client Componentsの境界では状態とデータ取得の場所を明示します。

Vercel、Cloudflare、自前Node.jsで動作が異なる点を個別に評価します。

静的ページが中心なら、この学習と確認の費用が利点を超えることがあります。

shadcn/uiの保守

更新と上流修正を確認します。

キーボード、ARIA、screen readerを製品レベルで試験します。

色、角丸、密度、余白をdesign tokenへ合わせます。

検証、送信、業務状態は独自実装です。

この所有責任を避けたいならpackage型ライブラリや少数の自作primitiveを検討します。

AI生成フロントエンドの確認

例が多いためAIはReact、Next.js、shadcn/uiのコードを生成しやすいものの、検収は残ります。

不要なServer/Client Componentsの層を増やすことがあります。

利用版やrouteの意味と合わないcache規則を作ることがあります。

生成したshadcn/uiの組み合わせがdesign tokenや状態を無視することがあります。

実装時間は短くなっても、構成、状態、アクセシビリティ、見た目の確認費用は残ります。

一つの製品で複数フレームワークを使う

AstroのコンテンツサイトとNext.js管理画面は境界を明確にしますが、二つのappの依存、設定、CI/CDが必要です。

blog.example.comとapp.example.comのようなrouteやdeployも管理します。

一人会社ならmonorepoにまとめても構いません。コンテンツ中心ならAstro、アプリ中心ならNext.js、半々なら二つの明示的なapp境界を選べます。

次のステップと関連記事

公開済みの記事

ブログフレームワーク選定はHugo、Astro、Hexoを比較します。

Astro 5とLighthouse 100はcontent collections、islands、性能設定を扱います。

AstroとNext.jsの比較は構成と描画方式を比較します。

React 19 Actionsはフォームと非同期操作を扱います。

Next.js App Routerシリーズ

ルーティング、移行、Middleware、Auth、Dark ModeはSaaS管理画面向けの個別記事で詳しく説明しています。

本シリーズの後続記事

本稿は「一人会社の技術スタック」シリーズ第5回です。後続ではNode.js、Python、Go、Supabase、自作APIなどのバックエンドを比較します。

Cloudflare、Vercel、自前サーバー、コンテナのデプロイも扱います。

データベースではPostgreSQL、Supabase、PlanetScale、MongoDBを比較します。

認証ではmanaged serviceと自作方式の境界を扱います。

ページをコンテンツ、動的データ、保守コストで分類したら、次はその前端選択を支えるバックエンドとデプロイ境界を決めます。