カテゴリ階層を設計する
2026年9月11日 更新概要
- カテゴリは最大3階層まで登録できます。階層設計を整えておくと、トピック分析・ダッシュボード・チケット化のすべてで絞り込みや自動分類が安定します。
- 本ガイドではカテゴリ構造を考える際のポイントと、運用時に見直すべき項目をまとめます。
画面パス
設計の基本方針
- 階層はシンプルに: ルート（大分類）→中分類→小分類の3階層を上限とし、利用者が迷わず選べる粒度に揃えます。
- 重複を避ける: 同じ意味のカテゴリを複数作らず、名称に業務用語や製品名を入れて区別します。
- 説明文を充実させる: それぞれのカテゴリに「含める例」「除外する例」を記載し、判断基準を明確にします。
- 自己解決可否を定義する: FAQやマニュアルで解決できるなら「自己解決可」、有人対応が必要なら「自己解決不可」に設定し、KPI分析に反映させます。
- 外部IDを管理する: 他システムと連携する場合は外部ID欄を利用し、マッピングを台帳で管理します。
運用の流れ
- 現状把握 トピック画面で「カテゴリ未分類」の件数や、チケット化が多いカテゴリを調べ、整理が必要な領域を把握します。
- 案の作成 表計算ソフトなどで新旧の階層を一覧化し、統合・細分化するカテゴリを検討します。必要に応じてCSVエクスポートを活用します。
- 編集モードで調整 「カテゴリ」画面の編集モードで追加・削除・説明文の更新を行い、保存前に構造を確認します。
- トピックへの反映と検証 大きく変えた場合は「トピックに反映」を実行し、誤分類が改善しているかを確認します。「トピックに反映」の対象は、ソースの総件数が30,000件以下であれば全件、30,000件を超える場合は新しいものから30,000件です。
- 周知とドキュメント更新 変更内容や運用ルールを社内の共有スペースに記載し、サポートチームへ周知します。
チェックリスト
- ルートカテゴリの数が多すぎないか（5〜10個程度が目安）。
- 各階層で「その他」「その他（○○）」が必要以上に増えていないか。
- 説明文に最新のサービス名や機能名が反映されているか。
- タグ条件や自己解決可否がチームの運用ルールと一致しているか。
- 外部連携のマッピング表が最新か。
トラブルシューティング / FAQ
- 階層を深くできない: カテゴリは最大3階層までです。必要に応じて中分類を追加し、階層構造を再設計してください。
- 同名カテゴリが作れない: 同じ階層内では名称が重複しないようにしてください。区別が必要な場合は「A-新規」「A-既存」などラベルを工夫します。
- 変更後にトピックが未分類に戻った: 説明文やタグ条件が厳しくなりすぎた可能性があります。「含める例」「除外する例」とタグ条件を見直し、条件を緩めてから「トピックに反映」を実行してください。
- 外部IDを変更したい: 連携システムへの影響が大きいため、事前に関係者と調整し、CSV更新とマッピング表の更新を同時に行ってください。
関連ドキュメント
