HTTPステータスをエラークラス階層（例: 409→業務的に意味のある専用エラークラス、その他5xx全般→汎用エラークラス1種）にマッピングして返すAPIクライアント設計を採る場合、UI側のエラーハンドリングもそのクラス階層に合わせて分岐の粒度を決める。

判断基準: そのエラーに対してユーザーが取り得るアクション・理解すべき文脈が他のエラーと異なるかどうかで専用UIの要否を決める。「対象がすでに存在する」「権限がない」のような業務エラーはユーザーの次の行動が変わるため、instanceofで専用クラスを判定し専用モーダル/メッセージを出す価値がある。一方、502 Bad Gateway・504 Gateway Timeoutのようなインフラ・一時障害系のエラーは、原因の違いをユーザーに提示してもユーザー側の対応（時間を置いて再試行する程度）が変わらないため、個別のステータスコードごとに分岐を作らず汎用エラークラス1種にまとめ、共通の汎用エラートースト/メッセージへ流す。

この設計を採用している場合、フロントエンドの状態網羅（Storybook等でのAPIモック状態一覧）でも、業務エラー（例: 409）と汎用エラー（5xx系の代表1状態）の2区分で十分であり、502と504のように同じ汎用エラークラスにマップされるステータスコードを個別の状態として作り込む必要はない。作り込むとステータスコード数だけ状態が増えるが、UI上の分岐がそもそも無いため検証価値が薄い。

適用条件: APIクライアント層がステータスコードをエラークラスへマッピングする設計であること。マッピングをせず生のステータスコードでUI側if分岐している設計には直接当てはまらない。