PRD駆動開発：30以上のPRDでAIエージェントと開発を進める方法

SaasMakerのRalphBlasterワークフローは、1行のチケットから完全なプルリクエストを45分以内に生成します。開発者は実装中にコードを一切触りません。¹

私もこのパターンを試しました。うまくいきます。しかし、デモ動画では見せない失敗の仕方もあります。

TL;DR

過去6ヶ月で、AIエージェントのタスクに30以上のPRDを作成してきました。このパターンは、明確な受入基準を持つ明確に定義されたタスクに対してうまく機能します。CRUDエンドポイント、テストの追加、既存のパターンに沿ったUIコンポーネントなどです。一方で、曖昧な要件、新しいアーキテクチャの判断、反復的な人間の判断を必要とするものには失敗します。私のPRDテンプレートは、シンプルなユーザーストーリー形式から、ファイルの場所、テスト期待値、制約、明示的な「触るな」リストを含む構造化されたドキュメントに進化しました。この進化は、エージェントが曖昧なPRDを予想外の方法で解釈したために起きました。

私が実際に使っているワークフロー

ステップ1：チケットの作成

何をすべきかを平易な言葉で定義します。具体性は当初思っていたよりもはるかに重要です。

曖昧（予測不能な結果を生む）：

Add user preference saving to the settings page.

具体的（予測可能な結果を生む）：

Add dark mode toggle to /settings. Persist to user_preferences
table (column: dark_mode, type: boolean, default: false).
Use existing SettingsForm component. Add toggle below the
notification section. No new dependencies.

2つ目のバージョンはエージェントを十分に制約するため、出力が期待と一致します。1つ目のバージョンでは、新しいReactコンポーネント、3つの新しいnpmパッケージ、そして私が望んでいたデータベース永続化の代わりにlocalStorage実装を使った設定ページが返ってきました。

ステップ2：PRDの生成または作成

私の/prdスキルは、チケットをユーザーストーリー、受入基準、ファイルの場所、テスト期待値を含む構造化されたPRDに変換します。² 典型的なPRDは以下のようになります。

## Story: Add dark mode toggle
**As a** user
**I want to** toggle dark mode from settings
**So that** I can read comfortably in low light

### Acceptance Criteria
- [ ] Toggle appears in SettingsForm below notifications
- [ ] Persists to user_preferences.dark_mode (boolean)
- [ ] Default: false (light mode)
- [ ] Toggle state reflects current DB value on page load

### Files to Modify
- app/routes/settings.py (add dark_mode to form handler)
- app/templates/settings.html (add toggle component)
- app/models/user.py (add dark_mode column if missing)

### Files NOT to Modify
- app/static/css/styles.css (dark mode CSS already exists)
- app/templates/base.html (already reads dark_mode class)

### Test Expectations
- Test toggle persists to database
- Test default value on new user
- Test toggle reflects current state on reload

「Files NOT to Modify」セクションは、テンプレートの最大の進化でした。これがなければ、エージェントは親切に関連ファイルを「改善」し、私が要求も望みもしていない変更を導入してしまいます。

ステップ3：エージェントによる実装

エージェントは隔離されたgitワークツリーで作業し、現在のブランチへの干渉を防ぎます。³

# Create isolated worktree for agent task
git worktree add ../worktrees/dark-mode -b feature/dark-mode

# Agent works in ../worktrees/dark-mode/
# I continue working in main workspace

# Review and cleanup after merge
git worktree remove ../worktrees/dark-mode

私の再帰ガードはエージェントのスポーン動作を監視します。gitセーフティガーディアンはエージェントがフォースプッシュや認証情報のコミットを防止します。これらのフックは自動的に実行されます。実装中にエージェントを監視する必要はありません。

ステップ4：レビュー

エージェントが完了すると通知が届きます。PRDの受入基準に対してdiffをレビューします。すべての基準をクリアしていればマージします。そうでなければ、手動で修正するか、更新されたコンテキストでエージェントを再起動します。⁴

PRD駆動開発がうまくいく場面

明確なデータモデルを持つCRUDエンドポイント。 PRDはモデル、ルート、レスポンス形式を指定します。エージェントは既存のパターンに一致するボイラープレートを生成します。

既存コードへのテスト追加。 「app/content.pyのload_post_by_slugに対して、有効なスラッグ、無効なスラッグ、ファイル欠損のケースをカバーするテストを作成」は、関数がすでに存在し受入基準が客観的であるため、有用なテストを生成します。

既存パターンに沿ったUIコンポーネント。 「ガイドページと同じタブパターンを使って、ブログ一覧ページにカテゴリフィルターを追加」は、エージェントが既存のパターンを参照できるため機能します。

定義されたスキーマによるデータベースマイグレーション。 PRDはカラム、型、デフォルト値、制約を指定します。エージェントはマイグレーションを生成し、モデルを更新します。

PRD駆動開発が失敗する場面

曖昧な要件。 「ブログをもっと良くして」はPRDではありません。エージェントは変更を加えますが、あなたの意図が指定されていないため、意図とは一致しません。

新しいアーキテクチャの判断。 議論システムの合意モデルを設計する必要があったとき、PRDではその判断を捉えることができませんでした。選択肢を探索し、トレードオフを評価し、設計を反復する必要がありました。それにはPRDではなく、私の議論スキルが必要でした。

パフォーマンス最適化。 「ページの読み込みを速くして」にはプロファイリング、計測、反復的な調査が必要です。エージェントはPRDから本番のトラフィックパターンをプロファイルすることはできません。

セキュリティクリティカルなコード。 認証システムのPRDは、正常系を処理するコードを生成します。認証のエッジケース（タイミング攻撃、セッション固定、非標準フローでのCSRF）には、PRDでエンコードできない人間の専門知識が必要です。

PRDテンプレートの進化

バージョン1（1ヶ月目）：シンプルなユーザーストーリー

As a user, I want to save preferences so I can customize my experience.

問題： 曖昧すぎました。エージェントはストレージの仕組み、UIの配置、スコープについて合理的だが間違った仮定をしました。

バージョン2（2ヶ月目）：ファイルの場所を追加

## Story: Save preferences
### Files to Modify
- app/routes/settings.py
- app/templates/settings.html

問題： 改善しましたが、エージェントは依然として許可なく隣接ファイルを「改善」しました。

バージョン3（4ヶ月目）：制約を追加

## Story: Save preferences
### Files to Modify (only these)
- app/routes/settings.py
- app/templates/settings.html
### Constraints
- No new dependencies
- Use existing database models
- Do not modify CSS

問題： 制約がトレーニングデータの「ベストプラクティス」と矛盾する場合、エージェントが制約を無視することがありました。

バージョン4（現在）：明示的な除外リスト＋テスト期待値

現在のテンプレートは「Files NOT to Modify」、明示的なテスト期待値、受入基準のチェックボックスを追加しています。このバージョンは約85%の確率で予測可能な結果を生成します。残りの15%は、明確化された指示による2回目のパスが必要です。⁵

30のPRDから見えたパターンライブラリ

30以上のPRDを経て、パターンが浮かび上がりました。

新規機能の成功率（50%）が、PRD駆動開発が私のワークフローを補完するものであり、置き換えるものではない理由を物語っています。新規の作業の半分は、PRDでは事前に捉えられない反復作業を必要とします。

主要な学び

ソロ開発者向け： - まず1つの明確に定義されたPRDタイプ（CRUD、テスト）から始め、複雑なタスクに拡張する前にワークフローを検証してください - すべてのPRDに「Files NOT to Modify」を追加してください。エージェントは親切にも、あなたが触るよう頼んでいないコードを「改善」します - gitワークツリーを使ってエージェントの作業を隔離してください。失敗したエージェント実行のクリーンアップコストは、git考古学ではなく1つのコマンドであるべきです

エンジニアリングマネージャー向け： - PRDの品質がエージェントの出力品質を決定します。自律エージェントの利用を拡大する前に、PRDテンプレートとレビュープロセスに投資してください - 変更なしマージ率を追跡し、ワークフローの成熟度を測定してください。PRDテンプレートの進化に伴い、この比率は改善されるはずです - 新しいアーキテクチャの作業とセキュリティクリティカルなコードは、PRDに委任すべきではありません。エージェントへの委任は、明確に定義された反復可能なタスクに限定してください

参考文献