Skip to Content
Docs04. 評価軌跡(trajectory)評価
中級trajectory-evaluationevaluationagent-loop更新: 2026-07-05この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

軌跡(trajectory)評価

この記事の目的

最終出力だけでは見えない Agent の品質 — 経路の正しさ・効率・安全性 — を、軌跡(実行ステップの列)に対する評価として設計できるようになります。ルールベースのアサーションと LLM-as-a-Judgeコードでは採点できない開放的な出力を、基準を与えた別の LLM に判定させる評価手法。judge 自体の検証(人手ラベルとの一致率測定)を前提とする。 をどう使い分けるか、そして「経路をどこまで縛るべきか」を判断できるようになります。

対象読者

  • 「最終出力は合っているのに挙動が不安」「失敗の原因がどのステップか分からない」という状態にあるエンジニア
  • ツール呼び出しの正しさ・効率・安全性を定量的に検証したいチーム

前提知識

本文

概要: 最終成果だけでは足りない 2 つの理由

軌跡(trajectory)とは、Agent ループLLM が「観測 → 思考 → 行動」のサイクルを繰り返し、完了・失敗・上限のいずれかの停止条件まで自律的に処理を続ける制御構造。の 1 回の実行が残すステップの列 — モデルの思考・ツール呼び出し(名前と引数)・ツール結果・最終応答 — のことです。

最終成果の評価だけでは不足する理由は 2 つあります。

  1. 正解でも悪い経路がありえます — 偶然の正解(検索に失敗したのにモデルの学習知識で答えた)、非効率な正解(同じ検索を 5 回繰り返した)、危険な正解(不要な書き込み操作を経由した)は、最終出力の採点ではすべて「合格」になります
  2. 不正解の原因が分かりません — 失敗がツール選択・引数・結果の解釈・統合のどこで起きたのかは最終出力からは見えず、分からなければ直せません。軌跡は失敗の局所化(どのステップから壊れたか)の一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。です

詳細: 軌跡の何を見るか

観点問い例
ツール選択呼ぶべきツールを呼ぶべきときに呼んだか検索が必要な質問に、検索せず学習知識で答えていないか
引数の質引数が正しく妥当かID の取り違え、検索クエリが的を外していないか
効率無駄なステップがないか総ステップ数、同一ツールの同一引数での繰り返し
エラー回復ツール失敗後の行動が適切かエラーを無視して進む・同じ呼び出しを盲目的に繰り返すことがないか
安全性禁止・不要な操作をしていないか照会タスクの途中で書き込み系ツールを呼んでいないか

詳細: 評価方法は 2 系統の併用

方式仕組み向くもの限界
ルールベースのアサーション軌跡の構造化ログに対してコードで条件を検査する必須ツールの呼び出し有無、順序の制約、回数上限、禁止操作、引数の形式「引数の質」「回復の適切さ」のような判断を要する観点は書けない
LLM-as-a-Judge による軌跡レビュー整形した軌跡を judge に渡し、観点別に判定させる経路の合理性・エラー回復の適切さなど判断を要する観点コスト・非決定性。judge 自体の検証が必要(LLM-as-a-Judge)

機械的に判定できる条件、特に安全性はアサーションで固めます。たとえば「禁止ツールを呼んでいない」「承認なしに書き込みをしていない」「ステップ数が上限以内」は数行のコードで検査でき、決定的で速く、judge のような検証も要りません。判断を要する観点だけを judge に回します。

なお、安全性の条件は評価時の検査だけでなく実行時のガードにもするべきものです(Human-in-the-Loop 設計、ガードレール)。評価は「ガードが効いていること」の確認として機能します。

詳細: 前提は軌跡の構造化された記録

軌跡評価は、ループの各ステップ(種別・ツール名・引数・結果・トークン量・所要時間)が構造化された形式で記録されていることが前提です。この記録は本番の可観測性トレース・メトリクス・ログといった外部出力から、システム内部で何が起きたかを説明できる性質。Agent では技術メトリクスに加えて品質シグナルの設計が必要になる。(可観測性とトレーシング)で必要になるものと同じです。評価専用の後付けログを作らず、評価と本番で共通のトレース形式に最初から投資すると、本番で起きた失敗をそのまま評価ケースへ変換できるようになります。

設計判断: 経路をどこまで縛るか

軌跡評価には「正しい経路」を固定しすぎる罠があります。Agent の価値は経路を実行時に決める自由度にあるため(Workflow 型 vs Agent 型の使い分け)、期待する軌跡との完全一致を要求すると、正しい別解を不合格にし、モデルやプロンプトの変更のたびに大量に壊れる脆いテストになります。

  • 縛るのは不変条件だけにします — 安全性(禁止操作の不在)、必須のマイルストーン(「この情報を取得してから回答する」)、資源上限(ステップ数・コスト)
  • 「このツールをこの順でこの引数で」まで指定したくなったら、その部分はそもそも Agent ではなく Workflow として固定すべきだったサインです

長いタスクにはマイルストーン単位の部分点を設計します。全体の合格/不合格だけでは「どこまで進めたか」の改善が観測できません。「候補を提示できた」「確認を取ってから実行した」のような中間到達点を採点対象にすると、改善が数値に現れるようになります。

実務での注意点

アンチパターン

  • 期待する軌跡との完全一致を要求する → 正しい別解を不合格にし、モデル・プロンプト変更のたびに大量に壊れて保守されなくなる → 不変条件(安全性・マイルストーン・上限)だけをアサーションにする
  • 生の軌跡ログをそのまま judge に流し込む → 長大な JSON がコンテキストを圧迫し、判定の質が下がる → ステップごとの要約(ツール名 + 引数の要点 + 結果の要点)に整形してから渡す
  • 軌跡の記録を評価のときだけ後付けする → 本番と評価で見えるものが食い違い、本番の失敗を再現・ケース化できない → 最初から評価と本番で共通のトレース形式で記録する

チェックリスト

  • 軌跡が構造化された形式で記録されている(評価と本番で共通)
  • 安全性の条件(禁止操作・承認必須の操作)がアサーションで検査されている
  • 効率の上限(ステップ数・同一呼び出しの繰り返し)が検査されている
  • 経路の完全一致ではなく不変条件で縛っている
  • 判断を要する観点に使う judge は人手ラベルで検証済みである
  • 長いタスクにマイルストーン単位の部分点が設計されている

関連トピック

参考資料

TODO・未確認事項

LLM-as-a-Judge回帰テストと CI 組み込み