React状態管理ライブラリ完全比較〜Redux Toolkit・Zustand・Jotai・Valtio・TanStack Query〜【2026年版】

「React 状態管理 比較って結局どれを選べばいいの?」「Redux Toolkit・Zustand・Jotai・Valtio・TanStack Query…名前は聞くけど、自分のプロジェクトでどれを採用すべきか判断がつかない」――2026年のReact開発者が一度は通る悩みです。本記事はRedux Zustand Jotai 比較を軸に、useStateやuseContextでは限界が来た時に登場する外部状態管理ライブラリ7種(Redux Toolkit・Zustand・Jotai・Recoil・Valtio・MobX・XState)と、サーバー状態管理3種(TanStack Query・SWR・Apollo Client)を、bundle size・パフォーマンス特性・採用判断軸の3点で徹底比較します。「Contextで済む領域」と「ライブラリに移行すべき領域」の境界、各ライブラリの強み・弱み、現場で使われる実装パターン、そして20〜40代のWebエンジニアがチーム内でレビュー時に堂々と判断を下せる採用基準フローチャートまで、コードブロック15本超・比較表4つ・FAQ7問で解説します。読み終えるころには、技術選定で迷うことがなくなり、プロジェクトの規模・チーム構成・更新頻度に応じた最適解を自分で出せるようになっているはずです。

なぜReactには状態管理ライブラリが必要なのか

Reactは「UIライブラリ」であり、状態管理は基本的にuseState・useReducer・useContextという標準APIで完結する設計になっています。しかし、アプリケーションが成長すると、標準APIだけでは解決しづらい3つの壁に必ずぶつかります。1つ目は頻繁な更新による再レンダリング地獄、2つ目はサーバー状態(キャッシュ・再取得・楽観的更新)の複雑性、3つ目は複数開発者で長期保守するための型安全性とDevToolsです。React 状態管理 比較を行う上で、まずこの3つの壁を理解することが出発点になります。

useState・useReducerだけで済むケース

状態管理ライブラリを導入するか迷ったら、まず「その状態は本当に共有が必要か?」を問い直してください。フォームの入力値・モーダルの開閉・タブの選択状態など、1つのコンポーネントに閉じる状態はuseStateで十分です。少し複雑な遷移ロジックがあっても、useReducerで対応できます。Reactの公式ドキュメントでも「状態はできる限りローカルに保つ」ことが推奨されています。

// useStateで完結する典型例
import { useState } from "react";

function SignupForm() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [agreed, setAgreed] = useState(false);

  return (
    <form>
      <input value={email} onChange={(e) => setEmail(e.target.value)} />
      <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} />
      <label>
        <input type="checkbox" checked={agreed} onChange={(e) => setAgreed(e.target.checked)} />
        利用規約に同意する
      </label>
    </form>
  );
}

useContextで済むケースと済まないケース

テーマ切り替え・ログインユーザー情報・言語設定など、「めったに変わらない・ツリー全体で共有する値」はuseContextで配信するのがベストプラクティスです。詳しくはuseContext完全ガイドで解説していますが、Contextには「value変化で全購読者が再レンダリングされる」という致命的な特性があります。リアルタイムチャット・大量のフォーム要素・カート内商品の数量変更など、秒間に何度も更新が走る状態では、Provider分割やuseMemoでも追いつかなくなります。この瞬間が、外部ライブラリ導入の検討タイミングです。

外部ライブラリが解決する3つの課題

外部状態管理ライブラリは、Contextの限界を超えるために「細粒度の購読(selector)」「不変性の保証」「DevToolsによるデバッグ性」の3点を提供します。Redux ToolkitならcreateSliceとImmerで安全な状態更新、ZustandならuseStore(selector)で必要なフィールドだけ購読、JotaiならAtom単位で配信先を限定、というように、各ライブラリが独自のアプローチで再レンダリング問題を解いています。

クライアント状態管理ライブラリ7種の特徴比較

ここからは、クライアント側の状態管理に使われる主要7ライブラリ――Redux Toolkit・Zustand・Jotai・Recoil・Valtio・MobX・XStateを順に見ていきます。それぞれbundle size・学習コスト・思想が大きく異なるため、まず一覧で全体像を掴みましょう。

主要ライブラリの基本スペック比較表

Redux Toolkit: エンタープライズの王道

Redux Toolkit(以下RTK)は、かつての「Reduxボイラープレート地獄」を解決した公式の現代版Reduxです。createSliceでreducer・action・selectorを一括生成でき、Immerが内部で動くため「見た目はmutableに書けるが内部はimmutable」な状態更新が可能。Redux DevToolsによるタイムトラベルデバッグは、複数開発者で長期保守するエンタープライズアプリで圧倒的な強みになります。

// Redux Toolkit: createSliceでカート機能を実装
import { createSlice, configureStore } from "@reduxjs/toolkit";
import { useSelector, useDispatch } from "react-redux";

const cartSlice = createSlice({
  name: "cart",
  initialState: { items: [] as { id: string; qty: number }[] },
  reducers: {
    add: (state, action) => {
      const found = state.items.find((i) => i.id === action.payload.id);
      if (found) found.qty += 1;
      else state.items.push({ id: action.payload.id, qty: 1 });
    },
    remove: (state, action) => {
      state.items = state.items.filter((i) => i.id !== action.payload.id);
    },
  },
});

export const { add, remove } = cartSlice.actions;
export const store = configureStore({ reducer: { cart: cartSlice.reducer } });

// コンポーネントから利用
function Cart() {
  const items = useSelector((s: any) => s.cart.items);
  const dispatch = useDispatch();
  return <button onClick={() => dispatch(add({ id: "x1" }))}>追加</button>;
}

Zustand: 小さく速く現代的

Zustandは約1KBという驚異的な小ささでありながら、selector・middleware・persistを備えた現代的な状態管理ライブラリです。create関数1つでストアを定義し、Hookとして直接使えるシンプルさが最大の魅力。React 状態管理 比較で「最初の1本」として推奨されることが多く、個人開発から数十人規模のプロジェクトまで幅広く採用されています。

// Zustand: createでストアを定義
import { create } from "zustand";

type CounterState = {
  count: number;
  increment: () => void;
  reset: () => void;
};

const useCounter = create<CounterState>((set) => ({
  count: 0,
  increment: () => set((s) => ({ count: s.count + 1 })),
  reset: () => set({ count: 0 }),
}));

// selectorで必要なフィールドだけ購読 → 不要な再レンダリングを防ぐ
function Counter() {
  const count = useCounter((s) => s.count);
  const increment = useCounter((s) => s.increment);
  return <button onClick={increment}>{count}</button>;
}

Jotai: Atomで分散する次世代型

JotaiはRecoilにインスパイアされた、「Atom」単位で状態を分散管理するライブラリです。Recoilよりも軽量で、TypeScript対応も成熟しています。グローバルなストアを持たず、atomを定義した瞬間にそれが状態の単位になるため、コンポーネントの近くに状態を置く「Co-location」思想と相性抜群。Server ComponentsやSuspenseとの親和性も高く、Next.js 15以降のアプリで採用が伸びています。

// Jotai: atomを定義して必要な箇所でuseAtom
import { atom, useAtom } from "jotai";

const themeAtom = atom<"light" | "dark">("light");
const userAtom = atom<{ name: string } | null>(null);

// 派生atom(他のatomから自動計算)
const greetingAtom = atom((get) => {
  const u = get(userAtom);
  return u ? `こんにちは、${u.name}さん` : "ゲストさん";
});

function Header() {
  const [theme, setTheme] = useAtom(themeAtom);
  const [greeting] = useAtom(greetingAtom);
  return (
    <header data-theme={theme}>
      <span>{greeting}</span>
      <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>切替</button>
    </header>
  );
}

Recoil・Valtio・MobX・XStateの位置づけ

残る4ライブラリも一言で押さえておきましょう。RecoilはMeta製でJotaiの先輩格ですが、2024年以降メンテナンスが鈍化しており、新規採用は減少傾向です。ValtioはProxyベースで「普通のオブジェクトをそのまま更新する」感覚で書ける珍しいライブラリ。MobXはObservableパターンで、Vue.jsのreactivityに近い書き心地。OOP的なクラスベース設計と相性が良く、Angularから来た開発者にも馴染みやすいです。XStateは「有限状態機械(FSM)」を主軸に置く異色の存在で、複雑な遷移ロジック(注文ワークフロー・認証フロー・動画プレイヤー等)を仕様化したい場面で輝きます。

// Valtio: Proxyでmutable風に書ける
import { proxy, useSnapshot } from "valtio";

const state = proxy({ count: 0, name: "Tarou" });

function App() {
  const snap = useSnapshot(state);
  return (
    <div>
      <p>{snap.name}: {snap.count}</p>
      <button onClick={() => { state.count++; }}>+1</button>
    </div>
  );
}

// MobX: Observableクラスで状態を持つ
import { makeAutoObservable } from "mobx";
import { observer } from "mobx-react-lite";

class CounterStore {
  count = 0;
  constructor() { makeAutoObservable(this); }
  increment() { this.count += 1; }
  reset() { this.count = 0; }
}
const counterStore = new CounterStore();

const Counter = observer(() => (
  <button onClick={() => counterStore.increment()}>
    {counterStore.count}
  </button>
));

// XState: 有限状態機械で注文ワークフローをモデル化
import { createMachine } from "xstate";
import { useMachine } from "@xstate/react";

const orderMachine = createMachine({
  id: "order",
  initial: "cart",
  states: {
    cart:     { on: { CHECKOUT: "payment" } },
    payment:  { on: { PAID: "shipping", FAIL: "cart" } },
    shipping: { on: { DELIVERED: "done" } },
    done:     { type: "final" },
  },
});

function OrderFlow() {
  const [state, send] = useMachine(orderMachine);
  return (
    <div>
      <p>現在のステップ: {String(state.value)}</p>
      <button onClick={() => send({ type: "CHECKOUT" })}>支払いへ</button>
    </div>
  );
}

サーバー状態管理ライブラリの登場とその意味

ここまでは「クライアント側の状態」を扱うライブラリでしたが、現代のReactアプリで状態の大半を占めるのは実はサーバー状態(API取得データ・キャッシュ・再取得・楽観的更新)です。これをRedux Toolkitに無理に詰め込むのは2018年の発想で、2026年はTanStack Query・SWR・Apollo Clientを使うのが標準解です。

クライアント状態とサーバー状態は別物

「ユーザーがフォームに入力した値」はクライアント状態、「サーバーから取得したユーザー一覧」はサーバー状態です。両者はキャッシュの有無・再取得の必要性・整合性の保ち方がまったく異なります。サーバー状態を専用ライブラリに任せると、以下のような面倒事から一気に解放されます。

• ローディング・エラー状態の管理: isLoading・error・isFetching等を自動で提供。
• キャッシュとstaleTime: 同じデータの二重取得を防ぎ、適切なタイミングで再取得。
• 楽観的更新(optimistic update): サーバー応答前にUIを更新して快適なUXを実現。
• バックグラウンド再取得: ウィンドウフォーカス・ネットワーク復帰時に自動でリフレッシュ。
• キャッシュ無効化: mutation後に関連するqueryKeyを一斉に再取得。

TanStack Query(旧React Query)の威力

TanStack Queryは事実上のデファクトスタンダードです。useQueryでサーバーデータの取得とキャッシュ、useMutationで書き込みと楽観的更新を扱います。Redux Toolkit + RTK Queryで代替することもできますが、純粋なサーバー状態管理だけならTanStack Queryのほうがシンプルで採用例も豊富です。

// TanStack Query: useQueryでAPI取得をキャッシュ込みで管理
import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query";

function UserList() {
  const { data, isLoading, error } = useQuery({
    queryKey: ["users"],
    queryFn: async () => {
      const res = await fetch("/api/users");
      if (!res.ok) throw new Error("取得失敗");
      return res.json();
    },
    staleTime: 60_000,
  });

  if (isLoading) return <p>読み込み中…</p>;
  if (error) return <p>エラー: {(error as Error).message}</p>;
  return <ul>{data.map((u: any) => <li key={u.id}>{u.name}</li>)}</ul>;
}

// 楽観的更新の例
function useAddUser() {
  const qc = useQueryClient();
  return useMutation({
    mutationFn: (name: string) => fetch("/api/users", { method: "POST", body: JSON.stringify({ name }) }),
    onMutate: async (name) => {
      await qc.cancelQueries({ queryKey: ["users"] });
      const prev = qc.getQueryData(["users"]);
      qc.setQueryData(["users"], (old: any[]) => [...(old ?? []), { id: "tmp", name }]);
      return { prev };
    },
    onError: (_e, _v, ctx) => qc.setQueryData(["users"], ctx?.prev),
    onSettled: () => qc.invalidateQueries({ queryKey: ["users"] }),
  });
}

SWRとApollo Clientの使いどころ

SWRはVercel製で、TanStack Queryよりさらに軽量・シンプル。Next.jsのプロジェクトで「とりあえずfetchをラップしたい」程度なら最有力です。Apollo ClientはGraphQL専用で、スキーマと一体化したキャッシュ管理が魅力。バックエンドがGraphQLなら第一選択肢になります。

// SWR: シンプルな書き心地
import useSWR from "swr";

const fetcher = (url: string) => fetch(url).then((r) => r.json());

function Profile() {
  const { data, error, isLoading } = useSWR("/api/me", fetcher, {
    revalidateOnFocus: true,
    dedupingInterval: 5000,
  });
  if (error) return <p>失敗</p>;
  if (isLoading) return <p>読み込み中</p>;
  return <p>こんにちは、{data.name}さん</p>;
}

// Apollo Client: GraphQLクエリをHookで実行
import { gql, useQuery, useMutation } from "@apollo/client";

const GET_TODOS = gql`
  query GetTodos {
    todos { id title done }
  }
`;

function TodoList() {
  const { data, loading, error } = useQuery(GET_TODOS);
  if (loading) return <p>読み込み中</p>;
  if (error) return <p>エラー: {error.message}</p>;
  return (
    <ul>
      {data.todos.map((t: any) => (
        <li key={t.id}>{t.done ? "✓" : "□"} {t.title}</li>
      ))}
    </ul>
  );
}

// Zustand: persistミドルウェアでlocalStorageに保存
import { create } from "zustand";
import { persist } from "zustand/middleware";

type AuthState = { token: string | null; setToken: (t: string) => void; logout: () => void; };

const useAuth = create<AuthState>()(
  persist(
    (set) => ({
      token: null,
      setToken: (t) => set({ token: t }),
      logout: () => set({ token: null }),
    }),
    { name: "auth-storage" }
  )
);

パフォーマンス特性とbundle sizeの実測比較

採用判断で見落とせないのがパフォーマンス特性です。bundle sizeは初回ロードに直結し、再レンダリング戦略はインタラクションのキビキビ感に直結します。Redux Zustand Jotai 比較では、この2点を必ず突き合わせて評価しましょう。

bundle sizeとパフォーマンスの比較表

再レンダリングの抑制パターン3種

各ライブラリは異なるアプローチで「不要な再レンダリング」を防いでいます。整理すると以下の3パターンです。

• Selectorパターン(Redux Toolkit・Zustand): ストアから必要なフィールドだけを取り出し、その値が変わった時だけ再レンダリング。
• Atomパターン(Jotai・Recoil): 状態を小さな単位(atom)に分解し、そのatomを購読しているコンポーネントだけ再レンダリング。
• Proxyパターン(Valtio・MobX): 実行時に「どのフィールドが参照されたか」を自動追跡し、そのフィールドが変わった時だけ再レンダリング。

どれが正解というわけではなく、チームメンバーの慣れ・既存コードベースの思想・型安全性への要求で選びます。たとえばRedux DevToolsに慣れたチームならRedux Toolkit継続が安全ですし、新規スタートアップで軽さ重視ならZustandやJotaiが好相性です。

Concurrent Renderingとの相性

React 18以降のConcurrent Rendering(startTransition・useDeferredValue・Suspense)を最大限活かすには、ストアがuseSyncExternalStoreを正しく実装している必要があります。Zustand・Jotai・TanStack Queryは標準対応済み。Redux Toolkit(react-redux v8以降)も対応しています。Recoilは2026年時点で対応が遅れており、新規採用の優先度は下がっています。

採用判断フローチャートと実践的な選び方

ここまでの内容を踏まえ、実プロジェクトでの採用判断フローを示します。「何となく流行っているから」ではなく、プロジェクトの特性に合わせて選ぶのがプロの責任です。

判断フロー(5ステップ)

1. そもそも共有が必要か? → 不要ならuseState・useReducerで終了。
2. 更新頻度は? → 低頻度(テーマ・認証ユーザー等)ならuseContextで十分。useContext完全ガイド参照。
3. サーバー状態が中心か? → YesならTanStack Query / SWR / Apollo Client。クライアント状態は別ライブラリと組み合わせ可。
4. チーム規模と既存資産は? → 大規模・複数開発者・型安全重視ならRedux Toolkit。小〜中規模で軽さ重視ならZustand or Jotai。
5. 状態遷移が複雑か? → 注文ワークフロー・認証フロー等で状態爆発が予想されるならXStateを部分採用。

プロジェクトタイプ別の推奨スタック

「最初からRedux」「全部Context」がアンチパターンな理由

2010年代後半によく見られた「とりあえずRedux」は2026年時点ではアンチパターンです。useStateで十分な状態までactionとreducerに乗せてしまい、コードが3倍に膨らみます。同様に「全部Context」も、再レンダリング地獄を招きスケールしません。useState完全ガイドとuseContext完全ガイドで標準APIの守備範囲を理解し、その上で外部ライブラリを段階的に導入するのが正解です。

段階的導入のすすめ

新規プロジェクトの場合、いきなり全ライブラリを入れる必要はありません。以下の順で段階的に拡張するのが、現場で破綻しにくい進め方です。

• Phase 1: useState + useReducer + useContext のみで開始。
• Phase 2: サーバー通信が増えたらTanStack QueryまたはSWRを追加。
• Phase 3: クライアント状態が複雑化したらZustandやJotaiを追加。
• Phase 4: 業務ロジックの状態遷移が複雑になればXStateを部分導入。
• Phase 5: 複数チームで保守する規模になればRedux Toolkitへ集約も選択肢。

状態管理スキルを伸ばす学習ロードマップ

状態管理はReact上級者と中級者を分ける最大のテーマです。useStateの使い方は知っていても、Redux Toolkit・Zustand・Jotai・TanStack Queryを業務レベルで使い分けられるエンジニアはまだ少数派。ここを押さえれば、フロントエンドエンジニアとしての市場価値は確実に上がります。

独学で進めるなら

各ライブラリの公式ドキュメントは非常に質が高く、まずはRedux Toolkit → Zustand → Jotai → TanStack Queryの順に1つずつ小さな個人アプリで試すのが王道です。自分でcreate-react-appやVite + Reactのテンプレートにライブラリを足し、トークンの保存・カート・無限スクロールなど典型的なシナリオを実装してみてください。React Hooks 完全実践ガイドでカスタムフック設計を学び、各ライブラリのHookと自作フックの組み合わせ方を体得すると、応用が一気に効くようになります。

スクールでまとめて学ぶなら

独学が苦手な方や、転職を視野に体系的に学びたい方には、現役エンジニアによるメンタリング付きスクールが効率的です。テックアカデミーのフロントエンドコース・Reactコースでは、Redux・Recoilを含む実務カリキュラムが用意されており、状態管理ライブラリの選び方まで踏み込んで学べます。侍エンジニアのオーダーメイドコースなら、Zustand・Jotai・TanStack Queryなど最新ライブラリだけを集中して学ぶプランも組めます。DMM WEBCAMPのWebアプリ開発コースは、Redux Toolkitを使った実プロジェクト型カリキュラムが特徴で、ポートフォリオに状態管理設計を盛り込みやすい構成です。学習中・学習直後の転職活動にはレバテックキャリアのようなIT専門エージェントに登録しておくと、状態管理ライブラリの実務経験を活かせる求人が集中的にレコメンドされます。

独学・スクール・転職支援の使い分け

状態管理ライブラリに関するFAQ

Q1: 2026年に新規プロジェクトを始めるなら何を選ぶ?

個人〜中規模ならZustand or Jotai + TanStack Queryが現代的な鉄板です。大規模・エンタープライズならRedux Toolkit + TanStack Query(またはRTK Query)を選びましょう。「迷ったらZustand + TanStack Query」と覚えれば9割の場面で外しません。

Q2: Reduxは時代遅れ?

いいえ、現代のRedux ToolkitはかつてのReduxとは別物です。ボイラープレートが激減し、Immer・selector・型安全性が標準装備。Redux DevToolsによるタイムトラベルデバッグは依然として最強で、複数チームで長期保守するなら今でも最有力候補です。

Q3: ZustandとJotaiはどう違う?

Zustandは単一ストア + Hookでアクセス、Jotaiは多数のatomを分散配置という思想の違いがあります。Redux経験者にはZustandが馴染みやすく、Recoilや`useState`の延長で考えたい人にはJotaiが馴染みやすいです。bundle sizeは両者とも非常に軽量で、性能差は実用上ほぼ無視できます。

Q4: TanStack Queryとクライアント状態管理ライブラリは併用する?

Yesです。「サーバー状態 = TanStack Query」「クライアント状態 = Zustand or Jotai or Redux Toolkit」と役割を完全に分けるのが2026年の標準構成です。Reduxにサーバー状態まで詰め込むのは旧式パターンで、TanStack Queryに任せる方が圧倒的にシンプルです。

Q5: Recoilはもう採用しない方がいい?

新規プロジェクトでは避けた方が無難です。Meta社のメンテナンスペース鈍化とConcurrent Rendering対応の遅れがあり、ほぼ同等の機能を持つJotaiが活発に進化しているため、Jotaiに軍配が上がります。既存のRecoilプロジェクトを無理に移行する必要はありませんが、新規はJotai推奨です。

Q6: MobXはまだ使われている?

使われています。特にAngular出身のチームやOOPベースの大規模社内システムでは今も現役です。ただしReactエコシステムの主流からは外れつつあり、求人数ではRedux Toolkit・Zustand・TanStack Queryに大きく水をあけられています。新規習得の優先度は低めでOKです。

Q7: 状態管理ライブラリの選定はチームで議論すべき?

必須です。状態管理は技術選定の中でも最も「後で覆しにくい」決定の1つで、半年後に「やっぱりZustandに移行」となるとコストが甚大です。プロジェクト開始前に、想定するアプリ規模・更新頻度・チームメンバーの慣れ・採用コスト(教育コスト)を一覧化し、3〜4人で1時間議論するだけで、後の数百時間が浮きます。

まとめ: 2026年のReact状態管理は「適材適所」が正解

本記事では、React 状態管理 比較の決定版として、Redux Toolkit・Zustand・Jotai・Recoil・Valtio・MobX・XStateというクライアント状態管理7種と、TanStack Query・SWR・Apollo Clientというサーバー状態管理3種を、bundle size・パフォーマンス・採用判断軸の3点で徹底比較しました。Redux Zustand Jotai 比較の結論を一言でまとめれば、「Redux Toolkitはエンタープライズ、Zustandは万能の中庸、Jotaiは分散・Co-location思想」。サーバー状態は迷わずTanStack Query。クライアントとサーバーを混在させない――これが2026年のベストプラクティスです。「全部Context」も「最初からRedux」も時代遅れ。プロジェクトの規模・更新頻度・チーム構成を見極め、useState → useContext → Zustand/Jotai → TanStack Query → 必要ならRedux Toolkit/XStateという段階的拡張を選んでください。さらに学びを深めたい方は、useState完全ガイド・useContext完全ガイド・React Hooks 完全実践ガイドと合わせて読むと、React状態管理の地図が完成します。技術選定で迷わないエンジニアになるために、本記事を何度も読み返し、自分のプロジェクトで実際に手を動かして検証していきましょう。