概要

状態（state）とは、UIやアプリケーションが“今どうあるか”を定義する情報の集合体である。
状態管理とは、**「状態をどこに持ち」「どう変化させ」「どう再現性を担保するか」**を設計する行為である。

本稿では、以下を軸に状態管理を構造的に整理する：

ローカルステート vs グローバルステートの役割と境界
状態の責務とスコープの設計
ステートマシンによる状態遷移の明示化
状態変更のトリガーと影響範囲の制御
現場における実用アプローチの選定基準

1. ローカルステート：コンポーネント内の状態

let count = 0;

function increment() {
  count++;
  render(count);
}

✅ コンポーネント内完結
✅ UIに直接関係する短命ステート向き
❌ 複数コンポーネントで共有すると破綻

2. グローバルステート：アプリケーション全体で共有される状態

const appState = {
  user: null,
  theme: 'dark',
  isLoading: false
};

✅ 認証情報・設定・ネットワーク状態など
✅ 単一の“真実の情報源”（Single Source of Truth）
❌ 不用意に増やすと依存爆発

3. ステートマシン的思考：状態遷移を制御する

✅ 明示的な“状態 → 状態”の遷移モデル

const state = {
  status: 'idle', // idle → loading → success / error
};

function transition(event) {
  if (state.status === 'idle' && event === 'FETCH') {
    state.status = 'loading';
  } else if (state.status === 'loading' && event === 'SUCCESS') {
    state.status = 'success';
  }
}

→ ✅ 状態とイベントの“許容遷移”を明文化
→ ✅ 誰がいつ何を変えるかが見える設計に

4. 状態を「責務」で分類する戦略

状態の種類	例	保持場所
表示用の一時状態	モーダル開閉・フォームの入力内容	ローカルステート
アプリケーション状態	認証ユーザ・テーマ・カート	グローバルステート
ネットワーク状態	isLoading, errorMessage	一時的にはローカル、共有が必要ならグローバル
状態遷移	認証: 未ログイン → ログイン中 → 完了	ステートマシンモデル

5. グローバルステートを管理する手段

✅ Context API（Reactなど）

const ThemeContext = createContext('dark');

✅ 軽量で構成もシンプル
❌ 状態の更新頻度が高いと再レンダリング地獄

✅ 状態管理ライブラリ（Zustand, Redux, Vuex など）

const useStore = create(() => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 }))
}));

✅ スコープを切ってセレクティブ購読
✅ ミドルウェアによるログ・永続化も可
❌ 抽象化しすぎると複雑化する

6. 状態の“不変性”と安全な更新

const next = { ...prev, isOpen: true };

✅ 状態を直接 mutate しない（再レンダリングが起きない）
✅ Object.assign / スプレッド構文でコピー更新

7. 状態トリガーの設計と制御

UI → 状態更新
APIレスポンス → 状態更新
タイマー / 外部イベント → 状態更新

✅ 更新元が多い場合は「イベント」として抽象化

dispatch('LOGIN_SUCCESS', payload);

→ ✅ 状態に直接触れず、間接的に制御する構造へ

設計判断フロー

① 状態はローカルUI専用？ → useState等で管理

② 状態は複数コンポーネントから参照される？ → グローバル管理

③ 状態が明確なフェーズを持つ？ → ステートマシン設計

④ 状態の変更元が複数ある？ → イベントドリブン化

⑤ 状態が変化する頻度は？ → 高頻度ならセレクティブ購読設計

よくある失敗と対策

❌ 状態の責任が不明瞭で“なんとなく共有”

→ ✅ スコープ設計を「誰が持ち」「誰が読んで」「誰が変えるか」で分割

❌ グローバルステートにローカル状態を混在

→ ✅ UI状態（例：開閉）はローカルに留める

❌ 状態の変更に副作用が埋め込まれている

→ ✅ 状態と副作用は分離（例：useEffectで外部反応）

結語

状態管理は単なる変数の保持ではない。
それは**「情報の流れをどう設計し、責任をどこに持たせるか」**という、アーキテクチャの中核そのものである。

状態は構造に従い
状態変化はルールで制御され
状態の読み書きは責任が明確である

設計された状態は、予測可能性と信頼性をもたらす。
状態は“どう持つか”ではなく、“どう変化するか”まで設計すべきである。