pain-harvester

name	pain-harvester
description	指定したドメイン・技術領域のユーザーが抱える「未解決の痛み」をインターネットから収集・分析するスキル。GitHub Issues、Stack Overflow、Reddit、フォーラム等から悲鳴を拾い集め、サービス/ツール開発やテックブログ執筆の優先順位判断に使える形で整理する。「ペインを探したい」「ユーザーの課題を調べたい」「ニーズ調査したい」「何を作るべきか知りたい」「ブログのネタを探したい」「エラーSEOのネタを探したい」「未解決の問題を調べたい」「困りごとを収集したい」で使う。

Pain Harvester

指定したドメインの「世界中の悲鳴を拾い集める」スキル。 ユーザーが何に困っているかを構造化して、何を作るか・何を書くかの判断材料にする。

ワークフロー概要

Step 1: ドメイン定義 → Step 2: 悲鳴収集 → Step 3: 正規化・クラスタリング → Step 4: スコアリング → Step 5: レポート出力

---

Step 1: ドメイン定義

ユーザーからドメイン/技術領域を受け取る。引数として渡されることもあれば、会話の中で明らかになることもある。

以下を明確にする:

• 対象ドメイン: 技術名、ライブラリ名、業界など（例: "Supabase RLS", "ERP XML連携", "Nix flakes"）
• 目的: サービス/ツール開発のネタ探し or テックブログ/SEOのネタ探し or 両方
• スコープ: 広く浅く探すか、特定の狭い領域を深掘りするか

目的が不明な場合は「両方」として進める。スコープが不明な場合はまず広く探し、後から絞る。

---

Step 2: 悲鳴収集

複数のデータソースから並列で検索する。Agentツールを使って並列にサブエージェントを起動し、各ソースを同時に調査する。

検索ソースと戦略

各サブエージェントに以下の検索を割り当てる:

サブエージェント1: GitHub Issues

WebSearchで以下を検索:

site:github.com/*/issues "{ドメイン}" is:open
"{ドメイン}" "bug" OR "error" OR "not working" OR "help wanted" site:github.com

狙い:

• 未解決（open）のissueで、リアクション（thumbs up）が多いもの
• 同じエラーが複数リポジトリで報告されているもの
• "help wanted" や "good first issue" ラベルがついた放置issue

サブエージェント2: Stack Overflow / Q&Aサイト

WebSearchで以下を検索:

site:stackoverflow.com "{ドメイン}" [unanswered] OR answers:0
site:stackoverflow.com "{ドメイン}" closed:no score:..3
"{ドメイン}" "no accepted answer" site:stackoverflow.com

狙い:

• 未回答または低評価回答しかない質問
• 回答はあるが「これでは解決しなかった」コメントがついている質問
• 質問自体のvoteが高い（＝多くの人が同じ問題を抱えている）

サブエージェント3: Reddit / フォーラム

WebSearchで以下を検索:

site:reddit.com "{ドメイン}" "frustrated" OR "struggling" OR "anyone else" OR "hate"
site:reddit.com "{ドメイン}" "workaround" OR "hack" OR "ugly fix"
"{ドメイン}" "pain point" OR "annoying" OR "wish" OR "missing feature"

狙い:

• 不満や苦労を表明している投稿
• ワークアラウンドを共有している投稿（＝公式の解決策がない）
• 機能リクエストや「こうだったらいいのに」系の投稿

サブエージェント4: ブログ / Dev.to / Zenn / フォーラム

WebSearchで以下を検索:

"{ドメイン}" "困った" OR "ハマった" OR "解決できない" site:zenn.dev OR site:qiita.com
"{ドメイン}" "pitfall" OR "gotcha" OR "caveat" site:dev.to
"{ドメイン}" error message -solved -fixed

狙い:

• 日本語圏の困りごと（Zenn, Qiita）
• 英語圏の落とし穴記事（Dev.to）
• エラーメッセージそのものが記事タイトルになっているもの（＝エラーSEOの種）

各サブエージェントへの共通指示

以下のドメインについて、ユーザーの「未解決の痛み」を収集してください。

ドメイン: {ドメイン名}

検索クエリ: {上記の検索クエリ}

各検索結果について、以下の情報を抽出してください:
1. 元の問題の要約（1-2文）
2. 元の投稿/issueのURL
3. どれくらい多くの人が同じ問題を抱えていそうか（リアクション数、類似issue数等）
4. 既存の解決策があるか（未解決/部分的に解決/ワークアラウンドのみ）
5. 元の投稿の日付（古すぎる場合は注記）

最低10件、できれば20件以上の痛みを収集してください。
類似の問題は別々にカウントしつつ、同じ問題だと注記してください。

---

Step 3: 正規化・クラスタリング

収集した生データを構造化する。

3-1: 一人称ペイン文への正規化

各ペインを以下の形式に変換する:

「{ドメイン}で〜しようとすると、〜できない/〜が起きる」

例:

• 「Supabase RLSでJOINを使ったポリシーを書くと、パフォーマンスが著しく劣化する」
• 「Nix flakesでプライベートリポジトリを参照しようとすると、認証が通らない」
• 「ERP XMLのエラーコード304が出ると、公式ドキュメントに記載がなく解決できない」

3-2: カテゴリ分類

各ペインを以下の5カテゴリに分類する:

カテゴリ	説明	例
process	手順・ワークフローの問題	設定が複雑すぎる、手順が多すぎる
error	エラー・バグ・不具合	特定条件でクラッシュする、エラーメッセージが不明瞭
missing	機能不足・未実装	この機能がない、この連携ができない
docs	ドキュメント不足・不正確	公式ドキュメントがない、情報が古い
performance	パフォーマンス・スケーラビリティ	遅い、大規模で使えない

3-3: 類似ペインのクラスタリング

同じ根本原因を持つペインをグループ化する。例:

• 「RLSポリシーが遅い」と「RLSでJOINすると遅い」→ 同一クラスタ「RLSパフォーマンス問題」
• クラスタ内のペイン数が多いほど、そのクラスタの重要度は高い

---

Step 4: スコアリング

各クラスタ（ペイングループ）に4軸でスコアをつける。

スコアリング基準

軸	説明	判定方法
頻度	何件の独立した報告があるか	収集データ内の件数
深刻度	どれくらい困っているか	投稿のトーン、「blocking」「critical」等のキーワード、リアクション数
未解決度	既存の解決策がどれだけ不十分か	未回答、ワークアラウンドのみ、公式対応なし等
機会スコア	ビジネス/コンテンツとしての機会の大きさ	以下のサブ指標の総合判断

機会スコアのサブ指標

• 課金意欲: B2B/業務利用の文脈か、趣味の文脈か
• 緊急性: 「今すぐ解決しないとまずい」度合い
• 検索可能性: エラーメッセージや具体的なキーワードがあるか（SEO狙い可能か）
• 解決難易度: 自分たちが解決策を提供できそうか

各軸を 1-5 で採点し、総合スコア = 頻度 + 深刻度 + 未解決度 + 機会スコア（4-20点）で算出する。

---

Step 5: レポート出力

markdownファイルとして出力する。出力先はユーザーに確認するが、デフォルトはカレントディレクトリに pain-report-{ドメイン}-{日付}.md として保存する。

出力フォーマット

# Pain Report: {ドメイン名}

> 調査日: {YYYY-MM-DD}
> ソース: GitHub Issues, Stack Overflow, Reddit, Zenn/Qiita/Dev.to

## サマリー

- 収集したペイン総数: {N}件
- クラスタ数: {M}グループ
- 最も深刻なペイン: {概要}
- 最も頻出するペイン: {概要}

---

## サービス/ツール開発向け: 何を作るべきか

上位のペインクラスタを機会スコア順に並べる。

| 順位 | ペイン         | カテゴリ | 頻度 | 深刻度 | 未解決度 | 機会 | 総合 | 出典数     |
| ---- | -------------- | -------- | ---- | ------ | -------- | ---- | ---- | ---------- |
| 1    | 「〜できない」 | error    | 5    | 5      | 4        | 5    | 19   | GH×3, SO×2 |
| 2    | ...            | ...      | ...  | ...    | ...      | ...  | ...  | ...        |

### 詳細: 上位ペインの深掘り

#### 1. {ペイン名}（総合スコア: {N}/20）

**問題の概要**:
{2-3文で問題を説明}

**代表的な声**:

- "{元の投稿からの引用}" — [出典](URL)
- "{元の投稿からの引用}" — [出典](URL)

**既存の解決策と限界**:
{現状のワークアラウンドとその不十分さ}

**機会の分析**:
{なぜこれがビジネス機会になるか。誰が金を払うか。}

---

## テックブログ/SEO向け: 何を書くべきか

エラーSEOやロングテール記事のネタとしてのペインリスト。

| 順位 | キーワード/ペイン            | 検索意図         | SERP状況       | 記事タイプ提案        |
| ---- | ---------------------------- | ---------------- | -------------- | --------------------- |
| 1    | "error code XXX"             | 即座に解決したい | フォーラムのみ | 解決記事 + ツール誘導 |
| 2    | "{ドメイン} {操作} できない" | やり方を知りたい | 古い記事のみ   | 最新版チュートリアル  |
| 3    | "{ドメイン} vs {代替}"       | 比較検討中       | アフィ記事のみ | 実体験ベース比較      |

### 検索意図の分類

各ネタに以下の検索意図タグをつける:

- **🔥 今すぐ解決**: エラーや障害に直面中。緊急性が高く、課金意欲も高い
- **📚 学びたい**: 概念や使い方を理解したい。PV狙い向き
- **🔄 比較検討**: ツール選定中。信頼性のある情報を求めている
- **💡 できるか知りたい**: 特定のユースケースの実現可能性を調べている

---

## 生データ: 収集した全ペイン一覧

{正規化済みの全ペインリストを、出典URLつきで列挙}

---

実行上の注意

検索クエリの調整

• ドメインが広い場合（例: "React"）は、サブドメインに分割して検索する（"React Server Components", "React hydration", etc.）
• 日本語ドメインの場合は日本語検索を優先し、英語は補助的に使う
• 検索結果が少ない場合は、関連キーワードや類義語で再検索する

コスト管理

• 1回の実行で最大4つのサブエージェントを並列起動する
• 各サブエージェントはWebSearch/WebFetchを使うが、深追いしすぎない（1ソースあたり最大10ページ閲覧）
• 網羅性より代表性を重視する。全ての痛みを拾う必要はなく、パターンが見えれば十分

鮮度の管理

• 2年以上前の投稿は「古い可能性あり」と注記する
• 最新バージョンで解決済みの問題は除外するか、「要確認」とマークする

ユーザーとの対話ポイント

• Step 1完了時: ドメイン定義の確認。「この方向で探しますか？」
• Step 2完了時: 生データの量と質の報告。「十分集まりました」or「もう少し深掘りしますか？」
• Step 5完了時: レポートの確認。「特に深掘りしたいペインはありますか？」