新しいモデルのベンチマークを回すのはもうやめて、エージェントがサブスクリプションの解約を試みる様子を観察し始めてください。その二つの活動の間にこそ、プロダクションシステムが崩壊する原因が潜んでいます。シングルターンのテストでは、回答が好ましい響きかどうかは分かります。しかし、エージェントが誤って別の顧客に返金したのか、カレンダーAPIに対して14回もループを繰り返したのか、あるいは不正チェックを完全にスキップすることに決めたのかまでは分かりません。エージェントが生成するものの中で、テキストは最もリスクの低いものです。真のリスクは、エージェントが操作するツール、変更するデータ、そして助けを求めるべき時にそのまま進んでしまう瞬間に潜んでいます。

なぜテキストベンチマークはプロダクションで失敗するのか

標準的なベンチマークでの高スコアは、誤解を招く安堵感を与えるものになっています。優雅な文章を書くエージェントであっても、運用上のリスクとなる可能性があります。システムが予約を入れたり、データベースのレコードを編集したり、サポートチケットを作成したりする場合、生成されたテキストはワークフローの表面に見えている部分に過ぎません。その裏側で、エージェントはどのエンドポイントを叩くか、どのようなペイロードを送信するか、いつ停止するかといった具体的な意思決定を行っています。読解力のリーダーボードで上位にいても、リソースの二重予約、誤った行の更新、あるいはログファイルへの機密状態の漏洩によって、コストを増大させてしまう可能性があるのです。出力の洗練度だけでなく、作業のメカニズムを検証する必要があります。もしエージェントがオフラインのQAテストで高スコアを出しながら、ループやツールの誤用によってワークフローを失敗させるのであれば、その評価は間違ったシグナルを見ていることになります。

5つの依存関係のマッピング

Van Data Teamのチームは、すべての評価を5つの特定のコントロールポイントをマッピングすることから始めます。これにより、問いの性質が根本から変わります。「あるモデルが別のモデルより賢いか」と問うのをやめ、「エージェントが実際の制約条件下で、プロダクションのタスクを実際に完了できるか」を問い始めるのです。

ビジネス成果 (Business outcomes)。 「完了」がドル換算でいくらになり、顧客にどのような影響を与えるのかを定義してください。エージェントが要約を出力したからといって、タスクが完了したことにはなりません。在庫レコードが正確であり、予約が確定し、顧客が有効な追跡番号を受け取ったときに初めて、タスクは完了したと言えます。

変更可能な状態 (Mutable state)。 エージェントが変更を許可されている範囲を正確に把握してください。どのテーブル、どのステータス、どの勘定フラグでしょうか？エージェントが返金、ジョブの再スケジュール、請求先住所の更新を行える場合、それが触れるすべてのフィールドをリストアップする必要があります。

ツールの権限 (Tool permissions)。 どのAPIエンドポイントと関数がスコープ内にあるかを明示してください。検索ツール、書き込みツール、通知ツールへのアクセス権を持つエージェントは、境界線が曖昧だとそれらを混同してしまいます。各権限を特定の運用上のニーズに紐付けてください。

失敗からのリカバリ (Failure recovery)。 カレンダーAPIがタイムアウトしたり、500エラーを返したり、不正な形式のJSONを返したりした場合に何が起こるかを決定してください。エージェントはパニックを起こしたり、成功メッセージをハルシネーション（幻覚）したり、永遠にリトライを繰り返したりしてはいけません。明確なフォールバックパスが必要です。

人間によるレビューゲート (Human review gates)。 エージェントが続行する前に、人間が承認しなければならない瞬間を特定してください。これは自動化の弱さを示すものではありません。影響の大きい変更に対する安全弁であり、評価基準（ルーブリック）のための正解ラベル（ground-truth）のソースとなるものです。

真の評価プランとはどのようなものか

依存関係のマッピングが終わったら、プロダクションの複雑さに対応できる評価プランが必要です。スライド資料に並ぶような指標は、ここでは役に立ちません。

合成データによる問題集ではなく、実際のプロダクションでの失敗からテストセットを構築してください。 もしエージェントが先週の火曜日に、2つの似たようなSKUを混同して失敗したのであれば、その全く同じ混同を恒久的なテストケースにすべきです。インシデントから新しい教訓を得るたびに、評価スイートを成長させていく必要があります。

運用の観点から成功の定義を明確にするルーブリックを作成してください。 「役に立つ」や「正確である」といった曖昧な基準は役に立ちません。有用なルーブリックとは、「返金タスクは、元の支払いIDが参照され、金額がリクエストと一致し、確認メールがキューに入れられ、トランザクションIDがログに記録された場合にのみ成功とする」といった形で定義されるものです。

ツール呼び出しとリトライに関するトレース仕様を定義してください。 エージェントが何を計画し、実際に何を呼び出し、何回リトライし、そのリトライ戦略が適切であったかを確認できるオブザーバビリティ（観測性）が必要です。ツールレベルの粒度を持たないトレースは、単なる綺麗な物語に過ぎません。

人間にアラートを出すタイミングに関するポリシーを設定してください。 エージェントは自らの境界線を理解している必要があります。リクエストが金額のしきい値を超えた場合、VIPアカウントを参照した場合、あるいは未経験の状態に遭遇した場合は、推測するのではなくエスカレーションを行うべきです。

Install release gates to block bad model upgrades. A new model is only an upgrade if it improves your specific outcomes. If it hallucinates tool arguments more often, increases latency, or introduces new safety risks, it does not ship. The gate keeps production stable even when the base model vendor ships a new version.

Runtime Grading: Watching the Agent Work

Anthropic has been pushing the industry to move beyond offline tests toward runtime grading. Instead of judging a transcript after the fact, runtime grading lets a system judge the agent's work while the task is still in flight. This creates a chance to catch errors before they harden into real problems.

Adding a grader costs tokens and latency. You cannot afford to grade every tiny step. The placement of each grader is a design decision. Put them where the mistakes are expensive. The most valuable checkpoints sit just before committing a state change to a database, just before capturing a payment, and just before sending a message to a customer. These are the moments where a bad decision becomes an irreversible action.

Watch out for a specific blind spot. If the same model performs the work and also grades the work, it may miss the same mistakes. The reasoning that produced an error can easily rationalize that error away during review. For high-impact tasks, keep human review inside the loop. Let people validate the grader's own judgment, especially when money or customer trust is on the line.

The goal here is operational control. Connect your incident data, your task rubrics, and your runtime traces into one feedback cycle. Evaluate the whole path: the plan, the tool use, the recovery behavior, and the final result. Use offline tests to catch known, reproducible errors before release. Use runtime traces to find the new failures you did not anticipate. Use human review to discover where your rubrics are naive and need tightening.

So ask yourself: where would you put a runtime grader in your workflow? Before a tool call, after a tool call, or only before a risky change? Most teams start too broad, grading everything, and then grind to a halt under the cost. Start narrow. Pick the one action that would hurt the most if it went wrong. Put a grader there first.

Start With One Expensive Mistake

Operational evaluation is not a research exercise. It is a way to sleep better once the agent is live. You do not need a perfect framework on day one. You need a single, well-defined workflow, a rubric written in plain business terms, and a grader placed at the exact moment where an error becomes expensive. Get that right, and you have a foundation you can actually trust.

If you want to dig deeper into agent evaluation and runtime grading with a community of practitioners, you can find the GyaanSetu learning community at https://t.me/GyaanSetuAi.