編集→編集確認パターン

例：顧客管理システム

顧客情報（会社名・担当者・連絡先など）を登録・更新する。

適用する原則: 編集はその場で行う、確認画面は最低限にする

要件

顧客情報は随時更新される
更新履歴を残したい
入力ミスを防ぎたい
複数人が同時に編集する可能性がある

典型

典型パターン：詳細→編集→確認別タブで開く ↗

典型の画面遷移

GET    /customers              一覧
GET    /customers/:id          詳細（参照のみ）
GET    /customers/:id/edit     編集画面
POST   /customers/:id/confirm  編集確認画面へ → セッション保存
GET    /customers/:id/confirm  編集確認画面   ← セッションから表示
POST   /customers/:id/back     修正する       → 編集画面へ戻る
PUT    /customers/:id          更新実行       → DB保存

典型のテーブル構造

起きる問題

詳細 → 編集 → 確認と3画面を遷移する
確認画面のためにセッション管理が必要
単純な更新なのにルートが多い

再設計

再設計パターン：詳細画面内編集別タブで開く ↗

再設計の画面遷移

GET    /customers              一覧
GET    /customers/:id          詳細（編集モード含む）
PUT    /customers/:id          更新 → 確認モード表示後、DB保存

再設計のテーブル構造

設計のポイント

詳細画面内に編集モードを持つ（画面遷移しない）
確認は「画面」ではなく「操作の一部」（モーダルやインライン確認）
セッション不要、常にDB保存

比較

画面遷移の比較

観点	典型	再設計
画面数	4画面	2画面
ルート数	7	3
編集	別画面	詳細画面内のモード
確認	別画面	操作の一部
保存	セッション + DB	DB のみ