状態管理の使い分け｜ReactでuseState・Context・Zustandを比較

Reactの状態管理で、useState、Context、Zustand、Redux Toolkitのどれを使うべきか迷う人は多いです。

• useStateだけで十分なのか？
• Contextはいつ使うべきなのか？
• Zustandはどんな場面で使うのか？
• Redux Toolkitは今でも必要なのか？

結論から言うと、Reactの状態管理は「その状態をどこで使うのか」で選べばOKです。

そこでこの記事では、React・Next.jsの実務でよく使われるuseState、Context、Zustand、Redux Toolkitの違いと選定基準を、初心者にもわかりやすく解説します。

結論：Reactの状態管理は共有範囲で選ぶ

基本的には、Reactの状態管理は状態の共有範囲で選びます。

状態の使い方	おすすめ	代表例
1つのコンポーネント内だけで使う	useState	モーダル、フォーム、タブ
数階層のコンポーネントで共有する	Context	テーマ、言語設定、ログイン情報
複数画面・アプリ全体で共有する	Zustand	カート、通知、ユーザー状態
大規模で状態変更のルールを厳格にしたい	Redux Toolkit	金融、管理画面、大規模SPA

迷ったら、まずは以下の順番で検討すると失敗しにくいです。

1. まずはuseStateで管理できないか考える
2. props drillingがつらくなったらContextを検討する
3. 複数画面で共有するならZustandを検討する
4. 大規模開発でルール化や追跡性が必要ならRedux Toolkitを検討する

最初から高度な状態管理ライブラリを入れるより、小さく始めて、必要になったタイミングで広げる方が実務では運用しやすいです。

Reactの状態管理とは？

Reactの状態管理とは、画面上で変化するデータをどこで持ち、どのコンポーネントから使えるようにするかを決めることです。

例えば、以下のような状態はReactでよく扱います。

• 入力フォームの値
• モーダルの開閉
• 選択中のタブ
• ログインユーザー情報
• カート内の商品数
• 通知の未読件数

この中で、フォームやモーダルのように画面内だけで使う状態もあれば、ログインユーザー情報やカート件数のように複数画面で使いたい状態もあります。

つまり、状態管理では状態そのものよりも「どこから使うか」が重要です。

なお、React公式のuseStateやcreateContextのような標準機能だけで足りる場面もあれば、アプリ全体で状態を共有するためにZustandやRedux Toolkitを使った方がよい場面もあります。

useStateとは？コンポーネント内の状態管理に使う

useStateは、React標準の状態管理Hookです。主に、コンポーネントに状態変数を追加したいときに使います。

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

useStateが向いているケース

• モーダルの開閉
• フォーム入力
• タブ切り替え
• アコーディオンの開閉
• 検索キーワードの入力値

これらは基本的に、そのコンポーネントや画面内だけで完結する状態です。そのため、最初から外部ライブラリを使う必要はありません。

1つのコンポーネント内で使う状態は、まずuseStateで管理すると考えましょう。

useStateのメリット

• React標準なので追加ライブラリが不要
• 学習コストが低い
• コードがシンプル
• 小さなUI状態に向いている

useStateのデメリット

• 複数階層で共有するとprops drillingが発生する
• アプリ全体で共有する状態には向かない
• 状態が増えると管理場所が散らばりやすい

Contextとは？props drillingを避けたいときに使う

Contextは、React標準の仕組みで、親から子へpropsを何階層も渡さずに値を共有できます。

例えば、ログインユーザー情報をHeader、UserMenu、ProfileButtonで使いたい場合、propsだけで渡すと以下のようになります。

Layout
↓
Header
↓
UserMenu
↓
ProfileButton

その結果、途中のHeaderやUserMenuでは使わないのに、ProfileButtonへ渡すためだけにpropsを受け取る必要があります。これがprops drillingです。

このような場面では、Contextを使うことで中継用propsを減らせます。

import { createContext, useContext } from "react";

const UserContext = createContext(null);

function ProfileButton() {
  const user = useContext(UserContext);

  return <button>{user.name}</button>;
}

Contextが向いているケース

• ダークモード
• 言語設定
• ログインユーザー情報
• テーマカラー
• 数階層で共有する設定値

使いどころとしては、アプリ全体というよりも、特定の範囲内で共通の値を参照したい場合に向いています。

Contextの注意点

ただし、便利だからといって、すべての状態をContextに入れるのはおすすめしません。

なぜなら、Contextの値が変わると、その値を参照しているコンポーネントが再レンダリングされるからです。例えば、user、theme、notificationを1つのContextにまとめると、通知が変わっただけでユーザー情報やテーマを使うコンポーネントまで再描画される可能性があります。

そのため、Contextは更新頻度が低い状態や共有範囲が限定された状態に使うのが現実的です。

Zustandとは？アプリ全体の状態管理に使いやすいライブラリ

一方、Zustandはシンプルにグローバル状態を管理できるReact向けの状態管理ライブラリです。

特に、Reduxよりもコード量が少なく、Contextよりも状態を分けて扱いやすいため、中小規模から実務規模のReactアプリで使いやすい選択肢です。

import { create } from "zustand";

type UserStore = {
  userName: string;
  setUserName: (name: string) => void;
};

export const useUserStore = create<UserStore>((set) => ({
  userName: "",
  setUserName: (name) => set({ userName: name }),
}));

そして、利用側では必要な状態だけを取り出せます。

const userName = useUserStore((state) => state.userName);

Zustandが向いているケース

• ECサイトのカート状態
• 通知の未読件数
• ログインユーザー状態
• 複数画面で使うUI状態
• チャットやSNSの一時的な共有状態

つまり、useStateやContextでは管理がつらいけれど、Redux Toolkitほど厳格な設計は不要。このような場面ではZustandが使いやすいです。

Zustandのメリット

• コード量が少ない
• 学習コストが比較的低い
• 必要な状態だけを購読しやすい
• Contextよりグローバル状態を整理しやすい

Zustandのデメリット

• Redux Toolkitほどルールが厳格ではない
• 大規模化するとストア設計のルールが必要
• チーム開発では命名や分割方針を決めておく必要がある

Redux Toolkitとは？大規模開発向けの状態管理

一方で、Redux ToolkitはRedux公式が推奨しているReduxの書き方です。現在Reduxを使う場合、基本的にはRedux Toolkitを選びます。

また、状態変更の流れを明確にしやすく、Redux DevToolsによる追跡もしやすいため、大規模なチーム開発で強みがあります。

dispatch
↓
action
↓
reducer
↓
state更新

たしかに一見すると面倒ですが、状態変更の流れが明確になるため、誰が、どこで、どの状態を変更したのかを追いやすくなります。

実際にRedux公式でも、Redux Toolkitは効率的にReduxを書くための公式推奨ツールセットとして位置づけられています。

Redux Toolkitが向いているケース

• 金融システム
• 大規模な管理画面
• 複雑な状態遷移がある業務システム
• 数十人規模で開発するSPA
• 状態変更の履歴やルールを重視するプロジェクト

ただし、小規模な個人開発や中規模のWebアプリでは、最初からRedux Toolkitを入れる必要がないケースも多いです。

Reduxはオワコンなのか？

結論として、Reduxはオワコンではありません。ただし、昔よりも「必ずReduxを使うべき」という場面は減っています。

その理由は、ReactやNext.jsの設計が変わり、サーバーデータをフロント側のグローバル状態に保存しなくてもよい場面が増えたからです。

• Next.js App Routerの普及
• React Server Componentsの活用
• Zustandなど軽量な状態管理ライブラリの選択肢
• React QueryやSWRなどサーバーデータ管理の選択肢

そのため、2026年現在はUI状態はuseStateやZustand、サーバーデータはServer Componentsやデータ取得ライブラリで扱うという考え方が現実的です。

Next.js Server Componentsで状態管理はどう変わった？

Next.jsのApp Routerでは、デフォルトでServer Componentsを使えます。これらはサーバー上で実行されるため、データ取得をサーバー側で行い、その結果をHTMLとして返せます。

export default async function Page() {
  const user = await getUser();

  return <div>{user.name}</div>;
}

以前は、ブラウザでAPIを取得して、その結果をReduxなどに保存してから表示するケースがよくありました。

画面表示
↓
API取得
↓
Redux保存
↓
表示

しかし、Server Componentsを使うと、サーバー側でデータを取得して、そのまま描画できます。

サーバーでデータ取得
↓
HTML生成
↓
表示

つまり、Server Componentsは状態管理をなくしたのではなく、サーバーデータをフロント側の状態として持つ必要性を減らしたと理解するのが正確です。

サーバーデータとUI状態を分けて考える

ここまでの内容を踏まえると、React・Next.jsの状態管理では、サーバーデータとUI状態を分けて考えると整理しやすくなります。

種類	例	管理方法
サーバーデータ	商品一覧、記事一覧、ユーザー情報	Server Components、React Query、SWRなど
UI状態	モーダル、フォーム、タブ、カート操作	useState、Context、Zustandなど

そのため、サーバーに存在するデータを、何でもReduxやZustandに保存する必要はありません。一方で、ユーザー操作によって変わるUI状態は、引き続きフロント側で管理する必要があります。

実務でのおすすめ構成

実務では、以下のように考えると選びやすいです。

プロジェクト	おすすめ
個人開発	useState中心。必要になったらZustand
中小規模のWebアプリ	useState、Context、Zustand
Next.jsアプリ	Server Componentsでサーバーデータを扱い、UI状態はuseStateやZustand
大規模業務システム	ZustandまたはRedux Toolkit。運用ルールが重要
状態変更の追跡性が重要なシステム	Redux Toolkit

そのため、最初から高度な状態管理を入れるより、まずはuseStateで始め、共有範囲が広がったらContextやZustandを検討するのがおすすめです。

bluenaでは、ReactやNext.jsの開発経験を活かしたいエンジニア向けに、案件選びやキャリア相談の機会を用意しています。実務でどの技術を伸ばすべきか迷っている方は、カジュアル面談で現在地を整理することもできます。

よくある質問

Reactの状態管理はまず何から学ぶべきですか？

まずはuseStateを学ぶべきです。なぜなら、useStateを理解すると、Reactで状態が変わる仕組みや再レンダリングの基本がわかるからです。その後、props drillingに困ったらContext、複数画面で状態を共有したくなったらZustandを学ぶと理解しやすいです。

ContextとZustandはどちらを使うべきですか？

テーマや言語設定のように更新頻度が低く、共有範囲が限定されている状態ならContextが向いています。一方で、カート、通知、ユーザー状態のように複数画面で使い、更新も発生する状態ならZustandが使いやすいです。

Redux Toolkitは今から学ぶ必要がありますか？

React初心者が最初に学ぶ必要はありません。まずはuseState、Context、Zustandを理解すれば、多くの開発に対応できます。そのうえで、Redux Toolkitは大規模開発や状態変更の追跡性が重要な案件に関わるタイミングで学ぶとよいです。

Next.jsでは状態管理ライブラリは不要ですか？

不要とは限りません。たしかに、Server Componentsによってサーバーデータをフロント側のグローバル状態に保存する必要は減りました。しかし、モーダル、フォーム、タブ、カート操作などのUI状態は引き続き管理が必要です。

まとめ：Reactの状態管理は小さく始めて、必要に応じて広げる

最後に整理すると、Reactの状態管理は最初から難しく考える必要はありません。

• コンポーネント内だけならuseState
• 数階層で共有するならContext
• アプリ全体で共有するならZustand
• 大規模で状態変更の追跡性が必要ならRedux Toolkit

また、Next.jsのServer Componentsによって、サーバーデータをフロント側の状態として持つ必要性は減っています。

状態管理で迷ったら、まずは「これはサーバーデータなのか、UI状態なのか」、次に「どの範囲で共有するのか」を考えましょう。

この順番で整理すれば、useState、Context、Zustand、Redux Toolkitの選び方で迷いにくくなります。

React・Next.jsの実務スキルを伸ばしたい方は、まず状態管理の使い分けから整理してみてください。