新規事業の顧客インタビューを設計する — Claudeで前提ごとの質問と判定基準を作る

顧客インタビューが「やってみたが何も決まらなかった」で終わる原因の多くは、聞き方より前にあります。何を確かめたいのか、何が聞けたら成立と見なすのかが決まらないまま、相手の前に座っていることです。

この記事は、リーンキャンバスで洗い出した危うい前提を出発点に、前提ごとの質問、避ける誘導、成立の判定基準をインタビュー前に文書へ固定する手順を扱います。作業の場はClaudeのProjectsです。Claudeに任せるのは設計書の叩き台と誘導の点検で、相手の本音を代わりに答えさせることはしません。

質問の前に、前提ごとに3つを決める

インタビューの設計単位は質問ではなく前提です。前提1つにつき、次の3点を先に決めます。

3点目が抜けると、インタビューのあとで「手応えはあった」という感想だけが残ります。基準を先に決めておくのは、良い結果に都合のよい物差しを後から選ばないためです。

前提そのものの洗い出しは、リーンキャンバスをClaudeで作る手順で扱っています。ここでは、その台帳の「外れると事業が成り立たない」前提を、手元にある状態から始めます。

前提の種類で、聞く内容が変わる

新規事業の前提は、おおよそ次の5種類に分かれます。種類ごとに、聞く質問の型と避ける誘導の型が決まります。以下は設計の型を示す例で、実際の事業の値ではありません。

どの行も、軸は過去の行動です。「使いたいですか」「払いますか」のような未来の仮定を聞く質問は、相手が礼儀として前向きに答えやすく、成立の根拠として弱くなります。

聞いてはいけない質問の型

誘導は、意図して仕掛けるものより、気づかないうちに混ざるもののほうが多く見られます。設計書に禁止の型として書いておくと、本番で自分の質問を点検しやすくなります。

• 褒めを求める質問。「このアイデアをどう思いますか」は、相手の評価を聞いているだけで、前提の成否と結びつきません。
• 仮定の未来。「もしあったら使いますか」は、行動ではなく気持ちの回答になります。
• 選択肢の押しつけ。「A、B、Cのどれが近いですか」は、相手が考えていない軸を持ち込みます。
• 複数の質問の合体。「費用と手間と頻度はどうですか」は、答えやすい1つにだけ答えが寄ります。
• 提案の先出し。解決策を説明してから課題を聞くと、相手は説明に合わせて課題を語り直します。

この5つは、Claudeに点検させやすい観点でもあります。質問案を渡して「どの型に当たるか」を判定させれば、人が見落とした箇所を拾えます。

手順1: Projectsを作り、資料を置く

claude.aiの「Projects」から「+ New Project」で作成します。名前と説明はClaudeからは見えないため、Claudeに伝えたいことはプロジェクト指示かナレッジに書きます。ナレッジに入れた資料は、そのProjectのすべてのチャットで使われます。

置く資料は次のとおりです。

00_idea_memo.md           アイデアメモ
02_lean_canvas_確定版.md   確定したキャンバス
03_assumption_ledger.md    前提台帳(ID / 前提 / 影響 / 現時点の根拠)

前提台帳は、前提ごとの「外れたときの影響」と「現時点の根拠」の列を持つ表です。台帳がまだ無いときは、先にキャンバスの手順で作っておきます。既にあるインタビュー記録は、氏名を「A氏」、社名を「X社」のような記号に置き換えてから入れます。Team・Enterpriseプランでは作成時に公開範囲を選べ、「Keep it private」なら自分と招待したメンバーだけが使えます。ナレッジの資料は、閲覧できるメンバーから読まれる点に注意が要ります。

手順2: プロジェクト指示で設計の型を固定する

「Set project instructions」に、設計の約束事を入れます。保存した指示は、そのProjectのすべてのチャットに効きます。

あなたは新規事業の顧客インタビューの設計を支援する調査担当です。
ナレッジの前提台帳だけを根拠にします。
 
1. 質問は、相手の過去の行動と事実を聞く形で書く。
   「使いたいか」「払うか」のような未来の仮定は質問にしない。
2. 前提ごとに「聞く質問」「避ける誘導」「成立の基準」を必ず出す。
3. 成立の基準は、人数と条件を数字で書く。
   数字の根拠が資料に無いときは「要決定」と書き、案を作らない。
4. 相手の回答を想像して書かない。回答例が必要なときは、
   冒頭に「想像した例」と明記する。

4番目が重要です。Claudeは模擬回答を流暢に書けますが、それは顧客の声ではありません。想像した例と実際の記録が混ざると、設計書を読み返したとき証拠と創作の区別がつかなくなります。

手順3: 前提ごとの設計書を作らせる

新しいチャットで、台帳のうち検証の優先度が高い前提を指定して依頼します。

03_assumption_ledger.md の A2 と A3 について、
インタビュー設計書を作ってください。
前提ごとに次の表を出します。
- 聞く質問(3つまで。過去の行動を聞く形)
- 避ける誘導(この前提で混ざりやすいもの)
- 成立の基準(人数と条件)
- 反証と見なす発言(前提が外れたと判断する材料)

「反証と見なす発言」まで先に書かせるのが、この手順の要点です。成立の基準だけでは、外れたときの判断が曖昧なまま残ります。成立と反証の両方が決まっていれば、中間の結果は「追加で聞く」と判断できます。

返ってきた表は、次の順で読み直します。

1. 質問が過去の行動を聞く形になっているか
2. 成立の基準の数字が、自分の事業の規模に合っているか
3. 反証の材料が、成立の基準と矛盾していないか

成立の基準の数字は、Claudeの案をそのまま採用しません。「10人に聞いて3人以上」のような数は、市場の大きさ、相手の見つけやすさ、事業が許容する失敗の重さで変わります。ここは事業を知っている人が決める部分です。

手順4: 質問案の誘導を点検させる

設計書の質問が固まったら、別のチャットで点検だけを頼みます。設計したチャットとは文脈を分けるほうが、自分の案をかばわない判定になります。Projectsでは、チャット同士で文脈は共有されません。ナレッジに追加した情報だけが引き継がれる仕様なので、点検用のチャットには設計書を貼るか、ファイルとしてナレッジに入れます。

次の質問案を、誘導の観点で点検してください。
型は、褒めを求める / 仮定の未来 / 選択肢の押しつけ /
複数の質問の合体 / 提案の先出し、の5つです。
当たる質問には型の名前と、直した質問案を示してください。
当たらない質問は「問題なし」とだけ書いてください。

「問題なし」の書き方を指定しているのは、無理に指摘を捻り出させないためです。指摘が多すぎるときは、点検の型が曖昧か、元の質問が相手に答えづらい形になっています。

手順5: 練習は人と、模擬回答は証拠にしない

Claudeに顧客役を演じさせて質問の流れを練習することはできます。聞く順番に詰まりがないか、重い質問から入っていないかを確かめる用途には向きます。

ただし、練習で得た回答は成立の基準に数えません。顧客役の発言はClaudeが作ったもので、現実の誰かの行動ではないからです。練習は質問の言い回しと流れを直すためのもの、成立の判定は実在の相手の記録だけ、と分けておきます。

手順6: 設計書をナレッジに戻す

設計書が固まったら、日付付きのファイルにしてナレッジに戻します。たとえば 04_interview_plan_20261013.md です。プロジェクト指示はすべてのチャットに効きますが、設計書の中身は効きません。ナレッジに戻さなければ、次のチャットのClaudeは設計書を知らない状態から始まります。

インタビューを終えたら、記録を 10_interview_A_20261015.txt のように1回1ファイルで追加し、設計書の「成立の基準」と照合させます。

10_interview_A_20261015.txt を追加しました。
04_interview_plan_20261013.md の前提 A2 について、
成立の基準に対して、この記録がどう当たるかを示してください。
該当する発言は原文のまま引用し、ファイル名を添えてください。

引用は、元の記録を開いて原文と照らしてから台帳に載せます。ナレッジが大きくなって有料プランでRAGモードに切り替わると、Claudeは関連する断片を取り出して答える形になります。複数の記録を横断して照合する方法はインタビュー逐語録の横断分析に、RAGの挙動はClaude ProjectsのRAG検索にあります。

判定基準の書き方の例

設計書に書く成立の基準は、数と条件が揃っていると結果を見たときに迷いません。形式を示す例です。

前提 A2: 現行の手順を変えてでも導入したい
対象: 見積業務を週に1回以上担当している購買担当者
人数: 8人に聞く
成立: 3人以上が、過去1年に現行手順を自分で変えた具体例を語る
反証: 6人以上が、手順を変える権限も動機もないと語る
追加で聞く: 上記のどちらにも当たらない

「成立」と「反証」のあいだに「追加で聞く」の領域を置いておくと、結果が割れたときに判断を先送りせず、次に聞く相手や質問を決められます。人数が少ないうちは、数字は確率ではなく「次に進んでよい目安」として扱います。

つまずきやすい点

成立の基準を、結果を見てから直したくなる。結果が基準に届かなかったとき、基準を下げて合格にしたくなります。基準を変えるなら、変えた理由と日付を設計書に残し、変更前の版も取っておきます。

Claudeが顧客の声を作ってしまう。設計書に「想像した例」が混ざると、証拠のように見えます。指示の4番目を入れていても、回答例を頼んだ場合は冒頭の明記があるかを確認します。

質問が増えて1回のインタビューに収まらない。前提1つにつき質問は3つまでに絞ります。全前提を1回で聞こうとせず、優先度の高い前提から回します。

話を聞くだけで終わり、行動の事実が出てこない。相手が意見を語り始めたら、「直近でそれをしたのはいつですか」のように行動へ戻します。意見が多く行動が少ないこと自体が、課題の深さを測る材料になります。

インタビュー後の分析まで同じチャットで済ませる。記録が増えたあとの横断分析は、専用の手順に分けたほうが整理しやすくなります。分析の道具としてはDovetailコネクタがあり、結果を導入事例に仕上げる流れは導入事例の作り方にあります。

まとめ

顧客インタビューの質は、本番の話術より、前提ごとに質問・誘導・基準を先に決めてあるかで分かれます。Claudeは設計書の叩き台と誘導の点検に向き、顧客の声を作る用途には向きません。

成立の数字は事業を知っている人が決め、結果を見る前に固定します。設計書をナレッジに戻して回すと、Projectsが検証の記録を積む場所になります。Projectsの基本はClaude Projects完全ガイドから確認できます。