customer-research

customer-researchスキルの概要

customer-researchスキルでできること

customer-research スキルは、ありがちなブレストで終わらせず、構造化された顧客調査をエージェントに実行させるためのスキルです。実務では主に2つの用途に対応します。すでに手元にある調査データを分析すること、そして一次情報がない場合に公開情報から新しい顧客シグナルを見つけることです。これにより、UXリサーチ、プロダクトマーケティング、ポジショニング、メッセージ設計、ICP整理、Voice of Customer の統合に幅広く使えます。

customer-researchを導入すべき人

この customer-research スキルは、プロダクト、UX、メッセージの意思決定をする前に、きちんと根拠を持ちたいチームに向いています。特に相性がよいのは、UXリサーチャー、創業者、PM、プロダクトマーケター、グロースチーム、そしてインタビュー、アンケート、サポートチケット、レビュー、コミュニティ投稿をもとに仕事をする支援会社や代理店です。

customer-researchが特にハマるユースケース

次のような場面では customer-research が有効です。

• インタビュー書き起こしやアンケート回答を分析したい
• 雑多な顧客の声をテーマや引用に整理したい
• jobs to be done、課題、トリガー、期待成果、購買時の言い回しを見つけたい
• まだ直接インタビューしていない段階で、初期のICPや市場理解を進めたい
• Reddit、G2、Capterra、フォーラム、ニッチコミュニティから繰り返し現れるパターンを掘り起こしたい

汎用プロンプトより優れている理由

最大の違いは、ワークフローに規律があることです。このスキルは、まず既存の product-marketing コンテキストを確認し、分析前に調査目的を明確にし、「既存アセットの分析」と「新しく調査を探しに行く」を分けたうえで、曖昧な要約ではなく具体的な項目を抽出するようエージェントを導きます。さらに同梱の evals を見れば、よい振る舞いの基準も分かるため、手探りになりにくいのも利点です。

導入前に押さえておきたいこと

これはデータ収集ツールでもスクレイピング用パッケージでもありません。価値があるのは、調査のフレーミング、ソース選定、抽出構造、そして統合の質です。自動パイプライン、ダッシュボード、統計的なサーベイ分析が欲しいなら、この customer-research ガイド単体では適していません。一方で、AIエージェントによるリサーチ用プロンプトの質を上げたい、出力の一貫性を高めたいという目的には有力な候補です。

customer-researchスキルの使い方

customer-researchのインストール手順

リポジトリから次のコマンドでインストールします。

npx skills add https://github.com/coreyhaines31/marketingskills --skill customer-research

その後、スキルフォルダを開いて次のファイルを確認してください。

• skills/customer-research/SKILL.md
• skills/customer-research/evals/evals.json
• skills/customer-research/references/source-guides.md

最初に1つだけ読むなら SKILL.md から始めるのがおすすめです。出力品質のイメージを早くつかみたいなら、次に evals/evals.json を読むと理解が早まります。

まず product context の有無を確認する

このスキルでは、質問を始める前に .agents/product-marketing-context.md または .claude/product-marketing-context.md を確認することが実務上かなり重要です。エージェントがあらかじめプロダクト、買い手、カテゴリ、制約条件を理解しているだけで、customer-research の出力品質は大きく変わります。

該当ファイルがあるなら、エージェントにその場所を伝えるか、同等の内容をプロンプトに貼り付けておきましょう。

2つの動作モードを明確にする

customer-research スキルは、次のどちらのモードで使うかを最初に明示すると最も安定します。

1. Analyze existing assets
   書き起こし、チケット、アンケート、レビュー、通話メモ、サポートログがある場合はこちらを使います。

2. Go find research
   直接の顧客データがなく、Reddit、レビューサイト、フォーラム、競合周辺の議論など公開情報から調査したい場合はこちらです。

最初にモードを指定しておくと、エージェントが「統合」と「ソース探索」を混同しにくくなります。

良い出力につながる入力

customer-research をうまく使うには、エージェントに次を渡してください。

• プロダクト、または扱う課題のカテゴリ
• ターゲットユーザー、または ICP
• 調査目的
• 利用可能なソース
• 欲しい成果物
• 時間、地域、市場、セグメントなどの制約

弱いプロンプトの例:

• 「顧客調査を手伝って」

より強いプロンプトの例:

• 「Use the customer-research skill in analyze-existing-assets mode. I have 18 interview transcripts from heads of support at B2B SaaS companies. Goal: identify recurring onboarding pain points, switching triggers, and language we can use on our website. Deliverable: prioritized themes, representative quotes, and a short implications section for UX Research and messaging.”

あいまいな依頼を完成度の高いプロンプトにする

この customer-research スキルで安定しやすいプロンプトの型は次のとおりです。

• context: どのプロダクトやオーディエンスを対象にしているか
• objective: 調査結果でどの意思決定を支えたいか
• mode: asset 分析か、調査探索か
• source list: どんなデータがあるか
• extraction fields: 何を抽出したいか
• output format: 最終的にどんな成果物が欲しいか

例:

“Use the customer-research skill for UX Research. Product: user onboarding software for mid-market SaaS teams. Audience: onboarding managers and customer success leaders. Mode: analyze existing assets. Sources: 12 transcripts, 40 churn survey responses, 85 support tickets. Extract: jobs to be done, pain points, trigger events, desired outcomes, alternatives considered, exact language, and high-signal quotes. Output: clustered themes with frequency and intensity, then 5 UX opportunities.”

customer-researchが得意な抽出項目

スキル本体と evals を見る限り、エージェントは次のような項目の抽出に向いています。

• jobs to be done
• pain points や friction
• trigger events
• desired outcomes
• 顧客が自然に使っている言葉
• 比較対象になっている代替案や競合
• テーマのクラスター
• 頻度と強度
• 根拠として使える money quotes

この構造が便利なのは、生の調査データから、UX改善、ポジショニング、メッセージ設計といった次の意思決定へつなげやすいからです。

UX Researchでcustomer-researchを使うコツ

UX Research で使うときは、「insights を出して」だけで済ませないほうがよいです。代わりに次のようなものを求めましょう。

• 繰り返し現れるタスクの分解
• 現在のワークフローにある friction points
• 混乱や遅延が起きる瞬間
• 満たされていない期待
• workaround 的な行動
• 機能選定の基準
• 根拠付きの opportunity areas

こうしておくと、customer-research がマーケティング寄りの要約に流れず、実際のユーザー行動に根ざした分析になりやすくなります。

公開情報リサーチをうまく使う方法

“go find research” モードでは、リポジトリ内の reference guide が Reddit、G2、Capterra、フォーラム、ニッチコミュニティなど実用的な調査先を示しています。強い進め方は「自社ブランド名を検索する」ことではなく、「ICP がその課題について話している場所を探す」ことです。

特に役立つソース種別:

• 課題起点の Reddit スレッド
• 競合比較の投稿
• レビューサイト上の不満点や評価ポイント
• ワークフローや workaround を語るフォーラム投稿
• 「X にはどのツールを使っていますか？」系の議論

初回の本番利用前に読むべきリポジトリ内ファイル

次の順に読むのがおすすめです。

1. ワークフローを理解するための SKILL.md
2. 想定されるプロンプトの振る舞いと出力形式をつかむための evals/evals.json
3. ソース別の調査テクニック、特に Reddit 調査を確認するための references/source-guides.md

特に evals は有用です。分析前にユーザーの目的を確認することや、頻度と強度の両方で見ることを勧めている点など、見落としやすい期待値が分かります。

実務でのおすすめワークフロー

実運用で customer-research を使うなら、次の流れが現実的です。

1. プロダクトと対象ユーザーの文脈を渡す
2. どの意思決定のための調査かを明示する
3. mode 1 か mode 2 を選ぶ
4. 手元の資料、または調べたいソースを渡す
5. 構造化された項目の抽出を依頼する
6. 最初の統合結果を見て、抜けているセグメントがないか確認する
7. 矛盾、例外ケース、強い引用に絞って2回目を回す
8. 最後に結果を、具体的な UX、プロダクト、または messaging の成果物に落とし込む

依頼しやすい実用的な出力形式

次のアクションに合う deliverable を選びましょう。

• 引用付きのテーマ表
• JTBD summary
• 根拠に基づく persona 用インプット
• セグメント比較
• 頻度と強度で順位付けした主要 pain points
• コミュニティやレビューサイトの source map
• プロダクトや UX Research 向けの implication memo

成果物を具体化すると、customer-research の初回利用でもすぐ使える出力になりやすくなります。

customer-researchスキル FAQ

customer-researchは初心者にも向いているか

はい。ただし、その調査がどんな意思決定を支えるべきかは自分で分かっている必要があります。通常のプロンプトより構造はしっかりしていますが、初心者でもプロダクトの文脈を渡し、有用な成果物を選ぶことは必要です。そこが曖昧だと、出力も広くぼやけたままになりがちです。

通常のプロンプトではなくcustomer-researchを使うべきタイミング

多数のアセットをまたいで、再現性のある抽出と統合をしたいときは customer-research を使うべきです。汎用プロンプトでも要約はできますが、このスキルのほうが目的確認、調査フレームの適用、クラスター化、引用抽出、根拠提示まで進みやすく、単なる観察メモで終わりにくいです。

これはマーケティングチーム専用か

いいえ。marketing skills リポジトリに入ってはいますが、customer-research は UX Research、プロダクトディスカバリー、サポート分析、初期の市場理解にも有効です。根底にある手法は、ユーザーの痛み、トリガー、期待成果、使う言葉を理解したいチーム全般に適合します。

customer-researchスキルの適用範囲と限界

一次調査の運用、参加者リクルーティング、分析計測の設計、厳密な定量手法の代替にはなりません。強みがあるのは、調査設計の枠組み作り、ソース探索、定性分析、そして統合です。

インタビュー書き起こしがなくてもcustomer-researchは使えるか

はい。そこはこのスキルの導入しやすさの1つです。オンライン上の公開ソースから調査を見つけるモードが明示的に用意されているため、初期フェーズのチームや、まだ顧客接点のない新規セグメントに入るチームでも使いやすくなっています。

customer-researchが向かないケース

次のような場合は見送ったほうがよいです。

• 統計的に妥当なアンケート分析が必要
• 調査手法に対する法務・コンプライアンス確認が必要
• 自動スクレイピングやデータパイプラインが必要
• 根拠収集なしで、その場限りのコピー案だけ欲しい

リポジトリにはソース別のガイダンスも含まれているか

はい。references/source-guides.md には、特に Reddit の探索方法、検索パターン、どの投稿が pain、代替案、switching trigger を明らかにしやすいかといった、具体的な公開情報リサーチの指針が含まれています。

customer-researchスキルを改善する方法

トピックではなく、意思決定を渡す

最も大きく品質を上げるのは、「何について調べるか」ではなく「何を決めるための調査か」を伝えることです。「顧客を調べて」は弱く、「次の UX sprint で優先すべき onboarding friction を見つけて」はかなり強い依頼です。意思決定が明確なほど、抽出も統合も良くなります。

ソースの意味づけをより明確にする

各ソースが何を表しているかをエージェントに伝えましょう。

• win interviews
• churn interviews
• 新規ユーザーからの support tickets
• SMB バイヤーによる G2 reviews
• 買い手ではなく実務担当者による Reddit posts

これにより、獲得、オンボーディング、継続、乗り換えのシグナルを混ぜずにクラスター化しやすくなります。

根拠付きでセグメントを分けさせる

customer-research のよくある失敗は、異なるユーザーを1つの混ざった persona にまとめてしまうことです。改善したいなら、次を明示的に求めてください。

• セグメント間の違い
• ソース間の矛盾
• 少数だが深刻な pain points
• 買い手、管理者、日常利用者の違い

テーマだけでなく頻度と強度を求める

テーマだけでは、意思決定にはやや弱いことが多いです。少なくとも次の区別をつけるよう依頼しましょう。

• よくあるが深刻度は低い問題
• 件数は少ないが強度の高い問題
• 意思決定を左右すべきでない単発の逸話

これは evals から見えてくる、実務上かなり重要なパターンの1つです。

正確な言い回しと money quotes を求める

単なる調査メモ以上に使える出力が欲しいなら、逐語的なフレーズや短い引用を求めてください。そうすることで、customer-research は UX Research の統合、社内共有、後続の messaging 作業にもより使いやすくなります。

公開情報リサーチは検索の種を改善する

mode 2 では、プロダクトカテゴリ名だけで検索を始めないことが重要です。検索語には次のようなものを混ぜてください。

• 課題そのものを表す文
• job titles
• competitor names
• “alternative”, “switch”, “recommend”, “frustrated with” といった表現

リポジトリの reference guide が示している通り、ブランド起点の検索より、課題起点の検索のほうが実際のワークフロー上の痛みを早く見つけやすいです。

初回出力のあとにもう一段深掘る

最初の出力は、最終回答ではなく全体マップとして扱うのが基本です。そのうえで、次のような追い質問をすると精度が上がります。

• “Which themes are strongest for new users versus experienced users?”
• “What contradictions appear between interviews and reviews?”
• “Pull 10 quotes that show urgency, not just dissatisfaction.”
• “Which findings are most actionable for UX Research in the onboarding flow?”

よくある失敗パターンを把握する

customer-research は次の条件だと性能が落ちやすいです。

• ソース品質が混在しているのにラベル付けされていない
• 1つのプロンプトで求める成果が多すぎる
• 対象セグメントが曖昧
• 公開ソースを、直接の顧客インタビューと同じ重みで扱っている
• 十分な生データがない段階で統合だけを求めている

再利用できるプロンプトテンプレートを作る

customer-research を繰り返し使うなら、標準テンプレートを作っておくと便利です。含める項目は次のとおりです。

• product summary
• ICP と non-ICP
• research question
• mode
• source inventory
• extraction fields
• output format
• constraints
• どの意思決定を支える結果か

こうしておくと、このスキルは単発のプロンプト補助ではなく、再現性のあるリサーチワークフローとして機能するようになります。