モダンReactアプリを支えるライブラリ群

モダンなReactアプリは、Reactそのものに加えて、予測可能な少数のライブラリで構成されています。サーバーステートのデータフェッチング用に1つ、クライアントステート用に1つ、ルーティング用に1つ、スタイリング用に1つ、UIプリミティブ用に1つ、そしてフォーム用に1つです。React自体——現在の19.2ライン——はコンポーネント、フック、レンダリングを担います。それ以外はすべて選択次第ですが、エコシステムの変化の速さが、その選択を実際以上に難しく感じさせています。実態としては、各用途に明確なデフォルトが1つ、状況に応じた代替が1〜2つ存在します。

この記事では、スタックをジョブ・トゥ・ビー・ダン（達成すべき目的）別に整理します。ファウンデーション、ステート、データフェッチング、ルーティング、スタイリング、UI、フォーム、アニメーションの各カテゴリについて、2026年のデフォルト、代替を選ぶべき状況、そしてエコシステムを再形成しつつある2つの力——React Server Components（RSC）とReact Compiler——との相互作用を解説します。

Reactプロジェクトのファウンデーション：フレームワークの選択

ライブラリを選ぶ前に、アプリの基盤となるファウンデーションを選択します。2026年においてこの決断は、React Server Componentsを必要とするかどうかによって大きく左右されます。ここでのジョブ・トゥ・ビー・ダンは、プロジェクトのスキャフォールディング、ビルドツール、ルーティング、そしてレンダリング戦略を1つの出発点にまとめることです。

ほとんどの新規アプリでは、Next.jsがデフォルトです。安定したRSC、サーバーアクション、ファイルベースのルーティングを備えた、最も完成度の高いフルスタックReactフレームワークです。クライアントサイドレンダリングのシングルページアプリを構築する場合や、フルフレームワークなしに高速でopinionatedでないビルドを求める場合は**Viteを選択してください——ルーティングとデータフェッチングは自分で組み立てます。プロジェクトがコンテンツ主導の場合——マーケティングページ、ドキュメント、ブログ——で、インタラクティビティが必要な箇所にのみReact islandsを使い、主に静的HTMLを配信したい場合はAstroを選択してください。型安全なルーティングとサーバー関数が優先事項で、アーリーアダプターとして採用できる場合はTanStack Start**を選択してください。v1リリース候補として安定版に近づいており、RSCサポートは現在も開発中です。

これらすべてにわたって考慮すべき2つの力は、データフェッチングをサーバーに移行するReact Server Componentsと、どのファウンデーションを選んでもコンポーネントを自動メモ化するReact Compilerです。

React Compilerがライブラリ選択に与える影響

React Compilerは現在安定版となり、手動で行う最適化の内容を変えています。React Compiler 1.0は2025年10月7日にリリースされ、React Confで発表されました。ビルド時にコンポーネントとフックの値を自動メモ化し、手動のuseMemoとuseCallbackの呼び出しのほとんどを不要にします。ライブラリ選択の観点では、かつて統合コードを煩雑にしていたボイラープレートの一類型——セレクターのラッピング、フォームフィールドに渡すコールバックのメモ化、派生値の安定化——がコンパイラによって処理されるようになったことを意味します。

ライブラリ選択への実際の影響：自動メモ化によって、アトミックステートライブラリのパフォーマンス上の優位性が薄れ、フォーム統合からボイラープレートの一カテゴリが排除されます。そのため、ライブラリはre-renderストームを避けるための手動チューニングの量ではなく、データモデルとエルゴノミクスで選ぶことになります。コンパイラはReact Compilerのインストールドキュメントによると、Vite、Next.js、Expoで対応しています。

Reactステート管理ライブラリ：4バケツの分類法

モダンなReactアプリには4つの異なるステートバケツがあります——TanStack Queryで管理するサーバーステート、useStateまたはZustandで処理するクライアントUIステート、nuqsが担うURLステート、そしてZustandのグローバルアプリステート——そして、バケツに対して誤ったツールを選ぶことが、不必要な複雑さの最も一般的な原因です。「ステート管理が難しい」という苦痛のほとんどは、サーバーデータをクライアントストアに入れたり、URLに属すべき共有UIステートをグローバルステートとしてモデル化したりすることから生じます。

サーバーステートにTanStack Query、ローカルステートにビルトインフック、共有UIステートにURLを使うことで、専用のグローバルストアが必要な領域は縮小しています。グローバルストアが必要な場合、Zustandがデフォルトです——プロバイダー不要で、セレクターサブスクリプションを持つ最小限のcreate()ストアです：

import { create } from 'zustand'

const useCartStore = create((set) => ({
  items: [],
  addItem: (item) => set((state) => ({ items: [...state.items, item] })),
}))

既存のReduxコードベースを保守・拡張する場合で、DevToolsのタイムトラベルや構造化されたアクション追跡が必要な場合はRedux Toolkitを選択してください。細粒度のアトミックサブスクリプションが本当に必要な場合はJotaiを選択してください——ただし、React Compilerが自動メモ化を行うようになった今、アトミックモデルのre-render削減という優位性は以前より弱まっています。URLステートに関しては、nuqsが型付きの検索パラメータを提供し、フィルターとページネーションをリフレッシュ後も維持し、リンクで共有できます。

サーバーステートとstaleTimeのデフォルト

TanStack QueryのstaleTimeはデフォルトで0です。つまり、コンポーネントのマウントごとにデータが古いとマークされ、バックグラウンドでの再フェッチがトリガーされます。ナビゲーションメニューやユーザープロフィールのような安定したデータに対しては、staleTimeをゼロ以外の値に設定することが、ほとんどのアプリが行っていない最も効果的な設定変更です。重要なデフォルトのドキュメントにはこう記されています：

import { useQuery } from '@tanstack/react-query'

// staleTime のデフォルトは 0 → マウントのたびに再フェッチ。
// ビューごとに変化しないデータにはゼロ以外の値を設定する。
const { data } = useQuery({
  queryKey: ['profile'],
  queryFn: fetchProfile,
  staleTime: 5 * 60 * 1000, // 5分
})

このデフォルトをそのままにしておくことが、よくある本番環境での障害パターンです。データ量の多いアプリのセッションリプレイでは、ルート変更のたびにバックグラウンド再フェッチのウォーターフォールが発生しているのをよく見かけます——これは、実際のユーザーセッションに対してネットワークシーケンスのリプレイを見るまで、1行の設定に起因するとは気づきにくいパターンです。

Reactデータフェッチングとルーティングライブラリ

データフェッチングのデフォルトは、どこでフェッチするかによって異なります。クライアントサイドのフェッチング——RESTまたはGraphQLのキャッシング、楽観的更新、バックグラウンド同期——にはTanStack Queryがデフォルトです。Next.js 16のようなRSCフレームワークでは、Server Components内でサーバー上でフェッチしてデータをpropsとして渡すため、クライアントサイドのフェッチングライブラリを完全に回避できます。GraphQLファーストで正規化されたキャッシングが必要な場合はApollo Clientを、TypeScriptでクライアントとサーバーの両方を制御しスキーマレイヤーなしのエンドツーエンドの型推論が必要な場合はtRPCを選択してください。

ルーティングも同様のサーバー/クライアントの分割に従います。メタフレームワークを使用する場合、ルーティングはフレームワークが処理します。使用しない場合、React Routerが最も広く使われているライブラリです。クラシックなクライアントサイドライブラリモードと、ローダー、アクション、サーバーレンダリングを備えたフルフレームワークモードの両方を提供しています。型安全なルート推論が優先事項の場合はTanStack Routerを選択してください——v1で安定しており、パラメータと検索のTypeScript推論はクラス最高水準です。

TanStack Start——型安全なファイルベースのルーティング、サーバー関数、SSRを提供——はv1リリース候補として安定版に近づいています。TanStack Startのドキュメントによると、RSCサポートはまだ開発中であるため、今すぐRSCが必要なチームにとってはNext.js 16の方がより完成されたフルスタックの選択肢です。現在のデフォルトではなく、注目の新参者として追跡してください。

ReactスタイリングライブラリとRSC互換性

RSC互換性は、スタイリング選択の第一級フィルターになりました。styled-componentsやEmotionのようなランタイムCSS-in-JSライブラリはブラウザでスタイルを注入するため、サーバーでレンダリングするReact Server Componentsのモデルと競合します。そのため、RSCを使用するNext.js 16アプリでは、ランタイムCSS-in-JSではなく、Tailwind CSS v4またはCSS Modulesが互換性のあるデフォルトです。

Tailwind CSSはユーティリティファーストのデフォルトです。v4ラインでは@themeディレクティブによるCSS内での設定が可能になり、Tailwind v4のアナウンスによると高速なエンジンが搭載されています。単一のclassNameでスタイリングが完結します：

<h1 className="text-blue-700">{title}</h1>

ユーティリティクラスの語彙を学ばずに、コロケーションされたスコープ付きCSSが必要な場合はCSS Modulesを選択してください——何もリークせず、RSCでクリーンに動作します。ランタイムコストなしにTypeScriptで型安全なスタイルを記述したい場合は、vanilla-extractのようなビルド時CSS-in-JSを選択してください。

styled-componentsは2025年3月にメンテナンスモードに入り、新規プロジェクトには推奨されません。ただし、放棄されたわけではなく——'use client'境界の背後でRSCでも動作し、v6.4リリースでcreateThemeによるRSC互換のCSSバリアブルテーマリングが追加されました。

より広い観点では：ランタイムのスタイル注入はサーバーレンダリングモデルと相性が悪いため、新規のRSCアプリではユーティリティファーストまたはビルド時のアプローチがより安全な選択です。

React UIライブラリ：依存モデルと所有モデル

UIレイヤーにおける最大の決断はアーキテクチャ的なものです。バージョン管理されたコンポーネントライブラリをインストールするか、コンポーネントのコードを直接所有するかです。スタイル付きコンポーネントライブラリ——MUI、Mantine、Chakra UI、Ant Design——は、時間をかけてアップグレードする依存関係として、洗練されたテーマ設定可能なデザインシステムを提供します。shadcn/uiが普及させた所有モデルは、コンポーネントのソースをプロジェクトにコピーします。

shadcn/uiのコピー＆ペーストモデルでは、コンポーネントのコードを完全に所有します——アップグレードすべきバージョン管理された依存関係がなく、破壊的変更のマイグレーションもなく、上書きできないライブラリ作者のデザイン上の決定もありません——これはMUIやMantineをインストールするのとはアーキテクチャ的に異なり、Tailwind上でカスタムデザインシステムを構築するチームのデフォルトになっている理由です。GitHubスターは11万を超えています。

// 所有モデル：ButtonはリポジトリにあるのでそのまままEdit可能。
import { Button } from '@/components/ui/button'

// 依存モデル：Buttonはバージョン管理されたパッケージから提供される。
import { Button } from '@mui/material'

shadcn/uiはヘッドレスプリミティブの上にコンポーネントを構築しており、デフォルトのプリミティブはRadixです。shadcn/uiのドキュメントによると、2026年初頭にBase UIが公式の代替プリミティブとして追加されましたが、Radixが推奨デフォルトのままです。

RadixはWorkOSによる2022年のModulz買収以来メンテナンスされており、一部の開発者はリリースペースが遅くなったと感じています——Base UI（MUIチームによる）が代替として登場した背景です——ただし、shadcn/uiは依然としてRadixをデフォルトとしており、MITライセンスのオープンソースとして活発にメンテナンスされています。MUI/Floating UIの系譜のプリミティブとスタイリングエンジンの柔軟性が必要な場合はBase UIを選択してください。エンタープライズのデータ集約型インターフェースを構築する場合で、テーブル、フォーム、日付ピッカーを自分で組み立てるのではなくバッテリー同梱のものが必要な場合はAnt Designのような完全スタイル付きライブラリを選択してください。

Reactフォームライブラリ

React Hook Formは、モダンなReactのフォームのデフォルトです。その設計は非制御型です。フィールドは各キーストロークをReactステートに保持するのではなく、refを通じて登録されるため、re-renderを構造的に最小化します。スキーマリゾルバーによるバリデーションを使う場合、典型的な組み合わせはReact Hook Formと、ランタイムバリデーションと型推論のためのZodです。

import { useForm } from 'react-hook-form'

const { register, handleSubmit } = useForm()

React Hook Formのドキュメントによると、registerはフィールドを制御型にせずにフォームに接続します。React Compilerが自動メモ化を行うようになったことで、かつてフィールドハンドラー周りの統合コードに必要だった手動のコールバックメモ化が不要になり、接続がさらにシンプルになっています。複雑な深くネストされたフォームステートを完全に型安全に扱いたい場合はTanStack Formを、サーバーアクションを中心にプログレッシブエンハンスメントなフォームを構築する場合はConformを選択してください。FormikとReact Final Formは事実上メンテナンスされていないため、新規プロジェクトでは避けてください。

フォームにおけるよくある本番環境での障害パターンは、キーストロークごとにステートを更新する制御型インプットによる過剰なre-renderです。非制御型モデルは中間的なステートイベントを減らし、セッションリプレイではよりクリーンなインタラクショントレースとして現れます——ユーザーのタイピングからフォームの送信までの間の冗長なレンダリングが減少します。

Reactアニメーションライブラリ

MotionはReactのデファクトスタンダードのアニメーションライブラリです。Motionは——かつてFramer Motionとして知られていたライブラリで——パッケージ名はmotion、インポートパスはmotion/reactを使用し、React 19の完全サポートを備えたv12メジャーに到達し、npmダウンロード数は月間約3,000万に達しています。

宣言的なAPIはinitialとanimateプロップで、アプリが必要とするほとんどのことを実現します：

import { motion } from 'motion/react'

<motion.div initial={{ opacity: 0 }} animate={{ opacity: 1 }} />

Motionのドキュメントによると、ジェスチャー、レイアウトトランジション、終了アニメーション用のAnimatePresenceをカバーしています。アクセシビリティに関する注意点として：prefers-reduced-motionメディアクエリを尊重してください。MDNはこれをユーザーがモーションを最小化したいという標準的なシグナルとして文書化しており、Motionはこれを読み取ってアニメーションを条件付きで制御できます。物理ベースのスプリングアニメーションをコアモデルとして使いたい場合はreact-springを、多くの要素にわたる細粒度のタイムラインオーケストレーションが必要な場合はGSAPを選択してください。

サポートキャスト：認証、テスト、チャート、i18n

コアスタックの他に、ほとんどのアプリを完成させるいくつかのカテゴリがあります——それぞれに1つの合理的なデフォルト：

• 認証： Auth.js
• テスト： ユニットテストにVitest、エンドツーエンドにPlaywright
• チャート： Recharts
• 国際化： i18next

それぞれが独自の深いトピックです。これらを出発点として、ドキュメントに従って進めてください。

2026年のReactスタック一覧

今日のNext.js 16アプリでは、互換性のあるデフォルトがジョブ別に並びます：

まとめ

変化の速さは確かですが、決断の空間は小さいです。ステートに適切なバケツを選び、フレームワークが許す場合はサーバーでフェッチし、UIレイヤーにはTailwindとshadcn/uiをデフォルトとし、アニメーションとフォームにはMotionとReact Hook Formを使いましょう。今すぐ理解すべき2つの変化は、React Compilerが統合コードからほとんどの手動メモ化を排除したこと、そしてRSC互換性がハードフィルターになったこと——ランタイムCSS-in-JSとまだ安定していないRSCサポートは、Next.js 16アプリに適合するものを絞り込みます。これらのデフォルトから始め、GraphQLのスケール、型安全なルーティング、物理演算アニメーションなど、特定の要件が実際に求める場合にのみ代替に切り替えてください。

よくある質問

styled-componentsをReact Server Componentsと一緒に使えますか？

styled-componentsはReact Server Componentsと'use client'境界の背後でのみ動作します。ブラウザでランタイムにスタイルを注入するため、RSCのサーバーレンダリングモデルと競合するからです。このライブラリは2025年3月にメンテナンスモードに入り、新規プロジェクトには推奨されません。ただし、リリースは継続されており、RSC互換のCSSバリアブルテーマリングも追加されています。新規のRSCアプリには、ビルド時にスタイルを生成するTailwind CSS v4またはCSS Modulesが互換性のあるデフォルトです。

shadcn/uiの所有モデルとMUIのようなライブラリのインストールの違いは何ですか？

shadcn/uiはコンポーネントのソースコードをプロジェクトに直接コピーするため、アップグレードすべきバージョン管理された依存関係も、破壊的変更のマイグレーションもなく、ファイルを直接所有・編集できます。MUIやMantineはバージョン管理されたパッケージとしてインストールし、時間をかけてインポートしてアップグレードします。カスタマイズの制御と管理されたアップデートをトレードオフします。所有モデルは完全なオーバーライド制御を求めてカスタムデザインシステムを構築するチームに適しており、依存モデルはコードを所有せずに洗練されたメンテナンスされたデザインシステムを求めるチームに適しています。

クライアントステートにuseStateの代わりにZustandを使うべき状況はいつですか？

直接の親子関係を持たない離れたコンポーネント間でステートを共有する必要がある場合——ショッピングカート、テーマ、多くの場所からアクセスされるセッションデータなど——にZustandを使用してください。フォームのドラフトやトグルのような、1つのコンポーネントまたは小さなサブツリーにローカルなステートにはuseStateまたはuseReducerを使用してください。純粋にローカルなステートにZustandを使うと、メリットなしに間接参照が増えます。一方、本当にグローバルなステートをprop drillingやcontextに入れると、不必要なre-renderと結合の問題が生じます。

React CompilerはTanStack Queryやステート管理ライブラリを置き換えますか？

いいえ。2025年10月7日に安定版となったReact Compiler 1.0は、ビルド時にコンポーネントとフックの値を自動メモ化し、手動のuseMemoとuseCallbackの呼び出しのほとんどを不要にしますが、サーバーステートのキャッシング、バックグラウンドでの再フェッチ、コンポーネント間のステート共有は管理しません。サーバーステートにはTanStack Query、クライアントステートにはZustandまたはuseStateが依然として必要です。コンパイラが変えるのは、これらの統合に必要な手動チューニングの量であり、ライブラリ自体が必要かどうかではありません。