AIエージェントの失敗を改善につなげる――NVIDIA NeMoで、実行トレースから評価とハーネスの修正を作る方法
結論：NVIDIAが紹介したのは、AIエージェントの実行トレースから失敗のパターンを見つけ、それを再現する評価を作り、エージェントのハーネス（システムプロンプトやツールの使い方など）を修正し、ホールドアウトの評価で改善を確認する、という改善サイクルをツールで回す方法です。
ポイントは次の3つです。
- 問題：エージェントの失敗の原因は、モデルだけでなく、プロンプト、ツール、ルーティング、メモリ、スキル、制御コードにあることが多い。汎用のベンチマークでは見つからない
- 方法：NeMo Compass（トレース分析）→ NeMo Eval Author（評価の作成）→ コーディングエージェントによる修正 → ホールドアウトの評価での確認、の順に回す
- 結果：架空の業務アシスタントでは合格数が3/6から6/6に増え、ツール呼び出し回数が約半分になった。ダッソー・システムズの設計支援エージェントでは、形式の誤ったツール呼び出しが142件から0件になった
2026年11月4日にNVIDIAの技術ブログで紹介されました。
前提：ハーネス、トレース、評価
ハーネス
AIエージェントは、LLMだけでは動きません。LLMの周りに、次のような仕組みがあります。
| 要素 | 内容 |
|---|---|
| システムプロンプト | エージェントの役割やルールを定義する |
| ツール | メール送信、検索、ファイル操作など |
| ルーティング | どの処理に回すかを決める |
| メモリ | 過去のやり取りを保持する |
| スキル | 特定の作業の手順 |
| 制御コード | 確認や承認などの処理 |
これらLLM以外の部分をまとめて ハーネス と呼びます。エージェントの失敗の多くは、モデルの能力ではなく、ハーネスの不備から生じます。
トレースと評価
- トレース：エージェントが1回の処理で、どのような判断をし、どのツールを、どのような引数で呼び出したかの記録
- 評価（eval）：決まった課題をエージェントに実行させ、合否を自動で判定するテスト
- ホールドアウト：修正を行うコーディングエージェントには見せない、別の評価課題。見せた課題だけで改善しても、その課題に過度に合わせた修正（過学習）の可能性がある。ホールドアウトでも改善して初めて、汎用的な改善と判断できる
失敗の例：下書きの依頼で送信してしまう
NVIDIAが示した失敗例は次のとおりです。
ユーザーが「プロジェクトの進捗をまとめたメッセージを下書きして」と依頼したところ、エージェントは下書きを作成しただけでなく、ユーザーの確認を取らずに送信ツール（
send_message）も呼び出した。
モデルの文章作成能力には問題がありません。問題は「送信前に必ず確認を取る」というルールが、ハーネスで守られていないことです。こうした失敗は、汎用の知識やコーディングのベンチマークでは検出できません。
改善サイクルの5ステップ
| ステップ | 内容 | 使うツール |
|---|---|---|
| ① トレース分析 | 実行トレースから、繰り返し発生している問題を見つける | NeMo Compass |
| ② 評価の作成 | 見つかった問題を再現する評価を作る。人がレビューして調整する | NeMo Eval Author |
| ③ ハーネスの修正 | コーディングエージェントが修正案を出す | Codex、Claude Codeなど |
| ④ 測定 | 開発用の評価とホールドアウトの評価を実行し、両方で改善したら採用する | Harbor、NeMo Gym |
| ⑤ 繰り返し | 修正後の新しいトレースを分析し、次の問題を探す | NeMo Compass |
① NeMo Compass：トレースから問題を見つける
NeMo Compassは、保存されたトレース（1行に1回の実行を記録したJSON）と評価の結果を、あらかじめ書いた エージェントの期待される振る舞いの仕様書（ETHOS.md）と照合して分析します。
- 繰り返し発生している問題を見つける
- ツールの使い方の異常や、期待される振る舞いからのずれを指摘する
- 指摘ごとに、根拠となるトレースのIDを示す
結果は、根拠となる例が付いた、優先順位付きの課題リストとして出力されます。
③ ハーネスを修正する
コーディングエージェントが修正案を出します。例では、エージェントのシステムプロンプト（Hermes Agentの SOUL.md）に、送信前の確認に関するルールを追加しています。システムプロンプト以外に、ミドルウェアやプラグインで修正する方法もあります。
モデルを再学習するのではなく、ハーネスを修正する点が重要です。再学習に比べて、短時間・低コストで試せます。
④ 2種類の評価で測定する
修正後、開発用の評価と、コーディングエージェントに見せていないホールドアウトの評価の両方を実行します。両方で改善した場合だけ修正を採用します。どちらかで悪化した場合や、結果が明確でない場合は、再度分析から行います。
⑤ 次の問題へ
修正後のエージェントの新しいトレースをNeMo Compassで分析し、次の問題を探します。
結果
架空の業務アシスタント
チャット、メール、ファイル、チケットにMCPで接続した架空企業のアシスタント（Hermes AgentをOpenShellのサンドボックスで実行）での結果です。開発用・ホールドアウトとも、2課題を各3回実行しています。
| 評価 | 合格数（修正前→修正後） | ツール呼び出し回数（修正前→修正後） |
|---|---|---|
| 開発用 | 3/6 → 6/6 | 10 → 6 |
| ホールドアウト | 4/6 → 6/6 | 28 → 15 |
ホールドアウトでも合格数が増え、ツール呼び出しがほぼ半分になりました。不要なツール呼び出しが減ったことを示しています。この例で分析したトレースは42件です。
ダッソー・システムズの設計支援エージェント
自動車のドア設計を支援するエージェント（LEO）での結果です。
- 形式の誤ったツール呼び出しが 142件から0件 に減り、正確さは変わらなかった
- 6つのシナリオで、総合評価スコアが相対で約28%向上し、1回あたりのツール呼び出しが35%減った
- 他のシナリオでの悪化は報告されていない
- 最初の1サイクルは、人の介入なしで約12時間かけて実行された
試すのに必要な環境
- Ubuntu 24.04（推奨：8 vCPU、メモリ32GB）とDocker
- OpenShell 0.1.2、Harbor 0.22.0
- NVIDIAのAPIキー
- 対応するコーディングエージェント（CodexやClaude Codeなど）
NeMo Compass、NeMo Eval Author、NemoClawのコミュニティのサンプルは、GitHubで公開されています。
制約と注意点
- 例として示された実験は小規模です（開発用・ホールドアウトとも2課題×3回）
- 自動で作成した評価は、人がレビューして要件に合わせる前提です
- ホールドアウトの課題は、コーディングエージェントから見えないよう管理する必要があります
- ダッソー・システムズの結果は、第三者が検証できる形では公開されていません
まとめ
- エージェントの失敗の多くは、モデルではなく、プロンプト、ツール、確認処理などのハーネスに原因がある
- NeMo Compassでトレースから問題を見つけ、NeMo Eval Authorで評価を作り、ハーネスを修正し、ホールドアウトの評価で改善を確認する
- 「開発用とホールドアウトの両方で改善した場合だけ採用する」という条件が、過学習した修正を防ぐ
あわせて読みたい
- OpenShell：AIエージェントの実行環境とCNCFへの寄贈
エージェントがアクセスできる範囲をポリシーで制限する実行環境 - Agent Substrate：待機の長いエージェントを少数のPodで動かす
エージェントを大規模に動かす仕組み
参考