AIエージェントの評価を実装する：本番ドリフトを検出するEvals設計

エージェントの「回答が悪くなった」という一言では、何が壊れたのか分からない。プロンプトか、ツールの呼び出しか、LLMの選択か、入力分布の変化か。本記事は、エージェント評価を3層に分解する設計を提案する。第1層はトレース契約の決定性——ツール列、引数の形式、最大ステップ数といった「壊れると業務停止する」ルールを検査する。第2層はルーブリックとLLM-as-Judge——自然言語の品質を多次元スコアで採点し、モデル候補の相対比較や品質傾向を測る。第3層は本番ドリフト検出——実際の入力分布や業務ルール変化に応じて、メトリクスを分解観測し、品質低下を入力特性の変化と区別する。面白いのは、この3層をpytestで統合実装できる点だ。タスク定義をYAMLに置き、同じエージェントAPIを呼び、採点器がトレースと回答を評価し、レポートが基準との差分を出す構成にする。CIで少数のスモークケース、夜間バッチで全量ケースという二段構えになり、重大度別のハードゲートも設けられる。ただし見落としやすいのは、外部ベンチマークの改善と自社タスク成功率の乖離だ。「新しいモデルのほうが強そう」という漠然とした理由で交換するのではなく、自社の完了条件との紐付けが必須になる。失敗分類も重要で、ツール選択が悪かったのか、引数作成が間違ったのか、結果の誤読か、全体的な品質低下かを分ける。この分類をチケットに残せば、場当たり的なプロンプト修正の悪循環を防げる。結論は『評価を監査の後工程に置かず、プルリクエスト・データ更新・モデル更新のそれぞれに接続して初めて、エージェントのSDLC（ソフトウェア開発ライフサイクル）が成立する』という一言に尽きる。