2026-08-15 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
エージェントが本番投入される数が増えるにつれ、「答えが合っているか」だけを見る評価では見落としが多いことが各社の実装から見えてきた。ツール呼び出しの順序、途中の迂回、非決定性による再現性の低さは最終出力だけでは検知できない。Anthropic・OpenAI・Langfuse がそれぞれの立場から示した実装は、評価対象を最終出力からステップ単位のトレースへ分解するという同じ方向を向いている。
Anthropic はエージェント評価を Tasks（入力と成功基準）、Graders（コードベース・モデルベース・人間による採点）、Transcripts（API呼び出しとツール使用の全記録）の三要素に分解して構造化する。非決定性を扱うために pass@k（k回中1回でも成功する確率）と pass^k（k回すべて成功する確率）を区別するのが特徴で、1試行あたり成功率75%でも3回連続成功の pass^3 は約42%まで落ちる、という具体例で「1回動く」と「本番で安定して動く」の差を示している。
この分解が広がったのは、最終出力だけを見る評価では合格していたはずのタスクが、実は無関係なツール呼び出しを挟んでいたり、有効な別解を「決まった手順と違う」という理由で誤って不合格にしていたりする、という失敗を各社が経験したからだ。Anthropic は Opus 4.5 が CORE-Bench で「96.12」の解答を「96.124991…」という厳密一致を要求する採点で不合格にされ、スコアが42%まで沈んだ事例を挙げている。採点ロジック自体のバグをモデルの欠陥と誤認するリスクが、軌跡単位でのレビューを必須にした。
OpenAI が Codex 向けに示した Skill eval の作り方は、outcome（タスク完了）・process（意図した手順を踏んだか）・style（出力が規約に沿うか）・efficiency（無駄な試行錯誤がないか）の4分類で成功基準を先に定義し、10〜20件の少数プロンプトセット（陽性・陰性の両方を含む）から始める。判定は二段構成で、codex exec --json の JSONL イベントストリームを解析して「npm install を実行したか」のような決定的チェックを行い、スタイルや規約遵守など定性的な要件は --output-schema で出力を構造化JSONに固定したモデル採点で処理する。
この役割分担が定着したのは、決定的チェックは高速で再現性が高い一方コーディング規約のような定性面を扱えず、モデル採点は柔軟だが素の自然文出力では同じ基準で一貫して採点しづらいためだ。--output-schema で採点結果自体をスキーマ制約すれば、GitHub Actions 上で他のCIチェックと同様に扱える。OpenAI は Codex GitHub Action がこの --output-schema を codex-args 経由でそのまま渡せる設計にしていることを明記している。
Langfuse は2026年7月時点で、LLM-as-a-judge の評価対象を trace全体からobservation（スパン）単位に移し、trace単位のジャッジ評価をレガシー扱いにした。あわせてツールコールを id / name / arguments / type / index を持つ構造化フィールドとして評価器に渡すようにし、生のテキスト出力を正規表現でパースする必要をなくした。エージェントのループを俯瞰するグラフビューも、繰り返しステップを「retrieve_docs (3/3)」のように集約する表示と、実行順に展開するDAG表示の2モードを用意している。
trace全体を一つのジャッジにかけると、失敗がどのステップに起因するか特定できず、改善のフィードバックが曖昧になる。observation単位に分解すれば、失敗したスパンにピンポイントで採点結果を紐づけられる。ツールコールの構造化フィールド化も同じ発想で、後付けのテキスト解析は引数のフォーマット変更ひとつで壊れるため、構造を最初からデータとして持たせる方向に各社が寄っている。