マスタのコード体系設計｜カテゴリ・タグ・品番の命名を崩さないルール作り

検索・集計・外部連携の“地盤”になるのが、コード体系（カテゴリ、タグ、品番、ステータス等）です。
ここが崩れると、集計は信用されなくなり、検索UIは迷子になり、CSV更新（一括更新）も差し戻しが増えます。
この記事では、コード体系を崩さず運用するためのルールを、設計→運用の順で整理します。

1. 役割分担：カテゴリは「置き場所」、タグは「切り口」

まず混ぜないことが重要です。カテゴリとタグの役割は本来違います。

• カテゴリ：階層（ツリー）で、必ず1つ以上の所属を持つ「置き場所」
• タグ：横断（ラベル）で、複数付与できる「切り口」

カテゴリの作り方は カテゴリ構造テンプレート、
タグの活用は 改善施策に活かす の思想が基本になります。

2. 命名規則：人間が読めて、機械がブレない形にする

現場が見て理解できることは大事ですが、自由入力は表記揺れで破綻します。
推奨は「表示名」と「コード」を分けることです。

• 表示名：人間が読む（例：タイヤ交換／ホイール取付）
• コード：機械が扱う（例：TIRE_CHANGE / WHEEL_INSTALL）

コードは、英大文字＋アンダースコア、または固定長コードなど、規則で縛ります。
検索（サジェスト）や外部連携（冪等性）まで含めると、ブレないコードが効いてきます。

3. 階層設計：深すぎる階層は運用が死ぬ

階層は深いほど綺麗に見えますが、現場入力の負担が増えます。
基本は「2〜3階層で足りるか」を先に検討します。

• 大分類（例：製品／問い合わせ／予約）
• 中分類（例：製品カテゴリ、問い合わせカテゴリ）
• 小分類（必要な場合のみ）

「細かさ」はタグで補えるため、階層を深くしすぎない方が破綻しにくいです。

4. 変更運用：追加・統合・廃止の“手順”を仕様にする

コード体系が崩れるのは、変更運用が無いからです。
次の3つは、機能としてなくても良いので、少なくとも手順として決めます。

追加（増える）

• 追加は誰が申請し、誰が承認するか（関連：承認）
• 同義語が既にないか（検索ログ活用は 別記事 にも繋がります）
• 表示名・コード・説明文（用途）をセットで登録する

統合（まとめる）

• 統合先を決め、旧コードは「廃止（参照）」として残す
• 既存データの付け替え計画を立てる（CSVでやるなら 一括更新）
• 検索/フィルタのUIに反映（検索UI）

廃止（使わない）

• 削除ではなく「無効化」にする（過去データの参照があるため）
• 入力候補から消し、過去一覧では表示できるようにする

この“削除しない”思想は、重複マージ（統合設計）とも相性が良いです。

5. 検索UX：品番・キーワード検索はコード体系の出来で決まる

品番・型番が絡む領域は、入力補助（サジェスト）が強いですが、
そもそもコード体系がブレていると、サジェスト候補が“ノイズ”になります。

• 同義語：「ホイール」「アルミ」「AW」などの揺れを吸収する辞書を持つ
• 正規化：全角/半角、ハイフン有無、空白などを寄せる
• 表記：表示名は分かりやすく、検索キーはブレないように分離する

業種別の典型

卸売・商社（品番・カテゴリ・条件差分）

品番と条件（ロット、納期、分納等）の組み合わせが増えます。
業務像は 卸売・商社向け を前提に、
見積フォーム（項目設計）とカテゴリ体系が一致していると、入力・集計・連携が一気に楽になります。

自動車販売・整備・タイヤショップ（サイズ・適合・作業メニュー）

サイズ表記、適合条件、作業メニューが増えがちです。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、
予約（持込取付）や入庫（入庫予約）で、同じ語が別意味にならないよう、コード体系を先に固めると運用が破綻しにくいです。

インテンスでも、コード体系はUIの前に固める領域として扱い、後から直せない前提で慎重に設計します。

まとめ

コード体系は、検索・集計・連携の“地盤”です。
カテゴリ（置き場所）とタグ（切り口）を分け、表示名とコードを分離し、追加・統合・廃止の手順を仕様として持つ。
これだけで、システムの寿命と運用コストが大きく変わります。