product-manager-prompts完全解説：PM業務を25種プロンプトで標準化するOSS（★832）

「ステークホルダーからの依頼に追われて、戦略を考える時間が一切取れない」——プロダクトマネージャー（PM）の最も典型的な悩みだ。Jobs-to-be-DoneやUser Storyの書き方は本で学んだが、いざ忙しい日々のなかで体系的に運用するのは難しい。product-manager-prompts（deanpeters/product-manager-prompts、★832・MIT）はこの問題に直接切り込むOSSだ。Mike Cohnのユーザーストーリー、Geoffrey Mooreのポジショニング、AmazonのWorking Backwards、PESTEL分析など、PM業界で確立された25種以上のフレームワークをプロンプトテンプレートに落とし込み、ChatGPT・Claude・Geminiで誰でも再現できる形で公開している。

この記事ではPM業務をAIプロンプトで標準化するOSSを解説します。AIとの協働コーディング全体像についてはVibe Coding完全ガイド：AI協働コーディングの新潮流2026年版をご覧ください。

product-manager-promptsとは：PMフレームワークをLLMで再現するOSS

deanpeters/product-manager-promptsはGitHub上に公開されたMITライセンスのリポジトリで、作者はDean Peters氏。ハッシュタグはagile・product-management・product-owner・generative-ai・chatgptが付与されており、PMが日常的に使うフレームワークをLLMで再現するためのテンプレート集として位置づけられている。リポジトリ全体は100% Markdownで構成され、ソースコードを書かずにプロンプトをそのままコピー＆ペーストして使う実用的な設計だ。

主要ディレクトリは6つに分かれる。

リポジトリ最大の特徴は「Raw View で読むこと」を強く推奨している点だ。GitHubのデフォルトプレビューでは表示されないHTMLコメントブロックに「なぜこのプロンプトが効くのか」「どのフレームワークから引用したか」「どこをカスタマイズすればよいか」が解説されている。これが他のプロンプト集との明確な差別化要因になっている。

25種以上のPMプロンプト分類

リポジトリの/prompts/ディレクトリに収録されているテンプレートはPMロール別に4つのカテゴリに整理できる。

戦略基盤（Strategic Foundation）

• jobs-to-be-done.md — Value Proposition Canvasベースで顧客の「片付けたい用事」を抽出
• positioning-statement.md — Geoffrey Mooreの『Crossing the Chasm』ポジショニング・ステートメント形式
• framing-the-problem-statement.md — 問題定義のベストプラクティスを構造化

顧客発見（Customer Discovery）

• proto-persona-profile.md — 初期段階のバイヤープロファイルをproto-personaキャンバスで作成
• customer-journey-mapping-prompt-template.md — 顧客体験のEnd-to-Endマッピング
• company-profile-executive-insights-research.md — 競合企業の経営層インサイト調査

要件・実行（Requirements & Execution）

• user-story-prompt-template.md — Mike Cohn＋Gherkin形式のテスト可能なストーリー
• user-story-splitting-prompt-template.md — 大きすぎるストーリーの分割テンプレ
• backlog-epic-hypothesis.md — 仮説駆動でEpicを起こすテンプレ

市場・コミュニケーション（Market & Communication）

• pestel-analysis-prompt-template.md — マクロ環境のPESTEL分析
• recommendation-canvas-template.md — 経営層への提言を組み立てるキャンバス
• visionary-press-release.md — Amazonの「Working Backwards」スタイル
• storyboard-storytelling-prompt.md — 概念を絵コンテで伝える物語化
• futuristic-product-faq.md — ステークホルダー想定質問のFAQ化
• reverse-engineer-IEEE830srs/ISO29148-to-PRD-prompt-template.md — 仕様書標準からPRDへ翻訳

これに加えてBeast GeneratorやMovie Title Generatorのような遊び心のあるプロンプトも収録されており、「使い続けたくなる」設計になっている点も見逃せない。

中身の解剖：Jobs-to-be-Doneプロンプトの構造

代表例としてjobs-to-be-done.mdの構造を覗いてみると、product-manager-promptsの設計思想がよく分かる。

あなたは Jobs-to-be-Done エクササイズを進行する
Product Discovery アシスタントです。

# Sticky-Note Rule
- 各箇条書きは 4〜8 単語で書くこと
- ASCII文字のみを使うこと
- 出力はMarkdownコードブロックで返すこと

# Required Context
- Product / Service:
- Target Customer:
- Existing Hypothesis:

不足している情報があれば、最大3つまで
1つずつ質問してください。明示的に「Assumption:」と
ラベルを付けて推論しても構いません。

# Output
1. Customer Jobs (functional / social / emotional)
2. Pains (challenges, costliness, mistakes, unresolved problems)
3. Gains (expectations, savings, adoption factors, life improvement)

# Next Step
最後に必ず4つの選択肢を提示し、ユーザーに番号で
選ばせること（例: "1 and 3"）。

注目すべきは3点。

1. Sticky-Note Rule：付箋に書ける長さ（4〜8単語）に制約することで、ワークショップにそのまま貼れる成果物を出させる
2. 不足情報の取り扱い：勝手に推論せず、まず3つまでの追加質問を許可。これにより幻覚を抑制しつつフローを止めない
3. 必ず4つの次のステップ：成果物を出して終わりではなく、Discovery → Validation → Opportunity Statement → Value Propositionといった次の工程にプロンプトチェーンを促す

この設計はAnthropic公式のClaude Cookbooksが提唱する「Output Schemas」「Stepwise Reasoning」と同じ思想で、PM領域に特化したものと言える。

User Storyプロンプトの実例

もう一つ実例としてuser-story-prompt-template.mdを見ると、Mike CohnのUser Storyベスト・プラクティス＋BDD（Behavior Driven Development）の組み合わせが組み込まれている。

# Output Format
- Story ID: US-XXX
- Summary: <persona>として、<value>を得たい
- Use Case:
  As a <user>, I want to <action>, so that <outcome>
- Acceptance Criteria (Gherkin):
  Given <precondition>
  And <precondition>
  When <action>
  Then <expected result>

# Split Signal Rule
- WhenまたはThenが2つ以上必要になった場合、
  user-story-splitting-prompt-template.md を使って
  ストーリーを分割すること

PMが現場で「あれこれ要件を盛りすぎて1つのストーリーが肥大化する」ありがちな失敗を、プロンプト側がルールで防ぐ設計になっている。これは単なる「テンプレ集」ではなく、ワークフローのガードレールとして機能している証拠だ。

既存OSSとの比較：PM版の何が新しいのか

ai-archive-jpではこれまで複数のプロンプト・スキル集を取り上げてきた。比較すると、product-manager-promptsの位置づけが明確になる。

product-manager-promptsの独自性は3点に集約される。

1. ロール特化型のフレームワーク網羅性

agent-skillsはエンジニアリング、awesome-design-mdはデザインに特化していたが、PM領域には体系的な公開プロンプト集が存在しなかった。product-manager-promptsはこの空白地帯を埋めている。Mike CohnのUser Stories Applied、Geoffrey MooreのCrossing the Chasm、Amazon方式のWorking Backwards、Strategyzer社のValue Proposition Canvasなど、PM教科書の中身がそのままプロンプトとして使える。

2. プロンプト同士の「チェーン化」

各プロンプトは独立に使うこともできるが、Discovery → Story → Acceptance Criteria → Splittingという連鎖をエンドユーザーに促す設計になっている。たとえばJobs-to-be-Doneの結果を受けてUser Storyテンプレに渡すことで、顧客理解から開発タスクまで一気通貫で生成できる。

3. HTMLコメントによる「教える」設計

GitHub上で「Raw」表示するとHTMLコメントブロックが見える。そこに「なぜこのプロンプトが効くか」「どのフレームワークから引用したか」「どこをカスタマイズすべきか」がメタ知識として埋め込まれている。これはユーザーにプロンプトエンジニアリング自体を教える仕組みで、教材性が極めて高い。

導入手順：Claude / ChatGPT / Geminiで使う

product-manager-promptsはCLI不要・依存関係なしで、コピー＆ペーストで動くのが最大の利点だ。

1. リポジトリのクローン or 必要ファイルだけ取得

git clone https://github.com/deanpeters/product-manager-prompts.git
cd product-manager-prompts
ls prompts/
# jobs-to-be-done.md
# user-story-prompt-template.md
# pestel-analysis-prompt-template.md
# ...

社内Wikiやnotionで一部だけ使うなら、特定ファイルを直リンクするだけでよい。例:

# Raw URLで取得（GitHub Web UIの "Raw" ボタンと同じ）
curl -o jobs-to-be-done.md \
  https://raw.githubusercontent.com/deanpeters/product-manager-prompts/main/prompts/jobs-to-be-done.md

2. ChatGPT / Claude / Geminiに貼り付け

Markdownファイル全体をシステムプロンプトまたは最初のユーザーメッセージとして貼り付ける。Claude Projects、ChatGPT Custom GPT、Gemini Gemsのいずれでも動作する。

[ここにjobs-to-be-done.mdの中身を全文貼り付け]

----

# Required Context
Product / Service: 法人向けSaaSの請求書管理SaaS
Target Customer: 経理部のマネージャー（従業員50〜300名規模）
Existing Hypothesis: 月末の締め作業に過剰な残業が発生している

3. プロンプトチェーンで深掘り

最初のJobs-to-be-Doneの出力を受けて、続けてUser Storyテンプレを貼り付ける。

前段のJobs-to-be-Done分析の結果（Customer Jobs / Pains / Gains）を
次のフォーマットで User Story に変換してください。

[ここにuser-story-prompt-template.mdを貼り付け]

これにより顧客理解の生情報がそのままアジャイル開発の入力になる。

4. Claude Code / Cursorに組み込む

Claude CodeやCursorと組み合わせる場合は、/.claude/commands/pm-discovery.mdのようなスラッシュコマンドに登録するのが定石だ。たとえばClaude Skills完全解説で解説したSkill構造に当てはめると、PM作業をエージェント側からも呼び出せる。

# Claude Code用のスキルディレクトリにコピー
mkdir -p .claude/skills/pm-discovery
cp prompts/jobs-to-be-done.md .claude/skills/pm-discovery/SKILL.md

これでClaude Codeから/pm-discoveryと打つだけでPMフローを起動できる。

実務適用：3つのユースケース

ユースケース1：新機能の戦略立案（Strategy）

経営層から「来期、AI関連の新機能を出したい」と曖昧な指示が来たケース。

1. PESTEL分析でAI市場の外部環境を整理（規制・経済・技術トレンド）
2. Jobs-to-be-Doneで社内の既存顧客が抱える問題を抽出
3. Positioning Statementで「誰に・何を・なぜ」を明文化
4. Visionary Press Releaseで経営層に提示する未来像を作る

これを2時間で1人のPMが回せる——以前は1週間かかっていた——のがprompt集の威力だ。

ユースケース2：スプリント前のバックログ整理

エンジニアと一緒にスプリント計画を組む直前。

1. Backlog Epic Hypothesisで各Epicに「検証すべき仮説」を紐づける
2. User Story TemplateでEpic配下のストーリーを生成
3. User Story Splittingで2スプリントに収まるサイズに分割
4. Acceptance Criteria（Gherkin）で各ストーリーのテスト条件を整理

このフローはVibe Coding完全ガイドが提唱する人間とAIの協働開発にPM工程をプリペンドした構造だ。

ユースケース3：ステークホルダー説得（Communication）

VP of EngineeringやCFOに新規プロダクトを承認してもらう場面。

1. Storyboard Promptで顧客の問題と解決策を絵コンテ風に描く
2. Futuristic Product FAQで予想される質問とその回答を準備
3. Recommendation Canvasで投資判断の意思決定資料に変換

「数字よりストーリーで動く役員」を相手にする際に効果が大きい。

「納期に間に合わない」「炎上対応」への対処は？間接プロンプトとカタルシス系の使い方

ここまで読んだPMの多くが期待しているはずの「納期に間に合わない」「スコープが膨れ上がっている」「ステークホルダーの板挟みで疲弊している」——こうした現場の火消し系プロンプトは、product-manager-prompts には直接的には収録されていない。25種のテンプレートはどれも戦略・要件・コミュニケーションの「平時の設計」に振り切っている。

ただし、これらの問題の根本原因にアプローチする間接プロンプトと、心理的負荷を逃がすカタルシス系プロンプトの2系統が用意されている。リポジトリの設計思想は「炎上を消す」のではなく「炎上を起こさない／起きた時に皮肉で受け流す」方向に振れている、という点を理解した上で使い分けたい。

系統A：根本原因にアプローチする5つの間接プロンプト

1. user-story-splitting-prompt-template.md：8つの分割ロジックでスプリントに収める

「機能Aを完成させる」というEpicが見積もり3スプリント超えしたとき、このプロンプトは8つの分割ルールでストーリーを切り刻む。

1. ワークフロー段階で分割（登録→確認→送信を別ストーリーへ）
2. 業務ルールの差分で分割（無料／有料プランで条件分岐）
3. データバリエーションで分割（個人／法人など対象データ別）
4. 複雑な受け入れ条件で分割（複数のWhen/Thenを別ストーリーへ）
5. 大きな実装工数で分割（マイルストーン区切り）
6. 外部依存で分割（外部APIに依存する部分を切り離す）
7. DevOps工数で分割（インフラ整備を別ストーリーに）
8. TADs（Tiny Acts of Discovery）：他のルールが当てはまらない時の最終手段として、検証を目的とした最小スパイクに分割

出力は2〜3個の分割案＋リスク・前提・次の一手という形式で返る。納期から逆算して「どこを諦めれば締め切りに間に合うか」を冷静に提示できるため、エンジニアとの会議で武器になる。

# 分割案 A: ワークフロー段階による分割
- US-101: 登録フォームの送信機能（Phase 1）
- US-102: 管理者承認フロー（Phase 2）
- US-103: 自動メール通知（Phase 3）

# リスク
- US-101単独リリース時、承認なしの登録が滞留する可能性
- DBスキーマがPhase 2/3で変更される前提

# 次の一手
1. リリース順序を決める
2. 各ストーリーのAcceptance Criteriaを生成する
3. リリーススライス（MVP境界）を引く

2. framing-the-problem-statement.md：問題を再定義してスコープを絞る

「I am／Trying to／But／Because／Which makes me feel」という5節構成で問題を物語化させるプロンプト。スコープが膨らみ続ける根本原因は「何を解決したいか」が曖昧なことが多い。これに対して、ペルソナを起点に問題の核を強制的に絞り込む。

I am: 月末締め作業の経理マネージャー
Trying to: 残業20時間以内で締め作業を完了させたい
But: 取引先からの請求書フォーマットが30種類あり手動補正が必要
Because: 統一フォーマット強制は取引先との関係上できない
Which makes me feel: 自分のキャリアを締め作業に削られている消耗感

ここまで絞れれば、機能の要件は「30種類のフォーマット自動補正」に自ずと縮約される。スコープクリープを起こす要件追加の多くは、この再フレーミングに通せば「対象外」と判定できる。

3. recommendation-canvas-template.md：経営層に「諦め」を売り込むための資料

納期延期やスコープ削減を経営層に飲ませるには、感情論ではなく意思決定資料が要る。このキャンバスはProductsideのAI Innovation for Product Managers由来で、4ブロックで構成される。

• Discovery & Definition：プロダクトアウトカム・問題ステートメント・解決仮説
• Strategy & Positioning：価値提案・差別化・PESTEL観点のリスク
• Validation & Justification：Tiny Acts of Discovery（小さな検証）・Proof-of-Life（仮説が生きている証拠）
• Execution：SMART成功指標・次の5ステップ

「これを削ると何が起きるか／削らないと何が崩れるか」をPESTEL（Political／Economic／Social／Technological／Environmental／Legal）の観点で並べることで、経営層が意思決定する材料として成立する。納期延期の交渉に持ち込む前に必ず通したい。

4. eol-for-a-product-message.md：機能を畳む時の対外メッセージを9セクションで生成

「炎上を未然に防ぐ」観点で見落とされがちなのがEOL（End of Life）通知だ。古い機能や派生プロダクトを畳めず保守工数が膨れ上がり、結果として新規開発の納期を圧迫する——という構造的な問題に効く。

このプロンプトは9セクションでEOLメッセージを生成する。

1. プロダクト変遷ナラティブ（撤退ではなく進化として位置づけ）
2. 現状コンテキスト（何を畳むのか）
3. 顧客への影響（透明に告知）
4. 移行先ソリューション（代替の提示）
5. 差別化と継続性（残るものと改善されるもの）
6. サポートと次のステップ
7. タイムライン（具体的なマイルストーン）
8. CTA（顧客が次に取る行動）
9. 検証すべき前提

出力はエンタープライズ顧客／中小顧客／社内サポート／経営層エスカレーションの4セグメント向けに使い分けられる設計。撤退戦が下手なPMが多い日本企業ほど、このテンプレの再利用価値は高い。

5. strategic-scrum-team-session-kickoff.md：キックオフで遅延を予防する

炎上の多くは「キックオフが雑」に起因する。このプロンプトは6コンテキストの問いかけ（イニシアチブの枠／ペルソナ／JTBD／ビジネス整合／プロダクトアウトカム／成功指標）でキックオフを構造化する。さらに7つの戦略的な柱（プロダクトビジョン整合・協調マインド・アジリティ・価値提供・自己組織化・継続学習・GTM成功）でチームを揃える。

要件の解像度を計画段階で上げきることで、スプリント中盤での「やっぱり違った」を撲滅する。納期遅延の最大要因が後工程ではなく仕様の認識ズレであるという経験則に直接効くプロンプトだ。

系統B：心理的負荷を逃がす「カタルシス系」3プロンプト

/resumes-resignations-reactions/ 配下の3ファイルは、READMEで「PMが向き合う矛盾するステークホルダー優先順位／無理な納期要求／HiPPO意思決定／スコープクリープ／燃え尽きサイクル」を扱うと明記されている。ただし解決ではなく、皮肉な創作で受け流す設計だ。

1. Glassdoor Review プロンプト：1スターレビュー風の「退職前の供養」

ボイスは「サティリカル・ドライ・極限まで疲弊」。Davidアッテンボロー（自然ドキュメンタリー）の語り口で燃え尽きた管理職を観察するスタイルに、Amazon商品レビューとSubstack辛口記事の感触を混ぜる。

ユーザーは3つの質問に答えるだけ。

1. 会社名
2. もっとも不条理なリーダーシップ行動（例：メンタルヘルス福利厚生をSlackボットに置換）
3. 日々の生存メカニズム（Slackミーム、退廃的な付箋儀式など）

出力は5つの語りビートで構成された1スターレビュー。「だまし討ちのように温かい導入→2行目で皮肉が始まる」展開、終盤の決め台詞「Would not recommend, unless you enjoy gaslighting yourself」。これは怒りを精密な皮肉に変換する装置で、退職届を出す前に書き切ることで「怒りを生のまま社内に持ち込まない」効果がある。

2. LinkedIn Lifestyle Influencer Article プロンプト：レイオフ後ポエムを反転攻撃

「人員削減をrealignment of intentionalityと言い換える」式の偽善的なリーダーポストをパロディ化する。スタイル指示は「Reid Hoffmanがオーツミルクラテ3杯を飲んだ後のhustle-poetry」＋ダグラス・アダムズ／ジョセフ・ヘラー／テリー・サザーン／スコット・アダムズの不条理文学を混合。

約600語のフェイクLinkedIn記事を生成する。セクション見出しは衝撃の冒頭→戦略的リフレーム→翻訳の瞬間→引いて見たトレンド分析という影響力者構文。レイオフを「成長」「明晰さ」「変革」に塗り替える最悪のリスト記事を意図的に書かせることで、企業メッセージと現実の乖離を可視化する。

PM自身がこれを書く意義は、「自分は同じ偽善ポストを書かない」という負の見本を作る点にある。エンプロイヤーブランディングを担うPMの倫理的なリマインダーとして機能する。

3. Dear John Letter プロンプト：解雇される前に先に振る

レイオフされたPMが「お前が私を解雇したのではない、私がお前と別れた」と書く決別の手紙。約400語、5名のナレーター人格から選ぶ。

構造は冒頭の反転（自分が振った設定）→感情的離脱の瞬間→不条理な職場の悲しみ→プロ意識の演技を見破る→静かな破壊行為→遅効性の捨て台詞→退職金への乾いた感謝。

「先に振った」という構図を取ることで、レイオフのコントロール不能感を創作によるコントロール感に変換する。これは欧米PMコミュニティの療法的ユーモア文化の典型で、日本の現場には馴染みが薄いが、英語環境で働くPMには有効に機能する。

なぜ「直接的な火消しプロンプト」がないのか

product-manager-promptsの設計者であるDean Petersは、「火消しはAIではなく組織が担うべき」という思想に立っているとリポジトリ全体から読み取れる。Jobs-to-be-Done・User Story Splitting・Recommendation Canvasのような上流の問題定義を強化することで、そもそも炎上の発生確率を下げる。それでも炎上した時はユーモアに逃がすことで、PM個人の心理的安全を守る。

この設計は、AIを「瞬間的な救済装置」ではなく「長期的な思考のパートナー」として位置づける哲学を反映している。日本のPMが「炎上対応プロンプトが欲しい」と感じた時点で、プロセスの上流に問題があることのシグナルとして読み替えるのが正しい使い方だ。

自作プロンプトとの違い：信頼性の根拠

PMがChatGPTで自作したプロンプトと、product-manager-promptsには明確な差がある。

リポジトリには182コミットのバージョン履歴があり、コミュニティから181のフォークと多数のIssue／PRが寄せられている。PMフレームワークの専門家集団によるレビューを通過したプロンプトとして、自作プロンプトにはない裏付けがある。

まとめ：PM業務にもAIエンジニアリングの作法を

product-manager-promptsはPM業務を「個人の勘と経験」から「再現可能な型」に引き上げるOSSだ。Mike Cohn・Geoffrey Moore・Amazonといった検証済みのフレームワークをLLMに直結することで、PMはステークホルダー要望に振り回される時間を減らし、戦略的思考に集中できるようになる。

エンジニア向けのClaude Code、デザイナー向けのawesome-design-mdに続く「ロール特化プロンプト集」第3の柱として、2026年のチーム開発に欠かせない存在になりそうだ。

参照ソース

• deanpeters/product-manager-prompts (GitHub)
• Jobs-to-be-Done Framework — Strategyzer
• User Stories Applied — Mike Cohn
• Crossing the Chasm — Geoffrey Moore
• Working Backwards — Amazon Press Release Approach
• PESTEL Analysis Framework
• Behavior Driven Development (Gherkin) — Cucumber