
【2026年最新】PdMで使えるChatGPTプロンプト20選|即コピペテンプレ集
この記事のポイント
プロダクトマネージャーの仕事は、書く・聞く・調べる・決めるの繰り返しだ。このうち「書く」と「調べる」はChatGPTで半分以下の時間に圧縮できる。逆に「決める」を丸投げすると痛い目を見る。
この記事は、現場のPdMが日々ぶつかる20の場面それぞれに、コピペで使えるプロンプトを1本ずつ用意した。雑な「PRDを書いて」では使い物にならない。役割・前提・出力フォーマット・制約を明示した構造化テンプレで、初稿の質を一段上げる。
なぜPdMこそChatGPTを使い倒すべきなのか

PdMは「兼任ロール」だ。リサーチャー・ライター・アナリスト・ファシリテーター・営業窓口を一人で抱える。どれも片手間になりがちで、結果的に意思決定の質が落ちる。ChatGPTは「兼任の片側」を肩代わりさせるのに向いている。
ダイヤモンド・オンラインが紹介した書籍『AIを使って考えるための全技術』では、Google・Microsoft・NTTドコモなど600社・2万人以上に思考研修をしてきた著者が、AIで思考を補助する方法論を体系化している(出典: ダイヤモンド・オンライン)。PdMがAIに任せるべきは「思考の代行」ではなく「思考の前段の整理」である、という整理はそのまま今のPdM業務に重なる。
PdMの時間配分は「書類7割・対話3割」
ヒアリング1時間あたりの議事録・要約・ネクストアクション抽出に、PdMは平均で同じ1時間を後処理に使うと言われる。ここを15分に圧縮できれば、週で5時間以上が浮く。プロダクトに向き合う時間が増える。これが本質的なリターンだ。
プロンプト設計の前提ルール(先に読んでほしい)

20本のテンプレを使う前に、共通ルールを5つだけ押さえておく。これを守ると出力の質が体感で倍違う。
| ルール | 内容 | なぜ重要か |
|---|---|---|
| 役割を与える | 「あなたはBtoB SaaSのシニアPdMです」 | 文体と前提知識が固定される |
| 制約を数値で書く | 「3案、各150字以内」 | 出力ブレを抑える |
| 出力フォーマット指定 | 「表形式で」「Markdownで」 | 後工程の整形が消える |
| 不明点は質問させる | 「不足情報があれば先に聞いて」 | 推測ハルシネーション抑制 |
| 一次情報を渡す | 議事録・ログをそのまま貼る | RAG的に文脈を補強 |
上の5つは「プロンプト(AIへの指示文)」全般で効く。とくに「不明点は質問させる」は地味に効く。AIに勝手に補完させると、後で全部書き直す羽目になる。
① PRD(プロダクト要求仕様書)の骨子を作る

PRDは0→1が一番つらい。テンプレートを埋める「最初の300字」をAIに任せる。
あなたはBtoB SaaSのシニアプロダクトマネージャーです。
以下の機能アイデアについて、PRD(プロダクト要求仕様書)の骨子を作ってください。
【機能アイデア】
{ ここに1〜3文で機能の概要を書く }
【出力フォーマット】
1. 課題(誰のどんな痛みか)
2. 解決策(機能の概要)
3. ユーザーストーリー(最低3つ、"〜として、〜したい、なぜなら〜"形式)
4. 成功指標(北極星指標と先行指標を1つずつ)
5. 非ゴール(やらないことを3つ)
6. 技術的リスク(最低2つ)
【制約】
- 各セクション200字以内
- 推測で書かず、不足情報は冒頭で質問してから書き始めること
「非ゴール」を入れておくのが地味に重要。スコープが膨らむのを防ぐ。
② ユーザーインタビューの設問を設計する

ヒアリングの質は質問設計でほぼ決まる。誘導尋問になっていないか、AIに点検させる。
あなたはユーザーリサーチの専門家です。
以下のテーマでユーザーインタビュー(60分)の質問リストを作ってください。
【調査の目的】
{ 何を検証したいか・どんな仮説を持っているか }
【対象ユーザー】
{ ペルソナの簡単な記述 }
【出力フォーマット】
- ウォームアップ(3問)
- 現状の業務フロー(5問)
- 課題・不満(5問)
- 既存の解決手段(4問)
- 新機能の反応を見る質問(3問)
- クロージング(2問)
【制約】
- 誘導質問・Yes/Noで終わる質問は使わない
- "なぜ"よりも"どうやって・いつ・どこで"を優先する
- 各質問の意図を1行で併記すること
「なぜ」を多用しないのは、ユーザーリサーチ界隈の定石。"why"は記憶ではなく解釈を引き出す。
③ 議事録から課題と仮説を抽出する
打ち合わせ後の30分を5分に圧縮するプロンプト。生の議事録をそのまま貼る。
以下はユーザーインタビューの議事録です。
プロダクトマネージャーの視点から、構造化して整理してください。
【議事録】
{ 議事録を全文ペースト }
【出力フォーマット】
1. 一次情報(発言の中で事実として確認できたもの)
2. ユーザー課題(顕在化しているもの/潜在的なもの に分けて)
3. ジョブ(JTBD形式:状況・動機・期待される成果)
4. 仮説(このユーザー群に共通しそうな構造仮説を3つ)
5. 次に検証すべき問い(3つ)
【制約】
- 発言の引用は"原文(行番号)"の形で残す
- 推測と事実を明確に分ける
- 議事録に書かれていない内容は補完しない
「原文の引用を残させる」のが効く。AIの解釈と発言の境界がにじまない。
④ 競合機能の差分テーブルを作る
3〜5プロダクトの機能比較を、表で一気に出す。
あなたは競合分析の専門家です。
以下のプロダクトについて、機能比較表を作成してください。
【比較対象プロダクト】
- A: { サービス名・URL }
- B: { サービス名・URL }
- C: { サービス名・URL }
【比較軸】
{ 自社の関心軸を5〜8個書く。例: 価格・SSO対応・API・日本語UI・etc }
【出力フォーマット】
Markdown表(行=比較軸、列=プロダクト)
表の下に、各プロダクトの"強み・弱み"を3行ずつ要約
【制約】
- 不明な項目は"未確認"と明記する(推測で埋めない)
- 価格・スペック数値は出典URLを併記
- 2026年時点で確認できない情報は除外
「未確認」を許容するのが重要。AIは空欄を嫌って嘘で埋める性質がある。
⑤ 機能アイデアを優先度ありで20個出す
発散フェーズ用。質より量、ただし構造化する。
あなたはプロダクトの新規アイデアを発想するファシリテーターです。
以下のテーマで、機能アイデアを20個生成してください。
【テーマ】
{ プロダクトの方向性 / 解決したい課題 }
【ユーザー】
{ 想定するユーザー像 }
【出力フォーマット】
| # | アイデア名 | 一言説明 | 解決する課題 | 実装難度(1-5)| インパクト見立て(1-5)|
【制約】
- "AIで〇〇"のような汎用案は3つまで
- 既存の競合に1:1で存在する機能は除外
- 風変わりだが筋の通った案を最低3つ混ぜる
「風変わりだが筋の通った案を混ぜる」を入れるとブレストの幅が広がる。
⑥ ICEスコアで優先順位をつける
20案を絞り込む工程。AIに評価まで任せる場合、評価軸を厳密に定義する。
以下のアイデアリストについて、ICEスコア(Impact × Confidence × Ease、各1-10)を算出してください。
【アイデアリスト】
{ ④や⑤で出た案を貼り付け }
【評価基準】
- Impact: 主要KPI({ 自社のNSM })への影響度
- Confidence: ユーザーニーズの確からしさ(過去の声 / 競合の動きを根拠に)
- Ease: 3ヶ月以内にMVPが出せるか
【出力フォーマット】
| アイデア | Impact | Confidence | Ease | ICE合計 | 評価根拠(各1行)|
【制約】
- 各スコアに根拠を必ず1行添える
- 同点が3つ以上出ないように差をつける
「根拠を1行添えさせる」のが点検しやすい。
⑦ ステークホルダー説明用の1pagerに変換する
エンジニア向けPRDから、経営層向け1pagerへの変換。
以下のPRDを、経営層向けの1ページサマリーに変換してください。
【PRDの本文】
{ PRDをペースト }
【1pagerの構成】
- リード(3行): なぜ今、なぜこれをやるか
- 想定インパクト(数値1つ)
- 主要なリスクと打ち手(2セット)
- 必要リソース(人月・期間)
- 意思決定をお願いしたいこと(GO/NO-GOで聞ける形)
【制約】
- 技術用語は最小限に
- 数値は元PRDから引用、創作しない
- 全体600字以内
「意思決定をお願いしたいこと」を末尾に必ず置くのがコツ。意思決定者の時間を奪わない。
⑧ KPIツリーを分解する
NSM(北極星指標)からKPIを構造化する。
あなたはグロースのアナリストです。
以下のプロダクトについて、NSM(北極星指標)からKPIツリーを作成してください。
【プロダクト概要】
{ サービス内容を3〜5行 }
【NSM】
{ 例: WAU、契約継続率 等 }
【出力フォーマット】
Markdownのインデント形式で3階層
- NSM
- 中間指標(4つ)
- 先行指標(各2〜3つ)
各先行指標に、計測方法(イベント名 or SQLのアイデア)を1行添える
【制約】
- "売上"のような結果指標を中間指標に置かない
- 各層は AND ではなく "構成要素の総和"で表現
KPIツリーは構造を間違えると意思決定がぶれる。インデント形式で出させて目視点検する。
⑨ A/Bテストの仮説書を作る
検証文化を作る最小単位、それが仮説書。
以下のテスト案について、A/Bテストの仮説書を作成してください。
【テスト対象】
{ どのページ・どの機能を変えるか }
【変更内容】
- A(コントロール): { 現状 }
- B(バリアント): { 変更後 }
【出力フォーマット】
1. ビジネス課題(1段落)
2. ユーザーの仮説("〜なユーザーは〜と感じている、なぜなら〜"形式)
3. 介入の仮説("〜を変えれば〜が起こるはず"形式)
4. 評価指標(主指標1つ・ガードレール指標2つ)
5. 必要サンプルサイズ(前提:転換率・MDE・有意水準を仮置きで)
6. テスト期間の見立て
7. 結果ごとの次アクション(勝ち / 負け / 引き分け)
【制約】
- "なんとなく良くなりそう"系の仮説は却下
- 「引き分け」のアクションを必ず書く
「引き分け」を書かせるのが粋。結論不明で塩漬けになるのを防ぐ。
⑩ ユーザーセグメント別のメッセージを書き分ける
リリースノートや初期メールを、セグメント別に書き分けるテンプレ。
あなたはBtoB SaaSのプロダクトマーケターです。
以下の新機能について、3つのセグメント別にリリースメッセージを作成してください。
【新機能】
{ 機能名と概要 }
【セグメント】
- A: { 例: 既存ヘビーユーザー }
- B: { 例: 一度離脱した非アクティブユーザー }
- C: { 例: 無料プランの新規ユーザー }
【出力フォーマット】
各セグメントについて:
- 件名(30字以内)
- 本文(300字以内)
- CTAの文言(10字以内)
【制約】
- 文体・温度感をセグメントごとに変える
- 機能名のスペルは原文を保つ
- 数字や時期は本文に書かれていなければ書かない
⑪ ローンチチェックリストを生成する
リリース直前に毎回作るやつ。テンプレ化しておくと抜けがなくなる。
以下のリリース内容について、ローンチチェックリストを作ってください。
【リリース内容】
{ 機能の概要・対象ユーザー・公開日 }
【チェックリストの分類】
- プロダクト(QA・パフォーマンス・アクセシビリティ)
- データ計測(イベント設計・ダッシュボード)
- カスタマーサクセス(FAQ・サポートチームへの周知)
- マーケティング(リリースノート・SNS・メール)
- 法務・セキュリティ(利用規約・プライバシー・SOC2影響)
【出力フォーマット】
分類ごとに、チェックボックス形式で5項目以上
各項目に責任者の役割(PdM/Eng/Design/CS/Marketing/Legal)をタグ付け
【制約】
- 一般論にしない。今回のリリース内容に紐づく具体タスクで書く
- 漏れがちな項目(i18n・ログ削減・コスト試算)を必ず含める
⑫ プロダクトのオンボーディング動線を分解する
新規ユーザーがアハ体験に到達するまでをステップで切る。
あなたはオンボーディング設計の専門家です。
以下のプロダクトについて、新規ユーザーが"アハ体験"に到達するまでの最適動線を設計してください。
【プロダクト概要】
{ サービス内容 }
【アハ体験の定義】
{ 例: "最初のレポートを共有した時"など }
【出力フォーマット】
ステップ番号 / 画面 / ユーザーの行動 / 想定離脱率 / 離脱を下げる打ち手
【制約】
- 6ステップ以内
- 各ステップで"ユーザーが何を理解すべきか"を1行
- 離脱率は仮説でよいが、根拠を1行併記
⑬ サポートチケットからプロダクト課題を抽出する
CSとの定例前にやると、議題がクリアになる。
以下はカスタマーサポートチケットの抜粋です。
プロダクト改善の観点から、構造化して整理してください。
【チケット】
{ 直近1ヶ月のチケットを箇条書きで貼る }
【出力フォーマット】
1. テーマ分類(最大8つ、頻度順)
2. 各テーマの代表的なチケット原文(1〜2件)
3. プロダクト改善で解消できる/できないの判定
4. 優先度(緊急・中・低)
5. 次の打ち手(プロダクト / コンテンツ / オペレーション のどれか)
【制約】
- 件数のカウントは正確に
- "問い合わせを減らす"だけが目的にならないよう、ユーザー成功の視点を残す
⑭ 既存ドキュメントから決定事項だけ抜き出す
長い議事録・Confluenceページの読み返しを5分に。
以下のドキュメントから、"決定事項" "未決事項" "Next Action" の3種類だけを抽出してください。
【ドキュメント本文】
{ 長文をペースト }
【出力フォーマット】
- 決定事項: 箇条書き(誰が・何を・いつから)
- 未決事項: 箇条書き(論点・ブロッカー)
- Next Action: 箇条書き(担当・期日)
【制約】
- 議論の経緯や雑談は省く
- 担当・期日が不明な項目は"要確認"と明記
- 推測で補完しない
⑮ ロードマップの言い換え(外部公開用)
社内ロードマップを、顧客向けに角を取って公開する。
以下の社内ロードマップを、顧客向け公開ドキュメントに書き直してください。
【社内ロードマップ】
{ 内部のスライド or 箇条書きを貼る }
【出力フォーマット】
- Now(着手中)
- Next(次クォーター)
- Later(半年〜1年)
【書き方の方針】
- 競合に手の内を見せすぎない(具体的な実装方法は伏せる)
- 顧客の課題ベースで語る("〇〇でお困りの方へ"のような導入)
- リリース時期は明言しない("Q4目標" 程度の解像度)
【制約】
- 約束に聞こえる断定表現は避ける
- 法務確認が必要な表現を3つ挙げて末尾に添える
「法務確認が必要な表現を3つ挙げさせる」のが現場感。
⑯ ペルソナ仮説を3パターン作る
新規事業の初期、まだユーザー像が定まっていない時に使う。
あなたはBtoB SaaSのプロダクトマネージャーです。
以下のサービス案について、ターゲットペルソナを3パターン作ってください。
【サービス案】
{ サービスの概要を3行 }
【ペルソナの構成】
- 業種・規模・役職
- 1日の業務フローの抜粋
- 直近で困っていること(3つ)
- 既存の解決手段(道具・ツール・人)
- 購買意思決定への関与度
- このサービスを採用する障害
【出力フォーマット】
3パターンを表形式で並列
【制約】
- 同じ業種で揃えない(多様性を出す)
- ステレオタイプな"DX推進室の山田さん"を避ける
- 名前は仮名(実在企業名は使わない)
⑰ プロダクト分析クエリのアイデアを出す
データチームに依頼する前の壁打ち。SQLを書かせるよりも「何を見るべきか」を出させる。
以下のプロダクトについて、リテンション分析のための"見るべきクエリ案"を10個出してください。
【プロダクト概要】
{ 主要なユーザー行動 / 計測しているイベント名 }
【出力フォーマット】
| # | クエリ目的 | 主要なイベント | 切り口(コホート・セグメント)| 期待されるインサイト |
【制約】
- "MAU"のような表面指標は除外
- 行動連鎖(例: ファネル)を含むクエリを最低3つ
- データチームに依頼する優先度(高・中・低)を末尾列に追加
⑱ 仕様の曖昧さを潰す(エンジニアレビュー前のセルフチェック)
仕様書をエンジニアに渡す前に、AIに突っ込みを入れさせる。
あなたはBtoB SaaSのテックリードです。
以下の仕様書を、実装視点で厳しくレビューしてください。
【仕様書】
{ 仕様書本文を貼る }
【観点】
- 仕様の曖昧さ("後で決める"が残っていないか)
- エッジケース(同時編集・権限不足・通信断・大量データ)
- 既存仕様との矛盾
- パフォーマンスの懸念
- セキュリティ上の見落とし
【出力フォーマット】
| 観点 | 該当箇所 | 指摘 | 提案 | 重要度(高・中・低)|
【制約】
- "問題なし"で終わらせない(最低10件は指摘を出す)
- 重要度の判断根拠を1行添える
「最低10件出させる」が点検漏れを防ぐ。出てきた指摘が薄ければ「これは却下」で良い。
⑲ 退会理由から構造課題を読む
退会ログから、プロダクトのコア課題を抽出する。
以下は直近3ヶ月の退会理由(自由記述)の抜粋です。
プロダクトマネージャーの視点から、構造課題を抽出してください。
【退会理由】
{ 自由記述を箇条書きで貼る }
【出力フォーマット】
1. テーマ分類(5つ以内、頻度順)
2. 各テーマの一次情報(原文の引用)
3. 解釈("このテーマの裏にある本質的な課題は〜")
4. プロダクト改善 / プライシング / オンボーディング / ICP不一致 の4分類で振り分け
5. 即座に手を打つべき1テーマと、その根拠
【制約】
- "価格が高い"の裏にある"価値が伝わっていない"のような二次解釈を必ず付ける
- 引用は原文のまま、改変しない
⑳ 自分の1週間を振り返る(PdMの個人OKR点検)
最後はPdM自身のためのプロンプト。週次の振り返りに30分使うなら、これで5分にしたい。
以下は私の今週のタスクリストです。
プロダクトマネージャーとしての観点で、振り返りを補助してください。
【今週のタスク】
{ 完了したタスク・着手したタスク・棚上げにしたタスクを貼る }
【振り返りの構成】
1. プロダクトに直接価値を生んだ時間(推定 %)
2. 浪費に見える時間(やる必要があったか怪しいタスク)
3. 翌週に持ち越すべき重要タスク(最大3つ)
4. 自分が委譲できたはずのタスク(最大2つ)
5. 来週の最優先1テーマ(理由を3行)
【制約】
- 慰めの言葉は不要
- "頑張った"系の評価語を使わない
- 客観的な改善提案だけ書く
「慰めの言葉は不要」を入れておくのが地味に効く。PdMは自分を甘やかさないほうが伸びる。
プロンプトをチームで再利用する3つの方法
ここまでの20本は、個人で使うだけだともったいない。チームに展開する方法を3つ。
| 方法 | 向く規模 | 利点 | 欠点 |
|---|---|---|---|
| GPTs(ChatGPT内蔵) | 個人〜小規模 | 即作れる・共有も簡単 | Plus以上が必要 |
| Notion AI / Slackのカスタムプロンプト | チーム単位 | ワークフローに溶け込む | プロンプト管理が散らかる |
| 社内プロンプトライブラリ(Notion DB等) | 全社 | バージョン管理可能 | 運用が重い |
GPTsから始めて、使われるものだけNotionに昇格させる流れが現実的だ。詳しくはNotion AIや関連ツールのガイドを参照。
ChatGPTで PdM 業務はどこまで自動化できる?
「全部任せたい」と思うかもしれないが、現実は半分以下だ。判断・関係性・空気を読む系の仕事は残る。
ChatGPT Review 2026(出典: ChatGPT Review 2026)でも「強力な汎用ツールだが、すべてのワークフローで自動的にベストとは限らない」と評価されている。PdMの仕事も同じで、AIに振れる部分とそうでない部分の見極めが要る。
任せていい仕事
- ドキュメントの草案・整形・要約
- データの構造化と分類
- 競合・市場のリサーチ補助
- アイデア発散・優先順位の壁打ち
任せきれない仕事
- 意思決定そのもの
- ステークホルダーとの政治的調整
- 重要な顧客との対面ヒアリング
- 数値の最終的な責任
モデル選びで結果はどれくらい変わる?
PdM業務でChatGPTを使う場合、無料プランか有料プラン(ChatGPT Plus)かで体感差は大きい。2026年4月時点、ChatGPT Plusは月額$20前後(出典: 起業の「わからない」を「できる」に)。
PCMag UK のレビュー(2026年版)でも「GPT-5および GPT-5 Thinking が主力モデル」と紹介されている(出典: PCMag UK ChatGPT Review 2026)。長文の構造化や論理的なPRDレビューには Thinking 系の方が向く。
| 用途 | おすすめモデル | 理由 |
|---|---|---|
| 議事録の要約・分類 | GPT-5系 通常モード | 速度重視で十分 |
| PRDレビュー・仕様の矛盾検出 | GPT-5 Thinking | 論理的な推論が深い |
| 競合機能リサーチ | Perplexity と併用 | 出典付きで返るため |
| 長文ドキュメントの構造化 | Claude Opus も併用 | 長文処理に強い |
Felo の解説記事やMeta AI のガイドも併せて読むと、用途別の使い分け感覚がつかめる。
プロンプトを"使い捨て"にしない運用のコツ
20本を眺めて満足しがちだが、回るチームはプロンプトに「育成」の意識を持っている。
- 良い出力が出たプロンプトに「v2」と版を切る
- 失敗した出力もログとして残す(何を書かなかったから失敗したか)
- 月1回、棚卸し。使われていないテンプレは削除
- プロンプトの中に、社内固有の用語集を埋め込む
特に4が効く。「弊社のNSMはWAU、サブKPIはxxxx」を毎回貼るより、テンプレに織り込んでおく。
セキュリティ・情報管理で踏むべき地雷
「ChatGPTに顧客情報を貼っていいのか?」は、2026年でもPdM経由で必ず聞かれる質問だ。
- 無料・Plusプラン: デフォルトで学習データに使われる可能性がある(オプトアウト可)
- Enterprise / Team プラン: 学習データから除外、SOC2 Type2 / GDPR対応(出典: 起業の「わからない」を「できる」に)
- API利用: APIから送ったデータは学習に使われない(OpenAI公式ポリシー)
顧客名・契約金額・個人情報を含む議事録は、必ずマスキングしてから貼る。これは交渉の余地がない。
OCRで紙資料をAIに食わせるパターンは増えている。安全に取り回したい場合はAI OCRツールガイドを併読。
実際に使っている企業・チーム
Tavily調査結果に基づく一般情報として、ChatGPTをPdM業務に組み込んでいる事例を紹介する。
マイクロソフト
Copilotスタックの一部としてOpenAIモデルを社内に深く統合。プロダクトのスペックドキュメント自動草案、仕様レビュー、ユーザーフィードバックの分類などPdM周辺業務でも活用が広がっている(出典: ダイヤモンド・オンライン 紹介書籍内)。
NTTドコモ
社内研修としてAIによる思考補助の方法論を導入。プロダクト企画部門でも、ブレストや仮説整理のフェーズでAIアシストを取り入れている(出典: ダイヤモンド・オンライン)。
KDDI
同じく書籍『AIを使って考えるための全技術』の研修導入企業として紹介。プロダクト企画と新規事業の発散フェーズで、AIを「思考の前段」として位置づける動きがある(出典: ダイヤモンド・オンライン)。
実在企業の活用は「全部AIに置き換えた」という極端な事例より、「特定の業務だけAIに任せて、人間の時間を意思決定に寄せる」というハイブリッド型が主流だ。
AI PICKS 編集部の判定
正直に書く。20本のプロンプトを並べたが、全部を使う必要はない。PdMの仕事は人それぞれ違うし、組織の成熟度でも何が「重宝する」かが変わる。
ただ、初稿を書く・要約する・構造化する・突っ込みを入れさせる、この4つはどんな組織のPdMでも効く。逆に「意思決定そのもの」「ステークホルダーとの感情調整」「重要顧客との対話」をAIに丸投げするのは、現時点では筋が悪い。
2026年は「AIを使うかどうか」ではなく「どこに使うか」で差がつくフェーズに入った。March 2026のGoogleコアアップデートで一次体験の重要性が再確認されたように、AIの仕事と人の仕事の境界線が、改めて引き直されている。PdMの場合、その境界は「書く・調べる」と「決める・関わる」の間にある。前者は遠慮なく振っていい。後者は自分で握る。これが現時点での編集部の見立てだ。
導入の壁は、技術的なものより心理的なものが大きい。「AIに任せたら自分の仕事がなくなる」という不安は古い。むしろ「AIで時間を作って、本来やるべき意思決定に集中する」のがPdMの新しい仕事の形だ。20本のテンプレを、その入り口として使ってほしい。
編集部の利用レポート(率直な感想)
ここまで偉そうに書いたが、編集部内でも20本すべてが「重宝する」わけではなかった。実際に使ってみての温度感。
- PRD骨子・議事録要約・退会理由の構造化: 圧倒的に時短になる。一択でAIに振っていい
- A/Bテスト仮説書・ICEスコアリング: 雑な仮説の点検には地味に効く。最終判断は自分で
- ペルソナ仮説: 初期発散にはいいが、ステレオタイプを避ける制約を入れないと正直イマイチ
- ロードマップの外部公開用変換: 法務観点の指摘までさせると破格に便利
- 個人OKR振り返り: 慰めを禁止する制約がないと、ただの自己肯定マシンになる。微妙
万能ではない。使う場面と制約の設計で、結果は段違いになる。
よくある質問(FAQ)
Q. ChatGPTの無料プランでも20本のプロンプトは使えますか?
A. 基本的には使えます。ただしGPT-5系の利用回数に制限があり、長文の出力ではPlus以上の方が快適です(出典: 起業の「わからない」を「できる」に)。重要なPRDレビューや長文の構造化はPlus以上を推奨します。
Q. 機密情報を含む議事録をChatGPTに貼っても大丈夫ですか?
A. 無料・Plusプランでは推奨しません。学習データから除外したい場合はEnterprise・Teamプランの利用、もしくはAPI経由での利用、または社内承認済みのAIゲートウェイ経由をおすすめします。顧客名・契約金額・個人情報は必ずマスキングしてください。
Q. ChatGPT、Claude、Geminiでプロンプトの書き方は変わりますか?
A. 共通する設計原則(役割付与・制約の明示・出力フォーマット指定)はどのモデルでも有効です。一方、長文処理ではClaude、リアルタイム情報ではPerplexityやGemini、構造化された推論ではGPT-5 Thinkingが向くなど、用途で使い分けるのが現実的です。
Q. プロンプトのテンプレを社内で共有する一番簡単な方法は?
A. ChatGPT PlusのGPTs機能で「社内専用GPT」を作るのが最も手軽です。チーム規模が大きくなったらNotionデータベースで管理する方法が現実解。バージョン管理と「使われていないテンプレの削除」を運用に組み込むのがコツです。
Q. AIが出した内容をそのままステークホルダーに出してもいいですか?
A. 推奨しません。事実関係・数値・固有名詞は必ずPdMが点検してください。特に「未確認」と明記された箇所、推測で書かれた可能性のある箇所は要チェック。AIは「もっともらしい嘘」を生成することがあるため、最終出力の責任はPdMが負う前提で運用してください。
Q. プロンプトに業界固有の用語を入れると精度は上がりますか?
A. 上がります。ただし初出時は平易な言葉で補足する設計にしておくと、AIの解釈ブレが減ります。社内用語集を別プロンプトとして渡すか、システムプロンプトに埋め込む方法が有効です。
Q. ChatGPTで PdM 業務はどこまで自動化できますか?
A. 草案作成・要約・分類・発散・優先度付けの「前段」はかなり自動化できます。一方、意思決定そのもの、ステークホルダー調整、重要顧客との対話は人間の領域として残ります。PdMの時間配分のうち、書類仕事の50〜70%を圧縮できれば成功と考えるのが現実的です。
Q. プロンプトの精度を継続的に上げるコツは?
A. 「失敗した出力」を捨てずに記録することです。何を書かなかったから失敗したのかを言語化し、テンプレに制約を1行追加していく。これを月次で棚卸しすると、3ヶ月でチーム共通の「効くプロンプト集」が育ちます。
関連する比較・代替を見る
PdM周辺で使えるAIツールの比較を別記事でまとめている。プロンプト設計と合わせて、ツール選びの参考に。
- ChatGPT vs Claude 用途別の使い分け
- ChatGPT vs Gemini 業務効率での比較
- Notion AI vs ChatGPT ドキュメント運用での比較
- Perplexity vs ChatGPT リサーチ用途での比較
- Claude vs Gemini 長文処理での比較
- ChatGPTの代替ツール一覧
- 画像生成系の比較記事
- Sora AIガイド(動画系)
参考にした一次情報
本記事の作成にあたり参照した一次情報および二次情報の出典リスト。
- ダイヤモンド・オンライン「【2026年こそAIを使いこなす!】仕事力が爆上がりする"ChatGPT神プロンプト"5選!」(書籍『AIを使って考えるための全技術』石井力重 著の紹介記事)
- 起業の「わからない」を「できる」に「【2026年最新】ChatGPTは無料?登録は必要?仕事に使える?」
- 中村祐太のFindUアカデミー「ChatGPT有料プランにする必要ある?プランの違いを徹底解説!2026年最新版」
- AIツールギャラリー「【2026最新】ChatGPTとは?特徴や使い方、料金まで解説!」
- ChatGPT Review 2026: Pricing, Features, Limits and Verdict
- ChatGPT Models Explained: Complete Comparison Guide (2026)
- PCMag UK「ChatGPT - Review 2026」
- OpenAI 公式ドキュメント(API利用時のデータ取り扱いポリシー)
