リサーチ・調査のプロンプト30選

競合調査・市場整理・論点抽出・一次情報の確認など、調べる仕事で使える指示文。ChatGPT・Claude・Perplexity にそのまま貼り付けて使えます。全文公開・登録不要で、 コピーボタンから1クリックで持ち出せます。

[競合プロダクト名]の公式サイトとドキュメントを読み、以下の形式で整理してください：
・3 行の要約
・主な機能 5 つ（重要度順）
・料金プランの要点
・強みと弱み各 3 つ
・自社との差別化ポイント候補 3 つ

出力は Markdown 形式で。

[サービス／組織]の SWOT を整理してください。
・各セル 3〜5 項目
・社内データの根拠を [DATA: …] で示す
・SO/WO/ST/WT のクロス戦略を 1 つずつ
・更新頻度の提案

[アプリストア / G2 等のレビュー本文を貼付]について：
・テーマ別カウント（不満／称賛／要望）
・代表的な引用
・スコアトレンド
・優先対応 3 件
・ポジティブを強化する案

[フィードバックリスト]について：
・タイプ（バグ / 要望 / 質問 / 称賛）
・対象機能
・緊急度
・ユーザー数 vs 影響度
・対応 / 棚上げの仮判断
重複を統合した一覧を作成。

[ビジネスゴール]を頂点に、KPI ツリーを 3 階層で構成してください。
・各 KPI の定義
・計測元データ
・改善のレバー（施策候補）
・他 KPI とのトレードオフ
ツリーは Mermaid で出力。

[属性・行動データ]からユーザーセグメントを 4〜6 個抽出してください：
・命名（覚えやすく）
・人口比率
・主要 KPI の差
・推奨アプローチ
・避けるべき施策
セグメント間の関係性も図示。

[市場ターゲット]の市場規模を以下の手順で推定してください：
1. 出発点（人口 / 企業数 など）
2. 絞り込み条件
3. 単価仮定
4. 計算
5. 感度分析（±30%）
最後に「これだけで意思決定しないための注意」も。

<context>
[製品概要 / 既存ユーザーから観測される代表的な使い方 3 種 / 売上の主要セグメント]
</context>

<task>
属性中心ではなく行動・JTBD ベースのペルソナを 3 体作る。年代や職種に依存した設計を避ける。
</task>

<output_format>
各ペルソナについて：
- 名前（記号でよい）と最小限の属性（職種程度）
- JTBD（解決したいジョブ・3 階層：機能 / 感情 / 社会）
- 典型的な 1 日の動線（製品との接点）
- 購入／継続の意思決定基準
- 避けたい痛み（製品が応えるべきもの）

ステレオタイプ（性別・年齢に紐づく決めつけ）は禁止。
</output_format>

[ユーザー行動の説明]から、ジョブ理論で構造化してください：
・状況
・動機（ファンクショナル / 感情 / 社会）
・期待される結果
・現状の代替手段
・乗り換えの障壁
インタビュー追質問も 5 つ。

[候補機能リスト]を以下の軸で評価してください：
・価値（顧客価値）／工数（実装コスト）／戦略整合
・各 1〜5 で採点
・優先度（高／中／低）
・依存関係
・3 ヶ月で実施するもの／後回し
スプレッドシート形式で出力。

[ユーザー動線]に対するファネル分析の設計：
・ステップ定義（5〜7 段階）
・各ステップの計測元
・離脱率の見方
・想定ボトルネックの仮説 3 つ
・改善 A/B テストの優先度

[解約アンケート自由記述リスト]をカテゴリ化してください：
・カテゴリ 5〜8 個
・件数と代表コメント
・各カテゴリへの典型的施策
・「価格」と「価値」を混同しない
誤分類しやすい例も併記。

[サービス・ターゲット]の NPS 計測を設計：
・タイミング
・配信チャネル
・質問順序（点数 → 自由記述）
・促進者／批判者への分岐
・分析時の注意（n 数 / 文化的バイアス）

[研究目的・対象]に対する 60 分インタビューの質問リストを作成：
・アイスブレイク 3
・現在の行動 6
・課題 6
・代替手段 3
・閉じ
・誘導質問を避ける言い回し
追質問の例も併記。

[調査目的]のアンケート 12 問を設計：
・誘導／二重否定／二重質問を避ける
・尺度の一貫性
・分岐
・自由記述の使いどころ
・想定クロス集計
タイトルと依頼文も。

[施策アイデア]を仮説マップに展開：
・前提（成立しないと崩れる）
・期待効果
・リスク
・最小検証方法（実験・インタビュー）
・成功 / 失敗の判断基準
スプレッドシート形式。

[競合 3 社の公開価格]から戦略を読み解いてください：
・課金軸（ユーザー数 / 利用量 / 機能）
・無料枠の太さ
・年契約割引
・カスタム見積りの境界
・ターゲット顧客の推定

[プロダクト名]のユーザーストーリーマップを作成：
・バックボーン（活動の時系列）
・ユーザータスク
・ストーリー（粒度小）
・MVP ライン
・後続リリースの分割
ファシリテートのコツも 3 つ。

[候補施策]を RICE で評価：
・Reach / Impact / Confidence / Effort を数値化
・スコア順
・Confidence の根拠を明記
・Effort 過小評価への警告
・四半期割当て案

[アンケート結果サマリ]の可視化を 5 案提案：
・チャート種類と理由
・伝えたい主張
・見落としやすい誤読
・補足テーブル
・ストーリー順序
ステークホルダー（経営／現場）別の最適案も。

[全機能の利用率データ]を踏まえて：
・コア / 一般 / レア / 死蔵 の 4 分類
・機能保持コスト（保守 / サポート / UI 占有）
・廃止候補の判断基準
・移行コスト（代替手段 / 影響ユーザー）
・統合 / リファクタの選択肢
発信文（廃止告知）のテンプレも併記。

[競合の新製品ローンチ概要]を 24 時間以内に評価：
・脅威の規模（ターゲット重複 / 価格優位 / マーケ規模）
・自社の即時対応の必要性
・短期（1 週）／中期（1Q）／長期（1 年）の打ち手
・社内コミュニケーション原稿
・反応しすぎ／無視しすぎの両極リスク

<context>
[サービス特性（B2B/B2C・利用頻度）／ユーザー定義／既存ファネル KPI／既知の解約理由]
</context>

<task>
リテンション分析の方針と最初の 30 日アクションを返す。「とりあえず週次 MAU グラフ」では終わらせない。
</task>

<output_format>
1. コホート定義（新規登録週 / 課金開始週 / 機能利用開始週）
2. 分析期間（短期 7 日 / 中期 4 週 / 長期 12 ヶ月のどれを主軸にするか）
3. 「アクティブ」の定義（業界ベンチと自社特性で乖離していないか）
4. 追跡 KPI（D1 / D7 / D30 / Smile Curve / NRR）
5. 改善の起点になる要素分解
   - オンボーディング: 最初の 24 時間のアクション
   - 習慣形成: 価値発揮アクション（Aha モーメント）
   - 価値: コア機能の利用頻度
6. 最初の 30 日のアクション（量的調査 / 質的調査）
7. ベンチマークとの比較指標
</output_format>

<example>
<input>
B2B プロジェクト管理 SaaS、課金 5,000 アカウント、月次解約 4%。MAU は伸びているが ARR 鈍化。
</input>
<output>
1. コホート: 課金開始週ベース（無料利用は別軸）
2. 期間: 中期 4 週で Smile を見る
3. アクティブ: 「週 3 回以上ログイン + 1 件以上タスク完了」（業界ベンチ「週 1」より厳しめだが本サービスは協業ツールなので妥当）
4. KPI: D7 60%, D30 45%, NRR 110% を目標
5. 分解:
   - オンボード: 最初 24h で「3 名以上招待」「初タスク作成」した群が D30 を 30pt 上回る
   - 習慣: 週次レビュー機能が習慣化トリガ
   - 価値: タスク完了数 × チームサイズ
6. 30 日: Day1-7 既存データ分析 / Day8-14 解約理由インタビュー 8 件 / Day15-30 オンボーディングテスト
7. ベンチ: SaaS B2B 平均 D30 35% を上回る目標
</output>
</example>

<context>
[インタビュー書き起こし（複数本可）／調査目的／対象者属性（個人特定情報は事前マスク）]
</context>

<task>
質的データを構造化し、ハルシネーションせず本文で語られた内容のみから仮説を導く。
</task>

<output_format>
1. オープンコーディング → 軸足コーディング（最初に主観なしで断片抽出）
2. テーマ抽出 5（出現頻度・重要度）
3. 代表引用（テーマごとに 2〜3 件、ID 付き）
4. 矛盾と葛藤（同一人物内の発言ブレ・人物間の対立）
5. 仮説 3 つ（"もし X ならば Y" 形式、検証方法併記）
6. 信頼度（n / 出現率 / 重み）
7. 個人特定しない記述ルール
</output_format>

<constraints>
書き起こしにない情報を補完しないこと。「一般論として」を禁止。
</constraints>

<example>
<input>
8 名のフリーランスデザイナーへのインタビュー（各 60 分）。「AI ツールの使い方」がテーマ。
</input>
<output>
コーディング: 152 断片 → 24 軸 → 5 テーマ
テーマ:
1. 「下書き生成」用途が圧倒的（8/8）
2. 「クライアント説明用」のリスク（5/8、AI 利用を隠す）
3. 学習コストの心理的壁（6/8）
4. 著作権への懸念（3/8、業界差あり）
5. 同業者との温度差（4/8）
代表引用: 「下書きは Midjourney、最終は手で」(P03) 等
矛盾: P05「AI に頼りすぎると失職」と「毎日 5h 使う」の同時発生
仮説: 1) 「公開時 AI 隠蔽」が需要となる、2) 学習サポートが導入の鍵、3) 著作権は業種で対応分岐
信頼度: n=8 で仮説 1 は強、3 は中
</output>
</example>

<context>
[論点・組織状況・既存戦略 / 意思決定者 / 期限 / 利用可能なデータ]
</context>

<task>
本ケースに適切な戦略フレームを 3 つ提案し、適用順序を示す。「全部やる」を避け、本論点に答えられるものに絞る。
</task>

<output_format>
1. 候補フレーム（JTBD / 5 Forces / Wardley / Blue Ocean / OGSM / North Star / SWOT 等）
2. 各フレームの強みと限界
3. 本ケースで「どの問いに答えるか」
4. 推奨 3 つと適用順序
5. 各フレームの所要時間とアウトプット形式
6. データが足りない場合の代替アプローチ
7. やってはいけない使い方（フレーム濫用 / 結論先行）
</output_format>

<example>
<input>
B2B SaaS、PMF後だが成長鈍化。次の差別化軸を経営会議で決めたい。1 ヶ月。
</input>
<output>
1. 候補: JTBD（誰のどの仕事を奪うか）、Wardley（成熟度）、Blue Ocean（差別化軸）、OGSM（実行）
2. 強み・限界: JTBD は深い顧客理解必要、Wardley はマップ作成 1 週間、Blue Ocean は 2 軸選定が肝
3. 本ケース問: ① 顧客の本当のジョブ ② 競合との相対位置 ③ 次の差別化
4. 推奨順:
   - W1-2: JTBD（既存顧客 8 名インタビュー）
   - W3: Blue Ocean（4 アクション フレーム）
   - W4: OGSM で実行落とし
5. 所要・成果物: JTBD = ジョブマップ、Blue Ocean = 4 軸キャンバス、OGSM = 1 ページ
6. データ不足時: PMF 仮説の補強として SaaS ベンチマーク調査
7. NG: 4 フレーム全部やって 3 ヶ月使う、結論先に決めて後付けでフレームを当てる
</output>
</example>

<context>
[ビジネスモデル / ユーザーが本当に欲しいもの（JTBD）/ 既存 KPI の構成 / 経営方針]
</context>

<task>
North Star Metric（NSM）候補を 3 つ提示し、推奨を返す。「MAU」のような薄い指標で逃げない。
</task>

<output_format>
各候補について：
1. 定義（厳密な計算式）
2. 分解（NSM = a × b × c のインプット指標）
3. 反例（数字が上がっても顧客価値が伴わないケース）
4. 計測の現実性（既存ログで取れるか / 工数）
5. 経営との対応（売上にどう繋がるか）

最後に：
- 最終推奨と理由
- 半年の検証プラン
- NSM が機能しない兆候のシグナル
</output_format>

<example>
<input>
B2B プロジェクト管理 SaaS。ユーザーが欲しいのは「チームの未完了タスクが減ること」。
</input>
<output>
候補A: WAU（弱い）
候補B: 週あたり完了タスク数 × アクティブチーム数
候補C: 「3 人以上のチームが週 5 件以上のタスクを完了した数」（質を担保）

各:
A 反例: 開いただけで通知見て終わる → 価値ゼロ
B 反例: 細かいタスク水増し
C 分解: アクティブチーム × 週次完了 × メンバー数バンド

推奨: C。理由: チーム協働を反映、課金 ARR と高相関、水増しに強い
検証プラン: 半年で C と ARR の月次相関を 0.7 以上を目標
失敗シグナル: C 上昇するが解約率も上昇 → ガードレール（NPS）併設
</output>
</example>

<context>
[提案内容 / 聞き手（CFO / CTO / 現場 / VC）/ 賛否予想 / 提案までの背景データ]
</context>

<task>
1 つの提案を、聞き手別に「刺さる切り口」で説得資料化する。「丁寧に説明すれば伝わる」幻想を捨てる。
</task>

<output_format>
1. 3 行サマリ（What / Why now / Ask）
2. 問題の規模（データで示す。憶測の数字を使わない）
3. 案 A / B / C と推奨案・却下理由
4. ROI 試算（楽観 / 標準 / 悲観の 3 ケース）
5. 想定反論と回答（最低 5 件）
6. 必要な意思決定（GO / NO-GO の閾値）
7. 聞き手別の言い換え
   - ファイナンス: 投資回収 / リスク
   - 技術: 既存負債 / セキュリティ / スケーラビリティ
   - 現場: ワークフロー変化 / 学習コスト
8. 1 ページサマリ（A4 1 枚で読める形式）
</output_format>

<example>
<input>
社内ツールを SaaS から内製に切り替えたい。聞き手 CFO（コスト懐疑派）/ CTO（技術賛成）/ 現場（変化嫌悪）。
</input>
<output>
1. サマリ:
   - What: 社内ツール A を内製化（年 ¥48M → ¥20M 想定）
   - Why now: 契約更新 6 ヶ月前 / 内製チーム余力あり
   - Ask: 4 月までに GO 判断、Q3 リリース
2. 問題: 現コスト ¥48M/年、3 年で ¥144M。利用率 65%（ライセンス 35% 余剰）
3. 案 A 内製 / 案 B 半額 SaaS 乗換 / 案 C 現状維持。推奨 A、B は移行コストで実質同等
4. ROI: 楽観 24 ヶ月 / 標準 30 ヶ月 / 悲観 42 ヶ月
5. 反論:
   - 「内製は運用負荷」→ AWS マネージド + 既存チームで月 1 人月以内
   - 「ベンダーサポートが消える」→ オンコール体制で代替
   - 「セキュリティ」→ SOC2 監査同等の社内ガード
   - 「使い勝手悪化」→ 必須機能 80% を維持、それ以上は要望ベース
   - 「途中で投げ出す」→ ベンダー再契約をフォールバックに
6. GO 閾値: 12 ヶ月で SaaS 並み利用率 80%
7. CFO: ROI 30 ヶ月、競合社内製化トレンド / CTO: 技術選定の自由度、依存解消 / 現場: 主要 5 機能は同じ・段階移行
8. 1 ページ: 上記サマリ + 棒グラフ + 反論集
</output>
</example>

<context>
[ファネル各ステップの定義／現状離脱率／業界ベンチマーク（あれば）／プロダクト特性]
</context>

<task>
離脱原因を量的＋質的に絞り込む調査計画を立てる。憶測でリデザインに走らない。
</task>

<output_format>
1. ステップごとの離脱率と業界ベンチとの差分（ステップ × Baseline × Gap）
2. 量的調査：イベントログから取るべき指標、セグメント切り
3. 質的調査：セッション録画／ユーザーインタビュー（n と対象選定）
4. 離脱理由の仮説 5（UI／価値／期待値／信頼／摩擦）
5. 各仮説の検証方法（A/B / 観察 / インタビュー質問）
6. 最初の 2 週間のアクション（リサーチ → 仮の打ち手 → 計測）
7. 中止条件（仮説どれも当たらなかったら？）
</output_format>

<example>
<input>
B2B SaaS、Step1(登録) 70%通過 → Step2(ワークスペース作成) 30% → Step3(初データ投入) 15%。業界ベンチは Step3 で 35%。
</input>
<output>
1. Step3 で業界比 -20pt が最大ギャップ
2. 量的: チームサイズ × 業界別離脱、データ投入の前 3 アクションのヒートマップ
3. 質的: Step3 まで来て 24h 以内に未投入のユーザー 8 名にインタビュー
4. 仮説: (a) 価値訴求が抽象 (b) 投入フォーマット不明 (c) 1 人で完結できない (d) 失敗時のリカバリ不安 (e) 営業対応待ち
5. 検証: (b) は録画でアタリを確認、(c) は招待動線の利用率
6. 2週: Day1-3 録画、Day4-7 インタビュー、Day8-14 仮説 (b) を A/B（テンプレ提供）
7. 中止: A/B で +0pt なら他仮説に転換
</output>
</example>

<context>
[現状価格 / 対象セグメント / 市場成熟度 / 競合価格 / 既存価格テストの履歴]
</context>

<task>
価格弾力性の検証プランを倫理配慮込みで設計する。「とりあえず価格を 2 段階上げて A/B」を避ける。
</task>

<output_format>
1. 手法比較（Van Westendorp / コンジョイント / 実価格 A/B / Gabor-Granger）
2. サンプルサイズと最小検出効果量
3. 既存ユーザーへの倫理的配慮（grandfather / 同意取得）
4. 実施期間と季節性・キャンペーン除外
5. 解釈の落とし穴（自己選択バイアス・ハロー効果）
6. SRM チェック / セグメント別効果
7. 結果から意思決定までの段取り
8. 中止条件
</output_format>

<example>
<input>
B2C 月額 SaaS、現状 ¥980。新規ユーザー月 1,000 人、既存 8,000 人。
</input>
<output>
1. 手法: 既存への影響回避のため Van Westendorp で価格レンジ把握 → 新規限定 A/B（既存除外）
2. Van Westendorp n=400、A/B は MDE 5% で 各 1,500/群
3. 既存は grandfather 6 ヶ月、A/B は新規ランダム 50/50
4. 期間: 4 週、年末年始除外
5. 落とし穴: アンケートは支払意思の過小申告（理性 vs 実際の差）
6. SRM: chi² 検定で 49.5/50.5 範囲内
7. 段取り: VW 1 ヶ月 → A/B 1 ヶ月 → 経営判断 → 全面適用 or 据置
8. 中止: A/B 中に CV 率 30% 以上低下なら即停止
</output>
</example>

<context>
[自社サービス概要 / 想定乗り換え先 / 顧客セグメント別の利用度合い / 契約形態]
</context>

<task>
顧客のスイッチングコストを定量化する。価格戦略とリテンション戦略の両方に使える形で。
</task>

<output_format>
1. データ移行コスト（エクスポート可否 / フォーマット / 量）
2. 学習コスト（管理者・利用者別の研修時間）
3. 既存ワークフロー再構築（連携 SaaS / マクロ / 帳票）
4. 社内承認・契約手続きの手数
5. 心理的コスト（既存資産への愛着 / 失敗恐怖）
6. 時間・人月・金額への換算
7. セグメント別の合計試算
8. 価格優位 vs スイッチングコストのバランス
9. 自社防衛策（高めるべき要素）と乗り換え攻撃時の打ち手
</output_format>

<example>
<input>
B2B プロジェクト管理 SaaS から競合への乗り換えを想定。10 名チーム / 100 名チーム別。
</input>
<output>
1. データ: API エクスポート可、過去ログ含むと 2 GB / 100 人で 1 日
2. 学習: 管理者 8h / 利用者 2h × 人数
3. ワークフロー: Slack 連携・GitHub PR 連携の再構築 各 1 日
4. 承認: 10 名は社長判断 / 100 名は稟議 1 ヶ月
5. 心理: 過去 2 年の蓄積、失敗時の責任
6. 換算（10 名）: 計 12 人日 + ¥30K = ¥150K相当 / 100 名: 計 80 人日 + 稟議遅延 1 ヶ月 = ¥1.2M
7. セグ: 大規模ほど高、SMB は ¥150K で動く
8. 競合が ¥-100K/年安いと SMB は乗り換え圏、大規模は無理
9. 防衛: API ロックイン / 連携 SaaS 増 / 履歴の価値を可視化
</output>
</example>