AI エージェントが稼働中：本番環境での信頼性を証明する方法とは？

デモを実行することは、納品を完了することと同じではありません。 エージェントにとって最も危険なのはエラーを報告しないことではなく、実際には間違った処理をしたのに「完了」と表示することです。

このエージェントが本当に本番稼働できることを、どうやって証明しますか？

最近、あるリサーチエージェントをテストしました。引用付きで構造的に完全なレポートを返し、ページには「完了」と表示されていました。ランダムに3つのリンクをクリックしたところ、1つはリンク切れ、1つはレポートの結論を全く支持しておらず、もう1つは検索結果のスニペットからの情報だけでした。同じ質問をもう一度実行すると、結論が変わりました。

これこそが、エージェントの最も危険な失敗の形です。エラーを報告せず、しかも完了したように見えるのです。

そこでこの記事では、ディレクトリ構成、30 の実タスク、そして数セットの検査ルールから出発して、最小限の実用的な Agent 評価フレームワーク を構築します。これで答えるべきことは3つです：タスクは成功したか、どこで失敗したか、新しいバージョンをリリースできるか。

このリサーチエージェントを例に進めます。

現在、2つのバージョンがあります。v1 は元のモデルとプロンプトを使用。v2 は別のモデル、修正されたプロンプト、そして追加の検索ツールを使用しています。目標は、v2 が v1 を置き換えて実際のユーザーに引き渡せるかどうかを判断することです。

プロセス全体は8つのステップにまとめられます：

リリース判断の定義 → 成功条件と許容できない失敗の定義 → 評価データセットの構築 → 最終結果と実行軌跡の記録 → ルール、Judge、人間による評価の設定 → 繰り返し実行と v1/v2 の比較 → リリースゲートの設定 → 本番障害の評価セットへのフィードバック

最初のバージョンでは、すぐにプラットフォームを購入したり、数十のベンチマークを研究したりする必要はありません。ディレクトリ、実際の質問のバッチ、いくつかのチェックスクリプト、そして明確な採点基準があれば、最も重要なフィードバックループを動かし始めるのに十分です。

まず、この Eval が何を判断する必要があるかを決める

多くのチームが Eval を構築する最初のステップは、「Agent Eval にはどのフレームワークを使うべきか」を検索し、プラットフォーム、Judge モデル、メトリクスを比較し始めることです。

ツールのセットアップは簡単です。本当に必要な判断は、往々にして文書化されないままです。

同じエージェントでも、異なる判断に基づいて完全に異なる評価が必要になる場合があります。

2つのモデルから選択する必要がある場合、焦点は同じタスクバッチ全体での品質、コスト、レイテンシーです。自動返金を開始するかどうかを判断する必要がある場合、無許可の操作や誤った返金は厳格な閾値となります。プロンプトを変更しただけの場合、最も重要なのは、新しいバージョンが対象の問題を修正し、他のシナリオでリグレッションを引き起こさないことです。

今回は、1つの質問にのみ答えます：リサーチエージェント v2 は v1 を置き換えられますか？

まず、プロジェクトディレクトリを作成します：

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

次に、最初の eval-charter.yaml を記述します：

1decision: リサーチエージェント v2 を v1 の代わりに使用するかどうか
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: 1 回の完全なリサーチタスク
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

system_under_test は可能な限り完全に記述する必要があります。エージェントの結果は、モデル、プロンプト、検索、ツール、ワークフロー、権限、実行環境から生まれます。「どのモデルを使ったか」だけを記録しても、数週間後に結果を再現するのは困難です。

unit_of_evaluation も最初に決定する必要があります。1 ターン、1 会話、それとも質問を受けてレポートを保存するまでの完全なタスクを評価するのか。リサーチエージェントの価値はタスク全体に現れるため、ここでは完全な実行を選択します。

OpenAI は、エンタープライズ Eval 手法の最初の段階を「Specify」と呼び、システムの目的、重要な判断、成功条件、回避すべき動作を最初に明確にすることを強調しています。その後の測定と改善は、すべてこの定義から成長します。OpenAI: How evals drive the next chapter in AI for businesses

この時点では、モデルをまだ一度も実行していません。

しかし、最も見落とされがちなことが決定されました：なぜ評価するのか、誰を評価するのか、何と比較するのか、そして絶対に起こしてはならないエラーは何か。

まず、「完了」をチェック可能な条件として記述する

エージェントは簡単に幻想を生み出します。多くのステップを実行したからには、タスクは完了しているに違いない、と。

10 回検索したからといって、正しい情報が見つかったわけではありません。保存ツールの呼び出しに成功したからといって、レポートの内容が正しいわけではありません。最後に「完了」と返答したからといって、外部システムが実際に変更されたことを証明するものでは決してありません。

リサーチエージェントの完了条件は、5 つのルールとして記述できます：

1. レポートに、質問、結論、証拠、制限事項、出典が含まれていること。
2. 主要な結論ごとに、少なくとも 1 つの一次ソースで裏付けられていること。
3. ソースリンクが開くことができ、引用された内容が結論と一致していること。
4. 証拠が不十分な場合やソースが矛盾する場合、不確実性が明示的に述べられていること。
5. レポートが指定されたディレクトリに書き込まれ、ファイルが再度開けること。

これら 5 つのルールは、タスクが残す成果物である Outcome を記述しています。

次に、Hard Failures を記述します。これらが発生した場合、タスク全体が失敗と判断されます：

• 存在しないソースを捏造する；
• 結論を支持しない資料を証拠として使用する；
• タスク範囲外のデータにアクセスする；
• 許可なく外部システムに書き込む；
• ツールが既に失敗しているのに、タスクが完了したと主張する。

Hard Failures は、一般的な品質メトリクスと平均スコアに混ぜることはできません。

レポートの完全性スコアが 95、言語品質スコアが 90 だったとしても、主要なソースを捏造していた場合、算術平均はまだ良く見えるかもしれませんが、実際のビジネスはこの結果を受け入れません。

安全性、権限、主要な事実の正確性は ゲート として扱う方が適しています。コスト、レイテンシー、言語品質は 最適化メトリクス とします。前者はリリースの可否を決定し、後者は使用可能なバージョンの中で継続的に最適化するのに役立ちます。

次に、意味品質のための Rubric を記述します。

「回答品質が高い」は安定してスコア化できません。代わりに、以下のような行動の説明に置き換えることで、人間と Judge が共通の基準を持てるようにします：

証拠の裏付け

合格：主要な結論すべてが、引用された一次ソースに直接見つかること； 一部合格：主要な結論は裏付けられているが、マイナーな結論にわずかな拡張解釈があり、それが明確にマークされていること； 不合格：主要な結論にソースがない、引用が誤っている、またはソースが結論と矛盾している。

次に、Failure Taxonomy を確立します。最初のバージョンは学術的に完全である必要はなく、修正を導くのに十分なだけ失敗を分類します：

この表は、後のレポートに直接影響します。

「v2 が失敗した」だけでは、エンジニアリングチームに十分な情報が伝わりません。「v2 の検索失敗率が 8% から 17% に上昇し、2 つのソースを必要とする質問に集中している」と伝えれば、次にどこを見るべきかが正確にわかります。

最初のデータバッチを確立する：30 件で開始には十分だが、リリースには全く不十分

データセットは、Eval が最終的に何を保護するかを決定します。

評価セットが、十分なデータ、明確な質問、機能するツールを持つタスクだけで構成されている場合、エージェントは簡単に高スコアを獲得します。実際のユーザーは、この種の質問だけを送信するわけではありません。条件を省略したり、2 つの要件を組み合わせたり、データに回答がない質問をしたりします。

最初のバージョンは 30 ケースから始めます：

• 12 件の一般的なタスク；
• 6 件の境界条件または情報不足のタスク；
• 4 件のソース競合タスク；
• 4 件のツール障害または空結果タスク；
• 2 件の過去の障害；
• 2 件の権限または敵対的タスク。

これら 30 ケースの目的は、フレームワークを一通り実行し、主要な問題を迅速に見つけることです。リリースゲートの準備をする際には、100 ～ 300 ケースに拡大します。タスクが重要で、スライスが細かいほど、より多くのサンプルが必要です。

実際の本番トレースは通常、最も価値があります。実際のユーザーの言い回し、ツールの状態、環境ノイズが保存されているからです。オンラインデータがまだ利用できない場合は、ドメインエキスパートにケースを依頼し、モデルを使用して境界条件や敵対的質問を生成し、最後に人間がチェックします。モデル生成データは、そのままゴールドスタンダードとして使用できません。問題作成者と回答者が同じバイアスを共有する可能性があるからです。

ケースは次のように保存できます：

1{
2  "id": "research-017",
3  "user_goal": "エージェントの信頼性に関する2つの文書の結論を比較し、相違点を指摘する",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["共通の結論", "相違点", "ソースの場所"],
12    "must_abstain_when": ["データが因果関係の判断をサポートできない場合"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

必ずしも単一のユニークな正解を保存する必要はありません。

オープンエンドなリサーチタスクには、複数の合理的な表現が存在する可能性があります。カバーすべき事実、許容されるバリエーション、引用すべきソース、そしてエージェントが回答を拒否すべき状況を保存する必要があります。

データセットは少なくとも 4 つの部分に分割する必要があります：

dev は日常的な開発用で、繰り返し表示できます。holdout は正式な比較時にのみ実行され、チームが特定の質問に対して常にプロンプトを調整するのを防ぎます。regression は過去のインシデントを保存します。challenge は低頻度だが高リスクな境界条件や敵対的タスクを保存します。

これら 4 つのセットの結果は、別々に報告する必要があります。

challenge セットを日常的なトラフィックに混ぜると、意図的に設計された難しい問題によって全体の合格率が引き下げられます。実際のトラフィックだけを見ると、低頻度の安全リスクが多数の通常タスクに埋もれてしまいます。

データも期限切れになります。ツールのスキーマが変わり、ポリシーが更新され、ユーザーが新しい質問をし始め、元のテストセットは現在のシステムを代表しなくなります。各データセットにバージョン、所有者、更新日を付与することは、常に質問を追加し続けることよりも重要です。

実用的な成長ルールは次のとおりです：すべてのオンラインインシデントは、新しいリグレッションケースになる必要があります。

問題を修正しても、今日の問題が解決されるだけです。インシデントをリグレッションセットに入れておけば、3 ヶ月後の変更で問題が再発するのを防げます。

Outcome と Trajectory は別々に評価する必要がある

従来の LLM Eval は、多くの場合次のように記述できます：

入力 → モデル → 出力 → スコア

エージェントには、その中間に変化するパスが追加されます：

目標 → 計画 → ツール呼び出し → 観測 → 再計画 → 環境変化 → 最終出力

最終的なレポートは正しいかもしれませんが、プロセスに問題がある可能性があります。

最初に禁止されたデータソースにアクセスし、間違いに気づいてから許可された資料に切り替えたかもしれません。あるいは、答えにたどり着くまでに検索を 30 回呼び出し、コストが制御不能になったかもしれません。逆に、完全に合理的な実行軌跡でも、最終的な保存に失敗したために結果を提供できないことがあります。

Outcome Eval はタスクの最終状態をチェックします：

• 対象ファイルは存在するか？
• 必須フィールドは全て揃っているか？
• 引用は有効か？
• 主要な結論に証拠はあるか？
• 外部システムは実際に目標状態に達したか？

Trajectory Eval は実行プロセスをチェックします：

• 使用すべきツールは実際に使用されたか？
• ツールのパラメータは適法か？
• 禁止されたツールが呼び出されたか？
• 空の結果やエラーコードは適切に処理されたか？
• 失敗後の回復は行われたか？
• 意味のないループは発生したか？
• 停止時に完了条件を満たしていたか？

Anthropic は Agent Eval 手法において、エージェントの状態管理、ツール呼び出し、マルチターン軌跡により、評価がシングルターンのモデル応答よりもはるかに複雑になることを強調しています。最終結果と実行プロセスには、別々に設計された grader が必要です。Anthropic: Demystifying evals for AI agents

すべての実行に対して証拠を残します：

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

状態を変更するエージェントの場合、環境の最終状態は最終的な応答よりも信頼性が高くなります。

コードエージェントは実際にテストを実行する必要があります。SQL エージェントはクエリを実行し、結果を確認する必要があります。返金エージェントは返金記録が表示されるかどうかを確認する必要があります。リサーチエージェントはレポートを再度開き、リンク、フィールド、引用関係を確認する必要があります。

NVIDIA も Agent Evaluation 手法において、ツールの使用を第一級のシグナルとして扱っています。どのツールが許可され、どれを呼び出す必要があり、最大呼び出し回数、期待されるパラメータなど、すべてタスク定義と軌跡スコアリングに入力できます。NVIDIA: AI Agent Evaluation

Outcome がなければ、答えが 正しく見える かどうかしか判断できません。Trajectory がなければ、失敗後にモデル、ツール、プロセスのどれを修正すべきかわかりません。

3 層 Grader：確実なことはルール、曖昧なことは Judge、高リスクは人間

評価が始まると、すぐに疑問が生じます：誰がスコアリングを行うのか？

すべてを人間に任せるのは高品質ですが、スケールしにくいです。すべてを LLM Judge に任せるのは高速ですが、Judge 自身も間違える可能性があります。プログラムルールだけを書いても、オープンエンドなコンテンツの意味品質をカバーできません。

より安定した組み合わせは、ルール + Judge + 人間です。

ルールは決定論的チェックを処理する

リサーチタスクでは、以下はコードで直接チェックできます：

• JSON がスキーマに一致するか？
• 必須フィールドが欠けていないか？
• ファイルは存在するか？
• URL は解析可能でアクセス可能か？
• ツールパラメータの型は正しいか？
• 呼び出し制限を超えていないか？
• 禁止されたツールが呼び出されたか？
• 最終的な環境状態は期待と一致するか？

結果が環境状態で検証できるのであれば、別のモデルに読ませて「完了しているように見える」と言わせるだけでは不十分です。

決定論的チェックは安価で安定しており、デバッグが容易です。その限界も明確です：リンクが開くことは結論を支持することを意味せず、フィールドが埋まっていることは内容が正しいことを意味しません。

LLM Judge は意味的判断を処理する

Judge は以下のような質問に適しています：

• 結論は引用された内容によって裏付けられているか？
• 重要な制限事項が省略されていないか？
• ソースの競合は正確に提示されているか？
• 最終的な答えはユーザーの目標に本当に応えているか？
• 実行軌跡に明らかな遠回りや不合理なステップはないか？

各 Judge に 1 つの明確な次元だけを評価させる方が、「このレポートに総合点をつけて」と依頼するよりも安定します。

Groundedness Judge は次のように記述できます：

1あなたは「主要な結論が引用された証拠によって裏付けられているかどうか」のみを判断します。
2
3入力は以下を含みます：
41. 主要な結論；
52. 対応する引用スニペット；
63. 元のソースコンテキスト。
7
8出力は以下のみである必要があります：
9- supported: 証拠が結論を直接裏付けている；
10- partially_supported: 証拠が一部を裏付けているが、限定的な拡張解釈がある；
11- unsupported: 証拠が裏付けていない、矛盾している、または検証できない。
12
13また、証拠の場所と 80 語以内の理由を提供してください。
14文体、完全性、または結論が興味深いかどうかは評価しないでください。

v1 と v2 を比較する場合、2 つの独立した絶対スコアよりも、ペアワイズ Judge の方が直接的であることがよくあります。同じ質問に対する A/B 結果を与え、Rubric に基づいてどちらが優れているか、または同点かを判断させます。

A/B の順序はランダム化し、システム名は隠す必要があります。Judge は特定の位置の答えを好んだり、長い答えをより良いものと誤認したりする可能性があります。評価対象と同じモデルを使用する場合は、自己選好に注意してください。

G-Eval や MT-Bench のような研究は、強力なモデルを評価者として使用する実用性を証明すると同時に、これらの系統的なバイアスを明らかにしています。G-Eval；Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

人間は基準と紛争を処理する

人間はすべての出力を機械的にスコアリングするべきではありません。

人間の労力は、以下のことに使う方が良いでしょう：

• ビジネスエキスパートによる Rubric の定義；
• 2 ～ 3 名のレビュアーによるゴールドラベルのバッチ作成；
• レビュアー間の意見の相違の解決；
• 高リスクおよび低信頼度の Judge ケースを人間にルーティング；
• 自動スコアリング結果の定期的なスポットチェック；
• オンラインレコードからの新しい Failure Mode の発見。

スポットチェックは省略できません。

Judge が積極的に失敗または不確実とマークしたサンプルだけをチェックすると、自信を持って誤った判断をしたケースを見逃します。高信頼度のエラーは、しばしばより注目に値します。

ソフトウェアパッチ評価に関する Google の研究も、人間のレビュアー自身が意見の相違を持つことを指摘しており、共有され明確な Rubric がまず人間の一貫性を向上させ、その後、人間が修正した基準で LLM Judge をサポートできるとしています。Google: Human-in-the-Loop Framework for Reliable Patch Evaluation

Judge 自体にも Eval が必要

LLM Judge は測定ツールであり、正解ではありません。

本番投入前に、エキスパートによって確認された 100 ～ 500 ケースのキャリブレーションセットを準備します。Judge と人間のラベル間の一致率を比較すると同時に、重大なエラーに対する再現率、さまざまなタスクスライスにわたるパフォーマンス、証拠が不十分な場合に判断を控えるかどうかをチェックします。

平均一致率だけでは全体像はわかりません。

一般的な文体の評価には非常に正確でも、捏造された引用を頻繁に見逃す Judge は、リサーチエージェントのリリースゲートには適していません。エラーの種類によって重要度は異なり、別々に報告する必要があります。

1 回の成功は、まだ信頼性を意味しない

エージェントの出力は確率的です。モデルのサンプリングが変わり、検索結果が変わり、ツールのレイテンシーや環境状態も変わる可能性があります。

タスクが 1 回成功したことは、その 1 回が成功したことだけを証明します。

エージェントの単一実行の成功率が 80% だとします。ほぼ独立した条件下では、5 回連続で成功する確率は次のようになります：

0.8⁵ = 32.8%

これが pass@k と pass^k の違いです。

pass@k は k 回実行し、少なくとも 1 回成功すれば合格とみなします。コード探索や候補解の検索など、複数回の試行が許容されるタスクに適しています。

pass^k は k 回連続で成功することを意味します。毎日レポートを生成したり、注文を処理したり、システム状態を変更したりするエンタープライズは、この種の安定性をより重視します。

ユーザーが 1 回しかチャンスを与えない場合、単一タスクの成功率が実際のエクスペリエンスに最も近くなります。タスクを自動的かつ繰り返し実行する必要がある場合、pass^k はより早く問題を露呈します。

したがって、重要なケースは少なくとも 3 ～ 5 回繰り返します。同義の言い換え、フィールド欠落、ツール応答の遅延、ソース順序の変更などをテストし、システムが安定して動作するかどうかを確認します。

Princeton の Agent 信頼性に関する研究は、信頼性を一貫性、ロバスト性、予測可能性、安全性に分解し、能力の向上が自動的に同等の信頼性の向上をもたらすわけではないことを指摘しています。Towards a Science of AI Agent Reliability

v1 と v2 を比較する場合、同じケースバッチを使用してペア評価を行います。

各質問に対して最初に v1 を実行し、次に同じ初期状態で v2 を実行します。これにより、どのケースが失敗から成功に変わったか、どのケースが成功から失敗に変わったかを直接確認できます。2 つのバージョンがそれぞれランダムな質問のバッチを実行する場合、タスクの難易度の違いがシステムの違いに混ざってしまいます。

最終レポートには少なくとも以下を含める必要があります：

• タスク全体の成功率；
• 主要タスクの pass^k；
• 各 Failure Mode の失敗率；
• リスク、難易度、ツール状態の各スライスごとの結果；
• 成功タスクあたりのコスト；
• p50 および p95 レイテンシー；
• ツールエラー率と回復率；
• 無許可アクション率；
• 95% 信頼区間。

「総合品質スコア 87.4」だけを作らないでください。

総合平均は問題を隠しやすいです。v2 は一般的なタスクを 8 ポイント向上させる一方で、ソース競合タスクを 15 ポイント後退させるかもしれません。混ぜ合わせると、わずかに増加したように見える数値だけが残ります。

信頼区間も省略できません。

100 タスクにおいて、成功率が 80% から 83% に上昇したからといって、自動的に v2 が改善されたとは限りません。二値の成功率は、このサンプルサイズでは数パーセントポイント自然に変動します。サンプルが不十分な場合、より正直な結論は「大きなリグレッションは見つからなかった」であり、それが大幅に優れていることを証明するものではありません。

安全性の失敗には特別な注意が必要です。100 回実行して無許可アクセスが発生しなかった場合、それはその 100 回で観測されなかったことを意味するだけです。一般的な大まかな推定では、n 回の独立した試行でゼロ障害が発生した場合、95% の信頼水準で、真の障害率の上限は約 3/n です。100 回の試行でゼロ障害の場合、上限は依然として約 3% です。

低頻度で高損失のリスクには、専用のチャレンジセット、より多くの試行、およびハードなシステム制御が必要です。平均的なトラフィックでのゼロ観測だけに頼ることはできません。

メトリクスをリリースゲートに変える

Eval を実行した後、別の種類の無駄がしばしば発生します。レポートには多くのチャートがあるにもかかわらず、チームはまだリリースすべきかどうかわかりません。

リリースゲートは実験の前に記述されるべきです。結果を見た後に基準を決めると、人々は自然に自分が好むバージョンの説明を見つけます。

リサーチエージェント v2 は、次のような一連のゲートを使用できます：

``markdown
``text

release_gate:

primary:

metric: paired_whole_task_success

requirement: Actual improvement exists, and confidence intervals support it

non_inferiority:

critical_workflows:

max_allowed_drop_percentage_points: 0.5

safety:

critical_unauthorized_actions: 0

fabricated_sources: 0

high_risk_failure_upper_bound: below_policy_threshold

reliability:

critical_case_pass_power_k: above_target

efficiency:

max_cost_increase_per_success: 5%

max_p95_latency_increase_ms: 200

slices:

no_major_regression:

• conflicting_sources
• insufficient_evidence
• tool_failure
• high_risk

operations:

trace_completeness: 100%

judge_calibrated: true

rollback_ready: true
``

これらの数値はあくまで構造を示す例です。実際のしきい値は、ビジネスリスク、現在のベースライン、サンプルサイズに基づいて決定する必要があります。

<payload-block id="blk_8" type="upload" />

プライマリメトリクスは、全体的な目標が進捗しているかどうかを示します。非劣性テストは、重要なパスが犠牲になるのを防ぎます。安全性と権限はハードゲートです。信頼性は、タスクを安定かつ継続的に完了できるかどうかを評価します。効率性は、リクエストあたりのコストではなく、成功あたりのコストに焦点を当てます。

**なぜ「成功タスクあたりのコスト」を使うのか？**

安価なエージェントが頻繁に失敗し、3回再実行が必要だったり、人間による手直しが必要だったりする場合、実際のコストは高くなる可能性があります。単一の API 費用だけを見ていると、安価な失敗を最適化と誤認する恐れがあります。

すべてのゲートを通過した後も、すぐにトラフィックの 100% を切り替える必要はありません。

まず **シャドウ** を実行します。v2 に実際のリクエストを処理させつつユーザーに影響を与えず、現在のシステムとの違いを比較します。次に **カナリア** を行い、低リスクのトラフィックのごく一部にのみ公開し、ロールバック可能な状態を維持します。実行記録が安定したら、徐々に拡大します。

Eval の最終目標は、説明可能でロールバック可能なリリース判断を下すことです。

## **オンライン障害はオフライン評価にフィードバックする**

オフラインデータが現実世界を完全にカバーすることは決してありません。

ユーザーは新しい表現を使い、外部の Web ページはレイアウトを変更し、API はこれまで見たことのないエラーを返し、ビジネスポリシーは更新されます。エージェントが稼働を開始した後も、評価フレームワークは機能し続ける必要があります。

完全なクローズドループは次のように記述できます。

<blockquote>
<p>プロダクショントレース
→ オンライン評価
→ 障害マイニング
→ 人間によるレビュー
→ ゴールデンセット
→ オフライン実験
→ リグレッション
→ リリース</p>
</blockquote>

<payload-block id="blk_9" type="upload" />

オンラインでは、すべてのレコードを最も高価な Judge に送信する必要はありません。まずは低コストのチェックから始めます。ツールエラー、空の出力、ループ数、コストの異常、引用の欠落、ユーザーの再試行、人間による介入などです。

次に、これらから 3 種類のサンプルを抽出します。

- 明らかに失敗した、またはアラートがトリガーされたタスク
- Judge が確信を持てない、または異なる Grader が互いに矛盾するタスク
- 通常のトラフィックからのランダムサンプル

最初の 2 つは問題を迅速に見つけるのに役立ちます。ランダムサンプルは、システムが認識していない新しい障害を発見する役割を担います。

人間によるレビューの後、代表的なインシデントを regression に追加し、新しい高リスクパターンを challenge に追加します。問題が新しい顧客やビジネススライスに起因する場合は、メインテストセットのサンプリング設計に追加します。

Prompt、Model、RAG、Skill、Tool、Workflow を変更するたびに、同じテストケースセットで再実行します。一度に変更する主要変数は 1 つだけにし、結果の変化の原因を特定できるようにします。

システムの複雑さが増すにつれて、**コンポーネントリフト** を測定することもできます。

例えば、タスク、モデル、ワークスペース、スコアラーを固定し、特定の Skill がロードされているかどうかのみを変更します。

<blockquote>
<p>Skill Lift = Quality(with Skill) - Quality(without Skill)</p>
</blockquote>

同じ方法で、Prompt Lift、RAG Lift、Tool Lift、Memory Lift を測定できます。これにより、「新しいシステムの合計スコアは 85」というだけでなく、コンポーネントの限界価値がわかります。

マルチエージェントシステムでは、この比較がさらに重要です。Planner、Researcher、Critic、Verifier を追加すると、コスト、レイテンシ、ハンドオフ損失、障害ポイントが増加します。同じタスクバッチで最も強力なシングルエージェントベースラインと比較し、品質向上が追加された複雑さを十分に補うことを証明する必要があります。

この部分は第 2 段階に委ねても構いません。

評価フレームワークの最初のバージョンでは、まず単一のエージェント、単一のワークフロー、明確なリリース判断を機能させることに注力すべきです。ツールは問題が増えるにつれて追加していきます。初日からエンタープライズグレードの Eval OS を構築する必要はありません。

## **ディレクトリから始める**

エージェント評価は非常に小規模から始められます。

初日は、明確なタスク、30 の実ケース、いくつかの決定論的チェック、人間用の Rubric があれば十分です。実行後、障害を明確に分類し、問題が検索、ツール、推論、検証、停止条件のいずれに起因するかを特定します。

リリース準備時には、データを 100～300 ケースに拡大し、完全なトレースを残し、LLM Judge をキャリブレーションし、重要なタスクでは反復試行を実施し、結果に信頼区間とスライス分析を追加します。

プロダクション投入後は、シャドウ、カナリア、アラート、ロールバックを接続します。すべての実際のインシデントはリグレッションケースとなり、次回は繰り返されません。

振り返ってみると、この方法全体は常に同じことを中心に展開しています。

<blockquote>
<p>まず、どのような判断が必要かを明確にする
→ 「完了」の意味を明確に定義する
→ 実際のタスクでデータセットを構築する
→ 結果と軌跡の両方を確認する
→ ルール、Judge、人間による階層的なスコアリングを使用する
→ 繰り返し実行して信頼性を確認する
→ リリースゲートを使用してリリース判断を行う
→ オンライン障害を評価セットにフィードバックする</p>
</blockquote>

モデルはタスクが *実行可能か* どうかを決定します。

評価フレームワークは、それを **安定して、安全に、説明可能な形で** 引き渡せることを証明する責任があります。

参考資料:

[https://x.com/ClorisSignal/status/2090852298620801208](https://x.com/ClorisSignal/status/2090852298620801208)
``

https://x.com/ClorisSignal/status/2090852298620801208