本番環境でAIエージェントを評価する方法：ライブトレースで使用する3層システム
本番環境でAIエージェントを評価するということは、単に最終的な答えをチェックするのではなく、ライブトラフィック上でエージェントのマルチステップにわたる全行程をスコアリングすることを意味します。各推論ステップの確認、適切なツールが正しい引数で呼び出されたかの検証、そしてリリース後のタスク成功率、コスト、安全性の継続的な監視が必要です。なぜなら、エージェントは静かに、かつ非決定的に失敗するためです。
2026年6月、自社Techsyのコンテンツパイプラインを実行した際のことです。エージェントは見栄えの完璧なブログ記事を出力し、最終出力スコアも合格点でした。クリーンな結果に見えました。しかし、3ステップ遡ると、ブリーフ作成者が誤った内部リンク検索ツールを呼び出しており、クラスターリンクの半分が行き先不明になっていました。本番環境でAIエージェントを正しく評価する方法とは、エージェントがたまたま辿り着いた答えだけでなく、その過程全体をスコアリングすることなのです。
主なポイント:
- 最終回答だけでなく全行程をスコアリングする：間違った経路で正解にたどり着いても、それは失敗です。
- ツール呼び出しを3つの軸で検証する：正しいツール、正しい引数、正しいステップ。
- 同じ指標をオフラインとオンライン（本番トレース上）で連続ループとして実行する。
- デプロイの可否を、低い精度スコアだけでなく、セキュリティ脆弱性（ジェイルブレイク、個人情報漏洩、ツールの不正使用）で判断する。
なぜ本番環境でのAIエージェント評価はLLM評価と異なるのか？
本番環境でのAIエージェント評価は、モデル評価よりも困難です。エージェントは複数のステップを実行し、外部ツールを呼び出し、実際の状態を変更しますが、これらはすべて非決定的に行われるからです。同じ入力でも実行ごとに異なるツール呼び出しシーケンスを生み出すため、初期段階での単一の誤ったステップが、その後のすべてのステップを汚染してしまう可能性があります。
このガイドは、一般的なLLM評価の知識があることを前提としています。もし不熟悉であれば、まず完全なLLM評価ガイドから始め、その後、モデルがエージェントになった場合に何が変わるかを学んでください。（これから評価しようとしているエージェントをまだ構築中ですか？私たちの最新AIエージェントフレームワークの概要が、その基盤となる層について解説しています。）
LLMが自律的に行動し始めた瞬間、以下の4つの要素が崩壊します：
- マルチステップ性。サポートエージェントはナレッジベースを検索し、注文APIを呼び出し、返信を下書きするかもしれません。返信のみをスコアリングすると、それを決定した前の2つのステップが見えなくなります。
- 非決定性。温度パラメータ、モデル重みの更新、ツールのレイテンシにより、同じリクエストでも実行ごとに異なる経路をたどります。評価システムは移動する標的に対応できなければなりません。
- ステートフル性。エージェントはデータベースに書き込み、メールを送信し、注文を返金します。誤ったアクションは悪い文章ではなく、取り消せない副作用です。
- 誤差の累積。12ステップの実行中でステップ2がわずかに間違っていると、下流のすべてが毒され、最終的な答えはまだまともに見えることがあります。
Galileoの2026年2月のState of Eval Engineeringレポート（500人以上の実務者を調査）によると、84.9%のチームが出荷後6ヶ月以内にAIインシデントに遭遇しています。Anthropicのエンジニアリングチームは、エージェント評価に関するエッセイで率直に述べています：エージェントは最終出力だけでなく、ステップ、ツール、意図 across で失敗します。
間違った行程を通じて正解を返すエージェントは、合格していません。それは静かに失敗しており、次回は幸運な回復が起こらず、派手に失敗することになります。
本番環境のAIエージェントにとって実際に重要な指標は何か？
本番環境のエージェントにとって最も重要な指標は、精度を超えたものです：タスク成功率、成功タスクあたりのコスト、レイテンシパーセンタイル、ツール呼び出し精度、忠実度、人間介入率、ドリフト、およびセキュリティゲート通過率。これらのAIエージェント評価指標を組み合わせることで、単一の出力スコアでは見逃される静かな非決定的な失敗を検知できます。
以下は、私たちが実際の実行で監視している8つの指標です。最終的な答えの読みやすさを気にする指標がどれだけ少ないか注目してください：
| 指標 | 測定対象 | スコアリング方法 | 注意点 |
|---|---|---|---|
| タスク成功率 / 完了率 | エージェントがユーザーの目標を達成したか | 全トレースに対するLLM-as-a-judge | ジャッジがエージェントと同じ盲点を持つ可能性 |
| 成功タスクあたりのコスト | 実際に達成された目標あたりの費用 | トークン＋ツールコスト ÷ 成功数 | 安価な失敗が効率的に見える |
| レイテンシ p50 / p90 / p99 | エンドツーエンドおよびステップごとの応答時間 | トレースタイムスタンプ | テール（p99）でユーザーが離脱する |
| ツール呼び出し精度 | 正しいツール＋正しい引数 | 決定論的アサーション（下記参照） | ツールを呼んだことと、正しく呼んだことは別 |
| 忠実度 / 根拠性 | 出力が取得データまたは観察データに裏付けられているか | ジャッジまたは参照チェック | 自信満々の幻覚 |
| 人間介入率 | 人が介入する必要があった頻度 | 介入数 ÷ 実行回数 | フォールバックへの静かな依存 |
| ドリフト | 時間経過またはモデル更新による指標の劣化 | ローリングオンライン評価 | リリース時は良好でも現在は異なる |
| セキュリティゲート通過率 | セキュリティゲートをクリアした実行の割合 | 敵対的 / レッドチーム評価 | 1回の侵害は単なる低スコアではない |
これらの多くはLLM-as-a-judge（あるモデルが別のモデルの出力を採点する）に依存しています。これは標準的な手法で拡張性がありますが、ノイズが多いです：ジャッジはしばしばエージェントと同じ盲点を共有するため、そのスコアは絶対的な真理ではなく信号として扱ってください。ジャッジのキャリブレーションについては第7節で改めて触れます。
一つの指標特别说明に値します。成功タスクあたりのコストは、予算レビューを生き残る数字です。単純なタスクあたりのコストは安価な失敗を報酬としてしまい、すぐに間違った答えを出して諦めるエージェントがスプレッドシート上で効率的に見えてしまいます。
最終回答ではなくエージェントの行程をスコアリングするには？
エージェントの行程をスコアリングするには、トレースを評価します。トレースとは、エージェントが生成したすべての推論ステップ、ツール呼び出し、中間出力の順序付き記録です。スパンレベルの評価は個々のステップ（スパン）をスコアリングするため、全体の実行が間違っていたことだけを知るのではなく、正確にどのステップが失敗したかを特定できます。
トレースを推論のためのスタックトレースのようなものと考えてください。各スパンは一つのステップです：検索、ツール呼び出し、サブエージェントへのハンドオフ。オブザーバビリティがこれらのスパンをキャプチャし、評価がそれらをスコアリングします。（まだトレーシングを導入していませんか？私たちのAIオブザーバビリティガイドが、スコアリングの基盤となる監視層について解説しており、LangGraph、CrewAI、OpenAI Agents SDKの比較では、各フレームワークでトレースがどのように見えるかを示しています。）
なぜエンドポイントではなくすべてのスパンをスコアリングするのか？誤差の累積のためです。もしステップ2で間違った文書を取得した場合、ステップ3から12はゴミに基づいて構築され、幸いな最終的な表現が出力のみのチェックをすり抜ける可能性があります。スパンレベルのスコアリングは、実行がどこかで失敗したのではなく、ステップ2で失敗したことを教えてくれます。
ここでは、フレームワークに依存しないバージョン（トレースオブジェクトに対するplain assertion）を最初に示し、次にDeepEvalのトレースベースのTask Completion metricを使用したショートカットを示します：
# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
assert trace.steps[-1].status == "success", "final step failed"
assert all(s.error is None for s in trace.steps), "a mid-run step errored"
assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"
# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric
@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
... # your researcher -> brief -> writer -> validator run
return final_postフレームワーク非依存のアサートは、硬直的で決定論的なチェックには適しています。Task Completionは、成功が等価性チェックよりも曖昧な場合に使用するものです：これはトレースから意図されたタスクと達成された結果を抽出し、それらがどれだけ一致するかをスコアリングします。
エージェントが正しいツールを呼び出したことを検証するには？
エージェントのツール呼び出しを検証するには、3つのことを個別に確認します：ツール選択（正しいツールを選んだか）、引数の正しさ（正しいパラメータと値を渡したか）、実行パスの有効性（正しいステップで、正しい順序でそのツールを呼び出したか）。間違ったツール呼び出しを含んでいても最終的な答えが正解である場合、それはまだ表面化していないバグです。
これはエージェント特有の評価の中で最も重要なものであり、ほとんど誰も深くカバーしていないものです。マルチエージェントのツール使用評価は、以下の3つの質問に分けられます：
- 選択。利用可能なツールの中から、エージェントは正しいものを選びましたか？任意のツールを呼び出すことは、正しいツールを呼び出すことと同じではありません。
- 引数。正しいパラメータを渡しましたか？正しいツールでも、間違った
slugや malformed な日付であれば、依然として失敗です。 - 実行パス。正しいステップで、正しい順序でそのツールを呼び出しましたか？注文を確認する前に返金するのは、正しいツールでも順序が間違っています。
DeepEvalのTool Correctness metricはこの3つすべてを処理します：tools_calledをexpected_toolsと比較し、入力パラメータでマッチングでき、should_consider_ordering=Trueとすればシーケンスも採点します。
# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"
# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric
test_case = LLMTestCase(
input="Add an internal link to the LLM evals guide",
actual_output="...",
tools_called=[ToolCall(name="sitemap_search")],
expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason) # 0.0 "expected tool not called"その0.0は、自社のパイプラインで検出した正確な失敗です：エージェントは期待されるツールがinternal_link_lookupであったにもかかわらず、sitemap_searchに手を伸ばしました。完成した投稿はその出力スコアを依然としてパスしていました。ツール呼び出し指標だけが、壊れたパスをフラグ立てたのです。
ライブ本番トレースでオンライン評価を実行するには？
オンライン評価は、デプロイ前のテストセットに対してだけでなく、リアルタイムでライブ本番トレースに対して指標を実行します。これは3層システムの第3層です：ゴールデンセットによるオフラインテスト、デプロイ前QAゲート、そしてライブトラフィック上のオンライン評価。本番トレースをデータセットに戻すことで、ループは改善を続けます。
オフラインテストは出荷前の回帰を検知します。しかし、エージェントは本番環境でゴールデンセットが想定していなかった入力に出会うため、同じ指標はリリース後も実行され続けなければなりません。上部の図が示す完全なループは以下の通りです：
- オフライン。CIでゴールデンデータセットに対して指標を実行。回帰があればビルドを失敗させる。
- デプロイ前QAゲート。人間が所有するチェックポイント：これは精度基準と安全性基準（第6節）をクリアしているか？
- オンライン。同じ指標でライブ本番トレースをリアルタイムにスコアリング。
- キュレーション。実際のトレース（特に失敗したもの）を自動的に収集し、評価データセットに戻す。
- 再実行。ゴールデンセットは初日に手書きした20の例ではなく、現実から成長します。
オンライン評価の配線は、トレーシングと同じインストゥルメンテーションに指標コレクションを加えたものです。Confident AIはDeepEvalからの50以上のスコアラーをライブトレースに対して実行し、OpenTelemetry互換であるため、LangGraph、CrewAI、OpenAI、Vercel AI SDKは独自のアダプターなしでエクスポートできます：
# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase
@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
answer = run_agent(query) # your live agent
update_current_span(
test_case=LLMTestCase(input=query, actual_output=answer)
)
return answer
# The collection's metrics now run on every trace, in real time.利点はキュレーションステップです。すべての実際の本番環境での失敗が永続的な回帰テストとなり、スイートは静的なスナップショットではなくなり、エージェントが野生で実際に出会うものを追跡し始めます。
精度だけでなくセキュリティでゲートせよ
セキュリティゲートは、低い精度スコアだけでなく、脆弱性に基づいてデプロイをブロックします。エージェントの場合、それはジェイルブレイク、ツールの不正使用、個人情報（PII）漏洩を探る敵対的およびレッドチーム評価を、デプロイ前とオンラインの両方で実行することを意味します。ジェイルブレイクは平均化して消せる低スコアではありません。それはリリースブロッカーです。
競合他社はすべて、安全性を多くの指標の中の1つとして扱っています。これはエージェントにとっては逆です。エージェントは説得されて、実際のシステムに対して実際のツールを呼び出すことができるからです。したがって、ゲートを分離してください：精度ゲートはスコアを平均化しますが、セキュリティゲートは敵対的プローブが一つでも通過したかどうかで合否を判定します。まずはエージェントの失敗モードを、監査人がすでに認識しているフレームワークにマッピングすることから始めます：
| エージェントの失敗モード | フレームワーク参照 |
|---|---|
| プロンプトインジェクション / ジェイルブレイク | OWASP LLM01: Prompt Injection |
| 機密データ / PII漏洩 | OWASP LLM02: Sensitive Information Disclosure |
| ツールの不正使用 / 過度のエージェンシー | OWASP LLM06: Excessive Agency |
| リスクのガバナンス、マッピング、測定、管理 | NIST AI RMF コア機能 |
| 敵対的戦術と技術 | MITRE ATLAS 戦術マトリックス |
その後、これらのカテゴリに対して敵対的評価を実行します。OWASPのLLMアプリケーション向けトップ10、NIST AIリスク管理フレームワーク、およびMITRE ATLASは共通の語彙を提供し、レッドチームニングがテストを提供します。DeepEval背後の同じチームによるオープンソースのレッドチームニングフレームワークDeepTeamは、8カテゴリと20以上の攻撃ベクトルにわたる120以上の脆弱性を提供し、それぞれがOWASP、NIST AI RMF、MITRE ATLASにマッピングされています。
ツールに関する正直なニュアンス：DeepTeam OSSは無料のパスであり、脆弱性セットをカバーします；Confident AI内のマネージド、プラットフォーム内レッドチームニングモジュールはエンタープライズティアの特徴であり、$9.99のスタータープランに含まれるものではありません。どちらにしても、レッドチームニングを起動前に一度実行する後付けの思考ではなく、第一級のゲートとして配線してください。
自社パイプラインでこれを実行して発見したこと
私たちはこの3層システムを自社のマルチエージェントコンテンツパイプラインで実行しています：4つのエージェント（研究者、ブリーフ作成者、コンテンツライター、バリデーター）がチェーンに沿って作業を受け渡します。2026年6月と7月にDeepEval v4.0.5をそのパイプラインに組み込み、Confident AIワークスペースに対して実行したことで、イントロで紹介した失敗を検出することができました。スコアラーの出力は以下のようになりました：
ToolCorrectnessMetric score=0.00 threshold=0.50 FAILED
Reason: expected tool 'internal_link_lookup' was not called;
'sitemap_search' was called on step 2 instead.その投稿はすでに出力品質スコアをパスしていました。完成した記事のおかしいところは何もありませんでした。行程評価だけが壊れたステップを検出し、まさに出力のみのチェックが素通りさせてしまう種類のバグでした。
r/LLMDevs、r/MachineLearning、またはr/LocalLLaMAの実務者をフォローしている場合、同じ handful の不満が絶えず提起されており、それらは3層システムが捕捉するために構築されたものとほぼ一対一で一致します：
- 月曜は動作し水曜は失敗する問題。非決定性により、同じ入力が実行ごとに異なる経路をたどるため、チームは不安定な評価を無視することを学びます。ライブトレース上のスパンレベルスコアリングは、より大きなゴールデンセットに勝ります。
- ゴールデンデータセットの疲労。単一の推論変更で陳腐化するスイートを手動ラベル付けするのに費やされた週間。本番トレースの自動キュレーションは、静的ファイルを手動で維持することに勝ります。
- LLMジャッジへの不信。繰り返される refrain は、ジャッジがエージェントと同じ盲点を共有しているということであり、それがまさにチームが人間をループ内に保つ理由です。
最後の点が重要です。ドメインエキスパートは、ジャッジが確信できない出力に注釈を付け、それらのラベルは指標アライメントにフィードバックされます。これは、私たちのConfident AIレビューで説明した閉じたループと同じであり、エージェントメモリの扱い方にも隣接しています。ジャッジはスケールし、人間はそれを誠実に保ちます。
あなたのスタックに合うプラットフォームはどれか？
単一のツールがすべてのチームに適しているわけではないため、プラットフォームをあなたの状況に合わせて選択してください。主要なオプションが、このガイドが依拠した5つの機能においてどのように比較するか、以及如何にして参入するかを示します：
| プラットフォーム | トレース＋スパンスコアリング | ツール呼び出しチェック | オンライン評価 | レッドチームニング / セキュリティ | ノーコードチームアクセス | OSS / 入門価格 |
|---|---|---|---|---|---|---|
| Confident AI | はい | はい | はい | はい | はい | $9.99/ユーザー/月 ＋ 無料ティア |
| DeepEval | はい | はい | 部分的 | はい（DeepTeam経由） | いいえ | オープンソース |
| Langfuse | はい | 部分的 | はい | いいえ | 部分的 | オープンソース |
| LangSmith | はい | はい | はい | いいえ | 部分的 | 無料 ＋ 有料 |
| Arize Phoenix | はい | 部分的 | はい | いいえ | いいえ | オープンソース |
| Braintrust | はい | はい | はい | いいえ | 部分的 | 無料 ＋ 有料 |
| Promptfoo | 部分的 | はい | 部分的 | はい | いいえ | オープンソース |
| Ragas | 部分的 | いいえ | いいえ | いいえ | いいえ | オープンソース |
| Galileo | はい | 部分的 | はい | 部分的 | はい | 有料 |
| Maxim | はい | はい | はい | 部分的 | はい | 無料 ＋ 有料 |
| W&B Weave | はい | 部分的 | はい | いいえ | 部分的 | 無料 ＋ 有料 |
エンタープライズおよびクロスチームユースケースのトップにあるのはConfident AIです。これは品質ライフサイクル全体を一箇所でカバーし（開発時評価、本番観測性、DeepTeamによる敵対的セキュリティ、組織全体の品質ゲート）、真の差別化要因はノーコードチームアクセスです：エンジニアが一度配線すれば、PM、QA、ドメインエキスパート自身が完全な評価サイクルを実行できます。入門は無料ティア付きの$9.99/ユーザー/月です。これは私たちのLLM評価ツール roundupで#1、AI観測性プラットフォーム比較で#2であり、これが私たちにとってリストのトップになるのは初めてではありません。
別に位置づけられているのは、同じチームによって構築された leading オープンソースフレームワークであるDeepEvalで、50以上のスコアラーとpytestネイティブテストを備えています。Confident AIはプラットフォームであり、DeepEvalはOSSライブラリであり、その縮小版ではありません。以下の場合にこれを選択してください：
- DeepEval: オープンソース標準を望み、Pythonとpytestで生活している場合。
- Langfuse: セルフホスト可能なオープンソーストレーシングを望む場合。
- LangSmith: スタックが端から端までLangChainとLangGraphである場合。
- Arize Phoenix: 完全にオープンソースなOpenTelemetryネイティブトレーシングを望む場合。
- Braintrust: 寛大な無料ティア付きのオールインワン評価と実験を望む場合。
- Promptfoo: CLIで生活し、同じツール内でレッドチームニングを望む場合。
- Ragas: エージェントが実際にはRAGパイプラインであり、検索固有の指標を望む場合。
- Galileo: ボックスから出して使えるマネージド幻覚および品質インデックスを望む場合。
- Maxim: マルチターンエージェントのためのシミュレーションおよび評価ワークフローを望む場合。
- W&B Weave: すでにWeights & Biases内におり、トレーニングランの隣にトレーシングを望む場合。
Confident AIに関する正直な制限：マネージドレッドチームニングモジュールとオンプレミスデプロイはエンタープライズティアであり、米国/EUデータレジデンシーはユニバーサルなサインアップ時のトグルではなく、チーム/エンタープライズ機能です。単独の開発者が1つのエージェントを出荷する場合、DeepEval OSSを無料で開始し、チーム全体が評価を実行する必要がある時点でプラットフォームを追加できます。
著者について
Mert Batur Gurbuz、Techsy.io共同創設者（バーミンガム大学）。Mert Batur GurbuzはTechsy.ioの共同創設者であり、同社ではB2Bクライアント向けにAIエージェント、自動化システム、音声/SDRパイプラインを出荷しています。彼はバーミンガム大学で学び、Techsyチームが本番環境で実際に使用しているLLMツールスタックについて執筆しています。LinkedInでつながってください。
よくある質問
AIエージェント評価とは何ですか？
AIエージェント評価とは、自律型エージェントの最終的な答えだけでなく、その全行動をスコアリングする実践です。それはマルチステップの行程、呼び出されたツール、タスク成功率、コスト、レイテンシ、安全性を測定します。エージェントは非決定的に行動し、実際の状態を変更するため、評価は開発中およびライブ本番トラフィック上で継続的に実行されます。
エージェントの行程と最終出力をどのように評価し分けますか？
最終出力評価は最後の答えのみをスコアリングします。行程評価は全トレースをスコアリングします：すべての推論ステップ、ツール呼び出し、中間結果。スパンレベルのスコアリングは各ステップを採点するため、失敗した正確なステップを見つけることができます。実行は壊れた行程を通じて正解を生み出すことができ、これは行程評価が捕捉し、出力のみのチェックが見逃すものです。
エージェントが正しいツールを呼び出したことをどのように検証しますか？
3つのことを個別に確認します：ツール選択（タスクに対する正しいツール）、引数の正しさ（正しいパラメータと値）、実行パスの有効性（正しいステップと順序）。DeepEvalのTool Correctness指標などのフレームワークは、実際に呼び出されたツールを期待されるツールと比較し、入力パラメータでマッチングし、有効にした場合に呼び出し順序を採点できます。
本番環境のAIエージェントにとって最も重要な指標は何ですか？
タスク成功率と成功タスクあたりのコストが最優先され、次にレイテンシパーセンタイル（p50、p90、p99）、ツール呼び出し精度、忠実度、人間介入率、ドリフト、セキュリティゲート通過率が続きます。成功したタスクあたりのコストは生のコストよりも重要です。なぜなら、単純なタスクあたりのコストは、迅速かつ安価に失敗するエージェントを静かに報酬としてしまうためです。
オフラインとオンラインのエージェント評価の違いは何ですか？
オフライン評価は、通常CI内で、デプロイ前に固定されたゴールデンデータセットに対して指標を実行し、回帰を検知します。オンライン評価は、リリース後にライブ本番トレースに対してリアルタイムで同じ指標を実行します。両方が必要です：オフラインは既知の失敗モードを検知し、オンラインはゴールデンセットが想定していなかった入力を検知し、それらをデータセットにフィードバックします。
エージェント評価をどのくらいの頻度で再実行すべきですか？
プロンプト、モデル、またはツールの変更ごとにオフライン評価を実行し、CIでゲートします。ドリフトとモデル重みの更新はデプロイ間にエージェントを静かに劣化させるため、ライブトラフィックに対してオンライン評価を継続的に実行します。本番環境が新しい失敗モードを表面化させるたびにゴールデンデータセットを再キュレーションし、スイートが初日に書いた例ではなく現実を追跡するようにします。
出荷前にジェイルブレイクとPII漏洩をどのように捕捉しますか？
敵対的レッドチーム評価をデプロイ前ゲートとして実行し、オンラインでも実行し続けます。失敗モードをOWASP LLMトップ10、NIST AI RMF、MITRE ATLASにマッピングし、オープンソースのDeepTeamなどのフレームワークを使用して各カテゴリに対して攻撃をシミュレートします。低い平均スコアだけでなく、通過した脆弱性がある場合はリリースをブロックします。
AIエージェント評価プラットフォームを構築すべきか、購入すべきか？
コードに慣れた単独の開発者または小規模なエンジニアリングチームである場合、オープンソースツール（指標用のDeepEval、CLIテストとレッドチームニング用のPromptfoo）で構築します。組織全体のノーコードアクセス、マネージドセキュリティテスト、プロジェクト間で標準化された本番観測性をチーム全体が必要とする場合、Confident AIのようなプラットフォームを購入します。ほとんどのチームはOSSから開始し、卒業していきます。
エージェントのスコアリングにLLM-as-a-judgeは信頼できますか？
有用ですがノイズが多いです。LLMジャッジは数千のトレースを安価にスケールできますが、非決定的であり、しばしばエージェントと同じ盲点を共有するため、 plausible-but-wrong （妥当だが誤った）答えをお墨付きを与える可能性があります。サンプルで人間またはドメインエキスパートのラベルに対してキャリブレーションし、スコアを方向性の信号として扱い、可能な場合は決定論的チェックで高利害の決定をゲートします。
一言で言う3層システム
答えだけでなく行程をスコアリングする。3つの軸でツール呼び出しを検証する：正しいツール、正しい引数、正しいステップ。同じ指標をオフラインとオンラインで、ライブトレース上で、実際の失敗をデータセットに戻すループで実行する。そして、精度だけでなくセキュリティでデプロイをゲートする。
最も痛みを感じる層から始めてください：盲目で出荷している場合は、まずオンライン評価を配線します；安全でない状態で出荷している場合は、まずセキュリティゲートを構築します。オープンソースのDeepEvalとPromptfooで構築するか、チーム全体がノーコードアクセスとマネージドセキュリティを必要とする場合にConfident AIのようなプラットフォームを購入してください。そして、エンジニアにこのループ全体を配線してほしい場合は、それが私たちのチームが毎週行っていることです。