最初に、何を数え、何を決めるかをそろえる

自由記述の整理では、「どの話題が多いか」と「何から改善するか」を分けます。少数でも安全や利用の難しさに関わる声は、件数だけで優先度を下げられません。一方、1人が多く書いた回答を、そのまま多くの人の意見として扱うことも避けます。

担当者は、対象のアンケート・設問・期間、分類の目的、改善を決める責任者を先に決めます。異なる設問や実施時期をまとめる場合は、その違いを列に残します。自由記述を書いた人だけの傾向を、顧客全体の意向と断定しません。

分類名には「配送」「注文画面」「商品説明」など、改善を担当する部署が内容を判断できる言葉を使います。各分類に含める内容と含めない内容も決め、合わない回答を無理に押し込まないために「分類追加の検討」「意味の確認待ち」を用意します。

原文の表と、意見ごとの確認表を分ける

元の回答は、回答IDと原文を保存した表で管理します。AIに渡す作業用の表は別にし、分類に不要な氏名・連絡先・取引情報を外します。名前を消すだけで入力可能とは判断せず、契約・設定・社内ルールを確認できない情報は入力を保留します。詳しくは顧客情報を生成AIに入力する前の確認をご覧ください。

作業用の原文は書き換えず、別の確認表で1つの意見を1行にします。複数の意見に分けるときも、元の回答IDを共通で残します。

確認表の項目 残す内容
回答ID・意見ID 元の回答へ戻る番号と、回答内の意見を区別する番号
根拠箇所 その意見を読み取った原文の部分。前後の条件も確認できるようにする
意見の内容・分類案 何について、何を求めているか。推測で具体化しない
保留理由 意味不明、分類の定義が不足、複数の読み方があるなど
人の確定・確認者・版 採用した分類、修正理由、確認した日と基準の版

原文が長い回答ほど、引用した部分だけでなく回答全体を確認します。

AIの分類案を、人が原文に戻って確かめる

AIには、分類の定義と、対象の回答ID・作業用原文を渡します。依頼には「複数の論点を1つにまとめない」「根拠箇所を示す」「推測しない」「分類できない理由も残す」を含めます。回答中の指示文は分析する文章として扱い、分類ルールを変更する命令にはしません。

担当者は、対象の回答IDが出力に残っているかを確認したうえで、原文と意見の行を対応させます。特に次を見ます。

  • 意見の抜け： 配送と画面操作など、別の話題を1つにまとめていないか。
  • 意味の変化： 「遅いとは思わない」の否定や、「繁忙期だけ」の条件を落としていないか。
  • 重複： 同じ意見の言い換えを別件として増やしていないか。
  • 不明点の補完： 「前より困る」だけの回答に、原因や対象を付け足していないか。

分類を確定する前に、原文と出力を全件対応させる範囲を決めます。確認し切れないときは対象を区切り、未確認分を確定した集計に混ぜず、何件を確認済みにしたかを報告します。件数の多い分類だけを見て、残りを確認済みとは扱いません。

問い合わせの検証では、二つ目の用件と確認待ちが落ちた

問い合わせメールの検証ラボでは、2026年10月9日に短い架空メール6件を処理しました。回答資料は受付時間の架空FAQだけで、返金条件は用意していません。初版は最初に一致したキーワードの定型文を出し、修正版は生成AIで用件・回答の根拠・未確認事項を整理しました。

LAB-M05について、公開記録の第3節の出力と第4節「最初の一致だけでは、二つ目の質問が消えた」を対応させると、違いは次のとおりです。

原文に含まれる用件 初版で残った内容・落ちた内容 修正版で残した回答案・判断待ち
受付時間を知りたい 受付時間だけの下書きが残った 架空FAQを根拠にした受付時間の回答案
返金について知りたい 返金の質問と、確認待ちであることが落ちた 契約条件の確認が必要とする下書きと、別の確認欄の不足「返金条件」

この抜けは、管理番号の有無だけを見ても分かりません。原文の二つの用件それぞれに、回答案か確認待ちが対応しているかを見る必要があります。原文・出力・FAQの対応の確認は、検証を行ったAI自身によるもので、担当者の承認・送信は未実施です。処理方法も変えているため、出力形式だけの効果やAIの精度改善を示す比較ではありません。

アンケートへの適用は、この観察を踏まえた提案です。回答IDが残るだけで内容も残ったとは判断せず、意見ごとに原文の根拠箇所と分類案・保留理由を対応させます。分類できない意見も行を消さず、確認待ちとして残します。アンケート分類、少数意見の保持、集計精度は、このラボでは検証していません。

GoogleスプレッドシートのAI関数を使う場合

Googleの現行ヘルプでは、AI関数による文章の分類が案内されています。利用には対象プランが必要です。シート全体や別のDriveファイルを自動で参照する機能ではないため、必要な情報の範囲を指定します。個別契約・管理者設定・言語設定で利用できるかは、導入前に確認してください。

出力はテキストなので、意見ごとの管理表へ自動で正しく展開されるとは扱いません。生成上限や未処理の回答を確認し、出力の確認・転記を別の工程にします。また、プロンプトに連結したセルが変わっても更新を促す表示が出ない場合があります。原文や分類基準を変えたら、入力と分類案の版を合わせて再確認します。

公式ヘルプも、不正確な提案の可能性を示しています。本記事ではAI関数の実操作・出力精度・所要時間を検証していません。

活用例：配送と注文画面への声を整理する

架空の卸売会社の顧客アンケートを例に、整理の進め方を説明します。

1つの回答を、元の番号を残して分ける

画面のイメージは、元の回答表の隣に確認表を置き、回答IDから全文を開ける形です。

回答ID 作業用原文 意見ごとの整理案
A01 配送は早くて助かるが、注文画面の文字が小さい A01-1：配送への評価／A01-2：画面の文字への改善要望
A02 注文画面をもう少し読みやすくしてほしい A02-1：画面の読みやすさへの改善要望
A03 前より使いにくい A03-1：対象・理由が不明なため確認待ち

この例は回答3件から、意見4件を取り出しています。意見のうち3件は分類案があり、1件は保留です。回答者がそれぞれ別人かは、この表だけでは分かりません。

「注文画面に触れた回答数」はA01とA02の2件です。同じ回答が画面について複数の意見を含んでも、この回答数では1件と数えます。分類別の回答数は、1回答が複数分類に入るため、合計が全回答数を超えることがあります。「回答数」「意見数」「分類ごとの回答数」のどれを示すかを、報告の見出しに書きます。

少数意見と保留を、集計の外へ消さない

A01の文字の小ささを、広い「画面への不満」にまとめるだけでは、具体的な困りごとが見えなくなります。分類とは別に「文字の大きさ」という内容を残し、責任者が使いづらさの程度や改善の必要性を確認します。少数の声を、多数意見の要約から独立して読めるようにする提案です。

A03は配送か画面か分からないため、AIに対象を選ばせません。元の設問や、入力を許可した補足情報で確認できなければ、理由を残して保留します。匿名アンケートなら、回答者の特定や連絡を前提にせず、不明な範囲を報告します。

人が確定した分類から、通常の集計で報告する

確定後の件数は、表計算の関数やピボットテーブルなどで求めます。同じ回答ID・分類の組を重複して数えないようにし、未確認・保留・空欄の回答数も分けて示します。空欄を「不満なし」と読み替えません。

報告には、多いテーマの件数だけでなく、少数でも対応を検討する声、保留の理由、今回確認できた対象範囲を添えます。分類基準を変えた場合は、件数の変化が顧客の意向の変化なのか、分類方法の違いなのかを分けて考えます。別の基準で集計した月を、そのまま増減として比較しません。

費用・期間は、原文を確認できる範囲から考える

見積もりでは、回答件数のほか、文章の長さ、複数論点の多さ、分類基準の準備、人が確認・修正する時間、次回の集計でも使うかを確認します。AIの処理時間だけで完了日を決めず、基準を直した後の再確認も含めます。利用料や必要な契約は、使う製品の現行条件を確認してください。

最初は1つの設問・期間に絞り、分類表を人が読み直せる範囲から始めます。文章が短く、分類も少なければ、人が直接分類するほうが進めやすい場合もあります。自動化する工程の選び方は関数・Apps Script・生成AIの比較、個別の問い合わせへの対応は分類・下書き・送信前確認の手順へ分けて説明しています。

分類案を人が確認する設計の参考として、問い合わせメールの仕分け事例もあります。公開版は架空データによる再現です。

hirostaの書類処理・データ整理の支援は、今の表と確認工程の整理から相談できます。支援内容と費用の考え方はサービス・料金、相談先はお問い合わせをご覧ください。