1 状態管理の概念
1.1 状態の定義と種類
状態とは、処理の各時点においてシステムが保持する「現在の事情」を表す情報一式である。状態には、画面に表示される値、ユーザー操作の履歴、認証や権限に関わる情報、通信の途中経過、内部キャッシュの内容など、多様な要素が含まれる。状態管理とは、これらを一貫した形で保持し、必要な更新を行い、参照・共有の手順を定めることで、挙動の再現性と整合性を確保する実践である。
状態は、いくつかの観点で分類できる。第一に「ローカル状態」と「共有状態」である。ローカル状態は特定の画面や部品の内部に閉じた情報を指し、共有状態は複数の領域から同時に参照・更新され得る情報を指す。第二に「基本状態」と「導出データ」である。基本状態は入力や外部イベントにより直接確定する値で、導出データは基本状態から計算されて得られる派生値である。第三に「永続状態」と「揮発状態」である。永続状態は再起動後も保持が必要な情報に相当し、揮発状態はメモリ内での一時的な保持にとどまる。
1.2 状態が問題になる典型パターン
状態が扱いづらくなる要因は、情報の所在の曖昧さ、更新順序の不確実性、更新の伝播設計の欠落、そして更新回数の過多にある。以下は実務で頻出する崩れ方である。
1.2.1 画面とデータの不整合
表示と内部データが同期していないと、画面上の値が実際の計算結果や次の遷移条件と一致しない。たとえば入力フォームに表示された値を状態に保存せずに、途中で再描画やコンポーネント入れ替えが起きると、ユーザーが見ている内容と処理が参照する内容がずれる。結果として送信される値が期待と異なる、あるいは正しいバリデーション結果が提示されないといった問題が起きる。
1.2.2 非同期処理による競合
非同期処理では、要求が投入されてから完了するまでの順序が保証されない。通信の遅延や並列実行により、古い応答が新しい応答の後に到達することがある。これにより、状態が後から更新されてしまい、画面表示やローカルキャッシュが「最新ではない」内容になる。競合の中心は、状態更新のタイミングと参照の整合性が設計されていない点にある。
1.2.3 伝播しない更新・過剰な更新
更新が必要な箇所に伝わらない場合、表示や依存計算が古い値を使い続ける。逆に、更新が広範囲に伝播しすぎると、不要な再計算や再描画が増え、操作の体感が悪化するだけでなく、競合の発生機会も増える。特に状態の粒度が粗すぎると、わずかな変化でも大域的な更新が発生しやすい。
1.3 状態管理の目的（整合性・再現性・保守性）
状態管理の目的は大きく三つに整理できる。第一に整合性である。複数の画面や部品が同じ事実を参照し、矛盾のない更新結果に到達するよう設計する。第二に再現性である。入力イベントや外部応答の系列が与えられた場合に、状態遷移と最終結果が追跡可能であることが重要になる。第三に保守性である。変更が局所化され、影響範囲の見積もりが容易になるほど、開発と運用の負荷は下がる。
これらは相互に関連する。整合性を高めると再現性が上がり、再現性が上がると問題の切り分けが容易になり、保守性が改善する。状態の扱いを「いつ」「どこで」「何を」更新するかという観点から明確にすることが、その実現につながる。
2 状態の設計方針
2.1 状態の所在（どこに持つか）
状態の所在は、設計上の最重要論点の一つである。どこに保持するかが決まらないと、更新の伝播範囲、アクセス権限、ライフサイクル、そしてテスト容易性が定まらない。
2.1.1 ローカル状態と共有状態の切り分け
ローカル状態は、その情報が意味を持つ範囲内に閉じるほど扱いやすい。たとえばある入力欄の編集中値は、当該フォームの文脈だけで使われるならローカルに置くのが自然である。一方、複数画面から参照されるユーザー選択、検索条件、カートのように一貫した事実として機能するものは共有状態として扱う利点が大きい。
切り分けの判断基準として「参照者数」と「更新頻度」を用いると整理が進む。参照者が限られ、更新が頻繁でも影響範囲が小さいならローカルが適する。逆に参照者が多く、更新がその後の遷移や他画面の表示に影響するなら共有化が望ましい。共有状態には責務が集まりがちであるため、粒度と更新の責任範囲を意識的に制御する必要がある。
2.2 状態の正規化と最小化
状態は少ないほど良いという単純化は避けるべきだが、過剰な重複は確実に問題を招く。状態を設計する際には、正規化によって重複を減らし、最小化によって更新の対象を絞ることが有効になる。
2.2.1 参照データと導出データの扱い
基礎となる参照データと、そこから計算される導出データを区別する。参照データを単一の場所で保持し、導出はその都度または確実なタイミングで再計算する方針は、状態の矛盾を減らす。たとえばテーブル表示で並べ替えや集約を行う場合、並べ替え結果を状態として保存するより、元の配列とソート条件から導く設計の方が整合性が保ちやすい。
ただし計算コストが高い場合は、導出結果をキャッシュとして持つ余地がある。その際も、キャッシュを「いつ無効化されるか」「どの入力変化で更新するか」を明確にし、参照データとの対応関係が崩れないよう制約を置くことが重要になる。
2.3 更新の原則（単方向性・イベント駆動）
状態更新の流れを理解しやすくするために、単方向性とイベント駆動という考え方が使われる。単方向性は、入力（イベント）から状態変更が導かれ、結果として描画や副作用が実行されるという筋道を保つことで、循環や予期せぬ書き換えを抑える。
2.3.1 不変性と変更点の管理
不変性は、状態の内容を直接書き換えるのではなく、変更された部分を反映した新しい状態として扱う発想である。これにより、いつどの更新が起きたかを追跡しやすくなり、比較（差分）やリプレイの基盤も整う。変更点の管理としては、更新の対象フィールドを意識し、不要な書き換えを避けることで再描画や再計算の量も抑えられる。
イベント駆動と組み合わせると、外部からの刺激（ユーザー操作、タイマー、通信応答）が入力として扱われ、その入力に対する変換が一貫したルールに従う構造が作れる。結果として、状態遷移は説明可能になり、テストの設計もしやすくなる。
3 実装パターンとアーキテクチャ
3.1 単一状態ツリー方式
単一状態ツリー方式は、アプリケーション全体または主要領域について、状態を一つの階層構造として保持する考え方である。更新はその中心に対して行われ、各コンポーネントは必要な部分だけを参照する。階層化された構造により、データの所在が明確になり、共有状態の追跡もしやすい。
利点は、状態の全体像が見えやすく、変更履歴や監視を設計しやすい点にある。欠点としては、状態ツリーが肥大化しやすいこと、更新のたびに影響範囲が広がりやすいこと、責務が集中しやすいことが挙げられる。したがって、最小化や参照・導出の区別を徹底し、更新の粒度を制御することが重要になる。
3.2 コンポーネント中心の管理
コンポーネント中心の管理では、状態の保持が部品のライフサイクルに結びつき、必要に応じて上位から受け渡される。画面の部品構造をそのまま状態の分割単位として捉えるため、局所的な問題に強い構成になる。
3.2.1 コンテキストと依存注入の考え方
コンテキストや依存注入は、状態や操作（関数・サービス）を階層を越えて渡すための仕組みとして利用される。コンテキストは、特定の範囲に対して値を配布する点で状態共有に相性が良い。依存注入は、生成や取得を呼び出し側から切り離し、テストや差し替えをしやすくする。
ただし、コンテキストで共有する範囲を広げすぎると、関係の薄い部品まで更新の影響を受ける。依存注入も同様に、依存先の境界を曖昧にすると責務が散らばり、理解コストが増える。状態の粒度と配布範囲を設計することが、コンポーネント中心方式の要点になる。
3.3 イベント・ストア方式
イベント・ストア方式は、状態そのものを直接保存するというより、状態を構成する出来事（イベント）を記録してから状態を再構成する発想である。イベントは時系列のログとして扱われ、必要に応じてリプレイすることで状態に到達する。
3.3.1 アクションとリデューサの役割
イベント・ストアにおける代表的な実装では、「アクション」が外部からの意図を表し、「リデューサ」がその意図を現在状態へ反映する変換器として振る舞う。アクションには何が起きたかの情報が含まれる。リデューサは、現在の状態とアクションから新しい状態を生成する。ここで重要なのは、変換規則が純粋であること、つまり同じ入力なら同じ出力を返す性質をできるだけ保つことである。
ログが残るため、監査や原因追跡の利点がある。さらに再現性が高くなり、過去の状況を再構築してデバッグする道が開ける。ただし、イベントの増加に対する処理効率、スナップショット戦略、イベントの互換性など、運用面での設計が必要になる。
3.4 業務ドメインに基づく分割（ドメイン分離）
ドメイン分離は、状態を機能単位や責務単位ではなく、業務領域（受注、請求、在庫など）のまとまりで分ける方針である。目的は、関心の分離を強め、境界をまたぐ影響を最小化することにある。
この考え方では、各ドメインが保持する状態の意味と更新規則を明確にし、他ドメインとの連携はイベントや問い合わせの形で行う。結果として、状態変更の責任が明確になり、変更時の影響範囲を限定しやすい。分割の過度な細分化は逆効果になるため、業務上の整合性が保たれる単位で境界を定めることが求められる。
4 実務上の論点
4.1 非同期状態（ローディング・成功・失敗）
非同期処理では、「結果を待っている」「成功した」「失敗した」という段階が状態として表れる。これらを曖昧に扱うと、画面が永遠に待機したままになったり、失敗理由を適切に表示できなかったりする。
一般に、ローディング中は入力や操作の可否を制御し、成功時はデータを確定し、失敗時は再試行やフォールバックを可能にする設計が求められる。状態遷移は「開始」「応答受領」「後処理」などの段階を通じて整然と進むよう整理し、成功・失敗の分岐が画面の表示要素へ確実に反映されるようにする。
4.2 キャッシュと再取得戦略
キャッシュは応答の遅延を抑え、ネットワーク負荷を軽減する。だが、キャッシュが古いまま参照されると誤った表示や操作につながるため、無効化条件と再取得の方針が不可欠になる。
再取得戦略は、時間期限、参照の回数、ユーザー操作に基づく更新、通信エラー時の挙動などを組み合わせて設計される。特に競合領域では、再取得が並列に走った場合に「どの結果を採用するか」を決める必要がある。採用条件（最新の要求に紐づく応答のみ採用する等）を状態更新のルールとして固定すると、整合性の崩壊を抑えやすい。
4.3 永続化とセッション管理
永続化は、アプリ再起動や画面離脱後も必要な情報を維持するために行われる。典型例には、検索条件、入力途中、ユーザーのログイン関連の情報、UIの選択状態などが含まれる。
ただし、永続化するほど整合性の管理は難しくなる。セッション管理では、期限切れ、権限変更、データ形式の更新などにより、保存した情報が現状と合わなくなる可能性を考慮する必要がある。永続化される状態に対しては、「保存のタイミング」「復元時の検証」「不整合時のリカバリ（リセットや再認証）」を設計に含めるとよい。
4.4 並行更新と競合解決
並行更新は、同時に複数の要求や操作が状態へ影響する状況で発生する。例えば複数タブからの操作、同一データへの連続変更、非同期応答の到達順序が入れ替わるケースがある。
4.4.1 楽観的更新と確定処理
楽観的更新は、応答待ちの間もユーザー体験を損なわないよう、まずは成功すると仮定して状態を更新する手法である。その後、サーバからの結果で確定または取り消しを行う。ここで重要なのは、取消し時に整合性を戻す方法と、失敗時のユーザー通知の扱いである。
確定処理では、応答が返ってきた時点でローカル状態をサーバ基準へ合わせる。楽観的更新の利点は待ち時間の見え方にあり、欠点は失敗時の復元コストにある。よって、取り消しのために必要な情報（以前の状態、更新の識別子など）をどこまで保持するかを設計段階で決めることが求められる。
4.5 監視・デバッグ支援（状態の可視化）
状態管理の品質を高めるには、実行時の状態変化を追跡可能にする工夫が必要である。監視やデバッグ支援は、問題の発見を早め、原因特定の速度を上げる。
4.5.1 差分表示とタイムトラベル的発想
差分表示は、前の状態からどこが変化したかを要点として提示する考え方である。更新が多数ある状況で、人が理解すべき差分だけを抽出できるため、追跡負担が軽減される。
タイムトラベル的発想は、状態の履歴をたどって過去の状況を再現し、ある時点での表示や振る舞いを確認する考え方である。イベントの記録や不変性の活用と相性が良く、再現性のあるデバッグに寄与する。ログ量やプライバシーなどの運用課題もあるため、必要な範囲での追跡に設計を絞ることが現実的である。
5 テストと品質保証
5.1 状態遷移のテスト戦略
状態管理では、結果の値だけでなく、遷移の筋道が正しいかを確認することが重要になる。テスト戦略としては、状態入力（前提）とイベント入力（刺激）から、期待される次状態が得られるかを中心に組み立てる。
状態遷移は分岐が多くなりやすいため、主要ケース（正常、失敗、競合、タイムアウト、再試行）を状態図やシナリオとして整理し、そこに対応するテストを割り当てると網羅性が上がる。副作用がある場合は、状態更新と副作用実行を分離して検証できる設計にしておくと、テストの安定性が向上する。
5.1.1 ユニットテストでの検証観点
ユニットテストでは、状態変換器や更新関数の振る舞いに焦点を当てる。具体的には、同じ入力に対して同じ出力が得られるか、意図しないフィールドが書き換えられていないか、境界条件で破綻していないかを確認する。
また非同期に関連する場合でも、応答を模した入力を与えることで状態の分岐を検証できる。競合解決ルール（採用する応答の優先度など）も、このレベルで表現可能なら早期に検出できる。結果として、統合段階での不具合を減らす効果が期待できる。
5.2 統合テストとE2Eテストの役割分担
統合テストは複数コンポーネントや層（状態層、データ取得層、描画層など）を組み合わせ、境界での挙動を確認する段階である。E2Eテストは実際の利用に近い操作列を通じて、表示と操作の一連の流れが正しいかを評価する。
役割分担の目安として、状態変換の正しさはユニットで担保し、結合時の依存関係の破綻を統合で検出し、最後にユーザー目線の回帰をE2Eで押さえるとバランスがよい。E2Eはコストが高くなりやすいため、状態の枝分かれ全てをE2Eで網羅するのではなく、重要な経路と例外の代表だけに絞るのが実務的である。
5.3 回帰を防ぐためのチェックリスト
回帰は、過去に正しかった挙動が後の変更で崩れることである。チェックリストを用意することで、状態関連の変更が入ったときの検証を標準化できる。
- 主要な画面遷移で表示が期待どおりに更新されるか（入力値と送信値の一致を含む）
- 非同期応答の順序が入れ替わっても採用結果が矛盾しないか
- ローディング、成功、失敗の表示状態が過不足なく切り替わるか
- キャッシュの無効化条件が正しく働き、古い情報が優先されないか
- 永続化した情報が復元時に妥当性検証され、破綻時のリカバリが用意されているか
- 競合時に取り消しや確定が適切に動作し、ユーザーに誤解を生まないか
- 差分や履歴の記録が、必要な範囲で取得できるか
これらはすべてを毎回実施する必要はないが、変更の性質に応じて重点項目を選ぶことで、検出の漏れを抑えられる。特に状態の所在や更新ルールに変更が入った場合は、重点的に確認する価値が高い。