| 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完了時: レポートの確認。「特に深掘りしたいペインはありますか？」
