※本稿は、当方ブログの紹介です。全文はこちらへどうぞ。
https://shinichi.noguchi.jp.net/blog/2026-09-05-agent-evals-in-production.html
AIエージェントを本番運用すると、「プロンプトを少し変えただけでツールの呼び出し順が変わった」「モデルを更新したら、回答の再質問率が上がった」という問題が起きます。通常の単体テストだけでは、自然言語の品質や、複数ステップのエージェントの挙動までは十分に検証できません。
そこで必要になるのがEvalsです。Evalsは、AIエージェントの出力・ツール利用・本番挙動を継続的に評価する仕組みです。この記事では、実装を次の3層に分けて説明しています。
1. 決定性テスト
ツール選択、引数、JSONスキーマ、禁止操作の有無など、正解を比較的明確に定義できる部分を自動テストします。Pythonのpytestで、期待するツール列と実際のトレースを比較すれば、プロンプト変更による基本的な回帰を早期に検出できます。
2. ルーブリック採点
自然言語の回答は、完全一致ではなく評価基準を定義します。正確性、根拠の明示、指示への適合、安全性などを0〜2点で採点し、LLM-as-Judgeを補助的に使います。ただし、LLM-as-Judgeには自己選好、位置バイアス、長さバイアスがあります。被評価モデルとは別系列のジャッジを使い、提示順を反転し、人間の判定で定期的に校正することが重要です。
3. オンライン評価
評価用データセットだけでは、現実の利用状況の変化を見逃します。本番では、再質問率、途中離脱率、人手へのエスカレーション率、ツール失敗率、1タスクあたりのステップ数などを観測します。モデルを変えていなくても指標が悪化した場合、入力分布や業務ルールが変わった可能性があります。
最小構成は「タスク定義→ランナー→採点器→レポート」です。CIでは少数のスモークセットを毎回実行し、全量評価は夜間バッチに分けるとコストを抑えられます。重要タスクは100％維持、通常タスクはpass@1の低下幅を閾値化するなど、平均点だけでなく重大度ごとのゲートを設けます。
モデル更新時は、いきなり全利用者へ展開しません。同じEvalsスイートで現行モデルと候補モデルを比較し、シャドー運転、カナリア投入、全量展開の順に進めます。ベンチマークのスコアが高くても、自社の業務タスクの成功率が高いとは限らないためです。
AIエージェントの評価は、後付けの監査ではなく、プルリクエストとモデル更新に組み込むべき開発工程です。決定性テスト、ルーブリック採点、本番ドリフト検出を役割分担させることで、「一度動いたから本番へ」から「変化を検知できるから運用できる」へ移行できます。
※2026年9月時点の公開情報と一般的な実装パターンに基づきます。
本文：https://shinichi.noguchi.jp.net/blog/2026-09-05-agent-evals-in-production.html