ユーザーフィードバック用プロンプト：大量のレビューを貼るだけで分類・集計・優先順位付けまで一括処理

ユーザーフィードバック用プロンプトが役立つのは、こんな場面です。アプリストアのレビュー、アンケートの自由回答、サポートチケット、コミュニティの書き込みが何百件もたまり、上司に「ユーザーが一番不満なのは何か」と聞かれても、チームは「たぶん価格」「たぶんクラッシュ」と印象でしか答えられない。以下のプロンプトは、生のフィードバックを分類表、高頻度の問題、対応の優先順位に一度で変換します。コピーして変数を差し替え、最後にフィードバックを貼るだけです。

AIに要約を書かせるのとは違います。要約は感想しか得られませんが、このプロンプトはすべての結論に件数と原文の引用を求めるため、結果をそのまま要求の優先順位付けや週次会議の資料に使えます。20件未満なら自分で読む方が速いです。数百件以上になり、チャネル別やバージョン別の比較が必要になったときに真価を発揮します。

プロンプト本文（コピーして使用）

あなたはユーザーリサーチを担当するプロダクトアナリストです。以下のユーザーフィードバックを、ルールどおりに処理してください。

1. 分類：［分類軸、デフォルト：機能の問題 / 操作性 / 価格・課金 / 性能・障害 / コンテンツ・サービス / その他］で1件ずつ分類し、主カテゴリは1つだけにしてください。2つにまたがる場合は感情の強い方に入れ、副カテゴリを備考に書いてください。
2. 集計と感情：カテゴリごとの件数と割合を数え、さらにポジティブ、中立、ネガティブを分けて数えてください。推測は禁止です。数えきれない場合は、まず全件の分類結果を列挙してから合計してください。
3. 高頻度の問題：各カテゴリで最も頻度の高い具体的な問題を3つ選び、それぞれに代表的なユーザーの原文を1件、書き換えずそのまま引用してください。
4. 優先順位：件数、ネガティブの強さ、支払いや継続への影響を総合して、各問題にP0、P1、P2を付け、理由を一文で説明してください。
5. 出力形式：最初に集計表（カテゴリ｜件数｜割合｜ネガティブ件数｜代表的な原文）、次に高頻度の問題リスト、最後に分類不能または情報不足の件数を別に示してください。製品改善の約束は書かず、フィードバックに存在しない原因を作らないでください。

私の製品は［製品名と一文の紹介］です。このバッチの出所は［チャネル、例：アプリストア / サポートチケット / アンケート］、期間は［開始日と終了日］です。

フィードバック原文（1行に1件）：
［フィードバック原文を1件ずつ貼り付けてください］

変数の差し替え方

結果を受け取ったら追加で聞く2つの質問

1つ目は分類ミスの確認です。「分類に最も自信がなかった10件を挙げ、原文、入れたカテゴリ、迷った理由を示してください。」分類の正確さが集計の信頼性を決めます。この10件を確認する方が、全件を読み直すよりずっと楽です。

2つ目は場面の深掘りです。「P0の問題について、使用場面をさらに分解してください。どの操作手順、どの端末やバージョンで起きましたか。フィードバックに書かれていない点は情報不足と明記し、推測しないでください。」これでリストが開発者の再現条件になり、「重いと言われている」で止まりません。

陥りやすい3つの落とし穴

1つ目、貼る前に個人情報を除去してください。原文には電話番号、注文番号、実名が混ざりがちです。「ユーザーA」のような仮名に置き換えてから貼り、社内ルールがある場合は承認済みのAIツールを使ってください。

2つ目、一度に数千件を貼らないでください。モデルが丁寧に読める量を超えると後半の分類が雑になり、件数がずれます。200件前後ずつに分けて実行し、最後に各バッチの集計表を貼り直して統合させ、数字を一つずつ照合してください。

3つ目、件数の多さは重要さとイコールではありません。価格への不満は声が大きくなりがちですが、離脱の原因は数件しかない決済失敗かもしれません。プロンプトが支払いへの影響で順位付けするのはそのためです。最終判断では集計表を解約・継続データと照らし合わせてください。

一度うまくいったら分類軸を固定し、次のバッチでも同じカテゴリを使ってください。2か月分の件数を並べれば、改善している問題と悪化している問題が一目で分かります。