11月10日、LangChainが「What Is Eval-Driven Development? How to Improve AI Agents」と題した記事を公開した。この記事では、AIエージェントの品質をテスト駆動開発の考え方で体系的に改善する「Eval駆動開発（EDD）」の具体的な実践手順について詳しく紹介されている。
なぜ手動テストでは限界があるのか
AIエージェントの開発は、プロンプトを書いて手動で試し、調整して再試行するところから始まる。初期は明らかなエラーが多く、改善の手応えも得やすい。しかし開発が進むにつれ、「今の変更がエージェントをよくしたのか悪くしたのか」の判断が難しくなる。
これはエージェントが非決定的だからだ。同じ質問に対して毎回異なる答えが返り、複数の正解が存在し得る。エージェントが独自にツールを呼ぶかどうかを判断する以上、従来のユニットテストをそのまま適用できない。
LangChainが提唱するEval駆動開発（EDD）は、テスト駆動開発（TDD）の発想をエージェント開発に持ち込んだ手法だ。メトリクスを先に定義し、それに向かって反復的に改善していく。LangChainは自社の高度なエージェントの開発にもEDDを活用しており、たとえばIssueBenchはGitHubのIssueを題材にエージェントの問題解決能力を評価するベンチマーク基盤で、EDDの実践例のひとつとして紹介されている。
EDDの3ステップ
Step 1: 「良い状態」を定義する
最初にエージェントが何をすべきかを明文化する。具体的には、必要な振る舞いをリストアップし、それぞれに要件を書いたプロダクト要件書（PRD）を作る。
EDDでは1度に1つの振る舞いに絞って改善する。これにより、ある変更の効果が他の変更と混在しないようにできる。着手前に次の4点を短いスペックとしてまとめておく。
- その振る舞いが起きるべき状況
- エージェントがすべきこと
- エージェントがすべきでないこと
- 引き続き正しく動かすべき既存の振る舞い
たとえば社内ドキュメント検索エージェントにcreate_ticketツール（ITチケット起票）を追加する場合、スペックはこうなる。
- When: ユーザーが「VPNに接続できない」など、何かが壊れていると報告したとき
- Do:
create_ticketを呼ぶ- Don't: 「VPNへの接続方法は？」のようなHow-to質問でチケットを起票しない
- Keep intact:
search_docsとweb_searchが今と同様に動き続ける
Step 2: 実装前にEvalを書く
Step 2は「データセットを作る」「Evaluatorを書く」「ベースラインを取る」の3サブステップで構成される。
データセットを作る。 テストケース（examples）の集合がデータセットだ。入力と、オプションで「正解（golden output）」を含む。実際のエージェントの実行ログは最良のデータソースになる。ユーザーは開発者が予測しない表現を使うし、エッジケースも自然に含まれる。LangSmithでは、実際の実行ログを直接データセットに追加できる。
データセットは拡張もできる。たとえば「怒っているユーザー」の例が少なければ、既存の例をLLMに渡して怒り口調に書き直させ、エージェントが正しいツールを呼ぶかどうか検証する。
Evaluatorを書く。 スコアリング方法は2種類ある。
- Code eval: 決定論的なチェックに使う（例: 呼ばれたツール名の一致）
- LLM-as-a-judge: 自然言語の品質など、決定論的に判断しにくい場合に使う
ドキュメントエージェントの例では、ツール選択の正否はコードで判定できるため、Code evalが適している。
ベースラインを取る。 何も変更する前にエージェントを全例で実行し、その結果を「ベースライン実験」として記録する。チケット起票機能がまだ存在しない段階では、チケット関連の例はすべて不合格になるが、既存の動作が記録されることで、後から「何かが壊れていないか」を確認できる。
Step 3: 変更して比較する
ツールを実装したら、同じEvalを再度実行する。EDDの核心は「ヒルクライミング」だ。評価→比較→調整のループを繰り返し、客観的な改善の証拠を積み上げていく。
LangSmithの比較ビューでは、2つの実験を並べて各exampleのスコアを確認できる。平均スコアだけでなく、どのケースが退行したかを見ることが重要だ。
実際のドキュメントエージェントの例では、create_ticket追加後に平均スコアは上がったが、「VPNへの接続方法は？」というHow-to質問でチケットが起票されてしまうという退行が発生した。トレース（各モデル呼び出しとツール呼び出しの記録）を確認すると、ツールの説明が「VPNとノートPCの問題」と広すぎる記述になっていたことが原因だと判明した。ツールの説明を「ITが対応すべき作業要求」に絞ると、すべての例が合格した。
また、小さなデータセットで100%を達成することが必ずしも目標ではない点にも注意が必要だ。同じ例を見ながら調整を続けるとオーバーフィッティングが起きる。これを検出するには、反復中は見ない「ホールドアウトセット」を別に用意しておく。チューニング用の例でスコアが上がっても、ホールドアウトセットで横ばいならオーバーフィットの疑いがある。
本番環境でのEDD継続
EDDはデプロイで終わりではなく、本番環境でも継続的に機能する。CI統合と本番モニタリングの2つの軸で、エージェントの品質を運用フェーズでも維持・追跡する仕組みが整っている。
CI統合: LangSmithはpytestやVitestと連携でき、プルリクエストごとにEvalを自動実行できる。コード変更のたびに評価が走ることで、退行を早期に検出できる。
本番モニタリング: デプロイ後は以下の手段でカバーする。これらを組み合わせることで、開発中に想定しなかったパターンや劣化を継続的に把握できる。
- Online evaluators: ライブトレースをリアルタイムにスコアリング
- Annotation queues: チームが問題のある実行を手動でレビュー
- Dashboards: スコア・コスト・レイテンシを時系列で追跡
- Insights: 本番トレースをクラスタリングして新パターンを検出
- LangSmith Engine: 問題クラスターをデータセット例とアサーションに自動変換
LangChainはDeep Agents（同社が開発・公開しているエージェントフレームワーク）の開発でも実際にEDDを適用しており、そのEvalスイートをGitHubリポジトリで公開している。実際の本番Evalスイートの実装例として参照できる。
詳細はWhat Is Eval-Driven Development? How to Improve AI Agentsを参照していただきたい。
