Redditの投稿から顧客の声を生かすメッセージ集を作る

1. 作業を1つ選び、範囲を明確にする

表現を集める前に、理解したい作業を書き出します。製品についての漠然とした感想ではなく、具体的な作業と状況を選びます。

ここで使う学習用の題材では、対象の作業はレポートのエクスポートです。収集範囲は、繰り返し行う設定も含め、レポートの列に関する作業に絞ります。こうして範囲を決めると、エクスポートの速さに関する表現と、レイアウトを作り直すことに関する表現を分けて扱えます。

次の3点を記録します。

1. 理解したい作業。
2. その表現が意味を持つ状況。
3. このメッセージ集の対象にしない表現の種類。

例えば、レポートの列を準備する作業についての記述を含められます。関係のない請求の話題は、収集対象から外せます。これは調査の進め方の提案であり、Redditユーザーが実際に何を話しているかについての調査結果ではありません。

提供された公開質問には、「顧客調査にRedditを実際にどう使っていますか」とあります。この問いには、実践的な方法が求められています。ただし、証拠は保存された検索結果のタイトルと抜粋です。この資料の作成にあたり、ページ全体は確認していません。この記録から分かるのは、関連する質問があったことです。このガイドとまったく同じ問いが、どの程度よく尋ねられているかは分かりません。顧客調査についての公開質問：2026-08-11取得、公開日不明、タイトルと抜粋のみ。

目的は、後でメッセージを検証するために役立つ言葉を集めることに絞ります。このメッセージ集を、全体的な感情のスコア、機能の順位、事業アイデアが売れる証拠として扱わないでください。

2. 出典と自分のメモを分けて記録する

見直しができるスプレッドシートなどの表を使います。選んだ記述ごとに「文脈カード」を作ります。これは、引用、出典、自分のメモをまとめた1件の記録です。

1件の投稿に、役立つ記述が複数含まれることがあります。1件の投稿から複数のカードを作る場合は、すべてのカードに同じ出典識別情報を残します。カードが増えても、出典の投稿数や人数が増えたことにはなりません。

次の項目を保存します。一部の項目は、収集結果から取得できます。調査メモは自分で追加します。

メッセージ仮説とは、検証したい文案です。出典からの引用でも、確認済みの製品についての主張でもありません。

出典の文章は変更せずに残します。記述を短くする場合は、その根拠となる記述全体を横に保存します。これにより、短くした引用でも同じ意味が保たれているかを、確認者が確かめられます。

欠けている値は不明として扱います。頻度が書かれていないことは、「一度もない」という意味ではありません。所要時間が書かれていないことは、0分という意味ではありません。役割が書かれていなくても、その人に購入の決定権がないとは言えません。公開日が不明でも、確認した日を公開日にはできません。

3. 表現を選ぶ前に出典を読む

関連する公開の出典をそれぞれ開き、記述を理解できるだけの文脈を読みます。検索結果の抜粋は、候補を探すのに役立ちます。ただし、カードとして採用するには文章が足りない場合があります。

次の順に進めます。

1. URLと出典識別情報が、読んでいる投稿と一致することを確認します。
2. タイトルと、本文の関連する記述を読みます。
3. その記述にある言葉が、誰の言葉なのかを確認します。
4. その言葉が示す作業、条件、期間を確認します。
5. 意味を保てる範囲で、最も短い記述を選びます。
6. 前後の文脈と、未解決の疑問を保存します。

投稿内に引用された他人の言葉を、投稿者自身の言葉として扱わないでください。質問も慎重に扱う必要があります。エクスポートができるか尋ねている人が、エクスポートの失敗を報告しているとは限りません。

主張の範囲を限定する言葉を残します。「私たちのチームでは」は、体験談の適用範囲を限定します。「毎週」は、繰り返される状況を示します。「エクスポートできる」は、その体験談ではエクスポートが可能であることを示します。これらの言葉を削ると、意味が変わることがあります。

異なる投稿の一部を組み合わせて、1つの引用にしないでください。複数の記述を文章作成の参考にする場合は、カードを分けて残します。それらのつながりは、解釈の欄で説明します。

文脈から作業や発言者を特定できない場合は、カードを保留にします。想定する顧客像に合わせて、欠けた情報を補わないでください。

4. 必要に応じてActorで公開投稿を収集する

Actorは、ホスティング環境で動くデータ収集プログラムです。Reddit Search Scraper Actorには、公開投稿の収集に適した入力項目と出力項目が文書で示されています。表現の選定、文脈の読み取り、メッセージ集の作成は、自分で行います。

少量を収集するための入力例は、次のとおりです。

{"maxResults":3,"query":"export report columns","sort":"relevance","time":"all"}

これは提案する入力例です。保存済みの設定をコピーしたものでも、実行済みの検索でもありません。静的なスキーマチェックには合格しています。スキーマとは、使用できる項目名、型、値を定めたものです。静的チェックでは、収集プログラムを実行せずに、入力がその規則に合うかを確認します。

使う前に、次を確認します。

1. `query`を、選んだ作業に関する言葉に置き換えます。
2. 最初の少量の確認では、`maxResults`を3のままにします。
3. `sort`を確認します。この例では`relevance`を指定しています。
4. `time`を確認します。この例では`all`を指定しています。
5. 実際に使う入力を、そのまま出典の記録と一緒に保存します。

確認したスキーマでは、`maxResults`に1から10000までの整数を指定できます。`sort`に指定できる値は、`relevance`、`hot`、`top`、`new`、`comments`です。`time`に指定できる値は、`all`、`hour`、`day`、`week`、`month`、`year`です。

上限を3に指定しても、利用できる投稿が3件返るとは限りません。期間を指定しても、その期間を完全に網羅できるとは限りません。この資料の作成にあたり、Actorは実行していません。この確認では、現時点でデータを取得できることや、収集処理が正常に動くことは証明されていません。公開のデフォルトビルド2.0.6：2026-10-25確認、スキーマの証拠のみ、実行なし。

文書に示された出力項目には、上の表にある出典と日時の項目が含まれます。一部の値は欠けている場合があります。文章と併せて、`status`と`unavailableFields`を確認してください。欠けた文脈を推測で補わないでください。

Reddit Post Customer Language Research Taskも、作業を始める際の選択肢です。Taskとは、保存されたActorの入力設定です。2026-10-25に、その公開ページと、対象が該当するTaskであることを確認しました。現在保存されている入力と、実行時の動作は未確認です。使う前に設定を確認してください。ここに示した入力例が保存されているとは限りません。

ここで収集するのは公開投稿です。所有者だけがアクセスできるサポート記録、アカウントデータ、非公開メッセージは、必要な権限のある別の手順で扱います。それらをRedditの出力として記録しないでください。また、発言が公開されていても、その人を推薦者として紹介する許可があることにはなりません。

5. 状況、解釈、文案を分ける

出典を保存したら、別の欄に自分のメモを追加します。

「状況」は、その言葉がどのようなときに当てはまるかを説明します。「きっかけ」は、何が作業の開始につながるかを説明します。「望む結果」は、発言者が何を達成したいかを示します。これらの項目は、それぞれ独立して不明になる場合があります。

毎週行う作業だと分かっても、今回の困難が生じた原因は分かりません。設定の繰り返しへの不満があっても、特定の機能を求めているとは限りません。表を埋めるためだけに、すべての項目を記入しないでください。

解釈は分かりやすい言葉で書きます。その根拠となる言葉を示してください。望む結果を推測した場合は、本人の明言ではなく、自分の解釈であると記します。

次に、自分の言葉でメッセージ仮説を書きます。次の3つを区別できるようにします。

1. 出典：その人が書いた内容。
2. 解釈：その記述が何を意味すると自分が考えるか。
3. メッセージ仮説：今後使うために提案する文案。

自分のメッセージに近づけるために、引用を書き換えないでください。自分でまとめた文章を、引用符で囲まないでください。

メッセージを公開する文章に使う前に、その訴求内容を製品が実現できるか確認します。困難についての記述があっても、解決策が有効であることは確認できません。製品が対応できるか不明な間も、メッセージ案をメッセージ集に残しておくことはできます。

6. 作業に必要のない個人情報を削除する

作業と状況は残します。表現を説明するために必要のない個人情報は削除します。

レポートの列についての表現を残すために、作業用のメッセージ集へ公開ユーザー名を記録する必要はありません。出典をたどれるように、カードキー、出典ID、URLを使います。連絡先を追加したり、無関係な情報から勤務先を推測したりしないでください。

選んだ記述に個人情報が含まれる場合は、可能であれば、より短い箇所を原文どおりに選びます。それによって重要な意味が失われる場合は、カードに取り扱い制限を付けるか、共有用の版から外します。説明せずに文章を変更し、それを正確な引用と呼び続けないでください。

出典にアクセスできることと、その内容を公に紹介することは分けて考えます。出典をたどれる社内用カードでも、広告や公開の顧客事例にそのまま使えるとは限りません。出典メモにも、この違いを記します。

7. 作成例：2枚の文脈カードと1つのメッセージ案

独自に作成した架空の例です。この例に含まれる投稿とカードは、すべて創作です。Actorの実行結果、顧客の成果、実際に確認された企業の調査結果ではありません。2枚のカードを使うこの例は、入力例で提案した上限の3とは別のものです。

最初の架空の投稿には、次のように書かれています。

文全体を保存します。「エクスポートできます」は重要です。「毎週」も重要です。この記述を「エクスポートできない」と短くすると、意味の一部が逆になります。

メッセージ仮説は、書き手が考えた案です。架空の発言者は、その表現を使っていません。また、そのような機能が存在することも示していません。

次に、エクスポートの速さを評価する2件目の架空の投稿を追加します。独自の出典と状況を持つカードBとして保存します。これを使ってカードAの内容を打ち消さないでください。エクスポートの速さと、繰り返される列の設定は、作業の異なる部分に関する話です。

カードが2枚あっても、確認済みの購入者が2人いることにはなりません。多数派であることや、市場での割合も分かりません。カードAの所要時間は不明であり、ゼロではありません。カードBの評価が良くても、その時間が分かるわけではありません。

より大きなメッセージ集では、件数を報告する前に単位を確認してください。カードはカードとして、投稿は投稿として数えます。1つの出典から複数の記述を選ぶ場合があります。

8. 各カードを確認し、証拠の不足に対応する

引用を制作指示書に使う前に、カード全体を確認します。

1. 引用の出典となる記述とURLをたどります。
2. 引用を出典と一語ずつ照合します。
3. 否定表現、条件、期間、単位を確認します。
4. 誰の言葉で、どの作業に関するものかを確認します。
5. 推測した詳細には、解釈であると記します。
6. メッセージ仮説は引用欄の外に記録します。
7. 提案する訴求内容を、製品が実現できるか確認します。
8. 欠けている値や、未解決の文脈上の不明点が分かるように残します。

確認で問題が見つかったカードには、次の対応を取ります。

以前の出典を保存していないのに、それを復元できると主張しないでください。出典リンクが切れていると、今確認できる範囲が狭まる場合があります。その限界を記録します。

文脈が足りないカードは、その作業に困難がないという証拠ではありません。まだ解釈できない記録です。同様に、少量を収集して使える表現が見つからなくても、顧客に有用な発言がないとは言えません。まず、問題が検索語、出典の取得状況、選定範囲のどこにあるかを確認します。