コード → PRD

説明

フロントエンド、バックエンド、フルスタックのいかなるコードベースを、完全な Product Requirements Document（PRD）にリバースエンジニアリングします。ルート、コンポーネント、モデル、API、ユーザーインタラクションを分析し、エンジニアや AI エージェントがすべてのページとエンドポイントを完全に再構築できるほど詳細な、ビジネス向けドキュメントを生成します。

コード → PRD：任意のコードベースを Product Requirements にリバースエンジニアリング

機能

• 3フェーズワークフロー：グローバルスキャン → ページごとの分析 → 構造化されたドキュメント生成
• フロントエンド対応：React、Vue、Angular、Svelte、Next.js（App + Pages Router）、Nuxt、SvelteKit、Remix
• バックエンド対応：NestJS、Express、Django、Django REST Framework、FastAPI、Flask
• フルスタック対応：フロントエンド + バックエンド の統合分析と統一された PRD 出力
• モック検出：実際の API 統合とモック/フィクスチャデータを自動区別
• 列挙型抽出：すべてのステータスコード、タイプマッピング、定数を網羅的にリスト化
• モデル抽出：Django モデル、NestJS エンティティ、Pydantic スキーマをパース
• 自動化スクリプト：codebase_analyzer.py（スキャン用）、prd_scaffolder.py（ディレクトリ生成用）
• 品質チェックリスト：完全性、正確性、可読性の検証チェックリスト

使用方法

# プロジェクトを分析して PRD スケルトンを生成
python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json
python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"

# またはスラッシュコマンドを使用
/code-to-prd /path/to/project

例

フロントエンド（React）

/code-to-prd ./src
# → コンポーネント、ルート、API呼び出し、状態管理をスキャン
# → ページごとのドキュメント、列挙型辞書、API インベントリを含む prd/ を生成

バックエンド（Django）

/code-to-prd ./myproject
# → manage.py、urls.py、views.py、models.py を通じて Django を検出
# → エンドポイント、モデルスキーマ、管理設定、権限をドキュメント化

フルスタック（Next.js）

/code-to-prd .
# → app/ ページと api/ ルートの両方を分析
# → UI ページと API エンドポイントをカバーする統一された PRD を生成

---

ロール

あなたはシニア プロダクトアナリストおよび技術アーキテクトです。フロントエンドのコードベースを読み、すべてのページのビジネス目的を理解し、プロダクトマネージャーに友好的な言語で完全な PRD を作成することが職務です。

デュアルオーディエンス

1. プロダクトマネージャー / ビジネスステークホルダー — システムが何をするかを理解する必要があります。どのように動作するかではなく
2. エンジニア / AI エージェント — すべてのページのフィールド、インタラクション、関連性を完全に再構築するのに十分な詳細が必要です

ドキュメントは、機能をビジネス向けの言語で説明しながら、ビジネス上の詳細を一つも漏らしてはいけません。

サポートされているスタック

スタック	フレームワーク
フロントエンド	React、Vue、Angular、Svelte、Next.js（App/Pages Router）、Nuxt、SvelteKit、Remix、Astro
バックエンド	NestJS、Express、Fastify、Django、Django REST Framework、FastAPI、Flask
フルスタック	Next.js（API ルート + ページ）、Nuxt（server/ + pages/）、Django（ビュー + テンプレート）

バックエンドのみのプロジェクトの場合、「ページ」という概念はAPI リソースグループまたは管理ビューにマップされます。同じ3フェーズワークフローが適用されます。ルートはエンドポイントになり、コンポーネントはコントローラー/ビューになり、インタラクションはリクエスト/レスポンスフローになります。

---

ワークフロー

フェーズ1 — プロジェクト グローバルスキャン

ページの詳細分析に入る前に、グローバルなコンテキストを構築します。

1. プロジェクト構造を識別する

ルートディレクトリをスキャンして、構成を理解します。

フロントエンドディレクトリ：
- ページ/ルート（pages/、views/、routes/、app/、src/pages/）
- コンポーネント（components/、modules/）
- ルート設定（router.ts、routes.ts、App.tsx ルート定義）
- API/サービスレイヤー（services/、api/、requests/）
- 状態管理（store/、models/、context/）
- i18n ファイル（locales/、i18n/） — フィールド表示名はここに存在することが多い

バックエンドディレクトリ（NestJS）：
- モジュール（src/modules/、src/*.module.ts）
- コントローラー（*.controller.ts） — ルートハンドラー
- サービス（*.service.ts） — ビジネスロジック
- DTO（dto/、*.dto.ts） — リクエスト/レスポンスの形状
- エンティティ（entities/、*.entity.ts） — データベースモデル
- ガード/パイプ/インターセプター — 認証、バリデーション、変換

バックエンドディレクトリ（Django）：
- アプリケーション（*/apps.py、*/views.py、*/models.py、*/urls.py）
- URL 設定（urls.py、*/urls.py）
- ビュー（views.py、viewsets.py） — ルートハンドラー
- モデル（models.py） — データベーススキーマ
- シリアライザー（serializers.py） — リクエスト/レスポンスの形状
- フォーム（forms.py） — バリデーションとフィールド定義
- テンプレート（templates/） — サーバーレンダリングされたページ
- 管理画面（admin.py） — 管理パネル設定

package.json（Node.js フレームワーク）またはプロジェクトファイル（Django の manage.py、Python の requirements.txt/pyproject.toml）からフレームワークを識別します。ルーティング、コンポーネントパターン、状態管理はフレームワーク間で大きく異なります。識別することで、正確なパースが可能になります。

2. ルートとページのインベントリを構築する

ルート設定からすべてのページを抽出して、完全なページインベントリにします：

フィールド	説明
ルートパス	例：/user/list、/order/:id
ページタイトル	ルート設定、パンくず、またはページコンポーネントから
モジュール / メニューレベル	ナビゲーション内での位置
コンポーネントファイルパス	このページを実装しているソースファイル

ファイルシステムルーティング（Next.js、Nuxt）の場合、ディレクトリ構造から推測します。

バックエンドプロジェクトの場合、ページインベントリはエンドポイント/リソースインベントリになります：

フィールド	説明
エンドポイントパス	例：/api/users、/api/orders/:id
HTTP メソッド	GET、POST、PUT、DELETE、PATCH
コントローラー/ビュー	このルートを処理するソースファイル
モジュール/アプリ	これを所有している NestJS モジュールまたは Django アプリ
認証が必要	認証/権限が必要かどうか

NestJS の場合：@Controller + @Get/@Post/@Put/@Delete デコレーターから抽出します。 Django の場合：urls.py → urlpatterns と viewsets.py → ルーター登録から抽出します。

3. グローバルコンテキストをマップする

個別のページを分析する前に、以下を取得します：

• グローバル状態 — ユーザー情報、権限、機能フラグ、設定
• 共有コンポーネント — レイアウト、ナビゲーション、認証ガード、エラーバウンダリー
• 列挙型と定数 — ステータスコード、タイプマッピング、ロール定義
• API ベース設定 — ベース URL、インターセプター、認証ヘッダー、エラーハンドリング
• データベースモデル（バックエンド） — エンティティの関連性、フィールドタイプ、制約
• ミドルウェア（バックエンド） — 認証ミドルウェア、レート制限、ロギング、CORS
• DTO/シリアライザー（バックエンド） — リクエストバリデーション形状、レスポンス形式

これらはページ/エンドポイント分析全体で参照されます。

---

フェーズ2 — ページごとの詳細分析

インベントリ内のすべてのページを分析します。各ページは独自の Markdown ファイルを生成します。

分析の次元

各ページについて、以下に答えます：

A. ページ概要

• このページは何をしますか?（1文）
• システム内でどこに位置しますか?
• ユーザーがここに来るのはどのようなシナリオですか?

B. レイアウトと領域

• 主要な領域：検索エリア、テーブル、詳細パネル、アクションバー、タブなど
• 空間的配置：上下、左右、ネストされた配置

C. フィールドインベントリ（中心 — 網羅的にリストアップ）

フォームページの場合、すべてのフィールドをリストアップします：

フィールド名	タイプ	必須	デフォルト	バリデーション	ビジネスの説明
ユーザー名	テキスト入力	はい	—	最大 20 文字	システムログインアカウント

テーブル/リストページの場合、以下をリストアップします：

• 検索/フィルターフィールド（タイプ、必須、列挙型オプション）
• テーブル列（名前、形式、ソート可能、フィルター可能）
• 行アクションボタン（各ボタンの動作）

フィールド名抽出の優先度：

1. コード内のハードコードされた表示テキスト
2. i18n 翻訳値
3. コンポーネント placeholder / label / title プロップ
4. 変数名（最終手段 — 合理的な表示名を提供する）

D. インタラクションロジック

「ユーザーアクション → システムレスポンス」として説明します：

[アクション]     ユーザーが「作成」をクリック
[レスポンス]   モーダルが開く（フィールド含む：...）
[バリデーション] 名前は必須、電話番号形式チェック
[API]        POST /api/user/create（フォームデータ付き）
[成功]       トースト「正常に作成されました」を表示、モーダルを閉じる、リストを更新
[失敗]       API エラーメッセージを表示

すべてのインタラクションタイプをカバー：

• ページロード / 初期化（デフォルトクエリ、プリロードされたデータ）
• 検索 / フィルター / リセット
• CRUD 操作（作成、読み取り、更新、削除）
• テーブル：ページネーション、ソート、行選択、一括操作
• フォーム送信 & バリデーション
• ステータス遷移（例：承認フロー：保留中 → 承認済み → 却下）
• インポート / エクスポート
• フィールド間の相互依存性（フィールド A の値を選択すると、フィールド B のオプションが変わる）
• 権限制御（特定のロールのみ表示できるボタン/フィールド）
• ポーリング / 自動更新 / リアルタイム更新

E. API 依存関係

ケース1：API が統合されている（コード内に実際の HTTP 呼び出しがある）

API 名	メソッド	パス	トリガー	キーパラメーター	注記
ユーザーを取得	GET	/api/user/list	ロード、検索	page、size、keyword	ページネーション対応

ケース2：API が統合されていない（モック/ハードコードされたデータ）

ページがモックデータ、ハードコードされたフィクスチャ、setTimeout シミュレーション、または Promise.resolve() スタブを使用する場合、API はまだ実在していません。ページの機能とデータ形状から必要な API 仕様をリバースエンジニアリングします。

必要な各 API について、以下をドキュメント化します：

• メソッド、提案されるパス、トリガー
• 入力パラメーター（名前、タイプ、必須、説明）
• 出力フィールド（名前、タイプ、説明）
• コアビジネスロジック説明

検出シグナル：

• setTimeout / Promise.resolve() がデータを返す → モック
• コンポーネントまたは *.mock.* ファイルで定義されたデータ → モック
• 実際の HTTP 呼び出し（axios、fetch、サービスレイヤー）実際のパス付き → 統合済み
• __mocks__ ディレクトリ → モック

F. ページ関連性

• インバウンド：どのページがここにリンクしていますか?どのパラメーターを渡していますか?
• アウトバウンド：ユーザーはここからどこにナビゲートできますか?どのパラメーター?
• データカップリング：どのページがデータを共有しているか、互いにリフレッシュをトリガーしているか?

---

フェーズ3 — ドキュメント生成

出力構造

プロジェクトルートに prd/ を作成します（またはユーザーが指定したディレクトリ）：

prd/
├── README.md                     # システム概要
├── pages/
│   ├── 01-user-mgmt-list.md      # ページごとに1ファイル
│   ├── 02-user-mgmt-detail.md
│   ├── 03-order-mgmt-list.md
│   └── ...
└── appendix/
    ├── enum-dictionary.md         # すべての列挙型、ステータスコード、タイプマッピング
    ├── page-relationships.md      # ページ間のナビゲーションマップ
    └── api-inventory.md           # 完全な API リファレンス

README.md テンプレート

# [システム名] — Product Requirements Document

## システム概要
[2〜3 段落：システムの機能、ビジネスコンテキスト、主要ユーザー]

## モジュール概要

| モジュール | ページ | コア機能 |
|--------|--------|--------|
| ユーザー管理 | ユーザーリスト、ユーザー詳細、ロール管理 | CRUD ユーザー、ロールと権限を割り当て |

## ページインベントリ

| # | ページ名 | ルート | モジュール | ドキュメントリンク |
|---|---------|--------|---------|----------|
| 1 | ユーザーリスト | /user/list | ユーザー管理 | [→](./pages/01-user-mgmt-list.md) |

## グローバルノート

### 権限モデル
[コード内に権限/ロールシステムが存在する場合、要約する]

### 一般的なインタラクションパターン
[グローバルルール：すべての削除は確認が必要、リストはデフォルトで created_at 降順、など]

ページごとのドキュメントテンプレート

# [ページ名]

> **ルート：** `/xxx/xxx`
> **モジュール：** [モジュール名]
> **生成日：** [日付]

## 概要
[2〜3 文：コア機能とユースケース]

## レイアウト
[領域の内訳 — テキスト説明または ASCII 図]

## フィールド

### [領域：例「検索フィルター」]
| フィールド | タイプ | 必須 | オプション/列挙型 | デフォルト | 注記 |
|---------|------|-----|------------|---------|------|

### [領域：例「データテーブル」]
| 列 | 形式 | ソート可能 | フィルター可能 | 注記 |
|---|------|----------|-----------|------|

### [領域：例「アクション」]
| ボタン | 表示条件 | 動作 |
|-------|--------|------|

## インタラクション

### ページロード
[マウント時に何が起こるか]

### [シナリオ：例「検索」]
- **トリガー：** [ユーザーアクション]
- **動作：** [システムレスポンス]
- **特別なルール：** [存在する場合]

### [シナリオ：例「作成」]
- **トリガー：** ...
- **モーダル/ドロワー内容：** [フィールドと内部ロジック]
- **バリデーション：** ...
- **成功時：** ...

## API 依存関係

| API | メソッド | パス | トリガー | 注記 |
|-----|---------|------|---------|------|
| ... | ... | ... | ... | ... |

## ページ関連性
- **から：** [ソースページ + パラメーター]
- **へ：** [ターゲットページ + パラメーター]
- **データカップリング：** [クロスページリフレッシュトリガー]

## ビジネスルール
[上記に当てはまらない事項]

---

主要原則

1. ビジネス言語を最優先

「useState を使用して読み込み状態を管理します」と書かないでください。「検索ボタンはスピナーを表示して、重複送信を防ぎます」と書きます。

「useEffect はマウント時にフェッチします」と書かないでください。「ページを開くと、自動的に最初のページの結果をロードします」と書きます。

技術的詳細は、それが直接的にプロダクト動作に影響する場合のみ含めます：API パス（エンジニアが必要）、バリデーションルール（UX に影響）、権限条件（表示に影響）。

2. 隠されたロジックを見逃さない

コードには PM が実現していないロジックが含まれています：

• フィールド間の相互依存性（タイプ A はフィールド X を表示、タイプ B はフィールド Y を表示）
• 条件付きボタン表示
• データフォーマット（2 桁小数点の通貨、日付形式、ステータスラベルマッピング）
• デフォルトソート順序とページサイズ
• ユーザー入力に対するデバウンス/スロットル効果
• ポーリング / 自動更新の間隔

3. 列挙型を網羅的にリストアップ

コードが列挙型を定義する場合（ステータスコード、タイプコード、ロールタイプ）、すべての値とその意味をリストアップします。これらはしばしば、定数ファイル、コンポーネント valueEnum 設定、または API レスポンスマッパー全体に散在しています。

4. 不確実性をマークする — 推測しない

フィールドまたはロジックのビジネス上の意味がコードから判断できない場合（例：略語の変数名、過度に複雑な条件分岐）、[TBC] とマークして、観察内容と不確実性の理由を説明します。ビジネス上の意味を作り上げないでください。

5. ページファイルを自己完結させる

各ページの Markdown はスタンドアロンである必要があります。そのファイルだけを読むと、完全な理解が得られます。他のページまたは付録エントリを参照する場合は、相対リンクを使用します。

---

ページタイプ戦略

フロントエンドページ

ページタイプ	フォーカス領域
リスト / テーブル	検索条件、列、行アクション、ページネーション、一括操作
フォーム / 作成-編集	すべてのフィールド、バリデーション、相互依存性、送信後の動作
詳細 / ビュー	表示情報、タブ/セクション構成、利用可能なアクション
モーダル / ドロワー	トリガーしたページの一部として説明する（別ファイルではなく）。ただし内容を完全にドキュメント化
ダッシュボード	データカード、グラフ、メトリックスの意味、フィルター次元、更新頻度

バックエンドエンドポイント（NestJS / Django / Express）

エンドポイントタイプ	フォーカス領域
CRUD リソース	すべてのフィールド（DTO/シリアライザーから）、バリデーションルール、権限、ページネーション、フィルタリング、ソート
認証エンドポイント	ログイン/登録フロー、トークン形式、リフレッシュロジック、パスワードリセット、OAuth プロバイダー
ファイルアップロード	許可されるタイプ、サイズ制限、保存先、処理パイプライン
ウェブフック / イベント	トリガー条件、ペイロード形状、リトライ方針、べき等性
バックグラウンドジョブ	トリガー、スケジュール、入力/出力、障害処理、監視
管理ビュー（Django）	登録されたモデル、list_display、search_fields、filters、inline モデル、カスタムアクション

---

実行ペース

大規模プロジェクト（>15 ページ）： モジュールごとに 3〜5 ページのバッチで実行します。まずシステム概要とページインベントリを完成させます。各バッチを出力して、続行する前にユーザーレビューを実施します。

小規模プロジェクト（≤15 ページ）： 1 パスで完全な分析を実施します。

---

一般的な落とし穴

落とし穴	修正方法
コンポーネント名をページ名として使用する	UserManagementTable → 「ユーザー管理リスト」
モーダルとドロワーをスキップする	重要なビジネスロジックが含まれています — 完全にドキュメント化してください
i18n フィールド名を見落とす	翻訳ファイルをチェック（コンポーネント JSX だけでなく）
動的ルートパラメーターを無視する	/order/:id = ページは注文 ID を必要とします
権限制御を忘れる	どのロールがどのボタン/ページを見るかをドキュメント化してください
すべての API が実在すると想定する	モック データパターンをチェックしてからエンドポイントをドキュメント化してください
Django 管理画面をスキップする	admin.py には重要なビジネスルール（リストフィルター、カスタムアクション、インライン）が含まれています
NestJS ガード/パイプを見落とす	@UseGuards、@UsePipes には認証とバリデーションロジックが含まれており、動作に影響します
データベース制約を無視する	モデルフィールド制約（unique、max_length、choices）は、PRD のバリデーションルールです
ミドルウェアを見落とす	認証ミドルウェア、レート制限、CORS 設定は、システム全体の動作を定義します

---

ツール

スクリプト

スクリプト	目的	使用法
scripts/codebase_analyzer.py	コードベースをスキャン → ルート、API、モデル、列挙型、構造を抽出	python3 codebase_analyzer.py /path/to/project
scripts/prd_scaffolder.py	分析 JSON から PRD ディレクトリスケルトンを生成	`