アンケートの自由記述を、生成AIで「いくつかのテーマに分けたい」と考えることがあります。最初に大切なのは、回答を全件投入することではありません。

最初の試行では、次の4点を先に決めます。

  1. 何のために分類するか、入力してよい範囲はどこまでか
  2. どの分類ラベルを使い、どこを「その他」「要確認」にするか
  3. AIの分類と原文のどこを、人が照合するか
  4. 分類結果をどの判断には使わず、何を記録して次へ進むか

これは法的な適法性や匿名化の十分性、AIの分類精度を保証する手順ではありません。実在の機密回答を使わず、合成コメントまたは人が入力可否を確認した低リスクな例で、小さく確かめるための業務案です。

1. AIに渡す前に、目的と入力範囲を決める

目的を一つに絞る

最初の目的は、たとえば「次回アンケートで改善候補になりそうなテーマを分ける」程度に絞ります。

「回答者ごとの満足度を判定する」「従業員や顧客の良し悪しを評価する」「人事や顧客対応の判断を自動化する」といった目的は、この記事の対象外です。目的が一つなら、入力するコメントも、AIに求める出力も小さくできます。

入力前チェック

確認すること 最初の試し方 止める条件
分類の目的 改善候補のテーマ分けなど、一つの目的にする 個人評価や自動意思決定が目的になっている
入力データ 合成コメントを優先する。実在の回答を使う場合は、入力可否を人が確認した低リスクな5〜10件に限る 氏名、連絡先、顧客識別子、従業員の個別評価、健康・要配慮情報、未公開情報が残っている
サービス条件 実際に使うサービスの現在の利用規約・プライバシーポリシーとデータ取扱いを確認する 条件が確認できない、または自社の確認者が入力可否を判断できない
利用範囲 テーマ分けと原文照合の補助に限る 個人の評価、採用・人事・健康・与信、外部共有へ直結させる

個人情報を含むプロンプトを入力する場合の必要範囲、サービス提供者のデータ取扱い、利用規約・プライバシーポリシー、出力の不正確さについては、個人情報保護委員会の注意喚起が留意点を示しています。ただし、これは2023年の注意喚起です。現在選ぶサービスの条件、個別契約、現行法令の判断を代替するものではありません。

外部サービスを使う場合、サービス側が担う対策があっても、自社側に残る運用上の確認があります。IPAの中小企業向け情報セキュリティ資料は、外部サービスを利用する運営形態で、利用者側に運用・認証情報管理などの対策が残る例を示しています。これは一般的な情報セキュリティの文脈であり、特定の生成AIサービスの安全性や入力可否を決める根拠ではありません。

匿名化済みなら、自動的に入力してよいわけではない

匿名化したつもりでも、回答文の組み合わせから誰のことか判断できるか、個別の顧客・従業員情報や社内機密が残っていないかを、この記事では保証できません。

迷ったら、次の順で止めます。

  • 実在の回答を使わず、同じ構造の合成コメントを作る
  • 人が入力範囲を確認できるまで、外部サービスへ送らない
  • 入力対象から外した理由と、確認者・確認日だけを記録する

2. 分類軸と「その他」「要確認」を先に作る

AIへ「分類して」とだけ依頼すると、何を基準に分けたのかを後から説明しにくくなります。まず人がラベルを作り、ラベルに入らない回答を受け止める場所を用意します。

3〜5個のラベルと例外ラベルを作る

この件数は公的資料が定めた標準ではなく、最初の小さな試行案です。店舗やサービスの利用後アンケートを「次に改善するテーマ」に分ける仮想例なら、次のように始められます。

ラベル 含めるコメント 含めない・保留するコメント
説明の分かりやすさ 案内、資料、説明の理解しやすさに触れるもの 待ち時間だけを述べるもの
待ち時間・手続き 受付、予約、手順、待ち時間に触れるもの 説明の理解しやすさだけを述べるもの
商品・サービス内容 内容、機能、品ぞろえなどに触れるもの 個別の担当者の評価を含むもの
その他 上のどれにも当てはまらないもの 原文にない理由を補えば入るもの
要確認 複数ラベル、意味が曖昧、機微な情報、原文照合ができないもの 人が原文を読んで一つに決められるもの

「その他」はどの分類にも当てはまらない回答、「要確認」は原文確認や人の判断が必要な回答です。無理に分類を完了させないために、役割を分けます。

ラベルごとに、次の4項目を1枚に書いておくと、AIの出力と人の判断を比べやすくなります。

項目 記録する内容
ラベル名 例：説明の分かりやすさ
含める条件 何が書かれていれば含めるか
含めない条件 似ていても別ラベルにするもの
境界例 迷ったら「要確認」にする具体例

個人の属性や「良い・悪い」を分類軸にしないことも、最初に明記します。自由記述に書かれていない年齢、性格、意図、原因などを推測してラベルを付けない、というルールです。

合成コメントでラベルを試す

以下は記事用の仮想例であり、実在の回答ではありません。

A01｜「案内の説明は短くまとまっていて、初めてでも流れが分かりました」
A02｜「受付から呼ばれるまで、思ったより時間がかかりました」
A03｜「説明資料の用語が難しく、どこを読めばよいか迷いました」
A04｜「内容はよかったですが、予約変更の手順が分かりにくかったです」
A05｜「担当の人は親切でしたが、もう少し早く対応してほしかったです」
A06｜「特にありません」

A05は「待ち時間・手続き」に寄せることもできますが、担当者への評価が含まれるため、この試行では「要確認」にしても構いません。大切なのは、AIの判断を正解として受け取ることではなく、先に決めたラベル定義と原文が合っているかを確認できることです。

3. AI出力を原文と照合し、人へ戻す条件を置く

出力欄を三つ以上にする

分類結果だけを受け取らず、最低限、次の欄を残します。

欄 目的
IDとラベル どのコメントをどのテーマに分けたかを追えるようにする
原文の根拠箇所 そのラベルの根拠が、回答文のどこにあるかを見る
確信度または要確認理由 人が先に読む対象を分けるための記録欄。AIの保証値ではない

確信度という欄を置いても、AIの出力が正しいと保証されるわけではありません。根拠箇所が空欄、原文にない理由が書かれている、複数のラベルにまたがる、といった状態を見つけるために使います。

依頼文のひな型

実際のサービスの条件を確認した後、合成または入力可否を確認済みの低リスク例で、次のように依頼します。

目的：アンケート自由記述を、次回改善候補のテーマに整理する
ラベル：説明の分かりやすさ／待ち時間・手続き／商品・サービス内容／その他／要確認

ルール：
- 原文に書かれていない属性、理由、意図、評価を推測しない
- 1件に複数のテーマがある、または意味が曖昧なら「要確認」
- どのラベルにも根拠がなければ「その他」
- 原文から根拠となる短い箇所を示す
- 判断できない理由があれば「要確認理由」に書く

出力欄：
ID｜ラベル｜原文の根拠箇所｜確信度または要確認理由

この依頼文は、本記事の編集上の提案です。公的資料がこのラベル数や出力形式を指定しているわけではありません。

人の照合チェック

AIの出力を受け取ったら、コメントごとに次を確認します。

確認質問 問題がなければ 問題があれば
ラベルは、先に決めた定義に合っているか 確認済みにする ラベルを修正するか要確認へ戻す
根拠箇所は原文に実際にあるか 根拠を記録する 保留して原文を再確認する
原文にない理由や属性を足していないか その推測を削る 要確認にして人が判断する
複数ラベル・曖昧さはないか 決めたルールで記録する 無理に一つへ決めず要確認にする
個人評価や機微な情報へつながっていないか この試行の範囲内か再確認する 入力・利用を止め、担当者へ戻す

AIセーフティ・インスティテュートの評価観点ガイドは、主にAIシステムの開発者・提供者が評価時に参照するための資料です。本記事はその個別評価項目をアンケート分類へ転用するものではありません。出力を最終判断にせず、原文と照合し、保留を人へ戻す設計は本記事の編集上の提案です。

4. 施策や個人評価へ直結させず、次の確認を記録する

分類が終わっても、その結果だけで施策や評価を決めません。まず「どの範囲を、どの定義で、誰が確認したか」を残します。

初回試行の記録テンプレート

目的：
対象期間：
入力範囲と除外した情報：
使用したサービスの確認日：
分類ラベルと定義の版：
AI出力を確認した人：
確認日：
原文との不一致・推測・要確認：
次に人が確認する事項：
この結果だけでは決めないこと：

「この結果だけでは決めないこと」には、個人の評価、採用・人事・健康・与信に関わる判断、顧客への個別対応、外部共有など、今回の試行範囲を越えるものを書きます。

次の判断は、分類結果の良し悪しを一つの数字で決めず、次のように分けます。

  • 根拠箇所があり、ラベル定義と一致し、要確認が人に戻っている：同じ低リスク条件で再試行を検討する
  • 原文にない推測やラベルの揺れがある：ラベル定義を見直し、件数を増やさず再判定する
  • 入力範囲やサービス条件が確認できない：AIへの入力を止め、条件確認へ戻る
  • 個人評価や自動意思決定につながりそう：この手順の対象外として人の判断に戻す

ここでの「再試行を検討する」は、AIの分類精度や業務効果が確認されたという意味ではありません。何が判断できず、どこを人が確認したかを記録できた、という範囲の学習です。

この手順の根拠と限界

この記事で使った根拠と、そこからの推論を分けておきます。

  • 根拠として確認できること：個人情報を含む入力の必要範囲、サービス条件の確認、外部サービスを使う場合にも利用者側の対策が残ること、AI出力を最終判断にしない評価文脈。
  • 本記事の編集上の提案：合成または低リスクな5〜10件、3〜5ラベル、「その他」「要確認」、原文の根拠箇所、人へ戻す条件、記録テンプレート。
  • この記事からは言えないこと：匿名化の法的保証、特定AIサービスの現在の保存・学習条件、分類精度、業務改善、問い合わせ、検索需要、MASTER key株式会社の認知成果。

検索仮説と公開後の観測

この記事の検索語は「生成AI アンケート 自由記述 分類」を中心とする仮説です。topic-specificな検索需要、対象URLの検索順位・クリック、直接の読者発話、分類を業務で使った結果は、現時点では観測されていません。

公開後に確認できるなら、対象URLに帰属するGSCのquery・page・position、GA4のlanding page・referrerを見ます。対象URLへ帰属するpage-level dataがなければ、記事の成功・失敗を判定せず、not_evaluableとして扱います。owned media全体の集計値を、この一記事の需要や認知成果に置き換えません。

参照元

本文の根拠として確認した公式一次資料です。資料の適用範囲と限界は本文中の説明も参照してください。