voice-of-customer-miner

顧客の声のマイニング

目的

レビューサイト、アプリストア、Reddit や実務者フォーラム、コミュニティ掲示板から公開されている顧客の声をマイニングし、満たされていないニーズ、競合の弱み、乗り換えのきっかけを見つけます。検索計画 → 情報源の調査 → 発言のそのままの記録 → ニーズのテーマ → それが意味すること → 次の選択肢。 これは競合情報とディスカバリーをつなぎ、インタビューのサイクルを待たずに、顧客が実際に使った言葉を届けます。ただし、公開されている声は怒っている人や声の大きい人に偏るため、浮かび上がったテーマはすべて、あくまで検証すべき仮説であり、決定的な結論ではありません。常に実際の会話を最後のステップにします。

入力

最も効果的な入力： マイニング対象の製品または競合（自社、競合他社、またはその両方）と、この調査結果を役立てる意思決定です。 あると便利な入力： 焦点を当てるテーマ（オンボーディング、価格設定、信頼性など）。指定がない場合は、テーマを限定せずに調査します。

呼び出し時にインラインで指定された入力（スキル名の後のテキスト、貼り付けられたコンテキスト、または末尾に追加された ARGUMENTS: 行）は、すでに回答済みの内容として扱います。質問数の上限に含めて活用し、再度質問しないでください。

手ぶらで始めても大丈夫です。 スキルは最大3つの質問（誰の声か、どの意思決定に役立てるか、テーマを絞るか範囲を限定しないか）から始め、回答がなければ、前提を明記して進めます。

呼び出し例： Mine voice-of-customer for [Competitor A] and [Competitor B], focus on onboarding — informs whether our Q1 bet is a migration tool.

主な概念

• 適用されるプロトコル： autonomous-investigation の契約（質問数の上限は3つ、検索計画の確認、事実／推論／仮定のラベル付け、ジャスト・イナフ・モード、安定したスキーマ、4つの選択肢からなる最終ステップ）に従います。規律の参考：OSINT のレビューおよびコミュニティ調査レイヤー（intelligence-collection-disciplines を参照）。
• 機能ではなくニーズでテーマ化します。 「エクスポートが壊れている」は機能への不満ですが、「チームが使う場所にデータを持っていけない」は根底にあるニーズです。ニーズを基準にテーマ化するのは、JTBD やペインストーミングと同じく、解決策にとらわれない規律であり、テーマをディスカバリーに活用できる形にする方法です。
• 実際の発言が成果物です。 URL を添えた、短く、実際の顧客の言葉を引用します。実際の発言から、ペルソナが使う言葉を学べます。顧客が使う正確な言葉は、インタビューの質問やポジショニングのコピーになります。引用、評価、レビュー件数、レビュアーの役割を捏造してはいけません。
• 情報源にはそれぞれ既知の偏りがあります。 レビュー投稿者は否定的な意見に偏り、ベンダーのコミュニティはロイヤルティの高いユーザーに偏り、アプリストアではアップデートへの不満が過剰に代表されます。情報源ごとに偏りを記録してください。公開されている声は、偏りが分かっている証拠であり、絶対的な真実ではありません。
• 頻度は正直に伝えます。 複数の情報源で繰り返されていることと、1つのスレッドに集中していることと、孤立しているが印象的なことは異なります。どれに当たるかを明記してください。雄弁な不満投稿者が1人いるだけでは、テーマとは言えません。
• 使用しない場合： 意味のある公開情報がない（初期段階、ニッチなエンタープライズ領域）場合は、代わりに discovery-interview-prep を実施します。非公開の領域における自社ユーザーの声が必要な場合は、自社のチケットや調査をマイニングします。統計的な確信度が必要な場合は、これは定性的なテーマ化です。

適用

1. インラインのコンテキストを反映し、未回答の質問だけを尋ねます（最大3つ）。
   1. 誰の顧客の声か――自社、競合他社、またはその両方ですか？
   2. この調査結果をどの意思決定に役立てますか？
   3. 焦点を当てる特定のテーマはありますか。それとも範囲を限定せずに調査しますか？
2. 3項目の検索計画を提示します。どの声の情報源を調べるか、代表的な発言をどう選ぶか、観察と解釈をどう区別するかを説明します。修正がなければ続行します。
3. 複数の種類の声の情報源を調査します。レビューサイト（G2、Capterra、TrustRadius）、アプリストア、Reddit や実務者フォーラム、コミュニティ掲示板、ソーシャルメディアのスレッドなどを調べ、短い実際の引用を URL とともに記録し、情報源ごとの偏りを記します。
4. 以下のスキーマを正確に出力します。

出力スキーマ（並べ替えないでください）

# Voice-of-Customer Snapshot

## 1. Scope
**Products mined:** | **Decision supported:** | **Sources swept:** | **As-of date:**

## 2. Need Themes
For each of the top 3-5 themes:
### Theme: [Underlying need, solution-free, 4 to 8 words]
- **Frequency:** [recurring across sources / concentrated / isolated]
- **Verbatim:** "[short real quote]" — [source, URL]
- **Verbatim:** "[short real quote]" — [source, URL]
- **Who says it:** [role/segment, if evident — labeled]
- **Reading:** [Inference — what this suggests]

## 3. Competitor Weak Points
- **[Competitor]:** [weakness in customers' words; frequency; URL]
- [Max 5, strongest evidence only]

## 4. Switching Triggers
- [What pushes customers off a product; what pulls them; labeled, cited]

## 5. So What?
- **3** opportunity hypotheses (phrased as problems, not features)
- **2** battle-card-ready weaknesses (with evidence quality noted)
- **3** assumptions to validate in real interviews
Each bullet: label, confidence, URL where relevant.

品質チェック付きの、このスキーマのコピー＆ペースト用記入版は template.md にあります。

最終ステップ（選択肢を正確に4つ提示）

1. 最上位のテーマからディスカバリーインタビューの質問を作成する（discovery-interview-prep）
2. 弱点を競合対策用のバトルカードにまとめる（battle-card-builder）
3. 最上位の仮説からオポチュニティ・ソリューション・ツリーを構築する（opportunity-solution-tree）
4. Verbose Mode でテーマを1つに絞って再実行する

1、2、3、4、1 and 2、Verbose Mode、または独自のパスを指定してください。

例

適切にまとめられたテーマ（架空の製品、説明用の実際の発言）：

テーマ：契約終了時に過去のデータを取り出す

• 頻度： 繰り返し — 過去6か月間に2つのサイトで9件のレビューとフォーラムのスレッド1件
• 実際の発言： 「エクスポートにサポートチケットを3件も使ったのに、カスタムフィールドが欠落した」 — [G2風のレビュー、URL]
• 実際の発言： 「離れると監査証跡を失うことになるので、望んでいたより1年長く使い続けた」 — [フォーラムのスレッド、URL]
• 誰が言っているか： 従業員50～200人の企業のオペレーションマネージャー — 推論（表示されているレビュアーの役職に基づく）
• 読み取り： 解約時の摩擦が、本人の意思に反する顧客維持として機能している — 推論。競合が手間のかからない移行を実現すれば、これを相手の堀から顧客離脱のきっかけに変えられます。

テーマ名に機能（「エクスポートツール」など）が含まれていない点に注目してください。ニーズを表しているため、レビューでは想像もされなかった解決策をディスカバリーで探れます。

完全なマイニング実行例（架空のFSMソフトウェア市場）はexamples/sample.mdを参照してください。頻度を正直に評価した結果、印象的なテーマでも信頼度は低くなり、各情報源のバイアスが読み取りの指針になります。声が少ないケース、つまり市場でレビューがほとんど投稿されない場合に、誠実なマイニングがどのようなものになるかはexamples/sample-industrial.mdを参照してください。

よくある落とし穴

• 機能名でテーマを設定すること。 顧客が責める機能ではなく、その根底にあるニーズを軸にまとめましょう。そうしないと、声の大きいUIへの不満にロードマップを委ねることになります。
• 実際の発言を捏造すること。 レビューを言い換えて引用符で囲む行為です。引用符を付けるなら、実際のURLにある実際の抜粋でなければなりません。この分野に「捏造してはならない項目」の一覧があるのは、顧客の発言を捏造することが誘惑的であると同時に有害だからです。
• 怒りを増幅すること。 印象的な星1つのレビュー1件をテーマとして提示することです。頻度を正直に扱うのが重要です。繰り返しなのか、集中しているのか、孤立しているのかを明示してください。
• 偏りを見落とすこと。 レビューサイトを全数調査のように読むことです。怒っている人や声の大きい人が過剰にサンプルされ、満足していても何も言わない多数派は投稿しません。情報源ごとのバイアスに関する注記は必須です。
• 検証への引き継ぎを省略すること。 テーマをそのままロードマップに載せることです。出力の「実際のインタビューで検証すべき前提」セクションはディスカバリーへの橋渡しです。活用してください。

参考資料

• autonomous-investigation（ワークフロー）— 全体を統括するプロトコル
• intelligence-collection-disciplines（コンポーネント）— OSINTにおけるレビューのマイニング情報源とバイアス分析の手法
• jobs-to-be-done（コンポーネント）— テーマの着地点となる、ソリューションに依存しない枠組み
• discovery-interview-prep（インタラクティブ）— 検証を行う場所
• opportunity-solution-tree（インタラクティブ）— 機会に関する仮説を構造化する
• battle-card-builder（ワークフロー）— 弱点を活用する
• https://github.com/deanpeters/product-manager-promptsリポジトリのmarket-intelligence/voice-of-customer-miner-prompt.mdを元に改変。