状態管理の迷宮：なぜ私たちはまだライブラリ選定で消耗しているのか
フロントエンドのアーキテクチャ設計において、最も宗教戦争が起きやすく、かつプロジェクトの寿命を決定づけるテーマは何か。そう、「状態管理（State Management）の選定」だ。
世の中には「Reduxはボイラープレートが多すぎて悪だ」「いや、Zustandこそが至高の軽快さだ」「Recoilは未来の標準だ（そして事実上のメンテナンスモードになった）」といった、感情論に満ちた議論があふれている。
しかし、シニアエンジニアやチーフアーキテクトたる者、トレンドやバズワードに惑わされてはならない。私たちが見るべきは、ブラウザのメモリ効率、Reactのレンダリングパイプライン（Fiberアーキテクチャ）、そして非同期処理における競合（Race Condition）の制御、これら一点のみである。
今回は、React標準機能からZustand、Redux Toolkit（RTK）に至るまで、それぞれの内部挙動とメモリ・レンダリングのコストを解剖し、泥臭い現場で生き残るための「真の選定基準」を紐解いていこう。
—
1. 状態管理の現在地：主要アプローチの内部挙動とコスト
まずは、私たちが日常的に使っているツールたちが、裏で何をやっているのかを正確に把握する。ここを理解していないと、パフォーマンスチューニングの際に「なぜか再レンダリングが止まらない」という幽霊のようなバグに一生悩まされることになる。
React標準 (`useState` / `useReducer` + `useContext`)
Reactのプリミティブな機能だけで状態を管理する場合、最大の罠は「Contextの伝播メカニズム」にある。
Contextは、値が更新されると、そのProvider配下にあるすべてのコンシューマーコンポーネントを、メモ化（`React.memo`）の有無を無視して強制的に再レンダリングさせる。
- メモリ効率: 極めて高い（追加の依存関係がない）。
- レンダリング負荷: 最悪（部分的な最適化をサボると、ルート付近のContext変更でアプリ全体が爆発する）。
- 適したユースケース: フォームの入力値、テーマ切り替え、言語設定など、アプリ全体で頻繁に更新されず、かつ依存コンポーネントが少ないグローバル状態。
Zustand
現代の軽量状態管理のデファクトスタンダード。Zustandの本質は、Reactの外側に「独立したVanillaなストア」を持つことだ。Reactのコンポーネントは、Selectorを使ってそのストアの一部を「購読（Subscribe）」する。
// Zustandの内部挙動をイメージした簡略的な仕組み
// ストアの変更はReactのライフサイクルから切り離されているため、無関係なコンポーネントは一切再レンダリングされない。
const useStore = create((set) => ({
bears: 0,
increase: () => set((state) => ({ bears: state.bears + 1 })),
}));
- メモリ効率: 非常に高い。余計なプロバイダツリーを生成しない。
- レンダリング負荷: 極めて低い。Selectorが返す値が変わらない限り、コンポーネントは再レンダリングされない。
- 適したユースケース: 中規模から大規模アプリケーションのUI状態、セッション情報、複雑なウィジェット間のデータ共有。
Redux Toolkit (RTK)
「重厚長大」の代名詞だったReduxは、Toolkitの登場によって劇的に洗練された。Immerを内蔵し、書きやすくなっただけでなく、強力なDevToolsによるタイムトラベルデバッグ、そして非同期処理を担う`createAsyncThunk`の存在が最大の武器。
- メモリ効率: 中程度（ストアの正規化やミドルウェアのオーバーヘッドがある）。
- レンダリング負荷: `useSelector`による最適化が効くため低い。ただし、巨大な単一ストア（Single Source of Truth）の設計を誤ると、キャッシュの無効化戦略で苦しむ。
- 適したユースケース: 金融、EC、SaaSなど、複雑なドメインロジック、厳密な監査ログ、予測可能な状態遷移が絶対的に求められるミッションクリティカルなシステム。
—
2. 非同期競合とメモリリーク：実務で踏む地雷原
状態管理の選定において、同期的な値の保持以上に重要なのが、非同期処理（API通信やタイマー）が絡んだ際の競合（Race Condition）とメモリリークの対策だ。
例えば、ZustandやReduxで非同期のアクションを叩いたとき、ユーザーが素早く画面を行き来すると、古い非同期リクエストのレスポンスが、新しいリクエストの後に返ってきて状態を上書きしてしまう現象（いわゆる「古いデータによる状態の汚染」）が起きる。
これを防ぐための、実務レベルで使えるZustandストアのパターンを見てみよう。
実装例：非同期の競合を防ぐガード機構を持つZustandストア
import { create } from ‘zustand’;
interface UserState {
data: User | null;
loading: boolean;
error: string | null;
// リクエストの世代管理を行うためのトークン
fetchUser: (userId: string) => Promise
}
// 最後に発行されたリクエストのIDを追跡する（クロージャを活用）
let latestRequestId = 0;
export const useUserStore = create
data: null,
loading: false,
error: null,
fetchUser: async (userId: string) => {
const currentRequestId = ++latestRequestId;
set({ loading: true, error: null });
try {
const response = await api.getUser(userId);
// 競合対策: このリクエスト以降に新しいリクエストが走っていたら、結果を破棄する
if (currentRequestId !== latestRequestId) {
return;
}
set({ data: response, loading: false });
} catch (err) {
if (currentRequestId !== latestRequestId) {
return;
}
set({ error: (err as Error).message, loading: false });
}
},
}));
このコードの肝は、`latestRequestId`による世代管理だ。API通信の非同期の隙間を突き、古いレスポンスが状態を破壊するのを防ぐ。Redux Toolkitの`createAsyncThunk`を使う場合も、`abort()`シグナルを活用して同様のケアが必要になるが、Zustandのような自由度の高いライブラリでは、こうした防衛的コードを自前で組み込むアーキテクチャの知見が問われる。
—
3. チーフアーキテクトが教える「状態管理ライブラリ選定の4象限」
では、実際のプロジェクトでどの技術を選ぶべきか。私は以下の4つの軸でマトリクスを描き、チームに判断を委ねている。
[ドメインロジックの複雑さ: 高]
│
│ Redux Toolkit │ Zustand + Server State (TanStack Query)
│ (厳密なトランザクション、 │ (ドメインは複雑だが、ボイラープレートを
│ 予測可能性が絶対必要な場合) │ 減らしたい現代的な大規模アプリ)
├───────────────────────────┼────────────────────────────────────────
│ React Context │ Zustand / Jotai
│ (小規模・静的な設定値、 │ (UIの状態管理、モーダル、テーマ、
│ シンプルなコンポーネント) │ スタンドアロンなウィジェット群)
│
└───────────────────────────┴────────────────────────────────────────
[ドメインロジックの複雑さ: 低] [状態の共有範囲: 広]
黄金律：Server State と Client State の完全分離
現代のReact開発における最大のパラダイムシフトは、「サーバーから取得したデータ（Server State）」と「UIの開閉状態などのデータ（Client State）」を完全に分離することだ。
かつてはReduxにすべてのAPIレスポンスを突っ込んでいたが、それはアンチパターンである。キャッシュ、重力的な再フェッチ、楽観的アップデート（Optimistic Updates）などは、TanStack Query（React Query）やSWRに任せるべきだ。
したがって、現在の正しい選定フローはこうなる：
1. サーバーデータのキャッシュ・同期: TanStack Query 一択。
2. 純粋なUI状態・グローバルな一時データ:
- アプリが小規模、あるいはコンポーネントツリーが浅い → `React Context`
- 複数コンポーネントからクリーンにアクセスしたい、パフォーマンスを妥協したくない → `Zustand`
3. 極めて複雑なフロントエンドのドメインロジック・チーム規模が大きく規律が必要:
- 予測可能な状態遷移とDevToolsの恩恵を受けるために → `Redux Toolkit`
—
結びに代えて：ツールに縛られるな、アーキテクチャを設計せよ
「どの状態管理ライブラリが一番優れているか？」という問いは、プログラミングの世界における「どのナイフが一番優れているか？」という問いに似ている。料理人（エンジニア）が裁こうとしている食材（要件）によって、ペティナイフを選ぶべきか、牛刀を選ぶべきかは変わる。
大切なのは、フレームワークの内部挙動（再レンダリングのトリガー、メモリリークの温床、非同期の競合）を解剖学的に理解し、プロジェクトの規模、チームの習熟度、そして寿命から逆算して「最適解をハックする」ことだ。
流行り廃りの激しいフロントエンドの荒波において、流行のライブラリに飛びつくのではなく、ブラウザとReactの基本プリミティブに立脚した堅牢なアーキテクチャを築き上げてほしい。それこそが、真のシニアエンジニアの仕事である。
コメント