CS チームと Product チームがすでに別々に収集している3つのフィードバックストリーム —Canny のフィーチャーリクエスト、Sprig のプロダクト内サーベイ回答、サポートチケットのエクスポート— を、優先順位付けされた1つの Voice of the Customer レポートに統合する Claude Skill です。output は、各テーマが重み付けされた需要スコア、それを求めているセグメント、出典付きの代表的な verbatim、そして1行のプロダクトインプリケーションを持つ、ランク付けされたテーマリストです。3人が3つのツールを読んで顧客が「本当に」何を求めているか議論する代わりに、CS Ops は1つのコマンドを実行し、product review が行動に移せる統合された doc を得ます。artifact の bundle には SKILL.md、チームが一度だけ適応させる3つのリファレンスファイル、そして output の例が含まれます。
使うべきとき
あなたは定期的な VoC サマリー —月次の product council、四半期のロードマップ input、または年次計画の artifact— を作成する必要がある CS Ops リードまたは Product Manager で、生のシグナルは Canny、Sprig、サポートツールのチケットエクスポートのうち少なくとも2つに存在しています。この Skill は、フィードバックの量が人間がすべてを読める地点を超えている（1サイクルあたりおよそ150件以上）が、チームはまだブラックボックスのスコアではなく特定の verbatim へのトレーサビリティを求めている、というケースのために作られています。
3つのソースがそれぞれ安定した schema でエクスポートできるとき —投票数と board 付きの Canny の posts、サーベイの質問とセグメント属性付きの Sprig 回答、カテゴリとアカウント tier 付きのサポートチケット— に最もよく機能します。この Skill は3つすべてにわたってクラスタリングし、5通りに言い換えられた同じ要望を重複排除し、あなたがコントロールする数式で各テーマを重み付けします。各 item にアカウント価値またはセグメントのフィールドを付加できるとき、最も擁護可能な output を生成します。なぜならそれが、レポートが生の言及数ではなく revenue で重み付けされた需要でランク付けすることを可能にするものだからです。
使うべきでないとき
この Skill をロードマップ決定の唯一の input として使わないでください。これは表明された需要を統合します。支払い意欲、技術コスト、戦略適合性は測定しません。テーマがランクリストの先頭に来るということは、多くの価値あるアカウントがそれを大声で求めたことを意味し、それが作るべき正しいものであることを意味しません。プロダクトインプリケーションの行は議論のための呼び水であり、判決ではありません。
1サイクルでおよそ50件未満には向けないでください。それ以下では、PM はリファレンスファイルを適応させるのにかかる時間より短い時間で各 item を直接読めますし、クラスタリングが overfitting します —実際には1つの要望の2通りの言い換えにすぎない、2件ずつの「テーマ」が得られてしまいます。
ソースにセグメントやアカウント価値の属性がまったくない場合は使わないでください。それがないと、各テーマは生の数で重み付けされ、最も声の大きいセグメント（通常は Canny に posts を投稿する低 ARR の self-serve ユーザー）に過剰に index し、チケットを起票する代わりに CSM にメールするエンタープライズアカウントを過小カウントします。カウントのみの VoC レポートはロードマップの優先順位付けを積極的に誤導します。
verbatim を外部共有用に匿名化されたものとして扱わないでください。この Skill は、レポートが誰が何を言ったかを漏洩しうるほど十分なソース文脈（アカウント tier、ときには引用フレーズ）を保持します。別の編集パスを実行しない限り、output は社内にとどめてください。
セットアップ
初回はおよそ45〜90分で、そのほとんどは3つのリファレンスファイルを自分のエクスポート schema と重み付けポリシーに適応させることに費やされます。
- Skill をインストールする。
apps/web/public/artifacts/voice-of-customer-synthesis-skill/の bundle を~/.claude/skills/voc-synthesis/に配置します。この Skill は1つのエントリーコマンドsynthesize_voc(period, sources)と、各ソースの正規化、クラスタリング、Claude の2パスパイプラインのための内部 helper を定義します。 - 3つのソースをエクスポートする。 Canny API（または CSV エクスポート）経由でその期間の Canny posts を
title、details、score（投票数）、board、リンクされた会社フィールドとともに取得します。Sprig 回答をサーベイの質問、フリーテキスト回答、少なくとも1つのセグメント属性とともに取得します。サポートチケットのエクスポート（Zendesk、Freshdesk、Front、Help Scout —CSV をエクスポートできる任意のツール）をsubject、description、category、account_tierとともに取得します。3つすべてを CSV または JSON としてinputs/に配置します。 - schema map を適応させる。
references/1-source-schema-map.mdを開き、各ソースの実際のカラム名を Skill の内部フィールド（text、weight_signal、segment、source_label）にマッピングします。これは初回実行で最も頻繁に壊れるファイルです。なぜならチームごとに Canny の board 名や Sprig のサーベイ ID が異なるからです。この Skill は、必須フィールドが未マッピングの場合、部分的なデータで黙ってスコアリングするのではなく実行を拒否します。 - 重み付けポリシーを設定する。
references/2-weighting-policy.mdを開き、数式を設定します。default はtheme_score = items にわたる (segment_weight * recency_factor) の合計で、segment_weightはエンタープライズに3、mid-market に2、self-serve に1、recency_factorは0日目の1.0から期間境界の0.5へ線形に減衰します。これらをあなた自身のバンドに置き換えてください。ポリシーをハードコードではなくファイルに持つことが、product council が重み付けに異議を唱え、あなたがコードを編集するのではなく2分で再実行できることを可能にします。 - output テンプレートを適応させる。
references/3-report-template.mdを開き、セクションの順序と verbatim の引用フォーマットを、あなたの product review が期待するものに合わせます。次にsynthesize_voc(period="2026-Q2", sources=["canny", "sprig", "support"])を実行します。この Skill は1つの Markdown レポートと、懐疑的な人がクラスタリングを監査できるよう、割り当てられたテーマ付きの全 item の CSV を書き出します。
この Skill が実際に行うこと
この Skill は2パスで実行され、その分割は意図的です。パス1は抽出とクラスタリング、パス2はランク付けと説明です。両方を1パスで行うと、モデルが最後に合理化したものへドリフトするクラスタリングを生成します。なぜなら、テーマが何であるかを決定すると同時にその優先順位を主張しているからです —優先順位の推論がクラスタリングを汚染します。
パス1は schema map を通じて3つのソースを共通のレコード形状に正規化し、次に Claude に item を候補テーマにクラスタリングするよう求めます。prompt はモデルに、各 item を正確に1つのテーマか明示的な unclustered バケットに割り当て、各割り当てを正当化するテキストのスパンを引用することを強制します。unclustered バケットは失敗ではなくガードです。健全な実行は5〜15パーセントを未クラスタのまま残し（真に一回限りの要望）、30パーセントを超える unclustered 率は、ソースがこのサイクルで統合するには異質すぎるというシグナルで、この Skill は統合を強制するのではなくそれを表面化させます。
パス間で、スコアリングは Claude ではなく決定論的な Python です。references/2-weighting-policy.md の重み付け数式はクラスタリングされた item に対してコードで実行されるため、同じ input は常に同じランキングを生成し、レビュアーは任意のテーマのスコアを手で再計算できます。Claude にテーマを「重み付け」させると、ランキングは監査不可能で再現不可能になります。モデルはクラスタリングして説明し、コードがスコアを付けます。
パス2はランク付けされたテーマを取り、各テーマについて2〜3件の代表的な verbatim を選択し（可能なら1ソースにつき1件、テーマが Canny の声の大きい少数派だけで支えられないように）、1行のプロダクトインプリケーションを書き、スコアを駆動するセグメントを名指しします。output はランク付けされたレポートと item ごとの CSV です。レポートはトップテーマで始まり、CSV は監査証跡です。
コストの現実
Claude Sonnet での完全な実行は、item 数とテキストの長さに応じておよそ30,000〜90,000 input トークン、5,000〜10,000 output トークンのコストがかかります —VoC サイクルあたり12〜30セントと考えてください。支配的な input 変数はサポートチケットの説明の長さです。schema map で各 item のテキストを600文字に cap すると、400 item のサイクルをクラスタリングシグナルを失わずに低い端の近くに保てます。実時間は2〜5分で、エクスポートとスコアリングはローカルなので、そのほぼすべてが2つの Claude パスです。
代替案 —PM が毎サイクル集中した1日を費やして300件の item を手で読んでタグ付けする— と比べると、この Skill はそれをおよそ90分にします（初回実行後は何も適応させず、その後レポートをレビューして CSV を抜き取り監査）。VoC を月次で実行するチームにとって、それは月あたりおよそ1日分の PM 時間の回収であり、トレードはトークンで月あたり1ドルを大きく下回り、十分に予算内です。
成功の姿
3つの数字を追跡してください。第1に、クラスタリングの一致: item ごとの CSV から30件をサンプリングし、PM に各 item が正しいテーマにあるか判断させます。2サイクル目までに85パーセント以上を目指してください。70パーセントを下回るのは、schema map がモデルにノイズの多いテキスト（通常はチケット本文の未除去 HTML や署名）を供給していることを意味します。第2に、ロードマップのトレーサビリティ: 次の2四半期のロードマップ決定のうち、VoC テーマを名指しで引用するものの割合。ゼロのままなら、レポートは作られているが消費されておらず、フォーマットを product review の実際の儀式に合わせる必要があります。第3に、サイクルごとの unclustered 率 —5〜15パーセントのバンドで安定して推移するのが健全です。突然のスパイクは、ソース schema が upstream で変わったことを意味します。
代替案との比較
Productboard または Canny のネイティブロードマップビューとの比較。 Productboard と Canny はどちらも自社の壁の中でフィードバックを集約し、投票やインサイトでランク付けします。シグナルがすべてすでにそのうちの1つに存在するなら、ネイティブビューのほうが手間が少ないです。ギャップ: どちらも Canny と Sprig とサポートチケットの3つすべてにわたって統合せず、両方とも、あなたがコントロールする revenue で重み付けされた数式ではなく自社の engagement シグナルでランク付けします。1つのツールがシグナルの80パーセントを保持するときはネイティブビューを使い、シグナルが本当に3つのシステムにわたって分割されていてセグメント重み付けが必要なときはこの Skill を使ってください。
スプレッドシートでの手動タグ付けパスとの比較。 PM が各 item を読んでタグ付けすると、人間がモデルの見逃すニュアンスを捉えるため、最も忠実度の高いクラスタリングを生成します。トレードはサイクルあたりの集中した1日と、数百 item を超えてスケールせず PM の転職を生き延びないという事実です。最初の1〜2サイクルは手動タグ付けを使って重み付けバンドを現実に対してキャリブレーションし、その後は Skill に定期的な量を担わせ、人間の読みを unclustered バケットに残してください。
汎用 LLM へのダンプ（「このフィードバックを要約して」）との比較。 3つのエクスポートをチャットウィンドウに貼り付けて要約を求めるのは始めるのが速く、スコアもソースのトレーサビリティもなく、検査できない黙った重複排除を伴う、自信ありげで監査不可能な塊を生成します。決定論的スコアリングを伴う2パス分割は、まさに output をロードマップの議論で擁護可能にするために存在し、汎用ダンプは決してそうではありません。
注意点
- 最も声の大きいセグメントのバイアス。 self-serve ユーザーは Canny に posts を投稿し、エンタープライズの champion は CSM にメールします。カウントベースのビューは、たまたま公開チャネルを使うセグメントを体系的に過剰に重み付けします。ガード: スコアリングは
references/2-weighting-policy.mdのsegment_weightで各 item を乗算するため、単一のエンタープライズチケットが複数の self-serve 投票を上回りうる —そしてレポートはテーマごとに駆動セグメントを名指しするので、レビュアーは裸の数を信頼するのではなく重み付けが機能しているのを見られます。 - ソースにわたるクラスタリングのハルシネーション。 3つの語彙を統合するよう求められると、モデルは実際の区別をならしてしまうテーマを発明しうる（「エクスポートが遅い」と「エクスポートにカラムが欠けている」を1つとして扱う）。ガード: パス1は各割り当ての正当化スパンを引用し item ごとの CSV を書き出すので、レビュアーは監査証跡で悪い統合を見つけられます。
unclusteredバケットは、無理な引き伸ばしを強制する代わりにモデルに明示的な逃げ道を与えます。 - 古いまたはずれたソース schema。 名前を変えられた Canny の board や新しい Sprig のサーベイ ID は、エクスポートが含むものを黙って変え、レポートは部分的なデータに対してスコアリングします。ガード: schema map のバリデーションは未マッピングの必須フィールドに対して実行を拒否し、どのソースとカラムが失敗したかを報告します。ロードされたものに対してスコアリングはしません。
- 需要を優先順位として読むこと。 ランクリストはセグメント価値で重み付けされた表明需要を測定します —支払い意欲、build コスト、戦略適合性ではありません。ガード: プロダクトインプリケーションの行は推奨ではなくレビューのための質問として表現され、レポートはそれが複数の中の1つの input であることを記す常設ヘッダーを持つので、読者は rank を build 決定と取り違えられません。
- verbatim の漏洩。 保持されたソース文脈は、レポートが外部共有された場合に誰が何を言ったかを特定しうる。ガード: レポートはテンプレートヘッダーで社内限定とマークされ、bundle は建物を出る任意のバージョンについてアカウント識別子と引用フレーズを除去する
redactフラグを同梱します。
スタック
- Canny —投票数と board 付きのフィーチャーリクエスト posts（Canny API または CSV エクスポート）
- Sprig —セグメント属性付きのプロダクト内サーベイのフリーテキスト回答
- サポートツール —チケットエクスポート（Zendesk、Freshdesk、Front、または Help Scout）、カテゴリとアカウント tier 付き
- Claude —2パスパイプライン: 抽出とクラスタリング、その後ランク付けと説明（コストのため Sonnet 推奨）
- ローカルスコアリング —決定論的 Python がパス間で重み付けポリシーを適用し、ランキングを再現可能で監査可能にします