顧客インタビューをAIで分析するときは、発言を短くするだけでなく、誰のどの発言から、どこまで言えるかを残します。同じ人が同じ課題を何度も話したとき、発言数を人数へ読み替えると、課題の広がりを大きく見せてしまいます。
この記事では、架空の3人・6発言から、根拠付きの知見と次の調査課題を作ります。質問表を作る段階ではなく、聞き取り後の整理を扱います。実際の顧客調査、AIによる分析、製品改善の効果は検証していません。
目次
調査の問いと、分析する記録を固定する
今回の架空の問いは「備品申請の後、受付されたことをどのように確認したか」です。対象はP01・P02・P03の3人で、記録版v1に6つの発言断片があるとします。匿名IDは説明用で、実在する顧客との対応表はありません。
GOV.UKの分析ガイドは、見聞きした観察を取り出し、テーマごとに整理した後、知見と次の行動へ進む流れを説明しています。見聞きした内容と、それが何を意味すると思うかを分けて記録する点を、AIへ渡す表でも保ちます。GOV.UK：調査セッションの分析（新しいタブで開く）
実際には記録の版、参加者ID、発言位置、質問や前後の文脈を対応させます。引用を読みやすく直した要約と、原文をそのまま示す引用も別欄にします。記録へ戻れない断片を、もっともらしい文章で補って証拠にしません。
発言と、分析者の解釈を別欄に置く
次は独自に作った発言です。録音や文字起こしから抽出した実測データではありません。
表は横にスクロールできます
| 発言ID | 参加者 | 架空の発言原文 | 発言の扱い |
|---|---|---|---|
| N01 | P01 | 申請した日の夕方に、画面で状態を確認しました。 | 本人が語る過去の行動 |
| N02 | P01 | 翌日も同じ画面を見ました。 | 本人が語る過去の行動 |
| N03 | P02 | 昨日の申請が届いたか分からず、担当者にチャットしました。 | 本人が語る過去の行動と理由 |
| N04 | P03 | 完了メールで受付済みと分かったので、その後は確認しませんでした。 | 本人が語る過去の行動と理由 |
| N05 | P02 | 担当者に聞いた後は、返事を待ちました。 | 本人が語る過去の行動 |
| N06 | P01 | 通知があれば便利そうです。 | 仮想の機能への意向 |
本人が話した過去の行動と、調査者が実際に操作を観察したことは同じではありません。この表からは、P01が画面を操作する様子を調査者が見たとは言えません。N06も通知機能を実際に使った結果ではなく、機能への意向です。
GDSの公式ブログは、参加者コードを観察メモへ付け、誰が何を話したか追えるようにする方法を説明しています。ここでもN01とN02を別人の声として扱わず、P01に結び付けます。GDS：調査分析の進め方（新しいタブで開く）
発言3件と、参加者2人を区別する
「申請後に画面確認や担当者への問い合わせをした」という過去の行動のテーマへ、N01・N02・N03を対応させます。このテーマに対応する発言は3件ですが、参加者はP01・P02の2人です。
N05はチャット後の待機、N06は将来の希望なので、このテーマの発言数へ加えていません。どちらも元表から消さず、別の分析材料として残します。テーマの定義を変えるなら、どの発言を含めるかも更新します。
表は横にスクロールできます
| 集計するもの | 今回の値 | 読み方 |
|---|---|---|
| 記録全体 | 6発言、3人 | 今回の架空記録の範囲 |
| 画面確認・問い合わせのテーマ | 3発言、2人 | N01・N02・N03、P01・P02 |
| メールで受付済みと分かった経験 | 1発言、1人 | N04、P03 |
| 通知への仮想の意向 | 1発言、1人 | N06、P01。過去の利用実績ではない |
最後の3行は排他的な参加者区分ではありません。P01は過去の行動と仮想の意向の両方に出ます。人数を足して調査参加者数へ戻さないでください。
今回の2人という値を、市場全体の困りごとの発生率へ広げません。誰を、どんな問いで、どのように聞いたかが違えば材料も変わります。また、発言が記録にないことだけで、その人は困っていないと判定しません。P03については、N04という具体的な発言があることを根拠に扱います。
反対の経験を残し、知見の範囲を狭める
この例で「全員が受付されたか分からず困った」とまとめると、P03のN04と合いません。「通知が必要な顧客が多数いる」とも結論できません。通知への意向はP01のN06だけで、実際の利用や購入につながるかは不明です。
根拠付きの短い知見なら、「P01は画面、P02はチャットで申請後の状態を確かめた。一方、P03は完了メールで受付済みと分かり、その後の確認はしなかった」と書けます。原文をつなげた一人の直接引用ではなく、分析者の要約として示します。
ここから「受付済みと分かる情報の届き方や理解に違いがあるかもしれない」という解釈を置けます。ただし、P01・P02へメールが届かなかった、メールが分かりにくかった、という事実は入力にありません。システム不具合や原因へ飛躍しないようにします。
改善案を、次に検証する問いへつなげる
表は横にスクロールできます
| 段階 | 今回の記載例 | 状態 |
|---|---|---|
| 発言根拠 | N01・N02・N03とN04 | 原文へ戻れる材料 |
| 知見 | 状態を別手段で確認した2人と、メールで分かった1人がいた | この記録内の要約 |
| 解釈 | 受付確認の情報が届く状況や理解に差があるかもしれない | 仮説 |
| 次の調査 | 各人へ何が届き、何を見て受付済みと判断したかを確認 | 未実施 |
| 改善候補 | 受付確認の表示や文面を試す | 効果未検証 |
「通知機能を実装する」という仕様決定まで、自動で進めません。今回の不明点を確かめると、既存メールの表示、送信状況、別の業務手順などを調べる必要が出るかもしれません。候補の効果を測る場合も、何が変われば改善と判断するかを別に定めます。
参加者数と根拠IDを検算する
次のPythonは、手作業で付けた対応関係の件数を照合します。自然文からテーマを自動分類する処理ではありません。
speaker = {
"N01": "P01", "N02": "P01", "N03": "P02",
"N04": "P03", "N05": "P02", "N06": "P01",
}
theme = ("N01", "N02", "N03")
counterexample = ("N04",)
future_preference = ("N06",)
assert len(speaker) == 6
assert set(speaker.values()) == {"P01", "P02", "P03"}
assert len(theme) == len(set(theme)) == 3
assert set(theme) <= set(speaker)
participants = {speaker[note] for note in theme}
assert participants == {"P01", "P02"}
assert len(participants) == 2
assert {speaker[n] for n in counterexample} == {"P03"}
assert {speaker[n] for n in future_preference} == {"P01"}
print(len(theme), len(participants))
この計算はテーマの意味が正しいことや、発言の聞き違いがないことを保証しません。分類根拠は原文と前後関係へ戻って編集確認します。辞書に入れる前のID重複や原記録の欠落を検出する汎用処理も含めていません。
AIへは、根拠のない原因と顧客像を足させない
架空の顧客インタビュー記録N01～N06を整理してください。
発言原文、参加者ID、テーマ、分析者の要約、仮説、次の調査を分けてください。
同じ人の複数発言を複数人として数えず、発言IDと参加者IDを併記してください。
過去の自己申告、調査者が見た行動、仮想の希望を区別してください。
仮説と異なる経験や、未分類の発言も残してください。
入力にないメールの未達、原因、購入意思、顧客全体の割合を作らないでください。
原文をつなぎ合わせた直接引用を作らず、要約には要約と表示してください。
出力：根拠表、テーマ別の発言数と参加者ID、知見、反対の経験、未確認、次の問い。
依頼文と分類は手製例です。AIでの再現性や正答率は未測定です。整理後は、反対の経験が要約から消えていないか、希望が実際の行動へ変わっていないか、テーマの人数に重複がないかを点検します。
分析表を共有する際も、原記録への参照と公開できる引用を分けます。記録を分析に使えることと、発言を広告や外部資料へ引用できることは別です。根拠を残しながら、必要な相手へ必要な範囲を渡す形にします。
参考資料
- GOV.UK Service Manual：Analyse a research session（新しいタブで開く）
- GDS：How we do research analysis in agile（新しいタブで開く）
公式資料の確認日：2026年10月20日。参加者、発言、テーマ、知見、改善候補は独自の架空例です。掲載Pythonと集計をローカルで検査しました。実顧客、録音・文字起こし、AI分類、原因、需要、改善効果、共有・公開、画面表示は未検証です。