ハードコードされたドロップダウン enum を「設定で編集できる DB マスタ」に移行する

Webアプリで、種別・カテゴリ等の選択肢が 複数の UI ファイルに配列でベタ書き され、さらに DB の CHECK 制約 / enum でも固定されている状態を、利用者が設定画面から自分で追加・編集できるマスタテーブルに一本化する手順。新カテゴリ追加のたびにコード改修＋マイグレーションを複数箇所で行う運用を解消する。

想定スタック: 任意の SQL DB（Postgres 等）＋サーバーサイドレンダリングの Web フレームワーク。以下は一般化した手順。

手順

1. マスタテーブルを新設

create table if not exists <items> (
  id uuid primary key default gen_random_uuid(),
  name text unique not null,
  sort_order int not null default 100,
  is_active boolean not null default true,
  created_at timestamptz not null default now()
);
-- 既存でハードコードされていた全選択肢の「和集合」をシード(冪等)
insert into <items> (name, sort_order) values ('<値1>',1),('<値2>',2), ... 
on conflict (name) do nothing;

※ UI ごとに配列がバラバラ（違う値集合）なことが多い。全 UI の値の和集合を必ずシードする。

2. 固定 CHECK / enum 制約を撤廃

alter <対象カラムの型/テーブル> drop constraint if exists <column>_check;

値の正当性は「マスタから選ばせる UI」で担保する方式に切り替える。これをやらないと、マスタに足した新値を保存した瞬間 CHECK 違反で弾かれる。

3. 共通ヘルパーで選択肢を供給

getActive<Items>() = is_active=true を sort_order 昇順で返す関数を1つ作り、全ての select がこれを呼ぶ（ベタ書き配列を全廃）。ページはサーバー側で取得。

• 現在値がマスタに無い場合の保険 option を必ず足す（無効化済み/旧値でも、既存レコードの選択が UI から消えないように）。

4. 設定画面に CRUD を追加

一覧（名前/並び順/有効無効）＋追加＋リネーム＋有効/無効トグル。既存の「マスタ管理」系設定ページを雛形にすると速い。

5. 書き込みは管理者クライアント(RLS バイパス)で

テーブルの行レベルセキュリティが「管理者のみ書込」でも、設定操作のサーバーアクション自体が認証ゲートなので、アクション内では admin/service ロールのクライアントを使い、一般権限の利用者でも self-serve で編集できるようにする。

落とし穴（必ず守る）

• 値でロジック分岐しているコードは絶対に触らない。if (type === "特定値") {...} のような value-keyed 分岐は選択肢の供給源変更とは無関係。マスタで値をリネームするとこの分岐が壊れるので、リネームは分岐対象値を避けるか同時にコードを直す。
• 同じ意味で違う表記の値（例 "A" と "A社向け"）が別 UI に混在していることがある。統合時に別値として両方残すか、リネーム辞書で寄せるかを先に決める。
• CHECK 撤廃は「アプリが唯一の入口」である前提。DB を直接叩く経路があるなら、トリガや FK で別途担保する。

検証（完了報告の前に必ず）

1. 型チェック。
2. マイグレーション適用後、マスタ内容を read-back（シード件数・新値・制約が消えたこと）。
3. 各画面を実際に開いて選択肢がマスタ由来で出ること、設定画面で追加→即 select に反映されることを確認。