AIでアンケート自由記述を分類する方法｜カテゴリと傾向を整理

アンケートの自由記述をAIで分類するなら、先に「何を知るための分類か」を決め、回答の一部でコードブックを試してから全件へ広げます。肯定・否定の二択だけでは、価格への不満と機能要望が同じ扱いになり、次の改善が選べません。1回答に複数の話題があれば複数ラベルを許し、判断しにくい回答は「不明」に残します。属性や意図を回答文から推測せず、集計前に人が分類のずれを点検します。

集計前に決めるReader Job

最初に結果を使う人と意思決定を一つにします。たとえば「次四半期に改善する問い合わせ体験を選ぶ」「解約理由の多い箇所を調べる」「新機能候補の要望を分ける」では、必要な分類軸が異なります。目的が曖昧なまま分類を始めると、テーマを細かく付けても会議で使える結論になりません。

回答に質問文、調査期間、回答者が任意で記入した属性を結び付けます。質問の表現によって「料金が高い」の意味が変わることがあるためです。QualtricsのText iQ資料では、全体SentimentとTopic Sentimentを区別し、ひとつの回答に複数Topicの感情を付与できる例が示されています。これは同じ回答が一つの感情に収まらない場合の設計例であり、すべての分類サービスに同じ機能があるという意味ではありません。

Codebookを小さく設計する

表は横にスクロールできます

項目	定義すること	例
Topic	回答をどの改善領域へ結び付けるか	料金、操作、サポート
Sentiment	Topicごとの評価。判断できなければUnknown	操作は肯定、料金は否定
Evidence	labelを選んだ語句や文	「請求画面が見つからない」
Uncertainty	皮肉、文脈不足、複数解釈など	文脈がなく判定保留
Other	codebookにない話題	新規Topic候補
No answer	無回答・意味を読めない回答	空欄、判別不能

「操作」と「使い方」のような重複カテゴリは、違いを一文で説明できるか確認します。含む例だけでなく、隣のカテゴリへ入れる例も書くと境界が明確になります。自由記述は複数topicを含むため、単一分類を必須にする場合は、主題を一つ選ぶ規則と、補助topicを捨てる理由を明示してください。Sentimentは回答全体と話題別を分け、否定語があるかだけで判定しない設計が必要です。

具体例で境界を確かめる

回答：「機能は便利ですが、解約の手順が見つからず、料金も分かりにくかったです。」

Topicを単一にするなら、調査目的に沿って主な困りごとを選び、他の話題は捨てるか「副topic」へ保存します。multi-labelなら「機能 / positive」「解約 / negative」「料金 / negative」のように分け、各labelに根拠語句を残します。回答全体を単純にnegativeと集計すると、満足されている機能が見えなくなる一方、全体positiveだと解約・料金の問題が埋もれます。

別の例：「まあ、使えなくはないです。」は単語だけでpositiveに決められません。質問文や前後の回答が無く、意図が曖昧ならUnknownにします。Unknownは失敗ラベルではなく、誤った確定を防ぐための値です。AIに根拠語句と不確実性を同時に返させ、根拠のない属性や回答者の心理を補わないよう指示します。

sampleを使って定義を直す

1. 回答ID、質問文、回答文、必要な調査属性を一行に置き、直接識別情報を除いたsampleを作る。

2. 初期sampleを人が読み、目的に関係するtopic候補を作る。

3. 各topicの定義、含む例、除外例、複数labelの扱いをcodebookへ記録する。

4. 別のsampleに同じcodebookを適用し、複数人なら同じ回答の一部を独立して分類する。

5. 意見が分かれる例を集め、定義を修正してから同じsampleを再確認する。

6. 未知の回答が多い場合は、無理に既存カテゴリへ押し込まず、Other / Unknownの内訳を検討する。

7. 分類定義を固定した後で全件へ適用し、件数と割合の分母を明記する。

表は横にスクロールできます

Response ID	Question	Text	Topic	Topic別sentiment	根拠語句	Confidence / Uncertain
R-01	改善点	手続きが分かりにくい	操作	negative	分かりにくい	low/medium/highではなく定義
R-02	良かった点	問い合わせの返信が早い	サポート	positive	返信が早い	根拠明確
R-03	利用理由	価格も機能も比較中	料金、機能	Unknown	比較中	文脈不足

表の値は入力形式の例です。実際のデータを見て分類した結果ではありません。AIへの依頼には、codebookの定義、複数label、Unknown条件、出力schema、禁止事項をまとめます。JSONや表形式を指定しても、件数・列ずれ・存在しないlabelが混ざる可能性はあるため、後段で検証します。モデル名だけで品質を保証せず、同じsampleとルールで比較してください。

集計と読み違いを防ぐ

各Topicの回答数だけでなく、全回答数、分類対象数、無回答、複数topic回答数、Other / Unknown数を出します。multi-labelではTopic件数の合計が回答数を超えることがあります。Topicの割合を出すときは、回答者ベースなのかlabel件数ベースなのかを明記します。属性別比較では、母数の小さい群を過大解釈せず、収集方法・質問・期間が同じか確認します。

Sentiment比率は「顧客満足度」そのものではありません。自由記述を書く人は全回答者の一部で、質問文や回答意欲にも左右されます。コメントの言葉遣いから回答者の年齢、性別、役職、購入意図を推定しないでください。少数の強い意見を全体傾向へ一般化せず、代表例を匿名化して示す場合も再識別リスクを確認します。

属性別に見るときは分母を三つに分ける

部署や利用年数で結果を分けるなら、属性は回答者が提供した列や承認済みの調査データから取得します。コメントの書き方から役職や年齢を推定して埋めません。属性が不明な回答は独立した区分にし、全体へ戻したときの件数を確認します。

次は架空の調査例です。「全回答者」は当該属性のアンケート回答者、「自由記述あり」は今回の分類対象回答者、「料金Topic」は料金の話題を含む回答者の重複なし件数です。

表は横にスクロールできます

属性	全回答者	自由記述あり	料金Topicの回答者	自由記述ありを分母	全回答者を分母
A群	20	10	6	60%	30%
B群	20	5	4	80%	20%

B群は自由記述内での料金Topic比率が高くても、全回答者に対する記述の比率はA群より低くなります。どちらも「不満を持つ人の割合」や「従業員全体の意見」を直接示す値ではありません。自由記述の有無にも差があるため、分母を省いて「B群の料金不満が多い」と断定しないでください。

QualtricsのCrosstabsでも、回答者数、欠測、回答のある対象に基づく割合などを分けて説明しています。これは集計条件の確認に使う例で、上の自作表がQualtricsの画面と同じ計算設定だという意味ではありません。Qualtrics：Crosstabs（新しいタブで開く）

複数Topicと少数群を報告前に点検する

一回答に料金と操作の両方があっても、料金Topic内では同じ回答IDを二度数えません。属性別のTopic数を足すときも、属性が一人一区分なのか、複数属性の組合せなのかを決めます。ラベル件数を回答者数として扱わず、集計表に単位を残します。

少数群をどこまで表示するかは、分析前に組織の共有基準と調査時の約束に沿って決めます。特定の人数なら必ず安全という固定基準をここでは設けません。群名、原文引用、他の属性との組合せから個人が分からないかを確認し、必要に応じて群をまとめるか、その群の値と原文を表示しない方法を選びます。非表示にした人数が他の合計から逆算できないかも確認してください。

報告では「対象期間・質問文・codebook版・属性の取得元・分母・自由記述未回答・Unknown/Other・非表示条件」を表に添えます。群の比率差だけで原因や個人評価を決めず、追加確認したい問いとしてまとめます。この例は説明用で、実際の従業員データを分類・集計した結果ではありません。

プライバシーと運用

氏名、メールアドレス、注文番号、健康・雇用などの機微情報を含む回答を外部サービスへ渡す前に、契約、管理者設定、利用目的、保存・削除条件を確認します。不要な識別情報は分析用データから外し、共有権限を絞ります。データの利用条件はサービス、契約、workspace設定で変わり得るため、資料の更新日と自組織の契約を確認してください。個人情報を含む原文を、承認されていない無料アカウントへ貼り付ける運用は避けます。

AIに分類を依頼する

目的：[分類結果を使う意思決定]

Codebook：[各topicの定義・含む例・除外例]

入力：[Response ID、質問、回答]

出力：Response ID / Topic（複数可）/ Topic別sentiment /

      根拠語句 / Unknown理由

回答にない属性や意図を推測しない。

定義に合わない回答はOther、曖昧なものはUnknownにする。

入力IDを保持し、根拠にない説明を追加しない。

出力後は、IDの欠落・重複、未定義Topic、空の根拠、原文にない語句、Topicごとのsentimentが妥当かを検証します。最後に人がsampleを読み、Codebookと実際の分類がずれていないか確認します。

AIものさしの判断

カテゴリ設計とsample reviewが済み、Other / Unknownの扱いも決まったら全件へ進みます。結果は改善候補を探す地図として使い、回答数だけで優先度を決めず、業務データや追加調査と組み合わせます。分類根拠を説明できないものは修正または保留し、判断に使う前に元回答へ戻れるIDを残してください。

分類品質を測る

正解データがない状態で「精度が高い」とは判断できません。担当者がcodebookに沿って独立に確認した回答を基準集合にし、AI分類と比較します。すべての回答へ人手でラベルを付ける必要があるとは限りませんが、どの範囲をレビューしたか、合意しなかった回答をどう扱ったかを記録します。Topicごとの誤分類、見逃し、Other / Unknownの比率を確認し、特定の言い回しや短文だけに偏っていないかを見ます。

分類品質が低いときは、Promptを強くする前にcodebookを見直します。「対応が悪い」がサポートか製品操作か判別しにくいなら、境界例を追加するか、質問文との組合せを使うか決めます。定義を変えた後は以前の集計と混在させず、codebook バージョンと再分類対象を記録してください。

結果を報告する表

表は横にスクロールできます

Topic	回答数	対象回答数	割合の分母	代表的な根拠	Unknown / Other
料金				匿名化した表現
操作				匿名化した表現

割合が回答数を分母とするか、複数labelを含む総label数を分母とするかで数値は変わります。報告書には、期間、質問、重複labelの扱い、無回答除外条件を書きます。代表例は母集団の典型と決めつけず、「分類例」として提示します。感情分類の結果だけで従業員や顧客の態度を評価せず、個別判断には原文・状況・担当者の確認を組み合わせます。

見直しのタイミング

新しい質問、対象顧客、商品、利用目的を加えたときは、既存の分類がそのまま使えるかsampleで確かめます。カテゴリ追加のたびに過去データも再分類するか、時点を分けるかは分析目的で決めます。時系列を比べるなら、変更前後で質問文とcodebookが同じか、差分があるか明示します。