PRP Generator

PRP ジェネレーター（プロダクト要件プロンプト）

概要

PRP ジェネレーターを使うと、製品の機能やシステムの構築に必要なすべての情報をまとめた、包括的なプロダクト要件プロンプトを作成できます。PRP は AI を活用した開発に最適化されており、人間にも AI にも理解しやすい明確な要件を提示します。

主な目的： 漠然としたアイデアを、実行可能で網羅的な要件に変換します。

このスキルを使用する場面

PRP ジェネレーターは、次のような場合に使用します。

• 新しい製品や大規模な機能の開発を始めるとき
• 要件が不明確、または散在しているとき
• 開発チームに要件を伝える必要があるとき
• AI アシスタントを実装に活用するとき
• 発見フェーズから開発フェーズへ移行するとき
• 新しいチームメンバーをプロジェクトに迎えるとき

主な機能

• 要件を標準化された12のセクションに整理する
• プロジェクトの複雑さのパターン（A、B、C）を特定する
• Jobs-to-be-Done 形式でユーザーストーリーを抽出する
• 成功基準と指標を定義する
• 機能要件と非機能要件を文書化する
• 制約、リスク、前提条件をまとめる
• スコープ内とスコープ外を明確にする

ワークフロー

PRP の12セクション構成

完全な PRP は、次の12のセクションで構成されます。

1. プロジェクト概要
2. 問題の説明
3. 成功基準
4. ユーザーストーリー（Jobs-to-be-Done）
5. 機能要件
6. 非機能要件
7. 技術的制約
8. データ要件
9. UI/UX 要件
10. リスクと前提条件
11. スコープ外
12. 未解決の質問

それぞれ詳しく見ていきましょう。

---

1. プロジェクト概要

目的： 全体的な背景とパターン分類を示します

含める内容：

• プロジェクト名と1文での説明
• パターン分類（A、B、またはC）
• 期間の見積もり
• 対象ユーザー
• ビジネス上の背景

例：

Project: Customer Support Chatbot
Pattern: C (AI-Native System)
Timeline: 10-12 weeks
Users: Customer support agents + end customers
Context: Reduce support ticket volume by 40% while maintaining customer satisfaction

---

2. 問題の説明

目的： 解決する問題を明確に定義します

テンプレート：

[User type] faces [problem] when [situation].
This causes [negative outcome].
We know this because [evidence].

例：

Customer support agents face long response times when customers ask common questions about billing, account setup, and feature usage. This causes customer frustration and agent burnout handling repetitive inquiries.

We know this because:
- 60% of tickets are "How do I..." questions
- Average response time is 4 hours
- Agent surveys show 70% of time spent on repetitive questions
- NPS dropped from 45 to 38 in past 6 months

---

3. 成功基準

目的： 測定可能な成果を定義します

構成：

• 主要指標（ノーススター指標）
• 副次指標
• 成功に必要な最低基準

例：

Primary Metric:
- Reduce support ticket volume by 40% within 3 months of launch

Secondary Metrics:
- 80% of common questions answered by AI without escalation
- <2 second response time for AI answers
- >4.0/5.0 user satisfaction rating with AI responses
- 50% reduction in agent time spent on common questions

Minimum Success:
- 30% ticket reduction + 4.0/5.0 satisfaction

---

4. ユーザーストーリー（Jobs-to-be-Done）

目的： Jobs-to-be-Done 形式でユーザーのニーズをまとめます

テンプレート：

When [situation], I want to [action], so I can [outcome].

例：

Customer Stories:
1. When I have a billing question, I want instant answers, so I can resolve issues without waiting.
2. When I'm setting up my account, I want step-by-step guidance, so I don't get stuck.
3. When I need to reset my password, I want a simple self-service flow, so I don't need to contact support.

Agent Stories:
1. When a complex issue arrives, I want context from the AI conversation, so I can help efficiently.
2. When training new agents, I want the AI to handle basics, so I can focus on teaching advanced topics.
3. When customers escalate, I want conversation history, so I don't ask redundant questions.

---

5. 機能要件

目的： システムが実行すべき内容を定義します

カテゴリ：

• 中核機能（P0 - 必須）
• 重要な機能（P1 - あるべき）
• あれば望ましい機能（P2 - あってもよい）

例：

P0 (Core - MVP):
- FR-001: System answers common questions from knowledge base
- FR-002: System escalates to human when confidence is low (<70%)
- FR-003: Agents can see full conversation history
- FR-004: System tracks conversation satisfaction ratings

P1 (Important - Post-MVP):
- FR-005: System learns from agent corrections
- FR-006: System handles multi-turn conversations with context
- FR-007: Agents can override AI suggestions

P2 (Nice-to-have - Future):
- FR-008: System proactively suggests help articles
- FR-009: System detects frustrated customers
- FR-010: Multi-language support

---

6. 非機能要件

目的： システムの性能や動作を定義します

カテゴリ：

• パフォーマンス
• セキュリティ
• スケーラビリティ
• 信頼性
• ユーザビリティ

例：

Performance:
- NFR-001: Response time <2 seconds for 95th percentile
- NFR-002: Handle 100 concurrent conversations
- NFR-003: Knowledge base search <500ms

Security:
- NFR-004: Customer data encrypted at rest and in transit
- NFR-005: SOC2 Type II compliance
- NFR-006: Role-based access control (RBAC)
- NFR-007: Audit logs for all AI responses

Scalability:
- NFR-008: Support 10,000 conversations/day at launch
- NFR-009: Scale to 100,000 conversations/day within 6 months

Reliability:
- NFR-010: 99.9% uptime SLA
- NFR-011: Graceful degradation if AI service unavailable

Usability:
- NFR-012: Agents can use with <10 minutes training
- NFR-013: WCAG 2.1 AA accessibility compliance

---

7. 技術的制約

目的： 技術上の制限と要件を明確にします

含める内容：

• 連携する既存システム
• 技術スタックの要件
• インフラストラクチャの制約
• 予算の制限
• スケジュール上の制約

例：

Integrations:
- Must integrate with existing Zendesk system
- Must use company SSO (Okta)
- Must log to existing Datadog monitoring

Technology Stack:
- Backend: Python (existing team expertise)
- LLM: OpenAI GPT-4 (approved vendor)
- Vector DB: Pinecone or Weaviate (to be decided)
- Frontend: React (existing stack)

Infrastructure:
- Deploy on existing AWS infrastructure
- Use existing CI/CD pipelines (GitHub Actions)

Budget:
- OpenAI API budget: $5,000/month maximum
- Infrastructure: $2,000/month maximum

Timeline:
- MVP must launch within 10 weeks
- Full feature set within 16 weeks

---

8. データ要件

目的： 必要なデータとその管理方法を明確にします

構成：

• データソース
• データモデル
• データのプライバシー
• データの保持

例：

Data Sources:
- Knowledge base articles (500+ articles in Notion)
- Historical support tickets (Zendesk, 2 years)
- Product documentation (GitHub docs)
- FAQ pages (company website)

Data Models:
- Conversations: id, customer_id, agent_id, messages[], status, satisfaction_rating
- Messages: id, sender, text, timestamp, ai_confidence
- Knowledge: id, title, content, embeddings, category, last_updated

Data Privacy:
- PII must be redacted before AI processing
- Conversation data retained for 90 days
- Analytics data aggregated and anonymized
- GDPR right-to-delete compliance

Data Security:
- Encrypt customer data at rest (AES-256)
- Encrypt in transit (TLS 1.3)
- Role-based access to conversation data

---

9. UI/UX 要件

目的： ユーザーとシステムのやり取りを定義します

含める内容：

• ユーザーフロー
• インターフェース要件
• デザイン上の制約
• アクセシビリティのニーズ

例：

Customer Interface:
- Chat widget in bottom-right corner
- Typing indicators and response time estimates
- Clear "Talk to a human" button always visible
- Conversation history accessible for 30 days

Agent Interface:
- Side panel showing AI suggestions
- One-click "Accept AI answer" button
- Edit AI answer before sending
- Flag incorrect responses for retraining
- Dashboard showing AI performance metrics

User Flows:
1. Customer asks question → AI retrieves answer → Displays with confidence
2. Low confidence → Auto-escalate to agent → Agent sees full context
3. Agent corrects AI → System logs for improvement

Design Constraints:
- Match existing brand colors
- Mobile-responsive design
- WCAG 2.1 AA compliant
- Support keyboard navigation

---

10. リスクと前提条件

目的： 想定される障害要因と依存関係を特定します

構成：

• リスクとその軽減計画
• 検証が必要な前提条件
• 外部要因への依存関係

例：

Risks:
1. AI hallucination risk
   - Mitigation: Confidence thresholds, human review for low confidence

2. Knowledge base quality risk
   - Mitigation: Content audit before launch, SME review of top 100 articles

3. User adoption risk (agents don't trust AI)
   - Mitigation: Gradual rollout, agent training, show accuracy metrics

4. API cost overruns
   - Mitigation: Aggressive caching, token limits, usage monitoring

Assumptions:
1. Customers will accept AI responses (validate with beta test)
2. Knowledge base is accurate and up-to-date (audit required)
3. 80% of questions can be answered with existing knowledge
4. OpenAI API latency is acceptable (<2s)

Dependencies:
1. Access to Zendesk API (need approval from IT)
2. Knowledge base export from Notion
3. OpenAI API quota increase (currently limited)
4. Agent availability for training and feedback

---

11. スコープ外

目的： 構築しないものを明確に示します

重要な理由： スコープの拡大を防ぎ、期待値を設定します

例：

Out of Scope for MVP:
- Voice/phone support integration (post-MVP)
- Multi-language support (Phase 2)
- Integration with CRM system (future)
- Custom AI model training (using OpenAI)
- Mobile app (web only initially)
- Proactive outreach (reactive support only)
- Sentiment analysis dashboard (future analytics)
- Agent performance scoring (v2 feature)

Explicitly NOT Building:
- Custom LLM training (too expensive)
- Real-time translation (complexity vs. value)
- Video call integration (different project)

---

12. 未解決の質問

目的： 回答が必要な不明点を記録します

構成：

• 質問
• 回答できる人
• 回答が必要な期限
• 回答が得られなかった場合の影響

例：

Open Questions:

Q1: What's acceptable AI error rate for customers?
- Who: Product Manager + Customer Success lead
- Deadline: Week 2 (before architecture finalized)
- Impact: Determines confidence thresholds and escalation flow

Q2: Can we access historical conversation sentiment data?
- Who: Data team
- Deadline: Week 3 (before training data collection)
- Impact: Improves AI tone matching

Q3: What's our Zendesk API rate limit?
- Who: IT/Infrastructure
- Deadline: Week 1 (critical for architecture)
- Impact: May need caching strategy

Q4: Do we have budget for Pinecone or need open-source vector DB?
- Who: Engineering Manager
- Deadline: Week 2 (affects tech stack)
- Impact: Pinecone is easier, open-source is cheaper but more work

Q5: Are agents allowed to edit AI-generated responses?
- Who: Legal/Compliance
- Deadline: Week 4 (before feature development)
- Impact: Affects agent interface design

---

例

例 1：シンプルな機能（パターン A）

プロジェクト： ユーザーダッシュボードに CSV エクスポートを追加

# PRP: CSV Export Feature

## 1. Project Overview

Pattern A (Simple Feature)
Timeline: 2-3 days
Add CSV export button to user dashboard

## 2. Problem Statement

Users need to export data for offline analysis. Currently they must manually copy-paste.

## 3. Success Criteria

- 80% of users who click export get successful download
- <5s export time for typical dataset (1000 rows)

## 4. User Stories

When viewing my data, I want to click "Export CSV", so I can analyze it in Excel.

## 5. Functional Requirements

FR-001: Export button in dashboard toolbar
FR-002: Exports all visible columns
FR-003: Respects current filters
FR-004: Filename includes timestamp

## 6-12. [Abbreviated for Pattern A]

---

例 2：新しいプロダクト（パターン B）

上記の各セクションにあるカスタマーサポートチャットボットの例を参照してください

---

例 3：AI ネイティブシステム（パターン C）

プロジェクト： マルチエージェント型リサーチアシスタント

# PRP: Multi-Agent Research Assistant

## 1. Project Overview

Pattern C (AI-Native System)
Timeline: 14-16 weeks
Multi-agent system with specialized agents for research, synthesis, and fact-checking

## 2. Problem Statement

Researchers spend 60% of their time finding and synthesizing papers instead of analysis. Current tools return overwhelming results without quality filtering.

## 3. Success Criteria

Primary: Reduce research time from 8 hours to 2 hours per topic
Secondary:

- 90% accuracy in paper relevance
- 85% user satisfaction
- <30s for initial results
- 5+ papers synthesized per query

## 4. User Stories

- When I enter a research topic, I want a synthesized summary with sources, so I can quickly understand the landscape
- When results are vague, I want follow-up questions suggested, so I can refine my search
- When I find a relevant paper, I want related papers suggested, so I can explore deeper

## 5. Functional Requirements (AI-specific)

FR-001: Search agent queries multiple academic databases
FR-002: Filter agent scores paper relevance (0-100)
FR-003: Synthesis agent creates 500-word summary
FR-004: Fact-check agent validates key claims
FR-005: Orchestrator coordinates agents and resolves conflicts

## 6. Non-Functional Requirements (AI-specific)

NFR-001: Agent coordination latency <5s
NFR-002: RAG retrieval accuracy >90%
NFR-003: Handle 50 concurrent research sessions
NFR-004: LLM token budget: $10/research session maximum

## 7. Technical Constraints (AI-specific)

- LLM: GPT-4 for synthesis, GPT-3.5 for filtering
- Vector DB: Pinecone (1M vectors)
- Agent framework: LangChain or CrewAI
- Academic APIs: Semantic Scholar, arXiv

## 8. Data Requirements (AI-specific)

- Paper embeddings: title + abstract + keywords
- Citation network graph for related papers
- User research history for personalization
- Fact-check database with verified claims

## 9-12. [Complete as per structure]

---

ベストプラクティス

1. 解決策ではなく、問題から始める

機能要件を書く前に、問題の説明を書きます。「何を」の前に「なぜ」を理解してください。

2. 成功基準を測定可能にする

悪い例：「ユーザーエクスペリエンスを向上させる」 良い例：「タスク完了率を 60％ から 85％ に引き上げる」

3. Jobs-to-be-Done 形式を使用する

機能リクエストだけでなく、ユーザーの意図を捉えます。

4. 対象外を明確にする

「X を作ると思っていた」という後の議論を防げます。

5. 未解決の質問をすべて記録する

不明点を隠さず、明示して解決状況を追跡します。

6. 学びに応じて PRP を更新する

PRP は進化します。新しい情報がわかったら更新してください。

7. ステークホルダーとレビューする

以下のステークホルダーと PRP を検証します。

• プロダクトマネージャー（ビジネス要件）
• エンジニアリングリード（技術的な実現可能性）
• デザイナー（UX 要件）
• セキュリティ担当者（コンプライアンス要件）

---

よくある落とし穴

1. 要件ではなく、解決策を書く

アンチパターン： 「状態管理には React と Redux を使う」 より良い例： 「システムは複数のビュー間でリアルタイム更新を処理できること」

2. 成功基準が曖昧

アンチパターン： 「ユーザーが満足すること」 より良い例： 「NPS スコアが 50 を超え、タスク完了率が 80％ を超えること」

3. 非機能要件が抜けている

アンチパターン： 機能だけを列挙する より良い例： パフォーマンス、セキュリティ、スケーラビリティを含める

4. 知識を前提とする

アンチパターン： 「当然、認証が必要です」 より良い例： すべての要件を明示する

5. パターンの複雑さを混在させる

アンチパターン： パターン A にパターン C のオーケストレーションを組み合わせる より良い例： PRP の深さをパターンの複雑さに合わせる

---

関連スキル

• framework-orchestrator - PRP を使ってパターンと順序を決定します
• product-strategist - PRP 作成前に問題を検証します
• user-researcher - PRP に必要なユーザーインサイトを提供します
• bmad-method - ビジネスモデルを技術要件に反映します
• security-architect - セキュリティ要件のセクション
• api-designer - 技術的制約のセクション

---

成果物

以下を含む完全な PRP ドキュメントです。

1. 12 のセクションすべてに記入済み
2. パターン分類（A、B、C）
3. 主要なステークホルダーによるレビュー済み
4. 担当者と期限を設定して未解決の質問を追跡
5. バージョン管理済み（学びに応じて更新）

---

成功指標

以下を満たしていれば、良い PRP を作成できています。

• 開発者が頻繁に確認を求めずに実装できる
• ステークホルダーがスコープと成功基準に合意している
• リスクと前提条件が早期に明らかになっている
• 対象外が明確になっている
• 未解決の質問に担当者と期限が設定されている
• パターンの複雑さがプロジェクトの実態に合っている

---

覚えておいてください： 良い PRP があれば、開発を整理して進められ、スコープの際限ない拡大を防げます。後で数週間を節約するために、前もって時間をかけてください。