AIエージェントの評価を実装する — 本番ドリフトを検出するEvals設計とLLM-as-Judgeの限界

ソフトウェアエンジニアなら、コードを変更したらテストを回すのは当たり前です。ところがAIエージェントの実装では、この当たり前の環が欠けているケースが少なくありません。「プロンプトを1行変えたら業務フローが壊れた」「モデルを最新版に切り替えたらツール呼び出しの成功率が落ちた」。こうした事故は、従来の単体テストだけでは検出できません。本稿では、AIエージェント専用の回帰テスト体系であるEvalsを、実装と運用の両面から整理します。

1. なぜ従来のテストではエージェントを守れないのか

通常の関数は、同じ入力に対して同じ出力を返すことを期待できます。一方、エージェントはモデルの確率性、外部ツールの状態、会話履歴、取得した文書の内容に左右されます。つまり入力と出力の間に、従来のテストにはなかった揺らぎがあります。

非決定性・自然言語・マルチターンが同時に存在する

評価を難しくする要因は三つあります。第一に、temperatureやモデル更新による非決定性。第二に、正解が一つに定まらない自然言語。第三に、直前の発言やツール結果が次の判断を変えるマルチターン状態です。「文字列が完全一致するか」だけでは、よい回答を落とし、悪い回答を見逃します。

ユニットテストとEvalsの責任分界

pytestなどの通常テストは、ツールのスキーマ、認証、タイムアウト、データ変換のような決定的な部分を担当します。Evalsは、その上にある「この依頼で適切なツールを選んだか」「安全な順序で実行したか」「利用者が次に行動できる説明になっているか」を評価します。両者を混ぜず、責任分界を明確にすることが最初の設計です。

2. Evalsは3層に分けて設計する

図：決定性テスト、ルーブリック採点、本番モニタリングの3層

Layer 1：決定性のあるテスト

ツール選択の正解、必須パラメータ、JSONスキーマ、禁止操作の不在は自動採点できます。たとえば「請求書を検索して合計する」というタスクなら、検索ツールが呼ばれ、日付範囲が正しく渡され、金額が数値として返ることを検証します。モデルの文章を採点する前に、壊れると即座に業務停止につながる契約を固定します。

Layer 2：ルーブリックによる品質採点

自然言語の品質は、評価基準をルーブリックに落とします。正確性、根拠の明示、指示への適合、安全性をそれぞれ0〜2点で採点し、合計点と重大違反を分けて記録します。LLM-as-Judgeは便利ですが、最終判定ではなく、同じ基準を大量に適用する補助者として位置づけるのが安全です。

Layer 3：本番トラフィックからのドリフト検出

評価用データセットだけでは、現実の変化を捉えられません。本番では、ユーザーの再質問率、途中離脱率、人手へのエスカレーション率、ツール失敗率、1タスクあたりのステップ数を継続的に観測します。モデルを変えていないのに指標が悪化したなら、入力分布や業務ルールが変わった可能性があります。これは「正解率」ではなく、サービス品質の変化を監視する層です。

3. Pythonとpytestで最小のevalスイートを組む

最初から大規模な評価基盤を作る必要はありません。タスク定義、ランナー、採点器、レポートの四つに分ければ、小さく始められます。タスクはYAMLやJSONで管理し、プロンプト、期待するツール、評価基準、重大度をコードから分離します。これにより、評価データのレビューと実行ロジックの変更を別々に扱えます。

from dataclasses import dataclass

@dataclass
class EvalCase:
    name: str
    prompt: str
    expected_tools: list[str]
    must_contain: list[str]
    severity: str = "normal"

def score_trace(trace: dict, case: EvalCase) -> dict:
    tools = [call["name"] for call in trace.get("tool_calls", [])]
    tool_ok = tools == case.expected_tools
    text = trace.get("final_text", "")
    content_ok = all(word in text for word in case.must_contain)
    return {"tool_ok": tool_ok, "content_ok": content_ok,
            "passed": tool_ok and content_ok}

この例では、ツール呼び出しの順序と必須語句を決定的に採点しています。実際には、個人情報の出力、承認なしの破壊的操作、根拠のない断定を重大違反として別に扱います。合格率だけを一つの数字にまとめると、重大な失敗が平均値に埋もれるためです。

回帰閾値をCIのゲートにする

基準モデルのpass@1が95%で、変更後が93%なら、差分は2ポイントです。ここで「全体平均が許容範囲」とせず、重要タスク群は100%維持、通常タスクは2ポイント低下までというように層別化します。CIでは少数のスモークセットを毎回回し、全量評価は夜間バッチに回すと、時間と費用を抑えられます。

4. LLM-as-Judgeを鵜呑みにしない

LLM-as-Judgeは、長い回答を一定の基準で読む作業を自動化できます。しかし評価者自身もモデルであり、完全に中立ではありません。被評価モデルと同じ系列を好む自己選好、先に提示された回答を好む位置バイアス、長い文章を高く評価する冗長性選好が知られています。

緩和策は「モデルを変える」だけでは足りない

ジャッジと被評価モデルを別系列にし、ペア比較では提示順を反転させます。同じケースを複数回採点して一致率を記録し、一定割合は人間がラベルを付けてジャッジとの相関を確認します。1〜5点の総合点だけでなく、どの基準に違反したかという理由を構造化して保存すると、誤判定の分析が可能になります。

人間の役割は「全件採点」から「校正」へ

人間が全件を読むのは高価ですが、代表的なケース、ジャッジの確信度が低いケース、モデル間で判定が割れたケースを読む運用なら続きます。評価者に任せる範囲と人間が確認する範囲を定期的に見直し、評価そのものが劣化していないかを点検します。

5. モデル更新はシャドー、カナリア、全量の順で進める

ベンチマークのスコアが上がっても、自社の業務タスクが改善するとは限りません。自社の評価セットを固定し、候補モデルと現行モデルを同じ条件で比較します。まず本番入力を候補モデルへ複製するシャドー運転で、実ユーザーには返さず差分だけを観測します。次に一部のトラフィックへカナリア投入し、エスカレーション率やコストを監視します。

6. Evalsを組織運用へ落とし込む

失敗をプロンプト、ツール、モデルに切り分ける

eval失敗時は、まずトレースを確認します。適切なツールを選んだのに結果を誤読したならプロンプトや出力処理、引数が不正ならツール契約やデータ変換、同じ入力で全体的に悪化したならモデル変更を疑います。原因の分類をチケットに残せば、場当たり的なプロンプト修正を減らせます。

本番の失敗事例を評価データへ還流する

評価セットは一度作って終わりではありません。ユーザーが再質問した例、オペレーターが修正した回答、ツールが失敗したケースを匿名化して追加します。月次で重複や陳腐化を整理し、代表性を保ちます。評価データ自体が業務の変化を映す、運用資産になります。

まとめ：EvalsはAIエージェントのSDLCを成立させる

ガードレールが実行時の防御なら、Evalsは開発時と運用時の検証です。決定性テストで壊れてはいけない契約を守り、ルーブリックで自然言語の品質を測り、本番指標でドリフトを検出する。この3層を分けて組み合わせると、「一度動いたから本番へ」から「変化を検知できるから運用できる」へ進めます。評価を後付けの監査にせず、プルリクエストとモデル更新に組み込むことが、エージェント開発をソフトウェア開発の一部に戻す最短ルートです。

※2026年9月時点の公開情報と一般的な実装パターンに基づく解説です。各サービスの仕様・料金は変更される可能性があります。