既存のタグ/カテゴリとは別の「分類軸」を新設して第一級データにしたくなったとき、いきなりスカラーな enum カラムにすると後で詰まる。先に軸の性質を判定して表現を選ぶ。

判定する性質と対応

• 多ラベルか: 1 レコードが複数値を同時に持ちうるなら、スカラー列は情報を捨て、分類器に恣意的な単一選択を強いてノイズを生む。→ 配列カラム（text[] + GIN）か多対多の join にする。単一値が確実なときだけスカラー列。
• 語彙が進化するか: 値の追加・改名・削除が将来起きるなら、ネイティブの DB enum 型は硬い（追加に制約、削除・改名が特に高コスト）。→ text + CHECK 制約、または lookup テーブルにして語彙変更を安いマイグレに保つ。
• 誰が所有するか: システム固定の閉じた語彙（分析や生成が依存する）か、ユーザーが自由に増減・改名するタグか。両者を同じ仕組みに混ぜない。システム所有の軸をユーザー編集タグのテーブルに相乗りさせると、ユーザー操作で分析の前提が壊れる。

backfill と消費側

• 既存行に値が無い状態で NOT NULL + デフォルト値を入れると、本来別カテゴリのレコードが一律デフォルトに化け、その軸で取りたかった分析を汚す。→ nullable か明示的な unclassified にし、go-forward（新規から付与）を基本にする。
• 第一級化＝下流が filter/集計に使うということ。消費側（分析・表示）が実在してから列を足す。読む人がいない分類列は、ノイズだけ抱えた dormant フィールドになる。
• 自動分類は soft signal として扱い（hard なゲートにしない）、ユーザーが容易に訂正できるようにする。境界が曖昧な軸は定義と例を crisp にしないと信号が劣化する。

検証

新軸を入れる前に「多ラベルか／語彙は固定か／所有は誰か／消費側はあるか／既存行はどう扱うか」に答えられるか確認する。答えられないうちは、専用カラムでなくタグ的な軽い表現で検証し、固まってから第一級化する。