この記事の途中に、以下の記事の引用を含んでいます。
React State Management in 2025: What You Need
1. そもそも「Reactの状態管理」って、なんでこんなに悩ましいの？
Reactアプリを開発する際、誰しもが一度は「状態管理、なにを選べばいいの？」という問いにぶつかることでしょう。
定番のReduxもあれば、新興のZustandやJotai、果ては「Contextだけで十分じゃない？」論争まで、議論は尽きません。
今回紹介する海外の技術記事React State Management in 2025: What You Needでは、著者が「もう“状態管理ライブラリ”自体いらないかも？」という強烈な意見を展開しつつ、その背景と選定基準をロジカルに解説しています。
流行り廃りの激しいReact界隈で「何を・いつ・なぜ選ぶべきか？」を今一度整理したい技術者にとって、非常に示唆的な内容です。
2. 「ベストなライブラリは存在しない」──著者の主張とその意義
この記事の最大のポイントは、アーキテクチャ設計あるあるの「◯◯が一番良い！」論を真っ向から否定している点です。
その象徴的な一節を引用します。
There is no such thing as “the best” anything. It always, always depends. (Except for ice cream. Pistachio ice cream is the best).
これは「ベストな状態管理ライブラリなんて存在しない。プロジェクトの前提や目的次第だ。」という徹底した現場主義を表しています。
加えて、「リモートデータ管理に専用のデータフェッチライブラリを使えば“状態管理”のほとんどがそちらで事足りてしまう」とも指摘。
…you might find that you don’t need a dedicated state management library at all. There are different state concerns that in the “old Redux days” were lumped together. But these days, a lot of them could be handled better with a library that targets that specific concern.
つまり、「状態管理」を単一のライブラリで全部やろうという発想自体が、すでに時代遅れになりつつあることが強く主張されています。
3. 「状態管理」の分類で劇的にラクになる設計術
それでは本当に、Reactアプリでは「状態管理ライブラリ」がいらなくなるのでしょうか？
記事ではまず、「状態」そのものを細かく“リモートステート（外部データ）”、“URLステート”、“ローカルステート”、“共有ステート”に分類しています。
このアプローチが極めて実践的。
3-1. リモートステートはTanStack Query/SWR一択
著者も強調するように、現在のReactアプリで最も複雑になるのは「サーバ/DBから取得してクライアントで扱うデータ（リモートステート）」の管理です。
「これを全てReduxでやろうとすると、“80%ぐらいのReduxコードがただのAPIコール管理に消費されてしまっていた”」との指摘は、古くからのReact開発者ほど身に染みるはず。
…~80% of your Redux-related code handles everything above. In this case, you don’t need a state management library. You need a good React-first data management library.
ここで推奨されているのがTanStack Query（旧React Query）やSWR。
これらのライブラリは、
– ローディング・エラー管理
– キャッシュ
– クエリの重複防止
– 楽観的更新
– ページネーションや自動リトライ
——など「リアルなWebアプリ」に不可欠な課題をあらかじめ網羅的に解決します。
地味ながら、こうした選定基準は極めて重要です。なぜなら「状態管理＝グローバルなストアで何でも管理」と短絡するより、データの流れとスコープに合わせて最適解を選ぶことで、コードのシンプルさ・パフォーマンス・保守性が飛躍的に向上するからです。
3-2. URLステート：地味だけど重要な落とし穴
URLが状態（例：クエリパラメータで絞り込みやタブの選択など）を表すケースも昨今では非常に一般的です。
記事では、これも「昔はReduxで頑張って同期していたが、今はnuqsという専用ライブラリで驚くほど簡単になる」と語っています。
Use nuqs library instead. Same as with TanStack Query being a game-changer for remote state, this beautiful but obscurely named library is a game-changer for managing query params.
React Routerなどフル機能なルータで十分な場合もありますが、「手動同期が必要なケースは絶対自作せず、素直に専用ツールを使え」と強調する姿勢は合理的です。
3-3. ローカルステートはuseState/useReducerで十分
これも迷いがちなポイントですが、「Redux全盛期には全部グローバルストアだった細かいUI状態（例: ドロップダウン開閉やダイアログ表示・非表示）は、ReactのuseStateだけで事足りる」と明言されています。
むしろ、明示的に「状態を共有する必要があるのか？」という問いを都度立てることこそ大切だとされています。
3-4. 真の「共有ステート」が必要になったとき、Contextは万能薬じゃない
状態を複数の疎結合なコンポーネント間で共有したいとき、「Prop drilling」や「Context API」を検討しがちです。
Contextによる実装例も詳細に解説されていますが、その後で「Contextはスケールしない」「Provider Hellになる」とバッサリ。
Welcome to “Providers Hell”.
この課題が規模拡大時にあらわれることは、現場で大規模SPAを開発した経験がある人なら一度は痛感したはずです。
Contextが万能に見えて実は「少数のシェアドステート」にしか向かない、という冷静な指摘が響きます。
4. 本当に必要なときだけ「状態管理ライブラリ」を導入せよ
ここまで考え抜いた上で、著者は初めて「真の意味で状態管理ライブラリが必要なのは、Contextでも到底まかないきれない複雑な“共有ステート”を扱う場面だけ」と主張します。
どんな特徴を持つライブラリがよいか、具体的な評価基準も示されています。
The very first thing I’m going to look for in a shared state solution is simplicity…I need something that is dead simple to set up and does not introduce its own unique and abstract terminology.
また、現在人気の主要ライブラリを「シンプルさ」「React流に合致しているか」「無駄なリレンダーがないか」など、多角的に評価。
その結果：
- Redux：複雑すぎ（👎）
- Redux Toolkit：構造化・意欲的だが学習コストあり（😐）
- Zustand：シンプルさ・React寄り・導入容易さで満点（🎉）
- MobX/Jotai/XState：独自概念・記法・非React流・高学習コストで却下（👎）
Zustand is the winner in all categories. Which matches my default tech stack choice for any new project: TanStack Query + nuqs + Zustand.
「Zustand+TanStack Query+nuqs」がデフォルトというのは、現在のReactアプリ実務の経験値に裏打ちされた意見として、非常に納得度が高いです。
ただし、「プロダクトや組織によって最適解は異なる」と繰り返し補足しており、「構造化や堅牢さ重視ならRedux Toolkit、高度な状態遷移ならXState」といった活用例も併記。
このバランス感覚と現実的な解は、単なる“流行り物ヨイショ”記事とは一線を画しています。
5. 【考察】現場視点で「状態管理」どう考えるべきか
ここまでの内容を自分なりに考察します。
5-1. 「全部グローバル管理」からの脱却は必須
かつてのReduxを使い倒してきた開発現場では、何でもかんでもストアに詰め込み、「どんどん複雑化→カオス→技術的負債化」という経験を積んだ方も多いはず。
その大半は「本当は共有しなくていいのに、惰性でグローバルに置いてしまう」という設計上の安直さが原因でした。
現状、リモートデータ管理＝TanStack Query、URL同期＝nuqs、ローカルUI状態はuseState…という分担は、「単一責任の原則」をReactで実現する一点突破の戦略だと感じます。
5-2. 状態の“スコープ設計”が最大の勘所
個人的に、この記事の最大の価値は「状態の種類ごとに専用ツールを使い分けることの合理性」と、「“共通ストア”の乱用リスク」を明示している点だと考えます。
たとえば次のような状況を想定してみましょう。
- APIレスポンスに基づくデータ表示：TanStack Queryでキャッシュ・ローディング・エラー管理まで自動化
- ページネーションや条件付き取得：APIクエリをkeyにして自動でキャッシュ分離
- タブやダイアログopen/close状態：useStateのローカル管理でグローバル影響ナシ
- タブ状態や検索条件をURLに反映：nuqs一発で非同期同期も柔軟に実現
- 特定の情報（テーマ・ユーザー認証状態など）のアプリ全体共有：Contextの少数Providerで限定的に
このように、「状態の寿命・スコープ・変更主体」をフロント設計初期で正確に想定しておかないと、後からモノリシック化・スパゲッティ状態につながります。
5-3. 状態管理ライブラリ選定の「経験則」への警鐘
ReduxやMobXの隆盛期は「使い方が難しいほどプロっぽい」と思った時代も正直ありました。
しかし学習コスト・リファクタリングの大変さ・中途半端なパフォーマンスチューニングなど、現実は甘くはありません。
記事の「覚える必要がない新しい概念があるなら、その時点で失格！」という基準は2020年代後半における“疲弊した現場”への明確な処方箋であり、今後のトレンドセッターになっていくでしょう。
6. まとめ──「自分たちの最適解」を探る時代へ
この記事の結論として、「もはや待望の万能『状態管理ライブラリ』は登場しない」と断言されています。
むしろ、それぞれの状態の種類に合ったツールを組み合わせる時代になった、と言ってよいでしょう。
Most of the time, especially if you’re not implementing the next Figma, you don’t need a “state management library” at all. …Break your state into different concerns, and you’ll find yourself with better solutions for them than any “generic” state management library.
この姿勢を現場で徹底することで、
– コード量の劇的削減
– バグ/リファクタ容易性の向上
– メンテナンス担当者の心理的負担減
– 使い切れない機能の“よけいな学習コスト”の回避
など、様々なメリットがあります。
最後に、あなたのプロジェクトや組織にとって大切なのは「トレンドに乗ること」ではなく、「どんな状態をいかに管理する必要があるのか？」を正確に分析し、無駄なくシンプルな道具立てを選ぶこと。
それが2025年以降、Reactアプリ開発をラクにする最大の武器になるでしょう。
categories:[technology]
コメント