自由回答の列を表計算ソフトに貼り、「主な意見をまとめて」と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、反対例、未確認事項を残し、次の検証と事業判断は人が決めます。
手順は、分析後の判断を固定し、原本を保存し、試行用回答からコード案を作り、全件へ仮コードを付け、誤分類を直し、版を固定して集計する流れです。一度の指示で「要約と示唆」まで作らせないこと。工程ごとに成果物を分けるのが肝心です。
検品では、否定の脱落、原因の補完、コードの過統合・過分割、少数意見の消失を優先します。件数の多さだけで結論を決めず、回答者条件、質問文、代表回答、反対例を合わせて読みます。導入時は少量の回答で誤分類を確かめ、自社用のコード定義と検品基準を作ってください。
根拠のない一般化を止め、追加確認へ渡せる状態になったとき、その分析は完成です。
