機能要望をAIで分類する方法｜カテゴリ設計と精度の確かめ方
目次
要望が100件を超えてくると、ひとつずつ読んで振り分ける運用が難しくなってきます。ここでAIによる分類が選択肢に入りますが、丸投げして精度が出るものではありません。うまく機能するかどうかは、AIに渡す前の設計、即ち、何の軸で分けるか、各カテゴリをどう説明するかでほぼ決まります。
この記事では、分類軸の決め方から、AIに任せられる工程と人が見るべき工程の線引き、そして自社の要望データで精度を確かめる手順について紹介します。収集から優先順位づけまでの全体像は機能要望管理とは？収集・整理・優先順位付けの基本を、収集そのものは機能要望の収集を一本化する方法をご覧ください。
- 分類の軸は、優先順位づけなど後工程から逆算して決める。探しやすさのための分類は使われない
- 精度を左右するのはプロンプトの書き方ではなくカテゴリの説明文。何を含み、何を含まないかを書く
- 精度は公式情報やデモの印象ではなく、自社データ100件の人の手によるレビューで確かめる
分類の軸は逆算して決める
AIに渡す前に決めるべきなのは、「何の軸で分けるか」になります。ここが曖昧なまま分類を始めると、どれだけ精度が高くても使われない分類ができあがります。
分類は整理整頓のためにやるものではなく、次の判断に使うためのものです。だから軸は、分類した後に何をしたいかから逆算していきましょう。
| 後工程 | 向いている軸 |
|---|---|
| 優先順位を決めたい | 解決したい課題の単位 |
| どの領域に要望が集中しているか知りたい | プロダクトの機能・画面の単位 |
| 対応する担当を割り振りたい | 要望の種類（新機能・既存改善・不具合） |
迷ったら、課題の単位を軸にするのがやりやすいです。機能案そのものでまとめると「ダークモード」と「配色変更」が別々に数えられて票が分かれてしまいますが、課題単位なら同じ束にまとまり、そのまま優先順位づけの材料になります。
一方、「誰が言ったか」「どの経路で届いたか」は分類軸には向いておりません。これらは要望を記録する時点で属性として持たせておき、集計時にフィルタとして掛け合わせるものです。軸を1本のカテゴリツリーに全部詰め込もうとすると、カテゴリ数が非常に増えてしまい、かえって振り分けられなくなります。
AI分類における2つの型
軸が決まったら、AIにどう手伝わせるかについて決めていきましょう。ツールや手法はさまざまですが、やっていることは大きく2つに分かれます。
| テーマ | 何をするか | 向いている場面 |
|---|---|---|
| カテゴリへの割り当て | あらかじめ決めたカテゴリに1件ずつ振り分ける | 分類軸がすでに決まっている |
| まとまりの発見（テーマ抽出） | データから自然なグループを自動で見つける | 何が届いているか分かっていない |
前節のように軸を決めてから使うなら前者、そもそもどんな要望が届いているのか把握できていない段階なら後者（いわゆるテーマ抽出）、という使い分けになります。運用としては、最初に「まとまりの発見」で全体像をつかんでカテゴリ案を作り、以降は「割り当て」を行っていく、という形がおすすめです。
この2つに、別々のツールが要るわけではありません。ChatGPTやClaudeに、カテゴリ定義を渡して1件ずつ振り分けさせれば前者、要望リストだけを渡して「近い内容ごとにまとめて」と頼めば後者になります。同じ生成AIでも、何を渡すかで型が切り替わるだけです。
精度を決めるのは、カテゴリの説明文
分類がうまくいかないとき、原因はプロンプトではなくカテゴリ設計にあるかもしれません。カテゴリ名だけ決めて放り込む形では難しいでしょう。なぜなら、名前しか情報がなければ、AIは「認証」という2文字から中身を推測するしかないからです。
持たせるべきは、カテゴリごとの説明文です。イメージとしては、入社初日のメンバーに口頭で説明するつもりで、何を含み、何を含まないかまで書くとよいです。除外条件を書くことで、隣のカテゴリとの境界が綺麗に整理されます。
カテゴリ名 — 認証とアクセス
含む — ログイン、多要素認証、パスワード再設定、アカウントへのアクセス
含まない — 表示速度、稼働率、システム全体の性能に関する問題
粒度で迷ったら、似た要望でも、解決に必要な動きが違うなら別カテゴリにするという基準が使えます。逆に、2つのカテゴリが同じ要望を拾える状態は誤分類のもとなので避けます。
すでに集まった要望を人手で束ね直す作業は別の工程です。粒度のそろえ方は機能要望の重複統合・粒度そろえの実践Tipsで扱っています。
生成AIと表計算で今日から始める
ここまでの設計ができていれば、あとは使い慣れた生成AIに渡すだけで、専用ツールは不要です。もし、現在スプレッドシートで要望を管理しているなら、そのまま試せます。
やることは単純で、ChatGPTやClaudeに次の2つを渡すだけです。
- カテゴリ定義（前節の「含む・含まない」形式で書いたもの）
- 要望の元の文面（要約せず、言われたとおりの言葉）
返してもらう項目は「カテゴリ名」「確信度（高・中・低）」「判断根拠となった元の文の抜き書き」の3つで指定します。結果をシートの列に貼り付ければ、確信度「低」だけを人が見る運用がすぐ開始できます。
この方法の利点は費用面もありますが、それだけではありません。ここで書いたカテゴリ定義と、後述する検証結果は、将来専用ツールに移行するときそのまま持ち越せる資産になります。逆にここを飛ばしてツールを先に利用を開始したとしても、結局カテゴリ設計から始めることになります。
なお、要望データには顧客名や取引情報が含まれがちです。外部のAIサービスに渡す前に、入力データの扱い（学習への利用有無など）と自社の規程は確認しておいてください。
まず100件試してみる
やっかいなのは、分類器は**「わかりません」とは返さず、それらしい誤った値を返す**ことです。結果の一覧を眺めるだけでは、もっともらしく埋まったカテゴリ列から誤りを見つけられません。だからこそ、運用に載せる前に自社データでの検証が要ります。
「精度が不安だから導入できない」で止まりがちですが、検証は思ったより小さく始められます。
LLM評価の実務ガイドとして知られる Hamel Husain らの記事では、経験則として少なくとも100件を人がレビューすること、そして約20件見て新しい失敗パターンが出てこなければ止めてよいことが示されています（出典）。
自社データから100件抜き出す
実際に届いた要望をそのまま使います。きれいなサンプルではなく、雑然としたものを含めてください。
AIの分類結果を人が見て、誤りにメモを書く
正誤の判定だけでなく、どう間違えたかを自由記述で残します。この段階では整理しません。
メモを失敗の種類ごとにまとめ、件数を数える
ここが要です。すべての失敗を潰すのではなく、実際に多く起きているものから手を付けます。
多い失敗に対してカテゴリ定義を直す
プロンプトをいじる前に、カテゴリの説明文と除外条件を見直すほうが効きます。
同じ100件を使い回すことができれば、プロンプトの直し方やモデルの乗り換えの効果も同条件で試せます。将来専用ツールを検討することになっても、この検証がそのまま判断材料になります。
任せる範囲と、人が見る範囲
量をさばく工程、即ち、取り込み、重複のマージ、カテゴリへの割り当て等はAIに寄せられます。一方、カテゴリの説明文を書く、確信度の低い結果を確認する、見えてきた傾向をどう解釈するかは人の工程です。主要なツールが軒並み人の確認・修正ステップを残しているのは、この境界がプロダクト設計上の共通解になっているためです。
分類は最初のレイヤーにすぎません。分類できた束のうちどれから作るかという判断は、事業の文脈を知る人にしかできません。優先順位の決め方は開発する機能の優先順位を決める方法で扱っています。
アーコレ運営の知見
アーコレを運営する私たち自身も、本文とまったく同じ生成AI+スプレッドシートの運用で、寄せられた要望を分類しています。ここまで書いた手順は、私たちが実際に回している手順そのものです。ただし「AIが分類し、人がそれに従う」形にはしていません。事業の状況や顧客ごとの背景といったコンテキストは、どうしてもAIに渡しきれないため、最終的な判断は人が行うと決めています。一方で、届いた要望をすべて議論のテーブルに上げると、今度は多すぎて人が判断できません。そこで、人が判断できる量まで候補を削る前処理だけをAIに任せる、という線引きに落ち着きました。
運用してみて効いた工夫は2つあります。ひとつは、カテゴリ定義と一緒に用語の辞書を渡すこと。プロダクト固有の言葉や顧客特有の言い回しは、前提を与えないと一般的な意味で解釈され、別の話と混同されることがありました。もうひとつは、一度に渡す件数を絞ること。大量にまとめて分類させると、同じ定義を渡していても結果がブレていきます。
そして一番の学びは、誤分類を「AIの精度の問題」で片付けないことです。振り分け結果がおかしいときは、たいてい渡しているコンテキストのほうが足りていません。結果を見て何が不足していたかを見抜き、辞書とカテゴリ定義をブラッシュアップしていく。この繰り返しが精度を育てます。
よくある質問
1件の要望が複数のカテゴリにまたがる場合はどうすればよいですか？
それは異常ではなく、要望データでは普通に起きます。無理に1件1カテゴリへ押し込もうとすると、押し込むためにカテゴリ定義のほうが歪んでいきます。複数タグを許容する設計にしたうえで、集計時にどう数えるか（重複して数えるか、主カテゴリだけ数えるか）をチームで決めておくほうが現実的です。
分類の前に要望を要約させてもよいですか？
分類対象は元の文面にしてください。要約を挟むと、誤分類が起きたときに原因が元の要望のどこにあったのかを追えなくなります。また要約の時点で情報が削られるため、要約と分類の2段階で誤りが重なります。要約は分類の入力ではなく、人が一覧を読むための補助として使ってください。元の言葉を残す理由は機能要望の収集を一本化する方法（/learn/feature-request-collection）でも扱っています。
カテゴリはいくつくらいが適正ですか？
件数より先に、後工程で使い分ける必要があるかで決めてください。目安としては、全カテゴリを1画面で見渡せて、新しい要望をどこに入れるか迷わない数（多くの場合10〜20個）に収まります。それを超えて細かくしたい場合は、カテゴリを増やすのではなく、属性（顧客セグメントや経路）との掛け合わせで表現できないかを先に検討します。
まとめ
AIで分類する準備とは、モデルやツールを選ぶことではなく、後工程から逆算した軸と、含む・含まないまで書いたカテゴリ説明文を用意することでした。ここさえできていれば、使い慣れた生成AIとスプレッドシートで今日から試せます。
自社の要望データで使えるかどうかは、試すまで分かりません。100件を人が見る検証を先に済ませてから、運用に載せる範囲を決めていきましょう。
