React系フレームワーク最新動向2026: Next.js 16 / React Router v8 / TanStack Start / Remix 3 / Astro をどう選ぶか

Last updated at 2026-07-14Posted at 2026-07-14

はじめに

この記事では、2026年7月時点でのReact系フレームワークの最新動向を、公式ドキュメントやブログなどの一次情報に基づいて整理します。
Next.js・React Router v8・TanStack Start・Remix 3・Astro・Waku・RedwoodSDKを中心に、機能・データ・コミュニティの議論・ユースケース別の選び方までをまとめました。

対象読者は、React系フレームワークの技術選定を控えているエンジニア、または現状の選定を見直したいエンジニアです。
「Next.jsだけで判断していいのか」「TanStack StartやRemix 3は実際どこまで進んでいるのか」といった疑問を持つ方に向けて書いています。

前提として、内容はすべて2026年7月時点の情報です。
フレームワークの進化は速く、数ヶ月で状況が変わる可能性があります。
本文中のバージョン・日付は極力明記していますが、参照時は必ず最新の公式情報を確認してください。

なお、この記事はもともと社内向けの調査レポートとして作成したものを、レビュー指摘と追加の一次情報検証を経て書き直しています。
初稿には「TanStack Startがv1.0に到達した」「Remix 3はプレビュー未公開」といった、選定判断に影響しうる誤りがありました。
これらは今回すべて修正し、根拠となる一次情報のURLも本文と参考文献に明記しています。

要点（最初に結論）

React本体は安定期です。React 19系（2026年6月時点で19.2.7が最新パッチ）が本番標準で、React Compiler 1.0（2025年10月正式リリース）がNext.js・Vite・Expoに統合済みです。
Next.js 16は機能網羅性で本比較の中でも範囲が広く、RSCについても現時点で最も完全な実装と評価されています。一方でState of JS 2025では満足度の低下傾向が報告されており、Astroとの差が広がっています。
React Router v8（2026年6月17日リリース）は「意図的に地味」な安定志向のメジャーです。RSC・Server Actionsは早期プレビュー段階で、本番採用は推奨されていません。
TanStack Startは2026年7月時点でv1.0 Release Candidate（RC）です。v1.0の正式リリースには到達していません。RSCについては2026年4月にストリームAPIが公開されましたが、"use server"形式のServer Actionsは意図的に非対応で、createServerFnによる明示的なRPCを使う設計です。
Remixブランドは「Remix 3」として別プロジェクトへ再出発しており、2026年4月30日にBeta Previewが公開済みです。当初表明していたPreactフォーク方針は取り消し線で撤回され、現在は独自のコンポーネントモデルを構築する方針に転換しています。ただし本番採用を検討できる段階ではありません。
RedwoodSDKは最新版がv1.5.7（2026年7月8日リリース）で、ルーティングはdefineAppとroute関数によるコード定義方式です。ファイルシステム規約によるルーティングではありません。
Astroはコンテンツ主体のMPA設計を基本としつつ、ClientRouterによるクライアント遷移やtransition:persistによる状態維持の機能も持っています。複雑なクライアント状態を中心に据えるSPAであれば、React RouterやTanStack Routerの方が自然な選択です。
選定の目安は次の通りです。フルスタック・大規模SaaS・エンタープライズ実績を重視するならNext.js。型安全性やViteエコシステムを重視し、Next.jsの複雑さを避けたいならTanStack StartまたはReact Router v8のFramework Mode。コンテンツ主体のサイトで最小JSを狙うならAstro。単純なSPAで十分ならVite+Reactにルーティングライブラリを足す構成も選択肢です。

機能マトリクス

早見表として、React系の主要フレームワーク8つを比較します。
比較軸は「SPA」「SSR」「SSG」「静的配信のみで運用可」「RSC」「ルーティング方式」「Islands」の7項目です。
1つの表に全項目を入れると読みづらいため、「配信・レンダリング」と「アーキテクチャ」の2表に分けています。
従来の○/△/×だけに頼ると、StableとExperimentalの違いのような成熟度の差が消えてしまうため、RSC列は成熟度ラベル（Stable / Preview / Experimental / 非対応）で示しています。

対象は次の8つです。
表内では紙幅の都合で括弧内の限定条件を省略しているので、行名は次の構成を指すものとして読んでください。

Vite + React（create-viteのreact-tsテンプレート）
Next.js 16
React Router v8（Framework Mode）
TanStack Start（v1.0 RC）
Remix 3（Beta Preview）
Astro
Waku
RedwoodSDK

配信・レンダリング

最初の3列（SPA・SSR・SSG）は、代表的なレンダリング／ナビゲーション構成に対応できるかを示します。
最後の1列は、その成果物を実行時サーバーなしで配信できるかという配信形態を示します。
なお、SPAはナビゲーションの構成、SSR・SSGはHTMLを生成するタイミングを表すもので、これらは排他的ではありません。
「初期表示はSSRやSSG、その後はSPA的なクライアント遷移」という併用構成もあります。

SPA（シングルページアプリケーション）: ページ全体をリロードせず、クライアント側で画面遷移するアプリを構築できるかです。ブラウザ側のJavaScriptで描画するCSR（クライアントサイドレンダリング）を土台に、クライアントルーターで遷移する構成が代表例です。サーバーからRSC payloadを取得して遷移する方式（Waku・RedwoodSDK等）は、CSRのみで完結する狭義のSPAとは異なるため△としています。
SSR（サーバーサイドレンダリング）: リクエスト時にサーバーでHTMLを生成し、クライアントへ返す方式です。
SSG（静的サイト生成）: ビルド時にページを静的なHTMLとして事前生成する方式です。ルート単位の部分的な対応も含みます。ビルド後にページ単位で静的出力を再生成するISR（Incremental Static Regeneration）という発展形もありますが、対応がNext.jsなど一部に限られるため、本表では列にせずNext.jsの詳解で扱います。
静的配信のみで運用可: ビルドで生成したHTML・JavaScript・CSS・データ等を、実行時のアプリケーションサーバーなしで配信する構成が取れるかです。左の3列が「どの構成でレンダリングできるか」であるのに対し、この列は「実行時サーバーなしで運用できる構成があるか」という存在判定です。SSGに対応していても、ISR・Server Actionsのような実行時サーバー前提の機能を使う構成では静的配信にできないため、別の列にしています。

判定は次の基準で付けています。

○: 公式機能として対応
△: 手動実装が必要、Experimental、または狭義のCSR型SPAではなくSPA的遷移にとどまる
×: 単体では未対応（別ツールが必要、または該当機能を公式ドキュメントで確認できない）
未確定: 仕様が確認できない

フレームワーク	SPA	SSR	SSG	静的配信のみで運用可
Vite + React	○※1	△※2	△※3	○
Next.js 16	○	○	○	○※4
React Router v8	○※5	○	○※5	○※5
TanStack Start	○	○	○※8	○
Remix 3	未確定※10	未確定	未確定	未確定
Astro	△※11	○	○	○
Waku	△※12	○	○	○
RedwoodSDK	△※15	○	×※15	×※15

アーキテクチャ

「Islands」は、静的HTMLの中でインタラクティブな部分だけをハイドレーションする設計（部分ハイドレーション）を指します。

フレームワーク	RSC	ルーティング方式	Islands
Vite + React	非対応	任意追加	×
Next.js 16	Stable	ファイル規約	×
React Router v8	Preview※6	△※7	×
TanStack Start	Experimental※9	ファイル規約	×
Remix 3	未確定	未確定	未確定
Astro	非対応	ファイル規約	○
Waku	Stable※13	ファイル規約	×※14
RedwoodSDK	Stable※13	コード定義※16	×

注記

※1 CSRによる描画そのものは標準構成です。ただしテンプレートにルーティング機能は含まれないため、SPAとしての画面遷移にはReact RouterやTanStack Routerの追加が必要です。
※2 Viteは公式SSRガイド（Vite: Server-Side Rendering）を提供していますが、手動セットアップが前提で、フレームワークとしての統合機能ではありません。
※3 Vite公式SSRガイドには、本番SSRと同じ処理でルートを静的HTMLへプリレンダリングする例が示されています（Vite: Pre-Rendering / SSG）。ただしビルトインのCLIではなく手動スクリプトが必要で、Vike等の上位フレームワークを使う選択肢もあるため△としています。
※4 Next.jsはoutput: exportによる静的書き出しを公式サポートしており、実行時サーバーなしで配信する構成が取れるため○としています（Next.js Static Exports、Next.js SPAs）。RSCはこの構成でもビルド時に実行されます。ただしServer Actions・Cookie・ISRなど実行時サーバーを必要とする機能はこの構成では使えません（この種の制約はReact Routerのssr:falseやWakuの静的配信にも共通します）。
※5 React Router v8のreact-router.config.tsでssr:falseを指定するとSPAモードになり、静的ファイルサーバーのみで配信できます。prerender設定（boolean／パス配列／非同期関数）でビルド時プリレンダリングにも公式対応しています（React Router: Pre-Rendering、一次情報で確認済み）。
※6 Server Components/Server Actionsは2026年7月時点で早期プレビュー段階で、本番採用は推奨されていません。本記事では成熟度ラベルとして「Preview」と表記しますが、React Router公式ドキュメント上の表現は「unstable」です。
※7 React Router Framework Modeの標準はapp/routes.tsによるコードベースのルート設定です。ファイル規約によるルーティングは、公式の追加パッケージ@react-router/fs-routesを導入した場合にのみ利用できます（React Router: File Route Conventions、一次情報で確認済み）。
※8 TanStack Startは公式のStatic Prerendering機能でSSGに対応します。静的ルートの自動検出・リンククロール・動的ルートの指定・出力先設定が統合されています（TanStack Start: Static Prerendering）。かつてSPAモードのプリレンダリングでルートルートしか描画されない不具合がありましたが（GitHub Issue #4798）、2025年7月27日に修正・クローズ済みです。
※9 2026年4月13日の公式ブログでRSCストリームを扱うAPIが公開されています。ただし"use server"形式のServer Actionsは意図的に非対応で、createServerFnによる明示的なRPCを使う設計です（TanStack Blog: React Server Components Your Way、一次情報で確認済み）。
※10 Remix 3は2026年4月30日にBeta Previewが公開済みです。ただし本番採用を判断できる段階の技術詳細はまだ確定していないため、各列は「未確定」としています。
※11 AstroのClientRouterはページ遷移をインターセプトしDOMを差し替えることでMPAを疑似SPA化する機能です。Reactなどによるページ全体のCSRではなく、取得した次ページのHTMLをDOMへ差し替える方式であるため△としています。transition:persistディレクティブを使えば、コンポーネントやHTML要素の状態を維持したままクライアント遷移することもできます（Astro Docs: View Transitions）。
※12 Wakuは<Link>とクライアントルーターによるフルリロードなしの遷移に対応します。ただし通常はRSC payloadを取得して画面を更新するRSCベースの構成で、CSRのみで完結する狭義のSPAとは異なります。SSRを無効化する機能もunstable_disableSSRとしてExperimental段階のため△としています（Waku: No SSR）。
※13 RSCの実装自体は標準搭載されていますが、フレームワーク本体の成熟度は別問題です。Wakuの最新版は2026年6月28日公開のv1.0.0-beta.6でBeta段階、RedwoodSDKは2026年7月8日公開のv1.5.7です（いずれもGitHub Releasesで確認）。どちらも新興フレームワークであり、RSCが標準搭載である点と本体の実運用実績は分けて捉える必要があります。
※14 WakuはRSCネイティブ設計であり、Astro/Fresh/HonoXのような「静的HTML＋部分ハイドレーション」という明示的な設計原則（Island Architecture）とは異なる思想のため×としています（Waku create-pages docs）。公式が「Island Architectureではない」と明言した一次情報は確認していません。
※15 RedwoodSDKはCloudflare Workers前提の設計です。SPAはinitClientNavigation()によるSPA的なクライアント遷移に対応しますが、遷移時にWorkerからRSC payloadを取得するサーバー依存の方式で、APIもExperimentalのため△としています（RedwoodSDK: Client-Side Navigation）。SSG・静的配信は、ビルド時にルート別HTMLを生成しWorkerなしで配信する機能を公式ドキュメント（RedwoodSDK: Routing）で確認できず、Cloudflare Worker上での実行が前提のため×としています。
※16 RedwoodSDKはdefineAppとroute関数を使ってルートをコードで列挙する方式です。ファイルパスからの自動マッピングではありません（RedwoodSDK: Routing docs、一次情報で確認済み）。

各フレームワークの詳解

各節は「概要」「主な特徴」「メリット」「デメリット・課題」「適用場面」で統一しています。

React 本体

概要

UIライブラリ本体です。ルーティング・データ取得・SSR/SSG等はフレームワーク側の実装に依存します。

主な特徴

React 19が2024年12月5日に安定版リリースされました。
2026年6月時点のパッチ版はv19.2.7 / v19.1.8 / v19.0.7です（React Versions、React 19 blog）。
React 19.2ではView Transitions、useEffectEvent、<Activity/>が追加されました（React 19.2 announcement）。
<Activity/>は、バックグラウンドUIをDOMとstateを保持したままdisplay:noneで非表示にするコンポーネントです（非表示中のEffectはアンマウントされ、クリーンアップが実行されます）。

React Compilerは2025年10月7日にv1.0が正式リリースされました。
ビルド時に自動でメモ化を行うツールで、useMemo/useCallbackでは難しい条件付きメモ化などの最適化を行います。
Meta社内実績として、本番実測で初期表示・ページ遷移が最大12%高速化、一部インタラクションで2.5倍高速化との報告があります。
Next.js・Vite（vite-plugin-react経由）・Expo（SDK 54以降でデフォルト有効）と統合済みです（React Compiler v1.0）。

Server Components（RSC）は仕様上フレームワーク非依存です。
react.devの記述によれば、Server Componentsを含む機能をフレームワークレベルで採用するには相応の実装作業が必要で、「現時点ではNext.js App Routerが最も完全な実装」とされています（Creating a React App、一次情報）。
安定性・統合度・商用実績で見るとNext.jsが最も成熟している一方、React Router（unstable/preview段階）・TanStack Start（experimental、Server Actions非対応）・Waku・RedwoodSDKにもRSCの実装があります。

メリット

Compiler・Server Componentsといった先端機能を各フレームワークが取り込める土台として安定しています。
Hooksベースの設計は業界標準として定着しています。

デメリット・課題

ライブラリ単体ではルーティング・データ取得・コード分割の解を提供しないため、フレームワーク非採用の場合は自前実装が必要です（Sunsetting CRAでも明言されている課題です）。

適用場面

単体で使うことは稀です。
既存フレームワーク（Next.js/React Router等）やビルドツール（Vite等）と組み合わせて使うのが前提になります。

Next.js

概要

Vercelが開発するフルスタックReactフレームワークです。
App Router・RSC・Cache Componentsなど、本比較の中では機能範囲が広いフレームワークです。

主な特徴

Next.js 16は2025年10月21日にリリースされました（Next.js 16 blog）。
2026年6月時点の安定パッチはv16.2.7〜v16.2.10です。

Turbopackが安定版になり、デフォルトバンドラーになりました。
公式発表では、開発ビルドで2〜5倍高速なプロダクションビルド、最大10倍高速なFast Refreshを実現するとされています。

Cache Componentsという新モデルが導入され、"use cache"ディレクティブでページ・コンポーネント・関数を明示的にキャッシュできます。
Partial Prerendering（PPR）を発展させたもので、旧experimental.pprフラグは廃止・統合されました。

React Compiler統合の設定（reactCompiler）がexperimentalから昇格しましたが、デフォルトは無効のままです。
Model Context Protocol統合によるAIエージェント向けデバッグ支援機能「Next.js DevTools MCP」も追加されました。

破壊的変更としては、Node.js 20.9以降が必須、TypeScript 5.1以降が必須、next lint廃止（Biome/ESLint直接利用へ）、params/searchParams/cookies()等の完全非同期化、AMPサポート撤廃があります。

メリット

SSR・SSG・ISR・RSC・Cache Componentsまで全戦略に対応する機能網羅性があります。
Vercelエコシステムを活用でき、公開指標上でも利用規模が大きいフレームワークです。
RSCについては、現時点で最も完全な実装と評価されています。

デメリット・課題

State of JS 2025では、Next.jsの満足度が低下傾向にあり、Astroとの差が39ポイントに拡大していると報告されています（詳細は後述「パッケージ配布トラフィックの参考値・調査データ」）。
App Router・Server Components・キャッシュモデルの複雑さが不満の要因として指摘されています。
Vercelの最適化への実質的なロックイン感を指摘する声もあります。

適用場面

エンタープライズ・大規模SaaS、Vercelエコシステムを活用できる案件、RSCをフル活用したい案件に向いています。

出典: Next.js 16 公式blog（詳細に確認済み・一次情報）。

React Router v8（Remixの現行系譜）

概要

RemixはReact Router v7への統合を経て、現行はReact Router v8として展開されています。
Remixブランド自体は別プロジェクト「Remix 3」として再出発しており、後述します。

主な特徴

Remixは2024年11月にReact Router v7へ統合されました（Merging Remix and React Router）。
React Router v6とRemix v2は2026年時点でともにEOLとなり、セキュリティパッチは提供されません。

React Router v8は2026年6月17日にリリースされました（React Router v8 blog）。
公式は「意図的に地味」な安定志向のメジャーと位置づけており、ミドルウェア改善、Split Route Modules、型安全なhref、Link maskingなどを追加しています。
Node.js 22.22.0以降、React 19.2.7以降、Vite 7が必須になり、ESM-onlyへ移行しました。
Server Components/Server Actionsは早期プレビュー段階で、本番採用は推奨されていません。

React Routerは「Declarative Mode（基本ルーティング）」「Data Mode（loader/action等のデータ機能追加）」「Framework Mode（型安全・SSR/SSG/SPA戦略を含むフルスタックパッケージ）」の3段階で機能を積み増す設計です（Picking a Mode）。
Framework Modeの標準ルーティングはapp/routes.tsによるコードベースのルート設定です。
ファイル規約によるルーティングを使いたい場合は、公式の追加パッケージ@react-router/fs-routesを導入し、flatRoutes()をapp/routes.tsからエクスポートします（React Router: File Route Conventions、一次情報で確認済み）。
react-router.config.tsでssr:falseを指定すると、実行時のサーバーレンダリングを無効化しビルド時にindex.htmlを生成するSPAモードが使えます（Single Page App (SPA)）。

プリレンダリング（SSG）については、react-router.config.tsのprerender設定で、指定パス（boolean／パス配列／非同期関数で指定）をビルド時に静的生成できます。
ssr:falseと併用し、静的ファイルサーバーのみで配信する構成も可能です（React Router: Pre-Rendering）。

React RouterはShopify・X.com・GitHubなど大規模サービスで採用されているとRemix公式blogが言及しています。
ただしこれは一次情報の自己申告であり、各社の公式発表での裏取りは行っていません。

メリット

Viteベースで明示的な制御ができ、ホスティング非依存性が高い設計です。
3モードの段階的な機能追加により、SPAだけの軽量用途からフルスタックまで1つのライブラリ系列でカバーできます。

デメリット・課題

RSC/Server Actionsは早期プレビューで、本番の主軸にはまだできません。
ファイル規約ルーティングを使うには追加パッケージが必要で、標準のコードベース設定と比べると学習ステップが1つ増えます。

適用場面

型安全性やViteエコシステムを重視し、Next.jsの複雑さを避けたい案件（Framework Mode）に向いています。
単純なSPAが欲しいだけの案件（SPAモード）にも使えます。

TanStack Start

概要

TanStack Router上に構築されたフルスタックフレームワークです。
「明示的な制御がフレームワークの魔法に勝る」という思想でNext.jsに対抗する位置づけです。

主な特徴

2026年7月時点のリリース状況は、v1.0そのものではなくv1.0 Release Candidate（RC）です。
TanStack公式のドキュメントページには「RCを固定して使い、1.0に向けて準備中」という趣旨の記述があり、機能面はfeature-completeとされているものの正式な1.0リリースには至っていません（TanStack Start latest docs、一次情報で確認済み）。
2025年9月23日公開のブログ記事「TanStack Start v1 Release Candidate」でも、「v1.0 Release Candidateに到達した。これはフィードバックを踏まえて1.0としてリリースする予定のビルドである」という趣旨が明記されています（TanStack Start v1 RC announcement）。
npmの@tanstack/react-start最新バージョンは1.168.27ですが、これはTanStackのモノレポ内で複数パッケージのバージョンを共有増分するスキームによる数値とみられ、公式ドキュメント上の「RC」表記と矛盾するものではないとみられます。

RSCについては、2026年4月13日公開のブログ記事「React Server Components Your Way」で、RSCストリームを扱う公式APIが発表されています（TanStack Blog: React Server Components Your Way、一次情報）。
一方で"use server"形式のServer Actionsは意図的に非対応です。
公式ブログでは、既存の攻撃ベクトルの存在や、暗黙のネットワーク境界を生む懸念を理由に挙げています。
代わりにcreateServerFnによる明示的なRPCを使う設計で、クライアント・サーバー境界を意図的に明示的にしています。

Viteベースで、型安全なファイルベースルーティング、アイソモルフィックなサーバー関数、フルドキュメントSSR、ストリーミング、Vite/Rsbuild両対応を備えています。
SSRが不要な場合、アプリの「シェル」のみを含む静的HTML（デフォルト/_shell.html）を生成しクライアントでブートストラップする専用SPAモードもあります（TanStack Start: SPA mode）。
ルート単位でSSRのオン/オフを切り替えられるSelective SSRという機能もあります（Selective SSR docs）。

TanStack RouterとReact Router v8の比較では、「TanStack Routerは型安全性で優位（検索パラメータ・パスパラメータ・loaderデータが設定だけで完全に型付けされる）」「TanStack Routerはダッシュボード・管理画面等のクライアント重視SPAに適し、React Router Framework ModeはRemix由来のloader/action/SSRを日常的に使うフルスタックアプリに適す」という整理があります（TanStack Router vs React Router v7 (PkgPulse)）。

メリット

型安全性が高い設計です。
SPAモード・Selective SSRなど、レンダリング戦略の柔軟性が高いのも特徴です。
Vite/Rsbuildベースでホスティング非依存性が高い点も評価されています。

デメリット・課題

2026年7月時点でv1.0 RC段階であり、正式な1.0リリースは今後です。
RSCについては、ストリームAPI自体は提供されているものの、"use server"形式のServer Actionsには意図的に非対応で、その代わりにcreateServerFnを使う設計思想を理解する必要があります。
過去にSPAモードのプリレンダリングにルートルートしか描画されない不具合がありましたが（GitHub Issue #4798）、2025年7月27日に修正済みです。

適用場面

型安全性やViteエコシステムを重視し、Next.jsの複雑さを避けたい案件に向いています。
クライアント重視のダッシュボード・管理画面・検索UI（URLに複雑な状態を持たせるアプリ）にも適しています。

GitHub: TanStack Routerで約14,800 star（2026年7月時点、GitHub）。

Remix 3

概要

Remixブランドは、React Routerへの統合で一度収束したように見えましたが、「Remix 3」として全く別の方向性で再始動しています。

主な特徴

2025年5月28日公開のブログ記事「Wake up, Remix!」で、Remix 3の構想が発表されました（Wake up, Remix!）。
このブログの生Markdownソースを確認したところ、「Preactをフォークして使う」という当初の記述は取り消し線（~~...~~）で明確に打ち消されており、続けて「我々はこれまでに見たことがないほどWebに近いと感じる、独自のコンポーネントモデルを構築している」という文が続いています。
つまり、Preactフォークは撤回済みの旧方針で、現在の方針は独自のコンポーネントモデルの構築です。

2026年4月30日には、Remix 3のBeta Previewが公開されました（Remix 3 Beta Preview）。
GitHubのremix-run/remixリポジトリにはremix@3.0.0-beta.5タグが実在することを確認しています。
Beta Previewのブログ本文には「Preact」「fork」という単語は登場せず、コンポーネントモデルについては「プレーンなJavaScript変数によるstate、明示的な更新、中断可能な非同期処理、mixinで構成される再利用可能な振る舞い」という、特定のvdomライブラリに依存しない独自の設計哲学が説明されています。

「Model-First Development（AIワークフロー最適化）」「Web APIベース」「コンパイル時解析よりランタイム設計優先」「依存ゼロを目指す」等の原則を掲げていますが、2026年7月時点ではBeta Previewの段階であり、本番採用を判断できる技術詳細はまだ確定していません。

メリット

React Routerという既存の依存関係を切り離し、Web標準APIに寄せた設計を志向している点は、今後の方向性として注目に値します。
Beta Previewが公開されたことで、実際のAPI・設計思想を確認できる段階になっています。

デメリット・課題

Beta Preview段階であり、本番採用の判断はまだできません。
当初のPreactフォーク方針から独自のコンポーネントモデル構築へ大きく方針転換しているため、既存のRemix/React資産との互換性・移行パスは今後の検証が必要です。

適用場面

現時点では新規プロジェクトへの採用対象ではなく、動向を注視する段階です。
React Router系の将来動向を気にする案件は、当面はReact Router v8を採用しつつRemix 3のBeta Previewを追う形が妥当です。

Astro（React統合可能な選択肢として）

概要

Islands Architecture（サーバーでHTML生成し、インタラクティブ部分のみ個別にハイドレーションする方式）を採用するコンテンツ重視フレームワークです。
React・Vue・Svelteなどを1ページ内で混在させることもできます。

主な特徴

Astro v5.0（2024年末）でServer Islandsが導入されました。
動的・パーソナライズされた「島」をオンデマンドでサーバーレンダリングしつつ、ページの他の部分は積極的にキャッシュ可能にする機能です（Astro Docs: Server islands）。
Server IslandはAstroコンポーネント自体である必要があり、Reactクライアントコンポーネント内に直接埋め込むことはできない制約があります。

ClientRouter（旧ViewTransitions）は、ページ遷移をインターセプトしDOMを差し替えることで、MPAを疑似SPA化する組み込みルーターです。
この仕組みはAstroの基本設計がMPA・コンテンツサイト向けであることを前提にしていますが、SPA的な使い方を一切できないわけではありません。
transition:persistディレクティブを使うと、ページ遷移をまたいでコンポーネントやHTML要素の状態を維持できます。
公式ドキュメントには、<video>要素が新しいページに遷移しても再生を継続する例や、フレームワークコンポーネント（アイランド）の状態を保ったまま画面に残せる例が挙げられています（Astro Docs: View Transitions、一次情報で確認済み）。
2026年時点でView Transitions APIのブラウザサポートは85%超に達しており、ネイティブAPIとAstro組み込みコンポーネントのどちらを使うか選べる状況になっています。

最新版はastro@7.0.7（2026年7月8日リリース）で、GitHub star数は約61,000（2026年7月時点）です。

メリット

最小JS・高パフォーマンスを実現しやすい設計です。
State of JS 2025ではメタフレームワーク部門で満足度トップとなっており、Next.jsとの差は39ポイントです。
Server Islandsにより部分的な動的コンテンツにも対応できます。

デメリット・課題

RSCには非対応で、Reactアイランドは通常のクライアント/サーバーレンダリングとして動作します。
MPA・コンテンツサイトが基本設計であるため、複雑なクライアント状態を中心に据えたアプリケーションでは、React RouterやTanStack Routerの方が自然な選択になるとみられます。
ClientRouterやtransition:persistでカバーできる状態保持には限界があり、大規模なクライアント状態管理をAstro単体で完結させる用途には向きません。

適用場面

コンテンツ主体サイト（マーケティング・ブログ・ドキュメント・LP）に向いています。
部分的な動的要素や簡単なページ間の状態維持が必要な場合も、Server Islandsとtransition:persistで対応できる範囲であれば選択肢になります。

Waku

概要

Daishi Kato氏（Jotai/Zustandのメンテナ）による、RSCサポートに特化した軽量フレームワークです（Waku公式、GitHub）。

主な特徴

src/pagesによるファイルベースルーティングを採用しています。
ページ・レイアウト・スライス単位でstatic（SSG）/dynamic（SSR）のレンダリングを混在させることができます（Waku create-pages docs）。
2026年2月にv1.0 alphaへ到達し（InfoQ: Waku reaches alpha）、2026年6月28日にはv1.0.0-beta.6が公開されてBeta段階へ進んでいます（Waku GitHub Releases、GitHub APIで確認）。
公開APIサーフェスは安定し、以後はバグ修正・互換性改善にフォーカスしています。

メリット

Next.js App Routerの複雑さを避けた「RSCのみを提供する」軽量設計です。
ほぼ静的なサイトに一部動的ルートを混在させる用途に強みがあります。

デメリット・課題

RSCネイティブでありIsland Architectureとは異なる設計思想です（機能マトリクスの判定根拠は上記注記参照）。
エコシステム・採用実績はまだ薄い状況です。

適用場面

Cloudflare/Netlify等へのRSCネイティブなデプロイを試したい新興・実験的案件に向いています。

RedwoodSDK

概要

RedwoodJSが2024年にGraphQL中心の旧アーキテクチャから方向転換し、Cloudflare Workers向けにゼロから再構築したサーバーファーストのReactフレームワークです（RedwoodSDK公式、GitHub）。

主な特徴

最新版はv1.5.7（2026年7月8日リリース）です。
npm registryのdist-tags.latestとGitHub Releasesの両方で確認しており、直近もv1.5.6（7月6日）、v1.5.5（7月2日）、v1.5.4（7月1日）、v1.5.3（6月29日）と継続的にリリースが続いています（RedwoodSDK GitHub Releases、一次情報で確認済み）。

ルーティングはdefineAppとroute関数を使ってコードでルートを列挙する方式です。
ファイルパスから自動でルートが生成されるファイルシステムルーティングではありません（RedwoodSDK: Routing docs、一次情報で確認済み）。
src/worker.tsx内でroute("/", handler)のようにルートを明示的に定義していく設計です。

RSC・Server Functions・D1データベース・Passkey認証・Queues/Crons・R2ストレージを標準搭載しています。
Viteプラグインとして動作し、Cloudflareへワンコマンドデプロイできます。

メリット

Cloudflareエコシステム（D1/R2/Queues等）とRSCが統合済みで、サーバーファースト構成をゼロから組まずに始められます。

デメリット・課題

Cloudflare Workers前提の設計であり、自由度は低めです。
ビルド時にルート別HTMLを生成しWorkerなしで配信するSSG／静的エクスポート機能は公式ドキュメントで確認できず、実行時のWorker動作が前提です。
Cloudflareエコシステムの前提知識が必要です。

適用場面

Cloudflareネイティブで最新のRSCアーキテクチャを試したい、新興・実験的な案件に向いています。

メタフレームワーク不要のケース（Vite + Reactという選択）

概要

「SPAだけ作れればよい」案件では、Next.js等の重量級メタフレームワークを使わず、Vite+Reactを土台にルーティングライブラリを足す構成でも十分なケースがあります。

主な特徴

Create React App（CRA）は2025年2月14日に公式に非推奨化されました（Sunsetting Create React App）。
React 19対応版を最後に、以後は「メンテナンスモード」（アクティブなメンテナが不在）です。
React公式は「Next.js・React Router・Expo等のフレームワークへの移行」または「Vite・Parcel・Rsbuildのようなビルドツールでゼロから構築」を代替として案内しています。

react.devの新規プロジェクト作成ガイド（Creating a React App）は「新しいアプリ・サイトを作るならフレームワークから始めることを推奨する」と明言し、Next.js（App Router）・React Router（v7以降）・Expoの3つを名指ししています。
Viteは直接の推奨導線ではなく、「ビルドツールからゼロで組み立てる場合」のガイドへのリンクとして言及される位置づけです。
ただしこれは「Viteが非推奨」という意味ではなく、React公式が原則としてフレームワークを起点にすることを勧めつつ、特殊な制約や学習目的でのビルドツールからの構築も正式な選択肢として案内している、というのが正確な立場です。

npm create vite@latest -- --template react-tsによるVite+Reactの構成は、HMR・JSX対応が標準搭載され、SPA構築の実践では引き続き広く使われています。
ファイルベースルーティングが欲しい場合は、React Router v8のFramework Mode（ssr:falseでSPAモード、または@react-router/fs-routesでファイル規約）やTanStack Router/TanStack Startの専用SPAモードを追加する構成が該当します。

メリット

学習コストが低く始められます。
ビルド・デプロイの自由度が高く、SSR/RSC等の複雑なモデルを気にせず開発できます。

デメリット・課題

React公式の主要な推奨導線からは外れているため、今後のドキュメント・エコシステムの手厚さはフレームワーク採用時より薄くなる可能性があります（推測）。
CRA自体は動作しますが、新規プロジェクトでの利用は非推奨です。

適用場面

社内ツール・管理画面・ダッシュボードなど、SEO・SSRが不要でクライアントのみで完結するアプリに向いています。
既存APIサーバーが別にあり、フロントは薄いSPAで十分な構成にも適しています。

機能・特徴比較表

各フレームワークの特徴を一覧にしました。
1つの表に全項目を詰めると読みづらいため、「リリース状況とレンダリング」「開発体験とデプロイ」の2表に分けています。
各セルは要点のみの短い表現にしているので、判定の細かい条件や背景は各フレームワークの詳解節と機能マトリクスの注記を参照してください。

リリース状況とレンダリング

フレームワーク	最新版（2026年7月時点）	レンダリング戦略	RSC対応
React 本体	19.2.7	フレームワーク依存	仕様提供元
Next.js	16.2.10	SSR・SSG・ISR・RSC・Cache Components	Stable（最も完全な実装）
React Router v8	v8.2.0	SSR / SPA / 静的（Framework Mode）	Preview（本番未推奨）
TanStack Start	v1.0 RC	SSR・ストリーミング＋専用SPAモード	Experimental（Server Actions非対応）
Astro	`astro@7.0.7`	静的優先＋Server Islands	非対応
Remix 3	3.0.0-beta.5	未確定（独自コンポーネントモデル志向）	未確定
Waku	v1.0.0-beta.6	RSCネイティブ（static/dynamic混在可）	ネイティブ設計（本体はBeta）
RedwoodSDK	v1.5.7	RSC・SSR・ストリーミング・リアルタイム	Stable（ネイティブ設計）

開発体験とデプロイ

フレームワーク	ルーティング	データ取得	デプロイ先自由度	学習コスト
React 本体	非提供（Router別途）	非提供	N/A	中
Next.js	ファイル規約（App Router）	Server Actions・`fetch`拡張	Vercel最適	高
React Router v8	コード定義（ファイル規約は任意追加）	Loader / Action	高（Vite前提）	中
TanStack Start	ファイル規約（型安全）	サーバー関数	高（Vite/Rsbuild）	中〜高
Astro	ファイル規約	フレームワーク非依存	高（静的〜SSR）	低〜中
Remix 3	未確定	未確定	未確定	未確認
Waku	ファイル規約（`src/pages`）	RSC経由	詳細未確認	低〜中
RedwoodSDK	コード定義（`defineApp`/`route`）	Server Functions（Cloudflare統合）	低（Cloudflare前提）	中

表から省いた補足は次のとおりです。
Next.jsのデプロイはBuild Adapters API（alpha）で他プラットフォーム対応を強化中です。
TanStack StartのRSCはストリームAPIの提供で、"use server"の代わりにcreateServerFnによる明示的RPCを使います。
AstroはClientRouterによる疑似SPA化とtransition:persistによる状態維持が可能です。
Remix 3はPreactフォーク方針を撤回し、Web API準拠の独自コンポーネントモデルを志向しています。
学習コストの背景（Next.jsのキャッシュモデル、RedwoodSDKのCloudflare前提知識など）は各詳解節に記載しています。

パッケージ配布トラフィックの参考値・調査データ

npmのダウンロード数やGitHubのStar数は、CI・ミラー・botのトラフィックを含む集計値です。
実際の採用規模を直接示す数値ではなく、あくまで参考値として扱う必要があります。

npm週間ダウンロード数（npm registry API実測値、2026年7月5日〜11日）

パッケージ	週間ダウンロード数	取得日
`react`	153,316,909	2026-07-13（npm API）
`next`	44,699,800	同上（npm API）
`react-router`	42,596,717	同上（npm API）
`@tanstack/react-router`	18,898,696	同上（npm API）
`@tanstack/react-start`	18,390,493	同上（npm API）
`astro`	3,924,883	同上（npm API）
`@remix-run/react`	1,121,896	同上（npm API）

@tanstack/react-routerと@tanstack/react-startの週間ダウンロード数は、RCという段階にしては大きく、Astroの約4.8倍という規模になっています。
npm registryの生ダウンロード数はCI/ミラー/bot経由のトラフィックを含み、実際の人間による採用規模を必ずしも反映しない既知の限界があります。
この数値は一次情報（npm公式API）から取得した生データとして提示しますが、実採用規模の指標としては割り引いて解釈する必要があります（推測）。

GitHub Star数（2026年7月時点、各リポジトリ実測値）

GitHub Starも、採用規模や本番利用率を直接示す指標ではなく、認知・関心の参考指標として捉える必要があります。

リポジトリ	Star数	最新リリース
vercel/next.js	約141,000	v16.2.10（2026年7月1日）
withastro/astro	約61,000	`astro@7.0.7`（2026年7月8日）
remix-run/react-router	約56,500	v8.2.0（2026年7月8日）
TanStack/router	約14,800	2026-07-01付リリース

出典: 各GitHubリポジトリページ（Next.js、Astro、React Router、TanStack Router）。

State of JS 2025（2026年3月公開）

State of JS 2025（公式サイト）の幸福度（happiness）指標の回答者数は11,411名です。

Next.jsの満足度は68%から55%へ低下したと報告されています。
この数値はInfoQ記事（InfoQ: State of JS 2025まとめ）による二次情報であり、一次情報のState of JS 2025サイトでの直接確認はできていません。
そのため本文の主張としては、具体的な数値そのものよりも「Next.jsの満足度は低下傾向にあり、Astroとの差は39ポイントに拡大している」という傾向を軸に扱います。

使用率は59%でトップですが、ポジティブ21%・ネガティブ17%と最も賛否が分かれるプロジェクトの一つとされています。
「最も好かれているプロジェクト13位」かつ「最も嫌われているプロジェクト5位」という両極端な評価も報告されています。
Astroの満足度はメタフレームワーク部門でNext.jsに対し39ポイント差でトップです。
不満の要因としては、Server Components・App Routerの複雑化への批判が挙げられています（同記事。ただし要因ごとの寄与率まで公式集計で示されているわけではありません）。

TanStack Startは調査開始時点でベータを脱していなかったため正式集計対象外ですが、「Other Meta-Frameworks」枠で235件の言及があり、期待の高さがうかがえます。

Stack Overflow Developer Survey 2025

公式サイトによると、この調査は回答者数49,000以上、177カ国、62設問・314技術を対象としています。

全回答者ベースの使用率は以下の通りです。

技術	使用率（全回答者）	使用率（プロフェッショナル開発者）
React	44.7%	46.9%
Next.js	20.8%	21.5%
Vue.js	17.6%	18.4%
Angular	18.2%	19.8%
Svelte	7.2%	6.9%
Astro	4.5%	4.3%

コミュニティの議論

Next.jsへの集中と反発が見られます。
npmダウンロード数・GitHub star・SO調査使用率のいずれでもNext.jsが公開指標上でトップですが、State of JS 2025では満足度が低下傾向にあり、Astroとの差が39ポイントに拡大しています。
App Router・Server Components・キャッシュモデルの複雑さが不満の要因として繰り返し指摘されています。
Next.js 16のCache Componentsは、この複雑さ批判への対応（"use cache"による明示的キャッシュ制御への回帰）という側面があるとみられます（推測）。

Vite系の台頭も見られます。
React Router v8（Vite 7必須・ESM-only化）、TanStack Start（Vite/Rsbuildベース）はいずれもViteエコシステムを基盤に採用しています。
「Next.js固有のバンドラー・キャッシュモデルより、Viteの標準的な仕組みの上に明示的な制御を積む」という設計思想が、複数の新興・刷新フレームワークで共通しています。

軽量経路をめぐっては、公式の推奨導線と実務でのニーズにギャップがあります。
CRAの公式非推奨化（2025年2月）とreact.devの「フレームワーク推奨」路線がある一方で、Vite+ReactへReact Router/TanStack RouterのSPAモードを足す軽量構成は実務で使われ続けています。
React公式が非推奨としているのはCRAであり、Viteによるゼロからの構築自体は正式な選択肢として案内されている、という点は正確に区別する必要があります。

Remix / React Routerの再編も注目点です。
RemixブランドはReact Routerへの統合で一度収束したように見えましたが、「Remix 3」として全く別の方向性（独自のコンポーネントモデル・依存ゼロ志向）で再始動しています。
当初表明していたPreactフォーク方針は撤回され、Web APIへ寄せた独自設計へ転換した点は、React本体への依存すら見直す動きとして注目に値します。
2026年4月30日にBeta Previewが公開済みではありますが、実態はまだ検証段階です。

RSCの標準化は道半ばです。
RSCは仕様上フレームワーク非依存ですが、react.devの表現によれば「現時点ではNext.js App Routerが最も完全な実装」とされています。
安定性・統合度・商用実績ではNext.jsが最も成熟している一方、React Router（unstable/preview）・TanStack Start（experimental・Server Actions非対応）・Waku・RedwoodSDKにもRSCの実装があります。
Waku・RedwoodSDKのようなRSCネイティブ設計の新興フレームワークが、この状況を変えうる候補として言及されています。

コンテンツ配信とアプリケーション配信の分岐も明確になっています。
Astroはコンテンツ主体サイト（マーケティング・ブログ・ドキュメント）で満足度トップを維持し、Next.js/React Router/TanStack Startはアプリケーション寄りの用途で競合するという住み分けが進んでいます。

ユースケース別の選び方

SPAを作るとき

フレームワーク機能（ファイルベースルーティング・型安全性）が欲しい場合は、React Router v8のSPAモード（ssr:false）またはTanStack Router/TanStack StartのSPAモードが候補になります。
TanStack Routerは検索パラメータ・パスパラメータ・loaderデータの型安全性で優位とされ、ダッシュボード・管理画面向きです。
React Router Framework Modeは将来SSRへ拡張したい場合に移行しやすい構成です。

最小構成でよい場合は、Vite+React（create-vite react-ts）にReact Router/TanStack Routerを追加する構成でも十分です。
ただし2026年時点のReact公式ガイドはこの構成を主要導線としては案内していない点に留意してください。

CRAは2025年2月に公式非推奨化されており、新規プロジェクトでの採用対象にはなりません。

フルスタック開発

エンタープライズ・大規模SaaS、Vercelエコシステムを活用できる案件にはNext.js 16が有力です。
機能網羅性・エコシステムの面で本比較の中では範囲が広いフレームワークですが、複雑さとロックイン（Vercel最適化）は許容する前提になります。

Next.jsの複雑さやキャッシュモデルを避けたい、型安全性を重視したい場合は、TanStack StartまたはReact Router v8のFramework Modeが候補です。
Viteベースで明示的な制御ができますが、TanStack StartはRSCがExperimental段階（Server Actions非対応）、React Router v8のRSCもPreview段階です。

Cloudflareエコシステム前提でフルスタックを組みたい場合はRedwoodSDKが候補です。
D1/R2/Queues等が統合済みですが、自由度は低めです。

エッジで軽量なフルスタックを試したい（実験的）場合はHonoXも候補です（alpha運用のリスクを許容できる場合、詳細は後述の付録参照）。

パフォーマンス重視（RSC vs Island Architecture）

RSCで最新アーキテクチャを試したい（新興・実験的）場合は、WakuまたはRedwoodSDKが候補です。
RSCネイティブ設計で最小クライアントJSを狙えますが、採用実績・エコシステムはまだ薄く、破壊的変更リスクを許容できる案件向けです。
安定性・統合度・商用実績で見るとNext.jsが最も成熟している点も踏まえて判断してください。

Island Architectureで部分的にインタラクティブにしたい場合は、Astro（React/Vue/Svelte等を混在可）、Deno環境ならFresh、Honoエコシステムなら HonoXが候補です。
いずれもJS配信量を絞りつつ必要な部分だけハイドレーションする設計です。

RSCとIsland Architectureは「サーバーで多くを解決する」という方向性は共通しますが、設計モデルが異なります（機能マトリクスで両者を別列にした理由でもあります）。
RSCはサーバーでコンポーネントを実行し、そのレンダリング結果をクライアントへ渡すモデルです（クライアントからサーバー処理を呼び出すServer Functionsは、RSCと関連はあるものの別の機能です）。
Island Architectureは、静的HTMLを基本にインタラクティブな部分だけをハイドレーションするという設計原則です。

JAMstack・コンテンツサイト

コンテンツ主体サイト（マーケ・ブログ・ドキュメント・LP）にはAstroが有力です。
最小JS・高パフォーマンスで、State of JS 2025では満足度トップです。
Server Islandsで部分的な動的コンテンツにも対応できます。

Gatsbyは2026年時点で新規採用を積極的には推奨しません（詳細は後述「対象外としたフレームワーク」節）。
既存Gatsbyサイトの延命は可能ですが、新規案件では優先度が低いとみられます。

Deno環境かつコンテンツ寄りサイトであればFreshも候補になりえます。
開発は活発ですが、採用実績・エコシステムはAstroに比べ薄く、この点は未確認です。

モバイルアプリ（参考）

Expo / React Nativeが候補です。
New Architecture必須化・React Compilerデフォルト有効など高速化が進んでいますが、本比較のWeb案件の代替にはなりません。
詳細は後述の付録を参照してください。

付録: 近縁の選択肢・関連技術

Fresh・HonoX・Farm・Expoは、React系フレームワークそのものではない、またはWeb案件の主対象ではないため、主比較から分離して紹介します。

Fresh（Deno / Preactベース）

概要

DenoチームによるWeb Standards API・Preact・Islands Architectureベースのフルスタックフレームワークです（Fresh公式、GitHub）。
PreactベースのためReact系そのものではありません。

主な特徴

「デフォルトでJSゼロ配信、全ページをサーバーレンダリングし、インタラクティブな部分だけを明示的に"island"としてopt-inする」設計です。
Fresh 2.x系はプログラマティックなApp() API、Vite統合オプション、起動時間短縮、CORS/CSRF/CSP組み込みプラグインなどを追加しています（Deno: An Update on Fresh）。
2026年7月時点の最新版は@fresh/core v2.3.3（2026年4月公開、jsr.io の @fresh/core ページ）です。
deno.com自体がFreshで稼働しており、開発は停滞せず活発です。

メリット

Preactベースのため軽量・高速です。
デフォルトでJSゼロ配信のIsland Architectureにより、配信JS量を最小化できます。

デメリット・課題

Reactエコシステム（ライブラリ・型定義等）をそのまま使えない場面があります(一般的なPreact/React互換性の制約、個別検証はしていません)。
Deno実行環境が前提になります。
SSG（静的書き出し）対応の詳細は一次情報で個別確認しておらず、未確認です。

適用場面

Deno環境でのIsland Architectureベースの高速サイト構築に向いています。
React系プロジェクトへの直接採用ではなく、近縁の選択肢として比較検討する位置づけです。

HonoX（Honoベース）

概要

軽量Webフレームワーク「Hono」上に構築されたフルスタックメタフレームワークです（GitHub: honojs/honox）。
Honoベースであり、React系そのものではなく、UIライブラリを差し替え可能な設計です（React/Preact/hono/jsx等を選べます）。

主な特徴

ファイルベースルーティング、Honoによる高速SSR、Islandsハイドレーション（インタラクションが必要な部分だけJSをハイドレート）を提供します。
@hono/vite-ssgによりSSGにも対応しています（Hono SSG Helper）。
2026年7月時点でも"alpha"段階が継続しており、同一メジャーバージョン内で破壊的変更が入りうるzerover運用です。
最新リリースはv0.1.59（2026年7月10日、GitHub Releases）ですが、日付表記の年の読み取りに若干の不確実性があり未確認です。
直近も継続的にコミット・リリースがあり開発は活発です。

メリット

Hono自体が軽量・高速なエッジ向けフレームワークであるため、HonoXも同様の軽量性を持ちます。

デメリット・課題

alpha段階が長期化しており、本番採用には破壊的変更のリスクを織り込む必要があります。

適用場面

Cloudflare Workers等のエッジ環境で軽量なフルスタックアプリを組みたい場合に向いています。

Farm（Vite互換バンドラー）

概要

Rust製の高速バンドラーです（Farm公式）。
Vite互換のプラグイン/APIを持つビルドツールであり、ルーティング・SSR等を備えたアプリケーションフレームワークではありません。

主な特徴

v1.0はGitHub Releases上で2024年4月15日付です（Farm v1.0 Releases）。
その後も更新は続いており、@farmfe/coreの2026年7月時点の最新版は1.7.11です（npm registryで確認）。
2026年時点では、Vite公式が進めるRust製バンドラーRolldownとの比較の文脈で語られることが多いです（PkgPulse: Farm vs Rolldown vs Vite）。

メリット

Vite互換のため、React SPAのビルド土台としての置き換えを狙えます。
ビルド高速化を主眼とする設計です。

デメリット・課題

SSR/SSG/RSC・ルーティング等のフレームワーク機能を持ちません。
Vite本体がRolldownによる高速化を進めており、独立バンドラーとしての立ち位置は流動的とみられます（推測）。

適用場面

ビルド速度がボトルネックの大規模SPAで、Vite代替のバンドラーとして検討する枠です。
フレームワーク選定の直接の比較対象ではありません。

Expo / React Native

概要

モバイルアプリ開発が主用途であり、本記事のWeb向けReactフレームワーク比較の主対象ではありません。

主な特徴

Expo SDK 56はReact Native 0.85系・React 19.2を搭載し、Hermesがデフォルトエンジンです。
なお2026年7月時点ではSDK 57系（expo@57.0.4）が公開されており、SDK 56は1世代前のリリースです（npm registryで確認）。
Android低速起動が40%改善、iOSビルドが50%以上高速化、GCポーズ時間73%削減との報告があります（dev.to記事）。
これは二次情報のみで、Expo公式changelogでの一次情報裏取りはできていません。

SDK 55以降、Legacy Architectureは完全撤廃され、New Architectureが必須化されました（無効化不可）。
React CompilerはExpo SDK 54以降でデフォルト有効です（React Compiler公式blogで確認済み、一次情報）。

メリット

モバイル・Web双方への展開が1コードベースで狙えます。
React Compiler・New Architectureにより高速化が進行中です。

デメリット・課題

Web専用案件の代替にはなりません。

適用場面

モバイルアプリ開発（Web案件ではない）に向いています。

対象外としたフレームワーク

Gatsbyは2026年時点でメンテナンスモードにあるとみられます。
Netlifyが2023年2月にGatsby Inc.を買収しましたが（Netlify press release）、買収後数ヶ月でコアチームの大半が離脱し、リリース頻度も大きく低下したと複数の解説記事が指摘しています（Robin Wieruch: Is Gatsby.js Still Worth Using in 2026?）。
それでも開発自体は完全停止しておらず、最新版はgatsby@5.16.1（2026年2月10日リリース、React 19・Node.js 24対応を含む）とパッチ提供は継続しています（GitHub Releases）。
一方でプラグインエコシステム（かつての最大の強み）は多くが長期未更新で放置されているという指摘があり、新規プロジェクトでの採用は慎重に見る意見が多い状況です。
Netlifyは公式にはGatsby JSの保守・エンタープライズ向け安定性への継続コミットを表明していますが（Gatsby Cloud自体は2023年にsunset）、実態としては新規採用の優先度は低いと判断し、本記事でも引き続き対象外としました。
なお「メンテナンスモード」という評価自体は複数の二次情報に基づく総合判断であり、Netlify/Gatsby公式がそう明言した一次情報は確認できていません。

Vike（旧vite-plugin-ssr）等の小規模Vite系は、Vite系代替の潮流としてReact Router v8 / TanStack Startの節で代表させ、個別調査は省略しました。

確認できていないこと

以下は、本記事の作成過程で確認できなかった点や、二次情報にとどまる点です。
正直さを保つため、削除せずまとめて残します。

Turbopack採用率（開発セッション50%以上・本番ビルド20%）はNext.js 16公式blog記載のVercel自己申告値で、独立した検証データはありません。
State of JS 2025のNext.js満足度「68%→55%」という具体値はInfoQ（二次情報）のみで確認しており、一次情報サイトでの直接確認はできていません。
Remix 3の技術詳細（RSC採用の有無を含む）はBeta Preview段階のため引き続き未確定です。Preactフォーク方針の撤回と独自コンポーネントモデルへの転換自体は一次情報（生Markdownソースの取り消し線）で確認済みですが、実際のブラウザ表示上の視覚的な取り消し線表示は確認していません。
remix@3.0.0-beta.5タグの正確な日付には表記ゆれがあり確定できていません。beta.1〜4の個別存在も直接確認していません。
Expo SDK 56の性能改善数値（Android起動40%改善等）は二次情報（dev.to記事）からのみ確認しており、Expo公式changelogでの一次情報裏取りは未実施です。
Waku・RedwoodSDKの正確な週間ダウンロード数は未取得です（新興プロジェクトのため変動が速く、本記事では優先度を下げました）。
npm週間ダウンロード数、特にTanStack系パッケージの高さの要因分析は推測にとどまります。npm registry側の集計ロジック（ミラー・CIキャッシュの扱い）についての公式説明は確認できていません。
React Router導入企業（Shopify・X.com・GitHub）の記載はRemix公式blogの自己申告であり、各社の公式発表での裏取りは行っていません。
TanStack StartのServer Actions対応（"use server"形式）の具体的な提供時期・提供予定の有無は確認できていません。
RedwoodSDKについては、ビルド時にルート別HTMLを生成しWorkerなしで配信するSSG／静的エクスポート機能を公式ドキュメントで確認できませんでした。存在を確認できないため機能マトリクスではSSG・静的配信を×としていますが、ドキュメント全体を網羅的に走査したわけではありません。
Waku・RedwoodSDKを「Island Architectureではない」と判定した根拠は解説記事の記述と設計思想の理解に基づくもので、公式が明示的にそう述べた一次情報は確認していません。
FreshのSSG（静的書き出し）対応の詳細は一次情報で個別確認していません。
HonoXの最新リリース日表記（v0.1.59）は取得ツールの年表記変換に若干の不確実性があり、完全な一次情報再確認はしていません。
react.devの新規プロジェクト作成ガイドの最終更新日は本文に明記がなく、2026年7月時点で閲覧した内容を基にしています。
React Router・TanStack Start・Waku・RedwoodSDKの「RSC実運用可否」を横並びで比較する記述は、react.dev自体がこの比較を行っていないため、react.dev以外の二次情報を一部参考にしています。各公式ドキュメントの直接確認は今回一部にとどまっています。

まとめ

2026年7月時点のReact系フレームワークは、Next.jsが機能網羅性とRSCの成熟度で先行しつつ、満足度面では低下傾向という難しい局面にあります。
TanStack Start・React Router v8はいずれもVite基盤で明示的な制御を志向していますが、RSCについてはTanStack StartがExperimental、React Router v8がPreview段階で、どちらも本番の主軸にはまだ据えられません。
Remix 3はBeta Previewが公開されたばかりで、独自のコンポーネントモデルという新方針への転換が進行中です。
RedwoodSDK・Wakuのようなサーバーファースト・RSCネイティブな新興フレームワークも選択肢として育ちつつありますが、採用実績はまだ薄い段階です。
Astroはコンテンツ主体サイトで満足度トップを維持しており、状態維持機能の拡充によりMPAとSPAの中間的な使い方の幅も広がっています。

選定においては、機能の有無だけでなく「Stable」「Preview」「Experimental」といった成熟度の違いを踏まえることが重要です。
特にRSC対応は、フレームワークによって提供範囲・安定度が大きく異なるため、公式ドキュメントで最新のステータスを都度確認することをおすすめします。

参考文献

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up