プロダクトマネージャーエージェント：機能を作る前に、課題と優先度を決める

プロダクトマネジメントを分解する

プロダクトマネージャーは、要望をそのまま開発チケットに変換する人ではない。顧客課題、事業目標、開発制約、リスクを見比べ、何を作るべきか、何を作らないべきかを整理する職能である。

分解した能力	AIの役割	成果物
課題整理	顧客要望を課題、原因、代替手段に分ける	課題メモ
要求管理	要望、バグ、改善案を分類する	要求バックログ
優先度設計	事業効果、顧客影響、工数、リスクで比較する	優先順位案
仕様化	ユースケース、受け入れ条件、例外を整理する	PRD、仕様ドラフト
リリース判断	何を出し、何を延期するか整理する	リリース判定メモ
連携	CS、営業、開発、デザインの論点を接続する	部門横断メモ

Role

基本ロールは「プロダクト企画・仕様整理エージェント」とする。

顧客要望を課題単位に分解する
仕様ドラフトと受け入れ条件を作る
優先順位の比較材料を作る
リリース前の論点を整理する
営業、CS、開発、デザインからの情報を統合する

最終的なロードマップ、価格、リリース可否、撤退判断、重要顧客への約束は人間に戻す。

Tools

Tool	用途
issue管理	要望、バグ、仕様、進捗の確認
プロダクト分析	利用状況、ファネル、機能利用率の確認
CRM/CSツール	顧客要望、解約理由、商談理由の確認
ドキュメント検索	PRD、仕様書、過去決定ログの参照
デザインツール	画面案、ユーザーフロー、レビューコメントの参照
Git/CI	実装状況、リリース対象、変更差分の確認

Thinking

思考法	チェックする問い
Problem/Solution分離	要望は課題か、解決案か
顧客影響	誰のどの業務が変わるか
事業効果	売上、継続率、効率、差別化のどれに効くか
実装負荷	工数、技術負債、運用負荷はどれほどか
代替策	作らずに解決できる方法はあるか
リリースリスク	出すことで壊れる体験や業務はないか

Output

項目	内容
課題	顧客、状況、困りごと
背景	データ、要望、商談、問い合わせ
仕様案	ユースケース、受け入れ条件、例外
優先度	効果、工数、リスク、期限
未確認	顧客、開発、法務、CSに聞くこと
リリース論点	公開範囲、告知、サポート、計測

KPI

要望の課題分類率
PRD作成時間
受け入れ条件未定義のissue数
リリース後の手戻り数
顧客要望から仕様化までの日数
ロードマップ上の未検証仮説数

エスカレーション

ロードマップや価格に影響する
重要顧客への約束が必要
法務、セキュリティ、会計、労務に関わる
開発工数が大きい、または戻しにくい
既存顧客の業務を壊す可能性がある

発生しうる業務

頻度	業務	AIに任せる粒度
日次	要望確認、issue整理、仕様質問の回答補助	課題分類、回答案
週次	優先度見直し、開発進捗、顧客影響確認	週次PdMメモ
月次	ロードマップ、KPI、リリース振り返り	施策評価メモ
随時	新機能企画、障害後改善、重要顧客要望	PRD、論点表

学習方法

学習材料	学ぶこと
顧客要望	課題の頻度、深さ、顧客属性
プロダクトログ	実際の利用、離脱、未利用
商談・CS記録	売れる理由、解約理由
過去PRD	仕様粒度、受け入れ条件
リリース振り返り	手戻り、障害、反応

能力の磨き方

要望をそのまま仕様にした失敗例をナレッジ化する
リリース後に、期待KPIと実績を比較する
人間が追加した受け入れ条件をテンプレートへ戻す
優先度案が採用されたか、却下されたかを理由つきで残す
月1回、ロードマップ上の仮説を削る

作り方

要望DBを課題、顧客、重要度、出典で整理する
PRDテンプレートを作る
受け入れ条件を必須項目にする
issue管理、CS、分析ツールを参照させる
リリース判断は承認制にする
リリース後の振り返りを学習材料に戻す

作れない場合は、「要望分類bot」「PRD下書きbot」「優先度比較bot」「リリース判定bot」に分ける。

最小実装

最初から自律実行させるのではなく、読み取り、下書き、承認付き更新の順に広げる。プロダクトマネージャーエージェントの最小実装は、顧客課題、要求、仕様、優先度、リリース論点を整理するための「入力を読む場所」「出力を残す場所」「人間が承認する場所」を固定することである。

層	最小構成
入力	issue管理、プロダクト分析、CRM、CSツール、デザインツール、Gitから読み取り専用で参照する
処理	事実、推測、未確認、次アクションを分けて整理する
承認	外部送信、重要判断、台帳更新、金銭・契約・人事に関わる操作は人間承認にする
記録	出力、採否、修正理由、次回改善点を同じ場所に残す

入力データ

顧客要望、問い合わせ、商談理由
利用ログ、ファネル、解約理由
開発工数、既存仕様、制約
ロードマップ、事業KPI、リリース期限

入力データには、取得日、参照元、更新者を残す。古い情報や未確認情報を混ぜると、AIはもっともらしいが危ない判断を出す。

出力フォーマット

フィールド	内容
`problem`	顧客課題
`requirements`	要求と受け入れ条件
`priority`	効果、工数、リスクによる優先度
`prd`	仕様ドラフト
`release`	リリース論点
`unknowns`	未確認事項、追加で人間が見る点
`human_review`	承認者、判断期限、エスカレーション条件

この形式で残すと、後から「AIが何を見て、何を出し、人間がどこを直したか」を追える。

サンプルプロンプト

あなたはプロダクトマネージャーエージェントです。
目的は「顧客課題、要求、仕様、優先度、リリース論点を整理する」ことです。

入力:
- 対象: [対象名]
- 参照データ: [参照元]
- 期限: [期限]
- 制約: [承認条件、禁止事項、守るべきルール]

指示:
1. 事実、推測、未確認事項を分けてください。
2. 出力フォーマットに沿って整理してください。
3. 判断できない点を無理に結論づけず、human_reviewに戻してください。
4. 外部送信、重要更新、金銭・契約・人事に関わる操作は実行せず、承認依頼にしてください。

出力:
- 要約
- 構造化データ
- 次アクション
- human_review

ワークフロー

要望を課題と解決案に分ける
事業効果、顧客影響、工数で優先度を比較する
PRDと受け入れ条件を作る
リリース可否とロードマップ変更は人間に戻す

この流れを固定すると、AIは単発の相談相手ではなく、業務の一部として改善できる。

失敗パターン

要望をそのまま仕様化する
声の大きい顧客だけで優先度を決める
リリース後の計測を設計しない

失敗パターンは、禁止事項としてプロンプトに入れるだけでは足りない。出力レビュー時に「今回どの失敗に近かったか」を記録し、次の入力データや評価基準へ戻す。

評価ルーブリック

課題と解決案が分離されている
受け入れ条件がテスト可能
優先度に根拠がある
事実、推測、未確認が分離されている
人間に戻すべき判断がhuman_reviewに出ている

5段階評価にする場合は、3を「人間が軽く直せば使える」、4を「そのまま業務で使える」、5を「次回のテンプレートに採用できる」と定義する。