この技術でできること
- 画面移動して戻ってきた時に「データが消えている」という重大なUX毀損を防ぐことができる
- アプリ全体で共有すべきデータと、その画面だけで閉じるデータを分け、古い情報が残ることによる混乱を削減できる
- URLを一つの「状態」として活用し、SNSでのシェアやブラウザの「戻る」ボタンが正しく動くUIを設計できる
例: 検索結果画面でフィルターをかけた後、詳細画面を見て「戻る」ボタンで戻った際、状態管理が正しく設計されていればフィルター条件がそのまま残っています（URLのパラメーターに状態を持たせる設計など）。ユーザーは再度検索し直すストレスから解放されます。
なぜ難しいか
現代のWebやアプリは、単なる「紙のページ」ではなく「生きているソフトウェア」だからです。
ユーザーが入力した文字、開いているモーダルウィンドウ、サーバーから取ってきた最新の在庫数……これら変化するデータすべてが「状態（State）」です。この「状態」をどこに保存しておくかの設計を誤ると、「一覧では既読なのに詳細では未読になっている」といったデータ矛盾や、「画面遷移するたびにリセットされるフォーム」といった使いにくいUIが量産されます。
設計プロセスの判断ポイント（Before/After）
パターン: ローカル（局所）とグローバル（全体）の分離
Before（現実の悪い例）: 「入力途中のコメント」や「今開いているドロップダウンの表示状態」まで、すべてのデータをアプリ全体で共有する巨大な保存領域（グローバルステート）に詰め込んでしまう。 → エンジニア視点では、どの画面がどのデータを変更したかが追えなくなり、別の画面を開いた時に意図せずドロップダウンが開いたままになるなどのバグ（状態の汚染）が多発する。
After（現実的な整理）: 状態の「寿命」と「影響範囲」を見極め、保存場所を明確に分ける。
- ローカル: 「モーダルの開閉」など、その画面が消えたら捨てていい状態（破棄する）
- グローバル: 「ログインユーザー情報」など、アプリ全体で常に必要な状態（保持する）
なぜ改善されるか（なぜ現実的か）: 「画面が破棄されたら一緒に忘れてもいいデータ」をシステム全体から切り離すことで、不具合の波及を防げるからです。記憶を最小限に保つことは、システムの安定動作（UXの一貫性）に直結します。
代替手段: もしローカルな状態（例：入力中の長い文章）を画面遷移後も残す必要があるなら、グローバル状態にあげるのではなく「下書きとしてサーバーやブラウザ内ストレージに保存する」という機能要件に変更する。
アンチパターンと衝突（デザイナー × エンジニア）
❌ 「別の画面に行っても、さっき入力した情報を全部出しておいて」
デザイナーの視点: ユーザーの入力の手間を省きたい。一度選んだカテゴリや入力した検索キーワードは、どの画面に遷移してもずっと引き継いでおいてほしい。（品質＝完全な利便性と入力記憶） エンジニアの視点: 一時的な情報をずっとメモリ（グローバル）に持ち続けると、メモリリークの原因や、別のタスクを始めた時の「古いデータの表示」というバグを生む。遷移したら一旦リセットするのが安全だ。（品質＝メモリの安全性と状態のクリーンさ）
なぜ衝突するか（品質の定義差）: デザイナーは「便利さ＝すべての記憶の保持」と捉える傾向があり、エンジニアは「不要な記憶の保持＝負債やバグの温床」と捉えるためです。
どう合意するか:
- 記憶すべき内容を「URLのパラメーターに含める（シェア可能にする）」「データベースに保存する」「一時的にメモリに持つ」のどれで解決するかを要件定義の段階で共に設計する。
- 何でもアプリ側に持たせず、ブラウザの自然な復元機能に任せることも視野に入れる。
実践チェックリスト
最低ライン（Must）
[ ] UIデザインを作る際、その画面が「どんなデータ（状態）を前提として表示されるか」を定義している [ ] ユーザーが「リロード」や「ブラウザバック」した時に画面がどうなるかを想定している
理想ライン（Better）
[ ] 「この状態はURLに持たせますか（例：?tab=profile）、内部で持ちますか」とエンジニアに提案できる
[ ] モーダルやフォームの設計時、一時的な状態（ローカル）なのか保存すべき状態（グローバル）なのかを切り分けている
関連技術
前提となる技術
- コンポーネント設計 — 状態をどこに閉じ込めるかを決める「箱」の設計
次に学ぶ技術
- API設計 — 手元の状態を、いつどのように本サーバー側と同期させるかの設計
まとめ
- この技術の本質: 時間の変化とともに移り変わるデータを「どこに置き、いつ捨てるか」の交通整理
- 体験への影響: 画面のあちこちで矛盾したデータが表示される不快感を防ぎ、アプリへの信頼性を担保する
- 実務での判断軸: 「画面を移動して戻ってきた時、この情報は消えていても許されるか？」
- 次に学ぶべき技術: API設計（システム全体の究極の「グローバル状態」であるサーバーとの連携方法を学ぶ）
目的別のおすすめ:
- フロントエンド層をどう分割するか知るなら → コンポーネント設計
- 全体構造から見直すなら → アーキテクチャパターン
