読みきれない自由記述が宝の山に。LLMで実現する「構造化」アンケート分析の設計図

「今回のNPS調査、自由記述欄に3,000件もコメントが来ているけど、誰が読むんだ？」

マーケティングやカスタマーサクセスの現場で、このような課題がよく聞かれます。四半期ごとの満足度調査、イベント後のアンケート、あるいは日々の問い合わせログ。これらは本来、顧客の「生の声」が詰まった宝の山です。しかし、現実にはその膨大な量に圧倒され、担当者が斜め読みして気になったコメントをいくつかピックアップするか、あるいは「ワードクラウド」を作成して、「なんとなく『使いにくい』という単語が大きいですね」といった報告で終わらせてしまうケースが後を絶ちません。

自由記述データの死蔵は、ビジネスにおける最大の機会損失の一つだと考えられます。

従来のテキストマイニングツールが抱えていた「文脈理解」の限界

これまでも、テキストマイニングツールは存在しました。しかし、従来のツールの多くは「形態素解析」という手法に依存していました。これは文章を単語に分解し、その出現頻度を数えるアプローチです。

例えば、「サポートの対応は早かったが、解決には至らなかった」というコメントがあったとします。従来のツールでは「早い」「解決」という単語が抽出され、ポジティブな要素としてカウントされてしまうことがありました。文脈として「解決しなかった（ネガティブ）」という重要な意味が抜け落ちてしまうのです。

また、「画面が重い」「動作が遅い」「ロードに時間がかかる」はすべて同じ「パフォーマンスの問題」を指していますが、単語ベースの集計ではこれらが別々の項目としてカウントされ、課題の真のボリュームが見えにくくなるという問題もありました。

コスト1/100、スピード100倍の衝撃：LLMによるパラダイムシフト

ここで登場したのが、ChatGPTやClaudeに代表されるLLM（Large Language Model：大規模言語モデル）です。LLMの革命的な点は、単語ではなく「意味」と「文脈」を理解できることにあります。

先ほどの例であれば、LLMは「対応速度は評価されているが、問題解決能力には不満がある」と正確に解釈します。さらに、「画面が重い」といった多様な表現も、「パフォーマンス課題」という一つのカテゴリに統合して分類することが可能です。

実際の導入事例では、これまで専門のアナリストが行っていた数千件のタグ付け作業を、LLMを活用することで大幅に短縮できたケースがあります。コストも大幅に削減可能です。しかし、ここで強調したいのは、単に「楽になった」ということではありません。人間では集中力が続かず見逃してしまうような微細な予兆を、AIは疲れを知らずに拾い上げることができるのです。

「要約」ではなく「構造化」：AIに求めるべき正しいアウトプット

多くの人がChatGPTを使ってアンケート分析をしようとする際、「このデータを要約して」と指示してしまいます。しかし、これはビジネス活用という観点からは間違いです。

要約は、文章を短くして「読みやすく」する処理です。しかし、分析に必要なのは「読み物」ではなく「集計可能なデータ」です。目指すべきは、自由記述という非構造化データを、表計算ソフトなどで集計できるような構造化データ（タグ、フラグ、スコア）に変換することです。

• 要約のアプローチ: 「全体的にUIへの不満が多く、特にログイン画面の改善要望が見られました。」（ふんわりとした定性情報）
• 構造化のアプローチ:
  • ID: 001 -> カテゴリ: UI/UX, サブカテゴリ: ログイン, センチメント: Negative, 具体的内容: ボタン配置
  • ID: 002 -> カテゴリ: 機能要望, サブカテゴリ: データ出力, センチメント: Neutral, 具体的内容: PDF対応

このように構造化されて初めて、「先月と比較してログインに関する不満が15%増加している」といった定量的な分析が可能になります。本記事では、この「構造化」を実現するための具体的な設計論と実践フローについて、論理的かつ明快に解説していきます。

---

原則1：分析精度は「事前のカテゴリ定義」で9割決まる

LLMは飛躍的に進化しており、最新の推論強化モデルなどは深い論理的思考が可能になりました。しかし、それでもAIは魔法の杖ではありません。「いい感じに分析して」と丸投げすれば、「いい感じの（しかし意思決定には使えない）当たり障りのないレポート」が返ってくるだけです。高精度な分析を行うための第一歩は、人間が仮説に基づき「分析の軸」を定義することにあります。

AIへの丸投げはNG：予備分析による仮説構築の重要性

よくある失敗例として、顧客アンケートをAIに分析させた際、「機能について」「料金について」「その他」という3つの粗い分類しか出力されず、有用な洞察が得られなかったというケースがあります。これは、AIに対して「どのような粒度で分類すべきか」というビジネス視点の指示が欠落していたために起こります。

AIはテキストの意味を理解することはできますが、「組織が今、何を知りたいか」というコンテキストまでは把握していません。新機能の受容性を検証したいのか、潜在的な解約リスク（チャーン）の予兆を探りたいのか。目的によって、設定すべき「軸」は根本的に異なります。

ボトムアップ型（AI提案）とトップダウン型（人間指定）のハイブリッド設計

現在推奨されるのは、共同編集機能や推論強化モデルを活用した、以下の3ステップによるカテゴリ定義プロセスです。いきなり全データを処理するのではなく、まずはAIと対話しながら「定義書」を作り上げることに注力します。

1. ランダムサンプリングと初期提案（ボトムアップ）
   全データからランダムに50〜100件程度を抽出します。このデータをAIに渡し、「この回答群から、ビジネス改善につながる主要なトピックカテゴリを10個提案してください」と依頼します。

2. 共同編集機能による調整（トップダウン）
   AIが提案したカテゴリリストを、人間がレビュー・修正します。
   「このカテゴリは細かすぎるから統合する」「今期はサポート品質に注力しているため、サポート関連は『速度』と『品質』に分割する」といった戦略的な調整を、AIと共同でドキュメント上で直接行います。

3. 推論モデルによる論理検証
   作成した定義書に対し、推論能力の高いモデルを使って検証を行います。「この定義書で分類に迷うようなグレーゾーンの回答例をシミュレーションしてください」と指示し、事前に定義の曖昧さを解消しておきます。

MECE（漏れなくダブりなく）を意識したタグ設計のベストプラクティス

カテゴリを設計する際は、MECE（Mutually Exclusive and Collectively Exhaustive：漏れなくダブりなく）を意識することが重要ですが、アンケート分析においては「その他（Others）」をいかに減らすかが分析の質を左右します。

AIは分類に迷うと安易に「その他」に入れたがる傾向があります。これを防ぐために、プロンプト設計において以下のような工夫が有効です。

• 「その他」の使用制限と理由記述: 「可能な限り既存のカテゴリに分類してください。『その他』を選択せざるを得ない場合は、その判断理由を具体的に記述してください」と指示します。
• 複合カテゴリの許容: 一つの回答に複数のトピックが含まれる場合（例：「機能は良いが高い」）、無理に一つに絞らせるのではなく、マルチタグ（[機能:Positive], [価格:Negative]）を許容する設計にします。
• モデルの使い分け: 定義作成には推論能力の高いモデルを使用し、大量データの分類処理には高速でコスト効率の良いモデルを使用するという「適材適所」のアプローチも、コストと精度のバランスを取る上で重要です。

この「定義」のプロセスこそが、人間が最も知恵を絞るべき部分です。ここさえ論理的に構築できれば、あとの大量処理はAIが驚くべき精度と速度で実行してくれます。

原則2：「感情」と「事実」を分離して抽出するプロンプト設計

アンケート分析において、顧客の「感情」と、その原因となった「事実」を混同することは避けるべきです。「怒っている」ことは分かっても、「なぜ怒っているか」が構造化されていなければ、具体的な改善アクションには繋がりません。

ポジティブ/ネガティブ判定だけでは見えない「改善の種」

従来の単純なセンチメント分析では、テキスト全体を「Positive」「Negative」「Neutral」のいずれかに分類していました。しかし、ビジネスの現場における分析では、これだけでは不十分なケースが多々あります。

例えば、「機能は豊富で素晴らしいが、マニュアルがわかりにくくて使いこなせない」というコメントがあったとします。これを全体として「Neutral（中立）」と判定してしまっては、貴重な顧客の声が埋もれてしまいます。ここでは、「機能＝Positive」「マニュアル＝Negative」という、対象ごとの評価（Aspect-Based Sentiment Analysis）が必要です。

最新のLLMは、文脈理解と推論能力が大幅に強化されており、こうした複雑な文章構造も正確に分解できるようになっています。

「事象（Fact）」と「感想（Emotion）」を分けて出力させるテクニック

プロンプトを設計する際、以下の3つの要素を明確に分離して抽出するように指示することが重要です。

1. Topic（話題）: 何について話しているか（例：ログイン画面、料金プラン）
2. Sentiment（感情）: その話題に対してどう感じているか（Positive/Negative/Neutral）
3. Key Phrase（根拠）: その判断の根拠となる具体的な記述（事実）

以下は、実務で効果的なプロンプトのテンプレートです。

# 指示
以下のアンケート回答を分析し、指定されたJSON形式で出力してください。

# 分析ステップ（思考プロセス）
1. 回答に含まれる「具体的な事実（何が起きたか）」と「感情（どう感じたか）」を分離して特定する。
2. 複数のトピックが含まれる場合は、トピックごとに分割する。
3. 各トピックについて、Sentimentを {Positive, Negative, Neutral} のいずれかで判定する。

# 出力フォーマット（JSON）
[
  {
    "topic_category": "カテゴリ名（定義書から選択）",
    "sentiment": "Positive/Negative/Neutral",
    "summary": "事象の要約（15文字以内）",
    "original_quote": "回答からの抜粋"
  }
]

このようにJSON形式で出力させることで、表計算ソフトやBIツールへの取り込みが容易になります。また、対話型プレビュー機能を活用すれば、抽出結果の構造をその場で確認・修正しながら進めることができ、分析作業の効率が飛躍的に向上します。

具体的な要望（Feature Request）を漏らさず拾うための指示

さらに、単なる感想だけでなく、「具体的な要望」が含まれている場合、それを別途フラグ立てして抽出する手法も有効です。

プロンプトに「もし回答の中に『〜してほしい』『〜があれば良いのに』といった機能要望や改善提案が含まれる場合は、is_requestフラグをtrueにし、request_contentにその内容を抽出してください」という指示を追加します。

これにより、カスタマーサクセス（CS）チームは「is_requestがtrue」のデータだけをフィルタリングすることで、顧客からの要望リストを即座に作成できます。これをプロダクト開発チームへ共有するフローを構築すれば、アンケート分析が直接的なVOC（Voice of Customer）活動へと昇華されます。

原則3：ハルシネーションを防ぎ信頼性を担保する検証フロー

ビジネスでAIを活用する際、避けて通れないのが「ハルシネーション（もっともらしい嘘）」のリスクです。特にLLMは、文章を滑らかにするために、元のデータにはない情報を勝手に付け加えてしまうことがあります。アンケート分析において、顧客が言っていないことを「言った」と報告することは致命的です。

AIは平気で嘘をつく：参照元IDの紐付けによるトレーサビリティ確保

ハルシネーション対策の基本は、「トレーサビリティ（追跡可能性）」の確保です。

AIに分析させる際は、必ず元のアンケート回答に「ID」を振り、出力結果にもそのIDを付記させます。これにより、抽出されたインサイトが「どの回答に基づいているのか」をいつでも原文に戻って確認できるようになります。

表計算ソフトの関数を使って、AIの出力結果の横に原文を表示させるシートを作成することが推奨されます。こうすることで、分析結果と原文を並べて見ることができ、違和感があればすぐに確認できます。

人間による抜き打ちチェック（Human-in-the-loop）の組み込み方

AIの精度を100%にするのは不可能ですし、その努力はコスト対効果が見合いません。実務的には、「信頼区間」を設定した抜き打ちチェックが有効です。

運用開始直後は、AIが処理したデータの20〜30%を人間が目視チェックします。ここでAIの分類ミスや解釈違いを見つけたら、そのパターンをプロンプトの「具体例（Few-shot）」として追加し、修正します。

精度が安定してきたら、チェック率を5〜10%に下げます。ただし、ゼロにはしません。常に人間が監視プロセスに入っている（Human-in-the-loop）状態を保つことが、AIシステムの品質維持には不可欠です。

確信度（Confidence Score）を活用したリスク管理

高度なテクニックとして、LLMに自分自身の回答に対する「自信の度合い」をスコアリングさせる方法があります。

プロンプトに「分類の自信度を1〜5の5段階で評価し、confidence_scoreとして出力してください。判断に迷う場合はスコアを下げてください」と指示します。

分析時は、このスコアが「4」以上のものは自動処理し、「3」以下のものだけを人間が重点的にチェックするという運用フローを組みます。これにより、人間の工数を最小限に抑えつつ、リスクの高い「微妙な回答」だけを丁寧に拾い上げることが可能になります。

---

原則4：定性×定量のクロス分析で「経営に響く」レポートを作る

ここまでで、自由記述データはLLMによって「構造化されたデータ（タグやスコア）」に変換されました。しかし、構造化はあくまで手段であり、ゴールではありません。ここからが、データに命を吹き込む分析フェーズのスタートです。

実証データに基づいた観点から言えば、単に「お客様の声」を羅列しただけのレポートは経営層には響きません。構造化された定性データを、CRM（顧客関係管理）や売上データなどの「定量データ」と組み合わせることで初めて、事業戦略に直結するインサイトが導き出せます。

抽出したタグを顧客属性（プラン、利用期間）と掛け合わせる

アンケート回答には、通常「回答者ID」などが紐付いています。これをキーにして、CRMにある顧客属性データと結合することで、解像度の高い分析が可能になります。BIツールを活用すれば、以下のようなクロス集計が容易に行えます。

• プラン別分析:
  • 上位プラン顧客: 「セキュリティ」「ガバナンス」に関するタグが多く、機能要望も高度な管理機能を求めている傾向が見える。
  • 標準プラン顧客: 「価格」「コストパフォーマンス」への言及が多く、基本的な使い勝手に関する要望が中心である。
• 利用期間別分析:
  • 導入初期（1ヶ月以内）: 「初期設定の難しさ」「ドキュメントの分かりにくさ」につまずいている。
  • 定着期（1年以上）: 「レポート機能のカスタマイズ性」や「API連携」など、より深い活用段階での不満を持っている。

こうした分析は、単なるテキスト要約では見えてきません。LLMを用いて自由記述を「タグ」という構造化データに変換したからこそ、定量的な比較・検証が可能になるのです。

「ロイヤル顧客の不満」と「離脱予備軍の要望」の可視化

経営インパクトを最大化するためには、NPS（ネットプロモータースコア）やLTV（顧客生涯価値）との掛け合わせが極めて有効です。以下の2つのセグメントに注目することが推奨されます。

1. 推奨者（NPS 9-10）のネガティブコメント:
   ロイヤル顧客が発する不満は、単なるクレームではなく「愛ある苦言」です。彼らはプロダクトに期待しているからこそ、改善点を指摘してくれます。ここには、プロダクトをさらに進化させるための核心的なヒントが隠されています。

2. 離脱予備軍（解約リスク高）のキーワード:
   解約率が高いセグメントや、NPS批判者（0-6）が頻繁に使用するキーワードを分析します。「他社比較」「割高感」「サポートの遅さ」といった単語が特定のプランや業種で頻出している場合、それはチャーン（解約）の予兆です。具体的な対策を打つための根拠となります。

時系列変化を追う：施策前後の定性コメント変容分析

特定の施策（新機能リリース、UI改修、価格改定）を行った前後で、コメントの傾向がどう変化したかを定点観測します。

例えば、UIリニューアル後に「使いやすい」というポジティブタグが増加した一方で、「文字が小さい」「コントラストが低い」といった具体的なネガティブタグが急増するケースがあります。これはNPSの総合スコアだけを見ていては気づけない変化です。

LLMによる構造化データを用いれば、こうした「施策の副作用」を早期に検知し、迅速な修正サイクル（PDCA）を回すことが可能になります。定性データの時系列モニタリングこそが、アジャイルなプロダクト改善の鍵となります。

実践ケーススタディ：月間5,000件の問い合わせ分析を自動化した事例

最後に、理論がどのように現場で実践され、成果を生んだのか、月間5,000件の問い合わせ分析を自動化した導入事例を見ていきましょう。

導入前の課題：属人化した分類と形骸化したレポート

この事例では、月間約5,000件の問い合わせやアンケート回答が寄せられていました。これまでは担当者が業務の合間を縫って手動分類を行っていました。しかし、時間が足りずに分類は粗くなり、「その他」が40%を占める状態でした。結果としてレポートは形骸化し、開発チームや経営層からは「もっと具体的な改善点が知りたい」と不満が出ていました。

実践したプロンプトと運用フローの全貌

以下のフローでLLMを導入しました。

1. カテゴリ再設計: 過去のデータ200件を分析し、「機能バグ」「UI改善」「課金周り」「要望」など2階層・計25個のカテゴリを定義。
2. プロンプト開発: 「事実」と「感情」を分離し、機能要望フラグを立てるプロンプトを作成。
3. 自動化フロー: 毎週末にデータをバッチ処理し、表計算ソフトに構造化データを出力。BIツールに連携してダッシュボード化。

特に工夫したのは、「緊急度判定」です。プロンプトに「解約を示唆する文言（例：『他社への乗り換えを検討』）がある場合は、emergencyフラグを立てよ」という指示を追加しました。

得られた成果：分析工数80%減とプロダクト改善サイクルの高速化

導入から3ヶ月で、以下の成果が出ました。

• 工数削減: 分類作業にかかっていた時間が月間20時間から4時間に短縮（80%減）。残った時間は、AIが「判断に迷った」データの確認と、インサイトの深掘りに充てられるようになりました。
• 解約阻止: 「emergencyフラグ」の検知により、解約リスクのある顧客へ即座にフォローを入れる体制が構築でき、月間で数件の解約阻止に成功しました。
• 開発への貢献: 「機能要望リスト」が自動生成されるようになり、開発チームとの定例会議での議論が活発化。「この機能要望は今月だけで50件も来ているのか、優先度を上げよう」といったデータドリブンな意思決定が定着しました。

---

まとめ：データという「原石」を磨くのは人間の役割

LLMの登場により、これまで捨て置かれていた膨大なテキストデータは、活用可能な資産へと変わりました。しかし、AIはあくまで「高速に処理するエンジン」であり、どこに向かって走るかを決める「ハンドル」を握るのは人間です。

1. 目的を持ってカテゴリを定義する
2. 事実と感情を分けて抽出する
3. 人間が品質を担保する
4. 定量データと掛け合わせて意味を見出す

この4つの原則を守れば、プログラミングの深い知識がなくても、LLMと表計算ソフトだけで高度な分析基盤を構築することは十分に可能です。

もし、「自社でも同じような課題があるが、どこから手を付ければいいかわからない」という場合は、専門家に相談するか、公開されている業界ごとの分析カテゴリ設計例や運用フローを参考にすることをおすすめします。

まずは手元のアンケートデータ100件を使って、AIとの対話を始めてみてください。そこには、まだ見ぬ顧客の本音が眠っているはずです。