Zenn
🕹️

React に状態管理ライブラリが必要な理由──Context API の限界とパフォーマンス課題

に公開
React
Redux
frontend
jotai
Zustand
tech

はじめに

Reactなどのフロントエンド開発において、状態管理ライブラリ（Zustand、Jotai、Redux など）を使う機会は非常に多いと思います。
技術選定の場面では「どの状態管理ライブラリを採用するか」が話題に上ることも多く、「おすすめ状態管理ライブラリ◯選」といった記事もよく見かけます。

しかし一方で、「そもそもなぜ状態管理ライブラリが必要なのか？」という根本的な理由について、体系的に説明された記事はあまり多くありません。

本記事では、状態管理ライブラリを導入する本質的な理由について、特にパフォーマンスの観点に重きを置いて整理しています。

本記事で扱わない話題

本記事は、「状態管理ライブラリの存在理由」を明確にすることに焦点を当てており、以下のようなトピックは扱いません：

  • 「状態」「状態管理」とは何か
  • 各状態管理ライブラリの具体的な使い方

翻って、この記事の対象読者は、フロントエンドにおける状態管理の基本的な知識を持ち、ライブラリを何らかの形で使ったことがある方です。そのうえで「なぜライブラリを使うべきなのか？」という問いに一歩踏み込んで理解したい方を想定しています。

なお、状態管理とは何かについて詳しく学びたい方には、以下の記事が参考としておすすめです。
少し古い記事ではありますが、歴史的背景も含めてまとめられており、初学者にもわかりやすいでしょう。

「状態管理」って何？：https://zenn.dev/gagaga/articles/state-management

なぜ状態管理ライブラリが必要なのか：一般的な理解

状態管理ライブラリを使う理由として、一般的には以下のようなメリットがよく挙げられます：

  1. Prop Drilling（propsのバケツリレー）問題の解消
    コンポーネント階層を跨いでpropsを渡す煩雑さをなくせる。
    Prop Drillingについての詳細は以下がわかりやすいです。
    Prop Drilling：https://zenn.dev/matazou/articles/9728f26b15de68
  2. 可読性・保守性の向上
    状態のロジックが集中管理されることで、コードベースが整理されやすくなる。
  3. デバッグのしやすさ
    状態の変更を一元的に追跡できるため、不具合の原因が特定しやすくなる。

これらの点が非常に重要である事は確かです。
特に、Prop Drillingの問題が適切なコンポーネント分割に対する障壁になるケースがあり、大規模開発においては可能な限り避けるべきだと筆者は考えます。
（念の為補足を入れると、元記事にはコンポーネント分割をしないという方針も示されており、小規模開発等においてはこの方針も検討するべきでしょう。）

Context APIだけでProp Drilling問題は解決可能

ここで一度整理しておきたいのは、React の Context API だけでもシングルトンな状態共有を実現し、Prop Drilling問題を解決することは可能であるという点です。

たとえば createContext と useContext を使えば、ツリーのどこからでもアクセス可能な共有状態を作ることができます。これにより、Prop Drillingの問題は解決できます。

const MyContext = createContext({ foo: 0 });

const Parent = () => (
  <MyContext.Provider value={{ foo: 123 }}>
    <Child />
  </MyContext.Provider>
);

const Child = () => {
  const { foo } = useContext(MyContext);
  return <div>{foo}</div>;
};

このように、Prop Drilling回避や状態の一元化という目的であれば、わざわざ外部ライブラリを使わずともContext APIで代替可能です。

したがって、「Prop Drillingを防ぎたいから」という理由だけで外部ライブラリを導入するのはやや早計かもしれません。

Context APIの弱点：再レンダリングの制御ができない

しかし、Context APIには本質的な弱点があります。

それは、Contextの値が持つプロパティのうち、どれか一つでも変わると、それを参照しているすべてのコンポーネントが再レンダリングされてしまうという点です。

たとえば、次のように状態fooとbarを含むオブジェクトをコンテキストで共有していたとしましょう。

「Open Sandbox」ボタンからデモを起動してみてください。
「increment foo」ボタンをクリックすると、fooだけでなくbarを表示しているコンポーネントまで再レンダリングされていることが確認できるはずです。

この仕様は公式ドキュメントでも言及されており、回避策には以下のようなものが提示されています。

  1. Context を分割する
  2. useMemo や useCallback を多用する
    • useMemo や useCallback を使うことで、オブジェクトや関数の参照が毎回変わるのを防ぎ、不要な再レンダリングを抑えることができます。

たしかに、ドメイン設計を明確にしてContextを適切に分割しながら使えば、再レンダリングの影響をある程度抑えることは可能です。
しかし、このアプローチをすべての開発者が一貫して正しく適用し続けるのは非常に難しく、属人性が高まる恐れがあります。

よほど外部ライブラリに依存したくないなど特別な理由がない限り、Context APIのみで中〜大規模アプリの状態管理を行うのは、実用上かなり難易度が高いと筆者は考えます。

状態管理ライブラリの強み：購読単位が明確

ここでようやく、ZustandやJotaiのような「購読単位が明確」な状態管理ライブラリの強みが発揮されます。

以下は、先ほどのContext APIの例と構成はほぼ同じで、状態管理の部分だけをZustandに差し替えたサンプルです。

先ほどと同様に「Open Sandbox」ボタンからデモを起動してみてください。
「increment foo」ボタンをクリックすると、fooを使っているコンポーネントのみが再レンダリングされ、barのコンポーネントは影響を受けていないことが確認できます。

もちろん、このサンプル程度の小規模な構成であれば、fooとbarが同時に再レンダリングされても大きな問題にはなりません。

しかし、実際の開発現場では

  • 1ページに多数のコンポーネントが配置されている
  • 状態変更が頻繁に発生する
  • レンダリング処理が重たい（画像処理・グラフ描画・アニメーションなど）

といった条件が重なることがよくあります。

そのような場合、わずかな「余計な再レンダリング」が大きなパフォーマンス低下につながるのです。

このように、Context APIでは困難だった再レンダリングの細かな制御を、Zustandのようなライブラリであればシンプルに、明確に実現できます。

再レンダリング制御のしやすさこそが、状態管理ライブラリを導入する本質的な動機のひとつだといえるでしょう。

まとめ：なぜ状態管理ライブラリが必要なのか

状態管理ライブラリは、単なる「便利な道具」ではなく、Reactにおける再レンダリングの制御という構造的な課題を解決するための本質的な選択肢です。

たしかに、ReactのContext APIを使えば、シングルトンな状態共有やProp Drillingの解消は可能です。
小規模なアプリケーションであれば、それだけでも十分に機能するでしょう。

しかし、Context APIは「値の一部が変わっただけでも、すべてのコンシューマが再レンダリングされてしまう」という特性があり、中規模以上のアプリケーションではパフォーマンスチューニングが非常に難しくなります。

ZustandやJotaiのような状態管理ライブラリは、「必要な値だけを購読する」という構造によって、無駄な再レンダリングを避け、コードの意図を明確に保ったまま状態を安全に扱うことができます。

つまり、「なぜライブラリを使うのか？」という問いに対しては、パフォーマンスと明確な購読単位を確保するためというのが大きな理由の一つです。

状態管理の選定は、ただの好みや流行ではなく、アプリケーションの構造と開発体験を左右する設計判断です。
道具を選ぶ理由を理解していれば、選定も使い方も、ブレることはありません。

おまけ：AI時代のライブラリ選定指針

AI駆動開発が一般的になりつつある現在「AIと協調してコードを書く時代において、どのようなライブラリが“AIにとっても扱いやすい”と言えるのか？」という観点がライブラリ選定において不可欠になってきているように感じます。

ここでいう「AIにとって扱いやすいライブラリ」とは、単に人間にとってのDX（Developer Experience）が良いだけでなく、AIがコードを正しく補完・生成・リファクタリングしやすい設計を備えている必要があります。

たとえば今回テーマとした状態管理ライブラリに当てはめて考えると、次のような特性が「AIライク」と言えるでしょう：

  • APIの構造がシンプルで一貫している
    複雑な設定やネスト構造が少なく、AIが補完やコード生成の流れを予測しやすい。
  • どの状態がどこで使われているか（購読範囲）が明示されている
    セレクター構文などで「この値だけ使っている」と書けると、AIも安全にコードを追加・編集できる。
  • 特殊なコンテキスト構造や副作用が少ない
    Providerの入れ子やライフサイクルの影響が少ない設計だと、AIでも誤操作しにくくなる。
  • 設定がシンプルで導入が容易
    ファイルを分けてストアを作成し、必要な箇所でインポートするだけのような仕組みは、AIが学習しやすく、再利用性も高い。

こうした特徴を備えていると、AIは人間の意図をより正確に理解しやすくなり、生成されたコードも破綻しにくくなります。

ZustandやJotaiは、まさにこのような「AIライク」な設計を持つ状態管理ライブラリの代表例です。
一方、Reduxのようにreducerやaction type、middlewareなど複数の抽象レイヤーが絡むライブラリは、人間にとっては柔軟性がある一方で、AIにとっては構造を追いづらく、誤解や破壊的変更が生まれやすい傾向があります。

Discussion