アンケート自由記述のAI採点、結果がブレる原因は基準側

画像出典: 写真: Raimond Spekking（CC BY-SA 4.0 / Wikimedia Commons）

自由記述欄は、設問の数字では見えない本音が出てくる一番おいしい部分です。それなのに集計の段になると、一件ずつ読んで「これは価格の不満」「これは問い合わせ対応の話」と手で振り分ける作業になり、締切に追われて雑になる。正直なところ、ここが一番やりたくない工程だと思います。

AIに渡して仕分けさせる話は当然出てくるのですが、やってみた人の感想はだいたい二つに割れます。「かなり使える」と「同じ回答が日によって違うカテゴリに入るので信用できない」。この差は、実はモデルの選び方よりも渡した基準の書き方で決まります。どう組むとブレないのか、そして基準が曖昧なときに何が起きるのかを、順番に見ていきます。

AIに自由記述を採点・分類させる手順は？

Anthropicの公式ドキュメント「Classification」は、分類タスクの実装を4段階で示しています。①強いプロンプトを作る ②テストケースを用意する ③評価（eval）を実行する ④分類器を本番投入する。順番が大事で、プロンプトを書いたらすぐ全件に流すのではなく、正解がわかっている少数のケースで答え合わせをしてから本番に出す形です。

同ガイドでは、プロンプトを練る時間の大半は「強い評価セット（eval）の構築」に使われるとされています。つまり作業の重心は、うまい指示文をひねり出すことよりも、何が正解かを自分で決めておくことにあります。ここが決まっていないと、出てきた分類が合っているのか間違っているのかを判定できません。

1. カテゴリを決めて言葉で定義する「価格」「問い合わせ対応」といったカテゴリ名だけでなく、それぞれ何を含み何を含まないかを一文ずつ書きます。境界が曖昧な組み合わせ（価格と機能など）は、どちらに寄せるかも決めておきます。
2. 正解つきのテストケースを30〜50件作る過去のアンケートから回答を抜き、自分でラベルを付けます。きれいな回答ばかり選ばず、皮肉・両方の話が混ざった回答・短すぎる回答を意図的に入れます。
3. プロンプトに基準と実例を載せるカテゴリ定義をそのまま書き込み、入力と出力の例を2〜5個添えます。出力はJSONなど機械で集計できる形式を指定します。
4. テストケースで答え合わせをする自分のラベルとAIの出力を突き合わせ、合わない件を一覧にします。ここで出た不一致が、基準を直すための材料になります。
5. 基準を直してから全件に流す不一致の原因がカテゴリ定義の曖昧さなら定義を書き直し、例の不足なら例を足します。納得できる水準になってから本番の件数に広げます。

Claudeの成功基準の定義ガイドでは、モデルが何をすべきか・何を無視すべきか・どの文脈を使えるか・どの形式で返すか・どう成功を測るかを明示することが推奨されています。自由記述の仕分けに当てはめると、「無視すべきもの」の指定が特に効きます。「ご担当者さまいつもありがとうございます」のような挨拶文や、設問の意図から外れた雑談を分類対象から外すかどうかで、集計結果の見え方が変わります。

採点基準（ルーブリック）はプロンプトにどう書くのか？

「5段階で満足度を採点して」とだけ渡すと、3点と4点の線引きがAI側の裁量になります。採点を伴う場合は、各点数が何を意味するかを言葉にした採点基準表を一緒に渡します。

評価基準の組み込み方には、プロンプト文中にそのまま書き込むほかに、出力の最後に自己チェック項目を置く、生成前に「必ず満たす条件」を宣言させる、生成後に条件を満たしていなければ修正させる、といったやり方があります。分類と採点を同時にやらせるなら、出力の末尾に「選んだカテゴリの定義文を引用し、回答のどの部分が該当するかを示す」と足しておくと、根拠が目に見えるので人のレビューが速くなります。

正解ラベルが存在しないけれど評価基準は明確に定義できる場合、モデルに採点させる手法（LLM-as-a-judge）はAnthropicの評価ガイドでも有効な手法として紹介されています。自由記述の満足度採点はまさにこの形です。ただし「評価基準が明確に定義できる場合」という条件が付いていることに注意してください。基準を言葉にできていない状態で採点させるのは、この手法の前提から外れます。

実例は2〜5個、ラベルを偏らせない

Few-shotプロンプティングは、実際の問い合わせの前に入出力の例を2〜5個提示する手法です。形式・トーン・判断の深さは、言葉で説明するよりも実例を見せたほうが効果的に伝わるとされています。カテゴリ定義で書き切れない微妙な線引きは、境界ぎりぎりの回答を例にして「これはこちら」と見せるのが早いです。

ここに落とし穴が一つあります。例のラベルが同じものに偏っていると、モデルは入力の内容に関わらずそのラベルへ引き寄せられます（ラベル偏重）。手近な回答から例を作ると、たまたま多いカテゴリばかりになりがちです。例を並べたら、ラベルの内訳を数えてバランスを確認してください。

分類タスクでは温度（temperature、出力のばらつき具合を決める設定値）を0にして一貫性を高めるのが標準的な推奨です。ただし温度0でも、API経由のホスト型推論では完全な決定性は保証されないという指摘もあります。同じ回答を二回投げて違う結果が返ることはゼロにはできない、という前提で設計しておくのが安全です。

基準が曖昧だと、なぜ結果がブレるのか？

顧客フィードバックのテキスト分析では、分類カテゴリ（タクソノミー）が「製品」「サービス」のような大まかなテーマだけだと、ニュアンスの違うフィードバックが不適切に一括りにされる問題が指摘されています。「アプリが重い」と「機能が足りない」はどちらも製品の話ですが、同じ箱に入れてしまえば打ち手は何も決まりません。

逆に、細かくすれば良いわけでもありません。NPS（顧客推奨度。「このサービスを人に薦めますか」を0〜10で聞き、理由を自由記述で書かせる調査形式）などの自由記述回答を大規模に分類する際は、タクソノミーを事前に明確に定義することと、カテゴリ数を絞って単純な構造にするほうが複雑な階層構造より精度が高くなりやすいことが推奨されています。粒度の粗さと、カテゴリの定義の曖昧さは別の問題です。直すべきは後者が先です。

もう一つ、運用を始めてから効いてくるのがドリフト（経年劣化）です。専門家が作ったタクソノミーの問題は初期の精度ではなく、製品や顧客の言葉遣いが変化すると固定的な分類構造が徐々に誤分類を起こすようになる点にあるとされています。新機能が出れば顧客はその名前で語り始めますが、カテゴリ表は去年の言葉のままです。四半期ごとに「どのカテゴリにも入れにくかった回答」を見返す時間を、運用に組み込んでおくといいです。

皮肉と混在した感情は誤分類されやすい

2026年のベンチマークでは、37モデルにわたってハルシネーション率が15%〜52%の範囲で報告されており、皮肉・感情の混在・文化的ニュアンスを含む文章は、一般的なWebテキストで学習されたモデルによって頻繁に誤分類されるとされています。幅が大きいのは測り方とモデルの差で、どのモデルでも一定割合は間違うという前提で読むのが実務的です。

「対応は早くて助かりました（二週間かかりましたが）」のような回答は、前半だけ読めば称賛です。自由記述にはこの種の文が必ず混ざるので、テストケースにも意図して入れておきます。そこで落ちることが事前にわかっていれば、該当しそうな回答だけ人が見るという切り分けができます。

AIが採点役になるときの偏り

採点をモデルに任せる場合、自己優先バイアス（self-preference bias）という傾向が研究で指摘されています。評価者となるLLMが、自分自身または似た傾向のモデルが生成した回答を高く評価する傾向で、特定の思想やスタイルを助長するリスクがあるとされます。原因は完全には解明されていませんが、モデルにとって馴染みのあるテキストを好む傾向が一因と説明されています。対策として、評価対象のモデルとは異なるモデルを評価者に用いる方法が提案されています。

自由記述は人間が書いたものなのでこのバイアスの影響は限定的ですが、AIで下書きした回答が混ざる場面（社内向けの記述式調査など）では頭に入れておく価値があります。また、同一入力に対する判定のゆらぎ（flipping noise と呼ばれます）は、位置バイアスや長さバイアスと並ぶ再現性低下の要因として研究されています。長い回答が短い回答より高く採点されやすい、といった傾向が混ざりうるということです。

うまく分類できなかったとき、どこを疑うか？

結果が納得できないときに、いきなりモデルを変えるのは遠回りになりがちです。原因は指示文側・渡したデータ側・モデルや環境側の三つに分けられるので、順に切り分けます。

1. まず指示文を疑う誤分類された回答を5件取り出し、自分がその回答をどのカテゴリに入れるか、その判断根拠がカテゴリ定義の文に書かれているかを確認します。書かれていなければ原因は定義側です。定義に一文足して、同じ5件を再実行します。
2. 次に渡したデータを疑う定義には書かれているのに外れる場合は、実例を見ます。ラベルの内訳が偏っていないか、例に使った回答が本番の回答と文の長さや口調で大きく違わないかを見ます。例を差し替えて再実行します。
3. 最後にモデル・環境側を疑う同じ入力・同じ指示文で結果が毎回変わるなら、温度が0になっているかを確認します。それでも揺れる場合は、API経由では温度0でも完全な決定性は保証されないという前提に当たっています。入力が長すぎて後半が効いていない可能性もあるので、1回のリクエストで渡す件数を減らして試します。

どの段で直ったかを記録しておくと、次の調査で同じ回り道をしなくなります。筆者が試した環境と日付（使ったモデル名・プラン・実行日）もメモに残してください。精度の話は、どのモデルでいつ測ったかが抜けると比較できなくなります。

改善の度合いは、印象ではなく数字で見ます。評価指標は精度（precision）・再現率（recall）・F1スコアといった定量指標で測定すべきで、ベンダーの主張や印象論に頼るべきではないとされています。手計算でも、テストケース50件のうち何件が自分のラベルと一致したかを数えるだけで、直前の版と比べられます。

顧客の個人情報を入力する前に確認すること

アンケートの自由記述は、本人が名前・勤務先・連絡先・病歴などを書き込んでいることがあります。設問が求めていなくても書かれるので、渡す前に中身を見る工程が必要です。

伏せ字は、分類に必要な情報を壊さない形にします。具体的には次のように置き換えます。

「営業部」「対応が」といった分類の手がかりは残していることに注目してください。固有名詞だけを角かっこの記号に替え、文の構造と文脈語は残します。全文をまるごと削ると、何の不満だったのかが読み取れなくなります。

置き換えは件数が多いと手作業では抜けるので、表計算ソフトの置換や簡単なスクリプトで機械的に処理し、処理後のファイルを数件抜き取って確認する流れにします。伏せ字の確認は、AIに渡す前に人がやる工程として残してください。伏せ字にする作業自体をAIに任せると、見落としが起きたときに気づく機会がなくなります。

最初に試すなら、どこから手を付けるか

いきなり全件を流す必要はありません。過去のアンケートから30件だけ取り出し、自分でラベルを付けて答え合わせをする。これだけで、自分のカテゴリ定義のどこが曖昧かが見えます。定義が固まっていれば、件数が増えても同じ指示文が使えます。

手で800件を仕分ける二日と比べれば、30件の答え合わせに使う一時間は十分に元が取れます。精度を上げる作業は、プロンプトをひねることではなく、自分の判断基準を言葉にすることです。そこが済んでいれば、モデルが変わっても作り直しは要りません。

よくある質問

AIに自由記述を分類させる手順は何から始めればいいですか？

Anthropicの公式ドキュメント「Classification」は、①強いプロンプトを作る ②テストケースを用意する ③評価（eval）を実行する ④分類器を本番投入する、の4段階を示しています。最初にやるのは分類カテゴリを決めてそれぞれの定義を一文で書くことと、正解ラベルを自分で付けたテストケースを30〜50件用意することです。

同じ回答なのにAIの分類結果が変わるのはなぜですか？

分類タスクでは温度（temperature）を0にして出力の一貫性を高めるのが標準的な推奨ですが、温度0でもAPI経由のホスト型推論では完全な決定性は保証されないという指摘があります。加えて、同一入力に対する判定のゆらぎ（flipping noise）は位置バイアスや長さバイアスと並ぶ再現性低下の要因として研究されています。揺れをゼロにはできない前提で、抜き取り確認を残す設計にします。

分類カテゴリは細かく分けたほうが精度が上がりますか？

いいえ。NPS（顧客推奨度。推奨度を0〜10で聞き、理由を自由記述で書かせる調査形式）などの自由記述回答を大規模に分類する際は、カテゴリ数を絞って単純な構造にするほうが、複雑な階層構造より精度が高くなりやすいことが推奨されています。ただし「製品」「サービス」のような大まかなテーマだけで切ると、ニュアンスの異なるフィードバックが一括りにされる問題が指摘されています。カテゴリ数を増やすより、各カテゴリの定義文で境界を明示するのが先です。

AIの分類精度はどう測ればいいですか？

精度（precision）・再現率（recall）・F1スコアといった定量指標で測定すべきで、ベンダーの主張や印象論に頼るべきではないとされています。小規模なら、自分でラベルを付けたテストケース50件のうち何件が一致したかを数えるだけでも、プロンプトを直す前後の比較ができます。

※記事で使用した内容・数値は変更される場合があります。最新情報は公式サイトをご確認ください。