Agent 評価データセットの作り方：実タスク、軌跡ログ、回帰テストまで

先週までは日報を問題なく生成していた Agent が、モデル更新後も「一見正しい」最終サマリーを返しました。ところが軌跡を見ると、権限チェックとデータ更新ツールが抜けています。カスタマーサポート Agent は最終回答こそ正しかったものの、返金ツールの引数を間違えていました。公開 benchmark では、このリスクは見えません。事故の振り返りには traceId、tool call、approvalId、state event、人間の判定が残っているのに、次回リリース前に必ず走るテストにはなっていない。そこが問題です。

この種の退化は、モデルを変えたり、demo を 1 回走らせたりするだけでは防げません。Agent 評価データセットは、実タスクの分布と本番の失敗軌跡から作る必要があります。ツール呼び出し、引数形式、状態遷移、承認記録、人間のラベルを含め、CI ゲートで回帰テストとして実行する。ここでは、失敗事例と実際のシナリオから、継続して使える eval dataset を作り、毎回のリリース品質を守る方法に絞ります。

1. なぜ公開 benchmark だけでは足りないのか

1.1 公開 benchmark の限界

公開 benchmark が測るのはモデル能力であって、あなたの業務タスクの品質ではありません。AgentBench や WebArena のような評価セットは標準タスクを提供しますが、チーム固有のツールチェーン、権限モデル、状態機械までは覆えません。

たとえば、あなたのレポート Agent が check_permission、refresh_data、generate_report の 3 つのツールを呼び、「チェック→更新→生成」の順で実行しなければならないとします。公開 benchmark はこのフローをテストしません。あなたの tool schema や権限境界を知らないからです。

公開 benchmark の点数が良くても、業務タスクが退化しないとは限りません。Agent 評価データセットが測るべきなのは、汎用的な推論能力ではなく、自分たちの実タスク分布です。

1.2 自前データセットの主要な価値

自前の eval dataset は、公開 benchmark では見えないリスクを捕まえます。典型例を比べると次のようになります。

シナリオ	公開 benchmark	自前 eval dataset
レポート Agent が権限チェックを漏らす	見えない。このツールと権限モデルが存在しない	軌跡制約として捕捉：check_permission を必ず呼ぶ
サポート Agent が返金引数を間違える	そのツールも返金 schema もない	期待ツール呼び出しリスト + 引数形式制約
モデル更新後に状態遷移が悪化する	その状態機械がない	状態軌跡の断言：チェック→承認→実行
事故の振り返りがテスト化されない	事故データがない	失敗事例を negative cases に入れる

公開 benchmark はモデル選定に使い、自前データセットはリリースゲートを守るために使います。両者は補完関係であり、互いの代わりにはなりません。Agent 評価 benchmark の比較を読んでいれば、どの公開評価セットが選定に向くかは把握できているはずです。ここでは、自分たちの本番環境から評価データを作る方法に集中します。

2. Agent eval dataset の中核フィールド

2.1 必須フィールド

Agent eval dataset は、ユーザー入力と期待回答を保存するだけのものではありません。ツール呼び出しの軌跡、状態遷移、人間の判定を記録する必要があります。必須フィールドは次のとおりです。

フィールド	説明	ソース
input	ユーザーのタスク記述	本番 trace / 手動設計
expected output	期待される最終回答	人間の annotation / golden set
expected tool calls	期待されるツール呼び出しリスト	軌跡分析。例：["check_permission", "refresh_data"]
trajectory assertions	軌跡制約（必須/禁止/順序）	状態機械 + 承認フロー
human labels	人間の判定（正しい/誤り/一部正しい）	事故の振り返り / ラベル付けキュー

LangSmith の Evaluation concepts では、Agent 評価は最終回答だけでなく、ツール選択、引数形式、実行軌跡を覆うべきだとされています。OpenAI Agents SDK Tracing は trace_id、workflow_name、span などのフィールドでツール呼び出しや状態イベントを記録できます。ただし、それらの生フィールドは脱感作と抽出を経てからでないと、データセットには入れられません。

2.2 任意フィールド

業務上必要であれば、次のフィールドを追加します。

フィールド	説明	用途
approval records	承認記録（承認者、時刻、結果）	権限モデル上、承認が必要なツール呼び出し
state transitions	状態遷移シーケンス	状態機械の制約。例：["init", "check", "approve"]
metadata	traceId、環境、モデルバージョン	振り返りでの特定とバージョン比較

Agent の権限モデル（N157）と人間の承認設計（N155）を読んでいれば、approval records には承認ステップ、承認者、承認結果を記録し、高リスク操作が承認を通ったか検証する必要があるとわかるはずです。

2.3 脱感作とプライバシー

本番 trace は、そのまま評価セットに入れられません。OpenAI Agents SDK Tracing の文書は、一部の span がモデルの入出力や function tool の入出力を取得する可能性があるため、機微データを含めるかどうか設定が必要だと示しています。

必ず脱感作するフィールド：PII（氏名、メール、電話番号）、secret（API key、DB パスワード）、顧客データ（注文番号、取引金額）。

残すフィールド：traceId、span_id（調査用）、workflow_name（分類用）、ツール名、状態名（断言用）。

脱感作の方法には、<user_id> のようなプレースホルダーへの置換、ハッシュ化、削除があります。Phoenix の Running Evals on Traces 文書では、trace を評価入力に変換できるとされています。ただし、それでも label/score/rubric が必要です。完全な生 trace を eval dataset に直接入れてはいけません。

3. 本番 trace から eval example へ

3.1 データ収集フロー

本番 trace から eval example を作るには、脱感作、ラベル付け、階層分け、保存の 4 ステップが必要です。一度きりの実装ではなく、継続運用です。

チェックリスト：

1. 監視 platform から失敗 trace をエクスポートする（Agent の監視と失敗復旧を参照）。
2. 失敗タイプで分類する：ツール呼び出しエラー、引数形式エラー、状態遷移エラー、最終回答エラー。
3. 脱感作する：PII/secret/顧客データを削除し、traceId、span_id、workflow_name を残す。
4. 人間がラベル付けする：正しい/誤り/一部正しい + 失敗理由。
5. 階層に分けて保存する：golden set / negative cases / edge cases。

Phoenix datasets の文書では、examples は production、staging、evaluations、manual から収集できるとされています。本番環境は実タスク分布を提供し、staging 環境のテストケースは境界シナリオを補えます。

3.2 階層分けの基準

階層	基準	用途
golden set	100% 正しい + 高頻度タスク	リリースゲートで必須通過、pass rate のしきい値
negative cases	典型的な失敗パターン	回帰テストのアラート。同じ失敗の再発を防ぐ
edge cases	長尾/境界シナリオ	補助的なカバレッジ。必要に応じて組み込む

ラベル付けの次元（LLM-as-judge rubric に対応）：ツール選択の正しさ、引数形式の正しさ、実行順序の正しさ、最終回答の品質、人間のラベルとの一致度。

OpenAI Evaluation best practices は、typical、edge、adversarial cases を含むテストデータと、human expert labellers の利用を推奨しています。ここでの階層分けはその考え方に対応しますが、評価セットの目的はリリースゲートを守ることなので、高頻度タスクと典型的な失敗パターンをより重視します。

4. Trajectory assertions の書き方

4.1 軌跡制約の種類

Trajectory assertions は、Agent が守るべきツール呼び出し、引数形式、状態遷移、承認ルールを定義します。代表的な制約は次の 5 種類です。

制約タイプ	例	失敗条件
必須ツールリスト	["check_permission", "refresh_data", "generate_report"]	いずれかの必須ツールが欠ける
禁止ツールリスト	["delete_user", "drop_table"]	禁止ツールを呼ぶ
引数形式制約	{"refund_amount": "number", "user_id": "uuid"}	引数の型が違う
状態遷移順序	["init", "check", "approve", "execute"]	状態が飛ぶ、または重複する
承認ステップの存在	["need_approval", "approval_granted"]	承認イベントが欠ける

LangSmith の Evaluation concepts は、Agent 評価で trajectory、tool selection、argument formatting を評価すべきだと述べています。Phoenix の Running Evals on Traces 文書では、span_id を使って評価結果を特定の実行区間に関連付けています。つまり、軌跡断言は失敗した span までたどれる形にできます。

Agent の計画能力評価（N158）と状態機械・prompt 境界を読んでいれば、状態軌跡フィールドが state/event/checkpoint から来ることがわかります。これにより、状態遷移が期待どおりの順序か検証できます。

4.2 コード例

以下は、一般的な Agent 評価で使える trajectory assertions の擬似コード例です。

# trajectory assertions の例
def assert_trajectory_correct(result):
    # ツール呼び出しリストを抽出する
    tools_called = [call.tool for call in result.tool_calls]

    # 必須ツール
    required_tools = ["check_permission", "refresh_data"]
    for tool in required_tools:
        assert tool in tools_called, f"Missing required tool: {tool}"

    # 禁止ツール
    forbidden_tools = ["delete_user"]
    for tool in forbidden_tools:
        assert tool not in tools_called, f"Called forbidden tool: {tool}"

    # 引数形式制約
    for call in result.tool_calls:
        if call.tool == "refund":
            assert isinstance(call.args["refund_amount"], (int, float)), "refund_amount must be number"
            assert len(call.args["user_id"]) == 36, "user_id must be uuid format"

    # 状態遷移順序
    expected_states = ["init", "check", "approve", "execute"]
    actual_states = [event.state for event in result.state_events]
    assert actual_states == expected_states, "State transition order mismatch"

    # 承認ステップの存在
    approval_events = [e for e in result.state_events if e.type == "approval"]
    assert len(approval_events) >= 1, "Missing approval step"

このコードは、必須ツール、禁止ツール、引数形式、状態遷移順序、承認ステップをどう確認するかを示しています。実装では LangSmith の trajectory assertion や Phoenix の trace eval を使えますが、中核ロジックは同じです。

Agent の計画能力評価を読んでいれば、計画軌跡も回帰サンプルに変換し、タスク分解や自己修正能力の検証に使えるとわかるはずです。

5. LLM-as-judge の階層型 rubric

5.1 なぜ総合点だけでは足りないのか

LLM-as-judge が総合点だけを返すと、揺れが大きく、原因の切り分けが難しくなります。80 点という結果は、ツール選択は間違っているが回答はたまたま正しい、あるいは回答は誤っているが形式は整っている、という意味かもしれません。prompt、tool schema、検索、状態機械のどこに問題があるのか区別できません。

LangSmith の Evaluation concepts は、Agent の主要コンポーネントごとに品質基準を定義することを推奨しています。correct tool selection、proper argument formatting、trajectory です。各コンポーネントを分けて採点することで、モデル更新や prompt 変更後の退化を素早く見つけられます。

Prompt エンジニアリング上級実践を読んでいれば、DeepEval も TaskCompletenessMetric のような階層指標を重視しており、最終出力だけを見ないことがわかります。

5.2 階層型スコア表

次の rubric は、Agent 評価を 5 つの次元に分け、それぞれ 0〜2 点で採点します。

次元	0 点	1 点	2 点
ツール選択の正しさ	誤ったツール	一部正しい	完全に正しい
引数形式の正しさ	型エラー	一部フィールドに形式エラー	完全に正しい
実行順序の正しさ	状態が飛ぶ	順序にずれがある	完全に正しい
最終回答の品質	要求を満たさない	一部満たす	完全に満たす
人間のラベルとの一致度	専門家判断と矛盾	一部一致	高度に一致

LangSmith や Phoenix で使える rubric 設定例です。

rubric:
  dimensions:
    - name: tool_selection
      weight: 0.3
      criteria:
        0: "誤ったツールを呼び出した"
        1: "一部の正しいツールを呼び出した"
        2: "ツール選択が完全に正しい"

    - name: argument_formatting
      weight: 0.2
      criteria:
        0: "引数の型が誤っている"
        1: "一部フィールドの形式が誤っている"
        2: "引数形式が完全に正しい"

    - name: execution_order
      weight: 0.2
      criteria:
        0: "状態遷移が飛ぶ、または重複する"
        1: "実行順序にずれがある"
        2: "実行順序が完全に正しい"

    - name: final_answer_quality
      weight: 0.2
      criteria:
        0: "ユーザー要求を満たしていない"
        1: "要求を一部満たしている"
        2: "要求を完全に満たしている"

    - name: human_alignment
      weight: 0.1
      criteria:
        0: "専門家判断と矛盾している"
        1: "一部一致している"
        2: "高度に一致している"

ツール選択の重みが最も高い（0.3）のは、Agent の中核が正しいツールを呼ぶことだからです。人間のラベルとの一致度は最も低い（0.1）重みとし、LLM-as-judge と専門家判断の一致を校正するために使います。

6. リリースゲートと回帰テスト

6.1 CI 連携手順

Agent eval dataset の価値は、CI に接続してリリースゲートにすることで生まれます。連携手順は次のとおりです。

チェックリスト：

1. CI pipeline に eval 実行ステップを追加する（pytest、LangSmith offline eval、Phoenix experiments など）。
2. pass rate のしきい値を設定する（例：90%）。
3. golden set は全件通過（100%）を条件にする。
4. negative cases のアラートルールを設定する（通知はするが、必要に応じてブロックしない）。
5. ベースラインバージョンと現在バージョンを比べる version comparison（improvement/regression）を設定する。
6. ゲートの発火タイミングを定義する（PR / merge / canary）。

LangSmith の Evaluation concepts は、offline evaluations を regression testing、unit testing、backtesting に使えるとしています。対象は datasets 内の examples です。Phoenix experiments の文書は、prompt、LLM、アプリケーションロジックの変更を比較し、improvement/regression を判断できると説明しています。DeepEval は pytest-native eval をうたい、CI/CD や Python scripts で実行でき、LLMTestCase と TaskCompletenessMetric で Agent trace を階層的に採点できます。

6.2 しきい値設定表

指標	しきい値	失敗時の動作
pass rate	≥ 90%	マージをブロック
golden set	100% 通過	マージをブロック
negative cases	アラート発火	ブロックはせず、チーム責任者に通知
version comparison	regression なし	マージをブロック

CI 設定例です。

evaluation:
  triggers:
    - pull_request
    - merge_to_main
    - canary_deployment

  conditions:
    pass_rate: 0.9
    golden_set: 1.0
    no_regression: true

  notifications:
    on_failure: ["team-lead", "on-call"]
    on_negative_alert: ["team-lead"]

ゲートの発火タイミングには、問題のあるコードを main branch に入れないための PR、merge 後も条件を満たすことを確認する merge、production traffic の前に検証する canary があります。コスト制御とモデルルーティング（N156）を読んでいれば、コストしきい値もゲート条件にできるとわかるはずです。ここでは評価しきい値に絞ります。

7. 実ケースの振り返り

7.1 シナリオ説明

日報 Agent は先週、正常にレポートを生成していました。check_permission で権限を確認し、refresh_data でデータを更新し、generate_report でレポートを生成する流れです。モデル更新後も Agent は「一見正しい」最終サマリーを返しましたが、軌跡では check_permission と refresh_data が抜けていました。

ユーザーが受け取ったのは、権限チェックもデータ更新もされていないレポートです。しかし表面上はわかりません。公開 benchmark では、このリスクを検出できません。あなたの tool schema と状態機械を持っていないからです。

7.2 問題の特定

監視 platform から失敗 trace をエクスポートします（Agent の監視と失敗復旧を参照）。軌跡を分析すると、ツール呼び出しリストに check_permission と refresh_data がなく、状態遷移は init から execute へ直接飛び、check と approve が欠けていました。最終回答は正しく見えますが、データソースは更新されていません。

ラベルは「ツール選択エラー + 状態遷移ジャンプ」です。

7.3 データセット更新

失敗事例を negative cases に追加します。同時に golden set も補強します。先週成功した日報タスクを探し、完全なツール呼び出しシーケンスを含め、正しいケースとしてラベル付けします。

trajectory assertions を更新します。必須ツールリストに check_permission と refresh_data を追加し、状態遷移順序の断言を ["init", "check", "approve", "execute"] にします。

7.4 CI ゲートによる検知

次回 PR で eval が実行されます。negative case がアラートを出します：check_permission のツール呼び出しが欠けています。golden set は全件通過しているため、成功ケースの基準は壊れていません。

原因は prompt でした。更新後のモデルは「レポートを生成する」という指示を直接実行寄りに解釈し、前段の権限チェックとデータ更新を無視していました。

7.5 修正と回帰確認

prompt を修正し、「レポート生成前に必ず権限を確認し、データを更新する」と明記します。eval を再実行すると、pass rate は 85% から 95% に上がり、negative case はアラートなしで通過し、golden set は全件通過します。version comparison も regression なしの improvement を示します。

マージしてリリースします。CI ゲートが、この退化を production 前に止めました。

7.6 フィールド対応表

段階	使用するフィールド
問題特定	traceId、span_id、tool_calls、state_events
データセット更新	input、expected tool calls、trajectory assertions、human labels
CI ゲート	pass rate、golden set、negative cases
修正検証	pass rate、version comparison

このループは、本番失敗から回帰テストまでの流れを示しています。事故の振り返りごとに、traceId、tool call、approvalId、state event、人間の判定を eval example として固定すれば、次回リリース前に同じ失敗を防げます。

8. 次に読むもの

• Agent 状態機械と prompt 境界：状態遷移制約と軌跡断言フィールドの出どころを理解する
• Agent 権限モデル：承認記録フィールドと高リスクツール呼び出しルールを理解する
• 人間の承認設計：approval records と承認フローをテストとして固定する方法を理解する
• コスト制御とモデルルーティング：コストしきい値をゲート条件にする考え方を理解する
• Agent の監視と失敗復旧：失敗 trace のエクスポートと事故振り返りループを理解する