AI Backlog Managerによって、「次に解くべき問題」をデータから選べるようになったとします。
しかし、優先順位が決まっただけでは、まだClaude Codeへそのまま実装を任せることはできません。
「コンバージョンを改善したい」「検索を使いやすくしたい」「このエラーを減らしたい」という課題と、実際にコードへ落とせる仕様の間には、大きな差があるからです。
そこで次に必要になるのが、AI Product Managerです。
Product Analytics、Sentry、User Feedback、GitHub Issue、Business Goalなどを材料に、課題を整理し、User Story、Acceptance Criteria、KPI、Edge Case、Non-Goalsまで含んだPRDへ変換します。
重要なのは、AIへ「それっぽい仕様書を書かせること」ではありません。
実際のEvidenceから問題を定義し、何を作れば成功なのかを明確にしてから開発へ渡すことが今回のテーマです。
この記事でわかること
- AI Product Managerの全体構成
- Product DataからProblem Definitionを作る考え方
- User Story・Acceptance Criteria・KPIの作り方
- 曖昧な仕様を開発へ流さない仕組み
- PRDからAI Tech Lead・Claude Codeへ接続する方法
- 公開後の結果を次の仕様改善へ戻す流れ
結論
AI Product Managerの役割は、アイデアを大量に出すことではありません。実際のユーザー行動・障害・要望・事業目標をEvidenceとして整理し、「誰の、どんな問題を、何のために、どこまで解決するのか」を開発可能な仕様へ変換することです。
今回作るAI Product Manager
今回の全体フローは次のようになります。
Product Analytics ────┐
Sentry Errors ─────────┤
User Feedback ─────────┤
GitHub Issues ─────────┤
Business Goal ─────────┘
↓
AI Backlog Manager
↓
Priority Problem
↓
AI Product Manager
↓
Problem Definition
↓
User Story
↓
PRD
↓
Acceptance Criteria
↓
KPI / Success Metrics
↓
Edge Cases / Non-Goals
↓
Human Approval
↓
AI Tech Lead
↓
Task Decomposition
↓
AI Development TeamAI Backlog Managerが「何を優先するか」を決めるレイヤーなら、AI Product Managerは「何を、どの状態まで作ればよいか」を決めるレイヤーです。
Backlog Itemをそのまま開発へ渡さない
たとえば、次のIssueがあったとします。
モバイルのCheckout Conversionが下がっている。
PostHog:
Conversion -14%
User Feedback:
「購入ボタンが見つけにくい」
Session Replay:
CTAを探してスクロールしているユーザーが多いここからClaude Codeへ「Checkoutを改善して」と渡すと、AIが自由に解釈する範囲が広すぎます。
ボタンを大きくするのか、固定表示するのか、入力フォームを短くするのか、レイアウトを変えるのかが定義されていないためです。
曖昧なIssueをそのまま実装しない
AIの実装能力が高くても、仕様が曖昧なら「正しく間違ったもの」を高速に作る可能性があります。実装前にProblemとSuccess Conditionを固定することが重要です。
最初にProblemを定義する
最初から解決策を考えるのではなく、「何が問題なのか」を整理します。
Problem:
Mobile Checkout Conversion has decreased.
Affected User:
Mobile users reaching checkout.
Observed Evidence:
- Conversion down 14%
- Repeated CTA search behavior
- 38 feedback reports
- Desktop conversion stable
Hypothesis:
CTA visibility may be contributing to abandonment.
Business Impact:
Lost completed purchases.ここで重要なのが、EvidenceとHypothesisを分離することです。
Key Point
「Conversionが14%下がった」はFactですが、「CTAが原因」はHypothesisです。AIにProduct判断をさせるときは、この2つを混ぜないようにします。
誰の問題なのかを明確にする
同じ機能でも、対象ユーザーによって正しい仕様は変わります。
Who
- 新規ユーザー
- 既存ユーザー
- Mobile User
- Admin
Problem
- 迷っている
- 失敗している
- 時間がかかる
- 機能を知らない
Desired Outcome
- 完了率向上
- 時間短縮
- Error減少
- 利用率向上
User Storyへ変換する
Problemが整理できたら、User Storyへ変換します。
As a
mobile user ready to purchase,
I want
to clearly identify the primary checkout action,
so that
I can complete my purchase without searching for the next step.User Storyを書くことで、UIの見た目ではなくユーザーの目的を中心に仕様を考えられます。
PRDの基本構造
AI Product Managerが出力するPRDには、最低でも次の情報を持たせます。
1. Summary
2. Problem
3. Evidence
4. Target User
5. User Story
6. Goal
7. Non-Goals
8. Functional Requirements
9. Acceptance Criteria
10. Success Metrics
11. Edge Cases
12. Risks
13. Dependencies
14. Analytics Events
15. QA Requirements
16. Open QuestionsGoalとNon-Goalsを分ける
AI開発では、何を作るかと同じくらい何を作らないかを決めることが重要です。
Goals
- CTAの視認性を上げる
- Mobile UXを改善する
- 計測を追加する
Non-Goals
- 決済Provider変更
- Checkout全面刷新
- Desktop UI変更
Non-Goalsを明示しておくことで、Claude Codeが善意で変更範囲を広げることを防ぎやすくなります。
Functional Requirementsを作る
次に、実装として必要な振る舞いを定義します。
FR-01
Mobile Checkout画面にPrimary CTAを常時表示する。
FR-02
CTAは現在のCheckout Stepに応じて適切なLabelを表示する。
FR-03
Validation Errorが存在する場合は次Stepへ進まない。
FR-04
CTA click eventをAnalyticsへ送信する。
FR-05
Desktop UIの既存挙動は変更しない。ここまで来ると、実装Agentが自由に判断しなければならない範囲がかなり減ります。
Acceptance Criteriaを作る
仕様が完成したかどうかを判断する条件です。
「いい感じにする」ではなく、テスト可能な表現へ変換します。
AC-01
Mobile viewportでPrimary CTAが表示される。
AC-02
PageをスクロールしてもCTAへアクセスできる。
AC-03
必須入力が不足している場合は次Stepへ進まない。
AC-04
CTAクリック時にanalytics eventが1回送信される。
AC-05
Desktop viewportでは既存Layoutを維持する。
AC-06
既存Checkout E2EがPASSする。重要
Acceptance Criteriaは、そのままUnit TestやPlaywright E2Eの設計へ変換できるレベルまで具体化します。
仕様とTestを最初からつなぐ
従来は、実装が終わったあとに「何をテストするか」を考えるケースもあります。
AI開発では、仕様作成時点でTest Scenarioまで作っておく方が扱いやすくなります。
Requirement
↓
Acceptance Criteria
↓
Test Scenario
↓
Implementation
↓
Playwright
↓
PASS / FAILKPIを実装前に決める
機能を公開してから「成功したのか分からない」という状態を防ぐため、PRDにSuccess Metricsを含めます。
Primary KPI:
Mobile Checkout Conversion
Baseline:
42%
Target:
46%+
Guardrail:
Payment Error Rate must not increase
Observation Period:
14 daysここで初めて、公開後に「この変更は成功したのか」をデータで判断できます。
Guardrail Metricも必要
一つのKPIだけを最適化すると、別の指標を悪化させる可能性があります。
Primary KPI
- Conversion
- Activation
- Retention
Guardrail
- Error Rate
- Refund
- Latency
- Support Contact
Conversionが上がってもPayment Errorが大きく増えていれば、成功とは言えません。
Analytics EventもPRDで定義する
公開後に計測したいなら、実装時点でEventも決めます。
Event:
checkout_primary_cta_clicked
Properties:
- checkout_step
- device_type
- user_type
- experiment_variant
Event:
checkout_completed
Properties:
- device_type
- payment_method
- experiment_variantこうしておけば、開発AgentがTracking実装まで含められます。
Edge Caseを先に洗い出す
通常ケースだけを定義すると、実装後に仕様漏れが見つかりやすくなります。
確認したいEdge Case
- 未ログインユーザー
- Validation Error
- Network Error
- 二重クリック
- Slow Connection
- Mobile Keyboard表示中
- 既存データとの互換性
AIに既存Repositoryも確認させる
Product仕様だけを見てPRDを作ると、現在のArchitectureと合わない仕様になる場合があります。
そこでRepository Contextも入力に加えます。
Product Problem
+
Existing Repository
+
Current Architecture
+
Current APIs
+
Database Schema
+
Existing Tests
↓
AI Product Manager
↓
Feasible PRDただし、Product Managerが細かい実装方法まで決める必要はありません。
Product SpecとTechnical Designを分離する
AI Product ManagerとAI Tech Leadの役割を分けます。
AI Product Manager
- Problem
- User
- Goal
- Requirements
- KPI
AI Tech Lead
- Architecture
- Files
- API Design
- DB Changes
- Task Split
Product Managerは「何を満たすべきか」、Tech Leadは「どう実現するか」を担当します。
Open Questionsを残す
AIが分からないところを勝手に埋めるのではなく、仕様の不確実性をOpen Questionsとして残します。
Q1.
Sticky CTAは全Checkout Stepで表示するか？
Q2.
Existing UserとGuest CheckoutでLabelを変えるか？
Q3.
A/B Testとして公開するか？
Q4.
TabletはMobile仕様に含めるか？不明点を推測で埋めない
重要な仕様に複数の解釈が存在する場合は、AIが勝手に一つを選ぶのではなくOpen QuestionとしてHumanへ戻します。
Specification Readinessを判定する
PRDが完成したら、「開発へ渡してよい状態か」をチェックします。
PRD
↓
Problem Defined?
↓
Target User Defined?
↓
Requirements Clear?
↓
Acceptance Criteria Testable?
↓
KPI Defined?
↓
Open Questions Resolved?
↓
Risk Identified?
ALL PASS
↓
READY FOR DEVELOPMENT
FAIL
↓
RETURN TO PRODUCT REVIEWAI Product ManagerのPrompt例
このBacklog Itemを、
開発可能なPRDへ変換してください。
利用できるContext：
- Backlog Item
- Product Analytics
- User Feedback
- Sentry
- Business Goal
- Existing Repository
- Existing Features
まだコードは変更しないでください。
次を作成してください。
1. Summary
2. Problem Definition
3. Evidence
4. Hypothesis
5. Target User
6. User Story
7. Goals
8. Non-Goals
9. Functional Requirements
10. Acceptance Criteria
11. Success Metrics
12. Guardrail Metrics
13. Analytics Events
14. Edge Cases
15. Dependencies
16. Risks
17. QA Requirements
18. Open Questions
ルール：
・FactとHypothesisを分離する
・Evidenceのない主張を断定しない
・実装方法を必要以上に決めない
・Acceptance CriteriaはTest可能にする
・KPIを必ず定義する
・今回やらないことを明記する
・重要な不明点を推測で埋めない
・曖昧な仕様はOpen Questionへ戻す
・Security / Billing / Auth / Data変更はRiskとして明示するHuman Approvalを残す
AIがPRDを作ったからといって、自動的に開発へ送る必要はありません。
AI Product Manager
↓
Draft PRD
↓
Human Review
│
├── APPROVE
│ ↓
│ READY
│
├── REVISE
│ ↓
│ AI Product Manager
│
└── REJECT人間は文章をゼロから書くのではなく、Problem、Scope、KPI、Riskが正しいかを判断します。
承認済みPRDをGitHub Issueへ変換する
開発へ渡す単位としてGitHub Issueを使う場合、PRDの重要部分をIssueへ変換できます。
Approved PRD
↓
Parent Issue
├── Problem
├── Requirements
├── Acceptance Criteria
├── KPI
├── Risk
└── Dependencies
↓
AI Tech Lead
↓
Sub-Issues
↓
DevelopmentAI Tech LeadがTechnical Designへ変換する
ここから前回作ったAI Development Teamへつながります。
PRD
↓
AI Tech Lead
↓
Architecture Analysis
↓
Task Decomposition
│
├── Frontend
├── Backend
├── Analytics
├── Unit Tests
└── E2E
↓
Dependencies
↓
Parallel DevelopmentProduct SpecとTechnical Planが分離されているため、実装方法を変えてもProduct Goalは維持できます。
Acceptance CriteriaからTaskを作る
各Acceptance Criteriaを、開発とQAへ追跡できるようにします。
Requirement
↓
Acceptance Criteria
↓
Development Task
↓
Test Case
↓
CI / E2E
↓
PASSこれにより「実装は終わったが、どの仕様を満たしたのか分からない」という状態を減らせます。
GitHubのSub-IssueとDependencyを使う
大きなPRDから複数Taskへ分割した場合、Task間には順序があります。
Parent:
Mobile Checkout Improvement
│
├── #301 Analytics Events
│
├── #302 CTA Component
│
├── #303 Validation
│
├── #304 Unit Tests
│
└── #305 E2E
#305
blocked by
#302
#303Taskを階層化し、Dependencyを持たせることで、AI Development Teamが実行可能なTaskを判断しやすくなります。
公開後の検証条件もPRDに含める
AI Product Managerの仕事は、実装仕様を作って終わりではありません。
公開後に何を見るかも決めます。
Release:
Mobile Checkout CTA
Primary KPI:
Checkout Conversion
Guardrail:
Payment Error Rate
Observation:
14 days
Decision:
KEEP
ITERATE
ROLLBACK
INVESTIGATE公開後はPostHogやSentryへ戻る
Productionへ出したあとは、実際の利用データを確認します。
Feature Release
↓
PostHog
├── Conversion
├── Funnel
├── Retention
├── Session Replay
└── Experiment
Sentry
├── Error Rate
└── Regression
User Feedback
↓
Outcome Analysis
↓
AI Product Manager
↓
KEEP / ITERATE / ROLLBACK仕様と実際の結果を比較する
公開前にPRDでKPIを決めているため、結果との比較ができます。
Expected
- Conversion +4%
- Error増加なし
- Mobile改善
Actual
- Conversion +1%
- Error変化なし
- Scroll減少
この差分が、次のBacklog ItemやExperimentになります。
AIに失敗した機能も評価させる
AI開発が高速になるほど、「たくさん作ること」より「効果のなかった変更を早く学習すること」が重要になります。
Hypothesis
↓
Specification
↓
Implementation
↓
Release
↓
Measure
↓
Result
SUCCESS
↓
Keep
PARTIAL
↓
Iterate
FAIL
↓
Learn
↓
New Hypothesis仕様生成を完全自動化しないケース
Product判断には、データだけでは決められないものもあります。
Human Reviewを必須にしたいケース
- 価格・料金体系を変更する
- Business Modelへ影響する
- 個人情報の利用方法を変える
- Auth・Permissionの概念を変更する
- 法令・Complianceが関係する
- 重要顧客との契約へ影響する
- Evidenceが不足している
AI Product Managerを段階的に導入する
-
1
PRD Draft
人間が選んだIssueからAIがPRDの下書きを作ります。
-
2
Evidence連携
AnalyticsやFeedbackを自動でPRDへ追加します。
-
3
KPI生成
公開後に確認するSuccess Metricまで作ります。
-
4
QA連携
Acceptance CriteriaからTest Scenarioを作ります。
-
5
Tech Lead連携
承認済みPRDをTaskへ自動分解します。
-
6
Outcome Learning
公開後の結果を次の仕様改善へ戻します。
Product Organization全体がつながる
ここまでの記事をつなげると、かなり大きなループになります。
Product Data
↓
AI Backlog Manager
↓
Priority Problem
↓
AI Product Manager
↓
PRD / Specification
↓
Human Approval
↓
AI Tech Lead
↓
Task Decomposition
↓
AI Development Team
↓
AI QA
↓
Integration
↓
Human Approval
↓
Production
↓
PostHog / Sentry
↓
Outcome
↓
Product Dataここまで来ると、AIは「コードを書くツール」という位置付けから大きく変わります。
Product Dataを理解し、課題を整理し、仕様を作り、実装し、結果を計測して、次の改善へつなげるところまで、一つのシステムとして扱えるようになります。
OmochiX View
AI時代のProduct Managementでは、仕様書を書く速度そのものより、「実データから正しいProblemを選び、Success Conditionを定義し、その結果を次の意思決定へ戻せるか」が重要になります。AI Product Managerは、そのループを高速化するレイヤーです。
3行まとめ
- AI Product Managerは、Backlog ItemをProblem・User Story・Requirement・Acceptance Criteria・KPIを含むPRDへ変換する
- FactとHypothesisを分け、曖昧な仕様は推測せずOpen QuestionとしてHumanへ戻す
- PRDをAI Tech Lead・Development Team・QAへつなぎ、公開後のOutcomeを次のProduct判断へ戻すことで開発ループが閉じる
次はAIがExperimentまで設計する
PRDを作り、実装し、Productionへ公開できるようになると、次の問題が出てきます。
「いきなり全ユーザーへ公開せず、どの案が本当に良いのか検証できないか」という問題です。
次の記事では、AI Product Managerが複数の改善Hypothesisを作り、Feature Flag、A/B Test、Success Metric、Guardrail Metricを設計し、結果を分析して次の判断へ戻すAI Experiment Managerを作ります。
あわせて読みたい
AI Backlog Managerを作る
Sentry・Analytics・User Feedbackなどから、次に解くべき問題をAIが評価する仕組みを解説します。
あわせて読みたい
複数Claude CodeでAI開発チームを作る
承認された仕様をTaskへ分解し、複数のAIエージェントで並列実装・QA・統合する構成を解説します。
AI開発支援
企画・仕様・開発までAIでつなぎたい方へ
Product Analytics、GitHub、Claude Code、Vercel、Playwrightなどをつなぎ、Backlogから仕様・開発・QA・計測まで循環するAI開発システムを設計します。
出典：GitHub公式ドキュメント / PostHog公式情報 / Anthropic Claude Code公式ドキュメント / Sentry公式ドキュメント
