概要
https://zenn.dev/r_kaga/articles/54698ed22fbfe9
詳細内容
## テストが設計を駆動するなら、評価は何を駆動する？ 〜テスト駆動開発と評価駆動開発、「先に定義する」ことの力〜
https://zenn.dev/r_kaga/articles/54698ed22fbfe9
非決定論的なLLM出力を制御し、AIプロダクトの品質を駆動するための「評価駆動開発（EDD）」の有用性と具体的な実践サイクルを提示する。
**Content Type**: Technical Reference | テクニカルリファレンス
**Language**: ja
**Scores**: Signal:5/5 | Depth:4/5 | Unique:3/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 81/100 | **Annex Potential**: 77/100 | **Overall**: 80/100
**Topics**: [[評価駆動開発(EDD), テスト駆動開発(TDD), 品質保証, ソフトウェア2.0, プロンプトエンジニアリング]]
本記事は、非決定論的な振る舞いを持つLLMを用いたプロダクト開発において、従来のテスト駆動開発（TDD）の思想を「評価」へと拡張した「評価駆動開発（Eval-Driven Development: EDD）」の重要性と実践方法を深く考察している。著者は、TDDが「使う側の期待」を先に書くことで優れた設計を導くのと同様に、AI開発においても「成功の定義」を先に言語化することが品質向上の鍵であると主張する。
LLMの出力は「2+2=4」のような決定論的な世界ではなく「明日の天気予報」のように不確実であり、従来のユニットテストだけでは品質を担保できない。そこで重要となるのが、Andrej Karpathy氏が提唱する「Software 2.0（検証できることを自動化する）」の概念である。著者は評価基準を定義するプロセスを「AIの出力を検証可能にするための言語化の強制」と捉え、これがチーム内での「良いユーザー体験」の認識合わせとして機能することを強調している。
記事では、EDDの実践プロセスとしてTDDの「Red-Green-Refactor」サイクルを適応させたモデルを提案している。
1. **Step 1 (Red)**: 評価基準を先に定義する。何をもって成功とするかを明確にする。
2. **Step 2 (Green)**: 評価をパスさせる。プロンプトやモデルを調整し、まずは目標の出力を得る。
3. **Step 3 (Refactor)**: プロンプトの洗練、ツール定義の改善、あるいはエージェント構造の簡素化といったアーキテクチャの改善を行う。
特にリファクタリングにおいて、Anthropicの知見を引き合いに「必要以上に複雑なシステム（エージェント等）にしない」という「適切なシステム構築」の原則に触れている点は、エンジニアにとって極めて示唆に富む。
また、評価の導入タイミングについても現実的な指針を示している。NotionやCursorの開発現場でも初期は「バイブス（雰囲気）」で進められていた事例を紹介し、改善が別の場所を壊す「モグラ叩き」の状態に陥った時こそがEDDへ移行する閾値であると述べる。まずは自動化を急がず、失敗事例を1つ選んで「なぜダメなのか」を言語化し、人間同士で基準を揃えるキャリブレーションから始めるべきだという著者の主張は、AIプロダクト特有の「曖昧さ」に対する非常に実務的なアプローチである。