EvalはAI時代の新しいPRD：非決定論的システムの品質管理とフライホイール設計
概要¶
従来のPRDは「仕様を書き→作り→検証する」決定論的なループを前提にしている。AIは非決定論的であり、同じプロンプトが毎回異なる出力を生む。この構造的な違いから、AIプロダクトではEval（評価スイート）がPRDの役割を担うべきだという主張。EvalはCI/CDに統合されプロダクション観測データで継続的に改善される「フライホイール」になる。
詳細¶
従来のPRD vs Evalの対応関係¶
| PRDのセクション | Evalの対応 |
|---|---|
| 要件定義 | 測定可能なシグナルとして定義 |
| 受け入れ基準 | Pass/Failの自動テストとして実装 |
| ロードマップ | 改善目標（どのスコアをいくつ上げるか） |
| 成功指標 | 本番データから継続取得するメトリクス |
「PRDはGoogle Docで埃をかぶる。Evalスイートは全コミットで動く」
AI開発の新しいループ¶
1. PM が「良い」の定義を構造的・反復可能なテストとして定義（Eval作成）
2. チームがEvalを目標にヒルクライム（プロンプト・RAG・ツール・モデルを改善）
3. 品質バーをクリアしたらリリース
4. 本番データを観測 → 新しいFailureケースをEvalに追加
5. 2に戻る
具体例：料理動画からレシピ生成機能¶
PRDの書き方（曖昧）：
「helpful で accurate であること」
→ 何をもって pass とするかが不明
Evalの書き方（測定可能）：
1. フォーマットチェック → 食材 → 手順の順になっているか（AIジャッジ）
2. 食材の網羅性チェック → 動画に登場した食材がすべて含まれるか（文字列マッチ）
3. 手順の可読性チェック → 短い文で書かれているか（AIジャッジ）
エンジニアへの指示：「この数字を上げてください」
3種類のEvalジャッジ¶
| 種類 | 用途 | 特徴 |
|---|---|---|
| アルゴリズム | 文字列マッチ、フォーマット検証、長さ制約 | 高速・安価・完全に信頼可能 |
| AIジャッジ | トーン・有用性・一貫性などの主観的評価 | スケーラブルだが人間のキャリブレーション必要 |
| AIジャッジ＋人間アライメント | 主観的判断が必要な深い品質評価 | 実装難易度高いが複雑な品質次元に対応 |
Evalフライホイールの4段階¶
Stage 0 → "Vibes"
手動スポットチェック・直感・クレーム対応のみ
→ 盲目で飛行中
Stage 1 → テストセット（リアクティブ）
Pass/Failのテストセット、リリース前に手動実行
→ 改善だが依然として後手
Stage 2 → CI/CD統合（プロアクティブ）
自動実行・品質バーでリリースをブロック
→ 品質を組織的に担保
Stage 3 → フライホイール（複利的）
本番データが継続的にEvalスイートに流入
本番障害 → 自動でテストケース化 → 毎週改善
→ 複利的な競争優位
PMの週次サイクル¶
月曜: 本番トレースを確認 → 20件の問題ある出力をフラグ
火曜: 20件を5つのEvalケースに絞る → Evalスイートに追加
水曜: 先週モデルと今週候補でフルEvalを実行
木曜: 差分を確認 → データが出荷可否を決める
金曜: フライホイールが速くなった
よくある失敗パターン¶
- 「汎用的な知性」を測ろうとする（具体的なタスクに絞ること）
- 設計に多くのステークホルダーを巻き込みすぎる
- サードパーティEvalを検証せずに信頼する
- ローンチ時だけ実行して止める
- Evalスコアを最適化してしまう（グッドハートの法則）
なぜ重要か / いつ使うか¶
- AIプロダクトのPMがどこに時間を使うべきか判断するとき
- 「AIの品質をどう担保するか」をエンジニアリングチームに説明するとき
- CI/CDパイプラインにEvalを組み込む設計を始めるとき
- 「PRDを書くべきか、Evalを書くべきか」で迷ったとき