Webサービスの技術構成 2026年版 — Vue.js/Nuxt/Astroの使い分けとその理由
Webサービスの技術構成 2026年版 — Vue.js/Nuxt/Astroの使い分けとその理由
結論
- Reactベースの技術選定メモをVue.jsに置き換えると、「単純なやつ」はVue 3 + Vite、「ちょい複雑」はNuxt（Static Generation）になる。
- 「React + Vite」が「Next + Vite」になることはない。Next.jsは独自のバンドラー（Turbopack、旧webpack）を使うフレームワークで、Viteとは別系統である。
- 「単純」と「ちょい複雑」の分かれ目は、Viteというビルドツール単体を使うか、Nuxtというメタフレームワークを使うかの違いにある。ルーティング・データフェッチ・SEO・画像最適化・APIルートを規約として持っているかどうかが境目になる。
- 記事コンテンツ中心のサイトにAstroを選ぶ判断は正しい。Nuxt/Next.jsは「アプリケーション」を前提に全コンポーネントを既定でハイドレートするが、Astroは「コンテンツ」を前提に既定でJavaScriptをゼロにし、必要な箇所だけVue/Reactを部分的にハイドレートする。
- ちょっとしたAPIは、エンドポイントが少なければ生のCloudflare Workers、ルーティングやミドルウェアが増えたらHonoを使う。
以下、各分岐点について、なぜその組み合わせになるのかを順に説明する。
1ページだけの簡単なWebページ
HTMLファイルを1枚書いてCloudflareに置く。ここは規模を問わず変わらない。ビルドプロセスもフレームワークも要らず、告知ページ・簡易フォーム・LP1枚向けの構成になる。
静的ビルドできるやつ
単純なやつ: Vue 3 + Vite
vite buildで静的アセットを吐き出し、Cloudflare Pagesのような静的ホスティングにそのまま置く。ページ数が少ない、ルーティングが要らない（あってもvue-routerを自分で足す程度）、複雑なデータフェッチが要らない、といったシンプルなSPAや社内ツールに向く。
ちょい複雑: Nuxt（Static Generation）
Nuxtをnuxt generateでビルドし、サーバーを立てずに静的HTMLとして書き出す。ファイルベースルーティング（pages/ディレクトリ構造がそのままURLになる）、データフェッチ規約（useAsyncData/useFetch）、SEO用のuseSeoMeta、画像最適化（@nuxt/image）、APIルート（server/api/）まで、一つのフレームワークの中で一貫した作法として提供される。このサイト（mdx-playground）自体もNuxt 3 + @nuxt/contentで構築されている。
コラム: 「React + Vite」は「Next + Vite」になり得るか
結論から言うと、ならない。Next.jsは独自のバンドラーであるTurbopack（旧webpack）を使うフレームワークで、Viteの上に構築されているわけではない。2026年時点でTurbopackはNext.jsの標準バンドラーとなっており、本番ビルドでもTurbopackが既定で使われる。一方Viteは、Rust製エンジン「Rolldown」への置き換えが進み、開発サーバーと本番ビルドの両方が高速化されている。
つまり「Next.jsの中身をViteに差し替える」という構成は存在しない。Next.js＝Turbopack系、Vue/Svelte系のメタフレームワーク＝Vite系という棲み分けが、2026年時点の実質的な構図になっている。Viteの上に構築されたNext.js相当のメタフレームワークが欲しいなら、Vue圏ではNuxt、他にはSvelteKit・Astro・TanStack Start・Vike（vite-plugin-ssrの後継）などが選択肢になる。
「単純」と「ちょい複雑」の分かれ目
これは「ビルドツール単体」か「メタフレームワーク」かの違いに集約される。
Viteはビルドツール（開発サーバー＋バンドラー）であり、ルーティング・データフェッチ・SEO・APIルートの作法を持たない。必要になれば、vue-router・自前のfetchロジック・@unhead/vueなどを個別に組み合わせる。構成の自由度は高いが、その分すべて自分で決める必要がある。
Nuxtはメタフレームワークであり、上記の作法を規約として最初から持っている。ページ数が増える、フォームが複雑になる、複数コンポーネント間で状態を共有したい、といった「フロントエンドでゴニョゴニョしたい」場面になるほど、規約の恩恵が効いてくる。
つまり「ちょい複雑＝フロントエンドで複雑な状態管理・インタラクションをしたいときにNext.js的なフレームワークが出てくる」という理解は正しい。Vue版で言えば、その役をNuxtが担う。
| 観点 | Vue 3 + Vite（単純） | Nuxt（ちょい複雑） |
|---|---|---|
| ルーティング | 自分でvue-routerを追加 | ファイルベースで自動生成 |
| データフェッチ | 自分でfetchロジックを書く | useAsyncData/useFetchの規約あり |
| SEO・メタタグ | 自分で@unhead/vue等を組む | useSeoMetaが標準搭載 |
| 画像最適化 | 自分で対応 | @nuxt/imageモジュールあり |
| APIエンドポイント | 別途バックエンドが必要 | server/api/でフロントと同居できる |
| 向く場面 | 1〜数ページの単機能ツール、社内ダッシュボード | ページ数が多い、状態共有が要る、SEOが要るサイト |
記事っぽいコンテンツ中心: Astro
文章系のコンテンツが中心のサイトにAstroを選ぶ判断は正しい。
NuxtとAstroの違い
Nuxt/Next.jsは「サイト全体がインタラクティブなアプリケーション」を前提に設計されており、コンポーネントは既定でクライアント側にハイドレート（JavaScriptで動く状態に）される。Astroは「サイトの大半は読み物」を前提に設計されており、既定ではJavaScriptを一切送らずHTMLのまま配信する。Vue・React・Svelteといったコンポーネントを使いたい箇所だけ、「Island（島）」として個別に指定してハイドレートする。1つのAstroページの中に、Vueで書いたカルーセルとReactで書いたモーダルを共存させることもできる。
したがって、ブログ・ドキュメント・LPのように「大半は読ませるページで、動く部分は一部だけ」というサイトはAstroの得意領域であり、逆に管理画面・ダッシュボードのように「ページの大半が状態を持つUI」であるサイトはNuxt/Next.jsの得意領域になる。
ちょっとしたAPIが必要: Workers直接 vs Hono
| 選択肢 | 向く場面 | 具体例 |
|---|---|---|
| 生のCloudflare Workers | エンドポイントが1〜数個、ルーティングがif分岐数個で済む | Webhookの受け口1つ、単純なリダイレクトルーター |
| Hono | ルート数が増える、パスパラメータが要る、ミドルウェア（認証・CORS・バリデーション）が要る | 複数リソースを持つREST API、認証を挟む管理API、OpenAPI仕様を出したいAPI |
Honoは軽量なTypeScript-firstのWebフレームワークで、Web標準（Request/Response）に準拠しているためCloudflare Workers・Deno・Bunと相性がよい。2026年時点でCloudflare Workers上に複数エンドポイントを持つAPIを新規に作る場合の既定の選択肢になっている。
サーバーが必要になったら
ここから先は元のメモの構成（React/Next.js前提）をそのまま残す。Vue圏で対応させる場合、「小〜中規模」の枠はNuxtのSSRモード（NitroのcloudflareプリセットでCloudflare Workers上にデプロイ）が、「中〜大規模で最短」の枠はVercel上のNuxtが、それぞれTanStack Start・Next.jsの役割に近い。
- 小規模〜中規模 → TanStack Start on CF Workers
- 中〜大規模。最短で出したい → Next.js on Vercel
- 中規模でコスト削減したい。苦しむ覚悟がある → OpenNext on CF Workers（Next.js専用のCloudflareアダプタで、公式サポート外の部分を自分たちで埋める必要がある）
なお、Nuxtの場合はNitroが元々Cloudflare向けのプリセットをネイティブに持っているため、OpenNextのような追加アダプタを挟む苦労は生じにくい。
DB
| 選択肢 | 向く場面 | 具体例 |
|---|---|---|
| D1 / Durable Objects | 小〜中規模でCloudflare Workersを使っている | 個人開発のSaaS MVP、ブログのコメント機能、簡単なTodoアプリのバックエンド |
| Turso | Cloudflare以外のホスティングで小〜中規模のSQLite的DBが欲しい | Vercel上のアプリでlibSQLのEmbedded Replicaを使い、読み取りをリージョンごとに高速化したいとき |
| Supabase | Postgresを安く使いたい、国内向け | 国内向けSaaSで、認証・リアルタイム機能もセットで欲しいとき |
| Neon | Postgresを安く使いたい、東京リージョンがなくてもよい海外向け | サーバーレスPostgres、ブランチ機能でPRごとに検証用DBを分離したい開発チーム |
| PlanetScale | Postgres/MySQLを使いたく、コストは許容できる | 本格的にスケールするtoCサービス、頻繁なスキーマ変更を伴うチーム開発 |
ストレージ
| 選択肢 | 向く場面 | 具体例 |
|---|---|---|
| R2 | コストを節約したい | 個人ブログの画像・動画配信、アクセス数はあるが予算が限られるプロジェクト |
| AWS S3 / GCS（バージョニング有効） | 消えたら詰む | 契約書・請求書等の法定保存文書、金融系のバックアップアーカイブ |
| R2 + 定期バックアップ（S3/GCS最安クラス） | 節約したいが消えたら詰む | 個人開発だが顧客データを預かるSaaS、コストを抑えつつ最低限の冗長性は欲しいとき |
メール配信
| 選択肢 | 向く場面 | 具体例 |
|---|---|---|
| AWS SES | たくさん送る | 月間数万〜数十万通のトランザクションメール（パスワードリセット、注文確認）を送るサービス |
| Cloudflare Email Service | Workersを使っている | Workers上で完結させたい小規模プロジェクトの通知メール |
| Resend | あまり送らない | 個人開発SaaSのウェルカムメール・週次ダイジェスト、月数百〜数千通程度 |
(SendGridは無料プランがなくなったため候補から外している。)
その他
| 用途 | 選択肢 | 具体例 |
|---|---|---|
| 決済 | Stripe | サブスク課金・単発課金いずれも |
| 認証 | BetterAuthを検討し、要件が合わなければ他サービス | 自前で持ちたいがゼロから実装はしたくないとき |
| リアルタイム同期 | Cloudflare WorkersのDurable Objects | チャット、共同編集、ライブスコア表示 |
| 一部の人に向けて公開 | Cloudflare Zero Trust | 社内ツール、限定ベータ公開 |
ビジネス的な要件が色々ある
Google Cloudのサービスを組み合わせる（Cloud Run / SQL / Memorystore / Tasks / Scheduler / Storage）。具体的には次のような場面で選択肢に上がる。
- 既存のGoogle Workspace/GCP資産と統合が必要
- コンプライアンス要件でリージョン・監査ログ等の柔軟な制御が必要
- チームがKubernetes/コンテナベースの運用に慣れている
- Cloudflare/Vercelのマネージドサービスだけでは足りない複雑なワークフロー（バッチ処理、キュー、スケジュールジョブの組み合わせ）がある
まとめ
| 疑問 | 回答 |
|---|---|
| 「React + Vite」は「Next + Vite」になり得るか | ならない。Next.jsは独自バンドラー（Turbopack）を使う別系統のフレームワークで、Viteの上には乗っていない |
| 単純とちょい複雑の違いは何か | ビルドツール単体（Vite）か、ルーティング・データフェッチ・SEOを規約として持つメタフレームワーク（Nuxt）かの違い |
| 「ちょい複雑＝フロントで複雑な処理をしたいときにNext.js的なものが出てくる」の理解は合っているか | 合っている。Vue版ではその役をNuxtが担う |
| 記事コンテンツ中心はAstroでいいか | よい。Nuxt/Next.jsは全体をハイドレートする「アプリケーション」前提、Astroは既定JSゼロで一部だけ動かす「コンテンツ」前提という設計思想の違いがある |
| Workers直接とHonoの違いは何か | エンドポイントが少なければ生のWorkers、ルーティングやミドルウェアが増えたらHono |