LLM・AIエージェント開発を加速する評価駆動開発（EDD）入門：サイレントエラーを見つけ出す実践的アプローチ

はじめに

「プロダクション環境でエージェントが完璧に動作している、と思いきや、実はサイレントエラーが発生していた」――AIエージェントやLLM（大規模言語モデル）を活用したアプリケーション開発において、このような状況に直面したことはありませんか？本記事では、YouTube動画「Eval-Driven Development for AI Agents」のプレゼンターであるRachel Lee Neighbors氏（MDN Web DocsやReactドキュメントでも著名なエンジニア）の解説に基づき、従来の開発手法では見落とされがちなAIエージェント特有のサイレントエラーを検出し、解決するための「評価駆動開発（Eval-Driven Development: EDD）」という実践的なアプローチをご紹介します。

従来のソフトウェア開発におけるテスト駆動開発（TDD）は、コードの決定論的な性質に依存していましたが、LLMやAIエージェントは非決定論的であるため、TDDの考え方をそのまま適用するのは困難です。そこで登場するのが、エージェントの評価に特化したEDDの概念です。

本記事では、EDDの基本概念から、エージェントの可観測性（Observability）の重要性、具体的なトレースとスパンを用いた問題診断、そして失敗から学習して評価データセットを構築するプロセスまでを、初心者にも分かりやすく解説していきます。本記事で扱う内容は、主にArize PhoenixというオープンソースプラットフォームのTypeScript SDKを用いた例が中心となりますが、EDDの概念自体は他のツールや環境にも応用可能です。

評価駆動開発（EDD）の基本概念とTDDとの比較

従来のテスト駆動開発（TDD）に慣れている方のために、EDDにおける主要な概念とTDDの用語を対比させながら説明します。

TDD用語とEDD用語の対比

この対比により、TDDの経験がある方であればEDDの概念をよりスムーズに理解できるでしょう。EDDは、エージェントの非決定論性に対応しつつ、品質を保証するための不可欠なアプローチとなります。

サイレントエラーの発見と可観測性（Observability）の重要性

「エージェントが『検索する正しいテーブルを見つけさせてください』と出力している場面を想像してみてください。これは、エージェントがどこを検索すべきか分かっていないことを示唆しており、ユーザーに不信感を与えかねません。しかし、もしこのメッセージがログの奥深くに埋もれていたら、あなたは気づかないかもしれません。」

見えないものはテストできない

プロダクション環境でエージェントが完璧に動作しているように見えても、裏側で望ましくない挙動やエラーがひっそりと発生していることがあります。これを「サイレントエラー」と呼びます。この問題を解決するためには、まず「見えないものはテストできない」という原則を理解し、エージェントの内部挙動を可視化する「可観測性（Observability）」を確立することが不可欠です。

幸いなことに、LLMやAIエージェントは本質的に可観測性を持っています。彼らは、ユーザー入力、LLMの出力、ツール呼び出しなど、すべてのステップをログとして記録します。これらのログを適切にキャプチャすることが、可観測性を実装する第一歩です。

スパンとトレース

スパン（Span）: エージェントが行った作業の記録単位です。入力、出力、実行タイミング、発生したエラーなどの情報を含みます。十分なスパンを収集することで、エージェントの挙動の貴重な洞察を得ることができます。
トレース（Trace）: 単一のリクエストに対するエージェントの全呼び出しスタックを指します。つまり、一つの目的を達成するためにエージェントが実行した、一連のスパンの集合体です。トレースを見ることで、エージェントがどのような思考プロセスを経て最終的な出力を生成したのか、あるいはどこで問題が発生したのかを詳細に追跡できます。

可観測性ツールの活用

可観測性を実装するためのツールはいくつか存在します。デモで用いられるPhoenixは、オープンソースで小規模なプロジェクトに適していますが、大規模なエンタープライズ環境では、R-BAC（ロールベースアクセス制御）などを備えたArize AI Xや、Braintrustのような競合製品も選択肢となります。また、一部のプラットフォーム（例: Mastra）には、すでに「Scores」のような可観測性機能が組み込まれています。

どのようなツールであれ、可観測性を有効にしてこれらのログ（トレース）を収集することは非常に重要です。そうすることで、いつかシステム障害が発生した際に、その原因を特定するための決定的な手がかりを得ることができます。

トレースを用いた障害診断の実践

実際にサイレントエラーがどのように発見され、診断されるのか、具体的な例を見てみましょう。

SQLクエリ生成エージェントの失敗例

あるエージェントがSQLクエリを生成してデータベースを検索しようとしているシナリオを想定します。しかし、トレースを確認すると、その中に一つの「失敗したスパン」が含まれていました。このスパンには、「no such table products」という例外が記録されています。これは、エージェントが呼び出したツール（データベース）に「products」というテーブルが存在しないことを示しています。つまり、エージェントはデータベースのスキーマを知らずに、テーブル名を推測してしまっていたのです。

隠れたコストとパフォーマンスの低下

この一つの失敗したツール呼び出しは、連鎖的な問題を引き起こしました。データベースへのクエリが失敗したにもかかわらず、エージェントは別のツール呼び出しをトリガーし、データベース全体を再クエリしようとしたり、さらに別のツール呼び出しを行ったりしました。結果として、本来であれば1回のLLM（例えばClaude Sonnet）へのラウンドトリップで済むはずが、3回ものラウンドトリップが発生していました。

このような挙動は、一見するとエージェントが機能しているように見えますが、実際には以下のような深刻な問題を引き起こします。

推論コストの増加: 不要なLLMへの呼び出しは、API利用料を大幅に増加させます。
ユーザーエクスペリエンスの低下: 応答時間が長くなり、ユーザーにストレスを与えます。

エージェントは賢いですが、まだ非常に高価なリソースです。このようなサイレントエラーは、気づかないうちに予算を食いつぶし、ユーザー体験を損なう可能性があります。これは壊滅的な障害ではありませんが、放置すれば確実に問題が肥大化します。

失敗から学ぶ：ゴールデンデータセットの構築

障害を発見したら、次のステップは、その失敗を将来の改善と評価に活かすことです。エージェント開発においては、発生したエラーログを収集し、「ゴールデンデータセット」として蓄積していくことが非常に効果的です。

ゴールデンデータセットとは

ゴールデンデータセットは、厳選された入力と、それに対する期待される出力（オプション）のコレクションであり、エージェントの「テストスイート」として機能します。エージェントのコード、モデル、プロンプト、あるいは基盤となるインフラストラクチャ（ハーネス）に変更を加えるたびに、このゴールデンデータセットに対してエージェントを実行し、新しい変更が性能を損なっていないか、あるいは以前の失敗が修正されているかを確認します。

エラーログをデータセットへ

重要なのは、「エージェントがどのように失敗するかを想像する必要はない」という点です。従来のTDDでは、開発者はあらゆるエッジケースを想定し、それに対するアサーションを書く必要がありました。しかし、EDDにおいては、現実世界で発生した「失敗」こそが最も貴重な情報源となります。

システムが失敗した際のログ（特に、上記で説明したような破損したスパンを含むトレース）を積極的に収集し、それらをゴールデンデータセットの新しいエントリとして追加していきます。これにより、エージェントは自身の失敗から学習し、より堅牢になっていきます。

Phoenixのドキュメントやクックブックには、「高シグナルトレースの発見」という記事があり、週に一度エバル結果を確認し、長期的に改善に大きな影響を与えるエラーを特定して収集するプラクティスが推奨されています。

データセットの継続的な拡充

このゴールデンデータセットは、新しいハーネス、モデル、ツールを導入する際に特に重要になります。新しいコンポーネントが既存のシステムと問題なく連携できるかを、過去の失敗事例を通じて効率的に検証できるためです。システムを監視し、失敗を収穫し、それを評価スイートの一部として組み込むことが、エージェント開発における週次の重要なプラクティスとなります。

まとめ

本記事では、LLM・AIエージェント開発におけるサイレントエラーの問題を解決するための「評価駆動開発（EDD）」の概念を、TDDとの比較や具体的な事例を交えて解説しました。

主要なポイントは以下の通りです。

EDDの導入: 非決定論的なAIエージェントの評価には、従来のTDDとは異なるEDDのアプローチが不可欠です。
可観測性の確立: スパンとトレースを用いてエージェントの内部挙動を可視化し、サイレントエラーの発見を可能にします。
トレースによる診断: 失敗したトレースを分析することで、見過ごされがちなパフォーマンスの低下やコスト増大の原因を特定できます。
失敗からの学習: 実際のプロダクション環境で発生したエラーログを「ゴールデンデータセット」として蓄積し、エージェントの品質と信頼性を継続的に向上させます。

AIエージェントの品質を保証し、コスト効率を高め、最終的に優れたユーザーエクスペリエンスを提供するためには、EDDのプラクティスが非常に有効です。本記事が、皆さんのエージェント開発の一助となれば幸いです。

参考動画

Eval-Driven Development for AI Agents https://www.youtube.com/watch?v=40UrR1QeXeE