AIアンケート分析の実務|自由回答を分類・集計する手順

この記事は、ネクストイノベーションベース編集部の鳥居 誉定が書きました。

自由回答の列を表計算ソフトに貼り、「主な意見をまとめて」とAIに頼みます。返ってきた3行の要約は、そのまま報告書に貼れそうな出来です。けれど、その要約はどの回答を見て書かれたのでしょうか。たった一人だけが書いた「導入を止める理由」は、そこに残っているでしょうか。

AIアンケート分析とは、自由回答の原文を残したうえで、分類コードの作成、回答へのコード付与、集計候補の作成をAIに補助させる実務です。要約を作らせることではありません。回答ID、原文、コード、判断理由を分けて持ち、人がいつでも原文へ戻れる状態を先に用意します。

この記事では、回答を回収したあとのアフターコーディング、つまり分類・集計・示唆化について、原文へ戻れる7段階の進め方を示します。

ここで紹介する手順は、各社の回答データと判断基準で検証するための設計案です。

AIアンケート分析で扱う範囲を決める

AIへ任せる範囲は、自由回答の整形、コード候補の作成、仮コードの付与、類似回答の抽出、集計表の初稿までです。人が決めるのは、回答者が何を意味したのか、少数意見を事業判断へ残すか、仮説を維持するかです。

選択式の回答なら、設定した選択肢ごとにそのまま集計できます。自由回答はそうはいきません。同じ不満を、ある人は「承認が遅い」、別の人は「上長待ち」、また別の人は「決裁者が不在」と書きます。そのため、回答を集めた後に分類軸を作り、各回答へコードを付けます。これがアフターコーディングです。

単語を数える作業ではありません。「遅い」が画面表示なのか、社内承認なのか、それとも配送なのでしょうか。文脈がなければ決められません。質問文、回答原文、回答者条件を一組にして読ませます。

AIへ渡す作業と人が残す判断

分析物

AIへ依頼できる作業

人が確認・決定すること

回答原文

表記の統一候補、空欄や重複の検出

原文を変更してよい範囲、除外理由

コードブック

コード名、定義、類似コードの候補

分類軸、統合・分割、採用する定義

コード済み回答

主コード・副コードの仮付与

誤分類、複数解釈、判断保留

集計表

コード別件数、属性別の並べ替え

分母、欠損、比較可能性、読み方

示唆メモ

共通点、反対例、追加質問の候補

仮説の採否、次の検証、投資判断

要約から結論までを一度に出させると、コード定義、回答の読み違い、集計後の解釈のどこで誤ったのかが見えなくなります。工程ごとに出力を分けてください。

自由回答をAIへ渡す前に整える

入力データは、回答ID、質問ID、回答者属性、自由回答原文、除外フラグを別の列で持ちます。原本は読み取り専用で保存し、修正した文字列で原文を上書きしません。氏名や連絡先など分析に不要な情報は、入力データから外します。

その前に、分析後の意思決定を一文で書いてください。「顧客の声を把握する」では広すぎます。「申請業務の試作を次の検証へ進めるか判断する」「離脱理由を設問別に分類し、追加インタビューの対象条件を決める」。ここまで絞ると、残すべきコードが変わってきます。

回答データは、最低限この列で整えます。

列

入れる内容

役割

回答ID

R0001など重複しない識別子

集計結果から原文へ戻る

質問ID

Q01、Q02など

異なる質問への回答を混ぜない

回答者属性

業種、役割、利用経験など必要項目だけ

属性差を確認する

自由回答原文

回答者が入力した文字列

解釈の根拠を保持する

正規化文

明らかな表記揺れを整えた分析用コピー

原文を残したまま処理しやすくする

除外フラグ

空欄、意味不明、対象外など

除外件数と理由を残す

確認メモ

判断保留、要再読など

人手レビューへ渡す

「特になし」「ない」「該当しない」は、同じ意味とは限りません。区別できない回答を空欄と一緒に捨てないでください。除外するときも、原文と理由は残します。

自由回答のなかに個人名や顧客名が書かれていることもあります。組織の情報管理ルールに沿って削除するか、識別子へ置き換えてください。AIへ入力できる範囲は、利用するサービスの公式情報、契約条件、自社の社内基準を担当者が確認します。確認できないデータは投入しません。

AIでアフターコーディングを進める7段階

進め方は、判断の固定、原本保全、試行用回答の選定、コード案作成、全件への仮付与、人手レビュー、集計確定の7段階です。いきなり全件を要約させてはいけません。少量で分類規則を直してから、対象を広げます。

1. 分析後に決めることを固定する

誰が、どの会議で、何を決めるのかを書きます。仮説の維持、修正、保留、追加確認の条件を置き、判断と関係のない分類は増やしません。

2. 回答原本を保全する

回収データは原本として保存し、正規化、匿名化、除外は分析用コピーで行います。作業日と担当者も残しておきます。

3. 試行用の回答を選ぶ

短文、長文、複数論点、否定、質問とずれた回答。この5種類を試行用に混ぜます。冒頭の回答だけでコードを作ると、後半で必ず破綻します。

4. コード案と定義を作る

AIには、コード名、定義、適用条件、除外条件、代表回答ID、紛らわしいコードまで出させます。「不満」のような広いラベルは避け、回答から確認できる状況へ寄せてください。

5. 全回答へ仮コードを付ける

各回答に、主コード、副コード、根拠原文、判断保留の理由を付けさせます。既存の分類へ無理に押し込ませないこと。「該当なし」「新規コード候補」を許可します。

6. 人が境界事例をレビューする

コードが競合した回答、新規コード候補、否定、短文、属性で意味が変わる回答。ここから優先して読みます。同じ誤りが続くなら、個別に直さずコード定義を直して再処理します。

7. コードを固定して集計する

レビュー後のコードブックに版番号を付けます。主コードと副コードを混ぜないこと。回答件数とコード出現数のどちらを数えたかを注記し、コード済みデータと集計表は分けて保存します。

AIを使わない定性分析でも、原文、コード、解釈、判断は分けます。AIで速くするのは仮コードの作成までです。判断の根拠まで自動化してはいけません。

コードブックを作り、分類の揺れを抑える

コードブックは、自由回答へ付ける分類名、定義、適用条件、除外条件、具体例、更新履歴をまとめた表です。同じ言葉を担当者とAIが別の意味で使うのを防ぎ、なぜそのコードを付けたのかを後から再現できるようにします。

コード名だけの一覧では足りません。「時間がかかる」で一括すると、画面表示の待ち時間と社内承認の待ち時間が同じ箱に入ります。「画面処理の遅延」「承認待ち時間」に分け、適用条件と除外条件を書いてください。

項目

記入例

確認すること

コードID

C-014

名称変更後も識別できるか

コード名

承認者不在

短く、観察できる状況か

定義

承認権限を持つ人が不在で処理が止まる

原因を推測していないか

含める条件

不在、休暇、出張により承認待ちが発生

回答原文で確認できるか

含めない条件

承認者はいるが確認項目が多い

隣接コードとの境界が明確か

代表回答ID

R0042

原文へ戻れるか

更新履歴

v1.2で「権限不足」から分割

変更理由が残っているか

仮説から先に置いたコードは「仮説由来」、回答を読んで追加したコードは「回答由来」と記録します。一つの回答に複数の論点があれば、主コードと副コードを許します。統合や分割をしたときは版番号と変更理由を残し、どの版で集計したのかを報告書に書いてください。

アンケート分析に使うAIプロンプト例

プロンプトには、分析目的、入力列、コードブック、禁止事項、出力列、判断保留の条件を明記します。コード案の作成、コード付与、レビューを別の指示に分ければ、どの工程で意味が変わったのかを追えます。

コードブック案を作るプロンプト

あなたはアンケート自由回答の分類補助者です。
分析後に決めることは「[意思決定]」です。
質問文は「[質問文]」です。

入力された回答原文だけを根拠に、コードブック案を作成してください。
各コードに、コードID、コード名、定義、含める条件、含めない条件、
代表回答ID、紛らわしいコードを付けてください。

禁止事項:
- 回答にない原因、感情、要望を補わない
- 少数回答を削除しない
- 似た単語だけを理由に同じコードへまとめない
- 判断できない回答は「判断保留」とする

出力後に、統合候補、分割候補、新規確認が必要な回答IDを列挙してください。

[回答データ]

確定コードを各回答へ付けるプロンプト

以下の確定コードブックだけを使い、自由回答へコードを付けてください。
出力列は、回答ID、主コードID、副コードID、根拠原文、判断保留理由です。

必須ルール:
- 根拠原文は入力文から抜き出し、書き換えない
- 該当コードがなければ「該当なし」とする
- 新しい論点は「新規コード候補」とし、既存コードへ無理に入れない
- 否定、条件、比較対象を落とさない
- 回答者属性だけから意図を推測しない

[確定コードブック]
[回答データ]

プロンプトを長くすること自体が目的ではありません。満たすべきは、回答IDへ戻れること、原文にない説明を止められること、判断不能を保留できることの三点です。そこへ届くまで、少量のデータで指示と出力列を直します。

AI分析の誤りを人が検品する

全回答を同じ濃さで読む必要はありません。優先するのは、否定、複数論点、コード競合、新規コード候補、属性からの推測、短文回答です。見るべきはAIの文章が自然かどうかではなく、原文とコード定義が一致しているかどうかです。

誤り

出力に表れる症状

人が確認する箇所

原文の改変

回答にない語が根拠欄へ入る

回答IDから原文と完全照合する

否定の脱落

「困っていない」が「困っている」に分類される

否定語、条件語、比較表現を読む

原因の補完

「遅い」から原因をシステム性能と決める

回答者が原因まで述べたか確認する

コードの過統合

異なる待ち時間が一つにまとまる

含める条件と除外条件を見直す

コードの過分割

言い換えごとに別コードが増える

行動や状況が同じか確認する

少数意見の消失

多い意見だけで要約が閉じる

件数の少ないコードと未分類を読む

属性からの推測

役職だけで決裁権があると扱う

回答原文に権限の記述があるか確認する

人がコードを確定した回答は、検品用に手元へ残しておきます。指示やコードブックを変えたとき、同じ回答で再確認するためです。否定の誤認、コード漏れ、過統合。誤りの種類を分けて記録すると、直すべき箇所が特定できます。

件数が少なくても、導入や継続利用を止める条件が具体的に書かれているなら、それは次の確認対象です。少数意見を消さず、「例外・停止条件」として残してください。AI出力、人手修正版、集計確定版も、上書きせずに別々に保存します。

集計結果を新規事業の判断へつなげる

完成形は、頻出語ランキングではありません。仮説、根拠回答ID、反対例、未確認事項、次の検証が一枚で読める意思決定メモです。コード件数を市場全体の割合へ広げず、今回の回答者条件と質問文の範囲で解釈します。

集計表には、コード別件数だけでなく、回答者条件、質問ID、有効回答の扱い、複数コードの数え方、コードブックの版を書きます。主コードと副コードが付く設計なら、合計件数は回答者数と一致しません。その違いを注記しないと、会議の途中で数字の意味が変わってしまいます。

意思決定メモの項目

項目

書く内容

避ける表現

今回の問い

分析後に決める事項

顧客理解を深める

確認できた回答傾向

コード、件数、回答者条件

顧客は皆そう考える

根拠

代表回答IDと原文

AI要約だけの引用

反対例・例外

仮説に合わない回答

少数なので無視

未確認事項

設問では聞けなかったこと

回答がないため問題なし

暫定判断

維持、修正、保留、追加確認

AIが推奨したので採用

次の検証

誰に何をどう確かめるか

追加調査を行う

自由回答は、選択肢では想定していなかった論点を見つける入口になります。ただし、文章に現れた論点が、発生頻度や支払意思まで示すわけではありません。業務上の場面、現在の代替手段、発生条件を追加インタビューで確認し、必要なら行動記録や試作の利用へつなぎます。

たとえば「承認が遅い」というコードが多く出たとします。それでも、直すべき対象が承認画面なのか、権限規程なのか、担当者の不在なのかは、まだ決まりません。代表回答を読み、原因候補を分け、次の質問を設計します。AIの集計は終点ではなく、次に何を確かめるかを絞るための中間成果物です。

まとめ|AIの出力から回答原文へ戻れる状態を作る

AIアンケート分析では、回答原文を保全し、コードブックを人が確定し、AIの仮分類を境界事例から検品します。集計結果には回答ID、反対例、未確認事項を残し、次の検証と事業判断は人が決めます。

手順は、分析後の判断を固定し、原本を保存し、試行用回答からコード案を作り、全件へ仮コードを付け、誤分類を直し、版を固定して集計する流れです。一度の指示で「要約と示唆」まで作らせないこと。工程ごとに成果物を分けるのが肝心です。

検品では、否定の脱落、原因の補完、コードの過統合・過分割、少数意見の消失を優先します。件数の多さだけで結論を決めず、回答者条件、質問文、代表回答、反対例を合わせて読みます。導入時は少量の回答で誤分類を確かめ、自社用のコード定義と検品基準を作ってください。

根拠のない一般化を止め、追加確認へ渡せる状態になったとき、その分析は完成です。

無料相談を申し込む