10月5日、InfoQが「Building Reusable Evaluation Frameworks for Agentic AI Products」と題した記事を公開した。この記事では、Elasticが本番運用中の複数のAIエージェントに対して、チーム横断で再利用可能な評価フレームワークを構築した実践的な知見を紹介している。チームごとに評価コードを書き直す非効率をどう解消したか——その答えは、共通化と標準化の徹底にある。

「評価をゼロから書き直す」問題をどう解決したか

AIエージェントの品質評価は、チームごとに独自実装を繰り返しがちだ。Elasticでも同じ問題に直面した。

ElasticのプリンシパルデータサイエンティストであるSusan Chang氏は、セキュリティ担当チームとエンタープライズチャットボット担当チームがそれぞれ独自のデータセット・評価器・トレース基盤を構築していた状況を振り返る。両チームの評価基盤はまったく異なるものになっており、共通化できるはずのコードが重複していた。

この状況を解消するために設計されたのが「共有評価フレームワーク（Shared Evaluation Framework）」だ。フレームワーク整備後、新たに「AIルール生成エージェント」（自然言語からYAML/JSON形式のセキュリティ検知ルールを生成するエージェント）を追加した際、Chang氏は評価スイートをゼロから書き直すことなく、短期間でセットアップを完了できたという。

2つの本番エージェントが示す評価の難しさ

Elasticが実際に本番で動かしているエージェントの事例は、評価設計の難しさをよく示している。なお、元記事はプレゼンテーション動画形式であるため、以下の記述は公開情報に基づく紹介であり、発表内の細部については元動画を直接参照されたい。

① Attack Discovery（セキュリティ解析エージェント）

あるメガバンク顧客はペタバイト規模のログをElasticsearchに蓄積し、サイバーインシデント発生時に人手でログを精査していた。このエージェントはそのログから攻撃の兆候を自動抽出する。評価指標として使われているのは：

• アラートIDのマッチングに基づく精度（Precision）・再現率（Recall）
• 類似度スコア・事実性スコア
• MITREタクティクス（サイバー攻撃の分類体系）の誤生成を検出するドメイン固有メトリクス

② エンタープライズチャットボット（RAGエージェント）

こちらはElasticsearch上のプロプライエタリなドキュメントを参照して質問に答えるRAG（検索拡張生成）型エージェントだ。評価指標は：

• 回答の関連性・完全性
• ES|QL（Elasticが開発したクエリ言語）の構文正確性

ES|QLの構文チェックについては、エージェント自体にツール呼び出し機能を組み込み、生成したクエリを自動検証する仕組みも実装している。セキュリティ側のチームはこの指標を必要としておらず、チームごとに評価軸が大きく異なることが分かる。2つのエージェントを並べると、「汎用的な評価指標だけでは不十分であり、ドメイン固有の指標を追加できる拡張性が評価フレームワークに不可欠だ」という設計上の要件が浮かび上がってくる。

共有フレームワークの構成要素

共有フレームワークは以下の構成要素から成る：

• データセットローダー：セキュリティログ形式とQ&A形式など、異なるスキーマのデータを統一的に扱える標準スキーマを定義
• トレースベース評価器：トークン使用量・レイテンシ・ツール呼び出し回数などのオブザーバビリティ指標
• 共有RAG評価器：複数チームで再利用できる汎用的な検索精度評価
• カスタム評価器：ユースケース固有の指標（MITREタクティクス、ES|QL構文チェックなど）

評価の実行フローは、「データセット入力 → エージェント実行 → コードベース評価器＋LLM-as-a-judge＋トレースベース評価器の並列実行 → 結果をElasticに格納」という形になっている。

新チームが参加する際には、データセットローダーと共有評価器をそのまま引き継ぎ、カスタム評価器のみを追加実装すればよい。これがAIルール生成エージェントのオンボーディングを短期間で完了させた構造的な理由だ。

トレーシングが評価の前提条件である理由

Chang氏が強調するのが、トレーシングなしに評価は機能しないという点だ。

エージェントの最終出力だけを見ていると、「なぜ間違えたか」が分からない。内部でどのツールを呼び出し、どのデータベースを参照したかを記録してあれば、「間違ったデータベースを参照していた」「ベクトル検索の結果が不適切だった」といった原因の特定が可能になる。また、特定のツール呼び出し単体に対して評価を走らせることもできる。

ElasticではLangSmithやPhoenix（Arize）など複数のトレーシングツールを試用している。LangSmithの「データセットへの追加（Add to Dataset）」機能が特に有用だったと紹介されている。ユーザーから低評価（thumbs down）フィードバックを受けたケースをそのままテストデータセットに追加でき、次回以降の評価で回帰テストとして活用できる。これはいわば「本番が評価データを自動生成し続ける」仕組みであり、評価セットの鮮度を保つ上で実践的なアプローチだ。

PythonからTypeScriptへ：本番環境との乖離を埋める

興味深い実装上の判断として、評価コードベースをPythonからTypeScriptへ移行した経緯が紹介されている。

本番エージェントのコードはTypeScriptで実装されていた。データサイエンティストがPythonで評価スクリプトを書いていると、本番と評価環境の間に乖離が生じる。たとえば、本番側でTypeScriptのライブラリアップデートが入った場合、Pythonの評価コードがその変更を追従できず、評価結果が本番の挙動を正確に反映しなくなるリスクがある。

Elasticではこの問題に対処するため、もともとTypeScriptのテストフレームワークとして採用していたPlaywrightをベースに「Scout」と呼ぶカスタムランナーを構築した。Playwrightはブラウザ自動化ツールとして広く知られているが、ここではそのテスト実行・並列処理・レポーティングの仕組みをAIエージェント評価に転用している。Scoutはデータセットの読み込み・エージェント実行・評価器の呼び出し・結果収集をすべてTypeScriptで統一して処理する。

Chang氏は「すべてのケースでTypeScriptへの移行を推奨するわけではない」と明示した上で、本番環境と評価環境の言語を合わせることで再現性が上がるという判断を示している。ClaudeやCursorを活用してPythonのコードをTypeScriptに変換したとも述べており、AIツールを評価基盤の整備自体に活用している点も実践的だ。

詳細はBuilding Reusable Evaluation Frameworks for Agentic AI Productsを参照していただきたい。