はじめに
記録時点: 2024-10〜2025-01
タグ機能は導入直後こそ便利ですが、運用が進むほど分類が崩れます。 今回の課題は、機能不足ではなく「同じ意味のタグが増殖すること」でした。
この記事で扱う範囲
- 表記ゆれ・意味ゆれ・粒度ゆれの発生パターン
- 分類層を再定義した理由
- 命名レビューを運用へ組み込んだ方法
何が起きていたか
症状は大きく3種類でした。
- 表記ゆれ: 全角半角、語順、略語の揺れ
- 意味ゆれ: 同義語が別タグとして増える
- 粒度ゆれ: 教科レベルと単元レベルが同列で混在する
この状態では、タグ数が増えるほど検索品質が落ち、運用修正コストが上がります。
実装で変えたこと
1. タグを3層に分けた
同一入力欄へ全てを入れる運用をやめ、 大分類・中分類・補助タグの3層で扱うようにしました。
2. 命名ルールを追加前チェックへ組み込んだ
新規タグ追加前に、同義語・一般表記・将来運用の3点を確認する運用へ変更しました。
type TagValidation = { ok: boolean; reason?: string };
function validateNewTag(input: string, existing: string[]): TagValidation {
const normalized = normalizeTag(input);
if (existing.includes(normalized)) return { ok: false, reason: "duplicate" };
if (normalized.length < 2) return { ok: false, reason: "too-short" };
return { ok: true };
}3. 既存タグ統合を段階手順へ変更した
一括統合ではなく、影響範囲確認→置換→検索確認の順で進める方式にしました。
見送った案
1. タグ自由入力を完全禁止する
品質は上がる一方、現場の追加速度が落ちるため採用しませんでした。
2. 定期バッチで自動統合する
短期は楽ですが、誤統合の運用リスクが高いため見送りました。
3. 揺れをUI側だけで吸収する
表示上は揃ってもデータ整合が悪化するため不採用です。
運用で固定した確認観点
| 観点 | 期待値 |
|---|---|
| 同義タグ統合 | 検索漏れを発生させない |
| 新規追加 | 既存候補との重複を防ぐ |
| 粒度混在 | 3層分類で吸収できる |
| 主要求人検索 | 担当者が変わっても同じ結果になる |
この回の判断が次に効いたこと
運用ルールを機能設計と同じ優先度で扱う方針は、次の記事にもつながっています。
まとめ
タグ運用は、放置すると必ず分類が揺れます。 機能追加より先に分類層と命名ルールを整えたことで、タグを増やしても検索品質を落としにくい状態へ戻せました。