顧客インタビューの質問をAIで作るときは、「製品をどう思うか」を大量に聞くより、調べたい仮説と、最近の具体的な経験を結び付ける質問表を作ります。聞き手が期待する答えを質問に埋め込むと、困っている理由や、実際に使った代替手段が見えにくくなります。
AIには質問の初稿、追質問、誘導や前提の点検を頼みます。顧客の回答や需要を生成する役割は与えません。この記事では、社内の備品申請を支援するサービスを検討する架空の例で、仮説と質問、記録を対応付ける方法を説明します。実際の顧客調査やAI性能の実測結果ではありません。
目次
製品の機能からではなく、調べたいことから始める
最初に、今回の聞き取りで分かると次の判断が変わる問いを決めます。例えば「通知機能が欲しいか」より、「申請後に進み具合をどう確かめているか」を調べれば、通知以外の方法や、そもそも確認が不要な場面も聞けます。
仮説は、肯定する回答を集めるための結論ではありません。「差し戻しが多いかもしれない」と考えていても、実際は一度で終わる人がいるなら、その経験も残せる質問にします。利用者、利用を見送った人、別の方法で済ませた人など、誰の経験を聞くかも調査目的に合わせます。
GOV.UKのインタビューガイドは、調査上の問いからトピック、最初の質問、追質問を作り、流れを試す手順を説明しています。AIが出した順番をそのまま採用せず、聞きたいことと質問が対応しているかを確認します。GOV.UK：インタビューの設計（新しいタブで開く）
仮説・質問・反対の経験を一つの表にする
次は、備品申請について調べる架空の質問表です。質問の数を増やすための一覧ではなく、何を聞けたら仮説を見直せるかまで残します。
表は横にスクロールできます
| 調べたい仮説 | 最初の質問 | 必要に応じた追質問 | 仮説を見直す経験の例 |
|---|---|---|---|
| 申請に必要な情報が分からず、やり直しになる | 最近、備品を申請したときの流れを、始めから教えてください | 何を用意しましたか。途中で確認したことはありましたか | 必要な情報が分かり、一度で終わっていた |
| 進み具合が分からず、別の連絡をしている | 申請した後、結果が分かるまで、どうしていましたか | 状態を知りたい場面はありましたか。そのとき何をしましたか | 状態を確認する必要がなかった、または既存の方法で分かった |
| 既存の方法を使わない理由がある | その申請方法は、どのように選びましたか | 他の方法を考えましたか。選ばなかった理由は何ですか | 現在の方法が適していて、変更の必要がなかった |
追質問は、すべてを順番に読む台本ではありません。すでに回答が出た内容を聞き直さず、不明な部分を具体化するために使います。「やり直しが大変だったのですね」と先に評価を付けず、何が起き、本人がどう受け止めたかを分けて聞きます。
相手に申請経験がなければ、経験したことのように語ってもらわないでください。今回は実際の経験を扱えなかったと記録し、別の問いへ進むか、対象者の選び方を見直します。
誘導、二つの質問、架空の未来を切り分ける
AIの質問案では、次のような違いを見ます。
表は横にスクロールできます
| 点検前の質問 | 問題 | 言い換えの方向 |
|---|---|---|
| 申請システムが使いにくくて困りましたか | 使いにくい、困ったという前提が入る | 最近使った場面と、そのとき行った操作を聞く |
| 申請は簡単で、承認も早かったですか | 二つのことを一度に聞く | 入力の流れと、結果が分かるまでを別に聞く |
| 自動通知があれば使いますか | 仮想の機能への意向で、過去の行動ではない | 直近で進み具合を知りたかった場面を聞く |
| 普段はちゃんと申請していますか | 良い答えを求められたように受け取られ得る | 最近の一回について、実際の進め方を聞く |
将来の希望を聞いてはいけないわけではありません。ただし、「使いたい」という意向と、実際に使った行動を同じ証拠として扱いません。新しい機能の説明を先に見せると、その後の回答が説明の影響を受ける可能性もあるため、現状の経験を聞く部分と、案への反応を聞く部分を分けます。
GOV.UKは、開かれた中立的な質問と追質問を使い、一般論より実際の話や具体例に焦点を当てることを案内しています。この記事の表は、その考え方を架空の業務へ当てはめた編集例です。
AIへ渡すのは、調査目的と未確定の仮説
顧客インタビュー用の質問表を作ってください。
調査目的：［次に決めたいこと］。対象者：［聞きたい経験を持つ人］。
仮説：［未確定の仮説。結論として扱わない］。
出力：仮説ID｜調べたいこと｜最初の質問｜追質問｜前提が合わない場合の扱い。
最近の具体的な経験を聞ける質問を中心にしてください。
困っている、使いにくい、買いたいという答えを前提にしないでください。
一つの質問で複数の論点を聞かないでください。
仮説と反対の経験も記録できるようにしてください。
顧客の回答、発言引用、利用率、購入意思を創作しないでください。
最後に、誘導が残る箇所と確認事項を別表へ示してください。
初稿の質問数ではなく、調査目的との対応を見ます。対応する仮説も判断もない質問は、今回聞く必要があるかを見直します。逆に重要な仮説へ一つも質問が対応していなければ、聞き漏らす設計になっています。
当日の流れと、記録の欄を用意する
冒頭では調査の目的、扱う内容、録音・記録、共有範囲を説明し、必要な同意を確認します。顧客情報をAIへ入力できるかは、調査で得た同意だけでなく、組織のルールや利用環境にも照らして確認してください。
質問は、相手の役割や最近の作業を確認してから、具体的な一回の流れへ進めます。最後に聞き手の理解を短く返し、取り違えがないかを確認します。会話を質問表へ無理に戻し続けるのではなく、不明な箇所を自然な区切りで確かめます。
記録には次の欄を持たせます。
- 参加者の匿名IDと、対象となる経験の範囲
- 仮説ID、質問ID、質問表の版
- 実際に話された内容と、原記録の位置
- 行動、本人の意見、仮想の希望の区別
- 聞き手の解釈と、まだ確認していない点
- 次の調査や判断へ持ち越す質問
GOV.UKの分析ガイドは、観察した事実を取り出してから、まとまりや知見、次の行動へ進む流れを示しています。AIが作る要約でも、発言そのものと聞き手の解釈を同じ欄へ混ぜないようにします。GOV.UK：調査セッションの分析（新しいタブで開く）
事前練習の結果を、顧客の証拠にしない
同僚との試行で、質問の分かりにくさ、順番、重複、時間の使い方を確認します。AIを相手役にして練習する場合も、実際の顧客の経験を観測したことにはなりません。生成された「回答」を利用者の声や需要として集計しないでください。
練習後は、誘導のある質問を直したか、仮説に反する答えも記録できるか、経験がない人を無理に回答させないかを確認します。試していない質問表を、検証済みの調査手法と呼ばないようにします。
実際の聞き取りが終わっても、少人数の意見から市場全体の割合や購入率は決まりません。今回の対象者、経験の範囲、質問の仕方で得られた材料として扱い、次の確認へつなげます。
公開資料も含めた調査全体の設計は、AIで市場調査を進める方法で確認できます。顧客の発言をAIへ入力する段階では、顧客情報を入力するときの注意点も参照してください。
参考資料
- GOV.UK Service Manual：Using in-depth interviews（新しいタブで開く）
- GOV.UK Service Manual：Analyse a research session（新しいタブで開く）
資料の確認日：2026年10月20日。質問表は架空業務の編集例です。顧客への実施、AIによる質問生成、質問の中立性や所要時間の検証は未実測です。