顧客ヒアリングメモは、要約より先に「事実」と「解釈」を分けておく
顧客ヒアリングのメモは、AIと相性がよさそうに見える仕事の一つです。録音や議事メモを渡せば、要点をまとめ、課題らしいものを抽出し、次のアクションまで整理してくれる。忙しい現場では、とても助かる使い方だと思います。
ただ、ヒアリングメモをAIで扱うときに、最初から「きれいな要約」を目指すと少し危うい場面があります。要約は読みやすい一方で、顧客が実際に言ったことと、こちらがそう受け取ったことが混ざりやすいからです。営業、CS、企画、開発が同じメモを読むほど、この混ざり方はあとから効いてきます。
たとえば顧客が「この画面で毎回迷います」と話したとします。これはまず、発言としての事実です。一方で、「導線が悪い」「説明文が足りない」「権限設計が合っていない」といった整理は、こちら側の解釈です。どれもあり得ますが、最初のメモで一つにまとめすぎると、後工程ではそれが事実のように扱われやすくなります。
顧客ヒアリングをAIに渡す前に、まず分けておきたいのはこの線です。顧客が言ったこと、実際に起きたこと、こちらが推測した原因、次に確認すべきこと。これらを同じ「要約」の中に入れるのではなく、別の種類の情報として残しておく。AIを使うなら、むしろこの分離を手伝わせるのがよいのではないかと思います。
実務では、ヒアリングメモは単なる記録ではありません。プロダクト改善、営業提案、サポート対応、ロードマップ検討の材料になります。だからこそ、読みやすさだけでなく、あとから検証できる形で残っていることが大事です。誰かの解釈が早い段階で強く入りすぎると、別のチームが見たときに確認余地が狭くなります。
AIに任せる範囲も、ここで少し変わります。「全部をうまくまとめて」と頼むより、「発言として残す部分」「観察として残す部分」「こちらの仮説として分ける部分」「追加確認が必要な部分」を分けてもらう。きれいな文章に整える前に、情報の種類をそろえるイメージです。
この分け方をしておくと、会議での使い方も変わります。開発チームは、顧客発言と推測を分けて見られます。営業やCSは、次回確認すべきことを持ち帰れます。企画側は、複数のヒアリングに共通する事実と、まだ仮説にとどまる解釈を分けて扱えます。メモがそのまま判断材料になりやすくなります。
最初から大きな仕組みにしなくてもよいと思います。まずは1回のヒアリングについて、メモの末尾に「事実」「解釈」「未確認」「次に聞くこと」の4つだけを置いてみる。AIには、その4つへ粗く振り分けてもらい、人が最後に直す。これくらいの小さな運用でも、要約だけのメモより後工程で使いやすくなります。
気をつけたいのは、AIが作った整理をそのまま正解にしないことです。AIはもっともらしい因果関係を作ることがあります。顧客が本当に困っていたことと、こちらが改善したいことが、自然な文章の中で近づきすぎることもあります。だから、解釈の欄には「仮説」として残し、事実の欄とは分けておく必要があります。
顧客ヒアリングメモの価値は、短くなることだけではありません。あとから別の人が読み、別の判断に使えることにも価値があります。AIで要約するほど、この「あとから使える形」が重要になります。読みやすいメモより先に、事実と解釈が分かれているメモを作る。
AI活用は、記録作業を軽くする話であると同時に、記録をどう判断材料へ変えるかの話でもあります。顧客の声を扱う仕事では、最初の一手は要約の精度を上げることではなく、事実と解釈を混ぜない置き方を決めることなのかもしれません。
書いた内容をskillで利用するなら
---
name: "customer-interview-evidence-split"
description: "顧客ヒアリング、商談メモ、CS/サポート対応ログ、ユーザーインタビュー、VOC、顧客フィードバック、プロダクト改善メモを扱う時に使う。顧客の声をすぐ要約せず、事実・観察・解釈・仮説・未確認・次に聞くこと・次アクションへ分け、営業/CS/企画/開発が後から検証できる判断材料に変える。顧客が言ったこととチームが推測したことを混ぜたくない時、AI要約の前処理をしたい時、PM/CS/営業から開発への引き継ぎを作る時は必ず使う。"
---
# Customer Interview Evidence Split
顧客ヒアリングメモを、AIでいきなり「きれいな要約」にしないための skill。
目的は短くすることではなく、後から別の人が読み、別の判断に使える状態へ整えること。顧客が実際に言ったこと、観察できたこと、こちら側の解釈、まだ未確認のことを分けてから、最後に要約する。
## Core Rule
要約する前に分ける。
- 顧客が言ったことを、こちらの解釈に混ぜない。
- 観察できたことと、推測した原因を分ける。
- AIが作った自然な文章を、そのまま正解にしない。
- `事実`, `解釈`, `未確認`, `次に聞くこと` を最低限残す。
## When To Use
使う場面:
- 顧客ヒアリングメモ
- 商談、ディスカバリーコール、オンボーディング記録
- CS / サポート対応ログ
- ユーザーインタビュー、ユーザーテスト観察メモ
- VOC、NPS自由記述、アンケート自由回答
- 顧客の声をもとにしたプロダクト改善メモ
- 営業/CS/リサーチから、PM/企画/開発/デザインへ渡す引き継ぎ
使わない場面:
- 顧客の声が主題ではない通常の議事録
- 社内意思決定だけの会議メモ
- すでに公開用に整えられた事例記事の校正
## Input Check
最初に入力の種類と信頼度を判定する。
入力種別:
- `transcript`: ほぼ逐語の会話ログ
- `rough_notes`: 人が取ったラフなメモ
- `summary_only`: すでに誰かが要約したものだけ
- `mixed`: 会話ログ、メモ、担当者コメントが混在
- `survey_feedback`: 複数人の短い自由回答
信頼度:
- `high`: 直接発言や逐語ログがある
- `medium`: 詳細メモはあるが逐語ではない
- `low`: 要約済み、二次情報、発言者や文脈が曖昧
`summary_only` の場合、顧客の直接発言を捏造しない。引用風にせず、`要約からの抽出` と明記する。
## Workflow
1. 入力を一度読み、顧客接点の種類と目的を把握する。
2. 先に raw evidence を拾う。まだ要約しない。
3. 下の7分類に分ける。
4. 解釈が事実のように書かれている箇所を警告する。
5. 分類が終わってから、3-5行の短い要約を作る。
6. 追加確認質問と次アクションを、確信度つきで出す。
7. 外部共有や公開用途なら、顧客名、個人名、契約、金額、機密情報を一般化する。
## Seven Buckets
基本はこの7分類を使う。
1. `顧客が言った事実`
- 顧客が明示的に言ったこと。
- 短い直接表現がある場合は残す。
- 例: `この画面で毎回迷います`
2. `観察できた行動`
- 会話や操作中に実際に起きたこと。
- 迷い、繰り返し操作、入力漏れ、回避策、沈黙、確認回数など。
3. `チーム側の解釈`
- 担当者やチームが「こういう意味かもしれない」と受け取ったこと。
- `可能性がある`, `示唆している`, `かもしれない` の形にする。
4. `仮説`
- 検証できる原因説明。
- 反証できる形にする。
5. `未確認 / 足りない証拠`
- 判断前に足りない情報。
- 顧客属性、頻度、再現条件、他顧客でも同じか、正確な発言など。
6. `次に聞くこと`
- 同じ顧客、または類似顧客に確認する質問。
- 誘導質問にしない。
7. `次アクション`
- Product / Design / Engineering / CS / Sales / Research で実行できる行動。
- 低リスクで戻せる行動と、追加証拠が必要な行動を分ける。
## Output Format
標準出力:
# Customer Evidence Split
## 入力と信頼度
- 入力種別:
- 信頼度:
- 注意:
## 要約
-
-
-
## Evidence Split
| 分類 | 内容 | 根拠 | 信頼度 | 主な利用先 |
|---|---|---|---|---|
| 顧客が言った事実 | | | high/medium/low | |
| 観察できた行動 | | | high/medium/low | |
| チーム側の解釈 | | | high/medium/low | |
| 仮説 | | | high/medium/low | |
| 未確認 / 足りない証拠 | | | high/medium/low | |
| 次に聞くこと | | | high/medium/low | |
| 次アクション | | | high/medium/low | |
## 解釈しすぎリスク
-
## チーム別引き継ぎ
- Product:
- Design:
- Engineering:
- CS / Support:
- Sales:
- Research:
## Practical Handling
### 事実と原因を分ける
悪い例:
- 顧客はUIが悪いと言っている。
良い例:
- 顧客が言った事実: `この画面で毎回迷います`
- 観察できた行動: 同じ箇所で2回戻っている
- 仮説: 導線ラベルが顧客の業務語彙と合っていない可能性
- 次に聞くこと: 最初にどこを押すと思ったか
### 要約を最後にする
先に要約すると、顧客発言、観察、解釈、仮説が自然な文章の中で混ざる。必ず分類後に要約する。要約では、確信度と未確認事項を残す。
### AIの整理を正解にしない
AIは自然な因果関係を作りやすい。`Aが原因でBが起きている` と書きたくなったら、直接証拠があるか確認する。なければ仮説へ移す。
## Red Flags
必ず警告する状態:
- 1人の発言が、顧客全体の事実として扱われている
- 顧客が言っていない原因が、顧客ニーズとして書かれている
- チームが作りたい改善案が、顧客要望に変換されている
- AI要約で不確実性が消えている
- 修正案が、問題の検証より先に出ている
- 顧客名、個人名、契約、金額、医療/健康/人事などのセンシティブ情報が残っている
## Quality Bar
完了前に確認する。
- `顧客が言った事実` と `チーム側の解釈` が混ざっていない。
- すべての仮説に、確認方法か反証方法がある。
- 未確認事項が消えていない。
- 次アクションが、証拠量に対して大きすぎない。
- 要約が、根拠よりも確信度を強く見せていない。
- 別チームが読んでも、何を信じてよく、何を確認すべきか分かる。
## Mini Prompt To Reuse
この顧客ヒアリングメモを、要約の前に
1. 顧客が言った事実
2. 観察できた行動
3. チーム側の解釈
4. 仮説
5. 未確認
6. 次に聞くこと
7. 次アクション
に分けてください。最後に3-5行で要約し、解釈しすぎリスクも指摘してください。